Диаграмма ER - Отображение поставок в офис и его ветки

Ответ 1

Это немного странная структура. Обычно так, как я бы справился с этим, не было бы структуры с цепочкой, которую вы здесь, но, в свою очередь, использовали бы какую-то систему на основе транзакций.

То, как я буду справляться с этим, - это отключить все от order и have one-to-many отношений.

Например, я вижу, что у вас есть OrderDetail off order, но это всегда будет подмножество order. Все заказы всегда будут содержать детали; Я бы связал OrderDelivery с основной таблицей order и имел доступную деталь в любой момент как только ссылочную таблицу, а не от OrderDetailDelivery.

У меня было бы Office как поле на OrderDelivery, а также использовать Branch таким же образом. Если вы хотите иметь отдельные таблицы для них, это нормально, но я бы использовал OrderDelivery как центральное место для них. A null может указать, было ли оно доставлено или нет, и затем вы можете использовать свой прикладной уровень для обработки порядка процесса.

Другими словами, OfficeID и BranchID могут существовать как поля для указания внешнего ключа в их соответствующих таблицах OrderDelivery

Изменить

Поскольку дизайн немного изменился (и он выглядит лучше), я хотел бы отметить, что у вас есть supplier с теми же метаданными, что и Delivery. supplier для меня звучит как сущность, тогда как Delivery - это процесс. Я думаю, что supplier может хорошо себя вести в качестве справочной таблицы. Другими словами, вам не нужно включать все те же метаданные в эту таблицу; вместо этого вы можете создать таблицу (так же, как и сейчас, для supplier), но вместо этого вызывается SupplierDelivery.

То, что я вижу, это то, что вы хотели бы отслеживать все части заказа различных продуктов через все свои контрольные точки. Имея это в виду, вы можете не обязательно иметь отдельный объект для этого, но вместо этого отслеживать что-то вроде SupplierDate как одно из полей на Delivery. В любом случае я бы не стал слишком зависеть от структуры; ваш прикладной уровень будет справляться с этим.

Я бы очень внимательно относился к:, если в нескольких таблицах есть поля с тем же именем, но они не ссылаются друг на друга, вы можете создать разные имена. Например, если deliveryDate у поставщика отличается от того же ключа на Delivery, вы можете подумать о том, чтобы называть его чем-то вроде shipDate, или если вы имеете в виду дату, когда он пришел к поставщику, supplierDeliveryDate в противном случае вы может смутить себя в будущем с вашими запросами и сделает ваш код чрезвычайно сложным для синтаксического анализа без большого количества комментариев.

Изменить для включения диаграммы [снова отредактирован для лучшей диаграммы]:

Ниже я расскажу, как с этим справиться. Ваша переделанная диаграмма довольно близка, но вот несколько изменений

Мое объяснение:

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

Отличительные объекты такие, как описано:

• Order
• продукт
• Поставщик
• Branch

Штаб-квартира, в то время как я включил ее, на самом деле не является необходимым компонентом диаграммы; по-видимому, здесь делаются приказы и просьбы, но я понимаю, что ни в коем случае порядок не проходит через штаб-квартиру; это скорее центральная область обработки. Я собираю продукты, которые не проходят через штаб-квартиру, а вместо этого переходят непосредственно в ветки. Если они это сделают (что может замедлить процессы доставки, но это зависит от вас), вы можете заменить его ветвью и иметь ветвь как ее ссылку, как и раньше. В противном случае, я думаю, вы были бы в безопасности, чтобы полностью удалить его из диаграммы.

Таблицы ссылок

Они настроены для возникающих отношений "многие ко многим".

• OrderProductDetail - заказы могут иметь много продуктов, и многие заказы могут иметь один и тот же продукт. Каждая комбинация первичных ключей может быть связана с рядом продуктов в заказе. [Edit: см. Ниже, теперь это связывает заказы, продукты и поставщиков через ProviderProduct]. Поскольку это таблица ссылок, вы можете иметь любое количество продуктов в заказе.
• SupplierProduct- это работает в предположении, что для одного и того же продукта существует более одного поставщика, и что у одного поставщика может быть несколько продуктов, поэтому эта таблица ссылок создана для обработки инвентаря, доступного для каждого продукта. Изменить: теперь это прямая ссылка на OrderProductDetail, так как имеет смысл, что отдельные поставщики имеют ссылку на заказ, вместо двух удаленных таблиц. Это может служить центральной связью для объединения поставщиков и продуктов, но затем привязан к OrderProducDtail. Поскольку это таблица ссылок, у вас может быть любое количество поставщиков, поставляющих любое количество или количество продукта.
• Доставка. Филиалы могут получать множество заказов, и, как вы упомянули, заказ может быть разделен на разные части, исходя из доступности. По этой причине это связано с OrderProductDetail, что соответствует конкретным суммам с каждым продуктом. Поскольку OrderProductDetail уже является таблицей ссылок с двумя первичными ключами, orderId имеет внешний ключ двойного первичного ключа OrderProductDetail, используя сопряженные ключи productId и orderId, чтобы убедиться, что существует четкая связь с конкретным продуктом в более крупном порядке.

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

Примечание: Последнее изменение: добавлен идентификатор поставщика для OrderProductDetail и переключен на двойной первичный ключ поставщикаId и productId от поставщикаProduct, чтобы убедиться, что у вас есть более четкий способ убедиться, что вы можете быть достаточно гранулированным в как продукты идут от поставщиков до OrderProductDetail.

Надеюсь, это поможет.

Ответ 2

Я надеюсь, что это решит вашу проблему. Если есть проблемы, сообщите мне.

Спасибо

Ответ 3

Я предлагаю вам упростить ваш ER следующим образом

Затем определите таблицы

Suppliers(SupplierId) where SupplierId is PK
Products(ProductId) where ProductId is PK
HeadQuarters(HeadQuarterId) where HeadQuarterId is PK
Branches(BranchId, HeadQuarterId) where BranchId is PK and HeadQuarterId references HeadQuarters
Orders(OrderId, OrderDate, SupplierId) where OrderId is PK and SupplierId references Suppliers
Deliveries(OrderId, DeliveryNumber, DeliveryDate, BranchId) where (OrderId, DeliveryNumber) is PK, OrderId references Orders and BranchId referenced Branches
DeliveriedProducts(OrderId, DeliveryNumber, ProductId, ProductQuantity) where (OrderId, DeliveryNumber, ProductId) is PK, (OrderId, DeliveryNumber) references Deliveries and ProductId references Products

Как только вы это сделаете, вы можете получить кадастры со следующим запросом:

select HeadQuarterId, BranchId, SupplierId, OrderDate, OrderId, DeliveryNumber, DeliveryDate, ProductId, ProductQuantity
from Branches
    join Deliveries using (BranchId)
    join Orders using (OrderId)

Если заказы в филиал могут быть сделаны в разных офисах (HeadQuarters), заказная служба больше неявно определяется принимающей ветвью, поэтому таблица Orders должна содержать еще один столбец (OrderingHeadQuarterId), представляющий новое отношение "Заказы, сделанные HeadQuarters".

Ответ 4

Здесь есть несколько проблем, предполагая, что вы исправили Поставщика, чтобы иметь только первичный ключ-поставщик.

Самое очевидное, что вам не хватает ветки в заказах, поэтому замените Order.headQuartersId на Order.branchId.

Также вы должны знать о первичных ключах. Является ли тот же продукт у двух поставщиков двумя записями? Предположим, да. Тогда поставщик на поставку будет излишним, если вы не хотите, чтобы у вас был только один поставщик (вы, вероятно, делаете). Это действительная денормализация. Или удалите поставщика из продукта. Или нет, это неважно.

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

Учитывая все это, вы можете получить список заказов, поставленных в штаб-квартире для каждого из своих веток, таким образом:

                         JOIN Supplier
                       /                             
SELECT * FROM Delivery JOIN OrderDetailDelivery
             JOIN OrderDetail JOIN Product
                              \ 
                               JOIN Order JOIN Branch JOIN HQ

по всем соответствующим внешним ключам. Если (как указывает @alessandro), порядок HQ может отличаться от HQ Branch, что является дополнительной информацией.

Я не знаю, как это доставит вам инвентарь. Я думаю, вам придется записывать все происходящее или, по крайней мере, идти в филиал. Я думаю, @qazifarhan дает вам что-то вроде этого, но вы можете просто иметь две нулевых даты доставки для ветки и HQ. null означает, что еще не поставлено. Записи с датой доставки HQ, но дата поставки ветки не будет вашей инвентаризацией HQ.