논리적 데이터베이스 모델링 – Relation(관계)의 모든 것

 

 

관계형 데이터베이스에서 Relation(관계) 는 테이블 간의 연결을 정의하는 핵심 요소다. 

논리적 모델링에서는 참여도, 외래 키 위치, 카디널리티(1:1, 1:N, M:N)를 정확히 설계해야 데이터 무결성과 조회 효율이 보장된다. 

이 글에서는 관계의 기본 원칙부터 1:1, M:N 관계의 실무 구현 패턴까지 정리한다.

 

 

1. 관계의 기본 원칙

관계형 데이터베이스의 관계는 방향이 없다. 

JOIN을 통해 어느 쪽에서든 양방향으로 자유롭게 탐색할 수 있다. 외래 키는 단순히 제약조건일 뿐, 조회 방향을 제한하지 않는다. 

 

참여도(Participation) 

• 참여도는 엔티티가 관계에 필수(Mandatory)인지 선택(Optional)인지를 나타낸다. 
• 논리적 모델링에서는 외래 키의 NULL 허용 여부로 구현한다. 

 

까마귀발 표기법 핵심 원칙 

• 한 엔티티 쪽 끝에 있는 기호는 반대편 엔티티에 대한 규칙을 설명한다. 
• 관계선 끝의 기호는 반대편 엔티티의 최소/최대 참여 수를 뜻한다.

 

0: 선택적 참여, 1: 필수적 참여

 

 

 

 

 

 

 

2. ERD와 비즈니스 규칙

ERD는 데이터베이스 제약조건으로 구현하기 어려운 비즈니스 규칙도 그대로 표현한다.

DDL은 ERD 중 DB가 강제할 수 있는 부분만 구현한다.

애플리케이션 코드에서 DDL로 구현하지 못한 나머지 규칙을 처리한다.

 

관계형 DB의 기본 법칙

• 외래 키는 항상 '다(N)' 쪽에 존재한다.
• FK를 N쪽에 두면 NULL로 선택적 관계를 표현할 수 있다.
• 부모-자식 관계에서 참조 무결성을 지킨다.
• PK는 유일하다: 동일 PK 행은 존재할 수 없다.
• FK는 단일 행만 참조한다: 한 값이 정확히 하나의 행을 가리킨다.
• 컬럼은 원자적: 하나의 컬럼에 여러 값 넣지 않는다 (제1정규형).

 

 

 

 

3. 일대일(1:1) 관계

1:1 관계는 드물지만 성능 최적화, 보안, 선택적 정보 분리, 관심사 분리를 위해 사용한다.

DB에서 1:1을 강제하려면 외래 키에 UNIQUE 제약조건을 추가한다.

 

외래 키 위치 선택

보조 테이블에 FK (권장)

• 주 테이블 변경 없이 관계 추가 가능
• 1:N으로 확장 용이
• 개방-폐쇄 원칙(OCP) 만족

주 테이블에 FK (예외적)

• 관계가 필수적일 때: NOT NULL로 정합성 강제
• 조회 성능이 극도로 중요할 때: JOIN 없이 존재 여부 확인

확장성 비교  

• 예외를 제외하고 보조 테이블에 FK를 두는 것이 표준이다. ⭐️

위치	장점	단점
보조 테이블	확장성 높음, 1:N으로 UNIQUE만 제거하면 변경	-
주 테이블	주 테이블 필수 관계 강제 가능	조회 빠름 확장성 낮음, 로직 복잡

 

 

 

 

4. 다대다(M:N) 관계

관계형 DB는 원자성, PK 유일성, FK 단일 참조 제약 때문에 M:N을 직접 표현할 수 없다.

이 때, 중간에 연결 테이블(Junction Table)을 두는 것이 방법이다.

 

연결 테이블의 역할

 

실무에서 대부분  연관 엔티티(Associative Entity)가 되어 비즈니스 의미를 가진다!

 

 

textA 테이블 (1) ←→ (N) 연결 테이블 (1) ←→ (N) B 테이블

 

• 양쪽 PK를 FK로 가져 다리 역할 한다.
• JOIN으로 양방향 조회 가능.
• 관계 자체의 속성(주문 수량, 가격 등)을 저장한다.

 

연관 엔티티 추천 이름 및 특징

1. 연결 강조
   1. 주문상품(order_product)
      • '주문'과 '상품' 테이블을 직접적으로 연결한다는 관계를 이름에 명시적으로 보여준다.
      • 매우 직관적이고 단순하여 관계를 파악하기 쉽다는 장점이 있다.
2. 의미 있는 이름
   1. 주문 항목(order_item)
      • '주문'에 포함된 '항목'이라는 의미를 가장 명확하게 전달한다.
      • 실제 쇼핑몰 비즈니스 로직(예: 장바구니 항목, 주문 항목)과 용어가 일치하여 이해하기 쉽다.
   2. 주문상세(order_detail)
      • '주문의 상세 내역'이라는 의미로, ‘order_item' 과 거의 동일한 의미로 널리 사용된다.
      • 주문에 속한 각 상품 정보를 상세히 나타낸다는 점을 강조한다.

 

 

5. 개념적 vs 논리적 모델링

속성 없는 M:N

• 개념적: M:N 관계로 표현
• 논리적: 연결 테이블로 1:N + 1:N 분해

속성 있는 M:N

• 개념적: 이미 연관 엔티티로 표현
• 논리적: 그대로 테이블 구현

실무 팁: 속성 없는 M:N을 발견하면 "이 관계에 어떤 추가 정보가 필요한가?"를 고민한다. 대부분 숨겨진 속성이 드러나 연관 엔티티가 된다.

 

 

마무리

논리적 모델링에서 관계 설계는 참여도, 외래 키 위치, 카디널리티를 정확히 파악하는 데 달려 있다.

1:1은 보조 테이블에 FK + UNIQUE, M:N은 연결 테이블로 풀어낸다.

이 패턴을 따르면 DB 제약과 비즈니스 규칙이 모두 조화롭게 구현된다.

 

 

 

 

 

끝!