advisor 가 후보키면 update anmaly 가 발생하지 않을 것이다. (중복이 없으므로)
takecourse relation 을 보자.
- 이 테이블의 기본키는? 단일 att 로는 모두 중복이 있으므로 att간 조합이 필요.
기본키의 후보키를 적어보자.
- {sno, cname} : 한 학생이 특정 수업은 하나만 들으므로.
- {sno, prof} : 한 교수가 한 강의만 강의하므로.
- att 간의 함수 종속은?
{sno, cname} 이 기본키인 경우
{sno, cname} > prof
prof > cname
- 학번이 같을 때 cname, prof 가 같은 게 아니므로 X
- cname 도 sno, prof 에 대해
- prof 에 따라 cname 이 결정되므로 화살표 O
- 몇 정규형?: 3 정규형
{sno, prof} 가 기본키인 경우
{sno, prof} > cname
prof > cname
- 따라서 박스 안 prof 에서 화살표 시작하도록 한다.
- Partial Dependency가 있으므로 1정규형. (없어야 2정규형임!)
- 2 정규화 해주려면 {prof, cname}, {sno, ?}
- ? 을 cname 으로 해주면 학생이 듣는 수업의 교수를 확정지을 수 없다.
- ? 를 prof 로 해주면 학생의 교수, 교수의 과목, 따라서 학생의 과목도 알 수 있으므로
- {pro, cname}, {sno, prof} 로 decompose 해준다.
- Binary relation 2개가 나오고, 정규화가 끝난다.
Anomaly 를 체크해보자.
-
Insertion: primary key 를 null로 하면서 추가하지 못하는 상황이 있나 확인한다. P5라는 교수가 자료구조를 강의한다, 수강생이 결정이 안되었다면 (null, 자료구조, P5)가 되어야 하지만 기본키에 속하므로 저장할 수 없다. 따라서 있음.
-
Deletion: 100번 학생이 자료구조 취소하면 기본키라 튜플을 통째로 삭제해야 한다. 그러면 P2가 어떤 과목을 가르치는지 모른다. 마지막 300도 마찬가지. 따라서 있음.
-
Update: P1이 강의하는 과목의 이름을 프로그래밍 > 컴퓨터 프로그래밍으로 바꿔야 한다면 모두 찾아 바꿔야 한다. Updaate anomaly 있음.
3정규형인데도 Anomaly 발생이유?
cname 의 결정자인 prof 가 수퍼키가 아니기 때문.(prof 의 공통된 값들은 cname 도 같아야.결정자가 수퍼키가 아니라면 기본적으로 Update Anomaly 가 발생한다.) 따라서 결정자를 수퍼키로 만드는 것이 BCNF이다.
BCNF
3정규형 충족, 모든 결정자가 수퍼키인 상태(중복 없음의 상태). 이를 strong 3NF 라 부르기도 한다. (결정자가 수퍼키라면 따로 decompose 하지 않아도 됨)
따라서 prof 공통으로 분리한 각 테이블은 다음과 같다.
enrolllprof는 결정자가 없고, cprof 의 prof 는 기본키인 동시에 수퍼키다. 따라서 중복이 없어 BCNF 를 만족!
따라서 앞서 다른 두 후보키를 기본키로 했을 때 케이스가 나뉘었고, 정규화 과정도 달랐다. 그러나 정규화 이후의 결과는 동일함을 알아두자. (정규화 목적이 Anomaly 를 없애는 것에 있으므로.)
- sno 없이 P5가 강의하는 정보를 crpof 에 추가 가능
- 학생의 교수만 삭제하면 교수의 과목 삭제 없이 삭제 가능
- 과목 이름이 수정될 경우 하나만 수정하면 됨.
- 기본키는? 1, 2개 att 로는 어떤 조합으로도 중복된 값이 생긴다. 따라서 기본키는 {course, teacher, textbook} 이다.
- 함수종속은? course, teacher, textbook을 한 박스에 넣고, dependency 를 보는데 어떤 것도 결정자가 되지 못한다.
- 어떤 정규형? partial, transitive 없고, 모든 결정자가 수퍼키여야 하는데 결정자도 없으므로 BCNF도 충족.
Anomaly 분석
1. 세 att 모두 기본키여서 null 이 저장될 수 없으므로 insertion anomaly 존재.
2. Jane 이 OS 를 강의할 수 없을 때 null을 저장할 수 없으므로 존재.
3. Database 의 교재를 DB System 개정판으로 이름을 바꾸면 다 업데이트 해줘야 함.
Anomaly 존재, 이유는? 데이터의 중복이 너무 많기 때문이다.
특징?
- 각 course 를 가르치는 teacher 는 교재와 상관없이(textbook에 independent) 정해져 있음. : 교사가 추가되면 새로운 튜플 추가.
- 각 course의 교재는 teacher 와 상관없이 정해짐. : database 교재로 한 권을 더 추가하면 3개 튜플이 추가되어야 함.
이렇게 하면?
이렇게 해도 multivalue 라 문제가 생긴다. 이를 아래로 분할해볼 수 있다.
- 추가 가능.
- Jane 이 OS 강의 못할 때 과목의 교재는 여전히 남아있다. 교재가 삭제되더라도 강의자가 남아있다.
- 한 튜플만 수정하면 된다.
이러한 정규화는 multi-value 가 가능하다고 가정하고 거기서 시작한 것이다.
MVD
-
문제는 중복 데이터였다
-
다른 속성에 독립적인 att라면 4정규형을 통해 해결 가능.
-
course > teacher 하나를 결정하지 못하지만, 여러 개의 값을 결정할 때 Multi-Valued Dependency 를 유발. (다중값 종속)
-
X(course)가 multi-determine Y(teacher), R - X - Y (= Z = textbook)에 독립적으로 (조건은 두 개다, X가 여러 Y를 결정해야 하고, Z에 독립적이어야 한다, 만약 X, Y att 2개라면 MVD 성립하지 않음.)
-
이럴 경우 화살표 두 개를 쓴다.: course >> teacher / course >> textbook
-
학생이 한 명의 지도교수를 갖는다: 학생 > 지도교수
-
학생이 여러명의 지도교수를 갖는다: 학생 >> 지도교수
-
이렇게 independent 한 것을 어떻게 하는가? database 를 가르치는 teacher 가 새로 추가 되었다고 했을 때 textbook 수만큼 튜플이 추가되어야 한다.
MVD의 특성
- A>>B라면 A>>C 도 성립한다.
- 일반적인 함수종속(X가 Y 하나에 연결)은 MVD 에 속한다. (A > B 이면, A >> B이다, 반대는 아님.)
- BCNF 끝났는데 문제? MVD 때문이다 > MVD 제거(4정규형)
- 만약 Binary relation 이라면 MVD가 아니므로 나눠주기만 하면 된다.
- teacher 또는 textbook 을 null 로 하면서 course 를 추가할 수 있다
- Jane 을 삭제해도 교재 유지 가능
- 교재 이름 하나만 수정하면 된다.
4NF
기본키, 함수종속, MVD 해결 Normalization
-
기본키: {name, street, city, title, year} 모든 att 조합이다
-
함수종속: 없음
- Insertion 있음
- Deletion 있음
- Update 있음
- MVD 있나?
name >> {street, city} (주소가 추가되면 영화 이름수만큼 튜플 추가), Z = {title, year}
name >> {title, year} (영화 이름이 추가되면 주소 수만큼 튜플 추가) , Z = {street, city}
-street, city 와 title, year 처럼 묶인 이유는 title, year 은 서로 independent 하지 않기 때문이다. 만약 그렇다면 Star Wars 가 모든 연도에 입력되어 있어야 할 것.
- 그러나 street city 와 title year 사이는 independent 하다. 123 Hollywood 가 스타워즈, 엠파이어, 리턴에 다 있다.
따라서 릴레이션은 {name, street, city} 와 {name, title, year} 로 묶는다.
(anomaly 모두 해결)
