데이터 독립성과 3단계 스키마

핵심 요약

외부·개념·내부 스키마를 구분하고 논리적·물리적 데이터 독립성을 연결한다.

핵심 질문

1. 데이터 독립성과 3단계 스키마를 실제 업무 사례에서 어떤 기준으로 판별하는가?
2. 한 행이 나타내는 업무 사실과 유일성·필수성·변경 가능성은 무엇인가?
3. 잘못 모델링하면 어떤 중복·이상 현상·변경 영향이 발생하는가?
4. 여러 설계안 중 업무 의미와 변경 용이성을 가장 잘 보존하는 안을 어떻게 고르는가?

학습 목표

• ANSI/SPARC의 외부·개념·내부 스키마를 구분한다.
• 논리적 데이터 독립성과 물리적 데이터 독립성의 차이를 설명한다.

개념 지도

업무 범위 → 핵심 대상 → 개념 모델 → 논리 모델 → 물리 구현

핵심 내용

3단계 스키마는 사용자 관점과 전체 논리 구조, 물리 저장 구조를 분리한다.

논리적 데이터 독립성은 개념 스키마가 바뀌어도 외부 스키마와 프로그램의 영향을 줄이는 성질이다. 물리적 데이터 독립성은 인덱스나 저장 구조가 바뀌어도 개념 스키마가 유지되는 성질이다.

흔한 오해와 주의점

• 물리적 데이터 독립성은 외부와 개념 사이가 아니라 개념과 내부 사이의 독립성이다.
• 외부 스키마는 사용자마다 여러 개 존재할 수 있지만 개념 스키마는 통합 관점이다.
• 데이터 독립성은 변경 영향도를 0으로 만든다는 뜻이 아니라 계층 간 결합을 낮춘다는 뜻이다.

문항 풀이 보강: 스키마와 독립성 연결표

사용자별 화면·View          외부 스키마
조직 전체 엔터티·관계·제약  개념 스키마
파일·블록·인덱스·저장 위치  내부 스키마

외부 스키마는 사용자나 응용 프로그램별로 여러 개 존재할 수 있다. 개념 스키마는 이 관점들을 통합한 조직 전체의 논리 구조이며, 내부 스키마는 저장 장치에 어떻게 배치되는지를 표현한다.

문제의 “모든 사용자 관점을 통합한 조직 전체 관점”이라는 문장은 개념 스키마의 대표 단서다. “물리 저장 구조를 바꾸어도 응용 프로그램이 영향받지 않음”은 물리적 독립성이다.

두 종류의 독립성을 변경 사례로 확인하기

내부 스키마 변경
Heap Table → Partitioned Table, Index 추가, Tablespace 이동
논리 스키마의 고객·주문 속성과 응용 View는 유지
→ 물리적 데이터 독립성

논리 스키마 변경
고객 주소를 고객 테이블에서 주소 이력 엔터티로 분리
기존 화면에는 호환 View를 제공해 프로그램 Interface 유지
→ 논리적 데이터 독립성

물리적 독립성은 저장 구조 변경으로부터 개념 스키마를 보호하고, 논리적 독립성은 개념 스키마 변경으로부터 외부 스키마와 응용 프로그램을 보호합니다. 일반적으로 논리적 독립성이 더 어렵습니다. 업무 의미가 바뀌면 외부 View와 프로그램의 결과 의미까지 함께 바뀔 수 있기 때문입니다.

시험에서의 판단 기준

• 파일 배치·Index·압축·Partition 변화는 내부 스키마 쪽입니다.
• 엔터티·속성·관계·제약 변화는 개념 스키마 쪽입니다.
• 사용자별 화면·View·보고서 구조는 외부 스키마 쪽입니다.
• “하위 계층 변경이 상위 계층에 영향을 주지 않는다”는 방향으로 독립성을 읽습니다.

사례를 판별하는 순서

1. 모델이 표현해야 하는 업무 사실과 행 단위(Grain)를 한 문장으로 정의합니다.
2. 각 인스턴스를 유일하게 식별할 수 있는 후보와 변경 가능성을 확인합니다.
3. 속성이 어느 사실에 종속되는지와 관계의 필수성·카디널리티를 확인합니다.
4. 중복 저장으로 삽입·갱신·삭제 이상이 생기는지 검토합니다.
5. 물리 성능을 이유로 구조를 바꿀 때 원천 데이터와 동기화·복구 규칙을 함께 설계합니다.

모델 품질 확인표

• 같은 업무 사실이 여러 곳에 중복 저장되지 않는가?
• 이름과 도메인이 한 가지 의미로 사용되는가?
• PK·FK가 실제 업무 관계와 선택성을 정확히 표현하는가?
• 현재 화면이나 프로세스에 과도하게 종속되지 않는가?
• 정규화와 성능 설계의 이유를 측정 가능한 근거로 설명할 수 있는가?

변경 영향으로 데이터 독립성 판단하기

논리적 데이터 독립성은 개념 스키마가 바뀌어도 외부 스키마와 Application 변경을 최소화하는 성질입니다. 물리적 데이터 독립성은 Index·Partition·저장 위치 같은 내부 스키마가 바뀌어도 개념·외부 스키마가 유지되는 성질입니다.

-- 개념 스키마 변경을 기존 외부 계약에서 숨기는 View 예시
CREATE VIEW customer_api_v AS
SELECT customer_id,
       last_name || first_name AS customer_name
FROM   customer;

문제에서는 “무엇이 바뀌었는가”와 “어느 상위 계층을 그대로 유지하려는가”를 먼저 적습니다. Index 추가를 논리적 독립성으로, Column 분할을 물리적 독립성으로 뒤집어 고르는 실수를 주의합니다.

마지막 점검

• 화면의 입력 항목이나 현재 프로세스를 그대로 엔터티·관계로 옮기지 않습니다.
• 한 행의 업무 사실, 후보 식별자와 함수 종속성을 먼저 확정합니다.
• 중복과 비일관성을 만들면서 조회 편의만 얻는 설계를 정답으로 선택하지 않습니다.
• 반정규화와 물리 설계는 측정된 성능 문제와 동기화·복구 대책이 있을 때 적용합니다.

복습 문제

1. 인덱스를 추가했는데 애플리케이션 SQL 의미가 그대로라면 어떤 독립성인가?
2. 사용자별 View는 어느 스키마에 해당하는가?
3. 이 개념을 실제 업무 사례에서 판별할 수 있는가?
4. 한 행의 업무 의미와 식별자를 설명할 수 있는가?