База оперирует определяемыми  правовыми объектами. Назовем их “сущностями”.

У сущности есть параметры, атрибуты.

Для каждой сущности  база определяет список параметров взаимозависимых сущностей их параметров и логики анализа. При этом набор значений параметров имеет множественную корреляцию и ограничения. 

Таким образом. База на лету должна построить алгоритмическую и параметрическую функцию по данному параметру и показать нормы, которые участвуют в данной функции.

НБ - нельзя делать слепую базу, логику которой пользователь не видит.

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

Проверка теории “в лоб”: лестничная клетка. Выход может быть наружу или в вестибюль для общественных зданий, если это эвакуационная ЛК. Тогда требования к маршу получены. И обратно: Марш - если это ЛК является путем эвакуации и т.д.

Взаимо-вложенность сущностей - зависимости могут быть как прямые так и опосредованные, когда нет однозначной принадлежности. На примере видно, что одна сущность прямо вложена в другую, при этом также относится и к третьей, определяется четверой и т.д. Вывод - прямая жесткая зависимость вложенности недостаточна. Напоминаем, IFC описан жесткими древовидными зависимостями.

Автоматический поиск ограничений и Определение схем зависимостей.

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

“что надо:” - внесли законодательное условие с определенным объемом ограничений на базе ограниченного круга сущностей (норму). Ввод должен быть не сложнее человеческого описания. База “подхватила” норму и при необходимости! Применила. О чем идет речь: 1 вариант - обработка всей базы с добавлением флагов (неудачный метод) 2 - подхватить “норму” на лету при выполнении запроса.

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

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

Определяющим требованием становится необходимость хранения  правил, делающих данные более активными и позволяющих системе баз данных автоматически выполнять проверки корректности данных и автоматизировать анализ, выстраивая алгоритм на основе этих “активных” данных.. 

Обе указанные возможности обеспечат искомые функции повышая ценность хранимых данных за счет расширения их семантического содержимого.Работы на эту тему http://citforum.ru/database/digest/dig_0511.shtml указывают следующие направления:  (1) добавлении "объектной инфраструктуры" к самой системе баз данных в виде поддержки определяемых пользователями типов данных, функций и правил; (2) построении поверх этой инфраструктуры "реляционных расширителей", которые поддерживают специализированные приложения, такие как выборка изображений, развитый текстовый поиск, географические приложения. Система, которая обеспечивает объектную инфраструктуру и набор реляционных расширителей, называется "объектно-реляционной".

Объектно-реляционные системы объединяют достоинства современных объектно-ориентированных языков программирования с такими свойствами реляционных систем как множественные представления данных и высокоуровневые непроцедурные языки запросов. 

В источнике описывается идея “Активных данных” :

Начало выдержки: 

“Под "свойством активности данных" понимается механизм, заставляющий оператор SQL производить некоторые действия, потребность в которых в самом операторе явно не выражена. Активные данные имеют особенно важное значение в среде "клиент/сервер", в которой приложения разрабатываются распределенными группами, поскольку этот механизм дает возможность определения глобальных правил, применимых ко всем приложениям.

В DB2 существуют две категории активных данных - ограничения и триггеры. Ограничения являются декларативными утверждениями, истинность которых контролируется системой, например, "Размер обуви всегда представляется положительными числами" или "У каждого служащего имеется менеджер". Триггеры - это автоматические действия, которые срабатывают каждый раз при возникновении определенного события или условия, например, "Когда останется только 10 карандашей, нужно заказать еще 100" или "Следует вести учет всех тех, кто изменяет содержимое таблицы ACCOUNTS".” 

Конец выдержки”