Database ‐ 식별 관계 & 비식별 관계 - thought-corner/Backend-PlayGround GitHub Wiki

Identifying Relationship & Non-Identifying Relationship

• 부모 테이블의 키를 물려받아 자식 테이블의 기본 키 일부로 사용한다면 식별 관계가 되고, 부모 테이블의 기본 키를 일반 컬럼으로만 사용한다면 비식별 관계가 된다.

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

• 아파트 '101동 502호'에 산다고 가정할 때, '502호'라는 나의 집을 식별하려면 '101동'이라는 정보가 반드시 필요하다.
• 다른 동에도 '502호'가 존재할 수 있기 때문이다.
• 즉, 호수의 정체성은 동에 의존하고 이다. 자식의 식별자가 부모의 식별자를 포함해야만 완전해지는 관계가 된다.
• 'A회사'에 다니는 사원번호 '777번'을 부여받았다고 가정할 때, 회사 내에서 '777번'이라는 정보만 있으면 충분히 식별이 된다.
• 이 '777번' 사원 번호는 회사 내에서 유일하기 때문이다.
• 부모와의 관계가 자식의 존재를 식별하는 데 필수적이지 않은 관계가 비식별 관계이다.

식별 관계의 문제점

• 식별 관계는 부모의 식별자를 자식이 물려받는다는 점에서 논리적으로 명확해 보일 수 있으나 강한 결합은 실무적인 관점에서 여러 심각한 문제점을 만드는데 이는 애플리케이션의 유연성과 확장성을 크게 저해하는 요인으로 작용한다.
  • 유연성 부족 : 부모와 자식이 PK로 강하게 묶여 있기 때문에 한 번 맺어진 관계를 변경하는 것이 매우 어렵다.
  • 기본 키 컬럼의 전파와 복잡성 증가 : 관계 깊이가 깊어질수록 부모의 PK가 계속해서 누적되어 자식 테이블의 PK가 비대해지고 복잡해진다. 이는 SQL 쿼리와 Join을 어렵게 만들고 ORM 기술 사용 복잡성을 가중시킨다.

비식별 관계 선택 이유

• 식별 관계는 관계와 비즈니스 규칙을 테이블의 PK에 직접 묶어버린다. 논리적으로는 명확해보이나 비즈니스 규칙이나 데이터 소속 관계가 변경될 때 PK 자체를 흔들어 시스템 전체에 치명적인 영향을 준다.
• 비즈니스 규칙이나 데이터 소속 관계가 변경될 때, PK 자체를 흔들어 시스템 전체에 치명적인 영향을 준다.

식별 관계, 비식별 관계 설계 트렌드

• 비식별 관계가 모든 문제를 해결하며 다음과 같은 명확한 가치를 제공한다.
• 압도적인 유연성과 민첩성
  • 소프트웨어 요구사항은 항상 변한다.
  • 식별 관계의 강한 결합은 이런 변화에 대응하는 것을 극도로 어렵게 만든다.
  • 반면, 비식별 관계의 느슨한 결합은 PK 변경 없이 관계나 비즈니스 규칙을 수정할 수 있게 하여 변화에 민첩하게 대응할 수 있도록 한다.
• 단순성과 일관성
  • 단순한 것이 최고다.
  • 모든 테이블이 id라는 이름의 단일 대리 키를 PK로 갖는 구조는 매우 단순하고 일관성이 있다.
  • 개발자는 테이블의 구조를 예측하기 쉬우며, JOIN 쿼리나 데이터를 다루는 로직을 작성하기가 훨씬 수월해진다.
  • 식별 관계는 계층이 깊어질수록 PK가 계속해서 비대해지고 다루기 어려워진다.
• ORM 친화적
  • JPA 등 현대 애플리케이션 개발의 표준이 된 ORM 기술들은 엔티티(테이블)가 독립적인 식별자(PK)를 갖는 것을 기본으로 설계되었다.
  • 비식별 관계는 ORM과 완벽하게 조화를 이루며 개발 생산성을 극대화한다.
  • 복합키를 사용하는 식별 관계는 ORM에서 다루기 매우 번거롭고 추가적인 코드 작성을 요구한다.
• 비즈니스 로직과의 완벽한 분리
  • 테이블의 식별자(PK)을 이러한 비즈니스 값과 묶어버리는 것은 매우 위험하다.
  • 비즈니스와 무관한 대리 키를 사용하는 비식별 관계는 외부 변화로부터 데이터 구조를 안전하게 보호하는 방화벽 역할을 한다.