핵심 인사이트 (3줄 요약)
- 본질: 카디널리티 비율 (Cardinality Ratio)은 엔터티 간 관계에서 한쪽이 다른 쪽과 몇 개까지 연결될 수 있는지를 나타낸다.
- 가치: 1:N 관계를 정확히 잡아야 외래 키 (Foreign Key) 위치, 인덱스, 정규화 방향이 흔들리지 않는다.
- 판단 포인트: 비즈니스 규칙이 실제로는 M:N인데 1:N으로 우기면 데이터 중복과 무결성 문제가 바로 생긴다.
Ⅰ. 개요 및 필요성
카디널리티 비율 (Cardinality Ratio)은 엔터티-관계 (ER, Entity-Relationship) 모델에서 두 엔터티가 얼마나 많은 인스턴스로 연결되는지 나타내는 표현이다. 가장 자주 보는 형태는 1:1, 1:N, M:N이며, 그중 1:N은 한 부모가 여러 자식을 가질 수 있는 관계를 뜻한다. 이 비율을 잘못 잡으면 테이블 설계가 비즈니스 현실을 거꾸로 반영하게 된다.
카디널리티를 이해해야 하는 이유는 단순히 도식이 예뻐지기 때문이 아니라, 관계의 물리적 구현이 바로 결정되기 때문이다. 외래 키를 어디에 둘지, 유니크 제약을 어디에 둘지, 조인 경로가 어떻게 되는지가 여기서 갈린다.
Customer 1 ─────────< Order N
PK customer_id FK customer_id
한 고객은 여러 주문을 가질 수 있지만, 각 주문은 한 고객에 속한다.
- 📢 섹션 요약 비유: 한 반 선생님은 여러 학생을 담당할 수 있지만, 학생 한 명은 보통 한 반에만 소속된다.
Ⅱ. 아키텍처 및 핵심 원리
1:N 관계에서는 부모 테이블의 기본 키 (PK, Primary Key)가 자식 테이블의 외래 키 (FK, Foreign Key)로 내려간다. 이렇게 하면 부모 한 건을 기준으로 여러 자식이 달릴 수 있고, 자식의 소속 부모를 쉽게 찾을 수 있다. 반대로 M:N 관계는 중간 연결 테이블이 있어야 직접적으로 풀린다.
| 관계 | 의미 | 구현 포인트 |
|---|---|---|
| 1:1 | 서로 1개씩만 연결 | 한쪽에 unique FK |
| 1:N | 한쪽이 여러 개 연결 | N쪽에 FK 배치 |
| M:N | 양쪽이 여러 개 연결 | 교차 / 연결 테이블 필요 |
부모 테이블
┌──────────────┐
│ parent_id PK │
└──────┬───────┘
│ 1:N
▼
┌────────────────────┐
│ child_id PK │
│ parent_id FK │
└────────────────────┘
1:N 설계에서는 FK를 가진 자식 쪽에 인덱스를 두는 것이 일반적이다. 그래야 부모 기준 조회와 자식 그룹 조회가 모두 안정적으로 빠르다. 카디널리티는 논리 모델의 개념이지만, 실제 성능과 제약은 물리 설계와 바로 연결된다.
- 📢 섹션 요약 비유: 큰 우산 하나가 여러 사람을 덮을 수는 있지만, 각 사람은 자기 우산을 여러 개 가질 수는 없다.
Ⅲ. 비교 및 연결
카디널리티는 '몇 개까지 연결되는가'를 말하고, 옵션성(optionality)은 '0도 가능한가'를 말한다. 그래서 1:N과 0:N은 다르다. 이 차이를 무시하면 필수 관계인데도 null이 남거나, 선택 관계인데도 강한 제약을 걸어 입력이 막힌다.
| 축 | 카디널리티 | 옵션성 | 설계 영향 |
|---|---|---|---|
| 1:1 | 한 개씩 | 0 / 1 가능 | unique 제약 필요 |
| 1:N | 하나 대 여러 개 | 0..N / 1..N | FK와 인덱스 설계 |
| M:N | 여러 개 대 여러 개 | 양쪽 가능 | 연결 테이블 필요 |
정규화 관점에서도 1:N은 의미가 크다. 1:N을 제대로 모델링하면 반복 데이터를 줄이고, 집계와 조인이 예측 가능해진다. 반대로 M:N을 억지로 1:N으로 만들면 정규화가 무너지고 갱신 이상이 생기기 쉽다.
- 📢 섹션 요약 비유: 문이 몇 개 달렸는지와, 그 문을 반드시 열어야 하는지 여부는 서로 다른 질문이다.
Ⅳ. 실무 적용 및 기술사 판단
실무에서는 관계를 만들기 전에 '누가 부모이고 누가 자식인지', '한 부모가 자식을 몇 개 가질 수 있는지'를 문장으로 먼저 적어야 한다. 그다음 1:N이면 FK를 자식 테이블에 두고, M:N이면 연결 테이블을 만든다. 비즈니스 규칙을 테이블 구조로 옮기는 순간이 곧 설계의 핵심이다.
체크리스트
- 관계가 실제로 1:N인지 비즈니스 문장으로 확인했는가?
- N쪽 FK에 인덱스와 무결성 제약을 두었는가?
- M:N인데 억지로 한 테이블에 밀어 넣지 않았는가?
- 옵션성과 필수 관계를 구분했는가?
안티패턴
-
여러 자식 ID를 한 컬럼에 쉼표로 저장하는 경우
-
실제로는 M:N인데 1:N으로 표현해 중복을 늘리는 경우
-
FK를 두지 않고 애플리케이션 코드만 믿는 경우
-
📢 섹션 요약 비유: 가족관계를 명확히 적어 두면 누구 집 주소를 찾아야 하는지 헷갈리지 않는다.
Ⅴ. 기대효과 및 결론
카디널리티를 정확히 잡으면 데이터 무결성, 조회 경로, 정규화 방향이 한꺼번에 정리된다. 특히 1:N은 가장 흔하면서도 설계 품질을 크게 좌우하는 관계다. 결국 좋은 모델링은 '관계를 그리는 일'이 아니라 '관계의 수를 정확히 적는 일'이다.
결론적으로 1:N은 데이터베이스의 기본이지만, 아무리 기본이라도 잘못 잡으면 전체 설계를 흔든다. 관계를 먼저 문장으로 검증하고, 그다음 테이블로 옮겨야 한다.
- 📢 섹션 요약 비유: 한 명이 여러 칠판을 가리킬 수는 있어도, 칠판 하나가 여러 선생님을 동시에 모실 수는 없다.
📌 관련 개념 맵
| 개념 | 연결 포인트 |
|---|---|
| ER (Entity-Relationship) | 엔터티 간 관계를 표현하는 논리 모델 |
| PK (Primary Key) | 부모 엔터티를 식별하는 키 |
| FK (Foreign Key) | 자식 엔터티가 부모를 참조하는 키 |
| Junction table | M:N 관계를 푸는 연결 테이블 |
| Normalization | 중복과 이상을 줄이는 설계 원리 |
📈 관련 키워드 및 발전 흐름도
비즈니스 규칙
│
▼
카디널리티 판정
│
▼
PK / FK / 연결 테이블 결정
│
▼
무결성 제약과 인덱스 적용
흐름의 핵심은 문장으로 관계를 확인한 뒤 구조로 옮기는 것이다.
👶 어린이를 위한 3줄 비유 설명
- 한 부모가 여러 자녀를 돌볼 수 있어요.
- 하지만 자녀 한 명은 보통 한 집에만 속해요.
- 그래서 몇 대 몇인지 먼저 정해야 표가 헷갈리지 않아요.