관계형 데이터베이스 정규화

1. 서론

관계형 데이터베이스(Relational Database Management System, RDBMS) 설계의 초석을 이루는 정규화(Normalization)는 데이터의 중복성을 체계적으로 제거하고 데이터 무결성을 향상시키기 위한 일련의 공식적인 절차이다. 1970년, 컴퓨터 과학자 에드거 F. 커드(Edgar F. Codd)가 관계형 모델을 제창하며 처음으로 그 개념을 도입한 이래 1, 정규화는 데이터베이스 이론과 실무의 핵심적인 패러다임으로 자리 잡았다. 커드의 근본적인 목표는 데이터의 논리적 구조를 물리적 저장 방식으로부터 분리하여 ’데이터 독립성’을 확보하는 것이었다.2 이는 당시 주류였던 계층형 또는 네트워크 모델이 데이터의 논리적 표현과 물리적 구현을 강하게 결합시켜, 데이터 구조의 작은 변경만으로도 응용 프로그램을 수정해야 했던 한계를 극복하려는 혁신적인 시도였다.2

정규화의 핵심 과정은 ’무손실 분해(lossless decomposition)’로 요약할 수 있다. 이는 하나의 거대한 테이블(릴레이션)을 정보의 손실 없이 더 작고, 논리적으로 일관된 여러 개의 테이블로 분해하는 작업을 의미한다.5 이 과정을 통해 데이터의 중복 저장을 최소화하고, 이로 인해 발생하는 데이터의 논리적 불일치, 즉 ‘모순(contradiction)’ 상태인 ’이상 현상(Anomaly)’을 방지한다.6 오늘날 정규화는 단순히 이론적 이상을 추구하는 것을 넘어, 데이터의 삽입, 갱신, 삭제 과정에서 발생할 수 있는 구체적인 문제들을 해결하고 데이터베이스의 안정성과 무결성을 극대화하는 실용적인 방법론으로 인식되고 있다.5

본 안내서는 관계형 데이터베이스 정규화에 대한 심도 깊은 ’고찰(a study)’을 목표로 한다. 이를 위해 정규화의 이론적 배경이 되는 데이터 이상 현상과 종속성 이론을 시작으로, 제1정규형부터 제6정규형에 이르는 각 단계별 과정과 원칙을 상세히 분석할 것이다. 나아가 정규화가 실제 시스템 성능에 미치는 영향을 탐구하며, 그 필연적 귀결인 비정규화(Denormalization)와의 균형점을 모색한다. 마지막으로, NoSQL, 그래프 데이터베이스와 같은 현대적 데이터 패러다임 및 데이터 웨어하우징 설계 철학과의 비교를 통해 관계형 데이터베이스 정규화의 현재적 위상과 미래를 조망하고, 자동화된 데이터베이스 설계의 가능성을 탐구함으로써 주제에 대한 포괄적이고 다층적인 이해를 제공하고자 한다.

2. 정규화의 이론적 토대

관계형 데이터베이스 정규화는 단순히 경험적 규칙의 집합이 아니라, 데이터의 논리적 구조와 제약 조건을 설명하는 엄밀한 이론적 기반 위에 세워져 있다. 이 이론의 핵심은 ’데이터 이상 현상’이라는 문제의 인식과, 그 근본 원인인 ’함수 종속성’의 분석에 있다. 제1부에서는 정규화가 해결하고자 하는 구체적인 증상인 데이터 이상 현상을 정의하고, 이를 진단하고 해결하기 위한 이론적 도구인 종속성 이론을 심층적으로 탐구한다.

2.1 구조적 결함의 증상으로서의 데이터 이상 현상

잘못 설계된 데이터베이스 스키마는 데이터 조작 시 예기치 않은 부작용을 일으키는데, 이를 통칭하여 ‘수정 이상 현상(Modification Anomaly)’ 또는 ’갱신 이상(Update Anomaly)’이라 부른다.8 이러한 이상 현상은 본질적으로 하나의 릴레이션에 서로 다른 종류의 사실(facts)을 무리하게 혼합하여 저장함으로써 발생하는 데이터 중복 때문에 나타난다.10 정규화는 이러한 이상 현상을 제거하여 데이터베이스를 올바르게 설계해 나가는 과정이며, 주요 이상 현상은 삽입, 갱신, 삭제의 세 가지로 분류된다.11

2.1.1 삽입 이상 (Insertion Anomaly)

삽입 이상은 특정 데이터를 저장하기 위해, 아직 존재하지 않거나 불필요한 다른 데이터를 함께 입력해야만 하는 모순적인 상황을 의미한다.12 이는 테이블이 여러 종류의 정보를 동시에 표현하도록 설계되었을 때 발생한다.

예를 들어, ‘직원’ 정보와 ‘부서’ 정보를 하나의 테이블 (직원ID, 직원이름, 부서명, 부서전화번호)에 저장한다고 가정하자. 이때 새로운 부서인 ’마케팅부’가 신설되었지만 아직 배정된 직원이 없는 경우, 이 테이블에는 ’마케팅부’의 정보를 독립적으로 추가할 수 없다.9 테이블의 기본키가 직원ID라면, 직원에 대한 정보 없이는 부서 정보만 삽입하는 것이 불가능하기 때문이다. 이 문제를 해결하기 위해 직원ID에 가상의 값이나 NULL을 입력해야 하는데, 이는 데이터의 무결성을 해치는 행위이다.10 또 다른 예시로, 수강 신청 정보가 없는 신입생 정보를 학생 테이블에 추가하려면 ’수강과목’과 같은 필드에 불필요한 NULL 값을 삽입해야 하는 경우가 이에 해당한다.13

2.1.2 갱신 이상 (Update Anomaly)

갱신 이상은 중복 저장된 데이터 중 일부만 수정되어 데이터의 일관성이 깨지는 현상을 말한다.12 이는 동일한 정보가 데이터베이스 내 여러 곳에 흩어져 있을 때 발생하며, 데이터의 ‘모순(contradiction)’ 상태를 유발한다.6

앞서의 (직원ID, 직원이름, 부서명, 부서전화번호) 테이블에서 ’개발부’에 홍길동과 김철수 두 명의 직원이 소속되어 있다고 가정하자. 이 경우 ’개발부’의 전화번호는 홍길동의 행과 김철수의 행에 각각 중복으로 저장된다. 만약 ’개발부’의 전화번호가 변경된다면, 이론적으로는 이 부서에 속한 모든 직원의 행에서 전화번호를 일괄적으로 수정해야 한다.9 만약 이 과정에서 하나의 행이라도 누락된다면, 동일한 ’개발부’에 대해 서로 다른 전화번호가 존재하는 데이터 불일치 상태가 발생한다. 이로 인해 어떤 정보가 최신이고 정확한지 판단할 수 없게 된다.5

2.1.3 삭제 이상 (Deletion Anomaly)

삭제 이상은 특정 데이터를 삭제했을 때, 그 데이터와는 직접적인 관련이 없지만 우연히 같은 행에 저장되어 있던 다른 유용한 정보까지 연쇄적으로 손실되는 문제를 의미한다.12 이를 ’연쇄 삭제(chain deletion)’라고도 부른다.16

다시 (직원ID, 직원이름, 부서명, 부서전화번호) 테이블 예시를 살펴보자. ’영업부’에 소속된 유일한 직원이 김철수 한 명뿐인 상황에서, 김철수 직원이 퇴사하여 해당 행을 삭제한다고 가정하자. 이 경우, 김철수 개인의 정보뿐만 아니라 ’영업부’라는 부서의 존재와 그 전화번호 정보까지 데이터베이스에서 완전히 사라지게 된다.9 마찬가지로, 특정 학생이 수강을 취소하여 마지막 남은 수강 기록을 삭제했더니, 그 학생의 학적 정보까지 함께 삭제되는 현상도 삭제 이상의 대표적인 예이다.14

이러한 세 가지 이상 현상은 데이터베이스 설계의 근본적인 결함을 드러내는 증상이다. 그 본질은 현실 세계에서 명백히 구분되는 독립적인 개념(entity), 예를 들어 ‘직원’, ‘부서’, ‘학생’, ‘강좌’ 등을 하나의 테이블에 부적절하게 융합했기 때문에 발생한다. ’직원’은 ‘부서’ 없이도 존재할 수 있고, ‘부서’ 또한 소속 직원이 없어도 존재할 수 있는 별개의 실체이다. 이상 현상은 이처럼 데이터 모델이 현실 세계의 의미 구조를 정확하게 반영하지 못했을 때 나타나는 필연적인 결과이다. 따라서 정규화는 단순히 기술적인 오류를 수정하는 작업을 넘어, 데이터 모델을 현실 세계의 의미 구조에 맞게 재조정하여 각 데이터가 ‘단일한 진실의 원천(Single Source of Truth)’ 원칙을 따르도록 만드는 근본적인 모델링 과정이라 할 수 있다.

2.2 데이터 구조의 문법 - 종속성 이론

데이터 이상 현상을 체계적으로 해결하기 위해 관계형 데이터베이스 이론은 ’종속성 이론(Dependency Theory)’이라는 형식적인 도구를 사용한다. 종속성 이론은 데이터 속성(attribute)들 간의 숨겨진 규칙과 제약 조건을 명확하게 기술하는 언어와 같다. 정규화 과정은 이 종속성 이론을 바탕으로 테이블을 분해하여, 암묵적으로 존재하던 데이터의 제약 조건을 데이터베이스 스키마의 명시적인 구조로 변환하는 작업이다.7

2.2.1 함수 종속성 (Functional Dependency, FD)

정규화의 가장 기본적인 개념은 함수 종속성이다. 릴레이션 R에서 속성의 집합 X와 Y가 있을 때, X의 각 값이 Y의 값을 오직 하나만 결정한다면 “Y는 X에 함수적으로 종속된다“고 말하며, 이를 X–>>Y로 표기한다.15 여기서 X는 ‘결정자(determinant)’, Y는 ’종속자(dependent)’가 된다.15 예를 들어, 학생 테이블에서 학번이 이름을 유일하게 결정한다면, 학번 –>> 이름이라는 함수 종속성이 성립한다. 함수 종속성은 정규화의 제1정규형부터 보이스-코드 정규형(BCNF)까지의 과정을 이끄는 핵심 원리이다.

• 완전 함수 종속 (Full Functional Dependency): 종속자가 기본키(Primary Key) 전체에 종속되는 경우를 의미한다. 만약 기본키가 여러 속성으로 구성된 복합키(composite key)라면, 종속자는 기본키를 구성하는 모든 속성에 대해 종속되어야 하며, 그 어떤 부분 집합에도 종속되어서는 안 된다.5 제2정규형은 모든 비핵심 속성(non-key attribute)이 기본키에 완전 함수 종속되도록 하는 것을 목표로 한다.

• 부분 함수 종속 (Partial Functional Dependency): 종속자가 복합 기본키의 일부에만 종속되는 경우를 말한다.5 예를 들어,

수강 테이블의 기본키가 {학번, 과목코드}일 때, 성적은 {학번, 과목코드} 전체에 종속되지만, 과목명은 과목코드만으로도 결정될 수 있다. 이 경우 과목명은 기본키의 일부인 과목코드에 부분적으로 함수 종속된다. 제2정규화는 이러한 부분 함수 종속을 제거하는 과정이다.20

• 이행적 함수 종속 (Transitive Functional Dependency): 비핵심 속성이 다른 비핵심 속성에 종속되는 관계를 의미한다. 즉, X–>>Y이고 Y–>>Z라는 종속 관계가 존재하여 결과적으로 X–>>Z가 성립할 때, 이를 이행적 함수 종속이라고 한다 (단, X는 후보키이며 Y는 후보키가 아니다).8 예를 들어,

주문 테이블에서 주문번호 –>> 고객번호이고, 고객번호 –>> 고객주소 라면, 고객주소는 주문번호에 이행적으로 종속된다.8 제3정규화는 이러한 이행적 함수 종속을 제거하는 것을 목표로 한다.22

2.2.2 고차 종속성 (Higher-Order Dependencies)

함수 종속성만으로는 설명할 수 없는 더 복잡한 데이터 구조적 제약이 존재하며, 이를 해결하기 위해 고차 종속성 개념이 도입되었다.

• 다치 종속성 (Multi-valued Dependency, MVD): 하나의 결정자 값이 여러 개의 종속자 값 집합을 결정하지만, 그 종속자들 사이에는 아무런 관련이 없는 경우를 의미하며, X–>>–>>Y로 표기한다.19 예를 들어, 한 학생(학번)이 여러 개의 전공(전공명)과 여러 개의 동아리(동아리명)에 소속될 수 있고, 특정 전공을 이수하는 것이 특정 동아리 활동을 강제하지 않는다면, 학번 –>>–>> 전공명과 학번 –>>–>> 동아리명이라는 다치 종속성이 존재한다.25 이러한 구조는 불필요한 데이터 조합을 만들어내므로, 제4정규형에서는 이를 분리하여 제거한다.

• 조인 종속성 (Join Dependency, JD): 다치 종속성을 일반화한 개념으로, 하나의 릴레이션을 여러 개의 릴레이션으로 분해했다가 다시 조인(JOIN)했을 때, 원래의 데이터와 정보 손실 없이 동일하게 복원될 수 있는지를 다루는 종속성이다.18 만약 릴레이션 R을 R1, R2,…, Rn으로 분해했을 때, 이들을 모두 조인한 결과가 원래의 R과 같다면, R은 조인 종속성 *(R1, R2,..., Rn)을 만족한다고 한다. 제5정규형은 후보키에 의해 암시되지 않는 모든 비자명적(non-trivial) 조인 종속성을 제거하는 것을 목표로 한다.27

2.2.3 형식적 도구: 암스트롱의 공리 (Armstrong’s Axioms)

주어진 함수 종속성 집합 F로부터 논리적으로 유추할 수 있는 모든 함수 종속성의 집합(이를 F의 폐포, F^+라 한다)을 찾아내기 위해, 윌리엄 암스트롱은 ’암스트롱의 공리’라 불리는 추론 규칙들을 제시했다. 이 공리들은 ’건전성(soundness, 잘못된 종속성을 생성하지 않음)’과 ’완전성(completeness, 모든 올바른 종속성을 생성할 수 있음)’을 모두 만족한다.29

• 기본 공리 (Primary Rules):

1. 재귀성 (Reflexivity): 만약 Y⊆X 이면, X–>>Y이다. (어떤 속성 집합은 항상 자기 자신의 부분 집합을 결정한다).23
2. 부가성 (Augmentation): 만약 X–>>Y 이면, XZ–>>YZ이다. (종속성의 양쪽에 같은 속성을 추가해도 종속성은 유지된다).23
3. 이행성 (Transitivity): 만약 X–>>Y이고 Y–>>Z이면, X–>>Z이다. (종속 관계는 이행된다).23

• 유도 규칙 (Secondary Rules): 기본 공리로부터 유도될 수 있는 부가적인 규칙들로 합집합(Union), 분해(Decomposition), 의사 이행성(Pseudotransitivity) 등이 있다.23

이처럼 종속성 이론은 데이터 내에 존재하는 의미론적 제약 조건을 형식적으로 표현하는 강력한 언어이다. 학번 –>> 학과라는 함수 종속성은 “모든 학생은 단 하나의 학과에만 소속된다“는 현실 세계의 비즈니스 규칙을 나타낸다. 정규화되지 않은 테이블에서는 이 규칙이 데이터 값들 사이에 암묵적으로만 존재하여 위반될 가능성이 있다. 하지만 정규화 과정을 통해 학생 테이블과 학과 테이블을 분리하고 외래 키(Foreign Key)로 연결하면, 이 암묵적인 규칙은 데이터베이스 스키마가 직접 강제하는 명시적인 구조적 제약 조건으로 변환된다. 따라서 정규화는 데이터의 의미론적 무결성을 스키마 레벨에서 보장하는 체계적인 과정이라 할 수 있다.

3. 정규화의 과정: 단계적 분해

정규화는 비정규 릴레이션(Unnormalized Relation)에서 시작하여 일련의 정규형(Normal Form) 단계를 순차적으로 적용하는 과정이다. 각 정규형은 이전 단계의 정규형을 만족해야 하는 계층적 구조를 가진다.24 즉, 제3정규형을 만족하는 테이블은 자동으로 제1, 제2정규형을 만족한다. 실무에서는 일반적으로 제3정규형(3NF)이나 보이스-코드 정규형(BCNF)까지의 정규화가 주로 수행되며, 이는 대부분의 데이터 이상 현상을 해결하기에 충분하다. 제2부에서는 가장 핵심적인 제1정규형부터 이론적 완결성을 위한 제6정규형까지, 각 단계의 정의와 목표를 구체적인 예시와 함께 단계적으로 탐구한다.

3.1 기초 정규형 (1NF, 2NF, 3NF)

데이터베이스 설계의 실질적인 토대를 이루는 것은 제1, 제2, 제3정규형이다. 이 세 단계의 정규화 과정은 데이터 모델에서 가장 흔하게 발생하는 구조적 문제들을 해결하며, 결과적으로 현실 세계의 개념들을 논리적으로 분리된 개별 엔티티로 명확하게 식별하는 역할을 한다. 이 과정을 이해하기 위해, 하나의 주문에 여러 상품이 포함될 수 있는 전자상거래 시스템의 주문 테이블을 예시로 단계별 분해 과정을 살펴본다.8

초기 비정규 릴레이션 (Unnormalized Relation)

위 테이블은 상품정보 컬럼에 여러 상품의 코드, 이름, 수량, 가격이 중첩된 형태로 포함되어 있어 정규화가 필요한 상태이다.

3.1.1 제1정규형 (First Normal Form, 1NF)

• 규칙: 릴레이션에 속한 모든 도메인(컬럼)의 값이 **원자값(Atomic Value)**이어야 한다. 즉, 하나의 셀에는 단 하나의 값만 존재해야 하며, 반복되는 그룹이나 중첩된 구조를 허용하지 않는다.5

• 목표: 데이터의 기본 구조를 관계형 모델에 맞게 평탄화하고, 각 행을 고유하게 식별할 수 있는 기본키를 설정하는 것이다.

• 적용 과정:

위 예시 테이블에서 상품정보 컬럼은 여러 개의 상품 데이터를 포함하는 반복 그룹이므로 제1정규형을 위반한다.20 이를 해결하기 위해 각 상품 정보를 별도의 행으로 분리한다. 이 과정에서

주문번호만으로는 행을 고유하게 식별할 수 없으므로, 상품코드를 포함한 {주문번호, 상품코드}를 복합 기본키(Composite Primary Key)로 설정한다.

1NF 적용 후 릴레이션 (주문_상품 테이블)

이제 모든 컬럼은 원자값을 가지지만, 주문일자, 고객정보 등 동일한 주문에 대한 정보가 상품 수만큼 불필요하게 중복되는 문제가 발생한다. 이는 부분 함수 종속으로 인한 문제이다.

3.1.2 제2정규형 (Second Normal Form, 2NF)

• 규칙: 제1정규형을 만족해야 하며, 모든 비핵심 속성이 기본키에 **완전 함수 종속(Fully Functionally Dependent)**이어야 한다. 즉, **부분 함수 종속(Partial Functional Dependency)**을 제거해야 한다.5 이 규칙은 복합 기본키를 가진 테이블에만 의미가 있다.

• 목표: 기본키의 일부에만 종속된 속성들을 별도의 테이블로 분리하여 데이터 중복을 줄이는 것이다.

• 적용 과정:

1NF를 만족하는 주문_상품 테이블의 기본키는 {주문번호, 상품코드}이다.

• 주문수량은 특정 주문의 특정 상품에 대한 수량이므로 기본키 전체에 종속된다 (완전 함수 종속).

• 주문일자, 고객번호, 고객명, 고객주소는 주문번호만으로 결정되므로, 기본키의 일부인 주문번호에 부분적으로 종속된다.

• 상품명, 단가는 상품코드만으로 결정되므로, 기본키의 일부인 상품코드에 부분적으로 종속된다.8

이러한 부분 함수 종속을 제거하기 위해 테이블을 세 개로 분해한다.

2NF 적용 후 릴레이션

1. 주문 테이블 (주문번호에 종속된 속성들)

1. 상품 테이블 (상품코드에 종속된 속성들)

1. 주문항목 테이블 (기본키 전체에 종속된 속성)

분해 후, 주문 테이블에서 고객명, 고객주소가 고객번호에 의해 결정되는 새로운 종속성이 발견된다. 이는 이행적 함수 종속이다.

3.1.3 제3정규형 (Third Normal Form, 3NF)

• 규칙: 제2정규형을 만족해야 하며, **이행적 함수 종속(Transitive Functional Dependency)**이 존재하지 않아야 한다. 즉, 기본키가 아닌 속성이 다른 기본키가 아닌 속성을 결정해서는 안 된다.8

• 목표: 기본키에 직접 종속되지 않고 다른 일반 컬럼을 통해 간접적으로 종속되는 속성들을 분리하여, 논리적으로 독립된 개체를 완전히 분리하는 것이다.

• 적용 과정:

2NF 분해 결과로 나온 주문 테이블을 보면, 주문번호 –>> 고객번호 이고, 고객번호 –>> {고객명, 고객주소} 관계가 성립한다. 따라서 {고객명, 고객주소}는 기본키인 주문번호에 이행적으로 종속된다.8 이 문제를 해결하기 위해 이행 종속의 원인이 되는 속성들을 별도의 테이블로 분리한다.

3NF 적용 후 릴레이션

1. 주문 테이블 (수정됨)

1. 고객 테이블 (신규 생성)

1. 상품 테이블 (변경 없음)
2. 주문항목 테이블 (변경 없음)

이 과정을 통해 최종적으로 주문, 고객, 상품, 주문항목이라는 네 개의 테이블이 생성되었다. 각 테이블은 현실 세계의 독립적인 개체(고객, 상품) 또는 관계(주문, 주문항목)를 명확하게 표현한다. 이처럼 제1정규형부터 제3정규형까지의 과정은 단순히 데이터 중복을 제거하는 기술적인 절차를 넘어, 데이터에 내재된 논리적 구조를 발견하고 이를 기반으로 현실 세계를 정확하게 모델링하는 체계적인 방법론임을 알 수 있다.

3.2 고등 정규형 (BCNF, 4NF, 5NF)

제3정규형까지의 정규화는 대부분의 데이터베이스 설계 문제를 해결하지만, 드물지만 중요한 특정 유형의 데이터 중복과 이상 현상을 남길 수 있다. 이러한 미묘한 문제들을 해결하기 위해 보이스-코드 정규형(BCNF), 제4정규형(4NF), 제5정규형(5NF)과 같은 고등 정규형이 제안되었다. 이 정규형들은 함수 종속성을 넘어 다치 종속성, 조인 종속성과 같은 더 복잡한 구조적 제약 조건을 다룬다.

3.2.1 보이스-코드 정규형 (Boyce-Codd Normal Form, BCNF)

• 규칙: 제3정규형을 만족해야 하며, 릴레이션에 존재하는 모든 결정자(determinant)가 **후보키(Candidate Key)**여야 한다.22 BCNF는 제3정규형보다 더 엄격한 조건을 요구하며, ’강한 제3정규형’이라고도 불린다.

• 목표: 제3정규형이 해결하지 못하는, 여러 개의 후보키가 중첩되어 발생하는 특정 이상 현상을 제거하는 것이다.37

• 3NF와 BCNF의 차이: 제3정규형은 비핵심 속성이 다른 비핵심 속성에 이행적으로 종속되는 것만 금지한다. 그러나 결정자가 후보키가 아니면서, 종속자가 기본키의 일부인 경우는 허용할 수 있다. BCNF는 이러한 예외 없이 모든 결정자가 후보키(또는 슈퍼키)가 되어야 한다고 규정한다.

• 예시: (학생, 과목, 교수) 릴레이션이 있고, 다음과 같은 제약 조건이 있다고 가정하자.

1. 한 학생은 특정 과목을 한 명의 교수에게서만 수강한다. (\{학생, 과목\} –>> 교수)

2. 한 교수는 한 과목만 가르친다. (교수 –>> 과목)

이 릴레이션의 후보키는 (학생, 과목)과 (학생, 교수) 두 개이다. 이 릴레이션은 제3정규형을 만족한다. 왜냐하면 기본키가 아닌 속성(교수 또는 과목) 간의 이행 종속이 없기 때문이다.

하지만 교수 –>> 과목 종속성에서 결정자인 교수는 후보키가 아니다. 따라서 이 릴레이션은 BCNF를 위반한다.37 이로 인해 특정 교수가 아직 담당하는 학생이 없으면 강좌 정보를 삽입할 수 없는 삽입 이상, 특정 학생의 수강 취소로 인해 교수의 담당 과목 정보가 사라지는 삭제 이상 등이 발생할 수 있다.40

• 분해 과정: BCNF를 만족시키기 위해 릴레이션을 (학생, 교수)와 (교수, 과목)으로 분해한다. 이제 각 릴레이션의 모든 결정자는 후보키가 되므로 BCNF를 만족한다.39

3.2.2 제4정규형 (Fourth Normal Form, 4NF)

• 규칙: BCNF를 만족해야 하며, 비자명적인 **다치 종속(Multi-valued Dependency, MVD)**이 존재하지 않아야 한다.22
• 목표: 하나의 테이블에 두 개 이상의 독립적인 다대다(N:M) 관계가 포함되어 발생하는 데이터 중복을 제거하는 것이다.
• 다치 종속의 개념: 속성 A, B, C가 있을 때, A의 한 값에 대해 여러 개의 B 값이 대응되고, 여러 개의 C 값이 대응되는데, B와 C 값의 집합이 서로 독립적일 때 다치 종속(A–>>–>>B∣C)이 존재한다고 한다.19
• 예시: (교수, 과목, 참고도서) 릴레이션이 있고, 한 교수는 여러 과목을 가르칠 수 있으며, 한 과목은 여러 참고도서를 가질 수 있다고 가정하자. 이때, 교수가 가르치는 과목 집합과 과목에 해당하는 참고도서 집합은 서로 독립적이다. 만약 ’김교수’가 ’자료구조’와 ’알고리즘’을 가르치고, ’자료구조’의 참고도서가 ’A책’과 ’B책’이라면, 이 정보를 하나의 테이블에 표현하기 위해서는 (김교수, 자료구조, A책), (김교수, 자료구조, B책), (김교수, 알고리즘, A책), (김교수, 알고리즘, B책)과 같이 불필요한 조합의 행들이 생성된다. 이는 교수 –>>–>> 과목과 과목 –>>–>> 참고도서라는 다치 종속성 때문이다.26
• 분해 과정: 다치 종속을 제거하기 위해 릴레이션을 (교수, 과목)과 (과목, 참고도서)로 분해한다. 각 테이블은 이제 하나의 다치 종속 관계만을 표현하므로 제4정규형을 만족한다.22

3.2.3 제5정규형 (Fifth Normal Form, 5NF) / 투영-조인 정규형 (Projection-Join Normal Form, PJ/NF)

• 규칙: 제4정규형을 만족해야 하며, 후보키를 통하지 않는 비자명적인 **조인 종속(Join Dependency, JD)**이 존재하지 않아야 한다.18
• 목표: 여러 릴레이션으로 분해했다가 다시 조인할 때, 원래 없었던 ’가짜 튜플(spurious tuple)’이 생성되지 않도록, 즉 무손실 분해의 최종 단계를 보장하는 것이다.
• 조인 종속의 개념: 릴레이션 R을 투영(projection)하여 R1, R2,…, Rn으로 분해했을 때, 이들을 다시 조인한 결과가 R과 동일하다면, R은 조인 종속 *(R1, R2,..., Rn)을 만족한다. 5NF는 이러한 조인 종속성이 후보키에 의해 암시되는 경우를 제외하고는 존재해서는 안 된다고 규정한다.
• 예시: (공급업체, 부품, 프로젝트) 릴레이션이 있고, “만약 공급업체 S가 부품 P를 공급하고, 프로젝트 J가 부품 P를 사용하며, 공급업체 S가 프로젝트 J에 납품한다면, 반드시 공급업체 S는 프로젝트 J에 부품 P를 공급해야 한다“는 복잡한 제약 조건이 있다고 가정하자. 이 제약은 하나의 테이블로는 완벽하게 표현하기 어렵고, 특정 데이터 조합에서는 분해 후 재결합 시 원래 없던 데이터가 생길 수 있다.
• 분해 과정: 이 문제를 해결하기 위해 릴레이션을 (공급업체, 부품), (부품, 프로젝트), (공급업체, 프로젝트)의 세 테이블로 분해한다.43 이 세 테이블을 모두 조인해야만 원래의 정보를 손실이나 왜곡 없이 복원할 수 있다. 이렇게 분해된 각 테이블은 더 이상 분해할 수 없는 ’환원 불가능한 요소’가 되며, 제5정규형을 만족하게 된다.27

BCNF에서 5NF로의 진행은 정규화의 대상이 되는 종속성의 개념이 점차 추상화되는 과정을 보여준다. BCNF까지는 ’하나의 값이 다른 하나의 값을 결정한다’는 명확한 함수적 관계를 다룬다. 반면 4NF는 ’하나의 값이 값들의 집합을 결정한다’는 다치 관계를, 5NF는 ’여러 관계의 존재가 또 다른 관계의 존재를 암시한다’는 복잡한 구조적 제약 자체를 다룬다. 이는 정규화가 단순한 데이터 중복 제거를 넘어, 데이터 모델의 논리적 완결성과 구조적 무결성을 확보하는 정교한 과정임을 시사한다.

3.3 시간의 차원 - 제6정규형 (6NF)

제6정규형(6NF)은 데이터베이스 정규화의 이론적 종착점으로, 특히 시간의 흐름에 따라 데이터가 변화하는 ’시간적 데이터(Temporal Data)’를 다루기 위해 제안된 특수한 정규형이다. 크리스토퍼 데이트(Christopher J. Date), 휴 다윈(Hugh Darwen), 니코스 로렌초스(Nikos Lorentzos) 등에 의해 관계형 대수의 확장을 기반으로 정의되었다.45

• 규칙: 제5정규형을 만족해야 하며, 릴레이션에 비자명적인 조인 종속성이 전혀 존재하지 않아야 한다.45 현실적으로 이는 릴레이션을 더 이상 분해할 수 없는

환원 불가능한(irreducible) 요소로 나누는 것을 의미한다. 6NF 테이블은 일반적으로 기본키와 최대 하나의 비핵심 속성으로 구성된다.48

• 목표: 각 속성의 변화 이력을 개별적으로, 그리고 모호함 없이 추적할 수 있도록 데이터 구조를 원자화하는 것이다.

• 핵심 사용 사례: 시간적 데이터베이스 (Temporal Databases):

전통적인 데이터베이스는 특정 시점의 ’스냅샷’만을 저장한다. 그러나 많은 비즈니스 시나리오에서는 데이터의 이력 관리가 필수적이다. 예를 들어, 한 직원의 부서와 급여는 서로 다른 시점에, 독립적으로 변경될 수 있다.

• 문제 상황: 3NF 형태의 직원(직원ID, 이름, 부서, 급여) 테이블에서 이력 관리를 시도하면 문제가 발생한다. 부서만 변경되었을 때, 변경되지 않은 급여 정보까지 새로운 행에 중복 기록하거나, 복잡한 유효시작일(ValidFrom), 유효종료일(ValidTo) 컬럼을 관리해야 한다. 이는 데이터 중복과 갱신 이상을 유발한다.

• 6NF 해결책: 6NF는 이 문제를 각 속성을 시간 차원과 함께 독립적인 테이블로 분해함으로써 해결한다.48

• 직원_이름_이력(직원ID, 이름, 유효시작일, 유효종료일)

• 직원_부서_이력(직원ID, 부서, 유효시작일, 유효종료일)

• 직원_급여_이력(직원ID, 급여, 유효시작일, 유효종료일)

• 장점:

1. 최대 수준의 중복 제거: 각 정보 조각(예: “직원 A의 부서는 특정 기간 동안 B였다”)이 정확히 한 번만 저장된다.48
2. 갱신 의미의 단순화: 데이터 변경 시 영향을 받는 최소한의 정보만 수정(새로운 이력 행 추가)하면 되므로, 갱신 이상의 위험이 극적으로 줄어든다.48
3. 시간적 순수성 (Temporal Purity): 6NF 테이블의 각 행은 하나의 분리 불가능한 시간적 사실(temporal fact)을 나타내므로, 시간에 대한 추론이 명확하고 모호하지 않게 된다.48
4. 궁극의 유연성: 새로운 속성을 추가하는 것이 기존 테이블 구조를 변경하는 대신 새로운 이력 테이블을 추가하는 것으로 귀결되므로, 시스템 확장에 매우 유연하다.48

6NF는 정규화의 패러다임을 한 단계 더 발전시킨다. 3NF 테이블이 하나의 ’개체’에 대한 현재 상태의 스냅샷을 표현한다면, 6NF는 더 이상 개체 자체를 모델링하지 않는다. 대신, 그 개체에 대한 **개별 속성들의 시간적 변화 이력(a log of versioned attributes)**을 모델링한다. 즉, 데이터베이스는 더 이상 현재 상태를 저장하는 장소가 아니라, 과거부터 현재까지 발생한 모든 ’사실’들을 기록하는 원장(ledger)과 유사한 구조를 갖게 된다. 이는 이벤트 소싱(Event Sourcing)이나 불변의 로그(immutable log)와 같은 현대적인 아키텍처 패턴과 철학적으로 맞닿아 있으며, 관계형 모델이 시간의 흐름을 다루는 가장 정제된 방식임을 보여준다. 데이터 웨어하우스 분야에서 앵커 모델링(Anchor Modeling)과 같은 기법은 6NF 원칙을 적극적으로 활용하여 유연하고 감사 가능한 이력 데이터 관리를 구현한다.47

표 1: 정규형 요약 (1NF-6NF)

4. 실무에서의 정규화: 성능과 무결성의 균형

이론적으로 정규화는 데이터 무결성을 보장하는 가장 이상적인 방법이지만, 실제 시스템에 적용할 때는 성능이라는 현실적인 문제와 마주하게 된다. 정규화 수준이 높아질수록 테이블은 더 잘게 쪼개지고, 이는 데이터를 조회할 때 더 많은 테이블 조인(JOIN)을 요구하게 된다. 이러한 조인 연산은 특히 대용량 데이터를 다루는 분석 시스템에서 심각한 성능 저하의 원인이 될 수 있다. 제3부에서는 데이터 무결성이라는 정규화의 이상과 쿼리 성능이라는 현실적 요구 사이의 본질적인 상충 관계를 분석하고, 이를 해결하기 위한 실용적인 전략인 ’비정규화’와 정규화가 데이터베이스의 핵심 구성 요소인 ’쿼리 최적화기’에 미치는 영향을 심층적으로 탐구한다.

4.1 실용주의자의 선택 - 비정규화

정규화의 원칙을 의도적으로 위배하여 데이터베이스의 성능, 특히 읽기 성능을 향상시키는 최적화 기법을 비정규화(Denormalization) 또는 반정규화라고 한다.50 이는 데이터 무결성을 일부 희생하는 대신, 쿼리 실행 시 발생하는 조인 연산의 횟수나 복잡도를 줄여 응답 시간을 단축시키는 것을 목표로 한다.28

4.1.1 비정규화의 원리와 기법

정규화의 핵심이 데이터 중복을 ’제거’하는 것이라면, 비정규화는 성능 향상을 위해 데이터 중복을 ’전략적으로 허용’하는 것이다.

• 이론적 배경: 트랜잭션이 빈번하고 데이터의 일관성이 최우선인 온라인 트랜잭션 처리(OLTP) 시스템에서는 높은 수준의 정규화가 권장된다. 반면, 대량의 데이터를 읽어와 복잡한 분석을 수행하는 것이 주목적인 온라인 분석 처리(OLAP) 시스템이나 데이터 웨어하우스에서는 비정규화를 통해 성능을 최적화하는 경우가 많다.52
• 주요 기법:

1. 중복 컬럼 추가: 자주 함께 조회되는 데이터를 다른 테이블에 중복으로 추가하여 조인을 피하는 방식이다. 예를 들어, 주문 테이블을 조회할 때 항상 고객 테이블을 조인하여 고객명을 가져온다면, 주문 테이블에 고객명 컬럼을 추가할 수 있다.52
2. 파생/계산 컬럼 추가: 쿼리 시점에 계산하면 비용이 많이 드는 값을 미리 계산하여 테이블에 저장하는 방식이다. 예를 들어, 주문항목 테이블의 데이터를 합산하여 구하는 주문총액을 주문 테이블에 미리 계산해 저장해 둘 수 있다.52
3. 테이블 병합: 1:1 관계에 있거나, 1:N 관계이지만 N이 매우 적고 함께 자주 조회되는 테이블들을 하나의 테이블로 통합하는 방식이다.

4.1.2 비정규화의 장단점과 적용 시점

비정규화는 강력한 성능 개선 도구이지만, 명확한 장단점을 가지고 있어 신중한 접근이 필요하다.

• 장점:
• 쿼리 성능 향상: 조인 연산의 감소로 인해 데이터 조회 속도가 크게 향상된다.50
• 쿼리 단순화: 여러 테이블을 조인할 필요가 없어지므로 SQL 쿼리가 단순해지고, 개발 및 유지보수가 용이해진다.50
• 단점:
• 데이터 무결성 저해: 데이터 중복을 허용하므로, 갱신 이상 현상이 다시 발생할 수 있다. 예를 들어, 고객명이 변경되었을 때, 고객 테이블뿐만 아니라 비정규화된 모든 주문 테이블의 고객명까지 일관되게 수정해야 한다.50
• 저장 공간 증가: 데이터 중복으로 인해 추가적인 저장 공간이 필요하다.50
• 데이터 수정/입력/삭제 비용 증가: 데이터를 수정할 때 여러 곳을 변경해야 하므로 쓰기 작업의 비용과 복잡성이 증가한다.50

따라서 비정규화는 “정규화로 정확성을 확보하고, 성능 문제가 발생했을 때 최후의 수단으로 신중하게 적용해야 한다“는 원칙을 따라야 한다.28 주로 다음과 같은 상황에서 고려된다 50:

• 특정 쿼리가 매우 빈번하게 수행되어 성능 최적화가 필수적인 경우.
• 정규화된 스키마에서 조인이 지나치게 많아 쿼리가 복잡하고 성능이 저하될 때.
• 대량의 데이터를 집계하는 리포팅 또는 분석용 데이터베이스를 구축할 때.

결론적으로, 비정규화는 정규화의 대척점에 있는 개념이 아니라, 정규화된 모델을 기반으로 특정 요구사항을 충족시키기 위해 적용하는 보완적인 최적화 전략이다. 효과적인 데이터 아키텍처는 종종 두 가지 접근법을 모두 활용한다. 예를 들어, 기업의 핵심 거래 시스템(OLTP)은 3NF 이상으로 고도로 정규화하여 데이터 무결성을 보장하고, 이 시스템의 데이터를 주기적으로 추출하여 분석 시스템(OLAP)을 위한 비정규화된 데이터 마트를 구축하는 방식이다. 이는 정규화와 비정규화가 대립하는 가치가 아니라, 데이터 생명주기의 각기 다른 단계(데이터의 정확한 ’수집’과 효율적인 ‘제공’)에 최적화된 도구임을 보여준다.

제 7장: 정규화와 쿼리 최적화기

정규화가 성능에 미치는 영향은 단순히 조인 연산의 수 증가에 그치지 않는다. 더 근본적으로, 정규화는 데이터베이스 관리 시스템의 ’두뇌’라 할 수 있는 **쿼리 최적화기(Query Optimizer)**의 작업을 훨씬 더 복잡하고 어렵게 만든다.

4.1.3 조인 순서 최적화의 복잡성

사용자가 SQL 쿼리를 실행하면, 쿼리 최적화기는 해당 쿼리를 실행할 수 있는 수많은 ‘실행 계획(Execution Plan)’ 중에서 가장 비용이 적게 들 것으로 예상되는 계획을 선택한다. 여러 테이블을 조인하는 쿼리에서 가장 중요한 결정 중 하나는 어떤 순서로 테이블을 조인할 것인가이다.

• 조합적 폭발 (Combinatorial Explosion): 조인할 테이블의 수가 N개일 때, 가능한 조인 순서의 수는 N의 팩토리얼(N!)에 비례하여 기하급수적으로 증가한다. 이는 NP-난해(NP-hard) 문제로 알려져 있다.55
• 최적화기의 한계: 이 때문에 쿼리 최적화기는 테이블 수가 특정 임계치(예: PostgreSQL의 경우 12개)를 넘어가면 모든 가능한 순서를 탐색하는 것을 포기하고, 유전 알고리즘이나 탐욕 알고리즘과 같은 휴리스틱(heuristics)에 의존하게 된다. 이러한 휴리스틱 방식은 최적의 실행 계획을 보장하지 못한다.55

정규화 수준이 높아질수록 테이블의 수는 증가하므로, 동일한 비즈니스 질의를 수행하기 위해 더 많은 테이블을 조인해야 한다. 이는 쿼리 최적화기가 탐색해야 할 실행 계획의 공간을 폭발적으로 증가시켜, 최적의 계획을 찾지 못할 위험을 높인다.

4.1.4 카디널리티 추정의 부정확성

쿼리 최적화기가 실행 계획의 비용을 산정하는 데 사용하는 가장 중요한 정보는 각 연산 단계에서 생성될 결과 행의 수, 즉 **카디널리티(Cardinality)**이다.

• 추정의 어려움: 최적화기는 테이블의 통계 정보(히스토그램 등)를 바탕으로 카디널리티를 ’추정’하는데, 이 추정은 실제 값과 큰 차이를 보이는 경우가 많다. 특히 여러 컬럼 간의 상관관계를 고려하지 못하는 경우가 많아, 조인이 여러 번 중첩될수록 추정 오류는 눈덩이처럼 불어난다.55
• 오류의 파급 효과: 연구에 따르면, 실제 DBMS의 최적화기들은 조인 수가 5개를 넘어가면 카디널리티를 수십에서 수만 배까지도 잘못 예측하는 것으로 나타났다.55 잘못된 카디널리티 추정은 최적화기가 치명적으로 비효율적인 조인 순서(예: 거대한 중간 결과 집합을 생성하는 순서)를 선택하게 만드는 주된 원인이다.

고도로 정규화된 스키마는 더 많은 조인을 필요로 하므로, 카디널리티 추정 오류가 발생하고 증폭될 지점이 더 많아진다. 이는 최적화기가 잘못된 판단을 내릴 시스템적 위험을 증가시킨다.

4.1.5 벤치마크를 통한 증명: TPC-H vs. SSB

정규화된 스키마와 비정규화된 스키마의 성능 차이는 업계 표준 벤치마크를 통해 명확히 확인할 수 있다.

• TPC-H: 의사 결정 지원 시스템을 위한 대표적인 벤치마크로, 공급업체-부품-주문 관계를 모델링하는 의사-정규화(pseudo-normalized) 스키마를 사용한다.58 이 스키마는 복잡한 조인을 다수 포함하고 있어 쿼리 최적화기에게는 어려운 과제이지만, 실제 업계에서 널리 쓰이는 비정규화된 데이터 웨어하우스의 구조와는 거리가 멀다는 비판을 받는다.58

• Star Schema Benchmark (SSB): TPC-H의 한계를 보완하기 위해 개발된 벤치마크로, 실제 데이터 웨어하우스에서 널리 사용되는 **스타 스키마(Star Schema)**를 채택했다.59 SSB는 TPC-H의

LINEITEM과 ORDERS 같은 거대 트랜잭션 테이블을 하나의 거대한 팩트(Fact) 테이블 LINEORDER로 비정규화하고, 주변의 차원(Dimension) 테이블들도 비정규화하여 조인 복잡성을 크게 줄였다. 이는 분석 쿼리에 최적화된 구조이다.59

TPC-H와 SSB에 대한 성능 비교 연구는 동일한 논리적 데이터를 다루더라도, 비정규화된 스타 스키마가 복잡한 분석 쿼리에서 훨씬 우수한 성능을 보임을 일관되게 보여준다. 이는 비정규화가 단순히 조인 연산 자체의 비용을 줄이는 것을 넘어, 쿼리 최적화기가 탐색해야 할 공간을 줄이고 치명적인 카디널리티 추정 오류의 위험을 낮춤으로써 더 안정적이고 예측 가능한 성능을 제공하기 때문이다. 즉, 정규화의 성능 ’비용’은 개별 조인 연산의 합이 아니라, 쿼리 최적화 과정 전체에 가해지는 복잡성과 불확실성이라는 시스템적 위험에서 비롯된다.

5. 현대 데이터 생태계 속의 정규화

관계형 데이터베이스와 정규화 원칙이 수십 년간 데이터 관리의 표준으로 군림해왔지만, 21세기에 들어서면서 빅데이터, 실시간 처리, 비정형 데이터의 폭발적인 증가는 새로운 데이터 관리 패러다임의 등장을 촉발했다. NoSQL과 그래프 데이터베이스는 기존 관계형 모델의 한계를 극복하기 위해 등장했으며, 이들은 정규화에 대해 각기 다른 철학과 접근법을 제시한다. 또한, 대규모 데이터 분석을 위한 데이터 웨어하우징 분야에서도 정규화를 어떻게 활용할 것인가에 대한 오랜 논쟁이 존재한다. 제4부에서는 이러한 현대 데이터 생태계 속에서 정규화가 차지하는 위치와 그 의미를 다각적으로 조명한다.

5.1 관계형 패러다임 대 비관계형 패러다임

전통적인 관계형 데이터베이스(RDBMS)의 엄격한 정규화 원칙은 데이터의 일관성과 무결성을 보장하는 데 탁월하지만, 유연성과 확장성 측면에서는 한계를 보인다. 이러한 한계에 대한 대안으로 등장한 것이 NoSQL(Not Only SQL)과 그래프 데이터베이스이다.

5.1.1 NoSQL과 비정규화 모델링

NoSQL 데이터베이스는 RDBMS의 확장성 및 스키마 경직성 문제를 해결하기 위해 설계되었다.60 이들은 데이터 모델링에 있어 정규화와는 다른 철학을 따른다.

• 설계 철학: NoSQL의 핵심은 쿼리 효율성을 위해 데이터를 의도적으로 비정규화하는 것이다.62 RDBMS가 데이터 모델의 정규화를 통해 데이터의 중복을 제거하고 이를

JOIN으로 재구성하는 ‘쓰기 시점의 스키마(Schema-on-Write)’ 방식을 따른다면, NoSQL은 특정 조회 패턴에 최적화하기 위해 관련 데이터를 하나의 문서나 레코드에 중복 저장(embedding)하는 ‘읽기 시점의 스키마(Schema-on-Read)’ 방식을 선호한다. 모델링 과정 자체가, 필요한 쿼리 결과를 먼저 정의하고 그에 맞춰 데이터 구조를 설계하는 역방향으로 진행되기도 한다.62

• CAP 이론과 트레이드오프: NoSQL 시스템의 설계는 분산 시스템의 근본 원리인 **CAP 이론(CAP Theorem)**에 깊이 뿌리내리고 있다. CAP 이론은 분산 시스템이 일관성(Consistency), 가용성(Availability), 분할 허용성(Partition Tolerance) 세 가지 속성 중 최대 두 가지만을 동시에 만족시킬 수 있다는 원리이다.61

• 전통적인 단일 서버 RDBMS는 보통 CA(일관성+가용성)를 지향한다.

• 반면, 분산 환경을 전제로 하는 대부분의 NoSQL 시스템은 네트워크 단절 상황에서도 동작해야 하므로 P(분할 허용성)를 기본으로 선택하고, C와 A 사이에서 트레이드오프를 한다. 즉, 일관성을 우선시하는 CP 시스템(예: MongoDB, HBase)이나, 가용성을 우선시하는 AP 시스템(예: Cassandra, DynamoDB)으로 나뉜다.61 이는 엄격한 일관성을 일부 희생하여 대규모 확장성과 고가용성을 확보하려는 전략적 선택이다.

5.1.2 그래프 데이터베이스와 관계의 재정의

그래프 데이터베이스는 데이터 간의 ‘관계’ 자체를 저장하고 처리하는 데 최적화된 또 다른 비관계형 패러다임이다.

• 설계 철학: 그래프 데이터베이스의 핵심은 관계(edge)를 JOIN을 통해 쿼리 시점에 계산해야 하는 대상이 아니라, 노드(node)와 함께 저장되는 **일급 객체(first-class citizen)**로 취급하는 것이다.64 데이터는 노드(개체)와 이들을 직접 연결하는 관계(엣지)의 네트워크로 모델링된다.
• 정규화와의 비교: 그래프 모델은 RDBMS의 정규화-조인 문제를 근본적으로 다른 방식으로 해결한다. 데이터 개체 자체(노드)는 고객, 상품처럼 작고 정규화된 단위로 유지될 수 있다. 그러나 이들 간의 관계는 외래 키와 조인 테이블을 통하는 대신, 물리적인 포인터나 참조를 통해 직접 연결된다.67 이로 인해 복잡하게 연결된 데이터를 탐색할 때, 조인 횟수가 늘어남에 따라 성능이 기하급수적으로 저하되는 RDBMS와 달리, 그래프 데이터베이스는 탐색 깊이에 상관없이 거의 일정한 성능을 유지할 수 있다.66

NoSQL과 그래프 데이터베이스의 등장은 정규화의 ‘목표’(데이터 무결성, 중복 최소화) 자체를 부정한 것이 아니다. 오히려 이는 ’단일화되고 정규화된 관계형 데이터베이스’라는 ’방법’이 모든 종류의 문제, 특히 웹 스케일의 분산 환경이나 고도로 연결된 데이터셋 문제에 최적의 해법은 아니라는 점을 보여준다. NoSQL은 조인의 성능 비용을 피하기 위해 ’임베딩’이라는 제어된 비정규화 전략을 택했고, 그래프 데이터베이스는 ’조인’이라는 연산 자체를 ’탐색(traversal)’으로 대체했다. 이들은 정규화의 원칙을 버린 것이 아니라, 조인 연산의 한계를 극복하기 위한 ‘포스트-조인(post-join)’ 시대의 대안적 데이터 조직화 전략을 제시한 것으로 해석할 수 있다.

5.2 분석 시스템에서의 정규화 - 인몬 대 킴볼 논쟁

데이터 웨어하우징(Data Warehousing) 분야에서는 대규모 데이터를 분석 및 보고 목적으로 통합하고 저장하는 아키텍처를 어떻게 설계할 것인가를 두고 두 가지 주요한 철학이 오랫동안 대립해왔다. 빌 인몬(Bill Inmon)과 랄프 킴볼(Ralph Kimball)로 대표되는 이 두 접근법의 핵심적인 차이는 바로 ’정규화’를 데이터 웨어하우스의 어느 계층에, 어떻게 적용할 것인가에 있다. 이는 거시적 관점에서 벌어지는 정규화와 비정규화의 철학적 논쟁이라 할 수 있다.

5.2.1 빌 인몬의 접근법: 하향식(Top-Down)과 정규화된 EDW

빌 인몬은 ’기업 정보 공장(Corporate Information Factory)’의 아버지로 불리며, 데이터 웨어하우스를 전사적인 관점에서 구축할 것을 주장한다.

• 아키텍처: 그의 접근법은 ’하향식’으로, 먼저 전사적인 데이터를 통합한 중앙 집중형 **엔터프라이즈 데이터 웨어하우스(EDW)**를 구축하는 것에서 시작한다. 이 EDW는 조직의 ‘단일 진실 공급원(Single Source of Truth)’ 역할을 한다.69
• 데이터 모델: EDW의 핵심 데이터 모델은 **제3정규형(3NF)**으로 고도로 정규화된다.70 이는 데이터 중복을 최소화하고 전사적 데이터의 일관성과 무결성을 최우선으로 확보하기 위함이다.
• 데이터 흐름: 다양한 운영 시스템의 데이터는 ETL(Extract, Transform, Load) 과정을 거쳐 정규화된 EDW에 통합된다. 그 후, 특정 부서나 비즈니스 요구에 맞춰 최종 사용자를 위한 **데이터 마트(Data Marts)**가 EDW로부터 데이터를 공급받아 구축된다. 이 데이터 마트들은 보통 분석 성능을 위해 비정규화된 구조(예: 스타 스키마)를 가질 수 있다.70
• 장단점: 데이터 무결성과 일관성이 뛰어나고 전사적 관점을 제공하지만, 초기 구축에 많은 시간과 비용이 소요되며, 정규화된 EDW에 직접 쿼리할 경우 성능이 느릴 수 있다.70

5.2.2 랄프 킴볼의 접근법: 상향식(Bottom-Up)과 차원 모델링

랄프 킴볼은 최종 사용자의 분석 편의성과 성능에 초점을 맞춘 실용적인 접근법을 제시한다.

• 아키텍처: 그의 접근법은 ’상향식’으로, 특정 비즈니스 프로세스(예: 판매, 재고)에 초점을 맞춘 개별 데이터 마트를 먼저 구축하고, 이를 점진적으로 통합하여 전사적 데이터 웨어하우스를 구성한다.69
• 데이터 모델: 각 데이터 마트는 사용자가 이해하기 쉽고 쿼리 성능이 뛰어난 차원 모델(Dimensional Model), 특히 **스타 스키마(Star Schema)**를 기반으로 설계된다.70 스타 스키마는 정량적 측정값(facts)을 담은 중앙의 ’팩트 테이블’과, 분석의 기준이 되는 설명적 속성(dimensions)을 담은 주변의 ’차원 테이블’로 구성된 비정규화된 구조이다.
• 데이터 흐름: 운영 시스템의 데이터는 ETL을 통해 곧바로 비정규화된 데이터 마트로 적재된다. 전사적 데이터 웨어하우스는 ’준수 차원(Conformed Dimensions)’이라는 공통된 차원 테이블을 통해 논리적으로 연결된 데이터 마트들의 집합으로 간주된다.71
• 장단점: 빠른 구현이 가능하고 사용자 친화적이며 유연하지만, 데이터 중복이 발생하고 데이터 마트 간의 일관성을 유지하기 위한 노력이 필요하며, 전사적 통합이 어려울 수 있다.70

인몬과 킴볼의 논쟁은 본질적으로 데이터 아키텍처 설계에서 무엇을 우선시할 것인가에 대한 철학적 차이를 보여준다. 인몬은 데이터의 ‘저장과 통합’ 단계에 초점을 맞춰, 정규화를 통해 데이터 자산 자체의 순수성과 무결성을 지키는 ‘데이터 중심적(data-centric)’ 관점을 취한다. 반면 킴볼은 데이터의 ‘소비와 분석’ 단계에 초점을 맞춰, 비정규화를 통해 최종 사용자의 편의성과 성능을 극대화하는 ‘사용자 중심적(user-centric)’ 관점을 취한다. 현대의 많은 데이터 웨어하우스 아키텍처는 이 두 철학을 절충하는 하이브리드 접근법을 채택한다. 즉, 인몬 방식처럼 정규화된 데이터 레이크나 스테이징 영역을 두어 데이터의 통합과 무결성을 확보한 뒤, 이를 기반으로 킴볼 방식의 비정규화된 데이터 마트를 구축하여 분석 사용자에게 제공하는 것이다.72 이는 정규화와 비정규화가 아키텍처 내에서 각기 다른 목적을 위해 공존할 수 있는 상호 보완적인 도구임을 명확히 보여준다.

표 2: 데이터 모델링 패러다임 비교 분석

6. 비판적 및 미래적 관점

관계형 데이터베이스 정규화는 지난 50년간 데이터 관리의 이론과 실제를 지배해왔지만, 그 패러다임이 절대적이거나 완벽한 것은 아니다. 기술 환경의 변화와 새로운 이론의 등장은 정규화의 근본적인 가정에 대한 비판적 성찰을 요구하고 있다. 또한, 인공지능 기술의 발전은 데이터베이스 설계라는 인간 중심의 창의적 영역을 자동화할 새로운 가능성을 열고 있다. 제5부에서는 정규화 이론에 대한 비판적 시각과 대안적 모델을 탐구하고, 데이터베이스 설계의 자동화라는 미래적 전망을 조망한다.

6.1 비판과 대안적 공식화

정규화의 고전적 프레임워크는 그 자체로 완결성을 지니지만, 더 넓은 맥락에서 그 한계와 대안을 살펴보는 것은 주제에 대한 깊이 있는 이해를 위해 필수적이다.

6.1.1 커드 모델의 한계와 비판

에드거 F. 커드의 관계형 모델은 혁명적이었으나, 현실 세계의 모든 복잡성을 담아내기에는 한계가 있었다.

• 객체-관계 임피던스 불일치 (Object-Relational Impedance Mismatch): 관계형 모델의 테이블 기반 구조는 객체 지향 프로그래밍의 상속, 다형성과 같은 개념과 자연스럽게 부합하지 않는다. 이로 인해 애플리케이션 개발 시 데이터를 객체로 변환하고 다시 테이블로 변환하는 복잡한 매핑(ORM) 과정이 필요하다.74
• 구조적 경직성: 한번 정의된 스키마는 변경이 어렵고, 복잡한 계층 구조나 비정형 데이터를 표현하는 데 비효율적이다.74
• 닫힌 세계 가정의 한계: 참조 무결성을 강제하기 위한 관계형 모델의 ’닫힌 세계 가정(Closed-World Assumption)’은 분산 환경에서의 확장성과 정면으로 충돌한다. 전역적인 일관성을 유지하는 것은 대규모 분산 시스템에서는 거의 불가능에 가깝다.76

6.1.2 에릭 마이어의 ‘상보적 관계형(Co-Relational)’ 모델

이론 컴퓨터 과학자 에릭 마이어(Erik Meijer)는 관계형 모델(SQL)과 현대 NoSQL의 키-값 모델이 서로 수학적 쌍대(mathematical dual) 관계에 있다는 독창적인 이론을 제시했다.76

• 쌍대성의 개념: 범주론(Category Theory)에서 쌍대는 대상(object)은 그대로 두고 화살표(morphism)의 방향을 뒤집는 것을 의미한다. 마이어는 관계형 모델이 ’외래 키’라는 값 기반의 참조를 통해 테이블을 연결하는 반면, 객체/키-값 모델은 ’포인터/참조’를 통해 직접 연결한다는 점에 착안했다. 두 모델의 다이어그램은 화살표의 방향만 반대일 뿐, 구조적으로 동일한 쌍대 관계를 형성한다.77

• 쌍대적 특성: 이 구조적 쌍대성은 두 모델의 핵심 특성들이 서로 대립되는 이유를 명쾌하게 설명한다.

• SQL (관계형): ACID 일관성, 닫힌 세계 가정, 중앙 집중적, 동기적 ‘풀(pull)’ 방식의 쿼리 (Iterator 패턴)

• coSQL (비관계형): BASE 일관성, 열린 세계 가정, 분산적, 비동기적 ‘푸시(push)’ 방식의 데이터 전파 (Observer 패턴)

78

• 시사점: 이 이론은 ‘RDBMS 대 NoSQL’ 논쟁을 ’어느 것이 더 우월한가’의 문제가 아니라, ’문제의 성격에 따라 어떤 쌍대적 측면이 더 적합한가’의 문제로 재구성한다. 강력한 일관성과 임의의 복잡한 쿼리가 필요하면 관계형 측면이, 대규모 확장성과 유연성이 필요하면 상보적 관계형(co-relational) 측면이 유리하다. 이는 두 패러다임이 서로를 대체하는 것이 아니라, 서로 다른 문제 영역에 대한 동등하게 유효한, 그러나 정반대의 해법임을 시사한다.

6.1.3 철학적 비판: 푸코의 ‘정규화’

미셸 푸코(Michel Foucault)의 ‘정규화(normalization)’ 개념은 데이터베이스 이론과는 무관하지만, 비판적 성찰을 위한 흥미로운 은유를 제공한다. 푸코에게 정규화는 개인을 특정 ’규범(norm)’에 맞추어 훈련시키고 통제하는 ’규율 권력(disciplinary power)’의 한 형태였다.81 이 관점을 빌리자면, 데이터베이스 정규화는 혼란스러운 현실 세계의 데이터를 ’정규형’이라는 엄격하고 표준화된 규범에 맞추어 재단하는 행위로 볼 수 있다. 이 과정에서 규범에 맞지 않는 데이터 구조는 ‘이상 현상’ 또는 ’일탈’로 규정되어 반드시 교정되어야 할 대상으로 간주된다. 이는 정규화라는 기술적 과정 이면에 숨겨진, 데이터를 특정 질서에 편입시키려는 규율적 힘의 작동을 사유하게 한다.

6.2 데이터베이스 설계의 자동화

전통적으로 데이터베이스 설계와 정규화는 도메인 전문가와 데이터베이스 관리자(DBA)의 깊은 지식과 경험에 의존하는 수작업에 가까웠다. 그러나 최근 인공지능과 기계학습 기술의 발전은 이 복잡한 과정을 자동화하려는 연구에 새로운 활력을 불어넣고 있다.

6.2.1 자동화의 도전 과제와 접근법

자동화의 가장 큰 난관은 데이터에 내재된 의미론적 제약, 즉 함수 종속성을 인간의 개입 없이 발견하는 것이다.82 이를 해결하기 위한 다양한 접근법이 연구되고 있다.

• 데이터 기반 FD 발견: 최신 연구들은 원시 데이터(raw data)로부터 직접 함수 종속성을 찾아내는 알고리즘에 집중한다. Normalize와 같은 시스템은 데이터 인스턴스에서 발견되는 모든 FD를 효율적으로 계산하고, 사용자가 의미 있는 제약 조건을 선택하도록 돕는다.84

MAFD와 같은 다른 접근법은 확률적 그래피컬 모델(마르코프 블랭킷 등)을 사용하여 통계적으로 유의미한 근사 함수 종속성(Approximate FD)을 발견함으로써, 데이터의 노이즈나 불완전성에 더 강건하게 대응한다.85

• AI/ML 기반 정규화:

• 유전 알고리즘: 한 연구에서는 데이터베이스 설계를 다중 목표 최적화 문제로 정의하고, 유전 알고리즘을 사용하여 최적의 스키마를 ’진화’시키는 방법을 제안했다. 이 알고리즘의 적합도 함수(fitness function)는 테이블 수 최소화, 데이터 중복 최소화 등 정규화의 목표들을 직접적으로 반영한다. 이는 정규화 원칙을 최적화 알고리즘의 제약 조건 및 목표 함수로 변환하여 자동 설계를 시도하는 접근법이다.82

• 스키마 매핑 및 재사용: 대규모 기업 환경에서는 유사한 데이터 통합 시나리오가 반복된다. GAIA와 같은 시스템은 기존에 수작업으로 정의된 스키마 매핑들로부터 일반화된 ’메타-매핑(meta-mapping)’을 학습하여, 새로운 스키마에 대한 적절한 변환을 자동으로 추천한다.86 최근에는 거대 언어 모델(LLM)을 스키마 매칭 작업에 활용하려는 시도도 이루어지고 있다.83

6.2.2 미래 전망: AI 증강 설계

이러한 연구들은 데이터베이스 설계의 미래가 인간의 직관과 경험에만 의존하는 장인적 기술에서, AI가 제안하고 인간이 감독하는 AI 증강(AI-augmented) 프로세스로 전환될 가능성을 시사한다. 미래의 데이터베이스 설계 워크플로우는 다음과 같을 수 있다:

1. 분석가가 원시 데이터셋을 시스템에 제공한다.
2. AI 시스템이 데이터로부터 후보 함수 종속성들을 자동으로 발견한다.
3. 최적화 알고리즘(예: 유전 알고리즘)이 이 종속성들을 바탕으로 여러 정규화된 스키마 후보들을 생성한다. 각 후보는 서로 다른 최적화 기준(예: 무결성 최우선, 성능 균형 등)에 따라 평가된다.
4. 인간 전문가는 AI가 제안한 스키마들을 검토하고, 비즈니스 맥락에 가장 적합한 최종 설계를 선택하거나 미세 조정한다.

이러한 패러다임에서 정규화 원칙은 인간 설계자가 수동으로 적용하는 규칙이 아니라, 자동화된 최적화 시스템이 따라야 할 목표 함수와 제약 조건으로 내재화된다. 인간의 역할은 저수준의 설계 작업에서 벗어나, AI의 제안을 비판적으로 평가하고 비즈니스 전략과 연계하는 고수준의 감독자 역할로 변화할 것이다.

7. 결론

본 안내서는 관계형 데이터베이스 정규화에 대한 다각적인 고찰을 통해, 그것이 단순한 데이터베이스 설계 규칙을 넘어 데이터 관리의 근본적인 원리임을 밝혔다. 에드거 F. 커드가 제시한 데이터 독립성이라는 고차원적 목표에서 시작하여, 데이터 이상 현상이라는 구체적인 문제를 해결하기 위한 실용적 방법론으로 발전해 온 정규화의 역사는 그 이론적 깊이와 실용적 가치를 동시에 증명한다.

함수 종속성, 다치 종속성, 조인 종속성과 같은 정교한 이론적 도구들은 데이터 내에 숨겨진 의미론적 제약 조건을 명시적으로 드러내고, 이를 통해 현실 세계를 더 정확하게 모델링하는 길을 제시했다. 제1정규형에서 제6정규형에 이르는 단계적 과정은 데이터의 중복성을 체계적으로 제거하고 구조적 무결성을 확보하는 논리적 여정이며, 특히 제3정규형까지의 과정은 대부분의 실무적 문제를 해결하는 강력한 프레임워크를 제공한다.

그러나 정규화의 이론적 순수성은 성능이라는 현실적 제약과 필연적으로 충돌한다. 높은 수준의 정규화가 야기하는 조인 연산의 증가는 쿼리 최적화기에 큰 부담을 주며, 특히 대규모 데이터를 다루는 분석 환경에서는 비정규화라는 실용적 타협을 요구한다. 인몬과 킴볼의 데이터 웨어하우징 논쟁은 이러한 무결성과 성능 간의 트레이드오프가 아키텍처 수준에서 어떻게 철학적 선택으로 나타나는지를 명확히 보여준다.

더 나아가, NoSQL과 그래프 데이터베이스의 등장은 정규화의 패러다임에 근본적인 질문을 던졌다. 이들은 정규화의 목표 자체를 부정하기보다는, 관계형 모델의 ’조인’이라는 특정 메커니즘을 우회하여 확장성과 유연성을 확보하는 대안적 경로를 제시했다. 에릭 마이어의 상보적 관계형 모델은 이러한 대립이 단순한 기술적 경쟁이 아니라, 데이터 관계를 바라보는 두 개의 근본적으로 다른, 그러나 수학적으로 쌍대적인 관점의 발현임을 이론적으로 규명했다.

결론적으로, 정규화는 특정 기술(RDBMS)에 국한된 규칙이 아니라, 정보를 논리적으로 조직하고 중복을 최소화하려는 보편적 원리로 이해되어야 한다. 이 원리는 관계형 데이터베이스의 테이블 분해에서, 데이터 웨어하우스의 차원 설계, NoSQL의 데이터 임베딩 전략, 심지어 기계 학습의 특징 스케일링에 이르기까지 다양한 형태로 그 변주를 드러낸다. 따라서 미래의 데이터 전문가에게 요구되는 역량은 특정 모델에 대한 맹목적인 추종이 아니라, 정규화라는 근본 원리에 대한 깊은 이해를 바탕으로 주어진 문제의 성격에 맞게 정규화, 비정규화, 그리고 다양한 데이터 모델링 패러다임을 실용적으로 선택하고 조합할 수 있는 통찰력일 것이다. 인공지능이 설계 과정을 자동화하는 미래에도, 이러한 근본 원리에 대한 이해는 AI의 제안을 비판적으로 평가하고 최적의 아키텍처를 선택하는 인간 전문가의 핵심 역량으로 남을 것이다.

표 3: 인몬 대 킴볼 - 데이터 웨어하우징 철학 비교

8. 참고 자료

1. ko.wikipedia.org, accessed July 16, 2025, https://ko.wikipedia.org/wiki/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4_%EC%A0%95%EA%B7%9C%ED%99%94#:~:text=%EC%A0%95%EA%B7%9C%ED%99%94%EC%9D%98%20%EB%AA%A9%EC%A0%81%EC%9D%80%20%ED%95%98%EB%82%98,%EC%9D%98%20%EA%B0%9C%EB%85%90%EC%9D%84%20%EB%8F%84%EC%9E%85%ED%95%98%EC%98%80%EB%8B%A4.
2. A Relational Model of Data for Large Shared Data Banks, accessed July 16, 2025, https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf
3. 32 A Relational Model of Large Shared Data Banks (1970) - MIT Press Direct, accessed July 16, 2025, https://direct.mit.edu/books/edited-volume/chapter-pdf/2248382/9780262363174_c003100.pdf
4. A Relational Model of Data For Large Shared Data Banks: Lnformation Retrieval - Scribd, accessed July 16, 2025, https://www.scribd.com/document/522570326/codd
5. [DB] 데이터베이스 정규화(DB Normalization) 개념과 장단점, accessed July 16, 2025, https://bio-logisch.tistory.com/27
6. 데이터베이스 정규화 이론 1. 정규화이론이란? | 쿠키의 개발 블로그, accessed July 16, 2025, https://www.korecmblog.com/blog/database-normalization-1-what-is
7. [DB] 정규화의 개념 및 목적 - velog, accessed July 16, 2025, https://velog.io/@chy0428/DB-%EC%A0%95%EA%B7%9C%ED%99%94%EC%9D%98-%EA%B0%9C%EB%85%90-%EB%B0%8F-%EB%AA%A9%EC%A0%81
8. 정규화 (Normalization). 관계형 데이터베이스의 개념에 대해 찾아보니 …, accessed July 16, 2025, https://medium.com/jiwon-bae/%EC%A0%95%EA%B7%9C%ED%99%94-normalization-272d8a88b49
9. [DB] Modification Anomaly: 데이터베이스에 삽입/수정/삭제 시 …, accessed July 16, 2025, https://engineerinsight.tistory.com/397
10. 데이터베이스 이상 현상, accessed July 16, 2025, https://deep-deep-deep.tistory.com/161
11. [데이터베이스 개론] Chapter9 - 정규화, accessed July 16, 2025, https://rovictory.tistory.com/185
12. [정보처리기사] 데이터베이스 이상현상(Anomaly) : 삽입이상, 갱신이상, 삭제이상, accessed July 16, 2025, https://august-jhy.tistory.com/55
13. 데이터베이스 이상 현상(Anomalies) 정리 - Coding Note - 티스토리, accessed July 16, 2025, https://conding-note.tistory.com/244
14. [DB] 데이터베이스 삽입, 갱신, 삭제 이상 현상 (Anomaly) - yunanP - 티스토리, accessed July 16, 2025, https://yunanp.tistory.com/21
15. 함수 종속성(완전 함수 종속, 부분함수 종속, 이행 … - 코딩공장공장장, accessed July 16, 2025, https://developer111.tistory.com/entry/%EC%8B%9C%EC%8A%A4%ED%85%9C-%ED%99%98%EA%B2%BD%EB%B3%80%EC%88%98%EC%99%80-%EC%82%AC%EC%9A%A9%EC%9E%90-%ED%99%98%EA%B2%BD%EB%B3%80%EC%88%98%EC%9D%98-%EC%B0%A8%EC%9D%B4
16. 정규화 총정리 (1)_이상 현상(삽입, 삭제, 수정 이상) - innn - 티스토리, accessed July 16, 2025, https://goodafteryoon.tistory.com/47
17. Introduction of Database Normalization - GeeksforGeeks, accessed July 16, 2025, https://www.geeksforgeeks.org/dbms/introduction-of-database-normalization/
18. 정규화 - Shin’s Reports - 티스토리, accessed July 16, 2025, https://jaewonsoft.tistory.com/9
19. [데이터베이스] 정규화 정리 - TaxFree - 티스토리, accessed July 16, 2025, https://cotak.tistory.com/96
20. [데이터베이스] 데이터베이스 기본/ERD와 정규화 과정 - 코린이 삐약이의 성장일기, accessed July 16, 2025, https://bbeeyaks-moment.tistory.com/entry/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EA%B8%B0%EB%B3%B8ERD%EC%99%80-%EC%A0%95%EA%B7%9C%ED%99%94-%EA%B3%BC%EC%A0%95
21. [정보처리기사] 정규화(Normalization) 과정과 이상(Anomaly)의 종류 - Devinus - 티스토리, accessed July 16, 2025, https://devinus.tistory.com/26
22. [RDBMS] DB의 정규화 단계(1NF, 2NF, 3NF, BCNF, 4NF, 5NF)의 …, accessed July 16, 2025, https://co-no.tistory.com/entry/RDBMS
23. [DB 이론] 데이터베이스 정규화란? (이상 문제, 함수적 종속, 정규화 과정) - The Nirsa Way, accessed July 16, 2025, https://nirsa.tistory.com/107
24. 데이터베이스의 정규화(normalization)에 대해 알아보겠습니다., accessed July 16, 2025, https://feccle.tistory.com/23
25. 23화 [DB설계] 23. 다치 종속성(MVD)과 결합 종속성 - 브런치, accessed July 16, 2025, https://brunch.co.kr/@@hqFh/95
26. [DB] 제 4정규형과 제 5정규형, 4NF와 5NF - 코드 연구소 - 티스토리, accessed July 16, 2025, https://code-lab1.tistory.com/270
27. [데이터베이스] 정규화(Normalization) (1NF - 5NF) - webcodur - 티스토리, accessed July 16, 2025, https://webcodur.tistory.com/67
28. 관계형 데이터베이스의 정규화: 심층 분석 - AppMaster, accessed July 16, 2025, https://appmaster.io/ko/blog/gwangyehyeong-deiteobeiseuyi-jeonggyuhwa
29. Armstrong’s axioms - Wikipedia, accessed July 16, 2025, https://en.wikipedia.org/wiki/Armstrong%27s_axioms
30. Functional Dependencies and Armstrong’s Axioms For Query Optimization - Justin Jaffray, accessed July 16, 2025, https://justinjaffray.com/functional-dependencies-and-armstrongs-axioms-for-query-optimization/
31. Exercise 4 - CS - Huji, accessed July 16, 2025, https://www.cs.huji.ac.il/course/2005/db/solutions/ex4/sol4.pdf
32. Functional Dependencies and Normalization - TINMAN, accessed July 16, 2025, http://tinman.cs.gsu.edu/~raj/4710/sp08/fd-theory.pdf
33. 데이터 모델 정규화/반정규화의 실전 프로젝트 적용메뉴2, accessed July 16, 2025, http://keiis.co.kr/study0/600.Utility/A100.DB/E010.ERwin/100.normalization.html
34. Understanding Database Normalization: A Practical Guide with E …, accessed July 16, 2025, https://medium.com/@ajadiololade/understanding-database-normalization-a-practical-guide-with-e-commerce-examples-02c87b234a49
35. 정규화(Normalization) 개념과 정규화 과정(1NF, 2NF, 3NF, BCNF) - IT 정보기술 따라잡기!, accessed July 16, 2025, https://minimax95.tistory.com/entry/%EC%A0%95%EA%B7%9C%ED%99%94Normalization-%EA%B0%9C%EB%85%90%EA%B3%BC-%EA%B8%B0%EB%B3%B8-%EA%B3%BC%EC%A0%95
36. 데이터베이스 정규화 단계 (각 정규화 별 예시) - seseJeon, accessed July 16, 2025, https://sese-jeon.tistory.com/6
37. [Database] 정규화 (Normalization)와 1NF, 2NF, 3NF, BCNF - velog, accessed July 16, 2025, https://velog.io/@jystella17/Database-%EC%A0%95%EA%B7%9C%ED%99%94-Normalization%EC%99%80-1NF-2NF-3NF-BCNF
38. BCNF & 3NF - velog, accessed July 16, 2025, https://velog.io/@myday0827/BCNF-3NF
39. 정규화(Normalization) - 1223v - 티스토리, accessed July 16, 2025, https://farmfarm1223.tistory.com/98
40. 데이터베이스 정규화 - BCNF - YABOONG, accessed July 16, 2025, https://yaboong.github.io/database/2018/03/10/database-normalization-2/
41. [Database] 정규화(Normalization) 과정 (1NF, 2NF, 3NF, BCNF) - Hoyeon, accessed July 16, 2025, https://hoyeonkim795.github.io/posts/normalization-course/
42. [복습]데이터베이스 정규화 -4 (4NF, 5NF) - 파란만장 쬬롱 - 티스토리, accessed July 16, 2025, https://zzozzomin08.tistory.com/12
43. 데이터베이스 제5정규형 - IT 위키, accessed July 16, 2025, https://itwiki.kr/w/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4_%EC%A0%9C5%EC%A0%95%EA%B7%9C%ED%98%95
44. [DB이론] 정규화 ( Normalization ) - Victolee - 티스토리, accessed July 16, 2025, https://victorydntmd.tistory.com/132
45. Sixth normal form - Wikipedia, accessed July 16, 2025, https://en.wikipedia.org/wiki/Sixth_normal_form
46. Sixth normal form - DDE Scholar - Acemap, accessed July 16, 2025, https://ddescholar.acemap.info/field/2014446535
47. Sixth-Normal-Form.pdf - ResearchGate, accessed July 16, 2025, https://www.researchgate.net/profile/Sanjiv-Singh-4/publication/362570032_Sixth_Normal_Form/links/62f23146505511283ea10fc9/Sixth-Normal-Form.pdf
48. Synergy in Time: Combining Anchor Modeling and 6NF for Robust …, accessed July 16, 2025, https://volodymyrpavlyshyn.medium.com/synergy-in-time-combining-anchor-modeling-and-6nf-for-robust-temporal-databases-b5f2ac673d56
49. Sixth Normal Form (6NF) - Medium, accessed July 16, 2025, https://medium.com/@dinesh.kolli2000/sixth-normal-form-6nf-19ea30251993
50. [데이터베이스] 정규화 vs. 비정규화(반정규화) - lijly - 티스토리, accessed July 16, 2025, https://owlyr.tistory.com/20
51. accessed January 1, 1970, https.owlyr.tistory.com/20
52. 데이터베이스 정규화와 비정규화의 이해 - F-Lab, accessed July 16, 2025, https://f-lab.kr/insight/understanding-database-normalization-and-denormalization
53. 데이터베이스 설계의 핵심: 정규화와 비정규화의 이해 - F-Lab, accessed July 16, 2025, https://f-lab.kr/insight/understanding-normalization-and-denormalization-in-database-design
54. In terms of databases, is “Normalize for correctness, denormalize for performance” a right mantra? [closed] - Stack Overflow, accessed July 16, 2025, https://stackoverflow.com/questions/293425/in-terms-of-databases-is-normalize-for-correctness-denormalize-for-performanc
55. Debunking the Myth of Join Ordering: Toward Robust SQL Analytics - arXiv, accessed July 16, 2025, https://arxiv.org/html/2502.15181v1
56. Efficient Massively Parallel Join Optimization for Large Queries* - Vasilis Mageirakos, accessed July 16, 2025, https://mageirakos.github.io/files/pubs/gpuqo.pdf
57. How Good Are Query Optimizers, Really? - VLDB Endowment, accessed July 16, 2025, https://www.vldb.org/pvldb/vol9/p204-leis.pdf
58. TPC-H Benchmark - Emergent Mind, accessed July 16, 2025, https://www.emergentmind.com/topics/tpch-benchmark
59. A Review of Star Schema Benchmark - arXiv, accessed July 16, 2025, https://arxiv.org/pdf/1606.00295
60. RDB(관계형 데이터베이스) NoSQL(비관계형 데이터베이스) 비교 - gaeggu’s blog - 티스토리, accessed July 16, 2025, https://gaeggu.tistory.com/m/29
61. DB 유형 - NOSQL - CAP 이론 - Char - 티스토리, accessed July 16, 2025, https://charstring.tistory.com/107
62. [MongoDB] NoSQL 특징, NoSQL / MongoDB 모델링 - velog, accessed July 16, 2025, https://velog.io/@sukyeongs/MongoDB-NoSQL-%ED%8A%B9%EC%A7%95-NoSQL-MongoDB-%EB%AA%A8%EB%8D%B8%EB%A7%81
63. NoSQL 특징 및 제품 분류, CAP 이론, Consistency 일관성, Availability …, accessed July 16, 2025, https://swingswing.tistory.com/23
64. neo4j.com, accessed July 16, 2025, https://neo4j.com/blog/graph-database/graph-database-vs-relational-database/#:~:text=Relational%20databases%20optimize%20for%20storage,query%20performance%20to%20scaling%20strategies.
65. Graph vs Relational Databases - Difference Between Databases - AWS, accessed July 16, 2025, https://aws.amazon.com/compare/the-difference-between-graph-and-relational-database/
66. Graph Database vs. Relational Database: What’s The Difference? - Neo4j, accessed July 16, 2025, https://neo4j.com/blog/graph-database/graph-database-vs-relational-database/
67. Transition from relational to graph database - Getting Started - Neo4j, accessed July 16, 2025, https://neo4j.com/docs/getting-started/appendix/graphdb-concepts/graphdb-vs-rdbms/
68. Graph Database vs Relational Database: Which Is Best for Your Needs? | InterSystems, accessed July 16, 2025, https://www.intersystems.com/resources/graph-database-vs-relational-database-which-is-best-for-your-needs/
69. Kimball vs Inmon - The History of Data Warehousing - YouTube, accessed July 16, 2025, https://www.youtube.com/watch?v=RfKAXnVDuog
70. Data Warehouse Architecture Approaches: Inmon vs. Kimball | by Archana Goyal | Medium, accessed July 16, 2025, https://medium.com/@goyalarchana17/data-warehouse-architecture-approaches-inmon-vs-kimball-0bd8f04bb5cf
71. Inmon vs Kimball - Snowflake vs star? : r/dataengineering - Reddit, accessed July 16, 2025, https://www.reddit.com/r/dataengineering/comments/1ahebky/inmon_vs_kimball_snowflake_vs_star/
72. Navigating the Data Maze: A Comparison of Modeling Techniques …, accessed July 16, 2025, https://datasense.be/blog/comparison-of-modelling-techniques/
73. Difference between 3NF and Dimensional models? : r … - Reddit, accessed July 16, 2025, https://www.reddit.com/r/dataengineering/comments/149nipn/difference_between_3nf_and_dimensional_models/
74. Introduction of Relational Model and Codd Rules in DBMS - GeeksforGeeks, accessed July 16, 2025, https://www.geeksforgeeks.org/dbms/introduction-of-relational-model-and-codd-rules-in-dbms/
75. database - Web Development - Object db vs Relational db - Stack …, accessed July 16, 2025, https://stackoverflow.com/questions/5358131/web-development-object-db-vs-relational-db
76. A co-Relational Model of Data for Large Shared Data Banks - ACM Queue, accessed July 16, 2025, https://queue.acm.org/detail.cfm?id=1961297
77. (PDF) A Co-relational Model of Data for Large Shared Data Banks - ResearchGate, accessed July 16, 2025, https://www.researchgate.net/publication/221496589_A_Co-relational_Model_of_Data_for_Large_Shared_Data_Banks
78. (PDF) SQL versus coSQL — a compendium to Erik Meijer’s paper, accessed July 16, 2025, https://www.researchgate.net/publication/235707980_SQL_versus_coSQL_—_a_compendium_to_Erik_Meijer’s_paper
79. Subject/Observer is Dual to Iterator (Erik “Head in the Box” Meijer, Microsoft Corporation, emeijer@microsoft.com), accessed July 16, 2025, https://csl.stanford.edu/~christos/pldi2010.fit/meijer.duality.pdf
80. Erik Meijer - Contravariance is the Dual of Covariance Implies Iterable is the Dual of Observable (Making Money Using Math), accessed July 16, 2025, https://www.sen-symposium.nl/history/2014/program/meijer/
81. Normalization (Chapter 54) - The Cambridge Foucault Lexicon, accessed July 16, 2025, https://www.cambridge.org/core/books/cambridge-foucault-lexicon/normalization/70C71BDAC52F379E80471A0F34F41624
82. (PDF) A Novel Automatic Relational Database Normalization Method, accessed July 16, 2025, https://www.researchgate.net/publication/364633548_A_Novel_Automatic_Relational_Database_Normalization_Method
83. ReMatch: Retrieval Enhanced Schema Matching with LLMs - arXiv, accessed July 16, 2025, https://arxiv.org/html/2403.01567v1
84. Data-driven Schema Normalization - OpenProceedings.org, accessed July 16, 2025, https://openproceedings.org/2017/conf/edbt/paper-89.pdf
85. Approximate Functional Dependencies Discovery Using Markov Blanket - VLDB Endowment, accessed July 16, 2025, https://vldb.org/workshops/2024/proceedings/DATAI/DATAI-4.pdf
86. Meta-Mappings for Schema Mapping Reuse - VLDB Endowment, accessed July 16, 2025, http://www.vldb.org/pvldb/vol12/p557-atzeni.pdf