Успешная реализация структуры данных для хранения многоуровневых объектов

Полное название: успешная реализация структуры данных для хранения многоуровневых объектов с произвольным набором атрибутов.
В статье представлена структура данных для моделирования многоуровневых объектов с любым количеством атрибутов стандартных типов. Данная структура успешно реализована на практике.

Содержание
Введение
Иерархическая структура объектов
Классификация иерархических объектов
Моделирование атрибутов
Создание представлений для объектной структуры данных
Практическая реализация

Введение

Объектно-ориентированное программирование (ООП) стало революционным подходом в 1980-е годы [3]. В 1990-х годах применение ООП стало важнейшей областью исследований и разработок применительно к реляционным системам управления базами данных (СУБД) [1,7]. В 1996 г. была выпущена объектно-реляционная СУБД Informix Universal Server. Несмотря на важность и актуальность классической реляционной и объектно-реляционной моделей, тем не менее остается много нерешенных проблем.

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

Ограничения реляционных баз данных

В реляционной модели каждая запись об объекте находится в отношении с некоторым набором атрибутов. Количество атрибутов (полей) в таблице может измеряться десятками и даже сотнями. С увеличением длины записи (количества и размера атрибутов) падает производительность, поскольку требуется больше дисковых операций ввода/вывода. Разбиение широкой таблицы на несколько узких с меньшим числом атрибутов потребует операций соединения (join) и во многих случаях является неэффективным.

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

exp (vi) ~ n (1)

или

vi ~ ln (n) , (2)

в то время как зависимость между скоростью последовательного перебора и размером выборки пропорциональная:

v ~ n · k , (3)

где v - скорость последовательного перебора,
vi - скорость поиска с использованием индекса i,
n - количество записей в таблице,
k - количество колонок в таблице.

Применение индексов наиболее эффективно при большом количестве узких записей, а не широких [5]. Вдобавок, индексы имеют свои недостатки:

  • Чем больше атрибутов (колонок в таблице), тем больше индексов нужно создавать.
  • Для каждого индекса требуется дополнительное дисковое пространство (которое на практике может даже превышать размер индексируемой таблицы).
  • После модификации данных необходимо обновлять статистику или перестраивать все индексное дерево.

Еще одним ограничением реляционной модели является "плоская" организация атрибутов объектов. Это означает, что в реляционном отношении нельзя группировать или структурировать атрибуты - все они находятся на одном уровне иерархии. А на практике не все атрибуты объекта одинаково значимы и поэтому должны принадлежать разным уровням вложенности.

Конечно, есть дополнительные типы данных, определяемые пользователем, а также большие двоичные BLOB и текстовые CLOB-объекты. Однако, и у них есть свои ограничения. Например, поля BLOB и CLOB не могут быть упорядочены или проиндексированы и должны обрабатываться на стороне клиента.

Использование преимуществ объектно-реляционных технологий

Informix Universal Server [2,6] - это СУБД объектно-реляционного типа, созданная путем внедрения технологии ООП в популярную СУБД Informix Dynamic Server. Она обладает следующими свойствами ООП:

  • абстрактные типы данных,
  • наследование,
  • иерархии данных и типов.

На практике встречается много примеров, когда набора стандартных типов недостаточно. Хотя абстрактные типы данных дают определенные преимущества, описание новых типов в СУБД не совсем приемлемо - в дальнейшем всегда может возникнуть потребность добавить еще один тип.

К тому же определение новых типов в СУБД Informix Universal Server может вызвать отрицательные последствия, т. к. потребуются навыки опытных программистов по разработке на языке C процедур и методов хранения, доступа и индексирования данных.

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

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

Иерархическая структура объектов

Дерево объектов [4] представляет собой информационную систему для хранения иерархической структуры объектов. Задача усложняется тем, что у объектов допускается произвольное количество атрибутов - десятки, сотни и более, каждый из которых может быть в Informix любого типа (целый, вещественный, десятичный, строковый, дата/время и т. д.). Все это предусмотрено в представленной структуре данных.

Система иерархических таблиц и расширенных типов данных построена на базе Informix Universal Server и Informix Web DataBlade™. Но при этом используются стандартные методы доступа, т. е. нет необходимости программировать обработчики. Поэтому данная структура данных может быть реализована как на платформе Informix Universal Server, так и Informix Dynamic Server.

Структура данных (рис. 1) создана в СУБД Informix посредством SQL и состоит из таблиц, описанных ниже. Для их модификации разработаны хранимые процедуры. Пример создания таблиц и процедур их модификации приведен в отдельном файле (obj_sql.zip).


Структура данных для хранения иерархических объектов
Рис. 1. Структура данных для хранения иерархических объектов

Таблица objects_tree

Таблица objects_tree содержит информацию как об объектах-родителях, так и объектах-потомках иерархического дерева.

Таблица 1. Таблица objects_tree

objt_id SERIAL NOT NULL Первичный ключ
dlv_id INTEGER NOT NULL ID подразделения, где находится объект
obj_name NVARCHAR(254,1) NOT NULL Наименование объекта
ch_ar CHAR(1) Признак активности/архивности

Атрибуты (колонки) таблицы objects_tree:

obt_id - ID записи об объекте,
dlv_id - ссылка на ID в таблице подразделений,
obj_name - любой текст,
ch_ar - символ-признак архивности записи, используемый для хранения информации об удаленных объектах.

Для добавления, модификации и удаления объектов используются хранимые процедуры. При удалении объекта не производится рекурсивное удаление всех его потомков. Иначе говоря, если у объекта есть потомки, он не может быть удален. Если потомки объекта не удалены, процедура возвращает код ошибки SQL. Это сделано в целях безопасности данных. Реализация рекурсивного удаления потомков в хранимой процедуре повысит вероятность случайного удаления целой ветви дерева объектов.

Таблица objects_parents

Каждая запись в таблице objects_parents (табл. 2) содержит ссылку на объект-родитель и соответствующий ему объект-потомок в таблице objects_tree.

Таблица 2. Таблица objects_parents

oprnt_id SERIAL NOT NULL Первичный ключ
chld_id INTEGER NOT NULL ID объекта-потомка (объекта более низкого уровня)
prnt_id INTEGER NOT NULL ID объекта-предка (объекта более высокого уровня)

Оба поля - ID предка и ID потомка - ссылаются на таблицу objects_tree. Новые отношения родитель-потомок добавляются посредством хранимой процедуры. Для улучшения производительности родительский и дочерний объекты назначаются совместно. Но модификации не допускаются, для этого соответствующая запись должна быть удалена прямым вызовом SQL оператора DELETE.... FROM...., а затем новая запись добавляется путем вызова хранимой процедуры.

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

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

Таблица 3. Пример таблицы objects_tree

objt_id obj_name
.... ....
10 Политехнический университет
101 Институт электроники
102 Институт механики
201 Механико-машиностроительный факультет
202 Факультет вычислительной техники
301 Лаборатория металлорежущих станков
302 Лаборатория металлорежущего инструмента
303 Лаборатория компьютерной графики
.... ....

Таблица 4. Пример таблицы objects_parents

oprnt_id chld_id prnt_id
.... .... ....
11 101 10
12 102 10
13 201 102
14 202 101
15 301 201
16 302 201
17 303 202
.... .... ....

Классификация иерархических объектов

Классификация объектов описывается связкой следующих таблиц (рис. 1):

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

Таблица object_classes

Таблица object_classes (табл. 5) содержит записи, которые связывают описание объекта с позицией классификатора. Любой объект может быть связан с несколькими, но разными классификаторами. Такого рода уникальность обеспечивается специальным индексом в базе данных. Пользователям, не имеющим привилегий администратора базы данных (DBA), предоставлено право только на выборку данных. Все операции модификации выполняются только посредством специальных хранимых процедур.

Таблица 5. Таблица object_classes

objt_id INTEGER NOT NULL Первичный ключ
eqcs_id INTEGER NOT NULL Первичный ключ классификатора
eqc_id INTEGER NOT NULL Первичный ключ позиции классификатора
classlevel SMALLINT NOT NULL Уровень иерархии класса
valid CHAR(1) Признак того, что объект классифицирован (y/n)
  • eqcs_id - ссылка на таблицу классификаторов объектов eq_classifiers,
  • eqc_id - ссылка в таблице eq_classes на класс, которому объект назначен,
  • valid - признак правильной классификации объекта, который используется для автоматического установления связи объект-класс при добавлении эквивалентных классов (см. описание таблицы eq_class_link); поле может принимать значения 'y' или 'n' в зависимости от потребности установить связь объект-класс.

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

Когда объект переклассифицируется, полю valid автоматически присваивается значение 'y'. При отмене классификации если ID объекта не указан (null), то все связи с соответствующим классом удаляются, а если позиция классификатора не указана, то удаляются все связи объекта со всеми классами.

Таблица eq_classifiers

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

Таблица 6. Таблица eq_classifiers

eqcs_id SERIAL NOT NULL Первичный ключ классификатора
eqcs_name NVARCHAR(80,0) NOT NULL Наименование классификатора
eqcs_sign CHAR(10) Сигнатура классификатора

Наименования классификаторов уникальны. Поле сигнатуры классификатора eqcs_sign может содержать любую символьную строку в верхнем регистре либо null. Если не пусто, значение строки должно быть уникальным. Уникальность проверяется специальным триггером. Пользователи без привилегий DBA имеют право только на выборку данных.

Модификация данных выполняется хранимыми процедурами. Помимо добавления нового классификатора, в таблицу eq_classes добавляется корневой класс с тем же именем, что и у классификатора, и значением поля classlevel=0. В процедуре удаления классификатора вместе с ним удаляются все подчиненные классы.

Таблица eq_classes

Таблица eq_classes (табл. 7) содержит иерархию элементов классификатора, используемых для классификации объектов, описания которых находятся в иерархической таблице objects_tree.

Таблица 7. Таблица eq_classes

eqc_id SERIAL NOT NULL Первичный ключ элемента классификатора
eqcs_id INTEGER NOT NULL Ссылка на описание классификатора, к которому относится элемент
parent_id INTEGER Ссылка на родительский класс, находящийся в том же классификаторе
classlevel SMALLINT NOT NULL Уровень иерархии классификатора
eqc_name NVARCHAR(80,0) NOT NULL Наименование элемента классификатора
eqc_sign CHAR(10) Сигнатура класса

Наименования элементов, имеющих общего предка, уникальны.

Сигнатура класса eqc_sign может содержать любую символьную строку в верхнем регистре либо null. Если не пусто, значение строки должно быть уникальным в сочетании со значением поля eqcs_id. Уникальность проверяется специальным триггером. Пользователи без привилегий DBA имеют право только на выборку данных.

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

Таблица eq_class_link

Таблица eq_class_link (табл. 8) специфицирует эквивалентные классы. Эквивалентность означает, что все объекты, принадлежащие основному классу (т. е. классу, в котором они были созданы), будут принадлежать и дополнительным классам. Принадлежность основному и дополнительным классам описывается в таблице object_classes.

Таблица 8. Таблица eq_class_link

eqc_id_from INTEGER NOT NULL Ссылка на основной класс
eqc_id_to INTEGER NOT NULL Ссылка на дополнительный класс

Оба поля eqc_id_from и eqc_id_to содержат ссылки на поле eqc_id таблицы eq_classes. Эквивалентность классов устанавливается хранимой процедурой. На событие удаления связи между классами процедура автоматически удаляет записи, которые связывают объекты основного класса с дополнительными классами в таблице object_classes. Пользователи без привилегий DBA имеют право только на выборку данных.

Таблица eq_class_parms

В таблице eq_class_parms (табл. 9) хранится набор параметров для основных и подчиненных классов объектов. В таблице содержатся ссылки, которые определяют набор параметров, прописанных для основного и подчиненных классов, и устанавливаются связи между этими параметрами в таблице eq_param_descr и классом в таблице eq_classes.

Таблица 9. Таблица eq_class_parms

eqcp_id SERIAL NOT NULL Первичный ключ
eqpdes_id INTEGER NOT NULL Ссылка на описание параметра
eqc_id INTEGER NOT NULL Ссылка на элемент классификатора

Записи добавляются в таблицу специальной хранимой процедурой, которая возвращает значение eqcp_id добавленной записи.

Пример 2. Используя значения objt_id для классификации университета (пример 1), иерархию классов можно описать как показано в следующих таблицах.

Таблица 10. Пример таблицы eq_classifiers

eqcs_id eqcs_name eqcs_sign
.... .... ....
4 Университеты UNIV
.... .... ....

Таблица 11. Пример таблицы eq_classes

eqc_id eqcs_id parent_id classlevel eqc_name eqc_sign
.... .... .... .... .... ....
6 4 0 Университеты UNIV
7 4 6 1 Институты INST
8 4 7 2 Факультеты DEP
9 4 8 3 Лаборатории LAB
.... .... .... .... .... ....

Таблица 12. Пример таблицы object_classes

objt_id eqcs_id eqc_id classlevel valid
.... .... .... .... ....
101 4 7 1 Y
102 4 7 1 Y
201 4 8 2 Y
202 4 8 2 Y
301 4 9 3 Y
302 4 9 3 Y
303 4 9 3 Y
.... .... .... .... ....

Моделирование атрибутов

Представленная структура данных позволяет хранить произвольное количество атрибутов (параметров объектов) с их значениями различного типа в следующих таблицах:

Таблица eq_param_descr

Таблица eq_param_descr (табл. 13) является каталогом описания параметров. Получение фактического значения параметра возможно двумя способами, в зависимости от значения eqpref_id:

  • Если eqpref_id пусто, то значение параметра должно быть явно определено в таблице eq_param_values.
  • Если eqpref_id не пусто, то таблица eq_param_values должна содержать ссылку на запись во внешней справочной таблице. Само значение может быть получено из таблицы-связки eq_param_refs, а именно по названию таблицы, имени поля с первичным ключом и имени поля с числовым значением (см. описание таблиц eq_param_refs и eq_param_values).

Таблица 13. Таблица eq_param_descr

eqpdes_id SERIAL NOT NULL Первичный ключ
eqp_type CHAR(5) NOT NULL Сигнатура типа значений параметра
meas_id INTEGER Ссылка на единицу измерения параметра
eqpref_id INTEGER Запись во внешней справочной таблице
prm_name NVARCHAR(80) Наименование параметра
prm_sign CHAR(10) Сигнатура описания параметра
  • eqp_type - содержит сигнатуру одного из стандартных типов Informix - int, float, nchar, date, dtime, money, intrv,
  • meas_id - ссылка на таблицу единиц измерения или null,
  • eqpref_id - ссылка на таблицу eq_param_refs или null,
  • prm_sign - сигнатура описания параметра, содержащая любую символьную строку в верхнем регистре для удобства выборки данных либо null. Если не пусто, значение строки должно быть уникальным. Уникальность проверяется специальным триггером. Добавление, изменение и удаление записей выполняется хранимыми процедурами.

Таблица eq_param_refs

Таблица eq_param_refs (табл. 14) содержит ссылки, используемые в описании параметров.

Таблица 14. Таблица eq_param_refs

eqpref_id SERIAL NOT NULL Первичный ключ
tname CHAR(18) NOT NULL Название внешней справочной таблицы
cname CHAR(18) NOT NULL Имя поля во внешней справочной таблице, где хранится значение параметра
pkname CHAR(18) NOT NULL Имя поля, являющегося первичным ключом во внешней справочной таблице
linktablename CHAR(18) NOT NULL Имя таблицы-связки между внешним справочником и таблицей значений параметров

Прежде чем устанавливать связь между внешней справочной таблицей и перечнем параметров объектов, необходимо предварительно создать таблицу-связку, имя которой состоит из префикса '_l_' и названия справочной таблицы. Это имя генерируется хранимой процедурой, которая по названию справочной таблицы возвращает строковое значение имени связочной таблицы. В таблице-связке должно быть два поля - первичный ключ справочной таблицы и первичный ключ таблицы eq_param_values. После того, как таблица-связка создана, можно добавлять и удалять записи в таблице eq_param_refs посредством хранимых процедур. Добавление и удаление записей в таблице-связке выполняется прямым вызовом соответствующих операторов SQL.

Пример 3. Ниже показан пример создания таблицы-связки _l_bux_inv_num. Она предназначена для хранения значений ID справочной таблицы bux_inv_num и соответствующих значений ID таблицы eq_param_values (см. описание таблиц eq_param_refs и eq_param_values):

CREATE TABLE _l_bux_inv_num (
in_id          INTEGER,
eqpv_id   INTEGER UNIQUE
);
 
ALTER TABLE _l_bux_inv_num ADD CONSTRAINT FOREIGN KEY (eqpv_id)
REFERENCES eq_param_values (eqpv_id) CONSTRAINT fk1;
 
ALTER TABLE _l_bux_inv_num ADD CONSTRAINT FOREIGN KEY (in_id)
REFERENCES bux_inv_num (in_id) CONSTRAINT fk2;

Таблица eq_param_values

В таблице eq_param_values (табл. 15) хранятся значения параметров объектов.

Таблица 15. Таблица eq_param_values

eqpv_id SERIAL NOT NULL Первичный ключ
objt_id INTEGER NOT NULL Ссылка на описание объекта
eqcp_id INTEGER NOT NULL Ссылка на описание связки параметр-класс
eqpdes_id INTEGER NOT NULL Ссылка на описание параметра
i_value INTEGER Значение параметра целого типа
f_vale FLOAT Значение параметра вещественного типа
value NVARCHAR(254,0) Значение параметра строкового или других типов

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

Поля i_value и f_value содержат такое же значение параметра, но соответственно целого и вещественного типа. Хранение, модификация и удаление этих значений выполняется посредством хранимых процедур и триггеров, которые преобразуют, если это возможно, строковые значения в целые и вещественные и наоборот. Если такое преобразование невозможно, полям i_value и f_value присваивается null. Это обеспечивает быстрый поиск записей, имеющих соответствующий тип данных.

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

Пример 4. В следующих таблицах показано, как можно хранить значения параметров различных типов. В них использованы значения objt_id подразделений (пример 1), первичные ключи eqc_id классификатора (пример 2) и данные созданной таблицы-связки _l_bux_inv_num (пример 3).

Таблица 16. Пример таблицы eq_param_descr

eqpdes_id eqp_type meas_id eqpref_id prm_name prm_sign
... ... ... ... ... ...
1001 int 31 Инвентарный номер INV_NUM
1002 date Дата образования DATE_BORN
1003 nchar Руководитель CHIEF
... ... ... ... ... ...

Таблица 17. Пример таблицы eq_class_parms

eqcp_id eqpdes_id eqc_id
... ... ...
51 1001 8
52 1002 8
53 1003 8
... ... ...

Таблица 18. Пример таблицы eq_param_refs

eqpref_id tname cname pkname linktablename
... ... ... ... ...
31 bux_inv_num inv_num in_id _l_bux_inv_num
... ... ... ... ...

Таблица 19. Пример таблицы _l_bux_inv_num

in_id eqpv_id
... ...
123201 10011
123202 10012
... ...

Таблица 20. Пример таблицы eq_param_values

eqpv_id objt_id eqcp_id eqpdes_id l_value f_value value
10011 201 51 1001 123201 123201.000000000 123201
10012 202 51 1001 123202 123202.000000000 123202
10013 201 52 1002 01/01/1907
10014 202 52 1002 01/09/1996
10015 201 53 1003 Профессор Михайлов Ю.К.
10016 202 53 1003 Профессор Арсеньев Д.Г.
... ... ... ... ... ... ...

Создание представлений для объектной структуры данных

Для удобства доступа к данным из приложения рекомендуется создать необходимые представления. Преобразование данных в таких представлениях можно реализовать операторами запроса с вызовом хранимых процедур.

Пример 5. Ниже приведен пример создания представления v_obj для извлечения информации о подразделениях:

CREATE VIEW v_obj 
    (objt_id,dlv_id,obj_name,ch_ar,in_id,inv_num,date_born,chief_name)
AS
SELECT t1.objt_id, t1.dlv_id, t1.obj_name, t1.ch_ar,
    (select {+INDEX(v 'ix1')} i_value
     from eq_param_values v, eq_param_descr d
     where v.objt_id=t1.objt_id
      and v.eqpdes_id=d.eqpdes_id
      and d.prm_sign='INV_NUM')in_id,
    (select inv_num from bux_inv_num
     where
     in_id=(select {+INDEX(v 'ix1')}
      i_value from eq_param_values v, eq_param_descr d
     where v.objt_id=t1.objt_id 
      and v.eqpdes_id=d.eqpdes_id 
      and d.prm_sign='INV_NUM'))inv_num,
    (select {+INDEX(v 'ix1')} str2date(value)
      from eq_param_values v, eq_param_descr d
     where v.objt_id=t1.objt_id 
      and v.eqpdes_id=d.eqpdes_id 
      and d.prm_sign='DATE_BORN')date_born,
    (select {+INDEX(v 'ix1')} value[1,40] 
      from eq_param_values v, eq_param_descr d
     where v.objt_id=t1.objt_id
      and v.eqpdes_id=d.eqpdes_id 
      and d.prm_sign='CHIEF')chief_name
FROM
  objects_tree t1, eq_classes t2, object_classes t3, 
  objects_tree t4, objects_parents t5
WHERE     t2.eqc_sign='DEP' AND
     t3.objt_id=t1.objt_id AND
     t4.objt_id=t5.prnt_id AND
     t5.chld_id=t1.objt_id AND
     t2.eqc_id=t3.eqc_id
WITH CHECK OPTION;
 
GRANT SELECT ON v_obj TO PUBLIC;

В представлении v_obj подразделения выделяются из других объектов по условию eqc.sign='DEP' (см. пример 1). Атрибуты объектов, такие как инвентарный номер, дата образования и руководитель, выбираются по сигнатурам соответственно INV_NUM, DATE_BORN и CHIEF. Применительно к атрибуту inv_num (инвентарный номер), поля in_id и inv_num выбираются из справочной таблицы bux_inv_num. Функция str2date, определенная пользователем, преобразует строку date_born (дата образования) в значение типа datetime с учетом разделителя в настройках локали. Для улучшения производительности базы данных в строковом параметре chief_name (руководитель) берутся только первые 40 символов.

Выборка из представления v_obj дает список подразделений с их атрибутами, как показано ниже.

SELECT obj_name, inv_num, date_born, chief_name FROM v_obj

Таблица 21. Пример выборки SELECT

obj_name inv_num date_born chief_name
Механико-машиностроительный факультет 123201 01/01/1907 Профессор Михайлов Ю.К.
Факультет вычислительной техники 123202 01/09/1996 Профессор Арсеньев Д.Г.

Практическая реализация

Представленная в статье структура данных является смешаной объектно-реляционной и иерархической. Она предназначена для хранения многоуровневых объектов, имеющих произвольный набор атрибутов (параметров) различного типа, а также для их классификации. Элементы базы данных могут быть созданы как на платформе Informix Universal Server, так и Informix Dynamic Server, позволяя решать общеизвестные проблемы в информационных системах.

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

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

Представленная структура данных обладает следующими преимуществами по сравнению с традиционными аналогами:

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

Ограничения

Существует ряд ограничений на хранение атрибутов некоторых типов, особенно даты/времени (см. таблицу eq_param_values). За исключением целых и вещественных, значения других типов данных хранятся в поле value в виде текстовой строки. Для значений даты/времени в таблице eq_param_values нет специального поля datetime, и они должны храниться в строковом виде. В процессе выборки данных требуется преобразование строкового значения в дату/время. Для этого используются хранимые процедуры, в которых учитываются настройки локали.

Список использованных источников

1. P. Brown. Object-Relational Database Development: A Plumber's Guide. Informix Press (2001).
2. Объектно-реляционная СУБД Informix Universal Server / А. Грачев.- Informix Magazine / Russian Edition.- 1998.- № 1. http://www.florin.ru/win/informix_magazine/1_98/5_0.html .
3. M. Guttman and J. Matthews. The Object Technology Revolution. John Wiley & Sons (1995).
4. Online Objects Tree (OOT) - система построения, агрегации и хранения иерархической структуры объектов произвольных типов.- Informix Magazine / Russian Edition.- 1998.- № 1. http://www.florin.ru/win/informix_magazine/1_98/4_5.html .
5. Определение оптимальной структуры базы данных / А. Прохоров.- Informix Magazine / Russian Edition.- 1998.- № 1. http://www.florin.ru/win/informix_magazine/1_98/5_1.html .
6. A. Sanchez. Informix Dynamic Server with Universal Data Option: Best Practices. Informix Press (1999).
7. M. Stonebraker and P. Brown with D. Moore. Object Relational Databases (2nd edition). Morgan Kaufmann Publishers (1998).

В начало

Фото: Мещеряков С.В.Мещеряков С.В., к.т.н., доцент, окончил Вологодский политехнический институт по специальности автоматизация машиностроительного производства. В настоящее время является доцентом Санкт-Петербургского государственного политехнического университета. E-mail: serg@imop.spbstu.ru Перевод с английского: Serg V. Mescheryakov. A Successful Implementation of a Data Structure for Storing Multilevel Objects with Varying Attributes. IBM (2002). © 2002 International Business Machines Corporation. All rights reserved. IBM, Informix, Informix Universal Server, Informix Web DataBlade are trademarks or registered trademarks of IBM Corporation in the United States, other countries, or both. Other company, product, and service names may be trademarks or service marks of others.