데이터 베이스/설계 1편, 현대적 데이터 모델링 완전 정복

Ch07. 논리적 모델링(4) - 식별, 비식별 관계의 개념

webmaster 2026. 6. 27. 13:49

외래 키를 어떻게 사용하느냐에 따라 관계는 크게 다음 종류로 나뉜다.

  • 식별 관계(Identifying Relationship)
  • 비식별 관계(Non-identifying Relationship)

이 둘을 구분하는 기준은 단 하나다. "부모 테이블의 기본 키를 물려받아 자식 테이블의 "기본 (PK) 일부" 사용하는가(식별 관계), 아니면 부모 테이블 기본 키를 단순히 "일반 컬럼"으로만 사용하느냐?(비식별 관계)"

물론 경우 모두 부모의 기본 키를 알고 있으므로 받아온 부모의 키는 외래 (FK) 된다. 선택은 데이터베이스 모델의 구조, 유연성, 확장성에 영향을 미치므로, 방식의 차이점과 장단점을 명확히 이해해야 한다.

 

식별 관계, 비식별 관계 예시

1) 아파트와 호수: 식별 관계의 예시

 

우리가 "아파트 101 502호"에 산다고 가정해 보자. 여기서 "502호"라는 나의 집을 식별하기 위해서는 "101동"이라는 정보가 반드시 필요하다. 다른 동에도 502호는 존재하기 때문이다. , 나의 "호수"의 정체성(Identity) 부모인 "아파트 동"에 강력하게 의존하고 있다. "101동" 없이는 "502호"가 온전히 식별될 없다. 이것이 바로 식별 관계 본질이다. 자식의 식별자가 부모의 식별자를 포함해야만 완전해지는 관계다.

  • 부모의 식별자: 101동
  • 자식의 식별자: (101동, 502호) 부모 식별자인 101동을 포함해서 복합키를 만듦

 

2) 회사와 사원: 비식별 관계의 예시

 

이번에는 내가 "A회사"에 다니는 "사원번호 777번"이라고 해보자. 회사에서 나를 식별하는 "사원번호 777번"이라는 정보만 있으면 충분하다. 사원번호는 회사 내에서 유일하기 때문이다. 내가 어느 부서 소속인지는 나의 부가 정보일 , 나의 식별자 자체는 아니다. 이처럼 부모(회사)와의 관계가 자식(사원) 존재를 식별하는 필수적이지 않은 관계가 비식별 관계.

  • 부모의 식별자: 회사 A
  • 자식의 식별자: (사원번호 777번) 부모 정보 없이도 독립적으로 식별 가능

 

이제 개념을 데이터베이스 모델링에 그대로 적용해 보자.

  • 식별 관계
    • 부모 테이블의 기본 키(PK)를 받아서 자식 테이블의 "기본 키(PK) + 외래 키(FK"로 사용한다.
  • 비식별 관계
    • 부모 테이블의 기본 키(PK)를 받아서 자식 테이블의 "일반 컬럼 + 외래 키(FK)"로 사용한다.
    • 자식 테이블은 별도의 고유한 기본 키를 가진다.

 

이름에 식별, 비식별 이라는 단어가 들어가는가?

 

식별(Identifying) 관계(이름 그대로, 부모가 자식을 식별하는 사용되는 관계라는 의미다.)

  • 자식 엔티티는 부모 엔티티의 식별자(PK)를 가져와야만 자기 자신을 유일하게 식별(identify)할 수 있다.
    • "아파트 101동 502호" 예시를 다시 생각해 보자.
    • "502호"라는 자식은 "101동"이라는 부모의 정보 없이는 스스로를 온전히 식별할 수 없다.
  • 즉, 부모와의 관계가 자식의 신원(Identity)의 일부가 되는 것이다.

비식별(Non-identifying) 관계(반대로, 부모가 자식을 식별하는 사용되지 않는 관계라는 의미다.)

  • 자식 엔티티는 부모 엔티티의 식별자(PK) 없이도, 자기 자신만의 고유한 식별자(PK)를 이미 가지고 있다.
  • "A회사의 사원번호 777번" 예시에서 "사원"이라는 자식은 "사원번호 777번"이라는 독립적인 식별자를 가지고 있다.
    • "A회사"라는 부모의 정보나 특정 팀이라는 정보는 이 사원의 소속을 나타내는 부가 정보일 뿐, 이 사원의 신원 자체를 구성하지는 않는다.
    • 관계가 신원의 일부가 아니라, 단순한 연결의 의미만 갖는다.

이처럼 용어의 의미를 정확히 이해하면, "자식 테이블의 PK 부모의 PK 포함되는가?"라는 기술적인 규칙을 넘어, " 엔티티의 관계가 논리적으로 얼마나 강하게 묶여 있는가?"라는 모델의 본질을 파악하는 도움이 된다

 

약한 엔티티 - 식별 관계, 강한 엔티티 - 비식별 관계

우리가 식별 관계를 쓸지, 비식별 관계를 쓸지 결정하는 것은 단순히 테이블 구조를 정하는 기술적인 문제를 넘어선다. 결정은 사실, 비즈니스 규칙을 이해하고 데이터의 논리적 구조를 정의하는 개념적 모델링 단계에서부터 시작된다.

 

개념적 모델링과 관계의 강도

 

개념적 모델링 단계에서 우리는 엔티티(Entity)와 그들 간의 관계를 정의한다.

  • 이때 어떤 엔티티가 다른 엔티티 없이 존재할 수 있는지, 혹은 존재 자체가 다른 엔티티에 의존하는지를 파악해야 한다.
  • 이것이 바로 관계의 "강도(Strength)"이며, 식별/비식별 관계 선택의 근본적인 기준이 된다.

 

강한 관계와 식별 관계 - 약한 엔티티

  • 만약 자식 엔티티가 부모 엔티티 없이는 존재 의미가 없거나 식별 자체가 불가능하다면, 이 둘은 "강한 관계"로 묶여 있다고 본다. 개념적 모델링에서는 이런 자식 엔티티를 "약한 엔티티(Weak Entity)"라고 부른다.
  • 약한 엔티티는 스스로 존재할 수 없기 때문에, 부모의 식별자를 자신의 식별자 일부로 가져와야만 비로소 완전해진다.
    • 이것이 논리 모델링에서 식별 관계 구현된다.
  • 예시: "아파트 동" 없는 "호수" 의미가 없듯이, 부모의 존재가 자식의 존재에 필수적인 경우다.

 

약한 관계와 비식별 관계 - 강한 엔티티

  • 반면, 자식 엔티티가 부모 엔티티 없이도 독립적으로 존재할 수 있고, 자신만의 고유한 식별자를 가질 수 있다면, 이 둘은 "약한 관계"로 연결되어 있다고 본다.
  • 이런 엔티티는 "강한 엔티티(Strong Entity)"라고 부른다.
    • 부모와의 연결은 여러 관계 하나일 , 자식의 존재를 정의하지 않는다.
    • 이것이 논리 모델링에서 비식별 관계 구현된다.
  • 예시: 쇼핑몰의 member orders 관계를 보자.
    • member 없으면 orders 존재할 없긴 하지만, orders라는 개념 자체는 "order_id"라는 고유한 식별자를 가진 독립적인 엔티티다.
    • 우리는 주문 번호만으로 특정 주문을 식별할 있다. 회원은 주문을 "누가" 했는지 알려주는 정보일 뿐이다.
    • 따라서 관계는 비식별 계로 설계하는 것이 합리적이다.

결론적으로, 식별 관계와 비식별 관계의 선택은 " 데이터의 관계가 얼마나 긴밀하고 본질적인가?"라는 개념적 질문에 대한 논리 모델의 답변이라고 있다.