vaban4,

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

В концептуальной модели у вас используется Crow's Foot, а в физической - какая-то другая, не помню названия (IE, что ли?). Открываете гугель, набираете crow foot notation cheat sheet, если уж она вам так нравится, и вызубриваете ее наизусть. Делов на 5 минут от силы. Ну или распечатываете и кладете листочек рядом с собой.

Лично я предпочитаю IDEF1X, но это дело вкуса. Главное поймите, что стрелки на вашей физической модели показывают не направление действия, а родителя в паре "parent-child". Похоже, для вас это неочевидно.

После того, как вы начнете читать эту информацию с листа, идете по связям и прикидываете, какая из двух связанных сущностей может существовать без другой, а какая - не может. Ну или, иными словами, какая появляется в базе сначала, а какая - потом. Так понятно?

Ответ на этот вопрос даст вам понимание, в какую сторону должна быть направлена связь. Надписи на связях лучше тоже переделать, потому что сейчас у вас там полный хаос, который вас только сильнее запутывает. Как вариант, можете формулировать эти глаголы так, как вы бы писали фразу на английском в формате "<Dominant Entity> <Acts On> <Child Entity>". Например:

• Clients place Orders - у вас так и есть, оставляем;
  
• Payment methods Pay Pay - complete hogwash. Если делать все единообразно, то должно быть что-то типа "Payment methods referenced by Payments". Окей, не самый удачный пример, но зато показывает, что типы платежей это не сущность, а всего лишь справочник;
  
• Orders Pay Pay - должно быть Orders paid via Payments.
  
• Addresses located Clients - эээ. Clients have Addresses! Тут сразу видно, что направление связи неправильное, потому что изначальная фраза не имеет смысла.
  
• Employees prepare Orders - тут все правильно, но как я писал ранее, назначение сотрудника на заказ может произойти после того, как заказ сохранен в базе. Это не значит, что направление связи нужно менять на противоположное; вам всего лишь нужно сделать этот FK необязательным (снять галку в столбце Mandatory для данного атрибута в дочерней таблице).
  

vaban4,

DeliveryStatus это справочник, это видно просто по названию. Справочники никогда не ссылаются на реальные сущности, максимум на другие справочники. Так что направление связи у вас изначально было правильное.

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

В идеале, справочников на концептуальной модели быть вообще не должно. Там должны быть только сущности. Но, поскольку я никогда не делал концептуалки в PD, я не смогу вам подсказать, как из этого выкрутиться. Возможно, там есть способ объявить атрибут сущности как справочный, и тогда PD вам сгенерирует таблицу-справочник, как минимум в физической модели, а возможно что и в логической. Копайте.

Я уверен, можно найти весьма заковыристые граничные случаи, когда и справочник совсем не dimension, и сущность совсем не fact. В контексте данной задачи, этот принцип вполне подойдет, даже в такой категоричной формулировке.

Кроме того, должен же ТС иметь что-то подходящее, когда на первой работе ему скажут "Забудьте все, чему вас учили в институте!"