Моделирование иерархических объектов с произвольным набором атрибутов

Математическое моделирование: методы, алгоритмы, технологии ^

С. В. Мещеряков, В. М. Иванов Моделирование иерархических объектов

с произвольным набором атрибутов

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

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

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

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

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

v. - In п ,

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

v ~ п к,

где к — количество колонок в таблице.

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

чем больше атрибутов (колонок в таблице), тем больше индексов нужно создавать;

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

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

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

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

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

Informix Universal Server — это СУБД объ-ектно-реляционного типа, созданная путем внедрения технологии объектно-ориентирован-ного программирования в популярную СУБД Informix Dynamic Server [1.6]. Она имеет следующие свойства рассматриваемого подхода: абстрактные типы данных; наследование; иерархии данных и типов. На практике встречается много примеров, когда набора стандартных типов недостаточно. Хотя абстрактные типы данных дают определенные преимущества, описание новых типов в СУБД не совсем приемлемо — в дальнейшем всегда может возникнуть потребность добавить еще один тип.

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

Научно-технические ведомости СПбГПУ 1' 2009. ^Информатика. Телекоммуникации. Управление

навыки опытных программистов по ра зработке на языке "Си" процедур и методов хранения, доступа и индексирования данных.

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

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

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

Дерево объектов [5] представляет собой информационную систему для хранения иерархической структуры данных. Задача усложняется

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

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

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

espv_id SERIAL

obit id INTEGER

e«cp_'d INTEGER <k2>

cqp'Jtí id INTEGER <*3>

i wjlu« INTEGER

1 '.jloc П_ОАТ

vjlgc NVARCHAft<254)

eqpdesTíd^eqpdes

jd=eqpv_ii

eqpv/id=eqpy _id ob)t_td;/ot>jt_id

«•IP««.'« SERIAUIO)

CHAfVít)

¡HTEG6R

»IP'f.id INTEGER <<k>

£>ffTi_r>¿mí NVAftCHORiSO)

CHARCO)

«b;l_i¿ INTEGER <«(!> INTEGER "*2>

in_id INTEGER

INTEGER <*>

eqpref_id=eqpr

¡f id

SERiAUIO) dlt.id INTEGER tbl.njn« NVARCHAP

—z-

objt_¡<¡ =chld_id ob(t

'iftjme

SERiAKtOi CHAROS) jcnjrr.c CHALIS)

[fcnjmc CHAR08)

jlirfcUbltn «M СНАЛЧ9)

jd=prnt_¡d

ofrltíbLpaicnb

opin!_id SERiAUlQ^ chldjd INTEGER prm_td INTEGER *fl2>

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

Научно-технические ведомости СПбГПУ 1' 2009. Информатика. Телекоммуникации. Управление

Таблица 1

Описание l ao.iHii СУ БД для хранении иерархических объектов

Поле данных Описание

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

objects tree

objtjd SERIAL NOT NULL Первичный ключ

dlv id INTEGER NOT NULL ГО подразделения, где находится объект

obi name NVARCHAR(254.1) NOT NULL Наименование объекта

ch_ar CHAR(I) Признак активности/архивности

objects_parents

oprnt id SERIAL NOT NULL Первичный ключ

chid id INTEGER NOT NULL ГО потомка

prnt id INTEGER NOT NULL ГО предка

eq param descr

eqpdes_id SERIAL NOT NULL Первичный ключ

eqp type CHARD) NOT NULL Сигнатура типа значений параметра

meas id INTEGER Ссылка на единицу измерения параметра

eqpref id INTEGER Запись во внешней справочной таблице

prm name NVARCHAR(80) Наименование параметра

prm sign CHAR(IO) Сигнатура описания параметра

eq param refs

eqpref id SERIAL NOT NULL Первичный ключ

tname CHAR( 18) NOT NULL Название внешней справочной таблицы

cname CHAR( 18) NOT NULL Имя поля во внешней справочной таблице, где хранится значение параметра

pkname CHAR( 18) NOT NULL Имя поля, являющегося первичным ключом во внешней справочной таблице

linktablename CHARI18) NOT NULL Имя таблицы-связки между внешним справочником и таблицей значений параметров

eq param values

eqpv id SERIAL NOT NULL Первичный ключ

objtjd INTEGER NOT NULL Ссылка на описание объекта

eqcp id INTEGER NOT NULL Ссылка на описание связки параметр-класс

eqpdes id INTEGER NOT NULL Ссылка на описание параметра

i value INTEGER Значение параметра целого типа

f value FLOAT Значение параметра вещественного типа

value NVARCHAR(254.0) Значение параметра строкового типа

1. Если eqpref_id пусто, то значение параметра должно быть явно определено в таблице eq_param_values.

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

eqp_type — содержит сигнатуру одного из стандартных типов Informix: int. float, nchar, date, dtime, money, intrv;

measjd —ссылка на таблицу единиц измерения или null;

eqprefjd — ссылка на таблицу eq_param_ refs или null;

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

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

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

4-

Математическое моделирование: методы, алгоритмы, технологии

Таблица 2

Примеры заполнения таблиц СУБД для хранения иерархических объектов

objects_tree

obit id оЬ] паше

10 Политехнический университет

101 Институт электроники

102 Институт механики

201 Механико-машиностроительный факультет

202 Факультет вычислительной техники

301 Лаборатория металлорежущих станков

302 Лаборатория металлорежущего инструмента

303 Лаборатория компьютерной графики

objects_parents

oprnt id chid id prntjd

11 101 10

12 102 10

13 201 102

14 202 101

15 301 201

16 302 201

17 303 202

eq_param_descr

eqpdesjd eqp_tvpe meas id eqprefjd prm_name prm_sign

1001 int 31 Инвентарный номер INV NUM

1002 date Дата образования DATE BORN

1003 nchar Руководитель CHIEF

cq_param__refs

cqpref id tname cname pkname linktablename

31 bux inv num inv num in id 1 bux inv num

Lbuxjnv_num

in id eqpvjd

123201 10011

123202 10012

eq_param_values

eqpvjd objt id eqcpjd eqpdesjd 1 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 Профессор M.M. Радкевич

10016 202 53 1003 Профессор И.Г. Черноруit-кий

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

Далее представлен образец создания таблицы-связки _l_bux_inv_num (пример 2). Она предназначена для хранения значений ID справочной таблицы bux_inv_nuni и соответствующих значений ID таблицы eq_param_values (см. описание eq_param_refs и eq_param_values в табл. 1).

Пример 2.

CREATE TABLE _l_bux_inv_num

REFERENCES eq_param_values (eqpvjd) CONSTRAINT fkI:

ALTER TABLE J_buxJnv_num ADD CONSTRAINT FOREIGN KEY

REFERENCES buxjnv_num (injd) CONSTRAINT fk2:

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

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

Поля Lvalue и Lvalue содержат такие же значения параметров, но соответственно целого

Научно-технические ведомости СПбГПУ 1 ' 2009. Информатика. Телекоммуникации. Управление

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

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

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

ра eqcp_id и данные созданной таблицы-связки _l_bux_inv_num (см. пример 2).

Ограничения

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

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

Serg V. Mescheryakov. A Successful Implementation of a Data Structure for Storing Multilevel Objects with Varying Attributes. IBM. Informix Developer Zone. 2002 (http://www.ibm.com).

СПИСОК ЛИТЕРАТУРЫ

1. Грачев А. Объектно-реляционная СУБД Informix Universal Server// Informix Magazine / RE. 1998. № I (http://www.florin.ru/win/informix_maga-zine/l_98/5_0.html).

2. Прохоров А. Определение оптимальной структуры базы данных // Informix Magazine / RE. 1998. № I (http://www.florin.ru/win/informix_maga-zine/l_98/5_I.html).

3. Brown P. Object-Relational Database Development: A Plumber's Guide. Informix Press. 2001.

4. Guttman M., Matthews J. The Object Technology Revolution. John Wiley & Sons. 1995.

5. Online Objects 'Ггее(ООТ) —система построения. агрегации и хранения иерархической структуры объектов произвольных типов // Informix Magazine / Russian Edition. 1998. № I (http://www.norin.ru/win/ informix_magazine/l _98/4_5 .html).

6. Sanchez A. Informix Dynamic Server with Universal Data Option: Best Practices. Informix Press. 1999.

7. Stonebraker M., Brown P., Moore D. Object Relational Databases (2nd edition). Morgan Kaufmann Publishers. 1998.

Б. В. Бредихин

Особенности моделирования системы управления составным импульсным преобразователем

Импульсные преобразователи энергии при исследовании их динамических свойств рассматривались двояким образом [1, 5]: как импульсная (дискретная) система автоматического управления (САУ) и как непрерывная система. Поскольку изначально преобразо-

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

При решении многих задач анализа и синтеза импульсных преобразователей целесооб-