데이터베이스 구조·스키마·데이터 모델
데이터베이스는 통합·저장·운영·공용 데이터이고 DBMS는 이를 정의·조작·제어하는 소프트웨어다. 스키마는 구조와 제약의 정의이며 인스턴스는 특정 시점의 데이터다. 외부·개념·내부 스키마와 매핑을 구분하면 논리적·물리적 데이터 독립성을 판별할 수 있다. 데이터 모델은 구조·연산·제약조건으로 이루어지며 개념·논리·물리 설계를 거쳐 구현된다.
데이터베이스·DBMS·RDBMS·SQL을 구분한다
데이터베이스 관련 문제는 데이터 집합, 관리 소프트웨어, 데이터 모델, 요청 언어를 먼저 분리하면 대부분의 오답을 제거할 수 있다.
| 용어 | 의미 | 시험에서 구분할 점 |
|---|---|---|
| 데이터베이스(Database) | 서로 관련된 데이터를 일정한 구조로 통합·저장한 데이터 집합 | 프로그램이나 언어가 아니라 관리 대상인 데이터다. |
| DBMS(Database Management System) | 데이터베이스를 정의·저장·검색·변경하고 무결성·보안·동시성·회복을 관리하는 소프트웨어 | 데이터베이스 자체나 SQL과 같지 않다. |
| 데이터베이스 시스템 | 데이터베이스와 DBMS를 중심으로 사용자·응용 프로그램·하드웨어·운영 절차가 함께 동작하는 전체 환경 | 교재에 따라 포함 범위가 조금 다르지만 DBMS 하나만을 뜻하지는 않는다. |
| RDBMS(Relational DBMS) | 관계 모델에 따라 데이터를 릴레이션, 즉 표 형태의 논리 구조로 관리하는 DBMS | 모든 DBMS가 RDBMS인 것은 아니다. |
| SQL(Structured Query Language) | 관계형 DBMS에 데이터 정의·조회·변경·권한 제어 등을 요청하는 언어 | SQL은 언어이며 DBMS 제품이 아니다. |
데이터베이스의 기본 성격
전통적인 데이터베이스 정의에서는 다음 네 성격을 함께 묻는다.
| 성격 | 의미 | 오답 경계 |
|---|---|---|
| 통합된 데이터 | 여러 업무의 관련 데이터를 중복과 불일치가 최소화되도록 통합한다. | 중복을 무조건 0으로 만든다는 뜻은 아니다. 성능·가용성 때문에 통제된 중복을 둘 수 있다. |
| 저장된 데이터 | 컴퓨터가 접근할 수 있는 저장 매체에 보존한다. | 잠시 계산한 값만 모아 둔 임시 결과와 구분한다. |
| 운영 데이터 | 조직의 기능 수행에 계속 필요한 업무 데이터를 다룬다. | 개인 메모처럼 업무 목적과 무관한 자료를 뜻하지 않는다. |
| 공용 데이터 | 여러 사용자와 응용 프로그램이 공동으로 사용한다. | 한 프로그램만을 위해 고립된 파일과 대비된다. |
데이터베이스의 운용 특성은 다음처럼 정리한다.
| 특성 | 판단 기준 |
|---|---|
| 실시간 접근성 | 사용자의 질의에 업무상 허용되는 시간 안에 응답할 수 있어야 한다. 문자 그대로 지연이 0이라는 뜻은 아니다. |
| 계속적인 변화 | 삽입·삭제·수정으로 데이터 상태가 지속적으로 바뀐다. |
| 동시 공유 | 여러 사용자가 같은 데이터를 동시에 사용할 수 있으며 DBMS가 충돌을 조정한다. |
| 내용에 의한 참조 | 물리 주소가 아니라 데이터 값과 조건을 이용해 필요한 내용을 찾는다. |
DBMS가 제공하는 핵심 기능
| 기능 | 하는 일 | 대표 예 |
|---|---|---|
| 정의 | 데이터 구조, 자료형, 관계, 제약조건을 기술한다. | 테이블과 제약조건 생성 |
| 조작 | 데이터를 검색·삽입·수정·삭제한다. | 조건에 맞는 주문 조회 |
| 제어 | 무결성·권한·동시성·트랜잭션·회복을 관리한다. | 권한 검사, 로그 기록, 장애 복구 |
파일 처리 방식과 비교하면 DBMS는 데이터 독립성, 중복·불일치 통제, 동시 공유, 무결성, 보안, 백업·회복, 표준화를 제공하기 쉽다. 반면 제품과 운영 비용, 구조의 복잡성, 전문 인력과 자원 소모가 늘 수 있고 중앙 시스템 장애의 영향도 커질 수 있다. 따라서 “DBMS는 항상 더 단순하고 비용이 적다”는 선지는 옳지 않다.
사용자의 요청은 일반적으로 다음 흐름으로 처리된다.
사용자·응용 프로그램
│ SQL 또는 API 요청
▼
DBMS
├─ 스키마·권한·제약조건 확인
├─ 질의 처리와 실행 방법 결정
├─ 버퍼·로그·잠금·회복 관리
└─ 저장 장치의 데이터 접근
│
▼
결과 또는 처리 상태 반환
응용 프로그램은 원하는 내용을 요청하고, DBMS는 어떤 파일과 접근 경로를 사용할지 결정한다. 이 분리가 데이터 독립성의 기반이 된다.
스키마·인스턴스·메타데이터
스키마와 인스턴스
| 구분 | 스키마(Schema) | 인스턴스(Instance) |
|---|---|---|
| 의미 | 데이터베이스의 구조와 제약조건에 대한 정의 | 특정 시점에 저장된 실제 데이터 상태 |
| 다른 표현 | 내포(Intension) | 외연(Extension), 어커런스(Occurrence) |
| 변화 빈도 | 상대적으로 드물게 변경 | 삽입·수정·삭제에 따라 자주 변경 |
| 예 | 테이블명, 열, 자료형, 키, 관계, 제약조건 | 현재 고객 행과 주문 행의 값 |
다음 정의는 스키마이고, 그 아래의 행들은 스키마를 따르는 인스턴스다.
CUSTOMER(customer_id INTEGER PRIMARY KEY,
customer_name TEXT NOT NULL)
시점 A의 인스턴스
(1, '민준')
(2, '서연')
시점 B의 인스턴스
(1, '민준')
(2, '서연')
(3, '지우')
시점 A에서 B로 바뀌어도 열 구조와 제약조건이 그대로라면 스키마는 같고 인스턴스만 달라진 것이다. 일반적으로 DDL은 스키마를, DML은 인스턴스를 변경하지만 제품별 세부 동작과 예외는 별도로 확인해야 한다.
메타데이터와 데이터 사전
메타데이터(Metadata)는 데이터에 대한 데이터다. 테이블·열·자료형·기본값·제약조건·사용자·권한·저장 공간 같은 정의와 관리 정보를 말한다. DBMS는 이러한 메타데이터를 데이터 사전(Data Dictionary) 또는 시스템 카탈로그에 관리한다.
| 구분 | 예 |
|---|---|
| 사용자 데이터 | 고객 1번의 이름이 ‘민준’이라는 행 |
| 메타데이터 | customer_name 열의 자료형이 TEXT이고 NOT NULL이라는 정의 |
데이터 사전은 일반 업무 데이터와 목적이 다르다. 사용자가 임의로 시스템 내부 테이블을 직접 수정하는 방식이 아니라, 보통 DBMS가 DDL 실행 결과를 반영하고 사용자는 제공된 사전 뷰나 카탈로그 인터페이스로 조회한다.
3단계 스키마 구조
3단계 스키마 구조는 데이터베이스를 서로 다른 관점으로 분리하는 추상적 아키텍처다. 실제 제품 안에 이름이 정확히 ‘외부 스키마’, ‘개념 스키마’, ‘내부 스키마’인 객체 세 개가 반드시 존재한다는 뜻은 아니다.
외부 스키마 1 외부 스키마 2 ... 외부 스키마 n
\ | /
외부–개념 매핑
│
개념 스키마 1개
│
개념–내부 매핑
│
내부 스키마 1개
│
저장 데이터
| 단계 | 관점 | 주요 내용 | 개수의 고전적 설명 |
|---|---|---|---|
| 외부 스키마(External Schema) | 개별 사용자·응용 프로그램 | 필요한 데이터의 일부, 표시 형식, 접근 범위, 사용자별 이름 | 여러 개 |
| 개념 스키마(Conceptual Schema) | 조직 전체 | 전체 데이터의 논리 구조, 관계, 의미, 무결성·보안 규칙 | 1개 |
| 내부 스키마(Internal Schema) | 저장·접근 방식 | 레코드 배치, 파일 구조, 페이지, 인덱스, 접근 경로, 저장 표현 | 1개 |
외부 스키마는 ‘사용자 관점의 데이터 표현’이라는 추상 개념이다. SQL의 VIEW로 구현할 수 있지만 외부 스키마와 SQL 뷰가 언제나 일대일로 같은 것은 아니다.
두 매핑의 역할
- 외부–개념 매핑은 사용자별 외부 표현을 전체 개념 구조와 연결한다.
- 개념–내부 매핑은 전체 논리 구조를 저장 구조와 연결한다.
스키마가 바뀌었을 때 매핑이나 DBMS가 차이를 흡수하면 상위 단계와 응용 프로그램에 미치는 영향을 줄일 수 있다. 데이터 독립성은 변화가 절대로 전파되지 않는다는 뜻이 아니라, 영향을 최소화하도록 계층과 매핑을 분리했다는 뜻이다.
논리적·물리적 데이터 독립성
| 구분 | 변경되는 단계 | 보호하려는 단계 | 대표 예 |
|---|---|---|---|
| 논리적 데이터 독립성 | 개념 스키마 | 외부 스키마와 응용 프로그램 | 개념 스키마에 속성을 추가하거나 관계를 재구성해도 기존 외부 표현을 유지 |
| 물리적 데이터 독립성 | 내부 스키마 | 개념·외부 스키마와 응용 프로그램 | 인덱스 추가, 파일 재배치, 저장 장치 변경, 압축·파티션 방식 변경 |
방향을 다음처럼 기억하면 된다.
논리적 데이터 독립성: 개념 변경 → 외부 영향 최소화
물리적 데이터 독립성: 내부 변경 → 개념 영향 최소화
물리적 데이터 독립성은 저장 방식만 바꾸고 논리 구조를 유지하면 되므로 일반적으로 논리적 데이터 독립성보다 구현하기 쉽다. 논리 구조가 바뀌면 사용자에게 보이는 열·관계·제약조건과 프로그램의 전제가 함께 영향을 받을 가능성이 더 크기 때문이다.
다음 변화가 어느 범주인지 구분해 보자.
| 변화 | 실제로 바뀐 것 | 관련 판단 |
|---|---|---|
| 주문 테이블에 인덱스 추가 | 내부의 접근 경로 | 물리적 데이터 독립성의 대표 예 |
| 데이터 파일 위치와 저장 장치 변경 | 내부 저장 표현 | 물리적 데이터 독립성의 대표 예 |
| 개념 스키마에 고객 등급 속성을 추가하고 기존 사용자 화면은 그대로 유지 | 전체 논리 구조 | 논리적 데이터 독립성의 예 |
| 고객 행 한 건 삽입 | 인스턴스 | 스키마 변경이나 데이터 독립성 사례가 아님 |
| 백업 파일 생성 | 운영·회복 작업 | 그 자체로 논리적·물리적 데이터 독립성의 정의가 아님 |
3단계 스키마와 독립성
여러 외부 스키마는 사용자 관점, 하나의 개념 스키마는 전체 논리 구조, 내부 스키마는 저장 구조·접근 경로다. 논리적 독립성은 개념 변경의 외부 영향을, 물리적 독립성은 내부 변경의 개념 영향을 줄인다.
데이터 모델의 의미와 구성 요소
데이터 모델(Data Model)은 현실 세계의 데이터를 어떤 구조로 표현하고, 어떤 연산을 허용하며, 어떤 제약조건을 지켜야 하는지 설명하는 개념과 규칙의 집합이다.
| 구성 요소 | 설명 | 관계 모델의 예 |
|---|---|---|
| 구조(Structure) | 데이터와 관계를 어떤 형태로 표현하는가 | 릴레이션, 튜플, 속성 |
| 연산(Operation) | 데이터를 어떻게 검색·삽입·삭제·변경하는가 | 선택·투영·조인 또는 SQL 연산 |
| 제약조건(Constraint) | 허용되는 데이터 상태와 연산의 규칙은 무엇인가 | 도메인·키·참조 무결성 |
세 용어의 관계는 다음과 같다.
데이터 모델 → 표현 규칙과 연산의 틀
스키마 → 그 모델을 사용해 작성한 특정 데이터베이스의 설계도
인스턴스 → 그 스키마에 따라 저장된 특정 시점의 실제 값
예를 들어 관계 모델은 표·행·열과 관계 연산의 규칙을 제공한다. CUSTOMER(customer_id, customer_name)는 관계 모델로 작성한 하나의 스키마이고, (1, '민준')은 그 스키마에 속한 인스턴스의 일부다.
대표 데이터 모델
| 모델 | 구조와 관계 | 시험에서 보는 특징 |
|---|---|---|
| 계층형 모델 | 트리 구조의 부모–자식 관계 | 자식은 전통적으로 하나의 부모에 연결되며 1:N 표현에 적합하다. |
| 네트워크형 모델 | 레코드와 연결을 그래프처럼 구성 | 한 레코드가 여러 부모와 연결될 수 있어 M:N 표현이 가능하다. |
| 관계형 모델 | 데이터를 릴레이션으로 표현 | 키와 무결성 제약, 집합 기반 연산을 사용한다. |
| 객체지향 모델 | 객체·클래스·속성·메서드·상속을 사용 | 복합 객체와 객체의 행위를 함께 표현한다. |
| 객체관계형 모델 | 관계형 구조에 객체 개념을 확장 | 사용자 정의 타입과 복합 구조 등을 관계형 DBMS에 결합한다. |
ER 모델은 개체·속성·관계로 업무 의미를 표현하는 대표적인 개념적 데이터 모델이다. 계층형·네트워크형·관계형 모델처럼 저장 DBMS의 논리 구조를 직접 나타내는 모델과 용도를 구분해야 한다.
개념·논리·물리 데이터 모델링
데이터 모델링은 현실 업무를 데이터 구조로 단계적으로 구체화하는 과정이다. 단계가 내려갈수록 구현 세부가 늘어나지만, 검토 결과에 따라 앞 단계로 되돌아갈 수 있으므로 반드시 한 번만 진행되는 직선 과정은 아니다.
| 단계 | 핵심 질문 | 대표 산출물 | DBMS 제품 의존성 |
|---|---|---|---|
| 개념 데이터 모델 | 업무에 어떤 개체·관계·규칙이 있는가 | 핵심 개체, 관계, 업무 규칙, 개념 ERD | 거의 없음 |
| 논리 데이터 모델 | 선택한 데이터 모델로 구조를 어떻게 정제할 것인가 | 릴레이션·속성·식별자·키·도메인·정규화·논리 제약 | 원칙적으로 특정 제품과 독립 |
| 물리 데이터 모델 | 목표 DBMS에 실제로 어떻게 구현하고 성능을 확보할 것인가 | 테이블·열의 실제 이름과 자료형, 길이, 인덱스, 파티션, 저장 옵션, DDL | 높음 |
고객–주문 예제로 연결하기
개념 모델에서는 업무 의미를 먼저 잡는다.
고객은 주문을 할 수 있다.
한 고객은 여러 주문을 할 수 있고, 각 주문은 한 고객에 속한다.
주문 금액은 0 이상이어야 한다.
논리 모델에서는 관계형 구조로 정제한다.
CUSTOMER(
customer_id PK,
customer_name
)
CUSTOMER_ORDER(
order_id PK,
customer_id FK → CUSTOMER.customer_id,
ordered_at,
total_amount CHECK total_amount >= 0
)
물리 모델에서는 목표 DBMS의 자료형, 길이, NULL 허용 여부, 인덱스와 저장 위치를 구체화한다. 예를 들어 주문일은 적절한 날짜·시간 자료형으로, 금액은 필요한 정밀도의 수치형으로 정하고 고객별 주문 조회에 필요한 인덱스를 검토한다. 이 단계에서 실제 CREATE TABLE 문을 만들 수 있다.
데이터베이스 설계의 전체 흐름은 요구조건 분석 → 개념 설계 → 논리 설계 → 물리 설계 → 구현으로 정리한다. 앞 단계의 업무 규칙이 뒷 단계의 테이블·제약조건으로 연결되어야 한다.
이름이 비슷한 두 분류 축을 혼동하지 않는다
3단계 스키마 구조와 개념·논리·물리 모델링은 단어가 비슷하지만 같은 분류가 아니다.
| 구분 | 3단계 스키마 구조 | 개념·논리·물리 모델링 |
|---|---|---|
| 분류 목적 | 사용자 관점·전체 논리 구조·저장 표현을 분리 | 업무 요구를 구현 가능한 데이터베이스 설계로 구체화 |
| 구성 | 외부·개념·내부 스키마 | 개념·논리·물리 모델 |
| 핵심 관계 | 단계 사이의 매핑과 데이터 독립성 | 설계 산출물의 점진적 상세화 |
| 주의 | 개념 스키마는 조직 전체의 논리 구조다. | 개념 모델은 업무 개체와 관계를 높은 추상도로 표현한다. |
다음 등식은 성립하지 않는다.
- 외부 스키마 = 개념 모델
- 개념 스키마 = 논리 모델
- 내부 스키마 = 물리 모델
- 외부 스키마 = SQL
VIEW
서로 관련은 있지만 분류 목적과 범위가 다르므로 문제의 문맥을 확인해야 한다.
데이터베이스 기본 용어의 판단 기준
통합된 데이터는 서로 관련된 자료를 통합하여 불필요한 중복을 줄이고 일관된 관리 대상으로 만든다는 성격이다. 저장된 데이터는 저장 매체에 기록된 자료, 운영 데이터는 조직의 업무에 필요한 자료, 공용 데이터는 여러 사용자·응용이 함께 이용하는 자료라는 관점이다. 네 용어는 동일한 분류 질문이므로 키워드만으로 서로 바꾸지 않는다.
내용에 의한 참조는 사용자가 물리 주소를 직접 지정하기보다 값·조건으로 필요한 자료를 요청한다는 특성이다. 스키마에는 구조와 제약의 정의가, 인스턴스에는 특정 시점의 실제 값이 있다. 데이터 사전에는 테이블·열·자료형·제약조건·권한처럼 데이터 자체를 설명하는 메타데이터가 있다.
계층형 모델은 트리 구조를 기본으로 하여 루트가 아닌 자식 레코드가 하나의 부모와 연결되는 구조를 나타낸다. 네트워크형 모델은 더 일반적인 연결 구조를 표현한다. 객체지향 모델은 객체의 상태뿐 아니라 그 상태를 다루는 행위와 객체 식별성도 표현한다. 관계형 모델의 구조·연산·제약은 각각 릴레이션 구성, 조작 방식, 유효한 상태의 규칙에 해당한다.
DBA는 스키마·권한·저장 공간·백업·복구·성능 등 데이터베이스의 운영과 통제를 담당한다. 업무 프로그램의 모든 기능 구현, 모든 일반 사용자의 조회 수행 자체와 동일한 역할은 아니다.