Лента

Глава 19
Репозитории и управление метаданными^*)

Перспективы
Практические выводы
Что дает эта технология
Литература
Ссылки

Замечание для руководителя отдела ИС

Управление корпоративными метаданными при помощи репозиториев - интенсивно развивающаяся область, которая тем не менее пока еще значительно отстает от управления базами данных по общему технологическому уровню и стандартизации. По мере того как корпоративная интеграция приобретает все большее значение, растет и осознание ключевой роли репозиториев в создании надежных высокоразвитых систем. В этой главе мы рассмотрим различные модели распределенных репозиториев, которые имеют важное значение для выработки долгосрочной и целостной стратегии информационного управления.

19.1. Введение

Репозиторий - это всего лишь обычная база данных, где хранятся не пользовательские данные, а метаданные, не так ли?

На самом простом уровне можно принять и такое определение. Тем не менее, как мы увидим далее, репозитории устроены несколько сложнее, помимо того, они выделяются своей ключевой ролью в общей структуре корпоративного управления информацией. Далее будет показано также, что репозиторий - это на самом деле только часть механизма управления метаданными; критичным, с точки зрения эффективности реализации любого репозитория, является соответствующий пользовательский и прикладной инструментарий.

В этой главе мы рассмотрим основы технологии репозиториев, тенденции ее развития и перспективные направления в этой сфере.

19.2. Принципы организации репозиториев

Начнем с уточнения нашего определения репозитория "как просто базы данных". Филипп Бернштейн определяет репозиторий как "разделяемую базу данных с информацией об артефактах проектирования, требующую некоторых дополнительных функций управления помимо предоставляемых обычными системами баз данных"¹.

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

К функциям управления, необходимым для репозиториев, относятся следующие.

Парадигма включения/выключения (check in/check out) и некоторые формальные процедуры для объектов, находящихся под управлением репозитория (независимо от того, где и в какой форме эти объекты хранятся).

Поддержка множественных версий объектов, а также процедуры управления конфигурациями для таких объектов.

Способность оповещать инструментальные и рабочие системы о событиях, представляющих для них интерес, например об изменениях форматов или семантики объектов, контролируемых репозиторием.

Управление контекстом, разные способы обзора объектов репозитория (нечто вроде представлений в базах данных).

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

В дополнение к определению Бернштейна, отметим две характеристики, существенные с точки зрения дальнейшего развития репозиториев - независимость от поставщика и расширяемость².

До настоящего времени реализации репозиториев были, в основном, специфическими для конкретного поставщика или даже отдельного продукта, соответственно, роль их была довольно ограниченной. Специфический для продукта репозиторий выполнял функции менеджера хранения метаданных, используемых данным продуктом - инструментальной системой, приложением, СУБД и т. п.

При переходе к общему репозиторию для всех продуктов поставщика его роль расширяется; он не только выполняет функции менеджера хранения метаданных, но и отвечает за взаимосвязи между метаданными разных инструментов. Однако и на этом уровне мы все еще остаемся в рамках закрытых форматов представления объектов, коммуникационных протоколов и механизмов уведомлений, схем контроля версий и других функций репозитория (рисунок 19-1).

Репозитории, обладающие свойством независимости от поставщика, способны воспринимать встраиваемые интерфейсы множества разнообразных инструментальных и прикладных систем, а также других пользователей репозиториев (рисунок 19-2). Ключ к решению проблемы независимости от поставщика для репозиториев - тот же, что и для информационного управления в целом, фактически, для всего рынка информационных систем - стандарты. Стандарты репозиториев мы рассмотрим в разделе 19.3.

Еще одна их упомянутых выше характеристик - расширяемость - означает, что репозитории должны допускать расширение исходной схемы, поставляемой вместе с продуктом. Под расширяемостью понимается возможность добавлять новые типы объектов, изменять объекты и их свойства, а также другие способы настройки репозиториев на потребности организации (рисунок 19-3).

Так что же, собственно, делает репозиторий? Какова его роль, помимо того, что он является "менеджером системных метаданных"? Давайте рассмотрим один из сценариев функционирования репозитория³.

Представим себе, что в вашей организации интенсивно используются инструменты компьютерного проектирования программных систем (CASE), причем на всех стадиях жизненного цикла - сбор исходных требований, моделирование данных и процессов, тестирование и прочие функции. На протяжение цикла разработки вам необходимо поддерживать информацию от отношениях между объектами, полученными при помощи различных инструментов CASE; например, заданное требование A связано с объектом моделирования данных B, а также с определением C на языке определения данных (DDL) в вашей базе данных; тест X относится к программному модулю Y, который, в свою очередь, относится к требованиям A и Z (соответствующая схема изображена на рисунке 19-4).

Обратимся к тенденциям на рынке CASE, в особенности к приобретающим все большее влияние средам CASE типа SoftBench (Hewlett-Packard), которые способны принимать интерфейсы множества инструментальных систем в соответствии со стандартами интеграции данных и управления4. Можно сделать вывод о том, что ни один поставщик не способен будет предоставить инструменты, отвечающие всем мыслимым стадиям жизненного цикла системы. Среда разработки типичной организации будет состоять из множества разнообразных инструментальных средств от разных поставщиков, а также из всевозможных систем времени выполнения (компиляторов, СУБД, систем класса 4GL). Для того чтобы обеспечить взаимосвязи между объектами, как показано на рисунке 19-4, репозиторий должен уметь взаимодействовать со всем спектром инструментальных средств и систем времени выполнения.

Однако необходимо не только поддерживать связи между разнородными объектами, но и обеспечить взаимодействие самих инструментальных средств. Например, изменение объекта моделирования данных B должно автоматически приводить к изменению соответствующего объекта C, представленного на языке DDL (очевидно, некоторой СУБД), а также определенных программ, планов тестирования и других системных объектов, прямо или косвенно связанных c объектом B. На рисунке 19-5 показано два способа передачи подобных уведомлений. Один способ заключается в том, что вне репозитория должен существовать сервер уведомлений, к которому от различных инструментальных систем поступают сообщения об изменениях, подобных упомянутым выше, и который рассылает уведомления всем прочим инструментам и системам, которые зарегистрировались на получение информации об изменениях данного типа. Серверы уведомлений обычно находятся вне сферы сервисов репозитория.

Механизм уведомлений, встроенный в репозиторий, позволяет контролировать рассылку уведомлений при помощи методов и операций самих объектов. В репозиториях, построенных на основе активных баз данных, могут использоваться присущие таким СУБД средства - триггеры и хранимые процедуры (в реляционных) или методы (в объектно-ориентированных). Короче говоря, репозиторий сам располагает информацией о том, каким инструментам следует посылать уведомления о том или ином событии.

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

19.3. Стандарты репозиториев

Стандарты и репозитории - две вещи, трудно совместимые. В стадии разработки находятся, по крайней мере, пять стандартов для репозиториев⁵, но ни один из них нельзя считать столь же "зрелым" (по состоянию на 1993 г.), как SQL для реляционных баз данных.

Стандарты репозиториев варьируются от документов, охватывающих весьма узкий круг функций, допустим CDIF: CASE Data Interchange Format CASE (стандарт формата обмена данных) до таких, которые описывают обобщенный репозиторий, ориентированный на практически произвольные информационные системы, например IRDS: Information Resource Dictionary System (словарь информационных ресурсов)⁶. Назовем также стандарты PCTE: Portable Common Tool Environment, ATIS: A Tool Integration Standard, а также пересмотренную версию стандарта IBM AD/Cycle CASE platform, неофициально известную под названием AD/Platform⁷.

Рассмотрим в первую очередь IRDS, поскольку он носит характер общего стандарта, в отличие от других трех, ориентированных, в основном, на системы CASE (что касается ATIS, то сейчас рассматривается вопрос об его интеграции в IRDS).

IRDS впервые был опубликован в 1988 г. Американским национальным институтом стандартов (ANSI); он был разработан комитетом ANSI X3H3. Поскольку он никогда не опирался на предположения о характере аппаратного или программного обеспечения, то считается независимым от поставщика⁸.

В момент написания этой книги на рассмотрении в X3H3 находилось множество предложений по расширению IRDS сверх его исходных семи модулей, которые перечислены ниже⁹.

Стандарт ядра; описывает минимальные требования, которым должна удовлетворять система, претендующая на соответствие IRDS.

Базовая функциональная схема IRDS; реализация расширений к метамодели ядра.

Безопасность IRDS.

Расширяемые средства поддержки жизненного цикла; управление жизненным циклом содержания IRDS.

Процедурные средства; определение и выполнение командных процедур IRDS.

Прикладной программный интерфейс (API).

Списки сущностей; именование групп сущностей и манипулирование этими группами.

Среди предложений, которые, скорее всего, найдут отражение в следующей версии IRDS (и повлияют на стандарты репозиториев в целом), отметим следующие¹⁰.

• Для API: интерфейс к сервисам на основе стандарта ATIS.
• Форматы файлов экспорта/импорта (возможно, с учетом CDIF).
• Объектно-ориентированная метамодель.
• Средства распределения.

Остановимся подробнее на последнем пункте - распределенных средствах IRDS - и рассмотрим свойство распределенности как общую характеристику репозиториев будущего.

19.4. Распределенные репозитории

Репозитории, как и базы данных, могут быть распределенными в разной мере. В простейшем случае это будет среда, приблизительно эквивалентная по своей архитектуре среде базы данных с интерфейсом клиент-сервер. Поскольку репозитории имеют (и впредь будут иметь) в своей основе какую-либо СУБД, то очевидно, что для них достаточно широкое применение найдет интерфейс клиент-сервер, опирающийся на ODBC, IDAPI или другой подобный стандарт (см. гл. 3 и рисунок 19-6).

На другом конце спектра будут находиться репозитории, концептуально подобные распределенным базам данных. Распределенные репозитории (рисунок 19-7) подчинены тем же правилам, что и распределенные базы данных; это значит, что изменения, затрагивающие более одного узла, должны проводиться с применением двухфазовой фиксации (2PC) или другого аналогичного алгоритма распределенного управления одновременным доступом, для того чтобы обеспечить свойство атомарности транзакций (свойство атомарности означает соблюдение принципа "все или ничего", разд. 20-2). Механизмы фрагментации и тиражирования (разд. 2.4.2) применимы к репозиториям в той же мере, как и к базам данных с обычной информацией.

Как и в распределенных базах данных, в распределенных репозиториях будущего, по-видимому, будут применяться разнородные продукты, которые придется как-то интегрировать. Хотя стандарты типа IRDS, несомненно, будут способствовать решению проблемы неоднородности, достаточно даже самого поверхностного знакомства с существующими продуктами реляционных СУБД, основанных на "стандартном SQL", чтобы оценить, насколько серьезные проблемы для интеграции создадут имеющиеся в них всевозможные расширения и отклонения от стандарта SQL. Точно так же попытки интегрировать, скажем, репозиторий, совместимый с IRDS, и какой-либо уже существующий нестандартный репозиторий (унаследованную систему метаданных) приведут к тем же проблемам, которые уже обсуждались применительно к распределенным базам данных: семантические несоответствия, несовместимые способы представления данных и т. п. Сложности возникают и в ситуации, когда при необходимости произвести изменение, затрагивающее несколько серверов репозиториев, один или более из них оказываются недоступны. Бернштейн отмечает, что все подходы к решению этой проблемы весьма дорогостоящи, и ни один не нашел массового применения, поскольку каждый из них представляет некую модель управления одновременным доступом, находящуюся за рамками возможностей достаточно отработанных на сегодня технологий¹².

Репозитории вносят свои вариации и в механизмы тиражирования. В разд 19.2 мы упоминали, что репозитории должны поддерживать модель включения/выключения объектов. На рисунке 19-8 показана довольно привлекательная схема, где допустимо выключение одного или более объектов одного или нескольких репозиториев некоторым пользователем (или группой пользователей, которые могут воспользоваться для работы с выключенными объектами методами группового кооперативного доступа).

Пока эти объекты находятся на локальном ПК или на рабочей станции, либо в пределах какого-либо сервера LAN их можно рассматривать как тиражированные; т. е. в разных точках среды фактически существуют множественные версии объектов, даже если в этой среде не применяется тиражирование объектов на нескольких серверах. Таким образом, для репозиториев настоятельной необходимостью являются средства управления конфигурациями включения/выключения, а также поддержка множества версий объектов.

Бернштейн также отмечает, что тиражирования можно избежать за счет применения суррогатов, или "живых ссылок", из одного репозитория в другой (рисунок 19-9). Модель репозитория с суррогатами предполагает, что каждый объект хранится где-либо в среде в единственном экземпляре, хотя клиентские приложения и инструменты имеют доступ к множеству серверов репозиториев. При этом по всему множеству серверов поддерживаются суррогатные объекты в соответствии с некоторой принятой для данной среды политикой распределения (полный комплект суррогатов на каждом сервере; разбиение множества суррогатов по локально сгруппированным множествам серверов и т. п.). Если клиент пытается получить доступ к некоторому объекту или выключить его, в то время как на данном сервере хранится не сам объект, а его суррогат, то по живой ссылке можно найти реальное местонахождение объекта и выполнить его удаленное выключение¹³.

На первый взгляд, непонятно, в чем же преимущества суррогатов, если для доступа или выключения объекта все равно приходится производить операцию над удаленным репозиторием. Но за счет того, что в суррогате хранится основная информация об объекте - его идентифицирующие характеристики и какие-то базовые свойства, - некоторые функции, предшествующие фактическому доступу (например выяснение вопроса о том, "действительно ли это тот объект, который нужен"), могут выполняться над суррогатами, что снижает суммарные системные затраты (на сетевой доступ и обработку) по сравнению с ситуацией, когда все функции выполняются относительно удаленных серверов репозиториев. Только если данный объект действительно нужен, будет выполнена операция над удаленным репозиторием.

В архитектурах с применением суррогатов, как и для реализации механизмов уведомлений (разд. 19.2), вероятно, окажутся полезными средства активных баз данных. Правила, определяющие местонахождение реального объекта и способы его получения, могут храниться в самих суррогатах; когда инструментальная система или пользователь принимает решение о том, что нужен доступ к реальному объекту, должны срабатывать соответствующие триггеры, запускающие процедуры доступа к объекту (рисунок 19-10).

19.5. Гранулярность

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

Традиционно репозитории, не являющиеся системами хранения метаданных для одного продукта, содержали объекты довольно грубого уровня гранулярности. Так, в нем могли храниться объекты, представляющие КОНСТРУКЦИИ или МОДЕЛИ, а также ссылки на локальные менеджеры метаданных, специфические для конкретного инструментального средства (например реализующие информационные схемы SQL DBMS INFORMATION_SCHEMA), где поддерживалась более подробная информация (метаданные для каждой таблицы, столбца, домена и других объектах базы данных). Такая схема изображена на рисунке 19-11.

Подобная реализация могла быть удовлетворительной для базовых сервисов репозиториев, но не для поддержки отношений между объектами, как показано выше на рисунке 19-4. Для выполнения функций корпоративного масштаба, таких как анализ влияний (т. е. анализ эффекта, который произвело бы то или иное изменение свойств объекта x) или полное отслеживание исходных требований (т. е. обеспечение их соблюдения на протяжении всего жизненного цикла системы), необходим значительно более тонкий уровень гранулярности. Причем, как правило, для этого нужно хранить не только информацию об объектах самого нижнего уровня (потоки данных, сущности, определения столбцов базы данных), но и абстракции более высокого уровня (конструкции, модели и их компоненты), а также все значимые взаимоотношения между объектами любого уровня.

С задачей поддержки необходимого уровня гранулярности связаны две сложные проблемы. Первая - это высокая структурная сложность поддерживаемой информации: каждый инструмент должен иметь возможность определять объекты множества уровней, вплоть до максимальной степени подробности, отвечающей его потребностям; при этом потребности разных инструментов, вообще говоря, не совпадают. Как уже упоминалось, одно из фундаментальных свойств репозиториев будущего - расширяемость (возможность определять новые классы объектов репозитория); таким образом, каждый инструмент должен сформулировать свои требования, расширив базовые модели репозитория путем добавления новых типов объектов и межобъектных связей.

Вторая проблема заключается в том, что для хранения тонко гранулированной информации необходимо огромное пространство памяти. Фактически, речь идет о базах данных террабайтных объемов (где будут находиться, возможно, миллиарды объектов) для хранения не пользовательской информации, а метаданных. Предполагаемые решения на уровне СУБД включают, в частности, массово параллельные архитектуры, поддерживающие фрагментацию метаданных, распределенные мультирепозитории (на основе мультибаз данных) с доступом клиент-сервер посредством предопределенных процедур и т. п.

19.6. Инструментальные средства репозиториев

Бернштейн высказал одну очень точную мысль: никому не нужны просто репозитории; важно, чтобы репозитории помогали работе инструментальных средств, а репозитории без инструментов бесполезны¹⁴. Точно так же, как бесполезны были бы базы данных без приложений, которые помещают в них информацию и способны интеллектуально и эффективно эту информацию извлекать, так и репозитории не имеют смысла без адекватного инструментария, способного использовать преимущества технологии репозиториев.

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

Поскольку объекты, хранимые в репозитории и управляемые с его помощью (программы баз данных, содержимое баз данных, включая мультимедийные данные и различные изображения), представлены в самых разных формах (текст, звук, графический образ), то инструменты должны обеспечивать поддержку для всех форм данных. Один из возможных подходов состоит в применении гипертекстовых инструментов (гипертекстовые средства обсуждаются в гл. 18). Этот подход в особенности полезен в ситуации, когда речь идет об интеграции разнородных репозиториев, использующих разные форматы данных¹⁵.

При помощи подобного инструмента удобно было бы, например, просматривать содержимое репозитория, следуя по гипертекстовым ссылкам между объектами и при этом постепенно изучая структуру системы. На рисунке 19-12 показан пример работы с гипертекстовым навигатором для просмотра репозитория.

19.7. Заключение

Хотя репозитории и базы данных имеют много общего, мы можем теперь провести между ними определенные различия по ряду признаков, связанных в основном с характером их использования. И те и другие служат для управления данными (репозитории поддерживают метаданные, базы данных - пользовательскую информацию), однако парадигмы их содержимого различны.

При реализации репозиториев в качестве менеджеров хранения объектов применяются, как правило, либо реляционные СУБД, либо разного рода "доморощенные" системы. При этом возникает значительный промежуточный слой, отображающий схему репозитория (основанную, как правило, на модели "сущность-связь" или на объектно-ориентированной модели) на средства менеджера хранения. Это часто приводит: 1) к замедлению работы системы; 2) к сложностям в управлении большими объемами данных, составляющих содержимое репозитория. По мере того как все большее распространение получают объектно-ориентированные базы данных ("чисто" объектно-ориентированные или гибридные реляционно-объектно-ориентированные), существующие сегодня менеджеры хранения неизбежно будут вытесняться ОО СУБД или расширенными РСУБД. Этот процесс будет, вероятно, способствовать появлению более рациональных инструментальных средств и механизмов взаимодействия с репозиториями.

Реализации репозиториев будут, по-видимому, развиваться в тех же направлениях, что и СУБД, вместе с их окружением: широкое распространение архитектур, где клиенты подключаются к распределенной среде серверов репозиториев, гетерогенное распределение информации по этим серверам, управляемое тиражирование их содержимого - все эти свойства станут общепринятыми.

Перспективы

Краткосрочные

• Принятие стандарта IRDS.
• Появление на рынке коммерческих продуктов, соответствующих стандарту IRDS: эти продукты смогут управлять метаданными в гетерогенной распределенной среде.

Долгосрочные

• К 2000 г., когда интегрированные системы и оболочки CASE (I-CASE) станут более развитыми, огромные репозитории приобретут роль фундамента всей информационной среды и связанных с ней инструментальных средств и систем.

Практические выводы

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

Технология репозиториев восходит к так называемым словарям данных, применявшимся в программных системах. По мере того как словари данных обогащались все новыми функциями и возможностями, они все более приобретали черты инструмента для корпоративного управления метаданными.

Для репозиториев, в отличие от баз данных, насущной является проблема стандартизации. Работы в этой области ведутся вот уже в течение нескольких лет (отметим, в особенности, усилия по выработке стандарта IRDS, предпринимаемые и на национальном, и на мировом уровнях), однако результаты их, с точки зрения зрелости и реализуемости в коммерческих системах, еще далеки от стандартов для баз данных, таких как SQL.

Одна из интенсивно развивающихся областей - это создание инструментов, которые бы помогали разработчикам и пользователям просматривать обширное и многообразное содержимое репозиториев. Другое важное направление - это внедрение мощных возможностей репозиториев в среду CASE (I-CASE) для поддержки разработки систем на всем протяжении их жизненного цикла; это позволит сохранять информацию об отношениях между объектами метаданных, относящуюся к разным стадиям разработки, и генерировать соответствующие отчеты (например о том, как то или иное требование реализовано в базе данных или, наоборот, о том, на основе каких исходных требований было сформировано определение таблицы или столбца).

Что дает эта технология

Необходимо четко представлять себе, каково нынешнее состояние и перспективы развития технологий репозиториев. Следует осторожно относиться к помпезному шуму вокруг идеи "управления метаданными в масштабах корпорации посредством единого репозитория". На самом деле пройдет еще несколько лет, вероятно, примерно до 2000-го года, прежде чем возможности репозиториев реально смогут удовлетворить потребности глобальных информационных систем мирового масштаба. Тем временем, вполне возможно оснастить репозиториями системы масштаба подразделения, что создаст предпосылки для последующей интеграции, когда развитие технологий достигнет уровня наших амбиций.

Литература

J. Noll and W. Scacchi. Integrating Diverse Information Repositories: A Distributed Hypertext Approach. - IEEE Computer (December 1991).

A. Simon. The Integrated CASE Tools Handbook. - Van Nostrand Reinhold/Intertext 1993).

A. Tannenbaum. Implementing A Corporate Repository: The Models Meet Reality. - New York: John Wiley & Sons, 1993).

Ссылки

1. P. Bernstein, "Repositories and Client/Server: Do The Fit?", Proceedings of the DCI Database World, Vol. 1 (June 1993), D9-3.

2. A. Tannenbaum, "U.S. Market Seeing Repository Rebirth," Software Magazine (June 1993), 47.

3. Адаптировано из разных глав книги A. Simon, "The Integrated Case Tools Handbook" (New York: Van Nostrand Reinhold/Intertext, 1993).

4. См. A. Simon, "The Integrated Case Tools Handbook", гл. 1, 12 и 14, где рассматриваются принципы интеграции CASE и система SoftBench (Hewlett-Packard)

5. A. Tannenbaum. "U.S. Market Seeing Repository Rebirth", стр. 54.

6. A. Tannenbaum. "U.S. Market Seeing Repository Rebirth."

7. A. Tannenbaum. "U.S. Market Seeing Repository Rebirth."

8. A. Tannenbaum. "U.S. Market Seeing Repository Rebirth."

9. A. Tannenbaum. "U.S. Market Seeing Repository Rebirth."

10. A. Tannenbaum. "U.S. Market Seeing Repository Rebirth."

11. P. Bernstein, "Repositories...", D9-9.

12. P. Bernstein, "Repositories...", D9-13.

13. P. Bernstein, "Repositories...", D9-14.

14. P. Bernstein, "Repositories...", D9-6.

15. J. Noll and W. Scacchi, "Integrating Diverse Information Repositories: A Distributed Hypertext Approach, " IEEE Computer (December 1991), 38-44.

^*) Глава из книги "Strategic Database Technology: Management For The Year 2000", выходящей в издательстве "Финансы и Статистика" в 1997 г.

© Morgan Kaufmann Publishers, Inc.

© Финансы и Статистика.