Ch07. 논리적 모델링(4) - 현대적인 설계 트랜드

현대적인 애플리케이션 개발과 데이터베이스 설계에서는 비식별 관계를 사용하는 것이 사실상 표준이다.

 

과거: 식별 관계가 선호되었던 이유

과거에는 식별 관계를 선호하는 경향이 있었다.

• 논리적 명확성: "부모 없이는 자식이 존재할 수 없다"는 논리적 관계를 데이터 구조에 직접적으로 표현할 수 있다는 점을 높이 평가했다.
• 저장 공간 절약: 지금과 달리 저장 공간이 비쌌던 시절에는 "AUTO_INCREMENT"를 위한 별도의 ID 컬럼을 만드는 것을 낭비라고 생각하는 경향이 있었다.
• 쿼리 최적화: 특정 시나리오(예: 부모와 자식을 항상 함께 조회)에서 별도의 인덱스 없이도 PK 인덱스를 바로 활용할 수 있다는 점이 장점으로 여겨졌다.

하지만 이러한 장점들은 소프트웨어의 복잡성이 기하급수적으로 증가하고, 변화의 속도가 빨라진 현대에 와서는 그 의미가 대부분 퇴색되었다.

 

현재: 비식별 관계가 대세가 된 이유

오늘날 우리가 식별 관계의 단점이라고 지적했던 모든 것들 그러니까 유연성 부족, 복잡성 증가, 확장성 저해가 바로 현대 소프트웨어 개발에서 가장 피해야 할 요소들이다. 비식별 관계는 이 모든 문제를 해결하며 다음과 같은 명확한 가치를 제공한다.

 

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

 

현대적 설계의 원칙

 

• 기본 키(PK)
  • 테이블의 기본 키는 비즈니스와 무관한 대리 키(Surrogate Key)를 사용한다.
  • "BIGINT AUTO_INCREMENT"가 가장 일반적인 선택이다.
• 관계
  • 모든 관계는 비식별 관계(Non-identifying)로 설계한다.
  • 부모 테이블의 PK는 자식 테이블의 일반 컬럼(FK)으로 참조한다.
• 비즈니스 규칙
  • 데이터의 중복을 막는 등의 비즈니스 규칙은 UNIQUE 제약조건을 적극적으로 활용하여 보장한다.
  • PK로 해결하려 하지 않는다.

이 세 가지 원칙은 신원(Identity), 관계(Relationship), 규칙(Rule)이라는 데이터 모델의 세 가지 핵심 요소를 명확하게 분리하여, 각각의 변경이 서로에게 미치는 영향을 최소화한다.

 

 

예외: 식별 관계를 고려해볼 수 있는 경우

그렇다면 식별 관계는 이제 완전히 쓸모가 없는 것일까? 대부분의 경우에는 그렇다고 할 수 있다. 하지만 아주 드물게, 다음과 같은 조건이 모두 만족될 때 식별 관계를 고려해볼 수는 있다.

 

• 자식 테이블이 부모 테이블의 존재에 완벽하게 종속적일 때 (진정한 Weak Entity).
• 자식 테이블의 데이터가 독립적으로 조회될 일이 절대 없고, 항상 부모를 통해서만 접근될 때.
• 향후 비즈니스 규칙이 변경되어 이 관계가 바뀔 가능성이 전혀 없다고 확신할 때.

예를 들어, 시스템의 모든 로그를 기록하는 LOG 테이블과, 그 로그의 매우 상세한 내부 데이터를 저장하는 LOG_DETAIL 테이블이 있다고 가정해 보자. "LOG_DETAIL"은 "LOG" 없이는 아무 의미가 없으며, 절대 단독으로 사용되지 않을 수 있다. 이런 제한적인 경우에 한해 식별 관계를 적용할 수도 있다.

 

하지만 이 경우에도, 시스템 전체의 설계 일관성을 위해 비식별 관계로 설계하는 것이 장기적으로는 더 나은 선택일 수 있다.

 

 

최종 정리

우리는 "식별 관계 vs 비식별 관계"라는 데이터 모델링의 오랜 논쟁을 깊이 있게 살펴보았다. 결론은 명확하다.

 

단순함, 유연성, 확장성, 유지보수성은 좋은 소프트웨어가 갖추어야 할 핵심적인 덕목이다. 비식별 관계와 대리 키를 사용하는 설계 방식은 이러한 가치를 데이터베이스 레벨에서부터 튼튼하게 뒷받침해 주는, 수많은 경험을 통해 검증된 현대적인 설계의 최상의 선택이다.

 

이제 우리는 데이터의 관계를 맺을 때 더 이상 고민할 필요가 없다. 이 기준으로, 변화에 유연하고 오랫동안 사랑받는 안정적인 시스템을 설계해 나가자.

 

 

대리 키-PK, 자연 키-UNIQUE, 관계-비식별

현대적인 데이터베이스 설계는 대리 키-PK, 자연 키-UNIQUE, 관계-비식별 방식이 사실상 표준이다.

대리 키-PK, 자연 키-UNIQUE, 관계-비식별 이것만 딱 기억하자.