Давайте напомним схему ER-модель нашего СКВОЗНОГО ПРИМЕРА. Дополнительно к схеме Сущностей и Связей, добавим Атрибуты Сущностей. См. рисунок ниже.
Все (без исключения), что у нас в ER-модели было Сущностями - в http://hubcloud.pro станет Справочниками. Соответственно, у нас в системе появятся следующие справочники. (Подробно работа со справочниками описана в Справочники)
➢Владельцы
➢Лошади
➢Скачки
➢Забеги
➢Участники
➢Ставки
➢Жокеи
➢Игроки
Как быть с Атрибутами? Атрибуты - это поля в справочниках. Атрибуты могут быть Датой, Числом, “галочкой”, ссылкой на какой-то список.
Рассмотрим для примера Справочник Лошадей. В нашей ER-модели у Лошади есть следующие Атрибуты (см. рисунок выше):
- Порода
- Кличка
- Возраст
- Масть
Очевидно, что Порода и Масть это то, что может повторяться у многих Лошадей. Это некие списки. Но в HubCloud любые списки реализуются с помощью Справочников. То есть мы для Породы и Масти мы создадим Справочник Породы лошадей и Масти лошадей, хотя это всего лишь Атрибуты, а не Сущности.
И ссылку на это этот список мы добавим в поля справочника (подробно работа со справочниками описана в Справочники , кратко-схематично можно ознакомиться в конце главы).
(!) Возможно, что это показалось сложным для понимания. Сущность “Лошадь” из ER-модели стала Справочником. Но и некоторые Атрибуты (Порода и Масть) тоже стали Справочниками. Как это сочетается?
НА самом деле все просто. Любой необходимый нам список - это будет Справочник. Если нам нужен список из “ДА” и “НЕТ”, то мы тоже можем реализовать это справочником. То есть правило очень простое:
“Нужен любой список? Отлично, создавайте новый справочник”.
И не важно, что этот список “Сущность” или “Атрибут сущности”.
Это не противоречит ER-модели, так как - это просто теоретический инструмент, который помогает нам представить все в виде таблиц.
Тогда согласно нашей ER-модели мы создадим в HubCloud следующий набор Справочников и их Атрибутов.
(!) Атрибуты, которые мы сделали в системе Справочниками выделены синим текстом.
(!)Небольшое замечание. Не все Атрибуты Сущностей требуется делать Справочником, часто можно обойтись просто текстом (текстовым полем). Например, Кличка в нашем примере, это справочная информация и это поле можно сделать просто текстовым полем.
Может возникнуть вопрос, а какой Атрибут сделать просто текстовым полем, а какой списком (то есть Справочником)? Паспорт, адрес, станцию метро и прочее, сделать Справочником или текстом? Правило очень простое, если данное поле служит только для информации, то можно данное поле сделать просто текстовым полем. Если же нам потребуется делать ссылки на данное поле (1) или группировать по нему отчеты (2), выбирать в отчетах в качестве фильтра (3) или разделить права доступа по данному Атрибуту (4), то следует сделать этот Атрибут Справочником в системе. Если это лишь информационное поле, то можно сделать его текстовым полем.
Следующим шагом нам требуется реализовать Связи. Алгоритм действий следующий. Последовательно рассматриваем Сущности и сверяем их с таблицей-шпаргалкой из главы 2.1. Правила перехода от ER-модели к таблицам.
В нашем СКВОЗНОМ ПРИМЕРЕ, используя шпаргалку, мы получим следующую таблицу. См. рисунок ниже.
Все связи нашего примера реализуются с помощью двух таблиц. Это означает, что достаточно в одном Справочнике сделать ссылку на другой Справочник. Технически достаточно в Справочник добавить Поле, которое сделать Ссылкой и назначить необходимый Справочник. (Подробно, как работать со Справочниками можно прочесть в инструкции, кратко ознакомиться можно в конце этой главы).
Визуально можно представить это в виде схемы, см. рисунок ниже. Поля атрибутов выделены голубым цветом. А поля Ссылки на другие справочники выделены черным. Пробегитесь глазами по схеме. Есть Справочники, которые в которых нет ссылок на другие. Это Справочники: Игроки, Жокеи, Владельцы и Скачки. Все другие имеют Ссылку на другие справочники. Например, в Лошади есть ссылка на ее Владельца, а в Забеге ссылка на Скачки (все соответствии с ER-моделью СКВОЗНОГОПРИМЕРА).
Остается вопрос, а как быть, если нам встретятся Связи, которые можно реализовать только в трех и в более таблицах? ОТВЕТ: Такие Связи будут реализовываться только с помощью Операций (следующий уровень).
(!) Здесь стоит добавить, что на практике вы не почувствуете ограничений. По опыту, когда возникает потребность в реализации связи в трех и более таблицах, то в этом месте, скорее всего будет Операция. Как устроены Операции и как организовать работу на “уровне операций” будет рассмотрено в следующей главах.
Подведем итоги главы: Мы завершили "уровень ER-модели", о котором упоминали во Введении. В данной точку мы создали Справочники, которые будут необходимы в ходе ведения учета.
Во многих статьях и учебниках по созданию баз данных рассматриваются вопросы, как создавать ER- модели и переходить от ER-модели к таблицам.
Но редко где идут дальше и переходят на “уровень операций”, “уровень проводок”, “уровень отчетов” и "уровень математики прибыли". Хотя без решения задач данных уровней (возможно, за исключением "уровня математики прибыли") учетную систему создать невозможно.
Например, Как в рамках инструментов ER-модели (сущности-атрибуты-связи), отразить в схеме операции: приема ставок (1) и выплат игрокам (2)?
Ведь даже если мы введем в ER-модель сущность Касса, Статья движения денег, укажем Связи со Ставкой, определим тип и обязательность связи, то как это поможет нам рассчитать остаток денег в кассе?
Где в ER-модели будет “+” и “-” которые нужны для расчета остатков? Можно ввести такие Сущности, как “+” и “-”, но даже в этом случае глядя на схему ER-модели, представить, как будет считаться остаток в кассе - очень сложно.
А ведь одно из предназначений схем именно в том, чтобы иметь возможность представить как действует система целиком. Мы переходим на работу на следующих уровнях, где нам инструменты и другие методики работы.