논리적 데이터 독립성의 실제 경계

뷰가 지켜 주는 것은 “현재 계약”까지입니다

애플리케이션은 보통 테이블 자체가 아니라 외부 스키마인 VIEW를 바라봅니다. 따라서 개념 스키마가 바뀌더라도 뷰가 같은 의미를 유지할 수 있느냐가 핵심 판단 기준이 됩니다.

애플리케이션

직접 테이블을 읽지 않고, 필요한 필드 집합만 사용합니다.

user_view(name, email)

앱이 의존하는 논리적 계약면입니다.

users(id, name, email, ...)

테이블 구조와 관계가 바뀌는 지점입니다.

컬럼 추가

기존 구조를 유지한 채 확장

테이블 분할·병합

사용자가 보는 논리 구조 자체를 재편

개념 스키마 변화

phone 같은 새 컬럼을 추가

기존 컬럼과 테이블 관계는 그대로 남습니다.

테이블을 쪼개거나 합쳐 조인 구조가 달라짐

뷰가 기대하던 원본 테이블, 컬럼 위치, 관계가 함께 바뀝니다.

VIEW 영향

대체로 그대로 유지 가능

user_view가 새 컬럼을 선택하지 않으면 계약이 깨지지 않습니다.

재정의가 필요할 수 있음

같은 결과를 보여주려면 뷰 정의 자체를 다시 짜야 할 수 있습니다.

애플리케이션 영향

영향 최소화 가능

기존 필드 집합이 유지되므로 앱은 보통 수정 없이 계속 동작합니다.

연쇄 영향 가능

뷰, 질의, 필드 매핑, 비즈니스 로직까지 함께 손봐야 할 수 있습니다.

핵심 판단

논리적 데이터 독립성은 “개념 스키마가 바뀌어도 VIEW 계약을 유지할 수 있는 범위”에서만 자연스럽게 작동합니다. 그래서 물리적 독립성보다 실현이 더 어렵고, 현실에서는 완전 은닉보다 영향 최소화가 목표가 됩니다.