데이터 모델링 총정리-초보자를 위한 개념과 예시 (SQLD 정리 完)

SQLD 데이터 모델링 총정리 (정리 完)

 

안녕하세요, 유뿡뿡입니다.

SQLD 시작하면 SQL 문법부터 배울 것 같지만, 생각보다 먼저 이해해야 하는 내용이 있습니다.

바로 데이터 모델링입니다.

처음 접하면 “SQL 시험인데 왜 데이터베이스 설계를 배우지?”라는 생각이 들 수 있습니다.

하지만 SQL은 이미 만들어진 데이터베이스 구조 안에서 데이터를 조회하고 수정하는 언어입니다. 따라서 데이터가 어떤 구조로 저장되고, 서로 어떤 관계를 가지는지 이해하는 것이 중요합니다.

이번 글에서는 SQLD를 처음 공부하는 분들도 이해할 수 있도록 데이터 모델링의 정의부터 3단계 모델링, 데이터 독립성, 스키마, ERD까지 한 번에 정리해보겠습니다.

특히 단순 암기보다는 쇼핑몰과 회사 업무를 예시로 쉽게 풀어보겠습니다.

 

 

---

 

한눈에 보는 목차

1. 데이터 모델링이란?
2. 데이터 모델링의 특징
3. 정보시스템 모델링의 3가지 관점
4. 데이터 모델링이 제공하는 기능
5. 데이터 모델링이 중요한 이유
6. 데이터 모델링 시 주의할 점
7. 데이터 모델링의 3단계
8. 프로젝트 생명주기와 데이터 모델링
9. 데이터 독립성이란?
10. 외부·개념·내부 스키마
11. 논리적 독립성과 물리적 독립성
12. 매핑(Mapping)이란?
13. ERD란?
14. IE 표기법과 Barker 표기법
15. 좋은 데이터 모델의 요소
16. 주의사항 및 참고사항
17. 요약 정리
18. FAQ
19. 결론

 

---

1. 데이터 모델링이란?

데이터 모델링(Data Modeling)은 현실에서 발생하는 업무와 정보를 데이터베이스에 저장할 수 있는 구조로 표현하는 과정입니다.

쉽게 말하면, 

현실의 업무 → 필요한 데이터 추출 → 데이터 관계 정의 → 데이터베이스 설계 과정이라고 이해하면 됩니다.

■ 쇼핑몰을 예로 들어보겠습니다.

쇼핑몰에는 크게 다음과 같은 데이터가 필요합니다.

구분	주요 데이터
고객	고객번호, 이름, 연락처
상품	상품번호, 상품명, 가격
주문	주문번호, 주문일자, 금액
결제	결제수단, 결제금액
배송	주소, 배송상태

하지만 데이터만 각각 만들어놓으면 부족합니다.

예를 들어,

고객 1명 → 여러 번 주문 가능

주문 1건 → 여러 상품 포함 가능

상품 1개 → 여러 주문에서 판매 가능

처럼 데이터끼리의 관계도 정의해야 합니다.

 

즉 데이터 모델링의 핵심은

1. “어떤 데이터를 저장할 것인가?”

2. “그 데이터가 서로 어떻게 연결되는가?”

를 정하는 것입니다.

 

※  데이터 모델링 : 현실의 업무·사물·사건 등을 데이터 구조와 관계로 표현하는 과정

 

---

 

2. 데이터 모델링의 특징

데이터 모델링의 대표적인 특징은 세 가지입니다.

특징	의미	쉽게 이해하면
추상화	필요한 정보만 선택	필요한 것만 뽑기
단순화	복잡한 현실을 단순 표현	쉽게 만들기
명확화	의미를 명확하게 정의	헷갈리지 않게 만들기

■ ① 추상화

현실에 존재하는 모든 정보를 데이터베이스에 저장할 필요는 없습니다.

예를 들어 고객에게는 키, 몸무게, 혈액형, 취미, 주소, 전화번호 등 다양한 정보가 있습니다.

하지만 쇼핑몰이라면 주로 다음 정보가 필요합니다.

• 고객번호
• 고객명
• 전화번호
• 주소

즉 수많은 현실 정보 중 업무에 필요한 정보만 선택하는 것이 추상화입니다.

 

■ ② 단순화

실제 쇼핑 과정은 복잡합니다.

상품검색 → 장바구니 → 쿠폰적용 → 주문 → 결제 → 배송 → 수령

하지만 데이터를 설계할 때는 핵심 구조를 다음처럼 단순화할 수 있습니다.

고객 → 주문 → 주문상품 → 상품

복잡한 업무를 일정한 규칙으로 줄여 표현하는 것이 단순화입니다.

 

■ ③ 명확화

데이터 이름은 다른 사람이 봐도 의미가 명확해야 합니다.

예를 들어 컬럼명이 단순히

‘금액’

이라고 되어 있다면 어떤 금액인지 알기 어렵습니다.

그래서 다음처럼 구분합니다.

• 판매금액
• 할인금액
• 결제금액
• 공급금액

누구나 같은 의미로 이해하도록 만드는 것이 명확화입니다.

 

---

3. 정보시스템 모델링의 3가지 관점

정보시스템을 분석할 때는 크게 세 가지 관점으로 볼 수 있습니다.

관점	핵심 질문
데이터 관점	무엇을 관리하는가?
프로세스 관점	어떤 업무를 하는가?
상관 관점	업무가 어떤 데이터를 변화시키는가?

■ ① 데이터 관점

시스템에서 관리해야 할 데이터를 바라보는 관점입니다.

예를 들어 쇼핑몰이라면 다음처럼 구분할 수 있습니다.

[고객 영역]

• 고객
• 회원등급
• 배송지

[상품 영역]

• 상품
• 카테고리
• 가격
• 재고

[주문 영역]

• 주문
• 주문상품
• 결제
• 배송

 

■ ② 프로세스 관점

어떤 업무가 이루어지는지를 보는 관점입니다.

[회원 업무]

• 회원가입
• 로그인
• 회원정보 수정

[주문 업무]

• 주문
• 결제
• 주문취소

[물류 업무]

• 출고
• 배송
• 반품

 

■ ③ 데이터와 프로세스의 상관 관점

특정 업무가 실행될 때 어떤 데이터가 생성되거나 변경되는지 보는 관점입니다.

예를 들어 고객이 상품을 주문하면,

주문 발생 → 주문데이터 생성 → 재고 감소 → 결제데이터 생성 → 배송데이터 생성

처럼 여러 데이터가 동시에 영향을 받습니다.

 

---

4. 데이터 모델링이 제공하는 기능

데이터 모델링은 단순히 ERD를 그리는 작업이 아닙니다.

시스템 전체의 설계도 역할을 합니다.

■ 주요 기능

기능	설명
구조화	복잡한 업무를 데이터 구조로 표현
시각화	데이터 관계를 보기 쉽게 표현
규칙 정의	업무 규칙을 데이터에 반영
의사소통	개발자와 현업 간 공통 기준 제공
문서화	시스템 구조를 기록

예를 들어 건물을 만들 때 설계도가 필요하듯,

데이터 모델 → 시스템 개발 → 실제 서비스

과정에서도 데이터 모델은 설계도의 역할을 합니다.

 

---

5. 데이터 모델링이 중요한 이유

SQLD에서는 데이터 모델링의 중요성을 다음 세 가지 관점에서 이해하면 좋습니다.

■ ① 파급효과

데이터 구조 하나를 잘못 만들면 연결된 여러 시스템을 함께 수정해야 할 수 있습니다.

예를 들어 고객번호 체계가 잘못 설계됐다면 영향을 받을 수 있는 곳은 다음과 같습니다.

고객관리 / 주문 / 결제 / 배송 / CRM / 통계

즉 데이터 구조는 시스템 전체에 영향을 줄 수 있습니다.

 

■ ② 복잡한 정보 요구사항

회사에서는 단순히 주문 내역만 보는 것이 아닙니다.

예를 들어 이런 요청이 들어올 수 있습니다.

“부산지역 고객 중 최근 재구매가 많고 반품률이 높은 상품을 찾아주세요.”

이 요청을 처리하려면

고객 + 지역 + 주문 + 상품 + 반품

정보가 제대로 연결되어 있어야 합니다.

 

■ ③ 데이터 품질

동일한 정보를 여러 시스템에서 다르게 관리하면 문제가 생깁니다.

시스템	고객 주소
고객관리	부산광역시 남구
주문관리	부산 남구
배송관리	부산광역시 남구 대연동

어떤 주소가 최신 정보인지 판단하기 어려워질 수 있습니다.

따라서 데이터 모델링 단계부터 일관된 관리가 중요합니다.

 

---

6. 데이터 모델링 시 주의할 점

대표적으로 기억해야 할 것은 다음 세 가지입니다.

구분	의미
중복	같은 데이터를 여러 곳에 반복 저장
비유연성	작은 변화에도 구조를 크게 수정
비일관성	같은 정보를 서로 다른 기준으로 관리

■ 중복

고객 전화번호가 고객·주문·배송 테이블에 각각 반복 저장되어 있다면 전화번호 변경 시 여러 데이터를 수정해야 할 수 있습니다.

 

■ 비유연성

처음 배송방법을 ‘택배’ 하나만 고려했는데 이후

택배 / 퀵배송 / 매장수령 / 직접배송

이 추가될 때 전체 시스템을 수정해야 한다면 유연성이 떨어지는 구조입니다.

 

■ 비일관성

같은 사람을

영업시스템 = 고객번호

쇼핑몰 = 회원번호

ERP = 거래처코드

처럼 관리하면서 연결 기준이 없다면 통합 관리가 어려워집니다.

 

---

7. 데이터 모델링의 3단계

데이터 모델링은 크게 세 단계로 구분합니다.

단계	핵심 질문	특징
개념적	무엇이 필요한가?	큰 업무 구조
논리적	어떤 구조로 만들까?	데이터 구조 구체화
물리적	실제 DB에 어떻게 만들까?	실제 구현

■ ① 개념적 데이터 모델링

가장 큰 업무 구조를 정하는 단계입니다.

예를 들어 쇼핑몰이라면

고객 / 상품 / 주문 / 결제 / 배송

같은 주요 대상을 먼저 찾습니다.

그리고

고객 → 주문 → 상품

처럼 큰 관계를 정의합니다.

이 단계에서는 실제 컬럼명이나 데이터 타입까지 세세하게 결정하지 않습니다.

 

■ ② 논리적 데이터 모델링

개념적으로 정리한 대상을 구체적인 데이터 구조로 만드는 단계입니다.

[고객 엔터티]

• 고객번호
• 고객명
• 전화번호
• 주소
• 가입일자

[주문 엔터티]

• 주문번호
• 고객번호
• 주문일자
• 주문금액
• 주문상태

이 단계에서 기본키, 외래키, 속성, 관계 등을 구체적으로 정의합니다.

 

■ 기본키(Primary Key)

각 데이터를 서로 구분하기 위한 대표 값입니다.

엔터티	기본키 예시
고객	고객번호
주문	주문번호
상품	상품번호

예를 들어 고객번호 1001과 고객번호 1002처럼 서로 다른 번호를 이용하면 각각의 고객을 구분할 수 있습니다.

 

■ 외래키(Foreign Key)

다른 테이블과 관계를 연결하는 값입니다.

예를 들어 주문 테이블에 고객번호가 있다면,

고객 테이블의 고객번호와 연결해서

“누가 주문했는가?”

를 확인할 수 있습니다.

예)

고객 테이블 : 고객번호 1001 / 홍길동

주문 테이블 : 주문번호 5001 / 고객번호 1001

→ 주문 5001번은 고객 1001번의 주문

 

■ 속성(Attribute)

하나의 대상을 설명하는 세부 정보입니다.

예를 들어 고객이라는 엔터티의 속성은 다음과 같습니다.

고객번호 / 고객명 / 전화번호 / 주소 / 가입일자

 

※ 엔터티(Entity) : 관리해야 할 사람, 사물, 사건 등의 데이터 대상

 

■ 관계(Relationship)

엔터티와 엔터티가 서로 어떻게 연결되어 있는지를 의미합니다.

예)

고객 — 주문한다 → 주문

고객 1명은 여러 주문을 할 수 있기 때문에 고객과 주문은 1:N 관계가 될 수 있습니다.

 

■ ③ 물리적 데이터 모델링

논리적으로 만든 구조를 실제 데이터베이스에 구현하는 단계입니다.

예를 들어 논리 모델의

고객번호 / 고객명 / 전화번호

를 실제 DB에서는 다음처럼 만들 수 있습니다.

논리 속성	실제 컬럼 예시
고객번호	CUSTOMER_ID
고객명	CUSTOMER_NAME
전화번호	PHONE_NUMBER

그리고 각 컬럼의 데이터 타입, 인덱스, 저장방법 등도 결정합니다.

 

■ 세 단계 한 번에 외우기

개념적 = 무엇이 필요하지?

논리적 = 어떤 구조로 만들지?

물리적 = 실제 DB에 어떻게 만들지?

 

---

8. 프로젝트 생명주기와 데이터 모델링

데이터 모델링은 프로젝트 한 시점에만 진행되는 것이 아닙니다.

업무가 구체화되면서 데이터 모델도 점점 구체화됩니다.

요구사항 → 개념 모델 → 논리 모델 → 물리 모델 → 실제 개발

예를 들어,

“고객이 상품을 주문할 수 있어야 한다.”

라는 요구사항이 있다면

단계	내용
요구사항	고객이 상품 주문
개념	고객·주문·상품 정의
논리	고객번호·주문번호 등 정의
물리	실제 테이블·컬럼 생성
개발	SQL 및 프로그램 구현

이런 흐름으로 발전합니다.

■ 프로젝트 단계와 모델링은 정확히 1:1로 대응할까?

개념적·논리적·물리적 모델링을 프로젝트 단계와 연결해서 이해하면 편하지만, 실제 프로젝트에서는 회사나 개발 방법론에 따라 진행 시점이 달라질 수 있습니다.

중요한 것은 정확한 단계 이름을 외우는 것보다 다음 흐름을 이해하는 것입니다.

업무 요구사항 파악 → 전체 데이터 구조 정의 → 세부 데이터 구조 정의 → 실제 DB 구조 구현

즉 프로젝트가 진행될수록 데이터 모델은 추상적인 모습에서 실제 데이터베이스에 가까운 모습으로 점점 구체화됩니다.

 

---

9. 데이터 독립성이란?

데이터 독립성은 처음 공부하면 어렵게 느껴지지만 핵심은 단순합니다.

“한 부분을 변경해도 다른 부분에 미치는 영향을 최소화하는 것” 입니다.

예를 들어 데이터 저장방식을 바꿨다고 해서 사용자가 사용하는 화면까지 전부 수정해야 한다면 효율적인 구조라고 보기 어렵습니다.

그래서 데이터베이스 구조를 여러 단계로 나누고 서로 영향을 최소화하도록 설계합니다.

 

■ 데이터 독립성이 왜 중요할까?

데이터 독립성이 부족하면 데이터베이스 내부 구조가 조금만 변경되어도 사용자 화면이나 프로그램까지 수정해야 할 수 있습니다.

예를 들어 고객 검색속도를 높이기 위해 DB 내부의 인덱스를 변경했다고 해보겠습니다.

좋은 구조라면

DB 내부 변경 → 사용자 화면은 그대로 사용

할 수 있어야 합니다.

반대로 데이터 독립성이 부족하다면

DB 내부 변경 → 프로그램 수정 → 화면 수정 → 다른 시스템 수정

처럼 변경 영향이 계속 퍼질 수 있습니다.

따라서 데이터 독립성은 시스템의 유지보수와 확장성을 높이기 위해 필요한 개념입니다.

---

10. 외부 스키마·개념 스키마·내부 스키마

데이터베이스의 3단계 스키마 구조는 다음과 같습니다.

구분	쉽게 이해하면
외부 스키마	사용자 관점
개념 스키마	전체 데이터 구조
내부 스키마	실제 저장 구조

※  스키마(Schema) : 데이터베이스의 구조와 데이터 간 관계를 정의한 설계 구조

 

■ 외부 스키마

각 사용자나 부서가 데이터를 바라보는 방식입니다.

예를 들어 같은 회사 데이터베이스라도 필요한 정보는 부서마다 다릅니다.

부서	서로 필요한 데이터
영업팀	고객, 매출, 주문
물류팀	상품, 재고, 배송
회계팀	매출, 결제, 세금

영업팀은 고객과 매출이 중요하고, 물류팀은 상품 재고와 배송정보가 중요합니다.

즉 같은 데이터베이스를 사용하더라도 사용자마다 바라보는 데이터 범위가 다를 수 있습니다.

 

■ 개념 스키마

회사 전체에서 사용하는 데이터 구조입니다.

예를 들어

고객 / 상품 / 주문 / 재고 / 결제 / 배송

등이 어떻게 연결되는지를 전체적인 관점에서 정의합니다.

 

■ 내부 스키마

데이터가 실제로 저장되는 구조입니다.

예를 들면

• 파일 저장 구조
• 인덱스
• 저장 위치
• 데이터 접근방법

등이 포함됩니다.

 

■ 한 번에 기억하기

외부 스키마 = 누가 무엇을 보는가?

개념 스키마 = 전체 데이터 구조는 어떻게 되어 있는가?

내부 스키마 = 실제로 어떻게 저장되어 있는가?

---

11. 논리적 독립성과 물리적 독립성

데이터 독립성은 크게 두 가지입니다.

구분	변경되는 부분	영향 최소화 대상
논리적 독립성	개념 스키마	외부 스키마
물리적 독립성	내부 스키마	개념 스키마

 

■ 논리적 데이터 독립성

개념적인 데이터 구조가 변경되어도 사용자가 보는 구조에 미치는 영향을 최소화하는 것입니다.

예를 들어 고객 데이터에 ‘고객등급’을 새로 추가했다고 해서 기존 고객조회 화면을 반드시 모두 수정할 필요는 없습니다.

 

■ 물리적 데이터 독립성

실제 저장 구조를 변경하더라도 전체 데이터 구조에는 영향을 최소화하는 것입니다.

예를 들어 검색 성능을 높이기 위해 새로운 인덱스를 추가하더라도 사용자는 기존과 똑같이 고객정보를 조회할 수 있습니다.

 

■ 시험에서 헷갈리지 않는 방법

두 개념은 “어디가 변경되는가?”를 먼저 보면 쉽게 구분할 수 있습니다.

 

예시 1.

고객 테이블에 ‘고객등급’이라는 새로운 데이터가 추가됐지만 기존 배송조회 화면은 그대로 사용할 수 있습니다.

→ 논리적 데이터 독립성

 

예시 2.

고객검색 속도를 높이기 위해 인덱스를 추가했지만 고객 테이블의 논리적 구조는 그대로입니다.

→ 물리적 데이터 독립성

 

■ 암기 포인트

논리적 독립성 개념 → 외부 영향 최소화

물리적 독립성 내부 → 개념 영향 최소화

---

12. 매핑(Mapping)이란?

3단계 스키마는 서로 독립되어 있지만 연결은 되어 있어야 합니다.

이 연결 관계를 매핑(Mapping)이라고 합니다.

외부 스키마 ↔ 개념 스키마 ↔ 내부 스키마

예를 들어 사용자가 화면에서 보는 ‘고객명’이 실제 데이터베이스의 CUSTOMER_NAME 컬럼과 연결되어야 합니다.

이렇게 서로 다른 구조 사이의 대응 관계를 연결하는 개념이 매핑입니다.

 

■ 매핑은 왜 필요한가?

외부 스키마, 개념 스키마, 내부 스키마는 서로 역할이 다르지만 완전히 따로 존재할 수는 없습니다.

각 단계의 데이터를 서로 연결해야 실제 시스템이 동작할 수 있습니다.

매핑은 크게 다음처럼 이해하면 쉽습니다.

구분	연결 관계	역할
외부/개념 매핑	외부 ↔ 개념	사용자 관점과 전체 구조 연결
개념/내부 매핑	개념 ↔ 내부	전체 구조와 실제 저장구조 연결

예를 들어 영업팀 화면에 표시되는 ‘고객명’은 회사 전체 데이터 구조의 고객정보와 연결되어야 합니다.

또 개념적으로 정의된 고객번호는 실제 데이터베이스의 컬럼과 저장구조에 연결되어야 합니다.

즉 매핑은 서로 다른 스키마 사이를 연결하는 다리 역할을 합니다.

---

13. ERD란?

ERD는 Entity Relationship Diagram의 약자입니다.

쉽게 말하면

“데이터와 데이터 사이의 관계를 그림으로 나타낸 것”

입니다.

예를 들어 고객과 주문 관계를 보겠습니다.

고객 1명 → 주문 여러 건

즉

고객 1 : N 주문

관계가 됩니다.

조금 더 확장하면 다음처럼 표현할 수 있습니다.

고객 → 주문 → 주문상품 ← 상품

이 구조를 통해 어떤 고객이 주문했고, 어떤 주문에 어떤 상품이 포함됐는지를 표현할 수 있습니다.

 

■ ERD에서 실제로 확인해야 하는 4가지

ERD를 보면 선과 기호부터 보려고 하기 쉽지만, 먼저 다음 네 가지를 확인하는 것이 좋습니다.

구분	확인할 내용
엔터티	무엇을 관리하는가?
속성	어떤 정보를 가지고 있는가?
관계	서로 어떻게 연결되는가?
카디널리티	몇 개까지 연결될 수 있는가?

 

■ 엔터티와 속성 구분하기

예를 들어 다음과 같은 고객 데이터가 있다고 하겠습니다.

[고객]

• 고객번호
• 고객명
• 전화번호
• 주소

여기서

고객 = 엔터티

고객번호·고객명·전화번호·주소 = 속성

입니다.

 

■ 관계는 양쪽에서 읽어야 한다

ERD에서 매우 중요한 부분입니다.

예를 들어

고객 1 : N 주문

관계가 있다고 하겠습니다.

고객 기준으로 읽으면

“한 고객은 여러 주문을 할 수 있다.”

주문 기준으로 읽으면

“하나의 주문은 한 고객에게 속한다.”

가 됩니다.

 

따라서 ERD 관계는 한 방향으로만 읽는 것이 아니라 양쪽 엔터티를 기준으로 각각 해석하는 것이 중요합니다.

※ 카디널리티(Cardinality) : 엔터티 사이에서 몇 개의 데이터가 관계를 가질 수 있는지를 나타내는 개념입니다.

카디널리티의 구체적인 형태인 1:1, 1:N, N:M 과 최소·최대 관계수는 다음 14번에서 자세히 살펴보겠습니다.

 

---

14. IE 표기법과 Barker 표기법

ERD를 보면 엔터티 사이에 여러 모양의 선과 기호가 표시됩니다.

이 기호들은 단순한 장식이 아니라 “한 개가 연결되는지, 여러 개가 연결되는지”

그리고 “관계가 반드시 있어야 하는지, 없어도 되는지” 를 나타냅니다.

ERD를 표현하는 방식에는 여러 종류가 있으며 SQLD에서는 대표적으로 IE 표기법과 Barker 표기법을 알아둘 필요가 있습니다.

처음부터 기호를 외우기보다는 다음 순서로 이해하면 훨씬 쉽습니다.

관계 개수 이해 → 필수·선택 이해 → IE 표기법 → Barker 표기법 → 실제 관계 읽기

 

■ 먼저 관계의 개수부터 이해하기

ERD에서 가장 기본이 되는 관계는 다음 세 가지입니다.

관계	의미	대표 예시
1:1	하나 ↔ 하나	사람 ↔ 개인 사물함
1:N	하나 ↔ 여러 개	고객 ↔ 주문
N:M	여러 개 ↔ 여러 개	학생 ↔ 수업

 

① 1:1 관계

한쪽 데이터 하나가 다른 쪽 데이터 하나와 연결되는 관계입니다.

예를 들어 회사에서 직원에게 개인 사물함 하나만 배정한다고 가정해보겠습니다.

직원 1명 ↔ 개인 사물함 1개 이런 구조가 1:1 관계입니다.

 

② 1:N 관계

한쪽 데이터 하나가 다른 쪽의 여러 데이터와 연결될 수 있는 관계입니다.

가장 대표적인 예가 고객과 주문입니다.

고객 1명 → 주문 여러 건

고객 한 명은 여러 번 주문할 수 있지만 하나의 주문은 특정 고객의 주문입니다.

따라서  고객 1 : N 주문  관계가 됩니다.

 

③ N:M 관계

양쪽 모두 여러 데이터와 연결될 수 있는 관계입니다.

예를 들어 학생과 수업을 생각해보겠습니다.

학생 한 명 → 여러 수업 수강 가능

수업 하나 → 여러 학생 수강 가능

따라서  학생 N : M 수업  관계가 됩니다.

 

■ N:M 관계는 실제 DB에서 어떻게 만들까?

관계형 데이터베이스에서는 N:M 관계를 그대로 구현하기보다 중간 엔터티를 추가하여 두 개의 1:N 관계로 풀어내는 방식을 사용합니다.

예를 들어

학생 N : M 수업

관계 사이에 ‘수강’이라는 엔터티를 추가할 수 있습니다.

학생 1 : N 수강 N : 1 수업

수강 엔터티에는 다음과 같은 데이터를 저장할 수 있습니다.

수강 속성	내용
학생번호	어떤 학생인지
수업번호	어떤 수업인지
수강일자	언제 수강했는지
성적	해당 수업 성적

이렇게 중간 엔터티를 만들면 단순히 학생과 수업을 연결하는 것뿐만 아니라 관계 자체에서 발생하는 정보도 저장할 수 있습니다.

 

■ 그런데 1:N 만으로는 관계를 완전히 설명할 수 없다

예를 들어 다음 두 문장을 보겠습니다.

① 고객은 반드시 한 번 이상 주문해야 한다.

② 고객은 주문을 한 번도 하지 않을 수도 있다.

두 경우 모두 최대 주문 개수는 여러 개이므로 1:N 형태로 볼 수 있습니다.

하지만 의미는 분명히 다릅니다.

첫 번째는 주문이 반드시 존재해야 하고,

두 번째는 주문이 없어도 됩니다.

그래서 ERD에서는 관계의 최대 개수뿐만 아니라 최소 개수도 함께 표현합니다.

 

■ 최소값과 최대값 이해하기

관계를 다음 네 가지 형태로 정리하면 이해하기 쉽습니다.

표현	최소	최대	의미
0..1	0	1	없거나 하나
1..1	1	1	반드시 하나
0..N	0	N	없거나 여러 개
1..N	1	N	하나 이상 여러 개

예를 들어

“회원은 추천인이 없을 수도 있고 한 명만 등록할 수 있다.”

라고 한다면

0..1  입니다.

“주문은 반드시 고객 한 명에게 속한다.”

라고 한다면 

1..1  입니다.

“고객은 주문을 하지 않을 수도 있고 여러 번 주문할 수도 있다.”

라고 한다면

0..N  입니다.

“주문에는 상품이 하나 이상 포함되어야 한다.”

라고 한다면

1..N  형태로 이해할 수 있습니다.

 

■ Cardinality와 Optionality

여기서 SQLD 공부를 하다 보면 Cardinality와 Optionality라는 용어를 만나게 됩니다.

구분	쉽게 이해하기	확인하는 것
Cardinality	관계의 수	하나인가? 여러 개인가?
Optionality	관계의 필수 여부	반드시 있어야 하는가?

※ Cardinality(카디널리티) : 관계에 참여할 수 있는 데이터의 수를 의미합니다.

※ Optionality(옵셔널리티) : 해당 관계가 필수인지 선택인지를 의미합니다.

예를 들어

“고객은 주문을 하지 않을 수도 있고 여러 주문을 할 수도 있다.”

라고 한다면

Cardinality → 여러 개 가능

Optionality → 선택 가능

이라고 이해할 수 있습니다.

쉽게 질문으로 바꾸면 됩니다.

Cardinality = 몇 개까지 가능한가?

Optionality = 반드시 있어야 하는가?

 

■ IE 표기법이란?

IE는 Information Engineering의 약자입니다.

관계선 끝의 기호를 이용하여 최소 관계수와 최대 관계수를 표현합니다.

IE 표기법에서는 여러 개(Many)를 표현할 때 새의 발처럼 갈라진 Crow's Foot 형태의 기호를 사용합니다.

IE 표기에서 기본적으로 볼 기호

기호 개념	의미
○	0, 없어도 됨
｜	1
Crow's Foot	여러 개(N)

이 기호들을 조합하면 관계를 표현할 수 있습니다.

 

관계	의미
○ + ｜	0 또는 1
｜ + ｜	반드시 1
○ + Crow's Foot	0 또는 여러 개
｜ + Crow's Foot	1개 이상 여러 개

즉 IE 표기법에서는 관계선 끝을 볼 때

첫째, 0부터 가능한가? 1부터 시작하는가?

둘째, 최대 하나인가? 여러 개인가?

두 가지를 함께 확인하면 됩니다.

 

■ IE 표기법 예시

고객과 주문의 업무 규칙이 다음과 같다고 해보겠습니다.

“고객은 주문을 하지 않을 수도 있고 여러 번 주문할 수도 있다.”

“각 주문은 반드시 한 고객에게 속한다.”

이를 관계수로 정리하면 다음과 같습니다.

방향	관계
고객 → 주문	0..N
주문 → 고객	1..1

고객 입장에서는

주문 0건 가능 + 여러 건 가능 합니다.

하지만 주문 입장에서는 반드시 고객 한 명이 존재 해야 합니다.

이처럼 하나의 관계도 어느 쪽에서 읽느냐에 따라 의미가 달라집니다.

 

■ Barker 표기법이란?

Barker 표기법 역시 엔터티 사이의 관계를 표현하는 ERD 표기 방식입니다.

IE 표기법과 마찬가지로

• 하나인지 여러 개인지
• 관계가 필수인지 선택인지

를 표현하지만 기호를 표현하는 방식에 차이가 있습니다.

Barker 표기법에서는 관계의 필수 여부를 실선과 점선으로 표현하고, 여러 개(Many)는 Crow's Foot 형태로 표현합니다.

쉽게 말하면 Barker 표기법도 결국 다음 두 질문에 답하는 방식입니다.

① 반드시 관계가 존재해야 하는가?

② 하나인가, 여러 개인가?

예를 들어

“주문은 반드시 고객 한 명에게 속한다.”

라면  필수 + 하나  입니다.

반대로

“고객은 주문하지 않을 수도 있고 여러 주문을 할 수도 있다.”

라면  선택 + 여러 개  입니다.

 

■ IE 표기법과 Barker 표기법 차이

두 표기법은 그림 표현 방식에는 차이가 있지만 표현하려는 업무 규칙은 같습니다.

구분	IE  표기법	Barker 표기법
목적	엔터티 관계 표현	엔터티 관계 표현
관계수	1, Crow's Foot 등	1, Crow's Foot 등
선택 여부	○ 등의 기호 사용	관계선 표현으로 구분
핵심	관계 끝 기호 해석	관계선과 끝 기호 해석

따라서 시험 공부에서는

“IE는 이 그림, Barker는 저 그림”

식으로 무작정 암기하기보다,

먼저 업무 규칙을 읽은 뒤 관계를 해석하는 능력을 만드는 것이 중요합니다.

 

■ 필수 관계와 선택 관계

이제 필수 관계와 선택 관계를 실제 예시로 연결해보겠습니다.

구분	의미	예시
필수 관계	반드시 연결 대상 존재	주문에는 고객이 반드시 존재
선택 관계	연결 대상이 없어도 가능	고객은 주문이 0건일 수 있음

예를 들어

회원가입을 한 고객이 아직 아무 상품도 구매하지 않았다고 해보겠습니다.

고객 데이터는 존재하지만 주문 데이터는 없습니다.

따라서  고객 → 주문  관계에서 주문은 선택적으로 존재할 수 있습니다.

반대로 주문 데이터가 존재한다면 누가 주문했는지를 알아야 하는 업무 규칙이라고 가정할 수 있습니다.

따라서  주문 → 고객  관계에서는 고객이 필수가 됩니다.

 

■ 관계를 읽는 가장 쉬운 방법

ERD 기호를 보면 바로 기호 이름부터 생각하지 말고 다음 두 질문을 먼저 해보세요.

질문 1. 최소 몇 개인가?

0개도 가능한가?

아니면 최소 1개가 필요한가?

질문 2. 최대 몇 개인가?

1개까지만 가능한가?

아니면 여러 개가 가능한가?

이 두 질문만으로 대부분의 기본 관계를 구분할 수 있습니다.

최소	최대	관계
0	1	0..1
1	1	1..1
0	N	0..N
1	N	1..N

 

■ 관계 읽기 연습

다음 문장을 관계로 바꿔보겠습니다.

업무 규칙	관계
고객은 주문하지 않을 수도 있고 여러 번 주문할 수 있다	0..N
주문은 반드시 고객 한 명에게 속한다	1..1
직원은 반드시 하나의 부서에 소속된다	1..1
부서에는 직원이 없거나 여러 명 있을 수 있다	0..N
회원의 추천인은 없거나 한 명만 존재할 수 있다	0..1
주문에는 상품이 하나 이상 포함되어야 한다	1..N

문장에서 다음 표현을 찾으면 빠르게 판단할 수 있습니다.

“없을 수도 있다” → 최소 0

“반드시 있다” → 최소 1

“하나만” → 최대 1

“여러 개 가능” → 최대 N

 

■ 시험에서 기억할 핵심

IE 표기법과 Barker 표기법을 공부할 때 가장 중요한 것은 기호 자체보다 관계가 의미하는 업무 규칙을 읽는 것입니다.

다음 순서로 확인하면 됩니다.

1단계. 두 엔터티가 어떤 관계인지 확인

예) 고객 ↔ 주문

 

2단계. 한쪽에서 몇 개까지 연결되는지 확인

예) 고객 한 명 → 주문 여러 건

 

3단계. 관계가 없어도 되는지 확인

예) 주문하지 않은 고객도 존재 가능

 

4단계. 반대 방향에서도 다시 읽기

예) 주문 한 건 → 고객 한 명

 

최종적으로

고객 → 주문 = 0..N

주문 → 고객 = 1..1

처럼 해석할 수 있습니다.

 

■ 한 줄 요약

1:1 / 1:N / N:M = 관계의 큰 형태

0..1 / 1..1 / 0..N / 1..N = 최소·최대 관계수

Cardinality = 몇 개인가

Optionality = 필수인가 선택인가

IE·Barker = 이러한 관계를 ERD에서 표현하는 방법

---

15. 좋은 데이터 모델의 요소

좋은 데이터 모델은 단순히 ERD를 보기 좋게 만드는 것이 아닙니다.

실제 업무를 잘 표현하면서도 데이터 오류와 중복을 줄여야 합니다.

■ 대표적인 요소

요소	의미
완전성	필요한 데이터가 빠지지 않음
중복 최소화	같은 데이터를 반복 저장하지 않음
업무규칙 반영	실제 업무 기준을 구조에 반영
데이터 통합	같은 데이터를 일관된 기준으로 관리
명확성	데이터의 의미를 분명하게 표현
유연성	업무 변화에 대응 가능
의사소통	다른 사람도 구조를 이해할 수 있음

예를 들어 쇼핑몰인데 상품번호나 주문일자를 저장할 수 없다면 완전성이 부족합니다.

또 같은 고객을 부서별로 서로 다른 기준으로 관리한다면 데이터 통합이 부족하다고 볼 수 있습니다.

 

■ 좋은 데이터 모델인지 판단하는 질문

각 항목을 단순 암기하기보다 실제 설계를 보면서 다음 질문을 던져보면 이해하기 쉽습니다.

① 완전성

“업무에 필요한 데이터가 빠져 있지 않은가?”

예) 쇼핑몰인데 주문일자가 없다면 정상적인 주문관리가 어려울 수 있습니다.

 

② 중복 최소화

“같은 데이터를 여러 곳에 필요 이상 저장하고 있지 않은가?”

예) 고객 전화번호를 고객·주문·배송 테이블에 모두 반복 저장

 

③ 업무규칙 반영

“실제 업무 기준이 데이터 구조에 반영되어 있는가?”

예) 주문에는 반드시 주문 고객이 존재해야 한다.

 

④ 데이터 통합

“같은 데이터를 부서마다 서로 다른 기준으로 관리하고 있지 않은가?”

예)

영업팀 = 고객번호

쇼핑몰 = 회원번호

ERP = 거래처번호

 

⑤ 명확성

“데이터 이름만 보고 의미를 이해할 수 있는가?”

좋지 않은 예) 금액

좋은 예) 판매금액 / 할인금액 / 결제금액

 

⑥ 유연성

“업무가 조금 변경됐다고 데이터베이스 전체를 수정해야 하지는 않는가?”

사업과 서비스는 계속 변할 수 있기 때문에 데이터 모델도 변화에 대응할 수 있어야 합니다.

 

⑦ 의사소통
“데이터 모델을 만든 사람뿐 아니라 다른 사람도 구조를 이해할 수 있는가?”

데이터 모델은 개발자뿐 아니라 기획자, DBA, 데이터 담당자, 현업 담당자도 데이터 구조와 업무 관계를 이해할 수 있도록 표현하는 것이 좋습니다.

 

---

16. 주의사항 및 참고사항

SQLD 데이터 모델링을 공부할 때 단어만 외우면 쉽게 헷갈릴 수 있습니다.

예를 들어 

추상화 / 단순화 / 명확화

만 외우기보다

추상화 = 필요한 것만 선택

단순화 = 복잡한 것을 쉽게 표현

명확화 = 의미를 정확하게 표현

처럼 의미와 함께 기억하는 것이 좋습니다.

특히 다음 세 묶음을 연결해서 공부해보세요.

 

■ 데이터 모델링 단계

개념적 → 논리적 → 물리적

 

■ 스키마 단계

외부 → 개념 → 내부

 

■ 데이터 독립성

논리적 독립성 / 물리적 독립성

이 세 가지 구조를 구분해서 이해하면 시험문제를 풀 때 훨씬 정리가 잘 됩니다.

 

■ 시험 전 같이 구분해두면 좋은 개념

비교	핵심 차이
개념적 / 논리적 / 물리적	데이터 모델이 구체화되는 단계
외부 / 개념 / 내부 스키마	DB를 바라보는 계층
논리적 / 물리적 독립성	변경 영향의 범위
1:1 / 1:N / N:M	관계 가능한 개수
필수 / 선택	관계의 최소 참여 여부
Cardinality / Optionality	관계수 / 필수 여부
IE / Barker	ERD 관계 표현 방식

비슷하게 보이는 개념이 많기 때문에 각각이

모델링 단계인지

스키마 구조인지

관계 표현인지

먼저 구분하고 공부하면 훨씬 덜 헷갈립니다.

 

---

17. 요약 정리

이번 내용을 한 번에 정리해보겠습니다.

핵심 개념	요약
데이터 모델링	현실 업무를 데이터 구조로 표현
특징	추상화·단순화·명확화
관점	데이터·프로세스·상관관계
모델링 단계	개념적·논리적·물리적
스키마	외부·개념·내부
독립성	논리적·물리적
ERD	데이터 관계를 그림으로 표현
관계	1:1·1:N·N:M
좋은 모델	완전성·통합성·유연성 등

 

---

18. FAQ

Q1. SQLD인데 왜 데이터 모델링을 공부하나요?

SQL은 데이터베이스에 저장된 데이터를 사용하는 언어입니다.

따라서 고객, 주문, 상품 등이 어떤 구조로 연결되어 있는지 알아야 JOIN이나 데이터 조회 구조도 이해하기 쉬워집니다.

 

Q2. 데이터 모델링을 한 문장으로 설명하면 무엇인가요?

현실의 업무와 정보를 데이터베이스에 저장할 수 있는 구조로 바꾸는 과정입니다.

예를 들어 고객, 주문, 상품 관계를 테이블 구조로 설계하는 것입니다.

 

Q3. 개념적 모델링과 논리적 모델링은 어떻게 다른가요?

개념적 모델링은 큰 구조를 정하는 단계입니다.

예) 고객 / 주문 / 상품

논리적 모델링은 이를 구체화합니다.

예) 고객번호 / 주문번호 / 상품번호 / 주문일자

 

Q4. 기본키는 무엇인가요?

각 데이터를 서로 구분하기 위한 대표 값입니다.

예를 들어 고객번호 1001과 1002를 이용하면 서로 다른 고객을 구분할 수 있습니다.

 

Q5. 외래키는 무엇인가요?

다른 테이블과 관계를 연결하기 위해 사용하는 값입니다.

예를 들어 주문 테이블의 고객번호를 통해 해당 주문을 한 고객을 찾을 수 있습니다.

 

Q6. 외부 스키마는 화면을 뜻하나요?

단순히 화면 디자인만 의미하는 것은 아닙니다.

사용자 또는 프로그램이 필요한 데이터를 바라보는 관점이라고 이해하는 것이 좋습니다.

예를 들어 영업팀과 물류팀은 같은 데이터베이스를 사용해도 보는 데이터가 다를 수 있습니다.

 

Q7. 1:N 관계의 대표적인 예시는 무엇인가요?

고객과 주문입니다.

고객 한 명은 여러 번 주문할 수 있기 때문에

고객 1 : N 주문

관계로 볼 수 있습니다.

 

Q8. 필수 관계와 선택 관계는 어떻게 구분하나요?

반드시 관계가 존재해야 하면 필수 관계이고, 관계가 없어도 된다면 선택 관계입니다.

예를 들어 회원가입한 고객은 아직 주문하지 않았을 수도 있기 때문에 고객 입장에서 주문은 선택적으로 존재할 수 있습니다.

 

Q9. 논리적 독립성과 물리적 독립성은 어떻게 구분하나요?

논리적 독립성은 개념 구조의 변화가 사용자 관점에 미치는 영향을 줄이는 것입니다.

물리적 독립성은 실제 저장 구조의 변화가 전체 데이터 구조에 미치는 영향을 줄이는 것입니다.

 

Q10. ERD 공부는 어떻게 하는 것이 좋나요?

기호부터 외우기보다는 관계의 의미를 먼저 이해하는 것이 좋습니다.

고객 1명 → 여러 주문

학생 여러 명 ↔ 여러 수업

처럼 실제 사례를 먼저 이해하면 기호도 쉽게 연결됩니다.

 

---

19. 결론

SQLD 데이터 모델링은 처음에는 용어가 많아 어렵게 느껴질 수 있습니다.

하지만 전체 흐름을 이해하면 생각보다 단순합니다.

현실 업무 → 필요한 데이터 찾기 → 데이터 관계 정의 → 논리적 구조 설계 → 실제 데이터베이스 구현

이 과정이 데이터 모델링의 기본 흐름입니다.

그리고 이 과정에서 

1. 개념적·논리적·물리적 모델링

2. 외부·개념·내부 스키마

3. 논리적·물리적 데이터 독립성

4. ERD와 데이터 관계

등을 이해하게 됩니다.

SQLD를 공부할 때 각각의 용어를 따로 암기하기보다는 쇼핑몰의 고객, 주문, 상품 같은 하나의 예시를 계속 연결해서 공부하면 훨씬 이해하기 쉽습니다.

특히 이후 배우게 되는 엔터티, 속성, 관계, 식별자, 정규화, JOIN 등을 이해하기 위해서도 데이터 모델링의 기본 구조를 확실히 잡아두는 것이 좋습니다.