maratAbashevКлиент приходит в тур агентство с пожеланием отправиться в какой-нибудь тур. С этим вопросом обращается к менеджеру за консультацией. Менеджер выслушивает пожелания клиента и предлагает тур. Каждый тур включает свои индивидуальные услуги, стоимость, а так же тур может включать себя, как посещение одной страны(города), так и нескольких. Если клиента все устраивает, заключается договор. Через некоторое время клиент подходит к менеджеру, получает билеты и страховку. По указанной дате и времени, клиент отправляется на посадку и путешествует. Также клиенту предоставляется отель с номером.

Что-то в этом роде надо сообразить в виде диаграмме.
IMHO
поскольку почти никакой конкретики нет, можно придумывать и рисовать, что угодно. IMHO Лишь бы Вы могли это объяснить, почему именно так ))) В принципе, при должной подвещенности языка, можно и Вашу картинку объяснить. Как говорят в сфере искусств "художник так видит" ( C ) и "не стреляйте в пианисту, он играет как умеет" /Please do not shoot the pianist. He is doing his best/ ( C ) )))

Пытаемся выделить сущности и пытаемся выкинуть лишнее.

1. Клиент - ok
2. Тур - ok
3. Менеджер - ok. Далее вопрос, как менеджер связан с клиентом. Варианты:
у каждого клиента есть всегда закрепленный за ним менеджер (менеджер id это поле в табличку Клиент, связь 1N) /всякие проблемы, менеджер в отпуске пока забиваем/
менеджер закрепляется за конкретной заявкой/договором. Связь клиент-менеджер через табличку заявки/договора.
4. Заявка(консультация), договор - может быть или 2-е разные сущности (таблички), но, так как большинство полей будет совпадать, я бы сказал, что это одна сущность "заявка/договор" которая может находится в разных статусах (перечитать конспекты по теории конечных автоматов, чем IMHO сразу же убить преподавателя наповал "помниньем" таких слов /теория конечных автоматов/).
5. Тут же вырисовывается справочник статусов договора - заявка, заявка утверждена, заявка отвергнута, договор заключен, договор выполнен/закрыт.

Связь заявка/договор с туром. Если каждый договор только один тур - просто поле ТурИд в табличке договоров (1N), если в договор может входит больше одного тура - табличка связки Туры_в_договоре и связь (NN). Я бы делал все проще (1N) и так сущностей дофига

Возвращаемся к туру.

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

Здесь. Б.... Явным языком сказано, что тур и место посещения связаны связкой N:N. Где, б...., она на вашей диаграмме? Т.ч. преподаватель совершенно прав. Студенты на раз-два расчитайс, пшли вон отсюда. IMHO

Из данной фразы вырисовываются таблички связанные с туром:

6. Посещаемое_место (пусть будет place). Связано с туром N:N. Т.е. должна быть табличка-связка
6.1. Тур_Place - с полями ТурИд, PlaceId, Номер по порядку.
7. Отель - теоретически, что в каждом месте может быть несколько отелей. В сущности Отель поле PlaceId.
8. Я бы, как любитель игр типа SimCity и CitesXL еще ввел бы табличку attractions (достопримечательности/музеи/театры). Хотя, чисто физически, можно их же вбить и в отели.
9. Индивидуальные услуги предлагаемые к туру, связь с табличкой Тур (т.е., я так понимаю, под этим подразумеваются эскорт услуги индивидуалок. Поля уже понятны: пол, рост, размер бюста и так далее ))) )

Цена - нафиг, нафиг. Если еще прайс листы всюду добавлять (классика столько, массаж столько и так далее) это уже не зачет, а полноценный диплом вырисовывается. Банально обычные поля "цена", "валютаИд" в соответствующей табличке. Если есть поле валюта, то тогда сущность:

10. Справочник валют.

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

6.2. Dog_Place - я бы вставил следующее поля: ДоговорИд, PlaceId, Номер_по_порядку, Выбранный_отель_для_проживания, номер_в_отеле (если известен), цена, валютаИд. Что-то еще (даты никакие вставлять не стал, на месте препода, на любых полях с датами я бы студентов рубил умными вопросами которые точно бы показывали, делал человек сам или заказал на стороне).

11. Dog_Attraction - дополнительные билеты на посещение какой нибудь хрени.
ДоговорId, PlaceId, Номер_по_порядку, AttrationId, дата, цена, валютаИд.

12. Dog_Whores (индивидуалки) - ДоговорId, ИндивидуалкаId, Номер_по_порядку, цена, валютаИд

+ дополнительно:

13. Dog_Airlines - билеты на самолет. ДоговорId, АвиакомпанияИд, дата, цена, валютаИд.
14. Справочник авиакомпаний

что делать со страховкой, х.з. Можно тупо поле в тур СтраховаяКомпанияИд, цена, валютаИд и в договор СтраховаяКомпанияИд, Дата, цена, валютаИд

15. Справочник страховых компаний.

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

IMHO

p.s. Никакими туристически агентствами ни разу не пользовался. Предметной области не знаю. Т.ч., вполне возможно, полная хрен. Но думаю топик стартер тоже званием "эксперта по туристическому бизнесу" не обладает

Please do not shoot the pianist. He is doing his best

p.p.s. Плохо знаю, как точно должны выглядеть ER-диаграммы, но Ваши квадратики со стрелочками мне не нравятся. Хотя, возможно, ошибаюсь. У Вас должны быть конспекты, вам виднее.

Leonid KudryavtsevПочему ключевые поля для связи не указаны внутри квадратиков-сущностей

Меня больше беспокоит, что это за ER-диаграмма такая странная

Лично я, например, глядя на данную диаграмму в трезвом виде (после пол-бутылки возможно дело бы пошло лучше), вообще не понимаю:
1) через какие поля таблицы связаны друг с другом
2) между какими сущностями связь 1N (см.комм.выше), между какими сущностями связи NN

Т.ч. приложенную картинку с совокупностью линий, квадратиков и букв, лично я за ER-диаграмму считать отказываюсь. Хотя, в институтах не учился, возможно не прав. Если у автора топика в конспектах ровно такие диаграммы, то конечно, претензия не актуальна.