Проблемы моделирования

На сегодня ОРСУБД добились наибольшего успеха в областях

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

как геопространственные данные и временные ряды финансовых

приложений. Системы часто используются в Web-приложениях и

специализированных складах данных (datawarehouses). Развитые

Web-приложения демонстрируют преимущества возможностей ОРСУБД по

интегрированному управлению мультимедиа, традиционными

структурированными данными и шаблонами для динамической генерации

страниц.

Мультимедийные включают аудио, видео, графику и форматированный и

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

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

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

объекты (BLOBs - Binary Large Objects). Более интересна новая

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

и обработки хранимых мультимедийных данных. Например, Web

DataBlade Informix включает не только набор структур данных

(шаблонов) для мультимедийных страниц приложения, но также и

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

тегов, встроенных в HTML. Страницы приложения сохраняются с

применением непрозрачного UDT с именем html, у которого имеются

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

просто текст; интересны именно методы.

Временные ряды - упорядоченные массивы значений, индексируемые по

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

Во всех основных ОРСУБД имеется (или будет иметься) один или

более Cartridge, Datablade или Extender для работы с временными

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

методы, поддерживающие временные ряды. Независимо от источника

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

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

Значения серий более недоступны через нерасширенный SQL; для

извлечения и обработки значений и рядов целиком обычно нужны

функции и операции, например, функция GETVALUE с параметрами

SERIESNAME и DATE. Можно было бы перегрузить операцию PLUS для

сложения серии со скалярным значением и для сложения значений

двух серий.

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

объектно-реляционного подхода моделируются и данные, и процессы:

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

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

инкапсуляция операций и процессов. Очевидно, что методологии и

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

операции. Кроме того, эти средства должны давать возможность

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

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

Cartridge, DataBlade и Extender.

Продукты промежуточного ПО, ориентированные на базы данных

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

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

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

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

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

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

разработки. Например, в мире систем "клиент-сервер"

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

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

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

популярных СУБД, а можно работать с ODBC. Почти во все средства

разработки компании встроен BDE со

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

поддерживается и ODBC.

Наиболее существенным новым стандартом ориентированного на базы

данных промежуточного ПО является JDBC. В JDBC определен

интерфейс уровня вызовов (Call-Level Interface - CLI) для

использования в среде Java. JDBC не входит в последний вариант

JDK (Java Development Kit), поставляемый подразделением JavaSoft

компании . На самом деле, JDBC

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

архитектурно очень близкий к ODBC.

OLE-DB обеспечивает единую точку доступа к нескольким базам

данных. Задача разработки OLE-DB состояла в обеспечении

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

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

данных.

Имеются и независимые от средств разработки ориентированные на

базы данных продукты промежуточного ПО. Например, продукт

DB Tools.h++ компании

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

написанных на языке Си++. DB Tools.h++ дает возможность

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

объекты Си++. Для тех, кому ближе язык Java, предлагает Java-версию продукта под названием

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

Java-апплетов и приложений.
Аналогичный продукт Persistence

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

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

объектно-ориентированной среде разработки.

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

хранящимся на нескольких машинах, следует обратить внимание на

такие продукты переднего края как EDA/SQL компании . Подход, положенный в основу

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

число операционных систем, сетей и баз данных. Например, можно

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

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

используя один драйвер ODBC на стороне клиента. Подобного рода

продукты полезны для организаций, желающих перейти к

использованию архитектуры "клиент-сервер" без отказа от

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

Проект

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

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

Прототип устойчивых сессий ODBC

В работе над нашими начальными системами мы избежали трудностей, связанных с потребностями существенных изменений во внутренних частях системы восстановления баз данных, сосредоточившись на доступности сессий ODBC. Термин ODBC означает "open database connectivity" - технологию, основанную на стандарте ANSI/ISO, которая позволяет приложениям осуществлять доступ к нескольким базам данных сторонних поставщиков. В ODBC применяется интерфейс общего назначения CLI (call level interface), в котором SQL используется как стандарт для доступа к данным. Нашей целью является обеспечение устойчивых серверных сессий для клиентских систем, поддерживающих ODBC. Сессии могут переживать системный крах без потребности того, чтобы клиентские приложения не беспокоились об остановке работы, разве только из соображений времени выполнения.

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

Для обеспечения доступности сессий ODBC мы ввели обобщенный Phoenix ODBC драйвер, который будет работать с любой базой данных. Наш драйвер ODBC перехватывает каждое взаимодействие с системой баз данных средствами ODBC, поскольку только эти взаимодействия могут изменить состояние сессии ODBC. По существу, он обволакивает любой драйвер ODBC конкретной базы данных. Драйвер Phoenix перехватывает запросы приложения, направляемые серверу баз данных, журнализует операторы, изменяющие контекст сессии, и переписывает выбранные операторы SQL таким образом, чтобы вызвать создание долговременных таблиц базы данных, которые сохраняют состояние приложения. Затем запрос передается соответствующему "настоящему" драйверу ODBC.
Ответы возвращаются из сервера "настоящему" драйверу ODBC. Драйвер Phoenix ODBC перехватывает ответы "настоящего" драйвера клиентского приложения, различным образом кэширует, фильтрует, переформировывает результирующий набор и синхронизуется с состоянием приложения, материализованным на сервере баз данных.

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

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

Путь вперед

UDT v.5 и Oracle8 представляют собой существенное продвижение в

семействе наиболее популярных промышленных СУБД. Поскольку многие

возможности, появившиеся в Oracle8, уже существовали в предыдущих

выпусках DB2, компания Oracle все еще выглядит как догоняющая. С

другой стороны, хотя DB2 включает интегрированные средства

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

интегрированных средств разработки. На сегодня основной мощью

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

систем среднего уровня; IBM продолжает лидировать в области

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

Распределенные объекты и эффективность

Как говорилось выше, ориентированные на приложения распределенные объектные вычислительные системы потенциально могут понизить значимость сервисов баз данных. Это утверждение опирается на доминирующую роль объектно-ориентированных языков программирования и методологий, а также на наличие визуальных объектно-ориентированных инструментальных средств. На этот подход делают ставку компании Sybase и Microsoft, а Oracle и IBM ограничивают инвестирование своих ОРСУБД. (На самом деле, объектные расширения Oracle наиболее полно реализованы в среднем звене сервера приложений.) И конечно, не случайно все четыре компании являются ведущими поставщиками инструментальных программных средств.

Главным аргументом в пользу ОРСУБД и ОСУБД является их эффективность. Как писали Джим Грей и Андреас Рейтер в своей классической книге (Jim Gray and Andreas Reuter, Transaction Processing: Concepts and Techniques, Morgan Kaufmann, 1993), накладные расходы при межпроцессных взаимодействиях даже в самых простых случаях в тысячи раз превышают расходы на прямой доступ к основной памяти. Если переформулировать этот факт в терминах объектов, то операция может быть послана объекту, предположительно управляемому сервером объектов где-то в сети (подход ORB - Object Request Broker), или же объект может быть перемещен в приложение и обработан локально (подход баз данных). С каждым из этих подходов связаны свои проблемы эффективности, связанные с перемещением объекта "здесь" или посылкой операции для выполнения "там". Решения об использовании объектной базы дынных или ORB не являются взаимно исключающими. Объектный сервер в среде ORB может в действительности использовать объектную базу данных для хранения управляемых им объектов. В придачу к этому, следует учитывать, что коммуникационные расходы, необходимые для синхронизации серверов, возрастают квадратично при росте числа серверов.

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

Распределенные объекты и виртуальные ОРСУБД

Строго говоря, Sybase не предлагает ОРСУБД. Стратегия компании, воплощенная в Adaptive Server и Adaptive Component Architecture, включает три составляющих. Во-первых, Adaptive Server будет объединять различные механизмы управления данными на основе унифицированного интерфейса и Java VM, встроенной в СУБД. В виде Java-классов будет реализован богатый набор типов данных. Java-объекты будут храниться в традиционных реляционных таблицах, но управляться Java VM; доступ к серверу будет обеспечиваться через JDBC. Этот подход предложен для принятия в качестве части стандарта SQL-3. Сервер, соответствующий этому стандарту, по существу, будет служить контейнером Java-объектов, обеспечивая объектно-реляционное представление в традиционных РСУБД. Предположительно, тот факт, что Adaptive Server является виртуальной ОРСУБД, будет прозрачен для средств разработки приложений.

Во-вторых, такие средства сторонних поставщиков как менеджер временных рядов компании , Spatial Query Server компании , Image Engine компании , механизм полнотекстового поиска компании будут обеспечивать расширенные типы данных. По утверждению Sybase, ее DirectConnect устанавливает мосты между Adaptive Server и десятками внешних хранилищ данных.

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

Аналогичным образом, на объектном представлении реляционных данных базируется подход Microsoft. Компания не объявляет планов создания "истинной" ОРСУБД. Промежуточной задачей является выпуск SQL Server 7.0, в котором ожидается объединение OLAP-сервер Plato с наиболее устойчивой доступной версией ядра сервера реляционных баз данных. Однако требуется большая работа, чтобы обеспечить продукту место в секторе рынка крупномасштабных корпоративных СУБД.
Для достижения успеха, в частности, нужно иметь 64-разрядный вариант Windows NT с хорошей масштабруемостью в симметричных мультипроцессорных и кластерных архитектурах.

Нельзя сказать, что многие пользователи SQL Server и Windows NT считают эти продукты идеальными для управления мультимедийными данными, временными рядами или геопространственной информацией, хотя компания добилась существенного процесса в области Web. Попытки расширить компонентную объектную модель (Component Object Model - COM) для использования на неоднородных платформах, обеспечить возможность распределенных вычислений с применением Microsoft Transaction Server позволяют предполагать, что Microsoft ограничится возможностью вызова внешних пользовательских программ и не будет стараться обеспечивать истинную объектно-реляционную среду. Вместо этого будет продолжаться агитация к использованию API OLE DB для "универсального доступа к данным" с введением новых типов данных (например, текстовых).

Текущие и ожидаемые в ближайшем будущем результаты Microsoft, связанные с объектно-реляционными возможностями, не слишком значительны. В более отдаленной перспективе успех подхода объектно-реляционного представления данных может определяться широтой области распространения OLE DB, на что, в свою очередь будет влиять успешность внедрения JavaBeans, JDBC и Java со встроенным SQL.

Раздел GROUP BY

В качестве основы примеров используется известная по книгам К. Дейта база данных "поставщики и детали":

S ( S#, SNAME, STATUS, CITY ) PRIMARY KEY ( S# )

P ( P#, PNAME, COLOR, WEIGHT, CITY ) PRIMARY KEY ( P# )

SP ( S#, P#, QTY ) PRIMARY KEY ( S#, P# ) FOREIGN KEY ( S#) REFERENCES S FOREIGN KEY ( P#) REFERENCES P

Вот запрос к этой базе данных, для которой люди "естественно" используют раздел GROUP BY:

Q1: Для каждой поставляемой детали выдать номер детали, максимальное и минимальное число поставок.

"Естественной" (с применением GROUP BY) формулировкой запрса является следующая:

SELECT SP.P#, MAX(SP.QTY) AS MXQ, MIN(SP.QTY) AS MNQ FROM SP GROUP BY SP.P# ;

Предположим, что база данных содержит следующие значения:

S SP

S# SNAME STATUS CITY S# P# QTY ------------------------------- -------------- S1 SMITH 20 LONDON S1 P1 300 S2 JONES 10 PARIS S1 P2 200 S3 BLAKE 30 PARIS S1 P3 400 S4 CLARK 20 LONDON S1 P4 200 S5 ADAMS 30 ATHENS S1 P5 100 S1 P6 100 P S2 P1 300 S2 P2 400 P# PNAME COLOR WEIGHT CITY S3 P2 200 ------------------------------------ S4 P2 200 P1 Nut Red 12 London S4 P4 300 P2 Bolt Green 17 Paris S4 P5 400 P3 Screw Blue 17 Rome P4 Screw Red 14 London P5 Cam Blue 12 Paris P6 Cog Red 19 Rome

Тогда результатом запроса будет следующая таблица:

P# MXQ MNQ --------------- P1 300 300 P2 400 200 P3 400 400 P4 300 200 P5 400 100 P6 100 100

Вот другая формулировка того же самого запроса без использования GROUP BY:

SELECT DISTINCT SP.P#, (SELECT MAX(SPX.QTY) FROM SP AS SPX WHERE SPX.P# = SP.P#) AS MXQ, (SELECT MIN(SPX.QTY) FROM SP AS SPX WHERE SPX.P# = SP.P#) AS MXQ FROM SP ;

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

Пусть имеется таблица R { A, B, ... } и пусть agg - это агрегатная функция (например, SUM, MAX или MIN), применимая к столбцу R.B. Тогда выражение

SELECT R.A, agg(R.B) AS C FROM R GROUP BY R.A ;

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

SELECT DISTINCT R.A (SELECT agg(RX.B) FROM R AS RX WHERE RX.A = R.A) AS C) FROM R) ;

Будем далее называть это преобразование преобразованием Типа 1.

Теперь рассмотрим, что произойдет, если в исходной формулировке с GROUP BY будет присутствовать раздел WHERE. Расширим запрос Q1:

Q2: Для каждой поставляемой детали выдать номер детали, максимальное и минимальное число поставок, но при этом не принимать во внимание поставки поставщика S1.

Вот формулировка с GROUP BY:

SELECT SP.P#, MAX(SP.QTY) AS MXQ, MIN(SP.QTY) AS MNQ FROM SP WHERE SP.S# <> 'S1' GROUP BY SP.P# ;

Эквивалентная формулировка запроса без GROUP BY (не единственная из числа возможных) не намного хитрее:

SELECT DISTINCT SP.P#, (SELECT MAX(SPX.QTY) FROM SP AS SPX WHERE SPX.P# = SP.P# AND SPX.S# <> 'S1') AS MXQ, (SELECT MIN(SPX.QTY) FROM SP AS SPX WHERE SPX.P# = SP.P# AND SPX.S# <> 'S1') AS MNQ, FROM SP WHERE SP.S# <> 'S1' ;

Как видно, раздел WHERE из исходной формулировки с GROUP BY размножился в двух вложенных выражениях раздела SELECT. В исходной формулировке раздел WHERE управляет как разделом SELECT, так и разделом GROUP BY. Последовательность записи разделов в языке SQL несколько нелогична. В общем случае выражение, включающее разделы SELECT-FROM-WHERE-GROUP BY вычисляется в последовательности FROM-WHERE-GROUP BY-SELECT, и имело бы смысл писать именно в таком порядке. Но язык SQL этого не позволяет.

Как видно из приведенного выше примера, преобразование Типа 1 нуждается лишь в незначительных расширениях, чтобы включать возможность использования раздела WHERE. Детали очевидны. Еще раз изменим наш пример:

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

Формулировка с GROUP BY:

SELECT MAX(SP.QTY) AS MXQ FROM SP GROUP BY SP.P# ;

С использованием преобразования Типа 1 мы получим следующую формулировку:

SELECT DISTINCT (SELECT MAX(SPX.QTY) FROM SP AS SPX WHERE SPX.P# = SP.P# AS MXQ FROM SP ;



Вот результаты выполнения этих двух запросов:

С GROUP BY Без GROUP BY

MXQ MXQ ----- ----- 300 300 400 400 400 100 300 400 100

Как видно, результаты разные, т.е. запросы не совсем эквивалентны, и преобразование Типа 1 не работает в этом частном случае. Но действительной причиной отсутствия эквивалентности является то, что результат выполнения запроса с GROUP BY не есть отношение, поскольку содержит строки-дубликаты. Более существенно то, что дубликаты осмысленны. Например, у двух строк "300" разный смысл: одна из них означает, что у некоторой детали максимальный объем поставок равен 300, а другая - что имеется некоторая другая деталь с тем же самым максимальным объемом поставок. Эти "осмысленные дубликаты" представляют собой очень существенный отход от базовых принципов реляционной модели данных. Возможность их наличия говорит о том, что SQL не является и никогда не был истинно реляционным языком.

Заметим, что при использовании SQL "осмысленные дубликаты" могут появляться в ряде других случаев. Например, даже такое простое выражение как

SELECT CITY FROM S ;

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

Еще раз осмыслим запрос Q3. Что он на самом деле означает? Похоже, что нас интересовало множество максимальных поставок из SP. Формулировка без GROUP BY корректно производит эту информацию. Конечно, в результате не показывается, для каких конкретных деталей производились максимальные поставки, но требуемая информация предоставляется.

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

По мнению автора, запросы вида Q3, хотя и являются допустимыми, не слишком осмысленны.Такие запросы игнорируют существенную информацию. Обычно это связано с тем, что в раздел SELECT входят не все столбцы, используемые в разделе GROUP BY. Для подобных формулировок преобразование Типа 1 "работает некорректно". Но это преобразование работает правильно для всех "осмысленных" запросов.

Раздел HAVING

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

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

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

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

Результатом такого запроса является таблица

P# ----- P1 P2 P4 P5

Вот формулировка без использования разделов GROUP BY и HAVING:

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

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

SELECT R.A FROM R GROUP BY R.A HAVING agg(R.B) comp scalar ;

(где comp является некоторой операцией скалярного сравнения, а scalar - некоторое скалярное выражение) может быть логически преобразовано к эквивалентному выражению

SELECT DISTINCT R.A FROM R WHERE (SELECT agg(R.B) FROM R AS RX WHERE RX.A = R.A) comp scalar ;

Будем называть такого типа преобразования преобразованиями Типа 2. Посмотрим, что произойдет, если исходная формулировка будет включать раздел WHERE.

Q5: Для каждой детали, поставляемой более чем одним поставщиком (кроме поставщика S1), выдать номер детали.

Формулировка с GBH:

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

Формулировка без GBH лишь немного хитрее:

SELECT DISTINCT SP.P# FROM SP WHERE (SELECT COUNT(*) FROM SP AS SPX WHERE SPX.P# = SP.P# AND SPX.S# <> 'S1') > 1 ;

Пример показывает, что преобразование Типа 2 может быть легко обобщено для случая наличия раздела WHERE. Вот несколько более сложный пример:

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

Формулировка запроса с использованием GBH:

SELECT SP.P#, SUM(SP.QTY) AS TQY FROM SP GROUP BY SP.P# HAVING COUNT(*) > 1 ;

Применяя правила преобразований Типа 1 и 2, получим следующее:

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

И еще один пример:

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

Вот формулировка с применением GBH:

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

Преобразованный вариант:

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

В результате выполнения этих запросов были бы получены следующие результаты:

С GROUP BY Без GROUP BY и HAVING и HAVING

TQY TQY ----- ----- 600 600 1000 1000 500 500 500

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

Различение типов денормализации

Эти простые принципы позволят внести в логическую модель конкретные изменения, оказывающие небольшое влияние на дисковую подсистему и сохраняющие характеристики бизнес-модели. Денормализация диаграмм "сущность-связь" (ERD - Entity-Relationship Diagram) или денормализация уровня доступа могут быть использованы с применением или без применения CASE-средств.

Размышления о будущем

Все возможности, описанные в этой статье были доступны в DB2 for Common Servers с июля 1995 г. IBM планирует распространить те же

возможности и на других членов семейства DB2. Особенно важно то,

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

объектно-реляционной систем, в лабораториях IBM производилась

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

средств, включая следующее:

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

UDF с телом, написанным на SQL

UDF, результатом которых являются таблицы

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

возможно содержащим ссылки на другие строки-объекты

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

данных как временные ряды и географические данные.

Реализация

Методология, Java и JDBC

Для разработки JavaDQD использовался пакет Java Development Kit

(JDK) 1.1, выпущенный весной 1997 г. В состав JDK входят

компилятор и интерпретатор, а также модуль JDBC.

По мнению авторов, разработанный компанией SunSoft язык Java

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

прост, обладает свойствами объектной ориентированности,

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

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

платформо-независимые программы. Java-программа может быть

разработана в виде апплета, загружаемого через Internet и

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

находящегося на стороне клиента. В любом случае у программиста

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

получать доступ к удаленным данным Web-пространства и

использовать эти данные (текст, графические образы, звук) в своей

программе. Наличие JDBC позволяет Java-программисту подключаться

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

JDBC - это пакет, обеспечивающий API для единообразного доступа к

различным источникам данных на основе языка баз данных SQL.

Реально API представляет собой набор абстрактных классов, которые

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

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

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

Представление высокого уровня дается JDBC API, в котором имеются

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

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

интерпретировать JDBC как набор абстрактных классов, которые

должны быть реализованы для конкретной базы данных. Такая

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

чтобы Java-программист мог получить доступ к базе данных. После

реализации драйвера для конкретного источника данных это драйвер

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

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

высокоуровневый API.

Распределенный подход

Распределенные запросы реализуются в JavaDQD с использованием

нитей Java и пре- и пост-обработки. Вкратце, методология состоит

в следующем.

Запрос пользователя подвергается пре-обработке для создания

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

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

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

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

общего запроса.

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

нить. В каждой нити ее строка запроса используется для запроса

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

временную базу данных. Позже из таблиц временной базы данных

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

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

ResultSetMetaData, позволяющие определить типы данных и размеры

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

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

Производится выборка из временной базы данных по строке

финального запроса. Результаты запроса отображаются в окне

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

Пользователю JavaDQD не требуется знать о подключениях к

индивидуальным базам данных. Использование API и драйверов JDBC

позволяет сделать прозрачной для пользователей распределенную

природу запросов. Ответственность за безопасность несут драйверы

JDBC.

Реляционное и объектно-реляционное моделирование

Подход "сущность-связь" (ER - Entity-Relationship) является

традиционным в традиционном реляционном моделировании;

информационная инженерия (IE - Information Engineering) и IDEF1X

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

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

ОРСУБД, все эти три подхода приспособлены для моделирования

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

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

моделирования процессов.

Реляционное представление данных

По-существу, этот раздел статьи Кодда посвящен тому, что позже стали называть структурной частью реляционной модели; т.е. в нем обсуждаются отношения как таковые (и кратко упоминаются ключи), но вообще не рассматриваются реляционные операции (то, что позже стали называть манипуляционной частью модели). Краткого рассмотрения заслуживает приведенное в статье определение отношения. Определение выглядит примерно так: "Для данных множеств S1, S2, ..., Sn (не обязательно различных) R является отношением над этими множества, если является множество n-арных кортежей, первый элемент каждого из которых принадлежит S1, второй - S2 и т.д. Мы будем называть Sj j-м доменом R ... Будем говорить, что R имеет степень n." (И в статье 1970-го года добавлено: "Более точно, R является подмножеством декартова произведения своих доменов.")

Являясь приемлемым с математической точки зрения, это определение может быть подвергнуто критики с точки зрения баз данных -- здесь вступает в действие уравновешенный взгляд в прошлое! -- в нескольких отношениях. Во-первых, не проводится ясное различение между доменами, с одной стороны, и атрибутами или столбцами, с другой стороны. Правда, в статье позже вводится термин "атрибут", но отсутствуют его формальное определение и согласованное использование. (В статье 1970-го года вводится термин "активный домен" для обозначения множества значений данного домена, действительно появляющихся в базе данных в любой заданный момент времени, но и это понятие не является тем же самым, что понятие атрибута.) В результате, в индустрии существовала большая путаница вокруг различий доменов и атрибутов, и эта путаница сохраняется и по сей день. (Для справедливости я должен добавить, что в первой редакции моей книги "An Introduction to Database Systems", Addison-Wesley, 1975 различие между доменами и атрибутами тоже было не слишком ясным.)

Далее в статье 1969-го года приводится пример, который -- по крайней мере, на интуитивном уровне -- наталкивается на эту путаницу.
В примере используется отношение PART с двумя (помимо других) столбцами QUANTITY_ON_HAND и QUANTITY_ON_ORDER. Кажется очевидным, что эти два столбца должны были бы определены на одном и том же домене, но пример ясно говорит - нет. (Автор относится к ним как к разным доменам, а потом говорит, что эти домены "соответствуют тому, что обычно называют ... атрибутами".)

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

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

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


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

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

Между прочим, в статье 1970-го года термин "первичный ключ" используется вместо просто "ключа". Поэтому обратите внимание, что "первичный ключ" в статье 1970-го года используется не в том смысле, в каком обычно понимается сегодня, потому что:

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

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

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

Реляционные расширители

На основе представленной выше объектной инфраструктуры могут

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

прикладных областей. Далее будут обсуждены свойства одного из

таких расширителей - Text Extender, а также приведена краткая

характеристика других расширителей, существовавших для DB2 к

моменту написания статьи.

Text Extender. Этот расширитель поддерживает быстрый контекстный поиск в больших текстовых документах. Не требуется, чтобы

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

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

форматах, включая Microsoft Word, Word Perfect и AmiPro. Для

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

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

(например, CLOB). Расширитель создает специального рода индекса

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

этот индекс для поиска документов, содержащих желаемые комбинации

слов и фраз.

Поскольку документы используемые с применение Text Extender

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

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

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

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

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

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

Newsweek в 1990 г. и содержащих слова "Iraq" и "embargo" в одном

параграфе.

Подобно всем UDF, функции, реализованные в Text Extender, могут

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

таких функций является функция CONTAINS, возвращающая значение 1,

если данный документ соответствует заданному шаблону поиска.

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

операциями "&" (и), "|" (или) и NOT. В шаблоне можно также

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

одном предложении или параграфе. Например, следующий запрос

предназначен для поиска статей, содержащих слова "cooking" и либо

"Chinese" либо "Japanese" в любом порядке, но не содержащих слово

"sishi":

SELECT magazine, date, title

FROM articles

WHERE CONTAINS(articletext,

'("cooking"

& ("Chinese" | "Japanese")

& NOT "sushi")') = 1;

Reminiscences on Influential Papers

Richard Snodgrass, editor

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

Laura Haas, IBM Almaden Research Center,

[P. Selinger, M. Astrahan, D. Chamberlin, R. Lorie and T. Price, "Access Path Selection in a Relational Database Management System", in Proceedings of the ACM SIGMOD International Conference on Management of Data, pp. 23-34, Boston, 1979]

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

Alberto Mendelzon, Computer Science Department, University of Toronto,

[A.V. Aho, C. Beeri, and J.D. Ullman, "The Theory of Joins in Relational Databases", ACM Transactions on Database Systems, 4(3) : 297-314, September 1979]

В последнем номере Record Джефф Ульман вспоминал курс по базам данных Катриэла Бири в Пристоне в районе 1977 г. Эта статья (представленная в TODS в марте 1978 г.) была одним из первых продуктов, полученных на основе фермента курса Катриэля. Обсуждался следующий вопрос: при каких условиях набор функциональных зависимостей гарантирует, что любое отношение, удовлетворяющее этому набору, может быть декомпозировано без потерь информации? Для специального случая декомпозиции одного отношения в два решение было получено годом раньше Делобелем (Delobel) и Кейзи (Casey), а также Риссаненом (Rissanen), и в рукописи распространялось некорректное обобщение этого результата, полученное известными исследователями.

Будучи аспирантом и читая ранний вариант того, что потом стало известно как статья ABU, я поражался несколькими фактами: теория баз данных была настолько тонкой, что даже хорошо известные исследователи могли делать ошибки; что загадочный феномен "ловушки связи" ("connection trap"), обсуждавшийся в то время, можно было точно формализовать и проанализировать; что допускался юмор, так что Теорема 2 называлась "Теоремой Микки Мауса" по причинам, которые становились очевидными при взгляде на соответствующий рисунок (к сожалению, это название не вошло в опубликованный вариант статьи).

Простой и элегантный алгоритм проверки отсутствия потерь, который Джефф и Ал Ахо называли "нисходящей прогонкой зависимостей", явился стартовой точкой для Шаки Сагива (Shuky Sagiv), Дейва Майера (Dave Maier) и меня, в то время аспирантов, в работе, которая стала называться методом прогонки, остающемся и сегодня важным теоретическим средством. На самом деле, почти в то же самое время, когда выйдет этот номер Record, на конференции ICDT'99 в Иерусалиме будет представлена статья, в которой прогонка применяется к весьма современной теме интеграции информации; сопредседатель этой конференции никто иной как Катриэл Бири.



Meral Ozsoyoglu, Department of Computer Engineering and Science, Case Western Reserve University,

[P.A. Bernstein and D-M. W. Chiu. "Using Semi-joins to Solve Relational Queries", Technical Report No. CCA-79-01, Computer Corporation of America, 1979. (Also in JACM 28(1) : 25-40, 1981)]

Эта статья оказала наибольшее влияние на мои исследования. Когда я первый раз читал статью Берстейна и Чью в виде технического отчета в 1979 г., я был аспирантом в университете Альберты, и мой руководитель переехал в Чикаго. В это время я старался найти тему диссертации из области оптимизации запросов и прочитал несколько статей по обработке запросов и распределенным базам данных. Я заметил, что обработка некоторых запросов по их природе обходится более дорого, чем обработка некоторых других запросов, но не мог это формализовать. В отличие от других статей, которые основывались на эвристике, Бернстейн и Чью использовали очень новый подход: они классифицировали запросы на древовидные и циклические, ввели операцию полусоединения и показали, что в то время как ответы на древовидные запросы всегда могут быть получены с помощью полусоединения, для циклических запросов это может быть не так. Они также представили алгоритм для определения того, является ли запрос древовидным. Я был поражен, когда увидел, что этот алгоритм не применим к некоторым примерным запросам, которые я раньше, когда пытался построить схему оптимизации запросов, считал "типичными". Это побудило меня начать работать над обобщенным алгоритмом распознавания древовидных запросов и завершилось созданием диссертации про оптимизацию распределенных запросов на основе полусоединений. Наш алгоритм (созданный в соавторстве с моим руководителем C. Yu) был опубликован в том же году на конференции IEEE COMPSAC'79. (Алгоритм Бернстейна и Чью был органичен случаем наличия не более одного атрибута соединения между двумя отношениями, т.е. полусоединениями с одним доменом.) Это была моя первая аспирантская статья и стартовая точка моей исследовательской работы.


В литературе этот алгоритм распознавания древовидных запросов позже стали называть "GYO-редукцией" (GYO Reduction).

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

Jan Paredaens, Department of Mathematics and Computer Science, University of Antwerp,

[A.K. Chandra and D. Harel, "Computable Objects for Relational Data Bases", Journal of Computer and System Science, 21 : 156-178, 1980]

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

Krithi Ramamrithan, Department of Computer Science, University of Massachusetts, on leave at the Department of Computer Science and Engineering, Indian Institute of Technology, Bombay,

[C.T. Davies, Jr., "Data Processing Spheres of Control", IBM Systems Journal, 17(2) : 179-199, 1978]

Девис (в сотрудничестве с L.J. Bjork) ввел единую абстрактную управляющую структуру, а именно "сферы управления" (Spheres of Control) для достижения гибкой семантики почти каждого аспекта выполнения транзакций: атомарности процессов (читай - транзакций), фиксируемости, зависимостей между транзакциями, управления многопользовательским доступом, согласованности и восстановления.


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

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

Nick Roussopoulos, Department of Computer Science, University of Maryland,

[J. Gray, A. Bosworth, A. Layman and H. Pirahesh, "Data Cube: A Relational Aggregation Operator Generalizing Group-By, Cross-Tab, and Sub-Totals", in Proceedings of the IEEE International Conference on Data Engineering, pp. 152-159, New Orleans, February, 1996]



Я впервые услышал об операции "Data Cube" Грея и Ко. с горячего западного побережья в 1995 г. на сипмозиуме CIKM'95 в Балтиморе. Я немедленно послал Джиму e-mail с просьбой прислать статью и получил в ответ URL его набора статей на новом его работе в Microsoft. Я скачал статью и начал ее читать, но, к моему разочарованию, рисунки, которые в этом конкретном случае стоят больше тысяч слов, были перечеркнуты надписями с каким-то бормотанием Microsoft. Я полагаю, что Джим еще осваивал программное обеспечение Microsoft! Тем не менее, я смог извлечь основные идеи до Ново-Орлеанской конференции, где смог увидеть эти рисунки.

Для области OLAP и складов данных значимость статьи про Data Cube эквивалентна значимости статьи Теда Кодда 1970-го г. для реляционных баз данных. В ней формализуются понятия многомерных агрегатных представлений и иерархии между ними. Она также устанавливает исходные идеи о сложности инкрементальных алгоритмов поддержки различных агрегатных функций. Эта статья громадно повлияла на мои исследования организации хранения на основе кибердеревьев (cybertrees) и их массового обновления. В 1995 г. я работал над материализованными представлениями с агрегатами и другими функциональными абстракциями. Для этого было самое время. Спасибо Джиму, Адаму, Эндрью и Хамиду.

Jennifer Widom, Departament of Computer Science, Stanford University,

[Patricia G. Selinger, Morton M. Astrahan, Donald D. Chamberlin, Raymond A. Lorie and Thomas G. Price, "Access Path Selection in a Relational Database Management System", in Proceedings of the ACM SIGMOD International Conference on Management of Data, pp. 20-34, Boston, 1979]

Мне повезло быть одним из ранних участников этой серии "влиятельных статей", поскольку я предполагаю, что эта конкретная статья будет появляться снова и снова [редактор: я действительно получил этот материал раньше, чем опубликованный выше материал Лауры]. Я думаю, что эта статья повлияла на меня иначе, чем на большинство других людей -- для меня она имела большей частью педагогическое значение.


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

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

Phillip Yu, IBM IAC, T.J. Watson Research Center,

[R. Agrawal, T. Imielinski and A. Swami, "Mining Association Rules between Sets of Items in Large Databases", in Proceedings of the ACM International Conference on Management of Data, pp. 207-216, May 1993, Washington, DC]

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

Репликация

В DB2 v.5 включен продукт DataPropagator, позволяющий производить

реплицирование мгновенных снимков (snapshot) или обновляемых

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

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

на операционной рабочей загрузке. Кроме того, в DB2 v.5 появились

существовавшие ранее в Oracle средства симметричной репликации и

разрешения конфликтов. В Oracle8 улучшен процесс обновления

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

основанных на триггерах методов Oracle7. Используемая в DB2 и

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

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

минусы.

Seth Grimes, consultant in database and Internet design and development with Alta Plana Corp., ,

( DBMS, vol.11, N 3, March 1998. Оригинал статьи можно найти по адресу )

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

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

данными (ОРСУБД) серьезно влияет на технологию современных

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

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

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

гибкость объектно-ориентированного кузина. Проектировщики баз

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

языками определения данными (DDL - Data Definition Languages),

усваивая при этом новые возможности управления объектами. Языки

запросов и процедурные языки ОРСУБД также знакомы: SQL3,

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

интерфейсы вызовов являются расширениями языков и интерфейсов

реляционных СУБД. Хорошо известны лидеры - IBM, Informix и

Oracle.

Но как обстоят дела со средствами проектирования баз данных?

Расширены ли они соответствующим образом, чтобы помочь

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

данных? Позволяют ли эти средства моделировать весь набор новых

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

операции, сложные объекты и наследование равно как и использовать

готовые объектные модули в форме Extenders, DataBlades и

Cartridges? Производят ли средства генерации физической схемы

хорошие скрипты DDL? Понимают ли они язык SQL3 и нюансы системных

каталогов IBM DB2 Universal Database, Informix Dynamic Server (с

опцией Universal Data) и Oracle8?

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

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

и проанализированы методологии моделирования, проанализированы

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

Описываются три не связанных с производителями СУБД системы:

OR-Compass (Logic Works Inc. - ), InfoModeler

3.1 (InfoModelers Inc., , теперь компания

является подразделением компании Visio Corp., ) и

Universal Moleler 1.0 (Silverrun Technologies Inc.,

).

Синергия

Большие объекты, определяемые пользователями типы и функции,

ограничения и триггеры представляют в отдельности мощные

возможности. Но истинная объектно-реляционная мощность DB2

происходит из синергии этих возможностей. В качестве примера

рассмотрим, как объектно-реляционные возможности DB2 могут быть

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

многоугольников.

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

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

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

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

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

BLOB. Но мы хотели бы отличить это представление от других

объектов типа BLOB и поэтому создадим индивидуальный тип POLYGON:

CREATE DISTINCT TYPE POLYGON AS

BLOB(1M);

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

внутри большого объекта. Например, это может быть

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

многоугольника, а следующие содержат координаты вершин.

После создания индивидуального типа желательное поведение

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

соответствующих UDF. По крайней мере одна из этих функций должна

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

простых типов, таких как POINT или DOUBLE. Работа

функции-конструктора состоит в упаковке примитивных частей

многоугольника в BLOB с последующим преобразованием типа BLOB к

типу POLYGON (для этого следует использовать сгенерированную

системой функцию преобразования типов POLYGON(BLOB).

Ниже перечислены некоторые из UDF, задающие поведение типа

POLYGON. Эти функции могут быть написаны, например, на языках Си

или Си++.

degree(Polygon) returns Integer;

area(Polygon) returns Double;

perimeter(Polygon) returns Double;

rotate(Polygon, Double) returns Polygon;

intersect(Polygon, Polygon) returns Polygon;

Теперь можно создавать таблицы со столбцами типа POLYGON.

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

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

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

собственности:

CREATE TABLE properties

(taxid Char(6) PRIMARY KEY,

owner Varchar(32),

assessment Dollars,

parcel Polygon);

Для нахождения собственников больших участков можно использовать следующий запрос на языке SQL:

SELECT owner, area(parcel)

FROM properties

WHERE area(parcel) > 20000;

Наиболее эффективный способ выполнения этого запроса мог бы

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

доступ к участкам по значению их площади. Поддержка индексов на

UDF находится в планах развития DB2, но пока ее нет. Но возможно

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

эффективностью. Добавим к таблице PROPERTIES новый столбец,

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

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

столбца. Для добавления столбца можно использовать оператор SQL

ALTER TABLE properties

ADD COLUMN area Double;

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

над таблицей PROPERTIES операторов INSERT и UPDATE. Вот как могло

бы выглядеть определение триггера для INSERT:

CREATE TRIGGER insertprop

NO CASCADE

BEFORE INSERT ON properties

REFERENCING NEW AS newrow

FOR EACH ROW MODE DB2SQL

SET newrow.area =

area(newrow.area);

Поскольку площадь каждого участка автоматически вычисляется и

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

по значению их площади можно создать индекс на столбце AREA:

CREATE INDEX proparea ON

properties(area);

Теперь перепишем запрос в форме, которая даст возможность DB2

использовать этот индекс:

SELECT owner, area

FROM properties

WHERE area > 20000;

Системные крахи

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

Скалярные и не скалярные типы

В The Third Manifesto авторы требуют поддержки генераторов типа TUPLE и RELATION; в результате пользователи могут определять свои собственные типы кортежей и отношений. Кроме того, требуется, чтобы пользователи могли определять "простые" типы, такие как POINT, LENGTH, AREA, LINE и т.д., возможно, даже типы, подобные INTEGER, если система не обеспечивает их как встроенные типы. И термин "скалярный тип" относится к таким "простым" типам (после чего можно говорить о скалярных значениях, скалярных переменных и скалярных операциях).

Причины выбора термина "скаляр" заключались в следующем:

он уже используется (используется в том же смысле в течение многих лет в мире языков программирования); термин кажется корректным по сравнению с такими терминами как tuple и relation (а также array, list и прочее); термин корректен, хотя физическое представление "скалярных" значений и переменных может быть произвольно сложным; например, данное скалярное значение может иметь физическое представление в виде массива стеков списков символьных строк (снова подчеркнем важность различения типов и представлений).

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

Замечание: Можно говорить, что скалярные (или, если это больше нравится, инкапсулированные типы) являются атомарными, поскольку не содержат видимых пользователям компонентов.

Следующее поколение

Как будут выглядеть базы данных в 2003 г.? Следующие идеи не являются революционными; фактически, все они происходят из исследований и передовых разработок середины и конца 80-х. Многие возможности присутствуют в коммерчески доступных продуктах.

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

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

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

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

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

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

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


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

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

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

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

Станут общераспространенными темпоральные базы данных. Хотя возможности поддержки темпоральных (ориентированных на время) данных уже присутствуют во многих продуктах, они редко используются в основном потоке приложений. Обычно для поддержки времени создаются отдельные таблицы (например, END-OF-LAST-MONTH-INVENTORY), и разработчики обрабатывают темпоральные операции с использованием SQL и клиентских средств запросов.


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

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

Будут возрастать возможности VLDB (сверхбольших баз данных). Следует ожидать, каждый лидирующий продукт СУБД сможет легко управлять многотерабайтными базами данных.

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

Сложность

В последней части статьи Дейт говорит, что ожидает очевидной

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

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

относительно этого свойства его схемы.

Во-первых, беглый взгляд на критику Дейта многозначной логики

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

результате чего увеличивается вероятность ошибок. Мне кажется

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

сложности. Возможно, он будет объяснять нам, что сложность MVL

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

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

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

схемой Дейта, существует только по одной причине: потому что

семантика схемы либо некорректна (для равенств), либо не

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

больше и меньше).

Наконец, я не сомневаюсь, что Дейт найдет много слов в ответ. Но

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

последним, занимает лучшую позицию.

Сложные типы данных

UDB v.5 содержит встроенную поддержку контекстного поиска в

тексте; графических, аудио, видео и других типов данных;

временных рядов; пространственных типов данных и т.д. Имеется

возможность адресовать один оператор SQL как к традиционным типам

данных, так и сложным данным. Потребители или разработчики

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

("расширители" - "extenders"), используя инструментальные

средства, поступающие вместе с UDB.

Сложные данные в Oracle8 поддерживаются механизмом "катриджей

данных" ("Data Catridges). Хотя в предыдущих версиях Oracle

поддерживались текстовые, графические, видео и пространственные

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

в DB2. Для "слабого связывания" ("loosely couple") катриджей

данных был выбран подход брокеров объектных заявок (Object

Request Broker - ORB). Если подход IBM ориентирован на

обеспечение большей производительности, то подход Oracle

облегчает включение расширений в систему и их отключение от

системы. Обе компании работают с независимыми производителями

программного обеспечения (Indepedent Software Vendors - ISV), и в

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

Oracle использует более широкое определение объектно-реляционного

подхода, чем IBM. Подход Oracle существенно более

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

поддержке объектно-реляционных данных. Тем не менее, по словам

специалистов компании Oracle, планируемая полная поддержка

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

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

расширителей с использованием инструментального набора

разработчика (Software Developer's Kit - SDK), содержащие

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

типов данных и функций, написанных на языках Java, Basic, Cobol и

Си/Си++. Компания Oracle планировала обеспечить аналогичные

возможности в своем проекте Sedona, целью которого являлось

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

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

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

могут создаваться с использованием Java, JavaScript, Си/Си++,

Visual Basic, а также языков, основанных на SQL, и средств

Developer/2000.

SQL Commandments ()

Suresh Aiyer, senior consultant based in Washington, D.C.

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

В статье кратко обсуждаются 25 приемов, позволяющих добиться более быстрого выполнения операторов SQL. Некоторые из этих приемов ранее описывались в руководствах компании Oracle и журналах, а многие другие ранее не публиковались.

1. Хорошо знайте свои данные и бизнес-приложение.

Идентичная информация часто может быть получена из разных источников. Познакомьтесь с этими источниками; вы должны быть в курсе объема данных и их распределения в своей базе данных. Вы также должны иметь полное понимание используемой модели данных (равно как и связей между разными бизнес-объектами) до написания требуемых операторов SQL. Это понимание поможет намного лучше составлять запросы для извлечения информации из нескольких таблиц. CASE-средства, подобные Designer/2000, очень помогают документировать связи между различными объектами.

2. Тестируйте свои запросы на реалистических данных.

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

3. Пишите в своих приложениях идентичные операторы SQL.

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

select * from employee where empid = 10; SELECT * FROM EMPLOYEE WHERE EMPID = 10; select * from employee where empid = 20;

но при использовании связываемой переменной с именем i_empid оператор select * from employee where empid = :i_empid;

будет идентичным.

4. Внимательно относитесь к использованию индексов на таблицах.

Постарайтесь создать все необходимые индексы. Однако слишком большое число индексов может привести к снижению эффективности. Как же решить, какие столбцы следует индексировать?

Создавайте индексы на столбцах, которые часто используются в разделе WHERE встроенных операторов SQL или запросов, используемых конечными пользователями. Индексируйте столбцы, часто используемые в операторах SQL для соединения таблиц. Используйте для индексирования только те столбцы, в которые входит небольшой процент строк с одним и тем же значением. Не индексируйте столбцы, которые используются только в функциях и операторах раздела WHERE запросов. Не индексируйте часто изменяемые столбцы, а также не применяйте индексацию в тех случаях, когда повышение эффективности за счет создания индекса приводит к снижению эффективности при выполнении операций INSERT, UPDATE и DELETE. Выполнение этих операций замедлится из-за необходимости поддерживать индексы. Уникальные индексы лучше неуникальных по причине их более высокой селективности. Используйте уникальные индексы на столбцах первичного ключа и неуникальные индексы на столбцах внешнего ключа и столбцах, часто используемых в разделе WHERE. Создавайте индексы таким образом, чтобы столбцы, используемые в разделе WHERE составляли начальную группу столбцов в ключе индекса.



5. Делайте доступными к использованию индексные пути доступа к данным.

Для получения преимуществ от наличия индексов пишите SQL-операторы таким образом, чтобы для их выполнения были доступны индексные пути доступа. Оптимизатор не может использовать индексный путь доступа, основываясь только на существовании индекса; путь доступа должен быть сделан доступным в SQL. Механизм "указаний" (hints) - это один из способов гарантировать использование индекса.

6. При возможности используйте Explain Plan и TKPROF.

Если ваши SQL-операторы недостаточно хорошо настроены, они могут быть неэффективны, даже если сама база данных Oracle "хорошо смазана". Познакомьтесь с Explain Plan и средства TKPROF, чтобы уметь с пользой их применять. Explain Plan помогает узнать путь доступа, используемый для выполнения оператора SQL; TKPROF показывает реальные показатели эффективности. Эти средства привязаны к программному обеспечению сервера баз данных Oracle и могут помочь улучшить эффективность выполнения операторов SQL.

7. Разберитесь в том, как работает оптимизатор.

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



8. Глобально думайте при выполнении локальных действий.

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

9. Раздел WHERE является критическим.

Для следующих примеров раздела WHERE индексный путь доступа не будет использоваться, даже если индекс существует (COL1 и COL2 - столбцы одной таблицы, и создан индекс на COL1):

COL1 > COL2 COL1 < COL2 COL1 >= COL2 COL1 COL1 IS NULL COL1 IS NOT NULL (В индексе не сохраняются идентификаторы строк - ROWID - для столбцов, содержащих неопределенные значения. Поэтому для выполнения запросов строк с неопределенными значениями индекс не может быть использован.) COL1 NOT IN (value1, value2) COL1 != expression COL1 LIKE '%patern' (В этом случае начальная составляющая ключа индекса не указывается и поэтому индекс не может быть использован. С другой стороны, для COL1 LIKE 'patern%' и COL1 LIKE 'patern%patern%' индекс может использоваться в режиме сканирования в диапазоне значений ключа.) NOT EXISTS subquery expression1 = expression2 (Любые выражения, функции и вычисления, включающие индексированные столбцы, препятствуют использованию индекса. Например, в следующем примере наличие функции UPPER не дает возможность использовать сканирование по индексу, и будет применен полный просмотр таблицы:

SELECT DEPT_NAME FROM DEPARTMENT WHERE UPPER(DEPT_NAME) like 'SALES%');

10. Для фильтрации записей используйте WHERE, а не HAVING.

Избегайте использования раздела HAVING вместе с GROUP BY на индексированных столбцах. В этом случае индекс не используется. Фильтруйте строки с помощью раздела WHERE, а не раздела HAVING. Если для таблицы EMP существует индекс на столбце DEPTID, в при выполнении следующего запроса этот индекс использоваться не будет:

SELECT DEPTID, SUM(SALARY) FROM EMP GROUP BY DEPTID HAVING DEPTID = 100;

Однако этот запрос можно переписать так, чтобы индекс применялся:

SELECT DEPTID, SUM(SALARY) FROM EMP WHERE DEPTID = 100 GROUP BY DEPTID;



11. Указывайте в разделе WHERE начальные столбцы ключа индекса.

При наличии индекса с составным ключом этот индекс может быть использован, если в разделе WHERE фигурируют условия на начальные столбцы его ключа. Для следующего запроса может быть применен составной индекс на столбцах PART_NUM и PRODUCT_ID, образованный в связи с ограничением первичного ключа:

SELECT * FROM PARTS WHERE PART_NUM = 100;

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

SELECT * FROM PARTS WHERE PRODUCT_ID = 5555;

Последний запрос можно переписать так, чтобы индекс можно было применить. В этом запросе предполагается, что столбец PART_NUM будет всегда содержать положительные значения:

SELECT * FROM PARTS WHERE PART_NUM > 0 AND PRODUCT_ID = 5555;

12. Сравните сканирование через индекс с полным просмотром таблицы.

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

SELECT * --+FULL FROM EMP WHERE SALARY = 50000; SELECT * FROM EMP WHERE SALARY+0 = 50000;

Для выполнения следующего запроса также не будет применяться индексное сканирование, даже если существует индекс на столбце SS#:

SELECT * FROM EMP WHERE SS# '' = '111-22-333';

Индекс не используется и в том случае, когда Oracle-сервер должен выполнять неявное преобразование данных. В следующем примере SALARY является числовым столбцом таблицы EMP, и символьное значение преобразуется в числовое:

SELECT * FROM EMP WHERE SALARY = '50000';

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


Чтобы проиллюстрировать эту мысль, предположим, что команда ANALYZE применяется к таблице EMP и всем ее индексам. Oracle генерирует следующую статистическую информацию в таблицах-каталогах USER_TABLES и USER_INDEXES:

Table Statistics: NUM_ROWS = 1000 BLOCKS = 100

Index Statistics: BLEVEL = 2 AVG_LEAF_BLOCKS_PER_KEY = 1 AVG_DATA_BLOCKS_PER_KEY = 1

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

При использовании индекса для выбора одной строки - 3: (BLEVEL + (AVG_LEAF_BLOCKS_PER_KEY - 1) + AVG_DATA_PER_KEY).

При полном просмотре таблицы без индекса - 100.

При использовании индекса для выбора всех строк - 3000: (NUM_ROWS * число блоков, чтение которых нужно для выбора одной строки).

13. Используйте ORDER BY для индексного сканирования.

Оптимизатор Oracle будет использовать индексное сканирование, если запрос содержит раздел ORDER BY с указанием индексированного столбца. Для выполнения следующего запроса будет использован индекс на столбце EMPID, даже если этот столбец не используется в условиях раздела WHERE. Для каждой строки из индекса будет извлекаться ROWID, а потом с использованием ROWID будет производиться обращение к строке.

SELECT SALARY FROM EMP ORDER BY EMPID;

Если запрос будет плохо выполняться, можно попробовать переписать его с использованием указания FULL (см. 12-ую заповедь).

14. Знайте свои данные.

Как отмечалось выше, вы должны быть близко знакомы со своими данными. Например, пусть имеется таблица с именем BOXER и двумя столбцами BOXER_NAME и SEX. Для столбца SEX существует неуникальный индекс. Если имеется равное число боксеров мужского и женского пола, то следующий запрос будет быстрее выполнен путем полного просмотра таблицы:

SELECT BOXER_NAME FROM BOXER WHERE SEX = 'F';

Можно гарантировать такой способ выполнения, включив в запрос указание FULL.

Если же таблица содержит 98% строк, относящихся к боксерам-мужчинам, то следующий запрос будет выполнен быстрее по причине использования индексного сканирования:



SELECT BOXER_NAME --+ INDEX ( BOXER SEX) FROM BOXER WHERE SEX = 'F';

Этот пример иллюстрирует, насколько важно знать распределение данных. Эффективность выполнения SQL-запросов будет сильно меняться при росте размеров базы данных и изменении распределения данных. В Oracle 7.3 была включена функция HISTOGRAMS, позволяющая оптимизатору быть в курсе распределения данных в таблице и выбирать соответствующий план выполнения запроса.

15. Знайте, когда использовать просмотр больших таблиц.

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

16. Минимизируйте число просмотров таблиц

Обычно уменьшение числа просмотра таблиц в SQL-запросах приводит к повышению эффективности. Запросы с меньшим числом просмотров таблиц - более быстрые запросы. Вот пример. Таблица STUDENT содержит четыре столбца с именами NAME, STATUS, PARENT_INCOME и SELF_INCOME. Имя является первичным ключом. Значение статус равно 0 для независимых студентов и 1 - для зависимых студентов. Следующий запрос возвращает имена и величину доходов независимых и зависимых студентов. Форма запроса предполагает два просмотра таблицы STUDENT, создание временной таблицы для последующей обработки и сортировку для устранения дубликатов:

SELECT NAME, PARENT_INCOME FROM STUDENT WHERE STATUS = 1 UNION SELECT NAME, SELF_INCOME FROM STUDENT WHERE STATUS = 0;



Тот же самый результат будет получен при выполнении запроса с одним просмотром таблицы:

SELECT NAME, PARENT_INCOME * STATUS + SELF_INCOME * (1 - STATUS) FROM STUDENT;

17. Соединяйте таблицы в правильном порядке.

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

При использовании оптимизатора, основанного на правилах, главная таблица должна указываться последней в списке раздела FROM. Если применяется метод вложенных циклов, следует обдумать целесообразность создания индекса для убыстрения поиска во внутреннем цикле. Средства Explain Plan и TKPROF позволяют получить информацию о применяемом методе выполнения соединения, порядке соединения таблиц и числе строк, обрабатываемых на каждой фазе соединения.

В случае применения оптимизатора на основе оценок порядок, в котором таблицы указаны в разделе FROM, не является существенным для оптимизатора, который всегда пытается найти наилучший план выполнения запроса. Для управления порядком соединения таблиц можно использовать указание ORDERED. При выполнении следующего запроса таблицы были бы соединены в том порядке, в котором они указаны в разделе WHERE:

SELECT ORDERS.CUSTID, ORDERS.ORDERNO, ORDERS_LINE_ITEMS.PRODUCTNO --+ORDERED FROM ORDERS, ORDERS_LINE_ITEMS WHERE ORDERS.ORDERNO = ORDER_LINE_ITEMS.ORDERNO;



18. При возможности используйте только поиск через индексы.

Тогда для выполнения запросов оптимизатор будет нуждаться только в поиске в индексе, а не в таблице, и эффективность будет лучше. Оптимизатор будет использовать только поиск в индексе, если вся информация, необходимая для выполнения запроса, содержится в самом индексе. Если для таблицы EMP существует составной индекс на столбцах LNAME и FNAME, то при выполнении следующего запроса будет использован только поиск в индексе:

SELECT FNAME FROM EMP WHERE LNAME = 'SMITH';

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

SELECT FNAME, SALARY FROM EMP WHERE LNAME = 'SMITH';

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

19. Избыточность полезна.

Помещайте в раздел WHERE как можно больше информации. Например, если указан раздел WHERE COL1 = COL2 AND COL1 = 10, оптимизатор сможет вывести, что COL2 = 10. Но при задании раздела в форме WHERE COL1 = COL2 AND COL2 = COL3, оптимизатор не будет считать, что COL1 = COL3.

20. Старайтесь писать как можно более простые и тупые операторы SQL.

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

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


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

21. Одного и того же можно добиться разными способами.

Во многих случаях одни и те же результаты могут быть получены с использованием разных операторов SQL. Для выполнения таких операторов могут применяться разные пути доступа. Например, оператор MINUS может выполняться гораздо быстрее, чем запросы с WHERE NOT IN (SELECT) или WHERE NOT EXISTS. Предположим, что имеются индексы на столбце STATE и столбце AREA_CODE. Несмотря на наличие этих индексов для выполнения следующего запроса потребуется полный просмотр таблицы (по причине использования предиката NOT IN):

SELECT CUSTOMER_ID FROM CUSTOMERS WHERE STATE IN ('VA', 'DC', 'MD') AND AREA_CODE NOT IN (804, 410);

Однако этот запрос может быть переписан с использованием оператора MINUS, что позволит использовать индексное сканирование:

SELECT CUSTOMER_ID FROM CUSTOMERS WHERE STATE IN ('VA', 'DC', 'MD') MINUS SELECT CUSTOMER_ID FROM CUSTOMERS WHERE AREA_CODE IN (804, 410);

Если в разделе WHERE запроса содержится OR, такой запрос может быть переписан с заменой OR на UNION. Прежде, чем решиться использовать вариант SQL-запроса, тщательно сравните планы выполнения всех возможных вариантов.

22. Используйте специальные столбцы.

Не забывайте о наличии специальных столбцов ROWID и ROWNUM. Помните, что доступ к строке по ROWID является самым быстрым. Вот пример оператора UPDATE, в котором используется сканирование по ROWID:

SELECT ROWID, SALARY INTO TEMP_ROWID, TEMP_SALARY FROM EMPLOYEE; UPDATE EMPLOYEE SET SALARY = TEMP_SALARY * 1.5 WHERE ROWID = TEMP_ROWID;

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

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



SELECT EMPLOYEE.SS#, DEPARTMENT. DEPT_NAME FROM EMPLOYEE, DEPARTMENT WHERE EMPLOYEE.DEPT_ID = DEPARTMENT.DEPT_ID AND ROWNUM < 100;

23. Явные курсоры предпочтительнее неявных.

При использовании неявных курсоров требуется лишнее чтение. Для работы с явными курсорами используются операторы SQL DECLARE, OPEN, FETCH и CLOSE. Неявные курсоры в СУБД Oracle открываются для операторов DELETE, UPDATE, INSERT и SELECT.

24. Исследуйте возможности опции параллельного выполнения запросов и используйте ее преимущества.

Эта опция дает возможность параллельного выполнения операторов SQL с целью убыстрения. В Oracle7 параллельно могли выполняться только запросы с полным просмотром таблицы. В Oracle8 могут быть распараллелены и запросы с индексным сканированием в заданном диапазоне значений ключа, если индекс является разделенным. Опция можно использовать только в системах SMP и MPP с несколькими дисковыми устройствами. В сервере Oracle имеется много возможностей, но наличие этих возможностей само по себе не гарантирует повышенную эффективность. Необходимо соответствующим образом конфигурировать базу данных и специально оформлять операторы SQL. Например, следующий оператор SQL мог бы быть выполнен параллельно:

SELECT * --+PARALLEL(ORDERS,6) FROM ORDERS;

25. Сокращайте сетевой трафик и увеличивайте пропускную способность сети.

Использование обработки массивов и блоков PL/SQL может повысить эффективность и снизить сетевой трафик. Обработка массивов позволяет с помощью одного оператора SQL обработать несколько строк. Например, использование массивов в операторе INSERT позволяет за одно обращение к серверу занести в таблицу 1000 строк. Использование большого числа операторов SQL перегружает сетевой трафик. Однако, если операторы SQL содержатся в одном блоке PL/SQL, то можно послать весь блок на Oracle-сервер, обработать их и получить результаты на стороне клиента.

Среднее звено

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

взаимодействий точка-точка или клиент-сервер существует тенденция

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

проведения прикладной обработки. Выше уже обсуждались

соответствующие возможности TP-мониторов, но имеются и другие

варианты. Например, наряду с обеспечением коммуникационных

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

обработки. Аналогично модели TP-мониторов, но в несколько более

распределенной и неоднородной среде ORB'ы могут существовать на

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

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

ORB могут вызывать методы локального или удаленного ORB через

протокол IIOP. Идея состоит в создании единого приложения с

объектами, существующими в нескольких узлах сети. Но ORB'ы и

TP-мониторы не заполняют весь рынок промежуточного ПО среднего

звена. Имеется много других фирменных решений. Например, Midas

компании Borland будет работать с большинством инструментальных

средств (в настоящее время

поддерживается только Delphi 3.0) и позволит разработчикам

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

механизма ORB продукта Midas. Инфраструктура Midas основана на

DCOM. IBM сражается с

со своим новым продуктом промежуточного ПО, называемым Business

Object Server, библиотека классов которого дает приложениям

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

Более старое промежуточное ПО среднего звена можно вообще не

считать промежуточным ПО. Компании Fort Software Inc. и Dynasty

Technologies Inc. имеют собственные решения ORB, поддерживающие

их средства разделения приложений. Разработчики строят

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

мигрируют на другие серверы. Для общения объектов используется

механизм передачи сообщений. В продукте Dynasty служба транзакций

реализована с использованием Tuxedo. Оба продукта поддерживают

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

CORBA и MOM. В продукте Cactus компании IBM

используется аналогичный механизм, построенный над EDA/SQL.

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

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

объектно-реляционных баз данных - OR-Compass (Logic Works),

InfoModeler (Visio Corp.) и Universal Modeler (Sileverrun

Technologies Inc.). Каждое из этих средств позволяет

специфицировать физические свойства базы данных - внешнюю память,

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

баз данных напрямую в базе данных или (за исключением

InfoModeler) в файлах, содержащих операторы определения данных.

Статья 1969-го года

Теперь я хочу сосредоточиться на статье 1969-го года (хотя буду также упоминать некоторые моменты, где размышления в статье 1970-го года развивают или заменяют то, что содержалось в версии 1969-го года). Статья 1969-го года -- которая, чтобы напомнить, называлась "Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks" -- состояла из введения и следующих шести разделов:

Реляционное представление данных Некоторые лингвистические аспекты Операции над отношениями Выражаемые, Именованные и Хранимые отношения Порождаемость, Избыточность и Согласованность Управление Банком Данных.

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

Статья 1970-го года

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

Реляционная модель и нормальная форма
1.1. Введение
1.2. Зависимости данных в существующих системах
1.3. Реляционное представление данных
1.4. Нормальная форма
1.5. Некоторые лингвистические аспекты
1.6. Выражаемые, именованные и хранимые отношения Избыточность и согласованность
2.1. Операции над отношениями
2.2. Избыточность
2.3. Согласованность
2.4. Заключение

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

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

Support for Data Warehouses

Patrick O'Neil

Professor of Computer Science at the University of Massachusetts at Boston

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

использования параллелизма. Чтобы просто прочитать терабайт

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

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

один запрос на большом числе недорогих процессоров. Оптимизатор

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

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

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

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

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

решения задачи эффективности склада данных. Без использования

максимально совершенной техники индексации оптимизатор запросов

оказывается в состоянии всего лишь использовать неэффективные

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

которые применяются в коммерческих приложениях.

В статье приводится введение в основные понятия эффективных

методов индексации для поддержки приложений класса DSS (Decision

Support System): битовые (bitmap) индексы и индексы соединений.

Затем рассматриваются новые возможности индексации, внедренные в

Informix Extended Parallel Server (XPS)

Битовые индексы похожи на традиционные индексы, основанные на

списках идентификаторов строк (RID - Row Identifier). Но битовые

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

выигрыш в производительности.

Начнем с определения списка RID. Каждой строке в таблице

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

строку на диске. Обычно RID состоит из номера страницы на диске и

номера позиции записи на этой странице. Набор строк с данным

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

большинстве СУБД используются 4-байтовые RID (хотя в Oracle RID

имеет длину по крайней мере 6 байт). Традиционно списки RID

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

ассоциированных с каждым значением некоторого индексируемого

столбца. Если предположить потребность в индексе на таблице

SALES, содержащей 100 миллионов строк и включающей столбец

department c 40 разными значениями, то для каждого значения этого

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

соответствовать 2.5 миллионам строк.

При наличии громадного числа RID, ассоциированных с каждым

значением department, трудно рассчитывать, что удастся целиком

переместить список RID в основную память. Список разбивается на

фрагменты по несколько сотен RID, которые могут быть помещены в

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

можно хранить в B-дереве только одно значение department, так что

критически остается лишь потребность в хранении 100 миллионов

4-байтовых RID.

Теперь мы готовы ввести идею битовой индексации. В таблице, для

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

перенумерованы: 0, 1, 2, ..., N-1. Нумерация строк должна

производиться в соответствии с порядком их RID (физически

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

Требуется метод преобразования номера строки в RID и наоборот.

Теперь, если имеется последовательность из N бит, установим k-тый

бит в 1, если строка с номером k входит в набор строк, а в

противном случае - в 0. Битовый индекс на SALES по столбцу

department аналогичен тому, который основан на RID, но вместо

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

фрагменты. Каждый битовый фрагмент будет занимать 12.5 Мб, так

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

диска. Отношение числа битов, установленных в 1, к общей длине

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

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

можно компрессировать. Пока же будем считать, что все фрагменты

обладают высокой плотностью.

В этом случае полный битовый индекс требует на листовом уровне

чуть больше 500 Мб внешней памяти, т.е.


больше, чем индекс,

основанный на RID. Однако ситуация меняется, если индексируемый

столбец содержит мало различных значений. Если, например, таблица

SALES содержит столбец gender (пол) со всего двумя значениями M и

F, то для листового уровня битового индекса потребуется всего 25

Мб, в то время как для RID-индекса по-прежнему было бы нужно

иметь 400 Мб. Для индексов с менее чем 32 значениями битовые

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

Однако наиболее важным свойством неупакованных битовых индексов

является не экономия памяти, а возможность существенно повысить

скорость выполнения операций AND, OR, NOT и COUNT. Предположим,

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

свойство gender = 'M', а B2 - department = 'sports'. Тогда для

получения битового фрагмента, соответствующего свойству B1 & B2,

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

B1 и B2.

Для выполнения операции AND над двумя списками RID требуется

более сложная техника: слияние с пересечением. Нужно использовать

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

и в результирующем списке остаются те RID, которые встречаются в

каждом из исходных списков.

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

десятков RID, то цикл со списками RID окажется более эффективным,

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

шкал, длина каждой из которых равна общему числу строк в таблице.

Но при плотности битовой шкалы большей, чем 1/100, алгоритм на

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

алгоритмами для выполнения операций OR, NOT и COUNT.

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

индексы работают плохо по сравнению с RID-индексами не только в

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

обменов с внешней памятью. Для решения обеих проблем требуется

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

внешней памяти, но в то же время позволил бы по-прежнему быстро



выполнять операции AND, OR, NOT и COUNT. Один из подходов состоит

в совместном использовании битовой и RID индексации: когда

битовый фрагмент становится слишком разреженным, он заменяется на

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

битовых шкал. В этом случае становится сложно эффективно

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

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

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

проблемой битовой индексации.

Операции соединения при выполнении SQL-запросов требуют больше

всего ресурсов по сравнению с другими реляционными операциями.

Производители СУБД реализовали несколько алгоритмов для

эффективного выполнения соединений (соединения путем слияния -

Merge Join, соединения на основе хэширования - Hash Join и т.д.).

Однако появившийся в последнее время новый специализированный

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

существенное ускорение многих запросов.

Индекс соединения обеспечивает средства, с помощью которых СУБД

может эффективно транслировать ограничения на столбец одной

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

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

строка которой является агрегацией данных о продажах конкретного

продукта для конкретного заказчика в конкретный день (это

называется грануляцией агрегации). SALES является таблицей фактов

и соединяется с таблицами, представляющими три измерения,-

CUSTOMER, PRODUCT и TIME через внешние ключи cid, pid и day.

Предположим, что следующий запрос является распространенным:

(SEL1)

SELECT SUM(dollar_sales), SUM(unit_sales)

FROM SALES s, CUSTOMERS c, PRODUCTS p, TIME t

WHERE s.cid = c.cid AND s.pid = p.pid AND s.day = t.day

AND t.month = 'May95' AND p.package_type = 'box'

AND c.gender = 'M'

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

этого запроса. В этом запросе столбец gender принадлежит таблице

CUSTOMER, но только столбцы таблицы SALES агрегированы;



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

соединения. Но предположим, что производится некоторая

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

SALES со всеми соответствующими строками CUSTOMER (для каждой

продажи имеется только один заказчик) и ограничим строки SALES

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

около половины строк SALES, что лучше всего представляется

битовой шкалой. Аналогично, можно ограничить строки SALES

условием, что заказчики - женщины, и создать соответствующую

битовую шкалу. Теперь создадим индекс на SALES с двумя значениями

"M" и "F" и свяжем две ранее полученных шкалы с этими значениями.

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

сама таблица SALES не содержит такого столбца. Этот индекс делает

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

CUSTOMERS при выполнении запроса. Такой индекс называется

индексом соединения внешнего столбца (FCJ - Foreign Column Join).

Чтобы еще больше сократить работу по выполнению запроса, можно

создать на таблице SALES FCJ-индексы для p.package_type и

t.month. Тогда оптимизатор запросов сможет выполнить этот запрос

с использованием только индексов на таблице SALES. FCJ-индекс

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

статье Valduriez P., "Join Indexes", ACM TODS, 12 (2), 218-246,

June 1987.

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

индекс соединения (MTJ - Multi-Table Index) на таблице SALES,

объединяющий столбцы нескольких таблиц - t.month, p.package_type

и c.gender. Хотя такие индексы позволяют еще больше повысить

эффективность соединения, их наличие может привести к

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

эффективности, возможно, пришлось бы создать MTJ-индекс для

каждой комбинации внешних таблиц, которая характерна для данной

рабочей загрузки системы. С другой стороны, число FCJ-индексов

возрастает только линейно с увеличением числа внешних столбцов.



По этой причине MTJ- индексы могут быть полезны только в

исключительно специальных ситуациях.

Возникает вопрос: если понадобится создать много индексов

соединения, не приведет ли это к деградации системы? Ответ: нет.

На платформах DSS, где отсутствуют параллельные изменения,

индексы соединения позволяют повысить эффективность выполнения

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

пространство.

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

предназначенных для поддержки DSS? Новая форма индекса,

называемая GK-индекс (Generalized Key) представляет гибкую

комбинацию традиционных и битовых индексных структур. Вот

синтаксис оператора CREATE GK INDEX:

CREATE GK INDEX INDEXNAME

ON T

(SELECT AS KEY X.c1 {, Y.c2, ...}

FROM T, X, Y, ...

WHERE }

);

В результате будет создан именованный индекс на таблице T. Раздел

SELECT AS KEY явно определяет значение ключа индекса, который

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

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

набора конкатенированных значений столбцов таблиц X, Y, ..., а

раздел WHERE будет специфицировать (среди прочего), каким образом

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

индекса, соединяются в результирующую строку. Список SELECT не

порождает какого-либо порядка таблиц. Он означает только то, что

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

из таблицы T будет выбираться только один столбец; в разделе FROM

не требуется указывать несколько таблиц.

GK-индекс обеспечивает большую гибкость длф создания новых типов

индексов. Например, ниже показано, как создать FCJ-индекс на

таблице SALES для обозначений пола в таблице CUSTOMER:

CREATE GK INDEX ORDERGENDER

ON SALES

(SELECT AS KEY c.gender

FROM SALES s, CUSTOMER c

WHERE s.cid = c.cid);

При наличии этого индекса оптимизатор SQL-запросов будет

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

без какой-либо потребности во вмешательстве пользователя.



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

операторов SELECT. В обоих случаях доступ к таблице CUSTOMER не

требуется.

SELECT SUM(s.dollar_sales) FROM CUSTOMER c, SALES s

WHERE s.cid = c.cid AND c.gender = 'M';

SELECT SUM(dollar_sales) FROM SALES

WHERE CID IN (SELECT CID FROM CUSTOMERS WHERE

c.gender = 'M');

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

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

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

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

выполнения звезднообразного оператора SELECT, приведенного выше

(SEL1).

CREATE GK INDEX ORDERSMPG

ON SALES

(SELECT AS KEY t.month, p.package_type, c.gender

FROM SALES s, TIME t, PRODUCT p, CUSTOMER c

WHERE s.day = t.day AND s.pid = p.pid

AND s.cid = c.cid);

Формат GK-индекса настолько гибок, что поддерживает совершенно

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

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

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

столбец по формуле:

profit_per_unit = (dollar_sales - dollar_cost) / unit_sales

Все три составляющих являются реальными столбцами таблицы SALES,

так что вычисление производится легко для каждой строки SALES.

Такой виртуальный столбец может быть определен с помощью

операторов CREATE TABLE или ALTER TABLE диалекта языка SQL

компании Informix. После этого виртуальный столбец можно

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

этого столбца можно создать GK-индекс с помощью простого оператора

CREATE GK INDEX PROFITX

ON SALES

(SELECT AS KEY profit_per_unit

FROM SALES);

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

при задании в разделе WHERE некоторого набора ограничений. Этот

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

("найденным набором"). Если имеется желание ограничить внимание в

таблице EMPLOYEES "технарями", можно определить следующий

селективный GK-индекс:

CREATE GK INDEX TECHIES

ON EMPLOYEES

(SELECT AS KEY 'constant'

FROM EMPLOYEES

WHERE hobby = 'math' AND reading = 'Dibert');

Informix старается добиться еще более высоких показателей эффективности в будущем.

Своевременность

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

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

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

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

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

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

Объектно-ориентированные реализации предполагают поддержку

реляционной модели данных. ОРСУБД являются постепенным развитием

предшествующих им реляционных СУБД. В отличие от чисто объектных

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

массового перепрограммирования. Подобно тому как компилятор Си++

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

учетом главным образом синтаксических отличий SQL-92 от SQL3

ОРСУБД должны поддерживать существующие реляционные схемы. Однако

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

поддержки репликации в Informix Universal Data Option или

наследования в Oracle8, так что детали реализации нужно держать в

уме.

Наиболее важными новыми объектно-реляционными возможностями

являются определяемые пользователями типы (UDT - User-Defined

Types), определяемые пользователями функции (UDF - User-Defined

Functions) и инфрастуктура (методы индексации и доступа, а также

усовершенствованные способы оптимизации). Определяемые

пользователями типы классифицируются на уточненные (distinct),

непрозрачные (opaque) и строчные (составные).

Уточненные типы, называемые также типами значений, порождаются из

других типов, но имеют свои собственные домены (допустимые

множества значений), операции, функции и преобразования типов.

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

ОРСУБД, что помогает гарантировать соблюдение целостности.

Непрозрачные типы не порождаются из имеющихся, их внутренняя

структура, равно как и операции, функции и преобразования типов

должны быть определены для СУБД. Определенный должным образом

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

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

Строчный тип представляет собой набор полей других типов; один

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

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

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

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

Типы коллекций, представляющие множества или списки значений

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

одним нововведением объектно-реляционного подхода.

Cartridges, DataBlades и Extenders - это модули, построенные на

основе объектно-реляционной инфраструктуры СУБД. Они состоят из

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

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

Sybase

Компания Sybase начала связывать свою стратегию со средой расширяемого управления данными после объявления адаптивной серверной архитектуры (Adaptive Server Architecture). Упор делается на компонентную разработку приложений, и Sybase планирует обеспечить поддержку объектных компонентов Java, ActiveX и CORBA на всех трех звеньях вычислительной среды.

В следующих выпусках своих продуктов, появление которых ожидается во второй половине 1997 г., компания обеспечит программное обеспечение приложений промежуточного уровня (Jaguar Component Transaction Server), которое можно было бы назвать промежуточным программным обеспечением баз данных для интегрированного доступа к сложным данным и для поддержки объектного уровня через инструментальные средства типа PowerBuilder.

На стороне сервера баз данных Sybase переносит в сервер сервисы распределенных запросов OmniConnect. Со временем эти компоненты будут реализованы для всех серверов Sybase и будут включать общий языковой процессор, общие сервисы (безопасность, передачу сообщений, репликацию, администрирования и т.д.) и общий интеграционный компонент. Последний из перечисленных компонентов позволит интегрировать в среду Adaptive Server хранилища данных сторонних поставщиков (SDT - Specialty DataTypes). SDT будут разрабатываться с использованием DirectConnect API, с помощью которого в прошлом обеспечивался доступ к неоднородным источникам данных. Хранилища данных останутся физически раздельными, но пользователи смогут выполнять запросы по отношению ко всем поддерживаемым типам данных. Со временем Sybase сможет обеспечить расширяемость на более нижних уровнях серверной архитектуры (например, на уровне оптимизатора).

Sybase не особенно распространяется о своих планах, но известны некоторые общие направления:

Расширяемая система типов - Sybase будет поддерживать сначала ADT языка Java, а в следующих версиях Adaptive Server - типы данных SQL-3.

Определяемые пользователями функции - сегодня скалярные UDF поддерживаются в SQL Anywhere. В будущих выпусках Adaptive Server будут поддерживаться Java-UDF, возвращающие скалярные значения или ссылки на Java-объекты.

Расширяемый оптимизатор - Sybase будет обеспечивать глобальную оптимизацию для всех поддерживаемых SDT.

Большие объекты и внешние данные - Adaptive Server будет поддерживать доступ к внешним данным на основе уровня компонента интеграции. Некоторые партнеры хранят данные и индексы в базах данных Sybase, другие - нет. Планируется поддержка больших объектов в духе SQL-3.

Расширяемая языковая поддержка - хранимые процедуры все еще пишутся на Transact SQL, но ожидается поддержка Java с возможностью выполнения кода на сервере.

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

Taming Data Giants

Stephen Brobst, a founder and managing partner at Strategic Technologies & Systems

E-mail:

Owen Roberston, a senior DBA at Tanning Technoology Corp.

E-mail:

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

администрированием сверхбольших баз данных (VLDB - Vary Large

DataBases), таких как управление производительностью и достижение

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

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

обработка, масштабируемость, трехуровневые архитектуры. В

заключение описывается, как некоторые лидирующие РСУБД

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

Единственным способом эффективного управления таблицами,

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

формы разделения данных. Для разделения используются три основных

метода: разделение на основе хэширования, разделение в

соответствии с диапазонами значений ключа и циклическое

разделение (round-robin). При использовании разделения на основе

хэширования DBA (DataBase Administrator) должен выбрать один или

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

исходных данных для хэш-функции, результирующее значение которой

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

строка таблицы. Хорошая хэш-функция должна быть эффективной и

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

разделами. При разделении данных в соответствии с диапазонами

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

данных исходя из заранее приписанного к этому разделу диапазону

значений ключа. В некоторых базах данных требуется, чтобы такого

рода разделение выполнялось только для первичного (уникального)

ключа. Для больших таблиц в качестве ключа разделения часто

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

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

связываются в циклически связанную цепочку, и следующая строка

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

циклического разделения является эффективное распределение

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

таблицы.

В большинстве СУБД, ориентированных на поддержку систем класса

DSS (Decision Support System - системы поддержки принятия

решений), используется разделение на основе хэширования,

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

облегчающее выполнение соединений, если две таблицы разделены по

одному и тому же ключу (конечно, в этом случае строки обеих

таблиц с одинаковым значением хэш-функции от значения ключа

должны храниться в одном и том же разделе). В СУБД разряда

"shared-nothing" (такие системы основываются на

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

процессоры не имеют совместно используемых ресурсов основной и

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

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

способов разделения. Реально, если соединяются две таблицы, не

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

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

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

сильно зависит от размеров таблиц. В системах типа Extended

Parallel Server (XPS) компании Informix Software Inc., в которых

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

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

всего на 10% медленнее, чем если бы они были совместно

разделенными. Однако в системах типа shared-nothing, не

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

совместно разделенные таблицы соединяются более чем в два раза

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

системах Teradata (NCR Corp.), DB2/6000 Parallel Edition (IBM

Corp.), MPP (Sybase Inc.). В системах Non-Stop SQL (Tandem

Computers Inc.) и DB2 V.4 для MVS, которые ориентированы на

эффективную поддержку мощных систем класса OLTP (On-Line

Transaction Processing - оперативная обработка транзакций), для



больших таблиц применяется разделение по диапазонам ключа. В

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

вида разделения. Компания Oracle не будет поддерживать разделения

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

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

отдельной таблицы для каждого раздела и определения

представления, в котором все эти таблицы объединяются.

Используется специально разработанная техника оптимизации

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

Масштабируемость СУБД, ориентированных на OLTP-приложения

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

7.3 продемонстрировал хорошие возможности масштабируемости на

симметричном мультипроцессоре Cray Research 6400. Ограниченность

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

данных и соответствующим наличием критических участков в работе

сервера (например, при сериализации транзакций с помощью

синхронизационных блокировок). Одним из наиболее существенных

нововведений в Oracle 7.3 было применение нескольких списков

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

ресурс.

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

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

реализациях баз данных с несколькими экземплярами (multiple

database instances), таких как Oracle Parallel Server или

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

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

применяются архитектуры с разделением (shared-everything) и без

разделения (shared-nothing) ресурсов. В архитектурах с

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

любой блок базы данных; разделение данных не зависит от наличия

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

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

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

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


Обращения к блокам

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

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

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

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

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

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

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

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

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

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

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

типично для OLTP-приложений, механизм поддержания когерентности

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

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

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

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

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

Решением, которое позволяет добиться требуемого уровня

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

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

Распространенные двухуровневые конфигурации (сервер баз данных и

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

информации, характерным для VLDB. В трехуровневой архитектуре

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

находятся мониторы транзакций. Мониторы транзакций Tuxedo (BEA

Systems Inc.) и Encina (Transarc Corp., теперь эта компания

принадлежит IBM) доминируют на рынке UNIX-систем; CICS - на рынке

MVS. Использование надежного промежуточного программного

обеспечения дает много преимуществ. Прежде всего, логика

бизнес-приложений явно отделяется от уровней представления и

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

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

зависимости от данных (Data-Dependent Routing - DDR).


Такие

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

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

базы данных. Трехуровневая архитектура обеспечивает высокий

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

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

гораздо более эффективно, чем в двухуровневой модели. Наконец,

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

доступности баз данных.

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

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

режиме OLTP возникает другая проблема. В большинстве реализаций

индексные структуры являются локальными для разделов. Индексы,

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

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

но с другой стороны - вызывает трудности с масштабированием

масштабных OLTP-приложений. В случае, когда транзакция производит

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

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

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

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

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

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

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

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

транзакции. Заметим, что локальная индексация вполне хорошо

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

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

допустимы. Среди систем без разделения ресурсов только Non-Stop

SQL демонстрирует хорошую масштабируемость в режиме OLTP.

Ключем к достижению масштабируемости в режиме OLTP систем без

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

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

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



эти блоки. Индекс должен допускать наличие указателей (логических

или физических) на блоки данных, находящиеся под управлением

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

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

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

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

диапазонов значений ключа), но разделение глобального индекса

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

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

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

масштабирования системы, ориентированной на OLTP-системы, однако

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

эффективными. Есть основания рассчитывать, что в будущих системах

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

В системах класса OLTP оказывается достаточным использовать

оптимизацию запросов, основанную на правилах, или упрощенную

оптимизацию, основанную на оценках. Однако в системах класса DSS

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

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

фактором. Компания Oracle впервые применила этот подход к

оптимизации запросов в версии 7.0 (до этого оптимизация

основывалась на использовании правил). В версии 7.3 оптимизатор

существенно усовершенствован. Внедрен набор стратегий

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

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

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

распределение значений столбцов. В версии Oracle8 ожидается

появление дополнительных возможностей оптимизации. Компания IBM

собирается внедрить стратегии оценочной оптимизации,

разработанные в рамках проекта Starburst, в реализации DB2 как

для MVS, так и для UNIX. Ожидается, что это произойдет в первой

половине 1997 г. с выпуском продукта Common Server. Сервер XPS

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



благодаря эффективной реализации алгоритма соединения на основе

хэширования с возможностями распараллеливания. Oracle внедрил

алгоритм хэширования с соединением в версию 7.3, другие компании

собираются скоро это сделать. В СУБД компании Red Brick Systems

Inc. используются стратегии оптимизации, специально

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

Благодаря продуманному применению техники индексации и

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

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

превосходящую производительность реляционных систем. В продукте

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

индексации и разумного разделения таблиц.

Координаты компаний:

Cray Research Inc. (Silicon Graphics Company):

IBM Corp.:

Informix Software Inc.:

NCR Corp.:

Oracle Corp.:

Sybase Inc.:

Tandem Computers Inc.:

Технология восстановления Redo

Мы исследовали технологию, в которой используется новая технология восстановления баз данных redo [LD95] для обеспечения приложениям возможности пережить системные крахи, т.е. обеспечения восстановления состояния приложения наряду с восстановлением состояния базы данных [L97, L98]. Это позволяет приложениям благополучно поддерживать состояние между несколькими транзакциями. Хотя формы устойчивости программ не новы, требовались высокие расходы на журнализацию и установление контрольных точек для реализации устойчивости. Методы, разработанные в проекте Phoenix, существенно сокращают эти расходы на выполнение приложений за счет возможности логической журнализации, что уменьшает расходы на журнализацию. В этих методах применяются механизмы системы баз данных управления кэшированием и восстановления. Хотя остаются дополнительные системные расходы на поддержку устойчивости приложений, они гораздо меньше, чем раньше. Проект Phoenix продолжает развивать тенденцию к расширению системных ресурсов для сбережения более дорогих и более подверженных ошибкам человеческих ресурсов.

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

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

The Birth of the Relational Model

C.J. Date

Оригинал статьи можно найти по адресу

Воспоминания об исходных статьях Кодда и размышления об эволюции реляционной модели в сегодняшних лидирующих системах баз данных.

It was thirty years ago today / Dr. Edgar showed the world the way ...
- с извинениями перед Ленноном и МакКартни

Прошу прощения за поэтическое заимствование, но около тридцати лет тому назад доктор Эдгар Ф. Кодд (Edgar F. Codd) начал работать над тем, что стало Реляционной Моделью Данных. В 1969 г. он опубликовал первую статью в блестящей серии оригинальных статей, описывающих эту работу - статей, которые сделали мир таким, как мы его знаем. Конечно, за это время многие люди внесли свой вклад (иногда весьма значительный) в исследования баз данных вообще и исследования реляционных баз данных в частности; однако ни одна из этих последовавших работ не была настолько существенна или фундаментальна, как исходная работа Кодда. Я уверен, что и через сотни лет системы баз данных будут основываться на реляционном фундаменте Кодда.

The Birth of the Relational Model (Part 2 of 3)

C.J. Date

Оригинал статьи можно найти по адресу

В я начал свой ретроспективный обзор двух первых статей Кодда, посвященных реляционному подходу, -- "Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks" (IBM Research Report RJ599, August 19, 1969) and "A Relational Model of Data for Large Shared Data Banks" (CACM 13, June 1970). В частности, я детально рассмотрел первый раздел первой статьи. Напомню Вам, что статья состояла из шести разделов:

Реляционное представление данных. Некоторые лингвистические аспекты. Операции над отношениями. Выражаемые, именованные и хранимые отношения. Порождаемость, избыточность и согласованность. Управление банком данных.

The Birth of the Relational Model (Part 3 of 3)

C.J. Date

Оригинал статьи можно найти по адресу

В прошлом месяце я завершил свой ретроспективный обзор самой первой статьи Кодда, посвященной реляционному подходу. Теперь я хочу обратиться к следующей по счету статье "A Relational Model of Data for Large Shared Data Banks", вероятно, самой знаменитой статье в истории управления базами данных. Она появилась в Communications of the ACM на следующий год после выхода первой статьи. Как я объяснял в начале этой серии, вторая статья являлась прежде всего пересмотренным вариантом первой, но в ней были введены дополнительные понятия, которые заслуживают комментария.

The Fault with Defaults

Tom Johnson, independent consultant in Atlanta,
(Промашка со значениями по умолчанию - игра слов по-английски,
, vol.11, N 2, February 1998,
оригинал статьи можно найти по адресу )

Я с удовлетворением воспринимал позицию Криса Дейта относительно

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

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

логики (MVL - Multi-Valued Logic), предлагаемой SQL. Тогда мы

имели бы два способа работы с отсутствующей информацией. С одной

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

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

умолчанию. С другой стороны, для любителей дополнительной

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

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

Но, к сожалению, в своей серии статей "Faults and Defaults"

(ноябрь 1996 г., январь, февраль и апрель 1997 г.) Дейт занялся

не этим. Вместо этого он предложил схему "специальных значений"

(как он их называет), не поддерживаемую существующими СУБД и

требующую отказа использования в SQL MVL и внедрения в язык

поддержки альтернативного подхода. Дейт и не отрицает этого,

говоря, что "в сегодняшних SQL-ориентированных продуктах могут

быть трудности с применением нововведенных понятий", т.е. его

схемы со специальными значениями, но "это их проблема" (декабрь

1996 г.).

The Microsoft Database Research Group

David Lomet, Roger Barga, Surajit Chaudhuri, Paul Larson, Vivek Narasayya
Оригинал статьи можно найти по адресу .

One Microsoft Way, Bldg. 9
Redmont, WA 98052

The SQL Double Double

, Spring 1998

Оригинал статьи можно найти по адресу

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

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

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

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

подзапросов, но их основное назначение состоит в возможности

подразделения наборов данных - выполнении процесса, называемого

"реляционным делением". Для выполнения реляционного деления можно

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

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

Проще всего понять подзапросы без корреляции. Они выполняются

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

подзапроса без корреляции с использованием NOT EXISTS:

SELECT A.COL1, A.COL2, A.COL6, A.COL7

FROM TAB1 A

WHERE NOT EXISTS

(SELECT 1

FROM TAB2 B

WHERE B.COL4 = :hv1)

При выполнении оператора проверяется существование значения :hv1

в столбце COL4 таблицы TAB2. Если такое значение не входит в

состав значений COL4, SELECT верхнего уровня возвращает в

результирующую таблицу значения столбцов COL1, COL2, COL6 и COL7

из всех строк таблицы TAB1. Если по меньшей мере одно значение

:hv1 находится в COL4, SELECT верхнего уровня не выполняется и

результатом является пустое множество строк или SQLCODE = +100.

Первым выполняется нижний SELECT, возвращающий ответ true, если

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

B.COL4 = :hv1, и false, если ни одной такой строки найти не

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

результат нижнего запроса есть false (поскольку используется NOT

EXISTS).

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

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

имеется ссылка на столбец верхнего SELECT (одноуровневое

распространение). Такие подзапросы легко распознать, если в

разделах FROM применяются псевдонимы, и эти псевдонимы

предшествуют любому имени столбца в разделе WHERE.
Одиночные

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

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

запроса с одиночным вложенным запросом и использованием

псевдонимов A и B:

SELECT A.COL1, A.COL2, A.COL6, A.COL7

FROM TAB1 A

WHERE A.COL7 = 'X'

AND NOT EXISTS

(SELECT 1

FROM TAB2 B

WHERE A.COL2 = B.COL4)

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

уточненной строки верхнего запроса (WHERE COL7 = 'X'). После

этого проверяется существование A.COL2 (с использованием значения

этого столбца в первой уточненной строке TAB1) где-либо в стробце

COL4 таблицы TAB2. Если значение A.COL2 не входит в состав набора

значений COL4, верхний SELECT выбирает значения столбцов COL1,

COL2, COL6 и COL7 таблицы TAB1 из первой уточненной строки. Если

хотя бы одно значение A.COL2 обнаруживается в COL4, то верхний

SELECT продвигается к следующей уточненной строке (WHERE COL7 =

'X'). Процесс продолжается до тех пор, пока верхний запрос не

сможет обнаружить следующую уточненную строку. Тем самым, сначала

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

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

за раз. Нижний запрос выполняется вторым, возвращая ответ true,

если удается найти хотя бы одну строку, и false, если ни одна

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

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

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

(поскольку используется NOT EXISTS).

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

использующих SQL. В частности, меньше 10% разработчиков на базе

DB2 когда-либо видели такие запросы. Такие запросы выполняются в

стиле сверху-вниз-в середину-вниз-в середину-наверх. Первым

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

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

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

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



условие существования, по одной за раз. Последним выполняется

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

хотя бы одну строку, удовлетворяющую условию, и false, если не

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

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

BLK2 и BLK3:

SELECT SNAME

FROM S BLK1

WHERE NOT EXISTS

(SELECT 1

FROM SP BLK2

WHERE BLK2.S# = 'S2'

AND NOT EXISTS

(SELECT 1

FROM SP BLK3

WHERE BLK3.S# = BLK1.S#

AND BLK3.P# = BLK2.P#))

Этот запрос выдает список поставщиков, поставляющих все детали,

поставляемые поставщиком S2. Всем процессом управляет верхний

список поставщиков (BLK1.S#). Один поставщик передается нижнему

запросу. Далее выполняется средний запрос, формирующий список

деталей, уточненных условием WHERE BLK2.S# = 'S2'. Одна деталь

(BLK2.P#) передается от среднего нижнему запросу. Затем

выполняется нижний запрос и возвращает true или false среднему

запросу. Если результатом нижнего запроса является true, средний

запрос передает нижнему другую деталь (BLK2.P#). Этот цикл

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

либо не исчерпаются все детали. Если нет больше деталей, то это

означает, что результат среднего запроса пуст и верхнему запросу

передается false. Это является условием пропуска текущей строки

верхнего запроса в окончательный результат. В результирующее

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

все те детали, что и поставщик S2.

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

false, то среднему запросу разрешается выполняться, и он

возвращает верхнему запросу true. По этому поводу верхний запрос

выбирает следующего поставщика (BLK1.S#) и начинает заново весь

цикл. Этот процесс позволяет найти всех поставщиков, которые

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

S2.

Двойная корреляция с двойным условием NOT EXISTS представляет

мощный оператор реляционного деления.


Рассмотрим следующий запрос:

SELECT DISTINCT MAJOR <----- Верхний запрос

FROM PARTS T1

WHERE NOT EXISTS

(SELECT * <----- Средний запрос

FROM QUE T2

WHERE NOT EXISTS

(SELECT * <----- Нижний запрос

FROM PARTS T3

WHERE T1.MAJOR=T3.MAJOR

AND T3.MINOR=T2.ID))

Таблицы имеют следующую структуру и содержание:

Таблица PARTS Таблица QUE

10000000 строк 2 строки

MAJOR MINOR ID

----- ----- --

10 1 1

10 2 3

10 3

11 2

11 3

12 1

12 3

12 4

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

таблицы QUE на значения столбца MINOR таблицы PARTS. Запрос

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

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

значения столбца ID таблицы QUE. Запрос вычисляется следующим

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

MAJOR, равным 10. Это значение передается в нижний запрос.

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

столбца ID, равным 1, и это значение передается в нижний запрос.

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

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

равное 3. Нижний запрос опять дает значение true, но у среднего

запроса больше нет строк, поэтому он вырабатывает значение true,

и 10 помещается в окончательный результат. На следующем шаге

нижний запрос получает значение MAJOR, равное 11, и значение ID,

равное 3. Поскольку нижний запрос вычисляется в false, средний

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

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

12 войдет в результирующий набор.

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

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

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

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

мере все эти элементы. Следующий запрос позволяет найти всех

поставщиков, которые поставляют по меньшей мере все товары,



покупаемые калифорнийскими заказчиками:

SELECT SNAME

FROM S BLK1

WHERE NOT EXISTS

(SELECT 1

FROM IT BLK2, ORDERS O

WHERE O.STATE = 'CA'

AND O.ITEM = BLK2.ITEM

AND NOT EXISTS

(SELECT 1

FROM SI BLK3

WHERE BLK3.ITEM = BLK2.ITEM

AND BLK3.S# = BLK1.S#))

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

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

крайней мере, для среднего и нижнего запросов. Если в верхнем

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

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

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

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

Конечно, чем больше значений true возвращает нижний запрос, тем

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

выработка более 25% значений true, более эффективно использовать

следующий синтаксис:

SELECT P.MAJOR

FROM PARTS P, QUE Q

WHERE P.MINOR = Q.ID

GROUP BY P.MAJOR

HAVING COUNT(*) =

(SELECT COUNT(*)

FROM QUE)

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

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

значений столбца ID таблицы QUE. При наличии более 25% значений

столбца MAJOR, удовлетворяющих условию запроса этот запрос будет

выполняться более эффективно. Если вероятность нахождения "всего

____ что имеет _____ условие(я)" мала, то SQL Double Double

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

Подзапросы занимают небольшое, но ответственное место в наборе

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

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

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

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

выполнять проверку существования и реляционное деление.

Типы промежуточного ПО

Предлагается деление продуктов промежуточного ПО на пять

категорий: продукты, ориентированные на базы данных; виртуальные

системы; промежуточное звено (middle-tier); шлюзы; продукты,

ориентированные на Web.

Учет потребностей бизнеса

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

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

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

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

Унифицированный язык моделирования

Имеется новая альтернатива моделирования баз данных -

унифицированный язык моделирования (UML - Unified Modeling

Language), предложенный международным консорциумом Object

Management Group. Разработка UML возглавлялась компанией Rational

Software Corp. () и была основана на

унифицированной модели (Unified Model) программных объектов,

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

предприятия (ECM - Enterprise Component Modeling). ECM

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

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

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

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

приблизительно эквивалентны типам и методам ОРСУБД.

Universal Modeler

Этот продукт компании Siverrun представляет собой набор

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

бизнес-процессов, ERX (Entity Relational Expert) для

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

(физического) моделирования данных. Эти средства связаны со

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

и PowerBuilder. В качестве репозитория модели можно использовать

Model Management Center компании Silverrun.

К моменту написания этой статьи Universal Modeler 1.0 поддерживал

только Informix. Компания обещала вскоре обеспечить поддержку DB2

Universal Database, а в следующей версии RDM обещаны расширения,

поддерживающие Oracle8 и связывающие RDM с компонентом объектного

моделирования.

В Universal Modeler можно использовать три модельных нотации: IE,

Silverrun (вариант ER) и UML. Можно создавать определяемые

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

Допускается импортирование информации о DataBlades (здесь эта

информация называется SilverBlade). Объекты SilverBlade могут

использоваться в моделях. Однако возможности Universal Modeler

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

UNK и неравенство: основы

После неудачной попытки определить равенство Дейт переходит к

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

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

операндом UNK сомнительна. Попробовав предложить возможную

интерпретацию с теми же изъянами как интерпретация равенства, он

приходит к мнению, что использование этих операций, когда один

или оба операнда есть UNK, "не имеет смысла".

Теперь вы можете видеть, что я имел в виду, говоря, что с точки

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

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

мешает получению информации из базы данных (ноябрь 1996 г.; Дейт

"полностью не согласен" с этим в апреле 1997 г.). Позиция Дейта

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

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

при наличии UNK. Поэтому я полагаю, что позиция Дейта совместно с

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

истинность моего утверждения.

UNK и равенство

После объяснения того, что его схема потребует заменить каждый

домен (скажем, домен XXXX) новым доменом XXXX_OR_UNK, Дейт

переходит к рассмотрению различных операций над специальным

значением UNK. (Мне кажется, что предложенное Дейтом именование

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

содержат как реальные значения, так и UNK, а не одно или другое.

Обсуждение Дейта было бы немного более понятным, если бы домены с

именами XXXX_OR_UNK понимались как содержащие значения XXXX и

значение UNK.) Он начинает с операции установления равенства и

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

UNK говорит: "Заметим, что из определения следует, что сравнение

'UNK=UNK' вырабатывает значение true. Здесь нет никакой

трехзначной логики!" (январь 1997 г.).

На самом деле, трудно было бы найти лучший пример потребности в

трехзначной логике! И поскольку именно этот вопрос определяет то,

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

выразительность, что и MVL, мы должны очень тщательно

проанализировать утверждение Дейта о UNK и равенстве.

Рассмотрим таблицу с двумя столбцами и 100 строками, каждая из

которых содержит пару UNK. Предположим, что домен каждого столбца

включает a) целые числа и b) UNK. Следовательно, для каждой

строки с реальными значениями в обоих столбцах (числа от 1 до

100) шансы того, что строка содержит одинаковые значения,

составляют 1 к 10000 (100*100). Шансы того, что во всех строках

значения столбцов будут одинаковы и того меньше (1 к миллиону).

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

"Сколько строк в этой таблице содержат столбцы с равными

значениями" (с использованием схемы со специальными значениями).

В соответствии с определением Дейта ответом будет "Все 100". Но

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

шансы того, что этот ответ правильный, составляют 1 к миллиону!

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

базе данных за информацией?

Серьезность последствий неадекватности подхода Дейта зависит от

ситуации. Например, предположим, что столбцы чисел - это

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

механизмами для системы наведения ракетного крейсера. Пусть для

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

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

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

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

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

доменом TARGETING_COORDINATE_OR_UNK, он занесет в свой столбец

значение UNK во всех 100 строках.

Теперь используем интерфейс, основанный на новой схеме Дейта,

чтобы определить, по каким из ста целей следует стрелять. Мы

сказали: "Стрелять по каждой из 100 целей в том и только в том

случае, когда сравнение coordinate1=coordinate2 дает значение

true". И все 100 ракет будут запущены, хотя ни один из прицельных

механизмов не обеспечил координат ни одной цели!

Конечно, если бы мы догадались добавить к условию конъюнктивное

требование истинности сравнения coordinate1 != UNK, то ракеты не

были бы запущены.

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

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

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

оператора сравнения в схеме Дейта. Она связана с тем, что как

всем известно, ответом на вопрос "Равны ли два неизвестных

значения" не является "Да". И если Дейт ответит, что при

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

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

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

UNK, неравенство и реальный мир

До этого места я просто предполагал, что операции сравнения с

"больше" и "меньше" имеют смысл при наличии значения UNK. Но я

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

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

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

"Является ли значение X большим (или меньшим), чем значение Y",

когда значения X, Y или оба неизвестны (что, кстати, является

потребностью реального мира), то мы ничем не пожертвуем при

использовании подхода Дейта. С другой стороны, нам пришлось бы

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

использовании двузначной логики (по крайней мере, для "больше" и

"меньше").

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

"меньше" при наличии неизвестных значений действительно имеет

смысл, но этот ответ есть "unknown", поскольку значения одного

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

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

Попробуем оценить, какое количество информации запрещается

использовать схемой Дейта при том, что эта информация содержится

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

Предположим, что наша таблица представляет 100 вариантов расклада

игральных карт двух игроков. Числа от 2 до 14 соответствуют

картам от двойки до туза. Первый игрок - Джонс, второй - Смит.

Пусть a) в 10 вариантах неизвестны оба значения, b) в 23

вариантах неизвестно только одно значение и c) в оставшихся 67

вариантах известны оба значения. Для этих 67 вариантов

предположим, что 42 случаях карта Джонса бьет карту Смита, а 21

случае карта Смита бьет карту Джонса. (Чтобы избежать ненужной

сложности допустим, что в случае b) известное значение отличается

от 2 и 14.)

Теперь рассмотрим следующие вопросы:

Сколько раз Джонс точно выиграл у Смита?

Сколько раз Джонс мог бы обыграть Смита?

Сколько было точных ничьих?

Сколько могло бы быть ничьих?

Понятно, что ответы на вопросы следующие:

42

75 (42 + 10 + 23)

4

37 (4 + 10 + 23)

При использовании схемы Дейта были бы получены следующие ответы:

42

По меньшей мере 42, но не больше 65 (но с 23 вхождениями

"вопрос некорректен)

14 (4 + 10)

По меньшей мере 14 (4 + 10) (но с 23 вхождениями "вопрос

некорректен")

Теперь сравним результаты. Для первого вопроса оба подхода дают

один и тот же правильный результат.

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

правильный результат - 75, но не смогла этого сделать по причине

наличия UDK в качестве операнда в 23 операциях сравнения. Однако

в этих 23 случаях Джонс действительно мог выиграть у Смита. Это

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

не обеспечивает ей пользователей. Кстати, заметим, что правильный

ответ (75) находится за пределами диапазона, выданного схемой

Дейта, так что полученный на ее основе ответ является не только

неточным, но и абсолютно некорректным. Схема Дейта считает те 10

вариантов, в которых оба числа есть UDK, как ничьи, т.е. как

случаи с равными значениями. Поэтому они не учитываются в

качестве возможных ситуаций выигрыша Джонса у Смита. К сожалению

(для Дейта), в реальном мире в этих случаях Джонс мог бы выиграть

у Смита.

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

Джонс и Смит точно сыграли вничью в четырех, а не четырнадцати

случаях. И это по причине использования правила Дейта: "Сравнение

UDK=UDK вырабатывает true... Здесь нет трехзначной логики!"

Конечно, при понимании ограничений схемы Дейта мы могли бы

сформулировать запрос по поводу точных ничьих с использованием

условия "where column 1 = column 2 and column 1 != UDK

and column 2 != UDK". Для такого запроса был бы выдан правильный

результат. Но это не решает проблем схемы Дейта, а только

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

ошибок в семантике схемы.

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



но менее информативный, чем это возможно, поскольку каждый из 23

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

Заметим, что СУБД, поддерживающая неопределенные значения и MVL

выдала бы именно приведенные выше корректные ответы. При

использовании трехзначной логики X = Y, X > Y, X < Y вырабатывают

логическое значение uknown, если значение одного или обоих

операндов неизвестно. Например, при выработке ответа на четвертый

вопрос СУБД с неопределенными значениями и MVL руководствовалась

бы следующими соображениями: "Я знаю, что Джонс и Смит сыграли

вничью в четырех раскладах. Для 10 вариантов я не знаю ни одной

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

раскладов. В 23 случаях я не знаю одной карты, так что они могли

бы сыграть вничью и в этих раскладах. Общее число случаев - 37".

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

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

повседневных соображений такого рода. И снова Дейт

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

Управление банком данных

В этом завершающем разделе статьи 1969-го года содержится несколько замечаний по поводу протоколов, определяющих требуемые действия при обнаружении рассогласованности." Возникновение рассогласованности ... может журнализоваться внутренним образом, чтобы в том случае, если она не устраняется в течении некоторого разумного времени ... система могла оповестить сотрудника безопасности [sic]. Или же система могла бы [информировать] пользователя, что такие-то и такие-то отношения нуждаются в изменении для восстановления согласованности ... В идеале должны быть возможны [разные действия системы] ... для разных поднаборов отношений."

Это завершает мое обсуждение статьи 1969-го года. В следующий раз внимание будет посвящена более знаменитой статье 1970-го года.

В DB2 поддерживаются следующие типы ограничений:

Ограничения NOT NULLS, запрещающие неопределенным значениям

появляться в указанном столбце

Ограничения UNIQUE, запрещающие наличие значений-дубликатов в

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

Ограничения PRIMARY KEY, специфицирующее указанный столбец или

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

NOT NULL

Ограничения CHECK - предикаты, такие как BONUS Раздел WITH CHECK OPTION определения представлений,

запрещающий занесение или удаление данных через представление,

если это противоречит определению представлению

Ограничения FOREIGN KEY (называемые также ограничениям

"ссылочной целостности"), устанавливающие контролируемую системой

связь между двумя таблицами, "таблицей-предком" и

"таблицей-потомком". Для каждого отличного от неопределенного

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

ключа таблицы-предка.

Ограничения представляют собой декларативные правила. Триггер

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

при возникновении определенных событий. Вот некоторые из

возможностей механизма триггеров DB2:

Триггер может быть активизирован при выполнении операций

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

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

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

события, которое его активизирует.

Триггер может срабатывать в точности один раз при активизации

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

изменяемой оператором SQL.

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

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

его условие истинно.

Тело триггера может состоять из одного или нескольких

операторов SQL. В этих операторах могут использоваться

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

строк до и после активизации триггера. Если в тело триггера

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

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

пользователя, оператор которого активизировал триггер. Это

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

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

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

Рассмотрим, например, каким образом триггер может автоматически

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

содержит таблицу STOCKS со столбцами SYMBOL, PRICE и HIGHPRICE.

Текущая цена всегда поддерживается в столбце PRICE. Можно

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

всегда оказывалось ее максимальное значение. Этого можно достичь

путем создания следующего триггера:

CREATE TRIGGER stockhigh

NO CASCADE BEFORE UPDATE ON stocks

REFERENCING NEW AS newrow

FOR EACH ROW MODE DB2SQL

WHEN (newrow.highprice IS NULL OR

newrow.price > newrow.highprice)

SET newrow.highprice = newrow.price;

Виртуальные системы

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

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

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

промежуточного ПО и набора API. На каждой системе устанавливается

соответствующая версия промежуточного ПО и конфигурируется служба

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

системы становятся доступными всем приложениям в сети. Из одного

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

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

на UNIX-системе.

Хорошим примером промежуточного ПО этой категории является

продукт DCE, в котором поддерживается основанный на RPC доступ к

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

прочего, DCE обеспечивает собственные службы безопасности и

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

ресурсов с использованием шлюзов и интерфейсов. Однако DCE не

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

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

серверов и сети. Более того, применяемый механизм синхронных RPC

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

были активны. Обычно выполнение удаленного вызова должно быть

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

свое выполнение. DCE продается компаниями (подразделение IBM) и .

Продукты класса MOM в состоянии обойти некоторые ограничения,

необходимо присутствующие в системах, основанных на синхронных

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

сообщениями. Это означает, что целевой сервер может не быть

активным, но тем не менее API MOM не заблокирует приложение.

Еще более существенно то, что для реализации MOM не требуется

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

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

внешней памяти. Примерами MOM-продуктов являются MessageQ

компании , MQSeries компании

, Pipes компании

, MSMQ компании .

В конце 1997 г. на рынке MOM-продуктов ожидается сражение между

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

MOM-продуктов. выпустит новую версию MQSeries

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

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

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

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

интеграция с DCE. Кроме того, планирует снизить

цены. В новой версии MSMQ будет использоваться технология COM, и

она будет работать на платформах Windows NT и Windows 95 в сетях

TCP/IP и IPX/SPX. Первый выпуск MSMQ будет входить в состав

сервера NT и Transaction Server. Партнер

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

MSMQ с MQSeries и производимыми не

операционными системами. Компании и

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

MSMQ в конце этого года.

При всех своих достоинствах подход MOM страдает отсутствием

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

средств разработки. При использовании MOM в сочетании с

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

потребуется использовать различные DLL, средства ActiveX или

производить интеграцию с библиотекой классов средства разработки.

Из-за этого разработчикам приходится отказываться от традиционной

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

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

PowerSoft (подразделение компании )

или Developer/2000 компании . Не очень

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

Intersolve, поддерживающие взаимодействия прикладных объектов

внутри системы.

Компания недавно объявила о выпуске MOM-продукта TIB/Rendezvous 3.0. В этом продукте обеспечивается

интеграция ActiveX и Java, удостоверяемая доставка сообщений,

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

широковещания. Основанный на технологии ORB TID/Rendezvous



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

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

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

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

получает каждый подписчик.

Мониторы обработки транзакций (Transaction Monitors -

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

ПО, обеспечивающие одновременно выбор местоположения для

прикладной обработки и механизм взаимодействий. TP-мониторы дают

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

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

удаление заказчика. TP-монитор располагается между клиентом и

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

архитектуры "клиент-сервер". Клиент инициирует транзакцию в

мониторе с использованием механизма транзакционного RPC (TRPC), а

TP-монитор при необходимости запускает транзакции баз данных.

Ответ, если он существует, отправляется клиенту. Семейство

популярных мониторов транзакций включает Tuxedo компании , основанный на DCE продукт Encina

компании , Transaction Server компании .

Мощность TP-мониторов заключается в том, что они позволяют

разработчикам оформить части приложения в виде транзакции. У

транзакции имеются четкие точки начала и завершения. Если при

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

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

нестабильном или несогласованном состоянии. Кроме того, мониторы

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

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

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

через одно подключение к базе данных. Например, для 100 клиентов

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

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

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



отдельное подключение к базе данных. В дополнение к этому,

TP-мониторы в пределах одной транзакции могут выбирать и

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

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

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

обновить запись в базе данных DB2 на мейнфрейме. Тем самым,

TP-мониторы полезны для связывания различных унаследованных

систем и баз данных в общую виртуальную систему.

Основанное на ORB промежуточное ПО включает простые брокеры

объектных заявок, существующие на нескольких машинах и

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

Разработчики могут встраивать ORB'ы или программы, дающие доступ

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

интерфейс с ORB'ами (приложениями), существующими в других

системах. К коммерческим ORB, базирующимся на CORBA, относятся

Orbix компании и VisiBroker компании

. Сила этого подхода состоит в

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

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

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

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

восстановления после сбоев.

Воспоминания о влиятельных статьях

Richard Snodgrass, editor

Эта новая колонка посвящается процессу научного исследования. Изучаются пути распространения и развития новых идей.

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

Я попросил нескольких известных и представительных людей из сообщества баз данных выбрать одну статью (часто это весьма не просто!), которая оказала основное влияние на их исследования, и описать, что в этой статье понравилось и как она на них подействовала. Их ответы читаются с интересом и устраняют иногда непредсказуемое забывание хороших идей.

Elisa Bertino, University of Milan,

[P.P. Griffits and B. Wade, "An Authorization Mechanism for a Relational Database System", ACM Transactions on Database Systems, 1(3):242-255, 1976.]

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



Mike Carey, IBM Almaden Research Center,

[C. Zaniolo, "The Database Language GEM", in Processing of the 1983 ACM SIGMOD International Conference on Management of Data, San Jose, California, May 1983, D. Dewitt and G. Gardarin, eds, pp. 207-218.]

Это одна из моих любимых статей в области баз данных - я бы сильно рекомендовал ее каждому, кто работает над объектными расширениями реляционных систем баз данных. Коротко говоря, в статье расширяются реляционная модель и реляционный язык запросов (Quel) для обеспечения более строго типизированных таблиц, обобщения, ссылок, путевых выражений и атрибутов с множественными значениями. Жемчужиной (gem; намеренный каламбур!) эту статью делает то, что эти расширения являются удивительно понятными, простыми и естественными. Хотя некоторые "реляционные фанатики" даже сегодня утверждают, что отношения и объекты соотносятся примерно так же, как масло и вода, я полагаю, что почти 15 лет тому назад Заниоло в своем исследовании GEM многими способами доказал их неправоту. В число основных моментов статьи входят введение точечной нотации для путевых выражений, ясный подход к рассмотрению взаимодействия неопределенных значений и путевых выражений, уникальная система типов и подход к работе с множествами. Эта статья сильно повлияла на работу над объектно-ориентированными моделью данных и языком запросов, которую мы выполняли в контексте проекта EXODUS в Висконсине (Wisconsin).


Статья продолжает оказывать воздействие на мое видение мира при выполнении моей текущей работы над объектно-реляционными расширениями для DB2 UDB (Universal DataBase) и SQL3.



Jim Gray, Microsoft Research,

[D. Bitton, D.J. DeWitt, C. Turbyfill, "Benchmarking Database Systems: A Systematic Approach", in Processing of the International Conference on Very Large Databases, October, 1983, Florence, Italy, M. Schkolnick and C. Thanos, eds., pp. 8-19.]

В начале 1970-х имелся большой энтузиазм по поводу машин баз данных, специальных аппаратных средств, которые должны были каким-то образом решить проблемы производительности, досаждавшие системы баз данных в то время. Идея заключалась в том, что если выдающиеся исследователи баз данных смогут обойти ограничения файловой и операционной системы, если они смогут работать на "голом металле", то можно получить в десять раз более быстрые продукты. Имея сердечную склонность к миру ОС, я был смущен тем, что эти ребята рассчитывали выполнять ввод/вывод лучше, чем это удавалось нам - похоже, что они не понимали сути прерываний. И не только это, похоже, что они не принимали во внимание все тонкости обработки ошибок, мультипрограммирования, мультипроцессирования, безопасности и т.д. В один из дней ко мне пришло озарение: я прочитал статью Биттона-ДеВитта-Турбифилла. Внезапно я осознал, что происходит: я работал над тем, что теперь назвали бы проблемами оперативной обработки транзакций, в то время как мои друзья из области машин баз данных работали над тем, что теперь назвали бы добычей данных (data mining). Они выполняли соединения, они сканировали целиком 4-х мегабайтную базу данных, в то время как я выполнял мелкие транзакции над гигантскими по тем временам базами данных (500 Мб). Я беспокоился о безопасности, асинхронности, восстанавливаемости, управляемости, в то время как их заботили последовательные сканирования, агрегаты и, в особенности, соединения.

Чтобы кристаллизовать эти различия, я написал заметку "A Measure of Transaction Processing", в которой описывалась OLTP-транзакция.


В конце концов, это привело к возникновению Transaction Processing Performance Council и тестового набора TPC-A. В статье описывались мини-пакетная транзакция пользовательского уровня (копирование 1000 записей) и пакетная транзакция (сортировка миллиона записей). К сожалению, отсутствовала работа по копированию и восстановлению. Статья циркулировала в широких массах. Около 25 человек что-то добавили. Чтобы избежать необходимости получения согласия юристов из компаний ATT, DEC, Xerox, IBM и Tandem, мы опубликовали статью под псевдонимом Anon Et Al. Статья появилась в первоапрельском номере журнала Datamation в 1985 г. Теперь каждый год первого апреля вручается системам и группам, получивших лучшие результаты на этом тестовом наборе. Как-то я получил письма на имя Dr. Anon (в Tandem знали секрет и получали удовольствие от этой шутки).

Ирония этой истории состоит в том, что Висконсинский тестовый набор (Wisconsin Benchmark) в результате породил тестовый набор TPC-D. TPC-D теперь находится в центре великих сражений за производительность СУБД.



Henry F. Korth, Bell Laboratories, Lucent Technologies Inc.,

[J.N. Gray, R.A. Lorie, G.R. Putzolu, and I.L. Traiger, "Granularity of Locks and Degrees of Consistency in a Shared Data Base", in Modelling in Data Base Management Systems (G.M. Nijssen, ed.), North Holland Publishing Co., 1976, pp. 365-395.]

Когда меня попросили написать короткую заметку про одну статью, оказавшую основное влияние на мои исследования, мой выбор был абсолютно ясен. Ключевым словом было влияние. Хотя я читал больше отличных статей, чем могу пересчитать (несмотря на то, что их число исчислимо!), очень немногие статьи оказали серьезное влияние на программу моих исследований и на мой способ решения исследовательских проблем. Статья Грея-Лури-Путцолу-Трейгера относительно гранулированности блокировок - это не только первая статья, оказавшая серьезное воздействие на мою работу, но и наиболее влиятельная.

Первый раз я прочитал эту статью в 1978 г.


будучи аспирантом, специализирующимся на исследованиях баз данных, области о существовании которой я и не подозревал за год до этого. Джеф Ульман (Jeff Ullman), мой руководитель дал мне несколько довольно теоретических статей, имеющих отношение к управлению параллельным доступом к базам данных. Хотя эти статьи были действительно хорошими, у меня отсутствовало интуитивное понимание сути реальной проблемы управления тразнакциями в базах данных. Тогда Джеф указал мне на работы проекта System R, включая упоминавшуюся статью про гранулированность блокировок. Читая эти статьи и в особенности статью про гранулированность блокировок, я связал формальные понятия корректного параллельного выполнения с практическими требованиями дешевых протоколов с высокой степенью параллельности. Размышляя над идеями, введенными в статье, я решил выбрать темой своей диссертации управление параллельным доступом к базам данных (я представлял авторов статьи пожилыми людьми с короткими седыми волосами). Воздействие этой работы неизмеримо возросло, когда я провел следующее лето (1979 г.) с Джимом Греем, Пат Селинджер и группой System R (я был поражен несоответствием своих представлению реальному образу авторов и видом "бизнес"-офиса с креслом в форме мешка с фасолью). Глядя в прошлое, я считаю, что влияние на меня этой статьи частично связано с тем, что я познакомился с ней в нужное время, но я думаю, что основной источник ее влияния - это разумная смесь теории, текущих практических проблем и связи с существующими системами.



Betty Salzberg, Northeastern Univeresity,

[C. Mohan, D. Haderle, B. Lindsay, H. Pirahesh and P. Schwarz, "ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging", ACM Transactions on Database Systems, 17(1):94-162, March 1992.]

Для меня статья про ARIES была важной потому, что она позволила мне создать ясное представление о механизмах восстановления в системах баз данных. Например, я увидел как используются Log Sequence Numbers (LSNs) для поддержки протокола Write-Ahead-Logging (WAL).


В этом протоколе говорится, что до записи на диск страницы, измененной незафиксированной транзакцией, (до изменения на диске предыдущей версии страницы) предыдущее состояние измененной записи должно уже находиться где-нибудь еще на диске. Но всегда важно понимать некоторый механизм, поддерживающий выполнение теоретического правила. Общеупотребительным механизмом поддержки WAL являются LSN. Проставленный в странице базы данных P LSN = L - это LSN записи в журнале по поводу самого последнего изменения страницы P. Журнальные записи содержат предыдущее состояние измененных записей, и журнальные записи пишутся последовательно в порядке возрастания LSN. Если LSN самой последней журнальной записи, помещенной на диск, меньше L, то WAL полагает, что страница P еще не записана на диск. Сначала на диск должна быть помещена часть журнала, содержащая журнальную запись с LSN = L. Это один из многих механизмов восстановления, которого я не знал, и я думаю, что его не знали многие другие исследователи баз данных, пока им не стали доступны статьи про ARIES.

Чтение статьи во-многом повлияло на мои следующие исследования. Например, в моих исследованиях методов параллельного доступа и восстановления для методов доступа типа B-деревьев (II-дерево и hB-II дерево) LSN использовались для определения того, изменялась ли индексная страница со времени последнего ее посещения. (Если она не изменялась, можно избежать нового поиска в дереве.) Аспекты сравнения механизмов защелок (latches) и блокировок и поддержки тонко гранулированных блокировок, освещенные в статье про ARIES, были существенны для II-дерева и hB-II дерева. В этой статье была разъяснена концепция странично-ориентированного восстановления в сравнении с логическим восстановлением, и она также использовалась в II-дереве и hB-II дереве. В моих исследованиях в областях транзакционных потоках работы (Transactional Workflow) и оперативной реорганизации использовался метод воспроизведения истории по журнальным записям (из ARIES) для воссоздания системных таблиц и/или восстановления состояния выполняемого приложения.


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



Dennis Shasha, New York University,

[P.L. Lehman and S.B. Yao, "Efficient locking for concurrent operations on B-trees", ACM Transactions on Database Systems, 6(4):650-670, December 1981.]

Моими любимыми статьями всегда были такие, которые изменяли мои интеллектуальные предубеждения. Я прочитал статью Лехмана и Яо в 1981 г., когда старался найти тему для диссертации. Я изучал теорию управления параллельным доступом у Фила Бернштейна (Phil Berstein) и Ната Гудмана (Nat Goodman), когда оба они были в Гарварде, и был убежден в том, что конечной точкой является предупреждающая конфликты сериализуемость. В статье Лехмана и Яо были показаны исключения, очевидно, корректные, но не накрываемые этой моделью. На следующий год, пытаясь усилить модель, я понял, что требуется новая модель, и написал свою диссертацию об обобщенной модели параллельного доступа в индексных структурах.



Hector Garcia-Molina, Stanford University,

[K.P. Eswaran, J.N. Gray, R.A. Lorie, and I.L. Traiger, "The Notion of Consistency and Predicate Locks in a Database System", Communications of the ACM, 19(11):624-633, November 1976.]

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





Tomasz Imeilinski, Rutgers University,

[R. Reiter, "On Closed World Databases", in Logic and Databases, H. Gallaire and J. Minker (eds), Symposium on Logic and Data Bases, Centre d'etudes et de recherches de Toulouse, 1977. Advances in Data Base Theory, Plenum Press, New York, 1978, pp. 55-76.]

Я выбрал статью, которая поразила меня и оказала влияния на меня и на большое число исследователей, работавших (подобно мне) или работающих сейчас над логическими основами баз данных. Эта и несколько других статей Рея Рейтера положили начало новому подходу к пониманию баз данных - с упором на точную логическую формулировку скрытых предположений относительно содержимого базы данных при выполнении запросов. В статье приводится простое, но фундаментальное наблюдение, касающееся того, что имеются два в равной степени разумных способа интерпретации содержимого базы данных: предположение о замкнутости мира (факты, не выводимые из базы данных, являются ложными) и предположение об открытости мира (в действительности мы не можем ничего сказать о фактах, которые не могут быть логически выведены из баз данных). Рейтер замечает, что запросы SQL интерпретируют базу данных в соответствии с предположением о замкнутости мира, и приводит "недостающие" аксиомы. Его образ мыслей оказал влияние на мои исследования при подготовки диссертации PhD и на последующую работу в области дедуктивных баз данных. Хотя статья Рейтера не привела к появлению каких-либо "продуктов", как часто бывает сегодня, она является примером фундаментальной статьи, влияющей на способ мышления людей, и даже 20 лет спустя она все еще представляет собой важный источник для любого, кто изучает базы данных и их логические основы.

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





David Maier, Oregon Graduate Institute,

[M.P. Atkinson, P.J. Bailey, K.J. Chisholm, P.W. Cockshott and R. Morrison, "An Approach to Persistent Programming", The Computer Journal, 26(4):360-365, November 1983.]

Я впервые столкнулся с Persistent Programming Group в Эдинбурге Скт-Эндрю в 1984 г. В это время я работал на компанию GemStone Systems (потом Servio Logic) в связи с проектом их машины баз данных и системы. В компании происходила фундаментальная переориентация от реализации модели данных с вложенными множествами на специализированной аппаратуре к созданию объектно-ориентированной системы баз данных, работающей на стандартных рабочих станциях. Я старался погрузиться в объектно-ориентированное программирование вообще и в Smalltalk в частности, чтобы понять проблемы и преимущества объектно-ориентированной модели данных. Питер Бьюнман (Peter Buneman) посетил группу в Шотландии и указал мне на их работу, услышав, что я работаю на GemStone.

Указанная статья является кратким введением в PS-algol, вариант S-algol с возможностями долговременного хранения. В статье раскрываются некоторые проектные решения для превращения языка программирования в язык баз данных (например, как указывать потребность долговременного хранения и как обеспечить эффективный доступ к крупным коллекциям данных) и приводится краткий обзор реализации. (Парная статья, опубликованная почти в то же время в журнале Software - Practice & Experience, содержит более детальную информацию о реализации.) Статья подействовала на мое мышление в нескольких направлениях. Во-первых, она заставила меня осознать, что попытка построить систему баз данных путем добавления к существующему языку программирования возможности долговременного хранения не является такой уж дурацкой идеей. Во-вторых, статья показала мне, какие аспекты GemStone связаны с его природой как языка программирования с долговременным хранением, а что определяется объектной ориентированностью. Например, в PS-algol свойство долговременного хранения было ортогонально системе типов, поэтому здесь объектная модель не при чем.


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



Pat Selinger, IBM Almaden Research Center,

[B. Wegbreit, Studies in Extensible Programming Languages, Ph.D. Thesis, Harvard University, May 1970.]

Я присоединилась к группе баз данных IBM на раннем этапе создания System R, нашей первой попытки доказать, что на основе использования ориентированного на множества языка запросов реляционная система может иметь практическую реализацию с сохранением независимости данных, провозглашаемую реляционной моделью. Поэтому я предполагала выбрать знаменитую статью Кодда 1971 г. о реляционной модели данных, но это показалось мне слишком очевидным. Но на самом деле, у меня имелся более хороший выбор, с которым я скоро вас познакомлю. Я присоединилась к проекту System R потому, что там были умные люди, с которыми было интересно говорить. Я сделала свою диссертацию PhD на основе комбинации операционных систем и языков программирования и до поступления в IBM не знала буквально ничего о технологии баз данных. В IBM в первый же день мне вручили книгу Криса Дейта и сказали: "Читай это". Я думала, что имею небольшие шансы внести большой вклад в выполнение проекта. Оказалось, что я была не права. Технологии операционных систем и языков программирования в действительности имеют огромное отношение к системам баз данных: концепция компиляции, концепция изучения альтернатив при генерации кода и выборки оптимальной альтернативы, параллельность, мультипроцессирование ...


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

Однако одно направление технологии языков программирования не получило тогда должного применения. Я прочитала диссертацию PhD Бена Вегбрейта в начале 1970-х (да, я знаю, что это было очень давно). Это было одно из первых исследований в области расширяемых языков программирования, перегрузка функций, определяемые пользователями типы и функции. Эта работа оказала глубокое влияние на мои представления о том, что можно было бы сделать с языками программирования; они могли бы быть живыми, активными созданиями, а не только изложенным в руководстве статическим синтаксисом, используемым для выполнения конкретной задачи. Читая эту статью и помогая применять многие другие концепции языков программирования в технологии баз данных, я очень заинтересовалась возможностью применения свойства расширяемости языков программирования в базах данных таким образом, чтобы не разрушить простоту реляционной модели. В середине 1980-х у нас была такая возможность. Когда закончился проект распределенной системы R*, мы искали идеи для нового проекта, включая возможность построения системы баз данных второго поколения, основанной с самого начала на расширяемом, активном, живом ядре управления базами данных. Эта концепция расширяемости вызвала у нас настолько большой интерес, что мы решили развить ее более глубоко. Родился проект Starburst, и то, что мы называли тогда расширяемыми базами данных, легло теперь в основу объектно-реляционных систем баз данных, которые сегодня являются продуктами, почти через 30 лет после того, как технология баз данных была впервые связана с технологией языков программирования.



Jeffrey Ullman, Stanford University,

[P.A. Bernstein, "Synthesizing Third Normal Form Relations from Functional Dependencies", ACM Transactions on Database Systems 1(4):277-298, March, 1976.]



В 1975 г. Катриел Бири (Catriel Beeri) получил преподавательский пост в Принстоне после того, как провел год в качестве стипендиата университета Торонто, работая с Деннисом Цикритзисом (Dennis Tsichritzis) и его студентом Филом Бернстайном в области теории баз данных. У Катриела был курс по реляционным системам баз данных, который я посещал вместе со своими студентами. Этот курс произвел огромное воздействие в области баз данных; например, по крайней мере пять студентов (плюс сам Катриел) впоследствии возглавляли основные конференции по базам данных. Одна из ведущих тем курса была тесно связана с указанной статьей, включая метод Фила проектирования схемы и его наблюдения о том, что ранние статьи о функциональных зависимостях, нормальных формах и ключах содержат существенные ошибки, которые он исправил путем тщательного анализа и доказательств. Эта работа убедила меня в том, что теория функциональных зависимостей обладает определенной глубиной и что стоит предпринять усилия для понимания ее тонкостей и следствий. Сегодня, когда конкретный алгоритм, представленный в статье, используется не так уж часто, основополагающие понятия, введенные Филом и Катриелом, являются основным элементом при обучении студентов Computer Science и настолько распространены, что уже не рассматриваются как "теория".

Вот несколько "надежных" предсказаний на следующие пять лет:

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

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

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

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

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

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

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

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

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

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

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

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

Разработанная нами в проекте AutoAdmin технология выбора индексов требует установления и прототипирования интерфейсов нового сервера баз данных для разрешения создания гипотетических индексов.
Для создания гипотетического индекса требуется эффективное получение статистик для столбцов этого индекса. На этом шаге мы используем методы образцов [CMN98]. Были реализованы два компонента, в которых применяются эти интерфейсы.

Утилита index analysis utility [CN98] создает набор гипотетических индексов и анализирует их влияние при различных рабочих нагрузках системы. Утилита анализа может быть использована в разных клиентских инструментальных средствах.

Мы использовали утилиту анализа индексов при разработке средства index tuning wizard, которое циклически эффективно обходит пространство гипотетических индексов с целью предложения набора индексов, подходящего для данной рабочей загрузки. Оценить рабочую загрузку можно на основе тестового набора заказчика или путем просмотра журнала сервера баз данных с помощью доступных утилит. При каждом выборе набора гипотетических индексов используются специальные интерфейсы сервера баз данных для создания гипотетических индексов и оценки их потенциала для повышения производительности при данной нагрузке. Мастер настройки индексов использует новый метод поиска, который отсеивает ложные индексы на ранней стадии и использует характеристики подсистемы обработки запросов для снижения стоимости выбранных индексов. Например, принимает во внимание возможность доступа только к индексам. Кроме того, мастер структурным способом генерирует сложные варианты (например, индексы на нескольких столбцах) из хороших простых вариантов (например, индексов на одном столбце). Технические детали этого мастера можно найти в [CN97].

Несмотря на молодость проекта AutoAdmin, мы успешно воздействуем на SQL Server. В следующем выпуске (SQL Server 7.0) будет присутствовать наш мастер настройки индексов, который можно будет пускать в ход разными способами для выбора подходящих индексов в соответствии c рабочей нагрузкой [CN98-wp]. Рабочая нагрузка может обеспечиваться внешним образом или создаваться с использованием профилировщика SQL Server. Мастер настройки индексов будет существенным вкладом в решение задачи упрощения администрирования SQL Server.

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

Выражаемые, именованные и хранимые отношения

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

По этому поводу у меня имеется небольшое недовольство (если снова следовать правилу 20/20 для взгляда в прошлое). Кажется слегка неудачным способ использования Коддом термина хранимое отношение. Лично я предпочел бы разбить выражаемые отношения на два вида - базовые и производные отношения; я определил бы производное отношение как такое выражаемое отношение, значение которого в каждый момент времени производится из других выражаемых отношений в соответствии с некоторым реляционным выражением, а базовое отношение - как выражаемое отношение, не являющееся базовым в этом смысле. Другими словами, базовые отношения - "заданные"; порождаемые отношения - все остальные выражаемые отношения. И затем я бы четко прояснил, что базовые и хранимые отношения - это не обязательно одно и то же (см. рис. 1). Тем не менее, в статье фактически считается, что базовые и хранимые отношения являются одним и тем же (в основном потому, что в ней в ней вообще не упоминаются базовые отношения в качестве отдельной категории).

Рис. 1. Виды отношений

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

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

Достаточно по поводу этих огорчений. Кодд продолжает: "Если интенсивность доступа к некоторому неименованному, но выражаемому отношению возрастает до значительного показателя, следует дать ему имя и тем самым включить в именованный набор." Другими словами, сделайте его представлением! Так что уже в 1969 г. Кодд говорил об идее представлений как "законсервированных запросов".

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

Взгляд вперед: основы

Мы находимся на пороге нового тысячелетия. Что это означает для эволюции использования баз данных?

Опыт показывает, что максимальный период времени, для которого можно более или менее точно прогнозировать развитие большинства областей компьютерной технологии, составляет около пяти лет. Посмотрим на список тем книги автора Strategic Database Technology: Management for the Year 2000 (Morgan Kaufmann, 1995), в которой обсуждались пути развития систем управления базами данных и информационных систем в 90-е годы. Некоторые вещи, такие как гипертекст и гипермедиа уже стали общераспространенными. Отношение к другим предметам, таким как будущее развитие языка Xbase и стандарт, со временем изменилось.

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

В этой заметке автор пытался

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

Зависимости данных в существующих системах

Как уже отмечалось, статья 1970-го г. в гораздо большей степени касается вопроса независимости данных, чем ее предшественница 1969-го г. В аннотации Кодд говорит: "Пользователи больших банков данных должны быть избавлены от потребности знаний о том, как данные организованы в машине. На действия пользователей с терминалов и большинство прикладных программ не должно оказывать влияние изменение внутренних представлений данных". Другими словами, мы хотим иметь физическую независимость данных. Он продолжает: "[На такие действия и программы также не должно оказываться влияние] даже при изменении некоторых аспектов внешнего представления". Другими словами, мы хотим иметь и логическую независимость данных.

Кодд рассматривает различные примеры отсутствия независимости данных в существовавших в то время системах баз данных; он также обсуждает зависимости, связанные с упорядочиванием, индексацией и путями доступа. Потом он приводит один пример, иллюстрирующий такие зависимости в системах, которые обеспечивают "древовидные или немного более общесетевые модели данных" (другими словами, иерархические системы, такие как IMS, и сетевые системы, такие как IDS). Замечание: IDS была предшественником более известной системы IDMS; Кодд писал статью до того, как IDMS появилась на сцене.

Это говорит о том, как далеко мы ушли! С точки зрения пользователей решением проблемы зависимости от упорядочивания (в терминах SQL) является раздел ORDER BY; пользователи не ограничены предопределенным упорядочиванием, а в состоянии потребовать в динамике любое желательное упорядочивание. И если пользователи требуют упорядочивания, не отражаемого напрямую в хранимом варианте данных, то система должна быть в состоянии динамически сортировать или индексировать данные.

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

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

---

---