CC BY
29
Математическое моделирование: методы, алгоритмы, технологии ^
С. В. Мещеряков, В. М. Иванов Моделирование иерархических объектов
с произвольным набором атрибутов
Объектно-ориентированное программирование было революционным подходом в 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(10)
obit id INTEGER
e«cp_'d INTEGER <k2>
cqp'Jtí id INTEGER <*3>
i wjlu« INTEGER
1 '.jloc П_ОАТ(15)
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(2S4) ch "it СНАЛЧ)
—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 ( in_id INTEGER, eqpvjd INTEGER UNIQUE); ALTER TABLE _l_bux_inv_num ADD CONSTRAINT FOREIGN KEY (eqpvjd)
REFERENCES eq_param_values (eqpvjd) CONSTRAINT fkI:
ALTER TABLE J_buxJnv_num ADD CONSTRAINT FOREIGN KEY (injd)
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]: как импульсная (дискретная) система автоматического управления (САУ) и как непрерывная система. Поскольку изначально преобразо-
ватель как САУ — система нелинейная, при обоих подходах использовалась линеаризация, позволяющая упростить анализ и получить точные результаты.
При решении многих задач анализа и синтеза импульсных преобразователей целесооб-
