3층 스키마(3-level schema)는 데이터베이스의 구조를 외부·개념·내부 세 층으로 나눠 적는 방식입니다. 사용자가 보는 외부 스키마, 전체 구조인 개념 스키마, 저장 방식인 내부 스키마로 나눠 두면, 아래 층이 바뀌어도 위 층이 그대로인 데이터 독립성이 생깁니다.
데이터베이스의 구조를 적은 것을 스키마(schema)라 합니다. 앞 레슨의 개념·논리·물리 모델이 데이터베이스를 만들기까지의 단계라면, 3층 스키마는 만들어 둔 데이터베이스를 누가 어떻게 보는가의 이야기입니다. 급여 담당은 사번·이름·월급만, 조직도 담당은 이름과 부서명만 봅니다. 이 화면들과 테이블 전체, 저장 방식을 한 덩어리로 적으면 저장 방식만 바꿔도 화면 프로그램을 모두 고쳐야 해서, 세 층으로 나눠 적습니다.
1외부·개념·내부 스키마
외부 스키마(external schema)는 사용자와 응용 프로그래머가 저마다 보는 부분이라, 급여 담당과 조직도 담당처럼 여러 개일 수 있습니다. 뷰(VIEW — 필요한 부분만 골라 보여 주는 가상의 테이블)로 만들 수 있습니다.
개념 스키마(conceptual schema)는 EMP·DEPT의 모든 열과 관계, 제약 조건을 담은 데이터베이스 전체의 논리 구조로, 하나뿐입니다. 앞 레슨의 개념 모델과는 이름만 비슷한 다른 말입니다. 개념 모델은 엔터티와 관계만 그린 설계의 첫 단계입니다.
내부 스키마(internal schema)는 데이터를 저장 장치에 어떻게 두는지 적은 것으로, 역시 하나뿐입니다. 데이터 파일과 인덱스가 여기에 듭니다.
| 층 | 담는 것 | 이 회사에서는 | 몇 개 |
|---|---|---|---|
| 외부 | 사용자마다 쓰는 부분 | 급여 담당의 EMPNO·ENAME·SAL | 여럿 |
| 개념 | 전체 논리 구조 | EMP·DEPT의 열·관계·제약 조건 | 하나 |
| 내부 | 저장 방식 | 데이터 파일, 인덱스 | 하나 |
2물리적·논리적 데이터 독립성
EMP에 DEPTNO 순 인덱스를 더하면 내부 스키마만 바뀝니다. 인덱스는 찾는 길을 하나 더 내는 것이라 테이블의 열도, 급여 담당이 보는 세 열도 그대로입니다. 이처럼 저장 쪽이 바뀌어도 위 두 층이 영향을 받지 않는 성질을 물리적 데이터 독립성(physical data independence)이라 합니다.
이번에는 EMP에 입사일 열 HIREDATE를 더해 개념 스키마를 바꿉니다. 급여 담당의 뷰는 처음부터 세 열만 골랐으므로 그대로입니다. 테이블의 짜임이 바뀌어도 사용자가 보는 층이 그대로인 성질이 논리적 데이터 독립성(logical data independence)입니다.
층과 층 사이를 잇는 것을 사상(mapping)이라 합니다. 외부와 개념 사이가 논리적 사상, 개념과 내부 사이가 물리적 사상입니다. 아래 층이 바뀌어도 그 위의 사상만 맞춰 주면 위 층은 바뀌지 않습니다.
| 독립성 | 바뀌는 층 | 그대로인 층 | 이 회사의 예 |
|---|---|---|---|
| 물리적 | 내부 | 개념·외부 | DEPTNO 인덱스를 더함 |
| 논리적 | 개념 | 외부 | HIREDATE 열을 더함 |
예제
SQL(데이터베이스에 데이터를 묻고 바꾸는 언어) 문장은 2과목에서 배웁니다. 여기서는 결과가 그림과 같은지만 보면 됩니다.
아래 문장은 급여 담당의 뷰 EMP_PAY(외부 스키마)를 만든 뒤 인덱스(내부)와 열(개념)을 더하고, 마지막 SELECT로 뷰를 다시 봅니다.
CREATE VIEW EMP_PAY AS
SELECT EMPNO,
ENAME,
SAL
FROM EMP;
CREATE INDEX EMP_DEPTNO_IX
ON EMP (DEPTNO);
ALTER TABLE EMP
ADD (HIREDATE DATE);
SELECT *
FROM EMP_PAY
ORDER BY EMPNO;
| EMPNO | ENAME | SAL |
|---|---|---|
| 1001 | 김민준 | 520 |
| 1002 | 이서연 | 380 |
| 1003 | 박지호 | 410 |
| 1004 | 최유나 | 450 |
| 1005 | 정하늘 | 300 |
| 1006 | 강도윤 | 470 |
SELECT *는 모든 열을 달라는 문장인데도 뷰가 고른 세 열만 나옵니다. 아래 두 층이 바뀌어도 외부 스키마는 그대로입니다.
CREATE VIEW·CREATE INDEX·ALTER TABLE은 모두 DDL(테이블 같은 구조를 만들고 고치는 SQL 문장)입니다. ALTER TABLE은 DDL 레슨에서 자세히 봅니다.
시험 포인트
- 외부 스키마는 사용자마다 있어 여러 개일 수 있고, 개념 스키마와 내부 스키마는 하나뿐입니다. 외부 스키마는 뷰로 만들 수 있고, 인덱스는 내부 스키마에 듭니다.
- '핵심 엔터티와 관계만 담는다'는 개념 모델의 설명입니다. 개념 스키마 보기에 이 말이 붙으면 함정입니다.
- 자료에 따라 3층 스키마를 3단계 스키마라고도, 이 구조를 제안한 미국 표준 위원회의 이름을 따 ANSI-SPARC 3단계 구조라고도 부릅니다. 어느 이름으로 나와도 같은 것입니다.
- 자료에 따라 외부 스키마를 사용자 관점, 개념 스키마를 설계자 관점이나 통합 관점, 내부 스키마를 개발자 관점이나 시스템 프로그래머 관점이라고도 부릅니다. 어느 이름으로 나와도 같은 층을 가리킵니다. 내부 스키마의 개발자는 저장 구조를 다루는 시스템 프로그래머이고, 화면·업무 프로그램을 짜는 응용 프로그래머는 외부 스키마를 봅니다.
- 물리적 독립성은 내부 스키마가, 논리적 독립성은 개념 스키마가 바뀌는 경우입니다. 바뀌는 층을 서로 바꿔 놓은 보기가 함정입니다.
- 외부-개념 사이는 논리적 사상, 개념-내부 사이는 물리적 사상입니다.
확인 문제
1. 다음 쿼리의 마지막 SELECT는 어떤 결과를 낼까요? 그렇게 되는 까닭을 데이터 독립성으로 설명해 보세요.
CREATE VIEW EMP_PAY AS
SELECT EMPNO,
ENAME,
SAL
FROM EMP;
ALTER TABLE EMP
ADD (EMAIL VARCHAR2(40));
SELECT ENAME,
EMAIL
FROM EMP_PAY;
정답
ORA-00904(invalid identifier) 오류가 납니다. EMP에 EMAIL 열을 더한 것은 개념 스키마의 변경입니다. 뷰 EMP_PAY는 외부 스키마이고, 만들 때 고른 EMPNO·ENAME·SAL 세 열 그대로라 EMAIL이 없습니다. 개념 스키마가 바뀌어도 외부 스키마가 그대로인 논리적 데이터 독립성 때문입니다. EMAIL까지 보려면 뷰를 다시 만들어 외부 스키마를 바꿔야 합니다.
2. 이 회사 데이터베이스에 다음 일이 생겼습니다. 각각 어느 스키마가 바뀐 것이고, 다른 층은 어떻게 될까요?
- (가) EMP를 담은 데이터 파일을 더 빠른 디스크로 옮긴다.
- (나) DEPT에 전화번호 열 TEL을 더한다.
- (다) 급여 담당의 뷰에 DEPTNO 열을 더해 다시 만든다.
정답
- (가) 내부 스키마입니다. 테이블과 뷰가 그대로이니 물리적 데이터 독립성입니다.
- (나) 개념 스키마입니다. TEL을 고르지 않은 뷰는 그대로이니 논리적 데이터 독립성입니다.
- (다) 외부 스키마 자체가 바뀌어 급여 담당에게 열이 넷 보입니다. 아래 층이 바뀐 일이 아니라 독립성의 예가 아닙니다.
3. "개념 스키마는 개념 모델과 같은 말이라 엔터티와 관계만 담는다." 어디가 틀렸는지 EMP·DEPT로 설명해 보세요.
정답
개념 스키마에는 EMP·DEPT의 열과 기본키·외래키 같은 제약 조건까지 들어 있습니다. 엔터티와 관계만 그리는 것은 설계 첫머리의 개념 모델이라, 이름만 닮은 서로 다른 말입니다.