SQL 완전 정복 1편: 데이터모델링이란 무엇인가 — 모델링의 정의부터 ERD까지 완전 정리

들어가며

데이터베이스를 처음 공부할 때 가장 먼저 나오는 게 데이터모델링이다. 근데 막상 책을 펴면 "추상화, 명세화, 스키마..." 이런 단어들이 쏟아지면서 멈추게 된다.

이 글은 그 막히는 지점에서 시작한다. 어렵게 느껴지는 개념들을 최대한 쉽게 풀어서, 읽고 나면 "아, 이런 거구나"가 되도록 정리했다.

1. 모델링이란 뭔가

한 줄 정의

모델링은 복잡한 현실을 보기 좋게 정리하는 작업이다.

건축가가 건물 짓기 전에 설계도를 먼저 그리는 것처럼, 데이터베이스를 만들기 전에 데이터 구조를 그림으로 표현하는 게 바로 모델링이다. 설계도 없이 건물을 짓다가 기둥 위치가 잘못되면 전부 허물어야 한다. 데이터모델링을 먼저 하는 이유도 똑같다.

세 가지만 기억하면 된다. 현실을 있는 그대로 담는 게 아니라 필요한 것만 골라내고, 누구나 같은 방식으로 읽을 수 있는 약속된 표기법을 쓰고, 소통과 설계라는 목적이 있다.

모델 = 현실 세계를 목적에 맞게 압축한 표현

모델링의 종류

모델링이 데이터에만 쓰이는 개념은 아니다. 현실을 어떤 형식으로 표현하느냐에 따라 여러 분야에서 쓰인다.

정보시스템 모델링 — 업무 흐름과 데이터 구조를 도식화한다. ERD, UML이 여기 속한다.
수리 모델링 — 현실 현상을 수식으로 표현한다. 물리 공식, 경제 수식 같은 것들이다.
통계(확률) 모델링 — 데이터의 패턴을 확률로 표현한다. 회귀분석, 머신러닝 모델이 해당한다.
회로 모델링 — 전기·전자 회로를 도식으로 표현한다. 회로도, 논리 게이트가 여기다.

우리가 다루는 건 정보시스템 모델링, 그 중에서도 데이터 구조를 표현하는 데이터모델링이다.

모델링의 3가지 특징

좋은 모델에는 공통적으로 세 가지 특징이 있다.

추상화 (Abstraction)

현실의 모든 걸 담으려 하지 않는다. 고객 데이터를 모델링할 때 혈액형이나 취미는 안 담는다. 이름, 연락처, 주문 이력처럼 업무에 필요한 것만 골라내는 게 추상화다. 뭘 빼고 뭘 남길지 판단하는 능력이 곧 모델링 실력이다.

단순화 (Simplification)

복잡한 현실을 약속된 표기법으로 누구나 이해할 수 있게 표현한다. 수십 장의 문서로 설명해야 할 업무 구조도 ERD 한 장으로 표현하면 회의실에서 모두가 같은 그림을 보고 얘기할 수 있다.

명확화 (Clarity)

같은 모델을 보고 A와 B가 다르게 해석하면 그건 실패한 모델이다. 모호함을 없애고 누가 봐도 동일하게 읽히도록 정확하게 기술하는 것이 명확화다.

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

정보시스템을 모델링할 때 한 가지 시각으로만 보면 전체를 이해하기 어렵다. 세 가지 관점에서 함께 봐야 한다.

데이터 관점 (What) — 무엇을 다루는가

어떤 데이터가 있고, 그것들이 서로 어떻게 연결되는지를 본다. ERD가 이 관점의 대표 도구다.

프로세스 관점 (How) — 어떻게 처리되는가

업무가 어떤 순서로 흘러가는지를 본다. 어떤 조건에서 어떤 처리가 일어나고, 데이터가 어떻게 변환되는지를 파악한다. DFD(Data Flow Diagram), 플로우차트가 여기 쓰인다.

데이터와 프로세스의 상관 관점 (Interaction) — 무슨 데이터로 무엇을 하는가

어떤 데이터가 어떤 업무에서 쓰이는지, 어떤 업무가 어떤 데이터를 만들고 바꾸고 지우는지를 본다. CRUD Matrix가 대표적인 분석 도구다.

좋은 정보시스템 모델은 이 세 관점이 균형 있게 맞물린 구조를 가진다.

2. 데이터모델링이란 뭔가

정의

데이터모델링은 업무에서 필요한 데이터를 분석해서 데이터베이스 구조로 정의하는 전 과정이다.

단순히 테이블 만드는 작업이 아니다. 업무에서 어떤 데이터가 필요한지, 그 데이터들이 어떻게 연결되는지를 분석하고 표현하는 것까지 포함한다. 개발자, 기획자, DBA가 같은 그림을 보고 소통할 수 있게 만드는 공통 언어를 만드는 작업이기도 하다.

데이터 모델이 제공하는 6가지 기능

데이터 모델은 설계도 이상의 역할을 한다.

① 시스템 가시화 — 눈에 안 보이는 시스템 구조를 보이게 만든다.

② 구조와 행동 명세화 — 시스템이 어떤 구조로 어떻게 동작하는지를 명확히 정의한다. 개발의 기준점이 된다.

③ 구조화된 틀 제공 — 여러 사람이 협업해도 일관된 구조를 유지할 수 있는 기준을 준다.

④ 문서화 — 개발이 끝난 후에도 유지보수와 기능 추가 시 핵심 참고자료가 된다.

⑤ 다양한 관점 제공 — 기획자는 개념 모델로, 개발자는 물리 모델로 같은 시스템을 각자의 눈높이에서 볼 수 있다.

⑥ 상세 수준의 구체화 — 막연한 요구사항을 개념 → 논리 → 물리 단계로 점점 구체화한다.

데이터모델링이 중요한 3가지 이유

파급효과를 무시할 수 없다

데이터 모델은 시스템의 기초 공사다. 기초가 잘못되면 그 위에 쌓이는 모든 게 흔들린다. 개발이 절반쯤 진행된 시점에 데이터 모델을 바꾸면, 그 테이블을 참조하는 쿼리, API, 화면 로직을 전부 다시 짜야 한다. 초기 설계에 공을 들이는 게 결국 가장 싸게 먹히는 이유다.

복잡한 요구사항을 간결하게 표현한다

현실 업무의 요구사항은 복잡하다. 수백 가지 규칙과 예외가 뒤섞여 있다. 데이터모델링은 그 복잡함을 ERD 한 장으로 압축한다. 수십 장의 문서를 모델 하나로 대체하고, 모두가 같은 이해를 공유하게 만든다.

데이터 품질이 올라간다

잘 설계된 모델은 구조 자체가 잘못된 데이터의 진입을 막는 방어선이 된다. 제약 조건과 관계 정의를 통해 처음부터 잘못된 데이터를 차단한다. 데이터 품질은 사후에 관리하는 게 아니라 설계 단계에서 확보하는 것이다.

유의할 점 — 위험성을 낮추는 것이 핵심

중복을 최소화하라

같은 데이터가 여러 곳에 나눠 저장되면 반드시 문제가 생긴다. 고객 주소가 주문, 배송, 고객 테이블에 각각 저장돼 있다고 하면, 주소가 바뀔 때 세 곳을 모두 고쳐야 한다. 하나라도 빠뜨리면 데이터가 맞지 않는다. 이걸 데이터 이상 현상(Anomaly)이라 한다.

삽입 이상 — 데이터를 추가할 때 필요 없는 정보까지 함께 넣어야 하는 문제
수정 이상 — 중복된 데이터 중 일부만 수정돼서 불일치가 생기는 문제
삭제 이상 — 데이터를 지울 때 의도치 않은 정보까지 함께 사라지는 문제

정규화(Normalization)가 이 중복을 제거하는 핵심 기법이다.

비유연성을 낮춰라

지금 업무에만 딱 맞게 설계된 모델은 비즈니스가 바뀌는 순간 발목을 잡는다. 좋은 모델은 현재 요구사항을 충족하면서도 미래의 변화를 수용할 여지를 남겨둔다. 오늘의 완벽한 모델이 내일의 족쇄가 되지 않도록.

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

데이터모델링은 한 번에 끝나지 않는다. 추상적인 것에서 구체적인 것으로 단계를 밟아 내려간다.

        ┌──────────────────────┐
        │   개념적 데이터모델링  │  ← 가장 추상적 (업무 중심)
        └──────────────────────┘
                  ↓
        ┌────────────────────────────┐
        │    논리적 데이터모델링      │  ← 구조와 규칙 확정
        └────────────────────────────┘
                  ↓
        ┌──────────────────────────────────┐
        │      물리적 데이터모델링           │  ← 실제 DB 구현
        └──────────────────────────────────┘

1단계. 개념적 데이터모델링

"어떤 데이터가 있고, 어떻게 연결되는가"를 큰 그림으로 잡는 단계다. 기획자, 현업 담당자와 함께 만들며 특정 기술에 종속되지 않는다. "고객이 있고, 상품이 있고, 고객은 상품을 주문한다" 정도의 수준이다.

2단계. 논리적 데이터모델링

개념 모델을 구체화하는 단계다. 각 엔터티가 어떤 속성을 가지는지, 식별자(PK)가 뭔지, 관계가 어떻게 되는지를 확정한다. 정규화도 이 단계에서 적용한다. 아직 특정 DBMS에 종속되지 않는다.

3단계. 물리적 데이터모델링

논리 모델을 실제 DB에 구현하는 단계다. Oracle, MySQL, PostgreSQL 같은 특정 DBMS에 맞춰 테이블을 만들고, 인덱스와 파티셔닝도 고려한다. DDL(CREATE TABLE 등)이 이 단계의 결과물이다.

워터폴 방법론과의 연결

워터폴은 폭포처럼 위에서 아래로 순차적으로 진행하는 개발 방법론이다. 데이터모델링의 3단계가 이 흐름과 딱 맞아떨어진다.

워터폴 단계           데이터모델링
────────────────────────────────────────
요구사항 분석   →    개념적 데이터모델링
시스템 설계     →    논리적 데이터모델링
구현 / 개발     →    물리적 데이터모델링
테스트
운영 / 유지보수

앞 단계의 오류가 뒤에서 발견될수록 수정 비용이 기하급수적으로 커진다. 개념 설계를 잘못하면 논리 설계 전체를, 논리 설계를 잘못하면 물리 구현 전체를 갈아엎어야 한다. 파급효과가 바로 이것이다.

4. 데이터 독립성

왜 필요한가

서버 저장 장치를 HDD에서 SSD로 바꿨다고 개발자가 쿼리를 다시 짜야 한다면 문제가 있는 시스템이다. 데이터 독립성은 하위 단계의 구조가 바뀌어도 상위 단계에 영향을 주지 않는 성질이다. 독립성이 있어야 변경이 생겨도 영향 범위가 제한되고, 유지보수 비용이 낮아진다.

3단계 스키마 구조

데이터 독립성을 실현하기 위해 ANSI/SPARC이 제안한 아키텍처다. 세 계층으로 나눠서 각 계층이 서로 영향을 주지 않도록 설계한다.

┌─────────────────────────────────────────┐
│           외부 스키마 (External Schema)   │  ← 사용자 관점
│     사용자 A의 뷰  │  사용자 B의 뷰  │...  │
└──────────────────────┬──────────────────┘
                       ↕  논리적 독립성
┌──────────────────────┴──────────────────┐
│          개념 스키마 (Conceptual Schema)  │  ← 통합 관점
│          전체 데이터 구조와 관계 정의       │
└──────────────────────┬──────────────────┘
                       ↕  물리적 독립성
┌──────────────────────┴──────────────────┐
│          내부 스키마 (Internal Schema)    │  ← 물리적 단계
│         실제 데이터 저장 구조와 방식        │
└─────────────────────────────────────────┘

외부 스키마 — 사용자가 보는 뷰

사용자마다 자신에게 필요한 데이터만 보인다. 마케팅 팀은 고객 분석 뷰를, 물류 팀은 배송 현황 뷰를 사용한다. 하나의 DB에 외부 스키마는 여러 개가 존재할 수 있다.

개념 스키마 — 전체 데이터의 통합 지도

DBA가 정의하는 조직 전체의 데이터 구조다. 모든 외부 스키마의 기반이 되며, 물리적 저장 방식은 신경 쓰지 않는다. DB 하나에 개념 스키마는 반드시 하나다.

내부 스키마 — 실제 저장 방식

데이터가 디스크에 실제로 어떻게 저장되는지를 정의한다. 인덱스 구조, 파일 구성, 압축 방식 등 DBMS와 하드웨어에 가장 가까운 계층이다.

두 가지 독립성

독립성	의미	예시
논리적 독립성	개념 스키마 변경 → 외부 스키마 영향 없음	테이블 구조 변경 → 사용자 화면은 그대로
물리적 독립성	내부 스키마 변경 → 위 계층 영향 없음	저장 장치 교체 → 쿼리와 로직은 그대로

계층을 나누는 이유는 하나다. 변화가 위로 퍼져나가는 걸 막기 위해서.

5. 데이터모델링의 3가지 핵심 요소

데이터모델링은 결국 세 가지 질문에 답하는 작업이다.

업무에서 무엇을 다루는가? → 엔터티
그것은 어떤 성격을 가지는가? → 속성
그것들은 어떻게 연결되는가? → 관계

엔터티 (Entity) — 업무가 관여하는 어떤 것

엔터티는 업무에서 관리해야 할 대상이다. 실체가 있는 것(고객, 상품)뿐 아니라 개념적인 것(주문, 계약)도 될 수 있다.

여기서 중요한 구분이 있다.

구분	개념	예시
엔터티 타입 (복수)	같은 성격의 집합 전체	"고객"이라는 집합
인스턴스 (단수)	집합에 속하는 개별 하나	"홍길동"이라는 특정 고객

ERD에 그리는 네모 박스는 엔터티 타입(복수)이고, DB에 실제로 저장된 각 행(Row)이 인스턴스(단수)다.

속성 (Attribute) — 어떤 것이 가지는 성격

속성은 엔터티가 가지는 구체적인 특성이다.

구분	개념	예시
속성 타입 (복수)	특성의 이름	"이름"이라는 속성 항목
속성값 (단수)	실제 값	홍길동의 이름 = "홍길동"

속성 타입은 테이블의 열(Column) 이름이고, 속성값은 그 열에 담긴 실제 데이터다.

관계 (Relationship) — 어떤 것들 간의 연결

관계는 두 엔터티 사이의 업무적 연관성이다. 단순히 선을 잇는 게 아니라 카디널리티(몇 대 몇 관계인가)와 참여도(필수인가 선택인가)까지 포함한다.

구분	개념	예시
관계 타입 (복수)	엔터티 간의 연관 규칙	"고객은 상품을 주문한다"
관계 인스턴스 (단수)	실제 발생한 개별 연관	홍길동이 맥북을 주문한 그 건

 엔터티 타입 (고객)
    ├── 속성 타입: 이름, 이메일, 전화번호
    └── 관계: 고객 ──주문한다──▶ 상품

 인스턴스 (홍길동)
    ├── 속성값: "홍길동", "hong@example.com"
    └── 관계 인스턴스: 홍길동이 맥북을 주문한 특정 건

엔터티는 무엇, 속성은 성격, 관계는 연결. 셋이 맞물릴 때 데이터 모델이 완성된다.

6. ERD — 데이터 세계의 지도

ERD가 뭔가

ERD(Entity-Relationship Diagram)는 엔터티와 엔터티 간의 관계를 시각적으로 표현한 다이어그램이다. 1976년 피터 첸(Peter Chen)이 제안했고, 데이터 모델을 표현하는 국제 표준이 됐다.

ERD 하나로 시스템에 어떤 데이터가 있는지, 어떤 속성을 가지는지, 어떻게 연결되는지를 한눈에 파악할 수 있다. DB 만들기 전에 ERD부터 그리는 이유가 여기 있다.

ERD로 모델링하는 순서

1단계. 엔터티 도출 및 배치
       업무에서 관리할 대상을 찾아 박스로 그린다
               ↓
2단계. 엔터티 간 관계 설정
       업무적 연관이 있는 엔터티를 선으로 연결한다
               ↓
3단계. 관계명 기술
       관계를 동사로 표현한다 ("주문한다", "속한다")
               ↓
4단계. 관계의 참여도 기술
       필수인지 선택인지 표기한다
               ↓
5단계. 카디널리티 표기
       1:1 / 1:N / M:N 관계를 표기한다
               ↓
6단계. 속성 정의
       각 엔터티의 속성과 식별자(PK)를 정의한다

순서가 있는 이유가 있다. 속성보다 엔터티와 관계를 먼저 확정해야 전체 구조가 흔들리지 않는다. 관계 구조를 나중에 바꾸는 건 큰 파급효과를 낳는다.

IE 표기법 vs Barker 표기법

IE 표기법 (Crow's Foot)

관계선 끝 기호가 까마귀 발처럼 생겨서 Crow's Foot이라고도 부른다. 지금 가장 널리 쓰이는 표기법이다.

기호 의미
──────────────────────
  |    정확히 1 (필수)
  O    0 (선택적)
  <    여러 개 (N, 다수)

조합 예시
──────────────────────────────────────
  |──|    1 대 1  (필수)
  |──O    1 대 0 또는 1  (선택)
  |──<    1 대 여러 개  (1:N 필수)
  O──<    0 또는 1 대 여러 개  (1:N 선택)

예시: 고객과 주문

[고객] |───O< [주문]

→ 고객은 반드시 1명, 주문은 0건 이상 여러 건 가능

Barker 표기법

Richard Barker가 개발하고 Oracle CASE 툴이 채택했다. IE보다 직관적인 시각 언어를 쓴다.

항목	IE 표기법	Barker 표기법
엔터티 모양	날카로운 사각형	둥근 모서리 사각형
필수 관계	수직선 `\|`	실선 `——`
선택 관계	원 `O`	점선 `- -`
관계 이름	한 방향	양방향으로 동사구

Barker의 가장 큰 특징은 관계를 양방향으로 읽을 수 있다는 점이다.

[고객] ——주문한다——▶ [주문]
       ◀——속한다——

"고객은 주문을 한다" / "주문은 고객에 속한다" — 양쪽 방향 모두 자연스럽게 읽힌다.

ERD는 언어다. 표기법은 그 언어의 문법이다. 문법이 달라도 담는 내용은 같다.

7. 좋은 데이터 모델의 6가지 요소

모델은 그냥 그리면 되는 게 아니다. 잘 만든 모델과 못 만든 모델의 차이는 시스템이 운영되면서 서서히 드러난다.

요소	핵심 질문	왜 중요한가
완전성	필요한 데이터가 빠진 게 없는가?	모델에 없는 데이터는 시스템에도 없다
중복 배제	같은 데이터가 여러 곳에 저장되는가?	중복은 불일치와 이상 현상을 낳는다
업무 규칙	비즈니스 제약이 모델에 담겨 있는가?	코드에만 있는 규칙은 언제든 우회된다
데이터 재사용	여러 시스템이 같은 데이터를 쓸 수 있는가?	공통 데이터 설계가 시스템 통합을 쉽게 만든다
의사소통	기술자와 비기술자 모두 읽을 수 있는가?	모델은 기술 문서가 아니라 소통의 도구다
통합성	조직 어디서나 데이터의 의미가 같은가?	정의가 다르면 데이터를 합쳐도 숫자가 안 맞는다

이 여섯 가지를 갖춘 모델이 오래 살아남는 모델이다.

마치며

데이터모델링은 DB를 만들기 위한 준비 단계가 아니다. 업무를 이해하고, 데이터를 구조화하고, 시스템의 기반을 설계하는 핵심 작업이다.

모델링의 3가지 특징(추상화·단순화·명확화), 3단계(개념·논리·물리), 3가지 핵심 요소(엔터티·속성·관계), 그리고 좋은 모델의 6가지 조건. 이 개념들이 서로 연결된다는 걸 이해하면 데이터모델링은 암기 과목이 아니라 사고의 과목이 된다.

다음 편에서는 관계형 데이터베이스의 개요를 다룬다.