|
УСОВЕРШЕНСТВОВАННОЕ УПРАВЛЕНИЕ ИНФОРМАЦИЕЙ: НОВЫЕ ТЕХНОЛОГИИ БАЗ ДАННЫХ ДЛЯ ИНТЕГРИРОВАННЫХ ПРИКЛАДНЫХ СИСТЕМ
Введение ...................................................
1. Проект AIM..................................................
2. Хейдельбергский язык базы данных (HDBL).....................
3. Типы данных и функции, определяемые пользователем...........
4. Диалоговый интерфейс и интерфейсы прикладных программ.......
5. Архитектура системы AIM-P ..................................
Заключение .................................................
Проект усовершенствованных средств управления информацией
(Advanced Information Management - AIM) в настоящее время является
одним из главных направлений деятельности научного центра фирмы IBM в
Хайдельберге. Основная цель проекта - изучение требований к базам
данных (БД) и соответствующих проектных решений для новых интегриро-
ванных областей применения, таких как компьютеризованные производства
и учреждения. Для этих областей необходима новая технология БД, кото-
рая позволила бы надежно и эффективно управлять большими объемами
разнородных данных. Такая технология должна поддерживать не только
простые числовые данные, простые таблицы, используемые в управлении,
но и объекты сложной структуры, в том числе тексты, изображения,
речь. В этой статье описываются основные положения, цели и достижения
проекта AIM. Она также содержит обзор постановки, реализации и кон-
цепций AIM-P - экспериментальной СУБД, разработанной в рамках проекта
AIM.
Для новых областей применения необходима усовершенствованная
технология БД, позволяющая управлять большими объемами данных различ-
ных типов. При представлении этих типов данных как можно более "ес-
тественнее" с прикладной точки зрения можно избежать сложных отобра-
жений представления данных, используемых в прикладных программах, в
представления данных в БД. Это положение является очень важным, если
технология БД используется с целью повышения эффективности, а не
только в качестве средства интеграции в прикладном программировании.
Естественным может быть представление данных, зависящее от предметной
области. Системы автоматизации проектирования (CAD) могут использо-
вать объектно-ориентированные данные, например, о компьютерных платах
X и Y и связанных с ними объектах (возможно, обладающих своей струк-
турой), в то время, как системы компьютеризованного производства
(САМ) используют данные, ориентированные на данные, например, коли-
чество и тип микросхем во всех платах компьютера, независимо от того,
в какие объекты входят эти микросхемы. Это значит, что для того, что-
бы быть адекватной интегрированной обработке информации, технология
баз данных должна поддерживать различные представления одного и того
же типа данных или объекта, с одной стороны, и единообразное предс-
тавление большого количества различных типов данных, с другой сторо-
ны.
Современные СУБД создавались применительно к задачам администри-
рования в области бизнеса. Они не пригодны для реализации вышеупомя-
нутых систем в отношении моделей данных и эффективности. Как следст-
вие, в каждой из основных областей применения в настоящее время ис-
пользуется огромное количество специализированных файловых систем и
СУБД (рис.1).
ЪДДДДДДДДДДї ЪДДДДДДДДДДї ЪДДДДДДДДДї ЪДДДДДДДДДї ЪДДДДДДДДДї
іТекстовые і іТабличные і іДанные в і іИнженерные іГеографи-і
і данные і і данные і іучреждениі іи научныеі іческие и і
АДДДДВДДДДДЩ АДДДДВДДДДДЩ і ях і і данные і іграфичес-і
і і АДДДДВДДДДЩ АДДДДВДДДДЩ ікие данные
компьютер і і і АДДДДВДДДДЩ
ЪДДДДДДДЕДДДДДДДДДДДДДЕДДДДДДДДДДДДДЕДДДДДДДДДДДДЕДДДДДДДДДДДДЕДДДДДї
і і і і і і і
і ЪДДДДБДДДДї ЪДДДДДБДДДДДї ЪДДДДБДДДДї ЪДДДДБДДДДї ЪДДДДБДДДДїі
і іПрикладные іПрикладные і іПрикладные іПрикладные іПрикладныеі
і іпрограммыі іпрограммы і іпрограммыі іпрограммыі іпрограммыіі
і АДДДДВДДДДЩ АДДДДДВДДДДДЩ АДДДДВДДДДЩ АДДДДВДДДДЩ АДДДДВДДДДЩі
і і і і і і і
і ЪДДДДБДДДДї ЪДДДДДБДДДДДї ЪДДДДБДДДДї ЪДДДДБДДДДї ЪДДДДБДДДДїі
і і і і і і Оффиснаяі іСпециаль-і іСпециаль-іі
і і ИПС і і СУБД і і система і іная систеі іная систеіі
і АДДДДДДДДДЩ АДДДДДДДДДДДЩ АДДДДДДДДДЩ і ма і і ма іі
і АДДДДДДДДДЩ АДДДДДДДДДЩі
АДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДЩ
Рис. 1.
Эти системы отличаются функционально, представлением данных (мо-
делями данных, интерфейсами), стратегией обработки (оперативным изме-
нением данных, пакетным обновлением), управлением транзакциями, сред-
ствами восстановления и защиты, делая интеграцию прикладных систем
довольно сложной задачей. Разрешить эту ситуацию могли бы мощные
СУБД, поддерживающие данные различных предметных областей универсаль-
ным способом, могут (рис.2). Скорее всего, один тип системы не сможет
поддерживать все области применения. Однако можно стремиться покрыть
80-90 % основных типов приложений.
В настоящее время расширенная технология БД достаточно подробно
изучена. Ниже мы рассмотрим некоторые работы, оказавшие влияние на
этот проект.
ЪДДДДДДДДДДї ЪДДДДДДДДДДї ЪДДДДДДДДДї ЪДДДДДДДДДї ЪДДДДДДДДДї
іТекстовые і іТабличные і іДанные в і іИнженерные іГеографи-і
і данные і і данные і іучреждениі іи научныеі іческие и і
АДДДДВДДДДДЩ АДДДДВДДДДДЩ і ях і і данные і іграфичес-і
і і АДДДДВДДДДЩ АДДДДВДДДДЩ ікие данные
і і і і АДДДДВДДДДЩ
і і і і і
і і і і і
ЪДДДДБДДДДї ЪДДДДДБДДДДДї ЪДДДДБДДДДї ЪДДДДБДДДДї ЪДДДДБДДДДї
іПрикладные іПрикладные і іПрикладные іПрикладные іПрикладные
іпрограммыі іпрограммы і іпрограммыі іпрограммыі іпрограммыі
АДДДДВДДДДЩ АДДДДДВДДДДДЩ АДДДДВДДДДЩ АДДДДВДДДДЩ АДДДДВДДДДЩ
і і і і і
і АДДДДДДДДДДї і ЪДДДДДДДДДЩ і
і і і і і
і ЪДБДДБДДБДї і
АДДДДДДДДДДДДДДДДДДДДДДґ СУБД ГДДДДДДДДДДДДДДДДДДДДЩ
і і
АДДДДДДДДДЩ
Рис. 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 і
Списки Множества Отношение Отношение
і ^ і <ДДДДДДДДДДДЩ і ^ і ЪД(множество)ї (множество)
і і і ЪДДДДДї і і і і і і
і і і і і і і і і і і
і і АДДД>Щ А<ДДДЩ і і і і і
і АДДДДДДКортежиДДДДДДЩ і і і Кортежи
і і АДДДКортежиДДЩ і
і і і і
і і і і
і і і Атомарные
і і Атомарные значения
і і значения
АДДДДДДДДАтомарныеДДДДДДДДЩ Первая нор-
значения мальная фор
модель данных 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} і
ГДДДДДДВДДДДДДДВДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДВДДДДДДДДДДДДДДДДДДДДДґ
і і і { manuf-cells} і { staff } і
і і ГДДДДВДДДДДДДДДДДДВДДДДДДДДДДДДЕДДДДДДДДВДДДДДДДДДДДДґ
і dno і dname і і{non-nc-mach} {nc-mach} і і і
і і іcid ГДДДДВДДДДДДДЕДДДДВДДДДДДДґ 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 і
АДДДДДДБДДДДДДДБДДДДБДДДДБДДДДДДДБДДДДБДДДДДДДБДДДДДДДДБДДДДДДДДДДДДЩ
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}
ДДДДДДВДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДВДДДДДДДВДДДДДДДД
rob_idі {arms} і{endeffectors}
ГДДДДДВДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДДЕДДДДДДДЕДДДДДДДД
іarm_id
|