01.데이터 모델링의 이해

•

데이터 모델링이 "무엇을, 왜" 하는 작업인지 한 문장으로 설명할 수 있다.

•

개념적 → 논리적 → 물리적 모델링의 순서와 각 단계의 산출물을 구분할 수 있다.

•

3층 스키마와 두 가지 데이터 독립성(논리적/물리적)을 예로 들어 설명할 수 있다.

•

ERD를 읽고 테이블 관계를 파악할 수 있다.

1. 데이터 모델링이란?

1) 정의

•

현실 세계의 업무를 약속된 표기법으로 표현하는 과정

•

정보시스템을 만들기 위해 어떤 데이터가 존재하는지, 데이터끼리 어떤 관계인지를 그림과 규칙으로 정리하는 일

 쉽게 말하면
집을 짓기 전에 설계도를 그리는 것과 같습니다.
설계도 없이 벽돌부터 쌓으면(= 테이블부터 만들면) 나중에 반드시 부수고 다시 지어야 합니다.
데이터 모델링은 DB를 만들기 전에 그리는 설계도 작업입니다.

2) 데이터 모델링의 3가지 관점

관점	무엇을 보는가	질문 형태	산출물
데이터 관점 (What, Data)	업무가 어떤 데이터를 사용하는가	"선수 정보에는 무엇이 필요하지?"	데이터 모델(ERD)
프로세스 관점 (How, Process)	업무가 어떤 일을 하는가	"선수를 어떻게 등록하지?"	프로세스 모델
데이터와 프로세스의 상관 관점 (Interaction)	프로세스가 데이터에 어떤 영향을 주는가	"등록하면 어느 테이블이 바뀌지?"	CRUD 매트릭스

시험 포인트: "관점 3가지"를 고르는 문제가 자주 나옵니다. 데이터 / 프로세스 / 상관 세 단어를 반드시 외우세요.

3) 데이터 모델링의 특징 (3가지)

특징	의미	예시
추상화 (Abstraction)	현실을 일정한 형식으로 간략히 표현	선수 → PLAYER 테이블
단순화 (Simplification)	누구나 이해하도록 약속된 표기법으로 표현	ERD 기호 사용
명확화 (Clarity)	뜻이 애매하지 않게 정확히 표현	"이름" → PLAYER_NAME(한글명), E_PLAYER_NAME(영문명)

4) 데이터 모델링 시 유의점 (3가지)

유의점	문제 상황	결과
중복 (Duplication)	같은 데이터를 여러 테이블에 저장	한 곳만 수정하면 값이 서로 달라짐
비유연성 (Inflexibility)	데이터 정의와 프로세스가 강하게 결합됨	작은 업무 변경에도 시스템 전체를 고쳐야 함
비일관성 (Inconsistency)	데이터 간 상호 연관 관계를 명시하지 않음	서로 모순된 값이 저장됨

 자주 틀리는 함정비유연성 = 변경에 약한 것, 비일관성 = 값이 서로 안 맞는 것.
두 단어를 바꿔치기한 선지가 매년 나옵니다.

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

1) 단계별 흐름

단계	추상화	하는 일	산출물	특징
개념적 모델링	높음	업무에서 핵심 엔터티를 뽑음	개념 ERD	전사적·포괄적, DBMS 무관
논리적 모델링	중간	속성·관계·식별자 정의, 정규화	논리 ERD	재사용성이 가장 높음 , DBMS 무관
물리적 모델링	낮음	데이터 타입·인덱스·성능 고려	테이블 정의서, DDL	특정 DBMS에 종속

 시험 포인트

•

순서는 개념 → 논리 → 물리

•

재사용성이 가장 높은 단계 = 논리적 데이터 모델링

•

물리적 단계에서만 DBMS 종류(Oracle, MySQL…)를 신경 씀

2) 단계가 실제로 구체화되는 모습

"K-리그 축구팀 관리 시스템"이라는 하나의 업무가 단계를 거치며 어떻게 구체화되는지, 각 단계의 실제 산출물을 보면서 따라가 봅시다.

1단계: 개념적 모델링 — "무엇이 있는가"만 정한다

현업 담당자와 인터뷰한 내용입니다.

"우리는 경기장을 관리하고, 팀을 관리하고, 팀에 소속된 선수를 관리합니다.
그리고 어느 경기장에서 언제 경기하는지 경기일정도 관리해야 합니다."

이 대화에서 명사만 뽑아 사각형으로 그린 것이 개념 모델입니다. 속성(컬럼)도, 식별자도, 데이터 타입도 아직 하나도 정하지 않습니다.

개념 모델의 산출물 = "핵심 엔터티 목록" 딱 이만큼

엔터티(한글명)	설명	왜 엔터티인가
경기장	경기가 열리는 장소	관리할 정보가 있고, 여러 건 존재
팀	K-리그 소속 구단	관리할 정보가 있고, 여러 건 존재
선수	팀에 소속된 선수	관리할 정보가 있고, 여러 건 존재
경기일정	언제 어디서 하는 경기인지	관리할 정보가 있고, 여러 건 존재

 여기서 절대 하지 않는 일
"팀ID는 몇 자리로 할까?", "창단연도는 숫자형일까 문자형일까?" → 아직 생각하지 않습니다.
개념 단계의 목표는 오직 "우리 업무의 주인공(엔터티)이 누구인지" 를 빠짐없이 찾는 것입니다.

2단계: 논리적 모델링 — "어떤 정보를, 무엇으로 구분할지" 정한다

각 엔터티에 속성을 붙이고, 어떤 속성으로 한 건을 구분할지(식별자) 를 정합니다. 그리고 정규화를 수행해 중복을 제거합니다. 아직 Oracle인지 MySQL인지는 신경 쓰지 않습니다.

논리 모델 산출물 ① — 속성 정의서 (팀 엔터티)

속성명(한글)	식별자	도메인(논리적 자료형)	필수 여부	설명
팀ID	주식별자(PK)	문자	필수	팀을 구분하는 값 (예: K01)
지역명		문자	필수	연고 지역 (예: 성남)
팀명		문자	필수	구단 정식 명칭
창단연도		문자	선택	4자리 연도
경기장ID	외래식별자(FK)	문자	필수	홈으로 쓰는 경기장

논리 모델 산출물 ② — 속성이 붙은 ERD

논리 모델에서 정규화가 일어나는 장면 (중복 제거)

정규화 전에는 이런 표를 쓰고 있었다고 해봅시다.

선수ID	선수명	팀ID	팀명	경기장명
2012001	김철수	K01	성남일화천마	성남종합운동장
2012002	이영희	K01	성남일화천마	성남종합운동장
2012003	박민수	K02	수원삼성블루윙즈	수원월드컵경기장

•

 문제: 팀명이 바뀌면 선수 수만큼 전부 수정해야 하고, 하나라도 놓치면 비일관성 발생

•

 해결: 팀 정보는 팀 엔터티로 분리하고, 선수는 팀ID만 가진다 → 이것이 정규화

 이 단계가 시험에서 "재사용성이 가장 높다"고 하는 이유
Oracle을 쓰든 MySQL을 쓰든 위 ERD와 속성 정의서는 그대로 재사용할 수 있기 때문입니다.

🅲 3단계: 물리적 모델링 — "실제 DBMS에서 어떻게 만들지" 정한다

이제야 처음으로 Oracle이라는 특정 DBMS를 전제하고, 한글 논리명을 영문 컬럼명으로, 논리적 도메인("문자")을 실제 데이터 타입으로 바꿉니다.

변환 규칙 — 논리 모델의 무엇이 물리 모델의 무엇이 되는가

논리 모델		물리 모델
엔터티명 (팀)		테이블명 TEAM
속성명 (팀ID)		컬럼명 TEAM_ID
도메인 (문자)		데이터 타입 CHAR(3), VARCHAR2(40)
주식별자		PRIMARY KEY 제약조건
관계(선)		FOREIGN KEY 제약조건
— (논리에는 없음)		인덱스 — 물리 단계에만 존재

데이터 타입을 정하는 판단 (물리 단계에서만 하는 고민)

컬럼	선택한 타입	왜 그렇게 정했나
TEAM_ID	CHAR(3)	항상 3자리 고정 → 가변길이보다 유리
REGION_NAME	VARCHAR2(8)	지역명 길이가 제각각 → 가변길이
ORIG_YYYY	CHAR(4)	더하기·빼기를 안 하는 숫자 → 문자형이 정답
STADIUM_ID	CHAR(3)	부모 테이블의 PK와 동일한 타입·길이로 맞춘다

최종 산출물 — 실행 가능한 DDL

CREATE TABLE TEAM (
    TEAM_ID     CHAR(3)      NOT NULL,   -- [팀ID]     논리 모델의 주식별자
    REGION_NAME VARCHAR2(8)  NOT NULL,   -- [지역명]
    TEAM_NAME   VARCHAR2(40) NOT NULL,   -- [팀명]
    ORIG_YYYY   CHAR(4),                 -- [창단연도] 선택 속성이라 NOT NULL 없음
    STADIUM_ID  CHAR(3)      NOT NULL,   -- [경기장ID] 논리 모델의 외래식별자

    CONSTRAINT TEAM_PK PRIMARY KEY (TEAM_ID),          -- 주식별자 → PK 제약
    CONSTRAINT TEAM_FK FOREIGN KEY (STADIUM_ID)        -- 관계선   → FK 제약
                       REFERENCES STADIUM(STADIUM_ID)
);

CREATE INDEX IDX_TEAM_REGION ON TEAM(REGION_NAME);
-- ⚠️ 인덱스는 개념·논리 단계에는 존재하지 않는 개념 (물리 단계 전용)

SQL

복사

세 단계 한 장 비교

	개념적	논리적	물리적
표현	경기장 · 팀 · 선수	팀(팀ID, 지역명, 팀명, 창단연도, 경기장ID)	CREATE TABLE TEAM (TEAM_ID CHAR(3) …)
엔터티	이름만 있음	속성까지 확정	테이블로 생성
식별자	없음	주식별자 지정	PRIMARY KEY
관계	선만 그림	외래식별자 지정	FOREIGN KEY
자료형		문자 / 숫자 / 일자 (논리 수준)	CHAR(3), VARCHAR2(40), NUMBER
정규화		여기서 수행	—
인덱스			여기서만 등장
DBMS 종속	무관	무관	종속

 이 표 한 장이 곧 기출 문제입니다

•

"인덱스를 설계하는 단계는?" → 물리적

•

"정규화를 수행하는 단계는?" → 논리적

•

"DBMS에 독립적인 단계는?" → 개념적 · 논리적

3. 3층 스키마 (3-Level Architecture)

1) 구조

•

미국 표준화 기관 ANSI/SPARC가 제안한 DB 구조

•

목적: 데이터 독립성 확보 — 한쪽을 바꿔도 다른 쪽이 영향받지 않게 하는 것

스키마	다른 이름	누가 보는가	내용
외부 스키마	사용자 관점, 서브스키마	개별 사용자/응용프로그램	각자 필요한 부분만 보는 View
개념 스키마	통합 관점	DB 관리자(DBA)	조직 전체의 통합 DB 구조 (딱 1개만 존재)
내부 스키마	물리적 관점	시스템 설계자	실제 저장 방식, 인덱스, 파일 구조

2) 외부 스키마 = 사용자가 보는 "일부분"

외부 스키마는 실제로 뷰(View) 로 구현됩니다.

개념 스키마의 EMP 테이블 — 급여까지 전부 들어있다

사원번호	사원명	직무	급여	커미션	부서번호
7369	SMITH	CLERK	800	(NULL)	20
7499	ALLEN	SALESMAN	1600	300	30

외부 스키마(뷰) V_EMP_LIST — 급여를 숨긴 명단 화면

사원번호	사원명	직무	부서번호
7369	SMITH	CLERK	20
7499	ALLEN	SALESMAN	30

CREATE VIEW V_EMP_LIST AS
SELECT EMPNO, ENAME, JOB, DEPTNO   -- SAL, COMM 은 아예 선택하지 않음
FROM   EMP;                        -- → 사용자는 급여의 존재조차 알 수 없다

SQL

복사

3) 데이터 독립성 2가지

독립성	무엇과 무엇 사이인가	의미
논리적 독립성	외부 개념	개념 스키마(테이블 구조)가 바뀌어도 사용자 화면은 그대로
물리적 독립성	개념 내부	저장 장치나 인덱스가 바뀌어도 테이블 구조는 그대로

독립성이 실제로 지켜지는 장면 — 상황별 판정표

발생한 변경	어느 스키마가 바뀌었나	영향받는 곳	지켜진 독립성
EMP에 이메일 컬럼 추가	개념 스키마	뷰 V_EMP_LIST는 영향 없음	논리적 독립성
EMP에 인덱스 생성	내부 스키마	기존 SQL은 한 글자도 안 바뀜	물리적 독립성
디스크 교체 · 저장 위치 변경	내부 스키마	테이블 구조·SQL 모두 그대로	물리적 독립성
사용자별 조회 화면 추가	외부 스키마	개념·내부 스키마 영향 없음	논리적 독립성

 암기 요령
위쪽(외부-개념)이 논리적 독립성, 아래쪽(개념-내부)이 물리적 독립성.
"물리적인 디스크와 가까운 쪽이 물리적 독립성" 으로 기억하세요.

4. ERD (Entity Relationship Diagram)

1) ERD란

•

엔터티(사각형) 와 관계(선) 로 데이터 구조를 그린 그림

•

1976년 피터 첸(Peter Chen) 이 제안 → 사실상 세계 표준 표기법

2) ERD 작성 순서

 암기 문장: "그리고 → 배치하고 → 관계 맺고 → 이름 짓고 → 개수 정하고 → 필수인지 정한다"
순서를 바꾼 선지(예: ③과 ④를 바꿈)가 단골 오답입니다.

3) 실습 데이터로 보는 ERD

K-리그 실습 스키마의 ERD입니다.

4) ERD의 "선"이 SQL에서는 조인 조건이 된다

이것이 1과목과 2과목을 잇는 가장 중요한 연결고리입니다.

테이블 개수와 조인 조건 개수의 관계

조인할 테이블	타야 하는 관계선	필요한 조인 조건
TEAM, PLAYER (2개)	1개	1개
PLAYER, TEAM, STADIUM (3개)	2개	2개
테이블 N개	N-1개	N-1개

예시 — "골키퍼가 뛰는 홈 경기장 이름"을 구하려면 관계를 두 번 타야 한다

SELECT P.PLAYER_NAME, T.TEAM_NAME, S.STADIUM_NAME
FROM   PLAYER P, TEAM T, STADIUM S
WHERE  P.TEAM_ID    = T.TEAM_ID       -- ① PLAYER ─ TEAM  관계선
AND    T.STADIUM_ID = S.STADIUM_ID    -- ② TEAM ─ STADIUM 관계선
AND    P.POSITION   = 'GK';           -- 조회 조건 (관계선 아님)

SQL

복사

 조인 조건을 하나라도 빠뜨리면 카티션 곱(Cartesian Product)이 발생해 행 수가 폭발합니다.
이 "N개 테이블 → N-1개 조인 조건" 규칙은 2과목 내내 계속 출제됩니다.

5. 출제 포인트 한눈에 정리

#	꼭 외울 것	핵심
1	모델링 3가지 관점	데이터 / 프로세스 / 상관
2	모델링 특징	추상화 / 단순화 / 명확화
3	모델링 유의점	중복 / 비유연성 / 비일관성
4	모델링 3단계 순서	개념 → 논리 → 물리
5	재사용성이 가장 높은 단계	논리적 데이터 모델링
6	인덱스를 설계하는 단계	물리적 데이터 모델링
7	3층 스키마	외부 / 개념 / 내부 (개념 스키마는 1개)
8	논리적 독립성	외부 개념
9	물리적 독립성	개념 내부
10	ERD 작성 순서	그리기→배치→관계설정→관계명→참여도→필수여부
11	조인 조건 개수	테이블 N개 → N-1개

6. 확인 문제

Q1. 데이터 모델링의 세 가지 관점에 해당하지 않는 것은? ① 데이터 관점 ② 프로세스 관점 ③ 성능 관점 ④ 데이터와 프로세스의 상관 관점

정답 보기

Q2. 데이터 모델링 단계 중 재사용성이 가장 높고 정규화를 수행하는 단계는? ① 개념적 데이터 모델링 ② 논리적 데이터 모델링 ③ 물리적 데이터 모델링 ④ 개괄적 데이터 모델링

정답 보기

Q3. 아래 상황은 어떤 데이터 독립성에 해당하는가?

DBA가 조회 성능 향상을 위해 EMP 테이블에 인덱스를 추가했지만,
기존 응용프로그램의 SQL은 하나도 수정하지 않았다.

정답 보기 