Продолжается подписка на наши издания! Вы не забыли подписаться?

Организация каталога объектной информационной системы на базе реляционной СУБД

Авторы: Дмитрий Коваль
старший инженер-программист ЗАО НПП "РЕЛЭКС"
koval@relex.ru

Информационные системы принятия решений, накапливающие информацию в виде объектов о произвольной предметной области, в настоящее время довольно широко распространены. В данной статье подробно рассматривается способ организации каталога информационной системы на базе реляционной СУБД (РСУБД), который позволяет представить в виде объектов «внешние» для системы данные, хранящиеся в кортежах отношений РСУБД.

В настоящее время существует и разрабатывается большое число информационных систем поддержки принятия решений (Decision Support System). Подавляющее большинство подобных систем ориентировано на работу с данными, представленными в своем внутреннем формате. В статье предложена структура каталога объектной информационно-аналитической системы (ИАС), которая дает возможность представить в виде объектов «внешние» по отношению к ИАС данные.

В ИАС НЕВОД 3.5 была предложена универсальная схема хранения объектного представления данных в рамках модели «объект-качество». Схема представляет собой совокупность способов хранения, описываемых следующими формулами:


(1)


(2)


(3)

где O – множество всех объектов всех классов, R – множество отношений, DAttrID – домен, содержащий уникальные идентификаторы атрибутов, DObjID – домен, содержащий уникальные идентификаторы объекта класса, в который входит атрибут; DValueID – домен, содержащий идентификаторы значений качества (является первичным ключом отношения Ri); DValue – домен, содержащий значения качества.

Рассмотрим примеры для приведенных формул (1), (2) и (3). Пусть у нас задан класс объектов «ФИЗИЧЕСКОЕ ЛИЦО», который имеет в своем составе атрибуты «ФАМИЛИЯ» и «ИМЯ». Допустим, нам надо хранить в базе два объекта приведенного выше класса: «ИВАНОВ ИВАН» и «ПЕТРОВ ПЕТР».

Формула (1)

Пусть атрибуты «ФАМИЛИЯ» и «ИМЯ» принадлежат к одному качественному типу, тогда данные будут храниться в следующем виде (Таблица 1):

Идентификатор значения качества, DValueID Идентификатор атрибута класса, DAttrID Идентификатор объекта, DObjID Значение, DValue
1 1 1 ИВАНОВ
2 2 1 ИВАН
3 1 2 ПЕТРОВ
4 2 2 ПЕТР

В состав каталога системы в этом случае должны входить три отношения:

Зависимости между этими отношениями показаны ниже (Рисунок 1).


Рисунок 1. Зависимости между атрибутами отношений RQ, RC и RS для случая формулы (1)

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

Формула (2)

В этом случае данные хранятся в следующем виде (таблицы 2-3).

Идентификатор значения качества, DValueID Идентификатор объекта, DObjID Значение, DValue
1 1 ИВАНОВ
2 2 ПЕТРОВ
Таблица 3. Отношение, в котором хранится атрибут «ИМЯ»
Идентификатор значения качества, DValueID Идентификатор объекта, DObjID Значение, DValue
1 1 ИВАН
2 2 ПЕТР

В этом случае в составе системного каталога могут быть два отношения:

Зависимости между этими отношениями показаны ниже (Рисунок 2).


Рисунок 2. Зависимости между атрибутами отношений RC и RS для случая формулы (2)

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

Формула (3)

Данные будут храниться в следующем виде (таблица 4).

Идентификатор объекта, DObjID Значение 1, D2 Значение 2, D3
1 ИВАНОВ ИВАН
2 ПЕТРОВ ПЕТР

В этом случае в составе системного каталога также могут быть два отношения:

Зависимости между этими отношениями показаны ниже (рисунок 3).

Данный способ хранения данных является самым «быстрым» из трех, так как все значения атрибутов можно выбрать с помощью всего лишь одного запроса с условием на идентификатор объекта (см. таблицу 4). Но этот способ имеет один принципиальный недостаток: он не позволяет хранить в базе несколько значений одного и того же атрибута одного объекта. То есть, если в нашем примере «ПЕТРОВ» изменил фамилию на «СИДОРОВ» и в базе надо хранить сразу два значения атрибута «ФАМИЛИЯ», то этого сделать мы не сможем. Впрочем, большинство существующих информационных систем поддерживает хранение только одного значения атрибута и, возможно, во многих задачах большего не потребуется.


Рисунок 3. Зависимости между атрибутами отношений RC и RS для случая формулы (3).

Также следует отметить, что способ хранения данных в соответствии с формулой (3) позволяет представить хранящиеся в кортежах отношений РСУБД данные (в том числе «внешние» для ИАС) в виде объектов ИАС. Работа с «внешними» данными, в свою очередь, позволяет использовать ИАС в качестве надстройки над другими информационными системами.

Итак, в ИАС НЕВОД 3.5 реализованы три различных способа хранения данных. Системный каталог этой системы представляет собой объединение каталогов, упрощенные схемы которых приведены на рисунках (см. рисунки 1 и 3). Данная особенность ИАС НЕВОД 3.5 позволяет осуществить гибкую настройку системы в соответствии с особенностями моделируемой предметной области и пожеланиями заказчика.

Литература


Copyright © 1994-2016 ООО "К-Пресс"