2024. 9. 22. 14:33ㆍCS/Database System
1. Data models, Schemas and Instances
Data models
Data Model
- 데이터베이스의 structure, operations, constraints를 설명하기 위한 concepts의 집합이다.
Data Model Structure and Constraints
- database structure를 정의하기 위해 Constructs가 사용된다.
- Constructs는 type을 가지는 elements와 elements의 그룹인 record(entity, table), 각 그룹들 간의 relationship를 포함한다.
- 예를 들어, 학생 data가 다음과 같이 구성된다고 생각해보자. [이름, 학번, 연락처, 학과] 여기서 이름, 학번 등이 element가 되고 이름의 type은 string이 된다. A라는 학생은 [a, 001, 010…, CS…] 과 같은 형태로 데이터를 가질 수 있는데, 이를 엔티티라 한다.
- 모델링에서와 실제 데이터베이스에서 부르는 용어가 조금 다르다. entity는 data model에서 사용되고 record는 실제 데이터베이스에서 사용된다.
- 제약사항은 유효한 데이터를 위해 걸어둔다.
- 예를 들어 이름에 숫자가 포함되면 안된다. 라고 제약사항을 설정할 수 있다.
Data Model Operations
- 데이터베이스의 연산은 retrievals(검색), updates(수정) 에 사용된다.
- 기본적으로 insert, delete, update 연산을 지원하고 사용자 정의 연산도 만들 수 있다.
데이터 모델이 확장되면서 세 종류로 나뉘었다.
- Conceptual data models high-level, semantic, 실제 구현은 고민하지 않는다. 예를 들어 학생은 이름, 학번, 연락처, 학과로 구성되어있다. 라고 모델링하는 것이다.
- Physical data models
- low-level, internal, 실제로 컴퓨터에 어떻게 저장할 것인지에 관한 것이다. 어떻게 컴퓨터의 피지컬한 메모리에 block 배치는 어떻게 할것인지 등 low level에 관한 것이다.
- Implementation data models representational, relational data model 이라고도 한다. 예를 들어 학생과 과목을 생각해보면 한 학생은 여러 과목을 들을 수 있다. 이런 관계성을 모델링하는 것이다. Conceptual과 Physical model 사이에 있다.
Schemas VS Instances
Database Schema
- database를 기술한 것이다.
- database schema는 database structure (including data types), constraints를 포함한다.
- 테이블을 하나 정의하면 그걸 테이블 스키마라 하고, 테이블을 모아놓은 것을 데이터베이스 스키마라 한다. 단어 말 그대로 도식을 의미하며 설계도라 생각하면 된다.
Schema Diagram
Schema Construct
- 스키마는 데이터베이스의 구조나 틀을 정의한 것이다. 예를 들어 학생, 강의 같은 테이블들이 데이터베이스의 스키마를 구성하는 요소이다. 스미카는 데이터베이스가 어떻게 구성되고 어떤 데이터가 들어갈 수 있는지를 정의한다.
Database State
- 특정 시점에 실제 데이터베이스에 저장된 실제 데이터이다.
- database state는 database instance 라고도 불린다.
- 예를 들어, 테이블에 저장된 데이터들을 테이블 인스턴스, record 인스턴스라고 부를 수 있다.
Initial Database State
- 데이터베이스가 처음 시스템에 로드되었을 때의 상태이다.
Valid State
- 데이터베이스에 정의된 제약사항과 구조를 만족하는 상태(데이터)이다.
Database Schema와 Database State의 차이점
- 스키마는 잘 바뀌지 않는다.
- 데이터베이스 상태는 자주 바뀐다.
- 새 데이터가 추가되거나 기존 데이터가 수정될 때마다 변경된다.
- 스키마는 intension 이라고도 불린다.
- 상태는 extension 이라고도 불린다.
2. Three-Schema Architecture and Data Independce
프로그램-데이터 독립성과 다양한 사용자 관점 지원을 목표로 제안된 모델이다.
이 아키텍쳐는 데이터베이스를 세 가지 수준에서 정의한다.
Internal schema
- DBMS 구현과 관련된 부분
- 데이터베이스의 물리적 저장 구조와 인덱스와 같은 접근 경로를 정의한다.
- 데이터가 실제로 하드디스크 어디에 어떻게 저장되는지를 나타낸다.
Conceptual schema
- Database 모델링과 관련된 부분
- 전체 데이터베이스 구조와 제약 조건을 정의한다.
- conceptual or implementational data model을 사용한다.
- 사용자나 시스템은 이 스키마를 통해 데이터베이스가 어떤 구조를 가지고 있는지 등을 이해할 수 있다.
External schema
- 여러 사용자의 관점에서 데이터베이스를 정의한다.
- 보통 conceptual schema와 같은 data model을 사용한다.
예를 들어 보자.
학생이라는 테이블이 있고, 어떤 한 학생 홍길동에 대해 [A, B, C, D, E, F] 라는 데이터를 삽입했다.
그리고 external user는 조교와 교수가 있다. 조교가 볼 수 있는 데이터가 [A, B, C] 이고 교수는 [C, D, E, F]이다. 여기서 End Users는 사람, 개발자, 프로그램 모두 가능하다.
홍길동 학생의 데이터는 Internal Level에서 레코드 단위로 실제 데이터로 저장된다. A는 6 byte, B는 10 byte 이런식으로 저장된다.
Conceptual Level에서 block 단위의 record를 [A, B, C, D, E, F] 형태로 보여주게 된다.
Conceptual level에서의 데이터 [A, B, C, D, E, F] 를 조교에게는 [A, B, C], 교수에게는 [C, D, E, F] 이렇게 다르게 보여주는게 External/Conceptual Mapping이다.
또, Internal Level에서 byte 단위로 물리적으로 구성된 데이터를 [A, B, C, D, E, F] 와 같이 테이블로 보여주는게 Internal/Conceptual Mapping이다.
이처럼 세 레벨로 나누어서 데이터베이스 시스템을 설명하는 방법이 Three-Schema Architecture이다. 이 아키텍쳐의 핵심은 모든게 매핑이라는 것이다.
Three-Schema Architecture 장점
스키마 간 매핑을 하므로써 사용자나 프로그램이 request를 보내고 data를 받는 구조를 만들 수 있다.
- 서로 다른 수준의 스키마 간 데이터를 주고받을 때는 변환 작업이 필요하다.
- DBMS는 사용자의 요청을 받아서 해당 요청을 내부 데이터 저장 구조에 맞게 변환하고 처리한다. 그 후 다시 사용자가 볼 수 있는 형태로 변환한다.
한 데이터가 바뀌어도 다른 데이터에 영향을 미치지 않는 데이터 독립성이라는 장점도 있다.
데이터 독립성은 두 종류로 나뉜다.
Logical Data 독립성
- external schema를 바꾸더라도 conceptual schema에는 전혀 영향이 없다.
Physical Data 독립성
- internal schema를 변경하더라도 conceptual schema는 변하지 않는다.
- 예를 들어 구현할 때 E F 순으로 저장했는데, 그 저장 순서를 F E로 변경해도 매핑 덕분에 conceptual schema는 전혀 변하지 않는다. 똑같이 E F 순서로 볼 수 있다.
3. Database Languages and Interfaces
Languages라 하면 SQL이 되고 Interfaces는 콘솔, GUI 등이 된다.
Database Languages
DBMS 언어의 특징을 알아보자.
- **Data Definition Language (DDL), Data Manipulation Language (DML)**로 나뉜다. 이 두가지를 묶어서 구현한게 SQL이다.
- DDL은 create data type 등 무언가를 생성하는 것이고 DML은 select, update 등이다.
- DBMS 언어는 high-level 언어이다.
- 기계어가 아닌 high-level 언어를 컴파일러와 유사한 것을 통해 변환하는데, 기계어로 바꾸는 건 아니고 데이터가 저장되는 블락 단위로 조정하게끔 바꾼다.
- Non-procedural 언어이다.
- 예를 들어, C 언어는 순서대로 동작하는 절차형 언어이지만 SQL은 명령어의 순서대로 진행하는 것이 아니다. select * from student, class where student id = class id; 이 SQL 명령은 두 테이블을 join해서 데이터를 꺼내고게 된다. 그런데 student를 먼저 썼다고 해서 항상 student를 먼저 읽는 것은 아니다. 읽는 순서는 속도가 더 빠른 것을 판단해서 바꿔서 수행한다. 응답이 먼저 나온다고 해서 먼저 실행되는 것이 아니다.
- SQL을 쓸 때 stand-alone으로 터미널에서 mysql에 접근해서 SQL을 접근하는 방식으로 사용할 수도 있고, 프로그래밍 언어 안에서 통신을 통해 가져와서 처리하는 방식인 embedded in a programming language 방식도 있다.
- 프로그래밍 언어 안에서 처리하는 방식은 절차형으로 진행된다.
DDL을 자세히 알아보자.
- 대표적으로 create table이 있다.
- conceptual schema를 상세화하기 위해 DBA나 데이터베이스 디자이너가 사용한다.
- internal에서는 index 같은걸 생성할 때 쓰고 external view에서도 사용한다.
다음은 DML이다.
- data를 retrieval 하는 select, update하는 insert, delete, update가 해당된다.
- RDBMS는 집합을 근본으로 하고있기에 비절차 언어이다.
- 왜 집합이 비절차냐면, 예를 들어서 student라는 집합에 a, b, c, d, e라는 학생이 있다. 집합 a, b, …는 순서가 없다. 따라서 select를 하면 a, b, c, .. , b, c, a, e, d 는 순서와 관계 없이 같은 집합이다. 따라서 Non-procedural 언어인 것이다.
- 중요한 것은 SQL의 결과가 순서대로 나온다는 것은 보장이 없다는 것이다. 순서가 필요하다면 sorting을 한다던지 해야 한다. 결과만 보면 순서가 정해져있는 것 같지만 아랫단에서 보면 순서가 없다.
- DML을 구현하는 low level에서 보면 student는 4 KB 블럭에 순서대로 들어가 있을 것이다. select * from student; 를 하면 high level에서는 결과가 a b c d e로 나와도 되고 d a c e b로 나와도 된다. 그런데 실제 low level에서는 순서대로 저장되어있기에 순차적으로 찾아야 효율적이다.
- high level에서는 select를 쓰지만 가장 하단에는 iterator라는 operator라는게 존재한다. 임베디드 시스템 초창기에서도 SQL을 사용하지 않고 가볍게 레코드에 접근하기 위해 iterator를 사용하였다. SQL의 모든 retrieval 연산 가장 하단에는 iterator가 있다. 이 iterator는 단순히 100 byte씩 점프하면서 블락을 이동하는 for loop이다. 아랫단에서 iterator는 레코드를 하나씩 가져오는 역할을 하고, for loop로 구현할 수 있다는 것이 중요하다.
DBMS Interfaces
Stand-alone
- 터미널로 접근해서 쿼리를 직접 날려서 레코드를 가져오는 방식이다.
embedding DML in programming languages
- 보통은 프로그래밍 언어 안에 데이터베이스에 접근할 수 있는 인터페이스를 사용한다.
- 이 방식의 포인트는 데이터베이스 시스템에 내가 직접 접근하지 않는다는 것이다.
user-friendly interfaces
- 일반인들은 user interface를 통해 접근한다. 보통은 웹이 된다. 웹으로 DB를 보는건 사실 개신누리에서 내 정보를 보는 것과 같다.
4. The Database System Environment
전형적인 DBMS는 아래와 같다.
여기서 쿼리 optimizer가 가능한 것은 relational algebra , 관계대수 덕분이다. A라는 쿼리와 B라는 쿼리의 결과값이 반드시 같으면 A ≡ B (동치) 가 된다.
예를 들어 어떤 A라는 결과값을 내기 위해 1000개의 block을 읽고 나서 A가 true/false를 판단할 수 있고, B는 10개의 blcok이라고 가정해보자. A & B라면 A부터 1000개의 block을 읽고 A가 true라면 B를 읽어야 한다. 그런데 B가 false라면 앞에서 읽은 1000개의 blcok read는 의미가 없어진다. B부터 읽는 것이 훨씬 효율적인 것이다.
이처럼 쿼리 최적화를 해야 하는데 그 근거가 relational algebra이다. 수학적인 근거로 동치인 쿼리를 찾아낸다.