[강의] Database 모델링

Jerry·2025년 8월 27일

Chap01. DB 모델링 개요

모델링(Modeling)이란?

모델링은 현실 세계의 사물, 개념, 과정 등을 단순화하여 표현한 추상적 구조를 만드는 행위이다.
복잡한 시스템을 이해·분석·설계하기 위해 필요한 핵심 요소와 관계를 시각적으로 표현하는 과정이다.

DB 모델링이란?

현실 세계에 활용되는 데이터를 컴퓨터 공간에서 활용하기 위해 목적에 필요한 데이터를 찾아 논리적인 데이터의 구조로 설계하는 기법 (현실을 데이터로 추상화 하는 기법)
데이터의 개체(Entity), 속성(Attribute), 관계(Relationship)를 정의하고, 이를 통해 논리적·물리적 데이터베이스 스키마로 변환하는 활동이다.

데이터베이스 설계의 중요성

데이터베이스 설계는 데이터의 중복과 불일치 방지, 정합성과 일관성 보장을 통해 신뢰성 있는 시스템을 구축하기 위해 중요하다. 또한 체계적인 구조를 마련하여 효율적인 데이터 접근과 관리를 가능하게 함으로써 운영 및 확장성을 높인다.

구분설명
데이터 중복과 불일치 방지동일 데이터가 여러 곳에 중복 저장되는 것을 방지하여 저장 공간
낭비와 값 불일치 문제를 최소화함
데이터 정합성과 일관성 보장데이터가 정의된 규칙과 제약조건(참조 무결성, 도메인 제약 등)을 만족하여 신뢰성 있는 값을 유지하도록 함
효율적인 데이터 접근과 관리체계적인 스키마와 인덱스, 정규화 설계를 통해 빠른 검색·갱신이 가능하며, 관리 및 확장이 용이한 구조 제공

소프트웨어 개발과정

소프트웨어(프로그램) 개발 프로세스

DB 모델링의 주요 개념

요구사항 분석

사용자 요구사항 및 업무 규칙을 수집·분석하여 데이터 요구 사항을 정의

개념적 모델링

요구분석 단계에서 정의된 핵심 개체와 그들 간의 관계를 바탕으로 ERD를 생성하는 단계

논리적 모델링

개념 설계에서 추상화된 데이터를 구체화하여 개체, 속성을 테이블화하고 상세화 하는 과정

물리적 모델링

논리적 설계 단계에서 표현된 데이터(ERD)를 실제 컴퓨터의 저장장치에 어떻게 표현할 것인가 (관계형 데이터베이스로 전환)

각 단계별 주요 산출물 이해

단계주요 산출물개념
요구사항 분석요구사항 정의서 (Requirement Specification)사용자 및 시스템 요구사항을 정리한 문서로, 데이터 및 기능적 요구를 상세히 기술
개념적 모델링ERD (Entity-Relationship Diagram)개체(Entity), 속성(Attribute), 관계(Relationship)를 도식화하여 데이터 구조를 시각적으로 표현
논리적 모델링논리 데이터 모델 (Logical Data Model)정규화된 스키마, 키 정의, 제약조건 등 DBMS에 독립적인 논리적 구조를 설계
물리적 모델링물리 데이터 모델 & DDL (Physical Data Model & DDL)선택된 DBMS(PostgreSQL 등)에 맞게 테이블, 인덱스, 파티션 등을 정의하고 이를 SQL DDL로 구현

DB 모델링의 주요 개념

Entity(개념/논리 설계 용어) → Table(물리 설계 용어)

업무의 관심 대상이 되는 정보를 갖고 있거나 그에 대한 정보를 관리할 필요가 있는 유형, 무형의 사물(개체) (유형, 무형, 문서, 이력, 코드)

Attribute → column

엔티티에서 관리해야 할 최소 단위 정보 항목(관심이 있는 항목)을 말하며 엔티티는 하나 이상의 속성을 포함 (기본, 유도, 설계)

Instance → row

엔티티의 속성으로 실제로 구현된 하나의 값

Entity 조건

  1. 업무의 관심 대상이 되는 사물이어야 된다.
  2. 두 개 이상의 인스턴스를 소유해야 된다.
  3. 마땅한 속성을 소유해야 된다.

Attribute 명명 규칙

  1. 속성의 의미가 분명히 드러나게 작성할 것 (명확)
  2. 해당 업무에서 사용하는 이름을 부여할 것
  3. 서술식(수식어, 소유격) X, 약어 X
  4. 엔티티에서 유일하게 식별 가능하도록 지정할 것 (중복 X)

Relationship

두 개 이상의 개체(Entity) 간의 연관성을 정의

Cardinality

  • 각 엔티티에 속해 있는 인스턴스들 간에 수적으로 어떤 관계에 있는지를 나타냄
  • 종류로는 1:1, 1:N, M:N의 관계가 있다.

Primary Identifier → PK

엔티티 내 각 인스턴스를 구별하는 기준이 되는 속성

Foreign Identifier → FK

관계가 있는 엔티티 간의 연결고리 역할을 하는 속성

DB 모델링 도구 활용

www.erdcolud.com

Chap02. 요구사항 분석

요구사항 명세의 개념

요구사항 명세는 사용자가 원하는 기능과 제약조건을 체계적으로 문서화한 결과물이다. 시스템이 수행해야 할 기능적 요구와 성능, 보안, 제약조건과 같은 비기능적 요구를 모두 포함한다.
데이터베이스 설계의 입력 자료로 활용되어 이후 개념적·논리적 모델링의 기준이 된다.

비즈니스 요구사항 분석

비즈니스 요구사항 분석은 사용자가 필요로 하는 기능, 데이터, 제약조건을 체계적으로 도출하여 시스템 개발의 기준을 마련하는 과정이다. 업무 절차와 규칙을 정리하여 이후 데이터베이스 설계와 시스템 구현의 입력 자료로 활용된다.

구분개념
기능적 요구사항 식별비즈니스가 달성해야 할 구체적인 서비스와 기능을 정의하는 단계로, 사용자가 기대하는 주요 업무 절차를 도출함.
예: 회원가입, 주문 처리, 결제 승인, 보고서 출력
데이터 관련 요구사항 도출비즈니스 활동을 지원하기 위해 필요한 데이터의 종류, 속성, 형식, 발생 주기 및 보관 정책을 식별함.
예: 고객 정보, 주문 내역, 제품 재고, 로그 데이터
제약조건 파악시스템 설계 및 운영 과정에서 반드시 준수해야 하는 한계와 조건을 명확히 정의함.
예: 성능(응답시간 2초 이내), 보안(암호화, 접근 제어), 법규(개인정보보호법 준수), 예산·기간 제한

데이터 사전 작성

데이터 사전(Data Dictionary)은 데이터베이스에 저장될 데이터의 이름, 유형, 길이, 의미, 제약조건 등 을 체계적으로 정리한 메타데이터 집합이다.
시스템 전반에서 사용하는 데이터의 표준화와 일관성을 보장하기 위해 작성된다.

필요성설명
용어 정의와 표준화데이터 항목의 명칭과 의미를 일관성 있게 정의하여 혼용과 혼란을 방지
데이터 항목 식별시스템에서 사용되는 모든 데이터 요소를 목록화하고 속성을 식별
데이터 형식과 규칙 정의데이터의 유형, 길이, 기본값, 제약조건 등 형식과 관리 규칙을 명확히 규정

Chap03. 개념적 모델링

Part 1. Entity 도출하기

Entity 정의

엔티티 도출

업무 분석 단계 이후, 분석 자료(업무 기술서, 인터뷰 자료, 장부와 전표 등)로부터 엔티티 도출

엔티티 도출 과정

정해진 공식은 없으나 경험이 없으면 다음의 과정들을 거쳐서 엔티티 기술서 작성

  1. 엔티티 후보 풀과 엔티티 리스트를 그린다.
  2. 분석 대상 문서를 보고 명사를 찾아 표시한다.
  3. 명사 하나하나에 대해 속성인지 엔티티인지 구분한다.
  4. 중복된 명사나 유사한 의미의 명사는 하나로 정리한다.
  5. 엔티티 후보 풀에 있는 명사들을 검토한다.
  6. 도출된 엔티티에 대하여 구축될 시스템에서 데이터를 관리할 필요가 있는지 판단한다.

Part 2. ER-Diagram

ERD(Entity-Relationship Diagram)

요구분석사항에서 얻은 엔티티와 속성들을 실제 테이블과 테이블 간의 관계를 설계하기 위해 정해진 작도법을 통해 시각화 하여 표현하는 모델링 기법

ERD의 표기법

ERD의 표기법은 전통적(학문적)으로 피터첸 표기법을 사용하였으나 이는 다수의 테이블과 컬럼 값을 설계하기 어려웠고, 현대(현업)에서는 Crow-feet 표기법을 통해 주로 ERD을 설계하고 있다.

주식별자(Primary Identifier) → 기본키, 주키

  • 엔티티(Table)에 소속된 인스턴스(Row)들을 구별하는 기준 역할을 하는 속성
  • 기본키는 유일성, 최소성, 불변성, 존재성의 특징을 가짐
  • 기본키는 하나가 아닌 여러 속성일 수 있음 (복합 키)
  • 엔티티의 속성 중 주식별자 속성이 없다면 새로운 속성을 만들어 줌 (인위적 주식별자)

외래 식별자(Foreign Identifier) → 외래키

  • 관계가 있는 두 엔티티를 부모, 자식 엔티티로 구분한 후 부모의 주식별자와 공통 속성이 자식에게도 존재하면 해당 속성을 외래 키로 지정
  • 자식 엔티티에 부모 엔티티 주식별자 공통 속성이 없을 경우 자식에게 속성을 추가한 후 외래 식별자로 지정

엔티티 간의 부모-자식 관계

  • 상호 관계가 있는 두 엔티티 중에서 어느 쪽의 정보가 먼저 생성이 되는가에 따라 결정
  • 부모 엔티티의 정보가 있어야지만 존재할 수 있는 것이 자식 엔티티

참여도

  • 참여도에는 필수(mandatory), 선택(optional) 두 가지로 존재
  • 어떤 기준이 되는 엔티티가 있을 때 반드시 대응되는 엔티티가 존재해야 한다면 필수, 존재할 수도, 하지 않을 수도 있다면 선택

카디널리티

  • 두 개의 엔티티 간 관계에서 엔티티에 속해 있는 인스턴스들을 수적으로 표현한 것

식별 관계

  • 1:N 관계에서 외래 식별자가 자식 엔티티의 주식별자의 일부가 되는 관계 → 완전 종속
  • 부모의 데이터가 삭제 되면 자식도 사라져야 하는 형태의 관계 ex) 회원- 배송지 or 상세정보
  • PFK로 표시 (외래 식별자가 주식별자의 역할도 함)
  • 실선으로 관계 표시

비식별 관계

  • 1:N 관계에서 외래 식별자가 자식 엔티티의 주식별자 역할을 하지 못하고 단순히 새로운
    속성으로 추가되는 관계
  • 이때 한쪽이 사라져도 한쪽은 영향을 미치지 않는 관계 ex) 사원 - 부서, 학생 - 동아리
  • FK로 표시 (단지 외래식별자의 역할만 함)
  • 점선으로 관계 표시

1:1 관계

X에 속하는 한 개체는 Y에 속하는 한 개체에만 연결되며, Y에 속하는 한 개체도 X에 속하는 한 개체에만 연결될 때

1 : N 관계

X에 속하는 한 개체는 Y에 속하는 여러 개체에만 연결되며, Y에 속하는 한 개체는 X에 속하는 한 개체와 연결될 때

M : N 관계

  • X에 속하는 한 개체는 Y에 속하는 여러 개체와 연결될 수 있으며, Y에 속하는 한 개체도 X에 속하는 여러 개체와 연결될 수 있을 때
  • M:N 관계는 덜 완성된 모습으로 데이터 구조에 있어서 어떠한 실제적 방법으로도 구현이 불가능하다. (따라서 M:N관계는 해소해 주어야 한다.)

Chap 04. 논리적 모델링

논리적 모델링의 개념

논리적 모델링(Logical Modeling)은 개념적 데이터 모델을 기반으로 특정 DBMS에 독립적인 논리적 구조를 설계하는 과정이다. 정규화, 키 정의, 제약조건 등을 통해 데이터 간 관계와 구조를 체계화한다.이 단계에서 생성된 논리 데이터 모델은 이후 물리적 모델링으로 전환되어 실제 DB 구현을 수행한다.

속성 정의와 설계

속성 정의와 설계는 데이터베이스 내 각 데이터 요소의 의미, 형식, 제약조건을 명확히 규정하는 과정이다.
이를 통해 데이터의 정합성과 일관성을 확보하고 효율적인 관리가 가능해진다.

구분개념
속성의 기본 특성속성명, 데이터 타입, 길이, 기본값 등 기본적인 정의 요소
속성의 도메인 정의속성이 가질 수 있는 값의 범위와 규칙을 지정 (예: 성별=‘M’, ‘F’)
속성의 널 허용 여부해당 속성 값이 반드시 존재해야 하는지 여부를 지정 (NOT NULL 제약 등)

식별자 설계

식별자 설계는 엔터티를 고유하게 구분할 수 있도록 키(Key)를 정의하고, 데이터의 정합성과 무결성을 유지하기 위해 설계하는 과정이다. 즉, 데이터베이스에서 각 레코드를 유일하게 식별하기 위한 기준을 마련하는 단계이다.

키의 종류설명
슈퍼키 (Super key)한 엔터티에서 각 튜플을 유일하게 식별할 수 있는 속성들의 집합
후보키 (Candidate key)슈퍼키 중에서 불필요한 속성을 제외한 최소한의 속성 집합
기본키 (Primary key)후보키 중에서 대표로 선택된 키, NULL 불가 및 중복 불가
대체키 (Alternate key)기본키로 선택되지 않은 나머지 후보키, 필요 시 보조 식별자로 사용

정규화

DB에서 데이터의 중복을 제거하고,데이터 간의 종속성을 명확히 하여 구조를 체계적으로 분해하는 과정

단계이름개념목적/효과
1NF제1정규형 (First Normal Form)모든 속성이 원자값(Atomic Value) 으로만 구성되도록 테이블을 설계반복/중첩 컬럼 제거, 다중값 → 별도 행으로 분리
2NF제2정규형 (Second Normal Form)1NF 만족 + 부분 함수 종속 제거 (복합키의 일부에만 종속된 속성을 분리)기본키 전체에 종속되도록 하여 중복 제거
3NF제3정규형 (Third Normal Form)2NF 만족 + 이행 함수 종속 제거 (A→B, B→C일 때 A→C 종속 제거)비키 속성 간 종속 제거 → 데이터 일관성 강화
BCNF보이스-코드 정규형 (Boyce–Codd Normal Form)3NF 만족 + 모든 결정자가 후보키가 되도록 분해이상현상(Anomaly) 추가 제거, 더 엄격한 무결성
4NF제4정규형 (Fourth Normal Form)BCNF 만족 + 다치 종속(Multi-valued Dependency) 제거하나의 키에 대해 여러 독립적인 다치 속성을 분리
5NF제5정규형 (Fifth Normal Form, PJ/NF)4NF 만족 + 조인 종속(Join Dependency) 제거불필요한 조인으로 인한 데이터 중복 제거

목적

  • 데이터 중복 최소화
  • 삽입·삭제·갱신 이상(Anomaly) 방지
  • 데이터 일관성과 무결성 유지
  • 저장 공간 효율화 및 유지보수 용이성 향상

이상 (Anomaly) 현상

정규화 되지 않은 테이블에서 데이터를 삽입, 갱신, 삭제를 수행하다 발생하는 논리적 오류
이에 따라 무결성 원칙 위배, 일관성을 지켜지지 않고 데이터의 중복이 발생한다.

삽입 이상

불필요한 정보를 함께 저장하지 않고는 어떤 정보를 저장하는 것이 불가능

갱신 이상

반복된 데이터 중에 일부만 수정하면 중복된 다른 데이터의 불일치가 발생

삭제 이상

필수적인 정보를 함께 삭제하지 않고는 어떤 정보를 삭제하는 것이 불가능

Chap 05. 물리 모델링

Part1. 물리 모델링 수행

물리 모델링 개요

논리적 설계의 산출물인 ERD를 기반으로 DBMS의 구조와 성능을 고려해 실제 저장 구조로 구현하는 설계 단계

논리적 DB 설계
(데이터 모델링)
물리적 DB 설계
DBMS의 종류/제품에 상관 없이 진행
(ERD는 어떤 데이터베이스를 사용해도 적용가능)
특정 DBMS를 전제로 진행
(적용 DBMS의 특성을 고려)

테이블 설계

테이블 설계는 현실 세계의 개체와 속성을 데이터베이스 구조로 변환하여 테이블과 컬럼으로 정의하는 과정이다. 각 컬럼의 데이터 타입, 제약조건, 키를 명확히 설정하여 데이터 무결성과 효율적인 관리가 가능하도록 한다. 이를 통해 데이터 간 관계를 반영하고 향후 확장성과 성능까지 고려한 최적의 스키마를 구축한다.

컬럼 데이터 타입 선정

컬럼 데이터 타입 선정은 각 컬럼이 저장할 데이터의 성격과 범위에 맞는 적절한 타입을 지정하는 과정이다. 이를 통해 저장 공간을 효율적으로 사용하고, 데이터 무결성과 처리 성능을 보장한다.

분류데이터 타입설명
정수형 (Integer Types)SMALLINT (2바이트)
INTEGER (4바이트)
BIGINT (8바이트)
정수 값 저장
숫자형 (Numeric Types)NUMERIC(p,s), DECIMAL(p,s)고정 소수점, 정확한 계산 가능 (금융 계산 등에 적합)
REAL, DOUBLE PRECISION부동 소수점, 근사치 계산 (과학/통계 연산 등에 적합)
문자형 (Character Types)CHAR(n)고정 길이 문자
VARCHAR(n)가변 길이 문자 (길이 제한 있음)
TEXT가변 길이 문자 (제한 없음)
날짜/시간형 (Date/Time Types)DATE날짜 (YYYY-MM-DD)
TIME시간 (HH\:MI\:SS)
TIMESTAMP날짜 + 시간
INTERVAL기간, 시간 간격
불리언 (Boolean)BOOLEANTRUE, FALSE, NULL
자동 증가 타입 (Serial Types)SERIAL, BIGSERIAL자동 증가 정수 (주로 PK에 사용)
고유/확장 타입 (PostgreSQL 전용)JSON, JSONBJSON 데이터 저장 및 처리
ARRAY배열 형태 데이터 저장
UUID범용 고유 식별자 (Primary Key에 자주 사용)

키와 제약조건 구현

컬럼 제약 조건(Column Constraints)은 데이터 무결성과 일관성을 보장하기 위해 각 컬럼에 대해 값의 범위, 유일성, 참조 관계 등을 정의하는 규칙이다.
이를 통해 데이터 입력 시 오류를 예방하고 데이터베이스의 신뢰성을 확보한다.

구분설명쿼리 명령
기본값과 제약조건 설정컬럼 값이 입력되지 않을 경우 기본값 지정 및 NULL 허용 여부 설정DEFAULT, NOT NULL
기본키 (Primary Key) 구현 전략테이블 내 레코드를 고유하게 식별하는 키, NULL 및 중복 불가PRIMARY KEY
외래키 제약조건 (Foreign Key)다른 테이블의 기본키를 참조하여 데이터 참조 무결성 보장FOREIGN KEY
고유키 제약조건 (Unique Key)특정 컬럼 값의 중복을 허용하지 않도록 정의 (단, NULL은 허용 가능)UNIQUE

참조 무결성 규칙 설정

참조 무결성 규칙은 외래키 제약조건에서 부모 테이블의 데이터 변경이나 삭제가 발생했을 때, 자식 테이블의 데이터를 어떻게 처리할지 정의하는 규칙이다.

옵션개념실제 제약 문장 예시
CASCADE부모 데이터가 변경·삭제되면 자식 데이터도 함께 변경·삭제됨FOREIGN KEY (dept_id) REFERENCES department(dept_id) ON DELETE CASCADE
SET NULL부모 데이터가 삭제되면 자식의 외래키 값을 NULL로 설정FOREIGN KEY (dept_id) REFERENCES department(dept_id) ON DELETE SET NULL
RESTRICT자식 데이터가 존재할 경우 부모 데이터의 변경·삭제를 제한FOREIGN KEY (dept_id) REFERENCES department(dept_id) ON DELETE RESTRICT

인덱스 설계

인덱스(Index)는 데이터 검색 성능을 향상시키기 위해 특정 컬럼의 값을 기준으로 정렬된 별도의 자료구조(B-Tree, Hash 등)를 생성하는 객체이다.
종류로는 B-Tree 인덱스, Hash 인덱스, GiST/GIN 인덱스, 비트맵 인덱스 등이 있다.

인덱스 설계 원칙

원칙설명
선택도가 높은 컬럼 우선중복이 적고 카디널리티가 높은 컬럼에 인덱스를 적용
조회/조인/정렬 기준 활용WHERE, JOIN, ORDER BY, GROUP BY에서 자주 쓰이는 컬럼 중심으로 설계
과도한 인덱스 지양불필요한 다중 인덱스는 갱신 부하와 저장 공간 낭비를 초래하므로 최소화

인덱스 적용 기준

기준설명
WHERE 절 조건 컬럼자주 필터링되는 컬럼에 인덱스 적용
JOIN 키 컬럼테이블 결합에 사용되는 컬럼에 인덱스 부여
ORDER BY / GROUP BY대상 정렬·집계 대상 컬럼에 인덱스를 적용하여 처리 효율 향상

Chap 06. 설계 최적화

데이터 모델 검증

데이터 모델 검증은 설계된 데이터 모델이 요구사항을 정확히 반영하고, 무결성과 일관성을 유지할 수 있는지 확인하는 과정이다. 엔터티, 속성, 관계, 제약조건이 적절히 정의되었는지를 점검하며, 이 상현상 발생 가능성을 사전에 제거한다.
이를 통해 데이터베이스 구현 시 오류를 최소화하고 성능과 확장성을 보장한다.

일반적인 안티패턴 사례

사례개념설명
부적절한 기본키 선정가변적 값 사용주민번호, 전화번호 등 변경 가능성이 있는 속성을 기본키로 사용하면 무결성과 안정성이 깨짐
잘못된 일대다 관계 설정관계 오류부모-자식 관계를 잘못 정의하면 데이터 중복, 삭제/갱신 이상(Anomaly) 발생
순환 참조 구조상호 참조 문제테이블 간 외래키가 서로를 참조하는 순환 구조가 생기면 데이터 입력·삭제 제약과 복잡성이 증가

성능 관련 검증

성능 관련 검증은 데이터베이스 설계와 구현이 실제 운영 환경에서 요구되는 성능 목표를 충족하는지 점검하는 과정이다. 인덱스, 조인, 쿼리 실행 계획 등을 검토하여 응답 시간과 처리 효율성을 확인한다.
이를 통해 병목 지점을 사전에 발견하고 최적화 방안을 마련할 수 있다.

전형적인 성능 안티패턴

사례설명
과도한 인덱스 생성불필요한 인덱스가 많으면 쓰기(INSERT/UPDATE/DELETE) 시 성능 저하와 저장 공간 낭비 발생
비효율적인 조인 구조잘못된 조인 순서·조건으로 인해 불필요한 연산이 늘어나 쿼리 성능 저하 초래
부적절한 데이터 타입 선택데이터 크기·형식에 맞지 않는 타입 사용으로 저장 공간 낭비 및 연산 성능 저하 발생

반정규화(De-Nomalization)

  • 정규화 된 테이블 구조에서 성능 향상이나 조회 최적화를 위해 중복이나 종속성을 허용하며 테이블을 통합 또는 컬럼을 추가하는 과정, 주로 조인 감소, 쿼리 단순화, 응답 속도 개선을 목적으로 한다
  • 정규화를 통한 데이터 무결성 유지도 중요하지만, 다수 사용자가 동시 이용하는 환경에서 일정 성능을 유지하는 것도 매우 중요하다.
  • 이러한 반정규화로 인해 DB의 이상현상이 발생 할 수 있음으로 개발자 입장에서는 까다로운 기술
profile
Backend engineer

0개의 댓글