💡 핵심 인사이트
식별자(Identifier)는 우리가 앞서 배운 관계형 데이터베이스의 '기본 키(Primary Key)'를, 아직 테이블이 되기 전 밑그림 단계인 ER 모델링(개념적 설계) 단계에서 부르는 논리적인 명칭입니다.
똑같은 유일성과 최소성 성질을 지니지만, 부르는 관점만 다를 뿐입니다.
Ⅰ. 용어의 명확한 매핑 (개념 vs 논리/물리)
데이터베이스를 구축하는 시기에 따라 똑같은 대상을 부르는 이름이 바뀝니다. (시험 빈출)
| 단계 | ER 모델 (개념적 스케치) | RDBMS (논리/물리적 구현) |
|---|---|---|
| 데이터의 집합 | 개체 (Entity) | 릴레이션 (Table) |
| 데이터의 특징 | 속성 (Attribute) | 열 (Column) |
| 데이터 한 건 | 개체 인스턴스 | 튜플 (Row) |
| 고유 식별 수단 ★ | 식별자 (Identifier) | 기본 키 (Primary Key, PK) |
현업 기획자가 "사원 개체의 식별자는 사번으로 합시다"라고 스케치(ERD)해 주면, 며칠 뒤 DBA가 오라클 DB에 CREATE TABLE을 치면서 "사번 컬럼에 PRIMARY KEY 제약을 걸겠습니다"라고 구현하는 것입니다.
Ⅱ. 식별자의 4대 특징 (자격 요건)
식별자로 뽑히려면 ERD 회의에서 다음 4가지 질문을 완벽히 통과해야 합니다.
- 유일성 (Uniqueness): "이 속성값으로 모든 개체 인스턴스를 하나하나 안 겹치게 지목할 수 있는가?" (동명이인이 있는 '이름'은 탈락).
- 최소성 (Minimality): "군더더기 속성은 없는가?" (사번+이름 조합은 이름이 잉여라서 탈락).
- 불변성 (Immutability): "한 번 정해지면 값이 중간에 안 바뀌는가?" (전화번호는 유일할 수 있지만 폰을 바꾸면 값이 변하므로 식별자로 부적합. 사번은 평생 안 바뀜).
- 존재성 (Existence / Not Null): "이 값이 비어있는(NULL) 개체가 존재할 수 있는가?" (여권 번호는 유일하지만, 해외여행을 안 간 직원은 여권 번호가 NULL이므로 전 직원을 아우르는 식별자로 부적합).
Ⅲ. 주 식별자와 보조 식별자
키의 분류와 똑같습니다.
- 본질 식별자 (주 식별자): 업무적으로 정말 의미가 있어서 시스템을 대표하는 핵심 식별자입니다. (예: 주민등록번호). RDBMS의 **기본 키(PK)**가 됩니다.
- 인조 식별자 (대리 키, Surrogate Key): 원래 자연계에는 없던 식별자인데, 주민번호를 쓰자니 보안이 털릴 것 같아서 시스템이 편의상 강제로 일련번호
1, 2, 3...을 매겨놓은 가짜(인위적) 식별자입니다. (현대 웹 개발에서 가장 많이 쓰는 방식입니다.) - 보조 식별자: 유일성은 있지만 대표로 뽑히지 못한 2인자들입니다. RDBMS의 **대체 키(Alternate Key)**가 되며, 나중에 UNIQUE 인덱스가 걸립니다.
📢 섹션 요약 비유: 식별자(Identifier)는 설계도면에 적어놓은 **'건물 기둥의 예상 설계 이름'**입니다. 설계도에 "이곳에 중앙을 받치는 기둥(식별자)을 세워라"라고 적혀있다면, 훗날 실제 공사장에 시멘트와 철근으로 무너지지 않게 단단히 굳혀낸 물리적인 진짜 기둥이 바로 **'기본 키(PK)'**가 되는 것입니다. 둘은 결국 같은 뼈대입니다.