Тройные отношения: в чем разница между одной таблицей и несколькими таблицами?

Рассмотрим следующие троичные отношения:

Предположим, что все объекты имеют только два атрибута (PK и Name).

Вот таблицы, которые я получил (5 таблиц):

Sector
-------------------------
ID_Sector    SectorName
-------------------------

Product
-------------------------
ID_Product    ProductName
-------------------------

Company
--------------------------------------
ID_Company    ID_Sector    CompanyName
--------------------------------------

Relationship 1 (R1)
-------------------------
ID_Sector    ID_Product
-------------------------

Relationship 2 (R2)
-------------------------
ID_Company    ID_Product
-------------------------

Вопрос:

Это хорошее решение для этих троичных отношений? В чем разница между двумя таблицами (R1 и R2) вместо следующей таблицы:

Ternary table
-------------------------------------
ID_Sector    ID_Company    ID_Product    
-------------------------------------

Мне кажется, что наличие двух отдельных таблиц для каждого отношения (R1 и R2) является лучшим решением по сравнению с наличием одной таблицы, но я не знаю, так ли это на самом деле или это хорошая практика.

— feelthhis
источник

Два решения моделируют разные правила. С троичной таблицей вы говорите, что компания может иметь только определенные продукты в определенном секторе. В другом секторе будет другой набор продуктов, хотя эти два набора, конечно, могут перекрываться.

С бинарными таблицами вы заявляете, что этот сектор не влияет на то, к каким продуктам относится моя компания. Точно так же компания не имеет никакого влияния на то, какие продукты находятся в каком секторе.

Выбор между этими альтернативами будет определяться вашими бизнес-правилами. На это нельзя ответить абстрактной, академической дискуссией. Я нашел, что лучше всего назвать отношения между сущностями. Сказать, что компания связана с продуктом, скажем, интересно; сказать, почему компания связана с продуктом, еще лучше. «Компания покупает продукт» - это информация, отличная от «компания производит продукт» или «компания не имеет разрешения на использование продукта». Делая это, я часто открываю новые отношения, атрибуты и типы сущностей. Вам могут понадобиться как двоичные, так и троичные таблицы!

Изменить : для правил

Компания производит много продуктов / каждый продукт производится только одной компанией
Компания отчиталась ровно в одном секторе / каждый сектор отчитался о многих компаниях
Продукт продается только в одном секторе / каждый сектор имеет в наличии много продуктов.

Я бы имел эти типы сущностей

Сектор - SectorID

Компания - CompanyID, SectorID

Продукт - ProductID, CompanyID

Если какое-либо из ваших правил много ко многим, вам понадобятся таблицы бинарных ассоциаций.

Кроме того, имена отношений "имеет", "принадлежит" и "является" часто скрывают больше, чем они освещают. Если вы обнаружите, что ваши БА используют их, попросите их еще раз подумать.

— Майкл Грин
источник

Давайте предположим, что бизнес-правила: 1) компании производят продукцию; 2) Компании относятся к сектору (примеры сектора: машины, продукты питания, программное обеспечение); 3) Продукция относится к секторам. Я старался быть лаконичным и заплатил цену за сокрытие важной информации. Спасибо!

— чувствую это

Мой комментарий поднимает другой вопрос: какие бизнес-правила моделирует ERD выше? Есть ли способ сделать ERD очень точным в отношении бизнес-правил? Точно ли троичная таблица представляет ERD выше? Если это так, то приведенная выше ERD является неправильной моделью в отношении указанных трех бизнес-правил, верно?

— чувствую это

Какие бизнес-правила использует модель ERD выше: троичная таблица будет означать, что есть вещь, в которой ProductID, SectorID и CustomerID являются необходимыми и достаточными ключами. Что-то вроде «GE (компания) финансирует (Продукт) 90% (атрибут) всех авиационных двигателей (сектор)», тогда как «Goldman финансирует 5% авиационных двигателей» и «GE финансирует 3% ветряных мельниц».

— Майкл Грин

@feelthhis - «Есть ли способ сделать ERD очень точным в отношении бизнес-правил»: да! Это то, что делают ERD. Я отредактирую свой ответ. «Точно ли троичная таблица представляет ERD выше»: я думаю, что вы имеете в виду «правила выше». Нет. Продукт изготовлен ровно одной компанией. Компания принадлежит ровно одному сектору. Зная ProductID, можно однозначно идентифицировать клиента и сектор, и эти идентификаторы будут избыточны в троичной таблице. Следовательно, это не нормализуется в соответствии с вашими 3 правилами. «Если так ..»: согласен.

— Майкл Грин

Ternary Table: a company may...Использование обозначений (IDSector, IDCompany, IDProduct) означает ли это, что кортежи (1, 1, 1) и (1, 1, 2) разрешены («c1» создает «p1» и «p2» в «s1») ); и что кортежи (1, 1, 1) и (2, 1, 2) не разрешены («c1» производит «p1» в «s1» и «p2» в «s2»)? Почему? Разве троичная таблица не допускает какой-либо возможный кортеж (IDSector, IDCompany, IDProduct)? Binary Tables: sector has...; company has...Я думал, что троичная таблица была эквивалентна двоичным файлам, если троичная таблица допускает любой кортеж (IDSector, IDCompany, IDProduct).

— чувствую это