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

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

то, как я бы справился с этим, чтобы иметь все от order и have one-to-many отношения от этого.

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

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

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

редактировать

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

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

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

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

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

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

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

отдельных лиц, описаны:

• ордер
• продукт
• филиала

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

Связь С Таблицами

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

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

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

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

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