авторЕсли рассмотреть мою СООБЗ то объекты в ней хранятся вовсе не в виде таблиц, а в виде группы деревьев.А что - данные в этих деревья независимы от физ. уровня?

В РМД все данные и все манипуляции с данными огорганизованы исключително на основании данных, явно определяемых пользователем . Для того, что бы обратиться к некоторой записи мы должны знать имя переменной отношения (оно задается пользователем) имена атрибутов для поиска (задаются пользователем) и значения по которым производится поиск записи (также определяются пользователем и пользователь же ранее эти записи вставил). Замечаете какая фишка? - все манипуляции с данными происходят исключительно на основании только тех данных, которые сам пользователь определил, ввел в систему. Система же определяет лишь тип – отношение(и конечно же домены). А деревья - они привязаны к физическому размещению. Для манипуляций с данными они пользуют данные, которая определяется не пользователем, а уже существуют на физическом уровне, а именно - адреса(для ОЗУ) или о смещениях от начала файла (для файлов на диске). Эта информация о физическом размещении и, таким образом, организация данных виде деревьев зависит от физического уровня.

К чему сравниваю деревья и отношения? К тому, что многие думают, что основное преимущество РМД - представить данные в виде отношений ( что близко банальным и понятным для пользователя таблицам). Однако ИМХО преимущество РМД не только и даже не столько в этом. Гораздо важнее то, что данные, представленные в таком виде, являются абсолютно независимыми от организации на физическом уровня. ИМХО РМД - есть единственная модель данных …хотел написать "позволяющая делать то-то и то-то", но понял, что фраза "единственная модель данных" ужа сама по себе подразумевает самодостаточность данных. Если Вы можете доказать обратное, т.е. РМД не единственная модель данных (где достаточны только данные определяемые пользователем)– WELCOME!!! иа иначе все ваша аргументация "деревья – не деревья, внутри и снаружи" на меня не подействует.

Кто-то тут упомянул Турчина. Я этим несколько лет назад тоже им заморачивался. Я согласен, что РСУБД реализуют некий метасистемный переход, но цель этого перехода – не иная организация данных, а создание системы хранения, независимой от физической организации данных. Любая система, которая хочет быть таковой, должна так или иначе, на каком-то уровне строиться на основании данных, организованных в виде множества значений отношений, а иначе она будет каким-то образом зависить от организации данных на физическом уровне, и эта зависимоть будет постоянно вылазить и мешать . Тех, кто считает такую независимость неважной, я отсылаю в детский сад, где они могут на досуге прочитать книжку Дж.Мартина "Организация баз данных в вычислительных системах" (Изд. 2-е 1980 «Мир»). Книга старая но, попреженму актуальная. Особенно она будет полезна для людей, которые страдают ОО(что в общем то непредосудительно) и отвергают РМД (что ИМХО абсолютно неверно).

По поводу трех таблиц. :) Конечно я не знаю, как оно там в ООСУБД все устроено. Но ведь есть "объекты в памяти" и "объекты на диске"? Значит существует отношение между множеством адресов в памяти и набором позиций в файле. Мягкие ссылки как то реализуются? значит есть отношение между множеством физических адресов и мягких ссылок. Индексы есть (или будут?) Значит есть отношение между индексируемым атрибутом и ссылкой. То есть конечно таблиц как таковых может и не быть, но перечисленные отношения то есть... хотя бы формально? А если мы попросим систему найти объект по какому нибуть непроиндекированному атрибуту, она (опять таки формально!) должна такое отношение создать? Ну так не проще формально на каком то уровне эти данные так и организовать? Ведь на самом то деле она никак никому не мешает... Речь идет о трансляции команд языка высокого уровня в набор опреаций манипулирующих данными на физическом уровне, и эти промежуточные представления нужны только для того, что бы понять, как транслирвать команды, при условии, что ланные реально независимы от физического уровня.

2 Alexey Rovdo

авторА может правильнее смотреть на объектные системы как на конструктор для создания моделей? Т.е. используя ООСУБД мы создаем модель данных для конкретного приложения?
ИМХО да. Я бы выразился (используя терминологию того же Турчина) что OO есть парадигма не столько системы, сколько метатсистемного перехода. То есть есть набор типов, описываемый какой-то моделью, и используя ОО-средства и конструкции мы можем на его основе описать другой набор типов. Если модель описывает набор типов, то ОО-парадигма дает возможность описать любой такой набор на оснорвании заданого. Соответсвенно ОО система есть ИМХО система обладающая средствами для того, что бы на основании заданного ограниченного набора типов описать другой набор типов. То есть ОО-парадигма и понятие "модель данных" ортогональны вообще в принципе. Соответсвенно каим то образом противопостовлять их не нужно.

авторОбъектные СУБД не противостоят реляционным во всем. Есть ряд технологий, которые они - напротив - заимствовали у реляционных. Однако следует понимать, что будучи очень похожими на физическом уровне, ООСУБД гораздо богаче на уровне логическом. Т.е. в ООСУБД на физическом уровне вполне реализуемы все те же решания, которые есть в РСУБД (и если сегодня они еще не развиты до той же степени, что и у ведущих РСУБД, то это только вопрос времени). Логика ваших рассуждений сводится к тому, что раз уж они выглядят похоже на физическом уровне, то и нет смысла в отличиях на логическом уровне - РСУБД форева. Но ведь это не конструктивный подход. Ну... это вы ошибаетесь. Это совсем не логика моих рассуждений. Во первых я никогда не говорил РСУБД форева :). Я говорил РМД форева - это было(вопрос в том как её использовать и понимать). Но Ваши далнейшии высказывания к моим рассуждениям никак не относятся.

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

авторДля одних задач реляционная модель подходит наилучшим образом, а для других оптимальна другая модель. Повторю, что какое либо противопоставление OO и РМД ИМХО неверно. Зная Ваше понимание ООСУБД, я бы конец Вашей фразы трактовал как "...для других целей могут быть оптимальны системы хранения, в которых данные зависят от физической организации". С этим я не спорю. Но ОО здесь не при чем.

авторУв. shuklin.

shuklin Естессно независимы. А как иначе оно б работало? БД объектов остается логически целостной не зависимо от колличества перезапусков ядра системы и циклов сборки мусора.
Это Вы так независимость данных понимаете? Тогда мое пожелание почитать в саду книжку Мартина к Вам относится абсолютно и однозначно. :)

авторВ последней версии Cerebrum аналогично. Кстати, это основное концептуальное изменение, по сравнению с VNPI2 (1999)...тогда зачем Вам сборка мусора? Или появляется что-то, что есть в системе, но Вы не имеет к этому доступа?... а система доступ имеет, т.е. "знает" про это?

авторИМХО та степень зависимости от уровня хранения, которой обладает РМД и есть ее подавляющий недостаток. Она слишком большая! Да-да, РМД "совсем беремная". А ваш "мозг" - немножко. :)

авторНеужели никто не видит, что уровнем физического хранения для РМД являются таблицы?КонеЧно! если рассматаривать диск в микроскоп, то их можно увидеть воочию. :) Ну Вы подсталяться горазды. Про "таблицы" в "РМД" да еще "на физическом уровне".... это Вам как кандидату наук прямо таки уже непростительно....

авторПо-моему, объектной модели данных, аналогичной РМД, не может существовать... ИМХО -золотые слова. ОО-парадигма - это удобная парадигма РЕАЛИЗАЦИИ по сути любых типов. А модель данных - это СПЕЦИФИКАЦИЯ конкретного множества конкретных типов данных.