10. 데이터베이스 정규화(Normalization) 이상 현상부터 제1~3정규형까지

1. 정규화(Normalization)의 정의

정규화(Normalization)는 관계형 데이터베이스 설계에서 데이터의 중복을 최소화하고 구조를 종속성에 맞게 분해하여 데이터 무결성을 보장하는 과정입니다.

쉽게 말해, 하나의 큰 테이블에 무작위로 섞여 있는 정보들을 연관성 있는 항목끼리 쪼개어 여러 개의 작은 테이블로 깔끔하게 정리 정돈하는 규칙입니다.

2. 정규화가 필요한 이유

테이블을 정규화하지 않고 모든 정보를 하나의 표에 몰아서 저장하면, 데이터를 추가하거나 고칠 때 데이터가 꼬이거나 손실되는 이상 현상(Anomaly)이 발생합니다. 정규화는 이 문제를 해결합니다.

실제 개발에서 해결하는 이상 현상 3가지

• 삽입 이상 (Insertion Anomaly): 새 데이터를 넣으려고 할 때, 원하지 않는 불필요한 정보까지 억지로 함께 입력해야만 저장이 가능한 현상입니다. (예: 새로운 강의 코드가 생겼는데, 수강하는 학생이 아직 없어 학번 칸을 채우지 못해 강의 등록을 못 하는 경우)

• 삭제 이상 (Deletion Anomaly): 특정 데이터를 지울 때, 그 데이터와 연동되어 보존되어야 할 다른 유용한 정보까지 강제로 같이 지워지는 현상입니다. (예: 어떤 학생이 수강을 취소해서 수강 내역을 지웠더니, 그 과목의 교수 이름과 강의실 정보까지 데이터베이스에서 영원히 사라지는 경우)

• 수정 이상 (Update Anomaly): 중복된 데이터 중 일부만 수정하고 일부는 누락하여, 같은 항목에 서로 다른 값이 공존하게 되는 데이터 불일치 현상입니다. (예: 홍길동의 전화번호가 바뀌어 주문 내역 1건만 수정하고 나머지 5건은 그대로 두어 시스템이 홍길동의 실제 번호를 오인하는 경우)

3. 반드시 알아야 할 핵심 개념

정규화는 단계별로 진행되며, 초보자가 반드시 알아야 할 기본 3단계 규칙입니다.

• 제1정규형 (1NF): 테이블의 모든 열(Column)은 단 하나의 값(원자값)만 가져야 한다는 규칙입니다. 한 칸에 두 개 이상의 데이터가 쉼표로 묶여 들어가면 안 됩니다.

• 제2정규형 (2NF): 제1정규형을 만족하면서, 기본키가 아닌 일반 열들이 기본키의 일부가 아닌 '전체'에만 종속되어야 한다는 규칙입니다. 복합키(두 개 이상의 키가 합쳐진 기본키)를 쓸 때 주로 발생합니다.

• 제3정규형 (3NF): 제2정규형을 만족하면서, 기본키가 아닌 일반 열들끼리 서로를 참조하는 종속 관계(이행적 종속)를 가지면 안 된다는 규칙입니다.

4. 함께 알아야 하는 주변 기초 개념

• 함수적 종속성 (Functional Dependency): 어떤 열 A의 값을 알면 다른 열 B의 값을 유일하게 확인할 수 있을 때, 'B는 A에 함수적으로 종속된다'고 합니다. 학번(A)을 알면 이름(B)을 무조건 알 수 있는 관계가 대표적입니다.

• 역정규화 (Denormalization / 반정규화): 정규화를 거쳐 테이블을 너무 많이 쪼개놓으면 데이터를 읽을 때마다 과도한 조인(JOIN)이 일어나 속도가 느려집니다. 이를 해결하기 위해 성능 향상을 목적으로 의도적으로 정규화 규칙을 깨고 데이터를 다시 통합하는 실무 기법입니다.

5. 정규화의 실제 처리 흐름

잘못 설계된 원본 테이블을 정규화 단계를 밟아가며 분해하는 논리적 과정입니다.

1. 비정규 테이블 분석: 데이터 한 칸에 쉼표로 여러 값이 들어있거나 중복이 심한 원본 테이블을 찾아냅니다.

2. 제1정규화 진행: 여러 개 들어있는 데이터를 한 줄씩 모두 쪼개어 단일 값으로 바꿉니다.

3. 제2정규화 진행: 복합키 테이블에서 특정 키에만 붙어 다니는 독립된 속성들을 별도 테이블로 독립시킵니다.

4. 제3정규화 진행: 일반 열들끼리 원인과 결과 관계를 가지는 항목(예: 우편번호와 주소)을 찾아내어 분리합니다.

6. 정규화 단계별 테이블 변환 예시

초보자가 가장 헷갈려하는 제2정규형과 제3정규형의 변환 과정을 실제 데이터를 가진 표로 시각화하여 설명합니다.

■ 제2정규형(2NF) 대상과 해결 예시

아래는 제1정규형(원자값)은 만족하지만, 제2정규형을 위반한 테이블입니다. 복합키(학번+과목코드)를 기본키로 사용하고 있습니다.

[문제점 분석]: 기본키 전체(학번+과목코드)가 아니라, 기본키의 일부인 '과목코드' 하나에만 강의실 정보가 결정되는 부분 함수적 종속 현상이 발생했습니다. 이 때문에 CS101 과목의 강의실이 바뀌면 모든 학생의 행을 일일이 수정해야 하는 '수정 이상'이 생깁니다.

[제2정규형 해결]: 부분 종속을 제거하기 위해 테이블을 [수강 레포트]와 [과목 정보] 2개로 분리합니다.

[분리 후 1] 수강 레포트 테이블

[분리 후 2] 과목 정보 테이블

■ 제3정규형(3NF) 대상과 해결 예시

아래는 제2정규형은 만족하지만(복합키가 없음), 제3정규형을 위반한 테이블입니다.

[문제점 분석]: 기본키인 사원번호가 부서코드를 결정하고, 그 부서코드가 다시 부서명을 결정하는 이행적 함수 종속(A → B → C) 상태입니다. 이 때문에 'D02 영업팀'이라는 부서를 새로 만들었을 때, 발령받은 사원이 아직 없다면 사원번호(PK) 칸이 비어있게 되어 부서 자체를 등록하지 못하는 '삽입 이상'이 발생합니다.

[제3정규형 해결]: 일반 열끼리 종속되는 연결고리를 끊기 위해 테이블을 [사원 정보]와 [부서 정보] 2개로 분리합니다.

[분리 후 1] 사원 정보 테이블

[분리 후 2] 부서 정보 테이블

7. 예시 변환 구조 상세 설명

• 제2정규화의 효과: 과목코드와 강의실을 별도 테이블로 완전히 떼어냈습니다. 이제 과목의 강의실이 변경되더라도 '과목 정보' 테이블의 단 한 줄만 수정하면 되므로 데이터 불일치(수정 이상)의 위험이 완벽하게 가십니다.

• 제3정규화의 효과: 주종 관계를 형성하던 부서명 열을 부서코드와 함께 독립시켰습니다. 이제 새로 신설된 'D02 영업팀' 부서를 사원 등록 여부와 상관없이 미리 안전하게 입력(삽입 이상 해결)할 수 있게 됩니다.