PK·FK·업무 식별자의 연결

핵심 요약

논리 식별자가 물리 PK와 FK로 구현되는 흐름과 식별·비식별 관계의 차이를 정리한다.

핵심 질문

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

학습 목표

• 주식별자, Primary Key와 Unique Key의 역할 차이를 설명한다.
• 식별 관계와 비식별 관계가 자식 식별자에 미치는 영향을 구분한다.

개념 지도

업무상 유일성 → 후보 식별자 → 주식별자 선택 → PK·FK 전파 → 변경 가능성 검증

핵심 내용

논리 모델의 주식별자는 물리 모델에서 보통 PRIMARY KEY로 구현된다. 부모의 PK를 참조하는 자식의 FOREIGN KEY는 참조 무결성을 지킨다. 업무상 유일하지만 PK로 선택되지 않은 후보키는 UNIQUE 제약으로 구현할 수 있다.

식별 관계에서는 부모 식별자가 자식의 주식별자 일부가 된다. 주문과 주문상세처럼 자식이 부모 없이 식별될 수 없는 경우가 대표적이다. 비식별 관계에서는 부모 식별자가 자식의 일반 속성으로 내려가고, 자식은 별도 주식별자를 가진다.

식별 관계가 지나치게 이어지면 PK와 이를 참조하는 FK가 길어져 조인과 변경 비용이 커진다. 반대로 모든 관계를 인조키 기반 비식별 관계로 바꾸면 중요한 업무 유일성 제약이 빠질 수 있다.

흔한 오해와 주의점

• FK는 참조 무결성 제약이며 자동으로 인덱스를 생성한다는 뜻이 아니다.
• UNIQUE와 PRIMARY KEY는 모두 유일성을 다루지만 PK는 테이블의 대표 식별자이고 NULL을 허용하지 않는다.
• 인조 PK를 사용해도 자연키의 업무 유일성 검증은 별도로 필요할 수 있다.

문항 풀이 보강: 식별 관계와 비식별 관계 선택

관계의 종류는 부모 키가 자식의 주식별자에 포함되는지로 판단한다.

주문(주문번호)
주문상세(주문번호 PK/FK, 상세순번 PK)  → 식별 관계

부서(부서번호)
사원(사원번호 PK, 부서번호 FK)         → 비식별 관계

비식별 관계를 고려하는 경우

• 부모 없이 자식이 독립적으로 생성·식별될 수 있다.
• 부모의 식별자가 자식 PK로 계속 전파되어 복합키가 지나치게 길어진다.
• 부모 키가 변경될 가능성이 있어 자식 PK의 안정성이 낮아진다.
• 여러 부모에게서 받은 키 때문에 PK가 복잡해지고 SQL 조인이 불편해진다.
• 부모와 자식의 생명주기가 다르고 관계가 선택적이다.

반대로 자식의 존재와 식별이 부모에 본질적으로 종속되고, 부모별 일련번호처럼 부모 키 없이는 유일성을 설명할 수 없다면 식별 관계가 자연스럽다.

주의할 점

비식별 관계로 바꾸어 인조 PK를 추가해도 부모 FK와 원래 업무키의 유일성 규칙을 삭제하면 안 된다. FK는 참조 무결성을 보장하지만 DBMS가 언제나 자동으로 FK 인덱스를 만들어 주는 것은 아니다.

문제에 적용하는 순서

1. 부모 PK가 자식 PK에 포함되는지 본다.
2. 자식이 부모 없이 식별·생성될 수 있는지 본다.
3. 키 전파 길이, 생명주기와 변경 가능성을 검토한다.
4. 인조키를 선택했다면 원래 업무 유일성 제약이 남아 있는지 확인한다.

부모·자식 DDL로 관계 확인하기

CREATE TABLE customer (
  customer_id NUMBER PRIMARY KEY,
  email       VARCHAR2(200) NOT NULL,
  CONSTRAINT customer_email_uk UNIQUE (email)
);

CREATE TABLE orders (
  order_id    NUMBER PRIMARY KEY,
  customer_id NUMBER NOT NULL,
  CONSTRAINT orders_customer_fk
    FOREIGN KEY (customer_id)
    REFERENCES customer(customer_id)
);

PK는 물리 구현의 대표 식별자이고, email은 업무 후보키를 Unique Constraint로 보존한다. FK는 자식 값이 부모의 Candidate Key를 참조하도록 해 관계 무결성을 보장한다.

식별 관계와 비식별 관계

주문상품 PK = (주문번호, 상품순번)
주문번호는 동시에 FK → 식별 관계

주문 PK = 주문번호
고객번호는 일반 FK       → 비식별 관계

부모가 삭제될 때 자식도 반드시 함께 사라져야 한다는 생명주기와, 부모 키가 자식 식별에 필요한지 여부를 구분한다. ON DELETE CASCADE는 편리하지만 대량 연쇄 삭제와 감사 요구를 검토한다.

FK Index의 역할

FK Constraint 자체는 자식 컬럼에 Index를 자동 생성하지 않는다. 부모 키 변경·삭제와 자식 Join이 빈번하면 FK Index가 Lock과 Access 비용에 중요할 수 있다. 하지만 FK 컬럼의 선택도가 낮고 관련 SQL이 없다면 무조건 추가하는 공식은 아니다.

업무 식별자 보존

인조 PK를 만들더라도 자연 업무키의 중복 허용 여부를 명시한다. PK 하나만 유일하고 동일한 사업자번호·계약번호 조합이 중복되면 모델은 업무 규칙을 보장하지 못한다.

사례를 판별하는 순서

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

모델 품질 확인표

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

마지막 점검

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

복습 문제

1. 주문상세 PK가 (주문번호, 순번)이면 어떤 관계의 특징인가?
2. 인조키를 추가한 뒤 기존 업무키에 필요한 제약은 무엇인가?
3. 이 개념을 실제 업무 사례에서 판별할 수 있는가?
4. 한 행의 업무 의미와 식별자를 설명할 수 있는가?