식별자

식별자는 엔터티 인스턴스를 유일하게 구별합니다. 주식별자는 유일성·최소성·불변성·존재성을 만족하고 업무에서 대표성을 가져야 합니다.

식별자(Identifier)는 엔터티 안의 인스턴스를 서로 구별하는 속성 또는 속성의 조합입니다. 현실에서는 별명이 같아도 대상이 다를 수 있으므로, 업무에서 중복되지 않는 구분 기준이 필요합니다. 데이터 모델의 주식별자는 물리적인 관계형 테이블에서 보통 기본키(Primary Key, PK)로 구현합니다.

공유 자전거 운영 서비스에 ‘초록이’라는 별명의 자전거가 두 대 있다고 해 봅시다. 별명만으로는 어느 자전거인지 알 수 없습니다. 대신 운영 시스템이 발급한 BIKE_ID 101과 102를 쓰면 두 대를 정확히 구분할 수 있습니다.

인스턴스는 자전거 한 대에 해당하는 행이고, BIKE_ID는 그 행을 식별합니다. FRAME_NO처럼 업무상 고유성이 보장되는 다른 값도 식별자 후보가 될 수 있으며, 어떤 후보를 대표 식별자로 고를지는 설계 판단입니다.

주식별자는 유일성·최소성·불변성·존재성을 만족하도록 선정합니다. 시험에서는 조건의 이름을 뜻과 연결하거나, 적절하지 않은 주식별자 설명을 고르게 하는 유형이 자주 나옵니다. 네 조건은 유·최·불·존으로 기억합니다. 엔터티를 대표해 다른 엔터티와 참조 관계를 맺을 수 있어야 한다는 대표성도 함께 설명하기도 합니다.

최소성은 문자열이 짧아야 한다는 뜻이 아니라, 유일성을 보장하는 데 필요하지 않은 속성을 포함하지 않는다는 뜻입니다. 불변성은 키 값이 업무 과정에서 가능하면 바뀌지 않아야 한다는 뜻입니다. 또 DBMS의 PRIMARY KEY 제약은 유일성과 NOT NULL을 강제하지만, 최소성과 불변성까지 자동으로 보장하지는 않습니다. PK 값을 바꾸는 SQL 자체가 원천적으로 금지되는 것도 아닙니다.

식별자의 분류 축은 서로 독립적입니다. 예를 들어 주문번호는 주식별자이면서 내부·단일·인조 식별자일 수 있습니다.

식별자는 하나의 기준으로만 나누지 않습니다. 대표성, 생성 위치, 구성 속성의 수, 업무에서 도출됐는지 여부라는 서로 다른 네 관점으로 분류합니다. 예를 들어 BIKE_ID는 주식별자이면서 내부식별자·단일식별자·인조식별자일 수 있습니다.

주식별자는 엔터티를 대표하도록 선택한 키이고, 보조식별자는 대표로 채택하지 않았지만 인스턴스를 구별할 수 있는 다른 후보입니다. 이 예시는 자전거 프레임번호가 서비스 안에서 중복되지 않는다는 업무 규칙을 가정합니다. 그래서 FRAME_NO를 NOT NULL UNIQUE로 관리해 보조식별자로 활용합니다.

외부식별자는 부모 엔터티에서 가져온 키로, 물리 모델에서 보통 외래키(Foreign Key, FK)로 표현합니다. 다만 FK는 다른 테이블의 기본키뿐 아니라 적절한 고유키도 참조할 수 있으며, 자식의 FK가 반드시 자식 PK의 일부인 것은 아닙니다.

식별 관계에서는 부모의 주식별자가 자식 주식별자의 구성 요소가 됩니다. 비식별 관계에서는 부모 식별자가 자식의 일반 외래키로 전달되며 자식 주식별자에는 포함되지 않습니다.

관계 유형은 자식의 존재와 식별이 부모에게 의존하는지, 부모 키 변경이 자식에 미치는 영향이 어느 정도인지를 함께 보고 결정합니다.

예를 들어 부모 키 TECH_ID가 프로젝트배정의 복합 기본키 (TECH_ID, PROJECT_ID)에 포함되면 식별 관계입니다. 고객센터 문의 테이블이 독립된 기본키 TICKET_ID를 쓰고 CUSTOMER_ID는 일반 외래키로만 두면 비식별 관계입니다.

비식별 관계라고 해서 자식이 부모 없이 존재할 수 있는 것은 아닙니다. 자식의 외래키가 NOT NULL이고 참조 무결성 제약이 있으면 비식별 관계여도 부모 행이 반드시 있어야 합니다. 또 실선·점선의 의미는 표기법마다 달라서, IE에서는 식별·비식별 관계를, Barker에서는 필수·선택 참여를 구분합니다.

반대로 부모와 자식의 생명주기가 같고 자식이 부모 없이는 의미가 없다면(주문과 주문상품처럼) 식별 관계가 자연스럽습니다.

식별 관계가 연쇄되면 하위 엔터티는 상위 키를 조인 없이 바로 갖고 있어 조회에 유리할 때가 많습니다. 비식별 관계로 끊으면 PK는 단순해지지만, 상위 엔터티 정보를 얻으려면 오히려 조인이 더 필요할 수 있습니다. 그래서 '비식별로 바꾸면 조회 성능이 항상 좋아진다'는 틀린 설명입니다.

복합식별자와 함께 한 번 더 봅니다. 자전거 한 대는 여러 번 대여될 수 있습니다. BIKE_RENTAL의 주식별자는 각 대여를 구분하는 RENTAL_ID이고, BIKE_ID는 대여한 자전거를 가리키는 외래키입니다. 부모 BIKE의 키가 자식 BIKE_RENTAL의 PK에 들어가지 않으므로 비식별 관계입니다.

대여 한 건마다 점검 기록이 여러 개 남는다고 가정합니다. 점검 순번 CHECK_NO는 각 대여 안에서만 1, 2, 3으로 붙으므로 RENTAL_INSPECTION의 PK는 (RENTAL_ID, CHECK_NO)가 됩니다. 부모 대여의 키가 자식 PK에 포함되므로 식별 관계이고, 두 컬럼을 묶어야 각 점검을 구분할 수 있으므로 복합식별자입니다.

자전거 별명인 BIKE_NAME을 PK로 골랐다면 ‘초록이’ 두 대를 동시에 등록할 수 없습니다. 운영 담당자가 별명을 바꿀 때도 식별값이 바뀌므로 안정적인 키가 아닙니다. 자전거ID를 주식별자로 따로 두면 같은 이름의 개체를 구분하면서 이름은 자유롭게 고칠 수 있습니다.

(BIKE_ID, FRAME_NO)로 묶어 PK를 만들 필요도 없습니다. BIKE_ID 하나로 이미 유일하다면 FRAME_NO를 PK에 더하는 것은 최소성을 만족하지 못합니다. 반대로 대여점검은 CHECK_NO가 대여별로 반복되므로 (RENTAL_ID, CHECK_NO) 두 속성이 모두 필요합니다.