Database Three-Schema Architecture

Three-schema architecture는 Database System Foundation이 말한 "프로그램-데이터 독립성"과 "다관점 뷰"를 구체적인 스키마 계층으로 구현하는 프레임이다. 스키마를 3개 수준으로 분리해, 각 수준의 변경이 다른 수준에 영향을 주지 않도록 한다.^[1]

flowchart TD
  External["External Schema
(사용자 뷰, 프로그램 관점)"]
  Conceptual["Conceptual Schema
(전체 DB 구조·제약)"]
  Internal["Internal Schema
(물리적 저장 구조·인덱스)"]
  External -.->|logical independence| Conceptual
  Conceptual -.->|physical independence| Internal
  Program["Application Program"] --> External
  External --> Mapping1["외부/개념 매핑"]
  Mapping1 --> Conceptual
  Conceptual --> Mapping2["개념/내부 매핑"]
  Mapping2 --> Internal
  Internal --> Storage["Disk"]

3개 스키마 수준

수준	스키마	관점	사용 데이터 모델
외부 (External)	External Schema	사용자/프로그램 관점의 뷰^[2]. 각 사용자가 데이터베이스를 어떻게 보는지 기술^[3]	보통 개념 스키마와 동일한 데이터 모델^[3:1]
개념 (Conceptual)	Conceptual Schema	db 모델러 관점^[2:1]. 전체 데이터베이스 구조·제약 기술. 사용자 공동체를 위한 전체 스키마^[3:2]	개념적 또는 구현 데이터 모델^[3:3]
내부 (Internal)	Internal Schema	DBMS 구현 관점^[2:2]. 물리적 저장 구조·접근 경로(예: 인덱스) 기술^[3:4]	물리적 데이터 모델^[3:5]

스키마 레벨 사이의 매핑

외부/개념 매핑: 외부 스키마(프로그램) ↔ 개념 스키마 변환. 사용자 뷰를 전체 스키마의 일부로 매핑한다.
개념/내부 매핑: 개념 스키마 ↔ 내부 스키마(실제 저장 구조) 변환.

프로그램은 외부 스키마로 접근하고, DBMS가 내부 스키마로 매핑해 실행한다.^[4] 사용자/프로그램은 저장 세부를 몰라도 된다.

상용 DBMS에서 이 3계층이 명시적으로 사용되지는 않지만, 데이터베이스 시스템 구조를 설명하기에는 유용하다.^[1:1]

데이터 독립성

독립성 종류	정의	예
논리적 데이터 독립성	개념 스키마가 변해도 외부 스키마는 변하지 않는다.^[5]	전화번호 칼럼을 연락처로 바꿔도 매핑 관계는 존재하므로, 매핑은 유지하고 이름만 바꿔 보여준다.^[5:1]
물리적 데이터 독립성	내부 스키마가 변해도 개념 스키마는 변하지 않는다.^[6]	메모리에 E, F 순서로 저장돼 있을 때 F, E 순서로 바꿔도 매핑 관계만 같이 바꾸면 되므로 문제 없다. 파일 구조가 재구성되거나 새 인덱스가 생성돼 성능이 개선되는 경우도 해당한다.^[6:1]

데이터 독립성 2종을 구분하는 기준은 "어떤 스키마가 변했을 때 어느 스키마가 안 변해야 하는가"다.

개념 스키마 변화 → 외부 스키마 유지 = 논리적 독립성
내부 스키마 변화 → 개념 스키마 유지 = 물리적 독립성

DBMS 언어와 인터페이스

언어/인터페이스	역할
DDL (Data Definition Language)	데이터베이스 관리자/설계자가 개념 스키마를 명시한다. 많은 DBMS에서 내부·외부 스키마 정의에도 사용된다.^[7]
DML (Data Manipulation Language)	데이터베이스 검색(SELECT) 및 업데이트(INSERT/DELETE/UPDATE)를 지정한다. 프로그래밍 언어에 내장될 수 있다.^[8]
독립형 쿼리 인터페이스	DBMS에서 SQL 쿼리를 직접 입력한다.^[9]
프로그래머 인터페이스	DML을 프로그래밍 언어에 포함하기 위한 인터페이스.^[9:1]
사용자 친화적 인터페이스	메뉴 기반, 폼 기반, 그래픽 기반 등.^[9:2]

DML 유형

High-Level / Non-procedural — 결과는 같지만 무엇이 먼저 나올지 모른다. 집합(set) 기반이다.^[10] SQL을 대표 예로 드는 것은 이 page의 해석이다.
Low-Level / Procedural — 저장한 순서대로 그대로 실행한다.^[10:1] 이를 레코드 단위 처리로 보는 것은 이 page의 해석이다.

데이터 모델 분류 (3-schema를 지탱하는 개념 계층)

분류	설명	예
개념적 (Conceptual, high-level, semantic)	사용자가 데이터를 인식하는 방식에 가까운 개념. 엔티티 기반/객체 기반 데이터 모델이라고도 함^[11]	ER 모델
물리적 (Physical, low-level, internal)	컴퓨터에 데이터가 저장되는 방식에 대한 세부 정보. 보통 DBMS 설계/관리 매뉴얼로 임시 지정^[11:1]	파일 구조, 인덱스 물리 배치
구현 (Implementation, representational)	개념적·물리적의 중간. 상업적 DBMS 구현에 자주 사용^[11:2]	관계형 데이터 모델

Schema vs Instance (상태)

구분	설명	비유
Database Schema	데이터베이스에 대한 기술. structure, data types, constraints 포함^[12]	객체지향의 클래스^[12:1]
Schema Diagram	스키마의 시각적 표현^[12:2]	-
Schema Construct	스키마의 각 객체 (예: STUDENT, COURSE)^[12:3]	-
Database State (= Instance)	특정 시점의 실제 데이터^[12:4]	객체지향의 객체^[12:5]
Valid State	데이터베이스 구조와 제약조건을 충족한 상태^[12:6]	-

Schema는 거의 변하지 않고, State는 계속 수정된다. Schema는 intension(내연), State는 extension(외연)이다.^[12:7] 초기 데이터베이스 상태는 시스템에 처음 로드될 때의 상태다.^[13]

종합

3-schema architecture는 "DBMS가 왜 데이터 독립성을 제공할 수 있는가"를 설명하는 개념 프레임으로 읽을 수 있다. 외부/개념/내부를 분리하고 그 사이에 매핑을 두어, 사용자 프로그램은 저장 세부를 몰라도 되고, 저장 구조 변경이 프로그램 변경을 유발하지 않는다. 상용 DBMS가 이를 명시적으로 3-tier로 구현하지는 않지만, 설계 시 이 관점을 유지하면 논리적/물리적 변경의 영향 범위를 스키마 계층으로 흡수할 수 있다는 것이 이 페이지의 종합이다.^[14]

흔히 놓치는 지점

외부 스키마(뷰) 없이 모든 사용자가 개념 스키마에 직접 접근하면, 개념 스키마 변경 시 모든 응용 코드를 고쳐야 한다.
개념/내부 매핑 없이 저장 구조를 직접 노출하면 물리적 독립성을 잃고, 인덱스 변경 시 응용 코드를 고쳐야 한다.
Schema(구조)와 State(데이터)를 혼동해 "스키마가 바뀌었다"는 표현을 단순 데이터 수정에 쓰는 경우가 있다.
상용 DBMS가 3-schema를 명시적으로 쓰지 않는다는 이유로 개념 자체를 무시하는 경우가 있다 — 여전히 논리적/물리적 계층 분리 설계의 지침으로 유효하다.

출처

테스트 질문

3-schema architecture가 제안된 배경은 무엇인가?
논리적 데이터 독립성과 물리적 데이터 독립성의 차이와 각 예는 무엇인가?
상용 DBMS가 3-schema를 명시적으로 사용하지 않는 이유는 무엇인가?
Schema와 Instance(State)의 관계를 객체지향의 클래스/객체와 비교해 설명하라.
DDL과 DML이 각각 주로 다루는 스키마 수준은 무엇인가?

개념정리.md — "프로그램-데이터 독립성, 데이터의 다관점을 지원하기 위해서", "상용 DBMS에서 명시적으로 사용되지는 않음", "데이터베이스 시스템의 구조를 설명하기에는 유용" ↩︎ ↩︎
개념정리.md — L132-140 'DBMS schema 정의': "Internal Schema⭐ ... DBMS 구현", "Conceptual schema⭐ ... db 모델러 관점", "External schema⭐ ... 사용자 관점, 프로그램 관점" ↩︎ ↩︎ ↩︎
2장 데이터베이스 시스템 개념과 아키텍처.md — "내부 스키마: 물리적 저장 구조와 액세스 경로(예: 인덱스)를 설명 ... 일반적으로 물리적 데이터 모델", "개념적 스키마: 사용자의 공동체를 위한 전체 데이터베이스의 구조와 제약을 설명 ... 개념적 또는 구현 데이터 모델", "외부 스키마: 여러 사용자의 뷰를 설명 ... 일반적으로 개념적 스키마와 동일한 데이터 모델" ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
개념정리.md — "프로그램 = 외부 스키마, DBMS에 의해 내부 스키마에 매핑되어 실행" ↩︎
개념정리.md — "Logical Data Independence: 개념 스키마가 변화해도 외부 스키마는 변하지 않음 ... 전화번호를 연락처로 바꿔도 이미 매핑 관계는 존재하므로 매핑관계는 유지하고 이름만 바꿔서 보여주면 됨" ↩︎ ↩︎
개념정리.md — "Physical Data Independece: 내부 스키마가 변화해도 개념 스키마는 변하지 않음 ... 메모리에 E,F 순서로 저장되어 있을 떄, F,E 순서로 바꿔도 매핑관계만 똑같이 바꾸면되므로 문제없음"; 2장 데이터베이스 시스템 개념과 아키텍처.md — "예를 들어, 파일 구조가 재구성되거나 새로운 인덱스가 생성되어 데이터베이스 성능을 개선할 수 있음" ↩︎ ↩︎
개념정리.md — "Data Definition Language(DDL): 데이터베이스 관리자, 설계자가 데이터베이스의 개념 스키마 명시 ... 내부&외부 스키마 정의" ↩︎
개념정리.md — "Data Manipulation Language(DML): retrievals = select, updates = insert, delete, update, embedded programming language" ↩︎
2장 데이터베이스 시스템 개념과 아키텍처.md — "독립형 쿼리 언어 인터페이스", "프로그래머 인터페이스", "사용자 친화적인 인터페이스: 메뉴 기반, 폼 기반, 그래픽 기반" ↩︎ ↩︎ ↩︎
개념정리.md — L166-171: "Non-procedural Languages ... 결과는 같지만 뭐가 먼저 나올지 모름 ... set(집합) 기반", "Low Level or Procedural Language ... 저장한 순서대로 그대로 실행" ↩︎ ↩︎
2장 데이터베이스 시스템 개념과 아키텍처.md — "개념적(고수준, 의미적) 데이터 모델: 사용자가 데이터를 인식하는 방식에 가까운 개념", "물리적(저수준, 내부) 데이터 모델: 컴퓨터에 데이터가 저장되는 방식에 대한 세부 정보 ... DBMS 설계 및 관리 매뉴얼을 통해 임시적으로 지정", "구현(표현) 데이터 모델: 상기 두 가지의 중간 ... 관계형 데이터 모델" ↩︎ ↩︎ ↩︎
개념정리.md — "Database Schema: 데이터베이스에 대한 기술, structure, data types, constraints 포함 ... 객체지향에서 클래스와 유사", "Schema Diagram: 데이터베이스 스키마를 도식화", "Schema Construct: 스키마의 각 객체", "Database State(=Database Instance): 특정 시간에 실제 데이터 ... 객체지향에서 객체와 유사", "Valid State: 데이터베이스의 구조와 제약조건을 충족한 상태", "데이터베이스 스키마는 거의 변화없음", "데이터베이스 상태는 계속 수정됨", "Schema = intension", "State = extension" ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
2장 데이터베이스 시스템 개념과 아키텍처.md — "초기 데이터베이스 상태: 시스템에 처음 로드될 때의 데이터베이스 상태" ↩︎
출처 매핑 미확인 — "3-schema architecture가 왜 데이터 독립성을 제공할 수 있는가를 설명하는 프레임"이라는 종합, "설계 시 이 관점을 유지하면 영향 범위를 스키마 계층으로 흡수할 수 있다"는 해석은 source 개별 사실을 엮은 Wiki 차원의 해석이다. ↩︎