ER 모델과 관계 모델 변환

ER 모델은 업무 의미를 구조화한다

ER(Entity–Relationship) 모델은 현실 세계의 업무를 특정 DBMS의 테이블 문법보다 높은 수준에서 표현하는 개념적 데이터 모델이다. 무엇을 관리할지, 각 대상에 어떤 특성이 있는지, 대상 사이에 어떤 업무 규칙이 있는지를 개체·속성·관계·제약조건으로 나타낸다.

업무 규칙
   ↓
개체 유형 ── 속성
   │
   └── 관계 유형 ── 카디널리티·참여 제약·관계 속성
   ↓
관계형 스키마로 변환

문장에 나온 모든 명사가 곧 개체가 되는 것은 아니다. 독립적으로 식별하고 여러 인스턴스를 관리해야 하는 대상인지, 단순한 속성인지, 다른 개체와의 관계를 통해서만 의미가 생기는지를 확인해야 한다.

개체 유형과 개체 인스턴스

학생은 개체 유형이고, 학번 2026001인 민준은 개체 인스턴스다. 시험에서 “개체는 현실 세계에서 독립적으로 식별 가능한 대상”이라고 할 때는 일반적으로 개체 유형과 그 인스턴스를 포괄적으로 설명하는 문맥이다.

속성의 종류

속성(Attribute)은 개체나 관계가 가진 특성이다. 같은 값을 저장하더라도 어떤 업무 의미와 허용 범위를 갖는지가 중요하다.

유도 속성을 절대로 저장하면 안 된다는 뜻은 아니다. 조회 성능, 계산 비용, 과거 시점의 값 보존 같은 이유로 저장할 수 있지만 원본 값과 불일치하지 않도록 별도의 규칙이 필요하다.

관계 유형과 관계 인스턴스

관계(Relationship)는 하나 이상의 개체 유형이 맡는 역할 사이에 성립하는 업무상 연관이다.

관계는 동사형으로 읽으면 의미가 분명해진다. 고객–주문이라는 선만 그리는 것보다 “고객은 주문을 한다”, “주문은 고객에게 속한다”처럼 양쪽 역할을 함께 읽어야 한다.

관계 자체도 속성을 가질 수 있다. 학생과 과목의 수강 관계에 수강일, 성적, 수강 상태가 있다면 이 값들은 학생이나 과목 하나에만 속하지 않고 그 학생이 그 과목을 수강한 사실에 속한다.

관계의 차수와 역할

관계의 차수(Degree)는 한 관계 유형에 참여하는 서로 다른 개체 유형의 수다. 같은 개체 유형이 여러 역할로 참여하는 재귀 관계는 단항 관계로 본다.

단항 관계는 재귀 관계(Recursive Relationship)라고도 한다. 직원–직원 관계에서는 같은 개체 유형이 참여하더라도 관리자와 부하 직원처럼 역할 이름이 다르다. 관계의 차수와 뒤에서 설명할 릴레이션의 차수는 서로 다른 개념이다.

카디널리티와 참여 제약

관계 문제는 최대 몇 개까지 연결되는가와 최소 한 개가 반드시 필요한가를 분리해서 읽어야 한다.

최대 카디널리티

1:N이라는 표기만으로는 연결이 필수인지 알 수 없다. 이는 보통 최대 참여 수를 나타내며, 최소 참여 수는 별도로 확인해야 한다.

최소 참여 수와 선택성

• 선택 참여(Partial/Optional Participation): 최소 참여 수가 0이다.
• 전체 참여(Total/Mandatory Participation): 최소 참여 수가 1이다.

다음 업무 규칙을 보자.

한 부서는 직원이 없을 수도 있고 여러 명을 둘 수도 있다.
각 직원은 반드시 한 부서에 소속된다.

이를 최소·최대 표기로 쓰면 다음과 같다.

부서 한 개 → 직원 0..N명
직원 한 명 → 부서 1..1개

부서와 직원은 최대 기준으로 1:N이지만, 부서 쪽의 직원 참여는 선택적이고 직원 쪽의 부서 참여는 필수다. 0..1, 1..1, 0..N, 1..N처럼 최소와 최대를 함께 표시하면 의미가 가장 분명하다.

교재와 표기법에 따라 ‘카디널리티’라는 말에 최소·최대를 모두 포함하기도 하고, 1:1·1:N·N:M의 최대 수만 가리키기도 한다. 시험에서는 문제에서 사용한 표기와 설명을 먼저 따른다.

강한 개체와 약한 개체

예를 들어 직원의 가족을 관리하면서 가족 이름은 같은 직원 안에서는 중복되지 않지만 다른 직원 사이에서는 중복될 수 있다고 하자.

직원(직원번호, 이름)
부양가족(가족이름[부분키], 관계, 생년월일)

부양가족은 가족이름만으로 전체 시스템에서 식별되지 않는다. 직원번호 + 가족이름을 함께 사용해야 하므로 약한 개체로 모델링할 수 있다.

외래키를 가진 모든 개체가 약한 개체인 것은 아니다. 직원이 자체 직원번호로 식별되고 부서번호를 외래키로 갖는다면 직원은 부서와 관계를 맺지만 여전히 강한 개체다.

상위·하위 개체와 일반화·특수화

일반화는 여러 개체의 공통 특성을 상위 개체로 묶는 것이고, 특수화는 상위 개체를 추가 특성에 따라 하위 개체로 구분하는 것이다. 하위 개체는 상위 개체의 식별자와 공통 속성을 이어받는다. 예를 들어 직원 아래에 개발직과 영업직을 둘 수 있다. 이 단원에서는 방향과 상속 의미를 구분한다.

ERD 표기법은 기호보다 의미를 먼저 읽는다

ERD(Entity–Relationship Diagram)는 ER 모델을 도식으로 나타낸 것이다. 대표 표기법의 기호는 다르지만 표현하려는 의미는 같다.

Chen 표기법의 대표 기호

Crow’s Foot 계열 표기

Crow’s Foot 계열에서는 관계선 끝의 기호 조합으로 최소·최대 참여 수를 표현한다.

따라서 원과 세로선의 조합은 0..1, 세로선 두 개는 1..1, 원과 새발 모양은 0..N, 세로선과 새발 모양은 1..N으로 읽는다. 도구나 교재마다 선의 방향·세부 모양이 다를 수 있으므로 반드시 범례와 업무 문장을 함께 확인한다.

관계형 모델의 핵심 용어

ER 모델의 업무 의미를 관계형 모델로 옮기려면 릴레이션 스키마와 릴레이션 인스턴스를 구분해야 한다.

EMPLOYEE(employee_id, employee_name, department_id)

위 표현은 릴레이션의 이름과 속성을 정의한 릴레이션 스키마다. 특정 시점에 저장된 직원 튜플들의 집합은 릴레이션 인스턴스다.

예를 들어 EMPLOYEE(employee_id, employee_name, department_id)의 차수는 3이다. 현재 직원 튜플이 120개라면 릴레이션의 카디널리티는 120이다. 관계형 이론에서는 속성을 이름으로 식별하므로 속성의 나열 순서도 논리적 의미가 없지만, SQL 질의가 반환하는 열의 표시 순서는 SELECT 목록에 따라 달라진다.

‘차수’와 ‘카디널리티’의 문맥을 구분한다

같은 용어가 두 문맥에서 다르게 쓰이므로 문제에 관계, 릴레이션, 속성 수, 튜플 수 중 어떤 단서가 있는지 확인한다.

SQL 테이블과 수학적 릴레이션의 차이

관계형 모델의 릴레이션은 집합이므로 동일한 튜플이 중복되지 않으며 튜플의 순서도 본질적인 의미가 없다. 반면 실제 SQL에서는 다음 차이가 있다.

• 키나 UNIQUE 제약이 없으면 동일한 값을 가진 행이 여러 개 존재할 수 있다.
• 질의 결과도 기본적으로 중복을 포함할 수 있으며 DISTINCT가 중복 제거를 요청한다.
• SQL은 값이 없거나 알 수 없음을 나타내는 NULL을 사용한다.
• ORDER BY가 없으면 반환 행 순서를 보장하지 않는다.

따라서 “SQL 테이블은 수학적 릴레이션과 언제나 완전히 동일하다”는 선지는 옳지 않다.

ER 모델을 관계형 스키마로 변환한다

변환의 목표는 그림을 기계적으로 표로 바꾸는 것이 아니라 개체의 식별과 관계의 카디널리티·참여 제약을 키와 제약조건으로 보존하는 것이다.

일반 개체와 속성 변환

1. 각 강한 개체 유형을 하나의 릴레이션으로 만든다.
2. 단순 속성을 릴레이션의 속성으로 옮긴다.
3. 복합 속성은 필요한 단순 구성요소로 분해한다.
4. 개체의 식별자 중 선택한 식별자를 기본키로 매핑한다.
5. 대체 식별자를 보존해야 하면 UNIQUE 같은 제약으로 표현한다.
6. 유도 속성은 보통 저장하지 않고 계산하되, 저장할 필요가 있다면 일관성 유지 규칙을 둔다.

직원(직원번호, 이름, 주소[시·구·도로명], 생년월일, 나이[유도])

↓

EMPLOYEE(
  employee_id PK,
  employee_name,
  city,
  district,
  street,
  birth_date
)

다중값 속성 변환

다중값 속성은 한 열에 쉼표로 나열하지 않고 별도 릴레이션으로 분리한다.

직원 한 명이 전화번호를 여러 개 가질 수 있음

EMPLOYEE(employee_id PK, employee_name)
EMPLOYEE_PHONE(
  employee_id PK/FK → EMPLOYEE,
  phone_no   PK,
  phone_type
)

전화번호 중복을 허용하지 않는 업무 규칙이라면 employee_id + phone_no를 기본키로 사용할 수 있다. 같은 번호의 반복 이력까지 관리해야 한다면 발생 순번이나 유효 기간 등을 식별자에 포함하는 별도 설계가 필요하다.

약한 개체 변환

약한 개체는 소유자 개체의 기본키를 외래키로 포함하고, 그 키와 부분키를 결합해 기본키를 구성한다.

EMPLOYEE(employee_id PK, employee_name)
DEPENDENT(
  employee_id    PK/FK → EMPLOYEE,
  dependent_name PK,
  relation_type,
  birth_date
)

같은 dependent_name이 다른 직원에게 반복될 수는 있지만, 같은 직원 안에서 같은 이름이 중복되면 결합 기본키를 위반한다.

이항 관계 변환 규칙

1:1 관계

직원 한 명이 사원증을 최대 한 개만 가지고, 사원증은 반드시 한 직원에게 발급된다고 하자. 외래키는 일반적으로 필수 참여 쪽이나 NULL을 줄이기 쉬운 쪽에 두지만, 실제 업무 규칙과 접근 경로도 함께 고려한다.

EMPLOYEE(employee_id PK, ...)
ACCESS_CARD(
  card_no     PK,
  employee_id FK → EMPLOYEE NOT NULL UNIQUE,
  issued_at
)

FOREIGN KEY만 두면 여러 사원증 행이 같은 직원번호를 참조할 수 있으므로 최대 1개라는 규칙을 보장하지 못한다. UNIQUE(employee_id)가 같은 직원번호의 반복을 막아 1:1의 최대 카디널리티를 표현한다.

직원이 사원증을 반드시 가져야 한다는 반대 방향의 최소 참여 조건은 위 구조만으로 자동 보장되지 않는다. 직원 행이 존재하지만 대응하는 사원증 행이 없는 상태를 막으려면 생성 절차, 트리거, 지연 제약 등 추가 수단이 필요할 수 있다.

1:N 관계

부서–직원이 1:N이고 각 직원이 반드시 한 부서에 소속되어야 한다면 외래키는 N쪽인 직원 릴레이션에 둔다.

DEPARTMENT(department_id PK, department_name)
EMPLOYEE(
  employee_id   PK,
  department_id FK → DEPARTMENT NOT NULL,
  employee_name
)

외래키를 1쪽인 부서 테이블에 두면 부서 한 행이 여러 직원번호를 한 열로 보유해야 하므로 1:N 구조를 자연스럽게 표현할 수 없다.

N:M 관계

학생과 과목이 N:M이고 수강 관계에 수강일·성적이 있다면 연결 릴레이션을 만든다.

STUDENT(student_id PK, ...)
COURSE(course_id PK, ...)
ENROLLMENT(
  student_id  PK/FK → STUDENT,
  course_id   PK/FK → COURSE,
  enrolled_at,
  grade
)

한 학생이 같은 과목을 학기별로 다시 수강할 수 있다면 student_id + course_id만으로는 각 수강 사실을 구분하지 못한다. 이때는 학기나 수강번호를 키에 포함해야 한다. 키의 구성은 카디널리티뿐 아니라 실제 업무 규칙을 반영해야 한다.

재귀 관계 변환

직원이 다른 직원을 관리하는 단항 1:N 관계는 역할을 구분한 자기 참조 외래키로 표현할 수 있다.

EMPLOYEE(
  employee_id PK,
  employee_name,
  manager_id FK → EMPLOYEE.employee_id NULL 허용
)

manager_id가 NULL이면 상위 관리자가 없음을 나타낼 수 있다. 한 직원이 여러 관리자와 연결될 수 있는 N:M 재귀 관계라면 manager_id와 subordinate_id를 각각 직원 테이블에 참조하는 별도 연결 릴레이션이 필요하다.

좌우로 이동해 그림을 확인하세요.그림 크게 보기

N:M 관계를 연관 테이블로 변환

STUDENT와 COURSE의 N:M 관계를 ENROLLMENT로 나눈다. ENROLLMENT의 기본키는 (student_id, course_id)이며 두 열은 각각 외래키다. grade는 관계 속성이다. 수강 한 행은 학생 한 명·과목 한 개를 참조하며 학생과 과목은 각각 0회 이상 수강에 참여한다고 가정한다.

외래키만으로 모든 ER 제약을 보장할 수는 없다

관계형 변환 후에는 각 ER 제약이 실제 DDL에서 어떻게 강제되는지 다시 확인해야 한다.

ERD는 업무 규칙을 표현하는 설계 모델이고, 외래키는 그중 참조 무결성을 구현하는 수단이다. 두 개념을 같은 것으로 보거나 “관계선만 그리면 DBMS가 모든 규칙을 자동 보장한다”고 생각하면 안 된다.

논리 데이터 모델 품질 검증

ERD와 릴레이션을 만들었다고 설계가 완료된 것은 아니다. 업무 요구를 빠뜨리지 않았는지, 같은 사실을 중복 정의하지 않았는지, 관계와 식별자가 일관적인지 검토한다.

예를 들어 '한 주문은 한 고객에게 속한다'는데 주문에 고객 참조가 없으면 완전성 문제다. 같은 고객 상태를 서로 다른 의미의 코드로 정의하면 일관성 문제다. 논리 모델 검증에서는 특정 저장 파일이나 인덱스 옵션보다 업무 의미와 구조의 적합성을 확인한다.

ER 모델의 기호·참여·상속을 이어서 읽기

Chen 표기에서 타원은 속성, 이중 타원은 다중값 속성, 점선 타원은 유도 속성이다. 복합 속성은 주소를 시·도로·상세주소처럼 나누어 표현한 속성이다. 유도 속성은 다른 값으로 계산할 수 있으며, 생년월일과 기준일로 구한 나이는 기준일이 변하면 달라진다.

약한 개체의 부분키는 소유자 안에서만 식별한다. 사원별 부양가족번호 1이 다른 사원에게도 존재할 수 있다면 (사원번호, 부양가족번호)가 전체 식별에 필요하다. 소유자 키가 자식의 식별자 구성에 들어가는 관계가 식별 관계다. 외래키가 있다는 사실만으로 모든 자식이 약한 개체가 되는 것은 아니다.

최소 참여 수 1은 필수 참여, 0은 선택 참여다. 부모를 참조하는 자식 FK와 NOT NULL은 각 자식이 부모를 갖게 할 수 있지만, 모든 부모가 최소 한 자식을 갖도록 보장하지는 않는다. ER 모델의 의미와 실제로 선언한 제약이 보장하는 범위를 구분한다.

같은 직원 개체가 직원·상사라는 두 역할로 참여하면 단항 재귀 관계다. 관계의 차수는 서로 다른 개체 유형의 수이며 역할 수와 구분한다. 공급자·부품·프로젝트의 삼항 관계를 쌍별 관계로만 바꾸면 어느 삼중 조합이 실제로 유효했는지 잃을 수 있다.

일반화는 여러 개체의 공통 특성을 상위 개체로 모으는 방향이고, 특수화는 상위 개체를 특성에 따라 하위 개체로 나누는 방향이다. 중복 특수화에서는 같은 상위 개체가 둘 이상의 하위 유형에 속할 수 있다. 배타적 특수화에서는 이를 허용하지 않는다. 전체·부분 특수화는 모든 상위 개체가 하위 유형 중 하나에는 반드시 속하는지에 관한 다른 축이다.

모델 품질의 완전성은 업무에 필요한 개체·속성·관계·제약이 빠지지 않았는지를 묻는다. 배송 업무가 요구되는데 배송 개체나 연관 관계가 누락되었다면, 이름이 잘 지어져 있어도 완전한 모델은 아니다.