💡 핵심 인사이트
데이터베이스 모델링(ERD)에서 두 테이블이 외래 키(FK)로 연결될 때, 자식 테이블이 그 외래 키를 자기 이름표(기본 키, PK)의 일부로 승격시켜 쓰면 부모와 생사고락을 함께하는 끈끈한 **'식별 관계'**가 되고, 그냥 일반 속성으로만 가지고 있으면 자유로운 **'비식별 관계'**가 됩니다.

Ⅰ. 식별 관계 (Identifying Relationship) - "아빠 성(姓)을 물려받는 자식"

자식 테이블이 스스로를 유일하게 식별할 힘(독자적 PK)이 없어서, 부모 테이블의 기본 키를 빌려와 자신의 **'기본 키(PK)의 일부'**로 포함시켜 버리는 강력한 종속 관계입니다. (앞서 배운 약한 개체의 연결선입니다).

• 예시: [주문] 테이블(부모)과 [주문_상세] 테이블(자식).
  • 주문_상세 테이블은 스스로 PK가 될 만한 번호가 없습니다.
  • 그래서 부모의 주문번호(1001)를 FK로 훔쳐 온 뒤, 자기가 가진 상품 순번(1번)과 찰떡같이 결합하여 {주문번호(PK, FK) + 상품순번(PK)} 이라는 복합 기본키를 완성합니다.
• ERD 기호: 부모와 자식 사이를 튼튼한 **'실선(Solid Line ───)'**으로 그립니다.
• 특징: 부모(주문)가 취소되어 삭제되면, 자식(상세내역)도 우주에서 지워지는 완벽한 운명 공동체입니다.

Ⅱ. 비식별 관계 (Non-Identifying Relationship) - "독립한 성인 자식"

자식 테이블이 이미 자신만의 훌륭하고 독자적인 이름표(기본 키)를 가지고 있어서, 굳이 부모의 키를 자기 PK로 쓸 필요 없이 그냥 **'일반 열(일반 속성)'**으로만 놔두는 느슨한 관계입니다.

• 예시: [부서] 테이블(부모)과 [사원] 테이블(자식).
  • 사원 테이블은 이미 {사원번호}라는 완벽하고 유일한 PK를 스스로 가지고 있습니다.
  • 부모인 부서 테이블에서 부서번호(FK)를 가져오긴 하지만, 이를 PK로 삼지 않고 просто "이 사원이 소속된 부서가 어디지?"를 알려주는 단순 정보(일반 컬럼)로만 사용합니다.
• ERD 기호: 부모와 자식 사이를 헐거운 **'점선(Dashed Line - - -)'**으로 그립니다.
• 특징: 부서(부모)가 해체되어 삭제되더라도, 사원(자식) 데이터는 지워지지 않고 그저 부서번호 컬럼이 'NULL(무소속)'로 바뀌며 홀로 살아남을 수 있습니다.

Ⅲ. 실무 설계 가이드 (무엇을 써야 할까?)

• 과거의 관행: 과거엔 자식이 부모 키를 모두 PK로 물려받는 '식별 관계'를 남발했습니다. 하지만 할아버지 ➔ 아버지 ➔ 손자로 내려갈수록 PK 개수가 눈덩이처럼 불어나(예: 자식 PK가 컬럼 5개가 됨) 조인 쿼리 속도가 지옥으로 치닫는 문제가 터졌습니다.
• 현대의 대세: 인위적인 대리 키(Surrogate Key, 예: Auto_increment 되는 고유 ID)를 모든 자식 테이블에 무조건 달아주어 독자적 PK를 갖게 하고, 부모 키는 일반 속성으로 두는 **'전면적 비식별 관계(점선)' 위주의 느슨한 설계가 현대 데이터베이스 아키텍처의 강력한 표준(Best Practice)**으로 자리 잡았습니다. (JPA, Hibernate 등 ORM 프레임워크에서도 비식별 관계 매핑이 압도적으로 유리합니다.)

📢 섹션 요약 비유: 식별 관계(실선)는 캥거루 엄마 주머니 속에 사는 **'아기 캥거루'**입니다. 엄마가 죽으면 아기도 같이 죽는 완벽한 종속체입니다. 비식별 관계(점선)는 다 커서 자취방(독립 PK)을 구해 나간 **'성인 자녀'**입니다. 부모님(FK)이 계시다는 기록은 서류에 남아있지만, 부모님이 돌아가셔도 자식은 자기 집에서 자기 신분증(독립 PK)을 가지고 계속 살아갑니다.