데이터베이스를 설계할 때 ‘정규화’는 마치 건물을 짓기 전 튼튼한 설계도를 그리는 것과 같습니다. 당장의 편의를 위해 설계 원칙을 무시하고 주먹구구식으로 건물을 올리면, 머지않아 벽에 금이 가고 물이 새는 등 심각한 하자가 발생하게 됩니다. 데이터베이스 역시 마찬가지입니다. 정규화라는 체계적인 원칙 없이 데이터를 쌓아두기만 한다면, 데이터 중복으로 인한 저장 공간 낭비는 물론, 데이터 불일치라는 치명적인 문제에 직면하게 될 것입니다.
정규화는 데이터의 중복을 최소화하고 데이터의 일관성과 무결성을 확보하기 위해, 관계형 데이터베이스의 테이블을 논리적으로 분해하는 과정입니다. 이는 단순히 데이터를 나누는 행위를 넘어, 데이터 간의 종속성을 명확히 하여 보다 합리적이고 효율적인 데이터 구조를 만드는 철학에 가깝습니다. 이 글에서는 정보처리기사 시험의 핵심 출제 범위이자, 모든 데이터 전문가가 갖춰야 할 기본 소양인 ‘정규화’에 대해 제1정규형부터 보이스-코드 정규형(BCNF)까지, 구체적인 예시와 함께 그 필요성과 원리를 깊이 있게 탐구해 보겠습니다.
정규화가 필요한 이유: 데이터 이상 현상(Anomaly)과의 싸움
정규화를 거치지 않은 테이블에서는 데이터의 중복으로 인해 예기치 않은 문제가 발생하는데, 이를 ‘이상 현상(Anomaly)’이라고 합니다. 이상 현상은 크게 삽입 이상, 갱신 이상, 삭제 이상의 세 가지 유형으로 나뉩니다. 정규화는 바로 이러한 이상 현상을 근본적으로 해결하기 위한 과정입니다.
삽입 이상 (Insertion Anomaly)
삽입 이상은 새로운 데이터를 삽입하려 할 때, 불필요한 데이터가 함께 있어야만 삽입이 가능한 문제입니다. 예를 들어, ‘학생_수강’ 테이블에 ‘학번’, ‘이름’, ‘학과’, ‘수강과목’, ‘성적’이라는 컬럼이 있다고 가정해 보겠습니다. 아직 아무 과목도 수강 신청하지 않은 신입생 ‘김정보’의 정보를 입력하려면 어떻게 해야 할까요? ‘수강과목’과 ‘성적’ 컬럼이 비어있게 되는데, 만약 ‘수강과목’이 기본키(Primary Key)의 일부라면 NULL 값을 가질 수 없으므로 ‘김정보’ 학생의 정보 자체를 삽입할 수 없게 됩니다. 이처럼 특정 데이터가 없다는 이유로 전체 데이터가 입력되지 못하는 불합리한 상황이 바로 삽입 이상입니다.
갱신 이상 (Update Anomaly)
갱신 이상은 중복된 데이터 중 일부만 수정되어 데이터의 일관성이 깨지는 문제입니다. 위의 ‘학생_수강’ 테이블에서 학생 ‘이정처’가 ‘전산학과’에서 ‘컴퓨터공학과’로 전과했다고 가정해 보겠습니다. ‘이정처’ 학생이 3과목을 수강 중이라면, 3개의 행에 걸쳐 ‘전산학과’라는 정보가 중복 저장되어 있을 것입니다. 만약 이 중 2개의 행만 ‘컴퓨터공학과’로 수정하고 1개를 실수로 누락한다면, ‘이정처’ 학생의 학과는 ‘전산학과’이면서 동시에 ‘컴퓨터공학과’인, 논리적으로 말이 안 되는 상태가 됩니다. 이처럼 데이터의 일부만 갱신되어 발생하는 불일치 현상이 갱신 이상입니다.
삭제 이상 (Deletion Anomaly)
삭제 이상은 특정 데이터를 삭제했을 때, 유지되어야 할 다른 정보까지 함께 삭제되는 문제입니다. ‘학생_수강’ 테이블에서 학생 ‘박기사’가 수강하던 ‘데이터베이스’ 과목의 수강을 철회하여 해당 행을 삭제했다고 가정해 보겠습니다. 만약 ‘박기사’ 학생이 ‘데이터베이스’ 한 과목만 수강하고 있었다면, 이 데이터를 삭제하는 순간 ‘박기사’ 학생의 ‘학번’, ‘이름’, ‘학과’ 정보까지 데이터베이스에서 완전히 사라지는 문제가 발생합니다. 수강 정보 하나를 삭제했을 뿐인데 학생 정보 자체가 소멸되는, 의도치 않은 정보의 손실이 바로 삭제 이상입니다.
이러한 세 가지 이상 현상은 모두 데이터의 ‘중복’이라는 공통된 원인에서 비롯됩니다. 정규화는 테이블을 논리적으로 분해하여 이러한 중복을 제거하고, 각 테이블이 하나의 주제에 대한 정보만을 갖도록 함으로써 이상 현상을 원천적으로 방지합니다.
정규화의 단계: 순서대로 따라 하는 데이터 구조화
정규화는 여러 단계로 구성되어 있으며, 차수가 높아질수록 더 엄격한 제약 조건을 만족해야 합니다. 일반적으로 실무에서는 제3정규형(3NF)이나 보이스-코드 정규형(BCNF)까지 정규화를 수행하는 것을 목표로 합니다. 각 정규화 단계가 무엇을 의미하는지 예시를 통해 차근차근 알아보겠습니다.
아래는 정규화를 거치지 않은 ‘수강 신청’ 테이블의 예시입니다.
[정규화 전: 수강 신청 테이블]
| 학번 | 이름 | 학과 | 수강과목코드 | 수강과목명 | 담당교수 | 성적 |
| 1001 | 김정보 | 컴퓨터공학 | CS101 | 데이터베이스 | 이교수 | A+ |
| 1001 | 김정보 | 컴퓨터공학 | CS102 | 자료구조 | 박교수 | A0 |
| 1002 | 이정처 | 전자공학 | EE201 | 회로이론 | 최교수 | B+ |
| 1003 | 박기사 | 컴퓨터공학 | CS101 | 데이터베이스 | 이교수 | B0 |
제1정규형 (1NF: First Normal Form)
제1정규형은 테이블의 모든 컬럼 값이 ‘원자값(Atomic Value)’을 갖도록 하는 것입니다. 즉, 하나의 컬럼에 여러 개의 값이 들어가지 않도록 분해하는 단계입니다. 만약 한 학생이 여러 과목을 수강한다고 해서 수강과목 컬럼에 ‘데이터베이스, 자료구조’ 와 같이 쉼표로 구분된 값을 넣는다면 제1정규형을 위배하는 것입니다. 위의 예시 테이블은 각 컬럼이 이미 하나의 값만 가지고 있으므로 제1정규형을 만족합니다. 제1정규형은 관계형 데이터베이스의 가장 기본적이고 당연한 전제 조건입니다.
제2정규형 (2NF: Second Normal Form)
제2정규형은 제1정규형을 만족하고, 기본키가 여러 컬럼으로 구성된 복합키(Composite Key)일 경우, 기본키의 일부에만 종속되는 컬럼(부분 함수 종속)을 제거하는 단계입니다.
위의 ‘수강 신청’ 테이블에서 기본키는 ‘학번’과 ‘수강과목코드’의 조합입니다. 왜냐하면 ‘학번’만으로는 어떤 과목의 성적인지 알 수 없고, ‘수강과목코드’만으로는 누가 수강했는지 알 수 없기 때문입니다.
- ‘성적’은 ‘학번’과 ‘수강과목코드’ 모두에 의해 결정되므로 완전 함수 종속입니다. (누가 어떤 과목을 들었는지 알아야 성적을 알 수 있음)
- 하지만 ‘이름’, ‘학과’는 ‘학번’에 의해서만 결정됩니다. ‘수강과목코드’와는 아무런 관련이 없습니다.
- 또한 ‘수강과목명’, ‘담당교수’는 ‘수강과목코드’에 의해서만 결정됩니다. ‘학번’과는 관련이 없습니다.
이처럼 기본키의 일부에만 종속되는 컬럼들이 존재하므로, 이 테이블은 제2정규형을 만족하지 못합니다. 이를 해결하기 위해 부분 함수 종속을 제거하여 테이블을 다음과 같이 분해합니다.
[학생 테이블]
| 학번 (PK) | 이름 | 학과 |
| 1001 | 김정보 | 컴퓨터공학 |
| 1002 | 이정처 | 전자공학 |
| 1003 | 박기사 | 컴퓨터공학 |
[과목 테이블]
| 수강과목코드 (PK) | 수강과목명 | 담당교수 |
| CS101 | 데이터베이스 | 이교수 |
| CS102 | 자료구조 | 박교수 |
| EE201 | 회로이론 | 최교수 |
[수강 테이블]
| 학번 (FK) | 수강과목코드 (FK) | 성적 |
| 1001 | CS101 | A+ |
| 1001 | CS102 | A0 |
| 1002 | EE201 | B+ |
| 1003 | CS101 | B0 |
이제 ‘학생’ 정보, ‘과목’ 정보, ‘수강’ 정보가 각각의 주제에 맞게 분리되었습니다. ‘이름’이나 ‘학과’를 수정하고 싶으면 ‘학생’ 테이블에서 한 번만 수정하면 되고, 과목 담당 교수가 바뀌어도 ‘과목’ 테이블에서 한 번만 수정하면 됩니다. 갱신 이상의 문제가 해결되었습니다.
제3정규형 (3NF: Third Normal Form)
제3정규형은 제2정규형을 만족하고, 기본키가 아닌 다른 컬럼에 의해 결정되는 컬럼(이행적 함수 종속)을 제거하는 단계입니다. 즉, 기본키에 직접 종속되지 않고, 일반 컬럼을 거쳐 간접적으로 종속되는 관계를 없애는 것입니다.
만약 ‘학생’ 테이블에 ‘학과’와 함께 ‘학과사무실_전화번호’라는 컬럼이 추가되었다고 가정해 보겠습니다.
[수정된 학생 테이블 (제2정규형 만족)]
| 학번 (PK) | 이름 | 학과 | 학과사무실_전화번호 |
| 1001 | 김정보 | 컴퓨터공학 | 02-111-1111 |
| 1002 | 이정처 | 전자공학 | 02-222-2222 |
| 1003 | 박기사 | 컴퓨터공학 | 02-111-1111 |
여기서 ‘학과사무실_전화번호’는 기본키인 ‘학번’에 의해 결정되는 것이 아니라, 일반 컬럼인 ‘학과’에 의해 결정됩니다. (학번 -> 학과 -> 학과사무실_전화번호). 이것이 바로 이행적 함수 종속입니다. 이 경우 컴퓨터공학과의 전화번호가 바뀌면 컴퓨터공학과 소속의 모든 학생 데이터를 일일이 수정해야 하는 갱신 이상의 문제가 발생합니다.
제3정규형을 만족시키기 위해 이행적 함수 종속을 제거하여 다음과 같이 테이블을 분리합니다.
[학생 테이블 (3NF)]
| 학번 (PK) | 이름 | 학과 (FK) |
| 1001 | 김정보 | 컴퓨터공학 |
| 1002 | 이정처 | 전자공학 |
| 1003 | 박기사 | 컴퓨터공학 |
[학과 테이블]
| 학과 (PK) | 학과사무실_전화번호 |
| 컴퓨터공학 | 02-111-1111 |
| 전자공학 | 02-222-2222 |
이렇게 분해하면 학과 정보는 ‘학과’ 테이블에서 유일하게 관리되므로 데이터의 일관성을 유지하기가 훨씬 수월해집니다.
보이스-코드 정규형 (BCNF: Boyce-Codd Normal Form)
BCNF는 제3정규형보다 더 강화된 정규형으로, 모든 결정자(Determinant)가 후보키(Candidate Key)인 상태를 의미합니다. 조금 더 쉽게 말해, 테이블에서 어떤 컬럼을 결정하는 모든 ‘결정자’들이 기본키 역할을 할 수 있을 만큼의 유일성을 가져야 한다는 뜻입니다. 제3정규형까지 만족하는 대부분의 테이블은 BCNF도 만족하지만, 복잡한 종속 관계를 가지는 일부 특수한 경우에 BCNF 위반이 발생할 수 있습니다.
예를 들어, ‘특강_신청’ 테이블에 ‘학번’, ‘특강명’, ‘담당교수’ 컬럼이 있고, 다음과 같은 제약 조건이 있다고 가정해 봅시다.
- 기본키는 ‘학번’과 ‘특강명’의 조합이다.
- 교수 한 명은 오직 하나의 특강만 담당할 수 있다. (즉, ‘담당교수’가 ‘특강명’을 결정한다.)
[특강_신청 테이블]
| 학번 (PK) | 특강명 (PK) | 담당교수 |
| 1001 | 데이터베이스 | 김교수 |
| 1002 | 알고리즘 | 박교수 |
| 1003 | 데이터베이스 | 김교수 |
이 테이블에서 ‘담당교수’는 ‘특강명’을 결정하는 결정자입니다. 하지만 ‘담당교수’는 이 테이블의 기본키(또는 후보키)가 아닙니다. 이것이 바로 BCNF 위반입니다. 이 경우, 특정 교수가 담당 과목을 변경하면 불일치 문제가 발생할 수 있습니다. BCNF를 만족시키려면 이 종속 관계를 분리해야 합니다.
[수강생_교수 테이블]
| 학번 (FK) | 담당교수 (FK) |
| 1001 | 김교수 |
| 1002 | 박교수 |
| 1003 | 김교수 |
[교수_특강 테이블]
| 담당교수 (PK) | 특강명 |
| 김교수 | 데이터베이스 |
| 박교수 | 알고리즘 |
이렇게 분해함으로써 모든 결정자(‘담당교수’)가 후보키가 되어 BCNF를 만족하게 됩니다.
결론: 정규화, 성능과 타협하는 지혜로운 균형점 찾기
정규화는 데이터의 중복을 제거하고 이상 현상을 방지하여 데이터의 무결성과 일관성을 확보하는 가장 강력하고 기본적인 방법입니다. 잘 정규화된 데이터베이스는 유지보수가 용이하며, 데이터 구조의 확장에 유연하게 대처할 수 있는 장점을 가집니다. 정보처리기사 시험을 준비하는 수험생이라면 각 정규형의 개념과 부분/이행적 함수 종속 관계를 명확히 이해하고 테이블을 분해하는 과정을 반드시 숙지해야 합니다.
하지만 정규화가 항상 정답인 것은 아닙니다. 정규화 수준이 높아질수록 테이블이 잘게 분해되기 때문에, 원하는 데이터를 얻기 위해 여러 테이블을 조인(Join)해야 하는 경우가 많아집니다. 이는 조회(SELECT) 성능의 저하를 유발할 수 있습니다. 따라서 대규모의 읽기 작업이 빈번하게 발생하는 시스템이나, 빠른 응답 속도가 매우 중요한 서비스에서는 의도적으로 정규화 수준을 낮추거나 중복을 허용하는 ‘반정규화(Denormalization)’를 적용하기도 합니다.
결론적으로, 성공적인 데이터베이스 설계는 정규화 원칙을 맹목적으로 따르는 것이 아니라, 데이터의 무결성과 시스템의 성능 사이에서 현명한 균형점을 찾는 것입니다. 서비스의 특징, 데이터의 흐름, 사용자의 요구사항을 종합적으로 고려하여 최적의 정규화 수준을 결정하는 능력이 바로 데이터 전문가에게 요구되는 핵심 역량이라 할 수 있습니다.