с127 shuklin В теоретическом плане могу сослатся на свои научные статьи, ...

Сошлитесь.


www.shuklin.com

Мимо пробегал... Начиная с "Уровень сетевой объектно-ориентированной базы отвечает за создание экземпляров пользовательских объектов, а так же за работу с атрибутами объектов..." становится грустно. Например, откуда из "создания экземпляров и работа с атрибутами" следует, что уровень явлется сетевым.

Понятия сетевая БД, распределенная БД и клиент-серверная БД - разные понятия. В данном случае сетевая означает то, что данные в БД организованы не в таблицы а в сеть (граф с однонаправленными раскрашенными ребрами).

И что в этом печального ? ;)

Мимо пробегал...
Далее, когда эту OO базу начинают каким то образом привязывать к таблицам становиться совсем тоскливо. Насколько я понял, объекту таки соответсвует строка...

Да, строка разумеется объект - база то ОО ориентировананя. Вот если бы строка не была объектом - было бы грустно. Все строки - объекты. Но все объекты - вовсе не строки. Строка - частный случай. Опять не ясна ваша печаль.

Мимо пробегал..."Используя данную разработку программист полностью свободен создавать собственные таблицы, содержащие объекты-строки собственных типов" -ИМХО это не откровение. Даже наоборот. В сотый раз на те же грабли.

А где грабли? РБД пашет хреново. Эти идеи пашут лучше. Какие проблемы?

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


Граф это общее название. Частными случаями графа например являются дерево и сеть. ООБД вполне может быть деревом и не быть сетью.

Мимо пробегал...Более того, я как то не представляю себе, что бы объекты были бы НЕ ОБЪЕДЕНЕНЫ в какую нибудь структуру (ну ни могут они в воздухе висеть). В данном случае не получается ли "масленное масло"?


Если я пральна понял, то у версанта например объекты организованы в дерево. И прямая навигация работает только в пределах этого дерева (?).

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

Так что в терминологическом плане все честно, никаких тавтологий. Кстати, тавтологии применяются в самоописателе таблиц ;) И благодаря тавтологиям - никаких парадоксов рассела.

Мимо пробегал...
Строка - это объект.
Да
Мимо пробегал...Значит у нее есть OID и такой же OID есть у таблиц(объектов), у атрибутов(объектов) и т.п.....
Да
Мимо пробегал...
А могут там храниться такие объекты, что бы они были не строками, не таблицами, не атрибутами, а.... просто объектами?
Да, кстати, как справедливо заметил Дейт, объекты которые не имеют OID - что то типа объектного представления просто так реализованны быть не могут. Если у них нет ID то они не полноценные объекты, а если у них есть ID то они не представления. Тоесть с JOIN и подзапросами имеет место быть логическая трудность. С другой стороны, ООБД расчитаны на задачи требующие навигации а не поиска. Например все алгоритмы которые я принимаю к разработке в преедлах данного проекта принципиально расчитаны только на навигацию . Никаких поисков. Следовательно в РБД работать эти алгоритмы будут хреново, а для сетевой ООБД самое то.

И еще, не все объекты обязаны иметь OID. Так что объектные вью сделать можно (и частично они уже сделаны, причем совместимыми с DataView). Так что проблему поднятую Дейтом обойти пусть и не оч красиво но можно.

Мимо пробегал...
Но вот фраза "Не обязательно создав объект помещать его строкой в какую то таблицу" означает, что произвольный объект таки соответсвует строке.?...
коммент, не все объекты - строки или таблицы или еще что нибудь более специфическое. тоесть произвольный объект имеет право но не обязан соответсвовать строке
Мимо пробегал...
то есть получается, что таблица - это объект, но с другой стороны - таблица же - множество объектов, что может соответсвовать контейнеру, или классу, или типу, или чему то еще что обозначает множество. Но пардон, раз таблица - это объект, значит мы можем поместить ее в качестве строки в другой таблице?...
Почему можем, все таблицы являются строками таблицы "Tables" И даже сама таблица "Tables" является собственной строкой ;) Гораздо интереснее ситуация с аттрибутом "Name" который описывает собственное имя является строкой таблицы "Attributes" и колонкой таблицы "Attributes" и имеет значение в таблице "Attributes" = "Name" для строки которой же сам и является ; ))))

Мимо пробегал...
Вы поймите - это не я брежу! это я пытаюсь осознать всё, что вы наваяли в Вашем "Занятии «Streams-01»"!!! Вы поймите, что когда за фразой "Объектно-ориентированная база позволяет хранить не строки таблиц, как это принято в табличных базах данных, а экземпляры объектов" через несколько абзацев следует фраза "Каждая строка некоторой таблицы представляет собой экземпляр объекта" у любого здравомыслящего человека, находящегося хоть немножко в теме, начинает ехать крыша! Сначала мы отказываемся от строк, а потом резко начинаем их использовать!!! Как тут не погрустнеть?

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

Мимо пробегал...
Опять же - ежели бы вы говорили о такой OOcbcntvt хранения, каковой является например Версант этого вопроса не возникло бы. Там есть объекты, которые можно хранить долговременно - и все.

Этот тезис в полной мере относится и к VNPI (namespace Cerebrum.Runtime)
Объекты там храняться и все.

Мимо пробегал...
"Все" здесь означает, что объект описывается как хранимый и может храниться, и нет никаких таблиц, объектов БД и объектов в БД (таблицы, атрибуты, строки). Объект просто храниться -и все (ИМХО это по крайней мере понятно).

Да. Это про Cerebrum.Runtime. А вот на основе Cerebrum.Runtime и на основе "объектов и все" реализовано подобие реляционнй (табличной БД) - Cerebrum.Integrator. Для удобства. Вот в этом примере "все" пропадает.

Так же это "все" пропадает в примере про нейроны. Но нейроны это совсем другая история. Они кстати к Cerebrum.Integrator имеют весьма далекое отношение, практически никакого.

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

С одним я согласен - круто будет видно только после реализации нормального приложения для пользователя. Полезного приложения в каком то специфическом бизнес-сценарии. Ну этот момент я полагаю будет. Но не в течении ближайших недель. А до того момента мы будем вынуждены рассматривать потенциальные и неочевидные приемущества.

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

Мимо пробегал...Но пардон, раз таблица - это объект, значит мы можем поместить ее в качестве строки в другой таблице?...


Забыл добавить. Один и тот же объект имеет право не быть строкой ни в одной таблице или быть строкой в нескольких таблицах одновременно. Учитывая текущую реализацию вы имеете право добавить табицу "Tables" строкой в таблицу "Attributes" а аттрибут "Name" строкой в таблицу "Tables". Представление данных это вполне выдержит. Если вести речь о пользовательских объектах (а не о предопределенных "Types", "Tables", ...) то это относительно допустимо - надо более детально сценарии рассматривать, возможно что то подфиксить в cerebrum придется, благо эта часть Open Source. Если мы говорим именно о описаном сценарии размещения аттрибута в таблицах - ну во первых смыла это не имеет вовсе, во вторых текущая реализация Cerebrum.Windows.Forms & Cerebrum.Integrator на такой сценарий не расчитана. После такой операции БД придется выкидывать и заводить новую.

shuklin Мимо пробегал...Но пардон, раз таблица - это объект, значит мы можем поместить ее в качестве строки в другой таблице?...

Если добавлять в одну и ту же таблицу один и тот же экземпляр объекта несколько раз, или добавлять один и тот же экземпляр объекта в разные таблицы - в общем случае такой сценарий может привести к непредсказуемым последсвиям.

Однако данная возможность является полностью законной с точки зрения представления данных и может оказаться полезной во многих случаях. В этом случае пользовательский код, который работатет с конкретной таблицей должен быть рассчитан на то, что таблица содержит объекты различных типов либо несколько ссылок на один и тот же экземпляр объекта. Добавление объектов разнличных типов в одну таблицу применяется в таблице UiServices. Если все экземпляры таких объектов унаследованы от одного базового типа, который ожидается пользовательским кодом, то будет иметь случай стандартного полиморфизма. Таблица UiServices хранит пользовательские объекты, унаследованные от класса Cerebrum.Windows.Forms.Reflection.UiServiceDescriptor

vadiminfoКакой?

Вас интересует сеть вообще или конкретная реализация в ООСУБЗ Cerebrum.

Тему "сеть вообще" я буду считать в данном контексте оффтопиком ;)

в связи с этим.

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

vadiminfo
Т.е. отличается от просто деревьев наличием петель?
Т.е. отличается от просто графа тем что узел - тоже граф.
Подробнее про иерархические семантические сети в литературе авторства и под ред. Попова.

vadiminfoВ чем ее активность должна проявляться? Например, что она делает по ночам?
Про активные семантические сети - за подробностями к Амосову ;)

vadiminfo
Что за самоописание таблиц? Пример там есть? И тавтологии пример, если можно?
Сколько можно ссылку на cerebrum постить? опять ведь спамером объявите ;)

vadiminfo
И как без товталогии там мог бы появиться парадокс рассела?
Как раз с тавтологией ему появится труднее ))

vadiminfo
Мне просто так интересно. ... (множество всех множеств, которые не являются элементами самих себя)

В cerebrum на такой парадокс тянет утверждение: таблица всех таблиц, которые не являются строками самих себя

Опять сползли на абстракции )) что слабо exe запустить и сказать мол в таком то случае экзепшин выпадает - сакз )) или что в такой то функции параметров мало )))

c127
Я пару дней назад специально просил: подробнее. Где Вас научили так ссылаться, вроде в АН другие требования к ссылкам. Хоть название статьи указывайте.


Так достаточно? Или детализировать далее?

http://www.shuklin.com/ai/ht/ru/cybernetics.aspx
http://www.shuklin.com/ai/ht/ru/informatics.aspx

c127
shuklinМодель хранения данных в cerebrum представляет собой граф с раскрашенными ребрами, узлы графа так же представляют собой граф с расскрашенными ребрами.

Что такое граф с раскрашенными ребрами? Где почитать? Или сами объясняйте или давайте ссылки.


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

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

Семантическая сеть это граф узлам и/или ребрам которого назначены семы.

Иерархическая семантическая сеть - семантическая сеть у которой узлы имеют внутреннюю структуру в виде некоторого графа.

Alexey Rovdo Автор неоднократно продемонстрировал (и продолжает демонстрировать) незнание им базовых возможностей наиболее распространенных ООСУБД (Versant, в частности)... Для автора вероятно будет обидно, если я назову его "дилентантом".

И такую вероятность исключать нельзя ;) Однако отсутствие с вашей стороны конкретных замечаний о моих ляпах и домыслах на предмет достоинств ООСУБД Versant заставляет меня подозревать что домыслы эти весьма обоснованы ;)

4321 А что такое "раскрасска" (т.е. каждое ребро у вас кроме вершин и направления имеет еще и "цвет", или же даже множество "цветов")? Т.е. насколько сложным объектом является "ребро" вашего "сем.-блаблабла-графа"

В моей разработке каждое ребро имеет только один "цвет". Это все тот же OID.
Таким образом можно расскрасить ребра в "цвета" экземпляров объектов. Или другими словами иметь объекты соответствующие цветам ребер. Если нужно имитировать множество цветов, то надо делать несколько ребер разного "цвета".

4321да, и еще вопрос, имеет ли ваше понимание объектов нечто общее с http://packin.ru/abrial/glo.htm#object (и вааще ваши "хранилища" не с точки зрения реализации, но с т.з. т.с. "предназначения")

Да. предназначение очень близко. Например обе системы рассматривают словарь Зализняка как возможную область применения.

vadiminfoА это малопреодолимая пропасть для Cerebrum, если он всего лишь ООСУБД. ... Тем более shuklin предполагает развивать свою работу в сторону поддержки transactions, versioning & concurency. Т.е. функции СУБД еще нуждаются в улучшении и потому она, возможно, еще не совсем СУБД.

Или еще что в этом роде. А сейчас, мне кажется, важно именно все что касается вопроса СУБЗ.

Да, многие фишки которые есть у промышленных СУБД еще отсутствуют. И эти фишки так же важны для СУБЗ как и для СУБД. Поэтому я считаю более важным именно сторону вопроса, относящуюся к СУБД (при этом СУБЗ гораздо интереснее в плане дискуссии).

Кстати как СУБЗ Cerebrum требует не меньшей доводки чем как СУБД.

В связи с чем давайте считать Cerebrum - СУБД/З с крайне ограниченной областью возможного применения.

И главный вопрос, который волнует меня : Какие свойства Cerebrum требуют модификации и разработки в первую очередь, чтобы область его применения стала менее ограниченной ? Вот за развитие дисскуссии в этом ключе я буду крайне благодарен. Так как это позволит мне определить главные приоритеты по развитию заявленной идеи.

vadiminfoУ меня ничего нет таких авторов. Кто они такие? А есть ли что в каких-то толстых книгах, желательно буржазных авторов, но в русском переводе.

Амосов Н.М., Касаткин А.М., Касаткина Л.М., Талаев С.А. Автоматы и разумное поведение. Опыт моделирования. - Киев: "Наукова думка", 1973. - 261с.

Попов Э. В. Общение с ЭВМ на естественном языке. - М.: Наука. Главная редак-ция физико-математической литературы. 1982. - 360 с.

Попов Э.В. Экспертные системы: Решение неформализованных задач в диалоге с ЭВМ. - М.: Наука. Гл. Ред. физ.-мат. лит., 1987. - 284 с.

vadiminfoТ.е. там что - таблы это нечто большее, чем они обыкновенно считаются? Т.е. возможны таблы, которые являются строками самих себя? И спасает только некая товтолия?
Да, на все вопросы. Детальнее можно посмотреть Cerebrum Lessons : Streams-01 ( http://www.shuklin.com/ai/ht/ru/cerebrum/lessons/Cerebrum.Samples.Streams-01.aspx )

vadiminfo Или просто синтаксис такой, что можно написать все что хочешь?
Ващето синтаксис там не причем. Это модель представления данных такая. А языка запросов еще нет. И синтаксиса нет. Есть C#.

vadiminfoНет какого-нибуть контроля уникальности имен? Но это как бы разные объекты с одним именем.

Ага - контроля нет. Просто объекты.


vadiminfoСтруктурно то может быть табла строкой самой себя, если убрать товтологию?

Но ведь в чем тавтология, что таблица есть строка в таблице. А таблица Tables является строкой самой себя. Тавтология это следсвие такой возможности, а не причина. А следсвие убрать нельзя.

4321Вы всегда отвечаете только на часть вопроса?

Да. Я отвечаю только на те вопросы на которые могу дать конструктивные ответы.

vadiminfo shuklin
А таблица Tables является строкой самой себя.

Не въехал. У любой таблицы есть заголовок, а у строки его нет. Потому если в Tables (она типа словарь БД), есть описание и самой себя, это не значит, что она есть строка самой себя. У них разная структура. Например, система вообще не "понимает" смысла строки (хоть там и описывается Tables), но отличает строку от таблицы, в том числе и Tables. Мне так кажется.

Ну мы же в этой ветке не именно cerebrum обсуждаем. Я описываю его внутреннее устройство. Ваш тезис выше к cerbrum отношения не имеет.

Потому если в Tables (она типа словарь БД), есть описание самой себя, это значит , что она есть строка самой себя. Так как это описание есть тот же самый экземпляр объекта. И таблица Tables и строка Tables в таблице Tables - это один и тот же экземпляр одного и того же класса TableDescriptor и он расположен по одному и тому же адресу в памяти.

У меня не РБД а ООБД. И таблицы не соответсвуют общепринятым нормам РМД. Так в таблице Tables есть две колонки - SelectedAttributes & SelectedComponents. Значениями этих колонок являются списки OID объектов - описателей колонок таблиц и объектов - строк таблиц. Тоесть я нарушаю уже 1NF. И это правильно ;)

vadiminfoКстати, Вы думали о том, что есть дилемма называть эту таблицу Tables или Table? Первое ведь может наводить на мысль, что в каждой строке описывается несколько таблиц - множественное число.

Таблица Types содержит все типы - по одной строке на тип. Таблица Attributes - аттрибуты (колонки) по одной строке на аттрибут. Таблица Tables - список всех таблиц в системе (Types, Attributes, Tables ...) по одной строке на таблицу. Имхо название самое то.