이미 이전 포스팅에서 소개한 바 있는 MySQl 같은 DBMS(Database Management System)는 데이터를 관리하기 정말 편리한 기능들을 개발자나 데이터 이용자들에게 제공해준다.
하지만 특히 RDBMS(Relational Database Management System)
는 그런 데이터를 설계를 잘하여 관리하는 방법이 있다. 이것이 정규화
라는 개념이다.
관계형 데이터베이스의 설계에서 중복을 최소화하게 데이터를 구조화하는 프로세스를 정규화(Normalization)라고 한다.
데이터베이스 정규화의 목표는 이상이 있는 관계를 재구성하여 작고 잘 조직된 관계를 생성하는 것에 있다.
일반적으로 정규화란 크고, 제대로 조직되지 않은 테이블들과 관계들을 작고 잘 조직된 테이블과 관계들로 나누는 것을 포함한다.
정규화의 목적은 하나의 테이블에서의 데이터의 삽입, 삭제, 변경이 정의된 관계들로 인하여 데이터베이스의 나머지 부분들로 전파되게 하는 것이다.출처 : 위키백과 '데이터베이스 정규화'
위에는 우선 정규화에 대해서 위키백과의 정의에 대해서 다루고 있다.
나는 정규화 중에서 중요한 부분은 데이터 중복 제거와 구조화라고 생각이 든다.
정규화의 필요를 느끼기 위해서는 현재 본인이 만드는 데이터베이스가 어떤 문제가 있는지부터 알아야 한다. 지금 소개하는 데이터 간의 이상 관계를 알게 되면 문제점이 뚜렷이 나타날 것이다.
학번 | 이름 | 과목코드 | 연락처 |
---|---|---|---|
1901 | Alice | SB-03 | 010-XXXX-XXXX |
2002 | Bob | SB-04 | 010-ㅁㅁㅁㅁ-ㅁㅁㅁㅁ |
2002 | Bob | SB-05 | 010-ㅁㅁㅁㅁ-ㅁㅁㅁㅁ |
2003 | Charlie | SB-03 | 010-7777-7777 |
Alice의 수강신청 기록을 삭제했다. 하지만 졸업 필수과목이었기 때문에 학과처에서 수강 취소 연유를 묻고자 연락을 해야 한다. 하지만 연락처까지 같이 삭제되었기 때문에 조치를 못 하게 되는 경우가 생긴다. 이렇듯 삭제를 했을 때, 다른 부수 효과를 일으키는 문제를 삭제 이상이라고 한다.
학생의 학번을 기준으로 이름과 연락처를 기재하려고 한다. 하지만 위 테이블에 입력을 하기 위해서는 신청한 과목 코드를 NULL
로 처리를 해야 입력이 가능하다. 이렇듯 새로운 데이터를 입력할 때, 꼭 필요한 정보 이외의 불필요한 처리를 동반하는 문제를 입력 이상이라고 한다.
특정 학생의 연락처를 바꾸려고 한다. 위 예시에서는 특히 'Bob'의 경우를 특정할 수 있다. 한 사람의 연락처를 바꿔야 하는데, 위 테이블은 'Bob'에 해당되는 정보가 2 개여서 똑같은 수정을 두 번 실행해야 한다.
진짜 정말 기록하는데에만 의미를 두고 테이블을 생성하단면, 딱 비정규적인 테이블이 만들어질 것이다. '에드거 F. 커드'와 '레이먼드 F. 보이스'는 이러한 테이블을 정규화시키는 방법을 고안해서 제안했다.
그 중 일반적인 작업은 다음과 같다.
- 1NF(1차 정규화)
- 2NF(2차 정규화)
- 3NF(3차 정규화)
- BCNF(Boyce and Cudd Normal Form)
다음의 조건을 만족하면 된다.
결과적으로는 1:N 의 관계를 갖는 테이블 2개로 나뉘어진다.
모든 컬럼이 기본 키에 대하여 완전 함수형 종속이 되는 것이 조건이다.
함수형 종속이란 로 표현할 수 있는데, X가 바뀌면 Y는 X를 따라 다른 값을 취해야 한다. 만약 의 형태로 결정자가 추가되었는데 모든 결정자에 대해 Y가 값이 변경된다면 이때 완전 함수형 종속이고, 부분만 따른다면 부분 함수형 종속이라고 한다.
제조사와 모델 명이 결정자일 때, 제조국가는 모델 명과는 상관이 없는 속성이므로 따로 테이블을 구분해서 작성해준다.
대회명과 개최연도에 따라 우승자는 달라지지만, 대회명과 개최연도가 우승자의 생일과는 관련이 없다.
모든 결정자가 후보키 집합에 속해야한다.
후보키는 각 행을 유일하게 식별할 수 있는 최소한의 집합이다.
타입 | 등록번호 | 담당자 | 위치 |
---|---|---|---|
KICK | 114235 | Alice | 중앙로 |
KICK | 123543 | Alice | 시청 |
BIC | 114235 | Bob | 광장 |
BIC | 123543 | Bob | 시민공원 |
각 탈 것을 특정 지을 수 있는 후보키는 타입과 등록번호다. 이를 통해 고유한 한 탈 것의 위치를 찾을 수 있다. 하지만 담당자 1명이 담당하는 모델이 정해져있다고 하자. 그렇다면 담당자는 타입에 대한 결정자가될 수 있다. 이 경우에는 BCNF에 해당되지 않아 담당자의 배정 타입 관련 테이블 따로, 탈 것과 위치에 대한 테이블 따로 관리를 해야 한다.