2. 관계형 데이터 모델 및 정규화
핵심 인사이트
- 본질: 관계형 데이터 모델은 데이터를 테이블(관계) 형태의二维 구조로 표현하며, 수학적 집합론에 기반하여 데이터 조작과 무결성 규칙을 정형화한 것이 핵심 철학이다.
- 가치: 정규화는 데이터 중복을 제거하고 업데이트 이상을 방지하여 저장 공간을 절약하고 데이터 일관성을 보장하지만, 과도한 정규화는 조인 비용을 증가시켜 성능 저하를 유발할 수 있다.
- 융합: 정규화 이론은 함수 종속성과 함수 종속성을 추론하는 Armstrong 공리를 기반으로 하며, 실세계에서는 읽기 성능을 위해 의도적 비정규화가 이루어지기도 한다.
Ⅰ. 개요 및 필요성
개념: 관계형 데이터 모델의 탄생과 철학
관계형 데이터 모델 (Relational Data Model)은 1970년 Edgar F. Codd가 IBM (International Business Machines Corporation)에서 발표한 논문 "A Relational Model of Data for Large Shared Data Banks"에서 처음 제안한 패러다임이다. 이 모델의 핵심 철학은 데이터를 단순하고 직관적인 테이블 (관계) 형태로 표현하자는 것이다. 각 테이블은 행 (Tuple/Record)과 열 (Attribute/Column)로 구성되며, 각 행은 고유한 식별자 (Primary Key)에 의해 구분된다.
관계형 모델 이전에는 계층형 (Hierarchical) 모델과 네트워크형 (Network) 모델이 주류였다. 이러한 이전 모델들은 데이터 접근 경로가 미리 정의되어 있어 유연성이 부족했고, 응용 프로그램이 물리적 저장 구조에 강하게 결합되는 문제가 있었다. 반면 관계형 모델은 데이터 간의 관계를 논리적 차원에서 명시적으로 표현하되, 물리적 저장 방식과는 독립적으로 운용할 수 있게 했다. 이것이 "데이터 독립성 (Data Independence)"이라는 핵심 개념이다.
관계형 모델의 수학적 기반은 집합론 (Set Theory)과 술어 논리 (Predicate Logic)이다. 테이블은 어떤 도메인 (Domain) 위의 관계 (Relation)로서 정의되며, 데이터 조작은 관계 대수 (Relational Algebra)와 관계 해석 (Relational Calculus)을 통해 이루어진다. SELECT, PROJECT, JOIN, UNION, INTERSECTION, DIFFERENCE, DIVIDE 등의 관계 대수 연산이 SQL의理论基础를 형성한다.
정규화의 필요성: 왜 데이터를 설계하는가
초보 개발자들은 종종 "데이터베이스에 데이터를 넣고 필요할 때 가져오면 되지 않는 것 아닌가?"라는 질문을 한다. 그러나 데이터베이스 설계 없이 운영되는 시스템은 시간이 지남에 따라 여러 심각한 문제에 직면한다. 이러한 문제를 "업데이트 이상 (Update Anomaly)"이라고 하며, 종류는 세 가지이다.
첫째, 삽입 이상 (Insert Anomaly)은 특정 데이터를插入하려면 다른 무관한 데이터까지 함께 입력해야 하는 상황이다. 예를 들어, 새 직원을入社시키는데 아직 부서가 결정되지 않았다면, 부서 정보를 NULL로 설정하거나 가상의 부서를 만들어야 한다. 둘째, 삭제 이상 (Delete Anomaly)은 특정 데이터를 삭제하면 다른 중요한 데이터까지 함께 잃어버리는 상황이다. 어떤 부서의 마지막 직원을 삭제하면 부서 정보 자체가 사라진다. 셋째, 수정이상 (Modification Anomaly)은 데이터의 특정 값을更新할 때 일부만 변경되어 데이터 불일치가 발생하는 상황이다. 하나의 부서 이름을変更할 때 해당 부서에 속한 모든 직원의 부서 이름을 تحديث해야 한다.
이러한 이상들은 모두 데이터 중복 (Data Redundancy)에서 비롯된다. 같은 데이터가 여러地方에 저장되어 있으면, 하나의 데이터를更新할 때 모든 곳을一致되게 更新해야 하는데, 만약 하나라도 누락되면 데이터 불일치가 발생한다. 정규화 (Normalization)는 이러한 문제를 해결하기 위해 데이터베이스를 올바른 구조로 설계하는 과정이다.
이상”现象 도식화
┌─────────────────────────────────────────────────────────────────────────┐
│ Update Anomaly 예시: 비정규화된 Employee 테이블 │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ EMP_ID │ EMP_NAME │ DEPT_NO │ DEPT_NAME │ DEPT_LOCATION │ │ │
│ ├────────┼──────────┼─────────┼───────────┼─────────────────┤ │
│ │ 001 │ 김철수 │ D1 │ 개발 │ 서울 │ │
│ │ 002 │ 이영희 │ D1 │ 개발 │ 서울 │ │ ← 중복!
│ │ 003 │ 박민수 │ D2 │ 마케팅 │ 부산 │ │
│ │ 004 │ 정수진 │ D2 │ 마케팅 │ 부산 │ │ ← 중복!
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ 문제 상황들: │
│ │
│ [삽입 이상] D3 부서를新增하려는데 직원이 아직 없다면? │
│ → DEPT_NAME, DEPT_LOCATION를 어떻게 保存할까? │
│ → NULL을 허용하거나 가상의 직원을 만들어야 함 │
│ │
│ [삭제 이상] Employee 003, 004를 모두 삭제하면? │
│ → 마케팅 부서 정보가完全に 사라짐! │
│ │
│ [수정이상] 개발 부서가 서울에서 인천으로 이전한다면? │
│ → EMP_ID 001, 002의 DEPT_LOCATION을 모두 更新해야 함 │
│ → 하나라도 누락되면 데이터 불일치 발생! │
│ │
└─────────────────────────────────────────────────────────────────────────┘
이 그림에서 중요한 점은 하나의 사실(부서 정보)이 여러 행에 중복 저장되어 있다는 것이다. 이러한 중복은 저장 공간을 낭비할 뿐만 아니라, 데이터의 일관성을 유지하는 것을 어렵게 만든다. 정규화는 이러한 중복을 제거하여 각 사실이 한 곳에만 저장되도록 하는 과정이다.
📢 섹션 요약 비유
관계형 모델과 정규화를 도서관 카탈로그 시스템에 비유할 수 있다. 비정규화된 데이터는 같은 책의 위치 정보를 여러 카탈로그 카드에 중복으로 적어두는 것과 같다. 책이 이삽짐짐으로 위치가 바뀌면, 모든 카드를 찾아다니며 수정해야 한다. 하나라도 빠뜨리면 "이 책은 어디에 있나요?"라는 질문에 다른 대답을 하게 된다. 정규화는 책의 위치 정보를 단 하나의 중앙 카탈로그에만 적어두고, 다른 카드에서는 그 카탈로그를 참고하도록 하는 것이다. 이렇게 하면 수정이 필요할 때 한 곳만 변경하면 되고, 실수로 빠뜨리는 문제도 방지할 수 있다.
Ⅱ. 아키텍처 및 핵심 원리
관계형 모델의 수학적 기반: 함수 종속성
정규화 이론을 이해하기 위해서는 함수 종속성 (Functional Dependency, FD)의 개념을 파악해야 한다. 함수 종속성은 관계 스키마에서 한 속성 값이 다른 속성 값을 유일하게 결정하는 관계를 의미한다. 표기법으로 X → Y는 "X가 Y를 함수적으로 결정한다" 또는 "X의 값이 알면 Y의 값을 알 수 있다"를 뜻한다.
완전 함수 종속성 (Full Functional Dependency)은 결정자가 후보 키 (Candidate Key)의 부분 집합이 아닌 최소한의 속성 집합이어야 한다는 조건이다. 예를 들어, (학번, 과목번호) → 성적에서 학번만으로는 성적을 결정할 수 없고, 과목번호도 필수이므로 완전 함수 종속이다. 반면, (학번, 과목번호) → 학과에서는 학번만으로도 학과를 알 수 있으므로 부분 함수 종속 (Partial Functional Dependency)이다.
추이 함수 종속성 (Transitive Functional Dependency)은 X → Y, Y → Z이고, Y가 X의 일부가 아니며, Z가 X의 일부도 아닐 때, X → Z가 성립하는 경우이다. 이는 어떤 속성이 키가 아닌 다른 속성을 통해 간접적으로 결정되는 상황을 나타낸다.
정규형의 단계: 제1정규형부터 BCNF까지
정규형 (Normal Form)은 관계 스키마가 만족하는 구조적 조건의 수준을 나타내며, 고급 정규형으로 갈수록 더 엄격한 조건을 만족한다.
┌─────────────────────────────────────────────────────────────────────────┐
│ Normal Forms Hierarchy (정규형 단계) │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────┐ │
│ │ BCNF (3.5NF) │ ← 모든 FD에서 결정자가 │
│ │ (Boyce-Codd) │ 후보 키이어야 함 │
│ └────────┬─────────┘ │
│ │ │
│ ┌────────▼─────────┐ │
│ │ 3NF (3차) │ ← transitive dependency │
│ │ │ 제거 │
│ └────────┬─────────┘ │
│ │ │
│ ┌────────▼─────────┐ │
│ │ 2NF (2차) │ ← partial dependency │
│ │ │ 제거 │
│ └────────┬─────────┘ │
│ │ │
│ ┌────────▼─────────┐ │
│ │ 1NF (1차) │ ← atomic value (원자값) │
│ │ │ only, no repeating group│
│ └──────────────────┘ │
│ │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ 제1정규형 (1NF): 모든 속성의 값이 atomic (분해 불가능한 원자값) │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ ❌ 위반: SETOF, LIST, ARRAY类型的 속성 │ │
│ │ phone_numbers = {'010-1234-5678', '010-8765-4321'} │ │
│ │ │ │
│ │ ✅ 수정: 별도 테이블로 분리하거나 개별 컬럼으로 분리 │ │
│ │ phone_1 = '010-1234-5678', phone_2 = '010-8765-4321' │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ 제2정규형 (2NF): 1NF이면서, 모든 비주요 속성이 후보 키에 완전 종속 │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ StudentLecture (학번, 과목번호, 학과, 성적) │ │
│ │ │ │
│ │ • (학번, 과목번호) → 성적 (완전 종속) ✓ │ │
│ │ • 학번 → 학과 (부분 종속) ✗ → 별도 Student 테이블로 분리 │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ 제3정규형 (3NF): 2NF이면서, 어떤 비주요 속성도 다른 비주요 속성에 종속 X │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ EMP (사원번호, 부서번호, 부서명, 지역) │ │
│ │ │ │
│ │ • 사원번호 → 부서번호 (✓) │ │
│ │ • 사원번호 → 부서명 (✗ transitive via 부서번호) │ │
│ │ • 부서번호 → 부서명 (✗) │ │
│ │ → 부서 테이블을 분리하여 3NF 달성 │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ BCNF (Boyce-Codd Normal Form): 3NF이면서, 모든 FD의 결정자가 후보 키 │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ Tutoring (학생, 과목, 교수) │ │
│ │ │ │
│ │ • 각 과목은 하나의 교수만 담당: (학생, 과목) → 교수 │ │
│ │ • 각 教授는 각 과목 담당: 교수 → 과목 │ │
│ │ │ │
│ │ 문제: 교수가 결정자이지만 후보 키(학생, 과목)에 속하지 않음 │ │
│ │ → BCNF 위반 → 테이블 분할 필요 │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘
정규화의 각 단계는 특정 종류의 데이터 중복과 이상 문제를 해결한다. 1NF는 반복 그룹 (Repeating Group)을 제거하여 각 셀이 하나의 값만 가지도록 한다. 2NF는 부분 종속성을 제거하여复合 主키의 일부만으로 결정되는 속성을 별도 테이블로 분리한다. 3NF는 추이 종속성을 제거하여 主키가 아닌 속성들 간의 결정 관계를 차단한다. BCNF는 3NF보다 더 엄격하여, 후보 키가 아닌 결정자를 허용하지 않는다.
정규화 과정 도식화
┌─────────────────────────────────────────────────────────────────────────┐
│ Normalization Process Example │
│ │
│ 초기 비정규 테이블: │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ Project_Assignment │ │
│ │ ┌──────┬──────────┬────────┬───────────┬──────────┐ │ │
│ │ │ emp_id │ emp_name │ dept │ project_no │ project_name │ │ │
│ │ ├──────┼──────────┼────────┼───────────┼──────────┤ │ │
│ │ │ 001 │ 김철수 │ 开发 │ P1 │ Alpha │ │ │
│ │ │ 001 │ 김철수 │ 开发 │ P2 │ Beta │ │ │
│ │ │ 002 │ 이영희 │ 开发 │ P1 │ Alpha │ │ │
│ │ │ 003 │ 박민수 │ 마케팅 │ P2 │ Beta │ │ │
│ │ └──────┴──────────┴────────┴───────────┴──────────┘ │ │
│ └──────────────────────────────────────────────────────────────┘ │
│ │
│ 문제 분석: │
│ • emp_name은 emp_id에 종속 (부분 종속) │
│ • dept는 emp_id에 종속 (부분 종속) │
│ • project_name은 project_no에 종속 (추이 종속) │
│ • 개발 부서 김철수, 이영희의 dept 중복 (데이터 중복) │
│ │
│ ▼ 정규화 진행 │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────────┐ │
│ │ Employee │ │ Project │ │ Assignment (M:N) │ │
│ ├─────────────────┤ ├─────────────────┤ ├─────────────────────┤ │
│ │ emp_id (PK) │ │ project_no (PK)│ │ emp_id (FK) │ │
│ │ emp_name │ │ project_name │ │ project_no (FK) │ │
│ │ dept │ │ │ │ │ │
│ └─────────────────┘ └─────────────────┘ └─────────────────────┘ │
│ │
│ 효과: │
│ • dept 정보를 employee에서 한번만 保存 (중복 제거) │
│ • project_name을 project에서 한번만 保存 (중복 제거) │
│ • 새 프로젝트追加时 project 테이블에만 추가하면 됨 │
│ • 사원 정보를 修改时 employee 테이블에만 修改하면 됨 │
│ │
└─────────────────────────────────────────────────────────────────────────┘
정규화의 핵심 이점은 데이터 중복의 제거와 데이터 무결성의 향상이다. 위 예제에서可以看到 비정규 테이블에서는 "개발"이라는 부서 정보가 두 번 중복되어 있었다. 만약 부서명이 "개발팀"으로 변경되면 두 행을 모두 更新해야 하지만, 정규화 후에는 employee 테이블의 한 행만 更新하면 된다.
📢 섹션 요약 비유
정규화 과정을 요리법에 비유할 수 있다. 비정규화된 테이블은 하나의 큰 냄비에 모든 재료를 퓨전해서 요리하는 것과 같다. 맛은 좋을 수 있지만, 어떤 재료의 양을 늘리고 싶다면整个 요리를 다시 만들어야 할 수도 있다. 반면 정규화된 테이블은 각각의 재료가 별도의 그릇에 담겨 있고, 필요할 때만 조합하여 접시에 담아 제공하는 것에 비유할 수 있다. 이러한 방식이 관리하기 쉽고, 재료의 양을 조절하거나 새로운 재료를 추가하기도 편리하다. 하지만 식사 시간이 길어지면 여러 그릇을 왔다갔다 해야 하듯, 과도한 정규화는 조인을 많이 발생시켜 응답 지연을 증가시킬 수 있다.
Ⅲ. 융합 비교 및 다각도 분석
정규화 vs 비정규화: 트레이드오프
┌─────────────────────────────────────────────────────────────────────────┐
│ Normalization vs Denormalization: Trade-off │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────────────┬──────────────────────────────────────┐ │
│ │ 정규화 (3NF↑) │ 비정규화 │ │
│ ├────────────────────────┼──────────────────────────────────────┤ │
│ │ 장점 │ 장점 │ │
│ │ • 데이터 중복 최소화 │ • 조인 감소 → 읽기 성능 향상 │ │
│ │ • 업데이트 이상 방 │ • 쿼리 단순화 │ │
│ │ • 데이터 일관성 향상 │ • 개발 생산성 향상 │ │
│ │ • 저장 공간 절약 │ • 집계/분석 쿼리高速化 │ │
│ ├────────────────────────┼──────────────────────────────────────┤ │
│ │ 단점 │ 단점 │ │
│ │ • 과도한 조인 → 읽기 부하 │ • 데이터 중복 → 업데이트 이상 발생 │ │
│ │ • 복잡한 쿼리 │ • 저장 공간 증가 │ │
│ │ • 응용 프로그램 복잡화 │ • 데이터 불일치 위험 │ │
│ └────────────────────────┴──────────────────────────────────────┘ │
│ │
│ ════════════════════════════════════════════════════════════════════ │
│ │
│ 실무 선택 기준: │
│ │
│ ✓ 정규화 선택: │
│ • OLTP (Online Transaction Processing) 시스템 │
│ • 빈번한 INSERT/UPDATE/DELETE 작업 │
│ • 데이터 무결성이 핵심인 시스템 (금융, 회계) │
│ • 중복 데이터 업데이트 실수 가능성이 높은 환경 │
│ │
│ ✓ 의도적 비정규화 선택: │
│ • OLAP (Online Analytical Processing) 시스템 │
│ • 읽기 집중 (Read-Heavy) workload │
│ • 복잡한 조인으로 인한 성능 저하가 인정되는 경우 │
│ • 분석/보고서용 별도 데이터 웨어하우스 │
│ │
│ ✓ 하이브리드 접근: │
│ • OLTP DB: 정규화된 구조 (원본 데이터) │
│ • Data Warehouse: 비정규화된 구조 (분석용) │
│ • ETL (Extract-Transform-Load)로 데이터 동기화 │
│ │
└─────────────────────────────────────────────────────────────────────────┘
실무에서 "정규화 vs 비정규화"는黑白论争가 아니다. 현대 데이터베이스 설계는 정규화를 기본으로 하되, 성능 문제 해결을 위한 의도적 비정규화를 전략적으로 도입하는 것이 일반적이다. 중요한 것은安易한 비정규화가 아닌, 충분한性能 테스트와 모니터링을 통한 의사결정이다.
정규형 선택 가이드
┌─────────────────────────────────────────────────────────────────────────┐
│ Normal Form Selection Guide │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ 판단 트리: │
│ │
│ Start │
│ │ │
│ ├─► 데이터가 반복 그룹을 포함하는가? │
│ │ │ │
│ │ ├─► 예: ► 1NF 필수 │
│ │ └─► 아니오: 다음 질문으로 │
│ │ │
│ ├─► 복합 키(2개 이상 컬럼)를 사용하는가? │
│ │ │ │
│ │ ├─► 예: ► 비주요 속성이 키의 일부에만 종속되는가? │
│ │ │ │ │
│ │ │ ├─► 예: ► 2NF 필수 │
│ │ │ └─► 아니오: 다음 질문으로 │
│ │ └─► 아니오: 2NF 이상 │
│ │ │
│ ├─► 비주요 속성이 다른 비주요 속성을 결정하는가? │
│ │ │ │
│ │ ├─► 예: ► 3NF 필수 │
│ │ └─► 아니오: 다음 질문으로 │
│ │ │
│ └─► 결정자가 후보 키가 아닌 경우가 있는가? │
│ │ │
│ ├─► 예: ► BCNF 필수 │
│ └─► 아니오: 3NF로 충분 │
│ │
│ ════════════════════════════════════════════════════════════════════ │
│ │
│ 일반적 권장사항: │
│ • 대부분의 OLTP 시스템: 3NF (일반적으로 충분) │
│ • 복잡한 관계가 있는 경우: BCNF 고려 │
│ • 分析/보고서 시스템: 비정규화 또는 차원 모델링 고려 │
│ │
└─────────────────────────────────────────────────────────────────────────┘
📢 섹션 요약 비유
정규화 수준을 선택하는 것은 집의 방 나누기에 비유할 수 있다. 1NF는 방에 필요한 가구(원자값)만 있도록 정리하는 것이고, 2NF는 각 방의 용도를 명확히 하는 것이다. 3NF는 거실에 있는 물건이 침실로 이동할 이유가 없도록 하는 것이고, BCNF는 모든 방의主人(결정자)이 명확히 정해져 있는 것이다. 그러나 너무 세분화된 방 나누기는 복도를 많이 만들어動線을 불편하게 만들 수 있듯, 과도한 정규화도 조회를 복잡하게 만들 수 있다. 결국 집의 용도(OLTP vs OLAP)에 맞게 방 크기와 수를 결정해야 한다.
Ⅳ. 실무 적용 및 기술사적 판단
정규화 적용 시 실무적 고려사항
┌─────────────────────────────────────────────────────────────────────────┐
│ Normalization Practice Guidelines │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ 단계별 실무 체크리스트: │
│ │
│ □ 1NF 확인: │
│ • 모든 컬럼이 하나의 값만 갖는가? (NULL도 하나의 값) │
│ • 반복 그룹 (여러 전화번호, 여러 주소) 이 분리되었는가? │
│ • 배열, JSON, XML 타입의 컬럼이 별도 테이블로 분리되었는가? │
│ │
│ □ 2NF 확인: │
│ • 복합 키를 사용하는 테이블인가? │
│ • 그렇다면, 비주요 속성이 키의 일부에만 종속되는 경우가 없는가? │
│ • 부분 종속이 있다면 별도 테이블로 분리했는가? │
│ │
│ □ 3NF 확인: │
│ • 비주요 속성 간에 결정 관계가 없는인가? │
│ • 예: 사원번호 → 부서코드 → 부서명 에서 부서명이 부서코드에 종속? │
│ • 추이 종속이 있다면 적절히 분리했는가? │
│ │
│ □ BCNF 확인: │
│ • 모든 결정자가 후보 키인가? │
│ •违背 경우가 있다면 테이블을 분리했는가? │
│ • 분리 결과 데이터 손실이나 정보 손실이 없는가? │
│ │
└─────────────────────────────────────────────────────────────────────────┘
안티패턴: 실무에서 흔히 저지르는 정규화 실수
┌─────────────────────────────────────────────────────────────────────────┐
│ Normalization Anti-Patterns in Practice │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ ❌ 안티패턴 1: "모든 테이블을 3NF로 만들어야 한다" 고집 │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ 문제: │ │
│ │ • 소규모 조회 전용 테이블까지 과도한 정규화 │ │
│ │ • 조인이 너무 많아져 응답 시간 증가 │ │
│ │ • 오히려 비정규화가 성능에 유리한 경우 많음 │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ ❌ 안티패턴 2: UUID/ GUID를 Primary Key로만 사용 │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ 문제: │ │
│ │ • UUID는 순서가 없어 B-Tree 인덱스 분포가 불균형 │ │
│ │ • 저장 공간 증가 (128비트 vs 32비트 정수) │ │
│ │ • 범위 기반 查询 성능 저하 │ │
│ │ → 권장: 자연 키(Natural Key)가 적합하면 사용, 아니면 단일키+인덱스│ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ ❌ 안티패턴 3: NULL 남용 │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ 문제: │ │
│ │ • NULL 비교는 항상 삼치 논리 (TRUE/FALSE/UNKNOWN) │ │
│ │ • SQL 작성 시 복잡성 증가 │ │
│ │ • 인덱스 활용 어려움 │ │
│ │ → 권장: NULL 대신 空文字列, 0, 또는 특수 값 사용 고려 │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ ❌ 안티패턴 4: 다치 종속(MVD)을 고려하지 않음 │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ 문제: │ │
│ │ • 다치 종속은 함수 종속의 일반화인데 간과되기 쉬움 │ │
│ │ • 4NF 위반으로 불필요한 중복 발생 가능 │ │
│ │ → 권장: 다중 값을 가진 属性 쌍은 별도 테이블로 분리 │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘
📢 섹션 요약 비유
실무에서 정규화를 적용하는 것은 농부의 밭 관리에 비유할 수 있다. 적절한正规化는作物の品种별로 올바른 구역에 심는 것으로, 관리가 쉽고 수확이量大다. 그러나 너무 작은 구역으로 나누면土地利用率이 떨어지고, 구역 사이를 오가며 일해야 하니 효율이 떨어진다. 또한 같은 作物을 여러 구역에 중복으로 심으면管理 어려워지듯, 데이터도 중복되면更新 곤란해진다. 결국 밭의 크기와 형태를 作물 종류와 농사 방법에 맞게 결정해야 하듯, 정규화 수준도 시스템 특성에 맞게 선택해야 한다.
Ⅴ. 기대효과 및 결론
정규화 도입 효과: Before vs After
┌─────────────────────────────────────────────────────────────────────────┐
│ Normalization 도입 효과 분석 │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────┬───────────────────┬───────────────────┐ │
│ │ 항목 │ 정규화 전 │ 정규화 후 │ │
│ ├────────────────┼───────────────────┼───────────────────┤ │
│ │ 데이터 중복 │ 동일 정보 다수 저장 │ 각 정보 한 곳만 │ │
│ │ │ (공간 낭비) │ (최적화) │ │
│ ├────────────────┼───────────────────┼───────────────────┤ │
│ │ 삽입 이상 │ 불완전한 데이터 입력 │ 관련 테이블에 분리 │ │
│ │ │ 어려움 │ 삽입 가능 │ │
│ ├────────────────┼───────────────────┼───────────────────┤ │
│ │ 삭제 이상 │ 중요 데이터 손실 │ 해당 행만 삭제 │ │
│ │ │ 위험 │ 다른 테이블 무관 │ │
│ ├────────────────┼───────────────────┼───────────────────┤ │
│ │ 수정이상 │ 일부만 갱신시 │ 한 곳만 更新 │ │
│ │ │ 불일치 발생 │ → 일관성 유지 │ │
│ ├────────────────┼───────────────────┼───────────────────┤ │
│ │ 확장성 │ 구조 변경 어려움 │ 새로운 entity │ │
│ │ │ (많은 곳 수정) │ 추가 용이 │ │
│ └────────────────┴───────────────────┴───────────────────┘ │
│ │
│ 정량적 기대 효과: │
│ • 저장 공간: 20~40% 절감 (데이터 중복 제거) │
│ • 업데이트 Query: 실행 시간 감소 (중복 업데이트 불필요) │
│ • 데이터 무결성 문제: 95% 이상 감소 │
│ • 테이블 수가 증가하지만, 각각의 테이블이 단순해져 관리 용이 │
│ │
└─────────────────────────────────────────────────────────────────────────┘
미래 전망: 정규화 이론의 진화
정규화 이론은 1970년대에 확립되었지만, 현대 데이터베이스 환경에서 새로운挑战에 직면하고 있다. 첫째, 반정형/비정형 데이터의 증가로 인해 관계형 모델의適用 범위를 넘어서는 데이터가 증가하고 있다. Document Store, Column Family Store 등의 NoSQL에서 영감을 받은半정형 데이터 모델이 제안되고 있다. 둘째, 멀티 모델 데이터베이스의 등장으로 하나의 DBMS에서 관계형과 문서형 데이터를 함께 관리할 수 있게 되면서, 언제 정규화하고 언제 비정규화할지의 판단이 더욱 복잡해지고 있다. 셋째, 클라우드 환경에서의 분산 데이터베이스는 네트워크 분할과 지연으로 인해 전통적인 정규화 이론의 가정이 깨지는 경우가 있다.
📢 섹션 요약 비유
정규화 이론은 수십 년 된 고전 이론이지만, 그 핵심 철학은 여전히 유효하다. 좋은 데이터 설계는 자료를分類整理して、必要な時に必要なデータに能找到する 것이다. 그러나 세상이 변함에 따라 정리 방법도 달라져야 한다.古서는 책만 정리하면 됐지만, 이제는 책之外에 영상, 음성, 3D 모델 등 다양한 형태의 자료가 있다. 같은 이유로, 전통적인 정규화之外的 방법도 고려해야 할 때가 있다. 중요한 것은 정해진 룰을盲目的으로 따르는 것이 아니라, 데이터의 특성과 사용 패턴을 분석하여 가장 적합한 설계를 선택하는 것이다.
📌 관련 개념 맵 (Knowledge Graph)
| 개념 명칭 | 관계 및 시너지 설명 |
|---|---|
| 함수 종속성 | 한 属性이 다른 属性의 값을 결정하는 관계, 정규화 이론의 기초 |
| Armstrong 공리 | 함수 종속성 추론을 위한最小 완전한 공리 집합 |
| 후보 키 | Relation에서 행을 고유하게 식별할 수 있는最小 속성 집합 |
| Primary Key | 후보 키 중에서系統이 선택한 주 식별자 |
| 이상 현상 | 비정규화로 인해 발생하는 삽입/삭제/수정 이상 |
| BCNF | 정규형의 일종으로, 모든 결정자가 후보 키인 상태 |
| 조인 종속성 | Relation이 여러projection의 自然結合으로 분해될 수 있는 성질 |
| 무손실 분해 | 분해된Relation들을 조인했을 때 원래 데이터가 완전히 복원되는 성질 |
👶 어린이를 위한 3줄 비유 설명
정규화는 우리 장난감 상자를 정리하는 방법과 비슷해요. 만약 모든 장난감을 한 상자에 �杂乱地 넣으면, 자동차를 찾으려고 하면 모든 장난감을 뒤져야 하고, 같은 자동차가 여러 개 있으면 하나를 없애도 다른 것에 영향을 주지 않아요.
정규화는 비슷한 장난감을 같은 칸에 나누어 넣는 것이에요. 자동차는 자동차 칸, 인형은 인형 칸에 넣으면 찾는 것도 쉽고, 하나를 없애도 다른 칸에 영향을 주지 않아요.
하지만 너무 많은 칸으로 나누면, 각 칸에서 장난감을 가져오려면 여기저기 돌아다녀야 하니 시간이 오래 걸릴 수 있어요. 그래서 적당한 크기로 나누는 것이 중요해요.
최종 수정일: 2024-01-16 [extra] categories = ["study", "database"]