Остальные функциональные зависимости после разложения Boyce Codd?

Question

Этот пример декомпозиции был задан в классе, однако решение сбивает с толку, так как кажется, что он оставлен без изменений. Пожалуйста, подтвердите 3) ниже в BCNF, или не можете быть помещены в BCNF?

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 

Разложение:

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.) 

В 3) Котел-утилизатор содержит атрибуты R и G без появления, чтобы удовлетворить HT-> г или CS-> г.

HT-> г дисконтируется, потому что мы не имеем т в ПГТ CS-> г дисконтируется, потому что мы не имеем с в ПГТ

Есть ли правило, что если LHS функционала зависимость содержит атрибуты не в отношении, FD не применяется? Спасибо

Answer 1

FD по-прежнему относится к общему дизайну db.

Каждый FD всегда является выражением некоторого бизнес-правила. Все заявленные бизнес-правила всегда применяются независимо от того, должны ли они применяться в 1-табличной версии схемы базы данных или в ее разложенной версии. Однако, выражая их как FD требует, чтобы все атрибуты, участвующие в FD появляются в том же relvar (потому что, как они были изобретены: как способ выражения правило, которое применяется к отношение схемы (заметит, что она делает не говорят «схема базы данных» здесь). логическое следствие является то, что ФЗ просто не в состоянии выразить правила, что «пролет» больше, чем просто один отношение схемы. логическое следствие что заключается в том, что это не более чем нормально, что «разложение схемы отношений» будет/может привести к тому, что некоторые FD станут невыразимыми (не «неприменимо») в новой версии.

(1) FD, которые все еще могут быть выражены после декомпозиции/нормализации BCNF, могут быть «реализованы», объявив LHS FD как ключ к схеме отношений.

(2) FD, которые стали невыразимыми в разложенной схеме, должны быть восстановлены в общем дизайне базы данных в форме ограничения базы данных. Это «ограничение базы данных» очень похоже на ключевые ограничения, соответствующие этим FD из (1), поскольку эти ограничения базы данных также являются «ключом» сортировки, они просто не являются ключом к отношению в схеме базы данных, вместо этого они являются ключом к «виртуальному» отношению (aka «view»), которое определяется в схеме базы данных. Это представление представляет собой проекцию (точно на атрибуты, упомянутые в любой из сторон FD) JOIN (s) (таким образом, «рекомпозиция из разложенных частей») задействованных схем связей.

Это много слов и, возможно, трудно следовать, но процедура (для cs-> g): объединить схемы разложенных отношений (над HR, давая нам отношение HRCSG назад), проецировать вниз атрибуты, участвующие в FD (таким образом, проект до CSG), и в этом отношении CS должен быть ключом.

Обратите внимание, что я говорю «ключ» здесь в том смысле, что нельзя использовать одну комбинацию значений CS с разными значениями G. Не в том смысле, что это объявление, которое вы можете сделать в любой СУБД для обеспечения соблюдения такого правила.Если бы СУБД могла бы эффективно это сделать, дизайн базы данных был бы намного проще :-) Считалось, что применение правила и наблюдение за тем, чтобы данные никогда не нарушали это правило, теперь зависит от вас.

К счастью, на практике эти случаи не слишком многочисленны, и большую часть времени вы заметите, что подавляющее большинство FD в вашей исходной версии заканчиваются просто как ключи, объявленные в таблицах BCNF.