Оставшиеся функциональные зависимости после разложения Бойса Кодда?

Question

Этот пример декомпозиции был дан в классе, однако решение сбивает с толку, поскольку кажется, что некоторые FD остаются без внимания. Пожалуйста, подтвердите 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) HRSG содержит атрибуты R и G, не удовлетворяющие требованиям ht->r или cs-> g.

ht->r обесценивается, потому что у нас нет t в HRSG cs->g обесценивается, потому что у нас нет c в HRSG

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

Answer 1

FD все еще применяется к общему дизайну БД.

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

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

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

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

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

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