📚FOS Study
홈카테고리
홈카테고리

카테고리

  • AI 페이지로 이동
    • RAG 페이지로 이동
    • agents 페이지로 이동
    • BMAD Method — AI 에이전트로 애자일 개발하는 방법론
    • Claude Code의 Skill 시스템 - 개발자를 위한 AI 자동화의 새로운 차원
    • Claude Code 멀티 에이전트 — Teams
    • 멀티모달 LLM (Multimodal Large Language Model)
  • architecture 페이지로 이동
    • 캐시 설계 전략 총정리
    • 디자인 패턴
    • 분산 트랜잭션
  • css 페이지로 이동
    • FlexBox 페이지로 이동
  • database 페이지로 이동
    • mysql 페이지로 이동
    • opensearch 페이지로 이동
    • redis 페이지로 이동
    • 김영한의-실전-데이터베이스-설계 페이지로 이동
    • 커넥션 풀 크기는 얼마나 조정해야할까?
    • 인덱스 - DB 성능 최적화의 핵심
    • 역정규화 (Denormalization)
    • 데이터 베이스 정규화
  • devops 페이지로 이동
    • docker 페이지로 이동
    • k8s 페이지로 이동
    • k8s-in-action 페이지로 이동
    • monitoring 페이지로 이동
  • go 페이지로 이동
    • Go 언어 기본 학습
  • http 페이지로 이동
    • HTTP Connection Pool
  • interview 페이지로 이동
    • 210812 페이지로 이동
    • 뱅크샐러드 AI Native Server Engineer
    • CJ 올리브영 지원 문항
    • CJ 올리브영 커머스플랫폼유닛 Back-End 개발 지원 자료
    • 마이리얼트립 - Platform Solutions실 회원주문개발 Product Engineer
    • NHN 서비스개발센터 AI서비스개발팀
    • nhn gameenvil console backend 직무 인터뷰 준비
    • 면접을 대비해봅시다
    • Tossplace Node.js Developer
    • 토스플레이스 Node.js 백엔드 컬처핏
  • java 페이지로 이동
    • jdbc 페이지로 이동
    • opentelemetry 페이지로 이동
    • spring 페이지로 이동
    • spring-batch 페이지로 이동
    • 더_자바_코드를_조작하는_다양한_방법 페이지로 이동
    • Java의 로깅 환경
    • MDC (Mapped Diagnostic Context)
    • OpenTelemetry 란 무엇인가?
    • Java StampedLock — 읽기 폭주에도 쓰기가 밀리지 않는 락
    • Virtual Thread와 Project Loom
  • javascript 페이지로 이동
    • Data_Structures_and_Algorithms 페이지로 이동
    • Heap 페이지로 이동
    • typescript 페이지로 이동
    • AbortController
    • Async Iterator와 제너레이터
    • CommonJS와 ECMAScript Modules
    • 제너레이터(Generator)
    • Http Client
    • Node.js
    • npm vs pnpm 선택기준은 무엇인가요?
    • `setImmediate()`
  • kafka 페이지로 이동
    • Kafka 기본
    • Kafka를 사용하여 **데이터 정합성**은 어떻게 유지해야 할까?
    • 메시지 전송 신뢰성
  • linux 페이지로 이동
    • fsync — 리눅스 파일 동기화 시스템 콜
    • tmux — Terminal Multiplexer
  • network 페이지로 이동
    • L2(스위치)와 L3(라우터)의 역할 차이
    • L4와 VIP(Virtual IP Address)
    • IP Subnet
  • react 페이지로 이동
    • JSX 페이지로 이동
    • VirtualDOM 페이지로 이동
    • v16 페이지로 이동
  • task 페이지로 이동
    • ai-service-team 페이지로 이동
    • nsc-slot 페이지로 이동
    • the-future-company 페이지로 이동
📚FOS Study

개발 학습 기록을 정리하는 블로그입니다.

바로가기

  • 홈
  • 카테고리

소셜

  • GitHub
  • Source Repository

© 2025 FOS Study. Built with Next.js & Tailwind CSS

목록으로 돌아가기
🗄️database

데이터 베이스 정규화

약 4분
2026년 3월 24일
GitHub에서 보기

데이터 베이스 정규화

  • https://3months.tistory.com/193

  • 정규화 : 데이터베이스의 설계를 재구성하는 테크닉

  • 정규화를 통해 불필요한 데이터(redundancy)를 없앨 수 있다

  • 또한 삽입/갱신/삭제 시 발생할 수 있는 각종 이상현상(Anamolies)들을 방지할 수 있다

  • 정규화의 목적

    1. 불필요한 데이터 제거
    2. 데이터 저장을 "논리적" 으로 함 => 논리적이고 직관적
  • 정규화를 안했을 때의 문제점

s_ids_names_addresssubject_opted
401AdamNoidabio
402AlexPanipatMaths
403StuartJammuMaths
404AdamNoidaPhysics
  • 위와 같이 정규화 되지 않은 테이블은 => Adam이라는 학생 이름 값이 두번 들어가있다
  • 또한 데이터 핸들링시 다양한 이상현상이 발생한다
  1. Update : Adam의 Address가 변경되었을 때, 여러줄의 데이터를 갱신해야 한다 => 이로 인해 데이터의 불일치(inconsistency)가 발생할 수 있다
  2. Insert : 학생이 아무 과목도 수강하지 않는다고 하면, Subject_opted 컬럼에는 NULL 값이 들어간다
  3. Deletion : 만약 Alex 학생이 과목 수강을 취소한다면 Alex의 레코드가 테이블에서 아예 사라진다
  • 위와 같이 정규화가 제대로 되지 않는 테이블의 경우 갱신/삽입/삭제 시 다양한 문제점이 발생할 수 있다

  • 테이블의 구성을 논리적으로 변경하여 해결하고자 하는 것이 바로 정규화이다

  • 정규화의 법칙(Normalization Rule)은 1차 정규화, 2차 정규화, 3차 정규화, BCNF, 4차 정규화, 5차 정규화로 나뉜다

  • 실무적으로 4차, 5차 정규화까지 하는 경우는 많지많다

  • 이 글에서도 BCNF 까지 알아본다

1차 정규화

  • 1차 정규형 : 각 로우마다 컬럼의 값이 1개씩만 있어야 한다

  • 이를 컬럼이 원자값(Atomic Value)를 갖는다고 한다

  • 아래의 테이블 구조를 보자

StudentAgeSubject
Adam15Biology, Maths
Alex14Maths
Stuart17Maths
  • 위의 정보를 표현하고 싶은 경우는 아래와 같이 하나의 로우를 더 만들어야 한다
  • 결과적으로 1차 정규화를 함으로써 데이터 redundancy는 더 증가하였다
  • 데이터의 논리적 구성을 위해 이 부분을 희생한다고 볼 수 있다
StudentAgeSubject
Adam15Biology
Adam15Maths
Alex14Maths
Stuart17Maths

2차 정규화

  • 본격적인 정규화의 시작

  • 2차 졍규형 : 테이블의 모든 컬럼이 완전 함수적 종속을 만족

  • 기본키중에 큭정 컬럼에만 종속된 컬럼(부분적 종속)이 없어야 한다

  • 위 테이블의 경우 기본키는 (Student, Subject)로 두 개의 컬럼이 키가 된다고 볼 수 있다

  • 그런데 Age의 경우 기본키 컬럼중에 Student에 종속되어 있다

  • 즉, Student 컬럼의 값을 알면 Age의 값을 알 수 있게 된다.

  • 따라서 Age가 여러번 들어가는 것은 불필요하다고 볼 수 있다

  • Student Table

StudentAge
Adam15
Alex14
Stuart17
  • Subject Table
StudentSubject
AdamBiology
AdamMaths
AlexMaths
StuartMaths
  • 이를 해결하기 위한 방법은 위처럼 테이블을 분리하는 것이다
  • 그러면 두 테이블 모두 2차 정규형을 만족하게 된다
  • 조금 더 복잡한 테이블의 경우, 3차 정규화를 해야한다

3차 정규화

  • Student Detail Table

    Student_idStudent_nameDOBStreetCityStateZip
  • 위와 같은 테이블이 구성을 생각해보자

  • Student_id가 기본키이고 기본키가 하나임으로 2차 정규형은 만족한다

  • 하지만 이 데이터에서 Zip 컬럼을 알면, Street, City, State를 결정할 수 있다

  • 또한 여러명의 학생들이 같은 Zip 코드를 갖는 경우도 생각할 수 있다

  • 이 때에도 Zip 컬럼을 알면 Stree, City, State가 결졍된다

  • 따라서 중복된 데이터가 생길 가능성이 있다

  • 정리해보면 3차 정규형은 기본키를 제외한 속성들간의 이행적 함수 종속이 없는 것이다

  • 기본키 이외의 다른 컬럼이 그외 다른 컬럼을 결정할 수 없다

  • 3차 정규화도 2차 정규화와 마찬가지로 테이블을 분리함으로써 해결할 수 있다

  • New Student Detail Table

Student_idStudent_nameDOBZip
  • Address Table
ZipStreetCityState

BCNF (Boyce and Codd Normal Form)

  • 3차 정규형을 조금 더 강화한 버전
  • 3차 정규형을 만족하면서 모든 결정자가 후보키 집합에 속한 정규형
  • BCNF를 만족하지 않는 경우 => 일반 컬럼이 후보키를 결정하는 경우
database 카테고리의 다른 글 보기수정 제안하기

댓글

댓글을 불러오는 중...
목차
  • 데이터 베이스 정규화
  • 1차 정규화
  • 2차 정규화
  • 3차 정규화
  • BCNF (Boyce and Codd Normal Form)