카디널리티로 설계하는 엔티티 관계와 쿼리 성능

관계의 모양이 스키마의 제약조건이 된다

카디널리티(Cardinality)는 데이터베이스 모델에서 엔티티 사이에 몇 개의 인스턴스가 연결될 수 있는지 나타낸다. ERD(Entity-Relationship Diagram)에서 관계를 명확히 표현하는 데 쓰이며, 외래 키 배치와 무결성 제약조건, 조인 처리 방식에도 영향을 준다.

이 개념은 서로 다른 두 관점에서 사용된다. 관계적 카디널리티는 두 엔티티가 맺는 연결 범위를 뜻한다. 반면 속성 카디널리티는 특정 속성이 가질 수 있는 고유 값의 수를 의미한다. 고유 값이 많으면 높은 카디널리티라고 한다.

엔티티 사이의 연결 범위

한 인스턴스끼리만 연결되는 관계

일대일(1:1, One-to-One)은 한 엔티티의 각 인스턴스가 다른 엔티티의 최대 하나의 인스턴스와만 연결되는 형태다.

⤢✕

한 사람은 하나의 여권만 가질 수 있고, 하나의 여권은 한 사람에게만 발급되는 경우가 이에 해당한다.

보통 두 테이블 가운데 하나에 외래 키를 두어 구현한다. 양쪽 테이블 모두 외래 키에 유니크 제약조건을 설정해야 하며, 정규화 과정에서 큰 테이블을 분할할 때 자주 사용한다.

다수 측에 외래 키를 두는 관계

일대다(1:N, One-to-Many)는 한 엔티티 인스턴스가 다른 엔티티의 여러 인스턴스와 관계를 맺을 수 있는 구조다.

⤢✕

하나의 부서에는 여러 직원이 속할 수 있지만, 각 직원은 하나의 부서에만 속하는 경우를 생각할 수 있다. 외래 키는 다수(N) 측 테이블에 추가한다. 가장 일반적인 관계 유형이며 데이터 무결성을 보장하기도 상대적으로 쉽다.

다대일(N:1, Many-to-One)은 같은 관계를 반대편에서 바라본 표현이다. 여러 직원이 하나의 부서에 속한다는 설명처럼, 다수의 엔티티 인스턴스가 하나의 엔티티 인스턴스와 연결된다.

⤢✕

구현 방식은 일대다와 같고 관점만 다르다. 다수 측 테이블에 외래 키를 포함한다.

관계 자체를 테이블로 표현해야 하는 경우

다대다(N:M, Many-to-Many)에서는 양쪽 엔티티가 서로 여러 인스턴스와 연결될 수 있다.

⤢✕

학생은 여러 과목을 수강할 수 있고, 과목도 여러 학생에게 수강될 수 있다. 이 관계는 직접 구현할 수 없으므로 연결(junction) 테이블이 필요하다. 연결 테이블에는 양쪽 엔티티의 기본 키를 외래 키로 포함하며, 등록 날짜나 성적처럼 관계에 속하는 추가 속성도 저장할 수 있다.

고유 값 수와 참여 여부를 함께 읽기

속성 카디널리티는 속성의 고유 값 수를 말한다. 주민등록번호나 이메일 주소처럼 고유 값이 많은 속성은 높은 카디널리티에 해당한다. 성별이나 혼인 상태처럼 가능한 값의 종류가 적은 속성은 낮은 카디널리티를 가진다.

이 차이는 인덱스와 쿼리 계획에도 이어진다. 높은 카디널리티 속성은 인덱스 효율이 좋고, 낮은 카디널리티 속성은 인덱스 효율이 떨어진다. 따라서 카디널리티는 쿼리 최적화와 인덱스 설계에서 중요한 판단 기준이다.

선택성(Optionality)은 관계 참여가 필수인지 선택적인지를 표현한다. 필수 참여(Mandatory)는 반드시 관계에 연결되어야 하는 상태이고, 선택적 참여(Optional)는 관계에 연결되지 않아도 되는 상태다.

⤢✕

이 관계에서 직원은 주문을 하지 않아도 존재할 수 있다. 반대로 주문은 반드시 직원과 연결되어야 한다.

ERD와 UML에서 관계를 표시하는 방법

크로우 풋 표기법(Crow's Foot Notation)은 관계 끝의 기호로 범위를 표현하는 방식이다.

⤢✕

• || : 정확히 하나 (One)
• |o : 0 또는 1 (Zero or One)
• o{ : 0 또는 다수 (Zero or Many)
• |{ : 1 또는 다수 (One or Many)

UML 클래스 다이어그램은 숫자 범위로 카디널리티를 쓴다.

클래스A ───────── 1..* 클래스B

• 1 : 정확히 1개
• 0..1 : 0 또는 1개
• * 또는 0..* : 0개 이상
• 1..* : 1개 이상
• n..m : n개에서 m개 사이

인덱스와 조인 설계에 미치는 영향

관계를 올바르게 정하면 관계 제약조건을 통해 데이터 일관성을 유지할 수 있다. 조인 구조를 명확히 해 쿼리 실행을 효율화하고, 이후 요구사항 변화에도 대응하기 쉬워진다.

속성 카디널리티는 높은 카디널리티 컬럼을 인덱스 후보로 판단하는 기준이 된다. 옵티마이저가 실행 계획을 결정할 때도 영향을 주며, 테이블 간 카디널리티는 적절한 조인 전략을 선택하는 근거가 된다.

금융 시스템에서 계좌와 거래의 관계는 다음처럼 표현할 수 있다.

⤢✕

한 계좌는 여러 거래 내역을 가질 수 있고, 고객은 여러 계좌를 소유할 수 있다. 은행 지점도 여러 계좌를 관리한다. 모두 일대다 관계다.

이 구조에서는 계좌별 거래 내역을 조회하거나, 고객의 계좌 잔액을 합산하는 쿼리를 구성할 수 있다.

-- 계좌별 거래 내역 조회 (효율적: 1:N 관계)
SELECT t.* FROM TRANSACTION t
WHERE t.account_id = 123;

-- 고객별 모든 계좌 잔액 합계 (다중 테이블 조인 필요)
SELECT c.customer_name, SUM(a.balance)
FROM CUSTOMER c
JOIN ACCOUNT a ON c.customer_id = a.customer_id
GROUP BY c.customer_id, c.customer_name;

관계를 확정하기 전에 확인할 조건

카디널리티는 업무 규칙과 요구사항을 먼저 반영해야 한다. 여기에 자주 실행되는 쿼리 유형, 향후 요구사항 변화, 데이터 볼륨, 참조 무결성을 함께 검토해야 한다.

관계의 방향과 참여 범위를 정확히 모델링하면 데이터 무결성, 쿼리 성능, 시스템 확장성의 기반을 마련할 수 있다.