3.8. Устранение связи «многие ко многим»

В качестве примера рассмотрим функционирование фирмы «Столица» (часть варианта 8). Особенностью работы этой фирмы является посредническая деятельность - стыковка поставщиков товаров и покупателей. Один поставщик связан с несколькими покупателями. Один покупатель, в свою очередь, связан с несколькими поставщиками. По понятным причинам поставщик «не знает» покупателя и наоборот. Вот Вам предпосылка создания связи «многие ко многим» между двумя таблицами: поставщики и покупатели  (рис. 3.17).

 

Поставщики

 

ИНН

поставщика

Название

поставщика

Штрих-код

Название

товара

Дата

выпуска

Цена

за 1 ед.

К-во

252206156

«Океан-2»

46052461

Печенье

01.06.04

95-00

200

772654321

«Октябрь»

78690543

Печенье

12.07.04

123-50

450

772654321

«Октябрь»

78695544

Шоколад

15.05.04

43-00

500

772654321

«Октябрь»

78694455

Конфеты

14.06.04

105-00

350

278765433

«Амур пиво»

46052462

Печенье

14.07.04

97-00

600

                                                        

                                                    

Покупатели                                                                                                                      

                                                                                                                                   

ИНН

покупателя

Название

покупателя

Название

товара

Дата

покупки

Цена

за 1 ед.

К-во

Штрих-

код

276546373

«Татьяна»

Печенье

18.07.04

105-00

100

46052462

276546373

«Татьяна»

Печенье

18.07.04

140-00

150

78690543

273894756

«Светлый-3»

Печенье

21.07.04

110-00

50

46052461

 

Рис. 3.17. Пример связи «многие ко многим»

 

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

 Все эти проблемы (реляционной модели и алгоритма) легко решаются добавлением двух промежуточных таблиц: «Поставленные товары» и «Проданные товары». На рис. 3.19 показан фрагмент схемы данных превращения «связи многие ко многим» в несколько связей «один ко многим» с добавлением этих промежуточных таблиц.

 


Преобразование связи «многие ко многим» в несколько связей «один ко многим» и «много к одному» можно сделать следующим образом.  Вместо того чтобы рассматривать множество поставщиков, поставляющих товары многим клиентам, будем рассматривать одного поставщика и множество поставляемых им товаров («один ко многим»). Далее будем рассматривать деление товара одной партии на множество частей, подлежащих продаже («один ко многим»). В результете получим множество товаров, приобретаемым одним покупателем («много к одному»).

Появление таблицы «проданные товары» позволяет решить внутреннюю проблему учета остатков товара в фирме «Столица».

Особенностью реализации предложенной схемы является наличие составного первичного ключа в таблице «Поставленные товары» по связке полей «штрих-код товара» плюс «номер партии» (GoodsID + NumberPart).