Мы познакомились с инструментом “ER-модель”. Попробуем применить его на практике. Наш СКВОЗНОЙ ПРИМЕР будет система для учета ставок лошадиных бегов. (То, что получилось в итоге - можно будет посмотреть по ссылке на сайте hubcloud.ru).
Построим ER-модель для учета ставок лошадиных бегов.
(!) На практике чаще всего проект проходит следующим образом. Есть некий заказчик, которому нужно автоматизировать какие-то учетные операции. Есть некий специалист, который берется это делать. На первых встречах с заказчиком специалист берет интервью, где спрашивает заказчика о том, что ему (заказчику) нужно.
Задача первых интервью две.
Первая задача - структурно записать требования, к которым можно в последствии обращаться.
Вторая задача - это построить ER-модель клиента. В ходе интервью нужно выделить Сущности, Атрибуты и Связи, которыми оперирует заказчик. Схему можно начать рисовать прямо при заказчике, постоянно уточняя информацию.
Допустим после одного (или нескольких) интервью вы нарисовали следующую схему ER-модели.
Рассмотрим все Связи в ER-модели по порядку (номер на схеме совпадает с номером пункта ниже).
1) Лошадь и Владелец. У Владельца может быть много Лошадей. У Лошади всегда один Владелец. То есть тип связи (1:n). У Лошади обязательно есть Владелец, но, Владелец может совсем не иметь Лошадей (был Владельцем, но всех продал). Кардинальность связи (I0).
2) Скачки и Забег. Скачки могут иметь несколько Забегов, Забег принадлежит всегда одним Скачкам. Тип связи (1:n). Забег всегда должен принадлежать Скачкам, и в Скачках должен быть Забег (не могут быть назначены Скачки без одного Забега). Кардинальность связи (II).
3) Лошадь и Участник. Под Участником будем понимать некую уникальную и неповторимую связку “Лошадь-Жокей-№ дорожки-Забег”, в которой Лошадь принимает участие. В Забеге принимает участие много Лошадей. И Лошадь может принимать участие в разных таких "связках": "Лошадь-Жокей-№ дорожки-Забег”. То есть тип связи (n:n). Лошадь может не быть Участником (пропустила Забег), но в Участнике всегда присутствует Лошадь, то есть кардинальность связи (I0).
(!) В схеме связь 3,4,5 - это одна трех-стороняя связь. Представим, что Лошади и Жокеи могут меняться от Забега к Забегу. Например, в Забеге №1 Жокей А участвовал на Лошади В, а в Забеге №3 Жокей А участвовал на Лошади С. Смысл имеет только составная комбинация: Лошадь-Жокей-Забег. И именно на эту тройку и ставится Ставка: “на Лошадь с Жокеем, которые участвуют в конкретном Забеге”.
4) Жокей и Участник. С Жокеем все также, как и с Лошадью. Тип связи (1:n). Кардинальность (I0).
5) Участники и Забег. В Забеге всегда много Участников. Если принимать, как мы договорились, что Участники - это уникальная связка: “Лошадь-Жокей-№ дорожки-Забег”, то та же самая пара Лошадь-Жокей в другом забеге - будет уже другим Участником. То есть тип связи (1:n). В Забеге обязательно есть Участники. Участник - тоже всегда обязательно принимает участие в Забеге. То есть кардинальность связи (II).
6) Участник и Ставка. Игрок может поставить много ставок на одного участника (поставил ставку, подумал 10 минут и поставил еще одну). При этом Ставка ставится на победу одного Участника. То есть тип связи (1:n). На Участника может быть не поставлено ни одной ставки, но если Ставка поставлена, то она обязательно поставлена на участника. Кардинальность связи (I0).
7) Игрок может поставить много Ставок, Ставка принадлежит всегда одному Игроку. То есть тип связи (n:1). У Игрока может не быть ни одной Ставки (пропустил Заезд), но если Ставка сделана, то у нее обязательно есть тот, кто ее сделал, то есть Игрок. Кардинальность связи (0I).
Подведем итоги главы: Мы построили ER-модели для нашей учетной задачи. Далее рассмотрим алгоритм перехода от ER-модели к таблицам.