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

핵심 요약

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

학습 목표

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

본문

개념 지도

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

핵심 내용

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

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

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

부모·자식 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 하나만 유일하고 동일한 사업자번호·계약번호 조합이 중복되면 모델은 업무 규칙을 보장하지 못한다.

시험 포인트

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

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

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

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

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

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

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

주의할 점

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

문제에 적용하는 순서

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

자주 틀리는 부분

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