Методологии моделирования

Имеется много оснований для того, чтобы создавать модель и

использовать средства моделирования и проектирования, а не

перепрыгивать через этот этап и сразу приступать к прямому

программированию базы данных и приложений. Моделирование помогает

навести мосты между бизнес-концепциями (концептуальными

моделями), проектами баз данных (логическими моделями) и

физическими реализациями баз данных (физическими моделями или

схемами).

Логическая модель, созданная с применением средства

проектирования, изолирована от специфических особенностей СУБД,

теоретически позволяя реализовать один и тот же проект на разных

СУБД. Схемы же привязаны к конкретным серверным продуктам

управления базами данных. В течение многих лет средства

моделирования обладают возможностями обратной инженерии

(порождения логических моделей на основе существующих баз данных)

и прямой инженерии (генерации схем баз данных на основе

логических моделей).

Microsoft

Компания Microsoft для достижения расширяемости данных выбрала подход, менее ориентированный на базы данных, чем подходы Informix, IBM или Oracle. Microsoft все еще работает над преодолением унаследованного от Sybase SQL Server отсутствия блокировок на уровне строк и поддержки параллелизма. Компания старается продемонстрировать возможность Windows NT быть платформой баз данных переднего края. В отношение расширяемости, подобно Sybase, Microsoft в большей степени опирается на компонентный подход.

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

OLE DB - это промежуточное программное обеспечение, предоставляющее согласованный уровень абстракции по отношению к разнообразным типам и источникам данных. Обеспечивается единый интерфейс объектного уровня, позволяющий пользователям производить выборки из разнородных наборов данных, а поставщикам данных - делать их доступными. Кроме того, Microsoft преобразует SQL Server в СУБД, которая может обращаться к другим источникам данных, за счет отделения процессора запросов от компонента хранения данных. Теперь эти компоненты сами взаимодействуют через OLE DB. Если поставщики других хранилищ данных будут поддерживать OLE DB, Microsoft сможет интегрировать их в среду SQL Server для обработки запросов. SQL Server будет развит для обработки распределенных запросов, стоимостная информация будет пересылаться между источниками данных. Кроме того, каждый источник данных будет демонстрировать свою каталожную информацию через интерфейсы OLE DB.

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

Многомерная модель: Против

Для создания многомерной модели требуется разработать комбинацию составных данных, все DDL (операторы определения данных), программы извлечения данных; все сценарии нагрузки должны работать в соответствии с моделью и поддерживать ее. Многомерное моделирование уменьшает рабочую нагрузку СУБД и перекладывает работу на плечи разработчика базы данных. Очевидно, что это не идеально; база данных может работать быстрее и точнее, чем люди, у которых уже имеется трудная задача реализации сложного склада данных. Появляются дополнительные расходы, связанные с выполнением работы вручную.

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

Многомерность

OLAP (On-Line Analitical Processing - оперативная аналитическая

обработка) и многомерный анализ представляют собой важные факторы

систем поддержки принятия решений. Поддерживаемые в Oracle

звезднообразные запросы с соединениями (star-query join)

обеспечивают многомерное представление данных путем получения

Декартова произведения таблиц измерений с последующим соединением

результата с таблицей фактов. В DB2 используется модифицированный

оптимизатор, использующий динамические побитные индексы и

предварительное чтение списков для выборки строк из многомерной

таблицы фактов. Использование побитных индексов позволяет

повысить эффективность доступа к многомерным данным. В DB2 v.5

побитные индексы могут создаваться динамически, в то время как в

Oracle8 они должны быть предопределены. (Важно заметить, что

реализация побитных индексов IBM и Oracle существенно

различается.) Кроме того, в DB2 поддерживаются новые функции SQL

ROLLUP и CUBE, облегчающие многомерный анализ. Пользователи могут

"закатить" данные на более высокий уровень агрегации и видеть

данные в структуре куба, а не в традиционных табличных

структурах. Эти возможности расширяют функциональность языка SQL

и облегчают жизнь пользователей. Компания Oracle интегрирует c

Oracle8 продукт IRI Express для развития возможностей

многомерного анализа. В ближайшем будущем IBM также будет

обеспечивать полную поддержку многомерных данных за счет

интеграции UDB с сервером Essbase OLAP компании Arbor Software.

Многомерные модели: За

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

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

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

Моделирование "объект-роль"

В традиционных методологиях моделирования реляционных баз данных

обычно пренебрегают поддержки концептуального уровня.

Моделирование "объект-роль" (ORM - Object-Role Modeling) - это

привлекательная методология, направленная на отрицание этого

правила. Понятия ORM известны в течение ряда лет, хотя

методология стала привлекать широкое внимание относительно

недавно в связи с работой Терри Хаплина (Terry Haplin) по

реализации средства проектирования InfoModeler. Формальный язык

моделирования "объект-роль" (FORML - Formal Object-Role Modeling

Language) основан на концепциях ORM и поддерживает

систематический и строгий подход к моделированию

бизнес-концепций. Концептуальный моделер FORML позволяет

вербализовать данные, представить их в символической или

диаграммной форме, ограничить концептуальную модель фактами,

иллюстрирующими утверждения и проверить правильность модели.

Мотивация

С самого начала язык Java позиционировался как язык программирования для использования в среде Web. На Java разрабатывалось много простых приложений (игры, часы, тикеры и т.д.) информативных, новаторских Web-узлов. Но следует заметить, что языковые компоненты и конструкции, первоначально внедренные в язык для расширения его функциональных возможностей как Web-ориентированного языка, могут применяться и в других областях. Язык Java обеспечивает разработчиков средствами, пригодными для создания новых сетевых приложений, приложений баз данных и графических пользовательских интерфейсов (GUI Graphical User Interface). Java и связанные с этим языком технологии, такие как API JDBC, драйверы JDBC, многопоточность и AWT обеспечивают поддержку разработки независимых от платформы и используемой базы данных приложений. Вот компоненты, которые играют важную роль при построении интерфейсов с базами данных:

JDBC. Модуль Java Database Connectivity предоставляет

стандартизованное решение проблемы доступа к базам данных (JDBC

входит в пакет поставки Java начиная с версии 1.1).

Java Threads. Java - это многопотоковый язык программирования.

Поддерживается возможность создания и выполнения нескольких

нитей (легковесных квази-процессов) при выполнении в то же время

нескольких разных задач.

AWT. Набор инструментальных средств Abstract Window Toolkit

позволяет строить независимые от платформы графические

пользовательские интерфейсы.

Комбинация перечисленных компонентов составляет базовые

строительные блоки, используемые для разработки интерфейсов к

распределенным базам данных. Пакет Java Distributed Query

Dispatcher (JavaDQD) является независимым от платформы

GUI-приложением, позволяющим направлять запросы одновременно к

нескольким разнородным базам данных. В основе JavaDQD лежат

следующие идеи:

JavaDQD устанавливает подключение к базе данных с

использованием API и драйверов JDBC. Использование API дает

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

поддерживающей драйвер JDBC. Тем самым, пользователь может

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

базам данных Sybase используется драйвер FastForward, а для

доступа к базам данных MiniSQL - драйвер mSQL-JDBC. (Для

достижения требуемой функциональности mSQL-JDBC авторам пришлось

доработать.) По мере появления драйверов JDBC JavaDQD позволит

работать и с другими базами данных.

В JavaDQD используются нити Java для обеспечения пользователей

возможностью одновременного подключения к нескольким базам

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

баз данных. В этом случае для каждой затрагиваемой глобальным

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

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

В JavaDQD применяются AWT и другие компоненты для

предоставления пользователям интерфейса в стиле QBE

(Query-By-Example). Этот интерфейс создает единое виртуальное

окружение, в котором отображается информация обо всех текущих

подключениях. В результате пользователи в едином интерфейсе могут

запрашивать данные из разных баз данных так, как если бы это была

одна база данных.

Нам не всегда желательна инкапсуляция

Еще одна причина, которая заставляет автора считать инкапсуляцию не настолько важным понятием, как это полагается в литературе, состоит в следующем. Некоторые типы являются совсем не инкапсулированными, и это никому не мешает! В частности, это относится к "генерируемым" типам, которые определяются с использованием генераторов типов, такие как ARRAY, LIST, TUPLE и RELATION. Рассмотрим для определенности RELATION. Предположим, что теперь мы имеем дело с relvar (relation variable) POINT:

VAR POINT ... RELATION { X ..., Y ... } ... ; /* для простоты типы атрибутов X и Y опущены */

Замечание: Определение сформулировано на языке Tutorial D, который определен в Third Manifesto для иллюстративных целей. Многоточия в определении поставлено вместо конструкций, не являющихся существенными для этого обсуждения.

В этом определении для указании (генерируемого) типа relvar используется генератор типов RELATION; это конкретный тип отношения, а именно:

RELATION { X ..., Y ... } /* снова для простоты типы атрибутов X и Y опущены */

И этот тип определенно не является инкапсулированным: у него имеются видимые пользователям компоненты - атрибуты X и Y. И именно наличие этих видимых пользователям компонентов позволяет выполнять над relvar POINT непредвиденные запросы; например, можно выполнить проецирование на атрибут Y, ограничение по условию "значение Y меньше пяти".

Заметим мимоходом, что похожие наблюдение содержатся в книге Mike Stonebraker про объектно-реляционные СУБД: "Базовые типы полностью инкапсулированы. Единственный способ манипулировать [экземпляром] базового типа состоит в том, чтобы выбрать его и выполнить функцию, принимающую [экземпляр этого типа] в качестве аргумента. В противоположность этому, составные типы полностью прозрачны. Можно видеть все поля, и они легко доступны в языке запросов. Конечно, промежуточная позиция заключается в том, чтобы допустить в составном объекте наличие публичных (видимых) полей и приватных (инкапсулированных). Этот подход используется в Си++". Однако следует добавить, что остается неясным, проводит ли Стоунбрейкер четкое различие между реальными и возможными представлениями, как это делается в The Third Manifesto.

Вернемся к основному аргументу. Тот факт, что типы отношений не искапсулированы, не означает потерю независимости данных! Например, в случае relvar POINT нет абсолютно никаких причин, по которым нельзя было бы физически представить эту relvar полярными координатами R и U, а не декартовыми координатами X и Y. (Вероятно, это невозможно сделать в сегодняшних продуктах SQL, но это недостаток продуктов. Сегодняшние продукты SQL вообще обеспечивают меньшую независимость данных, чем теоретически в состоянии обеспечить реляционная технология.) Другими словами, даже при использовании не инкапсулированных типов требуется четко различать типы и представления, и "отказ от инкапсуляции" не обязательно ведет к разрушению независимости данных.

Намеки на будущее

Грядущий мир объектно-реляционных VLDB предлагает разработчикам и

конечным пользователям приложений богатые возможности получить

более мощные, интуитивно понятные и продуктивные приложения.

Однако, как это часто бывает при использовании новых технологий,

прежде, чем такие приложения станут обычными, потребуется период

изучения. Это изучение (и некоторые существенные изменения в

реализации) должно быть произведено поставщиками СУБД, которые

должны обеспечить функции манипулирования данными, определения

данных, администрирования и также средства обучения. Требуются

также значительные усилия для обеспечения всех необходимых типов

данных и методов и оптимизации данных. Эти процессы будут в

полном разгаре в 1998 г. и должны начать стабилизироваться в

1999-2000 гг.

Некоторые лингвистические аспекты

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

Величайшая интуиция Кодда подсказала ему, что можно представлять базу данных как набор отношений, которые, в свою очередь, могут представляться в виде наборов высказываний (по договоренности считающихся истинными), и следовательно, языки и понятия логики могут быть прямо применены к проблеме доступа данных и связным проблемам. В этом разделе статьи он обрисовал основные черты языка доступа, основанного на этих понятиях. Эти черты включают следующее: Язык должен быть ориентирован на работу с множествами, основное внимание должно быть сосредоточено на выборке данных (хотя должен также включать и операции обновления). Кроме того, язык не должен быть вычислительно полным; это означало, что речь идет о "подъязыке", "[встраиваемом] в разнообразные включающие языки ... Любые требуемые [вычислительные] функции могут определяться во [включающем языке] и вызываться [из подъязыка]". Лично я никогда не был полностью убежден в том, что выделение средств доступа к данным в отдельный подъязык было хорошей идеей, но он пребывает с нами в течение довольно долгого времени (в обличии встраиваемого SQL). Между прочим, в связи с этим интересно заметить, что с добавлением к стандарту SQL в 1996 г. возможности PSM (Persistent Stored Modules) SQL сам по себе теперь стал вычислительно полным языком, что означает отсутствие потребности во включающем языке (включающем SQL).

Кодд также писал: "Выполнение некоторых операций удаления может вызываться другими такими операциями, если объявлены зависимости по удалениям." Другими словами, уже в 1969 г. Кодд допускал возможность автоматически вызываемых "ссылочных действий", таких как CASCADE DELETE (и в статье 1970-го года он расширил это поняти, введя и ссылочные действия UPDATE. Кроме того, язык должен обеспечивать симметричное использование. Т.е. пользователь должен иметь возможность доступа к данному отношению с использованием любой комбинации его атрибутов, как известных, так и оставшихся неизвестными. "Эта возможность отсутствует в большинстве современных информационных систем." Совершенно верно. Ны мы принимаем это теперь как sine qua non (обязательное условие), по крайней мере, в реляционном мире. (По некоторым причинам в объектном мире эту возможность не считают настолько важной.)

Но что насчет непредвиденных запросов?

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

Получить Y-координату точки P Выбрать все точки по оси X Выбрать все точки со значением ординаты меньшим пяти.

В Third Manifesto (3) Крис Дейт и Хью Дарвин для разрешения этого конфликта предлагают потребовать, чтобы для каждого заданного типа были определены операции, раскрывающие некоторое возможное представление экземпляров этого типа (авторы называют такие операции "THE_operators"). Для типа POINT, например, можно было бы определить операции THE_X и THE_Y, что позволило бы производить следующие действия:

Q := THE_Y (P) ; /* получить Y-координату точки P и присвоить ее Q */ Z := SQRT ( THE_X (P) ** 2 + THE_Y (P) ** 2 ) ; /* получить расстояние до точки P от точки (0,0) и присвоить его Z */

Таким образом, THE_X и THE_Y действительно раскрывают возможное представление - а именно, декартовы координаты X и Y - и обеспечивают возможность выполнять непредвиденные запросы с точками. Однако это не означает того, что внутри системы точки действительно представлены декартовыми координатами; это значит лишь то, что декартовы координаты являются возможным представлением. В реальном представлении могут использоваться декартовы координаты, полярные координаты R и U или что-нибудь совсем другое. Другими словами, THE_операции не нарушают инкапсуляцию и не подрывают независимость данных. Заметим, кстати, что типы данных DATE и TIME языка SQL представляют пример встроенных типов с раскрытием некоторых возможных представлений. Например, для дат раскрывается возможное представление с компонентами YEAR, MONTH и DAY. Хотя, вероятно, следует добавить, что эти "возможные" представления в SQL, к сожалению, близки к реальным представлениям; в SQL различие между типами и представлениями часто не является четким.

Номинация "Брокер объектных заявок"

Победитель - VisiBroker (Visigenic Software, )

После поглощения компании PostModern Computing и ее продукта

компания Visigenic заняла лидирующие позиции на рынке брокеров

объектных заявок. Поддерживая такие Web-технологии как Java и

IIOP, компания работает с мощной группой партнеров (Netscape,

Novell, Oracle, Sybase, Borland, Hitachi), которые используют

VisiBroker в своих продуктах.

Номинация "CASE-средство для моделирования баз данных и приложений"

Победитель - ERwin (Logic Works Inc., )

ERwin обеспечивает возможности сложного моделирования, генерации

схемы, реинжениринга, а также позволяет интегрировать средства

разработки. В настоящее время продукт расширяется, чтобы быть в

состоянии моделировать сложные данные в универсальных серверах.

Номинация "Генератор отчетов для использования в приложениях или при необходимости"

Победитель - Crystal Reports (Seagate Software Inc.,

)

Crystal Reports обеспечивает доступ к десяткам источников данных,

и базовый компонент системы может быть внедрен в приложения с

использованием множества различных интерфейсов. В версии 6.0

добавлены средства поддержки Web, так что могут производиться

отчеты, доступные для браузеров.

Номинация "Лучшая техническая поддержка баз данных и средств разработки приложений"

Победитель - ERwin (Logic Works Inc., )

В этой номинации читатели DBMS выбрали ERwin компании Logic

Works как предпочтительное CASE-средство, выделив исключительные

качества технической поддержки.

Номинация "Лучший обозреватель или автор"

Победитель - Joe Celko

Кто сказал, что язык SQL скучен? Колонка Joe Celko "SQL for

Smarties" дает возможность читателям познакомиться с его

уникальными и перспективными соображениями в области индустрии

баз данных.

Читателям предлагались еще и следующие номинации, но по причине

малого числа поданных голосов награды не были присуждены:

"Средство тестирования для приложений "клиент/сервер" и

"Internet/intranet""

"Средство миграции, преобразования и очистки данных для складов

данных и других потребностей в миграции"

"Web-сервер как шлюз к базам данных или средство интеграции"

Номинация "Монитор обработки транзакций"

Победитель - Tuxedo (BEA Systems Inc., )

Tuxedo - это популярный монитор транзакций, работающий на

различных UNIX-платформах и в среде Windows NT. Сегодня Tuxedo

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

отслеживает работу приложений, администрирует безопасность,

управляет сообщениями и т.д.

Номинация "Наиболее существенный продукт, появившийся (или значительно измененный) в 1997 г.

Победитель - ERwin (Logic Works Inc.)

В ERwin 3.0 различаются логическая и физическая модели. В

последней версии продукта улучшены возможности пользовательского

интерфейса и введены практические усовершенствования, такие как

поддержка представлений.

Номинация "Наиболее значимый продукт для использования в складах и лавках данных"

Победитель - Teradata RDBMS (NCR Corp., )

Размеры баз данных, используемых для поддержки складов данных,

растут с феноменальными темпами. Сегодня в ходу такие термины как

петабайты. Компания Teradata начала поставлять параллельные СУБД

в 1984 г. задолго до того, как параллельная обработка стала

обычной в РСУБД переднего края. В настоящее время сервер баз

данных Teradata является популярным средством для организации

больших складов данных.

Номинация "Объектно-ориентированная СУБД для долговременного хранения классов и объектов"

Победитель - ObjectStore (Object Design Inc., )

ObjectStore - это зрелая ООСУБД, побеждавшая и в прошлые годы.

Сервер ObjectStore 5.0 обеспечивает интерфейсы для Java, ActiveX

и C++.

Номинация "Пакеты приложений для бухгалтерии и других бизнес-функций"

Победитель - Oracle Applications (Oracle Corp.)

Продукт Oracle Applications включает более 30 интегрированных

модулей для управления финансами, человеческими ресурсами,

управления поставками и т.д.

Номинация "Промежуточное программное

Победители - SQL Net (Oracle Corp.) и ODBC (Microsoft Corp.)

При критическом значении, которое промежуточное программное

обеспечение имеет для приложений, связанных с использованием баз

данных, эта разновидность программного обеспечения должна

оставаться прозрачным для конечных пользователей. Компания Oracle

предлагает стандартную версию SQL Net в связке со своими

популярными РСУБД. ODBC компании Microsoft претендует на большее:

драйверы ODBC имеются практически для всех доступных источников

данных (включая нереляционные) и почти все средства разработки

поддерживают использование этих драйверов.

Номинация "Сервер баз данных для

Победитель - Oracle (Oracle Corp. )

Поддерживая сверхбольшие базы данных, побитовую индексацию,

оптимизацию звезднообразных запросов и развитые средства

распараллеливания, компания Oracle доказала свою возможность

обеспечить потребности приложений складов и лавок данных.

Номинация "Сервер баз данных для оперативной обработки транзакций и операционных приложений"

Победитель - Oracle (Oracle Corp. )

Читатели DBMS продолжают хранить верность Oracle7 и теперь

Oracle8. РСУБД компании Oracle поддерживают большое число

пользователей, выполняют большое число транзакций, позволяют

работать с большими базами данных, обеспечивают высокий уровень

доступности данных. Улучшенная производительность Oracle8 должна

позволить компании остаться лидером в области OLTP.

Номинация "Средства разработки

Победитель - Visual Basic (Microsoft Corp., )

Появление Visual Basic революционизировало разработку приложений

в среде Windows. Но до появления версии 3.0 Visual Basic не

обеспечивал встроенную поддержку разработки приложений баз

данных. Сегодня Visual Basic - это зрелый и мощный продукт для

построения приложений масштаба предприятия, особенно при

использовании его с новейшими компонентами Back Office, такими

как Microsoft Transaction Server и Microsoft Message Queue

Server.

Номинация "Средства разработки приложений на основе Java и Web-браузера"

Нет победителя

Читатели высказали много различных мнений, но ни один продукт не

набрал достаточного количества голосов, чтобы быть признанным

победителем.

Номинация "Средства запросов

Победитель - BusinessObjects (Busines Objects SA,

)

Продукт может быть применен при использовании оперативных баз

данных, складов и лавок данных, а теперь еще и внутри

Web-браузеров. В последней версии (4.1) имеется возможность

использования интеллектуальных агентов для оповещения

пользователей об изменениях в базе данных.

Номинация "Средство администрирования серверов баз данных (включая системы неоднородных баз данных)"

Победитель - SQL Enterprise Manager (Microsoft Corp.,

)

С годами Microsoft SQL Enterprise Manager стал мощной и

популярной утилитой, позволяющей легко администрировать сложные

реляционные СУБД.

Номинация "Средство управления

Победитель - CA-Unicenter TNG (Computer Associates International

Inc., )

CA-Unicenter TNG управляет ресурсами в широком диапазоне, включая

сети, приложения, базы данных в среде различных операционных

систем. Продукт поддерживает безопасность, отслеживает события,

управляет распространением и обновлением программного обеспечения

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

Номинация "Средство управления версиями и исходным кодом"

Победитель - PVCS Series (Intersolv Inc., )

При наличии все возрастающей роли приложений, основанных на

Web-браузерах и HTML-страницах, надежная система управлениями

версиями, как всегда, актуальна.

Номинация "Срелство управления базами данных для технически неподготовленных пользователей"

Победитель - Access (Microsoft Corp., )

Последние усовершенствования продукта в значительной степени

облегчают его использование: имевшиеся ранее многочисленные

многошаговые процедуры теперь существенно упрощены и убыстрены.

Access близок к популярным средствам разработки уровня конечного

пользователя.

Номинация "Управление текстовой

Победитель - Oracle (Oracle Corp.)

После появления версии 7.3 Oracle7 РСУБД стала центром

универсального сервера компании. Не удовлетворяясь более

хранением только табличных данных, компания поставляет

специализированные серверы, такие как ConText для

интеллектуального управления текстовыми данными и Oracle Video

Server. Теперь механизм картриджей обеспечивает другие средства

для поддержки сложных типов данных в среде Oracle.

Нормальная форма

Как уже отмечалось, наиболее значительным изменением изменением в статье 1970-го г. является та идея, что всегда следует нормализовывать отношения: их следует определять только на "доменах, элементы которых являются атомарными (не составными) значениями". Таким образом, "нормализация" означает "отсутствие повторяющихся групп" или то, что теперь называется первой нормальной формой - 1NF. (Нормальные формы более высокого порядка -- 2NF, 3NF и т.д. -- были определены позже.) Кодд настаивает на нормализации, потому что нормализованное отношение "может быть представлено в памяти в виде двумерного массива с однородными столбцами ... [хотя] для отношений необходимы некоторые более усложненные структуры данных [т.е. ненормализованность].

Странно, что в своем первом аргументе в пользу нормализации Кодд сосредотачивается на простоте представления в памяти. Возможно, в действительности он имел в виду простое представление для пользователей. Немного странным является его использование термина "массив", поскольку доступ к элементам массива производится путем адресации их позиций, в то время как для элементов отношения (n-кортежей) это в основном не так.

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

Как кажется, второе утверждение является первым явным упоминанием Кодда того факта, что реляционная модель строго исключает использование указателей -- факта, который, как вы должны знать, впоследствии стал предметом многих споров. "Применение реляционной модели данных ...
дает возможность разработки универсального подъязыка данных, основанного на прикладном исчислении предикатов. Если набор отношений находится в нормальной форме, оказывается достаточным исчисление предикатов первого порядка." Это важный момент! -- и в нем отражается основной отход от статьи 1969-го года, в которой обсуждалось исчисление предикатов второго порядка, а не первого. Для читателей, которые могут быть не знакомы с этими понятиями, позвольте мне сказать (в реляционных терминах) лишь то, что "первый порядок" означает, что мы квантифицируем только строки отношений, а "второй порядок" дает возможность расставлять кванторы над отношениями. Логика первого порядка позволяет формулировать такие запросы как "Существует ли поставщик S1 в отношении поставщиков?" Логика второго порядка дает возможность формулировать запросы типа "Существует ли поставщик S1 в каком-либо отношении?"

Я хотел бы сказать еще кое-что по поводу этого вопроса нормализации. Я согласен с Коддом, что желательно оставаться в рамках логики первого порядка, если это возможно. В то же время я отвергаю идею "атомарных значений", по крайней мере в смысле абсолютной атомарности. В Третьем манифесте [3] мы допускаем наличие доменов, содержащих значения произвольной сложности. (Они могут быть даже отношениями.) Тем не менее, мы остаемся в рамках логики первого порядка. Более подробное обсуждение этой темы увело бы нас слишком далеко; если вы хотите знать больше, детали содержатся в другой статье Дарвена [4].

В статье 1970-го года Кодд приводит простой пример, показывающий, что происходит при нормализации ненормализованного отношения. Как уже отмечалось, под "нормализацией" здесь понимается приведение к первой нормальной форме, и пример является весьма прямолинейным. Однако в статье содержатся следующие дразнящие замечания: "Возможны и операции дальнейшей нормализации. Они не обсуждаются в этой статье." Еще один намек на появление интересной области исследований!

Между прочим, Кодд также замечает, что "он не знает приложений, в которых бы потребовался первичный ключ, компонент которого определен на домене с неатомарными значениями" (значительно перефразировано). В действительности такие приложения существуют, и одно из них описано в статье Дарвена [4]. Однако только то, что такие приложения существуют, не означает невозможности нормализации существующих отношений. (Опять же, это связано с тем, как понимать "атомарность".) И снова дальнейшее обсуждение нас увело бы слишком далеко.

Новые виды ответственности

Понятно, что расширяемость и функциональные возможности,

получаемые при добавлении объектных свойств к среде VLDB,

приводят к появлению новых видов ответственности для всех

сторон, связанных с созданием приложений.

Разработчики новых типов данных и методов могут теперь не

являться сотрудниками компании-поставщика СУБД, как это было при

применении чисто реляционных данных. В этом случае они будут

отвечать за оптимизацию данных и обеспечение оценочных функций.

Они также должны обеспечить новые средства индексации и методы

доступа к данным, когда это требуется. При тестировании этого

программного обеспечения потребуются механизмы изоляции и

разрешения проблем. В будущем эти разработчики будут должны при

необходимости предоставлять параллельные версии своих методов.

Новые виды ответственности появляются и у разработчиков

приложений. Они должны более тщательно обдумывать управление

внешней памятью и буферами и решать, что и когда следует

журнализовать. Как и администратор баз данных, они должны

реализовывать стратегии управления внешней памятью и буферами,

наиболее соответствующие проекту приложения, формулировать и

реализовывать стратегию журнализации, соответствующую требованиям

целостности и восстанавливаемости данных, производить более

сложный выбор средств индексации и денормализации и выбирать, где

следует выполнять разные функции для достижения оптимального

соотношения стоимость/эффективность - на сервере баз данных, на

сервере приложений или на стороне клиента.

Наконец, для достижения успеха новые виды ответственности должны

принять на себя и поставщики СУБД. В дополнение к обязанности

поставлять надежно работающие ОР-продукты для параллельных сред

они должны обеспечивать простые для использования интерфейсы,

поддерживающие обсуждавшиеся выше вспомогательные функции:

определение и внедрение новых типов данных, операторов, методов

доступа и индексации, оценочных функций и т.д. Более того, должны

обеспечиваться не только новые средства разработки приложений, но

новые учебные материалы и средства проверки того, что новые

функциональные возможности позволяют производить прикладные

программы настолько же надежные и мощные как и сегодняшние

реляционные приложения.

Многие из этих комментариев применимы не только к сверхбольшим

ОР-базам данных и приложениям, но и к более мелким. Однако

сравнение задач конфигурирования, управления и написания методов

и приложений для этих типов баз данных похоже на сравнение

операций супертанкера и парома. Имеется сходство на уровне

базового набора функций, но многие вопросы, возникающие в

гигантских системах, отсутствуют или неуместны в системах

меньшего масштаба.

Наиболее очевидным различием является то, что параллелизм

абсолютно необходим в случае VLDB и является необязательным (или

даже вредным в связи с накладными расходами) для баз данных более

скромного размера. Другие различия связаны со сложностью

управления метаданными, операций обновления, операций архивации

и восстановления и т.д. Наконец, дополнительную сложность

вызывает потребность в расширении сферы оптимизации. Эта

потребность не ограничивается расширением набора способов оценки

альтернатив, что само по себе представляет принципиальную

проблему для разработчиков ОР-СУБД. Необходима создание

алгоритмов для новых методов на очень больших наборах новых типов

данных, разработка функций для оценки эффективности выполнения

этих новых методов, понимание того, какие ограничения существуют

при распараллеливании выполнения методов. За решение этих

вопросов главным образом отвечают те, кто проектирует и реализует

оптимизатор.

Объектная инфраструктура

Большие объекты. При использовании традиционных методов хранение в базе данных больших объектов (например, видео-клипов) может

привести к существенной деградации производительности системы по

причине слишком интенсивного использования таких ресурсов как

буфера и журналы. Истинная объектно-реляционная система должна

обеспечивать специальные средства для повышения эффективности

приложений, связанных с большими объектами, и минимизации их

влияния на системные ресурсы.

В DB2 поддерживаются три типа данных для хранения больших

объектов: BLOB для бинарных объектов, CLOB для символьных строк и

DBCLOB для строк, в которых используются двухбайтовые наборы

символов. Для каждого из этих типов данных можно хранить объекты

объемом до 2 Гбт. Когда большие объекты сохраняется в столбце

таблицы, то на самом деле столбец содержит "дескриптор" каждого

такого значения; сами же большие объекты хранятся вне таблицы.

Такой подход предотвращает влияние наличия больших объектов на

физическую кластеризацию таблицы, которая может уменьшить число

чтений страниц внешней памяти при просмотре таблицы. Опции

оператора CREATE TABLE позволяют управлять расположением больших

объектов на физическом носителе.

Подсистема восстановления DB2 дает возможность создателю таблицу выключать обычную журнализацию изменений столбцов с большими

объектами. При выключенной журнализации по отношению к таким

столбцам гарантируется согласованность транзакций, но столбец не

может участвовать в процедуре прямого восстановления (повторении

операций зафиксированных транзакций при восстановлении базы

данных от контрольной точки).

По причине большого размера крайне желательно минимизировать

число перемещений и копирований больших объектов. В среде DB2

прикладная программа может объявить переменную-"локатор", которая

представляет значение большого объекта, но реально его не

содержит. Содержимое локатора является спецификацией того, как

значение большого объекта может быть материализовано в случае

необходимости. Локатор может быть использован для представления

значения большого объекта в любом выражении SQL, и операции над

локаторами очень эффективны, поскольку при их выполнении

происходит работа с "предписаниями" по материализации, а не с

сами значениями больших объектов. Например, если LOC1 и LOC2

являются переменными-локаторами, то при вычислении выражения

LOC1 LOC2 выполняется конкатенация спецификаций, содержащихся

в этих переменных, а не самих значений. При использовании

локаторов прикладная программа может выполнить серию действий над

значением большого объекта, откладывая его материализацию до

последнего момента.

Часто требуется импортировать большой объект из файла в базу

данных или экспортировать большой объект из базы данных в файл.

DB2 дает возможность прикладным программам обмениваться

значениями больших объектов между базой данных и файлом без

перемещения значений через буфера программы. В программе может

быть объявлена переменная "ссылка на файл", которая содержит имя

нужного файла. Ссылка на файл может использоваться в операторах

SQL как входная или выходная переменная, представляющая

содержимое файла, которое интерпретируется как большой объект.

Совместно локаторы и ссылки на файл часто дают возможность

обработки больших объектов без их реального считывания в память

программы.

Объектные и постреляционные СУБД

Теоретически ОСУБД в состоянии моделировать объектно-реляционные (и чисто реляционные) базы данных и управлять ими. Зачем же тогда беспокоиться о более ограничительных моделях?

Объектные базы данных не вытеснили РСУБД в конце 80-х - начале 90-х, поскольку на ранней стадии существования они обеспечивали, по существу, лишь среду постоянного хранения для программ, написанных на языках Си++ и Smalltalk, а их API были ограничены привязкой к объектно-ориентированным языкам. Со временем ОСУБД "подросли", приобретя интерфейс SQL и средства разработки приложений. Но в течение того же времени производители РСУБД переписали свои системы для эффективного использования мультипроцессоров. В системах появились многопотоковость (multithreading) и распараллеливание выполнения запросов. Потеря соответствия (impedance mismatch) между множественными результатами реляционных запросов и ориентированным на записи процедурным программированием была компенсирована во многих средствах разработки, что снизило преимущества объектного моделирования данных в ОСУБД. Кроме того, в последних выпусках РСУБД и ОРСУБД в дополнение к обычным типам индексации, основанной на B-деревьях и хэшировании поддерживаются битовая индексация, R-деревья и другие виды индексов, играющие важную роль при организации хранилищ данных (datawarehousing) и управлении геопространственными данными. В этих СУБД теперь применяется оптимизация на основе оценок, а табличное пространство может быть разделено (фрагментировано) между устройствами и даже серверами.

Майкл Стоунбрейкер любит называть компанию "домом отставного программного обеспечения", возможно, по причине неудовольства тем, что его РСУБД Ingres стала относительно незаметной после ее приобретения этой компанией. В Ingres никогда не было реализовано собственное видение реляционной СУБД, расширенной объектными свойствами, хотя модули управления объектами и знаниями поставлялись в начале 90-х, и это представляло первую попытку приближения к ОРСУБД.
В частности, модуль управления объектами дает пользователям возможность расширения Ingres определяемыми ими типами и методами, хотя сложность Си-кода, требуемого для реализации, делает их практически неиспользуемыми. Но на самом деле характеристика CA, данная Соунбракером, неверна. Продукты Unicenter-TNG и ОСУБД Jasmine далеки от пенсионного возраста.

Другой широко обсуждаемой компанией является , недавно образованная путем слияния компаний O2 Technology, Unidata и Vmark. Система Unidata относится к классу РСУБД, поддерживающих ненормализованную реляционную модель данных (в частности, допускаются вложенные таблицы). Поддержка аналогичных возможностях в ОРСУБД за счет механизмов строчных типов или вложенных таблиц обеспечивает существенно большую масштабируемость. Кроме того, Ardent предлагает РСУБД UniVerse, близкую по подходу к Unidata, и ОСУБД O2. Вполне понятно, что Unidata и UniVerse не справятся с ОРСУБД, но система O2, рекламируемая на рынке как "универсальный объектный сервер", - это достаточно впечатляющий продукт.

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

Несмотря на такие достоинства ПРСУБД как сильная технология, стандартизованные интерфейсы, совместимость с реляционным подходом и наличие ряда впечатляющих приложений, сомнительно, чтобы эти системы смогли вытеснить РСУБД или ОРСУБД. Функциональных возможностей ПРСУБД недостаточно, чтобы потеснить занимающие твердые позиции Oracle, IBM и Informix. Распределенные объекты представляют более жизненную альтернативу.

Object Relational Reality Check

, July 1998
, a principal of , a consultancy specializing in database design and software development for Internet and decision-support applications
Оригинал статьи можно найти по адресу

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

Технологию объектно-реляционных баз данных нельзя считать устоявшейся, и, более того, она далеко не так развита, как обещалось. Первая значимая коммерческая ОРСУБД Illustra появилась в 1993 г., а в 1997 г. несколько ведущих компаний-поставщиков СУБД стали предлагать свои оъектно-реляционные продукты, но во всех них остаются большие дыры. В каждой из этих ОРСУБД (Oracle8, IBM DB2 Universal Database и Informix Universal Server) объектные расширения реляционной модели реализуются неполно и разными способами. Доступно лишь немного средств проектирования и разработки, пригодных для использования в объектно-реляционных средах, и рынок приложений, основанных на этом подходе, развивается медленно. В результате поставщики ОРСУБД переосмысляют свои маркетинговые и технологические стратегии в свете навеянного Internet бума в распределенных объектных вычислениях, а поставщики чистых РСУБД (такие как и ) принимают решение обойтись поддержкой объектов на основе промежуточного программного обеспечения (middleware), не входящего в состав СУБД.

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

Обработка запросов с использованием материализованных представлений

Чтобы расширить пространство поиска физического проекта материализованными представлениями, нам требуется не только расширить базисные средства выбора индексов, но также гарантировать, что подсистема обработки запросов может поддерживать материализованные представления. В особенности требуется решить две следующие проблемы:

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

Поддержка представлений: Система должна автоматически обновлять все необходимые материализованные представления при каждом обновлении базовых таблиц.

До сих пор наша работа над материализованными представлениями фокусировалась на проблеме преобразования запросов. В большинстве предыдущих работ по поводу преобразования запросов делалось несколько упрощающих предположений: запросы и представления только категории "проекция-селекция-соединение" (Project-Select-Join - PSJ), семантика множеств (а не мультимножеств), никакого знания ограничений (таких как ключи и внешние ключи), вычисление запросов на одном представлении. В настоящее время мы имеем работающий прототип системы преобразования запросов, который справляется с более широким классом запросов и представлений (проекция-селекция-соединение-группирование) с обычной семантикой SQL, использует знания о ключах и внешних ключах, берется за преобразования запросов на нескольких представлениях. Мультимножественная семантика SQL добавляет новое измерение в проблему преобразования запросов, поскольку мы должны быть уверены не только в получении всех требуемых строк, но и в том, что будет правильно учтен фактор дубликации.

Принятие во внимание знаний о ключах и внешних ключах оказалось очень важным, но также и поразительно сложным. Рассмотрим две таблицы - Orders и Customers, где таблица Orders содержит внешний ключ CustomerNo, в котором запрещены неопределенные значения и который ссылается на первичный ключ таблицы Customers.
Предположим, что имеется представление, получаемое (естественным) соединением Orders и Customers, и что задается запрос, адресуемый к таблице Orders. Без знаний о ключах и внешних ключах мы могли бы заключить, что запрос не может быть выполнен с применением представления. (Поскольку операция естественного соединения в языке SQL по определению отсекает строки с неопределенными значениями столбца соединения и устраняет в результате дубликаты. Прим. С.Кузнецова.) Принимая во внимание внешние ключи, мы можем заключить, что в представлении присутствуют все требуемые строки, но, возможно, без учета фактора дублирования. Для гарантирования того, что фактор дублирования учитывается корректно, мы должны принять во внимание, одним из столбцов соединения является первичный ключ.

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

Обсуждение

В заметке сделана попытка показать, что запросы с разделами GROUP BY и HAVING (GBH-запросы) и переменные с областью значений являются избыточными в языке SQL. Интересно заметить, что эти аспекты SQL относятся к числу тех, которые наиболее трудно изучаются, понимаются и правильно применяются. Если говорить конкретно о GBH-запросах, то кажется, что альтернативные формулировки часто бывают более предпочтительными. Рассмотрим еще раз запрос Q4 из первой части заметки.

Q4: Выдать номер каждой детали, поставляемой более чем одним поставщиком.

Вот формулировки этого запроса с GBH и без GBH:

SELECT SP.P# FROM SP GROUP BY SP.P# HAVING COUNT(*) > 1 ;

SELECT DISTINCT SP.P# FROM SP WHERE ( SELECT COUNT(*) FROM SP AS SPX WHERE SPX.P# = SP.P# ) > 1 ;

По мнению Дейта,

Вариант без GBH по крайней мере логически понятнее и проще чем вариант с GBH, поскольку в нем не используются дополнительные языковые конструкции (разделы GROUP BY и HAVING) Из исходной формулировки проблемы не видно, что именно группирование требуется для выражения запроса на SQL (и оно действительно не требуется) Далеко не очевидно, что нужен раздел HAVING, а не раздел WHERE

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

Конечно, нельзя отрицать, что вариант формулировки с GBH более короткий. Но если единственным преимуществом формулировок с GBH является краткость, то было бы лучше определять такие формулировки как сокращенную запись. Тогда, вероятно, не проявлялись бы отмеченные в заметке аномалии и реализация была бы проще. Замечание: следует упомянуть, что реляционный аналог разделов GROUP BY и HAVING языка SQL оператор SUMMARIZE определяется как сокращенная запись.

Наконец, необходимо отметить, что язык SQL содержит много других избыточностей (например, оператор EXISTS абсолютно избыточен). В результате большинство тривиальных запросов может быть выражено на языке SQL массой различных способов. Даже такой простой запрос как "Выдать имена поставщиков, которые поставляют деталь P2" можно выразить по меньшей мере восемью разными на вид способами. (И это при том условии, что используются только возможности SQL-86! Если применять новые возможности SQL-92, число допустимых формулировок значительно увеличится.)

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

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

В заключение заметим, что проблемы избыточности устранить непросто. Если в язык когда-либо была внедрена некоторая возможность, ее никогда уже нельзя удалить, иначе перестанут работать существующие программы. Вот почему так важно иметь правильный язык с самого начала. И в этом основная сложность разработки языка.

Обзор материала журнала "Data Base Programming and Design" - "Звезды десятилетия"

, Центр Информационных Технологий

В этом (1997) году исполняется десять лет одному из наиболее

популярных и авторитетных журналов в области баз данных "Data

Base Programming and Design". По этому поводу на журнала выпущена специальная, доступная только в

электронной форме подборка материалов. Среди них, по нашему

мнению, особый интерес представляет материал под названием

"Звезды десятилетия" ("Stars of the Decade"). Редакция попросила

своих ведущих авторов выделить наилучшие программные средства

управления базами данных, которые появились в последние десять

лет. Нам кажется, что краткий пересказ этих мнений будет

интересен нашим читателям.

Nagraj Alur

DataBase Associates

Contributing Editor, Client/Server Forum column (1993-96)

Неоспоримым лидером среди поставщиков реляционных систем

управления базами данных (РСУБД) для мейнфреймов была компания

IBM с DB2 в среде MVS. Особое влияние на широкое признание

системы оказал выпуск DB2/2 в апреле 1988 г. В этой версии

системы сосуществовали возможности поддержки оперативных

транзакционных приложений и приложений, ориентированных на

системы принятия решений.

Компания Sybase сыграла решающую роль во внедрении в сферу РСУБД

аппаратуры микропроцессоров и технологии открытых систем на

основе применения архитектуры "клиент-сервер". Используемая

комбинация низкостоимостных персональных компьютеров и

технологии открытых систем произвела сильное впечатление на

индустрию баз данных. Необходимо также отметить значение

PowerBuilder в развитии технологии "клиент-сервер" на уровне

рабочих групп за счет возможности быстрой разработки приложения и

обеспечения доступа к разнородным РСУБД.

Компании Microsoft и Intel сосредоточились на том, чтобы

обеспечить доминирование клиентских станций с Windows на рынке

настольных компьютеров и сделать возможным создание корпоративных

информационных систем на основе использования дешевых серверов NT

и SQL-сервера.
Агрессивная ценовая политика, разработка

популярных стандартов ODBC, ActiveX и OLE DB, наличие большого

числа независимых производителей программного обеспечения и

консультантов способствовали влиянию на информационные технологии

таких инициатив Microsoft как Wolfpack, Viper и Falcon.

Компания Oracle способствовала росту популярности РСУБД и

архитектуры "клиент-сервер" тем, что поддерживала наиболее

широкий диапазон аппаратных и программных платформ. В этом

отношении версия Oracle7 явилась существенной вехой в эволюции

РСУБД.

Значимость технологии универсальных серверов (Oracle и Informix)

и баз данных (IBM) пока еще не доказана, но полезность этих

продуктов будет горячо отстаиваться в близком будущем.

Joe Celko

Northern Lights Software

Contributing Editor on SQL column (1990-1992)

Наиболее важным продуктом является тот, о котором знает немного

людей: реализация SQL компании Britton-Lee, выполненная Лаурой

Йедвааб (Laura Yedwaab) и ее группой. Этот продукт первым

выдержал испытания на новых тогда тестах FIPS на предмет полного

соответствия стандарту SQL/89. Это событие было знаменательным,

поскольку многие производители утверждали о невозможности

добиться соответствия стандарту, а маленькая компания с группой

разработчиков из пяти человек смогла это сделать. В результате

крупные компании немедленно занялись стандартизацией и

тестированием.

Terry Moriarty

Spectrum Technology Group Inc.

Contributing Editor, Enterprise View column (1993-present)

Ни один из продуктов не удовлетворяет полностью потребности

управления и администрирования данных. Как это не печально, по

всей видимости ни один поставщик не понимает, что значит

управлять информацией как стратегическим бизнес-ресурсом. Имеется

много продуктов управления базами данных, но совсем мало решений

для управления данными.

Если бы потребовалось выделить наиболее существенный продукт

управления базами данных, то им был бы Microsoft Access; не

потому что он лучший, а потому что самый распространенный.


MS

Access получил широкое распространение как компонент пакета MS

Office Professional, пригодный для управления локальными данными.

Бизнес-пользователи стали более грамотными по отношению к

компьютерам после того, как поиграли со своими персональными

базами данных в среде Access.

Наиболее существенным вкладом последнего десятилетия я считаю

принятие и реализацию поставщиками стандарта ODBC. Без технологии

такого типа склады данных использовались бы менее успешно, чем

в настоящее время.

Patrick O'Neil

University of Massachusetts

Most recent DBPD feature: "Informix and Indexing: Data Warehouse

Support", February 1997

Более десяти лет тому назад IBM выпустила свои первые реляционные

продукты - SQL/DS для VM (1982) и DB2 для MVS (1983). Ingres была

доступна для пользователей с конца 70-х, и Oracle в

действительности подавил IBM на рынке, но нет сомнений, что

именно долговременная поддержка компанией IBM реляционной модели

(SQL в 1974 г., работающая System R в 1977 г.) ориентировала

пользователей на использование реляционных продуктов в начале

80-х.

Долгий период консолидации и постепенных улучшений длился до 1993

г., когда Майкл Стоунбрейкер (Michael Stonebraker) выпустил в

свет объектно-ориентированную систему Illustra (поглощенную

компанией Informix в 1995 г.) - первый продукт десятилетия

настолько же важный, как DB2. Новые концепции Illustra сильно

влияют на рождающийся стандарт SQL3, и большинство поставщиков

СУБД учитывает это в новых продуктах (DB2 version 2, Oracle8).

Через пять лет приложения, написанные на основе реляционных

продуктов без использования объектно-реляционных расширений будут

выглядеть странно.

David Plotkin

Longs Drug Stores

Contributing Editor, Desktop Database column (1993-1995)

Для линии малых систем поворотным пунктом стал продукт Approach,

первая персональная СУБД, сделавшая доступными для

непрограммистов в среде Windows надежные реляционные базы данных

(раньше, чем Microsoft Access). При применении Approach



реляционные свойства приложений определяются с помощью простых

средств моделирования; простые для использования средства

управления экраном, генерации отчетов, макросов и запросов на

основе форм доставляют удовольствие. Теперь в Approach (которой

теперь владеют IBM/Lotus) имеется язык программирования, на я

редко использую его, потому что могу выполнять свою работу без

потребности в написании кода.

На другом конце спектра продукт Rochade Repository компании R&O

(теперь часть компании Viasoft) был особо значимым для хранения

метаданных. Свой первый репозиторий я реализовал не на Rochade

(эта честь принадлежит DB Excel компании Reltech, теперь это

часть компании Platinum Technology), но Rochade-репозиторий было

определенно легче совершенствовать, расширять и сопровождать. В

Rochade используется база данных с объектными свойствами, которые

облегчают расширения. Используемая архитектура "клиент-сервер"

является очень гибкой, и, по моему мнению, интерфейс Windows

гораздо быстрее осваивается, чем интерфейсы других репозиториев.

Объектно-ориентированный язык программирования позволяет

добавлять дополнительные интерфейсы (например средства запросов

для случайных пользователей) и автоматизировать почти все.

Наконец, средство ADW CASE компании KnowledgeWare (теперь часть

компании Sterling) было еще одним потрясением. Когда я первый раз

увидел этот продукт (в 1987 г.), он работал в среде операционной

системы GEM компании Digital Research на PC. Интерфейс на основе

мыши и твердое следование методологии IE делали этот продукт

неоценимым для начинающих администраторов данных.

Tim Quinlan

Consultant

Most recent DBPD feature: "Time to Reengineer the DBA", March 1996

Десять лет назад наибольшее влияние оказывала СУБД DB2 для MVS:

версии 1.3 и 2.1 доказали, что реляционные базы данных готовы к

использованию в промышленных масштабах и пригодны для оперативной

обработки транзакций (OLTP). DB2 обеспечила доверие к реляционным



базам данных и заложила основу их использования за пределами

областей, связанных с поддержкой принятия решений. Многие из

свойств DB2 воспроизведены в других СУБД (хотя редко настолько

же элегантно); IBM остается лидером в области

высокопроизводительных СУБД, применяемых в OLTP-приложениях.

SQL-сервер компаний Sybase и Microsoft был следующим крупным

шагом вперед. Появление этого сервера популяризировало

архитектуру "клиент-сервер" и многие важные свойства, такие как

триггеры баз данных, хранимые процедуры, поддержку больших

двоичных объектов (BLOB'ов), которые стали стандартными в

сегодняшних развитых реляционных продуктах. SQL-сервер изменил

способ проектирования, разработки и реализации систем. Он изменил

набор платформ, на которых можно использовать готовые системы, и

прикладное программное обеспечение, используемое для их

разработки. Все основные поставщики продуктов баз данных

последовали этому примеру: SQL-сервер оказал наибольшее влияние

на рынок баз данных за последние десять лет.

Последним крупным шагом вперед было появление

объектно-реляционных баз данных, таких как UniSQL и Illustra. Но

именно приобретение Illustra компанией Informix с последующим

слиянием кода удалило барьер для наращивания возможностей

реляционных баз данных. Механизм DataBlade, возможности

определения пользователями функций, операторов, типов данных и

даже методов доступа являются основными достижениями.

Возможности переопределения неструктурированных типов данных для

использования в операторах языка SQL обратили всех поставщиков

реляционных продуктов в сторону объектно-реляционных

универсальных серверов. Все это существенно изменит рынок баз

данных.

Что касается компании Oracle, то ее размер и возможность внедрить

в свои продукты почти любые возможности позволяет компании быть

несомненным лидером на рынке, которого другие поставщики хотели

бы вытеснить, но не следовать его техническим решениям.

Alan Simon

CoreTech Consulting Group

Most recent DBPD feature: "Beyond the Warehouse", Industry in




Focus Issue: December 1996

Наибольшее влияние за последнее десятилетие оказал продукт

Oracle7. Этим выпуском компания Oracle окончательно убедила

специалистов корпораций в области информационных технологий в

том, что реляционные СУБД пригодны для разработки масштабных

приложений. Хотя некоторые люди считают, что у Oracle отсутствует

собственная твердая позиция, компания является лидером на рынке с

феноменальным ростом числа продаж.

Doug Thomson

Pragmatek Consulting Group

Contributing Editor, Corporate Developer column (1995-present)

Насколько иной была индустрия баз данных десять лет назад!

Возникали неожиданные споры по поводу реляционной теории, десятки

парадигм и архитектур пытались пробиться в мир. Компания Oracle

была одной из немногих, которые руководствовались четкой и

перспективной точкой зрения: мобильная, основанная на SQL

реляционная система управления базами данных. У Cullinet,

Software AG и Progress не было реляционных продуктов; продукты

IBM и Applied Data Research не обладали мобильностью; в Ingres не

поддерживался SQL; Sybase и Informix выпустили свои успешные

продукты немного позже.

Бывшая восходящей звездой в мире СУБД, компания Cullinet Software

была обрушена волной реляционных систем. Горсточка питомцев

Cullinet применила полученные болезненные уроки к созданию

средства разработки приложений PowerBuilder, которое не было

первым, основанным на Windows и ориентированным на архитектуру

"клиент-сервер", но к которому впервые для продуктов этого класса

были применены эффективные методы продаж.

Около двух лет назад, когда индустрия СУБД становилась несколько

скучной по причине прочности позиций Oracle и ошибок Sybase,

появилась Illustra, претендующая на долю умов, если не на долю

рынка. Теперь, после интеграции технологии DataBlade Illustra с

технологией Informix (по крайней мере, на бумаге) конкуренция

снова обостряется.

Jay-Louise Weldon

SHL Systemhouse

Most recent DBPD feature: "Choosing Tools for Multidimensional




Data", February 1996

Acess и ODBC компании Microsoft позволили использовать

реляционную технологию на настольных компьютерах с возможностью

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

Distributed Option компании Oracle дал возможность прозрачного

доступа к данным. Replication Server компании Sybase позволил

поддерживать синхронные копии данных в удаленных компьютерах.

ERwin явился простым и элегантным CASE-средством для

использования на настольном компьютере. Illustra стала первой

СУБД следующего поколения.

Paul Winsberg

DataBase Associates

Client/Server Forum column (1993-1996)

Продукт Excelerator компании Index Technology был первым в

прошедшем десятилетии средством графического проектирования баз

данных на настольных компьютерах. Хотя Excelerator прекратил свое

существование к 1990 г., он породил целое поколение средств

моделирования данных, таких как KnowledgeWare, System Architect и

ERwin.

Важным продуктом был также Information Engineering Workbench

(IEW) компании Texas Instruments. Он был первым, позволяющим

генерировать 100% приложения, включая код и структуры данных.

Парадоксально, что IEW продемонстрировал как мощность

управляемого моделью подхода, так и его ограничения.

Список важных средств разработки был бы не полон без PowerBuilder

компании Powersoft. PowerBuilder подготовил путь для поколения

средств разработки, основанных на архитектуре "клиент-сервер" и

реляционных базах данных. Хотя Visual Basic занимал существенно

лучшую позицию на рынке, PowerBuilder был в течение нескольких

лет технологическим и поэтому оказал большее влияние.

В области СУБД ранние выпуски Sybase ввели в использование

хранимые процедуры, триггеры и доступ в стиле "клиент-сервер".

Эти технологии теперь доминируют на рынке, несмотря на то, что

Sabase переживает не самые счастливые времена.

Casey Young

RYC Inc./International DB2 Users Group (IDUG)

Most recent DBPD feature: "Seeking the Promised Land", June 1995"



Я приверженец DB2. Я работал с этим продуктом в течение 13 лет.

До 1997 г. DB2 не отличалась высокой производительностью. Но в

последующих выпусках ситуация изменилась: неожиданно стало

возможно рассматривать DB2 как реальную СУБД. В 1992 г. компания

UPS и др. прогоняли по 200000 транзакций в день над терабайтными

базами данных (существенное число для конца 80-х). К концу 1997

г. станут возможными терабайтные таблицы. DB2 для OS/390 стала

сервером с предельными возможностями.

Но взгляд на DB2 для OS/390 дает только половину картины.

Функциональные возможности DB2 Universal Database по-настоящему

не ограничены. В то время как Informix и Oracle ведут публичные

политические битвы вокруг названий и сотрудников, IBM выносит на

рынок объектные средства, расширители, обеспечивающие работу с

графикой, видео, текстами и т.д.

Единственное ограничение для использования DB2 - психологический

барьер у пользователей. Это наиболее существенный продукт

прошедшего десятилетия.

Обзор статьи "Bringing Object Relational Down To Earth"

, vol.10, N 6, June 1997

, Won Kim

, Центр Информационных Технологий

Существует путаница вокруг понятия универсального сервера баз

данных, и стоит разобраться, что же свойственно истинной

объектно-реляционной системе.

Эра объектно-реляционной технологии баз данных началась в 1992 г.

с выпуском системы баз данных UniSQL/X, сочетающей черты

реляционной и объектно-ориентированной системы. Вскоре после

этого компания Hewlett-Packard выпустила систему OpenOOB (позднее

переименованную в Odapter), представляющую собой объектный слой

над реляционной системой AllBase. В 1993 г. компания Montana

Systems (переименованная впоследствии в Illustra) начала поставки

первой коммерческой версии объектно-реляционной системы Postgres,

в реализации которой наибольшее внимание уделялось управлению

мультимедийными данными.

Эти три производителя вскоре привлекли внимание аналитиков прессы

и индустрии. Компания Informix поглотила Illustra Technology

(интересуясь главным образом технологией DataBlade для расширения

возможностей баз данных). Сегодня такие гиганты как Oracle,

Informix, Sybase, IBM и Microsoft имеют объявленные планы

преобразования своих реляционных продуктов в объектно-реляционные

к концу 1997 г. В результате на рынке объектно-реляционных систем

царствуют сомнения. Для этого есть несколько причин.

Во-первых, в результате поглощения компанией Informix технологии

Illustra и последующей маркетинговой активности в общей

технологии объектно-реляционных систем чрезмерный вес был придан

роли расширяемости типов данных. Во-вторых, озадачивает

отсутствие меры "объектно-реляционной полноты системы", т.е.

уровня поддержки возможностей объектно-реляционного моделирования

и управления данными.

В статье предлагается практическая метрика объектно-реляционной

полноты; эта метрика может применяться для определения того,

насколько продукт является истинным объектно-реляционным. Метрика

состоит из семи основных категорий, в каждой из которых

выделяются "наиболее важные" и "наименее важные" свойства. В

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

критически важные сервисы, объектно-ориентированная

вычислительная модель, требования эффективности и

масштабируемости, инструментальные средства, а также то, что

можно было бы назвать "использованием мощности" (harnessing the

power).



Модель данных

Базовая объектная модель (Core Object Modell), определенная

Object Management Group (OMG), включает реляционную модель данных

наряду с базовыми концепциями объектно-ориентированного

моделирования, свойственными объектно-ориентированным языкам

программирования. Модель OMG следовало бы иметь в качестве

стандарта. Объектная модель формирующегося стандарта SQL3 кое в

чем отличается от модели OMG, но обсуждаемые здесь концепции в

равной мере применимы и к SQL3.

Ниже используется аббревиатура RDB для обозначения реляционных

систем, ORDB - для обозначения объектно-реляционных систем, OR -

для обозначения объектно-реляционного подхода, OODB - для

обозначения объектно-ориентированных систем.

Основные модельные концепции OMG состоят в следующем:

Класс, экземпляр, атрибут, метод и ограничения целостности

В OR-полной ORDB модель данных должна включать понятие класса

(или типа), обладающего атрибутами, методами и ограничениями

целостности. Класс служит шаблоном для экземпляров, которые могут

создавать с разделением атрибутов и методов класса. Доменом

атрибута может быть примитивный тип данных, абстрактный тип

данных или ссылка на класс. Атрибут может содержать атомарные или

множественные значения; в последнем случае может иметь ноль или

много значений. Метод - это функция, применяемая к каждому

экземпляру класса и производящая вычисления на основе значений

его атрибутов. Ограничения целостности включают примитивные

ограничения, поддерживаемые RDB, такие как спецификация

допустимости неопределенных значений атрибута, ограничение

уникальности экземпляров класса и ограничение первичного ключа на



одном или нескольких атрибутах класса.

Уникальная идентифицируемость экземпляра

Экземпляр класса обладает уникальным и неизменным объектным

идентификатором (OID). Пользователь должен иметь возможность

запросить выборку экземпляра по его OID.

Инкапсуляция

Пользователь должен иметь возможность написать метод и

присоединить его к классу. К атрибуту класса можно относиться как

к специальному методу с интерфейсом, включающим только методы

чтения и изменения значения. Язык написания методов должен быть

комбинацией ObjectSQL и основного языка. Основной язык может

являться полным языком программирования, таким как Си или Си++,

или может быть ограниченным языком, подобным тем, на которых в

RDB пишутся хранимые процедуры.

Иерархия множественного наследования классов и разрешение

конфликтов имен

Пользователь должен иметь возможность создания класса как

подкласса одного или нескольких существующих классов. Подкласс

наследует спецификации атрибутов и методов всех своих

суперклассов (множественное наследование). Если два или более

суперкласса содержат атрибут или метод с одним и тем же именем,

но с разными спецификациями, возникает "конфликт имен". Хотя по

этой причине применение множественного наследования является

проблематичным, этот подход остается общепринятым стандартом и

должен поддерживаться в ORDB.

Ссылка на класс как домен атрибута (объектные ссылки на основе

OID)

Если домен атрибута является ссылкой на класс, система в

действительности хранит в атрибуте OID экземпляра класса, на

который имеется ссылка. Обычно в качестве OID используются

логические идентификаторы объектов, а не их физические адреса.

Поэтому применение OID'ов в ORDB (и по этим же причинам в OODB)

не требует возврата к физическим указателям иерархических и

сетевых баз данных.

Атрибуты с множественными значениями

Атрибут с множественным значением может хранить ноль или более

значений, и индивидуальные значения могут выбираться и изменяться

пользователем.


Атрибут с множественным значением может хранить

обычное множество (без элементов-дубликатов), мультимножество (с

потенциально возможными дубликатами) или последовательность

(упорядоченное мультимножество).

Абстрактные типы данных (Abstract Data Types - ADT)

ADT конструируется путем комбинирования примитивных типов данных.

Простым примером является тип данных "точка", который

конструируется путем комбинирования координат x и y, каждая из

которых представляется типом данных чисел с плавающей точкой. ADT

представляет собой специальный случай ссылки на класс и

примитивного алфавитно-цифрового типа данных. Подобно последнему,

значение ADT прямо хранится в атрибуте. Подобно ссылке на класс,

это непримитивный тип данных. Более того, как и в случае классов,

пользователи могут организовать ADT в виде иерархии классов.

Поскольку значение ADT прямо хранится в атрибуте, оно не может

совместно использоваться несколькими экземплярами.

Следующие модельные понятия OMG являются менее важными:

Иерархия наследования классов как домен

Семантика включения множеств, связанная с иерархией наследования

классов, предполагает, что экземпляры подкласса логически

принадлежат его суперклассу. Если домен атрибута специфицирован

как ссылка на класс, то этот домен может включать не только

ссылки на экземпляры указанного класса, но также и ссылки на все

экземпляры классов, являющихся прямыми или косвенными

наследниками данного класса.

Атрибуты и методы класса

Понятно, что экземпляр класса - это объект. Но следует ли

относиться как к объекту к самому классу? Ответ - "да". При

реализации этой идеи пользователи могут специфицировать атрибуты

и методы самого класса, а не только те, которые применимы к его

экземплярам. Атрибут класса может хранить значения, описывающие

класс или всю совокупность его экземпляров; метод класса

применяется к самому классу-объекту. Важными видами использования

атрибутов (и методов) класса являются моделирование агрегатных



свойств всех его экземпляров (например, средний вес автомобиля);

хранение значения, общего для всех экземпляров класса (например,

число колес у автомобиля); спецификация значения атрибута

экземпляра по умолчанию.

Язык запросов (ObjectSQL)

В ORDB должны поддерживаться ObjectSQL (язык баз данных с

минимальными расширениями стандарта реляционного языка SQL) и

соответствующие API (вызовы функций). Расширения SQL необходимы

для чтения и модификации объектов, определяемых и создаваемых на

основе перечисленных выше возможностей объектного моделирования.

Если пользователь не нуждается в использовании возможностей

объектного моделирования базы данных, должен использоваться SQL.

Относительно стандарта ObjectSQL имеются два предложения: SQL3 и

Object Query Language (OQL). Предпринимаются усилия по слиянию

этих двух языков в единый международный стандарт. Стандарт SQL3,

разрабатываемый комитетом ANSI X3H4, включает объектные

расширения стандарта RDB SQL-92. OQL, возникший в результате

усилий Object Data Management Group (ODMG) по стандартизации

языков доступа к объектным базам данных, пока еще не полностью

совместим с SQL3.



Основные свойства ObjectSQL

SQL-92

Поскольку текущим стандартом SQL является спецификация SQL-92,

ObjectSQL для ORDB должен начинаться с SQL-92 и содержать

расширенные средства запросов, соответствующие возможностям

объектного моделирования, которые пользователь может применять

при проектировании базы данных. Фундаментальные возможности

стандартного SQL включают запросы из одной таблицы, соединения

нескольких таблиц, вложенные подзапросы, запросы с GROUP BY,

HAVING и ORDER BY и запросы, включающие операции

объединения/вычитания/пересечения результатов запросов.

Запросы с вложенными объектами

Если пользователь создает класс (класс-1) с атрибутом, доменом

которого является ссылка на другой класс (класс-2), и создает

экземпляры этих классов, система будет хранить OID экземпляра

класса-2 в атрибуте класса-1, связывая тем самым экземпляр



класса-1 с экземпляром класса-2. Пользователь должен иметь

возможность выдавать запросы выборки экземпляров класса-1 на

основе условий поиска на экземплярах класса-2 или же запросы

выборки экземпляров класса-2, привязанных к экземплярам класса-1

(удовлетворяющим условиям поиска на экземплярах класса-1).

Конструкция запроса, называемая "выражением пути" ("path

expression"), может позволить пользователю специфицировать

условия поиска на последовательности классов, связанных через

домены атрибутов.

Запросы и атрибуты с множественными значениями

Если пользователь определяет атрибут с множественными значениями

и заносит в него набор значений, то этот пользователь должен

иметь возможность выбирать или изменять любой индивидуальный

элемент множества и любое его подмножество. ObjectSQL должен

обеспечивать соответствующие средства запросов. Хорошим базисом

для этого является конструкция "порождаемой таблицы" ("derived

table") языка SQL-92, но в настоящее время в SQL-92 отсутствуют

полные возможности манипулирования элементами множеств.

Запросы с методами/функциями в предикатах поиска

Пользователь должен иметь возможность использовать вызов метода в

любом месте запроса, где может содержаться вызов функции или

ссылка на атрибут. Система должна загружать и выполнять метод и

возвращать результат для использования при дальнейшем выполнении

запроса.

Запросы и абстрактные типы данных

Пользователь должен иметь возможность использовать в условии

поиска любой атрибут вне зависимости от вида его домена. В

частности, доменом может являться ADT.

Представления

"Представление" ("view") - это подмножество базы данных,

удовлетворяющее определенным пользователем условиям; содержимое

представления создается при выполнении соответствующего запроса.

В RDB представление логически эквивалентно таблице. В ORDB

представление не являются логическим эквивалентом класса, хотя

нужны по тем же причинам, что и в RDB.


Должна иметься возможность

определения представлений с условиями, включающими объектные

расширения.

Менее важные свойства ObjectSQL

Запросы и иерархия наследования

Из семантики включения следует, что запрос, адресуемый к

некоторому классу, может затрагивать все экземпляры этого класса

или же все экземпляры классов-наследников. Пользователь должен

иметь возможность специфицировать желаемый результат. Более того,

при формулировке и выполнении запроса часто бывает полезно

исключить некоторые классы иерархии.

Критически важные сервисы

Объектные расширения реляционной модели вызывают далеко идущие

последствия в области архитектуры баз данных. При объектных

расширениях RDB требуется добавление новых компонентах и

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

факт, что запрос ObjectSQL может включать в своем условии поиска

выражение пути, требует соответствующих расширений функций

оптимизатора запросов. Поскольку пользователи могут требовать

выборку объектов по их OID'ам, система должна поддерживать

хэш-таблицу для отображения OID'ов в физические адреса объектов.

Из-за того, что пользователи могут пожелать совместно

использовать большие документы как объекты, авторизация доступа

должна производиться на уровне объектов, а не на уровне атрибутов

или таблиц, как это делается в RDB. Далее перечисляются некоторые

требуемые возможности расширенных RDB. Не обсуждаются такие

службы как восстановление после сбоев, репликация, устойчивость к

сбоям, поскольку они не связаны с объектными расширениями. Однако

автор считает, что возможности восстановления относятся к

основным, а службы, обеспечивающие репликацию и устойчивость к

сбоям, являются менее важными.



Первичные возможности: RDB, расширенная до ORDB

Автоматическая оптимизация запросов и обработка запросов

В оптимизаторе запросов ORDB должны использоваться все ключевые

методы, внедренные в оптимизаторы запросов RDB, включая генерацию

всех разумных планов выполнения запроса, выбор оптимального плана



на основе оценки ожидаемой стоимости выполнения запроса,

использование методов доступа (индексов и сортировки), применение

алгоритмов вложенных циклов и сортировки со слияниями для

выполнения соединений, использование статистической информации

базы данных для проведения оценок.

Запрос, содержащий выражение пути, часто выполняется наилучшим

образом при прямом применении метода поиска в глубину по

последовательным OID'ам, указывающим на объекты. Другими словами,

ORDB не должна стремиться обрабатывать запрос с выражением пути с

использованием традиционных методов вложенных циклов или

сортировки со слиянием. Поэтому оптимизатор запросов RDB должен

быть расширен для обработки таких запросов. Кроме того, в ORDB

должен быть реализован механизм хранения и доступа к значениям

атрибута с множественными значениями.

В клиент-серверной архитектуре метод может выполняться на стороне

клиента или на стороне сервера (или и там, и там). Оптимизатор

запросов ORDB должен генерировать план выполнения запроса,

минимизирующий пересылку данных между клиентом и сервером при

выполнении запроса, включающего вызов метода. Очень трудно

разработать оптимизатор запросов, автоматически оценивающий

селективность условия поиска (отношение числа объектов,

удовлетворяющих условию поиска, к общему числу объектов в

пространстве поиска запроса), если в него входит вызов метода.

Как минимум, оптимизатор запросов должен уметь минимизировать

объем данных, выбираемых из базы данных, путем установки

приоритетов условий поиска; при этом условия с вызовом метода

имеют высший приоритет.

Индексация на абстрактных типах данных

RDB позволяют пользователям создавать индексы, дающие возможность

оптимизатору запросов ограничить до минимума пространство поиска

базы данных. Для организации этих индексов используется структура

B-дерева. Но индексы использовались только для алфавитно-цифровых

типов данных. Важной задачей является расширения концепции

индексирования для атрибутов, доменами которых являются ADT.



Широко известны индексные структуры, такие как R-деревья,

файлы-решетки (grid files) и k-d деревья, применяемые для

индексации пространственных данных (например, треугольников или

линий).

Управление параллельным доступом

В ORDB должны полностью использоваться все методы, употребляемые

в RDB, включая двухфазные блокировки, протоколы установки и

снятия блокировок, гранулированные блокировки, иерархические

блокировки, логические и физические блокировки и режимы

блокировок. Объектные расширения требуют некоторых добавок. Для

поддержки запросов с иерархией наследования классов, динамической

эволюцией этой иерархии требуются расширения техники управления

параллельным доступом на основе блокировок. Простым решением,

например, было бы блокирование всей грозди классов, растущей от

данного класса, для того, чтобы избежать некоторых нежелательных

ситуаций. Тот факт, что пользователь ORDB может использовать OID

для доступа к одному объекту, означает, что объект, а не страница

дискового пространства или класс должен быть наименьшей единицей

блокировки в ORDB.

Авторизация

В ORDB должен поддерживаться полный механизм авторизации,

поддерживаемый в RDB, включая авторизацию на уровне атрибута,

класса или представления; рекурсивную передачу и изъятие

привилегий доступа; передачу привилегий индивидуальным

пользователям, группам и сразу всем; авторизацию, привязанную к

ресурсам и т.д.

Объектные расширения вызывают добавление авторизации для

выполнения методов и авторизации для одного объекта. Именно

объект должен быть наименьшей единицей авторизации в ORDB.

Триггеры

Триггеры настолько же важны в ORDB, как в RDB. Но объектные

расширения не требуют существенных добавок, кроме как вызова

методов при выполнении действия триггера.

Хранимые процедуры

В ORDB методы присоединяются к конкретным классам и наследуются

подклассами. Методы могут выполняться как клиентом, так и

сервером. Хранимые процедуры настолько же важны в ORDB, как и в

RDB. В RDB хранимая процедура не присоединяется к какой-либо



таблице и поэтому не наследуется одной таблицей от другой. Но в

ORDB хранимая процедура может рассматриваться как метод сервера,

присоединенный к базе данных целиком, а не к какому-либо классу.

Динамическая эволюция схемы

RDB позволяют пользователям динамически изменять схему базы

данных; эти изменения обычно ограничены созданием и уничтожением

таблицы и добавлением и уничтожением атрибута. В ORDB схема имеет

больше составляющих, чем в RDB, и поэтому большее число элементов

схемы может динамически изменяться. Расширения включают

добавление метода класса и уничтожение метода, добавление и

уничтожение связи суперкласс/подкласс и даже изменение домена

атрибута.

Менее важные возможности: RDB, расширенная до ORDB

Мандаторная безопасность

Поддержка мандаторной безопасности всегда была важным вопросом

для пользователей систем баз данных правительственных и военных

учреждений. Внедрение объектных расширений усложняет эту задачу.

Дополнительные трудности связаны главным образом с использованием

методов и OID'ов.



Вычислительная модель

Многие приложения, такие как автоматизированные анализ,

проектирование, моделирование и тестирование, могут выполнять

операции с большими объемами данных в памяти. Эти приложения

управляют большим числом объектов и должны выполнять обширные

вычисления очень быстро, поэтому объекты должны находиться в

памяти и быть заранее скомпонованными. OODB проектируются с

учетом требования производительности, нужной таким приложениям,

при дополнительном предположении, что сами приложения написаны на

объектно-ориентированном языке. Для поддержки быстрого

навигационного доступа к объектам в основной памяти OODB

обеспечивают возможность автоматического управления большим

числом объектов в памяти (это называется "жизненным кэшем" или

"пулом объектных буферов"). OODB автоматически преобразуют

форматы хранения объектов из формата базы данных в формат памяти,

при загрузке в память преобразуют хранимые в объектах OID'ы в



указатели по памяти и при окончании транзакции выталкивают в базу

данных объекты, измененные в памяти. Опасность для приложений,

связанная с использованием указателей по памяти, может быть

сведена к минимуму за счет применения техники косвенных

указателей на описатели объектов.

RDB не поддерживают преобразование указателей и кэширование.

Поэтому приложения RDB использовать явные запросы с соединением

или хотя бы направленные к одной таблице для эмуляции простой

навигации объектов. Более того, приложения RDB должны также

отправлять измененные записи по одной в базу данных через

интерфейс RDB.

В ObjectSQL запросы и вызовы функций API могут использоваться в

комбинации. Запрос ObjectSQL может использоваться для загрузки

объектов в жизненный кэш; последующие вызовы API могут загрузить

дополнительные объекты, на которые имеются ссылки из объектов,

уже находящихся в кэше. При этом преобразование формата объектов,

преобразование указателей, передача объектов из базы данных в

кэш, сборка мусора и перемещение объектов из кэша в базу данных

должны выполняться автоматически. Оператор End Transaction

автоматически вытолкнет измененные объекты в базу данных.



Производительность и масштабируемость

ORDB должны быть нацелены на те сегменты рынка баз данных, в

которых чистые RDB не справляются с трудностями моделирования

сложных данных и управления мультимедийными данными, а также на

те сегменты, потребностям которых не могут удовлетворить OODB по

причине плохой масштабируемости и недостаточной развитости

критически важных служб.

Производительность системы баз данных, в конечном счете,

определяет ее возможный успех и поэтому требования высокой

производительности являются первичными. По отношению к ORDB

требования производительности выглядят следующим образом:

При выполнении чисто реляционных операций производительность

ORDB должна быть совместимой (с возможностью отклонения в

пределах 20 процентов) с производительностью чистых RDB

При выполнении навигационного доступа к базе данных на основе



OID или при навигации в памяти на основе указателей

производительность должна быть совместимой (с возможностью

отклонения в пределах 20 процентов) с производительностью OODB

Должна удовлетворяться возможность доступа к базам данных на

основе объектных расширений SQL (выражения пути, атрибуты со

значениями абстрактных типов, методы, определяемые пользователями

функции и иерархия наследования).

Масштабируемость тесно связана с производительностью;

производительность (пропускная способность и/или время отклика)

сервера баз данных должна соответствующим образом возрастать при

добавлении дисков и процессоров. Для поддержки больших баз данных

и большого числа пользователей ORDB должны соответствовать уровню

масштабируемости, достигнутому в современных RDB. Основные RDB

основываются теперь на трехзвенной архитектуре "клиент-сервер" и

для поддержки большого числа пользователей связываются с

мониторами транзакций (Tuxedo, Encina, TopEnd). Для увеличения

пропускной способности RDB запускаются на симметричных

мультипроцессорах (SMP), кластерах и даже массивно параллельных

процессорах (MPP). Кроме того, в RDB используются методы

распараллеливания, такие как архитектура множественных серверных

процессов (в которой каждый процесс управляет несколькими

нитями), асинхронные обмены с дисками, параллельный ввод/вывод,

распараллеливание выполнения запросов, распараллеливание

вспомогательных утилит (построения индексов, архивирование,

восстановление, сжатие базы данных, обновление статистики базы

данных, массовая загрузка).

Все эти методы повышения уровня масштабируемости важны и должны

использоваться и в ORDB. Однако, поскольку нельзя внедрить все

сразу, полезно классифицировать методы на первичные и вторичные.

(Поддержка MPP может не быть необходимой по причине

преимущественного использования в настоящее время технологий SMP

и кластеров.)

Первичные требования (для масштабируемости):

Интеграция с трехзвенным промежуточным программным обеспечением



Поддержка SMP с параллельным выполнением нескольких запросов

(без обеспечения распараллеливания индивидуальных запросов).

Вторичные требования (для масштабируемости):

Асинхронные обмены с дисками

Архитектура множественных серверных процессов

Параллельные обмены с дисками

Поддержка кластеров

Распараллеливание выполнения утилит

Распараллеливание выполнения индивидуальных запросов



Инструментальные средства баз данных

Пользователи RDB осознают потребность в инструментальных

средствах, выходящих за пределы непосредственных возможностей

сервера баз данных с его интерфейсами уровня SQL и API, для

поддержки цикла разработки приложений. Эти средства включают

следующее:

Средства администрирования базы данных, настройки

производительности и отслеживания использования ресурсов

Прекомпиляторы операторов SQL, встроенных в языки

программирования

Процессор интерактивного SQL или графический генератор запросов

для построения, редактирования и просмотра результатов запросов

Графические средства проектирования и просмотра для анализа и

редактирования схемы базы данных

Средства разработки категории 4GL для быстрой разработки

приложений, обладающих обычно графическим или ориентированным на

формы пользовательским интерфейсом.

Вообще говоря, средства для ORDB должны обладать расширенной

функциональностью, в которой учитываются расширения, присущие

объектному моделированию. В случае отсутствия средств,

специфических для ORDB, в самом крайнем случае ORDB должна иметь

интерфейсную связь с популярными продуктами RDB сторонних

компаний, в которых учитываются возможности объектного

моделирования.

Далее приводится сводка необходимых объектных расширений

инструментальных средств RDB. К наиболее важным возможностям

объектного моделирования с точки зрения пользователей относятся

атрибуты с множественными значениями, ADT и вложенные объекты;

иерархия наследования и методы не столь важны. Поскольку

инструментальные средства баз данных стали составной частью среды



разработки приложений, большинство этих возможностей относится к

первичной категории.



Первичные возможности инструментальных средств баз данных

Браузер/дизайнер базы данных должен позволять пользователям

редактировать и просматривать схему ORDB с учетом иерархии

наследования классов; иерархии вложенности классов на основе

атрибутов, домены которых есть ссылки на другие классы; атрибутов

с множественными значениями; методов и атрибутов со значениями

абстрактных типов данных.

Генератор запросов должен позволять пользователям конструировать

объектные расширения SQL и просматривать результаты запросов,

возвращающих атрибуты с множественными значениями, атрибуты со

значениями абстрактных типов, вложенные объекты и экземпляры из

иерархии наследования классов.

Средство разработки 4GL должно позволять пользователям

проектировать экраны для работы с атрибутами со множественными

значениями, атрибутами со значениями абстрактных типов и

вложенными объектами.

Средства администрирования базы данных должно быть расширено так,

чтобы, по меньшей мере, можно было распознавать планы выполнения

запросов с выражениями пути, методами, иерархией наследования;

кроме того, необходимы средства отслеживания ресурсов жизненного

кэша.

Разработанный компаниями Microsoft и Apple стандарт ODBC

используется как интерфейс RDB для разнообразных приложений,

выполняемых на PC. Если потребуется изменить эти приложения в

расчете на использование объектных расширений ORDB,

соответствующие расширения будут нужны и в ODBC.

Сегодня средства просмотра и публикации Web внесли существенные

изменения в среду разработки приложений. Эти изменения могут

устранить потребность в некоторых средствах, являющихся частью

традиционной среды разработки приложений.



Использование мощности

Объектные расширения в ORDB дают пользователям баз данных по

меньшей мере две важных возможности, выходящих за пределы

моделирования и манипулирования данными, - расширяемость базы

данных и интеграция неоднородных баз данных.


Средства расширения

баз данных были широко оглашены под названиями DataBlades,

Database Extenders и Data Catridges. Об интеграции разнородных

баз данных говорят меньше, но эта тема также очень важна.

Однако, поскольку обе возможности лежат за пределами

ответственности сервера ORDB, их можно рассматривать как

вторичные.



Вторичные возможности "использования мощности"

Расширяемость баз данных

Тема расширяемости баз данных была настолько раскручена

компаниями Illustra и Informix, что некоторые люди полагают

добавление к RDB DataBlades и других "расширителей" превращает

реляционную систему в объектно-реляционную. Конечно, добавление

средств DataBlades к серверу баз данных - это совсем неплохо. Но

не следует забывать о том, что ORDB должна обеспечивать описанные

выше возможности моделирования и управления и что DataBlades

относятся к категории вторичных возможностей, делающих ORDB еще

более мощной и полезной.

В целом, расширяемость базы данных означает возможность добавлять

любые новые возможности (например, алгоритмы обработки запросов,

новые режимы блокировок, новые методы доступа) к коммерческому

серверу баз данных. Однако для практических целей расширяемость в

действительности включает возможность пользователей (не

производителей) добавлять новые модули управления данными, типы

данных (классы) и операции (методы). Новый модуль управления

данными может быть источником данных стороннего поставщика

(графической или текстовой информации) или механизмом управления

источником данных (для распознавания образов или полнотекстового

поиска). Целью расширения базы данных является обеспечение

использования всех возможностей сервера базы данных (включая

обработку запросов и блокировки) при управление доступными

пользователям новыми данными.

Возможность добавления новых типов данных и операций - это всего

лишь логическое следствие парадигмы объектной ориентации, которая

предполагает разрешение создания новых классов с атрибутами и



методами, наследуемыми от существующих классов. Поэтому

практическая важность расширяемости состоит не только в

обеспечении возможности добавления на уровне пользователя новых

модулей управления данными и новых типов данных, но также в

доступности развитой библиотеки функций для конкретных типов

данных, обеспечиваемой не пользователями, а производителями.

Функции, привязываемые к некоторому типу данных, можно

подразделить на "прикладные функции" и "методы доступа".

Прикладные функции выполняют логику приложения с данными,

выбранными из базы данных; функции-методы доступа производят

хранение, поиск и поддержку данных в базе данных.

Прикладные функции представляют собой разумные и полезные

средства, которые разработчикам приложений следует добавлять к

поставляемым производителями библиотекам. Хотя добавлять

некоторые типы методов доступа (например, методы индексирования

для полнотекстового поиска) могут и пользователи, обычно трудно,

если не невозможно добавлять методы доступа для произвольных

типов данных.

Например, представим себе, что пользователь хочет добавить к

серверу ORDB метод индексации, основанный на R-дереве, для

поддержки геометрических данных. Каким образом после этого

оптимизатор запросов ORDB распознает, что такой индекс теперь

существует? Даже если оптимизатор сможет узнать об этом, как он

сможет оценить селективность индекса при оптимизации

геометрического запроса? Как, в конце концов, менеджер транзакций

будет выполнять функции восстановления и синхронизации

параллельного доступа по отношению к страницам R-дерева?

Интеграция неоднородных баз данных

По определению модель ORDB является комбинацией реляционной

модели данных и объектной модели. Объектная модель включает

ключевые модельные концепции, которые использовались в

иерархических и сетевых базах данных, такие как повторяющиеся

группы (атрибуты с множественными значениями) и навигация по

указателям (на основе OID). Поэтому модель ORDB представляет



собой идеальную схему для интеграции схем все существующих

разнородных баз данных, включая RDB, ORDB, иерархические и

сетевые базы данных и даже плоские файлы.

Ниже приводятся возможности, включение которых в ORDB делает

объектно-реляционную систему возможной основой системы мультибаз

данных (MDBS):

Возможность организации шлюзов к другим системам баз данных

Возможность представления единственной виртуальной глобальной

схемы над существующими схемами разнородных баз данных

Возможность производить декомпозицию одного запроса на

ObjectSQL в подзапросы, обрабатываемые существующими разнородными

системами баз данных, и выполнять всю необходимую пост-обработку

(сливать отдельные результаты, выполнять соединения между

таблицами разных баз данных, сортировать и группировать отдельные

результаты)

Возможность транзакционного контроля над существующими

разнородными системами баз данных (в основном, двухфазная

фиксация/откат)

Логически MDBS является окончательным обобщением идеи шлюза;

физически такая система управляет несколькими шлюзами, через

которые производится управление удаленными базами данных. MDBS

может иметь и свою собственную базу данных; например, данные,

извлеченные из удаленных баз данных, могут быть сохранены в

собственной базе данных MDBS - по сути дела, получает склад или

лавка данных (datawarehouse или data mart). В любом случае MDBS

представляет пользователям множество удаленных баз данных как

одну "виртуальную" базу данных.

Обзор статьи "DB2 V.5 and Oracle 8: What they've Got What They've Not"

, August 1997

, President of Bischoff Consulting Inc.

, Центр Информационных Технологий

IBM и Oracle стремятся к тому, чтобы обеспечить средства

управления базами данных, удовлетворяющие всем возможным

потребностям: интеграция с World Wide Web; intranets; поддержка

сложных типов данных; поддержка всех приложений, связанных с

оперативной обработкой транзакций (OLTP) и принятием решений.

Хотя многие считают невозможным удовлетворение всех этих

требований в одной СУБД, IBM и Oracle добились существенных

успехов в этом направлении. Кроме того, обе компании обеспечивают

поддержку больших баз данных, параллелизма, разделения данных,

высокого уровня доступности и целостности данных.

Компания Oracle объявила продукт Oracle8 в июне 1997 г., а IBM

объявила DB2 Universal Database Version 5 (UDB) в декабре 1996 г.

Хотя в обоих продуктах компании стремились обеспечить одни и те

же возможности, для их реализации применяются разные методы.

Существо подхода Oracle8 сосредоточено в движении в сторону

чистого объектно-ориентированного подхода. С другой стороны, в

UDB v.5 упор делается на интегрированную и масштабируемую

поддерку сложных данных за счет средств расширения РСУБД, а также

на интеграцию со средством доступа к Web Net.Data.

Обзор статьи "Universal Servers: The Players, Part 2" DBMS, vol.10, N 7, July 1997,

Judith R. Davis, principal with InfoIT Inc.,

Обзор подготовлен С. Кузнецовым,

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

Во второй части рассматривается, каким образом пять ведущих компаний-поставщиков РСУБД - Informix Software Inc., IBM Corp., Microsoft Corp., Oracle Corp. и Sybase Inc. - реально поддерживают расширяемость.

Операции над отношениями

В этом разделе статьи приводятся определения некоторых реляционных операций; другими словами, в нем описывается то, что позже стали называть манипуляционной частью реляционной модели. Прежде, чем вдаваться в определения, Дейт утверждает: "Эти операции не будут напрямую интересовать большинство пользователей. Однако проектировщики информационных и люди, отвечающими за управление банками данных, должны быть досконально знакомы [с ними]" (Курсив К.Дейта.) Как это верно! По моему опыту, к сожалению, люди, которым следует быть досконально знакомыми с этими операциями, слишком часто не обладают соответствующими знаниями.

В число определенных Коддом операций входят перестановка (permutation), проекция (projection), соединение (join), связывание (tie) и композиция (composition) (в статье 1970-го г. добавлена операция ограничения (restriction), которую я описываю здесь для удобства). Интересно заметить, что определения ограничения и соединения отличаются от тех, которые используются сегодня, а операции связывания и композиции теперь редко принимаются во внимание. В том, что следует ниже, символы X, Y, ... (и т.д.) по мере необходимости обозначают либо индивидуальные атрибуты, либо комбинации атрибутов. Кроме того, по причинам, которые скоро будут понятны, определение соединения откладывается до конца раздела.

Перестановка. Переупорядочение атрибутов отношения слева направо. (Как я отмечал в прошлом месяце, в статье 1969-го года предполагалась упорядоченность атрибутов отношения слева направо. В отличие от этого, в статье 1970-го года утверждается, что перестановка рассчитана исключительно на внутреннее использование, поскольку упорядоченность атрибутов слева направо не является -- или не должна являться -- существенной для пользователей.)

Проекция. Понималась более или менее так же, как и сегодня (хотя синтаксис был другим; далее я буду использовать синтаксис R{X} для обозначения проекции R на X). Замечание: название "проекция" происходит из того факта, что отношение степени n можно рассматривать как представление точек в n-мерном пространстве, и к проекции этого отношения на m его атрибутов (mСвязывание.
Для данного отношения A{X1,X2,...,Xn} связывание A - это ограничение A до тех строк, в которых A.Xn = A.X1 (если использовать термин "ограничение" в его современном смысле, а не в специальном смысле, определяемом ниже.)

Композиция. Для данных отношений A{X,Y} и B{Y,Z} композицией A c B называется проекция на X и Z соединения (a join) A с B (причина, по которой я говорю "a join", а не "the join", объясняется ниже). Замечание: естественная композиция - это проекция на X и Z естественного соединения.

Ограничение. Для данных отношений A{X,Y} и B{Y} ограничение A по B определяется как максимальное подмножество A такое, что A{Y} является подмножеством -- не обязательно точным -- B.

Кодд также говорит, что "весь обычный набор операций [также] применим ... [но] результат может не являться отношением". Другими словами, когда Кодд писал свою статью 1969-го года, он оставил на будущее определения специализированных реляционных вариантов декартова произведения, объединения, пересечения и вычитания.

Приступим теперь к определению соединения. Для данных отношений A{X,Y} и B{Y,Z} соединение A с B в статье определяется как любое отношение C{X,Y,Z} такое, что C{X,Y} = A и C{Y,Z} = B. Заметим, что следовательно A и B можно соединить (или они "соединяемы"), только если их проекции на Y идентичны -- т.е. только если A{Y} = B{Y}, условие, которое вряд ли удовлетворяется на практике. Также заметим, что если A и B соединяемы, то могут существовать различные соединения (в общем случае). Хорошо известное естественное соединение -- называемое в статье линейным естественным соединением, чтобы отличить его от другого вида, именуемого циклическим соединением -- это важный частный случай, но не единственно возможный.

Однако странно то, что приводимое в статье определение естественного соединения не требует соединяемости A и B в приведенном специальном смысле! На самом деле, это определение почти такое же, как то, которое мы используем сегодня.



Постараюсь объяснить, откуда берется это довольно ограничительное понятие "соединимости". Кодд начинает свое обсуждение соединений с важного вопроса: При каких условиях соединение двух отношений сохраняет всю информацию, содержащуюся в этих двух отношениях? И он показывает, что свойство "соединяемости" является достаточным для обеспечения сохранения всей информации (поскольку в результате соединения не теряется ни одна строка ни одного операнда). Далее он также показывает, что если A и B соединяемы, и либо A.X функционально зависит от A.Y либо B.Z функционально зависит от B.Y, то естественное соединение является единственным возможным соединением (хотя реально он не использует терминологию функциональных зависимостей -- это также оставлено на будущее). Другими словами, Кодд здесь закладывает фундамент важнейшей теории декомпозиции без потерь (которую он, конечно, развил в последующих статьях).

Замечательно, что Кодд также приводит пример, показывающий, что уже в 1969 г. он осознавал тот факт, что некоторые отношения не могут быть декомпозированы без потерь в две проекции, но могут быть декомпозированы без потерь в три проекции! Этот пример был, очевидно, не замечен большинством первоначальных читателей статьи; во всяком случае для исследовательского сообщества оказалось неожиданностью повторное открытие этого факта несколькими годами позже. Именно это повторное открытие привело к изобретению Рональдом Фейджином окончательной нормальной формы 5NF, называемой также нормальной формы проекции-соединения (PJNF).

Определяемые пользователями функции

DB2 обеспечивает более 100 встроенных функций для выполнения

различных вычислений над числами, строками, датами и другими

типами данных, а также дает пользователям возможность создания

собственных функций с использованием языков Си, Си++ и Бейзик.

Определяемые пользователями функции (User-Defined Functions -

UDF) могут принимать параметры и могут быть использованы в любом

выражении SQL, где предполагается наличие скалярного значения.

Поддерживается соглашение о передаче параметров UDF в

поставляемую пользователем программу реализации функции. Этой

программе передаются входные параметры функции, а также указатели

на буфера, в которые должны быть возвращены результат функции и

код статуса ее завершения. Создатель функции должен

откомпилировать реализующую ее программу и поместить выполняемый

файл в каталог, доступный серверу баз данных. После этого

пользователь должен зарегистрировать UDF в каждой базе данных,

где предполагается ее использование, путем выполнения оператора

CREATE FUNCTION. В этом операторе определяются типы параметров и

результата функции, указывается место расположения реализующей

программы. Описание функции помещается в таблицы системного

каталога. После этого при каждом вызове функции ее реализация

будет динамически загружаться и выполняться. Важно обеспечить

защиту выполняемого файла, поскольку он выполняется при вызове

функции без дополнительных системных проверок.

Комбинация имени функции и типов ее параметров называется

"сигнатурой" функции. SQL позволяет "перегружать" имя функции,

т.е. определять несколько функций с одним именем и разными типами

параметров. При обработке вызова функции DB2 вызывает функцию,

типы параметров которой строго соответствуют типам аргументов

вызова.

Определяемые пользователями типы

В DB2 определяемые пользователями типы данных называются

"индивидуальными типами" (distinct type"). В каждом из

индивидуальных типов используется общее представление одного из

встроенных типов (называемых "базовыми типами"), но может иметься

собственный набор допустимых операций.

Следующие операторы создают два индивидуальных типа с именами

DOLLARS и YEN, базирующихся на встроенном типе Decimal. Фраза

WITH COMPARISONS означает что можно сравнить любые два значения

типа DOLLARS и любые два значения типа YEN, однако значение типа

DOLLARS не может быть сравнено со значением типа YEN или с

обычным десятичным значением.

CREATE DISTINCT TYPE DOLLARS AS DECIMAL (10,2) WITH COMPARISONS;

CREATE DISTINCT TYPE YEN AS DECIMAL (10,2) WITH COMPARISONS;

При создании индивидуального типа DB2 генерирует функцию,

преобразующие значение индивидуального типа в значение его

базового типа и наоборот. Например, при создании типа DOLLARS

создаются функции преобразования DOLLARS(DECIMAL) со значением

типа DOLLARS и DECIMAL(DOLLARS) со значением типа DECIMAL(10,2).

Сразу после создания индивидуального типа единственными

операторами, применимыми к его значениям, являются операторы

сравнения. Например, если SALARY и BONUS - это два столбца типа

DOLLARS, то SALARY=BONUS и SALARY>BONUS являются допустимыми

предикатами, но выражения SALARY+BONUS и SALARY*BONUS не

допускаются, поскольку для типа DOLLARS не определены

арифметические операции.

Легко указать, какие из операций базового типа являются

осмысленными для созданного на его основе индивидуального типа.

Каждый встроенный оператор, такой как "+", реализуется функций с

тем же именем, что и оператор. Чтобы сделать этот оператор

применимым к индивидуальному типу, нужно просто создать функцию с

тем же именем, что и оператор, принимающую параметры и/или

возвращающую результат индивидуального типа данных. Функция,

реализующая оператор, может основываться на функции, реализующей

встроенный оператор. В следующих предложениях SQL определяются

оператор "+" для двух значений типа DOLLARS и оператор "*" для

значения целого типа и значения типа DOLLARS:

CREATE FUNCTION "+" (DOLLARS,DOLLARS)

RETURN DOLLARS

SOURCE

SYSIBM."+" (DECIMAL(),DECIMAL());

CREATE FUNCTION "*" (INTEGER,DOLLARS)

RETURN DOLLARS

SOURCE

SYSIBM."*" (INTEGER,DECIMAL());

После выполнения этих предложений выражения SALARY+BONUS и

2*SALARY будут допустимыми, но выражение SALARY*BUNUS останется

недопустимым, поскольку оператор умножения не определен для двух

значений типа DOLLARS.

Конечно, может потребоваться расширить функциональность

индивидуального типа за пределы набора операторов базового типа.

Например, можно создать тип ADDRESS, основанный на встроенном

типе VARCHAR(50). После этого можно создать определяемую

пользователями функцию TIMEZONE(ADDRESS), вычисляющую временную

зону этого адреса. Как и любая другая UDF, функция TIMEZONE может

быть написана на языках Си, Си++ и Бейзик и должна быть

зарегистрирована в соответствующей базе данных.

Оптимизация

Если сила Oracle заключается в средствах разработки, то IBM

выигрывает в возможностях оптимизации. Хотя в обоих продуктах

оптимизаторы используют оценки стоимости плана выполнения

запроса, оптимизатор DB2 в дополнение к размерам таблиц и

возможным путям доступа принимает во внимание скорость

центрального процессора и дисковых устройств, а также полностью

переписывает запросы, которые можно выполнить более эффективно в

другой формулировке. Oracle продолжает работать над своим

оптимизатором, пытаясь навести мосты между прежним оптимизатором,

основанным на использовании правил, и средством, которое

позволило бы пользователям включать в операторы SQL подсказки,

ориентирующие оптимизатор на использование более эффективных

путей доступа.

OR-Compass

В флагманском продукте компании Logic Works ERwin/ERX реализованы

средства моделирования в стиле "сущность-связь" с поддержкой

нотаций IDEF1X и IE. Обеспечивается прямая и обратная инженерия

для всех ведущих реляционных СУБД, синхронизация логических

моделей и физических схем. Система ModelMart обеспечивает

управление моделью при ее групповой разработке. Компонент

ERwin/OPEN поддерживает связи со средствами разработки

приложений, включая PowerBuilder и VisualBasic. Кроме того, Logic

Works предлагает средство обмена метаданными с системой

моделирования объектов компании Retional Rose.

OR-Compass - это новый продукт, который не является простым

расширением ERwin/ERX, хотя и допускается импортирование

ERX-модели. OR-Compass 1.0 работает с СУБД компании Informix

(), но в начале 1998 г. обещана поддержка

Oracle8 (), DB2 Universal Database компании IBM

() и Adaptive Server компании Sybase ().

В OR-Compass используется методология моделирования

"сущность-связь" в нотации IDEF1X.

Компоненты Row Type Wizard (RTW) и Functional Index Wizard (FIW)

помогают моделировать объектно-реляционные свойства. RTW

ориентирован на поддержку проектировщиков, мигрирующих от

реляционных к объектно-реляционным базам данных, и позволяет

произвести строчный тип на основе выбранных столбцов таблицы.

Компонент не дает возможности просто определить строчный тип. FIW

кажется более полезным, позволяя определить индекс для таблицы на

основе вычисляемого поля.

Полезным механизмом являются ModelBlades. Эти модули состоят из

определений и документации объектов, входящих в состав DataBlades

компании Informix, которые могут импортироваться из файлов

ModelBlade или скриптов DDL (Data Definition Language).

Импортируемые объекты могут включаться в определяемые

пользователями модели.

Oracle

Компания объявила, что Oracle 8 будет уметь делать с объектами все, что умеет делать Informix-Universal Server, и даже больше. Однако это не так в первом выпуске Oracle 8 (этот выпуск был официально объявлен 24 июня 1997 г., см. сервер компании Oracle). В фокусе Oracle 8 находятся расширенная система типов и поддержка бизнес-объектов; появление других возможностей расширяемости ожидается в версии 8.1. Oracle концентрируется на реализации своей сетевой вычислительной архитектуры (NCA - Network Computing Architecture), и в Oracle 8 вносятся улучшенные возможности производительности, масштабируемости, доступности, репликации, разделения данных и т.д.

NCA - это трехзвенная архитектурная структура, основанная на CORBA (Common Object Request Broker Architecture). В NCA используются расширяющие компоненты, называемые "картриджами", которые могут разрабатываться Oracle или сторонними поставщиками. Впервые использование картриджей приложений и картриджей баз данных

потребовалось в Oracle Web Application Server для организации связи на основе CORBA. В контексте расширяемой среды данных Oracle будет обеспечивать компоненты на уровне промежуточного программного обеспечения приложений (например, компонент управления транзакциями в Web Application Server) и на уровне универсального сервера (Oracle 8). На объектном уровне Oracle 8 поддерживает объектные представления данных с использованием новых объектных типов и существующих реляционных данных. Кроме того, Oracle 8 поддерживает объектный кэш клиентов и навигацию между объектами по ссылкам. Транслятор объектных типов отображает объекты базы данных в соответствующие конструкции языка Си.

Далее приводится сводка свойств, имеющихся в Oracle 8 и ожидаемых в версии 8.1.

Расширяемая система типов - поддерживаются объектные типы, типы коллекций (массивы переменного размера и вложенные таблицы) и ссылочные типы. Объектный тип может применяться либо к столбцу, либо к строке и может быть семантически эквивалентен именованному строчному типу SQL-3.
Кроме того, Oracle 8 явно связывает с объектными типами методы. Пока поддерживается только один уровень вложенности таблиц (в 8.0), не поддерживаются полностью инкапсулированные ADT. Будет поддерживаться одиночное наследование. Отсутствует возможность репликации расширенных данных.

Определяемые пользователями функции - скалярные UDF, перегрузка и разрешение имени на основе типов параметров, параллельное выполнение UDF с определенными пользователями агрегатами (функции столбцов) находятся в стадии обсуждения.

Расширяемая система индексации - поддержка определяемых пользователями индексных структур и индексов на выражениях появится вместе с компонентом Database Extesibility Services.

Расширяемый оптимизатор - возможность указывать стоимость UDF и обеспечивать статистику об использовании определенных пользователями данных ожидается с появлением Database Extesibility Services. К расширенным типам пока не применяются параллельные операции.

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

Расширяемая языковая поддержка - UDF и хранимые процедуры пишутся на PL/SQL или Си/Си++, причем подпрограммы на Си/Си++ выполняются вне адресного пространства сервера. Поддержка Java в сервере будет обеспечиваться в Database Extesibility Services (версия 8.1).

Предопределенные расширения - сервер Oracle 8 поддерживает хранение текстовых, пространственных и видео- данных; ожидается появление нового типа данных для хранения графической информации. Компания работает также с несколькими партнерами для тестирования и формализации API для Database Extesibility Services и разработки картриджей данных.

Параллельное выполнение индивидуальных запросов

В чисто реляционных базах данных для успешной работы с данными

объемом более 250 Гбт требуется наивысшая степень параллельности

при выполнении каждого индивидуального запроса. Первейшим ключом

к распараллеливанию является структура самого языка запросов SQL.

Этот язык предназначен для работы со множествами и накладывает

немного ограничений на порядок выполнения запроса; поэтому

оптимизаторы запросов реляционных СУБД обладают такой гибкостью

при выборе планов выполнения запроса. По этой же причине SQL

исключительно подходит для параллельного выполнения.

Для использования этой возможности необходимо придумать стратегии

выполнения, обеспечивающие оптимизированное параллельное

выполнение индивидуального запроса, а не только обеспечить

параллельное выполнение последовательных индивидуальных

стратегий. Заметим, что и индивидуальные операции определения и

манипулирования данными (а также утилиты архивирования и

восстановления) должны выполняться параллельным образом.

Поставщики реляционных СУБД выполнили большую часть работы для

обеспечения такого распараллеливания. Более того, оказалось

возможным поддерживать высокую степень прозрачности для

приложений и администраторов баз данных. Этому значительно

способствовали не только структура SQL, но также и то, что ядро

языка и типы данных были в основном зафиксированы в 80-х и начале

90-х гг. И тем не менее, от производителей требуется 2-3 года,

чтобы внедрить внутреннее распараллеливание запросов в зрелую

реляционную СУБД.

Многие отмечают, что сложность внедрения параллелизма в VLDB

связана с двумя аспектами. Первый аспект состоит в замене

последовательных алгоритмов на параллельные. Второй аспект более

тонкий. Для проектирования и разработки конкурентоспособного

программного обеспечения требуется качественная перестройка

образа мышления. Например, первым поползновением разработчика

программы загрузки базы данных было бы использование функции

INSERT. Этот метод работает для малых и средних баз данных, но не

годится для больших: слишком медленно. Необходимо разработать

метод, при котором происходит параллельная загрузка нескольких

потоков данных, опираясь на возможность использования нескольких

процессоров в архитектурах MPP или кластеры SMP. Если данные

поступают из одного последовательного источника (например,

устройства с магнитной лентой), первичная задача загрузки состоит

в как можно более быстром помещении данных в память. После этого

вся процессорная мощь должна быть использована в параллельном

режиме для помещения каждого элемента данных в нужное место,

поддержки индексов и т.д.

С расширением использования ОР-баз данных проблема становится

более сложной. Требуется учитывать наличие новых и потенциально

экзотических типов данных. Должны быть написаны и оптимизированы

для параллельного выполнения новые методы. Между экземплярами

новых типов данных и даже между экземплярами стандартных типов

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

операций и типов данных требуются новые методы доступа к данным,

и их тоже нужно оптимизировать для параллельного использования.

Наконец, необходимо принимать во внимание то, что количество

различающихся значений в одном столбце таблицы может в тысячу и

более раз превосходить число разных значений в другом столбце.

Для учета этого требуется применять новые подходы к хранению и

буферизации данных как на стороне сервера, так и на стороне

клиентов.

Параллельный язык манипулирования данными (Data Manipulation Language - DML) SQL

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

параллельного выполнения операций вставки, модификации и удаления

данных, и такая поддержка присутствует в обоих продуктах. Кроме

того, в продуктах поддерживается параллельное сканирование

индексов, но в Oracle имеются некоторые ограничения,

отсутствующие в DB2:

Параллельное выполнение операторов DML не производится, если

имеются определенные ограничения целостности: каскадное удаление;

ограничение по ссылкам таблицы к самой себе; ограничения с

отложенной проверкой

Для параллельно выполняемых операторов DML не поддерживаются

триггеры

Параллельное выполнение не происходит при наличии объектных или

LOB-столбцов.

Переменные с областью значений (range variables)

Замечание С.Кузнецова по поводу русскоязычной терминологии: На английском языке словосочетание "range variable" лаконично и правильно отражает суть понятия. К сожалению, до сих пор мне не удалось найти столь же лаконичный русский эквивалент, хотя было много попыток. Когда-то я пытался ввести в оборот термин "ранжированная переменная", но мне справедливо указали на отсутствие явного смысла в этом словосочетании. Если кто-нибудь знает, как лучше обозначать рассматривамое понятие на русском языке, дайте мне знать, пожалуйста.

Рассмотрим следующий запрос:

Q9: Выдать все пары номеров поставщиков, располагающихся в одном и том же городе

На языке SQL возможна следующая формулировка этого запроса:

SELECT FIRST.S# AS SX, SECOND.S# AS SY FROM S AS FIRST, S AS SECOND WHERE FIRST.CITY = SECOND.CITY

FIRST и SECOND являются примерами того, что в SQL называется корреляционными именами. Однако заметим, что SQL ничего не говорит о том, что именно именуют эти имена! В отличие от этого, в реляционном исчислении такие имена определяются для ссылок на переменные с областью значения, и далее будет использоваться этот термин.

Переменная с областью значений - это переменная, определенная на некоторой конкретной таблице; значениями переменной являются строки этой таблицы. Если областью значений переменной r является таблица R, то в каждый момент времени значением выражения "r" является некоторая строка R. В SQL переменные с областью значений вводятся посредством спецификации AS в разделе FROM (не нужно путать эту спецификацию со спецификацией AS в разделе SELECT, которая позволяет назначить имя столбцу результирующей таблицы).

Покажем, что, подобно разделам GROUP BY и HAVING, переменные с областью значений являются логически избыточными в языке SQL (несмотря на то, что они активно использовались в предыдущих примерах). Для иллюстрации сначала приведем формулировку запроса Q9 без использования переменных с областью значений:

SELECT SX, SY FROM ( SELECT S.S# AS SX, S.CITY FROM S) AS POINTLESS1 ) NATURAL JOIN ( SELECT S.S# AS SY, S.CITY FROM S) AS POINTLESS2 )

Замечание С.Кузнецова: Напомним, что здесь используется SQL-92, в котором допустимы и такие "алгебраические" формулировки.

Как видно, в этой формулировке на самом деле определяются две переменных с областью значений - POINTLESS1 и POINTLESS2, но логически они не требуются, поскольку отсутствуют ссылки на эти переменные. Они введены исключительно для того, чтобы удовлетворить синтаксические требования языка SQL.

В качестве второго примера используем запрос Q1 из первой части заметки:

Q1: Для каждой поставляемой детали выдать номер детали, максимальный и минимальный объем поставки этой детали.

Вот формулировка этого запроса без использования переменных с областью значений (равно как и разделов GROUP BY и HAVING):

SELECT DISTINCT PZ AS P#, ( SELECT MAX(SP.QTY) FROM SP WHERE SP.P# = PZ ) AS MXQ, ( SELECT MIN(SP.QTY) FROM SP WHERE SP.P# = PZ ) AS MNQ FROM ( SELECT SP.P# AS PZ FROM SP ) AS POINTLESS ;

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

В завершение раздела заметим, что переменные с областью значений должны быть необязательными в SQL, поскольку

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

Планирование ресурсов предприятия и транзакционные системы

Планирование ресурсов предприятия (Enterprise Resource Planning - ERP) требует наличия нескольких приложений, критичных для крупномасштабных организаций: финансы, человеческие ресурсы, управление системой поставок и т.д. На рынке ERP доминирует всего несколько поставщиков, в число которых входят , , и Oracle. Их программное обеспечение обычно строится поверх РСУБД.

ERP-приложения выполняют много транзакционных функций, которые базируются на нормализации для гарантирования высокого уровня параллельности и эффективности за счет минимизации числа обращений к дискам и блокировок. Другой важной областью применения РСУБД являются приложения, не относящиеся к категории ERP: резервирование, управление продажами, обслуживание заказчиков и т.д. Не слышно, чтобы поставщики таких приложений собирались перейти к использованию ОРСУБД. Продукт Universal Database Enabler компании Formida дает возможность использования объектов R/3 в приложениях Formida, но из этого не следует, что SAP применяет средства ОРСУБД. Единственной новостью, вызывающей вопросы, является участие компании Baan в разработке JavaBlend. Заключение автора: современные ОРСУБД могут являться универсальными серверами, но они далеки от универсального использования. Они могут управлять новыми типами данных, но поставщики корпоративных приложений вполне удовлетворены набором типов и ограниченными возможностями расширений РСУБД.

Поддержка Web

Явление Internet вызывает существенные изменения в способах

ведения бизнеса. В Сети все равны. Трудно узнать, является ли

бизнес-партнер в Internet большой многонациональной корпорацией

или лавочкой, расположенной в подвале. В этих условиях

конкуренция должна основываться на доступности продуктов, уровне

цен и качестве сервиса. DB2 v.5 и Oracle8 встречают появление

новой культуры рынка, обеспечивая развитую поддержку

Web-технологии. Пакет DB2 включает Net.Data, мощную поддержку

языка Java и средства интероперабельности со многими программными

средствами поддержки Internet производства как IBM, так и

других компаний. Oracle также предлагает развитую поддержку Web,

но не поддерживает хранимые процедуры и определенные

пользователями функции, написанные на языке Java. Продукт Web

Server, существующий со времени выпуска Oracle7, очень похож на

Net.Data и обеспечивает сопоставимые возможности за счет

использования брокера заявок web (web request broker). Net.Data и

Oracle Web Server упрощают написание интерактивных Web-приложений

путем расширения языка HTML средствами определения логики,

переменных, вызовов программ и производства отчетов.

Поддерживаются условная логика, HTML и подстановка переменных, а

также VRML.

Появляющиеся технологии

Что же будет дальше в мире промежуточного ПО? Коротко говоря,

Web, распределенные объекты, Web, Java и снова Web. Появление

Web-технологии применительно и к Internet, и к intranet дало

новую жизнь бизнесу промежуточного ПО. В то время, как компании

начинают связывать свои базы данных и другие ресурсы с Web,

производители промежуточного ПО получают удачную возможность

создать продукты, облегчающие этот процесс. Ирония ситуации

состоит в том, что использование браузера в качестве общей

платформы приложений "клиент-сервер" и HTTP в качестве общего

промежуточного ПО снижает интерес к промежуточному ПО на стороне

клиента. Анализируя возможности Web-технологии, нужно понимать,

что наибольшая выгода от промежуточного ПО может быть получена на

стороне сервера.

Популярные продукты промежуточного ПО, основанные на Web, можно

разделить на две категории - серверные и клиентские. Серверные

продукты обеспечивают связь между Web-сервером и сервером баз

данных с передачей данных клиенту на основе использования HTTP и

HTML. Часто встречается промежуточное ПО, поддерживающее и

разработки приложений, обеспечивая, например, возможность

отображения атрибутов базы данных на Web-страницы. Категория

серверных Web-продуктов промежуточного ПО включает, в частности,

WebDBC компании и Internet Database Connector (IDC), входящий теперь в состав

Microsoft Internet Information Server. Обычно такие продукты

легко устанавливаются и просто используются, обеспечивая

Web-мастеров и разработчиков приложений визуальной средой

разработки публикации данных из баз данных. На переднем крае

можно найти такие продукты как ActiveWeb компании , программная коммуникационная система,

дающая разработчикам доступ к приложениям, базам данных и

браузерам, поддерживающим Java, для обмена информацией через Web.

Конечно, и другие серверные продукты промежуточного ПО

обеспечивают разработчикам простой доступ к серверам приложений и

даже к унаследованным системам.

Криком моды являются клиентские Web-продукты промежуточного ПО.

Эти продукты позволяют разработчикам связывать с удаленными

базами данных выполняемые на стороне клиента Java-апплеты и

программные компоненты ActiveX. Среди первых на рынке появился

продукт JETConnect компании XDB Systems Inc. JETConnect дает

возможность разработчикам подключаться к удаленным серверам баз

данных на основе использования входящей в состав продукта

библиотеки классов. С появлением JDBC разработчики, применяющие

Java, получили стандартный механизм, дающий те же возможности,

что и JETConnect. Сегодня JDBC-драйверы имеются для большинства

популярных баз данных. Возможности JDBC встраиваются в средства

разработки; примером такого продукта является JBuilder компании

. Во многих отношениях JDBC похож на

ODBC, и те компании, которые создавали драйверы ODBC, найдут свою

нишу на новом рынке драйверов JDBC. В некоторых отношениях мир

Java будет выглядеть и функционировать очень похоже на то, что

сегодня представляет собой мир традиционного двухзвенного

клиент-серверного промежуточного ПО.

Производители промежуточного ПО вносят свой вклад и в развитие

технологии Web-разработок. Например, компания только что объявила о выпуске продукта

Ambrosia, представляющего собой управляемую событиями систему для

разработки бизнес-приложений в Internet. В системе используется

собственная реализация Java с гарантированной доставкой

сообщений, исчерпывающей безопасностью и транзакционными

возможностями.

Пользовательский интерфейс

Пользовательский интерфейс JDBC дает возможность строить

распределенные запросы в графической среде таким образом, что

несколько запрашиваемых баз данных представляются как одна база

данных. От пользователей не требуется знание схемы каждой

подключаемой базы данных. JavaDQD анализирует метаданные этих баз

данных и предоставляет пользователям информация об их схемах.

Диалог подключения к базе данных дает возможность подключиться к

локальным или удаленным базам данных и к временной базе данных.

Для выполнения подключения требуется указать URL базы данных и,

если это требуется, имя пользователя и пароль. В URL базы данных

указываются драйвер JDBC, источник данных и порт базы данных. Для

упрощения действий URL и имя пользователя могут быть сохранены в

конфигурационном файле, загружаемым во время инициализации

JavaDQD.

Для формулировки запросов и манипулирования данными используется

интерфейс в стиле QBE, при разработке которого использованы

средства GUI Java и MCT (Microline Component Toolkit). Компоненты

GUI и наличие в JDBS API возможности зондирования схемы базы

данных дают возможность динамического построения QBE-подобного

интерфейса после подключения к базе данных. Интерфейс дает

возможность создания и уничтожения объектов базы данных, а также

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

Интерфейс создания таблицы состоит из трех основных компонентов.

Во-первых, выдается список всех текущих баз данных. Пользователь

может выбрать базу данных, в которой будет создана новая таблица.

Во-вторых, выдается текстовое поле для ввода имени новой таблицы.

В-третьих, выдается решетка, в которой можно определить столбцы

таблицы: имя столбца, поддерживаемый тип данных и длину столбца.

Поддерживаемые типы данных определяются динамически путем

зондирования схемы выбранной базы данных.

Интерфейс выборки позволяет пользователям выбрать данные из

распределенной базы данных. Эти данные затем показываются во

фрейме результата. Интерфейс выборки показывает список доступных

таблиц, из которых могут быть выбраны данные. Этот список

включает все таблицы всех баз данных, к которым к этому времени

существуют подключения. Для идентификации таблицы используется

URL и имя таблицы. После выбора таблицы конструируется решетка

выборки для указания критерия, которому должны соответствовать

результирующие данные. Через строку view можно указать, какие

столбцы должны содержаться в результате. Кроме того, можно ввести

пример того, как должна выглядеть строка результата. Для задания

условия на значения столбца можно использовать предикаты =, <, >,

<=, >=, LIKE и <> и литеральные значения (строки символов и

числа). Условия, задаваемые в одной строке рассматриваются как

конъюнктивные; условия, задаваемые в разных строках, составляют

дизъюнкцию конъюнктов. Наконец, если из числа возможных таблиц

выбираются две или более таблицы, но на экране появляется строка

соединения, позволяющая задать условие соединения.

Отмечая удобство использования средств Java и JDBC для разработки

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

ограничений, имеющихся в их реализации JavaDQD. В основном эти

ограничения сводятся к некоторым особым требованиям, которым

должны удовлетворять драйверы ODBC.

Порождаемость, избыточность и согласованность

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

В статье 1970-го г. это определение слегка улучшено: Набор отношений называется строго избыточным, если включает по крайней мере одно отношение, некоторая проекция которого -- возможно, тождественная проекция, т.е. проекция на все атрибуты -- порождаема из других отношений этого набора. (Я взял на себя смелость несколько упростить определение Кодда, хотя, конечно, старался сохранить его исходный смысл.)

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

Однако хранимые отношения обычно не будут строго избыточны. Кодд развивает эту мысль в статье 1970-го г.: "Если ... строгая избыточность в именованном наборе прямо отражается ... на хранимом наборе ... то, вообще говоря, расходуются дополнительные пространство памяти и время обновления, [хотя может также достигаться] сокращение времени выполнения некоторых запросов и загрузки центральных процессоров."

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

Повышение эффективности модели

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

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

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

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

Практическая схема специальных значений

Во введении я выражал желание увидеть схему с двузначной логикой

и значениями по умолчанию, понятность и простота которой

уравновешивала бы уменьшение выразительной мощности. Поскольку

Дейт не дал нам такую схему, я кратко обрисую ее сам.

Прежде всего, я согласен с Дейтом в том, что по возможности нам

стоит устранить в своих базах данных атрибуты, допускающие

неопределенные значения. С некоторыми оговорками (которые здесь

не буду разъяснять) я согласен и с тем, что хорошим подходом

является расщепление типа сущности с подобным атрибутом на два

подтипа. В первом подтипе атрибут не сможет содержать

неопределенные значения, а во втором не будет самого этого

атрибута.

Во-вторых, я полагаю, что для идентификации специальных значений

следует зарезервировать одно или несколько значений из обычного

домена атрибута. Все что требуется, это одно значение, которое

означает, что "реальное значение отсутствует". Возможно,

потребуется различать случаи неприменимости, неизвестности и "то

или другое, не знаю точно что". В ответ на часто используемый

Дейтом аргумент, что имеется произвольное число различных типов

неопределенных значений и, следовательно, потребуется MVL с

произвольным числом истинностных значений, я заметил бы, что мне

кажется наивным полагать необходимость наличия формально

отличаемого вида неопределенных значений для каждого способа

формулировки условия отсутствия значения на естественном языке. В

книге Atzeni и DeAntonellis "Relational Database Theory"

(Benjamin/Cummings, 1993) показано, что любое такое условие можно

свести к одному из упомянутых выше.

При возможности, следует ввести бизнес-правила, гарантирующие,

что выбираемое значение не будет омонимом (т.е. не будет

использоваться в разном смысле). Например, если на предприятии

действует правило, что размер счета не может быть нулевым, то

можно использовать нули в атрибуте размера счета для индикации

отсутствия реального значения.

Однако иногда это невозможно.
Если на предприятии допускаются

счета нулевого размера, то наличие в столбце значения

"$000,000,00" будет означать a) счет нулевого размера и b)

"реальное значение отсутствует". Чтобы разобраться с подобными

омонимами, требуются дополнительные расходы. Выходом из положения

является добавления флага, отличающего нулевые счета ото всех

остальных, или использование в качестве специального значения

менее критичного и очень редко используемого реального значения

(например, "$999,999,98"). В последнем случае мы не устраняем

расходы на различение омономов, но существенно их сокращаем. На

самом деле, этот вид стратегии удешевленного использования

омонимов использовался десятки лет.

Наконец, заметим, что стратегия избежания омонимов с

использованием некоторого значения для идентификации "отсутствия

реального значения", не значащего ничего больше, предоставляет ту

же выразительную мощность (и те же сложности), что схема Дейта со

специальными значениями. Собственно, стратегия состоит в том,

чтобы найти представление UNK внутри обычного домена, а не

заставлять производителей СУБД расширять этот домен.

Новая схема Дейта является альтернативой MVL с неправильно

определенной операцией сравнения по равенству, полным отсутствием

операций сравнения на больше и меньше, невозможностью получать

полную информацию из базы данных и существенным усложнением

написания даже простых запросов. Более того, теперь, когда мы

понимаем, как далека схема Дейта от реализации, видно, что наши

дебаты не имеют непосредственного отношения к практической

разработке и использованию баз данных. И проектировщики, и

пользователи будут продолжать работать при наличии ограничений,

свойственных применяемым диалектам SQL.

Консерваторы будут избегать использовать неопределенные значения

и MVL, осмотрительно остерегаясь сложности. Чтобы им помочь, я

кратко изложил практический подход к управлению отсутствующей

информации, который может быть использован при наличии

сегодняшних продуктов баз данных. Этот подход не претендует на

оригинальность и лишь немного расширяет существующую практику.

Более рисковые пользователи будут использовать неопределенные

значения и, возможно, иногда им придется обжигаться. Но

постепенно у них составится понимание сути неопределенных

значений и MVL, которое невозможно получить при чтении книг.

Приложения

Пользователи будут переходить к ОРСУБД, если их собственным или разработанным сторонними поставщиками приложениям потребуются объектные расширения. ОРСУБД приняты в ряде важных прикладных областей, но в их число не входят области, обеспечивающие хлеб для РСУБД.

Success Story. Области, в которых у ОРСУБД дела обстоят хорошо, включают управление графической, аудио, видео, текстовой информацией, временными рядами, геопростраственными данными, а также Web-приложения. Для управления медиа-информацией требуется применение идейно простых методов к неструктурированным данным. В отличие от этого, управление временными рядами и геопространственными данными требует наличия относительно сложных структур данных и применения аналитических методов. Web-приложения занимают промежуточную позицию, основываясь на неструктурированных данных для представления шаблонов динамических страниц и усложненных методах управления переменными, логикой страниц и запросами к базам данных. Принятие для использования расширяемого языка разметки (eXtensible Markup Language - XML) поможет добиться большей структуризации шаблонов Web-страниц и других документов.

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

OLAP и хранилища данных (datawarehousing). OLAP (On-Line Analitycal Processing) - это интерактивный, исследовательский анализ данных, основанный на выделении нужных слоев многомерных кубов и агрегировании по измерениям. Развитые OLAP-системы позволяют связывать индивидуальные значения с агрегатами и с другими значениями. Для этих систем важно то, что можно делать с данными, а не как они хранятся.
Можно хранить кубы в специализированной многомерной базе данных или с помощью РСУБД. В последнем случае многомерное представление достигается с помощью реляционных OLAP-систем (ROLAP).

У каждого поставщика ОРСУБД имеются OLAP-средства. Компания IBM интегрирует продукт Essbase компании с DB2 и обеспечивает использование своего продукта Visual Warehouse в продуктах компании . Informix продает средство Metacube ROLAP, которое основано на технологии, полученной от Stanford Technology Group. Oracle предлагает Express Server (купленный у компании , в просторечии IRI Software), история которого восходит к 1970 г. Однако перспективы встраивания функций OLAP в ОРСУБД кажутся отдаленными. Расширения собственных аналитических возможностей СУБД выглядят, в лучшем случае, неоднородными. К хорошим примерам относятся продукты SQL Expander для DB2 компании , обеспечивающий ряд аналитических функций для обычных данных DB2, и S-Plus DataBlade компании , предоставляющий возможности статистического анализа, моделирования и визуализации.

Возможно, поставщики не имеют стимула, полагая, что их текущие реляционные и многомерные СУБД хорошо обслуживают приложения. Но имеются и технические проблемы, такие как написание эффективного кода для управления большими разреженными многомерными массивамм данных с множественными иерархиями и потребность в единообразных, быстрых, не ограниченных одним измерением вычислениях. Аналогичные трудности сохраняются для хранилищ данных, которые обычно основываются на многомерных моделях данных, реализуемых звездообразными схемами (или вариантами "снежинка" и "создездие"). В реализациях используются битовые индексы, доступные в традиционных СУБД. (Джерри Додж и Тим Горман (Gary Dorge and Tim Gorman, Oracle8 Data Warehousing, John Wiley & Sons, 1998) утверждают, что они осветили все возможности Oracle7 и Oracle8, но во всей книге не разу не упомянута поддержка объектов в Oracle8.)

---

---