В формулировках вашего вопроса нет четких технических терминов, поэтому неясно, каковы ваши ожидания и почему.Но это кажется спорным, если вы просто рассуждаете по основам ниже.
не должно быть никакой связи между атрибутами CustomerInvoiceID и SupplierInvoiceID
В отношении реляционной модели (ship) s / ассоциации представлены отношениями.Из оригинальной статьи Кодда 1970 года :
Изображенное соотношение называется компонент .[...] Значение компонента ( x , y , z ) состоит в том, что эта часть x является непосредственным компонентом (или сборкой) детали y , и z единиц детали x необходимы для сборки одной детали детали y .
Ваша 1NF-таблица Shop уже представляет отношение по CustomerInvoiceID, SupplierInvoiceID и т. Д. В нем содержатся строки, которые делают истинное утверждение ( предложение ) из шаблона оператора (( характеристика ) предикат ) что-то вроде:
product ProductID is described as ProductDesc
AND supplier SupplierID is named SupplierName
AND invoice SupplierInvoiceID is from supplier SupplierID
AND invoice SupplierInvoiceID bills for QtyBought of product ProductID
AND customer CustomerID is named CustomerName
AND invoice CustomerInvoiceID is to customer CustomerID
AND invoice CustomerInvoiceID bills for QtySold of product ProductID
В приведенной вами фразе вы, возможно, пытаетесь создать какое-то впечатление, что наборы идентификаторов счетов поставщиков и клиентовидентификаторы счетов в некотором смысле независимы.И в каком-то смысле они есть.Но в другом смысле это не так: мы можем представить бизнес-правило, согласно которому идентификаторы счетов-фактур ограничены так, что счета клиентов включают продукты, которые включают счета поставщиков.Конечно, идентификаторы так ограничены в этой взаимосвязи / таблице.Независимо от того, какие точные определения и утверждения можно выдвинуть для решения таких идей, нормализация к более высоким NF (нормальным формам) просто создает отношения / таблицы из заданных.Отношения компонентов - это определенные преобразования конъюнктур исходных отношений.(Иногда логически эквивалентны самим конъюнктам.) Не зная, что компонент представляет собой отношение, и что это может быть, почему 2NF / 3NF Shop кажется вам странным.
при переходе от 1 NF к 2NF, таблица создается для поддержания отношения между первичными ключами от 1 NF
Нормализация на более высокие NF заменяет таблицу на другие, которые являются проекциями ее, которые естественным образом присоединяются к ней.Он включает FD (функциональные зависимости) и CK (ключи-кандидаты).Не PK (первичные ключи) как таковые - PK - это просто некоторый CK, который вы решили назвать «PK».Нормализация «поддерживает» исходные отношения в том смысле, что эти отношения выразимы как соединение / И отношений компонентов и представлены их естественным объединением.
Ваш дизайн 1NF не способен регистрировать продукты, поставщиков иликлиентам не выставлен счет.Вы можете обнаружить этот факт при нормализации до более высоких NF - но нормализация до более высоких NF не устраняет такие проблемы (аномалии обновления и удаления) - несмотря на (плохие) презентации, говорящие, что это так.Кроме того, он регистрирует только те продукты, которые указаны как в некоторых счетах поставщиков, так и в некоторых счетах клиентов.Может быть поэтому тебе это кажется странным.Начиная с одной таблицы со всеми этими атрибутами, не является частью хорошего метода информационного моделирования.2NF / 3NF Shop - продукт правильной нормализации, но не из "хорошего" оригинала.
Он также не из "хорошей" нормализации.В общем случае существует более одного разложения на NF.Мы используем некоторые проверенные алгоритмы с плюсами и минусами, и нам, возможно, еще придется решить, какой из множества разложений мы предпочитаем.Мы не нормализуем данный NF, проходя через более низкие NF - несмотря на (плохие) презентации, говорящие, что мы это делаем.Здесь вы выбрали дизайн 2NF с компонентом Shop - но затем, когда вы выбрали дополнительные компоненты, компонент Shop стал избыточным - это проекция естественного объединения других компонентов.Возможно, поэтому вам это кажется странным.
Относительно реляционной модели, проектирования и нормализации базы данных.
Есть ли эмпирическое правило для построения запроса SQL из понятного человеку описания?
PS "0NF" и "1NF" не имеют фиксированного значения.
PS Re 2NF / 3NF Shop
Компонент - это проекция оригинала.Это строки, где его столбцы образуют подстроку оригинала.Таким образом, это строки, в которых существуют значения для других столбцов, так что значения столбца компонента и другие значения столбца образуют строку в оригинале.Это то же самое, что сказать, что отношение компонента является FOR FOR SOME или THERE EXISTS для других столбцов, примененных к отношению Original.
Принимая и повторяя приведенное выше выражение для отношения 1NF Shop, 2NF / 3NF Shop представляет собой следующееотношения:
FOR SOME values for ProductDesc,
SupplierID, SupplierName, QtyBought,
CustomerID, CustomerName & QtySold
[ product ProductID is described as ProductDesc
AND supplier SupplierID is named SupplierName
AND invoice SupplierInvoiceID is from supplier SupplierID
AND invoice SupplierInvoiceID bills for QtyBought of product ProductID
AND customer CustomerID is named CustomerName
AND invoice CustomerInvoiceID is to customer CustomerID
AND invoice CustomerInvoiceID bills for QtySold of product ProductID
]
Т.е. строки, где:
product ProductID is described as something
AND some supplier is named something
AND invoice SupplierInvoiceID is from that supplier
AND invoice SupplierInvoiceID bills for some quantity of product ProductID
AND some customer is named something
AND invoice CustomerInvoiceID is to that customer
AND invoice CustomerInvoiceID bills for some quantity of product ProductID
Если предположить, что у продуктов есть описания, что у поставщиков и клиентов есть имена и что в счете-фактуре товар выставляется в определенном количестве или количествах, этоэто строки, где:
invoice SupplierInvoiceID bills for product ProductID
AND invoice CustomerInvoiceID bills for product ProductID
Это строки, возвращаемые проекцией по 3 атрибутам 1NF Shop.Если в качестве баз / компонентов у нас есть таблица для каждого конъюнкта, который я дал для предиката 1NF Shop - таблицы вашего дизайна 3NF - или таблицы вашего дизайна 2NF, то в том смысле, что вы можете, таким образом, запросить для этих строк 2NF / 3NF Shop является резервным в качестве базы / компонента.