ER диаграммы предназначены в основном для того, чтобы описать структуру реляционной базы данных, которая играет роль информационного хранилища для большей части программных продуктов. Это обстоятельство серьезно ограничивает возможности аналитика, поскольку он вынужден переносить ограничения, присущие реляционной базе данных на свою модель. Иными словами, абстрагироваться от особенностей организации хранения данных в полной мере не удается. Абстракция без лишних ограничений – это залог создания наиболее гибких и адекватных информационных моделей. Немного поясню, что я имею в виду. ER диаграмма – это набор “плоских” сущностей и связей между ними. Под термином “плоский” я понимаю представление моделируемого объекта в виде его названия и характерного для него набора свойств, что однозначно сопоставляется с таблицей реляционной базы данных и ее набором полей. Нельзя к объектам относиться так примитивно, даже если разрабатываемый программный продукт должен решать достаточно простые задачи. Рассмотрим простейший пример – программный продукт, который должен обеспечивать информационную поддержку персоналу компании, торгующей недвижимостью, в частности, квартирами. Представление квартиры в виде одной сущности весьма проблематично, поскольку, помимо таких параметров, как возраст объекта, общая и жилая площадь, клиентов интересуют параметры каждой отдельной комнаты. Получается, что комнату необходимо выделять в отдельную сущность. А если речь идет о загородной недвижимости или многоэтажных квартирах, то этаж также становится отдельной промежуточной сущностью в модели. С одной стороны вроде бы ничего “криминального”, но в итоге мы получаем, что наша модель состоит как из независимых объектов (дом, квартира), так и из объектов, которые сами по себе существовать не могут (этаж, комната). ER диаграмма не позволяет выходить за пределы измерений “плоского мира” реляционной базы данных. Помимо самих структур данных аналитик также обязан определить правила обеспечения целостности данных: например, при удалении записи о квартире из базы данных должна также исчезнуть информация обо всех ее комнатах – что логично с точки зрения здравого смысла на языке ER диаграмм требует дополнительного описания. Про “искусственные” сущности, которые используются для моделирования связей типа “многие ко многим” вообще отдельный разговор. Иными словами, моделировать предметную область средствами ER диаграмм – малоэффективное занятие.
Нотация UML лишена подобных недостатков. Модели, описанные на UML, “рисуют” картину реального мира достаточно естественно и с разных ракурсов, поскольку диаграммы UML описывают не только структуры данных, но и прецеденты их использования в процессе работы программного продукта. В основе UML лежит объектно-ориентированный подход к описанию предметной области, поэтому автор UML модели не ограничен двухмерными проекциями реального мира, как в случае с ER диаграммами. Но тут возникает обратная проблема – необходимость “спускаться на землю” и описывать взаимно однозначное соответствие элементов модели со структурами базы данных. Тут может быть два пути: использовать объектно-ориентированную базу данных или разработать свои правила приведения элементов модели к терминам ER диаграмм. Первый вариант во многих случаях более предпочтителен, поскольку все “накладные расходы” и сложности реализации переходят на уровень СУБД, но, по разным причинам, не всегда приемлем. Второй вариант требует универсального подхода для всех элементов информационной модели и позволяет работать с обычными реляционными базами данных. Реализация второго варианта основана на использовании метаданных и инкапсуляции взаимодействия с реляционной базой данных в отдельных программных сервисах. Назовем второй подход – информационное моделирование на основе метаданных. Использование объектно-ориентированных СУБД и информационного моделирования на основе метаданных позволяет:
Манипулировать данными в терминах объектов, индивидуальность которых определяется уникальным идентификатором для каждого экземпляра.
Определять базовые и производные типы со всеми вытекающими преимуществами наследования и даже полиморфизма.
Доступ к данным объектов выполнять опосредовано – через набор интерфейсов объекта, каждый из которых определяет назначение и интерпретацию прикладных атрибутов и позволяет инкапсулировать работу с системными атрибутами (составляющими различного рода ключей).
Далее, повествование пойдет только о создании механизмах отражения объектно-ориентированной модели данных на структуры реляционной базы данных. Будет представлен вариант преобразования объектной модели к ER-представлению. Описание бизнес - сценариев и другие ”поведенческие” аспекты разрабатываемой модели в данном контексте являются второстепенными вопросами. Описание модели предметной области будем рассматривать в следующих терминах:
Информационное моделирование. Элементы модели
Объектно-ориентированное или логическое представление
Объект – основной элемент информационной модели, описывающий реальный объект целевой предметной области: физический объект, событие, отношение между объектами и т.д. В качестве примера рассмотрим класс объектов "автомобиль".
Компонент – элемент информационной модели, выделяющий логическую или физическую составную часть объекта: отношение целое-часть или отдельный информационный его аспект. Компонент может быть обязательным (двигатель), если обязан присутствовать как минимум один его экземпляр, и необязательным (кондиционер), если он является свойством отдельных экземпляров объекта одного и того же типа. Также, компонент может быть неповторяющимся - только в одном экземпляре (кузов) и повторяющимся - коллекция экземпляров (колесо). Каждый компонент характеризуется набором атрибутов.
Перечисление – закрытый справочник (набор допустимых значений заранее известен и является постоянным). Перечисление может быть связано с любым атрибутом компонента через его интерфейс. К примеру, для трансмиссии автомобиля это может быть {"механическая КП", "гидротрансформатор (АКП)", "робот", "вариатор"}
Структура информационного хранилища
Таблица – элемент информационной модели, описывающий структуру таблицы реляционной базы данных. Описание таблицы включает в себя описание полей с указанием их типа и длины. В описании полей используются только стандартные типы данных: целочисленный, вещественный, текстовый, дата и время и т.п.
Переходный уровень
Интерфейс – специальный элемент информационной модели, предназначенный для связи логического представления и структуры информационного хранилища. Интерфейс является поименованным набором характеристик - свойств интерфейса и связан с определенной таблицей. Каждое свойство интерфейса связано с полем таблицы и своим типом определяет логику и семантику работы с данными этого поля: простое значение, перечисление, ссылка на объект, автоматически заполняемое значение и т.д. Каждому компоненту объекта соответствует один интерфейс, свойства которого автоматически являются атрибутами компонента. Каждой таблице могут соответствовать более одного интерфейса, что позволяет по-разному интерпретировать данные одной и той же таблицы для разных компонентов.
Представление – дополнительный элемент информационной модели, описывающий форму табличного представления данных и являющийся поименованным набором пар интерфейс-свойство – колонок представления. Каждая колонка представления может быть дополнена критериями фильтрации и/или объединения данных.
Дизайнер рабочего пространства
Рабочее пространство
Рабочее пространство ex-terra software package состоит из набора соединений с источниками информации и определением документа приложения. Каждое соединение характеризуется параметрами соединения с реляционной базой данных и набором метаданных, интерпретирующих эти самые данные. В состав метаданных входят определения информационной модели, элементы которой я описал чуть выше.
Информационное моделирование. Иерархия элементов
Каждый элемент модели описывается набором свойств, которые можно увидеть в правой части дизайнера рабочего пространства при выборе этого элемента слева в навигационном дереве. Для большинства элементов модели определены следующие свойства:
Уникальный текстовый идентификатор элемента (Name).
Текстовое описание элемента (Caption).
Порядковый номер элемента (Index), если элемент входит в коллекцию однотипных элементов, например, в коллекцию полей таблицы.
Уникальный идентификатор базового элемента (Base), который необходимо определить, чтобы сделать текущий элемент производным.
Базовый элемент – элемент модели, свойства и структура которого наследуется производным элементом. В производном элементе свойства и структуру базового элемента можно переопределять или дополнять, задавая новые значения свойств и формируя свою структуру. Под структурой понимаются коллекции связанных элементов: для объекта – компоненты, для интерфейса – свойства, для таблицы – поля и т.д. Дополнение структуры своими связанными элементами приводит к тому, что итоговая - производная структура является объединением базовой и своей, например, определение в производном объекте новых компонентов или в производном интерфейсе новых свойств.
Важно: если в переопределенной структуре появится связанный элемент с именем (свойство Name), которое уже использовано в базовой коллекции связанных элементов, то новый связанный элемент будет переопределять соответствующий базовый связанный элемент. Переопределение связанных элементов может быть полезно при наследовании интерфейсов за счет новой интерпретации определенных ранее свойств.
Редактирование модели
В дизайнере рабочего пространства есть возможность добавить новый элемент модели с уникальным текстовым идентификатором, а также удалить выбранный элемент.
Информационное моделирование. Добавление и удаление элементов модели
Определение элементов модели можно редактировать в текстовом режиме в формате XML, включая определения связанных элементов. После подобных редактирований необходимо обновить всю загруженную модель, нажав соответствующую кнопку на панели управления дизайнера.
Информационное моделирование. Редактирование элементов модели
Документ приложения
Документ приложения представляет собой XML документ, определяющий правила навигации по разделам данных в шаблоне или проводнике приложения. Каждый элемент документа приложения может интерпретироваться проводником, как соединение рабочего пространства, запрос к базе данных на основе конкретного представления View (см. Описание модели), вход в прикладную операцию – транзакцию и т.п. Также, отдельные разделы документа используются для описания процедур контроля целостности данных, например, для внесения запрета на удаление экземпляров одних объектов, если в базе данных присутствуют связанные с ними экземпляры других объектов и т.д.
Информационное моделирование. Документ рабочего пространства
Формирование структуры информационного хранилища
Ну а теперь, собственно, кульминация – процесс формирования структур реляционной базы данных на основе созданной модели предметной области. Делается это с использованием специальной утилиты и сводится к выбору объектов, информацию о которых предполагается хранить в конкретной базе данных. Создаваемых таблиц может быть и меньше, чем количество компонентов выбранного объекта. Это происходит в том случае, если несколько компонентов объекта посредством своих интерфейсов связаны с одной и той же таблицей.
Формирование структур данных. Выбор объекта
А это фрагмент SQL, выполнение которого приведет к появлению в выбранной базе данных новых таблиц. Генерация SQL и является основной задачей рассматриваемой утилиты.
Формирование структур данных. Выполнение SQL
Шаблон приложения
На основе сформированной модели и созданных структур в базе данных мы автоматически получаем шаблон готового приложения, представленный проводником рабочего пространства. Проводник использует те же метаданные. Точнее, он использует тот же файл рабочего пространства и позволяет работать с данными в соответствии с правилами и ограничениями, описанными в разделах метаданных и в документе приложения.
