1. 정규화를 배우기 전의 사전 지식들
1) 키(Key)
데이터베이스에서 키는 각 레코드를 고유하게 식별하거나 테이블 간의 관계를 정의하는 데 중요한 역할을 합니다. 다음은 다양한 키의 종류와 예시입니다.
1.1) 슈퍼키 (Super Key)
테이블 내에서 유일성을 보장하는 하나 이상의 속성(컬럼) 집합입니다. 최소성은 보장하지 않습니다.
- 고객 테이블에 있는 {고객 아이디, 고객 이름}, {고객 아이디}, {고객 아이디, 고객 이메일} 모두 슈퍼키가 될 수 있습니다.
- {고객 아이디, 고객 이름}은 고객을 고유하게 식별할 수 있지만, 고객 아이디만으로도 고유성이 보장되므로 최소성을 갖추지 못한 슈퍼키입니다.
1.2) 후보키 (Candidate Key)
테이블에서 유일성과 최소성을 모두 만족하는 키입니다. 즉, 해당 속성만으로 유일하게 레코드를 식별할 수 있으며, 속성 개수를 줄이면 유일성을 잃게 되는 경우입니다.
- 고객 테이블에서 고객 아이디만으로도 유일성과 최소성이 보장된다면, 고객 아이디는 후보키가 됩니다.
- {고객 아이디}는 유일성과 최소성을 모두 만족합니다. 하지만 {고객 아이디, 고객 이름}은 최소성을 만족하지 않으므로 후보키가 아닙니다.
- 최소성이라는 것은 "1"로 절대값이 아닙니다. 슈퍼키 안에서 상대적인 최소값을 최소성이라고 합니다. 만약 유일성을 만족하는 집합인 {X, Y}에서 두 개 밑으로 줄일 수 없다면 {X, Y}는 후보키가 됩니다.
1.3) 기본키 (Primary Key)
후보키 중에서 선택된 키로, 테이블에서 각 레코드를 고유하게 식별하는 데 사용됩니다. 기본키는 NULL 값을 가질 수 없으며, 유일성이 보장됩니다.
- 고객 테이블에서 고객 아이디를 기본키로 선택하면, 이 속성은 테이블 내에서 고유하게 각 고객을 식별합니다.
- 기본키는 한 테이블에 하나만 존재합니다.
1.4) 대체키 (Alternate Key)
후보키 중에서 기본키로 선택되지 않은 나머지 키를 대체키라고 합니다. 기본키가 아닌 다른 유일성을 보장하는 키들이 대체키가 됩니다.
- 고객 테이블에서 고객 아이디가 기본키로 선택되었다면, 유일성과 최소성을 보장하는 고객 이메일은 대체키가 될 수 있습니다.
- 대체키는 테이블 내에서 레코드를 유일하게 식별할 수 있지만, 기본키로 사용되지 않은 후보키입니다.
1.5) 외래키 (Foreign Key)
다른 테이블의 기본키를 참조하는 키입니다. 외래키는 두 테이블 간의 관계를 정의하며, 외래키가 있는 테이블은 참조 무결성(참조하는 레코드가 존재해야 함)을 유지해야 합니다.
- 주문 테이블이 고객 테이블을 참조하는 경우, 주문 테이블의 고객 아이디는 고객 테이블의 기본키인 고객 아이디를 참조하는 외래키입니다.
- 외래키를 통해 주문 테이블은 고객 테이블의 고객과 관계를 맺습니다. 고객이 삭제되면 해당 외래키를 참조하는 레코드에도 영향을 줄 수 있어 참조 무결성을 유지하는 제약 조건이 필요할 수 있습니다.
2) 이상현상(Anomaly)
데이터베이스에서 이상현상(Anomaly)은 잘못 설계된 테이블 구조로 인해 발생하는 데이터의 무결성 문제를 말합니다.
일반적으로 관련성이 없는 속성들이 하나의 테이블에 묶여 있을 때 이러한 현상이 발생하며, 이를 해결하기 위해 정규화(Normalization)가 필요합니다. 이상현상은 크게 삽입 이상, 갱신 이상, 그리고 삭제 이상으로 나눌 수 있으며, 각 이상현상의 정의와 예시는 다음과 같습니다.
2.1) 삽입 이상 (Insertion Anomaly)
새로운 데이터를 삽입할 때, 불필요한 정보까지 함께 입력해야 하는 상황을 말합니다. 이로 인해 데이터 무결성이 깨질 위험이 있으며, 효율적이지도 않습니다.
- 한 테이블에 고객 정보와 이벤트 참여 정보가 함께 저장되어 있다고 가정해봅니다. 새로운 고객을 테이블에 삽입하려는 경우, 고객이 아직 이벤트에 참여하지 않았더라도 이벤트 정보와 참여 여부 필드를 함께 채워야 합니다. 이러한 불필요한 데이터를 넣게 되면 데이터 무결성에 문제가 생길 수 있습니다.
2.2) 갱신 이상 (Update Anomaly)
데이터를 갱신할 때, 하나의 행만 업데이트되어 데이터 일관성이 깨지는 상황입니다. 동일한 데이터가 여러 행에 중복으로 존재할 때 발생하며, 모든 관련 행을 일일이 수정해야 합니다.
- 예를 들어 고객이 소속된 부서 정보를 고객 테이블에 저장하고, 부서가 여러 행에 걸쳐 중복되어 있다고 가정해봅니다. 만약 부서 정보가 변경되면, 모든 고객 행에서 해당 부서 정보를 수정해야 합니다. 특정 행만 갱신되고 나머지 행이 갱신되지 않는 경우, 데이터 불일치로 인해 일관성이 깨질 수 있습니다.
2.3) 삭제 이상 (Deletion Anomaly)
데이터를 삭제할 때, 필요한 정보까지 함께 삭제되는 상황입니다. 이로 인해 중요한 데이터가 손실될 수 있습니다.
- 학생과 강사 정보가 하나의 테이블에 저장되어 있다고 가정해봅니다. 특정 학생 정보를 삭제하려고 할 때, 만약 그 학생이 유일하게 한 강사에게 배정된 경우, 강사 정보도 함께 삭제되는 문제가 발생할 수 있습니다. 이렇게 원치 않는 데이터 손실이 발생하여 데이터 무결성이 깨질 수 있습니다.
이와 같은 이상현상의 근본 원인은 테이블의 설계 방식에 있습니다. 이러한 문제는 속성 간의 관계를 나타내는 함수적 종속성을 제대로 반영하지 못한 결과입니다.
3) 함수 종속(Functional Dependency)
함수 종속 (Functional Dependency)는 데이터베이스 관계에서 한 속성(또는 속성 집합)이 다른 속성을 결정하는 관계를 나타내는 개념입니다. 함수 종속에서는 다음의 용어가 있습니다.
- 결정자 (Determinant): 함수 종속 관계에서 다른 속성의 값을 결정하는 속성입니다. 예를 들어, 도서 ISBN번호가 책 제목을 고유하게 결정한다고 하면 도서 ISBN번호는 책제목의 결정자입니다.
- 종속자 (Dependent): 함수 종속 관계에서 결정자에 의해 결정되는 속성입니다. 예를 들어, 위 관계에서 책제목은 도서ISBN번호의 종속자입니다.
3.1) 함수 종속(Functional Dependency)
속성 X와 Y가 있을 때, 관계 X -> Y가 성립한다는 것은 각 X 값마다 오직 하나의 Y 값만 대응한다는 의미입니다.이때 X를 Y의 결정자라고 하고, Y는 X에 함수적으로 종속된다고 표현합니다. 다시 말해, X의 값이 정해지면 이에 따라 오직 하나의 Y 값이 결정된다는 뜻입니다.
3.2) 부분 종속 (Partial Dependency)
복합키가 있는 경우, 복합키의 일부 속성에 의해서 다른 속성이 종속되는 관계를 말합니다.
복합키가 {X, Y}인 상황에서 {X, Y} -> Z와 Y -> Z가 모두 성립한다면, Z는 기본키 전체에 종속되는 것이 아니라 기본키의 일부인 Y에만 종속됩니다. 이를 부분 종속이라 하며, 이 경우 Z는 복합키의 일부에 의해 결정되므로 테이블을 분리하지 않으면 데이터 중복 및 이상 현상이 발생할 수 있습니다.
- 학생-과목 테이블에서 기본키가 {학생ID, 과목ID}라고 할 때, ‘과목 이름’은 과목ID에만 종속될 수 있습니다. 따라서 과목 이름은 기본키 {학생ID, 과목ID}의 일부인 과목ID에만 종속된 속성입니다. 이를 부분 종속이라고 합니다.
3.3) 완전 종속 (Full Dependency)
한 속성이 복합키 전체에 종속되며, 기본키의 일부에만 종속되지 않는 관계입니다. 부분 종속이 아닌 것을 말합니다.
기본키가 {X, Y}인 관계에서 {X, Y} -> Z가 성립하고, X 또는 Y 중 하나만으로는 Z를 결정할 수 없는 경우 Z는 {X, Y}에 완전 종속됩니다.
3.4) 이행적 종속 (Transitive Dependency)
한 속성이 다른 속성을 통해서 간접적으로 종속되는 관계입니다. X -> Y, Y -> Z가 성립할 때 X -> Z도 성립하게 되며, 이 경우 Z는 X에 이행적으로 종속된다고 합니다. 의미적으로는 Z가 X와 직접적인 관계가 아닌 중간자 Y를 거쳐 종속 관계를 형성하는 것입니다.
- 직원 테이블에서 직원ID -> 부서ID이고 부서ID -> 부서명이라면, 직원ID -> 부서명 관계도 성립합니다. 이 경우 부서명은 직원ID에 이행적으로 종속된 것입니다.
2. 정규화(normalization)
정규화는 이상현상이 발생하지 않도록 함수적 종속성 관계를 이용하여 테이블을 분해하는 과정입니다. 이를 통해 관련 없는 속성들을 분리하여 별도의 테이블로 구성하고, 중복을 줄이며 데이터 무결성을 보장할 수 있습니다. 정규화의 목적은 이상현상을 방지하고, 데이터의 일관성과 무결성을 유지하면서 효율적인 데이터 구조를 만드는 것입니다.
정규화는 보통 여러 단계로 나뉘며, 각 단계마다 테이블 구조가 보다 엄격하게 구성됩니다. 여기서는 1정규형부터 보이스-코드 정규형까지 정규화 과정과 각 단계의 정의, 예시를 설명합니다.
1) 1 정규형(1NF)
1정규형은 각 속성의 값이 원자값(atomic value)을 가지도록 하는 것입니다. 즉, 하나의 속성에는 하나의 값만 포함되어야 합니다.
- 비정규화된 테이블
| 학생ID | 이름 | 연락처 |
| 101 | 김철 | 010-1234-0233, 010-2332-2938 |
위 테이블에서 연락처 속성에 두 개의 번호가 저장되어 있어 원자성을 위반하고 있습니다.
- 1정규형 적용 후
| 학생ID | 이름 | 연락처 |
| 101 | 김철 | 010-1234-0233 |
| 101 | 김철 | 010-2332-2938 |
연락처를 분리해, 하나의 값만 저장되도록 합니다.
2) 2정규형(2NF)
2정규형은 1정규형을 만족한 상태에서 기본 키가 아닌 모든 속성이 기본 키에 대해 완전 함수 종속을 만족하도록 하는 것입니다. 즉, 부분 함수 종속성을 제거하여 기본 키의 일부가 아닌 전체에 종속되도록 합니다.
- 비정규화된 테이블
| 직원ID | 프로젝트ID | 직원이름 | 부서명 | 시간당급여 |
| 201 | P101 | 이민수 | 개발팀 | 30000 |
| 202 | P102 | 박지문 | 디자인팀 | 35000 |
| 201 | P102 | 이민수 | 개발팀 | 30000 |
비정규화된 테이블로, 직원이 특정 프로젝트에 참여하면서 시간당 급여를 받는 경우를 표현합니다. 여기서 직원ID와 프로젝트ID가 복합 키이며, 직원이름, 부서명, 시간당급여는 기본 키가 아닌 속성들입니다.
- 문제점
직원이름과 부서명은 직원ID에만 종속되어 있고, 프로젝트ID와는 관계가 없습니다. 따라서 직원이름과 부서명이 복합 키 전체가 아닌 직원ID에 부분 함수 종속되어 있습니다.
{직원ID, 프로젝트ID} -> {직원이름}
{직원ID} -> {직원이름} (직원ID만으로 직원이름을 결정하는 부분종속이 발생함)
- 2정규형 적용 후
1. 직원 테이블
직원 정보는 직원ID에 따라 완전히 종속되므로, 이를 별도의 테이블로 분리합니다.
| 직원ID | 직원이름 | 부서명 |
| 201 | 이민수 | 개발팀 |
| 202 | 박지영 | 디자인팀 |
2. 프로젝트 테이블
각 직원이 프로젝트에 참여하면서 발생하는 시간당급여 정보를 따로 저장합니다.
| 직원ID | 프로젝트ID | 시간당급여 |
| 201 | P101 | 30000 |
| 202 | P102 | 35000 |
| 201 | P102 | 30000 |
이렇게 테이블을 분리하면 직원이름과 부서명이 더 이상 부분 함수 종속되지 않아 2정규형을 만족하게 됩니다.
3) 3정규형(3NF)
3정규형은 2정규형을 만족한 상태에서 이행적 종속(transitive dependency)이 제거된 상태를 의미합니다.
- 비정규화된 테이블
| 학생ID | 학생이름 | 교수ID | 교수이름 | 교수연락처 |
| 101 | 김철수 | 201 | 이민호 | 010-1234-3222 |
| 102 | 박영희 | 202 | 정수빈 | 010-3232-2312 |
| 103 | 이준기 | 201 | 이민호 | 010-1234-3222 |
학생ID는 기본 키입니다. 학생ID를 기준으로 학생이름, 교수ID, 교수이름, 교수연락처가 저장되어 있습니다.
- 문제점
{학생 ID} -> {교수ID} -> {교수이름, 교수연락처}
다음과 같이 이행적 종속 관계가 발생합니다.교수이름과 교수연락처가 교수ID에 종속되어 있습니다. 이는 학생ID에 대해 이행적 종속 관계를 형성하므로 3정규형을 위반합니다. 이는 또한 갱신 이상이 발생할 수 있습니다. 만약 특정 교수의 연락처가 변경된다면, 그 교수를 담당하는 모든 학생의 교수연락처를 수정해야 합니다.
- 3정규형 적용 후
이행적 종속을 제거하여 아래와 같이 두 개의 테이블로 나눕니다.
1.학생 테이블
| 학생ID | 학생이름 | 교수ID |
| 101 | 김철수 | 201 |
| 102 | 박영희 | 202 |
| 103 | 이준호 | 201 |
2. 교수 테이블
| 교수ID | 교수이름 | 교수연락처 |
| 201 | 이민호 | 010-1234-3222 |
| 202 | 정수빈 | 010-3232-2312 |
이렇게 분리하면 교수ID가 학생 테이블의 외래 키 역할을 하며, 교수이름과 교수연락처는 더 이상 학생ID와 이행적 종속 관계에 있지 않게 됩니다.
4) 보이스/코드 정규화(BCNF)
보이스/코드 정규화 (BCNF, Boyce-Codd Normal Form)는 3정규형(3NF)을 강화한 형태로, 관계형 데이터베이스 설계에서 더 강력한 규칙을 적용하는 정규화 단계입니다.
BCNF는 3정규형을 만족하면서, 모든 결정자가 후보키여야 한다는 조건을 추가로 요구합니다. 즉, 어떤 속성(속성 집합)이 다른 속성들을 결정할 때, 그 결정자가 반드시 후보키여야 한다는 것입니다. 위 그림에서 간단하게 살펴보면 후보키에 해당하지 않는 속성은 다른 속성의 결정자가 될 수 없음을 설명합니다.
- 학생-과목-교사 테이블
| 학생 | 교사 | 과목 |
| 지혜 | 박선생님 | 데이터베이스 |
| 지혜 | 김선생님 | C언어 |
| 수빈 | 박선생님 | 데이터베이스 |
| 수빈 | 이선생님 | C언어 |
다음과 같은 함수 종속이 있습니다.
- (학생, 교사) → 과목
- (학생, 과목) → 교사
- 교사 → 과목
- 후보키: (학생, 교사)와 (학생, 과목)
위 관계는 3NF를 만족하지만, 교사 → 과목이라는 함수적 종속성에서 교사가 후보키가 아니기 때문에 BCNF를 위반하고 있습니다. 즉, BCNF 조건에 따르면 결정자가 후보키여야 하지만, 여기서는 교사가 후보키가 아닙니다. 이로 인해 학생 수빈의 데이터가 삭제되면, 이선생님이 C언어를 가르친다는 정보도 사라지는 이상현상이 발생 할 수 있습니다.
- BCNF 적용
1. 테이블1 (교사-과목 테이블)교사과목
| 교사 | 과목 |
| 박선생님 | 데이터베이스 |
| 김선생님 | C언어 |
| 이선생님 | C언어 |
2.테이블2 (학생-교사 테이블)학생교사
| 학생 | 교사 |
| 지혜 | 박선생님 |
| 지혜 | 김선생님 |
| 수빈 | 박선생님 |
| 수빈 | 이선생님 |
이렇게 두 개의 테이블로 분해하면 삽입, 갱신, 삭제 이상의 문제가 해결됩니다.