데이터 이상과 정규화를 공부하는 과정을 정리합니다.
"누가 DB 설계를 저렇게 해~?" 라고 생각하기도 했지만, 관계형 데이터베이스에서 중복성과 무결성을 강조하는 이유를 이해햐기 좋은 계기가 되었습니다.
💡 데이터 이상(data anomaly)
데이터 이상은 잘못된 DB 설계 과정에서 불필요한 데이터 중복으로 인해 발생하는 부작용을 말한다.
먼저 아무 생각 없이 릴레이션을 짰을 때 무슨 문제가 생기는지 알아보자.
여기 Student 릴레이션이 있다.
학번(PK) | 이름 | 학과 | 위치 | 나이 |
170 | 원석 | 컴퓨터 | 304호 | 27 |
180 | 영두 | 컴퓨터 | 304호 | 24 |
얼핏 보면 별 문제 없어보이고 검색(SELECT)까지만 해도 전혀 문제가 없다.
그러나 삽입, 갱신, 삭제시에 치명적인 문제가 발생한다.
삽입 이상
: 불필요한 데이터나 거짓 데이터를 함께 입력하지 않고서는 원하는 데이터의 입력이 불가능한 상황.
신생 학과로 알고리즘 학과와 그 사무실이 생긴 상황을 가정해보자.
(’알고리즘’, ‘ICT 대학 306호’)라는 정보를 릴레이션에 추가해야 하는데, 릴레이션의 PK인 학번 의 값이 비어있게 된다. 기본키의 값은 NULL이 될 수 없기 때문에, 억지로 학번 에 거짓 정보를 넣거나 거짓 학생을 넣어서라도 강제 삽입해야 한다.
갱신 이상
: 중복된 속성 값 중 일부가 수정되지 않을 경우 생기는 데이터 불일치
컴퓨터 SW 학과의 사무실 위치가 501호로 바뀐 경우를 가정해보자.
학과가 ‘컴퓨터SW’인 튜플 모두를 빠짐없이 갱신해야 한다(이미 여기서부터 비효율적). 게다가 만약 DB 관리자의 실수로 ‘원석’ 튜플만 갱신했다면, ‘영두’ 튜플의 학과 위치는 여전히 ‘304호’로 남게 되고 이는 ‘원석’ 튜플의 학과 위치 정보와 불일치하게 된다.
삭제 이상
: 원하지 않는 유용한 데이터까지 함께 삭제되어 데이터 손실이 발생할 수 있는 상황
‘성욱’ 튜플이 사라지는 경우(!)를 가정해보자. 학번 181 인 튜플을 찾아 삭제하게 되는데, 정보보호학과의 과 사무실 위치가 ‘303호’라는 유용한 정보도 함께 삭제된다.
💡 정규화의 개념
기본적으로 연관성을 갖는 속성끼리 그룹화해서 하나의 릴레이션으로 구성하는게 바람직하다.
정리해보면, 속성 사이의 많은 연관 관계를 무리하게 하나의 릴레이션으로 우겨넣을 때 이상 현상이 발생한다. 이를 방지하기 위해 속성 사이의 연관 관계(함수 종속성, dependency)를 분석한 뒤에 단계적으로 릴레이션을 분해하는 과정인 정규화가 필요하다.
- 중복성 최소화
- 데이터 모형 단순화
- 일관성, 정확성 보장
- 유연한 데이터 구축
- 조인 연산 비용 증가 (조회 성능 저하)
💡 정규형(Normal Form)
: 정규화 과정에서 릴레이션이 만족해야 하는 특정한 함수 종속성의 충족 조건
❗정규화는 함수 종속성 개념이 가장 중요하다.
제1정규형(1NF)
: 어떤 릴레이션에 속한 모든 속성들의 도메인이 원자값만을 가지는 정규형 (속성당 하나의 값만)
학번 | 이름 | 학과 | 위치 |
180 | 영두 | 컴퓨터SW, 경영 | 304호, 606호 |
181 | 성욱 | 정보보호 | 303호 |
속성 하나에 복수의 값이 들어간다면 애초에 릴레이션의 정의에 위배된다. 여기선 학과 속성을 ‘주전공’, ‘복수전공’으로 쪼개서 해결할 수 있다.
학번 | 이름 | 주전공 | 복수전공 | 주전공 위치 | 복수전공 위치 |
180 | 영두 | 경영 | 컴퓨터SW | 304호 | 606호 |
181 | 성욱 | 정보보호 | NULL | 303호 | NULL |
하지만 여전히 데이터의 중복은 그대로다.
제2정규형(2NF)
: 1NF를 만족하고, 부분 함수 종속을 제거하여 기본키외의 모든 속성이 기본키에 완전 함수 종속인 정규형
즉, 기본키에 속한 모든 속성 값(결정자)을 통해서만 일반 속성들을 결정할 수 있음을 의미한다. 기본키를 이루는 속성이 딱 하나라면 이미 만족된 것.
아래는 각 수업의 수강기록을 나타내는 CourseRecord 릴레이션이다. 기본키는 {학번, 과목번호} 조합이다.
학번 | 과목번호 | 강의 학점 | 교수 |
180 | a001 | C | 딜립 쿠말 |
181 | a002 | C++ | 양수미 |
‘학점’은 {학번, 과목번호} 조합을 통해서만 결정되므로 완전 함수 종속이다.
반면 ‘강의 교수’ 속성은 기본키의 일부인 ‘과목번호’ 속성만으로 결정되므로 부분 함수 종속이다. 따라서 위 릴레이션은 제 2정규형 조건을 충족하지 못한다.
두 릴레이션으로 쪼갠 다음, ‘강의 교수’를 Cource 릴레이션으로 보내면 해결된다.
학번 | 과목번호 | 학점 |
180 | a001 | C |
181 | a002 | C++ |
과목번호 | 강의 교수 |
a001 | 딜립 쿠말 |
a002 | 양수미 |
제3정규형(3NF)
: 2NF를 만족하고, 이행적 함수 종속을 제거하는 정규형.
기본키가 아닌 다른 속성이 결정자인지를 검사한다. 만약 일반 속성끼리 직접적으로 종속적인 관계를 갖고 있다면 제3정규형에 위배된다.
학번 | 이름 | 주전공 | 복수전공 | 주전공 위치 | 복수전공 위치 |
180 | 영두 | 경영 | 컴퓨터 | 304호 | 606호 |
181 | 성욱 | 정보보호 | NULL | 303호 | NULL |
‘주전공 위치’, ‘복수전공 위치’는 각각 ‘주전공’, ‘복수전공’에 종속적이다. 학번 → 주전공 → 주전공 위치 형태.
두 릴레이션으로 쪼개면 해결된다.
학번 | 이름 | 주전공_ID | 복수전공_ID |
180 | 영두 | 9 | 2 |
181 | 성욱 | 1 | NULL |
ID | 이름 | 사무실 위치 |
1 | 정보보호 | 303호 |
2 | 컴퓨터SW | 304호 |
9 | 경영 | 606호 |
BCNF
모든 결정자가 key (PK 혹은 후보키) 인 정규형.
❗우리가 아무 생각 없이 쓰던 auto increment id 값을 씀으로써 BCNF까지 지키게 된다. 결정자가 key이므로
참고 자료
데이터베이스의 정석 - 박성진
https://www.geeksforgeeks.org/introduction-of-database-normalization/
'CS > DB' 카테고리의 다른 글
[DB] MySQL EXPLAIN 쿼리 실행 계획 분석 방법 (1) | 2023.09.24 |
---|---|
[DB 기초] 조인(JOIN) (0) | 2023.09.12 |
[DB 기초] 트랜잭션 (0) | 2023.03.12 |
[DB 기초] DB 인덱스(index) (0) | 2023.03.03 |
[DB 기초] 테이블(Table)과 키(Key), 제약조건(Constraint) (0) | 2023.02.08 |