УСОВЕРШЕНСТВОВАННОЕ УПРАВЛЕНИЕ ИНФОРМАЦИЕЙ: НОВЫЕ ТЕХНОЛОГИИ
БАЗ ДАННЫХ ДЛЯ ИНТЕГРИРОВАННЫХ ПРИКЛАДНЫХ СИСТЕМ
Введение ...................................................
1. Проект AIM..................................................
2. Хейдельбергский язык базы данных (HDBL).....................
3. Типы данных и функции, определяемые пользователем...........
4. Диалоговый интерфейс и интерфейсы прикладных программ.......
5. Архитектура системы AIM-P ..................................
Заключение .................................................
Проект усовершенствованных средств управления информацией
(Advanced Information Management - AIM) в настоящее время является
одним из главных направлений деятельности научного центра фирмы IBM в
Хайдельберге. Основная цель проекта - изучение требований к базам
данных (БД) и соответствующих проектных решений для новых интегриро-
ванных областей применения, таких как компьютеризованные производства
и учреждения. Для этих областей необходима новая технология БД, кото-
рая позволила бы надежно и эффективно управлять большими объемами
разнородных данных. Такая технология должна поддерживать не только
простые числовые данные, простые таблицы, используемые в управлении,
но и объекты сложной структуры, в том числе тексты, изображения,
речь. В этой статье описываются основные положения, цели и достижения
проекта AIM. Она также содержит обзор постановки, реализации и кон-
цепций AIM-P - экспериментальной СУБД, разработанной в рамках проекта
AIM.
Для новых областей применения необходима усовершенствованная
технология БД, позволяющая управлять большими объемами данных различ-
ных типов. При представлении этих типов данных как можно более "ес-
тественнее" с прикладной точки зрения можно избежать сложных отобра-
жений представления данных, используемых в прикладных программах, в
представления данных в БД. Это положение является очень важным, если
технология БД используется с целью повышения эффективности, а не
только в качестве средства интеграции в прикладном программировании.
Естественным может быть представление данных, зависящее от предметной
области. Системы автоматизации проектирования (CAD) могут использо-
вать объектно-ориентированные данные, например, о компьютерных платах
X и Y и связанных с ними объектах (возможно, обладающих своей струк-
турой), в то время, как системы компьютеризованного производства
(САМ) используют данные, ориентированные на данные, например, коли-
чество и тип микросхем во всех платах компьютера, независимо от того,
в какие объекты входят эти микросхемы. Это значит, что для того, что-
бы быть адекватной интегрированной обработке информации, технология
баз данных должна поддерживать различные представления одного и того
же типа данных или объекта, с одной стороны, и единообразное предс-
тавление большого количества различных типов данных, с другой сторо-
ны.
Современные СУБД создавались применительно к задачам администри-
рования в области бизнеса. Они не пригодны для реализации вышеупомя-
нутых систем в отношении моделей данных и эффективности. Как следст-
вие, в каждой из основных областей применения в настоящее время ис-
пользуется огромное количество специализированных файловых систем и
СУБД (рис.1).
-----------¬ -----------¬ ----------¬ ----------¬ ----------¬
¦Текстовые ¦ ¦Табличные ¦ ¦Данные в ¦ ¦Инженерные ¦Географи-¦
¦ данные ¦ ¦ данные ¦ ¦учреждени¦ ¦и научные¦ ¦ческие и ¦
L----T------ L----T------ ¦ ях ¦ ¦ данные ¦ ¦графичес-¦
¦ ¦ L----T----- L----T----- ¦кие данные
компьютер ¦ ¦ ¦ L----T-----
--------+-------------+-------------+------------+------------+-----¬
¦ ¦ ¦ ¦ ¦ ¦ ¦
¦ -----+----¬ ------+-----¬ -----+----¬ -----+----¬ -----+----¬¦
¦ ¦Прикладные ¦Прикладные ¦ ¦Прикладные ¦Прикладные ¦Прикладные¦
¦ ¦программы¦ ¦программы ¦ ¦программы¦ ¦программы¦ ¦программы¦¦
¦ L----T----- L-----T------ L----T----- L----T----- L----T-----¦
¦ ¦ ¦ ¦ ¦ ¦ ¦
¦ -----+----¬ ------+-----¬ -----+----¬ -----+----¬ -----+----¬¦
¦ ¦ ¦ ¦ ¦ ¦ Оффисная¦ ¦Специаль-¦ ¦Специаль-¦¦
¦ ¦ ИПС ¦ ¦ СУБД ¦ ¦ система ¦ ¦ная систе¦ ¦ная сист妦
¦ L---------- L------------ L---------- ¦ ма ¦ ¦ ма ¦¦
¦ L---------- L----------¦
L--------------------------------------------------------------------
Рис. 1.
Эти системы отличаются функционально, представлением данных (мо-
делями данных, интерфейсами), стратегией обработки (оперативным изме-
нением данных, пакетным обновлением), управлением транзакциями, сред-
ствами восстановления и защиты, делая интеграцию прикладных систем
довольно сложной задачей. Разрешить эту ситуацию могли бы мощные
СУБД, поддерживающие данные различных предметных областей универсаль-
ным способом, могут (рис.2). Скорее всего, один тип системы не сможет
поддерживать все области применения. Однако можно стремиться покрыть
80-90 % основных типов приложений.
В настоящее время расширенная технология БД достаточно подробно
изучена. Ниже мы рассмотрим некоторые работы, оказавшие влияние на
этот проект.
-----------¬ -----------¬ ----------¬ ----------¬ ----------¬
¦Текстовые ¦ ¦Табличные ¦ ¦Данные в ¦ ¦Инженерные ¦Географи-¦
¦ данные ¦ ¦ данные ¦ ¦учреждени¦ ¦и научные¦ ¦ческие и ¦
L----T------ L----T------ ¦ ях ¦ ¦ данные ¦ ¦графичес-¦
¦ ¦ L----T----- L----T----- ¦кие данные
¦ ¦ ¦ ¦ L----T-----
¦ ¦ ¦ ¦ ¦
¦ ¦ ¦ ¦ ¦
-----+----¬ ------+-----¬ -----+----¬ -----+----¬ -----+----¬
¦Прикладные ¦Прикладные ¦ ¦Прикладные ¦Прикладные ¦Прикладные
¦программы¦ ¦программы ¦ ¦программы¦ ¦программы¦ ¦программы¦
L----T----- L-----T------ L----T----- L----T----- L----T-----
¦ ¦ ¦ ¦ ¦
¦ L----------¬ ¦ ----------- ¦
¦ ¦ ¦ ¦ ¦
¦ --+--+--+-¬ ¦
L----------------------+ СУБД +---------------------
¦ ¦
L----------
Рис. 2.
В проекте XSQL в теорию баз данных вводится термин "сложный объ-
ект". При использовании специальных атрибутов ("состоит_из", "являет-
ся_частью"), иерархические структуры можно определять в реляцион-
но-решетчатой модели данных. В процессе работы эти атрибуты использу-
ются для непосредственной выборки кортежей, составляющих сложный объ-
ект, без использования операции JOIN. Входящая в состав интерфейса
прикладных программ XSQL специальная структура данных в оперативной
памяти используется для передачи структуры и содержимого кортежа, со-
ответствующего сложному объекту, в прикладную программу.
Postgres поддерживает процедуры, состоящие из операторов языка
Postquel, а также процедуры, написанные на обычных языках программи-
рования, таких как ЛИСП и СИ. В этом подходе атрибуты таблиц БД могут
иметь процедурные значения, то есть значения атрибутов могут быть
процедурами, написанными на языках Postquel или Си. При каждом обра-
щении к атрибутам вызываются соответствующие процедуры. Более того,
Postgres поддерживает концепцию абстрактных типов дан ных, но только
как низкоуровневых представлений неструктурированных областей памяти.
Хранится только размер области; строгого определения типа, как того
требует теория абстрактных типов данных, нет. Тот же метод использу-
ется для передачи параметров от Postgres функциям, написанным на ЛИСПе
и Си.
В системе PROBE различают сущности и функции. Доступ к значениям
атрибутов сущностей возможен только с помощью соответствующих функ-
ций. Функции могут быть системными или определяемыми пользователем.
В Проекте Starburst исследовались вопросы проектирования архи-
тектуры СУБД с альтернативными областями памяти для отношений и соот-
ветствующих индексов.
GENESIS и EXODUS являются, по существу, инструментальными прог-
раммными средствами, обеспечивающими конфигурирование СУБД в соответ-
ствии с заданными спецификациями. GENESIS основана на компонентах БД,
интерфейсы которых стандартизованы, обеспечивая взаимозаменяемость
компонент. Одной из целей EXODUS является формирование ядра СУБД и
инструментальных программных средств для частичной генерации проблем-
но-ориентированных СУБД. При предположении, что в перспек тиве будут
существовать большие библиотеки проблемно-ориентированных типов дан-
ных и соответствующих функций, которые могут быть добавлены к ядру БД
(настройка), инструментальные средства типа GENESIS и EXODUS понадо-
бятся для конфигурирования таких систем.
В проекте DASDBS создается ядро БД, к верхнему уровню которого
могут подключаться различные проблемно-ориентированные интерфейсы. В
проекте разрабатывается поддержка вложенных отношений, вложенных тран-
закций, оптимизация запросов (на основе реляционно-решетчатого подхода
к вложенным отношениям в БД), расширяемость и вопросы архитектуры БД.
На проект PRIMA и лежащую в его основе модель данных оказал силь-
ное влияние молекулярный подход к представлению объектов. В этом про-
екте применяется SQL-подобный язык манипулирования данными, использую-
щий ссылки для моделирования рекурсивных или произвольных сетеподобных
структур данных. Особое внимание в проекте уделено архитектуре БД и
обработке рекурсивных запросов.
Проект AIM ставит целью исследовать возможность использования
технологии БД как средства интеграции данных. В этой статье также рас-
сматриваются функции и архитектура экспериментальной СУБД, основанной
на расширенной NF2 (вторая нормальная форма) модели данных, относящей
ся к классу реляционных. В первой части статьи представляются цели
проекта и теоретические предпосылки. Следующая часть содержит описание
языка БД и модели данных. В дополнительных разделах показано как язык
БД может быть расширен определенными пользователем типами данных и
функциями; описывается интерфейс с прикладными программами, позволяю-
щий пользователю использовать возможности СУБД из языка программирова-
ния и приводятся детали архитектуры системы.
1. Проект AIM
Проект AIM начался в 1979 г. объединением реляционной технологии с
новой техникой индексирования. При изучении систем автоматизации уч-
режденческой деятельности выяснилось, что классическая реляционная мо-
дель, даже дополненная средствами поиска текстов, не подходит для мо-
делирования сложных информационных объектов, таких как книги, докумен-
ты и различные типы форм. С другой стороны, технология реляционных БД
с ее гибкостью формулирования запросов к БД, структуризацией результа-
та, возможностью определения различных подмножеств таблиц и другими
свойствами - безусловно является перспективным направлением. Желание
использовать реляционный формализм для работы со структурными объекта-
ми привело в итоге (независимо от других групп, подобных VERSO) к идее
вложенных отношений. Они были названы отношениями NF2, так как первая
нормальная форма, неприменимая в данном случае, требует, чтобы значе-
ния атрибута были атомарными. Ясно, что наиболее критическим стал воп-
рос о том, может ли расширенная реляционная модель быть столь же легко
теоретически обоснована как классическая. Сначала проект концентриро-
вался в первую очередь на теоретических вопросах модели данных, осо-
бенно на ее отношении к функциональным и многозначным зависимостям.
Эта рпбота составила научный вклад в теорию вложенных отношений. Па-
раллельно этой более фундаментальной исследовательской работе была на-
чата разработка концепций создания расширенного SQL-подобного языка
БД, позволяющего работать с расширенной реляционной моделью на уровне
пользователя.
В 1982-1983 гг.. возникла необходимость в решении проблемы интег-
рации прикладных систем, разработанных для ранее не связанных друг с
другом предметных областей (о чем говорилось выше) и в определении
требований к связанным базам данных, а также проблем, возникающих при
интеграции. В связи с этим было решено направить исследования и проек-
тные работы на более широкое изучение вопросов связи баз данных. При
этом главным объектом изучения были объявлены требования к базам дан-
ных и пути реализации теоретических разработок для связанных баз дан-
ных в среде экспериментальной СУБД, названной AIM-P (Advanced
Information Management Prototype).
Ключевая концепция, которая должна была быть проверена в среде
экспериментальной СУБД, - это модель данных NF2, поскольку она способ-
на п ддерживать иерархические структуры и таблицы универсальным, а
именно реляционном способом. Кроме того, она обладает мощным языком
запросов, который позволяет рассматривать один и тот же тип данных как
с ориентацией на объекты, так и с ориентацией на данные. Однако вместо
чистой модели данных NF2 была использована расширенная версия, поддер-
живающая списки и множества в более общем виде и названная расширенной
NF2 моделью данных. Одновременно с исследованием модели данных на экс-
периментальной СУБД изучались другие вопросы, связанные с базами дан-
ных. Ниже излагаются цели проектирования всей системы и описываются
связанные с этим исследовательские и проектные разработки.
Архитектура.
Архитектура СУБД должна удовлетворять принципу "рабочая стан-
ция-сервер". Это значит, что центральный сервер базы данных должен
поддерживать распределенные данные, в то время как собственно обработ-
ка объектов баз данных (создание и манипулирование данными или объек-
тами) выполняется на рабочих станциях (в пользовательских прикладных
программах). Особое внимание должно быть уделено созданию эффективных
механизмов обмена данными между сервером и рабочими станциями с целью
уменьшения коммуникационных издержек, особенно в случаях работы с
большими объектами сложной структуры. Другими словами, архитектура ин-
тегрдрующей системы должна поддерживать эффективную совместимую обра-
ботку сложных объектов по принципу "сервер-станция".
Язык базы данных и модель данных.
Сервер БД должен обеспечивать однотипное представление всех типов
данных (от решетчатых отношений до сложных объектов), чтобы являться
интегрирующим средством. Это значит, что сложные объекты должны расс-
матриваться не как особые случаи, а как составная часть модели данных.
Все, или почти все операции, определенные для решетчатых данных, долж-
ны быть применимы в равной степени для сложных объектов. В сервере
должна использоваться модель данных реляционного типа с множествен-
но-ориентированным дескриптивным языком запросов, что обеспечит мини-
мальные издержки при обмене между сервером и рабочими станциями. Стан-
ция должна использовать этот интерфейс при обращении к данным. Интер-
фейс, который доступен пользователю или прикладной программе на стан-
ции, должен быть проблемно-ориентированным.
Расширяемость.
С течением времени СУБД должны становиться более настраиваемыми к
требованиям прикладных систем. Необходимые функции, такие как фильтры
для выбора правильных объектов из сервера БД, должны стать частью язы-
ка запросов сервера, а не частью прикладной программы станции, которая
выполняет выборку данных только после пересылки всех данных. Первым
шагом в этом направлениидолжна стать поддержка сервером БД типов дан-
ных и функций, определенных пользователем.
2. ХЕЙДЕЛЬБЕРГСКИЙ ЯЗЫК БАЗЫ ДАННЫХ (HDBL)
Ниже описывается главным образом модель данных AIM-P и соответст-
вующий язык БД. Подробное описание языка можно найти в литературе.
Модель данных:
Модель данных, поддерживаемая в AIM-P, является объектно-ориен-
тирован ным обобщением NF2 в части вложенных отношений. В начале в
проекте AIM-P использовалась чистая NF2 модель данных, дополненная
концепцией упорядоченных отношений и списком атомарных значений, выс-
тупающих в качестве значений атрибутов для того, чтобы адекватно
представлять численные век тора, матрицы и подобные конструкции.
Вскоре было показано, что ортого нальная модель данных более эффек-
тивна как с точки зрения пользователя, так и с позиций внутренней об-
работки запросов. Это значит, что атомарные и конструируемые типы
должны быть легко сочетаемы так, чтобы типы, которые могут быть пост-
роены в рамках языка запросов, поддерживались моделью данных. SQL в
этом смысле не является ортогональным языком. В реляционно-решетчатой
модели данных, на которой функционирует SQL, допустимы только множес-
тва кортежей.
В результате этих соображений была создана модель данных, осно-
ванная на концепции конструкционных типов (множеств, списков, корте-
жей) и атомарных типов (даты, целые, действительные, булевские, сим-
вольные, текстовые). Все конструкционные типы могут сочетаться один с
другим и с атомарными типами произвольным способом. Более того, каж-
дая из этих конструк ций (конструкционные типы и атомарные типы) мо-
жет встречаться на любом уровне объектного типа. К примеру, атрибуты
объекта, значение которого - кортеж, могут иметь значения атомарных
типов или типа множество, список или кортеж. Объекты не обязательно
являются элементами таблиц. Список списков действительных значений
(являющийся двумерной матрицей) может встречаться в качестве элемента
в другом списке или множестве, как значение атрибута в кортеже или
как самостоятельный объект (имеющий соответствующее имя). Объект мо-
жет быть даже простым целым, например,- максимальный использованный
номер накладной.
На рис.3 показано графическое представление рассматриваемой мо-
дели данных; как нормальная форма, так и чистая NF2 модель являются
частными случаями этой более общей модели данных. Эта модель данных
называется также расширенной NF2 моделью данных, так как она была
разработана путем развития модели данных NF2.
---¬ ---¬
¦ v ¦ ------------> ¦ v ¦
Списки Множества Отношение Отношение
¦ ^ ¦ <------------ ¦ ^ ¦ --(множество)¬ (множество)
¦ ¦ ¦ ------¬ ¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ L--->- L<---- ¦ ¦ ¦ ¦ ¦
¦ L------Кортежи------- ¦ ¦ ¦ Кортежи
¦ ¦ L---Кортежи--- ¦
¦ ¦ ¦ ¦
¦ ¦ ¦ ¦
¦ ¦ ¦ Атомарные
¦ ¦ Атомарные значения
¦ ¦ значения
L--------Атомарные--------- Первая нор-
значения мальная фор
модель данных AIM-P NF2 модель ма
(расширенная NF2 модель данных
данных)
Рис.3. Сравнение моделей данных AIM-P, NF2, NF1.
Язык БД:
В AIM-P используется SQL-подобный языковый интерфейс, HDBL, но в
противополож ность SQL, пользователь HDBL должен в явном виде указы-
вать тип результата. В SQL поддерживается только один тип результата,-
множество кортежей, - и выражения вида
SELECT dno
FROM departments
будут всегда таблицами, состоящими из одного столбца (унарное от
ношение). В HDBL такой результат тоже допустим, но допустимым может
быть и множество атомарных значений. По этой причине HDBL использует
вышеупо мянутые конструкционные типы для явного описания желаемой
структуры элементов результата (за исключением исходных структур, ко-
торые должны использоваться непосредственно). В нем используется но-
тация tuple(...) или [...] для определения структуры типа "кортеж",
list(...) или <...> для определения структуры типа "список" и
set(...) или {...} для определения структуры типа "множество". Эле-
менты результата являются неупорядоченными или упорядоченными в зави-
симости от исходных данных. Если они упорядочены, то результат упоря-
дочен; в противном случае он неупорядочен. Если результат вычисляется
с использованием операции JOIN, он является упорядоченным, если все
включенные таблицы упорядочены (списки кортежей ), иначе он является
частично упорядоченным (соединение множеств и списков кортежей) или
неупорядоченным (если включены толь ко множества кортежей).
Далее рассмотрим возможности HDBL на примерах. Основу примеров
составляет таблица, содержащая информацию о производственных цехах
(см. таблицу 1). Соответствующий оператор CREATE представлен на
рис.4. Как и в классическом SQL, в HDBL используется конструкция
SELECT-FROM-WHERE (SFW) для выражения операций проекции, ограничения
и соединения. Однако в HDBL конструкция SFW намного мощнее, чем в
SQL. Следующие примеры иллюстрируют это.
Таблица 1
Информация о производственных цехах в представлении NF2
--------------------------------------------------------------------¬
¦ { manuf-depts} ¦
+------T-------T------------------------------T---------------------+
¦ ¦ ¦ { manuf-cells} ¦ { staff } ¦
¦ ¦ +----T------------T------------+--------T------------+
¦ dno ¦ dname ¦ ¦{non-nc-mach} {nc-mach} ¦ ¦ ¦
¦ ¦ ¦cid +----T-------+----T-------+ eno ¦ function ¦
¦ ¦ ¦ ¦ qu ¦ type ¦ qu ¦ type ¦ ¦ ¦
¦------+-------+----+----+-------+----+-------+--------+------------+
¦ 15 ¦ Shafts¦ c13¦ 1 ¦MLDX300¦ 1 ¦NRP5000¦ 1217 ¦NC Programmer
¦ ¦ ¦ ¦ 1 ¦MLDX230¦ 1 ¦FLex ¦ 1494 ¦NC Programmer
¦ ¦ ¦ ¦ 1 ¦Autex77¦ ¦ ¦ 1548 ¦Supervisor ¦
¦ ¦ +----+----+-------+----+-------+ 1799 ¦Supervisor ¦
¦ ¦ ¦ c28¦ 1 ¦Varix92¦ 1 ¦Speedy5¦ 1852 ¦Laborer ¦
¦ ¦ ¦ ¦ 2 ¦Varix99¦ 2 ¦Preci ¦ 1877 ¦Chief ¦
¦ ¦ ¦ ¦ 1 ¦Autex77¦ ¦ ¦ 1938 ¦Laborer ¦
¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ 1941 ¦Laborer ¦
¦------+-------+----+----+-------+----+-------+--------+------------+
¦ 22 ¦ Slats ¦ c11¦ 2 ¦MLDX300¦ 1 ¦DSX700 ¦ 1199 ¦Supervisor ¦
¦ ¦ ¦ ¦ 1 ¦JRP500 ¦ 1 ¦DSX800 ¦ 1292 ¦Chief ¦
¦ ¦ ¦ ¦ 1 ¦Autex35¦ ¦ ¦ 1385 ¦NC Programmer
¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ 1741 ¦Laborer ¦
¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ 1855 ¦Laborer ¦
L------+-------+----+----+-------+----+-------+--------+-------------
create manuf_depts |производственные цеха
{ [ dno: integer, |номер цеха
dname: string (40), |название цеха
manuf_cells: |производств. участки
{ [ cid: string (10), |идентификат. участка
non_nc_mach: |не_приборы
{ [ qu: integer, | количество
type: string (40) ] }, | тип
|
nc_mach: |приборы
{ [ qu: integer, | количество
type: string (40)] } | тип
|
] }, |
staff: |персонал
{ [ eno: integer, | табельный номер
function: string (40)] } | должность
|
] } |
end |
Рис.4. Оператор CREATE для manuf_depts
Первый пример иллюстрирует, как найти полностью таблицу
manuf_depts
SELECT x
FROM x IN manuf_depts
Cледующий пример ищет все приборы (nc)
SELECT nc
FROM m IN manuf_depts,
cell IN m.manuf_cells,
nc IN cell, nc_mach.
Этот пример показывает, каким образом ищется подтаблица: опреде-
ляется связанная с manuf_depts переменная m. Переменная cell зависит
от m. Переменная nc, в свою очередь, иерархически зависит от cells.
Если интересуются не всеми nc, а только теми, у которых qu больше 1,
то к запросу может быть добавлен соответствующий предикат:
SELECT nc
FROM m IN manuf_depts,
cell IN m.manuf_cells,
nc IN cell. nc. mach
WHERE nc.qu > 1.
Следующий пример показывает случай вложенной конструкции SFW.
Для каждого цеха (manuf_depts) будут найдены только те участки
(manuf_cells), в которых есть приборы (nc_mach) типа Flex 200:
SELECT [ m.dno,
manuf_cells:
( SELECT [ cell.CID, cell.nc_mach ]
FROM cell IN m.manuf_cells
WHERE EXISTS ( nc IN cell.nc_mach):
nc.TYPE = `Flex 200` )]
FROM m IN manuf_depts
С помощью той же техники подзапросов может быть сформулировано
также вложение таблиц . Пусть имеются две таблицы MDEPT (dno, dname)
и staff (dno, eno, function). Из этих двух исходных таблиц с помощью
HDBL можно частично (только dno, dname, staff) собрать manuf_depts
(таблица 1). Это можно сделать следующим выражением HDBL:
SELECT [ x.dno, x.dname,
staff:
(SELECT [ y.ENO,
y.FUNCTION ]
FROM y IN SIAFF
WHERE x.dno = y.dno )]
FROM x IN MDEPT
Разъединение вложенных таблиц формулируется подобно соединению. При-
мером декомпозиции manuf_depts (таблица 1) сверху до STAFF с сохране-
нием атрибутов dno, dname, eno, function может быть выражение на HDBL:
SELECT [ x.dno, x.dname,
y.eno, y.function ]
FROM x IN manuf_depts. y IN x.staff
Естественно, HDBL может использоваться для модификации данных.
Например, для уничтожения данных о производственном участке C11 вы-
ражение на HDBL будет следующим:
DELETE mc
FROM md IN manuf_depts,
mc IN md.manuf_cells.
WHERE mc.CID = `C11`
Значение атрибута "количество машин-неприборов" (non_nc_mach)
типа MLDX 300 на участке C13 15-го цеха может быть увеличено на 1
следующим образом:
ASSIGN nnc.qu + 1
TO nnc.qu
FROM md IN manuf_depts,
mc IN md.manuf_cells,
nnc IN mc.non_nc_mach
WHERE md.dno = 15 and
mc.cid = `C13` and
nnc.type = `MLDX 300`
Добавление данных о новом цехе (без данных об участках и работа-
ющих) может быть выполнено следующим образом:
INSERT
{ [ dno: 33
dname: `new name`,
manuf_cell: { },
staff: { } ] } INTO manuf_depts.
Более сложная таблица robots демонстрирует некоторые возможности
HDBL, которые превосходят возможности чистой модели данных NF2. Соот-
ветствующие операторы CREATE показаны на рис.5 и в таблице 2.
CREATE robots |роботы
{ [ rob id: STRING (6 FIX), |идентификатор
arms: |манипуляторы
{[arm_id: STRING (12 FIX), |идент. манип.
axes: |оси
< [ Kinematics: |кинематика
[ dh_matrix: <4FIX <4FIX INTEGER>>,|
joint_angle: |угол сгиба
[ min: REAL, |минимальный
max: REAL ]], |максимальный
dynamics: |динамика
[ mass: REAL, | масса
accel: REAL ]] > ]}, | ускорение
|
endeffectors: |эффекторы
{ [ eff_id: STRING (16 FIX), |идент. эффек.
function: TEXT (1000)]} ]} |функция
END
Рис.5. Оператор CREATE для таблицы robots.
Дополнительно к значению атрибутов типа "отношение", таблица
robots представляет значения-списки (axes, dh_matrix) и значения-кор-
тежи (kinematics, joint_angle, dynamics). Значение-список означает,
что появляющиеся значения являются упорядоченными, например, для ат-
рибута axes(оси), т.е. существует первая ось, вторая ось и так далее.
Атрибут со значением типа "кортеж", такой как dynamics, имеет состав-
ное значение, а именно значение mass и значение accel. Таким образом,
значения типа "кортеж" представляют некоторую возможность структури-
зации подобно понятию RECORD во многих языках программирования. Для
нахождения всех роботов, у которых в число эффекторов входит отвертка
(Screw Driver) и которые имеют, по крайней мере, два манипулятора
(arms) с четырьмя и более осями (axes) запрос можно сформулировать
следующим образом:
SELECT ro
FROM ro IN robots
WHERE (COUNT (ro.arms) > = 2) AND
(FORALL (ar IN ro.arms):
COUNT (ar.axes) > = 4) AND
(EXISTS (ee IN ro.endefectors):
ee.functions = `Screw Driver`)
Таблица 2 Таблица robots
---------------------------------------------------------------------
{robots}
------T------------------------------------------------T-------T--------
rob_id¦ {arms} ¦{endeffectors}
+-----T------------------------------------------+-------+--------
¦arm_id ¦eff_id ¦function
¦ +-------------------------T----------------+ ¦
¦ ¦ [kinematics] ¦ [dynamics] ¦ ¦
¦ +---------------T---------+--------T-------+ ¦
¦ ¦ ¦[joint_ ¦ mass ¦accel ¦ ¦
¦ ¦ ¦ angle] ¦ ¦ ¦ ¦
¦ ¦ +----T----+ ¦ ¦ ¦
¦ ¦ ¦min ¦max ¦ ¦ ¦ ¦
------+-----+---------------+----+----+--------+-------+-------+--------
Rob1 ¦left ¦ <1, 0, 0, 1> ¦-180¦180 ¦ 50.0 ¦ 1.0 ¦ E200 ¦Gripper
¦ ¦ <0, 0, 1, 0> ¦ ¦ ¦ ¦ ¦ ¦
¦ ¦<0, -1, 0, 100>¦ ¦ ¦ ¦ ¦ E150 ¦Welder
¦ ¦ <0, 0, 0, 1> ¦ ¦ ¦ ¦ ¦ ¦
¦ +---------------+----+----+--------+-------+ E180 ¦Screw
¦ ¦ <1, 0, 0, 70> ¦-250¦60 ¦ 37.25 ¦ 2.0 ¦ ¦Driver
¦ ¦ <0, 1, 0, 0> ¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ <0, 0, 1, 20> ¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ <0, 0, 0, 1> ¦ ¦ ¦ ¦ ¦ ¦
¦ +---------------+----+----+--------+-------+ ¦
¦ ¦ <0, 0, 1, 0> ¦ -80¦250 ¦ 10.4 ¦ 6.0 ¦ ¦
¦ ¦ <1, 0, 0, 40> ¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ <0, 1, 0, -10>¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ <0, 0, 0, 1> ¦ ¦ ¦ ¦ ¦ ¦
¦ +---------------+----+----+--------+-------+ ¦
¦ ¦ <0, -1, 0, 0> ¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ <0, 1, 0, 0> ¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ <0, 0, 1, 0> ¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ <0, 0, 0, 1> ¦ ¦ ¦ ¦ ¦ ¦
+-----+---------------+----+----+--------+-------+ ¦
¦right¦ . . . ¦... ¦... ¦ ... ¦ ¦ ¦
------+-----+---------------+----+----+--------+-------+-------+--------
Rob2 ¦left ¦ . . . ¦... ¦ ...¦ ... ¦ ... ¦ ... ¦ ...
------+-----+---------------+----+----+--------+-------+-------+--------
Примечание к таблице 2.
Атрибут axes содержит список-кортежей, обозначаемый с помощью
<...>. Axes является упорядоченным отношением. Dh_matrix также явля-
ется списком, но элементы этого списка - тоже списки ( в данном слу-
чае матрицы 4x4). Kinematics и dynamics являются атрибутами, значени-
ями которых являются кортежи (обозначаются [...]) упорядоченного от-
ношения axes. Joint_angle, в свою очередь, является значением-корте-
жем для атрибута kinematics.
3. ТИПЫ ДАННЫХ И ФУНКЦИИ, ОПРЕДЕЛЯЕМЫЕ ПОЛЬЗОВАТЕЛЕМ
Современные языки запросов для реляционных баз данных обычно
обеспечивают фиксированное множество типов данных и операций. Они
обычно не позволяют расширять это множество типами данных и операция-
ми, определенными пользователем. Это является существенным недостат-
ком, особенно в новых областях применения, таких как автоматизация
учрежденческой деятельности. Здесь достаточно часто требуются специ-
альные типы данных и специальные функции, например, тип данных "мат-
рица" и функция умножения матриц. Так как матрицы и умножение матриц
обычно не поддерживаются языками запросов, пользователь должен моде-
лировать матрицу низкоуровневыми конструкциями, такими как строки
байтов, и писать громоздкую прикладную программу на обычном языке
программирования для интерпретации и манипулирования этими строками
байтов как матрицами. Поэтому необходим механизм, позволяющий пользо-
вателю определить его собственные типы данных и функции и добавить их
к СУБД таким образом, чтобы в дальнейшем их можно было использовать в
языке запросов как обычные встроенные функции для основных типов дан-
ных.
Необходимость таких средств была осознана в системе PRTV, извес-
тной как один из ранних прототипов реляционных СУБД. PRTV предостав-
ляла простейший механизм для пользовательских расширений. Пользова-
тель мог определять собственные процедуры (написанные на PL/1), кото-
рые затем можно было использовать в запросах и вызывать через СУБД во
время выполнения. Так как в PRTV таблицы всегда были в первой нор-
мальной форме (NF1), то сложные (иерархические) структуры данных не
могли быть обработаны.
В отличие от большинства других способов поддержки расширений
AIM-P преднамеренно не ограничивается парадигмой абстрактных типов
данных. Поэтому структуры, на которых пользователь определяет свои
функции, остаются видимыми. Тем самым данные любого определенного
пользователем типа могут быть запрошены и изменены с помощью обычных
выражений HDBL. Можно сочетать правильные выражения HDBL и функции,
определенные пользователем. Очевидно, что пользовательские типы дан-
ных можно рассматривать как оболочки данных, доступ к которым может
осуществляться только с помощью функций, определенных пользователем
для этого типа данных. Необходимо подчеркнуть, что специальных зна
ний о внутреннем устройстве СУБД не требуется. Рассмотрим на примерах
типы данных, определяемые пользователем и связанные с ними функции,
и, затем, инкапсулированные типы данных.
Предположим, например, что пользователь желает получить информа-
цию о всех роботах, для которых детерминант матрицы dh_matrix равен
1. Так как вычисление детерминанта матрицы есть стандартная функция
линейной алгебры, то соответствующая функция может быть найдена в
библиотеке стан дартных математических функций. Связь между этой фун-
кцией и HDBL осуществляется определением типа, к примеру, для матриц
4x4 действительных значений следующим образом:
DECLARE
TYPE dhtype <4 FIX <4 FIX REAL >> END
В этом примере dhtype - это имя типа, определенного пользовате-
лем. Он может быть впоследствии использован в других операторах
DECLARE TYPE или в операторах CREATE для создания новых объектов базы
данных. Теперь пользователь может определить заголовок пользователь-
ской функции вычисления детерминанта следующим образом:
DECLARE
FUNCTION determinant (matrix:dhtype):REAL
Для того, чтобы эта функция выполнялась, пользователь или сис-
темный программист должен запрограммировать тело функции. При прог-
раммировании тела функции, по-видимому, целесообразно использовать
универсальный язык программирования. Для AIM-P был выбран Паскаль,
так как система сама реализована на этом языке. Для того, чтобы дать
пользователям возможность применять собственные функции для своих
собственных типов данных, предварительно определенных с помощью опе-
раторов DECLARE языка HDBL, типы данных HDBL (как базисные, так и оп-
ределенные пользователем) должны быть отображены в структуры данных
языка Паскаль. Поскольку HDBL допускает для пользовательских типов
практически неограниченную сложность структуры, то их линейное предс-
тавление, как это делается в Паскале, в виде строки байтов (строки
символов) сделало бы реализацию функций довольно сложной и подвержен-
ной ошибкам. При таком подходе пришлось бы практически отказаться от
контроля типов в Паскале. Поэтому для AIM-P было решено отображать
атомарные типы данных HDBL и соответствующие конструкционные типы
(множества, списки, кортежи) в соответствующие ранее определенные ти-
пы данных языка Паскаль. Это дает не только более естественное отоб-
ражение, но и позволяет использовать мощный контроль типов данных
языка Паскаль при реализации функций пользователя. Во избежание появ-
ления ошибок отображения из представления типов HDBL в представления
типов языка Паскаль и наоборот, отображение осуществляется не пользо-
вателем, а компилятором типов, являющимся частью Диспетчера AIM-P.
В процессе выполнения перед вызовом функции AIM-P автоматически
ото бразит внутреннее представление AIM-P в представление языка Пас-
каль, а затем преобразовывает результат функции обратно во внутреннее
представление AIM-P. На вид Паскаль-представления можно в некоторой
степени влиять указанием директив компилятора типов HDBL ( STANDARD,
DENSE). Аналогичным образом автоматически генерируются заголовки фун-
кций Паскаль. Для нашего типа dhtype (из примера) Паскаль-представле-
ние с использованием директивы DENSE будет следующим:
TYPE dhtype$1 =
RECORD
ACT_ELEM: 0..4;
VAL : ARRAY [1..4] OF REAL
END;
dhtype =
RECORD
ACT_ELEM : 0..4;
VAL : ARRAY [1..4 OF dhtype$1]
END;
Заголовок Паскаль-функции для функции determinant будет следующим:
FUNCTION determinant (matrix: dhtype): REAL;
Теперь можно записать на Паскале функцию определения детерминан-
та следующим образом (в предположении, что существует бибилиотечная
функция compute_determ для вычисления детерминанта).
FUNCTION determinant (matrix: dhtype): REAL;
VAL local: ARRAY [1..4, 1..4] OF REAL;
VAL i, j: INTEGER;
BEGIN.
FOR i:=1 TO 4 DO
FOR j:=1 TO 4 DO
local [i, j] := matrix.val [i].val [j];
determinant:= compute_determ (local, 4)
END.
После трансляции функции детерминанта и ее редактирования с сис-
темой, она может быть использована в произвольных выражениях HDBL,
где в качестве типа результата выражения допускается значение типа
REAL. Например, можно найти данные о всех роботах (robots), для кото-
рых детерминант матрицы dh_matrix равен 1, при помощи следующего зап-
роса на HDBL:
SELECT r
FROM r IN robots
WHERE EXISTS (ar IN r.arms);
EXISTS (ac IN ar.axes);
determinant (ac.kinematics.dh_matrix) = 1
Функции пользователя могут быть даже настолько просты как функ-
ция извлечения квадратного корня, которая не требует введения новых
типов, так как включает только действительные значения. Поэтому эта
функция может быть определена в следующем виде:
DECLARE FUNCTION sguare_root (r:REAL):REAL
Реализация на языке Паскаль очень простая:
FUNCTION sguare_root (r:REAL):REAL;
BEGIN
sguare_root := sqrt (r)
END
Другой пример связан с введением типа данных COMPLEX для комп-
лексной арифметики. Предположим, что необходимо использовать абстрак-
тный тип данных COMPLEX и пользователь не должен знать особенности
внутренней реализации значений типа COMPLEX, а может использовать
значения COMPLEX только в функциях. Это может быть сделано объявлени-
ем типа данных как инкапсулированного типа. В этом случае система ог-
раничивает доступ к данным этого типа только доступом с помощью функ-
ций, связанных с ним. Таким образом представление может быть изменено
без необходимости изменения запросов. Тип COMPLEX может быть опреде-
лен в виде:
DECLARE TYPE COMPLEX
[re:REAL, im:REAL]
ENC END
Ключевое слово ENC обозначает, что COMPLEX является инкапсулирован-
ным типом данных. Соответствующий тип на Паскале будет такой:
TYPE COMPLEX =
RECORD
re: REAL;
im: REAL
END
Комплексная арифметика может теперь быть определена с помощью
функций
DECLARE
FUNCTION compl_make (r1, r2: REAL): COMPLEX;
DECLARE
FUNCTION compl_add (c1, c2: COMPLEX): COMPLEX;
DECLARE
FUNCTION compl_negate (c:COMPLEX):COMPLEX;
Соответствующая реализация на Паскале очень проста:
FUNCTION compl_make (r1, r2: REAL ): COMPLEX;
VAR result: COMPLEX;
BEGIN
result.re = r1;
result.im = r2;
compl_make := result
END;
FUNCTION compl_add (c1, c2: COMPLEX): COMPLEX;
VAR result: COMPLEX;
BEGIN
result.re := c1.re + c2.re;
result.im := c1.im + c2.im;
compl_add := result
END;
FUNCTION compl_negate (c:COMPLEX): COMPLEX;
VAR result: COMPLEX;
BEGIN
result.re := -c.re;
result.im := -c.im;
compl_negate := result
END
Теперь типы данных COMPLEX могут использоваться в любых операто-
рах СREATE для создания объектов БД. С помощью функций значения типа
COMPLEX могут использоваться в запросах HDBL.
Все структурные типы, которые могут создаваться с использованием
механизма типов HDBL также являются типами в HDBL. Следовательно, ти-
пы, определенные пользователем, могут появляться, к примеру, в левой
и правой частях оператора присваивания или могут быть входом для пос-
ледующего шага обработки. Механизм типов и функций стал неотъемлемой
частью модели данных и языка AIM-P.
4. ДИАЛОГОВЫЙ ИНТЕРФЕЙС И ИНТЕРФЕЙСЫ ПРИКЛАДНЫХ ПРОГРАММ
AIM-P поддерживает как диалоговый интерфейс для запросов, так и
интерфейс прикладных программ. Диалоговый интерфейс получает входные
операторы HDBL (определения данных, запросы, команды манипулирования
данными, определения типов и функций) и дает возможности получения
информации из каталогов (каталога объектов, каталога типов, каталога
функций), редактирования и поиска сохраненных запросов и просмотра
результатов запросов. Он также поддерживает определенные пользовате-
лем функции вывода для пользовательских типов данных.
Интерфейс прикладных программ (API) системы AIM-P основан на тех
же принципах что и системы R и SQL/DS. Препроцессор API обнаруживает
опреаторы языка API, встроенные в исходный текст прикладной программы
и преобразует их в соответствующие вызовы процедур резидентной части
API, а также в соответствующие объявления типов и переменных (главным
образом для передачи параметров) языка прикладной программы. Конст-
рукции языка API грубо можно разделить на две группы: декларативные
операторы и операционные операторы. Рассмотрим вкратце эти языковые
конструкции на нескольких примерах.
Декларативные операторы используются для описания объектов базы
данных (DECLARE RESULT), переменных прикладной программы, принимающих
значения объектов базы данных (DECLARE DATA) и указателей-курсоров
для навигации внутри объектов (DECLARE CURSORS). Пример оператора
DECLARE приведен на рис.6.
Курсоры объявляются с помощью оператора DECLARE CURSOR. В проти-
воположность System R или SQL/DS, которые поддерживают только решет-
чатые реляционные отношения, курсоры AIM-P упорядочены иерархически.
На рис.6 (использующем таблицу 1) c_cursor и s_cursor зависят от
d_cursor.
%INCLUDE celltup /* вставки Паскаль-представлений для CELLTUP*/
BEGIN DECLARE DATA;
type
staff_type = record
eno: integer;
funct: string (30)
end;
staff_arr_type = array [1..50] of staff_type;
var
dno :integer;
dname :string (10);
complex_cell_data :CELLTUP;
/* переменная определенного пользователем типа CELLTUP */
staff :staff_arr_type;
staff_info :AIM_RESULT_DESCR;
END DECLARE DATA;
BEGIN DECLARE CURSOR;
DECLARE RESULT manudept FOR UPDATE FROM QUERY_STATEMENT
SELECT [x.dno, x.dname, x.manuf_cells, x.staff]
FROM x IN manuf_depts;
DECLARE CURSOR d_cursor WITHIN manudept;
DECLARE CURSOR c_cursor FOR manuf_cells WITHIN d_cursor;
DECLARE CURSOR s_cursor FOR staff WITHIN d_cursor;
END DECLARE CURSOR;
Рис.6. Пример оператора DECLARE
Это значит, что c_cursor может оперировать только на тех произ-
водственных участках (manuf_cells), которые относятся к цехам
(manuf_depts), на которые в данный момент указывает d_cursor. Кроме
определения области действия зависимых курсоров, курсор дает доступ к
элементам данных своего уровня. Таким образом, d_cursor обеспечивает
доступ к атрибутам dno (атомарный), dname (атомарный), manuf_cells
(значение-множество) и staff ( значение-множество); c_cursor обеспе-
чивает доступ к атрибутам cid (атомарный), non_nc_mach (значение-мно-
жество) и nc_mach (значение-множество).
Операционные операторы используются для выбора управления API с
помощью прикладной программы. По существу, имеются операторы выполне-
ния запроса, обновления/копирования, операторы, относящиеся к курсо-
рам, сеансам и транзакциям. Для начала сеанса ( установления связи с
базой данных) используется оператор BEGIN SESSION, который обеспечи-
вает идентификацию пользователя и ввод пароля. Затем можно начать
транзакцию с помощью оператора BEGIN TRANSACTION и завершить ее с по-
мощью COMMIT TRANSACTION или ABORT TRANS- ACTION. Наконец, сеанс мо-
жет быть завершен вводом оператора END TRANSACTION.
Оператор EVALUATE manudept вызывает как выполнение запроса,
изображенного на рис.6, так и получение результата. По получении ре-
зультата могут быть открыты курсоры для передачи данных в переменные
прикладной программы (или наоборот). После ввода оператора OPEN
CURSOR d_cursor, этот курсор и все зависящие от него открываются и
могут быть установлены оператором MOVE.
Для передачи данных в переменные прикладной программы использу-
ется оператор GET. Пример использования этих функций представлен на
рис.7. Операторы GET на этом рисунке заслуживают более подробных ком-
ментариев; они показывают, что передача данных может происходить нес-
колькими путями:
- опция ATTR_WISE указывает, что атомарные значения атрибута,
доступ ные с помощью соответствующих курсоров, будут переданы в инди-
видуальные переменные прикладной программы (на рис.7 атрибут dno и
dname передаются в переменные программы dno и dname);
- опция TUPLE_WISE указывает системе, что все атомарные значения
атрибута на текущей позиции курсора будут взяты как одно целое (кор-
теж) и присвоены соответствующей (совместимой по типу) переменной ти-
па RECORD.
Cпецификация BY (n >1) осуществляет передачу более чем одного
экземпляра (кортежа) одновременно. Необязательная переменная типа
AIM_RESULT_DESCR ( см. staff_info на рис.6 и рис.7) может использо-
ваться для сообщения пользователю количества экземпляров данных (кор-
тежей), которые были в действительности переданы в прикладную прог-
рамму.
WHENEVER END LEAVE;
repeat
MOVE d_cursor; /* переместить на (следующий) цех */
GET d_cursor ATTR_WISE dno, dname INTO dno, dname;
/* здесь обработка DNO и DNAME в прикладной программе */
repeat
MOVE c_cursor; /* переместить на (следующий) участок */
GET c_cursor OBJECT_WISE INTO complex_cell_data;
/* вся информация об одном участке manuf_cells */
/* передается в одну переменную программы */
/* complex_cell_data */
/* обработка данных о приборах и не_приборах */
until false;
repeat
MOVE s_cursor /* переместить на следующий элемент staff */
GET s_cursor BY 50 TUPLE_WISE INTO staff: staff_info;
/* фактическое число найденных кортежей staff возвращается */
/* в staff_info. n_units_ret */
/* обработка массива STAFF в прикладной программе */
until false;
/* дополнительная обработка информации о цехе */
until false;
Рис.7. Операторы MOVE и GET с объектно-ориентированной
передачей данных
- опция OBJECT_WISE специфицирует, в отличие от ключевых слов
TUPLE_ WISE и ATTR_WISE, что все атомарные и неатомарные данные в те-
кущей позиции курсора будут переданы в прикладную программу: сложный
объект полностью передается за один раз (одним вызовом резидентной
части API). Конечно, для приема всех этих данных (особенно неатомар-
ные значения типа множества или списка) должна быть предусмотрена со-
ответствующая программная переменная . Соответствующие определения
типа для этой программной переменной (например, CELLTUP на рис.6) мо-
гут быть получены компилятором типов AIM-P на основе типов данных,
определенных пользователем, как это описано в предыдущем разделе.
- оператор WHENEVER на рис.7 используется для спецификации иск-
лючения из правил. В данном случае определено условие END (оператор
Паскаля/VS LEAVE используется для выхода из текущего цикла
REPEAT...UNTIL).
Если результат объявлен как FOR UPDATE (для обновления,
см.рис.6) , его можно читать и корректировать. Для этого курсор дол-
жен быть установлен так же, как для чтения (GET, FETCH). Для коррек-
тировки данных могут быть введены операторы UPDATE, INSERT или DELETE
(которые синтаксически похожи на оператор GET). После корректировки
используется оператор PROPAGATE, который передает измененные или но-
вые данные из станции серверу базы данных (или обратно). Это, однако,
не означает, что изменения уже зафиксированы. С позиции сервера изме-
нения сделаны только в одном рабочем поле. Пользователь все равно
должен еще ввести команду COMMIT или ABORT.
5. АРХИТЕКТУРА СИСТЕМЫ AIM-P
Архитектура системы AIM-P строится на принципе "клиент-сервер".
Это значит, что сервер базы данных функционирует на хост-машине
и обслуживает совокупность рабочих станций. Выбор такой архитектуры
продиктован тем, что станции автономно решают сложные и занимающие
много времени задачи, такие, например, как задачи проектирования.
Предполагается, что эти прикладные про граммы написанные на стандарт-
ных языках программирования, используют сервер для доступа к цент-
ральной базе данных. С помощью высокоуровневого языка запросов и ма-
нипулирования данными (такого как HDBL) у сервера запрашивается пред-
ставление объектов, которые могут быть сложными. После обработки на
станции измененные данные могут быть переданы обратно в центральную
базу данных. Поскольку данные потенциально могут быть сложной струк-
туры и большого объема, в передаче изменений в центральное хранилище
данных участвуют как сервер, так и рабочие станции.
Подсистема, работающая на станции состоит из Диспетчера резуль-
татов, являющегося компонентом Диспетчера сложных объектов (рис.8)
сервера AIM-P; Диалогового интерфейса, который обеспечивает интерак-
тивный интерфейс для запросов к базе данных и отображения результа-
тов, Препроцессора API и Резидентной системы API. Диалоговый интер-
фейс, Препроцессор API и Резидентная система API обычно доступны
только на рабочей станции. Подробнее рассмотрим архитектуру сервера.
Для того, чтобы систему AIM-P можно было модифицировать в связи
с изменяющимися требованиями или для проверки новых идей, система бы-
ла построена по модуль ному принципу. Компоненты Диспетчер буферов,
Диспетчер сегментов, диспетчер каталогов, Супервизор и Коммуникацион-
ная компонента выполняют те же функции, что и в любой СУБД. Они вы-
полняют управление вводом/выводом из внешней памяти в буфер системы и
наоборот, поддержкой создания сегментов (файлов), удалением и "сбор-
кой" мусора, а также управляют связью между виртуальными машинами
СУБД и другими виртуальными или реальными машинами.
Процессор запросов используется для анализа запросов HDBL, опти-
мизации запросов (алгебраическая оптимизация запросов и выбор путей
доступа), и, собственно выполнения запроса (включая запросы на мани-
пулирование данными).
------------------------------------------------¬
¦ ¦
¦ ------¬ --------------¬ ---------------¬ ¦
¦ ¦ ПРЕ ¦ ¦ Прикладные ¦ ¦ Диалоговый ¦ ¦
¦ ¦ +----+ программы ¦ ¦ интерфейс ¦ ¦
¦ ¦ ПРО ¦ L------T------- L------T-------- ¦
¦ ¦ ¦ ¦ ¦ ¦
¦ ¦ ЦЕС ¦ ¦ ¦ ¦
¦ ¦ ¦ -------+------¬ -------+-------¬ ¦
¦ ¦ СОР ¦ ¦ Оперативная ¦ ¦ Диспетчер ¦ ¦
¦ ¦ ¦ ¦система API ¦ ¦ результата ¦ ¦
¦ ¦ ¦ L------T------- L--------------- ¦
¦ L--T--- ¦ ¦
¦ ¦ ¦ ¦
+----+--------------+---------------------------+
¦ ¦
¦ Т е л е к о м м у н и к а ц и я ¦
L----------------------T------------------------- другие станции
¦ Станция ¦
¦ ¦
¦ ¦
L-¬ L-¬
¦ ¦
¦ Сервер центральной базы данных ¦
¦ ¦
-------------------------+----------------------------------+-------¬
¦ ¦
¦ Т е л е к о м м у н и к а ц и я ¦
L--------------------------------------------------------------------
--------T-----------¬
--------+-------+Супервизор ¦ ---------------¬
¦ ¦ ----+------------ ¦-------------¬¦
¦ ¦ ¦ ¦¦ Диспетче𠦦
¦ ¦ ¦ ------------¬ ¦¦индексирова-¦¦
¦ ¦ ¦ ¦ Процессор ¦ ¦¦ ния ¦¦
¦ --+---+---+ запросов +-T------T-------+¦ текстов ¦¦
¦ ¦ ¦ ¦ L-----T------ ¦ ¦ ¦L-------------¦
¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
-----+----¬¦ ¦ ¦ ------+-----¬ ¦ -----+----¬ ¦-------------¬¦
¦Диспетчер+- ¦ L---+ Диспетчер ¦ ¦ ¦Диспетчер¦ ¦¦ Текстовый ¦¦
¦каталогов+--+-------+ сложных +-+-+индексов ¦ ¦¦ процессо𠦦
L---------+-¬¦ ¦ объектов ¦ ¦ L----T----- ¦L-------------¦
¦¦ L-----T------ ¦ ¦ L-------T-------
¦¦ ¦ ¦ ¦ ¦
¦¦ ------+-----¬ ¦ ¦ ¦
¦L-------+ Диспетчер ¦ ¦ ¦ ¦
L--------+ подкорте- +-+------+----------------
¦ жей +-+
L-T---T------ ¦
---------------- ¦ ¦
--------+---¬ ------+-----¬ ¦
¦ Диспетчер ¦ ¦ Диспетчер ¦ ¦
¦ буферов ¦ ¦ сегментов +--
L------------ L------------
Рис.8. Архитектура. Сервер центральной базы данных
связан с множеством станций.
Этот компонент состоит из трех основных частей: Анализатора,
Подсистемы иерархической оптимизации и Подсистемы исполнения запро-
сов.
Диспетчер индексов состоит из двух частей: одна поддерживает
обычные индексы СУБД (такие, как В-деревья), другая используется для
поддержки текстовых индексов.
Диспетчер подкортежей используется для поиска подкортежей или
записей (базисных логических единиц доступа в AIM-P) в страницах и
отображения подкортежей в страницы. Подкортежи могут быть очень ма-
ленькими, но могут занимать и много страниц, особенно в случаях длин-
ных полей. Кроме того, этот Диспетчер разрабатывался для управления
транзакциями. Он поддерживает команды Begin-of-transaction (начало
транзакции), Commit (выполнить) и Abort (отменить), которые служат
для начала новой транзакции, фиксации изменений и их отмены соответс-
твенно. По этой причине Диспетчер подкортежей поддерживает для каждой
транзакции индивидуальную рабочую область, где выполняются все обнов-
ления. Во время выполнения содержимое этой рабочей области записыва-
ется в файл регистрации транзакций до того, как изменения станут дос-
тупными другим транзакциям.
Диспетчер сложных объектов является единственным компонентом,
который может определять структуру и реализацию. В то время, как Дис-
петчер подкортежей поддерживает все подкортежи одним и тем же спосо-
бом, Диспетчер сложных объектов делает различие между подкортежами
структур и подкортежами данных. Подкортежи структур, называемые ми-
ни-оглавлениями в терминологии AIM-P, содержат информацию о структуре
(то есть, отношения подчинения), в то время как подкортежи данных со-
держат только данные (за исключением некоторой управляющей информа-
ции, такой как дли на подкортежа и информация о нулевых значениях).
Диспетчер сложных объектов взаимодействует очень тесно с Диспет-
чером подкортежей и Процессором запросов, избавляя последний от необ-
ходимости следить за деталями размещения и поиска данных на физичес-
ком уровне. Совместно с Диспетчерами подкортежей и сегментов, Диспет-
чер сложных объектов помещает данные во внешнюю область памяти таким
образом, чтобы данные, которые относятся к одному объекту (сложный
объект, NF2-кортеж) хранились по возможности на смежных страницах.
Иначе говоря, он управляет физической кластеризацией. Более того,
Диспетчер сложных объектов скрывает различие в представлении сложных
объектов для Процессора запросов. В текущей реализации AIM-P поддер-
живаются три различные представления, это - базы данных, буферы объ-
ектов и внешнее представление.
Представление в виде базы данных используется для отображения
объектов БД во внешней памяти и в системных буферах СУБД. Эта струк-
тура разработана для эффективной поддержки доступа к любым объектам,
особенно при обработке операций проекции и селекции.
Представление в виде буфера объектов используется для представ-
ления результатов запроса, а также временных, промежуточных результа-
тов. Это представление более компактное, чем представление в виде ба-
зы данных и используется также для взаимосвязи "рабочая станция-сер-
вер". Третье представление - это внешнее представление типов HDBL в
структурах языка Паскаль. Это представление используется для поддерж-
ки типов данных и функций, определенных пользователем, а также для
передачи результатов запроса прикладной программе, если при передаче
указана опция OBJECT_WISE.
З А К Л Ю Ч Е Н И Е
Проект AIM - это исследовательская и проектная разработка науч-
ного центра г.Хайдельберг (Западная Германия), выполняемая в целях
уточнения требований к технологии баз данных в интегрированных прик-
ладных проблем ных областях. Исследовательский проект AIM-P основан
на концепции вложенных отношений. Анализ экспериментов по использова-
нию расширенной реляционной NF2 модели данных в информационных систе-
мах по учету недвижимости, информационных системах по химии, при гео-
метрическом моделировании и в САПР является многообещающим и дает все
основания утверждать, что эта модель данных представляет собой пра-
вильное направление в развитии СУБД.
Первая версия AIM-P начала работать в конце 1986 года. Нынешняя
версия (2.0) имеет следующие характеристики:
- решетчатые и вложенные отношения, как упорядоченные, так и не-
упорядочен ные. Допустимые типы атрибутов: атомарные, решетчатые и
вложенные отношения и списки или множества атомарных значений. Мно-
жество множеств и списки списков не поддерживаются;
- реализована большая часть средств HDBL, но пока выполняется
только частичная оптимизация запросов;
- доступ к данным журнала;
- доступ к возможностям HDBL в диалоговом режиме и через прог-
раммный интерфейс;
- поддержка типов данных и функций, определенных пользователем;
- поддержка текстовых данных (возможности поиска по тексту);
- поддержка связи рабочая станция-сервер;
- поддержка транзакций (отмена или подтверждение) в режиме рабо-
ты одного пользователя.
В этом кратком описании проекта могли быть освещены только неко-
торые аспекты работы. В статье не говорилось, в частности, о поддерж-
ке функций поиска текста и работе сервера одновременно с несколькими
рабочими станциями.
Начаты теоретические исследования по совершенствованию обработки
запросов нв основе интеграции индексов таблиц NF2 и по разработке ал-
гори мов преобразования и оптимизации запросов. Кроме того, начаты
исследования в области сортировки и исключения дублирования (что соз-
дает основу для поддержки рекурсивных запросов), а также в области
процедур управления параллельными объектно-ориентированными процесса-
ми.
Источник: Dadam P., Linnemann V. Advanced Information Management(AIM):
Advanced database technology for integrated applications.
IBM SYSTEM JOURNAL vol.28, No 4, 1989, p.661-681.
Перевод выполнил: Левский Юрий Владимирович.
|
