[ 정규화 ]
- 정규화: 이상현상이 발생하는 릴레이션을 분해하여 이상현상을 없애는 과정
- 이상현상이 있는 릴레이션은 이상현상을 일으키는 함수 종속성의 유형에 따라 등급을 구분가능
- 릴레이션은 정규형 개념으로 구분하며, 정규형이 높을수록 이상현상은 줄어듬.
정규화(Normalization)의 기본 목표는 테이블 간에 중복된 데이타를 허용하지 않는다는 것
>> 무결성(Integrity)를 유지할 수 있으며, DB의 저장 용량 역시 줄일 수 있다.
즉 데이터를 쪼개서 , 최대한 중복을 줄일수 있게 설계해보는 것 >> 불필요한 데이터(data redundancy)를 제거한다.
- 불필요한 정보를 제외하며, JOIN을 통해서 원하는 정보를 가져올 수 있다는 의미
- 데이터의 정확성, 일관성, 유효성이 유지되는 것 = 무결성
- 각종 이상 현상(Anomaly) 을 방지하기 위해서, 테이블의 구성을 논리적이고 직관적 하기 위함
1) 삭제 이상 (Delete Anomaly)
튜플 삭제시 연쇄 삭제가 발생하는 현상입니다!
예를 들어 2101 학번의 홍길동 학생이 ST01 과목을 수강 취소할 경우,취소 사유를 물을 수 있는 유일한 정보인 연락처마저 잃게 되는것을 의미합니다!
비슷하게 가입정보를 삭제해버리면 = 삭제이유를 같은 테이블에 넣어놓았을때 삭제이유까지 없어져 버림
2) 삽입 이상 (Insert Anomaly)
튜플 삽입시 지정하지 않은 속성값이 NULL을 갖거나, 원하지 않는 자료가 삽입되는 현상입니다!
예를 들어 2101 학번 홍길동 학생의 연락처만 추가하고 싶을 때,과목코드가 비게되므로 NULL값을 가져 문제가 발생하게됩니다!
- 컬럼 상태값 때문에
3) 갱신 이상 Update Anomaly
데이터 갱신시 일관성 유지가 안되는 현상입니다!
예를 들어 홍길동 학생이 연락처를 바꿨을 경우,ST01, ST02 모두 갱신해야하는데 ST01만 갱신할 경우 발생하게 됩니다!
- 하나만 바꾸고 싶은데 ,,, 하나씩 찾아서 다 체크하고 바꾸어야 함
위와 같이 진행되며 보통 1NF ~ 3NF까지 진행하거나 BCNF단계까지 진행한다고 합니다!
[ 제1 정규화 ]
- 테이블이 하나의 값을 가지도록 하는것
위의 테이블에서 추신수와 박세리는 여러 개의 취미를 가지고 있기 때문에 제1 정규형을 만족하지 못하고 있다. 그렇기 때문에 이를 제1 정규화하여 분해할 수 있다. 제1 정규화를 진행한 테이블은 아래와 같다.
[ 제2 정규화 ]
제2 정규화란 제1 정규화를 진행한 테이블에 대해 완전 함수 종속 = 기본키의 부분집합이 결정자가 되어서는 안됨 = 즉, PK 가 을 만족하도록 테이블을 분해하는 것
- 제1 정규형을 만족하고, 기본키가 아닌 속성이 기본키에 완전 함수 종속일 때
함수적 종속: X의 값에 따라 Y값이 결정될 때 X -> Y로 표현하는데, 이를 Y는 X에 대해 함수적 종속 이라고 합니다.
예를 들어 학번을 알면 이름을 알 수 있는데, 이 경우엔 학번이 X가 되고 이름이 Y가 됩니다.
X를 결정자라고 하고, Y는 종속자라고 합니다 다른 말로 X가 바뀌었을 경우 Y가 바뀌어야만 한다는 것을 의미합니다.
예를들어
있으면
학생번호 겹치고 강좌이름 따로따로니까 이걸 정규화 해주면 ? (기본키는 (학생번호, 강좌이름) = 복합키 / 기본키는 성적을 결정)
학생번호 - 강좌이름 - 성적 테이블 1개
강좌이름 - 강의실 테이블 1개
이렇게 만들어주면 별도의 테이블로 관리하여 제2 정규형을 만족시킬 수 있다.
왜냐면 강의실은 성적 컬럼에 필요없기 때문에 (성질이 다름 )
[ 제3 정규화 ] - 완전 함수적 종속 관계
테이블(Relation)이 제 3정규형을 만족한다는 것은 아래 두 가지 조건을 만족하는 것을 의미하게 됩니다!
- Relation이 제 2정규화 되었다.
- 기본 키(primary key)가 아닌 속성(Attribute)들은 기본 키에만 의존해야 한다.
- 즉, 더 잘게 쪼개버리기
이런 테이블에서
[ BCNF 정규화 ]
제3 정규화를 진행한 테이블에 대해 모든 결정자가 후보키가 되도록 테이블을 분해하는 것''
즉 , 더 잘게 쪼개기
수강 테이블이 존재한다고 하자.
특강수강 테이블에서 기본키는 (학생번호, 특강이름)이다. 그리고 기본키 (학생번호, 특강이름)는 교수를 결정하고 있다. 또한 여기서 교수는 특강이름을 결정하고 있다.
그런데 문제는 교수가 특강이름을 결정하는 결정자이지만, 후보키가 아니라는 점이다. 그렇기 때문에 BCNF 정규화를 만족시키기 위해서 위의 테이블을 분해해야 하는데, 다음과 같이 특강신청 테이블과 특강교수 테이블로 분해할 수 있다.
#
참조
https://mangkyu.tistory.com/110
https://mangkyu.tistory.com/28
댓글