Идентичность и эквивалентность

В ООБД при сравнении двух объектов между собой различают идентичность и эквивалентность объектов.

Определение идентичности

 Два объекта являются идентичными, если их идентификаторы совпадают. Поскольку в системе не может быть двух объектов с одинаковыми идентификаторами, это означает, что это один и тот же объект, на который ссылаются с двух разных мест. Идентичность обозначается так: o₁ º o₂.

Определение N-эквивалентности

Пусть 0-эквивалентность (обозначается »₀) то же самое, что проверка идентичности º. Тогда для любых двух объектов o₁, o₂ÎO, o₁ и o₂ n-эквивалентны (обозначается o₁ »_n o₂) для  n > 0, если:

Существует атомарный объект c, такой, что значение(o₁) = значение(o₂) и их поведения идентичны;

Существует объект-агрегат c, такой, что FID каждого поля с присутствует в o₁ и o₂, а также верно обратное: FID каждого поля o₁ (o₂) присутствует в c,
значение(o₁)=[A₁ : x₁, …, A_m : x_m] и значение(o₂)=[A₁ : y₁, …, A_m : y_m], и при этом
x_i »_n-1 y_i для 1£ i £ n; или

Существует объект-условие c, такой, что значение(o₁) = <x₁,  x₂,  x₃> и значение(o₂) = <y₁,  y₂,  y₃> и x_i »_n-1 y_i для 1£ i £ 3; или

Существует объект-множество c, такой, что значение(o₁) = {x₁, …,  x_l} и значение(o₂)
= {y₁, …,  y_m}  и  l = m и для каждого x_i(y_j) существует один y_j(x_i) : x_i »_n-1 y_j для 1£ i,j £ l; или

Существует объект-список c, такой, что значение(o₁) = (x₁, …,  x_l) и значение(o₂) = (y₁, …,  y_m)  и  l = m и  x_i »_n-1 y_i для 1£ i £ l.

Два объекта называются эквивалентными (o₁ » o₂) тогда и только тогда, когда
o₁ »_n o₂ для некоторого n > 0.

Идентификатор поля агрегата

Введение идентификатора поля позволяет преодолеть трудность определения размещения данных полей агрегатов. Суть проблемы заключается в том, что если мы наследуем классы B и C от класса A, а затем наследуем множественно класс D от классов B и C, то экземпляр класса D одновременно является экземпляром классов A, B и C. При этом важно, чтобы "старый" класс (например, A) умел работать с объектами класса D. Эта проблема рассматривается в работе [10], в которой авторы вводят следующие ограничения целостности структуры объектов:

1. В БД не могут существовать отдельные собственные части подклассов

2. Каждой части сложного объекта должна соответствовать только одна собственная часть.

В качестве решения они предлагают использование ссылок на классы и каждую собственную часть класса хранить отдельно.

В дипломной работе предлагается вместо хранения ссылок на классы установить для каждого поля свой идентификатор. При наследовании поле сохраняет свой иден­ти­фикатор. Таким образом, переименование полей не нарушает связь наследо­вания. Пере­именование может быть автоматическим, например, из-за конфликтов имен полей при множественном наследовании. Аналогично поступает оператор SQL Select, когда в ка­честве результата запроса ему нужно вернуть несколько столбцов, имеющих одина­ко­вые имена.

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

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

Триггеры. Ограничение доступа

В множество поведений любого объекта можно включить два списка с предопределенными именами «PRE_TRIGGERS» и «POST_TRIGGERS». Список PRE_TRIGGERS содержит объекты, обрабатывающие входящее сообщение. Как правило, это объекты-условия. Такой подход называется фильтрацией [20]. Список POST_TRIGGERS содержит объекты, которые проверяют результат воздействия и могут произвести откат. POST_TRIGGERS вызываются по окончании действия транзакции при выполнении операции удаления транзакционных зависимостей.

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

Список PRE_TRIGGERS позволяет организовать ограничение доступа, фильтруя сообщения, посланные объектом, ктороый не имеет полномочий для выполнения коман­ды, содержащейся в сообщении.

Список POST_TRIGGERS позволяет исключить часть данных из результата выполненной объектом операции, создав тем самым локальное пользовательское представление.

Впрочем, тема безопасности заслуживает отдельного рассмотрения. Как, например, в [9] и [18].

Действие (knowhow)

Действие представляет собой объект типа “строка”, хранящий текст ДССП-процедуры. Ссылка на действие может хранится в поле OBJKH объекта, через который и происходит вызов действия. Алгоритм выбора выполняемого действия рассматривается ниже. В интерфейсах объектов указаны идентификаторы объектов, которые в поле OBJKH хранят идентификатор действия. Значения этих объектов являются именем действия. Наиболее удобно использовать для этой цели строковые объекты. Использова­ние поля OBJKH позволяет выполнять одно и то же действие для различных методов различных объектов.

При вызове действия с идентификатором OIDKH делается вызов слова с именем kh$<OIDKH>. Например, для объекта с OIDKH=0x00000DFC это будет KH$00000DFC. Если возникает ситуация EXERR, значит слово в словаре отсутствует и подлежит компиляции. Для компиляции текст действия дополняется префиксом “: KH$<oid> ” и суффиксом “ ;”, после чего компилируется командой TEXEC и выполняется. Словарь действий называется $KH_VOC.

При изменении текста метода необходимо полностью очистить словарь ДССП $KH_VOC, хранящий откомпилированные действия, поскольку эти действия содержат в своем коде абсолютные ссылки на прежнюю откомпилированную версию действия. Впрочем, эта процедура очистки словаря выполняется лишь при переопределении текста действия, что бывает достаточно редко.

Объекты-поведения

В отсутствии классов, хранить методы в каждом объекте было бы слишком накладно. Вынесение правил поведения в отдельный объект позволяет уменьшить затраты на хранение объектов-данных. Математическая модель ООБД в [17], также разделяет дан­ные и поведения, что дополнительно дает возможность переиспользовать поведение дру­гого объекта.

Объект-поведение представляет собой множество объектов-методов, которое и назы­ва­ется интерфейсом объекта.

При посылке на вход произвольного объекта OID₂ сообщения OID₁ (которое тоже является объектом), сначала проверяется, содержится ли OID₁ в интерфейсе объекта OID₂ (проверка идентичности). Если да, то выполняется действие объекта OID₁, иначе сравниваются значения OID₁ и объектов интерфейса (проверка эквивалентности). Если соответствие найдено, выполняется действие, указанное в найденном в интерфейсе объекте.