데이터베이스 모델링 3단계 총정리 - 개념적 · 논리적 · 물리적 모델링 차이(SQLD)

데이터베이스 모델링 3단계 총정리 - 개념적·논리적·물리적 모델링 차이와 예시

 

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

데이터베이스 공부를 시작하면 자주 등장하는 내용 중 하나가 바로 개념적 데이터 모델링, 논리적 데이터 모델링, 물리적 데이터 모델링​입니다.

처음 보면 이름도 비슷해서 이런 생각이 들 수 있습니다.

“개념적이랑 논리적은 대체 뭐가 다른 거지?”

“테이블을 만드는 건 논리적인 걸까, 물리적인 걸까?”

“ERD(Entity Relationship Diagram)는 어느 단계에서 만드는 거지?”

저도 처음 공부할 때 단순히

개념적 → 논리적 → 물리적

순서만 외우면 금방 헷갈리더라고요.

그래서 이번 글에서는 데이터베이스를 실제로 구축한다고 생각하고,

1. 개념적·논리적·물리적 모델링의 차이
2. 하나의 업무가 실제 DB(Database) 구조로 바뀌는 과정
3. SQLD 시험이나 실무에서 헷갈리기 쉬운 부분

을 예시와 함께 쉽게 정리해보겠습니다.

 

---

 

한눈에 보는 목차

1. 데이터 모델링 3단계란?
2. 개념적 데이터 모델링이란?
3. 논리적 데이터 모델링이란?
4. 물리적 데이터 모델링이란?
5. 하나의 예제로 3단계 비교하기
6. 개념적·논리적·물리적 모델링 비교
7. ERD는 어느 단계에서 작성할까?
8. 실무에서 모델링이 필요한 이유
9. 주의사항 및 참고사항
10. 요약 정리
11. FAQ
12. 결론
13. 내 글들 중 관련있는 정보

 

 

---

1. 데이터 모델링 3단계란?

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

쉽게 말하면, 사람이 이해하는 업무를 컴퓨터가 관리할 수 있는 데이터 구조로 바꾸는 과정 이라고 보면 됩니다.

IBM에서는 데이터 모델을 추상화 수준에 따라 일반적으로 개념적 모델 → 논리적 모델 → 물리적 모델 순으로 구분하고 있습니다. 단계가 진행될수록 구조가 더 구체적으로 바뀝니다.

아주 쉽게 표현하면 다음과 같습니다.

단계	핵심 질문
개념적	무엇이 필요한가?
논리적	어떻게 연결할까?
물리적	실제 DB에 어떻게 만들까?

표만 보면 간단하지만 실제 차이를 이해하는 것이 중요합니다.

예를 들어 온라인 쇼핑몰을 만든다고 생각해보겠습니다.

처음부터 개발자가 다음과 같이 시작하지는 않습니다.

 

먼저, “우리 쇼핑몰에서는 고객, 상품, 주문을 관리해야 한다.”

라는 업무 개념부터 정리해야 합니다.

그 다음 고객과 주문이 어떻게 연결되는지 설계하고, 마지막에 실제 데이터베이스의 테이블과 컬럼으로 구현하게 됩니다.

즉, 업무 이해 → 데이터 구조 설계 → 실제 DB 구현 이라는 흐름입니다.

 

 

---

 

2. 개념적 데이터 모델링이란?

개념적 데이터 모델링(Conceptual Data Modeling)은 가장 큰 업무 구조를 정하는 단계입니다.

※ Conceptual = 개념적인, 큰 개념 중심의

이 단계에서는 데이터베이스에 어떤 테이블명을 사용할지보다

“우리 업무에서 무엇을 관리해야 하는가?” 를 먼저 생각합니다.

IBM은 개념적 데이터 모델을 시스템에 무엇이 포함되고 주요 개념들이 어떻게 구성되는지를 보여주는 상위 수준의 모델로 설명합니다.

예를 들어 쇼핑몰을 만든다면 주요 관리 대상은 다음과 같이 생각할 수 있습니다.

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

이것들을 데이터 모델링에서는 보통 엔터티(Entity)​라고 부릅니다.

※ Entity(엔터티) : 업무에서 관리해야 하는 사람, 사물, 사건 등의 데이터 대상

그리고 엔터티 사이의 큰 관계를 생각합니다.

• 고객 → 주문
• 주문 → 상품
• 주문 → 결제
• 주문 → 배송

이 단계에서는 보통 세부적인 컬럼이나 인덱스까지 결정하지 않습니다.

쉽게 말하면 집을 짓는다고 생각하면 개념적 모델링은 “방이 필요하고, 화장실이 필요하고, 거실이 필요하다.”

정도를 정하는 단계와 비슷합니다.

아직 콘크리트를 어떤 제품으로 사용할지, 전선을 어디에 설치할지는 정하지 않습니다.

데이터베이스도 마찬가지입니다.

개념적 모델링에서는 먼저 업무의 큰 그림을 만드는 것이 핵심입니다.

 

 

---

3. 논리적 데이터 모델링이란?

논리적 데이터 모델링(Logical Data Modeling)은 개념적으로 정리한 업무를 보다 구체적인 데이터 구조로 만드는 단계입니다.

※ Logical = 논리적인, 구조와 관계를 체계적으로 정리하는 것

예를 들어 개념 모델에서 단순히

• 고객
• 주문

이라고 정했다면 논리 모델에서는 각각 어떤 정보를 관리해야 하는지 구체화합니다.

고객 엔터티

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

 

주문 엔터티

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

여기서부터 속성(Attribute)​이 등장합니다.

※ Attribute(속성) : 엔터티를 설명하는 세부 정보

예를 들어 고객이라는 엔터티가 있다면,

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

등이 고객의 속성이 됩니다.

그리고 어떤 값으로 데이터를 구분할지도 정합니다.

 

기본키

기본키(PK, Primary Key)는 각 데이터를 구분하는 대표적인 값입니다.

※ PK = Primary Key, 기본키

예를 들어 고객번호가 1001, 1002, 1003처럼 존재한다면 고객번호를 이용해 각각의 고객을 구분할 수 있습니다.

 

외래키

외래키(FK, Foreign Key)는 다른 데이터와 관계를 연결하기 위해 사용하는 값입니다.

※ FK = Foreign Key, 외래키

예를 들어 주문 데이터에 고객번호가 들어 있다면

고객번호를 이용해  “이 주문을 누가 했는가?” 를 확인할 수 있습니다.

 

고객

고객번호 : 1001
고객명 : 홍길동

 

주문

주문번호 : 5001
고객번호 : 1001

이렇게 되어 있다면 주문번호 5001은 고객번호 1001의 주문이라는 관계를 만들 수 있습니다.

논리 모델에서는 이처럼 엔터티, 속성, 식별자, 관계 및 데이터 규칙 등을 구체화합니다.

SAP 역시 논리적 데이터 모델은 개념적 모델보다 상세한 구조를 정의하지만 특정 데이터베이스 기술에 종속되지 않는 단계라고 설명합니다.

이 부분이 중요합니다.

 

논리적 모델링은 상당히 구체적이지만 아직 특정 DBMS에 맞춰 구현하는 단계는 아닙니다.

※ DBMS = Database Management System, 데이터베이스 관리 시스템

 

예)

Oracle Database
MySQL
Microsoft SQL Server
PostgreSQL

등이 DBMS에 해당합니다.

 

 

---

4. 물리적 데이터 모델링이란?

물리적 데이터 모델링(Physical Data Modeling)은 논리적으로 설계한 데이터를 실제 데이터베이스에 구현할 수 있도록 만드는 단계입니다.

※ Physical = 실제 구현과 저장 구조를 고려하는 것

이 단계부터는 실제 개발과 상당히 가까워집니다.

예를 들어 논리 모델에서 다음과 같이 정의했다고 생각해보겠습니다.

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

물리 모델에서는 실제 DB 컬럼을 다음처럼 만들 수 있습니다.

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

그리고 단순히 컬럼 이름만 정하는 것이 아닙니다.

실제 DBMS에서 사용할 데이터 타입, 키, 인덱스, 제약조건, 저장 및 성능 관련 사항도 고려합니다.

IBM은 물리적 데이터 모델을 실제 데이터베이스 안에서 데이터가 어떻게 저장될지 정의하는 가장 구체적인 단계로 설명하고 있으며, DBMS별 속성과 성능 튜닝 요소가 포함될 수 있다고 설명합니다.

Oracle의 설명에서도 물리 설계 단계에서는 논리 모델의 엔터티를 테이블로, 속성을 컬럼으로, 관계를 외래키 제약조건 등으로 변환한다고 설명합니다.

예를 들어 실제 구현에서는 다음과 같은 부분까지 고민할 수 있습니다.

CUSTOMER_ID는 숫자인가 문자인가?

CUSTOMER_NAME은 어느 정도 길이까지 저장할 것인가?

CUSTOMER_ID에 Primary Key를 설정할 것인가?

검색이 많은 컬럼에 Index를 사용할 것인가?

즉 물리적 모델링은

설계도를 실제 데이터베이스에 건설할 수 있도록 만드는 단계

라고 이해하면 쉽습니다.

 

 

---

5. 하나의 예제로 3단계 비교하기

이번에는 쇼핑몰의 주문 업무 하나만 가지고 세 단계를 연결해보겠습니다.

 

개념적 모델링

먼저 어떤 데이터를 관리해야 하는지 생각합니다.

• 고객
• 주문
• 상품

그리고 큰 관계를 정합니다.

고객 → 주문 → 상품

여기까지는 업무 담당자도 충분히 이해할 수 있는 수준입니다.

 

논리적 모델링

이제 각각의 데이터를 구체화합니다.

고객

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

 

주문

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

 

상품

• 상품번호
• 상품명
• 판매가격

그리고 관계를 정의합니다.

고객 1명은 여러 주문을 할 수 있습니다.

따라서  고객 1 : N 주문 관계를 만들 수 있습니다.

※ 1:N (One-to-Many) : 하나의 데이터가 여러 데이터와 연결될 수 있는 관계

 

물리적 모델링

마지막으로 실제 DB 테이블과 컬럼을 설계합니다.

CUSTOMERS

• CUSTOMER_ID
• CUSTOMER_NAME
• PHONE_NUMBER

 

ORDERS

• ORDER_ID
• CUSTOMER_ID
• ORDER_DATE
• ORDER_STATUS

 

PRODUCTS

• PRODUCT_ID
• PRODUCT_NAME
• SALE_PRICE

 

이후 사용하는 DBMS에 맞게 데이터 타입, 기본키, 외래키, 인덱스 등을 실제 구현 가능한 형태로 결정합니다.

즉 같은 업무가  고객 → 고객 엔터티 → CUSTOMER 테이블 처럼 점점 구체화되는 것입니다.

 

 

---

6. 개념적·논리적·물리적 모델링 비교

세 단계에서 가장 중요한 부분만 비교해보겠습니다.

구분	개념적	논리적	물리적
목적	큰 구조	상세 구조	실제 구현
중심	업무	데이터	DB
상세도	낮음	중간~높음	가장 높음
기술 종속	낮음	낮음	높음

조금 더 쉽게 외우면 다음 세 문장으로 정리할 수 있습니다.

개념적 = 무엇이 필요한가?

논리적 = 어떤 데이터 구조로 연결할 것인가?

물리적 = 실제 데이터베이스에 어떻게 구현할 것인가?

SQLD를 공부한다면 이 세 문장을 먼저 기억한 뒤 세부 내용을 연결하는 방법이 이해하기 쉽습니다.

 

---

7. ERD는 어느 단계에서 작성할까?

여기서 많이 헷갈리는 것이 ERD입니다.

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

※ ERD = Entity Relationship Diagram, 개체-관계 다이어그램

쉽게 말하면

데이터 대상과 데이터 사이의 관계를 그림으로 표현한 것 입니다.

그런데 “ERD는 개념적 모델링인가요? 논리적 모델링인가요?”

라고 물으면 단순히 한 단계에만 사용된다고 설명하기에는 부족합니다.

IBM은 ER 모델 역시 개념적, 논리적, 물리적 수준으로 구분할 수 있다고 설명합니다. 개념 수준에서는 주요 엔터티와 관계를 중심으로 표현하고, 논리 수준에서는 속성 등의 상세 구조를 추가하며, 물리 수준에서는 실제 데이터베이스 설계에 필요한 구체적인 정보를 표현할 수 있습니다.

즉,

ERD 자체가 특정 한 단계만 의미하는 것은 아닙니다.

어느 정도 상세하게 표현하느냐에 따라 개념 ERD, 논리 ERD, 물리 ERD처럼 구분할 수 있습니다.

 

---

8. 실무에서 모델링이 필요한 이유

데이터 모델링은 시험을 위해서만 배우는 내용이 아닙니다.

회사에서 새로운 시스템을 구축한다고 생각해보겠습니다.

 

영업팀에서는 “고객별 판매 내역을 보고 싶습니다.” 라고 요청할 수 있습니다.

 

물류팀에서는  “어떤 상품이 어떤 창고에 있는지 관리해야 합니다.” 라고 할 수 있습니다.

 

CS팀에서는  “어떤 고객이 어떤 상품을 구매했고 언제 반품했는지 확인하고 싶습니다.” 라고 요청할 수 있습니다.

이런 요구사항을 개발자에게 바로 전달해서 테이블부터 만들면 나중에 데이터 구조가 꼬일 가능성이 있습니다.

 

먼저 주요 업무를 정리하고,

• 고객
• 상품
• 주문
• 재고
• 배송
• 반품

같은 관리 대상을 찾습니다.

그 다음 이 데이터들이 어떤 관계를 갖는지 설계합니다.

마지막으로 실제 DB 테이블로 구현합니다.

이것이 개념 → 논리 → 물리 모델링을 사용하는 이유입니다.

데이터 모델링은 개발자뿐만 아니라 비즈니스 담당자와 데이터 담당자가 같은 구조를 보면서 의사소통하는 데에도 도움이 됩니다. IBM 역시 데이터 모델링의 장점으로 개발자, 데이터 아키텍트, 비즈니스 분석가 등 이해관계자 사이의 데이터 관계 이해와 의사소통 개선을 설명하고 있습니다.

 

---

9. 주의사항 및 참고사항

개념적·논리적·물리적 모델링을 공부할 때 한 가지 주의할 점이 있습니다.

자료나 회사에서 사용하는 방법론에 따라 각 단계에서 어디까지 정의하는지 세부적인 범위가 조금씩 다를 수 있습니다.

예를 들어 일부 모델링 방법론이나 도구에서는 논리 모델 단계에서 데이터 타입이나 길이에 관한 정보를 비교적 상세하게 관리하기도 합니다.

따라서  “논리 모델에서는 절대로 이것을 하면 안 된다.” 처럼 지나치게 절대적인 기준으로 외우기보다는 각 단계의 목적과 추상화 수준을 기준으로 이해하는 것이 좋습니다. IBM 자료에서도 논리 모델은 상세한 데이터 구조를 표현하지만 기술 시스템 요구사항은 지정하지 않는다는 특징을 설명하고 있습니다.

 

핵심은 다음과 같습니다.

• 개념적 모델링은 업무 중심
• 논리적 모델링은 데이터 구조 중심
• 물리적 모델링은 실제 DB 구현 중심

이 기준만 정확하게 알고 있으면 대부분의 문제를 구분하기 쉬워집니다.

 

---

10. 요약 정리

이번 내용을 가장 간단하게 정리하면 다음과 같습니다.

단계	기억할 것
개념적	무엇을 관리할까?
논리적	어떻게 구조화할까?
물리적	실제 DB에 어떻게 만들까?

개념적 모델링에서는 고객, 주문, 상품과 같은 큰 업무 대상을 찾습니다.

논리적 모델링에서는 고객번호, 주문번호 등의 속성과 키, 관계를 구체적으로 설계합니다.

물리적 모델링에서는 실제 테이블명, 컬럼명, 데이터 타입, 인덱스, 제약조건 등 DB 구현에 필요한 구조를 결정합니다.

따라서 데이터 모델링은

현실의 업무 → 개념적 구조 → 논리적 데이터 구조 → 실제 데이터베이스

로 구체화하는 과정이라고 이해하면 됩니다.

 

 

---

11. FAQ

 

Q1. 데이터 모델링의 3단계는 무엇인가요?

개념적 데이터 모델링, 논리적 데이터 모델링, 물리적 데이터 모델링입니다.

예를 들어 쇼핑몰을 만든다면 고객·주문·상품이라는 큰 구조를 찾고, 각 데이터의 속성과 관계를 정한 다음 실제 DB 테이블로 만드는 흐름입니다.

 

Q2. 개념적 모델링에서 가장 중요한 것은 무엇인가요?

업무에서 어떤 데이터를 관리해야 하는지 파악하는 것입니다.

예를 들어 쇼핑몰이라면 고객, 주문, 상품, 결제, 배송 등이 주요 관리 대상이 될 수 있습니다.

 

Q3. 논리적 모델링에서는 무엇을 하나요?

엔터티의 속성, 식별자, 관계 및 데이터 구조를 보다 구체적으로 설계합니다.

예를 들어 고객 엔터티에 고객번호, 고객명, 전화번호 등의 속성을 정의하는 것입니다.

 

Q4. 물리적 모델링에서는 무엇을 하나요?

실제 DBMS에서 구현할 수 있도록 테이블, 컬럼, 데이터 타입, 키, 인덱스, 제약조건 등을 구체화합니다.

예를 들어 논리적인 ‘고객번호’를 실제 DB에서 CUSTOMER_ID라는 컬럼으로 구현하는 방식입니다.

 

Q5. 논리적 모델링과 물리적 모델링 차이가 무엇인가요?

가장 큰 차이는 실제 기술 환경에 대한 의존 여부입니다.

논리 모델은 업무 데이터 구조 자체에 초점을 두는 반면, 물리 모델은 실제 사용하는 DBMS의 구현 환경까지 고려합니다.

 

Q6. ERD는 논리적 모델링에서만 사용하나요?

그렇게 단정하기 어렵습니다.

ERD는 개념적·논리적·물리적 수준에서 각각 작성할 수 있으며 상세도와 목적이 달라질 수 있습니다.

 

Q7. 개념적 모델링을 생략하고 바로 테이블을 만들면 안 되나요?

작은 시스템에서는 간단하게 진행하는 경우도 있을 수 있습니다.

하지만 요구사항과 데이터 관계를 충분히 검토하지 않은 상태에서 바로 테이블을 만들면 향후 구조 변경이나 데이터 중복 문제가 생길 가능성이 있습니다.

예를 들어 처음부터 고객 정보를 주문 테이블에 모두 반복 저장하면 고객 정보 변경이나 통합 관리가 어려워질 수 있습니다.

 

Q8. 세 단계 중 가장 상세한 단계는 무엇인가요?

물리적 데이터 모델링입니다.

개념적 모델에서 물리적 모델로 진행될수록 실제 데이터베이스 구현에 필요한 정보가 구체화됩니다.

 

Q9. SQLD에서는 왜 이 내용을 공부하나요?

SQL은 이미 만들어진 데이터베이스 구조를 이용해 데이터를 조회하거나 처리하는 언어입니다.

따라서 테이블과 키, 관계가 왜 그렇게 설계됐는지를 이해하면 JOIN이나 관계형 데이터베이스 구조를 이해하는 데 도움이 됩니다.

 

Q10. 세 단계를 가장 쉽게 외우는 방법은 무엇인가요?

다음 세 질문으로 기억하면 쉽습니다.

• 개념적 : 무엇이 필요하지?
• 논리적 : 어떻게 연결하지?
• 물리적 : 실제 DB에 어떻게 만들지?

예를 들어 고객이라는 업무 대상을 찾는 것은 개념적, 고객번호와 주문 관계를 설계하는 것은 논리적, CUSTOMER_ID 컬럼으로 실제 구현하는 것은 물리적 모델링이라고 연결해서 기억하면 됩니다.

 

 

---

12. 결론

처음 데이터 모델링을 공부하면 개념적, 논리적, 물리적이라는 용어 자체가 어렵게 느껴질 수 있습니다.

하지만 실제 시스템을 만드는 순서로 생각하면 의외로 단순합니다.

먼저 무엇을 관리해야 하는지 찾고,
그 데이터를 어떤 구조와 관계로 만들지 설계하고,
마지막으로 실제 데이터베이스에 구현합니다.

즉,

개념 → 구조 → 구현 이라고 이해하면 됩니다.

특히 SQLD를 공부한다면 세 단계의 이름만 외우기보다 쇼핑몰의 고객·주문·상품처럼 하나의 사례를 가지고 단계별로 직접 바꿔보는 것이 훨씬 이해하기 쉽습니다.

다음에 ERD를 보거나 실제 데이터베이스 테이블을 볼 때도

“이 구조는 어떤 업무에서 시작돼서 여기까지 온 것일까?”

라고 생각해보면 데이터 모델링을 이해하는 데 도움이 될 겁니다.

 

 

---

 

SQLD 데이터 모델링 전체 내용을 처음부터 정리하고 싶다면 아래 글도 함께 보면 좋습니다.

SQLD 데이터 모델링 총정리 - 초보자를 위한 개념과 예시 (정리 完)
https://yobb.tistory.com/200

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

 

위 글에서는 데이터 모델링 3단계뿐만 아니라 데이터 모델링의 특징, 데이터 독립성, 외부·개념·내부 스키마, ERD, IE/Barker 표기법 등 SQLD 데이터 모델링 전반을 함께 정리했습니다.