데이터 모델링 관계 유형과 ERD 설계 기준

관계는 비즈니스 규칙을 테이블 구조로 옮긴다

데이터 모델의 관계는 엔티티를 연결하는 선에 그치지 않는다. 어떤 데이터가 함께 존재해야 하는지, 어디까지 중복을 허용하는지, 변경이 발생했을 때 어떤 범위가 영향을 받는지를 관계로 표현한다. 관계 유형을 잘못 고르면 조인 구조, 무결성 제약, 확장 방식이 모두 흔들릴 수 있다.

가장 자주 마주치는 카디널리티

일대다 관계는 외래키를 다 쪽에 둔다

하나의 엔티티 인스턴스가 여러 다른 엔티티 인스턴스와 연결되는 형태다. 데이터 모델링에서 가장 빈번하게 사용되며, 일반적으로 다 쪽 엔티티가 일 쪽 기본키를 외래키로 가진다. 부서 하나에 여러 직원이 소속되는 관계가 대표적이다.

⤢✕

다대다 관계는 교차 엔티티로 풀어낸다

양쪽 엔티티가 각각 여러 인스턴스와 연결될 수 있는 다대다 관계는 직접 구현하지 않는다. 두 엔티티의 기본키를 포함하는 교차 엔티티를 만들고, 이를 통해 관계를 표현한다. 학생과 과목의 수강 관계가 이에 해당한다.

⤢✕

일대일 관계는 분리할 데이터의 경계를 정할 때 쓴다

양쪽 엔티티 인스턴스가 서로 하나씩만 연결되는 관계다. 데이터 분리나 보안상 이유로 사용하며, 성능 최적화에도 활용할 수 있다. 한쪽 또는 양쪽 엔티티에 상대 엔티티의 기본키를 외래키로 포함한다. 사원과 사원 상세 정보의 분리가 한 예다.

⤢✕

계층과 역할이 필요한 관계

자기참조 관계로 같은 엔티티의 계층을 표현한다

자기참조 관계는 한 엔티티가 같은 엔티티와 관계를 맺는 구조다. 자신의 기본키를 참조하는 외래키 컬럼을 두며, 조직도나 댓글-대댓글, 부품 구성도처럼 계층을 표현할 때 사용한다.

⤢✕

자기참조 관계가 과도하면 재귀 쿼리가 복잡해지고 성능 저하로 이어질 수 있다. 계층 탐색 방식까지 함께 검토해야 한다.

병렬 관계에서는 역할명을 분명히 한다

두 엔티티 사이에 의미가 다른 관계가 함께 존재하면 병렬 관계가 된다. 예를 들어 사원은 프로젝트의 관리자일 수 있고, 프로젝트 구성원으로 참여할 수도 있다. 관계마다 별도 외래키와 역할명을 정의해 의미를 구분해야 한다.

⤢✕

공통 속성과 고유 속성을 나누는 슈퍼·서브타입

슈퍼·서브타입 관계는 일반화와 특수화를 데이터 모델에 반영한다. 공통 속성은 슈퍼타입에 두고, 각 유형에만 필요한 속성은 서브타입에 배치한다. 데이터 중복을 줄이고 무결성과 확장성을 높이는 방식이다.

배타적 관계에서는 슈퍼타입의 인스턴스가 하나의 서브타입에만 속한다. 서브타입 간 인스턴스 중복이 없는 XOR 관계이며, 직원과 정규직·계약직·임시직의 구분이 예시다.

⤢✕

포함 관계에서는 하나의 슈퍼타입 인스턴스가 여러 서브타입에 동시에 속할 수 있다. 서브타입 간 중복을 허용하는 OR 관계로, 고객이 온라인고객·오프라인고객·VIP고객에 함께 속할 수 있는 모델이 여기에 해당한다.

⤢✕

슈퍼·서브타입은 구현 방식에 따라 조회 성능이 크게 달라질 수 있다. 타입 정보의 정확성을 유지할 방법도 설계에 포함해야 한다.

부모 키가 자식의 정체성에 포함되는가

식별자 관계는 부모 없이 자식이 존재할 수 없다

식별자 관계에서는 부모 엔티티의 기본키가 자식 엔티티 기본키에 포함된다. 자식은 부모에 강하게 종속되며, 부모 없이 존재할 수 없다. ERD에서는 실선으로 표현하고 자식 엔티티는 둥근 모서리 사각형으로 표시한다. 주문과 주문상세의 관계가 대표적이다.

⤢✕

비식별자 관계는 자식의 식별자를 독립적으로 둔다

비식별자 관계에서는 부모의 기본키가 자식의 기본키에 포함되지 않는다. 자식은 부모 없이도 존재할 수 있는 약한 종속성의 관계다. 일반적인 ERD에서는 점선으로 표시한다. 부서 정보가 없어도 존재 가능한 직원 모델이 예시다.

⤢✕

관계 선택은 운영 조건까지 포함한다

다대다 관계는 조인 성능에 영향을 주므로 신중하게 설계한다. 관계 변경은 시스템 전체에 영향을 줄 수 있으므로, 변경될 가능성이 있는 비즈니스 규칙을 고려해 유연성을 확보할 필요가 있다.

관계 이름과 역할명을 명확히 남기고 문서화하면 유지보수성이 높아진다. 또한 참조 무결성 제약조건, 식별자와 비식별자 관계의 선택, 슈퍼·서브타입의 타입 정보 관리까지 함께 검토해야 데이터 일관성을 유지할 수 있다.

쇼핑몰과 인사 시스템에 적용하는 방식

쇼핑몰 모델에서는 고객-주문을 1:M 관계로, 상품-카테고리를 M:N 관계로 설계할 수 있다. 주문-주문상세는 식별자 관계로 연결하며, 회원 슈퍼타입 아래 일반회원과 기업회원을 배타적 서브타입으로 둘 수 있다. 상품의 자기참조 관계는 연관 상품 추천에 활용한다.

인사관리 시스템에서는 부서-직원을 1:M 비식별자 관계로 두고, 직원 자기참조 관계로 관리자-부하직원 구조를 표현한다. 직원-프로젝트는 M:N 관계가 되며, 직원 슈퍼타입과 정규직·계약직 서브타입은 배타적 관계로 모델링할 수 있다. 직원과 이력은 1:1 관계로 연결한다.