Проектирование базы данных с несколькими отношениями «многие ко многим» - PullRequest
1 голос
/ 02 ноября 2010

Я проектирую базу данных, в которой мне нужны следующие объекты:

Manufacturers: e.g. CocaCola
Brands: e.g. Diet Coke, Coke Zero
Continents: e.g. North America, Europe
Territories: e.g. United States, Canada
Regions: e.g. Alaska, California, Quebec
Suppliers

Поставщик находится в пределах одного и только одного Региона, который принадлежит Территории, которая принадлежит Континенту.

Бренд принадлежит Производителю.

Поставщики, Регионы, Территории и Континенты принадлежат как минимум 1, но, возможно, большему числу Брендов.

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

Буду признателен за любую помощь в этом.

Ответы [ 3 ]

1 голос
/ 02 ноября 2010

Производитель -> Марка -> Континент -> Территория -> Регион -> Поставщик Правильно?

При этом используются следующие внешние ключи:

Brand contains ManufacturerId
Continent contains BrandId 
Territory contains ContinentId 
Region contains TerritoryId 
Supplier contains RegionId 

Если дляНапример, многие континенты имеют одну и ту же марку, необходима таблица отношений:

Brand (id, more fields)
BrandToContinent (BrandId, ContinentId) = many to many
Continent (id, more info)

Или, возможно, вам нужно подключить бренд или поставщика ко многим регионам или континентам, а не стесняться добавлять больше внешнего ключассылки по мере необходимости!

1 голос
/ 02 ноября 2010

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

И, как указал Флинш, в вашем случае это даже проще: у вас на самом деле отношения только один ко многим, и поэтому выне нужны никакие таблицы ссылок.

Обновление .Чтобы определить различные отношения, подумайте о деловом значении слова «принадлежит».Бренд может принадлежать региону, так как «этот бренд принадлежит калифорнийскому производителю» и как «этот бренд используется для продажи товаров на Аляске».Это два разных отношения «один ко многим», а не «многие ко многим».

Обновление 2 .Допустимый пример «многие ко многим» - «пользователю разрешено читать несколько файлов, и каждый файл может иметь несколько пользователей с уровнем доступа« Чтение »».

HTH

0 голосов
/ 02 ноября 2010

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

Из того, что вы мне сказали, для меня звучит как отношения:

One continent -> Many Regions
One region -> Many territories
One territory -> Many suppliers
One manufacturer -> One brand
One brand -> Many suppliers
One brand -> Many regions
One brand -> Many territories
One brand -> Many continents

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

...