Большой архив статей, книг, документации по программированию, вебдизайну, компьютерной графике, сетям, операционным системам и многому другому
 
<Добавить в Избранное>    <Сделать стартовой>    <Реклама на сайте>    <Контакты>
  Главная Документация Программы Обои   Экспорт RSS E-Books
 
 

   Базы данных -> Разное -> Усовершенстованноее управление информацией



      УСОВЕРШЕНСТВОВАННОЕ УПРАВЛЕНИЕ ИНФОРМАЦИЕЙ: НОВЫЕ ТЕХНОЛОГИИ
           БАЗ ДАННЫХ ДЛЯ ИНТЕГРИРОВАННЫХ ПРИКЛАДНЫХ СИСТЕМ




        Введение ...................................................
     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.
Перевод выполнил: Левский Юрий Владимирович.


	   


 

 
Интересное в сети
 
10 новых программ
CodeLobster PHP Edition 3.7.2
WinToFlash 0.7.0008
Free Video to Flash Converter 4.7.24
Total Commander v7.55
aTunes 2.0.1
Process Explorer v12.04
Backup42 v3.0
Predator 2.0.1
FastStone Image Viewer 4.1
Process Lasso 3.70.4
FastStone Image Viewer 4.0
Xion Audio Player 1.0.125
Notepad GNU v.2.2.8.7.7
K-Lite Codec Pack 5.3.0 Full


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

Copyright © CompDoc.Ru
При цитировании и перепечатке ссылка на www.compdoc.ru обязательна. Карта сайта.