Объектное
представление о реляционной модели
Реализацию объектного представления логично начать с проектирования среды хранения информации о классах. Конечно, можно создать собственную систему хранения, но, поскольку речь идёт о базах данных, то, наверное, более разумно воспользоваться средствами СУБД. Базу данных объектного представления можно рассматривать как часть базы данных некоторой предметной области, либо как самостоятельную систему хранения информации. Второй путь более привлекателен, поскольку позволяет использовать одно и тоже объектное представление над несколькими базами данных. Что позволяет, в частности, перейти от объектного представления на уровне сущностей (отношений) к объектному представлению на уровне инфологической модели (баз данных), но это тема отдельного разговора. База данных объектного представления аналогична по своей структуре базе метаданных, которые используются для хранения информации об отношениях в реляционных СУБД. Действительно, это сходство проистекает от единства класса и отношения. Класс обладает практически всеми атрибутами, характерными для описания отношений: полями, индексами, триггерами, ограничениями и проверками. Дополнительным свойством классов является наличие у них методов. Следовательно, можно для описания классов использовать схемы, аналогичные схемам метаданных используемой СУБД, а, с другой стороны, позволяет применять стандартные средства взаимодействия с базами данных, при незначительной их модификации. Отсюда можно вывести ещё одно следствие: перетрансляция запросов из объектного представления в реляционное представление не требует сложных схем и значительных ресурсов. Программное обеспечение, выполняющее трансляцию запросов из объектного представления в реляционное, будем называть сервером объектного представления (SOV - Server of Object View). Его задачами являются:
Список перечисленных задач является минимальным, но не исчерпывающим. В реальных системах могут потребоваться дополнительные функции, например, те что реализованы в мониторах транзакций.
Схемы хранения объектного представления могут быть достаточно разнообразны, и их проектирование зависит от тех возможностей, которые они призваны обеспечить. Упрощенная схема объектного представления приведена на рис. 1. Она обеспечивает выполнение основных функций объектного представления: создание, изменение и уничтожение классов; предоставление необходимой информации для перетрансляции запросов и преобразования результатов выполнения запросов. Схема представляет собой концептуальную модель и реализована в виде ER-диаграммы (диаграммы Сущность-Связь). Сервер объектного представления независим от сервера базы данных, как с точки зрения инструментальных средств, так и с точки зрения физического размещения. То есть сервер объектного представления может использовать свою СУБД, например, локальную, и свою базу данных. Реальное расположение базы данных может повлиять на производительность всей системы. Существует два приемлемых варианта расположения: на сервере баз данных или на сервере объектного представления, если, конечно, это различные сервера. В первом случае желательно иметь быстрый канал связи между сервером или серверами баз данных и сервером объектного представления. Второй случай предъявляет повышенные требования к ресурсам сервера объектного представления, поскольку на нём должна производительно работать некоторая СУБД. Ключевой сущностью в данной схеме является понятие классов. Связь Inherited (CLASSES – CLASSES) реализует схему наследования. Поскольку связь является необязательной, то, следовательно, допустимо любое количество классов, не имеющих суперкласса. Схема наследования не предусматривает введение понятия множественного наследования, то есть каждый класс имеет один и только один суперкласс. Для реализации множественного наследования необходимо реализовать бинарную связь многие ко многим (M-N связь). Но подобная практика не представляется мне разумной.
Вторая связь - Links (CLASSES – CLASSES) позволяет устанавливать бинарные связи между классами. Из схемы видно, что данная связь представляет собой бинарную связь многие ко многим (M-N связь), то есть каждый класс может иметь произвольное количество связей с другими классами или с самим собой. В реляционной модели аналогом данной связи является связь, устанавливаемая по внешнему ключу (FOREIGN KEY). Строго говоря, данный тип связи возможен не только между классами, но и между классом и отношением. Однако можно сделать простое допущение, что каждое отношение представимо собственным классом. Это допущение устраняет неоднозначность.
Classes – это базовая сущность сохраняющее полное описание класса. Class Name – название класса. Уникальный идентификатор (первичный ключ) класса в рамках системы. Class Check – поле, содержащее все проверки, выполняемые на уровне класса. Например, если класс содержит поля ДАТА ПОСТУПЛЕНИЯ ТОВАРА и ДАТА СПИСАНИЯ ТОВАРА, то было бы целесообразно установить проверку ДАТА ПОСТУПЛЕНИЯ… < ДАТА СПИСАНИЯ…. Поскольку количество контрольных значений может быть произвольным, то можно выделить их в отдельную сущность. Но можно предположить, что сами проверки хранятся либо в виде триггеров, либо в некотором откомпилированном виде, и запускаются автоматически. В таком случае, допустимо хранить все контрольные проверки для каждого класса в одном поле. В любом случае, мне показалось неразумным “засорять” концептуальную схему излишними деталями. Class Abstract – логическое поле, принимающее значение TRUE, если класс является абстрактным и, значение FALSE, если класс имеет ассоциированное с ним отношение. Class Owner – поле, в котором сохраняется пользователь-разработчик, создавший данный класс. Class Date – поле, в котором сохраняется дата создания класса. Class Comment – поле комментария, где допустимо сохранять любые комментарии по поводу целей создания и правил использования класса. Хороший стиль программирования, в частности, рекомендует тщательно документировать все шаги, особенно, если их логику придётся понимать не только разработчику, но и его коллегам.
Classes Fields – сущность, определяющая атрибуты класса. Данная сущность имеет бинарную связь с классом один ко многим (1-N), что означает, что каждый класс может иметь произвольное количество атрибутов, но каждый атрибут принадлежит только одному классу. Field Name – поле, сохраняющее название атрибута данного класса. Значение данного поля должно быть уникальным в рамках класса. Field Nullable – логическое поле, определяющее может ли данный атрибут принимать значение NULL. Если поле имеет значение TRUE, значит атрибут может быть NULL, в противном случае, он должен быть NOT NULL. Field Size – поле, определяющее предельный размер атрибута. Данное поле используется в случае, если атрибут не имеет фиксированного размера, например, является строковым. Field Precision – поле, в котором задаётся точность представления атрибута. Используется только для атрибутов представляющих вещественные числа. Field Default – поле, в котором сохраняется значение атрибута по умолчанию. Field Check – поле, в котором сохраняются проверки правильности значения атрибута. Fields Comment – поле для комментария. Здесь желательно указывать назначение атрибута и правила его использования в прикладных программах и запросах.
Индексы класса имеют бинарные связи с собственно классами и полями классов. Каждый класс может иметь произвольное число индексов, но каждый индекс принадлежит только одному классу. Это определяет бинарную связь между классами и индексами, как один ко многим (1-N). Бинарная связь с полями класса является связью многие ко многим (N-M), поскольку каждое поле может быть включено в произвольное число индексов, и каждый индекс может содержать произвольное число полей. Строго говоря, классы, атрибуты и индексы образуют тринарную связь, но её невозможно отобразить современными средствами проектирования на уровне концептуальной модели. Исходя из этого, и было допущено упрощение. Index Name – поле, определяющее название индекса. Название индекса должно быть уникальным в пределах базы данных или класса, если используемая СУБД позволяет пересечение имён индексов, принадлежащих различным таблицам (отношениям). Index Flags – данное поле представляет собой комбинацию флагов. Первый флаг отвечает за активность/пассивность индекса. Вторая группа флагов определяет направление сортировки значений по возрастанию или убыванию. Наконец, третья группа флагов определяет тип индекса: первичный (PRIMARY), уникальный (UNIQUE), внешний (FOREIGN), ординарный (ORDINARY).
Триггеры позволяют описывать реакции на то или иное событие относительно своего класса. Trigger Name – поле, содержащее имя триггера. Trigger Event – это поле определяет событие, на которое обязан отреагировать триггер (Insert, Update, Delete). Trigger BeAf – логическое поле, которое определяет когда должен сработать триггер: до (before - FALSE) или после (after - TRUE) события. Trigger Position – это поле определяет последовательность срабатывания триггеров. Оно необходимо в случае, если существует несколько триггеров на одном и том же событии. Trigger Active – логическое поле, определяющее активность триггера. FALSE – означает, что триггер пассивен, TRUE – свидетельствует об активности триггера. Trigger Body – поле, сохраняющее текст триггера. Trigger Comment – поле необходимое для документирования назначения и правил использования триггера.
Методы позволяют определить набор действий, допустимых для данного класса. Иными словами, методы образуют высокоуровневый интерфейс класса. По своей сути они являются хранимыми процедурами, ориентированными на работу с определённым классом. Method Name – поле, содержащее имя метода. Method Body – текстовое поле, содержащее описание метода на языке используемой СУБД. Method Comment – комментарии
к методу и правила его использования.
Параметры, передаваемые в методы, обладают именем, типом и направлением (входные или выходные). Param Name – поле, содержащее имя параметра. Param Input – логическое поле, определяющее является ли параметр входным (TRUE) или выходным (FALSE).
Classes Types – это справочное отношение содержащее список доступных для данной СУБД ординарных типов. К ним относятся, например, числовые типы, включая целые и вещественные, тип даты, строковые типы и т.д. Classes Name – это имя типа данных, совпадающее с именем соответствующего типа данных в применяемой СУБД. |
|||||||||||
