Полтора года назад начался цикл статей про создание гибкой CMS и главной темой, на которой остановились подробно, была реализация объектной модели данных в реляционной СУБД (в MySql). Новые статьи давно уже не писались, но работа над моделью данных продолжала кипеть, порой, доходив до безумия. Сейчас мне хочется поделиться результатами той не простой, но интересной работы. В статье рассматривается объектная модель данных и структура базы данных для неё.

Необходимо предупредить, что нижеизложенную информацию будет легче понять тем, кто может представить четырехмерное пространство и не зациклиться на вопросе, что было раньше, яйцо или курица. Впрочем, я могу преувеличивать.

Объектная модель

Объект

Рассмотрев поверхностно реальный мир, надеюсь, большинство сделает приемлемый вывод, что кругом одни объекты, объекты состоят из объектов или просто связаны между собой. Дом, окна, двери в нем, жильцы, их руки и ноги, клетки, молекулы, атомы и так далее и подробней. Говоря об объектах, о связях между ними, о свойствах, мы оперируем своим воображением, у каждого по-своему уникальная модель воображения. Но сейчас задача не воображения рассматривать, а создать компьютерную объектную модель для представления в ней информации о реальном или воображаемом мире. Объект в этом случаи ассоциируется не только с чем-то единым из реального мира, но и с образами наших воображений, виртуальных миров и ещё неизвестно с чем.

Свойства и связи

Свойство объекта – это связанный с объектом другой объект. В реальности, где именно связь между объектами, сложно сказать. Где, например связь между головой и телом человека? Шея? А где связь между шеей и головой? Так дойдем до поиска связи между атомами и не остановимся. Нам же достаточно просто указать, что объект «А1» связан с объектом «Ж8». Думаю, понятно, что нужно хранить идентификаторы двух объектов. Мне же хочется сказать сразу о специфичности отношений в моделируемой структуре. Сначала пример. Возьмем несколько объектов класса «Деревяшка». Один объект сделаем свойством для шкафа, и он будет называться дверцей, другой сделаем свойством комнаты, и он будет называться дверью, другой свойством стола и называться столешницей и так подробнее. Объекты можно «поменять местами», но дверь у комнаты так и останется дверью. Название объекта – это не его свойство, оно даётся через отношение. Значит, название должно быть свойством отношения (связи).

Отношение само напрашивается быть объектом. Быть особым объектом, который связывает другие объекты и делает один свойством другого. Далее по тексту будет использоваться термин связь, как объект, связывающий два других объекта. Сделав связь объектом, можно будет к связи приделывать описания и абсолютно любые необходимые объекты, делая их свойствами для связи.

Связи «композиция» и «агрегация»

Связи между объектами в ООП различают по виду – агрегация, композиция и их обобщение (ассоциация). Нам достаточно двух видов связей между объектами. Агрегация – это независимая связь, удалив один объект, связанные с ним агрегацией объекты должны сохраниться. Композиция – это связь между цельным и его составляющими (частями), например, удаляя товар, нужно удалить его описания, фотографии, отзывы. Если объект является частью другого, то он уже не может быть частью ещё для одного объекта. Нужно заметить, что композиция образует иерархию и это лучше учесть в структуре БД для последующей возможности выполнять быстрые выборки с условиями по иерархии.

Атрибуты

Чтобы в точности смоделировать реальный мир, нужно что-то соизмеримое со всей вселенной. А у нас в распоряжении только MySQL. Поэтому мы не можем дробить объекты до атомного уровня и более, чтобы выявить нечто атомарное и из него всё смоделировать. Поэтому кроме свойств у объектов появляются атрибуты. Обязательный атрибут каждого объекта – его идентификатор. Кроме идентификаторов могут быть любые другие атрибуты, которые не выразить через объекты. Например, объект «строка1» мы не будем дробить на объекты-символы строки, а символы ещё на что-то, достаточно саму строку представить в атрибуте value. У связей между объектами атрибутами будет вид связи, идентификаторы связываемых объектов и другие характеристики. Используя атрибуты, мы останавливаем детализацию объекта на нужном уровне.

Класс

В реальном мире классы не увидеть. Они, либо непостижимы нашим разумом, образующие законы вселенной, либо классифицирующая информация в наших мыслях. В общем, это не особо важно, так как предназначение класса ясно из ООП. Классом определяется свойства и атрибуты, которые должны быть у экземпляров (объектов) этого класса.

Класс не должен быть какой-то специфической информацией, используемой только логикой программы, выполняющей объектно-реляционную проекцию (ORM). Если класс сделать объектом, то можно создавать свойства для него как для объекта, давать названия, описания и общими методами использовать классы в программе. И вот тут-то начинается интересное. Если делать класс (А) объектом, то нужен класс (Б) для описания свойств класса (А), а потом класс (В) для описания свойств класса (Б) и так далее. С детализацией объектов остановились через атрибуты. Чтобы избавится от бесконечных уровней метаданных, можно сделать так, чтоб класс (Б) описывал свойства всех классов и себя самого.

Так как классы делаем объектами, далее будет применяться термин сущность для обобщения объектов-классов, объектов-связей и обычных объектов. Забыл сказать – раз связи то же являются объектами, то для них тоже должен быть класс.

Определение классом свойств

При программировании класса, описание свойств осуществляется указанием имени свойства и класса, с объектами которого позволено связываться. По сути, создаётся отношение между классами, которое используется как описание свойств между объектами. Из этого следует, что нам достаточно связывать классы между собой и использовать эти связи в логике ORM, как метаданные. Связывать между собой классы позволяет тот факт, что классы являются объектами. Так как классы могут иметь свойства, как объекты, необходимо различать обычные связи и связи, определяющие свойства объектов. Достаточно ввести дополнительный атрибут «is_define» для связей и учитывать его в логике ORM.

Тут может получиться интересная ситуация. По идеи, ничто не мешает создать определяющую свойство связь между обычным объектом и классом или просто между объектами. Если такую ситуацию учесть в логике ORM, то любой объект сможет исполнять роль класса! Но нужно ещё обдумать практичность такой возможности. Сейчас не будем обдумывать.

Дополнительными атрибутами связи, определяющей свойства, будут признак, обязательное свойство или нет, и вес свойства – множественное или одиночное. Если свойство множественное, то объект может иметь несколько связей с одинаковым именованием. Логикой ORM связи множественного свойства группируются по имени, и предоставляется программный интерфейс для работы со списками.

Связь «наследование»

Между классами проявилась связь, определяющая свойства у объектов, но она как третий вид не рассматривается. (Ранее между объектами выделены два вида связи – композиция и агрегация). Однако между классами есть особый вид связи, похожий на композицию – это наследование. Наследование, как и композиция, образует иерархию. Наверно, ясно без дополнительных разъяснений, что бы наследовать один класс от другого, достаточно создать связь вида «наследование» между ними. Ничего нового создавать не надо, но нужно различать данный вид связи в логике ORM.

Связь «экземпляр»

И есть ещё один незаметный вид связи – отношение между классом и его объектами. Опять-таки, эта связь композиционного вида – объект принадлежит только одному классу и, по сути, является его составляющим, удаляя класс, нужно удалить его объекты.

Композиционный вид связи, в том числе наследование и отношение между классом и его объектами, характерен ещё тем, что владелец (родитель) ссылается на своих подчиненных, а не наоборот. Это расходится с UML, в котором наследование показывается стрелочкой от наследника к родителю. Если представить реализацию на программном уровне, то класс будет иметь массив своих объектов, объект «статья» будет иметь массив комментариев и каждый комментарий массив своих комментариев. Каждый класс будет иметь ещё и массив своих классов-наследников. Удаляем родителя, удаляется и массив с его содержимым.

Теперь рассмотрим, как же всё это лаконично представить на таблицах. Чтобы в базе данных хранились объекты разных классов, хранились сами классы, определения свойств и атрибутов, учитывалось наследование классов и, главное, что бы с помощью SQL можно было работать с базой данных, как с объектной!

Реляционная структура

Для достижения гибкого управления и использования данных, необходимо вместе с данными в базе хранить метаданные. Метаданными для объектной модели являются классы. Если будем хранить классы в базе данных (БД), то сможем ими управлять (создавать, изменять) не программируя, например, в разделе администрирования сайта, а также выполнять поиск данных с условиями на метаданные, например, выбирать сущности, принадлежащие классу «А», с учетом наследования классов.

Таблица определяет простой класс

Создав таблицу в базе данных, мы, по сути, определим простой класс. Называние таблицы будет соответствовать имени класса, а колонки определять атрибуты для объектов. Записи в таблице рассматриваются как объекты. Но кроме атрибутов, необходимы ещё свойства объектов.

Таблица для класса «Связь»

Создадим таблицу (link) для связей между объектами. В соответствующих колонках таблицы будут идентификаторы связываемых объектов (primary, secondary), вид связи (kind) и другие характеристики связи. Атрибуты связи необходимы в основном логике программы, осуществляющей объектно-реляционную проекцию (ORM), чтобы сохранить целостность данных и верно выполнить свою задачу по проекции. В созданной таблице будут храниться все виды связей между любыми объектами, классами и даже связями.

Таблица для класса «Сущность»

Так как связывать нужно объекты разных классов, т.е. строки из разных таблиц, то нужно, что бы идентификаторы объектов были уникальны в рамках всей базы данных. Не забываем так же, что связи то же являются объектами, и уникальность идентификаторов распространяется и на связи.

Необходима отдельная таблица идентификаторов, создаем и называем её таблицей сущностей (entity), строки которой будут соответствовать каждой сущности (каждому объекту) модели данных. Главное назначение этой таблицы в уникальности идентификаторов. С появлением таблицы сущностей вырисовывается и реализация наследования классов, когда атрибуты одного объекта хранятся в нескольких таблицах. В таблице entity, кроме идентификатора необходимо ещё указать класс сущности, по которому определять, в каких таблицах «продолжение» объекта. Добавим атрибут class, но будем указывать в нём не имя класса, а идентификатор класса. Таким способ оптимизируется четвертый вид связи «экземпляр», т.е. этот вид связи не будет реализовываться как объект и храниться запись о нём в таблице link. Такое решение связано с нереальностью хранения всех связей на каждый объект, так как объектами являются и сами связи. Дополнительно об этом будет сказано в подразделе «магический треугольник».

Таблица для класса «Класс»

Создаем таблицу для классов (class). Атрибутами класса являются идентификатор, системное имя, соответствующее имени таблицы и, при необходимости, атрибут-признак, можно ли класс наследовать (по мотивам ООП).

Чтобы установить наследование классов и определить свойства для объектов этих трех классов, необходимо создать соответствующие связи, фактически создать записи в таблице link.

Идентификаторы во всех таблицах, кроме entity являются внешними ключами, для реализации отношение 1:1 для сборки объектов размазанных по нескольким таблицам. В таблице entity идентификатор автоинкрементируется.

Обратите внимание, что идентификаторы классов так же должны быть уникальными среди всех объектов и не забываем, что классы должны быть объектами! Это значит, что записи, соответствующие классам, будут и в таблице entity, а в атрибуте class будет идентификатор класса (Б), которым определяются все классы. Подробнее о магии отношений между классами, ниже.

Магический треугольник

Эта статья написана ради рассказа о магическом треугольнике из трех базовых классов, поэтому читаем внимательно.

Уже было сказано, что для создания объекта необходим класс, которым определяются атрибуты и свойства объектов, но, чтобы создать класс, тоже необходим класс (другой)! Естественно, можно сначала создать вручную необходимые классы, а потом запустить систему. Так и придется сделать, но интересно рассмотреть, как между собой взаимосвязаны три базовых класса «Сущность» (entity), «Класс» (class) и «Связь» (link), так как в предложенной реализации нет исключения из утверждения, что у каждого объекта есть класс, и при этом классы то же являются объектами.

Для наглядности будем считать, что у классов есть свойство object, то самое свойство четвертого вида, которое на самом деле не реализуется в виде объектов.

Приступим. Нечто «Класс» необходим для создания классов, им должны определяться свойства и атрибуты для каждого класса, поэтому он назван классом. Его объектами должны быть все классы модели данных, в частности, «Сущность», «Связь» и он же сам – «Класс», чтобы самого же себя сделать классом.

На схеме показано свойство «objects», что оно связано с «Сущностью», «Связью» и «Классом». Но определения этого свойства ещё нет.

«Класс» сам себя и всех других делает классами, наделяя их характерными для классов атрибутами и свойствами – именем, возможностью иметь наследников «extends» и своих объектов «objects». Чтобы свойства «extends» и «objects» появились, должны существовать их определения. Их определения в классе «Класс». Кроме свойств, для классов определяются и атрибуты. Это просто колонки таблицы class.

Свойство «extends» определяется связью на «Класс», а свойство «object» на «Сущность». Потому что наследниками у классов могут быть только классы, а экземплярами, как классы, так и простые объекты.

На схеме появились определения атрибутов и свойства в «Классе» и реализация атрибутов в каждом классе. Нечто «Сущность» и «Связь» стали классами, так как являются объектами класса «Класс». Теперь они то же могут иметь свойства «extends» и «objects».

Класс «Сущность» необходим для определения всем объектам атрибута «идентификатор» («id»). Допустим, атрибут такой определили, создав таблицу entity, но он не кем пока не реализуется, так как у класса «Сущность» ещё нет объектов. У класса «Сущность» пока нет объектов, но появляются два наследника – классы «Связь» и «Класс». Наследуя «Сущность», классы «Связь» и «Класс» перенимают (наследуют) определение атрибута «id».

Отключаем последовательность в воображении и вспоминаем, что у «Класса» уже есть три объекта, а объектами реализуются определенные классами свойства и атрибуты. Что это значит? Это означает, что унаследованное «Классом» определение атрибута «id» от «Сущности» реализуется тремя объектами – ими же самими. «Сущность» реализует атрибут «id» — получает для него значение 1. «Класс» то же его реализует и получает значение 2. То же самое происходит со «Связью», он получает значение 3.

Класс «Сущность» сам себя делает сущностью через наследника «Класс»! Теперь получается, что класс «Класс» всех делает классами, а класс «Сущность» всех делает сущностями (объектами).

Но мы не учли, что просто так связи нельзя создавать. Чтобы определить свойства, необходимо было изначальное существование класса «Связь», так как созданные связи являются его объектами. Ситуация получается посложнее, чем с «курицей и яйцом». Три класса должны появиться и использовать друг друга одновременно. Последовательное появление невозможно.

Не удивительно, что свойство «objects» не реализуется на самом деле в виде объектов. Так как пришлось бы на каждую связи делать связь вида «экземпляр» от класса «Связь», потом на каждую связь между связями и классом «Связь» потом ещё и ещё и так до бесконечности. Оптимизировав реализацию связи «экземпляр», прикрыли ещё одну бесконечность.

Учитывая, что связи вида «экземпляр» не являются объектами, то на последней схеме всего объектов ровно 10. В таблице entity – 10 записей, в таблице class – 3 записи, в таблице link – 7 записей.

P. S.

Спроектированная объектная модель данных получилась достаточно гибкой, с широкими возможностями по структурированию и выборке информации. Остались ещё идеи по расширению её возможностей, но объектность не является залогом супер гибкости .Множественное наследование, нагромождение классов, различные костыли – всё это знакомо в мире ООП.

Но главной и не решенной проблемой оказалась производительность. Сложные SQL, сложности масштабирования через сегментирование данных и другое. Если вы разрабатываете свою ORM, то внимательно отнеситесь к балансу между гибкостью и производительностью. В изложенном варианте наблюдается перегиб в гибкости.

С января 2010 года началась работа над более простой, гибкой и масштабируемой моделью данных. Её основой стала иерархия и некоторые наработки в объектной модели. Но об этом чуть позже.

Всего доброго.