Ответ 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.
Надеюсь, это поможет.
