들어가며
잊고 있던 정규화 과정을 다시한번 기억해보며 ..
회사에서는 2단계 이상하면 많이한거랬나.. 3단계였나 기억이안나네
정규화 과정
릴레이션 (테이블) 간 잘못된 종속 관계로 DB 이상현상이 발생한다.
이를 해결하거나 저장공간을 효율적으로 사용하기 위해 릴레이션을 여러개로 분리하는 과정이다.
DB 이상현상이란 ?
삭제 이상
- 내가 원하는 값만 테이블에서 삭제하고 싶은데, 하나의 튜플이 삭제를 원하지 않는 속성값도 갖고 있기에 같이 지워져서 발생하는 문제
삽입 이상
- 내가 원하는 값만 테이블에 삽입하고 싶은데, 테이블에 필요하지 않은 필드들 때문에 원치 않는 필드의 값도 삽입해야 하는 경우 발생하는 문제
- ex) null
수정 이상
- 투플 수정 시 중복된 데이터의 일부만 수정되어 데이터의 불일치 문제가 일어나는 문제
제 1 정규형
- 릴레이션의 모든 속성 값(도메인원자값)이 원자값을 가지면 제 1 정규형
- 비정규형 → 1정규형
발생할 수 있는 문제점
- 삽입 이상 : 학생이 추가될 경우 수강명, 성취도를 무조건 입력하여야한다.
- 삭제 이상 : 홍철 학생이 프런트 특강을 제거하면 해당 과목에 대한 정보가 사라진다.
- 갱신 이상 : 1번 학생이 수강명을 변경할 경우 다 바뀐다.
제 2 정규형
- 릴레이션이 제 1 정규형이며 부분함수 종속성을 제거한 형태이다. → 완전함수 종속이다.
-
- X의 값을 알면 Y의 값을 바로 식별할 수 있고, X의 값에 Y의 값이 달라질 때, Y는 X에 함수적 종속
- 기본키가 여러 속성으로 구성되어 있을경우 기본키를 구성하는 모든 속성이 포함된 기본키에 종속된 경우완전 함수 종속
-
맨위 그림은 {유저 ID, 수강명} 이라는 기본키를 사용한다.
성취도 라는 컬럼은 {유저번호, 수강명} 이라는 대체키라는 기본키가 아닌 속성에 종속될 수 있기 때문에 제거해준다.
아래 그림은 {유저 ID, 수강명} 이라는 기본키를 사용하는데, 성취도 라는 컬럼은 {유저ID, 수강명}이라는 기본키에 종속되기에 완전함수 종속이라고 할 수 있다.
- 삽입 이상 : 수강만 했을 시점에는 성취도도 꼭 같이 삽입해주어야한다.
- 삭제 이상 : 홍철이 사라지면 수강과목이 사라진다.
- 갱신 이상 : ?
기본키에 대해 부분적으로 종속되는 속성들을 제거하여 데이터 중복성을 제거한다. 따라서 기본키 이외에 값으로 종속적인 속성이 없다.
제 3 정규형
제 2 정규형이고, 기본키가 아닌 모든 속성이 이행적 함수 종속을 만족하지 않는 상태를 의미한다.
- 이행적 함수 종속
- A→B , B→C 이면 A→C 이다. C가 A에 이행적 함수 종속이다.
위의 이미지는 홍철 → 플래티넘, 플래티넘 → 30% 면 홍철 → 30%이므로 이행적 함수 종속이다.
유저 ID라는 기본키가 등급을, 등급이라는 기본키가 할인율을 결정한다.
기본키 이외의 속성이 그 외 다른 속성을 결정할 수 없다.
이를 분리하여 이행적 함수 종속 아니도록 한다.
속성 X가 동일한 값을 가지면 Y와 Z도 강제로 같은 값을 가져야되는 중복 데이터가 발생한다.
- 삽입 이상 : 이행적 함수 종속이 있는 경우, 삽입 시에 종속된 속성들의 값을 함께 입력해야 한다.
- 갱신 이상: 이행적 함수 종속이 있는 경우, 갱신 작업 시 종속된 속성들을 함께 업데이트하지 않으면 데이터의 불일치가 발생합니다. 한 속성만 갱신하면 다른 종속 속성들과 일치하지 않는 데이터가 되는 문제가 발생할 수 있다.
- 삭제 이상: 이행적 함수 종속이 있는 경우, 특정 데이터를 삭제할 때 종속된 다른 데이터들도 함께 삭제해야만 데이터베이스의 무결성이 유지된다. 따라서 원하지 않는 데이터 손실이 발생한다. 마스터 삭제시 할인율 삭제
BCNF
제 3 정규형이고 결정자가 후보키가 아닌 함수 종속 관계를 제거하여 릴레이션의 함수 종속 관계에서 모든 결정자가 후보키인 상태를 말한다.
- X→Y가 성립할 때 모든 결정자 X가 후보키이면 BCNF 정규형
- 삽입 이상 : 새로운 강사가 수강을 추가할 수 없다. 학번이 필요하다.
- 삭제 이상 : 12010 이 코테를 취소하면 큰돌의 코테는 사라진다.
- 갱신 이상 : 큰돌 과목이 바뀌면 다바꿔줘야한다.
결정자(X)가 후보키로 취급되고 있지 않기 때문이다.
후보키는 슈퍼키중에서 최소성을 갖는 키이므로 이 릴레이션에서는 (학번, 수강명)이나 (학번, 강사)가 후보키가 된다. 강사만으로는 후보키가 될 수 없다.
하지만, 후보키가 아님에도 과목명을 결정할 수 있기 때문에 담당 교수는 결정자(X)에 속한다. 위의 문제를 해결하고자
모든 결정자는 항상 후보키가 되도록 릴레이션을 분해해주면 BCNF를 만족하게 된다.
무조건 정규화 과정이 옳은 것은 아니다. 성능이 너무 떨어질 경우 반정규화를 진행한다
'Database' 카테고리의 다른 글
[Database] 인덱스 인덱싱에 관하여 (0) | 2023.08.06 |
---|---|
[Database] 스프링과 트랜잭션 (0) | 2023.08.06 |
[Database] 동시성 제어 (1) | 2023.02.17 |
[Database] 회복 (0) | 2023.02.16 |
[Database] 정규화 (0) | 2023.02.13 |