M:N 관계를 해소해 데이터 무결성을 지키는 모델링 방법

M:N 관계는 왜 그대로 두면 안 되는가

데이터베이스 모델에서 M:N(다대다) 관계는 최종 논리 모델이 아니라 관계를 구체화하기 전의 상태다. 학생은 여러 강좌를 수강할 수 있고, 하나의 강좌에는 여러 학생이 등록할 수 있다. 이 관계를 테이블 구조에 직접 담으려 하면 같은 정보가 반복되거나 변경 과정에서 데이터가 어긋나기 쉽다.

대표적으로 데이터 중복, 삽입 이상(Insertion Anomaly), 삭제 이상(Deletion Anomaly), 갱신 이상(Update Anomaly)이 발생할 수 있다. 어떤 데이터를 넣기 위해 불필요한 데이터를 함께 추가해야 하거나, 하나를 지우는 과정에서 유지해야 할 정보까지 사라질 수 있다.

⤢✕

관계 자체를 엔터티로 모델링하는 방식

가장 널리 쓰이는 해소 방식은 두 엔터티 사이에 관계 엔터티를 만드는 것이다. 양쪽 엔터티의 기본키를 관계 엔터티에 외래키로 포함하고, 두 키를 복합 기본키(Composite Primary Key)로 설정한다. 관계에 따라 필요한 속성도 이 엔터티에 둔다.

학생과 강좌의 경우 수강 정보는 학생이나 강좌 어느 한쪽의 속성이 아니다. 수강신청일과 성적처럼 관계가 성립할 때 함께 생기는 정보이므로 별도 엔터티가 적합하다.

⤢✕

여기서 수강 엔터티는 학생과 강좌의 연결을 표현하며, 학번과 강좌코드를 복합 기본키로 가진다.

제한된 식별자를 속성으로 통합하는 경우

한 엔터티의 주 식별자(PK)를 다른 엔터티에 통합하는 방식도 있다. 한쪽 엔터티의 레코드 수가 제한적이고 변동이 적으며, 업무 규칙상 통합이 가능한 경우에 적용할 수 있다.

사원과 기술의 관계에서 기술 수가 제한적이라면 기술 항목을 사원 엔터티의 속성으로 둘 수 있다.

⤢✕

이 구조에서는 기술 엔터티의 각 항목을 사원 엔터티 속성으로 통합한다.

부모 엔터티에 참조 속성을 두는 경우

다른 방법은 한쪽 엔터티에 상대 엔터티의 속성을 추가하는 것이다. 업무 규칙상 최대값이 적은 쪽, 그리고 변경 가능성이 낮은 쪽을 선택한다.

프로젝트당 배정 가능한 사원 수가 제한적인 상황이라면 프로젝트 엔터티에 사원 참조 속성을 둘 수 있다.

⤢✕

모델을 확정하기 전에 확인할 업무 규칙

해소 방식은 관계가 무엇을 의미하는지부터 명확해야 결정할 수 있다. 두 엔터티의 관계 정의가 분명한지, 관계에 별도 속성이 필요한지, 앞으로 확장될 가능성은 어떤지를 확인한다.

선택 시에는 데이터 규모와 변동 가능성, 성능 요구사항, 유지보수 용이성, 업무 요구사항의 변화 가능성을 함께 본다. 관계 엔터티 방식은 일반적으로 활용되지만, 모든 관계에 동일한 구조를 기계적으로 적용할 수는 없다.

대학 수강신청 시스템에서는 학생과 강좌의 M:N 관계를 수강 관계 엔터티로 해소할 수 있다. 수강신청일, 출석률, 중간고사, 기말고사, 과제점수 등의 속성을 관계 엔터티에 추가하고, 1:N 관계로 전환해 참조 무결성을 보장한다.

쇼핑몰 주문 시스템에서는 상품과 주문의 M:N 관계를 주문상세 관계 엔터티로 표현할 수 있다. 주문수량, 단가, 할인율 등의 속성을 주문상세에 두면 주문 처리와 재고 관리의 무결성을 확보할 수 있다.

무결성과 조회 성능을 함께 다루기

M:N 관계 해소는 논리적 무결성만을 위한 작업이 아니다. 관계 엔터티를 기준으로 인덱스를 설계할 수 있고, 정규화된 구조에서는 필요한 데이터만 조회할 수 있다. 데이터 변경 시 트랜잭션의 영향 범위를 줄이는 데도 도움이 된다.

⤢✕

M:N 관계를 해소한다는 일은 관계를 1:N으로 바꾸는 데 그치지 않는다. 비즈니스 로직을 데이터 구조에 반영하는 과정이므로, 도메인 전문가와 협업해 업무 규칙을 정확히 모델에 담아야 한다.