3정규형
후보키(primary?) 속성 아닌 애들 중 이행적 속성이 존재시?
BCNF (3.5NF)
집합 F의 함수적 종속에서 클로저 F에 대해
a -> b is trivial (당연하다. a가 b를 결정할 경우가 당연하다는 것?)
a is a superkey for R (한국 책에서는 후보키라고 되어있음.)
라는 두가지 조건이 모든 F가 만족 시 BCNF.
BCNF 2정규형 만족하는 이유
Nearest Shop이 Shop Type을 결정하긴 한다. 근데 shop type이 후보키라서 2정규형이 맞다!!!
2정규형의 필요충분 조건
후보 키 K와 K에 속하지 않는 속성 A가 있을 때, A를 결정하기 위해 K의 일부가 아닌 K 전체를 참조해야만 하는 경우 1NF 테이블은 2NF이다.
person, shop / shop, shop type 으로 조인하지 않으면 lossless join을 하지 못함.
공통속성이 없기 때문에 손실이 발생한다.
However, this decomposed design allows us to record multiple shops of same type against the same person, i.e., it cannot preserve the dependency {Person, Shop Type} → {Shop} (=> a person can have only one nearest shop for each shop type).
살짝 트리키한 데이터다. 만약 이글아이가 미용실로 바꾸면 가까운 미용실이 두곳이 된다.
함수적 종속을 보장하지 못하는 테이블이 된다.
좋은 방법?
원래 테이블은 유지하고, nearest shop을 shop의 외래키로 연결을 해서 shop, shoptype의 테이블을 하나더만든다.
이런식으로 원형 테이블을 유지하는게 더좋다.
외래키 제약을 걸어두게 되면 shop에 등록된 상점만 나올 수 있따.
Decomposing a Schema into BCNF
Suppose we have a schema R and a non-trivial dependency a->b causes a violation of BCNF.
We decompose R into:
(a U b)
(R-(b-a))
차집합 해줘야 된다.
공통 집합이니 둘 중 하나가 키가 되어야 한다.
Constraints, including functional dependencies, are costly to check in practice unless they pertain to only one relation
= 함수 종속성을 포함한 제약조건은 하나의 관계에만 관련되지 않는 한 실제로 확인하는데 비용이 많이 든다.
If it is sufficient to test only those dependencies on each individual relation of a decomposition in order to ensure that all functional dependencies hold, then that decomposition is dependency preserving.
-> 모두 쪼개는 게 좋은 것 만은 아니다. dependency가 전부 분산되기 때문에 체크하기 힘들어짐. 이걸 감안해서 쪼개는 것이 좋다. 그런데 functional dependency들이 전부 유지되어야 한다.
dependency preserving까지 담는 것은 최상위. data table의 rule을 모두 지켜가며 만들기 쉽지 않다. 그러면 어떻게 해결해야 할 까? DB에서 최대한 정리해줘야 한다... 그렇지 않으면 코드가 지저분해짐.
Because it is not always possible to achieve both BCNF(3.5NF) and dependency preservation, we consider a weaker normal form, known as third normal form.
bcnf와 의존성 preservation을 만족하기 쉽지 않다? 그래서 그 밑인 3정규형을 고려한다?
정규형의 목적
Let R be a relation scheme with a set F of functional dependencies.
Decide whether a relation scheme R is in “good” form.
In the case that a relation scheme R is not in “good” form, decompose it into a set of relation scheme {R1, R2, ..., Rn} such that
each relation scheme is in good form
the decomposition is a lossless-join decomposition
Preferably, the decomposition should be dependency preserving. ->functinal dependency도 보존을 해야한다.
ch8 34p의 table은 3개의 컬럼 집합이 후보키다.
functional dependency 자체가 없으면? BCNF 만족한다.
36p로 분리되었다.
ID가 child_name을 어느정도 결정하긴 한다. instructor를 알기만하면 어느정도 결정할 수 있다...!
다치 종속 (여러개의 값으로 종속됨) 이라고 함.
다치 종속 발생시 제 4정규형까지 가준다.
아래와 같이 표현한다.
a ->-> b
다치종속은 함수종속과 다르게 표현한다. 실제로도 다름.
