Шуклин Д.Е.


Наивные ОРСУБД

Рассмотрим построение абстрактной объектно-ориентированной СУБД, взяв в качестве отправной точки реляционную СУБД. Пусть строки в таблицах будут экземплярами классов, описываемых заголовками таблиц. Все строки таблицы будут экземплярами данного класса. В этом случае колонка таблицы будет соответствовать полю некоторого класса, значение поля строки в таблице будет соответствовать значению поля экземпляра класса. Эта первая итерация разработки ООСУБД уже позволяет работать с РБД в терминах классов, экземпляров, значений полей экземпляров. До полноценной ОО системы здесь не хватает еще методов, overriding виртуальных методов, наследования и инкапсуляции. Тем не менее, очевидно, что никаких достоинств РСУБД в такой трактовке ОРСУБД не утеряно.

Объектно-реляционные СУБД

Двигаемся далее. Позволяем определять методы, неявно принимающие в качестве одного из параметров строку одной определенной таблицы. Такие методы можно рассматривать как методы класса-таблицы, оперирующие с данными экземпляров класса (строками таблиц). В каждую таблицу добавляем скрытое поле, в котором будем хранить идентификатор таблицы таких функций (vtbl). Теперь по аналогии с ООП возможно ввести одиночное наследование. Так таблица, наследующая некоторую таблицу наследует колонки этой таблицы или что тоже самое – наследует поля класса. Дополнительно наследуется интерфейс класса, определенный в базовой таблице. Наличие идентификатора таблицы виртуальных методов позволяет в такой базе данных реализовать виртуальные методы. Вызов некоторого метода для некоторой строки будет заключаться в определении таблицы виртуальных функций по идентификатору такой таблицы и, затем, в поиске и вызове реализации метода по его имени в таблице виртуальных методов. Базовая таблица будет содержать все экземпляры классов унаследованные от этой таблицы. Наличие vtbl что позволит вызывать реализации overridden методов определенных в derived таблицах строк входящих в базовую таблицу. Итак, в разрабатываемой абстрактной СУБД имеется поддержка концепции наследования и полиморфизма. Так же очевидно, что добавление такой возможности оставило в силе все существующие возможности РСУБД.

Инкапсуляция реализуется в разрабатываемой СУБД путем использования VIEWs. VIEWs позволяют защитить некоторые поля таблиц от прямого доступа, обеспечивая при этом доступ к интерфейсу классов благодаря наличию в каждой строке идентификатора vtbl.

Заметим, что такая реализация ОО идей в среде РСУБД не является новой – в качестве примера уже существующей реализации можно привести Postgree SQL.

Продолжаем. Каждая строка таблицы физически расположена в хранилище по некоторому уникальному адресу. Даже если это еще не реализовано в используемой в качестве прототипа РСУБД, технически возможно обеспечить неизменяемость этого адреса в течении всего времени жизни строки, соответствующей этому адресу. Аналогом такого адреса могут служить bookmarks используемые в современных РСУБД для адресации строк. Наличие уникального и неизменяемого во времени логического адреса строки позволяет нам реализовать концепцию указателей на строки и ввести тип указателя на строку-объект. В совокупности с разработанными ранее концепциями наследования, полиморфизма и инкапсуляции это делает разрабатываемую абстрактную ООСУБД полноценной системой ОО программирования.

Следует заметить, что идея указателей на строки тоже не нова и уже давно реализована в такой известной РСУБД как Oracle.

Рассматриваемые расширения РСУБД оставило без ущерба существующие возможности. Как и ранее, разработанная абстрактная ОРСУБД включает в себя РСУБД как частный случай.

Сетевые ООСУБД

Продолжаем разработку. В разработанной ОРСУБД таблицы представляют собой коллекции bookmarks указывающие на некоторые строки. Один и тот же экземпляр строки может находиться сразу в нескольких таблицах. Один экземпляр в таблице, экземпляром класса которой является данная строка и по одному экземпляру этой строки во всех базовых таблицах-классах. Интерфейс, поддерживаемый строкой (колонки + методы) соответствует классу, экземпляром которого является данная строка. Важным является то, что этот интерфейс не является эквивалентным интерфейсам базовых таблиц. Он шире, чем интерфейсы базовых таблиц, однако, этот интерфейс является совместимым с интерфейсом таблиц, в которые входит данная строка. Так плавно переходим к понятию интерфейса и абстрактных классов, давно используемых в ООП.

Это очень важный шаг, так как теперь возможность принадлежности некоторой строки к некоторой таблице определяется совместимостью интерфейса этой строки с интерфейсом, определенным для некоторой таблицы. Это позволяет сделать следующий шаг – рассматривать таблицы не как физическое хранилище для строк, а как коллекции экземпляров некоторых классов, интерфейсы которых совместимы с интерфейсами, определенными для этих коллекций. Обратим внимание на потенциальную независимость интерфейса, определенного для таблицы и интерфейса, определенного для строки. Не смотря на то, что разработанная система, в некотором частном случае может функционировать так же, как и РСУБД с которой была начата разработка, таблицы в разработанной СУБД более не являются отношениями в классическом смысле. Строки таких таблиц- коллекций это уже не подмножество декартового произведения определения интерфейса на область возможных значений интерфейса. Да, коллекции в разработанной системе при желании можно трактовать как подмножество декартового произведения определения интерфейса на область возможных значений интерфейса. Это делает РСУЮД частным случаем разработанной. Но, учитывая полиморфизм экземпляров- строк обеспечивающих доступ к своим внутренним структурам через public интерфейсы в такой СУБД появляется возможность совместного использования некоторых интерфейсов (колонок и/или методов) несколькими таблицами-коллекциями. Такие таблицы уже нельзя считать классическими отношениями, т.к. при изменении полей строк через одну таблицу, будут так же изменены поля этих же строк во всех других таблицах содержащих измененные строки.

Рассмотрим интерфейс более подробно. Интерфейс строки состоит из определения сигнатур методов, которые применимы к данной строке, а так же из определений полей-колонок унаследованных этой строкой. Ранее, допустив возможность наследования таблиц, была создана возможность одновременного включения одних и тех же колонок-полей в разные таблицы, что обеспечило полиморфизм строк. Как следствие, отдельная строка, наследующая множество интерфейсов имеет значения для колонок, описанных во всех унаследованных интерфейсах. Однако только то подмножество значений может быть доступно через некоторую таблицу, которое является пересечением множества всех колонок, унаследованных данной строкой и множеством всех колонок определенных как интерфейс для данной коллекции-таблицы. Что в таком случае есть строка? Строка это подмножество декартового произведения всех возможных колонок на все возможные значения этих колонок. Здесь получен интересный и неожиданный результат, несмотря на то что разработанная абстрактная ОРСУБД включает в себя РСУБД как частный случай, тем не менее, не таблица а строка таблицы является отношением .

Итоги

Подведем итоги. В процессе разработки никакие возможности РСУБД не были удалены из разрабатываемой абстрактной СУБД. В процессе разработки новые возможности только добавлялись. Разработанная ОРСУБД включает в себя РСУБД как частный случай. Строки-экземпляры наследуют значительное количество колонок, публикуя лишь некоторые через интерфейсы таблиц. Как строки, так и колонки могут одновременно входить в несколько разных таблиц. Таблицы являются коллекциями экземпляров объектов и более не являются классическими отношениями. Можно сказать, что экземпляры_классов-строки представляют собой узлы, поля этих экземпляров представляют собой атрибуты узлов. В том числе поля ссылочного типа хранят указатели на другие узлы. Сами узлы могут иметь миллионы атрибутов, публикуя лишь некоторые через интерфейс коллекций. Атрибуты могут иметь как скалярные значения, так и ссылки на другие узлы, тем самым образуя сеть. Обеспечивается наследование, полиморфизм и инкапсуляция в пределах VIEWs.

Итак, в итоге этой разработки была получена абстрактная объектно-ориентированная сетевая система управления базами данных, которая включает в себя все возможности реляционной СУБД как частный случай.

Возможность эффективной реализации такой объектно-ориентированной сетевой системы управления базами данных требует дальнейших исследований.

mirего коллективно уже как-то выдралиДа ну? ))) Что то я ни разу от вас лично ничего конструктивного в плане критики не услышал. Как фсегда сплошные личные наезды вместо аргументов. Уверен и на этот раз контсруктив если и будет то не от вас и в минимальном оъеме ((( Ну то не страшно, проект СООБЗ продолжает развитие не зависимо от личного мнения некоторых персоналиев )))

mirКонструктивная критика, по вашему, это безоговорочное согласие? Под конструктивной я понимаю критику направленную на улучшение критикуемого предмета, по возможности с конкретными предложениями по усовершенствованию и исправлению выявленных недостатков.

Про оракл вам уже написали, а про букмарк лукап прочитайте в бол.

mirЭти "оговорки" полностью меняют суть дела. А суть состоит в том, что хотя значение rowid в течение сеанса работы и не изменится, но все руководства говорят, что его нельзя сохранять для последующего использованияЯ фигею с вашей ограниченности. Где в этом топике шла речь о практическом исспользовании конкретного оракла? Оракл был привиден лишь как пример существования аналогичной концепции.

Впрочем не дождусь вашего комментария про оракловские Object References (REF)

mirЕще раз: в современных РСУБД нет поддержки таких "bookmarks", как ему бы хотелось.С этим я соглашусь. Если учесть все тонкости вопроса и отойти от темы, обсуждаемой в этой ветке, то действительно таких как Мне бы хотелось нет, этим и была промотивированна необходимость разработки собственной субд поддерживающей именно такую как Мне бы хотелось идентификацию объектов. И это правильно.