데이터베이스 설계

1. 요구사항 분석과 데이터 모델링 준비

1-01. 비즈니스 요구사항 분석

소프트웨어 시스템에서 요구사항 분석은 가장 첫 번째이자 중요한 단계이다. 요구사항을 정확하게 파악하지 않는다면 이후 설계, 구현, 테스트 단계에서 치명적인 영향을 줄 수 있다.

1) 종류

• 기능적 요구사항
  • 시스템이 무엇을 해야 하는가를 정의하는 요구사항
• 비기능적 요구사항
  • 성능, 보안, 안정성 등 기능 외적인 요구사항
  • 데이터 관련 요구사항 도출
    • 어떤 정보를 저장해야 하는지를 판단
  • 제약조건(Constraints) 파악
    • 무결성 유지를 하기 위해 고유성 제약, 형식 제약, 범위 제약, 필수 여부 등과 같은 제약들을 파악

1-02. 데이터 사전 작성

1) 데이터 사전(Data Dictionary)

데이터베이스에 저장되는 모든 데이터 항목에 대한 정의, 형식, 제약조건 등의 메타정보를 체계적으로 정리한 문서

시스템의 일관성과 유지보수성을 확보하는데 중요한 역할을 한다.

2) 데이터 사전 작성 단계

1. 용어 표준화 및 명명 규칙 정리하여 데이터 항목 간 중복/혼동 방지
2. ERD 또는 요구사항 정의서에서 데이터 항목 추출
   • 엔티티명, 속성명, 기본키 여부, 외래키 여부 등
3. 항목별 설명, 데이터 형식, 제약조건 정의
4. 도메인 및 단위 정의
   • 반복되는 속성 형식은 도메인(Domain)으로 별도 정의하여 재사용
5. 관리 책임자 및 변경 이력 추가

3) 활용

• API 문서와 연계 : API 계약 시 필수 정보 제공
• DB Migration 사전 작업 : 필드 변경 시 영향도 파악 및 조율 근거 제공
• 데이터 검증 및 품질 관리 : 오류/이슈 추적에 활용

2. 개념적 모델링

2-01. 개념적 모델링

요구사항 분석에서 도출된 “저장해야 할 정보”를 바탕으로, 업무 관점의 핵심 개체(엔티티)와 그 관계를 큰 틀에서 표현하는 과정

• 핵심은 현실 세계의 객체를 데이터베이스에 맞게 구조화하는 작업

2-02. 엔티티(Entity) 도출

개념적 모델링의 첫 번째 단계로, 전체 모델링의 뼈대를 형성한다.

• 엔티티란?
  • 데이터베이스에서 저장하고 관리해야 할 정보 단위로, 현실 세계의 객체(Object)(대상 또는 사건)를 말함
  • 특성 : 식별 가능성, 지속성, 속성 보유, 관계 가능성

1) 엔티티 도출 방법론

명확하게 나눠서 적용하기보다는 다 같이 활용함

1. 명사 추출 기법(Noun Analysis) : 명사 형태로 단어 추출
2. 질문 기반 도출 : 저장할 필요성이 있는가?, 고유하게 구별이 가능한가? 등

2-03. 엔티티 간 관계 정의

관계 정의는 데이터베이스 설계에서 서로 다른 엔티티 간의 상호작용 구조를 명시하는 단계

1) 관계의 유형

관계가 카디널리티(Cardinality)에 따라 3가지로 나눠짐.

• 1:1 - 한 개체는 하나의 개체와 관계를 가짐
• 1:N - 한 개체는 여러 개체와 관계를 맺을 수 있음
• N:M - 다수의 개체가 다수와 관계를 맺음
  • N:M 관계는 실제 테이블로 구현할 때 중간 테이블(연결 엔티티)을 반드시 생성할 것!

카디널리티는 관계에 참여하는 엔티티의 인스턴스 개수를 제한함

2) 필수 관계와 선택 관계

관계 정의 시 해당 관계가 “항상 존재해야 하는지(필수)” 또는 “존재할 수도 없을 수도 있는지(선택)”를 판단해야 함

• 필수 관계 : 관계가 반드시 존재해야 함.
• 선택 관계 : 관계가 없을 수도 있음

3. 논리적 모델링

3-01. 논리적 모델링 (Logical Data Modeling)

용자의 요구사항을 기반으로 식별된 엔티티와 속성 간의 관계를 정형화된 구조로 표현하는 과정

• 목적 : 데이터 구조의 명확화, 중복 최소화, 도메인 정의, 개발 표준 수립

3-02. 속성 정의와 설계

1) 속성(Attribute)이란?

엔티티가 가지는 구체적인 데이터 항목

• 구성 요소 : 속성명, 도메인, 데이터 타입, 제약 조건
• 분류 : 기본 속성, 파생 속성, 복합 속성, 다중값 속성

2) 속성 도메인(Domain) 정의

데이터의 일관성과 정합성을 보장하기 위해 속성은 반드시 도메인을 정의해야 한다.

-- PostgreSQL 예시: CHECK 제약조건을 통한 도메인 제한
CREATE TABLE member (
  id UUID PRIMARY KEY,
  name VARCHAR(50) NOT NULL,
  gender CHAR(1) CHECK (gender IN ('M', 'F')),
  birth_date DATE
);

3-03. 식별자 설계

1) 식별자(Identifier)

엔티티의 각 인스턴스를 고유하게 구별할 수 있도록 해주는 속성

• 같은 테이블 안에서 중복되지 않는 값
• 역할 기준 분류
  • 후보 키(Candidate Key) :한 테이블 내에서 엔티티를 식별할 수 있는 후보가 되는 모든 키 집합
  • 기본 키(Primary Key) : 후보 키 중 실제로 테이블의 주 식별자로 선택된 키로, 테이블당 하나만 존재
  • 대체 키(Alternate Key) : 후보 키 중에서 기본 키로 선택되지 않은 나머지 키들
• 구성 기준 분류
  • 단일 키(Single Key) : 하나의 컬럼으로 식별
  • 복합 키(Composite Key) : 두 개 이상의 컬럼 조합으로 식별
  • 슈퍼 키(Super Key) : 행을 유일하게 식별할 수 있는 컬럼(들의) 집합 전부

3-04. 정규화(Normalization) 수행

정규화는 관계형 데이터베이스 설계에서 테이블을 목적에 맞게 분해하고 재구성하여 데이터의 중복을 최소화하고 무결성을 높이기 위한 일련의 과정

• 목적 : 삽입/수정/삭제 이상(Anomaly)을 방지하고, 논리적으로 일관된 데이터 구조를 만드는 것
• 유형
  • 1NF(제1정규형) : 모든 테이블의 모든 열이 원자적인 값을 가져야 하고, 각 행이 고유한 키로 식별되어야 한다.
  • 2NF(제2정규형) : 비키(non-key)속성이 기본 키에 완전히 함수적 종속되어야 한다.
  • 3NF(제3정규형) : 모든 비키(non-key)속성이 기본 키에 대해 이행적 함수적 종속이 없어야 한다.
  • BCNF(보이스-코드 정규형) : 어떤 값이 다른 값을 결정(결정자)한다면, 그 결정하는 쪽은 반드시 행을 유일하게 식별할 수 있어야 한다.

4. 물리적 모델링

4-01. 물리적 모델링

논리적 모델링 결과를 바탕으로, 특정 DBMS에 맞게 실제 스키마로 구현 가능한 형태로 구체화하는 과정

• 목적 : 테이블/컬럼/데이터 타입/제약조건 등을 확정하고, 성능·운영 요구사항을 반영해 실행 가능한 설계로 만드는 것

4-02. 테이블 설계

• 테이블 명명 규칙 : 소문자와 언더스코어(_), 복수형을 사용하고, 접두사는 지양한다.
• 컬럼 데이터 타입 선정
• 기본값과 제약조건 설정

4-03. 키와 키의 제약조건 구현

• 기본 키(PK, Primary Key) 생성 전략
  • SERIAL, BIGSERIAL, UUID, 복합 키
• 외래키 제약 조건
  • 외래 키(FK, Foreign Key) : 다른 테이블의 기본키를 참조하여 관계를 설정
  • 옵션 : ON DELETE CASCADE, ON UPDATE CASCADE, RESTRICT / NO ACTION, ON DELETE SET NULL
• 고유키 제약 조건
  • 고유 키(Unique Key) : 중복되지 않는 값을 요구하지만, NULL 허용 여부는 명시 가능

4-04. 참조 무결성 규칙 설정

1) 참조 무결성(Referential Integrity)

관계형 데이터베이스에서 상위 테이블(부모)의 값이 없는 상태로 하위 테이블(자식)의 값이 존재하지 않게 하는 규칙으로, 데이터 신뢰성을 보장하고 관계를 명확화하며 유지보수에 용이해짐

2) CASCADE

• 부모 테이블 데이터 변경/삭제 시 자식 테이블에 동일하게 반영
• 삭제 시 연쇄 삭제, 변경 시 연쇄 변경 발생

3) SET NULL

• 부모 테이블 삭제/변경 시 자식 테이블 외래키를 NULL로 변경
• 외래키가 NULL 허용이어야 함

4) RESTRICT / NO ACTION

• 부모 테이블 데이터 삭제/변경 불가 (참조 중이면 거부)
• (PostgreSQL 기본값) RESTRICT, NO ACTION 동일하게 작동

4-05. 성능 최적화 - 인덱스 설계

인덱스(index, 색인)는 데이터베이스에서 검색 속도를 빠르게 하기 위한 자료구조

• 인덱스를 활용하지 않으면 테이블의 모든 데이터를 순차 탐색(Full Scan)해야 함
• 종류: B-Tree, Hash, GiST, GIN, BRIN

1) 설계 원칙

• 읽기 성능 우선
• 카디널리티(중복도) 고려
• 조회 패턴 반영
• 과도한 인덱스 지양

2) 적용 기준

• WHERE 절에 자주 등장하는 컬럼
• 조인 키로 사용되는 컬럼
• ORDER BY / GROUP BY 기준 컬럼
• DISTINCT(중복방지)로 자주 조회되는 컬럼

5. ERD 작성

5-01. ERD (Entity-Relationship Diagram)란?

데이터베이스 구조를 시각적으로 표현한 다이어그램

• 시스템에 필요한 데이터 구조와 관계를 명확히 설계하는 데 사용
• 개념적 모델링에서는 엔티티/관계 중심으로 표현
• 논리적 모델링에서는 속성/키/정규화까지 포함

5-02. ERD 구성요소

• 엔티티 : 데이터를 저장하는 테이블에 해당
• 속성 : 컬럼으로 저장되는 데이터 항목
• 기본키(PK) : 각 엔티티의 고유값
• 외래키(FK) : 다른 테이블을 참조하는 컬럼
• 관계 : 엔티티 간의 연결

5-03. ERD 표기법

1) IE 표기법 (Information Engineering)

한국 실무에서 가장 널리 사용되는 ERD 표기법

대부분의 DB 설계 도구에서 기본으로 지원

• 구성 요소
  • 엔티티 : 사각형으로 표현
  • 속성 : 타원형으로 표현하거나 생략
  • 관계선 : 엔티티 간 선으로 연결, 관계명을 표시
  • 카디널리티 : 관계선 양 끝에 숫자나 기호로 표기

  

2) UML 표기법

객체지향 설계를 위한 다이어그램이지만, ERD에서 클래스 다이어그램 형식으로 사용됨

• Java/Spring 기반 프로젝트에서 DB 구조를 시각화할 때 유용

+-------------+        +-------------+
|   Member    |1      *|    Order    |
+-------------+--------+-------------+
| id: Long    |        | id: Long    |
| name: String|        | date: Date  |
+-------------+        +-------------+

Spring Data JPA 도입하기

1. ORM과 JPA의 이해

1-01. Spring 데이터 엑세스 기술

1) SQL 중심 기술

개발자가 SQL 쿼리를 직접 작성하여 데이터베이스에 접근하는 방식

• 대표 기술 : MyBatis, Spring JDBC

2) 객체 중심 기술 (ORM)

SQL을 직접 쓰기보다, 객체 모델로 데이터 작업을 표현하고, 실제 SQL 생성과 실행은 도구(ORM)가 담당하는 방식

• 대표 기술 : JPA, Spring Data JPA

1-02. JAP (Java Persistence API)

Java 진영에서 사용하는 ORM(Object-Relational Mapping) 기술의 표준 API(사양 또는 명세, Specification)

• DBMS에 독립성을 가짐

1) Hibernate

JPA 표준 사양을 구현한 구현체(ORM 프레임워크)로는 Hibernate ORM, EclipseLink, DataNucleus 등이 존재(실제 동작 담당)

• 동작 구조 : Application ➡️ Spring Data JPA ➡️ JPA Interface ➡️ Hibernate ➡️ JDBC ➡️ DB

2) 동작 단계

1. Entity 생성 ➡️ persist()로 영속 상태 진입 (DB 상태 X)
2. 트랜잭션 커밋 시 실제 SQL 실행 ➡️ DB 반영
3. 조회 시 1차 캐시(Persistence Context) 우선 검색