관계형 모델

학습 목표

릴레이션·튜플·속성·도메인을 설명할 수 있다.

슈퍼키·후보키·기본키·외래키를 구분할 수 있다.

스키마와 인스턴스의 차이를 설명할 수 있다.

ER 다이어그램으로 엔티티·관계를 표현할 수 있다.

무결성 제약(엔티티·참조·도메인)을 설명할 수 있다.

문제 상황

• users 테이블에 email이 두 번 들어가도 DB가 막지 않는다
  • 유일성을 어디서 보장할지 모른다
• orders.user_id에 없는 사용자 ID가 들어간다
  • 주문과 사용자 관계가 깨져도 조회는 된다
• 스프레드시트에 고객 주소를 주문마다 복사한다
  • 한쪽만 수정되면 불일치가 난다

오리엔테이션에서 DBMS가 풀 문제를 봤다. 관계형 모델은 표(릴레이션) 와 키·제약으로 구조를 고정한다.

1. 릴레이션(Relation)

관계형 DB의 기본 단위. 수학의 관계(relation) 를 표로 구현한다.

• 릴레이션(Relation) — 행과 열로 이루어진 테이블 (예: Customer, Order)
• 튜플(Tuple) — 테이블의 한 행(row)
• 속성(Attribute) — 테이블의 한 열(column) (예: customer_id, name)
• 도메인(Domain) — 속성이 가질 수 있는 값의 집합 (예: 정수, 문자열, 날짜)

용어	SQL에서	예
릴레이션	테이블	orders
튜플	행	(1001, 'alice', 2026-06-18)
속성	컬럼	order_id, user_id, amount
도메인	컬럼 타입	INTEGER, VARCHAR(255)

• 릴레이션은 순서 없는 튜플의 집합
  • 행 순서는 의미 없음 (정렬은 쿼리에서)
  • 속성 이름은 유일해야 함
• 릴레이션끼리 FK로 연결되면 스키마가 된다
  • 위 그림: users → orders → order_items 참조 체인
  • 한 릴레이션만 보면 표이고, 연결을 보면 관계형 스키마다
• 스키마(Schema) — 릴레이션의 구조 정의 (이름, 속성, 타입, 제약)
• 인스턴스(Instance) — 특정 시점의 실제 데이터 (튜플 집합)

2. 키(Key)

튜플을 유일하게 식별하고 릴레이션 간 관계를 연결한다.

슈퍼키(Super Key)

• 튜플을 유일하게 구분하는 속성(들)의 집합
• 예: (customer_id), (customer_id, email), (email) — email이 unique라면

후보키(Candidate Key)

• 최소 슈퍼키 — 불필요한 속성을 제거한 슈퍼키
• 예: customer_id 단독, email 단독(유일할 때)

기본키(Primary Key, PK)

• 후보키 중 하나를 테이블당 선택
• NULL 불가, 중복 불가
• 예: orders.order_id

외래키(Foreign Key, FK)

• 다른 릴레이션의 기본키를 참조하는 속성
• 예: orders.user_id → users.user_id
• 참조 무결성: FK 값은 참조 대상에 존재하거나 NULL

키	역할	실무 팁
PK	행 식별	surrogate key(BIGSERIAL) vs natural key(이메일)
FK	관계 표현	ON DELETE CASCADE 등 동작 명시
Unique	비PK 유일성	로그인 ID, 주문 번호
Composite	복합 키	(tenant_id, user_id) 멀티테넌트

3. 스키마와 관계

여러 릴레이션을 묶은 데이터베이스 스키마가 애플리케이션의 데이터 모델이다.

users(user_id PK, email UNIQUE, name, created_at)
orders(order_id PK, user_id FK → users, amount, status)
order_items(item_id PK, order_id FK → orders, product_id, qty)

• 1:N 관계
  • 한 사용자 — 여러 주문
  • FK는 N 쪽(주문)에 둔다
• N:M 관계
  • 학생 — 수강 과목
  • 조인 테이블 enrollment(student_id, course_id) 로 풀기
• 정규화 전에 ER로 엔티티·관계를 그리면 중복 설계를 줄일 수 있다

4. ER 다이어그램

엔티티-관계 모델(Entity-Relationship). 설계 단계에서 쓰는 개념 스키마 표기.

• 엔티티(Entity) — 사각형, 독립 객체 (Customer, Order)
• 속성(Attribute) — 타원 또는 엔티티 안 필드
• 관계(Relationship) — 마름모, 엔티티 간 연결 (places, contains)
• 카디널리티(Cardinality) — 1:1, 1:N, N:M

카디널리티	예	관계형 변환
1 : 1	Employee — has — Passport	FK 한쪽 또는 테이블 병합
1 : N	Customer — places — Order	N 쪽에 FK
N : M	Student — enrolls — Course	조인 테이블 + 양쪽 FK

표기	의미
사각형	엔티티(릴레이션 후보)
마름모	관계(relationship)
PK 밑줄	기본키 속성

• ER → 관계형 변환 규칙 (요약)
  • 엔티티 → 테이블
  • 1:N → N 쪽에 FK
  • N:M → 조인 테이블 + 양쪽 FK
  • 1:1 → FK를 한쪽에 두거나 테이블 병합 (정책에 따라)

5. 무결성 제약(Integrity Constraint)

DBMS가 스키마 수준에서 강제하는 규칙. 애플리케이션 버그만으로 깨지지 않게 한다.

엔티티 무결성(Entity Integrity)

• 기본키는 NULL 불가
• PK가 없으면 행을 유일하게 가리킬 수 없음

참조 무결성(Referential Integrity)

• FK는 참조 PK에 존재하는 값 (또는 NULL)
• 위반 시: INSERT/UPDATE 거부, 또는 ON DELETE SET NULL 등 정책

도메인 무결성(Domain Integrity)

• 속성 값이 타입·범위·CHECK 를 만족
• 예: amount >= 0, status IN ('pending','paid')

제약	SQL 예
NOT NULL	name VARCHAR(100) NOT NULL
UNIQUE	email VARCHAR(255) UNIQUE
PRIMARY KEY	PRIMARY KEY (order_id)
FOREIGN KEY	FOREIGN KEY (user_id) REFERENCES users(user_id)
CHECK	CHECK (amount >= 0)

• 무결성은 DB와 앱 양쪽에서
  • DB: 마지막 방어선, 동시성·다중 클라이언트에 필수
  • 앱: UX·에러 메시지·비즈니스 규칙

다음에 다룰 것

• SQL 기초
• DDL/DML, SELECT·JOIN, GROUP BY

---

해당 내용은 Database System Concepts, 7/E (Silberschatz, Korth, Sudarshan) 의 내용을 기반으로 합니다.