Привет Всем!

На общее внимание и обсуждение выносится концепция синонимии/омонимии объектных идентификаторов в ООБД Cerebrum. Возможно кто то найдет в ней дырки или возможность к усовершенствованию. Это поможет мне сделать свою ООБД более эффективной и полезной.

Важной особенностью СООБЗ Cerebrum является отличие в адресации объектов по сравнению со стандартом объектных баз данных ODMG. По аналогии с естественным языком, когда одно и то же слово в разных контекстах имеет различное значение, и когда разные слова в некотором контексте имеют одинаковое значение, в ООБД так же возможно адресовать в разных контекстах разные экземпляры объектов с помощью одного и того же идентификатора, либо в некотором контексте адресовать один и тот же экземпляр с помощью разных идентификаторов. В этом случае каждый экземпляр persistent объекта определяет собственный контекст разадресации. В пределах любого экземпляра допустима только синонимия - когда разные ИД адресуют один и тот же внешний по отношению к текущему экземпляр другого объекта (в том числе и этого же самого если имеем ссылку на себя). Омонимия в пределах контекста разадресации не допускается. С другой стороны в БД столько контекстов сколько экземпляров. Поэтому в пределах всей БД каждый экземпляр может иметь практически неограниченное количество различных идентификаторов, без какого либо противоречия и конфликтов.
В Cerebrum каждый объект, так же как и в ODMG адресуется с использованием мягкого указателя или ID объекта Cerebrum.Runtime.NativeHandle . Получение указателей на экземпляры объектов, внешних по отношению к некоторому текущему объекту, производится в пределах контекста текущего объекта. Объект может адресовать только те объекты, с которыми он установил связь. Каждый связанный с текущим объект имеет идентификатор. Каждый уникальный идентификатор определяет в пределах текущего объекта экземпляр связанного с ним объекта. В пределах текущего объекта каждый идентификатор может адресовать только один экземпляр. Однако важным отличием от ODMG является возможность иметь в пределах некоторого объекта несколько различных NativeHandle адресующих один и тот же экземпляр. В пределах некоторого заданного объекта несколько разных идентификаторов могут ссылаться на один и тот же экземпляр объекта. В отличие от ODMG, где каждый объект имеет только один уникальный идентификатор в Cerebrum один и тот же объект может иметь различные идентификаторы. Если рассмотреть не один экземпляр, а всю базу, то по аналогии с явлениями естественного языка синонимии и омонимии в СООБЗ Cerebrum возникает явления синонимии и омонимии идентификаторов объектов. В различных контекстах определяемых различными экземплярами объектов один и тот же идентификатор объекта NativeHandle может адресовать как разные экземпляры, так и один и тот же экземпляр. Это явление можно назвать омонимией объектных идентификаторов. Так же как и в естественном языке при омонимии один и тот же идентификатор в разных контекстах одной и той же базы данных может адресовать как различные, так и одинаковые экземпляры объектов. Как в одном и том же контексте, так и в разных контекстах различные идентификаторы могут ссылаться на один и тот же экземпляр объекта. В этом случае возникает явление синонимии объектных идентификаторов, когда один экземпляр может иметь в пределах базы множество различных идентификаторов - синонимов.

Расширенная поддержка синонимии/омонимии объектных идентификаторов может использоваться для различных целей. В том числе для идентификации типа связей, при построении семантических и иерархических семантических сетей, для идентификации атрибутов объектов, реализации объектных views & joins.

Определенный атрибут объекта должен иметь идентификатор инвариантный к экземпляру объекта. Или различные экземпляры одного и того же класса должны получать различные экземпляры своих атрибутов при разадресации идентификатора атрибута. Так же желательно иметь возможность найти метаинформацию, описывающую атрибут по идентификатору атрибута. Рассмотрим пример реализации атрибутов объектов. Пусть идентификатор атрибута равен 1000 (атрибут ‘Name’ – имя объекта). Пусть имеются экземпляры с идентификаторами 1023 (Name=’Int32’) и 1024 (Name=’Int64’). В этом случае в глобальном контексте нас интересуют 3 экземпляра объектов с идентификаторами 1000, 1023 и 1024. Экземпляр с идентификатором 1000 – метаописатель атрибута ‘Name’. Экземпляр с идентификатором 1023 – метаописатель типа ‘Int32’ и экземпляр 1024 – метаописатель типа ‘Int64’. В контексте объектов 1000, 1023 и 1024 разадресация идентификатора 1000 не зависит от разадресации этого же идентификатора в глобальном контексте. В этих контекстах возможно создание дочерних экземпляров объектов с идентификатором 1000 и хранящих не метаописание атрибута а его значение. Так в контексте 1023 разадресация атрибута 1000 будет приводить к получению объекта - строки “Int32”, в контексте 1024 – строки “Int64” а в контексте 1000 – строки “Name”. Следует обратить особое внимание на разадресацию идентификатора 1000 в контексте метаописателя атрибута 1000. Такая разадресация возвращает имя метаописателя атрибута 1000 - строку “Name”. Таким образом метаописатель атрибута ‘имя объекта’ описывает и собственный атрибут ‘Name’. Значением атрибута 1000 метаописателя атрибута 1000 - ‘имя объекта’ является строка ‘Name’. Из данного примера видно, что идентификатор 1000 в четырех различных контекстах ссылается на 4 различных экземпляра объекта, при этом в собственном контексте описывает собственное имя.

Объектные представления должны обеспечивать соединения объектов. Например, если атрибутом объекта Работник является идентификатор объекта Организация то во многих случаях будет интересно получить способ обращаться к имени организации, к которой принадлежит этот работник. Это обеспечивается навигацией из объекта Работник по его атрибуту ‘идентификатор организации’ к экземпляру объекта Организация и далее к атрибуту ‘имя организации’. Результирующий агрегат – объект Работник с дополнительным атрибутом ‘имя организации’ должен иметь тот же идентификатор что и оригинальный объект Работник и должен обеспечивать прозрачный доступ ко всем свойствам объекта Работник и атрибуту ‘имя организации’. В объектной базе данных, поддерживающей синонимию/омонимию объектных идентификаторов, данная задача может быть решена следующим способом. Необходимо задекларировать новый атрибут ‘имя организации’ так как объект Организация имеет атрибут Имя и объект Работник так же имеет атрибут Имя. Если добавить к объекту Работник второй атрибут с идентификатором дублирующим уже существующий в этом экземпляре атрибут возникнет логический конфликт и будет невозможно определить, какое значение требуется вернуть при разадресации этого идентификатора. В каждый экземпляр класса Работник добавляется дочерним атрибутом экземпляр атрибута Имя объекта Компания с идентификатором этого атрибута ‘имя компании’. В результате каждый экземпляр имени компании будет иметь по два различных идентификатора, один – имя в контексте объекта Компания и второй – ‘имя компании’ в контексте объекта Работник. Все работники одной компании будут иметь в качестве значения атрибута ‘имя компании’ один и тот же экземпляр атрибута объекта Компания.Имя.


С уважением,
Шуклин Дмитрий

mir1. Аналогии с естественным языком не обеспечивают автоматическую легитимизацию всякой хрени. Омонимия и синонимия в ЕЯ хороша лишь для каламбуров, а объективно -- это огромный недостаток. Кто изучал хоть пару иностранных языков, тот это знает. Тянуть недостатки ЕЯ в инженерную систему -- глупо.ващето это стереотип, что многозначность есть недостаток ЕЯ. На самом деле наоборот. Многозначность есть достоинство ЕЯ. ну это уже лингвистика.

mir2. Главному вопросу -- А НА ХРЕНА ЭТО НАДО -- посвящены две с половиной мутных строчечки огромного поста. Вывод: сами не знаете, зачем.


Это надо для идентификации типа связей, при построении семантических и иерархических семантических сетей, для идентификации атрибутов объектов, реализации объектных views & joins. надеюсь не нужно объяснять что скрывается под этими терминами? Без описанной функциональности модель данных ООБД вырождается либо иерархическую модель либо в реляционную модель. При этом у иерархической модели есть недостатки по сравнению с реляционной, которые здесь уже были обсуждены неоднократно. А с описанной - получает плюсы как одной так и другой.

U-genePS Кстати, насчет comp.database.theory Вы там поострожней. 1) Язык надо знать. 2) Ребята там конкретные. Судя по Вашему началу - съедят. а что мне с того что съедят? вот вы тут типа "съели" меня - так пасибки, пару идей я с того безобразия для своей ООБД вынес. так что чем больше побьют тем моей ООБД лучше.

не было что классы это отношения)) классы это таблицы. а отношения это строки. ну да Дейт с Кодом ребята конкретные, там еще Декарт (которого я оч уважаю) но всеже. в моей бд отношение это строка. а в РБД - та что угодно мне в этом контексте от того ни жарко ни холодно.

так что JOIN для объектов это почти тоже самое что JOIN для отношений (строк). - тоесть новый экземпляр. а класса он экземпляр или нет, на самом деле сказать трудно. вот нету у Class1 аттрибута Name2. есть экземпляр Class1 и у этого экземпляра есть аттрибут Name2. в моей бд - банальность. технически экземпляр таки этого самого Class1 а концептуально - так самой БД всеравно что там у девелопера в голове делается. она биты перебирает.

а разница между РБД шным и моим - в том что у меня результат JOIN это новый экземпляр объекта. Тоесть узел у которого есть аттрибуты. Методы для этих аттрибутов будут определены в какой то сборке. Любым аттрибутам - любые методы - как законфижешь.

Если есть желание поговорить на эту тему спокойно - можем совместными усилиями разложить все по полочкам.

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

На самом деле неясности в моей системе еще маловато для ИИ вот:"от персетановки бкув слвоа все ранво чиатються галвное чтобы преавя и псолденяя бкувы солва блыи парвльиными,т.к. мы чиатем солво цлеиокм а не по бкуавм" )))

mir А что вы за бред такой несете в форуме comp.databases.theory? Что за фразу ни возьми, то просто перл невежества. Хоть бы эту: “a table is just a special case of a graph or network.” А ну-ка, ну-ка приведите-ка точное математическое определение графа и точное определение отношения . А потом укажите, при каких-таких “special cases” определение графа вырождается в определение отношения. Ась? Научная работа только после заключения договора и предварительной оплаты ;)

softВы бы хоть диаграмму структурной схемы своей ООБД нарисовали. http://www.shuklin.com/ai/ht/ru/cerebrum/lessons/Cerebrum.Samples.Streams-01.aspx

softВсе равно не вижу причины почему бы не сделать обычную надстройку над реляционной моделью.

Модификацию/выборку данных производить хранимыми процедурами?

А я не вижу причины, почему бы не реализовать тоже самое на ассемблере - вообще без какой либо БД, и без ОС )))

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

softНамного проще было бы просто построить надстройку над реляционным хранилищем и далее после доработки модели до работоспособного состояния дописать свой тип хранилища, если в этом возникнет необходимость. Вот как раз возникла. Только после доработки модели на плайн-С.

В качестве задания для домашней медитации:

- С какой эффективностью будет работать нейронная сеть из ста миллионов нейронов работающая через ОР маппер? Какие эксперименты на такой модели можно провести?

- Сколько рессурсов надо вбухать в реализацию такой модели?

- Какой итоговый профит (кроме теоретических результатов экспериментов) даст такая разработка?


softА так вы пытаетесь вре реализовать "на ассемблере - вообще без какой либо БД, и без ОС" :)Это было просто развитие вашей мысли А еще лучше эту сеть спаять паяльником из транзисторов.

softточка сборки АмосоваСомневаюсь в пригодности РБД для моделирования СУТ и М-Сетей. Хотя кто знает. В любом случае меня интересуют не М-Сети а СНС.

softА писать все практически с нуля... Вы просто не сможете обогнать корпорации с из ресурсами в сотни и тысячи человек.Это только в том случае если они тоже пытаются реализовать ту же самую модель.