[데이터베이스] 정규화 (Normalization)

데이터베이스 정규화란, 관계형 데이터베이스의 설계에서 중복을 최소화하고 무결성을 향상시키는 증 여러 목적을 달성하기 위해 데이터를 구조화하는 프로세스를 말한다. 좀 더 이론적으로 접근해보면 함수적 종속성을 이용해서 연관성있는 속성들을 분류하고, 각 릴레이션들에서 이상 현상(Anomaly) 이 생기지 않도록 하는 과정을 말한다.

 

[그럼 데이터베이스를 정규화하는 이유는 무엇일까?]

한 릴레이션(테이블)에서 여럴 엔티티의 애트리뷰트들을 혼합하게 되면 정보가 중복 저장되며, 저장 공간을 낭비하게 된다. 또한, 중복된 정보로 인해 이상 현상(Anomaly)이 발생하게 된다. 동일한 정보를 한 릴레이션에서는 변경하고, 나머지 릴레이션에서는 변경하지 않는 경우 어느 것이 정확한 값인지 알 수 없게 되는 것이다. 이러한 문제를 해결하기 위해 정규화 과정을 거치는 것이다.

이상 현상의 종류에는 어떠한 것들이 있을까?

• 갱신 이상 (Modification Anomaly)

  정확하지 않거나 일부의 튜플만 갱신되어 정보가 모호해지거나 일관성이 없어져 정확한 정보 파악이 되지 않는 문제점을 말한다.

• 삽입 이상 (Insertion Anomaly)

  원하지 않는 자료가 삽입된다든지, 삽입하는데 자료가 부족해 삽입이 되지 않아 발생하는 문제점을 말한다.

• 삭제 이상 (Deletion Anomaly)

  하나의 자료만 삭제하고 싶지만, 그 자료가 포함된 튜플 전체가 삭제되어서 원하지 않는 정보 손실이 발생하는 문제점을 말한다.

정규화는 구체적으로는 불만족스러운 나쁜 릴레이션의 애트리뷰트들을 나누어서 좋은 작은 릴레이션으로 분해하는 작업을 말한다. 정규화 과정을 거치게 되면 정규형을 만족하게 된다. 정규형이란 특정 조건을 만족하는 릴레이션의 스키마의 형태를 말하며, 제 1 정규형, 제 2 정규형, 제 3 정규형, 등등이 존재한다.

 

'나쁜' 릴레이션은 어떻게 파악할까?

엔티티를 구성하고 있는 애트리뷰트 간의 함수적 종속성(Functional Dependency)을 판단한다. 판단된 함수적 종속성은 좋은 릴레이션 설계의 정형적 기준으로 사용된다. 즉, 각각의 정규형마다 어떠한 함수적 종속성을 만족하는 지에 따라 정규형이 정의되고, 그 정규형을 만족하지 못하는 정규형을 나쁜 릴레이션으로 파악한다.

 

그럼 또 함수적 종속성이란 무엇일까?

애트리뷰트 데이터들의 의미와 애트리뷰트들 간의 상호 관계로부터 유도되는 제약 조건의 일종이다. X 와 Y를 임의의 애트리뷰트 집합이라고 할 때, X의 값이 Y의 값을 유일하게(unique) 결정한다면, X는 Y를 함수적으로 결정한다. 라고 한다. 함수적 종속성은 실세계에서 존재하는 애트리뷰드들 사이의 제약조건으로부터 유도된다.

 

[제 1 정규형]

릴레이션에 속한 모든 속성의 도메인이 원자값으로만 구성되어 있는 경우 제 1 정규형에 속한다고 한다. 쉽게 말하면 각각의 레코드(튜플)는 애트리뷰트의 값으로 하나만 가져야 한다는 의미이다. 예를 들어 다음과 같은 릴레이션은 1NF 을 만족하지 않는다.

id	name	class	score
200123	국수	국어, 수학, 영어	100, 70, 80

관계형 데이터베이스에서의 릴레이션은 모든 속성이 원자값을 가지는 특성이 있기 때문에, 최소한 1NF을 만족해야 릴레이션이 될 자격이 있다. 따라서 위의 릴레이션이 1NF을 만족하기 위해서는 다음과 같이 레코드를 분리해야 한다.

id	name	class	score
200123	국수	국어	100
200123	국수	수학	70
200123	국수	영어	80

 

[제 2 정규형]

제 1 정규형에 속하면서, 테이블의 모든 칼럼이 완전 함수적 종속을 만족하는 경우 제 2 정규형에 속한다고 한다. 기본키중에서 특정 칼럼에만 종속된 칼럼(부분적 종속)이 없어야 한다는 의미이다.

아래의 테이블을 한번 봐보자.

 

학번	과목 코드	성적	학부	등록금
200123	CSE11101	A+	컴퓨터학부	350
200123	CSE22202	A	컴퓨터학부	350
200123	CSE33303	B+	컴퓨터학부	350
190125	MEC01111	F	경영학부	300
180012	POD03303	C+	기계공학부	400
170003	CSE11102	D	컴퓨터학부	350

 

위의 테이블에 대한 함수적 종속성을 살펴보면 다음과 같다.

{학번, 과목 코드} -> 성적

{학번, 과목 코드} -> 학부

{학번, 과목 코드} -> 등록금

학번 -> 학부

학번 -> 등록금

학부 -> 등록금

학번 -> 학부, 학번 -> 등록금 이렇게 두 개의 부분 함수 종속성을 제거하는 것이 바로 제 2 정규화이다.

학번, 학부, 등록금 애트리뷰트를 갖는 학생 테이블과 학번, 과목 코드, 성적 애트리뷰트를 갖는 성적 테이블 둘로 나누어 주면 될 것이다.

학번 -> 학부 함수 종속성을 봤을 때, 학번만으로 학부에 대한 결정을 지을 수 있다. 그러나 현재 기본키가 학번과 과목 코드로 이루어져 있기 때문에 학번만으로 학부를 결정지을 수 있다는 게 의미가 없다. 그래서 이를 가능토록 해주는 과정이 제 2 정규화 과정인 것이다.

 

학생 테이블

학번	학부	등록금
200123	컴퓨터학부	350
190125	경영학부	300
180012	기계공학부	400
170003	컴퓨터학부	350

 

성적 테이블

학번	과목 코드	성적
200123	CSE11101	A+
200123	CSE22202	A
200123	CSE33303	B+
190125	MEC01111	F
180012	POD03303	C+
170003	CSE11102	D

 

이렇게 테이블이 둘로 분해되면서 학부와 등록금에 대한 중복 항목이 제거되었다. 그런데 정규화 과정에서 주의해야할 점은 정규화를 통해 분해된 테이블들이 조인을 통해서 원래의 구조로 복원될 수 있어야 한다는 점이다.

두 테이블 모두 제 1 정규형에 속하고, 기본키가 아닌 모든 속성이 기본키에 완전 함수 종속되므로 이제 제 2 정규형까지 만족한다고 할 수 있겠다.

 

그렇다면 제 2 정규형을 만족하면 이상 현상이 없어질까?

놉

• 삽입 이상

  새로운 학부가 생기는 경우 등록된 학생이 없다면 학번 속성이 NULL이 되므로 삽입할 수 없다.

• 갱신 이상

  컴퓨터학부의 등록금이 400으로 오르는 경우, 200123과 170003 모두 갱신하지 않으면 데이터 불일치 문제가 발생한다.

• 삭제 이상

  180012 학생이 자퇴하면 기계공학부에 대한 정보가 함께 사라진다.

제 2 정규형에서도 이상 현상이 발생하는 이유는 바로 이행적 함수 종속이 존재하기 때문이다. 이러한 이행적 함수 종속을 없애주는 과정이 바로 제 3 정규화이다.

 

[제 3 정규형]

제 2 정규형에 속하면서, 기본키가 아닌 모든 속성이 기본키에 이행적 함수 종속이 되지 않는 경우 제 3 정규형에 속한다고 한다.

 

그럼 또 또 이행적 함수 종속은 뭘까??

이행적 함수 종속은 쉽게 생각해보자면.. 삼단논법같은 관계를 가진 함수 종속이다. X, Y, Z에 대해 X -> Y이고, Y -> Z 이면 X -> Z 가 성립한다. 이때 Z가 X에 이행적으로 함수 종속되었다고 한다.

학생 테이블에서의 함수적 종속성을 살펴 보자.

학번 -> 학부

학부 -> 등록금

학번 -> 등록금

이걸 둘로 분리하면 된다. 그럼 학생 테이블과 학부 테이블이 생길 것이다.

 

학생 테이블

학번	학부
200123	컴퓨터학부
190125	경영학부
180012	기계공학부
170003	컴퓨터학부

 

학부 테이블

학부	등록금
컴퓨터학부	350
경영학부	300
기계공학부	400

 

그럼, 제 3 정규형을 만족하면 이상 현상이 없어질까?

아직 아니다.

지금까지 살펴본 테이블들은 기본키가 될 수 있는 후보키가 하나밖에 없었다. 하지만 후보키를 여러 개를 갖고 있는 테이블에서는 제 3 정규형을 만족하더라도 이상 현상이 생길 수 있다.

이를 해결하기 위한 정규형이 BCNF(Boyce-Codd Normal Form) 이다. 제 3 정규형보다 조금 더 엄격한 제약 조건을 가지기 때문에 Strong 3NF라고도 한다.

 

[BCNF]

제 3 정규형을 만족하면서 모든 결정자가 후보키 집합에 속한 경우에 BCNF에 속한다고 할 수 있다. 아래와 같은 경우를 살펴 보자.

학생	과목	교수	성적
1	AB123	김교수	A
2	CS123	박교수	A
3	CS123	박교수	A

 

후보키는 슈퍼키중에서 최소성을 만족하는 건데, 이 경우에는 {학생, 과목}이 된다. {학생, 과목}은 그 레코드를 유일하게 구분할 수 있다. 그런데, 이 테이블의 경우에는 교수(한 교수가 한 과목만 강의할 수 있다고 가정)가 결정자가 된다. 즉, 교수가 정해지면 과목이 결정되는 것이다. 그런데 교수는 후보키가 아니기 때문에 이 경우에는 BCNF를 만족하지 못한다.

위와 같이 테이블이 구성되어 있는 경우, 데이터가 중복되고 갱신 이상이 발생할 수 있다. 예를 들어 박교수가 강의하는 과목의 이름이 바뀌었다면 두 개의 레코드를 갱신해야 한다. 이를 해결하기 위해 마찬가지로 테이블을 분리하면 된다.

 

교수 테이블

교수	과목
김교수	AB123
박교수	CS123

 

수강 테이블

학생	과목	성적
1	AB123	A
2	CS123	A
3	CS123	A

 

 

 

 

 

Reference

https://yaboong.github.io/database/2018/03/09/database-normalization-1/

https://3months.tistory.com/193

https://github.com/JaeYeopHan/Interview_Question_for_Beginner/tree/master/Database#%EC%A0%95%EA%B7%9C%ED%99%94%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C