Database Normalization: 1NF to BCNF Explained

데이터베이스 정규화는 기능 종속성과 일반 양식을 통해 데이터 중복을 줄여 효율적인 데이터 관리를 보장합니다.

### 데이터베이스 정규화 이해하기: 1NF에서 BCNF로
* 📊 오늘은 **1NF 정규화의 기본**부터 시작하여 기능 종속성을 사용하여 데이터베이스를 정규화하는 방법을 살펴보겠습니다.
* 🔍 첫 번째 노멀 폼(1NF)은 노멀 폼이라는 특정 규칙에 따라 데이터를 구조화하여 **데이터 중복과 이상 현상을 최소화**하는 것을 목표로 합니다.
* 📈 정규화를 진행하려면 각 단계가 이전 단계를 만족해야 합니다. 즉, **테이블이 3NF에 있으면 1NF와 2NF에도 해당**합니다.
* 📚 일반적으로 정규화를 위한 최소 표준은 **3NF 이상**으로 간주되지만, 실제 적용은 **3NF 또는 BCNF에서 멈추는 경우**가 많으며, **4NF는 복잡성** 때문에 덜 일반적입니다.
* 🏦 기능적 종속성과 키로만 정의되어 실제 애플리케이션에 실용적인 **BCNF까지 네 가지 노멀 폼**을 설명하는 데 초점을 맞출 것입니다.
* 🗃 분석할 예제 테이블은 **은행 이름, 계좌 번호, 급여 분배 비율**과 같은 속성을 포함한 직원 급여 계좌 정보를 관리합니다.
* 🔑 이 표에서 기본 키는 각 계정을 고유하게 식별하는 **계정 ID**이며, **은행 이름과 계좌 번호의 조합**도 후보 키 역할을 합니다.
* 📉 정규화 프로세스를 시작하면서 **표에 있는 기능 종속성을 시각화**하여 정규화가 어떻게 중복성을 줄이고 데이터 무결성을 향상시키는지 설명하겠습니다.

### 데이터베이스 정규화 이해하기: 1NF에서 2NF로
* 📊 급여 분배 과정은 수입을 세 개의 계정으로 나누고, 한 계정은 **10%(0.1)**, 다른 계정은 **20%(0.2)**, 마지막 **70%(0.7)**를 특정 비율로 분배하는 방식으로 이루어집니다.
* 💳 각 계정은 고유한 카드 ID에 연결되어 있으며, 다른 시스템인 Mesh는 전체 급여에 대해 단일 계정을 사용하지만 **연결된 카드 ID가 두 개** 있습니다.
* 🔍 첫 번째 정규화 형식(1NF)은 모든 속성 값이 원자 단위여야 하지만 현재 설정은 **단일 항목에 값이 결합**되어 있어 이 규칙을 위반합니다.
* 🔄 이를 수정하기 위해 값을 분리하는 새로운 튜플을 생성하여 **1NF 위반을 해결**하지만, 이로 인해 데이터가 중복되고 비율 합계가 **1이 아닌 2로 잘못 계산**됩니다.
* 🔑 또한 계정 ID가 중복되면 튜플을 고유하게 식별할 수 없으므로 기본 키를 수정해야 하며, **계정과 카드 ID가 모두 포함된 복합 키**가 필요합니다.
* 📈 두 번째 정규화 형식(2NF)으로 이동하면, 소수가 아닌 모든 속성이 **기본 키에 완전히 기능적으로 종속**되어야 하지만 현재 부분 종속성으로 인해 그렇지 않다는 것이 확립됩니다.
* 🚧 해결 방법에는 중복성을 제거하기 위해 **속성을 다른 테이블로 분리**하여 모든 소수가 아닌 속성이 기본 키에 전적으로 의존하도록 하는 것이 포함됩니다.
* ✅ 재구조화 후 테이블은 이제 **2NF를 충족**하여 소수가 아닌 모든 속성이 새 디자인에서 설정된 복합 키에 기능적으로 완전히 종속되어 있음을 확인합니다.

(1부) DB 정규화(normalization)는 DB를 설계하는 공식적인 방법이죠~ 1부에서는 정규화 개념과 정규화 과정의 앞 부분인 1NF, 2NF를 설명합니다 :)

8년차 백엔드 개발자가 배워서 남주려고 만든 채널이에요

알기 쉽게 설명합니다

함께 성장했으면 좋겠어요 :)


#컴공맛집 #백엔드전문채널


쉬운코드

데이터베이스 정규화 소개 및 1NF 설명

1NF 정규화의 목적: 데이터 중복 및 이상 현상(업데이트, 삭제, 삽입 문제) 최소화

1NF 정규화 과정: 노멀 폼에 따라 데이터를 릴레이션으로 구성

노멀 폼: 정규화를 위해 준수해야 하는 룰들

정규화 과정: 초기 테이블에 노멀 폼 순차 적용

단계적 적용: 앞 단계 만족 시 다음 단계 진행 (예: 3NF 만족 시 1NF, 2NF도 만족)

1NF ~ BCNF: 함수적 종속성과 키로 정의되는 노멀 폼

일반적 정규화 기준: 3NF 도달 시 정규화 완료

실무 정규화 범위: 3NF 또는 BCNF까지 (최대 4NF)

5NF, 6NF 이상은 케이스 발생 가능성 낮고 복잡하며 학술적 분석 경향이 강함

본 영상 설명 범위: 1NF ~ BCNF (실무 적용 빈도 고려)

임직원 월급 계좌 정보 테이블 예시 및 키 개념 설명

테이블 구성: 임직원 월급 계좌 정보 관리 (국민/우리은행, 월급 분배 비율, 계좌 등급, 카드 정보)

슈퍼키: 테이블에서 튜플을 유니크하게 식별하는 애트리뷰트 집합

캔디데이트 키(키): 어떤 애트리뷰트도 제거하면 유니크 식별 불가능한 슈퍼키

예시 테이블 키: account id (단일 애트리뷰트 키), {bank name, account number} (다중 애트리뷰트 키)

프라이머리 키: 유니크 튜플 식별을 위해 선택된 캔디데이트 키 (본 예시: account id)

함수적 종속성(Functional Dependency) 분석

프라이머리 키(account ID) 기반 함수적 종속성: account ID 동일 시 다른 애트리뷰트 값도 동일

{bank name, account number} 키 기반 함수적 종속성: 키 값 동일 시 다른 애트리뷰트 값도 동일

employee ID와 employee name 간 함수적 종속성: employee ID 동일 시 employee name도 동일

계좌 등급(class)과 은행 이름(bank name) 간 함수적 종속성: class 동일 시 bank name도 동일

정규화(Normalization) 과정 시작 및 1NF 적용

정규화 과정: 1NF부터 순차적으로 진행

데이터 추가: 중복 데이터 발생 확인을 위한 예시 데이터 추가

1NF 규칙: 모든 애트리뷰트 값은 나누어질 수 없는 단일 값

1NF 위반 사항: 월급 분배 비율(ratio) 애트리뷰트가 단일 값이 아님

1NF 위반 해결: 튜플 추가 및 값 분리, 중복 데이터 발생

2NF 적용 및 중복 데이터 문제 해결

중복 데이터 원인 분석: 키 확인 및 non-prime attribute 파악

non-prime attribute: 키에 속하지 않는 attribute (class, ratio, employee ID)

키 기준 함수적 종속성 분석: non-prime attribute의 부분적 종속성(partial dependency) 확인

2NF 규칙: 모든 non-prime attribute가 모든 키에 대해 완전 함수적 종속(fully functional dependency)

2NF 위반 해결: 카드 정보 테이블 분리, 중복 데이터 제거

2NF 만족 확인: 두 테이블 모두 non-prime attribute가 모든 키에 대해 fully functional dependency 만족

3NF 확인: 남은 중복 데이터 확인 및 추가 정규화 여부 판단