식별자 분류와 주식별자 조건

핵심 요약

식별자의 여러 분류 축과 주식별자가 갖춰야 할 유일성·최소성·불변성·존재성을 익힌다.

핵심 질문

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

학습 목표

• 주·보조, 내부·외부, 단일·복합, 본질·인조 식별자를 구분한다.
• 좋은 주식별자의 조건을 사례에 적용한다.

개념 지도

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

핵심 내용

식별자는 엔터티의 각 인스턴스를 서로 구별하는 속성 집합이다. 분류 기준은 서로 독립적이다.

주식별자는 유일성, 꼭 필요한 속성만 포함하는 최소성, 값이 자주 바뀌지 않는 불변성, 반드시 값이 있는 존재성을 만족해야 한다. 주민등록번호처럼 업무 의미가 있더라도 변경·보안·정책 위험이 크면 별도의 고객번호를 인조식별자로 선택할 수 있다.

흔한 오해와 주의점

• 후보키는 유일성과 최소성을 만족하며, 그중 대표로 선택한 것이 주식별자다.
• 대체키와 인조식별자는 항상 같은 뜻으로 쓰이지 않는다. 분류 기준을 확인한다.
• 복합식별자의 일부 속성만으로 인스턴스를 유일하게 찾을 수 있다면 최소성이 깨진다.

문항 풀이 보강: 주식별자 도출 절차

식별자 문제는 “유일한가?”만 확인하면 오답이 되기 쉽다.

1. 모든 인스턴스를 유일하게 구분한다.
2. 유일성을 만족하는 최소 속성만 남긴다.
3. 값이 NULL이 아니고 생성 시점부터 존재한다.
4. 업무에서 자주 사용되고 값이 자주 바뀌지 않는다.
5. 이름·설명처럼 길고 변경 가능성이 큰 속성은 피한다.

사번과 주민등록번호가 모두 유일할 수 있어도 대표성과 안정성·보안을 고려해 사번을 주식별자로, 주민등록번호를 보조식별자로 둘 수 있다.

분류 축을 섞지 않기

• 다른 엔터티에서 상속받았으면 외부식별자, 자신이 만든 속성이면 내부식별자다.
• 속성 하나면 단일식별자, 둘 이상이면 복합식별자다.
• 업무에서 본래 존재하면 본질식별자, 편의를 위해 새 번호를 만들면 인조식별자다.

한 식별자가 동시에 주식별자·내부식별자·단일식별자·인조식별자일 수 있다. 이 분류들은 서로 배타적인 한 줄 선택지가 아니라 서로 다른 축이다.

식별자 선택을 잘못했을 때의 영향

주식별자는 단순히 현재 중복이 없는 컬럼이 아니라, 엔터티의 전체 생명주기 동안 각 인스턴스를 안정적으로 구분해야 합니다.

후보 1: 주민등록번호  → 유일성이 높지만 정정·보안·마스킹 요구가 큼
후보 2: 고객번호      → 업무 의미는 적지만 변경 가능성이 낮고 참조가 단순함
후보 3: 이메일        → 변경 가능하고 공유·중복 정책에 따라 유일성이 흔들림

고객번호를 PK로 선택하더라도 주민등록번호나 이메일의 업무상 중복 금지 규칙이 필요하면 UNIQUE 제약을 별도로 둡니다. 인조 식별자를 도입했다고 자연 업무키의 검증 책임이 사라지는 것은 아닙니다.

판별 순서

1. 후보 식별자의 유일성을 현재 데이터가 아니라 업무 규칙으로 확인합니다.
2. NULL 허용 여부와 값이 생성되는 시점을 확인합니다.
3. 값 변경 시 자식 FK·외부 Interface·이력에 미치는 영향을 계산합니다.
4. 복합 식별자가 지나치게 길다면 인조 PK와 업무키 UNIQUE를 함께 검토합니다.
5. 식별 관계로 자식 PK에 전파할지, 비식별 FK로만 참조할지 생명주기로 결정합니다.

사례를 판별하는 순서

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

모델 품질 확인표

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

주식별자 선택 사례

주문상품의 후보 식별자를 비교해 봅니다.

후보 A: 주문번호 + 상품순번
후보 B: 주문상품ID(Sequence)
후보 C: 주문번호 + 상품코드

주문번호 + 상품코드는 같은 상품을 한 주문에 두 줄로 담을 수 있다면 유일하지 않습니다. 주문번호 + 상품순번은 업무적으로 Row를 식별하지만 여러 자식 Table의 FK가 복합화됩니다. 주문상품ID는 단순하고 안정적인 인조 식별자가 될 수 있지만, 업무 중복을 막기 위한 UNIQUE(주문번호, 상품순번) 같은 별도 제약이 필요합니다.

CREATE TABLE order_item (
  order_item_id NUMBER       PRIMARY KEY,
  order_id      NUMBER       NOT NULL,
  line_no       NUMBER       NOT NULL,
  product_id    NUMBER       NOT NULL,
  CONSTRAINT order_item_uk UNIQUE (order_id, line_no)
);

좋은 주식별자는 현재 유일성뿐 아니라 NULL 불가, 최소성, 값의 안정성, 하위 관계 전파 비용을 함께 만족해야 합니다. 전화번호·이메일처럼 변경 가능한 속성을 PK로 선택하면 변경이 FK까지 전파될 수 있으므로 업무 식별자와 기술적 PK를 분리할지 판단합니다.

마지막 점검

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

복습 문제

1. 변경 가능성이 큰 전화번호가 주식별자로 부적합한 이유는?
2. 다른 엔터티의 식별자를 상속받아 만든 식별자는 내부인가 외부인가?
3. 이 개념을 실제 업무 사례에서 판별할 수 있는가?
4. 한 행의 업무 의미와 식별자를 설명할 수 있는가?