[DB] 데이터 모델링

2026. 5. 30. 22:47·Backend/DB

데이터 모델링

모델링

  • 현실 세계의 정보를 약속된 표기법을 활용하여 데이터베이스의 구조로 표현하는 과정입니다.
  • 단순하고, 추상화가 되어있어야 하고, 명료해야합니다.
  • 변화에 유연한 대응을 할수 있어야 합니다.
  • 유일성이 보장되어야 하고, 명확한 관계를 가지는 일관성이 있어야 합니다.

모델링 단계

  1. 개념적 모델링: 현실 세계에 대한 인식을 추상적 개념으로 표현합니다. ERD로 표현합니다.
  2. 논리적 모델링: 정규화를 활용하여 논리적 자료구조(테이블)로 변환합니다. 재사용성이 높습니다.
  3. 물리적 모델링: 물리적 구조의 데이터로 변환합니다.

* 물리적 모델링으로 갈수록 높은 수준의 구체화 (낮은 수준의 추상화) 레벨을 가지게 됩니다.

* 데이터 모델은 Entity, Attribute, Relationship을 반드시 가집니다.

E-R Diagram

  • IE 표기법과 Barker 표기법이 있습니다.
  • 작성 순서
    엔터티 도출 -> 배치 -> 관계 설정 -> 관계명 시술 -> 관계 차수 기술 -> 필수 / 선택사양 기술
    * 배치할 시 중요한 정보는 주로 좌상단에 배치합니다.

ANSI/SPARC 스키마 구조

스키마에는 3계층이 있어서, 외부 스키마(서브 스키마, 사용자 뷰)와 개념 스키마, 내부 스키마(저장 스키마)가 있습니다.

  • 여러 개의 외부 스키마(App, Web, ATM ...)들은 하나의 논리적인 구조에 의해서 동작합니다.
    • 논리적 독립성: 개념 스키마 변경 시, 외부 스키마에 영향이 없어야 합니다.
  • 이 개념 스키마들이 물리적으로 저장되는 곳이 내부 스키마입니다.
    • 물리적 독립성: 내부 스키마가 변경이 되어도, 개념과 외부 스키마에는 영향이 없어야 합니다.

데이터 모델의 구성 요소

Entity(엔터티)

개념

  • 현실 세계에 존재하고 명확하게 구분 가능한 객체를 말합니다.
  • 유일한 식별자를 보유해야하고, 인스턴스가 2개 이상이고, 2개 이상의 속성을 가져야 합니다. 또한 다른 엔터티와의 관계가 필수적입니다.
  • 엔터티를 명명할 때는 약어 사용을 지양하고, 단순 명사를 사용하며 중복 없이 의미가 명확해야 합니다.

유무형에 따른 분류

  • 개념 엔터티: 형태는 없지만 개념적으로 구분 (과목, 학과, 부서 등)
  • 사건 엔터티: 특정 시점에 발생한 사건 (수강, 주문, 예약 등)
  • 유형 엔터티: 물리적 형태가 존재 (책, 학생 등)

발생 시점에 따른 분류

  • 기본 엔터티: 다른 엔터티에 영향을 받지 않고 독립적으로 존재 (학생, 과목, 고객, 직원 등)
  • 중심 엔터티: 기본 엔터티와 행위 엔터티를 연결 (수강신청, 주문 등)
  • 행위 엔터티: 두 개 이상의 엔터티를 상속받아 생성되는 행위. (많은 수정사항이 발생, 주문 내역 등)

Attribute(속성)

개념

  • 더 이상 분리되지 않는 최소의 데이터 단위 (원자성)
  • 주식별자에 함수적 종속(A 속성에 의해 B가 유일하게 결정)

구성 형식에 따른 분류

  • 기본키(Primary Key, PK): 인스턴스를 유일하게 구별 가능하게 하는 속성
  • 외래키(Foreign Key, FK): 다른 엔터티의 관계로 연결된 속성
  • 일반 속성: PK/FK가 아닌 속성

* 자식 엔터티는 부모의 PK를 FK로 포함합니다.

도메인

  • 속성이 가질 수 있는 데이터의 타입과 크기에 대한 제한 사항을 정리 (데이터 무결성 보장)

Relationship(관계)

개념

  • 엔터티와 엔터티 간의 연관성
  • 존재적 관계: 다른 엔터티가 존재해야만 존재할 수 있는 관계
  • 행위적 관계: 행동, 동작, 사건에 의해 발생하는 관계

구성요소

  • 관계명(Membership): 관계의 이름
  • 차수(Cardinality): 1:1, 1:N, M:N
  • 선택사양(Optionality): 엔터티가 관계에 항상 참여하는지 여부

교차 엔터티

  M:N 관계를 표현하기 위해서 생성된 엔터티 (RDB는 M:N 관계의 표현이 불가)

 

관계 체크사항

  • 두 개의 엔터티 사이에 관심있는 연관규칙이 있는가?
  • 두 개의 엔터티 사이에 정보의 조합이 발생하는가?
  • 관계연결에 대한 규칙이 서술되어 있는가?
  • 관계연결을 가능하게 하는 동사가 있는가?

식별자

대표성 여부에 따른 분류

  • 주 식별자(기본키, PK): 대표성, 유일성, 최소성, 불변성, 존재성을 만족해야 합니다.
  • 보조 식별자(대체키, AK): 유일하게 구분 가능하지만 대표성이 없는 식별자

스스로 생성 여부에 따른 분류

  • 내부 식별자: 엔터티 내부에서 스스로 발생
  • 외부 식별자(외래키, FK): 다른 엔터티로부터 받아오는 식별자

속성의 수에 따른 분류

  • 단일 식별자: 하나의 속성으로 구성된 식별자
  • 복합 식별자: 둘 이상의 속성으로 구성된 식별자

대체 여부에 따른 분류

  • 본질 식별자: 프로세스 상에서 현실로 존재하는 식별자
  • 인조 식별자: 인위적으로 생성한 식별자

* 인조 식별자를 사용하면 데이터 중복 가능성이 생기고 불필요한 인덱스가 생기지만, 실제 비즈니스와 무관하계 설계 가능하고 개발 및 유지 보수성이 용이해집니다.

키

  1. 후보키: 유일성과 최소성을 만족하는 속성 또는 속성 들의 집합
  2. 기본키: 후보키 중에서 대표성을 가지는 주 키 (개체무결성)
  3. 대체키: 기본키를 제외한 나머지 후보키
  4. 외래키: 유일성은 만족하지만 최소성은 만족시키지 못하는 키
  5. 슈퍼키: 다른 테이블의 기본키를 참조하는 키 (참조무결성)

* 식별자는 논리 모델링 단계에서 사용하고, 키는 물리 모델링 단계에서 사용합니다.

정규화

데이터베이스의 이상현상을 방지하기 위해서 데이터 중복을 최소화하여 테이블을 분리하는 방법

DB 이상현상

  • 삽입이상: 데이터 삽입 시, 의도하지 않은 값들도 삽입되는 현상
  • 삭제이상: 데이터 삭제 시, 의도하지 않은 값들도 삭제되는 현상
  • 갱신이상: 일부 데이터만 갱신되어 모순이 발생하는 현상

정규화 단계

제 1 정규화 -> 제 2 정규화 -> 제 3 정규화 -> BCNF -> 제 4 정규화 -> 제 5 정규화

 

각 단계별 정규화 특징

  • 제 1 정규화: 도메인이 원자 값으로만 구성
  • 제 2 정규화: 부분적 함수 종속을 제거하여, 완전 함수 종속을 만족
  • 제 3 정규화: 이행 함수 종속 관계를 제거
  • BCNF: 경쟁자가 모두 후보키가 되도록 분해
  • 제 4 정규화: 다치 종속을 제거
  • 제 5 정규화: 조인 종속성을 이용

정규화의 예시

* 테이블 분해 시, 결정자는 남기고, 종속자는 제거합니다.

관계와 조인

서로 관계가 있는 테이블을 SQL로 연결해서 데이터를 조회하는 방법입니다.

정규화로 인해 분해된 테이블들은 조인 성능이 낮아질 수 있습니다. 이를 해결하기 위해서 반정규화를 수행하기도 합니다.

계층형 데이터 모델

같은 테이블을 참조하여 두 개의 테이블을 조인하는 관계입니다. 계층형 질의 혹은 셀프 조인을 사용합니다.

상호배타적 관계

두 테이블 중 하나의 테이블만 상속할 수 있는 관계입니다.

트랜잭션

데이터베이스의 하나의 논리적인 작업의 단위입니다.

  • COMMIT: 트랜잭션이 성공적으로 끝났음을 알리고 데이터베이스에 저장
  • ROLLBACK: 트랜잭션 중 오류가 발생하여 이전 상태로 되돌림

ACID 트랜잭션

  • Atomic(원자성): 트랜잭션이 수행되거나, 전혀 수행되지 않아야 합니다.
  • Consistency(일관성): 트랜잭션 실행 전후로 오류가 없어야 합니다.
  • Isolation(고립성): 트랜잭션끼리 서로 간섭하면 안됩니다.
  • Durability(지속성): 수행된 결과는 영구적으로 저장해야 합니다.

NULL 속성

정의되지 않은 값입니다. 비어있거나 0인 값이 아닌 값입니다. 따라서 비교 또는 연산이 불가하며 집계함수에서 제외됩니다.

반응형

'Backend > DB' 카테고리의 다른 글

[DB] 비관적 락과 낙관적 락  (0) 2026.05.01
[MySQL] MySQL에서의 트랜잭션과 잠금 분석  (0) 2026.03.26
[MySQL] InnoDB 스토리지 엔진 아키텍처 분석  (0) 2026.03.16
[MySQL] MySQL 엔진 아키텍처 분석  (0) 2026.03.05
'Backend/DB' 카테고리의 다른 글
  • [DB] 비관적 락과 낙관적 락
  • [MySQL] MySQL에서의 트랜잭션과 잠금 분석
  • [MySQL] InnoDB 스토리지 엔진 아키텍처 분석
  • [MySQL] MySQL 엔진 아키텍처 분석
soberyl
soberyl
개발과 청춘 일지
    반응형
  • soberyl
    soberyl 님의 블로그
    soberyl
  • 전체
    오늘
    어제
    • 분류 전체보기
      • 프로젝트
        • Snap Trade
        • 팀 프로젝트
        • 오픈 소스
      • 개발일지
        • 코딩 테스트
        • 알고리즘
        • CS
      • Full stack
      • Frontend
        • UXUI
        • React
        • Next.js
        • React Native
        • Monitor
      • Backend
        • NestJS
        • Spring
        • Monitor
        • DB
      • DevOps
        • CICD
      • Test
      • AI
      • Infra
        • AWS
        • On-premise
      • 청춘
        • 희곡
        • 연극
      • 잡설
  • 블로그 메뉴

    • 홈
    • 태그
    • 방명록
  • 링크

  • 공지사항

  • 인기 글

  • 태그

    thread
    연극
    테스트
    EC2
    코테
    최적화
    DB
    프론트엔드
    백엔드
    알고리즘
    코딩테스트
    MySQL
    거래소
    io
    CPU
    OS
    memory
    설계
    java
    희곡
  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.6
soberyl
[DB] 데이터 모델링
상단으로

티스토리툴바