[데이터베이스] 02_DBMS 데이터베이스 시스템

DBMS와 3단계 스키마

데이터베이스는 여러 사용자를 위해 데이터를 통합·공유하고, 위치가 아닌 내용으로 데이터를 찾게 해준다. 그런데 누가 그걸 실현해줄까?

사용자가 직접 디스크를 뒤져 데이터를 통합하고 동시 접근을 조율할 수는 없다. 그 일을 전담하는 소프트웨어가 바로 DBMS다.

이 글에서는 DBMS가 무엇이고, 그것이 데이터를 세 층(3단계 스키마)으로 나눠 다루는 이유, 그리고 그 결과로 얻는 데이터 독립성이라는 핵심 가치를 살펴본다.

---

1. DBMS와 발전 세대

DBMS(DataBase Management System)란?
데이터베이스를 관리하고, 사용자/응용 프로그램과 데이터베이스 사이를 중재하는 소프트웨어. 오라클·MySQL·PostgreSQL 등이 여기 해당한다.

 

DBMS의 핵심 역할은 "사용자가 데이터의 물리적 저장 방식을 몰라도 데이터를 다룰 수 있게 가로막고 서는 것"이다.

데이터 독립성·통합·동시 공유가 전부 이 중재 계층 덕에 가능해진다. 디스크에 흩어진 바이트 더미를, DBMS는 사용자에게 "테이블"이라는 깔끔한 모습으로 추상화해 보여준다.

세대	종류	데이터 구조
1세대	계층 / 네트워크 DBMS	트리 / 그래프(노드·간선)
2세대	관계 DBMS	테이블(2차원 표), 현재 주류
3세대	객체지향 / 객체관계 DBMS	객체 개념 도입
4세대	NoSQL / NewSQL	비정형·확장성 / 관계+확장성

세대의 흐름을 관통하는 건 "데이터를 무엇으로 표현하느냐"의 변화다.

초기엔 데이터 사이의 관계를 트리·그래프 구조로 직접 엮었는데, 이러면 구조가 경직되고 질의가 복잡했다. 2세대 관계 모델은 데이터를 단순한 표로 통일하고 관계를 "값의 일치"로 표현해 유연성과 단순함을 동시에 얻었다.

그래서 관계 모델은 수십 년째 주류 자리를 지키고 있고, 데이터베이스 이론의 대부분도 이 관계 모델을 토대로 한다.

---

2. 데이터베이스 3단계 스키마 (ANSI 구조)

스키마 vs 인스턴스
스키마(schema)는 데이터베이스의 구조와 제약조건을 정의한 설계도로, 자주 바뀌지 않는다. 인스턴스(instance)는 특정 시점에 실제로 저장된 데이터 내용이다. 비유하자면 스키마는 "표의 양식(열 정의)"이고, 인스턴스는 "그 표에 채워진 행들"이다.

ANSI는 이 스키마를 보는 관점에 따라 세 단계로 나눈다. 데이터베이스 이론의 핵심 골격이다.

단계	스키마	관점	개수
외부 단계	외부 스키마(서브 스키마)	사용자·응용 프로그램이 보는 뷰	여러 개
개념 단계	개념 스키마	조직 전체의 통합된 논리 구조	하나
내부 단계	내부 스키마	물리적 저장 구조	하나

 

직관적으로 잡으려면 한 회사를 떠올리면 좋다.

• 외부 스키마: 부서별 맞춤 화면. 영업팀에는 매출 관련 항목만, 인사팀에는 급여 관련 항목만 보인다. 사용자마다 필요한 것만 보므로 여러 개다.
• 개념 스키마: 모든 부서의 뷰를 합친, 회사 전체 데이터의 단일한 논리 구조다. 그래서 하나다.
• 내부 스키마: 그 데이터가 디스크에 어떤 인덱스·파일 구조로 저장되는지를 정의한다. 역시 하나다.

---

3. 데이터 독립성

3단계로 굳이 나눈 이유가 바로 여기 있다. 단계 사이를 사상(mapping)으로 연결해두면, 한 단계의 변화가 다른 단계로 번지지 않게 격리할 수 있다. 이것이 데이터 독립성이다.

독립성	의미
논리적 데이터 독립성	개념 스키마가 바뀌어도 외부 스키마(응용)는 영향받지 않음
물리적 데이터 독립성	내부 스키마(저장 구조)가 바뀌어도 개념 스키마는 영향받지 않음

 

예를 들어보자.

• 논리적 독립성: 전체 구조(개념 스키마)에 새 항목을 추가해도, 기존 부서 화면(외부 스키마)은 그대로 쓸 수 있다.
• 물리적 독립성: 저장 장치를 HDD에서 SSD로 바꾸거나 인덱스 방식을 교체해도(내부 스키마 변경), 데이터의 논리 구조(개념 스키마)와 그 위의 응용은 손댈 필요가 없다.

이 독립성이 왜 그렇게 강조될까? 데이터를 프로그램과 묶어 관리하던 시절에는 "데이터 구조를 한 번 바꾸면 그걸 쓰는 모든 프로그램을 함께 고쳐야 하는" 데이터 종속성이 큰 골칫거리였다.

3단계 스키마와 데이터 독립성은 바로 이 문제를 정면으로 해결한다. 변경의 파급을 계층 경계에서 끊는다는 발상은, 소프트웨어 설계에서 두루 통하는 "관심사 분리"의 한 모습이다.

---

4. 데이터 언어

사용자가 DBMS에 일을 시킬 때 쓰는 언어는 역할에 따라 셋으로 나뉜다. SQL을 배울 때 모든 명령어가 이 세 갈래 중 하나로 분류된다.

언어	역할	대표 명령
DDL (정의어)	구조(스키마)를 정의·변경·삭제	CREATE, ALTER, DROP
DML (조작어)	데이터를 조회·삽입·수정·삭제	SELECT, INSERT, UPDATE, DELETE
DCL (제어어)	권한·트랜잭션 제어	GRANT, REVOKE, COMMIT, ROLLBACK

 

구분의 기준은 "무엇을 대상으로 하느냐"다.

• DDL은 틀(스키마)을,
• DML은 그 틀에 담긴 내용물(인스턴스)을,
• DCL은 누가 무엇을 할 수 있는지와 작업의 확정/취소를 다룬다.

앞서 본 스키마/인스턴스 구분이 그대로 DDL/DML 구분으로 이어지는 셈이다.

---

한 걸음 더

• 외부 스키마는 실제 관계형 데이터베이스에서 뷰(VIEW)로 구현된다. 원본 테이블은 그대로 두고, 특정 사용자에게 필요한 열·행만 보여주는 가상의 표를 만들어주는 기능이다. 본문의 "부서별 맞춤 화면"이 바로 이것이며, 보안(민감한 열 숨기기)과 편의(복잡한 조인을 미리 정의)를 동시에 챙기는 실무 단골 도구다.
• 요즘 백엔드 개발에서 쓰는 ORM(JPA, Sequelize 등)은 이 독립성 위에 또 한 겹을 쌓은 것으로 볼 수 있다. 객체(코드)와 테이블(DB) 사이를 매핑해, 개발자가 SQL의 물리적 디테일을 덜 신경 쓰게 해준다. 추상화 계층을 더 쌓아 관심사를 분리하는 흐름이 여기서도 반복된다.
• "스키마는 자주 안 바뀐다"는 전통적 전제는 NoSQL에서 흔들린다. 문서형 DB(MongoDB 등)는 미리 스키마를 고정하지 않는 schema-less 방식이라, 데이터 형태가 자주 변하는 서비스에 유리하다. 대신 구조를 강제하지 않으니 무결성 보장은 응용 책임이 된다. 유연성과 안전성의 trade-off가 또 등장하는 셈이다.

---