vaban4,

• Juridical - это вам так гугл транслейт перевел? Назовите их Individuals и Companies, всем будет понятнее. В англоязычных системах так и делают, к слову.
  
• Клиентов лучше связать с адресами как 1:М, т.е. один клиент имеет 1 или более адресов. Да, это приведет к тому, что у вас будут повторяющиеся адреса между разными клиентами, но поверьте, это гораздо меньшая печаль, чем когда у вас М:М и вам нужно реализовывать развязку одного адреса в несколько разных. Не очень понимаю, кстати, какой у вас сейчас тип связи - в обратную сторону, что ли? У каждого клиента не более одного адреса, и по одному адресу на несколько клиентов? Не делайте так.
  
• Payment methods это хорошо, но где у вас сами Payments? Учтите, что платеж это часть заказа, а не клиента. Для простоты можно считать, что каждый заказ оплачивается ровно одним платежом; это позволит вам не создавать отдельную таблицу платежей, а просто включить соотв. атрибуты непосредственно в заказ. В любом случае, вам потребуется ссылка на метод платежа из заказов - либо напрямую как 1:М, либо через таблицу-связку (на ваше усмотрение).
  
• Ссылка на справочник состояния доставки непосредственно из таблицы заказов означает, что вы отказываетесь от хранения истории изменения статуса доставки. Это не плохо и не хорошо, вам просто нужно понимать, что вы при этом теряете. Например, провести разбор полетов в случае проблемы с доставкой у вас не получится, потому что историю вы не сохраняете.
  
• Разделение товаров на пиццы и напитки крайне примитивно. У нас, например, Dominos продает много чего, что не попадает ни в одну из этих категорий.
  
• Топпинги выглядят как справочник, но связь почему-то в противоположную сторону. То же самое, в общем-то, и с напитками: связь должна быть М:М. Учтите, что в реальной БД (за что я не люблю концептуальные модели) у вас будет таблица-связка OrderItems, и в ней вам придется реализовать внешние ключи, с одной стороны, на Orders (что просто), а с другой на доступные товары, и вот тут начинается веселье. Я например не выношу пепперони и прочие колбасные вещи, поэтому в моих заказах я выкидываю эти ингредиенты и добавляю либо Pork, либо Ham. Где вы собираетесь хранить такие кастомные позиции - прямо в OrderItems, в виде JSON-блоба? Так можно все что угодно хранить, реляционная модель будет вообще не нужна. Добавьте супертип для товаров, примерно в том же стиле что и клиенты = (юрики + физики), и эту таблицу товаров свяжите М:М с заказами.
  

vaban4,

В лабораторной проканает. В реальной жизни вы очень быстро пожалеете о таком решении. Я однажды так сделал, и понял что ошибся, когда начал писать код для разъединения адреса разных клиентов. Я его написал, конечно, но больше я так проектировать не собираюсь, и вам не советую. Экономия на спичках.

Да, но не напрямую. У вас М:М отношение между способами оплаты и клиентами, и это правильно, т.к. каждый клиент может платить по-разному, а если он вам реально доверяет, может даже разрешить вам хранить у себя его платежные данные, для ускорения оплаты в будущем . Только вот данные эти будут храниться в дополнительной таблице-связке, которая на вашей диаграмме отсутствует (точнее, она есть, но обозначается линией М:М отношения). В идеале, именно на эту таблицу-связку вы захотите ссылаться из Платежей, иначе непонятно, например, каким именно из 5 своих киви-кошельков заплатил клиент.

Учитывая вышесказанное, будет лучше, если вы сразу сделаете отдельную таблицу платежей. Даже если она де-факто будет 1:1 с заказами, платеж это отдельная сущность, и лучше сделать отдельную таблицу. Например, человек оплатил заказ, а платеж не прошел (по любой причине). Значит, клиенту придется пробовать другие методы оплаты, пока не найдется рабочий вариант. В этом случае у вас будет несколько платежей к одному заказу, но только один из них будет в состоянии Approved.

#6 - у вас опять будет 2 таблицы OrderItems, вы понимаете это? Из такой модели вы получите OrderPizzas и OrderBeverages, и они не будут отличаться друг от друга вообще ничем, кроме названия и второго FK. Но весь ваш код будет вынужден всегда делать UNION ALL между этими таблицами, потому что позиции каждого заказа размазаны между ними.

Когда я еще жил в россии, я увольнял за меньшее :). Что на это скажет препод, думаю, несложно догадаться.

В голову приходят следующие неудобные вопросы:

• Как клиенту сохранить свои платежные данные, для последующего использования?
  
• Как оплатить заказ в несколько платежей?
  
• Почему сотрудник зависит от наличия в базе его адреса? Нет адреса - нет сотрудника?
  
• Order is delivered by vehicle - delivered where? Как из заказа узнать, на какой адрес должна делаться доставка?
  
• Что это за 2 фиолетовые шняги, Combo и Exploits? Почему одна из них существительное, а вторая - глагол?
  
• Что делать, если заказ настолько большой, что для его выполнения приходится привлекать более одного сотрудника?
  
• С каких это пор телефонный номер содержит всего 8 цифр? Что делать, если номер начинается с ноля? (не шутка, в Австралии практ. все местные телефонные номера начинаются с ноля)
  
• Как я уже писал в предыдущем посте: в чем причина разделения позиций заказа на 2 таблицы?
  

Ага, в физической модели вы кое-что пофиксили, хорошо. Тогда вот вам еще:

• Вы уверены, что вам действительно нужно хранить в этой системе адреса сотрудников? Это довольно таки персональные данные, им место в отдельной системе - либо HR, либо корпоративной ERP. Если, конечно, под "сотрудниками" вы не понимаете рестораны, открытые на условиях франшизы (как тот же Dominos, например). Но тогда непонятно, какая тут может быть организационная иерархия. В общем, если вы откажетесь от адресов сотрудников, то можно будет инвертировать связь Clients - Addresses и все будет нормально.
  
• В момент сохранения заказа в базу, в общем случае, еще может быть неизвестно, какой именно сотрудник им займется. У вас же mandatory FK между этими двумя таблицами. Сделайте его хотя бы опциональным, что ли.
  
• Не забудьте добавить адрес доставки для заказа.
  

Нет, я написал ровно то, что хотел написать. Связь Clients - Orders у вас правильная, с ней все в порядке.

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

Самое плохое в таком подходе то, что вы не сможете на сайте показать клиенту его адресную книгу.