[Database Systems] Data Models, Three Schema Architecture, Data Independency, DBMS

Data Models

database의 구조를 잘 표현하기 위한 개념들의 집합이다.

여기서 개념들은 data types, relations, constraints 등이 있다.

Data Model을 concept을 기준으로 구분한 model들은 다음과 같다.

Physical data models
Conceptual data models
Representational data models

Physical data models

data가 storage media에서 어떻게 저장되는지에 대한 detail을 표현하는 모델이다.

physical model은 다음과 같은 정보를 표현한다.

• data type
• data를 빠르게 찾기 위한 index
• data를 빠르게 찾기 위한 다른 access path들

이 정보들은 DBMS에 의해 감추어진다.

Conceptual data models

사람 입장에서 저장되어야 할 data가 어떻게 표현되는가를 나타내는 모델이다.

사람이 data를 인식하는 방식으로 표현하며 사람과 가까운 high level data model이다.

ex) entity-relationship model

Representational data models

physical data model은 아주 low level이고, conceptual data model은 아주 high level이다.

Representational data model은 이 두 모델의 중간 level이다.

• physical data model에 비해 사람이 이해하기 쉽다.
• physical data model과 비슷한 점도 존재한다.

사람이 이해하기 쉬우며 physical model과도 가까우므로 DBMS를 implement 하는데에 쓰인다. 따라서 implementation data model이라고도 불린다.

Oracle, Microsoft SQL server 등 상용 DBMS는 자신만의 data model을 가진다.

그 model들은 representational data model을 탑재하고 있다.

따라서 사람은 representational data model을 가지고 database 구조를 잡고 DBMS에 저장해달라고 요청한다.

ex) relational model , network model , hierarchical model

Database Schema ( == metadata, intension)

data model로 표현된 database의 구조이다.

사용자 data를 관리하기 위해 구조에 대한 정보가 필요하므로 metadata라고도 한다.

database designer는 system analyst가 조사해서 가져온 data들 중 어떤 데이터를 저장할지 결정한다.

이후 고른 데이터들을 어떤 구조로 저장할지 결정한다. 이 때 database schema가 결정되고, 거의 변하지 않는다.

Database Instance

특정 시점에 schema 하에 들어가 있는 사용자의 data이다.

schema와는 다르게 instance는 insertion, update, deletion이 일어날 때마다 바뀌므로 자주 변동이 일어난다. 값이 하나라도 다르면 다른 instance가 되는 것이다. 따라서 특정 시간을 기준으로 database instance는 다르게 정의될 수 있다.

database state, snapshot, occurence, extension이라고도 한다.

Three-Schema Architecture

만들어지게 된 동기

: application program이 database 구조에 종속되지 않게 하기 위해 (program-data independence)

Three-Schema Architecture의 전체적인 구조는 다음과 같다.

• Internal Level: 전체 database에 대한 물리적인 구조를 기술한 것
• Conceptual Level: 전체 database에 대한 conceptual(logical)한 구조를 기술한 것
  • entities, data types, user operations, constraints 등이 기술되어 있다.
  • 데이터가 실제 physical storage media에서 어떻게 저장되는지에 대한 정보는 감추어준다.
• External or View Level: 일부 database에 대한 conceptaul(logical)한 구조를 기술한 것
  • database의 나머지 부분에 대한 정보는 감추어준다.
• Internal Schema: database가 storage media에서 어떻게 저장되는지를 physical data model로 표현한 것
• Conceptual Schema: Internal Schema를 사람이 이해할 수 있는 수준으로 만들어놓은 것
  • representational data model 또는 conceptual data model로 표현
• External View: 전체 conceptual database 중 사용자가 바라보는 일부에 대한 database
  • data model은 conceptual schema와 동일하다.
  • entities, data types, user operations, constraints 등이 기술되어 있다.
  • 데이터가 실제 physical storage media에서 어떻게 저장되는지에 대한 정보는 감추어준다.

physical한 database는 internal schema에 저장되고, user는 external schema에 저장된 logical한 view를 바라보게 된다.

 

	Internal Schema	Conceptual Schema
공통점	전체 database에 대한 구조를 나타낸다.
차이점	physical model로 표현된다.	conceptual 또는 representational model로 표현된다.

 

	External View	Conceptual Schema
공통점	conceptual 또는 representational model로 표현된다.
차이점	사용자가 바라보는 일부 database에 대한 정보를 표현한다.	전체 database에 대한 정보를 표현한다.

 

• External / Conceptual Mapping: external view에 대한 query를 conceptual schema에 대한 query로 바꾸어 주는 것.
  • 사용자는 전체 database가 아닌 자신이 바라보는 일부 database에 대해 query한다. DBMS는 사용자의 일부 database에 대한 query를 전체 database에 대한 query로 mapping해준다.
• Conceptual / Internal Mapping: 사용자의 external view에 대한 query → conceptual schema에 대한 query를 internal schema에대한 query로 바꾸어주는 것.
  • database의 물리적인 구조와 일치하는 level에 대한 query이므로 data를 찾을 수 있다.
  • internal schema에 대한 query로 실제 database에서 data를 처리하고 위로 올려보내 사용자의 요청에 응답한다.

실제 mapping은 다음과 같은 순서로 처리된다.

1. user는 external view(external level schema)에 대해 query한다.
2. external level schema에 대한 query를 conceptual level schema에 대한 query로 mapping한다.
3. conceptual level schema에 대한 query를 internal level schema에 대한 query로 mapping한다.
4. stored database로부터 result를 얻는다.
5. result를 external view로 올려보낸다.

Data Independence

위에서 언급했듯이 Three-Level Schema는 program-data independence를 위해 만들어졌다.

Data Independence란, 어떤 level의 schema에서 변화가 그것보다 상위 level schema에서의 변경을 요구하지 않는 것을 의미한다. 그것보다 아래 level schema의 변경은 요구할 수 있다.

 

program-data independence는 다음과 같은 방법으로 성립된다.

 

Physical Data Indepence

 

전체 database에 대한 internal schema가 바뀌면

→ internal schema level에서의 metadata만 바뀌면 된다.

→ conceptual schema를 기반으로 만들어진 external view(schema)도 영향을 받지 않는다.

→ external view로 만들어진 application program도 영향을 받지 않는다.

→ conceptual schema는 영향을 받지 않는다.

 

Logical Data Indepence

 

conceptual schema가 바뀌면

→ conceptual schema level의 metadata만 바뀌면 된다.

→ external view로 만들어진 application program도 영향을 받지 않는다.

→ external view(schema)는 영향을 받지 않는다.

 

DBMS가 갖는 가장 큰 이점이 Data Indepence이다. 이를 통해 프로그램의 유지보수 오버헤드를 크게 줄일 수 있다.

DBMS Languages

Data Definition Language (DDL)

: 다루려는 target database의 구조를 정의하거나 변경하는 데 사용

Data Manipulation Language (DML)

: database 구조 하에서 data를 검색, 삽입, 삭제, 수정하는 데 사용

  Procedural DML

• 원하는 데이터를 가져오기 위한 step을 일일이 알려줘야 한다.
• user query를 step by step으로 정의한다.
• 어떻게 데이터를 가져올지에 대해 focus 

  Non-Procedural DML

• 어떤 데이터를 가져올지만 알려주면 알아서 가져온다.
• user query를 '원하는게 무엇인지'로 정의한다.
• 어떤 데이터를 가져올지에 대해 focus

Storage Definition Language (SDL)

: target database의 구조를 나타내는 internal schema를 관리하는 데 사용

View Definition Language (VDL)

: three-level schema의 view level을 명시하는 데 사용

DBMS Component Modules

DBMS Component Module의 전체적인 구조

 

Stored Data Manager

: storage에 저장되어 있는 전체 data에 접근하는 부분

 

DDL Compiler

: schema를 다루는 language인 DDL을 process한다.

  → 사용자 data 골격이 metadata 형태로 나타난다.

  → system catalog에 metadata를 저장한다.

 

Runtime Database Compiler

: 사용자 query를 처리하기 위해 DB에 접근한다.

 

Query Compiler

: 사용자가 던진 query(interactive SQL)를 parsing해서 DBMS가 이해 가능한 function call로 바꾼다.

high level language (SQL statement) — Query Compiler —> low level language (function call)

이 function call은 Runtime Database Compiler를 호출하여 DB에 접근한다.

 

Precompiler

: 전체 application program에서 DB 접근하는 부분만 SQL로 짜여져있다.

Precompiler는 전체 프로그램 중 SQL statement만 골라내 DML Compiler에게 전달한다.

 

DML Compiler

: Precompiler가 골라낸 DML을 function call로 바꾸어 준다.

프로그램의 SQL statement 부분에 function call을 끼워넣는다.

 

 

DBMS Component Module을 다시 보자.

1. DBA Staff
   • DDL Statement를 통해 Schema를 정의할 수 있다.
     • DDL Compiler에 의해 metadata 형태로 나타난 database 구조를 system catalog에 저장한다.
   • Privilieged Commands를 통해 DB 통계를 내거나 system 상태를 monitor 할 수 있다.
     • 명령어가 Runtime Database Processor에 전달되어 DB에 접근하게 된다.
2. Casual Users
   • user가 interactive query(SQL statement)를 날리면
     • Query Compiler가 interactive query를 DBMS가 이해 가능한 function call로 바꾼 후
     • Query Optimizer에 의해 declarative command(interactive query)가 최적의 procedural한 방법으로 제공된다.
     • 명령어가 Runtime Database Processor에 전달되어 DB에 접근하게 된다.
3. Application Programmers
   • Application Program 전체 코드를 제공하면
     • Precompiler가 SQL statement에 해당하는 부분만 골라내 DML Compiler에 전달한다.
     • Java로 짜져있는 프로그램의 경우, SQL Statement를 제외한 부분은 Java Compiler로 전달된다.
     • DML Compiler가 최적의 방법을 찾아낸다.
     • 명령어가 Runtime Database Processor에 전달되어 DB에 접근하게 된다.

Database System Utilities

DBA가 Database를 쉽게 관리할 수 있도록 하는 기능들이다.

 

Loading

: DBMS 밖에 있는 data file을 불러오려면 유저가 DBMS에 data를 하나씩 입력해야 한다.

이는 매우 복잡하므로 DBMS는 Loading 기능을 제공한다.

Loading을 통해 유저는 외부의 data file을 database 내의 정보로 변환시킬 수 있다.

또한 새롭게 DB를 구축할 때 유용하다.

 

Backup

: 시스템이 중간중간에 database의 copy를 만들어놓는다.

system failure가 일어날 시 최신의 copy를 통해 최신 상태로 복구한다.

 

Database Storage Reorganization

: database의 구조가 internal schema에 명시되어 있을 때 그 구조를 다른 방식의 구조로 바꾸어준다.

DBMS 성능을 향상시키는 데 도움이 된다.

따라서 DBA가 DB 성능에 문제가 있다고 판단했을 때 reorganization을 한다.

ex) 기존 sequential하게 찾는 구조 → B tree를 이용해 찾는 구조로 reorganization하면 성능이 좋아진다.

 

Performance Monitoring

: DB를 모니터링하고 통계를 DBA에게 제공해서 DBA가 어떤 결정을 내릴 때 도움이 된다.

Classifications of DBMS

DBMS는 하나의 data model을 제공한다. 보통 representational model을 제공한다.

data model을 기준으로 분류

• Relational Model ( ⍷ Representational model )
  • DB를 table의 집합으로 표현
  • table 내에 record 단위로 정보 저장
  • 가장 많이 쓰임
• Network Model
  • 데이터를 record type, 1:N set으로 나타냄
  • 거의 쓰이지 않음
• Hierarchical Model
  • 데이터를 계층적 트리 구조로 나타냄
  • 거의 쓰이지 않음
• Object Model (Object Oriented Model)
  • DB를 class의 집합으로 표현
  • data는 class에 속하는 객체로 표현
  • inheritance 지원 → 복잡한 data modeling에 사용

user 수를 기준으로 분류

• Single user DBMS
• Multi-user DBMS

site 수를 기준으로 분류

• Centralized DBMS
  • DBMS가 하나의 machine에만 존재
  • 여러 machine이 DBMS가 들어있는 machine에 접근 → DBMS가 들어있는 하나의 machine에 bottleneck 발생
• Distributed DBMS
  • DBMS가 두 개 이상의 machine에서 실행
  • 여러 machine이 상호작용하여 사용자의 query 처리
  • Homogeneous DBMS
    • ex) 4개의 site에 DBMS 분산되어 존재, 4개의 DBMS가 모두 representational model을 가짐
  • Heterogeneous DBMS
    • ex) 4개의 site에 DBMS 분산되어 존재, 2개는 relational model, 2개는 object model

목적을 기준으로 분류

• General purpose DBMS
  • target X, 온갖 application에서 사용
• Special purpose DBMS
  • 특정 목적을 위해 사용되는 DBMS
    • ex) real-time DBMS