관계와 ERD (1:1 · 1:N · N:M)

테이블 사이 관계의 종류(1:1 / 1:N / N:M)를 프로젝트 예시로 먼저 보고, 엔터티 관계의 성격, 엔터티의 분류, 이를 그림으로 그리는 ERD 표기법 5가지까지 이어서 정리했습니다.

관계의 종류 (1:1 / 1:N / N:M)

• 1:1: 한 행이 다른 테이블의 딱 한 행과만 연결 (이 프로젝트에는 없음)
• 1:N (일대다): 부모 1행이 자식 여러 행과 연결. 이 프로젝트의 5개 관계가 전부 이 유형입니다 (사용자 1명 - 릴스 여러 개, 릴스 1개 - 좋아요 여러 개 등)
• N:M (다대다): 양쪽 다 서로 여러 행과 연결될 수 있는 관계. 이건 중간에 연결 테이블 (junction table)을 하나 더 둬야 표현할 수 있습니다. 원래 설계에서 reels와 hashtags가 이 관계였고, reel_hashtags라는 연결 테이블로 풀었었는데, 이번 4테이블 버전에서는 reels.hashtags 텍스트 컬럼으로 단순화하면서 이 N:M 구조 자체를 없앴습니다.

엔터티 사이의 관계: 존재 관계 vs 행위 관계

**엔터티(Entity)**는 데이터베이스로 관리하고 싶은 대상(사람, 물건, 사건 등)이고, **관계(Relationship)**는 그 엔터티들 사이의 업무적 연관성입니다. 관계는 크게 두 가지 성격으로 나뉩니다.

존재 관계: 가만히 있어도 성립하는 관계

어떤 행위 없이도, 존재 자체만으로 당연히 연결되는 관계입니다. 주로 소속/포함 구조에서 나타납니다.

• 부서 - 사원: 입사하는 순간 이미 어느 부서엔가 소속됩니다.
• 학부 - 학과: 학과는 태생부터 특정 학부 아래에 있습니다.

행위 관계: 이벤트가 일어나야 생기는 관계

두 엔터티가 가만히 있을 땐 아무 관계가 없다가, 특정 행위(이벤트)가 발생해야 만들어지는 관계입니다.

• 고객 - 주문: 고객이 "구매하는 행위"를 해야 주문 데이터가 생깁니다.
• 학생 - 수강신청: "신청하는 행위"가 있어야 데이터가 생깁니다.

M:N 관계는 그대로 테이블이 될 수 없다

논리적으로는 다대다(M:N) 관계를 그릴 수 있지만, 실제 테이블(물리 모델)로는 M:N을 직접 구현할 수 없습니다. 그래서 중간에 **교차 엔터티(Intersection Entity)**를 하나 끼워서 1:N + 1:N 두 개로 쪼갭니다. 대부분의 "행위 관계"가 바로 이 교차 엔터티 형태로 실체화됩니다. (학생 -N:M- 과목 → 학생 -1:N- 수강신청 -N:1- 과목)

자기 참조 관계

엔터티가 자기 자신을 참조하는 관계도 있습니다. 예를 들어 사원 테이블에서 "이 사람의 상사도 사원이다" 같은 계층 구조를 표현할 때 씁니다. 회사 조직도처럼 같은 종류의 데이터끼리 위아래 관계를 만들 때 쓰는 정상적인 모델링 방식입니다.

관계를 그릴 때 적는 것들

관계선 하나에는 보통 세 가지 정보가 들어갑니다.

• 관계명: 두 엔터티가 어떤 관계인지 (예: 고객이 주문을 "한다")
• 차수(카디널리티): 한쪽 하나에 반대쪽이 몇 개 붙는지 (1:1, 1:N, M:N)
• 선택성: 반드시 있어야 하는지(필수), 없어도 되는지(선택)

관계는 "업무 규칙상 이 둘이 이어져 있다"는 논리적인 연결이라서, 실제 테이블에 FK가 아직 없어도 논리 ERD에서는 관계를 먼저 그릴 수 있습니다. ERD에서 존재 관계는 주로 실선(식별 관계)이나 부모가 꼭 있어야 하는 점선으로, 행위 관계는 주로 점선(비식별 관계)으로 그립니다.

엔터티는 어떻게 나뉘나

엔터티도 성격에 따라 나눠볼 수 있습니다. 기준은 크게 두 가지입니다. 눈에 보이는 대상인가, 그리고 업무 흐름에서 언제 생기는가.

눈에 보이는가: 유형 · 개념 · 사건

분류	뜻	예시
유형 엔터티	물리적인 형태가 있고 오래 유지되는 대상. 가장 찾기 쉬움	사원, 상품, 회원, 책, 차량
개념 엔터티	형태는 없지만 관리해야 하는 개념	부서, 학과, 금융상품, 계정과목
사건 엔터티	업무를 하면서 생기는 행동·활동의 기록. 통계와 이력의 재료	주문, 결제, 예약, 출고

언제 생기는가: 기본 · 중심 · 행위

이 기준은 SQLD 시험에 특히 자주 나옵니다. 업무가 흘러가는 순서대로 엔터티가 생긴다고 보면 쉽습니다.

기본(키) 엔터티  →  중심(메인) 엔터티  →  행위 엔터티
  고객, 상품           주문                 주문상세, 결제취소내역
 (스스로 존재)     (업무의 핵심 사건)      (진행 과정에서 계속 쌓이는 기록)

• 기본 엔터티(키 엔터티): 다른 엔터티 없이 혼자서 생길 수 있는 엔터티입니다. 부모가 없고, 다른 엔터티의 부모 역할을 합니다. 예: 사원, 고객, 상품, 부서, 과목
• 중심 엔터티(메인 엔터티): 기본 엔터티에서 생겨나며 그 업무의 핵심이 되는 엔터티입니다. 데이터 양이 많고 행위 엔터티를 만들어내는 바탕이 됩니다. 예: 주문, 접수, 계약, 매출
• 행위 엔터티: 두 개 이상의 부모(기본·중심 엔터티)로부터 업무가 진행되면서 최종적으로 생기는 엔터티입니다. 내용이 자주 추가·변경되고, 주로 상세 설계 단계에서 나옵니다. 예: 주문상세, 계약변경이력, 사원발령이력

시험에서는 이렇게 나옵니다

• "고객이 상품을 주문한다"에서 중심 엔터티는? 주문 (고객, 상품은 기본 엔터티)
• "다른 엔터티의 부모 역할을 하며 독립적으로 생성되는 엔터티는?" 기본(키) 엔터티
• 유무형 분류(유형/개념/사건)와 발생 시점 분류(기본/중심/행위)를 보기에 섞어 두고, 성격이 다른 하나를 고르게 하는 문제도 자주 나옵니다.

ERD 표기법

**ERD(Entity Relationship Diagram)**는 엔터티와 관계를 그림으로 그린 것입니다. 그리는 방식(표기법)이 여러 가지 있는데, 전달하려는 정보(엔터티, 속성, 관계, 차수, 선택성)는 같고 모양만 다릅니다. 실무와 툴에서는 까마귀발(IE) 표기법을 가장 많이 씁니다.

까마귀발(Crow's Foot) 표기법

관계선 끝에 붙는 기호가 까마귀 발자국처럼 갈라져 있어서 붙은 이름입니다. 엔터티는 직사각형(표)으로 그리고, 표 위에 엔터티 이름을, 첫 행에 식별자(PK)를 적습니다.

┌────────────┐
│   사원      │  ← 엔터티 이름
├────────────┤
│ *사원번호   │  ← 식별자(PK)
│  이름       │
│  부서번호   │
└────────────┘

기호 하나로 **몇 개까지(차수)**와 **꼭 있어야 하는지(선택성)**를 한 번에 표현합니다. 선 끝에서 가까운 쪽 기호가 "최대 몇 개", 먼 쪽 기호가 "최소 몇 개"라고 읽으면 됩니다.

──○<   0개 또는 여러 개 (선택 + 다수)
──│<   1개 이상 (필수 + 다수)
──○|   0개 또는 1개 (선택 + 단수)
──||   반드시 1개 (필수 + 단수)

예를 들어 부서 ──||────○< 사원 이라고 그리면 "사원은 반드시 부서 하나에 속하고, 부서에는 사원이 0명 이상 있을 수 있다"는 뜻입니다.

Peter Chen 표기법

ERD를 처음 만든 피터 첸(Peter Chen)의 방식입니다. 엔터티는 사각형, 관계는 마름모, 속성은 타원으로 모두 따로 그립니다. 그림이 커지지만 개념을 설명하기 좋아서 교재나 개념 모델링에서 많이 봅니다.

정보 공학(IE) 표기법

위에서 본 까마귀발 표기법이 바로 정보 공학(Information Engineering) 표기법입니다. 제임스 마틴(James Martin) 등이 정리했고, ERwin 같은 모델링 툴의 기본 표기법이라 실무에서 가장 흔합니다. 관계선에 까마귀발(다수), 막대(1), 원(0)을 붙여 차수와 선택성을 표현합니다.

Ellis-Barker 표기법

오라클이 쓰던 방식(Oracle Case Method)으로 알려진 표기법입니다. 관계선을 반으로 나눠 자기 쪽 절반이 실선이면 필수, 점선이면 선택으로 읽습니다. 다수 쪽에는 까마귀발을 붙이고, 엔터티 안의 속성 앞에는 #(식별자), *(필수), o(선택) 같은 기호를 붙입니다.

IDEF1X 표기법

미국 공군에서 만든 표준 표기법입니다. 스스로 존재하는 엔터티(독립 엔터티)는 모서리가 각진 사각형, 부모에 기대는 엔터티(의존 엔터티)는 모서리가 둥근 사각형으로 그립니다. 식별 관계는 실선, 비식별 관계는 점선으로 엄격히 구분하고, 다수 쪽 끝은 까마귀발 대신 검은 점(●)으로 표시합니다.

UML 표기법

소프트웨어 설계에 쓰는 UML 클래스 다이어그램으로 ERD를 그리는 방식입니다. 기호 대신 숫자로 개수를 적는 게 특징입니다. 1(딱 하나), 0..1(없거나 하나), 0..*(0개 이상), 1..*(1개 이상)처럼 씁니다.

한눈에 비교

표기법	엔터티	관계	개수(차수) 표현	주로 쓰는 곳
Peter Chen	사각형	마름모	선 위에 1, N, M	교재, 개념 모델
IE (까마귀발)	직사각형(표)	선	까마귀발, 막대, 원	실무, ERwin 같은 툴
Ellis-Barker	둥근 사각형	선 (반은 실선, 반은 점선)	까마귀발	오라클 계열
IDEF1X	독립은 각진, 의존은 둥근 사각형	실선(식별), 점선(비식별)	검은 점(●)	공공, 국방 표준
UML	클래스 박스	선	숫자 (1, 0..*)	소프트웨어 설계

정리

개념	핵심
1:1	한 행이 다른 테이블의 딱 한 행과만 연결
1:N	부모 1행 - 자식 여러 행 (프로젝트의 5개 관계 전부)
N:M	연결 테이블(junction table) / 교차 엔터티로 1:N + 1:N으로 쪼개서 구현
존재 관계 / 행위 관계	존재만으로 연결(부서-사원) / 행위가 있어야 생김(고객-주문)
자기 참조 관계	엔터티가 자기 자신을 참조 (사원-상사)
관계 표기 요소	관계명 · 차수(카디널리티) · 선택성(필수/선택)
엔터티 분류	눈에 보이는가(유형/개념/사건), 언제 생기는가(기본/중심/행위)
ERD 까마귀발 표기	관계선 끝 기호로 차수(1/다수)와 선택성(필수/선택)을 함께 표현
그 밖의 ERD 표기법	Peter Chen(마름모 관계), Ellis-Barker(실선/점선 반반), IDEF1X(각진/둥근 사각형), UML(숫자로 개수)

출처: Codyssey-B1/B6-1

참고: 개인 Notion 학습 노트