Study/SQL

[SQLD] Part 01 - 데이터 모델링

the.Dev.Cat 2026. 3. 3. 03:29

이 글은 내가 SQLD 자격증을 위한 공부하면서 정리하는 메모이다.

Section 01. 데이터 모델의 이해

데이터 모델링이란

현실 세계의 데이터를 추상화해서 컴퓨터가 다룰 수 있는 형태로 변환하는 과정이다.

단순히 테이블 설계가 아니라, "이 세계에 어떤 데이터가 존재하고 어떻게 연결되어 있는가"를 표현하는 작업이다.

 

추상화란 현실에서 필요한 부분만 골라내는 것이다. 실제 고객은 키, 몸무게, 좋아하는 색깔 같은 속성을 가지지만, 쇼핑몰 시스템에서 필요한 건 이름, 연락처, 배송지 정도다. 관련 없는 것을 걷어내고 업무에 필요한 것만 남기는 과정이 추상화다.

 

 

데이터 모델링에는 세 가지 목적이 있다.

  • 업무 파악: 현실 세계를 이해하고 표현
  • 약속: 개발자와 이해관계자 간의 소통 수단
  • DB 설계: 실제 데이터베이스를 만들기 위한 청사진

쇼핑몰을 예로 들면, "고객이 상품을 주문한다"는 현실을 고객/상품/주문 엔터티와 그 관계로 표현하는 것이 데이터 모델링이다. 개발자가 바뀌어도, 기획자와 이야기할 때도 이 모델이 공통 언어가 된다.

3가지 관점

데이터 모델링은 관점에 따라 세 단계로 나뉜다.

관점 내용
개념적 데이터 모델링 비즈니스 요구사항을 추상화. 핵심 엔터티와 관계만 도출. ERD 개략
논리적 데이터 모델링 구체적인 속성, 식별자, 관계를 정의. 특정 DBMS에 독립적
물리적 데이터 모델링 실제 DBMS에 맞게 테이블, 컬럼, 인덱스 등을 설계

 

개념 → 논리 → 물리 순으로 점점 구체화된다.

 

같은 쇼핑몰 프로젝트라면 :

  • 개념 : "고객, 상품, 주문이 있고 고객이 상품을 주문한다" 수준의 그림
  • 논리 : 고객(고객번호 PK, 이름, 이메일), 주문(주문번호 PK, 고객번호 FK, 주문일시) 처럼 속성과 관계를 정의
  • 물리 : customer_id BIGINT NOT NULL AUTO_INCREMENT, 이름 컬럼에 인덱스 여부까지 결정

 

데이터 모델링의 3가지 요소

Entity(엔터티), Attribute(속성), Relationship(관계)

 

이 셋이 데이터 모델을 구성하는 기본 단위다.

간단히 말하면 엔터티는 "무엇", 속성은 "그것의 특성", 관계는 "엔터티들 사이의 연결"이다.

스키마 3층 구조

ANSI에서 정의한 데이터베이스 아키텍처 구조다. 시험에서 각 레벨이 뭘 담당하는지 물어보는 경우가 있다.

외부 스키마 (External Schema)
  ↑ 사용자/응용 프로그램이 보는 뷰

개념 스키마 (Conceptual Schema)
  ↑ 전체 데이터베이스의 논리적 구조 (DBA 관점)

내부 스키마 (Internal Schema)
  ↑ 실제 저장 구조, 인덱스, 파일 형식
  • 외부 스키마 : 사용자마다 다르게 보이는 뷰. 여러 개 존재 가능
  • 개념 스키마 : DB 전체를 통합한 하나의 논리적 설계. 1개
  • 내부 스키마 : 물리적 저장 방식. 1개

은행 시스템을 예로 들면, 창구 직원이 보는 고객 정보 화면과 인터넷 뱅킹 고객이 보는 잔액 화면은 서로 다른 외부 스키마다. 그 뒤에 계좌/고객/거래 테이블의 구조가 개념 스키마고, 실제로 디스크 어느 블록에 데이터를 어떻게 저장하는지가 내부 스키마다.

ERD (Entity Relationship Diagram)

데이터 모델을 시각화한 다이어그램이다. 1976년 피터 첸이 제안한 표기법이 시작이고, 지금은 IE 표기법이나 바커(Barker) 표기법이 실무와 시험에서 많이 쓰인다.

SQLD는 IE 표기법 기준으로 출제된다.

 

Section 02. 엔터티

엔터티의 정의

업무에서 관리되어야 할 정보가 있는 집합

 

개별 데이터 하나가 아니라 같은 성격의 데이터를 묶은 집합이다.

"고객"이라는 엔터티는 고객 한 명이 아니라 고객이라는 집합 전체를 뜻한다.

 

엔터티가 되려면 조건이 있다.

  • 업무와 관련이 있어야 한다
  • 두 개 이상의 인스턴스가 존재해야 한다 (고객이 한 명뿐인 시스템은 고객 엔터티가 없어도 됨)
  • 반드시 속성을 가져야 한다
  • 다른 엔터티와 최소 한 개 이상의 관계가 있어야 한다 (단, 통계성 엔터티 등은 예외)
  • 식별자로 구분 가능해야 한다

엔터티의 분류

분류 기준은 두 가지가 있다.

 

유무형 기준

유형 설명 예시
유형 엔터티 물리적으로 존재 고객, 상품, 직원
개념 엔터티 물리적으로 없고 개념적으로 존재 보험상품, 조직
사건 엔터티 업무 처리 과정에서 발생 주문, 청구, 이력

 

발생시점 기준

유형 설명
기본(Key) 엔터티 다른 엔터티에 의존하지 않고 독립적으로 존재. 업무에서 원래 존재하던 것
중심(Main) 엔터티 기본 엔터티로부터 발생. 업무의 중심이 되는 엔터티
행위(Action) 엔터티 두 개 이상의 엔터티로부터 발생. 자주 바뀌거나 데이터가 많음

 

예를 들어 쇼핑몰이라면, "회원"과 "상품"은 기본 엔터티, "주문"은 중심 엔터티,

"주문상세"나 "배송이력"은 행위 엔터티에 해당한다.

엔터티 명명 규칙

  • 업무에서 실제 사용하는 용어를 쓴다
  • 약어보다 완전한 이름을 쓴다
  • 단수 명사를 쓴다 (Customers가 아니라 Customer)
  • 유일한 이름이어야 한다
  • 생성 의미가 포함되지 않도록 (예 : "주문등록" 대신 "주문")

 

Section 03. 속성

속성의 정의

엔터티를 설명하는 더 이상 분리될 수 없는 최소 단위의 데이터

 

"고객" 엔터티의 고객명, 연락처, 이메일 같은 것들이 속성이다. 각각의 속성은 하나의 값(원자값)을 가져야 한다.

속성의 분류

특성 기준

유형 설명 예시
기본 속성 업무에서 직접 받아오는 원래 속성 이름, 가격, 날짜
설계 속성 모델링 과정에서 설계자가 만든 속성 코드값, 일련번호
파생 속성 다른 속성에서 계산/유도된 속성 합계, 평균, 나이

 

파생 속성은 데이터 중복을 유발하기 때문에 필요한 경우에만 사용한다.

생년월일이 있으면 나이는 계산할 수 있는데 굳이 저장할 필요가 없는 것처럼.

 

엔터티, 인스턴스, 속성, 속성값의 관계

헷갈리기 쉬운 개념 정리.

엔터티: 고객
  └── 인스턴스: 홍길동 (행 하나)
        └── 속성: 고객명, 이메일, 연락처
              └── 속성값: "홍길동", "hong@email.com", "010-1234-5678"
  • 한 엔터티에는 여러 인스턴스가 있다
  • 각 인스턴스는 속성들로 구성된다
  • 속성은 하나의 속성값만 가져야 한다 (다중값 속성은 별도 엔터티로 분리)

 

도메인

속성이 가질 수 있는 값의 범위와 제약

 

성별 속성이라면 도메인은 {남, 여}이고, 나이 속성이라면 도메인은 0 이상 150 이하의 정수처럼 정의할 수 있다.

데이터 타입, 크기, 제약 조건을 포함한다.

 

Section 04. 관계

관계의 정의

엔터티 간에 업무적으로 연관된 상태

 

관계는 단순한 선이 아니라, 두 엔터티가 어떤 맥락에서 연결되는지를 표현한다.

 

존재 관계 vs 행위 관계

구분 설명 예시
존재 관계 존재 자체로 연결 직원 - 부서 (직원이 부서에 소속)
행위 관계 업무 행위로 연결 고객 - 주문 (고객이 주문을 함)

 

관계의 표기 요소

관계는 세 가지 요소로 표기한다.

  • 관계명(Membership) : 두 엔터티가 어떤 관계인지 이름. 양쪽에 각각 붙는다
  • 관계차수(Cardinality) : 1:1, 1:M, M:N
  • 선택성(Optionality) : 필수(Mandatory) vs 선택(Optional)

관계명은 방향마다 따로 붙는다. "직원 - 부서" 관계라면 직원 → 부서 방향은 "소속된다", 부서 → 직원 방향은 "포함한다"처럼. ERD를 읽을 때 "직원은 하나의 부서에 소속된다", "부서는 여러 직원을 포함한다"로 읽으면 된다.

관계 차수

1:1 관계

  • 양쪽 엔터티의 인스턴스가 하나씩 연결
  • 예: 직원 - 사원증

1:M 관계

  • 한 쪽은 하나, 다른 쪽은 여러 개
  • 예: 부서 - 직원 (부서 하나에 직원 여러 명)
  • 가장 흔한 관계

M:N 관계

  • 양쪽 모두 여러 개
  • 예: 학생 - 강좌 (학생 한 명이 여러 강좌, 강좌 하나에 여러 학생)
  • 실제 DB 구현 시 중간 테이블(연결 엔터티)로 분해해야 함

선택성 표기

IE 표기법에서 세로 막대(|)는 필수, 원(O)은 선택을 뜻한다.

고객 ——|O——< 주문
        필수  선택  여러

 

이 표기는 "고객은 반드시 존재하고, 주문은 없을 수도 있으며, 있다면 여러 개 가능"을 의미한다.

 

Section 05. 식별자

식별자의 정의

각각의 인스턴스를 유일하게 구분할 수 있는 속성(들)

 

고객 엔터티에서 "고객번호"처럼 각 행을 유일하게 식별하는 기준이다. DB로 치면 Primary Key에 해당한다.

 

식별자의 특징 :

  • 유일성 : 모든 인스턴스에서 유일한 값
  • 최소성 : 불필요한 속성 없이 최소한으로 구성
  • 불변성 : 값이 자주 바뀌면 안 됨
  • 존재성 : NULL이 되면 안 됨

이름은 유일성을 만족하지 못하고, 연락처는 바뀔 수 있어서 불변성에 걸린다.

그래서 업무적으로 의미 없는 숫자 ID를 식별자로 쓰는 경우가 많다.

식별자 분류

대표성 여부

구분 설명
주식별자 엔터티를 대표하는 식별자. 하나만 존재
보조식별자 주식별자를 대체할 수 있는 식별자. 여러 개 가능

예 : 고객 엔터티에서 "고객번호"가 주식별자라면, "이메일"은 보조식별자.

 

생성 여부

구분 설명
본질식별자 업무 자체에서 만들어진 식별자
인조식별자 업무와 관계없이 설계자가 만든 일련번호

 

본질식별자는 주민등록번호처럼 현실에 이미 존재하는 것이고, 인조식별자는 자동 증가하는 ID처럼 의미 없이 구분만 하는 것이다. 인조식별자는 쓰기 편하지만 남용하면 안 된다. 본질식별자가 명확하다면 인조식별자를 굳이 추가할 이유가 없다.

 

속성 수 기준

구분 설명
단일식별자 속성 하나로 구성
복합식별자 속성 두 개 이상으로 구성

 

대체 여부

구분 설명
원조식별자 업무적으로 만들어진 원래 식별자
대리식별자 주식별자가 복잡할 때 대신 사용하는 식별자

 

식별자 관계 vs 비식별자 관계

ERD에서 관계선의 종류로 구분한다.

식별자 관계 (실선)

부모 엔터티의 주식별자가 자식 엔터티의 주식별자로 들어가는 관계

주문상세 테이블의 기본키가 (주문번호, 상품번호)처럼 부모의 키를 포함하는 경우다. 자식은 부모 없이 존재할 수 없다.

 

비식별자 관계 (점선)

부모 엔터티의 주식별자가 자식 엔터티의 일반 속성으로 들어가는 관계

 

직원 테이블에 부서번호가 외래키로 들어가지만, 직원의 기본키는 직원번호 하나인 경우다.

부모와 독립적으로 존재 가능하다.

식별자 관계 :  부모 ———— 자식  (실선)
비식별자 관계 : 부모 - - - 자식  (점선)

 

식별자 관계는 복합키가 점점 길어지는 문제가 생길 수 있어, 실무에서는 비식별자 관계를 더 많이 쓴다고 한다.