Каталог объектов

Таблица связей

Факты

Используемые классификаторы

Р исунок 1 – Схема четвертой нормально формы многомерных данных

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

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

Факты отражают пространственно – временные координаты объектов находящихся на различных этапах состояния объекта (этапа жизненного цикла, на котором находится объект). Таблица фактов должна включать следующие атрибуты: категория (класс) объекта, дата и время регистрации свойства объекта, идентификатор свойства, значение свойства. За счет этого таблицы «Каталог» и «Факты» будут иметь одинаковую структуру данных - в виде триплов.

Классификаторы оформляются в соответствии с первой нормальной формой для многомерных данных.

Такое представление данных по существу представляет универсальную модель хранения данных (УМД), т.к. структура данных для всех объектов мира одинаковая. Для работы с такой моделью необходимо все простые классификаторы (код, значение) хранить в одном классификаторе. Полные сведения о всех свойствах объектах – это отдельный объект, включающий уникальный идентификатор, код параметра, процесса (явления), имя статистической характеристики, временной, пространственный масштабы, полное и краткое наименование параметра на русском и английском языках, точность наблюдений или рекомендуемая точность расчета, единицы измерения, диапазон изменчивости (мин, мах значения), уравнение для вычисляемых значений, вертикальное разрешение (мин и макс высота/глубина), имя используемого классификатора для хранения отдельных свойств, метод определения свойства, международный код, описание свойства. Сведения о свойствах объекта являются отдельным объектом УМД.

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

При работе с УМД пользователь должен видеть только плоские таблицы, а соответствующий конвертор должен преобразовывать плоские таблицы в УМД и обратно.

Универсальная схема БД, предложенная для СУБД Oracle включает, следующие таблицы [16]:

- Схема (идентификатор схемы, имя схемы, комментарии);

- Таблица (идентификатор схемы, идентификатор таблицы, имя таблицы, комментарии);

- Столбец (идентификатор схемы, идентификатор таблицы, имя столбца, тип данных, значение по умолчанию, длина, точность, комментарии);

- Данные (идентификатор схемы, идентификатор таблицы, идентификатор столбца, номер строки, значение, комментарии).

Кроме того в состав такой модели входят таблицы Пользователь, Представление, Триггер и Ограничение целостности, рис.2. По существу, в этой схеме используется иерархия уточнения местоположения данных (схема-таблица, столбец-данные).

Рисунок 2 - Универсальная схема [16]

При формировании запроса можно пользоваться только одной таблицей «Данные». Главный недостаток такой универсальной схемы - большое число соединений даже для выполнения тривиальных запросов. Еще одним недостатком является то, что такая схема привязана к одной СУБД Oracle. Хотя похожие схемы можно создать и для других СУБД.

В УМД фирмы Treelogy (http://www.treelogy.ru/cd/42) разработчик оперирует практически с единственной таблицей «Перемещение объектов». Навигация по этой таблице очень проста и понятна, так как она представлена в виде дерева (перемещения связаны между собой полями «Откуда» и «Куда» - узлами дерева), отражающего структуру предприятия и его окружения в виде банков, контрагентов, партнёров и т.д., которое строит сам пользователь. Выглядит это аналогично проводнику Windows, только справа не файлы, а таблица перемещений выбранного в дереве узла. Узлы дерева называются Объектами. Объектами могут быть фирмы, их подразделения, товары, деньги, сотрудники. Все объекты равноправны. Объекты имеют вложенную структуру, то есть одни объекты можно вмещать в другие (так и образуется дерево).

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

В Treelogy все события, имеющие отношение к деятельности предприятия, фиксируются в едином виде - в виде записей таблицы перемещений. Каждое перемещение объекта (строка таблицы) имеет следующий формат (колонки таблицы):

• Дата/Время - фиксирует время произошедших изменений;

• Что, Откуда, Куда - фиксируют изменение положения в пространстве объектов (просто выбираем в дереве, что и откуда перемещается, а затем куда);

• Количество - количественные изменения;

• Дополнительные поля (качественные изменения) произвольные характеристики, создаваемые самим пользователем.

В Treelogy перемещения связаны в цепочки (с возможными ветвлениями). Это позволяет отслеживать всю историю перемещений любого объекта со всеми изменениями характеристик.

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

Структура такой БД универсальна и не изменяется в зависимости от бизнес-процессов предприятий. Это даёт возможность привязать конструкторы Запросов, Форм и Документов именно к этой структуре данных (то есть они оперируют не сложными таблицами БД, а с понятиями перемещений, объектов и их характеристик). Это упрощает и ускоряет организацию управленческого учёта, делает проект открытым для внесения любых изменений и независимым от разработчика, так как изменения модели управления не затрагивают структуру данных.

Язык JSON (JavaScript Object Notation) стал активно развиваться только в последние годы. Хотя еще в семидесятых годах подобный подход применялся для хранения документально-фактографической информации. Язык JSON основан на принципе хранения данных в форме «ключевое слово: значение». В работе [23] применена реляционная алгебра классической реляционной схемы к формату JSON и доказано, что этот формат описывается математически эквивалентным аппаратом. JSON предоставляет простой способ форматирования данных, например, описать контактную информацию можно следующим образом:

{

"contacts" : {

"contact" : {

"@attributes" : {

"id" : "1"

},

"name" : "Евгений Вязилов",

"phone" : "+7 48439 74676",

"address" : {

"street" : "6, Королева",

"city" : "Обнинск",

"state" : "Россия",

"zipCode" : "249035"

} } } }

На основе формата JSON и применения триплов выпускником кафедры КССТ ИАТЕ НИЯУ МИФИ М.Кабановым разработана универсальная модель представления данных, рис.3. Эта модель отталкивается от основных структурных единиц схемы БД: объект, экземпляр объекта, свойства объекта. Для каждой структурной единицы схемы БД предлагается создать свою таблицу, представленную в виде трипла. При этом главная структурная единица схемы – объект имеет ссылку на соответствующие экземпляры объекта. А каждый экземпляр объекта ссылается на таблицу, содержащую свойства конкретных экземпляров объекта. При этом каждая таблица имеет индекс, который хранится не в БД, а в системных файлах.