[DB02] Database system에서 사용되는 개념들
* 10.06 업데이트
해당 게시물은 한양대학교 컴퓨터소프트웨어학부 김상욱 교수님 데이터베이스시스템 온라인 강의를 듣고 정리한 자료입니다.
오류가 있다면 언제든 알려주세요!
● 해당 강의의 학습 목표
1. 데이터 베이스 시스템과 관련된 중요한 개념과 구조에 대해 이해한다.
· Data models
· Schemas and instances
· Data independence (데이터와 application program은 서로 독립적이다. -> DBMS를 씀으로써 사용자 데이터의 구조가 metadata의 형태로 저장되어 있기 때문이다.)
· Database languages and interfaces
◆ Data Models
- data: 실세계에 나타나는 어떤 fact
- data model: data의 특성을 잘 표현하기 위한 것들, database의 구조를 잘 설명하기 위한 개념들의 집합.
ex) 패션 모델은 상품의 특성을 잘 표현하기 위한 것이다. 마찬가지로 데이터 모델은 데이터베이스의 구조, 특성을 잘 표현하기 위한 개념들의 집합이다. 그 개념에는 data types, relations, constraints ... 등이 있다.
- 데이터 모델을 이용하면 데이터베이스의 특징, 구조를 잘 이해할 수 있다.
- 데이터의 추상화를 가능하게 한다. 즉, 데이터에 대한 detail말고 대략적으로 이해할 수 있게끔 도와준다.
ex) 패션 모델만 보고 그 상품의 재료를 알 수는 없다. 마찬가지로 데이터가 몇 바이트가 저장되어있는지 보여준다기 보다는 전체 데이터의 구성 정도만을 보여준다.
- 데이터 모델은 개념의 수준을 기준으로 다음과 같은 세 가지로 구분한다.
1) Physical models
2) Conceptual models
3) Representational models
◆ Categories of Data Models
1. Physical Data Models
· 데이터가 computer storage media(Hard disk, SSD) 안에서 물리적으로 어떤 형태로 저장되는지 그 detail을 표현한다. 즉, 데이터가 어떤 식으로 저장하는지 detail을 알 수 있다.
ex) 사람의 정보를 저장한다고 하자.
위와 같이 몇 바이트에 뭐가 있고 어떠한 type이고 물리적 저장장치 136번째 바이트부터 쭉 저장된다.
- Low-level data model
· Provide record-related information
- Type (Integer, Char, String)
- Index (데이터를 빠르게 access하기 위한 인덱스)
- Access path (빠르게 access할 수 있는 다른 path)
하지만 DBMS가 physical data model을 감추어 주기 때문에 해당 수업에서는 깊게 다루지는 않는다. DBMS는 사용자가 볼 수 있는 정보는 매우 제한적으로 제공하고 있다.
2. Conceptual Data Models
· 일반 사용자는 어떤 데이터가 몇 바이트인지 type이 뭔지 등과 같은 물리적인 정보를 알아듣기 어렵다. 따라서 conceptual data model은 detail한 정보보다는 사람들 입장에서 데이터가 개념적으로 어떻게 표현되는가를 나타내는 모델이다.
ex) 특정 학생과 특정 교수가 특정 교과목에서 만났다. 어떤 교수가 어떤 교과목을 가르친다.
즉, 실세계의 엔티티와 그것들의 관계를 표현하는 것이다.
- 사람들이 데이터를 인식하는 방식으로 표현한다는 점에서 사람과 가깝다.
- High-level data model
· 가장 대표적인 예: Entity-relationship model (ER model) -> 해당 모델에 대해 굉장히 자세하게 배울 예정이다.
이렇듯 하나의 예시라는 것을 기억하자!
3. Representational Data Models
· Physical data model과 Conceptual data model 사이에 있는 중간의 모델이다.
ex) low level language인 machine language는 사람들이 이해하기 어렵다. 반면 high level language인 C언어나 Java와 같은 경우는 사람들이 이해하기는 쉽지만 기계는 이해하기 어렵다. 그 사이에는 Assembly language가 있다. 사람도 비교적 이해하기 쉽고 machine language와 1:1로 mapping되기 때문에 기계도 이해하기 쉽다. 여기서 assembly language와 representational data model이 비슷한 역할을 하는 것이다.
- 이용자가 이해하기 쉽다.
- 데이터가 어떻게 computer storage media에 저장되는지 표현하는 모델인 physical data model과 비슷한 경향도 있다.
- DBMS는 representational data model을 전제로 개발되었고 우리가 알고 있는 ORACLE, SQL Server 모두 representational data model을 탑재하고 있다.
- 이 모델을 가지고 DBMS가 implement되기 때문에 implementation data models라고도 부른다.
· Used in most commercial DBMSs
. 예시: relational model(MYSQL, Microsoft sql server), network model, hierarchical model(과거)
여기서 현재는 대부분이 relational model을 사용하고 있다.
Level을 기준으로 분류 해보자.
Conceptual data model > Representational data model > Physical data model
◆ Schemas and Instances
(data model을 이용해서 database의 구조를 표현한다.) ==
(내 application이 다루는 데이터베이스의 구조를 나타내기 위해서 데이터 모델을 사용한다.)
'아! 우리 데이터 베이스를 이런 구조로 만들어야겠다!' 결정하고 데이터 모델로 그 구조를 표현한다.
그리고 데이터 모델을 통해서 표현한 구조를 데이터 베이스 스키마라고 한다.
· Database schema (or meta-data)
- 모델에 의해서 표현된 database 구조이다. 사용자 데이터를 관리하기 위해서 필요한 것이기 때문에 meta-data라고도 부른다.
- intension이라고도 부르지만 많이 사용되지는 않는다.
- Database designer가 데이터 베이스를 설계할 때 database schema가 defined된다.
- 결정된 데이터 베이스 스키마(구조)는 거의 변하지 않는다. 물론 특별한 상황이 있으면 변하기도 한다.
ex) 학생 정보 구조에 이름, 전화번호, 주소, 나이, 성별이 있었다. 졸업, 입학으로 인해 data가 변할 순 있지만 이 구조 자체가 변하는 경우는 없다. 과거에는 핸드폰이라는 정보는 없었다. 핸드폰이 생기면서 전화번호에 대한 새로운 field가 필요해졌고 이것이 바로 구조가 바뀌는 경우이다.
· Schema diagram
- 스키마를 그림으로 표현하는 것이다. 이 구조는 잘 바뀌지 않고 정보는 쉽게 바뀐다.
instance는 실제 들어가는 데이터 집합이다.
· Database instance
- 특정 시간, 특정 시점에 데이터베이스에 저장되어 있는 데이터를 database instance라고 한다.
- 지금 데이터베이스와 20초 후의 새로운 학생이 들어왔을 때의 데이터베이스는 다르다. 따라서 특정 시간 기점으로 데이터 베이스 instance는 다르게 정의될 수 있다.
- database state, snapshot, occurrence, extension으로 부르기도 한다. // Schema == intension
- database schema와 다르게 database instance는 자주 바뀐다. 학생이 새로 들어왔거나, 학생의 전화번호가 바뀌었거나, 학생이 휴학을 해서 나갔거나 등 삽입, 업데이트, 삭제가 자주 이뤄지기 때문에 하나라도 값이 바뀌면 database instance가 바뀌는 것이다.
◆ Three-Schema Architecture
세가지 데이터베이스 스키마를 가지는 구조
· 주목적
- application program이 데이터베이스 구조에 종속되지 않도록 하기 위함이다.
- For independence
· Database designer(시험에 나올지도 모름!)
- system analyst가 application 사용자 인터뷰를 통해 어떤 데이터가 필요한지 조사해오면 database designer가 database내에 사용할 data를 선택한다.
- 고른 데이터를 하나로 저장하는 것이 아니라 구조를 결정해서 저장한다. 따라서 database designer는 데이터베이스의 구조와 특징을 결정하는 사람이다. 즉, database schema를 결정하는 사람이다.
3가지 스키마는 다음과 같은 종류로 나뉜다.
1) Internal Schema: 실제로 Storage media에 데이터가 구체적으로 어떻게 저장되는가를 Physical data model을 통해서 표현한 것이다.
이 부분이 이해가 안 가서 예시를 들어보았다.
Internal schema가 physical data model을 구현한 결과이다.
ex) Physical data model: 이 테이블의 각 항은 고정된 크기의 바이트로 저장되어야하고 인덱스를 통해 빠르게 접근가능해야 한다. "이러한 계획"
Internal Schema: 이 테이블의 이름 field는 4byte로 저장되어야하고 디스크의 특정 블록에 저장된다. 검색 성능을 높이기 위해 B+ Tree를 사용한다.
"이러한 구체적인 구현 방식"
2) Conceptual Schema: Internal Schema는 너무 low level이기 때문에 사람이 이해할 수 있도록 만든 스키마이다. Conceptual data model 혹은 Representational data model에 의해서 표현된다.
3) External View: 전체 데이터베이스 중 특정 사용자가 바라보는 view를 나타내는 스키마이다.
그림을 풀어서 설명하면 다음과 같다. Conceptual Schema와 Internal Schema는 application에서 다루는 전체 데이터베이스의 스키마이다. 다른 점은 model이 다르다는 점이다. 반면, external view는 전체 데이터베이스 중 특정 사용자가 바라보는 view를 나타낸다. 즉, 일부의 데이터 베이스이다. 모델 자체는 Conceptual Schema에서 사용되는 모델과 동일하다.
정리! (두 번 설명하셨음!!)
Internal Schema & Conceptual Schema
공통점: 전체 데이터베이스를 나타낸다.
차이점: 사용되는 모델이 다르다.(Physical data model / Conceptual data model, Representational model)
Conceptual Schema & External View
공통점: 모델이 같다. (Concetual Schema가 Representational data model을 사용했으면 동일하게 External View도 Representational data model을 사용하고 Conceptual data model을 사용했으면 동일하게 Conceptual data model을 사용한다.)
차이점: Conceptual Schema는 전체 데이터베이스를 나타내는 반면 External View는 해당 사용자가 바라보는 부분 데이터베이스를 나타낸다.
EX) Mapping의 개념에 대한 예시이다.
한 사용자가 데이터베이스 내에서 뭔가를 찾아보고 싶다고 하자. 이 사람은 자신이 바라보는 데이터베이스를 대상으로 요청을 할 것이다. DBMS는 전체 데이터베이스를 가지고 있는데 사용자가 특정 데이터베이스에 대해서 요청했으니 전체 데이터베이스 스키마 입장에서 어떤 것인지 mapping을 해야한다. 이때 사용자가 하는 요청을 query라고 하고 external view에 대한 query를 전체 conceptual schema에 대한 query로 바꿔주어야한다. 이를 external/conceptual mapping이라고 한다. 다시 Conceptaul Schema에 대한 query를 Internal Schema에 대한 query로 바꿔준다. 이를 Conceptual/Internal Mapping이라고 한다. 이제 저장된 database에서 query에 해당되는 것을 처리하고 다시 위로 보내준다. DBMS는 전체를 총괄하면서 사용자의 query를 처리한다.
EX) independence 개념에 대한 예시이다.
만약 전체 database에 대한 internal schema가 바뀌었다고 해보자. 더 구체적으로 data를 access하기 위해서 B Tree를 썼었는데 누군가가 hashing으로 바꿨다고 해보자. 이때는 Internal Schema level에서 meta-data를 바꾸면 되는 것이다. Conceptual Schema는 영향을 받지 않는다. 따라서 Conceptual Schema를 대상으로 만든 external view도 영향을 받지 않고 마찬가지로 사용자의 프로그램은 external view를 대상으로 짜여져 있기 때문에 바뀌지 않아 independence가 유지되는 것이다.
비슷하게 conceptual schema가 바뀌면 이에 해당되는 meta-data가 바뀌기 때문에 external view는 영향을 받지 않고 이를 기반으로 짠 프로그램도 영향을 받지 않는다. independence는 계속 유지된다.
구체적으로 하나하나 뜯어서 보도록 하자! 여기까지 오신 여러분 수고많으십니다.. 긴.. 내용이죠.. 파잇팅~><
· Internal Level
- 전체 데이터베이스에 대한 물리적인 저장 구조를 기술한 것이다.
- physical data model를 사용해서 internal schema를 결정한다.
· Conceptual Level
- 전체 데이터베이스에 대한 개념적인, 논리적인 구조를 기술한 것이다. (Entities, data types, relations, user operations, constraints)
- Internal Schema와 다르게 물리적인 저장 구조의 디테일을 감추었다. 따라서 굉장히 abstract하게 보인다.
- higher level data model인 Conceptual data models나 Representational data models를 사용한다. DBMS가 Representational data models를 쓰기 때문에 보통은 Representational data models를 사용한다.
· External or view level
- 특정 사용자가 필요로 하는 일부 데이터베이스에 대한 논리적인 데이터베이스 구조를 기술한다. 그외의 다른 전체 데이터베이스는 가린다.
- higher level data model인 Conceptual data models나 Representational data models를 사용한다.
* External Schema와 Internal Schema는 데이터베이스를 다른 방식으로 표현한다.
- Internal Schema는 database가 물리적으로 어떻게 저장되어 있는지를 표현한 것이다.
- External Schema는 logical, conceptual model로 표현한 database가 저장되어있다.
· Mapping
1. 사용자는 external view만 보이기 때문에 이에 관련된 query를 던진다.
2. DBMS가 external level queries를 conceptual level schema를 대상으로 하는 query로 바꾼다.
3. DBMS가 conceptual level의 query를 받아서 internal level의 query로 바꾼다.
4. 저장된 database에서 결과를 받는다.
5. 결과를 external view로 바꾼다.
Q. Three-Schema Architecture를 그리고 아는 모든 것을 설명하시오.
◆ Data Independence
· Definition
- database system에서 어떤 level의 스키마가 바뀔 때 상위 level에 있는 스키마에 변경을 요구하지 않는다.
- 당연히 하위 level의 스키마는 바뀔 수 있다. 상위 단계의 스키마만 바뀌지 않는 것이다. 따라서 가장 최상위에 있는 스키마, external view는 바뀌지 않고 프로그램도 바뀌지 않는다.
· Types
- Logical data independance
- Physical data independance
1) Logical data independence
· Conceptual Schema가 바뀔 때
- External Schema는 바뀌지 않는다.
- External Schema를 보고 짠 application program도 바꿀 필요가 없어서 스키마에 종속되지 않는다.
2) Physical data independence
· 가장 밑단에 있는 internal Schema를 바꿀 수 있다.
- Conceptual Schema는 바뀌지 않는다.
- External Schema는 바뀌지 않는다.
- External Schema를 보고 짠 application program도 바꿀 필요가 없어서 스키마에 종속되지 않는다.
Q. Physical data independence가 무엇인지 설명하시오.
위에꺼 다 쓰면 됨.
위 두 개를 통틀어서 data independence라고 한다.
- DBMS를 사용할 때 얻을 수 있는 가장 큰 장점이다.
- 구조가 바뀌더라도 프로그램이 바뀌지 않아서 굉장히 편리하다.
◆ DBMS Languages
· DBMSs가 제공하는 언어이다. DBMS는 이 언어만 이해할 수 있다.
· 데이터베이스를 control하고 manage할 수 있는 언어이다.
· DBMS language는 다음과 같은 것들로 구성된다.
1) Data definition Language (DDL)
내가 다루고자하는 target database의 골격을 정의, 바꾸는 언어이다. 데이터베이스의 골격과 관련된 언어이다.
2) Data manipulation Language (DML). * 가장 많이 사용!
사용자가 데이터를 검색하거나, 집어넣거나, 제거하거나, 바꾸거나 하는데 사용되는 언어이다.
3) Storage definition language (SDL)
target database의 물리적인 구조를 나타내는 internal schema를 관리하는 언어이다.
4) View definition language (VDL)
external schema 또는 view를 명시하는데 사용되는 언어이다.
이 네 가지 것들이 하나의 언어인 SQL에 통합적으로 포함되어있다.
· 컴퓨터 language는 크게 두 가지 카테고리로 나눌 수 있다.
1) Procedural DML
- 사용자의 질의(query: 데이터베이스에서 이것 좀 찾아줘)를 절차적으로 쓰는 것. (procedurally: step by step으로 detail하게 처리할 순서를 알려주는 것)
- 데이터를 가져오기 위해 어떻게 할 것인지에 초점을 맞춰서 detail하게 하나하나 명시해야한다.
- C, Java 모두 procedural 한 language이다.
2) Non-Procedural DML
- 선언적으로 사용자의 질의를 정의한다. (declaratively: 능숙한 비서라면 ~ 어디로 Fax 보내주세요.)
- 원하는 것이 무엇이다라고 말할 뿐 어떻게 하는지 설명하지 않는다.
programmer, 사용자 입장에서는 후자가 더 좋다. 몇 마디 안 하고 바로 알아듣기 때문이다.
하지만 언어를 개발하는 사람의 입장에서는 후자가 훨씬 어렵다. 절차를 만들어 내야하기 때문이다.
◆ DBMS Interfaces
언어는 공부하고 문법에 맞게 DBMS에 요청해야하는데 이를 사용하지 않고 좀더 쉽게 만든 DBMS interface들도 많이 존재한다.
1) Menu-based interfaces
- 데이터베이스 안에 있는 데이터를 가져오기 위해서 query를 보내는데 language를 이용해서 low query를 만드는 것이 아니라 menu에서 제공하는 샘플들을 가지고 그 중에서 골라낸다.
- 보통 web application에 사용된다.
2) Graphical user interfaces
- graphical한 구조를 이용해서 표현한다.
- 보통 naive user를 대상으로 한 application에 사용한다.
ex) 은행 atm기 화면에 보이는 것들.
3) Forms-based interfaces
- 기본 틀이 되는 폼을 주고 그 안을 채워넣는 방식으로 질의를 준다.
- Menu-based interfaces, Graphical user interfaces, Forms-based interfaces 모두 일맥상통하다고 봐도 된다.
4) Natural language interfaces
- 데이터베이스 접근을 자연언어를 통해서 주는 것이다.
ex) 학생 중에서 학점이 3.14가 되지 않는 학생들 중에 DB 교과목을 A+받은 학생을 찾아라. 라고 주면 알아서 이해해서 데이터베이스 쿼리로 바꿔준다. 요즘에는 머신러닝을 이용해서 이를 시도 중이다.
5) Interfaces for DBAs (DB Administrator: DB, application 구축이 끝나고 실제로 사용이 시작된 후에 db 성능이 괜찮은지 감독하고 있다가 해결하는 사람)
- DBMS management 환경을 위한 interface를 제공한다.
◆ DBMS Component Modules
전체 DBMS내에 어떤 component가 존재하고 구체적으로 어떤 일을 하는지 다룬다.
기본적인 Storage Manager
Stored Database: 사용자의 데이터가 있다.
System Catalog/Data Dictionary: 사용자의 meta-data가 있다. 사용자의 데이터를 관리하기 위한 메타 데이터가 있다.
Stored Data Manager: 실제 disk에 있는 데이터를 직접적으로 가져온다.
Runtime Database Processor: database 내에 처리를 하는 부분이다.
Concurrency Control Subsystems: 여러 사람이 동시에 사용할 때 문제가 생기지 않도록 관리한다.
Backup Subsystems: system failure가 날 것을 대비해서 database 내용을 다른 곳에 copy해 두는 것이다.
Recovery Subsystems: system failure가 일어났을 때 copy 둔 것으로 원래 상태로 복구해 주는 것이다.
--------------
위의 것들을 이용해서...
DBA Staff / DB Designer
1. DDL를 통해서 스키마에 대한 정의를 한다.
2. DDL compiler가 이것이 어떤 의미인지를 이해하고 이해한 결과를 system catalog에 meta-data 형태로 스키마를 저장한다.
3. DBA Staff가 특정한 권한을 가지는 command를 통해서 database 내에서의 통계나 system의 상태를 모니터링한다.
Casual Users
1. SQL로 query를 던진다.
2. Query compiler가 query 내용을 이해한다. -> Query compiler가 declarative language를 이해한다.
3. Query Optimizer를 통해서 가장 optimize된 결과를 가지고 step by step으로 procedure run output을 준다.
4. 이 절차적인 방법으로 runtime database processor가 처리한다.
Application Programmers
1. SQL과 다른 언어로 application program을 짠다.
2. Precompiler가 application program 중에서 SQL에 해당되는 부분만 골라낸다.
3-1. DML Compiler가 query optimizer를 통해서 최적의 방법을 찾는다.
3-2. SQL외의 다른 언어 (ex) JAVA language compiler한테 프로그램을 넘겨서 최적의 방법을 찾는다.
4. 두 결과를 합쳐서 compiled transcation를 찾아낸다.
5. 이 결과를 runtime database processor가 처리한다.
다시 한 번 정리!
· Stored Data Manager: Storage에 저장되어 있는 전체 데이터를 access하는 부분 (User data, Meta data in a system catalog에 모두 접근한다.)
· DDL Compiler(스키마를 다루는 language compiler): DDL에 의해서 만들어진 스키마를 처리하는 컴파일러
처리과정을 끝내면 meta data 형태로 사용자 데이터에 대한 골격이 나타나는데 이를 system catalog에 저장한다.
· Runtime Database Processor: 사용자의 쿼리를 처리하기 위해서 db에 접근하는 부분
data manager랑 협업해서 처리한다.
· Query compiler (interactive SQL): 사용자가 SQL문을 던졌을 때 (이것을 interactive SQL라 부른다.) 이를 parsing 한다.
SQL로 표현되어 있는 query문을 문법적으로 쪼개서 이해한다. 내부적으로 DBMS가 이해할 수 있는 function call로 바꾸어 준다.
아래 level의 function call로 바꾸어 주는 것인데 이는 Runtime Database Processor가 작동하도록 function call을 만들어 주는 것이다.
즉, high level language인 SQL statement를 low level의 function call로 바꾸어 주는 것이다.
· Precompiler: 사용자의 프로그램 안에서 데이터베이스 접근하는 부분만 SQL로 짜여져 있는데 이 부분적으로 SQL로 짜여져 있는 statement를 골라내는 역할을 한다.
· DML compiler: 위에서 골라낸 SQL statement는 DML compiler로 넘어와서 하위 단계의 function call로 바꿔주는 역할을 한다.
이를 원래 프로그램에 SQL문 대신 끼워넣으면 전체 프로그램이 java language program이 되고 이를 java compiler로 compile하면 된다.
◆ Database System Utilties
위의 기능말고도 다른 다양한 기능들을 서술한다.
· Database utilities: DBA가 쉽게 DB system을 관리하도록 도와준다.
· Loading: DBMS 외부의 data files를 database 내에 있는 정보로 쉽게 바꿔주는 역할을 한다. 자동적으로 파일에 있던 데이터를 database format으로 convert해준다. 초기에 database를 build할 때 useful하다.
· Backup: database의 copy를 만들어내는 과정. system failure가 일어났을 때 backup했던 copy들 중에서 가장 최신의 것을 가져와서 바꿔준다.
· Database storage reorganization: internal schema에 명시에 되어 있는 구조로 database files가 되어있을 텐데 이를 다른 방식의 구조로 바꿔주는 역할을 한다. 구조가 다르면 성능이 달라진다. B Tree가 없었는데 sequential 하게 찾는 방법이면 성능이 떨어지니 DBA가 이 구조를 B Tree로 바꿔야겠어! 하면 이를 통해 성능을 높인다. DBMS performance에 문제가 있다고 판단했을 때 이를 향상시키기 위해 이를 사용한다.
· Performance monitoring: 이 역시 DBA가 사용하는 것인데 데이터베이스의 사용 현황, 성능 현황을 모니터링하고 이에 대한 통계를 DBA에 제공해주는 것이다. DBA에게 이를 제공함으로써 문제가 있으니 file reorganize하는 것이 필요하겠구나 하는 것들을 알게끔 한다.
◆ Classification of DBMSs
· 기준: data model을 통해서 DBMS를 분류하는 것이다. DBMS는 주로 representational model을 제공한다.
1) Relational model (가장 많이 사용됨) (을 제공하는 DBMS)
- database가 table들의 집합이라고 모델링한다.
- 각각의 table은 record의 집합으로 표현된다. record단위로 정보를 제공한다.
- 가장 유명하다. 오라클..
2) Network model (을 제공하는 DBMS)
- data를 record type, 1:N set type으로 모델링한다.
3) Hierarchical model
- data를 계층적인 트리구조로 표현한다.
4) Object model (Object oriented model)
- database는 class들의 집합이다.
- 데이터는 특정한 class에 속하는 object들로 표현된다.
- 모델링 파워가 매우 커서 복잡한 모델링을 잘한다. (상속, complex objects 개념... ) but 요즘에는 Relational modeling을 사용한다.
· 기준: 사용자의 수
1) Single user DBMS: excel
2) Multi-user DBMS: 보통은 이걸로 가정함.
· 기준: number of sites
1) Centralized DBMS: DBMS가 하나의 머신에 들어있어서 다른 머신에서 하나의 머신에 access함. bottleneck -> 성능 문제
2) Distributed DBMS: 두 개 이상의 머신에 DBMS가 돌아가면서 상호 협조하면서 사용자의 query를 처리함.
2-1) Homogeneous DBMS: 4개의 site에 DBMS가 올라와있고 4개가 모두 relational model을 가지고 있는 DBMS이다.
2-2) Heterogeneous DBMS: 2개에서는 relational model 나머지 2개에서는 Object model 쓰는 모델이 다른 DBMS이다.
· 기준: 목적
1) General purpose DBMS: 특정한 타겟을 정하지 않고 DBMS를 만들고 모든 application이 이를 다 쓸 수 있다.
2) Special purpose DBMS: 특정 목적을 위해 사용되는 DBMS이다.
ex) real time DBMS: 마감시간을 정해주고 이시간 내에 답을 달라는게 요구된다.
◆ Summary
- Concepts used in database systems
- Main categories of data models
Physical data models
Conceptual data models
Representational data modelsSummary
- Types of languages supported by DBMSs
- Interfaces provided by the DBMS
- DBMS classification criteria:
Data model, number of users, number of sites, purpose