Bulletin of the Technical Committee on

Data Engineering

September 1998, Vol. 21, No. 3

IEEE Computer Society

Все номера Бюллетеня являются тематически ориентированными, и сентябрьский номер посвящен вопросам интероперабельности в контексте инженерии данных. В тематическом блоке представлено пять статей. Ниже приводится их краткий обзор.

---

Data Access Interoperability in the IBM Database Family
The Sybase Architecture for Extensible Data Management
Interoperability, Distributed Applications and Distributed Databases:The Virtual Table Interface
Solving the Data Inter-Operability Problem Using a UniversalData Access Broker
Exporting Database Functionality - The Concert Way

---

 

Data Access Interoperability in the IBM Database Family

Michael J. Carey    Laura M. Haas    James Kleewein    Berthold Reinwald
{carey, laura, reinwald}@almaden.ibm.com, kleewein@us.ibm.com

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

В статье предлагается краткий обзор того, что делает компания IBM в связи с наличием упомянутых задач. Более конкретно, описываются средства доступа к неоднородным данным, обеспечиваемые в продуктах семейства DB2 Universal Database (DB2 UDB). Для решения проблемы доступа и управления данными, рассредоточенными по разным базам данным и системам баз данных, DB2 UDB включает технологию DataJoiner, обеспечивающую прозрачный доступ на основе языка SQL к унаследованным данным, которые управляются СУБД многих производителей. В связи с требованиями доступа к внешним данным и управлением ими в семействе DB2 UDB предлагается несколько соответствующих технологий:

• Table Functions для кастомизации определяемого пользователями доступа к внешним данным;
• DataLinks для синхронизации состояния файловых систем с состоянием баз данных;
• Extenders для управления новыми типами данных, такими как текст, графические и пространственные данные.

Все эти расширения описываются в статье, а читатели, которые интересуются вопросами применения унаследованных транзакций, отсылаются к статье о технологии Component Broker (www.software.ibm.com/ad/cb/litp.html), в которой описываются текущие работы IBM в этой области.

Данная статья особенно полезна для тех, кто использует DB2, но представляет интерес для все интересующихся текущим промышленным состоянием систем, поддерживающих интероперабельность данных.

 

The Sybase Architecture for Extensible Data Management

Steve Olson    Richard Pledereder    Phil Shaw    David Yach {olson, pleder, phil.shaw, yach}@sybase.com

Иллюзорной целью многих больших организаций является создание единой виртуальной системы, обеспечивающей интеграцию всех информационных ресурсов корпорации с координируемым и облегченным доступом к информации. Для того, чтобы помочь своим заказчикам в решении этой проблемы, помочь решить свои бизнес-проблемы и добиться выигрыша в конкуренции, компания Sybase предлагает стратегию Адаптивной Компонентной Архитектуры (Adaptive Component Archtecture - ACA). Основными аспектами ACA (см. также www.sybase.com/aca/whitepaper.html) являются:

• Использование стандартных промышленных компонентов;
• Быстрая разработка приложений;
• Доставка данных в правильном виде, в нужном месте и в требуемое время;
• Минимизация сложности как для конечных пользователей, так и для разработчиков.

ACA обеспечивает основу для разработки многозвенных информационных систем, обеспечивающую возможности управления и использования компонентов в распределенной вычислительной среде. Sybase обеспечивает средства для создания промежуточного звена - сервера приложений и базового звена - сервера баз данных. Для создания серверов приложений могут использоваться продукты Jaguar Component Transaction Server и PowerDinamo. Продуктом для поддержки базового звена является Sybase Adaptive Server, в который в рамках унифицированной архитектуры ACA входят SQL Server, Sybase IQ и SQL Anywhere.

Статья содержит подробное обсуждение того, как в Adaptive Server поддерживаются

• обработка распределенных запросов (наибольшее внимание уделяется вопросам оптимизации распределенных запросов),
• специальные типы данных (текст, временные ряды, геопространственные данные),
• расширения на основе Java (SQLJ, JDBC, определение хранимых процедур и пользовательских функций).

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

 

Interoperability, Distributed Applications and Distributed Databases:
The Virtual Table Interface

Michael Stonebraker    Paul Brown    Martin Herbach
Informix Software, Inc.

Для построения распределенных баз данных и распределенных приложений требуется обеспечение интероперабельности разнородных данных и компонентов соответственно. В статье обсуждается, каким образом в одной расширяемой объектно-реляционной системе баз данных могут поддерживаться обе модели интероперабельности. Описывается средство Virtual Table Interface (VTI), поддерживаемое в INFORMIX-Dynamic Server Universal Data Option (UDO) и обеспечивающее упрощенный доступ к разнородным компонентам.

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

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

Механизмом расширения возможностей менеджера памяти в UDO является VTI. Этот механизм позволяет пользователю определять таблицы, доступ к которым управляется пользовательским программным кодом. Для всех остальных частей UDO, включая подсистему запросов, особый статус виртуальной таблицы не виден. С помощью VTI создаются новые методы доступа. Соответствующие данные не обязательно должны храниться в штатной подсистеме хранения. Они могут создаваться даже "на лету" путем вызова внешнего компонента приложения, что делает VTI полезной парадигмой интероперабельности. Технические возможности VTI иллюстрируются на ряде примеров.

Стиль статьи - блестящий. Как это свойственно большинству статей Майкла Стоунбрейкера, эта статья позволяет глубже понять вроде бы известные, но недостаточно оцененные идеи.

 

Solving the Data Inter-Operability Problem Using a Universal Data Access Broker

Mike Higgs    Bruce Cottman
I-Kinetics, Inc.
{mhiggs, bruce.cottman}@i-kinetics.com

Статья начинается с подробного объяснения исторических корней проблемы интероперабельности. Основным примером корня зла является Библейская Вавилонская башня, в которой люди просто не могли понять друг друга по причине отсутствия инструментов поддержки интероперабельности. С самого начала различаются два понятия - способ представления данных и интерфейс доступа к данным. Вводится понятие универсального брокера доступа к данным, выступающего своего рода переводчиком языков конкретных интерфейсов с целью сделать их понятными для всех. Задача, кажущаяся теоретически нерешаемой, облегчается тем человеческим фактором, что имеется тенденция к ограничению общеупотребительных интерфейсов "наиболее часто используемыми". Одним из примеров является интерфейс ODBC, который основан на языке SQL, но реализации которого имеются даже для объектно-ориентированных баз данных с совсем другим способом представления данных.

По мнению авторов, имеющимися сейчас и отсутствовавшими ранее опорными информационными технологическими аспектами являются следующие:

• Широко доступные и экономически обоснованные мультипотоковые и мультипроцессорные системы.
• Повсеместно доступные и экономически обоснованные инфраструктуры распределенных вычислений.
• Применимость языка Java и основанных на этом языке интерфейсов для доступа к данным.
• Повсеместное использование и признание объектно-ориентированного подхода к построению систем.

Реальное существование этих аспектов сделало возможным для автором спроектировать и реализовать универсальный брокер DataBroker, представляющий практическое решение проблемы интероперабельности. По экономическим соображениям было решено показать жизненность понятия универсального брокера путем реализации на его основе фактического стандарта JDBC для Java. Опять же по экономическим причинам было решено вначале обеспечить поддержку распространенных представлений данных, поддерживаемых реляционными и дореляционными базами данных, такими как DB2 и IMS. В то же время, компания I-Kinetics развивает экспериментальные исследования, направленные на обеспечения возможности доступа через интерфейсы DataBroker к любым представлениям данных.

DataBroker реализован как многопотоковый сервер на основе CORBA, обеспечивающий отображение многопотоковости в семантику желаемого интерфейса. Например, для реализации JDBC каждый поток соответствует конкретному подключению JDBC, который отображается в сессию по отношению к представлению хранимых данных. DataBroker полностью базируется на CORBA. В качестве ORB используется Orbix со своими средствами безопасности, именования и транзакционности. В начальном варианте DataBroker поддерживает интерфейсы JDBC и CORBA IDL, причем по прагматическим соображениям реализация IDL основана на использовании JDBC.

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

 

Exporting Database Functionality - The Concert Way

Lukas Relly    Heiko Schuldt    Hans-J. Schek
Database Research Group
Institute of Information Systems
ETH Zurich, Switzerland

В современных СУБД используется неявное предположение о том, что услуги систем оказываются только по отношению к данным, хранимым в поддерживаемых ими базах данных. Все данные должны быть импортированы в соответствующую базу данных и перейти "во владение" соответствующей СУБД. Это предположение соответствует потребностям традиционных приложений баз данных, таких как банковские приложения, для которых достаточны поддержка модели данных СУБД, ее языки запросов и манипулирования данными и управление транзакциями. Однако продвинутые приложения из областей GIS, CAD, управления документами и т.д. во многих аспектах отличаются от традиционных приложений. Индивидуальные операции в таких приложениях являются намного более сложными и их непросто выразить на существующих языках запросов. Для решения задач этих приложений требуется доступ к данным, представленных в частных форматах или форматах обмена данными.

Некоторые новые СУБД, например, Oracle8 и Informix-Dynamic Server Universal Data Option обеспечивают доступ в BLOB-интерфейсе к обычным файлам операционной системы, а также включают возможности определения новых типов данных и соответсвующих конструкторов. Однако, если не считать случая использования файловых систем, все эти расширения обладают одними и теми же недостатками.

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

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

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

Статья представляет несомненный интерес для всех специалистов, работающих в области новых средств управления данными. Возможно, статья поможет по-новому взглянуть на само понятие системы управления