논리-물리 모델 변환

핵심 요약

논리 모델의 엔터티는 보통 테이블, 속성은 컬럼, 식별자는 PK·UK, 관계는 FK로 변환된다. 그러나 이 규칙만으로는 충분하지 않다. 관계의 선택성·삭제 규칙, 서브타입 구현, 이력의 현재행·기간 제약, 코드값 통제, 파생값 저장 여부를 DBMS가 강제할 수 있는 형태로 구체화해야 한다. 변환 결과가 논리 의미를 잃지 않았는지 논리-물리 매핑표와 DDL 대조로 확인한다.

학습 목표

• 논리 요소를 테이블·컬럼·키·제약으로 변환한다.
• 1:N, M:N, 1:1, 재귀 관계의 FK 배치와 제약을 설계한다.
• 서브타입의 대표 물리 구현 전략과 장단점을 비교한다.
• 이력·코드·파생 속성의 변환과 추적성 문서를 작성한다.

1. 기본 변환 원칙

1.1 엔터티와 속성

논리 속성 하나가 물리 컬럼 여러 개로 분해될 수 있다. 예를 들어 논리적 주소를 우편번호·기본주소·상세주소로 구현하거나, 금액을 금액값과 통화코드로 구현할 수 있다. 반대로 여러 논리적 플래그를 하나의 비트마스크 컬럼에 압축하면 의미·제약·조회성이 약해질 수 있으므로 변환 사유가 필요하다.

1.2 데이터 타입 매핑

논리 도메인의 의미를 먼저 정한 뒤 DBMS 타입을 선택한다.

• 금액: 범위·소수점·반올림을 고려한 정확 숫자형
• 일자와 시각: 일자만 필요한지, 시간대가 필요한지 구분
• 코드: 허용값·길이·문자 비교 규칙과 일치
• 긴 텍스트·바이너리: 최대 크기, 검색 여부, 외부 저장 여부
• 식별자: 값 범위·생성량·외부 연계 형식 고려

VARCHAR(4000)처럼 넉넉한 길이를 일괄 적용하면 도메인 검증이 약해지고 행 길이·인덱스·전환에 영향을 줄 수 있다.

2. 관계 변환 패턴

2.1 1:N 관계

부모 PK를 자식의 FK로 둔다.

고객 1 ─── N 주문

CUSTOMER(CUSTOMER_ID PK, ...)
ORDERS(ORDER_ID PK, CUSTOMER_ID FK, ...)

• 자식이 반드시 부모를 가져야 하면 FK 컬럼을 NOT NULL로 설계한다.
• 부모 삭제 시 RESTRICT, CASCADE, SET NULL 중 어떤 의미가 맞는지 업무 규칙으로 결정한다.
• 식별 관계라면 부모키가 자식 PK 일부에 포함될 수 있다.

2.2 M:N 관계

교차·연관 엔터티를 테이블로 변환해 두 개의 1:N 관계로 해소한다.

주문 M ─── N 상품
      ↓
주문라인(주문번호 PK/FK, 라인순번 PK, 상품번호 FK, 수량, 거래단가)

단순히 (주문번호, 상품번호)를 PK로 두면 같은 상품을 한 주문에 여러 라인으로 담을 수 없는지 확인해야 한다. 논리 식별자와 업무 반복 규칙에 따라 라인순번 또는 별도 식별자를 선택한다.

2.3 1:1 관계

FK를 어느 쪽에 둘지는 다음을 고려한다.

• 어느 쪽이 생명주기상 종속되는가?
• 어느 쪽 참여가 선택/필수인가?
• 함께 조회·생성되는가?
• 보안·성능·변경주기가 다른가?

FK에는 UNIQUE를 추가해야 1:N으로 확장되는 것을 막을 수 있다.

회원 1 ─── 0..1 회원민감정보
MEMBER_SENSITIVE(
  MEMBER_ID PK/FK,
  ...
)

민감정보가 회원 없이 존재할 수 없고 회원당 최대 한 건이면 자식 PK를 동시에 FK로 사용하는 방식이 자연스럽다.

2.4 재귀 관계

조직의 상위조직 관계는 같은 테이블을 참조하는 FK로 변환할 수 있다.

ORGANIZATION(
  ORG_ID PK,
  PARENT_ORG_ID FK NULL REFERENCES ORGANIZATION(ORG_ID)
)

최상위 조직은 부모가 없으므로 NULL을 허용할 수 있다. 자기 자신 참조 금지, 순환 금지, 최대 깊이 같은 규칙은 일반 FK만으로 모두 보장되지 않을 수 있다.

3. 서브타입 변환 전략

논리 서브타입이 있다고 특정 전략이 자동 결정되지 않는다. 유형 수, NULL 비율, 공통 조회, FK 참조, 유형 전환, 제약 구현 가능성을 비교한다.

예: 슈퍼+서브 테이블

CUSTOMER(
  CUSTOMER_ID PK,
  CUSTOMER_TYPE_CODE NOT NULL,
  CUSTOMER_NAME NOT NULL
)

PERSON_CUSTOMER(
  CUSTOMER_ID PK/FK REFERENCES CUSTOMER,
  BIRTH_DATE NOT NULL
)

CORPORATE_CUSTOMER(
  CUSTOMER_ID PK/FK REFERENCES CUSTOMER,
  CORPORATE_REG_NO NOT NULL UNIQUE
)

추가로 CUSTOMER_TYPE_CODE='P'이면 개인 테이블 행만 존재해야 한다는 배타·완전 규칙을 구현해야 한다.

4. 특수 논리 구조의 변환

4.1 이력

기간 이력은 업무키와 유효시작을 키로 사용하거나 별도 버전 식별자를 둘 수 있다.

CONTRACT_TERM_HISTORY(
  CONTRACT_ID,
  VALID_FROM,
  VALID_TO,
  RATE,
  PRIMARY KEY(CONTRACT_ID, VALID_FROM),
  CHECK(VALID_FROM < VALID_TO)
)

PK와 CHECK만으로 기간 중복이 모두 방지되는 것은 아니다. 제품 기능 또는 트랜잭션 검증이 추가로 필요할 수 있다.

4.2 코드

코드가 자주 바뀌고 명칭·유효기간·분류 같은 속성을 가지면 코드 테이블과 FK로 구현한다. 값이 매우 안정적이고 소수이며 시스템 전역에서 동일하다면 CHECK 제약을 검토할 수 있으나 변경 배포 방식까지 고려한다.

4.3 파생값

• 조회 시 계산: 원천과 항상 일치하지만 계산 비용 발생
• 뷰·계산 컬럼: 식을 중앙화하되 제품 지원 차이 존재
• 저장 컬럼: 읽기는 빠르지만 갱신·재계산·오류 복구 규칙 필요
• 요약 테이블: 대량 집계에 유리하지만 갱신 지연과 재생성 필요

저장 파생값은 반정규화에 해당할 수 있으므로 82600043의 근거·통제 기준을 적용한다.

5. 논리-물리 매핑표

이 표는 DDL 생성 후 역대조 기준이 된다. 논리 요소가 매핑되지 않거나 물리 객체에 대응 논리 근거가 없으면 검토 대상이다.

6. 변환 검증 흐름

논리 객체 목록 확정
  ↓
명명·타입·NULL·기본값 매핑
  ↓
주·대체 식별자와 관계를 PK·UK·FK로 변환
  ↓
M:N·1:1·재귀·서브타입·이력 전략 선택
  ↓
파생값·코드·업무 무결성 구현 위치 결정
  ↓
논리-물리 매핑표 작성
  ↓
DDL·샘플 데이터·삭제/변경 시나리오로 의미 보존 검증

시험 판단 포인트

• 1:N 관계의 FK는 일반적으로 N쪽에 배치하며 필수 관계는 FK NULL 허용과 함께 확인한다.
• 1:1 관계는 FK에 유일성 제약이 없으면 물리적으로 1:N이 될 수 있다.
• M:N 관계는 연관 테이블로 해소하고 관계 자체의 속성을 그 테이블에 둔다.
• 대체식별자는 논리 모델에서 사라지지 않으며 UK나 별도 업무 통제로 구현한다.
• 서브타입의 논리 제약과 물리 구현 전략을 구분한다.
• 변환 완료 여부는 테이블 수가 아니라 논리 규칙의 보존과 매핑 추적성으로 판단한다.

자주 틀리는 부분

• 주식별자만 PK로 옮기고 대체식별자의 유일성 규칙을 빠뜨린다.
• 선택 관계인데 FK를 무조건 NOT NULL로 지정하거나, 필수 관계인데 NULL을 허용한다.
• 1:1 FK에 UNIQUE를 두지 않아 여러 자식 행이 허용된다.
• 서브타입을 단일 테이블로 합치면서 유형별 필수 속성 제약을 모두 제거한다.
• 코드명만 저장하고 코드 식별값·유효성·참조 규칙을 관리하지 않는다.