Присоединение ссылки к другой ссылке - недопустимый подход в стандартах хранилища данных.
Прежде чем мы начнем, в вашей текущей модели есть несколько проблем, которые предполагают недопонимание хранилища данных.
- OrderID не может быть первичным ключом в таблицах ссылок, если когда-либо было изменение в заказе, у вас были бы дублированные первичные ключи.
- Вы спрашиваете, могут ли быть ShipName или ShipAddress быть бизнес, который предполагает, что вы не полностью понимаете концепцию хранилища данных бизнес-ключа. Бизнес-ключ подразумевает новый концентратор для хранения этого ключа. Не исключено, что они есть, но что происходит, когда у вас два клиента с одинаковым именем или один клиент меняет адрес. Я ожидал бы, что он с большей вероятностью увидит идентификатор клиента, а затем имя и адрес, прикрепленный к клиентскому хабу.
Я думаю, у вас есть два варианта здесь:
Сначала предположим, что у вас есть концентратор заказов, а затем оставьте подключенными к нему обе таблицы ссылок, и связь между деталями заказа и заказа остается скрытой \ косвенной в хранилище данных. Вам понадобится спутник, прикрепленный к ссылке на детали заказа, чтобы хранить цену за единицу и так далее. Это относительно простой подход, но он может иметь недостатки. Например, если один заказ может содержать один и тот же продукт более одного раза, есть риск потери информации или, в лучшем случае, вам придется работать с несколькими активными спутниками и связывать ключевые ключи.
Второй вариант - занять позицию эта информация о заказе сама по себе является бизнес-концепцией и поэтому должна иметь свой собственный хаб (позиция заказа или аналогичная концепция). Теперь новый хаб связывается с заказом с отношением один ко многим и отдельно связывается с хабом продуктов. Логика c теперь проще, но вам нужно строить больше объектов.