관계: 차수·카디널리티·선택성

핵심 요약

관계의 구성 요소와 1:1·1:M·M:N, 필수·선택 참여를 업무 문장으로 판별한다.

핵심 질문

1. 관계: 차수·카디널리티·선택성를 실제 업무 사례에서 어떤 기준으로 판별하는가?
2. 한 행이 나타내는 업무 사실과 유일성·필수성·변경 가능성은 무엇인가?
3. 잘못 모델링하면 어떤 중복·이상 현상·변경 영향이 발생하는가?
4. 여러 설계안 중 업무 의미와 변경 용이성을 가장 잘 보존하는 안을 어떻게 고르는가?

학습 목표

• 관계의 존재성과 행위성을 설명한다.
• 관계 차수, 카디널리티와 선택성을 ERD에서 읽는다.

개념 지도

업무 사실 → 엔터티와 행 단위 → 속성·도메인 → 관계·카디널리티 → 제약

핵심 내용

관계는 두 엔터티 사이의 업무상 연관 규칙이다. 고객이 주문을 한다는 행위 관계, 부서에 사원이 소속된다는 존재 관계처럼 양쪽 관점의 관계명을 문장으로 읽어야 한다.

• 관계 차수(Degree): 관계에 참여하는 엔터티 수
• 카디널리티: 한 인스턴스와 대응하는 상대 인스턴스의 수(1:1, 1:M, M:N)
• 선택성/Optionality: 관계 참여가 필수인지 선택인지(최소 1 또는 0)

논리 모델의 M:N 관계는 구현 단계에서 보통 연결 엔터티로 해소한다. 예를 들어 학생과 과목 사이의 수강 관계는 수강(학생번호, 과목번호, 수강일자) 같은 엔터티가 된다.

관계는 실제 업무 규칙으로 검증한다. “모든 주문은 반드시 한 고객에게 속하는가?”, “고객은 주문이 없어도 존재할 수 있는가?”처럼 양방향으로 질문한다.

흔한 오해와 주의점

• 1:M에서 FK는 일반적으로 M 쪽에 위치한다.
• 선택 관계라고 해서 FK 컬럼이 항상 NULL 허용인 것은 아니다. 관계 구현 방식과 다른 제약을 함께 본다.
• 관계명 없이 선만 그으면 행위의 의미와 방향을 검증하기 어렵다.

문항 풀이 보강: 관계를 검증하는 네 가지 질문

관계는 엔터티가 존재한다는 이유만으로 자동 생성되지 않는다. 다음을 업무 문장과 데이터 조합으로 확인한다.

1. 두 엔터티 사이에 업무상 관심 있는 연관 규칙이 있는가?
2. 두 엔터티의 정보를 함께 조회하거나 조합하는 업무가 있는가?
3. 업무 기술서나 장표에 연결 규칙이 표현되어 있는가?
4. 관계 연결을 가능하게 하는 동사와 조인 기준이 있는가?

관계의 표기에는 관계명, 차수(Degree), 카디널리티와 선택성이 포함된다. 두 엔터티가 참여하는 관계는 2항 관계이고, 한 고객이 주문 여러 건과 연결되면 1:M이다.

고객은 주문을 0건 이상 할 수 있다.
주문은 반드시 한 고객에 속한다.

이처럼 양쪽 방향으로 최소값(0 또는 1)과 최대값(1 또는 다수)을 각각 읽어야 한다. 선택 관계는 최소 카디널리티가 0이라는 뜻이고, 1:M의 M은 최대 카디널리티다.

문제에 적용하는 순서

1. 두 엔터티를 주어와 목적어로 바꾸어 양방향 문장을 만든다.
2. 각 방향의 최소와 최대를 따로 표시한다.
3. M:N이면 연결 엔터티가 필요한지 확인한다.
4. 단순히 함께 등장한다는 이유만으로 관계라고 판단하지 않는다.

최소·최대 카디널리티를 따로 읽기

고객 1명  ── 주문 0..N건
주문 1건  ── 고객 정확히 1명

이 관계에는 두 방향의 규칙이 있다. 고객은 주문 없이도 존재할 수 있으므로 고객→주문의 최소값은 0이고, 주문은 반드시 고객 한 명에 속하므로 주문→고객의 최소·최대값은 모두 1이다.

CREATE TABLE orders (
  order_id    NUMBER PRIMARY KEY,
  customer_id NUMBER NOT NULL,
  CONSTRAINT orders_customer_fk
    FOREIGN KEY (customer_id) REFERENCES customer(customer_id)
);

NOT NULL은 주문 쪽 필수 참여를, FK는 참조 대상의 존재를 보장한다. 고객이 주문을 반드시 한 건 이상 가져야 한다는 반대 방향의 최소값은 이 DDL만으로 자동 보장되지 않으며 별도 업무 절차가 필요하다.

M:N을 연결 엔터티로 바꾸기

학생과 과목은 M:N이지만 실제 업무에는 수강일자·성적·상태 같은 관계 자체의 속성이 존재한다.

학생 1 ── N 수강 N ── 1 과목
수강 PK = (학생번호, 과목번호, 학기)

연결 엔터티를 만들면 “한 학생이 같은 과목을 학기마다 다시 수강할 수 있는가?” 같은 업무 유일성을 PK로 표현할 수 있다.

식별 관계 여부

부모 식별자가 자식 PK에 포함되면 식별 관계다. 포함되지 않고 단순 FK로만 존재하면 비식별 관계다. 생명주기 종속성과 업무 식별 규칙을 확인해 선택하며, 선 굵기나 모양만 외우지 않는다.

사례를 판별하는 순서

1. 모델이 표현해야 하는 업무 사실과 행 단위(Grain)를 한 문장으로 정의합니다.
2. 각 인스턴스를 유일하게 식별할 수 있는 후보와 변경 가능성을 확인합니다.
3. 속성이 어느 사실에 종속되는지와 관계의 필수성·카디널리티를 확인합니다.
4. 중복 저장으로 삽입·갱신·삭제 이상이 생기는지 검토합니다.
5. 물리 성능을 이유로 구조를 바꿀 때 원천 데이터와 동기화·복구 규칙을 함께 설계합니다.

모델 품질 확인표

• 같은 업무 사실이 여러 곳에 중복 저장되지 않는가?
• 이름과 도메인이 한 가지 의미로 사용되는가?
• PK·FK가 실제 업무 관계와 선택성을 정확히 표현하는가?
• 현재 화면이나 프로세스에 과도하게 종속되지 않는가?
• 정규화와 성능 설계의 이유를 측정 가능한 근거로 설명할 수 있는가?

마지막 점검

• 화면의 입력 항목이나 현재 프로세스를 그대로 엔터티·관계로 옮기지 않습니다.
• 한 행의 업무 사실, 후보 식별자와 함수 종속성을 먼저 확정합니다.
• 중복과 비일관성을 만들면서 조회 편의만 얻는 설계를 정답으로 선택하지 않습니다.
• 반정규화와 물리 설계는 측정된 성능 문제와 동기화·복구 대책이 있을 때 적용합니다.

복습 문제

1. 고객 1명이 주문 여러 건을 만들 수 있을 때 카디널리티는?
2. M:N 관계를 물리 테이블로 바로 두기 어려운 이유는?
3. 이 개념을 실제 업무 사례에서 판별할 수 있는가?
4. 한 행의 업무 의미와 식별자를 설명할 수 있는가?