스키마는 데이터 모델을 바탕으로 DB의 구조를 기술한 것이다. 설계할 때 정해지고 한 번 정해지면 자주 바뀌지 않는다. 3단계 스키마 아키텍처는 그 스키마를 세 층으로 나눠 쌓는 방식이다.
저장 구조와 애플리케이션의 분리
물리적 저장 구조는 성능 때문에 조금씩 바뀐다. 인덱스를 추가하거나 저장 방식을 바꾼다. 그때마다 그 DB를 쓰는 모든 애플리케이션을 고쳐야 한다면 감당이 안 된다. 사용자 애플리케이션을 물리적인 DB로부터 떼어놓으려고 층을 나눈다.
외부, 개념, 내부 세 층
| 단계 | 스키마 | 무엇을 기술하나 |
|---|---|---|
| 외부 | 외부 스키마 | 개별 사용자가 보는 부분 |
| 개념 | 개념 스키마 | DB 전체의 논리적 구조 |
| 내부 | 내부 스키마 | 물리적으로 저장되는 방식 |
내부 스키마는 물리적 저장 장치에 가장 가깝다. 저장 구조, 데이터 구조, 접근 경로처럼 실체가 있는 것을 기술하고 물리적 데이터 모델로 표현한다. 외부 스키마는 실제 사용자가 바라보는 곳이라서, 사용자마다 필요한 데이터만 보여주고 나머지는 숨긴다. 개념 스키마는 내부 스키마를 한 번 추상화해 DB 전체 구조를 기술하되 물리적 저장 방식은 감춘다. 외부와 개념은 둘 다 논리적 데이터 모델로 표현한다.
가운데 층은 처음부터 있던 것이 아니다. 초창기 아키텍처에는 내부와 외부 둘뿐이었는데, 사용자마다 필요한 데이터가 달라지면서 내부 레벨에 중복 데이터가 쌓이고 데이터가 서로 어긋나기 시작했다. 그래서 개념 스키마가 끼어들었다.
층 사이의 독립성
각 층 사이에 대응 관계만 유지하면 아래층이 바뀌어도 위층은 그대로 둘 수 있다. 저장 방식을 바꿔도 논리적 구조는 그대로고, 논리적 구조를 조금 바꿔도 사용자 뷰는 그대로다. 다만 개념 스키마가 바뀔 때 외부 스키마를 지켜내는 쪽은 상대적으로 까다롭다. 대부분의 DBMS가 세 수준을 완벽하게 갈라놓지도 않는다. 어느 쪽이든 실제 데이터가 있는 곳은 내부 레벨뿐이고, 나머지 둘은 구조를 표현할 뿐이다.
스키마와 상태
스키마와 상태는 다르다. 상태(state)는 특정 시점에 DB에 실제로 들어 있는 데이터이고 스냅샷이라고도 한다. 이것은 계속 바뀐다. 테이블 정의가 스키마고, 그 안의 행들이 상태다.
다른 자리에서 같은 해법
같은 발상이 애플리케이션에서는 레이어드 아키텍처로, 자바에서는 인터페이스로 나타난다. 바뀌는 것과 바뀌지 않는 것 사이에 층을 하나 두는 것이 공통된 해법이다.