Notes

DB 01. DBMS 구조와 데이터 독립성

데이터와 정보의 차이, DBMS의 필요성, File System과 DBMS 비교, DBMS 발전 과정, DDL/DML/DCL, ANSI/SPARC 3-level architecture와 데이터 독립성을 정리한 학습 노트

Published: May 31, 2026
Updated: May 31, 2026
Area: Databases
Type: concept
Series: Database Systems
Category: Notes

DBMSDatabaseRDBMSNoSQLData IndependenceANSI SPARCDDLDMLDCL

이 글은 DB 01의 핵심 개념을 정리한 학습 노트다.
중심 흐름은 다음과 같다.

데이터와 정보의 차이
Database와 DBMS의 정의
File System 방식의 한계와 DBMS의 필요성
DBMS의 발전 과정
DBMS language: DDL, DML, DCL
DBMS 사용자 유형
ANSI/SPARC 3-level architecture와 Data Independence
Database System Architecture

1. 데이터와 정보

Database를 이해할 때 가장 먼저 구분해야 하는 것은 data와 information이다.

구분	의미	예시
Data	아직 해석되기 전의 원자료	학생명, 주소, 과목명, 성적이 들어 있는 표
Information	data를 질의나 프로그램으로 가공해 얻은 의미 있는 결과	`Database` 과목을 수강한 학생은 김철수이다

예를 들어 다음과 같은 데이터가 있다고 하자.

Name    Address          Course              Grade
홍길동   123 Kensington   Chemistry 102       C+
김철수   88 West 1st St. Database            A
박영희   100 Capitol Ln.  Psychology 102      A

이 표 자체는 data다.
여기에 다음 질의를 적용하면 information이 된다.

질의: Database 과목을 수강한 학생은?
정보: Database 과목을 수강한 학생은 김철수이다.

즉 Database는 단순한 저장소가 아니라, data를 체계적으로 저장하고 필요한 information으로 변환할 수 있게 해주는 기반이다.

2. Database의 정의

Database는 다음처럼 정의할 수 있다.

조직체의 application system들이 공유해서 사용하는 operational data들이 구조적으로 통합된 모임이다.

여기서 중요한 표현은 다음 네 가지다.

핵심어	의미
조직체	회사, 대학, 병원, 항공사처럼 데이터를 관리하는 주체
공유	여러 사용자와 application이 같은 데이터를 사용
운영 데이터	실제 업무 수행에 필요한 데이터
구조적 통합	정해진 data model에 따라 체계적으로 구성

예를 들어 대학 Database에는 다음 정보가 들어갈 수 있다.

학생 신상 정보
수강 과목
성적
학과별 개설 과목
교수 정보
담당 과목
급여 정보

항공기 예약 시스템에서는 좌석 예약, 승객, 항공편, 결제 정보 등이 Database에 기록된다.

3. Database의 특징

Database는 단순한 파일 묶음과 다르다. 주요 특징은 다음과 같다.

특징	설명
대규모 저장소	조직 전체의 많은 데이터를 저장
동시 사용	여러 부서와 사용자가 동시에 접근
중복 최소화	같은 데이터를 여러 곳에 반복 저장하는 문제를 줄임
Metadata 포함	실제 데이터뿐 아니라 데이터에 대한 설명도 포함
Program-data independence	데이터 구조 변경이 application에 미치는 영향을 줄임
효율적 접근	질의와 검색을 효율적으로 수행

특히 metadata는 중요하다.

metadata = data about data

예를 들어 STUDENT table에 실제 학생 데이터가 들어 있다면, metadata는 다음과 같은 정보다.

table 이름은 STUDENT
column은 SID, NAME, DEPT, GRADE
SID는 integer
SID는 primary key
NAME은 null이면 안 됨

즉 metadata는 실제 업무 데이터가 아니라, 그 데이터를 설명하는 구조 정보다.

4. DBMS란?

DBMS(Database Management System)는 Database를 관리하는 software다.

Database와 DBMS는 구분해야 한다.

구분	의미
Database	저장된 데이터의 구조적 모임
DBMS	Database를 정의, 질의, 수정, 보호, 회복하는 software

DBMS의 주요 기능은 다음과 같다.

새로운 Database 생성
Database 구조 명시
data 질의
data 수정
data 보호
여러 사용자의 동시 접근 제어
장애 발생 시 회복
Database language 제공

대표적인 Database language는 SQL이다.

CREATE TABLE STUDENT (
    sid INT PRIMARY KEY,
    name VARCHAR(30),
    dept VARCHAR(50)
);

SELECT *
FROM STUDENT
WHERE dept = 'Computer Science';

5. RDBMS와 NoSQL

전통적인 Database System의 중심은 Relational DBMS(RDBMS)다.

대표적인 RDBMS는 다음과 같다.

MySQL
PostgreSQL
MariaDB
Oracle
MS SQL Server
IBM DB2
Tibero
Cubrid

RDBMS는 데이터를 table, row, column으로 표현한다.
반면 NoSQL(Not Only SQL)은 관계형 table 구조만으로 처리하기 어려운 데이터까지 다루기 위한 방식이다.

대표적인 NoSQL 예시는 다음과 같다.

MongoDB
Firebase

NoSQL은 Big Data의 3V와 연결해서 이해하면 좋다.

Big Data 3V	의미
Volume	데이터 양이 매우 많음
Velocity	데이터가 빠르게 생성되고 처리됨
Variety	정형, 반정형, 비정형 등 다양한 형태의 데이터

정리하면 다음과 같다.

구분	강점
RDBMS	정형화된 table 구조, transaction, consistency
NoSQL	대용량, 고속, 다양한 형태의 데이터 처리

6. Schema와 Database State

Database를 이해할 때 schema와 state를 구분해야 한다.

구분	다른 표현	의미	변화
Schema	Intension	Database의 구조	자주 바뀌지 않음
Database State	Extension	특정 시점의 실제 데이터 내용	계속 바뀜

예를 들어 다음은 schema다.

DEPARTMENT(DEPTNO, DEPTNAME, FLOOR)
EMPLOYEE(EMPNO, EMPNAME, TITLE, DNO, SALARY)

여기서 DEPARTMENT, EMPLOYEE는 relation 이름이고, 괄호 안의 값들은 attribute다.
반면 실제 table 안에 들어 있는 row들은 Database state다.

DEPARTMENT
DEPTNO  DEPTNAME  FLOOR
1       영업       8
2       기획       10
3       개발       9

즉 column 구조는 schema이고, 실제 row 값들은 state다.

7. System Catalog

System Catalog는 Database의 schema 정보를 유지하는 metadata 저장소다.
다른 말로 Data Dictionary라고도 한다.

System Catalog에는 다음 정보가 저장된다.

table 목록
column 이름
column data type
primary key
foreign key
index 정보
사용자 권한
constraint 정보

즉 System Catalog는 DBMS가 Database를 관리하기 위해 참고하는 내부 metadata다.

8. File System 방식의 한계

DBMS가 등장하기 전에는 데이터를 일반 file에 저장하고 application이 직접 읽고 쓰는 방식이 사용되었다.

File System 방식의 기본 구조는 다음과 같다.

Application Program 1 ↔ Data File 1
Application Program 2 ↔ Data File 2
Application Program 3 ↔ Data File 3

File은 sequential records로 구성되고, 하나의 record는 여러 field의 모임이다.

record = related fields
file = sequence of records

예를 들어 Employee file이 다음 구조를 가진다고 하자.

ID, Name, Address

나중에 Cell-phone field를 추가하려면 file 구조와 application program을 함께 수정해야 한다.

ID, Name, Address, Cell-phone

이 방식의 핵심 문제는 다음과 같다.

File 구조와 application program 구조가 강하게 결합된다.

9. File System 방식의 단점

File System 방식의 주요 단점은 다음과 같다.

단점	설명
Data redundancy	같은 데이터가 여러 file에 중복 저장됨
Data inconsistency	중복 데이터 중 일부만 수정되면 불일치 발생
동시성 제어 부족	여러 사용자가 동시에 접근할 때 충돌 가능
Query language 부재	원하는 데이터를 쉽게 명시하기 어려움
Security 부족	세밀한 권한 관리가 어려움
Recovery 기능 부족	장애 발생 시 일관된 상태로 회복하기 어려움
Program-data dependence	file 구조 변경이 program 수정으로 이어짐
생산성 저하	검색, 갱신 로직을 program마다 직접 구현해야 함
공유와 융통성 부족	data가 application별 file에 흩어짐

예를 들어 EMPLOYEE file과 ENROLLMENT file에 모두 DEPARTMENT가 들어 있으면, 부서 변경 시 두 file을 모두 수정해야 한다. 하나만 수정하면 data inconsistency가 발생한다.

10. DBMS 방식의 장점

DBMS 방식에서는 application이 data file을 직접 다루지 않는다.
중간에 DBMS가 존재한다.

User / Application
        ↓
      DBMS
        ↓
Integrated Database

DBMS 방식의 장점은 다음과 같다.

장점	설명
중복성과 불일치 감소	data를 통합 관리
개발 및 유지 비용 감소	file 처리 로직을 반복 구현할 필요 감소
표준화 용이	이름, 형식, constraint를 조직 차원에서 통일
보안 향상	사용자별, role별 권한 관리
무결성 향상	constraint를 DBMS가 검사
회복 가능	장애 발생 시 consistent state로 복구
공유와 동시 접근	여러 사용자가 같은 Database 사용
Program-data independence	구조 변경 영향 최소화

DBMS는 사용자가 원하는 결과만 명시하게 하고, 실제 접근 방법은 DBMS가 결정한다.

SELECT name
FROM EMPLOYEE
WHERE department = 'Sales';

사용자는 what만 명시하고, DBMS가 how를 결정한다.

11. DBMS를 사용하지 않는 것이 나을 수 있는 경우

DBMS는 강력하지만 항상 정답은 아니다.
다음 조건에서는 DBMS 사용이 과할 수 있다.

초기 투자 비용이 너무 큼
DBMS overhead가 너무 큼
application이 단순하고 잘 정의되어 있음
앞으로 변경 가능성이 낮음
엄격한 real-time processing 요구가 있음
다수 사용자의 동시 접근이 필요하지 않음

즉 단순한 local configuration file이나 매우 작은 단일 사용자 프로그램에는 DBMS가 불필요할 수 있다.

12. Data Model

Data Model은 Database의 구조를 기술하는 개념들의 집합이다.

Data Model은 세 요소를 포함한다.

요소	설명
Structure	data type과 relationship
Operators	구조 위에서 동작하는 연산
Integrity Constraints	data가 만족해야 할 규칙

Data Model은 현실 세계의 대상을 Database에서 표현하기 위한 추상화 방식이다.

13. Data Model의 분류

Data Model은 크게 세 가지로 분류할 수 있다.

분류	의미	예시
Conceptual Data Model	사람이 인식하는 것과 유사한 고수준 모델	ER model, Object-oriented model
Representation / Implementation Data Model	최종 사용자와 computer 내부 표현 사이의 중간 모델	Hierarchical, Network, Relational model
Physical Data Model	실제 저장 방식 기술	ISAM, VSAM

Conceptual model은 설계 초기에 현실 세계를 분석할 때 중요하다.
Implementation model은 DBMS가 논리적으로 데이터를 표현하는 방식이다.
Physical model은 data가 disk에 어떻게 저장되는지를 다룬다.

14. DBMS 발전 과정

DBMS는 다음 흐름으로 발전했다.

Hierarchical DBMS
      ↓
Network DBMS
      ↓
Relational DBMS
      ↓
Object-Oriented DBMS / Object-Relational DBMS

각 모델의 특징은 다음과 같다.

DBMS 유형	구조	장점	한계
Hierarchical DBMS	Tree	1:N 관계에 효율적	N:M 관계 표현 어려움
Network DBMS	Graph	N:M 관계 표현 가능	link 중심이라 구조 변경 어려움
Relational DBMS	Table	단순하고 SQL 사용 가능	복잡한 객체 표현에는 한계
Object-Oriented DBMS	Object	복잡한 객체 표현 용이	표준화와 대중성 부족
Object-Relational DBMS	Relational + Object concept	관계형 기반 유지 + 복잡한 type 지원	시스템 복잡도 증가 가능

15. Hierarchical DBMS

Hierarchical DBMS는 tree structure를 사용한다.
대표 예시는 IBM의 IMS다.

예시 구조는 다음과 같다.

기업
 ├─ 부서 1
 │   ├─ 프로젝트 1
 │   │   ├─ 사원 1
 │   │   └─ 사원 2
 │   └─ 프로젝트 2
 └─ 부서 2
     └─ 프로젝트 3

이 구조는 1:N 관계에는 자연스럽다.
하지만 학생과 과목처럼 N:M 관계를 표현하기 어렵다.

학생 여러 명 ↔ 과목 여러 개

Hierarchical DBMS의 핵심 한계는 다음과 같다.

one-to-many 관계는 잘 처리하지만 many-to-many 관계는 그렇지 못하다.

16. Network DBMS

Network DBMS는 graph structure를 사용한다.
record는 node로, record 사이의 relationship은 edge로 표현된다.

Hierarchical DBMS보다 N:M 관계 표현에 유리하다.

학생 1 ─ 과목 1
학생 1 ─ 과목 2
학생 2 ─ 과목 1

하지만 record들이 link로 연결되어 있기 때문에 record structure를 변경하기 어렵다.
즉 접근 경로와 구조 변경 부담이 여전히 크다.

17. Relational DBMS

Relational DBMS는 1970년 E. F. Codd가 제안한 relational data model을 기반으로 한다.

Relational DBMS의 핵심은 table이다.

STUDENT(NAME, ST_NO, ADDRESS, DEPT, GRADE)

장점은 다음과 같다.

model이 단순함
table 형태라 이해하기 쉬움
SQL 사용 가능
사용자는 원하는 것만 명시
data가 어디에 있고 어떻게 접근할지는 DBMS가 결정

예시는 다음과 같다.

SELECT NAME
FROM STUDENT
WHERE DEPT = '컴퓨터';

이 질의에서 사용자는 what만 명시한다.
DBMS가 index 사용 여부, scan 방식, join 순서 등을 결정한다.

18. Object-Oriented DBMS와 Object-Relational DBMS

Object-Oriented DBMS는 object-oriented programming paradigm을 Database에 적용한 방식이다.

Object는 data와 method를 함께 가진다.

Student object
- attributes: sid, name, dept, grade
- methods: registerCourse(), getGrade()

장점은 복잡한 object를 표현하기 쉽다는 것이다.
CAD, multimedia, engineering data처럼 단순 table로 표현하기 어려운 데이터에 적합하다.

Object-Relational DBMS는 relational DBMS에 object-oriented concept를 통합한 방식이다.

예를 들어 다음 기능을 지원할 수 있다.

user-defined type
array
structured type
object type
image, spatial data 같은 special data type
function extension

19. DBMS Language: DDL, DML, DCL

DBMS language는 크게 세 가지로 나눌 수 있다.

구분	영문	역할	대표 명령
DDL	Data Definition Language	schema 정의	`CREATE`, `ALTER`, `DROP`, `CREATE INDEX`
DML	Data Manipulation Language	data 검색, 삽입, 수정, 삭제	`SELECT`, `INSERT`, `UPDATE`, `DELETE`
DCL	Data Control Language	권한과 transaction 제어	`GRANT`, `REVOKE`, `COMMIT`, `ROLLBACK`

짧게 정리하면 다음과 같다.

DDL = Define
DML = Manipulate
DCL = Control

20. DDL: Data Definition Language

DDL은 Database schema를 정의하는 언어다.

예시는 다음과 같다.

CREATE TABLE STUDENT (
    student_id INT PRIMARY KEY,
    name VARCHAR(30) NOT NULL,
    department VARCHAR(50),
    grade INT
);

DDL의 주요 기능은 다음과 같다.

기능	SQL 예시
data structure 생성	`CREATE TABLE`
data structure 변경	`ALTER TABLE`
data structure 삭제	`DROP TABLE`
index 정의	`CREATE INDEX`

DDL이 실행되면 DBMS는 schema 명세를 System Catalog 또는 Data Dictionary에 저장한다.

21. DML: Data Manipulation Language

DML은 Database 안의 실제 data를 다루는 언어다.

대표 기능은 다음과 같다.

기능	SQL 예시
검색	`SELECT`
삽입	`INSERT`
수정	`UPDATE`
삭제	`DELETE`

예시는 다음과 같다.

INSERT INTO STUDENT (student_id, name, department, grade)
VALUES (2024001, '김철수', '컴퓨터공학과', 2);

SELECT *
FROM STUDENT
WHERE department = '컴퓨터공학과';

UPDATE STUDENT
SET grade = 3
WHERE student_id = 2024001;

DELETE FROM STUDENT
WHERE student_id = 2024001;

DML은 procedural language와 non-procedural language로 나눌 수 있다.
SQL은 대표적인 non-procedural language다.

Procedural language: how를 명시
Non-procedural language: what을 명시

22. DCL: Data Control Language

DCL은 권한과 transaction을 제어한다.

권한 제어 예시는 다음과 같다.

GRANT SELECT
ON STUDENT
TO user1;

REVOKE SELECT
ON STUDENT
FROM user1;

Transaction 제어 예시는 다음과 같다.

COMMIT;

ROLLBACK;

COMMIT은 변경 내용을 확정하고, ROLLBACK은 변경 내용을 취소한다.

Transaction은 하나의 논리적 작업 단위다.
예를 들어 계좌 이체는 다음 두 작업이 함께 성공하거나 함께 실패해야 한다.

1. A 계좌에서 10만 원 차감
2. B 계좌에 10만 원 증가

23. DBMS 사용자

DBMS 사용자는 역할에 따라 나뉜다.

사용자	역할
DBA(Database Administrator)	운영, 권한, 백업, 회복, schema 관리
Database Designer	database structure 설계, normalization
Application Programmer	DB를 사용하는 application 개발
End User	질의, 갱신, report 생성
Operator	DBMS가 운영되는 computer system과 전산실 관리

24. DBA

DBA는 조직 전체의 일관성 있는 Database schema를 생성하고 유지하는 사람 또는 팀이다.

주요 역할은 다음과 같다.

Database schema 생성과 변경
integrity constraint 명시
사용자 권한 부여와 취소
role 관리
storage structure와 access method 정의
backup과 recovery
표준화 시행

예를 들어 DBA는 다음과 같은 constraint를 정의할 수 있다.

CREATE TABLE EMPLOYEE (
    empno INT PRIMARY KEY,
    name VARCHAR(30) NOT NULL,
    salary INT CHECK (salary >= 0),
    department_id INT,
    FOREIGN KEY (department_id) REFERENCES DEPARTMENT(deptno)
);

25. Application Programmer와 Canned Transaction

Application Programmer는 Database를 사용하는 application을 개발한다.

예시는 다음과 같다.

고객 관리
인사 관리
재고 관리
주문 처리

Application Programmer가 작성한 프로그램은 end user가 반복해서 수행한다.
이런 미리 작성된 반복 작업을 canned transaction이라고 한다.

예를 들어 ATM의 기능은 canned transaction의 좋은 예다.

잔액 조회
출금
입금
계좌 이체
거래 내역 조회

사용자는 SQL을 직접 작성하지 않고, 미리 만들어진 화면과 버튼을 통해 transaction을 실행한다.

26. End User

End User는 Database를 사용해 질의, 갱신, report 생성을 수행하는 사용자다.

End User는 다시 두 가지로 나눌 수 있다.

구분	특징	예시
Casual User	매번 다른 질의를 수행	분석가, 관리자
Naive User	canned transaction을 반복 수행	은행 창구 직원, POS 직원, 일반 앱 사용자

Casual User는 직접 SQL이나 query tool을 사용할 수 있다.

SELECT department, AVG(salary)
FROM EMPLOYEE
GROUP BY department;

Naive User는 SQL을 몰라도 application 화면을 통해 정해진 작업을 반복한다.

27. ANSI/SPARC 3-Level Architecture

ANSI/SPARC architecture는 Database System을 세 단계로 나누어 설명한다.

단계	영어	의미
외부 단계	External Level	사용자별 view
개념 단계	Conceptual Level	조직 전체의 logical schema
내부 단계	Internal Level	physical storage schema

핵심 구조는 다음과 같다.

External Views
      ↓
Conceptual Schema
      ↓
Internal Schema
      ↓
Stored Database

이 구조의 목적은 각 단계를 분리해서 data independence를 제공하는 것이다.

28. External Level

External level은 각 사용자가 보는 Database view다.

같은 Database라도 사용자마다 필요한 데이터가 다르다.

예를 들어 회사 Database에 다음 table이 있다고 하자.

EMPLOYEE(EMPNO, NAME, DEPT, SALARY, ADDRESS, PHONE)

일반 직원에게는 SALARY를 보여주지 않는 view를 제공할 수 있다.

CREATE VIEW EMP_PUBLIC AS
SELECT EMPNO, NAME, DEPT
FROM EMPLOYEE;

External level의 의미는 다음 두 가지다.

사용자 편의성
보안

29. Conceptual Level

Conceptual level은 조직 전체의 logical schema다.

예를 들어 다음과 같은 table 구조가 conceptual schema다.

EMP(ENO, ENAME, TITLE)
PROJ(PNO, PNAME, BUDGET)
WORKS(ENO, PNO, RESP, DUR)

Conceptual level은 다음을 다룬다.

어떤 data가 저장되는가
data 사이의 relationship은 무엇인가
어떤 integrity constraint가 있는가

반면 다음은 conceptual level의 관심사가 아니다.

data가 disk의 어디에 저장되는가
어떤 index를 쓰는가
file structure가 무엇인가

30. Internal Level

Internal level은 실제 physical data structure에 관한 schema다.

예를 들어 다음과 같은 내용이 internal schema에 해당한다.

EMP table은 unordered file로 저장한다.
EMP(ENO)에 index를 생성한다.
PROJ(PNO)에 index를 생성한다.
WORKS(ENO, PNO)에 index를 생성한다.

Internal level은 다음을 다룬다.

file organization
index
hashing
compression
access path
storage location

31. Schema Mapping

ANSI/SPARC architecture에서는 각 단계 사이에 mapping이 필요하다.

Mapping	역할
External/Conceptual Mapping	external view의 질의를 conceptual schema 기준 질의로 변환
Conceptual/Internal Mapping	conceptual schema 기준 질의를 internal schema 기준 접근으로 변환

예를 들어 사용자가 external view EMP_NAME에 대해 질의한다.

SELECT ENAME
FROM EMP_NAME
WHERE ENO = 10;

DBMS는 이를 conceptual schema의 EMP table 기준으로 바꾼다.

SELECT ENAME
FROM EMP
WHERE ENO = 10;

그 다음 internal schema를 확인해 EMP(ENO) index를 사용할지 결정한다.

32. Data Independence

Data Independence는 한 단계의 schema 변경이 상위 단계에 미치는 영향을 줄이는 성질이다.

두 종류가 있다.

구분	단계	의미
Logical Data Independence	External ↔ Conceptual	conceptual schema 변경이 external schema에 영향을 주지 않도록 함
Physical Data Independence	Conceptual ↔ Internal	internal schema 변경이 conceptual schema에 영향을 주지 않도록 함

예시는 다음과 같다.

변경 예시	독립성 종류
table에 column 추가	Logical Data Independence
table을 분해했지만 기존 view 유지	Logical Data Independence
index 추가	Physical Data Independence
file structure 변경	Physical Data Independence
data compression 방식 변경	Physical Data Independence
storage location 변경	Physical Data Independence

짧게 외우면 다음과 같다.

Logical Data Independence = 논리 구조 변경을 사용자 view로부터 숨김
Physical Data Independence = 저장 방식 변경을 logical schema로부터 숨김

33. Database System Architecture

DBMS 내부는 여러 module로 구성된다.

Module	역할
DDL Compiler	DDL을 처리하고 schema 명세를 System Catalog에 저장
Query Processor	DML 질의를 분석, 최적화, 실행 가능한 형태로 번역
Run-time Database Manager	실제 disk의 Database에 접근
Transaction Manager	concurrency control과 recovery 담당

전체 흐름은 다음과 같다.

DBA
 ↓ DDL
DDL Compiler
 ↓
System Catalog

End User / Programmer
 ↓ Query
Query Processor
 ↓
Run-time Database Manager
 ↓
Stored Database

Transaction Manager는 동시성 제어와 회복을 통해 Database consistency를 유지한다.

34. Database API와 ODBC

응용 프로그램은 Database API를 통해 DBMS에 접근할 수 있다.

대표 예시는 ODBC(Open Database Connectivity)다.

ODBC의 목적은 application이 특정 DBMS에 강하게 종속되지 않고, 표준화된 interface를 통해 여러 DBMS에 접근할 수 있게 하는 것이다.

Application
    ↓
ODBC API
    ↓
DBMS Driver
    ↓
Database

현대 환경에서는 JDBC, Python DB-API, ORM, database driver가 비슷한 역할을 한다.

35. Centralized Database System

Centralized Database System은 Database System이 하나의 computer system에서 운영되는 구조다.

Users
  ↓
Central DBMS + Database

장점은 다음과 같다.

구조가 단순함
중앙 관리가 쉬움
backup과 security 정책을 한 곳에서 관리하기 좋음
data 중복을 줄이기 쉬움

단점은 다음과 같다.

중앙 system에 부하 집중
중앙 system 장애 시 전체 서비스 영향 가능

36. Distributed Database System

Distributed Database System은 network로 연결된 여러 site에 Database가 분산되어 있는 구조다.

Site A DBMS + DB
      ↕
Site B DBMS + DB
      ↕
Site C DBMS + DB

핵심은 다음이다.

Database가 여러 site에 나뉘어 저장되어 있어도, 사용자는 전체를 하나의 Database처럼 사용할 수 있어야 한다.

장점은 다음과 같다.

지역별 접근 속도 향상 가능
확장성
장애 분산

주의할 점은 다음과 같다.

site 간 synchronization이 필요함
distributed transaction 관리가 복잡함
network 장애를 고려해야 함
consistency 유지가 어려울 수 있음

37. Client-Server Database System

Client-Server Database System은 client와 database server가 역할을 나누는 구조다.

Client
  ↕
Database Server
  ↕
Database

Client의 역할은 다음과 같다.

user interface
input handling
일부 application logic

Database Server의 역할은 다음과 같다.

Database 저장
DBMS 운영
query optimization
authorization check
concurrency control
recovery
integrity constraint 유지

38. 2-Tier Model과 3-Tier Model

Client-Server 구조는 2-tier와 3-tier로 나눌 수 있다.

구조	형태	특징
2-tier	`Client ↔ Database Server`	client가 DB server에 직접 접속
3-tier	`Client ↔ Application Server ↔ Database Server`	business logic이 application server에 위치

2-tier model은 단순하지만, client 수가 많아지면 DB 연결 관리가 복잡해질 수 있다.

3-tier model은 현대 web service 구조와 유사하다.

Web Browser / Mobile App
        ↓
Application Server
        ↓
Database Server

3-tier model의 장점은 역할 분리가 명확하다는 것이다.

client: 화면과 입력
application server: business logic
database server: data persistence와 DBMS 기능

39. 자칫 실수하기 쉬운 구분

Database와 DBMS

구분	설명
Database	저장된 data
DBMS	data를 관리하는 software

Schema와 State

구분	설명
Schema	구조, intension
State	특정 시점의 실제 내용, extension

DDL과 DML

구분	설명
DDL	table 구조를 만들거나 바꿈
DML	table 안의 data를 검색하거나 바꿈

DELETE와 DROP도 구분해야 한다.

DELETE FROM STUDENT;

DELETE는 table 안의 row를 삭제한다.
table 구조는 남아 있다.

DROP TABLE STUDENT;

DROP TABLE은 table 자체를 삭제한다.

Logical Data Independence와 Physical Data Independence

구분	변경되는 단계	보호되는 단계
Logical Data Independence	Conceptual schema	External schema
Physical Data Independence	Internal schema	Conceptual schema

Hierarchical DBMS와 Network DBMS

구분	구조	관계 표현
Hierarchical DBMS	Tree	1:N에 적합
Network DBMS	Graph	N:M 표현 가능

40. 핵심 요약

DB 01의 핵심은 다음과 같다.

Data는 원자료이고, Information은 data를 질의나 프로그램으로 가공한 결과다.
Database는 조직체의 application들이 공유하는 operational data의 구조적 통합체다.
DBMS는 Database를 정의, 질의, 수정, 보호, 회복, 동시성 제어하는 software다.
File System 방식은 data redundancy, inconsistency, security, recovery, program-data dependence 문제가 있다.
DBMS는 integrated database, query language, security, integrity, concurrency control, recovery를 제공한다.
Data Model은 structure, operators, integrity constraints를 포함한다.
DBMS는 hierarchical, network, relational, object-oriented, object-relational 방식으로 발전했다.
Relational DBMS의 핵심은 table과 SQL이며, 사용자는 what만 명시하고 DBMS가 how를 결정한다.
DDL은 schema 정의, DML은 data 조작, DCL은 권한과 transaction 제어를 담당한다.
DBA, Database Designer, Application Programmer, End User, Operator는 서로 다른 역할을 가진다.
ANSI/SPARC architecture는 external, conceptual, internal level로 구성된다.
Data Independence는 logical data independence와 physical data independence로 나뉜다.
DBMS architecture는 DDL compiler, query processor, run-time database manager, transaction manager로 구성된다.
Database system은 centralized, distributed, client-server 구조로 운영될 수 있다.