Цитата: adolfus от 17.09.2019 10:00:03На самом деле либо объектная модель данных, либо реляционная. Отобразить таблицы реляционной модели в структуры объектной пока никак не получается – проблема есть такая "object-relation mapping". Вот когда ее математики решат, возможно тогда словосочетание "объектно-реляционный" наполнится реальным смыслом, а так пока всего-лишь попытки забить колышки на участке, который кажется золотоносным.
"Всё дело, в волшебных пузырьках!", как нас заверяла реклама одной шоколадки.
"Реляционная" СУБД - та, где имеется чёткое соответствие отношений хранимых объектов (идентификатор или комбинация признаков его составляющая). Такая СУБД вполне спокойно хранит любые объекты - в том числе и бинарные, в том числе и классы (например тот же XML имеющий свои методы). Современные СУБД расширяются внешними и внутренними процедурами, представляющими тоже объекты, в том числе и бинарные. Есть типизация, абстракция, преобразование типов - достаточно признаков чтобы назвать объектно-реляционной СУБД?
Почитаем вики
объектно ориентированная база данных.
Сравним признаки?
Поддержка сложных объектов. В системе должна быть предусмотрена возможность создания составных объектов за счёт применения конструкторов составных объектов. Необходимо, чтобы конструкторы объектов были ортогональны, то есть любой конструктор можно было применять к любому объекту. Поддержка сложных объектов есть. Оговорка про конструкторы - не к месту. СУБД хранит и предоставляет доступ к данным, это не хост исполняемых процессов. Даже если там сохранены объекты как есть - они в любом случае сериализованы. И в любом случае их нельзя хранить "полностью в готовом виде" - так как при извлечении и размещении в памяти - должны быть заданы адреса в оперативке - это и есть "создание объекта определённого класса" и это опять таки вопрос исполняемого кода, а не хранения данных.
Поддержка индивидуальности объектов. Все объекты должны иметь уникальный идентификатор, который не зависит от значений их атрибутов.Это скорее свойство реляционных.
Поддержка инкапсуляции. Корректная инкапсуляция достигается за счёт того, что программисты обладают правом доступа только к спецификации интерфейса методов, а данные и реализация методов скрыты внутри объектов.Чем плоха модель безопасности обычной СУБД? Монопениссуально.
Поддержка типов и классов. Требуется, чтобы в ООБД поддерживалась хотя бы одна концепция различия между типами и классами. (Термин «тип» более соответствует понятию абстрактного типа данных. В языках программирования переменная объявляется с указанием её типа. Компилятор может использовать эту информацию для проверки выполняемых с переменной операций на совместимость с её типом, что позволяет гарантировать корректность программного обеспечения. С другой стороны класс является неким шаблоном для создания объектов и предоставляет методы, которые могут применяться к этим объектам. Таким образом, понятие «класс» в большей степени относится ко времени исполнения, чем ко времени компиляции.)Смотрим пункт №1. Только в разрезе времени выполнения, а не в разрезе управления данными.
Поддержка наследования типов и классов от их предков. Подтип, или подкласс, должен наследовать атрибуты и методы от его супертипа, или суперкласса, соответственно.
Перегрузка в сочетании с полным связыванием. Методы должны применяться к объектам разных типов. Реализация метода должна зависеть от типа объектов, к которым данный метод применяется. Для обеспечения этой функциональности связывание имен методов в системе не должно выполняться до времени выполнения программы.Этого нет и врядли когда то будет в обычных СУБД. Нахуа?
Вычислительная полнота. Язык манипулирования данными должен быть языком программирования общего назначения.Ну вот обычная библиотека - это ведь СУБД? В ней хранят книги - это объекты? Составные? Сложные? И метод у каждой книги есть свой (Book.Дряхлеть) ну это тот что присущ объекту самому, без посторонних вмешательств. Какая у библиотеки вычислительная мощность? 3 калькулятора, если по этажам собрать?
Набор типов данных должен быть расширяемым. Пользователь должен иметь средства создания новых типов данных на основе набора предопределённых системных типов. Более того, между способами использования системных и пользовательских типов данных не должно быть никаких различий.Смотрим пункт (1).
Итого на мой взгляд: вся вот эта муть написанная про "чистые" ООСУБД = сова натянутая на глобус. По тому, что смешаны понятия управления данными и программных действий над ними производимых. До тех пор пока мы не доживём до появления саморегулируемых цифровых данных. Все СУБД которые занимаются именно ХРАНЕНИЕМ и УПРАВЛЕНИЕМ доступом к данным - можно смело отнести в объектно-реляционным, в том понимании, что они способны хранить сложно-составные данные (сериализованные объекты) и хранимые отношения между ними (те связи которые присущи объектам вне контекста их последующего исполнения).