ERIL: визуальный язык для моделирования данных
Автор: Степан Митькин
Перевод на русский язык: Илья Ермаков
Содержание
Введение
Что такое ERIL? ERIL - это графический язык для описания моделей данных. Он основан на диаграммах "сущность-связь" и диаграммах классов. Этим объясняется его название: Entity-Relationship and Inheritance Language.
ERIL - напарник для ДРАКОНа. Язык ДРАКОН описывает алгоритмы и поведение. Он представляет собой значительно улучшенную разновидность блок-схем потока управления. ДРАКОН вводит ряд правил, которые делают блок-схемы более дружелюбными для визуального восприятия человеком.
Язык ERIL посвящён описанию структуры данных. Подобно ДРАКОНу, ERIL можно охарактеризовать как набор указаний и лучших практических моментов, нацеленных на улучшение читаемости структурных диаграмм.
Замечания по терминологии
В рамках статьи следующие термины следует понимать так:
- Класс, таблица, сущность. Эти понятия будут обозначать одно и то же, "тип объектов".
- Поле будет обозначать то же самое, что и свойство.
Модель данных
Зачем нам нужна модель данных?
Компьютерные программы работают с данными. Данные принимаются, преобразуется, сохраняются и передаются. Если вы видите структуру данных, вы понимаете основное назначение, идею программы.
В ИТ-бизнесе понимание обходится на вес золота. Главная помеха понимаю - сложность. Модель данных может стать мощным оружием против сложности.
Модель данных не ограничена только базами данных
Поскольку данные вездесущи во всех частях программных систем, моделирование данных не ограничивается только базами данных. Любой компонент программы может быть объяснён в терминах данных, с которыми он работает.
Хорошая новость в том, что природа данных остаётся неизменной, независимо от того, где данные сохраняются. Следовательно, любые данные могут быть описаны с использованием одного языка. Данные в базе данных, в памяти, в сети или даже в HTTP-заголовке организованы по сходным принципам. Это делает возможным представлять данные любого рода с помощью единственного визуального языка.
На этой диаграмме мы видим три примера:
- Процессы и потоки. В операционной системе может выполняться множество процессов (Process). Внутри каждого процесса может присутствовать один или более потоков выполнения (Thread).
- Заказчики, заказы и позиции заказа. Может быть много заказчиков (Customer). Через определённое время каждый заказчик может присылать заказы (Order). Каждый заказ может состоять из многих позиций (OrderLine).
- Исполнители, альбомы и дорожки. В коллекции может быть музыка многих исполнителей (Artist). Каждый исполнитель может выпустить несколько альбомов (Album) на протяжении своей карьеры. Альбомы состоят из дорожек (Track).
Все эти примеры взяты из разных предметных областей. Не взирая на это, они основаны на сходной абстрактной идее. Эта идея может быть представлена графически на диаграме "сущность-связь". И не имеет значения, храним ли мы эту информацию в реляционной базе данных или в XML-файле.
Логическая и физическая модель данных
Не является ли модель данных чем-то, что следует глубоко запрятать? Это ведь опасно - выставлять на пока глубинные секреты системы, не так ли? Да, это так. И поэтому нам необходимо сохранять разделение на логическую и физическую модели данных.
Физическая модель данных является конфиденциальной информацией, принадлежностью команды разработчиков. Она содержит все необходимые детали, которые помогают команде сохранять точное видение проекта.
Логическая модель данных является общедоступной. Эта модель - часть контрактов, которые соблюдает система. Логическая структура данных определяет мысленный образ вашей системы в головах ваших заказчиков.
Давайте возьмём в качестве примера приложение онлайн-банкинга. Реальное банковское приложение состоит из нескольких серверов и баз данных. Каждая из таких баз данных может иметь тысячи таблиц. Цель физической модели - дать точную информацию о каждом поле и каждом отношении.
Но потребитель услуг банка не сталкивается с такой огромной сложностью. Всё, что потребитель держит в уме, можно изобразить такой относительно простой картинкой:
- Список его личных счетов (Account).
- Список его личных банковских карт (Card).
- Список транзакций.
- К каждому счёту может быть привязано ноль или более карт.
- Ноль или более транзакций может быть зафиксировано для каждого счёта.
- Некоторые транзакции могут быть связаны с картами.
Это - логическая модель данных. Она предназначена для документирования и интеграции. Цель логической модели данных - достижение понятности системы для внешнего мира.
Советы по черчению моделей на языке ERIL
При поверхностном взгляде, язык ERIL расширяет диаграммы "сущность-связь" (ER-диаграммы) введением наследования и небольшим числом методов работы. Рассмотрим эти методы.
Разбиваем модель данных на много небольших диаграмм
Даже не пытайтесь уместить полную модель данных на одной диаграмме.
К сожалению, вот что часто бывает с новым разработчиком, вошедшим в проект.
"В этом файле - схема нашей базы данных. Взгляни, если у тебя хватит духа." - вот что обычно говорят новичку. Он переходит по ссылке, открывает файл и беспомощно таращится на необъятную паутину прямоугольников и стрелок.
Такая практика порождает (ошибочное) мнение, что диаграммы хороши только для маленьких, "здравствуймирных" приложений. Тем временем, решение оказывается простым и прямолинейным.
Поделите модель на несколько управляемых фрагментов. Разделяйте и управляйте. Вместо создания одной гигантской диаграммы, разбейте систему на много небольших. Каждая из небольших диаграмм должна содержать лишь несколько сущностей. Сущности на маленькой диаграмме должны в идеале относится к единственному понятию (концепту).
Нет нужды изображать все связи между выбранными сущностями. Покажите лишь те, которые имеют отношение к конкретной небольшой диаграмме.
Описываем каждый класс только один раз
Когда вы разобьёте модель данных на несколько под-диаграмм, будет нормальной ситуацией неоднократное упоминание одного и того класса (или таблицы). Более того, будет замечательно изобразить один и тот же класс несколько раз в рамках одной диаграммы. Например, для представления древовидной структуры данных.
Однако, определение класса должно присутствовать только в одном месте. Определение класса должно описывать его содержимое: поля, индексы и т.п. Другие места упоминания класса являются всего лишь отсылками к определению класса. Такие отсылки могут быть изображены как плоские прямоугольники с именами классов внутри.
Подобное же указание применимо к связям. Должно существовать только одно "определение" связи. Упоминания же этой связи могут быть изображены во многих местах.
"Определение" связи и "упоминание" связи отличаются тем, что определение несёт эллипсы с именами полей. Эти поля - ссылки и коллекции, с помощью которых реализована данная связь. Например, связь Order-OrderLine может быть реализована посредством ссылки OrderLine.Order и коллекции ссылок Order.OrderLines (т.к. это связь "один-ко-многим").
В примере ниже присутствуют две диаграммы на одной визуальной сцене. Определения классов Employee (сотрудник) и Division (подразделение) находятся в верхней диаграмме. Нижняя диаграмма содержит только упоминания этих двух классов.
Division связан с Employee двумя связями:
- Несколько сотрудников (Employee) работают в подразделении (Division).
- Подразделение (Division) имеет руководителем (Manager) одного сотрудника (Employee).
Подразделения образуют древовидную структуру: подразделение может состоять из более мелких подразделений (Subdivisions).
Стрелки, "лапы" и линии
Разные типы линий обозначают различные типы связей.
"Лапы" предназначены для отношений один-ко-многим, которые отслеживаются в системе в обе стороны.
Например, отношение исполнитель-альбомы (Artist-Albums). Несколько альбомов связаны с одним исполнителем.
Мы может получить список альбомов, которые принадлежат исполнителю, обратившись к свойству Artist.Albums. Свойство Albums - это коллекция (реальная или виртуальная) ссылок на сущности Album.
Также есть возможность перейти от альбома к его исполнителю, если мы воспользуемся свойством Album.Artist. Свойство Artist - это ссылка на сущность Artist.
Стрелка также обозначает связь один-ко-многим. Её отличие от "лапы" заключается в том, что в случае со стрелкой мы заинтересованы в переходя по связи только в одном направлении.
Примером может служить отношение Order-OrderType. Может оказаться полезным отследить тип заказа для конкретного заказа. Но нас могут не интересовать запросы вида "найти все заказы в мире, которые имеют данный тип". В этом случае достаточно однонаправленной ссылки от Order к OrderType.
Отношения многие-ко-многим могут представляться двумя способами:
- Если нас интересует только то, какие объекты с какими связаны, то мы используем горизонтальную линию с "лапами" на обоих концах.
- Если необходимо хранить какую-либо информацию относительно связи, то между связуемыми классами создаётся один или несколько промежточных классов (таблиц). Отношение многие-ко-многим превращается в две связи один-ко-многим.
Отношение один-к-одному может быть изображено простой линией. В таком отношении два объекта образуют пару. Если мы имеем отношение один-к-одному A-B, то выполняются следующие правила:
- Для каждого объекта типа A имеется максимум один объект типа B.
- Для каждого объекта типа B имеется максимум один объект типа A.
Здесь человек имеет только одного супруга.
Прямые углы и линии
Взгляните на эти две карты. В каком районе проще ориентироваться?
Конечно, в том, который изображён справа. Почему?
Поскольку правая городская планировка лучше организована:
- Улицы прямые.
- Улицы пересекаются под прямыми углами.
Эти ограничения приводят к более простой мысленной модели. "Манхэттэнская" мысленная модель намного облегчает и вождение, и чтение диаграмм.
Итак, мы имеем Манхэттэнские правила:
- Линии должны быть прямыми. Кривые и волнистые линии запрещены.
- Линии должны быть только вертикальными или горизонтальными. Наклонные линии не допускаются.
Чтобы проследить за кривой линией, требуются определённые усилия и напряжение глаз. Прямые линии не приходится отслеживать. Они расслабляют глаза и мозг.
Требование использовать строго вертикальные или горизонтальные линии ведёт к более простой структуре графа. Каждая вершина графа может иметь не более четырёх соседних.
Избегайте пересечения линий
Это - одна из наиболее важных инструкций.
Избегайте пересечения линий любой ценой!
Пересечение линий - это враг номер один при рисовании диаграмм. Они вносят двусмысленность и разрушают читаемость.
Наш мозг автоматически считает, что если некоторые объекты контактируют на диаграмме, то есть связь между ними. Чтобы убедить мозг в обратном, мы должны потратить драгоценное время и умственную энергию. Этих усилий можно и нужно избежать.
Запрет на пересечения линий является одной из главных составляющих языка ДРАКОН.
Иногда модель может быть взаимосвязана настолько тесно, что её невозможно изобразить без пересечений. В этом случае диаграмма разбивается на несколько частей. Каждая из таких частей затем чертится без пересечения линий.
T-образные соединения, конечно, позволяются.
Владеющие сущности - сверху, подчинённые - снизу
Очень часто объект является частью другого объекта. Если часть не может существовать без целого, такое отношение "часть-целое" называется владением (ownership), или отношением master-slave (хозяин-слуга).
Обычно объект-слуга уничтожается вместе со своим объектом-хозяином.
ERIL предлагает ясный способ выделить отношения такого типа:
- Вертикальные линии обозначают владение.
- Горизонтальные линии обозначают равноправные отношения.
Для отношений владения теперь легко увидеть, кто является хозяином, а кто - слугой. Верхняя сущность - это хозяин, нижняя сущность - это слуга. Объект может иметь только одного хозяина, владельца.
В равноправном отношении каждая сторона имеет одинаковые права. Поэтому не имеет значения, какая сущность расположена слева, а какая - справа.
Замечание относительно согласованности. Если линия соединена с одним классом вертикально, то она должна соединяться также и с другим классом вертикально. Будет ошибкой начать с вертикальной линии и закончить горизонтальной - или наоборот.
Другие наименования для отношений владения и равноправнных отношения - это композиция и агрегация. Проблема этих терминов в том, что они не эргономичны. Иными словами, их трудно запомнить и легко перепутать.
Не изображайте вместе наследование и отношения
Может показаться привлекательным собрать воедино всю информацию, касающуюся сущности, и поместить её в одном месте. Хотя в целом это хорошая идея, есть ситуации, когда это не так.
Например, связи данных и отношения наследования лучше изображать на различных диаграммах.
Наследование и связи могут быть показаны на одной и той же визуальной сцене, но в разных её частях. Эта рекомендация обусловлена тем, что наследование концептуально отличается от связей данных.
Различные идеи должны быть представлены раздельно.
Заключение
Модель данных является мощным, но недооценённым средством. Она помогает понимать структуру программы.
Есть два вида моделей данных:
- Внутренняя, или "физическая". Содержит закрытую детальную информацию по проекту или компоненту.
- Логическая. Описывает ПО в виде части контакта, которое это ПО обеспечивает. Критично для интеграции.
ER-диаграммы ("сущность-связь") и диаграммы классов - традиционные способы описания модели данных. ERIL улучшает их, вводя определённые правила и соглашения. Большинство идей, воплощённых в ERIL, были заимствованы из языка ДРАКОН, который продемонстрировал их большое практическое значение.
ERIL предлагает следующие принципы:
- Разделяй и управляй. Не пытайтесь уместить мир на одной стороне бумажного листа. Вместо этого рисуйте много простых диаграмм.
- Описывайте вещи в одном месте, ссылайтесь на них многократно. Каждый класс (таблица) и отношение может быть упомянуто многократно, но описано только в одном месте.
- Используйте стандартные и легко узнаваемые символы, чтобы показать тип отношения..
- Один-к-одному: простая линия.
- Один-ко-многим, двунаправленное: линия с "лапой".
- Один-ко-многим, однонаправленное: стрелка.
- Многие-ко-многим: линия с двумя "лапами".
- Линии должны быть прямыми. Никаких изогнутых, кривых или наклонных линий.
- Только вертикальные или горизонтальные. Линии должны быть только строго вертикальными или горизонтальными.
- Вертикальные линии обозначают владение.
- Горизонтальные линии обозначают равноправные отношения.
- Важно! Пересечения линий запрещены.
- Различные идеи изображаются по раздельности. Не сваливайте в кучу наследование и связи данных.
Хорошо начерченные диаграммы легче для чтения, чем плоский текст. В возражение можно сказать, однако, что диаграммы труднее создавать. Цель представленных правил - помочь не-художникам быстро производить читаемые структурные диаграммы.
Программный проект - это база знаний. Работа команды разработчиков - развивать и поддерживать её. Вместе с ДРАКОНом, ERIL перекрывает большинство аспектов этой базы знаний.
Версия автора: 25 января 2014 г.
Контакты автора: drakon.editor@gmail.com
Контакты переводчика: i@ermakov.pw