Синонимия/Омонимия

Важной особенностью СООБЗ 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 различных экземпляра объекта, при этом в собственном контексте описывает собственное имя.

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