2

이 분해 예제는 클래스에서 제공되었지만 일부 FD를 어드레스하지 않은 채로 두는 것처럼 솔루션이 혼란 스럽습니다. 확인하십시오 3) 아래 BCNF, 또는 BCNF에 넣을 수 없습니까?Boyce Codd 분해 후 남은 기능 종속성?

Let R be a relation schema, with schema(R) = {C,T,H,R,S,G} 

set of FDs F over R : 
C->T 
HR->C 
HT->R 
CS->G 
HS->R 

분해는 :

3에서
1) C T H R S G 
2) C T  C H R S G 
3) C T  H R C  H R S G 
end. (Not further decomposed.) 

)는 HRSG> R 또는 CS-> HT-g를 만족하는 나타나지 않고 특성의 R과 G를 포함한다.

HT-> R 할인됩니다 우리는 HRSG 에 t이 없기 때문에 CS -> g 우리는 HRSG에서 C를 가지고 있지 않기 때문에

이 규칙이 있습니까 할인되는 경우 기능의 LHS 종속성은 관계에없는 속성을 포함하고 FD는 적용되지 않습니까? 감사합니다

답변

2

FD는 여전히 전체 db 디자인에 적용됩니다.

모든 FD는 항상 일부 비즈니스 규칙의 표현입니다. 명시된 모든 비즈니스 규칙은 데이터베이스 스키마의 1 테이블 버전으로 수행되는지 또는 그로부터 분해 된 버전에 적용되는지에 관계없이 항상 적용됩니다. 그러나, FD에 관련된 모든 속성이 이 같은 relvar에 나타나는 FD가 요구하는대로 그들에게 을 표현 (즉, 그들이 발명 한 방법이기 때문에하십시오 에 적용되는 규칙을 표현하는 방법으로 관계 스키마. 논리적 결과는 FD의 규칙을 표현 단순히 능력이 있다는 것입니다 (이 은 "데이터베이스 스키마"여기가 말을하지 않습니다) 의 "범위"더 하나보다는 다만 관계 스키마. 논리적 결과 그 그 정상보다 더 이상 없다는 것입니다 "관계 스키마 분해"는 새 버전에서 일부 FD가 표현할 수 없게 될 수도 있습니다 ( "적용 할 수 없음").

(1) BCNF에 대한 분해/정규화 후에도 여전히 표현 가능한 FD는 FD의 LHS를 관계 스키마의 키로 선언함으로써 "구현"될 수 있습니다.

(2) 분해 된 스키마에서 표현할 수 없게 된 FD는 데이터베이스 제약 조건의 형태로 전체 데이터베이스 설계에서 복원되어야합니다. 이 "데이터베이스 제약"은 (1)의 FD에 해당하는 키 제약 조건과 매우 유사합니다. 즉, 이러한 데이터베이스 제약 조건은 정렬의 "키"이기도하며 데이터베이스 스키마의 관계에 대한 키가 아니며, 대신 데이터베이스 스키마에서 정의 할 수있는 "가상"관계 (일명 "보기")의 핵심입니다. 이 뷰는 관련 관계 스키마의 JOIN (즉, 분해 된 부분의 재구성)의 투영법 (FD의 양면에서 언급 된 속성과 정확히 일치 함)입니다.

단어가 많고 따라하기가 어렵지만 절차는 다음과 같습니다 (cs-> g의 경우). 분해 된 관계 스키마를 다시 결합하여 (HR을 통해 HRCSG 관계를 다시 제공), FD에 포함 된 속성 (따라서 CSG에 이르기까지 프로젝트)이 관계에서 CS는 핵심 요소 여야합니다.

다른 키 값과 함께 나타나는 동일한 CS 값 조합에 대해 허용 할 수 없다는 점에서 여기서 "키"라고 말합니다. 이 규칙을 시행하기 위해 모든 DBMS에 선언 할 수 있다는 의미는 아닙니다.DBMS가 효과적으로 이것을 할 수 있다면, 데이터베이스 설계가 훨씬 쉬워 질 것입니다 :-) 규칙의 시행은 데이터가이 규칙을 위반하지 않는다는 것을 의미하므로 이제 여러분에게 달려 있습니다.

다행히도 실제로 이러한 경우는 너무 많지 않으며 원래 버전의 대다수의 FD가 단순히 BCNF 테이블에 선언 된 키로 끝나는 것을 보게 될 것입니다.

+0

내가 이해할 수 있다면 표현할 수없는 FD가있을 때 BCNF를 사용할 수 있다는 점에 흥미가 있습니다! 대신 3NF로 가야한다고 생각했습니다. 어쨌든 원하는만큼 많은 가상 관계를 만들 수 있고 모든 FD를 데이터베이스 제약 수준에서 유지한다면 왜 분해가 필요할까요? :) – Alex