식별자

식별자

반응형

 

1) 식별자(Identifier)란?

• 엔티티(테이블) 안에서 각 행(인스턴스)을 유일하게 구분하는 값입니다.
• 한마디로 “중복 없이 딱 1건을 찍어내는 번호”입니다.
• 논리 모델에서는 식별자, 물리 모델(DB)에서는 보통 키(Key), PK라고 부릅니다.

예시

• 학생 테이블: 학번(student_id)
• 직원 테이블: 사번(emp_id)
• 주문 테이블: 주문번호(order_id)

---

2) 좋은 식별자의 특징(조건)

이미지 핵심 4가지입니다.

1. 유일성: 중복되면 안 됨
   • 이름은 동명이인이 있어서 식별자로 부적절
2. 최소성: 꼭 필요한 속성만으로 구성(가능하면 짧게)
   • “학번” 하나로 되면, “학번+이름+전화번호” 같은 조합은 과함
3. 불변성: 한 번 정해지면 바뀌지 않는 게 좋음
   • 전화번호/주소는 바뀔 수 있어 식별자로 부적절
4. 존재성: 값이 반드시 있어야 함(NULL 불가)
   • 식별자는 비어 있으면 안 됨

예시(좋은/나쁜 식별자)

• 좋은 식별자: 학번, 사번, 주문번호
• 나쁜 식별자: 이름, 전화번호, 주소(변경 가능/중복 가능)

---

3) 식별자의 분류(이미지에 나온 것 정리)

(1) 대표성에 따라

• 주식별자(Primary Identifier): 대표로 쓰는 식별자(보통 PK)
• 보조식별자(Alternate Identifier): 대체로 유일하지만 대표로는 안 쓰는 식별자(UNIQUE 후보)

예) 학생

• 주식별자: 학번
• 보조식별자: 이메일(학교 정책상 유일하다면)

---

(2) 생성 방식에 따라

• 내부식별자: 시스템이 자체 생성(일련번호 등)
• 외부식별자: 다른 기관/시스템에서 가져온 번호

예) 주문

• 내부식별자: order_id(자동 증가)
• 외부식별자: PG사 결제번호, 택배 송장번호

---

(3) 속성 수에 따라

• 단일식별자: 1개 속성으로 구성
  • 예: 학번, 사번
• 복합식별자: 2개 이상 속성 조합
  • 예: (주문번호 + 주문상세순번)

---

(4) 대체 여부에 따라

• 본질식별자(자연키): 업무적으로 원래 존재하는 값
  • 예: 학번(정책상 고정), 사업자등록번호(업무 식별용)
• 인조식별자(대리키): 의미 없는 번호를 새로 만들어 사용
  • 예: 회원_id(자동증가), 주문_id(UUID)

---

4) 주민등록번호를 주식별자로 쓰기 어려운 이유(이미지 요지)

• 개인정보 이슈(유출 위험, 규제)
• 변경 가능성(제도/정책/정정 등)
• 외부 연계 부담(연동 시 보안/승인/관리 복잡)
  그래서 실무에선 보통
   회원번호 같은 인조식별자(PK)를 쓰고, 주민번호는 저장 자체를 피하거나 최소화합니다.

---

5) 식별자 도출 기준(어떻게 고르나?)

• 업무에서 자주 조회/사용되는 속성을 우선 고려
• 이름처럼 중복될 수 있는 값은 피함
• 복합식별자는 너무 길어지면 성능/관리 어려움 → 가능하면 단순화
• 필요하면 인조식별자를 만들어 안정적으로 관리

예시(수강신청)

• 학생: 학번(주식별자)
• 과목: 과목코드(주식별자)
• 수강신청:
  • 방법1) 인조식별자 enroll_id
  • 방법2) 복합식별자 (학번 + 과목코드 + 학기)
    실무에서는 보통 관리 편의 때문에 enroll_id를 PK로 두고, 학번/과목코드는 FK로 둡니다.

---

6) 식별자 관계 vs 비식별자 관계

이 부분이 시험/실무에서 자주 나옵니다.

① 식별자 관계(Identifying Relationship)

• 부모의 PK가 자식의 PK에 포함되는 관계
• 자식은 부모 없이는 존재하기 어렵고, PK도 부모에 의존

 예시(주문–주문상세)

• 주문(ORDER): PK = order_id
• 주문상세(ORDER_ITEM): PK = (order_id + item_seq)
  여기서 order_id가 주문상세 PK에 포함 → 식별자 관계

---

② 비식별자 관계(Non-identifying Relationship)

• 부모의 PK가 자식에 FK로만 들어가고, 자식 PK는 따로 존재
• 자식이 독립 PK를 가짐

 예시(부서–사원)

• 부서(DEPT): PK = dept_id
• 사원(EMP): PK = emp_id, FK = dept_id
  dept_id가 사원 PK가 아니라 FK로만 존재 → 비식별자 관계

---

7) “식별자 관계만” 쓰면 생기는 문제(이미지 요지)

• 관계가 늘어날수록 자식 PK가 점점 길어짐
• PK가 복잡해져서 개발/유지보수/쿼리 작성이 어려워짐
  그래서 실무에서는 식별자 관계와 비식별자 관계를 적절히 섞어 씁니다.

---

초간단 요약

• 식별자 = 행을 유일하게 구분하는 값(PK 후보)
• 좋은 식별자: 유일/최소/불변/NULL 불가
• 종류: 주/보조, 내부/외부, 단일/복합, 본질/인조
• 관계:
  • 식별자 관계 = 부모 PK가 자식 PK에 포함
  • 비식별자 관계 = 부모 PK는 자식에 FK로만