| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 |
- Amazon S3
- C
- operating system
- AWS 침해사고 사례 분석
- 버퍼 오버플로우
- reversing
- Database
- terraform
- python
- dreamhack
- sql
- AWS 사고 사례 분석
- 운영체제
- network
- AWS 침해 사고 사례 분석
- 악성코드분석
- AWS 보안 아키텍처 분석
- programmers
- 리버싱
- 네트워크
- reversing.kr
- 프로그래머스
- 악성코드 분석
- CrackMe 문제
- AWS
- 드림핵
- TryHackMe
- crackme
- 파일 시스템
- AWS 3 Tier Architecture
- Today
- Total
lhywk 님의 블로그
[DB] 데이터 모델링 - ERD, 개체와 속성, 관계 본문
1. ERD란 무엇인가
ERD(Entity-Relationship Diagram, 개체-관계 다이어그램)는 개념적 데이터 모델인 E-R 모델을 그림으로 표현한 것이다. 현실 세계에 존재하는 개체들과 그 개체들이 가지는 속성, 그리고 개체들 사이의 관계를 시각적으로 나타내서, 데이터베이스를 설계하기 전에 전체적인 구조를 한눈에 파악할 수 있게 해준다.
ERD를 먼저 그려보는 것은 매우 중요한 과정이다. 코드를 작성하기 전에 건물의 설계도를 그리는 것과 비슷한데, 설계도가 잘못되면 이후에 아무리 코드를 잘 작성해도 구조적인 문제가 계속 발생하기 때문이다. ERD를 통해 어떤 데이터가 필요한지, 그 데이터들이 서로 어떻게 연결되는지를 미리 점검할 수 있다.
2. 개체와 속성
ERD는 크게 세 가지 요소로 구성된다. 개체, 속성, 관계가 바로 그것이다.
개체
개체(Entity)는 현실 세계에서 독립적으로 존재하며 다른 것과 구별될 수 있는 대상을 의미한다. 학생, 교수, 과목, 부서처럼 명사로 표현될 수 있는 것들이 대부분 개체가 된다. ERD에서 개체는 사각형으로 표현한다.
개체는 두 가지로 나눌 수 있다. 강한 개체(Strong Entity)는 다른 개체에 의존하지 않고 독립적으로 존재할 수 있는 개체를 의미한다. 학생이나 과목처럼 그 자체로 의미를 가지는 개체가 여기에 해당한다. 반면 약한 개체(Weak Entity)는 다른 개체의 존재에 의존해서만 존재할 수 있는 개체를 의미한다. 예를 들어 부양가족이라는 개체는 사원이라는 개체 없이는 의미를 가지기 어려운데, 이런 경우가 약한 개체에 해당한다.
속성
속성(Attribute)은 개체가 가지는 구체적인 특성을 의미한다. 학생이라는 개체는 학번, 이름, 학년, 학과 같은 속성을 가질 수 있다. ERD에서 속성은 타원으로 표현하며, 개체와 선으로 연결한다.
속성 중에서도 그 개체를 유일하게 식별할 수 있는 속성, 즉 기본키에 해당하는 속성은 타원 안의 글자에 밑줄을 그어서 구분한다.
속성은 성격에 따라 몇 가지로 더 나눌 수 있다. 단일 값 속성은 하나의 값만 가지는 속성이고, 다중 값 속성은 여러 개의 값을 가질 수 있는 속성이다. 예를 들어 한 사람이 여러 개의 전화번호를 가질 수 있다면 전화번호는 다중 값 속성이 된다. 다만 릴레이션의 속성은 원자 값이어야 하므로, 다중 값 속성은 실제 테이블로 옮길 때는 별도의 테이블로 분리해서 표현해야 한다.
또한 유도 속성이라는 것도 있는데, 이는 다른 속성의 값으로부터 계산되어 얻어질 수 있는 속성을 의미한다. 생년월일로부터 계산되는 나이가 대표적인 예이다.
아래 그림은 개체, 관계, 속성이 ERD에서 각각 어떤 모양으로 표현되는지, 그리고 기본키 속성은 어떻게 구분되는지를 보여준다.

3. 관계
관계(Relationship)는 두 개 이상의 개체들이 서로 어떻게 연관되어 있는지를 나타낸다. ERD에서 관계는 마름모로 표현하며, 관련된 개체들과 선으로 연결한다. 예를 들어 학생이 과목을 수강한다면, 학생과 과목이라는 두 개체 사이에 수강이라는 관계가 존재하는 것이다.
관계의 카디널리티
개체들 사이의 관계는 한쪽 개체의 인스턴스 하나가 다른 쪽 개체의 인스턴스 몇 개와 대응되는지에 따라 분류할 수 있다. 이를 관계의 카디널리티(Cardinality), 또는 매핑 카디널리티라고 부른다.
1:1 관계는 한쪽 개체의 인스턴스 하나가 다른 쪽 개체의 인스턴스 하나와만 대응되는 관계이다. 예를 들어 한 명의 사원이 하나의 주차공간만 배정받는 상황이 여기에 해당한다.
1:N 관계는 한쪽 개체의 인스턴스 하나가 다른 쪽 개체의 인스턴스 여러 개와 대응되는 관계이다. 예를 들어 하나의 학과에는 여러 학생이 속할 수 있지만, 한 학생은 하나의 학과에만 속하는 상황이 여기에 해당한다. 실무에서 가장 흔하게 나타나는 관계 형태이다.
N:M 관계는 양쪽 개체의 인스턴스가 여러 개씩 서로 대응되는 관계이다. 예를 들어 한 학생이 여러 과목을 수강하고, 한 과목도 여러 학생에게 수강되는 상황이 여기에 해당한다.
아래 그림은 이 세 가지 관계 유형을 구체적인 예시와 함께 정리한 것이다.

N:M 관계의 구현
관계형 데이터 모델은 릴레이션, 즉 테이블이라는 단순한 구조만 사용하기 때문에, N:M 관계를 테이블 하나로 직접 표현할 수가 없다. 그래서 N:M 관계는 항상 별도의 관계 릴레이션(흔히 교차 테이블, 혹은 연결 테이블이라고 부른다)을 만들어서, 두 개의 1:N 관계로 풀어서 구현한다.
학생과 과목 사이의 수강이라는 N:M 관계를 예로 들면, 수강이라는 별도의 릴레이션을 만들고, 이 수강 릴레이션이 학생 릴레이션의 기본키(학번)와 과목 릴레이션의 기본키(과목코드)를 각각 외래키로 가지도록 설계한다. 이렇게 하면 학생과 수강은 1:N 관계가 되고, 과목과 수강도 1:N 관계가 되어, 결과적으로 학생과 과목 사이의 N:M 관계가 두 개의 1:N 관계로 표현된다. 이 수강 릴레이션은 보통 두 외래키를 합쳐서 기본키로 사용하는 경우가 많다.
관계의 참여 정도
관계는 카디널리티 외에도 참여 정도에 따라 구분할 수 있다. 전체 참여(Total Participation)는 한 개체의 모든 인스턴스가 반드시 그 관계에 참여해야 하는 경우를 의미하고, 부분 참여(Partial Participation)는 그 관계에 참여하지 않는 인스턴스도 있을 수 있는 경우를 의미한다. 예를 들어 모든 사원이 반드시 부서에 소속되어야 한다면 전체 참여이고, 부서 발령을 받지 않은 사원도 있을 수 있다면 부분 참여가 된다.
4. ERD 작성 시 고려할 점
ERD를 실제로 작성할 때는 몇 가지 절차를 따르는 것이 도움이 된다.
먼저 시스템에 필요한 개체를 모두 식별한다. 어떤 명사들이 데이터로 관리되어야 하는지 목록을 작성하는 단계이다.
다음으로 각 개체가 가져야 할 속성을 정의한다. 이 단계에서 어떤 속성이 기본키가 될 수 있는지도 함께 고려한다.
그 다음으로 개체들 사이에 어떤 관계가 존재하는지 파악하고, 그 관계의 카디널리티가 1:1, 1:N, N:M 중 무엇인지 결정한다.
마지막으로 전체적인 다이어그램을 그려서 검토한다. 이 과정에서 빠진 개체나 불필요하게 중복되는 속성이 없는지 점검하는 것이 좋다.
이렇게 작성된 ERD는 이후 실제 릴레이션 스키마로 변환되는 토대가 된다. 개체는 보통 하나의 릴레이션으로, 개체의 속성은 그 릴레이션의 속성으로, 그리고 관계는 앞서 설명한 카디널리티에 따라 외래키나 별도의 릴레이션으로 변환된다.
'Database' 카테고리의 다른 글
| [DB] SQL - DDL, DML, DCL, TCL (0) | 2026.06.24 |
|---|---|
| [DB] 정규화 - 이상 현상부터 BCNF까지 (0) | 2026.06.24 |
| [DB] 관계대수 - 셀렉션, 프로젝션, 집합연산, 조인, 디비전 (0) | 2026.06.18 |
| [DB] 키와 무결성 제약조건 (0) | 2026.06.18 |
| [DB] 릴레이션, 스키마와 인스턴스, 관계 데이터 모델 (0) | 2026.06.18 |