Database Programming & Design

A discussion of some redundances in SQL


Greevous Bodily Harm (Part 1 of 2)
C.J. Date
оригинал статьи можно найти по адресу

Кристофер Дейт является независимым автором, лектором, исследователем и консультантом, специализирующимся в области систем реляционных баз данных. Корресподенцию ему можно послать по почте по адресу: Database Programming & Design, 411 Borel Ave., Ste. 100, San Mateo, CA 94402.
Известно ли вам, что разделы и (для их совместного названия далее используется аббревиатура GBH) в языке SQL избыточны? Другими словами, любой осмысленный запрос, который можен быть выражен с использованием одного из этих разделов или их обоих может быть выражен и без их применения. (Ниже поясняется значение слова "осмысленный".)


, A principal with Relational Database Architects Inc.


, September 1998
Оригинал статьи можно найти по адресу
Чем лучше логическая модель,
тем выше производительность физической реализации базы данных
Приложение представляет собой небольшую биллинговую базу данных для телекоммуникационной компании. Месяц ушел на то, чтобы разобраться с бизнес-потребностями и утвердить проект. Был подобран высококвалифицированный штат. Два месяца были посвящены анализу и проектированию. Сильная группа администраторов БД произвела реализацию проекта. Через два месяца после завершения реализации обнаруживаются существенные проблемы с производительностью.
Сколько раз приходилось производить послереализационное обследование только для того, чтобы понять, соответствует ли производительность ожиданиям. И в конце концов удается убедиться в том, что анализу бизнес-процессов и данных было уделено достаточное время, что разработанная модель соответствует бизнесу, что база данных, созданная для удовлетворения потребностей приложения, корректно спроектирована и правильно реализована. Тем не менее, имеется причина, по которой эффективность базы данных недостаточна. Вызвана ли она ограничениями СУБД? Возможно. Но если это так, то СУБД будет влиять и на другие приложения. Более вероятно, что причиной является выбранный способ разработки логической модели и ее последующей трансляции в физическую модель при реализации. Неэффективное выполнение этих стадий влияет на производительность приложения. Как найти узкие места? Следует проанализировать базовые компоненты моделей, их характеристики и действия, которые можно предпринять для преобразования логической модели с тем, чтобы максимизировать производительность, продолжая поддерживать потребности исходной бизнес-модели.


Активные данные


Под "свойством активности данных" понимается механизм,
заставляющий оператор SQL производить некоторые действия,
потребность в которых в самом операторе явно не выражена.
Активные данные имеют особенно важное значение в среде
"клиент/сервер", в которой приложения разрабатываются
распределенными группами, поскольку этот механизм дает
возможность определения глобальных правил, применимых ко всем
приложениям.
В DB2 существуют две категории активных данных - ограничения и
триггеры. Ограничения являются декларативными утверждениями,
истинность которых контролируется системой, например, "Размер
обуви всегда представляется положительными числами" или "У
каждого служащего имеется менеджер". Триггеры - это
автоматические действия, которые срабатывают каждый раз при
возникновении определенного события или условия, например, "Когда
останется только 10 карандашей, нужно заказать еще 100" или
"Следует вести учет всех тех, кто изменяет содержимое таблицы
ACCOUNTS".


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


Дон Чемберлин
Источник: Donald D. Chamberlin. Anatomy of an Object-Relational Database. DB2 Online Magazine, Winter 1996.
Замечания обозревателя:

Уважаемые читатели! Вашему вниманию предлагается не самая свежая
статья, посвященная принципам организации современных вариантов
DB2. Она была опубликована в конце 1996 г. в журнале DB2 Online
Magazine (). По слухам, официальный полный перевод этой статьи доступен в бумажной форме в Московском
представительстве компании IBM. Тем не менее, мне показалось
полезным опубликовать обзор статьи на нашем сервере по следующим
причинам.
Во-первых, имя автора этой статьи, господина Дональда Чемберлина известно отечественным специалистам в области баз данных более 20
лет. Для меня начало деятельности Дона в компании IBM связано с
легендарным проектом System R, реализация которого впервые
продемонстрировала практические возможности реляционного подхода
к базам данных. В настоящее время господин Чемберлин работает в
научно-исследовательской лаборатории IBM () и
является лидером группы, связанной с перспективными архитектурами
систем баз данных.
Во-вторых, представляемая вашему вниманию статья, на мой взгляд, исключительно просто и понятно описывает основные принципы
объектно-реляционного подхода в связи с его реализацией в DB2 for
Common Servers, которая, в свою очередь, является одной из
основных составляющих IBM DB2 Universal Database.
Надеюсь, что вы получите не меньшее удовольствие, чем я, когда
первый раз читал эту статью.
С уважением, Сергей Кузнецов
Системы управления реляционными базами данных представляют собой одну из наиболее удачных технологий в компьютерных науке и
индустрии. Большая часть данных в мире бизнеса хранится в
реляционной форме. До последнего времени индивидуальные элементы
хранимых данных были относительно небольшими и простыми. Для
хранения таких данных хватало поддержки набора предопределенных
типов данных, таких как целые и вещественные числа и строки
символов. Операции, определенные над этими типами данных

(например, арифметические операции и операции сравнения), были

также простыми и предопределенными.

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

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

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

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

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

письменные документы с диаграммами и аудио- и видеозаписи.

Очевидно, что традиционные возможности языка SQL, связанные с

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

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

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

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

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

и функций над ними.

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

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

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

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

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

использовать не только сами данные, но и поведение данных.

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

данных за счет расширения их семантического содержимого. Тенденция

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

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

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

расширяются в двух направлениях: (1) добавлении "объектной

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

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

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

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

выборка изображений, развитый текстовый поиск, географические

приложения. Система, которая обеспечивает объектную

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

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

Объектно-реляционные системы объединяют достоинства современных

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

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

данных и высокоуровневые непроцедурные языки запросов. В данной

статье анализируется объектная инфраструктура и реляционные

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

системой IBM DB2 for Common Servers, которая в дальнейшем тексте

будет называться просто DB2.


Applications of JAVA Programming Language to Database Management


SIGMOD Record, Web edition, March 1998
оригинал статьи можно найти по адресу

, ,
Department of Computer Science University of Kentucky


Архивация, восстановление, реорганизация


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


База стандартов


Одной из тенденций в мире современного промежуточного ПО является
движение к стандартам, включая не только те, которые
разрабатываются комитетами по стандартизации (например, CORBA),
но и стандарты, предлагаемые мощными компаниями-производителями.
В прошлом продукты промежуточного ПО основывались на частных
предложениях, которые не предполагали возможности
интероперабельности. Сегодня компании, производящие промежуточное
ПО, учатся использовать стандарты, такие как CORBA или DCOM
(Distributed Component Object Model) в качестве базовой модели
продуктов.
DCOM служит стандартной базой в однородной среде Windows. Опора
на DCOM позволяет приложениям, написанным на Visual Basic, Delphi
и PowerBuilder, связываться по сети с аналогичными приложениями и
использовать их сервисы с использованием механизма RPC. Таким
образом, DCOM может использоваться либо как примитивный уровень
промежуточного ПО, либо как инфраструктура для других продуктов.
Продукты промежуточного ПО, использующие DCOM, включают монитор
обработки транзакций Microsoft Transaction Server и Microsoft
Message Queue Server (MSMQ). В MS Transaction Server для
определения транзакций используется ActiveX, а взаимодействия с
приложениями и серверами ресурсов основаны на DCOM. Основанным на
DCOM MOM-продутом является Falcon. Компания
производит продукт Multitier Distributed
Application Services Suite, многозвенный продукт промежуточного
ПО, позволяющий строить распределенные приложения с
использованием основанных на DCOM брокеров объектных заявок.
Но DCOM - это не единственный и не первый механизм,
поддерживающий ORB. CORBA также обеспечивает инфраструктуру для
продуктов промежуточного ПО на основе естественной для CORBA
возможности межброкерных взаимодействий в однородных или
разнородных распределенных системах с применением общего
интерфейса и протокола. CORBA позволяет связать системы и
обеспечить единую виртуальную среду для разработчиков приложений.
На модели CORBA основаны продукты VisiBroker компании и Orbix компании . Оба продукта обеспечивают
связывание с Java, что позволяет отнести их и к категории
промежуточного ПО с Web-возможностями. Межброкерные
взаимодействия основываются на протоколе IIOP (Internet InterORB
Protocol), который рассматривается производителями программного
обеспечения для работы в Internet (в частности, Netscape
Communications Corp.) в качестве кандидата для замены
используемого в настоящее время для взаимодействия клиентских и
пользовательских частей Web протокола HTTP.


Чеканка приложений


С точки зрения инструментальных средств и приложений большее значение имеют объектно-реляционные модели и интерфейсы, а не детали реализации. Средства проектирования баз данных и разработки программного обеспечения играют ключевую роль в облегчении работы администраторов баз данных и программистов с объектно-реляционными моделями.
Проектирование баз данных. Несколько компаний сделало шаги по направлению к объектно-реляционному подходу. Компания недавно поглотила компанию Logic Works и теперь предлагает следство OR Compass. Компания распространяет Universal Modeler. Компания поглотила компанию InfoModelers и продает средство InfoModeler. Другие инструментальные средства, среди которых Object Database Designer компании Oracle и Retional Rose компании , позволяют создавать объектно-реляционные схемы. Многие производители поддерживают только реляционные части Oracle8 и DB2, предпочитая дождаться развития рынка.
По поводу имеющихся методологий и инструментальных средств можно сделать два критических замечания. Во-первых, в большинстве средств проектирования баз данных не используются должным образом бизнес-процессы и правила, из-за чего, вероятно, потребуется переход к Unified Modeling Language, разработанному . Во-вторых, ни один из существующих инструментов не помогает пользователям решить, каким образом реализовывать бизнес-правила - как определяемые пользователями функции в ОРСУБД или внешним образом в объектах приложения.
Разработка приложений. Традиционная разработка приложений баз данных базируется на языках четвертого поколения (4GL), встроенном SQL или интерфейсах уровня вызова типа ODBC или JDBC, API промежуточного программного обеспечения, а также на абстрактных объектах данных, основанных на низкоуровневых интерфейсах. История объектно-реляционных средств разработки подобна истории серверов - частичные успехи и обещаемые достижения.
Продукт JavaBlend компании , находящийся в состоянии бета-тестирования и ожидаемый к выпуску в июне 1998 г., отображает объекты и методы запросов Java на объекты базы данных и SQL с использованием JDBC, а также создает Java-классы для реляционных таблиц.
По утверждению компании, программный интерфейс JavaBlend был специально спроектирован для соответствия стандарту ODMG для объектно-реляционных отображений и объектных баз данных. Ожидается, что JavaBlend будет даже автоматически выводить отношения наследования между таблицами и создавать их для подклассов Java. Во втором выпуске продукта обещается наличие отображения на объектно-реляционные расширения.

Вот фрагмент JavaBlend-кода, показывающий, как транзакции и объекты базы данных отображаются на конструкции Java:

Transaction t = Transaction.create(); Customer c = Customer.selectElement("custID=123"); SalesRep s = c.rep; /* follow foreign key */ c.address = newAddress; s.sales = s.sales + thisOrder; t.commit(); /* write c & s back to database */

Подход JavaBlend поход на те, которые применяют компании Ardent Software в продукте Java Relational Binding (JRB), где Java-классы отображаются в реляционные таблицы посредством JDBC, и Informix в продукте Data Director for Java (DDJ), позволяющем создавать Java-приложения с использованием объектно-реляционных данных. Имеется несколько реализационных различий: в DDJ для взаимодействия клиента с сервером приложений используется Java RMI (Remote Method Invocation), в то время как в JavaBlend будет применяться OQL. Похоже, что поддержка управления транзакциями и запросами в JavaBlend будет более скромной, чем в DDJ. Кроме того, JRB и DDJ доступны уже сейчас.

Программное обеспечение Formida Fire компании , включающее Universal Development Environment (UDE), является единственным известным автору пакетом средств разработки приложений, поставляемый независимым производителем и способным работать с ОРСУБД.


Что означает инкапсуляция?


Говорят, что тип данных инкапсулирован, если экземпляры этого типа не имеют видимых пользователям компонентов. (Термин "экземпляр" используется как удобное, хотя и неуклюжее сокращение для "значение или переменная".) Например, в своей книге Smalltalk-80: The Language and It's Implementation (Addison-Wesley, 1983) Adele Goldberg и David Robson говорят: "Объект состоит из некоторой частной памяти и набора операций ... Публичные свойства объекта являются [спецификациями операций], составляющими его интерфейс... Частные свойства объекта - это набор [компонентов], составляющих его частную память".
Замечание: Автор предпочитает не использовать слишком часто термин "объект", потому что он нечеткий и часто приводит к неправильному пониманию сути. Ниже этот термин используется только в цитатах.
Как явствует из приведенного высказывания, пользователи Smalltalk оперируют экземплярами ("объектами") инкапсулированного типа посредством операций, явно определенных в связи с этим типом. Например, можно иметь тип CIRCLE и быть в состоянии вызывать операции, которые возвращают площадь - или длину окружности, или радиус (и т.д.) - любого заданного круга. Однако было бы незаконно утверждать, что круг имеет компонент площади, компонент длины окружности, компонент радиуса и т.д. Важным следствием этого является то, что мы не знаем и не должны знать, как круги представлены внутри системы; это представление доступно только через код, реализующий операции. Другими словами, для пользователей представляет интерес тип - это часть модели, - в то время как представление интересно только для реализации. В своем введении в объектные базы данных Stanley Zdonik и David Maier говорят: "Инкапсуляция [означает, что у каждого типа имеется] набор [операций и] представление ... которое выделяется для каждого его экземпляра. Это представление используется для сохранения состояния объекта. Только методы, реализующие операции объектов, имеют доступ к представлению, что дает возможность изменять представление не затрагивая оставшуюся часть системы.
Требуется только переписать методы".(1)

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

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

Последнее замечание по поводу термина. При подготовке этого материала автору пришлось просмотреть около 20 книг по объектной технологии и связанным темам. Удивительно, что ни в одной из них не удалось найти точное определение понятия инкапсуляции. (Лучшее разъяснение содержится в приведенной выше цитате из книги про Smalltalk; следует заметить, помимо прочего, что в этой книге вообще не используется термин "инкапсуляция", его нет даже в индексе.) Автор обнаружил, что некоторые авторы понимают под этим понятием физическое связывание определений представления данных и определений операций. Например, "Инкапсуляция - это понятие соединения обработки или поведения с экземплярами объектов, определенных в классах. Инкапуляция позволяет упаковывать вместе код и данные".(2) Но, по мнению автора, такая интерпретация термина приводит с перемешиванию модельных и реализационных вопросов. Пользователь не должен беспокоиться, у него не должно возникать поводов для беспокойства по поводу того, "упакованы ли вместе" код и данные. Убеждение автора состоит в том, что с точки зрения пользователя, т.е. с модельной точки зрения, инкапсуляция означает, что данные не содержат видимых пользователям компонентов и могут быть доступны только через посредство уместных операций.


Что такое промежуточное ПО?


Если говорить по-простому, промежуточное ПО обеспечивает простой
для использования API (Application Programming Interface -
интерфейс прикладного программирования) между приложением и
требуемыми для него ресурсами. Например, если производится
Java-апплет, для работы которого требуются внешние данные, можно
использовать классы пакета JDBC (Java Database Connectivity) для
доступа к информации из любого числа баз данных. Классы JDBC
скрывают от разработчика сложности целевой базы данных и
позволяют использовать любую базу данных без потребности
понимания ее специфических особенностей. Аналогичные возможности
обеспечивает ODBC (Open Database Connectivity) для приложений
"клиент-сервер", работающих в среде Windows, и средства, подобные
Borland Database Engine (BDE).
Возможности промежуточного ПО не ограничиваются обеспечением
доступа к базам данных. Продукты этого рода также дают
возможность прозрачного доступа на уровне API к другим системам и
их сервисам без потребности знать, что из себя представляют эти
системы. Слой промежуточного ПО может найти систему, используя
какой-либо вид сервиса именования, вызвать удаленный процесс и
возвратить ответ вызывающему процессу. К соответствующей
категории промежуточного ПО относятся Distributed Computing
Environment (DCE) компании , продукты, основанные на распределенной
объектной технологии CORBA (Common Object Request Broker
Architecture - общая архитектура брокера объектных заявок), и
большинство продуктов промежуточного ПО, основанных на передаче
сообщений (Message-Oriented Middleware - MOM).


Что значит термин VLDB?


Термин VLDB (Very Large Data Bases - сверхбольшие базы данных)
перегружен. Размер базы данных является лишь одним и не самым
важным параметром в контексте этой статьи. К примеру сказать,
практически не один из обсуждаемых далее вопросов не существенен
для баз данных, используемых в приложениях OLTP (On-Line
Transaction Processing), поскольку в таких приложениях запросы
даже к большим базам данных являются короткими и затрагивают
незначительное число элементов данных и метаданных. К тому же,
базы данных OLTP часто создаются и администрируются как наборы
относительно независимых небольших баз данных, разделенных в
соответствии со значением ключа. Вопросы же, обсуждаемые в этой
статье, касаются сверхбольших баз данных, запросы к которым
затрагивают большие объемы данных и метаданных и включают
массивные операции соединения, агрегации и т.п. Такие базы данных
и приложения сегодня главным образом связаны со складами данных
(data warehousing) и добычей данных (data mining).
Для среды VLDB характерны большое число операций ввода/вывода при
выполнении одного сложного оператора языка SQL и частая
потребность в генерации больших промежуточных наборов данных.
Запросы часто пересекают границы установленных разделов и
вовлекают данные, разбросанные по всей базе данных. Поэтому такая
база данных, как правило, должна администрироваться как единое
целое. Автор ориентируется на базы данных размером не менее 250
Гбт, к которым поступают сложные запросы, для которых требуется
оперативное администрирование для реорганизации, архивирования и
восстановления и для которых характерно регулярное выполнение
массивных операций (вставки, удаления и модификации) над объемами
данных не менее 25 Гбт. Для таких баз данных требуются системы
MPP (Massively Parallel Processing) или очень крупные кластеры
SMP (Symmetric MultiProcessor). Однако многие из обсуждаемых
далее вопросов относятся и к более мелким базам данных.


Continuing our discussion of redundancy in SQL Greevous Bodily Harm (Part 2 of 2)


C.J. Date

()
Кристофер Дейт является независимым автором, лектором, исследователем и консультантом, специализирующимся в области систем реляционных баз данных. Корресподенцию ему можно послать по почте по адресу: Database Programming & Design, 411 Borel Ave., Ste. 100, San Mateo, CA 94402.
Как и в первой части заметки, для примеров используется известная база данных "поставщики и детали":
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


CORBA: Masterminds Object Management


Warren Keuffel, software engineer and technology journalist

E-mail:
В 1989 г. группа компаний-производителей и пользователей, которые
считали перспективным применение объектно-ориентированного
подхода для разработки программного обеспечения, образовали
коалицию с целью навести порядок в хаотичном мире объектов.
Коалиция получила название Object Management Group (OMG). CORBA
является наиболее важным продуктом OMG. CORBA (Common Object
Request Broker Architecture - Общая архитектура брокера объектных
заявок) представляет собой спецификацию объектно-ориентированного
"универсального программного обеспечения промежуточного уровня"
("universal middleware"), позволяющего программистам без
потребности знания того, как и где реализованы объекты, написать
код новых объектов, взаимодействующих с существующими. OMG
специфицирует два базовых средства, предназначенных для
проектировщиков и разработчиков объектных систем, - IDL и ORB.
IDL (Inrerface Definition Language) в объектном мире играет роль,
аналогичную роли английского языка в международном сообществе
программистов, т.е. дает возможность объектам понимать друг
друга. Однако IDL только частично решает проблему обеспечения
возможности взаимодействия объектов. Требуется программное
обеспечение, которое доставляет заявки на вызов методов объектов.
В терминах OMG такое программное обеспечение называется ORB
(Object Request Broker). Как видно, акроним CORBA получается из
ORB путем добавления "C" ("Common") в начало и "A"
("Architecture") в конец. Тем самым, CORBA является архитектурой
(или спецификацией), определяющей общие свойства, которыми должны
обладать все реализации брокеров объектных заявок,
соответствующие спецификации. На самом деле, OMG не создавала
спецификацию CORBA и тем более программные продукты. OMG
запрашивает у представителей сообщества разработчиков
программного обеспечения предложения по поводу технологических
спецификаций.
Собранные предложения анализируются и оцениваются

членами OMG, и общая спецификация принимается на основе общего

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

политический как и технологический характер, во многом отражая

маркетинговую стратегию компаний, доминирующих в OMG (например,

IBM). Процесс принятия спецификаций в OMG носит демократический

характер; учитываются (хотя и не всегда принимаются во внимание)

многие точки зрения. По этой причине спецификация OMG более

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

архитектура компании Microsoft DCOM (Distributed Component Object

Model). Microsoft пользуется собственной технологической моделью,

не обращая внимание на наличие других точек зрения.

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

интересной частью CORBA является спецификация OTS (Object

Transaction Service), в которой определяется, каким образом

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

объектов и брокеров объектных заявок. Спецификация OTS была

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

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

транзакций. Технология монитора транзакций Encina, в частности,

была внедрена в общий технологический пакет DCE (Distributed

Computing Environment). Другой наиболее важный монитор транзакций

Tixedo (BEA/Novell) был использован в спецификации мониторов

распределенной обработки транзакций X/Open. Спецификация OTS была

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

мониторами транзакций, соответствующим спецификации X/Open.

Комитеты OMG, занимавшиеся OTS, понимали, что они должны

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

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

технологию управления транзакциями. Поэтому OTS обеспечивает

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

транзакциями, основанных как на ORB, так и на традиционных



мониторных транзакционных службах. Кроме того, OTS предполагает

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

(если угодно, в неоднородной среде) с полным следованиям

принципам ACID (Atomicy, Consistency, Isolation, Durability) и

двухфазным протоколам фиксации.

Эффективность обработки транзакций частично связана с наличием

хорошего управления параллельным выполнением транзакций. Для этих

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

(Concurrency Control Service). Определен набор возможных

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

заканчивая условными блокировками (intention locks). Изменяемые

блокировки (upgrade locks) позволяют программистам избегать

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

транзакционными, так и нетранзакционными).

Работа OTS делится между клиентами и серверами. Клиенты

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

транзакций. В OTS определены четыре важных интерфейса: Current,

Coordinator, Resource и SubtransactionAwareResource. Интерфейс

Current позволяет программисту установить контекст транзакции; по

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

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

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

управляющим ресурсами. Когда ORB получает ответ от

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

данные исходному клиенту. Интерфейс Resource относится к

объектам, поддерживающим протокол двухфазной фиксации. В

транзакции может участвовать несколько объектов с интерфейсом

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

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

Resource голосует против, транзакция откатывается или

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

клиента. Для повышения эффективности в средах с одним объектом

Resource в интерфейсе Current имеется возможность использовать



сообщение commit_one_phase, посылка которого позволяет отказаться

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

До появления версии спецификации CORBA 2.0 после установки ORB от

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

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

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

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

1994 г. была выпущена спецификация CORBA 2.0. В ней

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

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

Возможность межброкерных взаимодействий на основе TCP/IP

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

World Wide Web. 4Поэтому компания 0Netscape Communications Corp.

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

Netscape ONE (Open Network Environment) предполагается

использование межброкерного обмена сообщениями IIOP (Internet

Inter-ORB Protocol) вместо ориентированного на передачу файлов

протокола HTTP, применяемого в настоящее время. Этот переход

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

намного меньше тех, которые требуются HTTP.

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

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

объявила о партнерстве с компанией Transarc с целью включения

сервисов Encina OTS в ORB Orbix. Поскольку Transarc также

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

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

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

протокола IIOP можно использовать DCE в среде CORBA, поскольку в

CORBA 2.0 определен протокол GIOP (General Inter-ORB Protocol);

обеспечивается отображение сообщений GIOP в сообщения протокола

DCE CIOP (Common InterORB Protocol). Другой компанией,

предлагающей брокер объектных заявок, совместимый с CORBA 2.0,

является Visigenic Software Inc.


Продукт этой компании VisiBroker

for C++ ( раньше назывался ORBeline) является полной реализацией

ORB в соответствии со спецификацией CORBA 2.0 с поддержкой IIOP.

Возможно взаимодействие VisiBroker с другим продуктом компании,

VisiBroker for Java (раньше назывался Black Widow). Последний из

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

для построения распределенных Java-приложений. Продукт, который

может заинтересовать программистов, желающих интегрировать CORBA

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

Persistence Software Inc. Центральной концепцией компании

Persistence является объектный кэш, поддерживающей возможности

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

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

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

использования языка IDL.

Координаты компаний:

BEA Systems Inc.:

Black & White Software Inc.:

Gemstone Systems Inc.:

Iona Technologies Inc.:

Object Management Group Inc.:

Persistence Software Inc.:

Transarc Corp.:

Visigenic Software Inc.:


a vice president of worldwide


, a vice president of worldwide data warehousing solutions at Cambridge Technology Partners
Оригинал статьи можно найти по адресу

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

Ну и что, скажете вы. Сегодня ВСЕ используют базы данных. Автор с этим согласен. Заканчивается десятилетие, в котором мы видели становление Internet, переход технологии "клиент-сервер" в разряд mainstream, рождение новых подсегментов рынка компьютерных приложений (call-центры, пакеты автоматизации продаж, корпоративные информационные приложения в архитектуре "клиент-сервер"). Еще одно обстоятельство не перестает изумлять автора. Раньше в большинстве случаев СУБД использовались как продвинутые системы управления файлами. Сотня приложений, анализируемых автором в течение каждого года, составляет бесконечно малую часть сотен тысяч или даже миллионов приложений, существующих в мире бизнеса. Но определения схемы приложений всегда поражают, независимо от того, включают ли они десяток реляционных таблиц или несколько сотен. Почти всегда приходится видеть скелетные образующие языка определения данных (DDL - Data Definition Language), такие как операторы CREATE TABLE и CREATE INDEX со списками столбцов и указанием их типов данных и размеров, а также, возможно, с несколькими разделами NOT NULL.

Но где же разделы CHECK? Где ограничения для различных видов ссылочной целостности и резидентных в базе данных бизнес-правил? За пределами операторов DDL иногда встречается использование хранимых процедур, ну и что?

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

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

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


Managing Principal of the consulting



Managing Principal of the consulting firm Frazer Group, Menlo Park. California

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

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

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

объектно-ориентированных баз данных во многом обязано отраженным

в стандарте SQL2 врожденным ограничениям реляционной модели. В

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

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

модели данных, а системные администраторы желают иметь общую

технологию баз данных, к которым применим некоторый обобщенный

набор средств администрирования. В результате реляционная модель

расширяется поставщиками, и комитеты по выработки стандарта SQL3

включают в язык объектные свойства.

Объектно-реляционные (ОР) базы данных все еще являются новинкой и

обладают размерами в пределах 50 Гбт. По мере нарастания

распространенности ОР-технологии и снижения стоимости расходов на

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

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

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

перехода на новую технологию.

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

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

средств, так и программного обеспечения, то ограничения ОР-баз

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

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

такими ведущими компаниями - разработчиками продуктов управления

ОР-базами данных как IBM, Informix, NCR, Oracle, Sybase и

Computer Associates для обеспечения масштабируемости сложных

запросов к очень большим наборам ОР-данных. Наличие в этих

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

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

эффективности, который имел место в чисто реляционных системах.

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

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

также на разработчиков приложений и администраторов. С

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

Наконец, автор поясняет, что параллельное выполнение операторов

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

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

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

Однако в случае ОР-систем добиться параллелизма намного сложнее.


Денормализация ERD


Под денормализацией ERD понимается такая форма манипулирования структурой модели, при которой сохраняется специфика проблем бизнеса. Обычно преобразования происходят в виде комбинирования или сжатия ряда логических объектов модели. Это позволяет сократить длину цепочек вызовов, требуемых приложению для навигации в пространстве объектов базы данных, при преобразовании структуры от логических к физическим объектам. Ни при каком условии нельзя производить денормализацию ERD без предварительной проверки логической модели. Устранение связей 1:1. Такие связи между типами сущности A и B означают, что для каждого экземпляра A имеется один и только один экземпляр B. Хотя ключевые атрибуты сущностей могут быть разными, равноправное участие этих сущностей в связи означает, что к ним можно относиться как к единой сущности в любой единицы работы над данными. Различается только степень использования атрибутов. Комбинирование атрибутов с различной загрузкой не изменяет бизнес-представление и уменьшает время доступа за счет наличия только одного физического объекта (таблицы) и требования меньших дополнительных накладных расходов (индексов).
Разрешение связей M:N. Для каждого экземпляра A существует много экземпляров B, и для каждого экземпляра B существует много экземпляров A. При наличии сложных взаимодействий связи M:N отражают пересечение разных вхождений ключей. При "ручной" обработке с такой связью можно обращаться с помощью создания промежуточной сущности между двумя связанными сущностями, называемой ассоциативной сущностью. Ключ этой сущности является конкатенацией первичных ключей участвующих в связи сущностей. Например, если ключ A есть 1, а ключ B - 2, то ключом ассоциативной сущности A,B будет 1,2.
CASE-средства автоматически разрешают эту проблему путем создания ассоциативной сущности в процессе преобразования модели. Однако производители этих средств генерируют нестандартные имена для ассоциативных сущностей и идентифицирующих их ключей. Для порождения стандартизованных имен многие администраторы данных разрешают связи M:N путем явного создания ассоциативных сущностей с соответствующим именованием ключей.
После разработки ассоциаций при отображении процессов на сущности часто становится ясно, что реальный интерес представляют именно ассоциации. Редко бывает так, что в ассоциативной сущности отсутствуют действительно используемые атрибуты и единственным таким атрибутом является дата установления связи. Во многих случаях реализуется только ассоциативная таблица, а атрибуты сущностей-участников связи мигрируют в нее для повышения эффективности.

Разрешение рекурсивных связей. Рекурсивные связи представляют собой связи на экземпляры того же типа сущности, или "спиральные" связи. Это, хотя и может показаться сложным, означает всего лишь иерархию "предок-потомок" (возможно, многоуровневую). В случае одноуровневой рекурсии поведение аналогично связи 1:M с распространением ключа как внешнего для другого участника. Результатом является то, что рекурсивная сущность обладает внешним ключом, который на самом деле является иным образом первичного ключа. Однако некоторые CASE-средства генерируют нестандартное имя внешнего ключа. В этом случае администратору данных стоит самому произвести разрешение рекурсивной связи и произвести правильное именование внешнего ключа.

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

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


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

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

Во многих CASE-средствах супертипы и подтипы реализуются как отдельные сущности для преобразований, но в случае наличия связей M:N при использовании соглашений об именовании сущностей и ключей, предлагаемых поставщиками, в результате преобразований образуются нестандартные имена сущностей и атрибутов. В дополнение к этому, многие CASE-средства добавляют унаследованные атрибуты к каждому подтипу. Администратор должен обратить внимание на подтипы и исправить имена в соответствии со стандартами именования до начала преобразований.

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

Связи подмножеств представляют собой различные бизнес-представления относительно частичных множеств экземпляров сущностей для двух заданных типов сущности. Например, половина экземпляров A связана с половиной экземпляров B некоторым образом. Оставшаяся часть экземпляров A связывается с оставшейся частью экземпляров B некоторым другим образом.


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

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

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

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

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


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

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

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

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


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


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

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

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

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

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



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

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


Доля рынка


В соответствии с данными компании Dataquest Inc., в мире UNIX IBM
продала только 3% лицензий по сравнению с 54% компании Oracle.
Частично это объясняется тем, что IBM всегда ориентировалась на
очень большие системы переднего края и только теперь начала
экспансию в сторону систем среднего и малого класса. Тем не
менее, наблюдается существенный рост доходов IBM по продаже
систем для сред UNIX и NT. Для Oracle ситуация весьма отличается.
Компания начинала со средних систем, а теперь одинаково хорошо
работает на S/390 и на персональных системах (хотя неясно, какова
стратегия Oracle по отношению к S/390, если учитывать
традиционное доминирование IBM на этой платформе). Обе компании
усиленно инвестируют версии продуктов для Windows NT.


Другие расширители


  • Image Extender может хранить и выбирать изображения,
    представленные в нескольких популярных форматах, включая GIF,
    JPEG и BMP, а также преобразовывать изображения из одного формата
    к другому.
  • Video Extender может хранить и выбирать
    видео-последовательности, представленные в нескольких популярных
    форматах, включая MPEG1, AVI и Quicktime.
  • Audio Extender может хранить и выбирать аудио-клипы в
    нескольких популярных форматах, включая AIFF, MIDI и WAVE.
  • Fingerprint Extender может хранить и выбирать отпечатки
    пальцев, представленные в специальном формате, а также
    производить поиск отпечатков пальцев по заданному образцу.


    Другие средства моделирования


    В PowerDesign 6.1 компании Sybase добавлена поддержка абстрактных
    типов данных. Полная поддержка объектов и моделирования в духе
    UML ожидается в середине 1998 г. Выпуск Object Database Designer
    компании Oracle - основанного на UML продукта, генерирующего
    классы Си++ и схему базы данных, расширенной объектами, ожидается
    в начале 1998 г. Весной 1998 г. ожидается выпуск Designer/2000 с
    возможностями объектно-реляционного моделирования. Компания
    Popkin Software & Systems () собирается построить
    средство объектно-реляционного моделирования на основе
    возможностей объектного моделирования (UML) системы SA/Object
    Architect.
    Средства категории ECM нужны для отображения классов и методов в
    соответствующие объектно-реляционные типы и функции. Кроме того,
    эти средства должны давать проектировщикам выбор между
    размещением методов в прикладных классах и их инкапсуляцией в
    базе данных. Средства ECM включают Paradigm Plus компании
    Platinum Technology Inc. (), Rational Rose и
    Select Enterprise компании Select Software Tools
    (). Продукт компании Rational Software уже в
    состоянии генерировать схемы для Oracle8, хотя компания
    рассматривает этот как вспомогательный и не заменяющий средства
    моделирования баз данных. Основанный на UML продукт ParadigmPlus
    в настоящее время позволяет моделировать и производить прямую
    инженерию объектных расширений Oracle8 на фазах детального
    проектирования и конструирования. ParadigmPlus создает логические
    и физические модели, которые включают абстрактные типы данных,
    атрибуты, методы, и отображает их в физические схемы и
    программные классы Oracle8. Между объектной моделью приложения и
    моделью базы данных устанавливаются мосты на основе "общей
    метамодели".
    В заключение автор отмечает, что представленные средства
    моделирования имеют много общего с тремя основными ОРСУБД: они
    незрелые и функционально неполные. Общим дефектом рассмотренных
    средств является недостаточная методологическая поддержка при
    принятии решения об использовании типов.


    Essential Modelling Options



    Independent consultant, over the last 11 years has built and consulted on dozens of warehouses, using various databases.
    Оригинал статьи можно найти по адресу
    Несмотря на возникающие иногда религиозные войны между направлениями многомерного моделирования и построения схемы на основе третьей нормальной формы, истина состоит в том, что нужны оба подхода.
    Когда меня спрашивают сегодня, какую позицию я занимаю в сражении между звезднообразной схемой и третьей нормальной формой (3NF), я упорно отвечаю: "ровно по середине". Некоторые полагают, что пригоден один из подходов, но на самом деле имеется место для каждого из них. Я прислушиваюсь к аргументам, читаю статьи и обзоры дискуссий, реализую разнообразные модели, но не думаю, что любой узкий выбор пригоден для всех ситуаций.
    Третья нормальная форма является моделью сущностей, связей и атрибутов. При использовании этого подхода мир обычно представляется логическим и математическим образом, подобно подходу "кто, что, когда и как", применяемому в журналистике. Любой отход от этой "нормальной" модели называется денормализацией.
    Многомерная модель представляет мир в терминах менее абстрактных понятий, таких как "сколько и как часто" - "фактах", появляющихся на интересующем нас пересечении измерений. Она "денормализована", поскольку в данном пересечении может содержаться много фактов, которые можно было бы поместить в одну "строку" таблицы.
    К счастью для нас (людей из области информационных технологий и из мира бизнеса), Teradata предоставляет выбор физической реализации той и другой моделей. Я приведу обсуждение того, как все это работает и почему выбор является настолько важным.


    Гипотетическое финансовое приложение


    Предположим, что простая база данных Stockinfo содержит
    информацию о разных биржах. База данных содержит информацию о
    ценах закрытия каждой биржи для каждого торгового дня. Каждая
    строка таблицы соответствует отдельной бирже, и информация о
    ценах закрытия P1, P2, ..., Pm содержится в одном столбце
    Clprice как временная серия - новый тип данных. Запрос,
    направленный на поиск привлекательных для инвестиций бирж, мог бы
    иметь следующую форму: "Найти все биржи из списка OTC с текущей
    ценой закрытия, меньшей $30, с отношением цена/доход, меньшим 15,
    с бета (мерой устойчивости) за последний год, меньшей или равной
    единице, и такие, у которых цена возрастала более чем на 10
    процентов в течение последних двух месяцев".
    SELECT FROM Stockinfo Candidate AS
    Symbol, Industry, #PRICE (Clprice), Earnings,
    #BETA (Clprice, 240), #%CHANGE (Clprice, 40)
    WHERE Exchange = NASDAQ AND #PRICE (Clprice) < 30 AND
    #BETA (Clprice, 240) 10%
    Здесь #BETA (S,n), #PRICE (S) и #%CHANGE (S,n) - новые методы,
    применимые к временным рядам S и вычисляемые для последних n
    элементов; для PRICE (S) n=1.
    Поскольку база данных бирж очень велика, требуется выполнить этот
    запрос наиболее эффективным способом. В идеале, все вычисления
    нужно было бы выполнить параллельно для каждой строки. Однако на
    практике степень параллельности будет ограничена числом доступных
    процессоров и возможностями программного обеспечения.
    Заметим, что столбец Clprice меняется в каждый торговый день и
    содержит гораздо больше данных, чем другие столбцы (Symbol, Name,
    Address, Exchange, Industry и т.д.). Поэтому может оказаться
    разумным хранить элементы столбца Clprice отдельно от строк, в
    которые они входят; стратегии буферизации данных в реляционных
    СУБД не работают с большими элементами столбцов так же хорошо,
    как с малыми, и обычно их плохо удается обрабатывать единообразно
    совместно. В разделе WHERE содержится смесь стандартных и
    нестандартных операторов SQL. Если это является обычной ситуацией

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

    столбца Clprice повысит эффективность ввода/вывода.

    Понятно, что даже в этом простом случае разработчики ОР СУБД не

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

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

    элементов столбцов может потребоваться память объемом более одной

    страницы, отсутствует информация о размерах и степени

    устойчивости данных. Поэтому, в отличие от чисто реляционных

    систем, за оптимизацию и распараллеливание в ОР-системах

    совместно отвечают поставщик ОР СУБД, разработчики расширенных

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

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

    Как же на это реагируют разработчики ОР СУБД? Имеются два разных

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

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

    и интегрированный.

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

    этом случае работающая реляционная СУБД существует отдельно от

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

    данных. Этот факт скрывается от прикладной программы общим

    внешним программным обеспечением. Кроме поддержки интерфейса

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

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

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

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

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

    запросов.

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

    технологию объектных СУБД и пригодна для работы с распределенными

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

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

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

    базы данных для включения их в федеративную организацию, могут

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



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

    К сожалению, чем меньше делается таких изменений, тем большая

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

    более сомнительны перспективы оптимального выполнения. Часто

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

    объектной и реляционной базами данных. Рассмотрим, как будет

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

    бирж. Проверки, относящиеся к столбцам Exchange, Industry,

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

    Вычисления же BETA и %CHANGE в большей степени подходят для

    объектной базы данных. Поэтому программное обеспечение верхнего

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

    результате вместо применения простого просмотра файла (возможно,

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

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

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

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

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

    было бы заставить реляционную СУБД как можно тщательнее отобрать

    подходящие строки, а затем передать эти строки объектной СУБД для

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

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

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

    двумя СУБД.

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

    Для обеспечения конкурентоспособности федеративной архитектуры

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

    выполнения запросов. Технология распараллеливания в настоящее

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

    в области чисто объектных баз данных. Многое можно заимствовать,

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

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

    системах. Однако подобное изменение работающей объектной базы



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

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

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

    обрабатывать большие наборы промежуточных результатов.

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

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

    усилий. В историческом плане эта архитектура близка к архитектуре

    Sybase/NCR Navigation Server для параллельных реляционных СУБД.

    По указанным выше причинам позже в продукте Sybase MPP стали

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

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

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

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

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

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

    для VLDB распараллеливание, глобальная оптимизация

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

    применительно к унаследованным данным. Ценой этого является

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

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

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

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

    Для успешной реализации интегрированной ОР-архитектуры требуется

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

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

    методов к старым и новым операторам (перегрузка), возможность

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

    подходов к восстановлению и (по крайней мере, в будущем)

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

    объектов. Чтобы оценить влияние этих требований, достаточно

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

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

    На этапе грамматического разбора необходимо распознавать новые



    типы данных (временная серия в нашем примере) и новые операторы

    над этими типами (например, #BETA и #%CHANGE). Нужно быть в

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

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

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

    среде ОР VLDB такие оценочные функции часто должны быть более

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

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

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

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

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

    внимание стратегию хэширования. Очень большие объекты зачастую

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

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

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

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

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

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

    это не так. Например, применимые к данным в качестве методов

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

    эти операции не являются "коммутативными" в математическом

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

    зашифрованные данные не удастся существенно сжать. Наконец,

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

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

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

    В интегрированной архитектуре должно допускаться полностью

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

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

    от особенностей реляционной СУБД внедрение этой возможности может

    привести к существенным изменениям в реализации. Журнализация

    объектных данных - эта еще одна область, в которой часто



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

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

    журнал полные временные ряды при добавлении к Clprice нового

    элемента или писать в журнал всю строку (включая Clprice) при

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

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

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

    случаев, когда (объектные) данные не журнализуются.

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

    ОР-архитектуре должны допускать параллельный доступ от процессов

    и нитей ОР-СУБД. Эти компоненты должны отслеживать физическое

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

    храниться отдельно (или даже на отдельном носителе) от других

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

    материализовать в памяти большие объекты для обработки "когда это

    точно нужно" и возвращать их во внешнюю память после обновлений.

    Наконец (хотя это и не относится непосредственно к пути

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

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

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

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

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

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

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

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

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

    и журнализацией и кэшированием объектов. Как и в случае

    реляционных СУБД, требуется возможность параллельного выполнения

    административных функций.


    HAVING без GROUP BY (I)


    Хорошо известным (и малопонятным) фактом является то, что запросы на языке SQL могут включать раздел HAVING без соответствующего раздела GROUP BY. Рассмотрим, например, следующий запрос:
    Q8: Выдать общий объем поставок для всех деталей, если и только если минимальный объем поставки каждой детали больше 50. На языке SQL возможна следующая формулировка:
    SELECT SUM(SP.QTY) AS TQY FROM SP HAVING MIN(SP.QTY) > 50 ;
    Если база данных содержит значения, приведенные в первой части заметки, результатом запроса будет таблица с одним столбцом с именем TQY и одной строкой, содержащей значение 3100.
    Пояснение: Поскольку раздел GROUP BY отсутствует, то раздел HAVING применяется к "сгруппированной" версии SP, содержащей ровно одну группу. Если условие раздела HAVING вычисляется в true для этой группы (а так оно и есть для базы данных наших примеров), то раздел SELECT возвращает требуемую сумму значений. Если же при вычислении условия HAVING было бы получено false, то группа была бы отвергнута и окончательный результат был бы пустым. (Более точно, результатом была бы таблица с одним столбцом, не содержащая ни одной строки.)
    Можно ли сформулировать запрос без использования HAVING? Очевидная попытка (с использованием "преобразования Типа 2") дала бы следующий результат:
    SELECT DISTINCT SUM(SP.QTY) AS TQY FROM SP WHERE (SELECT MIN(SP.QTY) FROM SP) > 50 ;
    Но, к сожалению, эта формулировка не является логически эквивалентной предыдущей. Чтобы убедиться в этом, предположим, что минимальный объем поставки должен быть больше 500. Тогда при выполнении запроса в первой формулировке будет произведена таблица с одним столбцом и без единой строки. В отличие от этого, при выполнении запроса без раздела HAVING результирующая таблица будет состоять из одного столбца и одной строки (содержащей неопределенное значение), поскольку условие раздела WHERE вычисляется в false для каждой строки SP, и поэтому раздел SELECT будет вычисляться для пустой таблицы.
    Замечание: неопределенное значение с строке результата появляется в результате некорректной спецификации SQL, в соответствии с которой значение SUM для пустого множества есть NULL (а должно было бы быть нулевым).

    Но формулировка, эквивалентная исходной и не включающая HAVING, все- таки существует. Она немного более хитрая:

    SELECT DISTINCT ( SELECT SUM(SP.QTY) FROM SP) AS TQY FROM SP WHERE (SELECT MIN(SP.QTY) FROM SP) > 50 ;

    При выполнении запроса в этой формулировке, если (внешние) разделы FROM и WHERE совместно производят пустую таблицу, то таким будет и результат всего запроса. Причина состоит в том, что единственный элемент, указанный в разделе SELECT является не ссылкой на агрегатную функцию SUM, а скалярным выражением, содержащим такую ссылку. Мощность окончательного результата (т.е. число строк в результирующей таблице) не зависит от вида этого скалярного выражения; можно было бы заменить (SELECT SUM ...) на SP.P#, на SP.QTY или даже на литерал. Более детально, происходит следующее:

  • Предположим, что условие раздела WHERE вычисляется в false для каждой строки SP.
  • Тогда разделы FROM и WHERE совместно производят пустую таблицу (без строк).
  • Подзапрос в разделе SELECT, конечно, возвращает значение 3100. (Более точно, он вырабатывает таблицу с одним столбцом и одной строкой, содержащей численное значение, но SQL извлекает это значение из таблицы. Здесь для нас это обстоятельство не слишком важно, но в SQL вообще оно вызывает проблемы.)
  • Итак, обсуждаемая формулировка запроса логически эквивалентна следующей:

    SELECT 3100 AS TQY FROM empty ;

    (empty именует пустую таблицу.) Очевидно, что результатом такого запроса является таблица с одним столбцом TQY и без строк.

    Теперь мы можем сформулировать еще одно правило преобразования: Пусть имеется таблица R{A,B}, и agg1 и agg2 - агрегатные функции, применимые к R.A и R.B соответственно. Тогда выражение

    SELECT agg1(R.A) AS C FROM R HAVING agg2(R.B) comp scalar ;

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

    SELECT DISTINCT ( SELECT agg1(R.A) FROM R ) AS C FROM R WHERE ( SELECT agg2(R.B) FROM R ) comp scalar ;

    (Здесь comp - некоторый скалярный оператор сравнения, а scalar - некоторое скалярное выражение.)

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


    HAVING без GROUP BY (II)


    Имеется еще одно обстоятельство, связанное с запросами, которые содержат раздел HAVING и не содержат раздел GROUP BY. В языке SQL в связи с этим имеется логическая ошибка (еще одна!). Рассмотрим следующий запрос:
    SELECT SUM(SP.QTY) AS TQY FROM SP HAVING 0 = 0
    Предположим, что в данный момент SP не содержит ни одной строки. Тогда логично считать, что "сгруппированная" версия SP, к которой применяются разделы SELECT и HAVING, не содержит ни одной группы и что корректным результатом будет таблица с одним столбцом и без единой строки. Однако SQL производит результат с одним столбцом и одной строкой (содержащей неопределенное значение). Считается, что "сгруппированная" версия SP содержит в точности одну группу (пустую); условие HAVING (тривиально) вычисляется в true для этой группы, и поэтому раздел SELECT тоже вычисляется для такой группы (вместо того, чтобы применяться к сгруппированной таблице, не содержащей ни одной группы).
    Упражнение для читателей: Ниже приведена "эквивалентная" формулировка запроса без раздела HAVING, полученная применением преобразования Типа 3. Можно ли повергнуть эту формулировку подобной критике? Если нет, то вторая формулировка, конечно, более предпочтительна.
    SELECT DISTINCT ( SELECT SUM(SP.QTY) FROM SP ) AS TQY FROM SP WHERE 0 = 0 ;
    В завершение раздела следует заметить, что в любом случае запросы с HAVING и без GROUP BY не очень "осмысленны".


    IBM


    Компания IBM ведет исследования в области инфраструктуры расширяемых реляционных баз данных в течение более чем десяти лет. Компания была первой из основных поставщиков, выпустившим на рынок реляционный сервер баз данных с объектными расширениями: DB2 Common Server 2 (в июле 1995 г.). Теперь IBM готова начать поставки обновленного продукта с новым названием - DB2 Universal Server, представляющего собой слияние начальных объектно-реляционных свойств DB2 Common Server 2.1 с возможностями параллельной обработки DB2 Parallel Edition 1.2 и доступного на разнообразных мультипроцессорных платформах - SMP, кластеры и MPP. Ключевым моментом является то, что IBM обеспечивает полную функциональность на основе единого исходного текста сервера. Это обеспечивает основу новых разработок, тем более что расширения с самого начала базируются на полностью параллельных средах.
    Стратегия IBM в области объектно-реляционных баз данных включает четыре основных компонента. Во-первых, универсальная база данных DB2 (UDB - Universal DataBase) находится в стадии бета-тестирования и должна начать поставляться в третьем квартале 1997 г. Во-вторых, разновидность UDT - сильные связи с файлами (robust file links) позволяет DB2 UDB активно управлять внешне хранимыми данными с соблюдением требований безопасности и целостности. (Реализация этой возможности ожидается к концу 1997 г.) Третий компонент стратегии компании - DataJoiner - промежуточное программное обеспечение для доступа к неоднородным базам данных. Этот компонент включает все функциональные возможности сервера DB2, глобальный оптимизатор с расширяемыми знаниями о поддерживаемых источниках данных, возможность компенсировать функциональные различия между этими источниками. В планах компании позволить DataJoiner использовать объектно-реляционные расширения UDB при работе с поддерживаемыми менеджерами данных. Наконец, IBM разрабатывает компонент объектного слоя, называемый Client Object Support, который обеспечит единое логическое представление всех доступных данных, а также их транзакционную согласованность, управление кэшами клиентов и интеграцию с объектно-ориентированными языками.

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

  • Расширяемая система типов - уточненные типы, ADT и объекты OLE с поддержкой в будущем ADT в стиле SQL-3, строчных типов, типов коллекций, ссылок, множественного наследования и репликации данных UDT.

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

  • Расширяемая система индексации - IBM обеспечивает свои собственные индексы специального назначения для типов данных, поддерживаемых расширителями DB2 (DB2 Relational Extenders). В будущем выпуске будут поддерживаться определяемые пользователями индексные структуры, навигационный доступ через ссылки и возможность строить индексы на выражениях, на результатах вызовов функций и на атрибутах ADT.

  • Расширяемый оптимизатор - DB2 уже включает основанный на правилах оптимизатор с возможностью выполнять глобальную оптимизацию и преобразования запросов. Планируется расширить интерфейс оптимизатора с тем, чтобы можно было добавлять новые правила. Разработчик может указать стоимость UDF, включая информацию о том, производит ли функция внешние действия. При интеграции с DB2 Parallel Edition оптимизатор также применяет параллельные операции для разделенных определенных пользователями данных и индексов.

  • Большие объекты и внешние данные - LOB может храниться внутри базы данных или во внешних файлах. На сегодняшний день DB2 обеспечивает доступ к данным, хранимым вне сервера; в будущих выпусках (к концу 1997 г.) будет гарантироваться и целостность на основе механизма сильных связей с файлами.

  • Расширяемая языковая поддержка - UDF могут быть написаны на языках Си, Си++, Visual Basic или Java; хранимые процедуры могут писаться на языках третьего и четвертого поколения и Java.Ожидается появление языковых расширений в стиле SQL-3 для обеих целей.

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

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


    InfoModeler


    Средство моделирования InfoModeler 3.1 было первым,
    поддерживающим ОРСУБД на основе связей с продуктами компании
    Informix. В этой версии также обеспечивается возможность
    генерации схем для DB2 Universal Database. Отличительной
    особенностью системы является поддержка концептуального
    моделирования в стиле FORML. Кроме того, поддерживаются
    логические реляционные модели ER и IDEF1X.
    Серьезный недостаток InfoModeler состоит в наличии очень
    небольшого числа встроенных типов. Чтобы получить доступ к
    полному набору объектно-реляционных типов и функций,
    обеспечиваемых непосредственно ОРСУБД или расширителями
    (Cartridge, DataBlade, Extender), необходимо иметь подключение к
    "живой" базе данных, что ограничивает возможность автономной
    работы. Подключение к базе данных требуется и для проведения
    прямой и обратной инженерии, т.е. невозможно обойтись только
    DDL-скриптами.
    InfoModeler пока не обеспечивает возможность моделирования
    серверных функций, а именно они вместе с определяемыми
    пользователями типами составляют суть объектно-реляционного
    подхода. Система позволяет увидеть функции, которые уже
    определены в базе данных, но только при наличии подключения к
    ней. Ситуация похожа на "Уловку-22": можно работать только с уже
    существующими функциями, они не могут существовать, пока их не
    создали, а создать их InfoModeler не позволяет. Компания обещает
    устранить этот недостаток к будущих выпусках.


    Informix


    Компания Informix Software оказалась на переднем фронте объектно-реляционных систем после приобретения компании Illustra в начале 1996 г. Решение компании произвести слияние продуктов Informix-OnLine 7.2 и Illustra Server к концу того же года оценивалось в индустрии довольно скептически. Однако компания смогла выполнить свое обещание, выпустив в конце декабря устойчивую версию Informix-Universal Server (IUS) для трех платформ. В настоящее время IUS доступен на 10 платформах.
    Компания сконцентрировалась прежде всего на компоненте универсального сервера общей архитектуры. Пока не слишком большое внимание обращается на другие звенья архитектуры, кроме области Internet/Web (с применением продукта WebConnect). В большей степени затрагиваются вопросы поддержки сложных данных в средствах разработки и приложениях с использованием недавно объявленного продукта Data Director (приобретенного вместе с компанией CenterView Software в начале этого года). Этот продукт обеспечивает возможность использования передовых сред разработки (Java, PowerBuilder, VisualBasic и др.), доступ к расширениям в духе SQL-3 и, кроме того, доступ к новым типам данных и функций IUS.
    В своем первом выпуске IUS объединяет OnLine 7.2 с DataBlade API сервера Illustra и языковыми расширениями, основанными на идеях SQL-3, для поддержки широкого набора объектных средств. Расширения включают следующее:
  • Расширяемая система типов для интеграции определяемых пользователями типов данных (UDT - User Defined Types) - уточненных типов, абстрактных типов данных (ADT - Abstract Data Types), строчных типов и типов коллекций, включая возможность неограниченной вложенности таблиц. IUS поддерживает простое наследование в иерархии именованных строчных типов. Каждая таблица, основанная на строчном типе, становится типизированной таблицей и может использоваться в этой иерархии. В будущем ожидается появление ссылочных типов и ADT в духе SQL-3, а также средств репликации данных определяемых пользователями типов.
  • Определяемые пользователями функции (UDF - User Defined Functions) - полный диапазон типов UDF с поддержкой перегрузки, распознавания нужного тела функции на основе типов параметров и параллельного выполнения функций, когда это оправданно. (Параллельные возможности IUS применимы на платформах SMP; при использовании Informix-OnLine XPS эти возможности распространяются на кластерные архитектуры; на платформах MPP объектные расширения пока недоступны.)

  • Расширяемая система индексирования - R-деревья, применение B-деревьев к UDT, определяемые пользователями индексные структуры.

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

  • Большие объекты (LOB - Large Objects) и внешние данные - LOB'ы могут храниться внутри базы данных (в BLOB'ах) или во внешних файлах. IUS не гарантирует целостность данных, хранимых во внешних файлах, но имеет на этот счет планы. Интерфейс виртуальной таблицы позволяет регистрировать внешние данные в каталогах базы данных и обращаться к ним таким же образом как если бы они были таблицами IUS.

  • Предопределенные расширения - Informix подрядил много сторонних поставщиков для написания DataBlades - упакованных наборов расширений, представляющих некоторую прикладную область (текстовый поиск, управление графической информацией, финансовый анализ и т.д.). DataBlade интегрируется с ядром IUS на основе специального интерфейса уровня вызовов (DataBlade API). К июню 1997 г. планировалось иметь в поставке 20 DataBlade, еще 10

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

  • Расширения языков приложений - в дополнение к поддержке разработки UDT на основе собственной среды NewEra Informix теперь обеспечивает новое средство разработки клиентских приложений Data Director, которое дает возможность связи между данными, контролируемыми приложением, и данными, хранимыми в среде IUS.


    В этом средстве используются собственные интерфейсы с IUS (Java API и Си++ API), а не ODBC 4. Кроме того, Data Director поддерживает

    4языковые расширения в духе SQL-3.

    4В своем стремлении первой обеспечить доступность 4объектно-реляционных средств компания Informix 0не лучшим образом балансирует между новой технологий и сохранением той позиции на бизнес-рынке, которую удалось занять на основе Informix-OnLine 7.x. До слияния с Illustra основное внимание уделялось производительности и масштабируемости на основе разных видов параллелизма. С появлением IUS эти важные качества продуктов отошли на второй план. Кроме того, компания должна принимать во внимание наличие трех разных серверов баз данных - IUS, OnLine и XPS.

    Однако компании удалось продемонстрировать возможность эволюционного перехода к объектно-реляционной технологии с сохранением надежного и высокоэффективного управления базами данных. IUS является развитием OnLine, и именно так следует представлять его на рынке. Можно ожидать, что IUS будет использоваться не только как универсальный сервер, а превратится в полную расширяемую платформу управления данными.


    Инструментальные средства


    Оба продукта содержат базовый набор средств администрирования,
    позволяющих вводить команды СУБД и операционной системы;
    управлять сценариями; обрабатывать предупреждающие и аварийные
    сообщения; просматривать объекты. Пакет UDB v.5 содержит монитор
    событий (Event Monitor), монитор производительности (Performance
    Monitor), средства конфигурирования клиентской и серверной частей
    системы (Configuration Assistants), средство управления ресурсами
    (Resource Governor) и управляющий центр администрирования баз
    данных. Oracle имеет аналогичные инструменты: Oracle Expert,
    часть Oracle Enterprise Manager, производящий мониторинг событий,
    и Oracle Performance Pack - эквивалент Performance Monitor в DB2;
    однако эти средства не поставляются вместе с Oracle8. Раньше IBM
    критиковали за недостаточную развитость средств
    администрирования, но теперь они настолько улучшены и настолько
    хорошо интегрированы с UDB v.5, что практически сравнялись по
    возможностям со средствами Oracle.
    Что касается средств разработки приложений, то Oracle
    обеспечивает развитый набор таких средств, аналога которому IBM
    пока не имеет. Средства Oracle включают Developer/2000,
    Designer/2000 и Power Objects. Для разработки приложений IBM
    предлагает VisualAge для Java и для Basic, а также Си/Си++.
    VisualAge для Basic не интегрирован с DB2.


    Интеллектуальное разделение данных


    Пользователи нуждаются в средствах, упрощающих управление
    всерхбольшими базами данных. Разделение таблиц и индексов
    необходимо в среде больших баз данных, поскольку позволяет
    управлять данными на более мелком уровне и обеспечивает основу
    распараллеливания. UDB v.5 и Oracle8 обладают интеллектуальными
    возможностями разделения данных. В Oracle не допускается
    использование в разделенных таблицах столбцов с типами данных
    LONG, LONG RAW и Large Object (LOB). Кроме того, в Oracle не
    поддерживаются побитные (bitmap) индексы на разделенных таблицах,
    так что пользователи должны выбирать либо разделенное хранение
    таблиц, либо побитную индексацию. В DB2 разделение было возможно
    и в более ранних версиях, и упомянутые ограничения не
    устанавливаются.


    Исследовательская среда Microsoft


    Исследовательской группе баз данных Microsoft приносят пользу особенности нашей среды Microsoft, которые способствуют повышению эффективности исследований. Это относится к Microsoft Research в целом, а не только к исследованиям в области баз данных.

    Окружение исследований    : Люди из Microsoft Research и, в особенности, Рик Рашид полагают, что одной из существенных мер качества нашей исследовательской работы является публикация наших результатов на основных конференциях и журналах в этой области. Это стимулирует нас соизмерять свой успех с результатами лучших исследователей в каждой области. Другой важной мерой наших исследований является передача технологии производственным группам, что заставляет нас сосредотачивать внимание на индустриально значимых проблемных областях. Таким образом, профессиональное влияние и соответствие производственным потребностям обеспечивают высококвалифицированные индустриальные исследования.

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

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

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


    Исследовательские проекты


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

    Самонастраивающиеся базы данных    : Долговременной целью проекта AutoAdmin является превращение систем баз данных в самоадминистрирующиеся и самонастраивающиеся в полном объеме. Исходно в фокусе проекта находилась проблема физического проектирования баз данных (выбор индексов и материализованных представлений). В проекте AutoAdmin участвуют Сураджит Чаундхари, Пол Ларсон и Вивек Нарасайа.

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


    Как задать запрос вне звезды


    Предположим, что у нас имеется многомерная модель для заказанных товаров (Ordered Items) - одна для поставленных товаров (Shipped Items) и одна для полученных товаров (Received Items). Я могу пройти свою иерархию измерений, чтобы получить любой уровень Item, Store и Date. Просто, не правда ли?
    Я могу узнать, сколько телевизоров получу в течение следующих нескольких дней. Хотя для этого требуется группирование, я встраиваю информацию о своей категории и своем отделе в таблицу фактов и могу спуститься по иерархии выбрать подмножество строк -- и достаточно быстро получить ответ. Не нужны соединения, строки, вероятно, уже сгруппированы и требуется минимальная агрегация. (Но если имеется нечто, что я должен знать на обобщенном уровне, мне, видимо, придется построить для этого таблицу.) Вероятно, более 80% запросов будут выглядеть подобным образом.
    Но что делать, если я отвечаю за разгрузку товаров, а мой лучший рабочий будет отсутствовать на службе в следующие два дня? Мне может понадобиться узнать, какие из ожидаемых поставок слишком велики или слишком тяжелы, чтобы с ними можно было справиться усилиями оставшейся части бригады. Что из отправленного не будет получено (NOT IN в числе полученного) и что заказано, но еще не поставлено (возможно, UNION) c весом больше 80 фунтов, объемом в шесть кубических футов, длиной в шесть футов к каком-либо измерении или суммарной длиной каких-то двух измерений в семь футов? Вот так так!
    У меня нет ничего из этой информации, включенного в звезду. Все это имеется в таблице Item -- и я могу выполнить с ней соединение. Но для этого я должен выйти за пределы звезды и не могу использовать свои обычные средства OLAP. Более того, мне придется рассматривать три разные звезды.
    Средства подобные BI/Query компании Hummingbird позволяют взглянуть на модель (и, следовательно, на проблему) с реляционной точки зрения. Вы можете легко встроить в таблицу Item необходимые ограничения, соединить ее с Ships, исключить Received и добавить Orders c датой отправки в течение следующих двух дней.
    Вы решаете свою незамедлительную проблему без потребности построения и внедрения новой схемы.


    Комбинирование архитектур


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


    Комментарий С.Кузнецова


    Я полностью согласен с мнением господина Джонсона относительно
    ряда некорректностей в схеме, предложенной господином Дейтом.
    Однако я не могу согласиться с тем, что использование
    неопределенных значений и многозначной логики во всех случаях
    повышает выразительность языка и позволяет более естественно и
    просто пользоваться всей содержащейся в базе данных информацией,
    чем если ограничиться использованием выделенного значения
    "значение неизвестно" и двузначной логики.
    Все дело в том, что (по крайней мере в языке SQL) логическое
    значение unknown является запрещающим, т.е. если для некоторой
    строки таблицы условие выборки вычисляется в unknown, то строка
    не входит в результирующую таблицу запроса. По этому поводу
    трехзначная логика действительно помогает более сжато
    формулировать условия ограничения, но никак не содействует
    извлечению из базы данных возможной информации.
    Если обратиться к первому примеру Джонсона, то предположим, что
    нас интересуют цели, для которых хотя бы одно из прицельных
    устройств смогло выдать координаты (конечно, если координаты
    выдали оба прицельных устройства, то эти координаты должны
    совпадать). Условие выборки для этого запроса будет иметь
    следующий совсем непростой вид:
    (coordinate1 = coordinate2) OR ((coordinate1 IS NOT NULL) AND
    (coordinate2 IS NULL)) OR ((coordinate1 IS NULL) AND (coordinate2 IS NOT NULL))
    Попробуйте написать это по-другому! Здесь в чистом виде работает
    двузначная логика и специальное значение NULL. Трехзначная логика
    не помогает.
    Аналогично обстоят дела в более простом случае второго примера:
    "Сколько раз Джонс и Смит смогли бы сыграть вничью?". Понятно,
    что хотелось бы написать условие в виде:
    ((column1 = column2) = true) OR ((column1 = column2) = unknown)
    Но в языке SQL в таком виде условия задавать нельзя (да если бы и
    было можно, то так ли это просто и естественно?). Поэтому
    придется переформулировать условие следующим образом:
    (column1 = column2) OR (column1 IS NULL) OR (column2 IS NULL)
    Это ровно то же самое, что потребовалось бы написать при
    использовании схемы Дейта для получения корректного ответа. Опять
    работает двузначная логика и специальное значение NULL.
    Ну и где же здесь повышение выразительной мощности и упрощение
    формулировки запросов?


    Концепции и реализации


    РСУБД заменили предшествовавшие им иерархические и сетевые системы баз данных по причине своей гибкости и наличия интерфейсов, изолирующих код приложения от схем физического хранения. Объектно-реляционные системы основываются на знакомых реляционных таблицах, принципом проектирования является нормализация, методология основана на применении диаграмм "сущность-связь", используется язык SQL и интерфейсы ODBC и JDBC. Стремление выйти за рамки реляционных систем выражается в возможности определения пользовательских типов и функций, что позволяет полее естественно моделировать бизнес-объекты и инкапсулировать бизнес правила совместно с соответствующими данными. Набор расширенных базовых типов включает большие объекты, строчные типы и вложенные таблицы, типы коллекций и ссылочные указатели. Реализуются средства, совместимые со стандартом ANSI SQL-92 и грядущим стандартом SQL-3. Ключевые понятия объектно-реляционного подхода описаны в различных источниках, начиная с книги Майкла Стоунбрейкера (Michael Stonebraker, Object-Relational DBMSs: The Next Great Wave, Morgan Kaufmann, 1996).
    Конечно, имеются альтернативные подходы к модернизации РСУБД. К одному из них относятся объектные СУБД (ОСУБД), хотя многие относятся к ним, как к элегантным средствам хранения данных, которые никогда не заменят РСУБД и ОРСУБД. Кроме того, средства распределенных объектных вычислений, основанные на серверах приложений и транзакций и поддерживающие собственные модели данных, могут снизить роль сервисов баз данных.
    Какая из этих технологий приблизит нас к объектно-реляционным представлениям: ОРСУБД, ОСУБД или распределенные объекты? Ответ основывается на четырех ключевых аспектах принятия на рынке технологии баз данных: реализация, эффективность, инструментальные средства, приложения. Для начала рассмотрим текущие реализации объектно-реляционного компонента этого уравнения.
    . Предложенная компанией сетевая вычислительная архитектура (Network Computing Architecture - NCA) производит неотразимое впечатление: распределенные объектные вычисления на основе объектных расширений CORBA на стороне клиента, сервер приложений, составляющий среднее звено и сервер баз данных.
    Имеет ли значение то, что к настоящему времени полностью реализовано только звено сервера приложений, что были допущены ошибки, такие как продукт Sedona, никогда не являвшийся образцом средств разработки приложений, или то, что предлагаемое решение дороже сетевого PC? Нет, поскольку контролирование около половины рынка РСУБД обеспечивает компании такой же простор, как если бы она владела 90 процентами рынка настольных операционных систем.

    Подход Oracle к разработке "универсального сервера" в форме Oracle 7.3 состоял в том, чтобы объединить несколько разных серверов данных под одним названием. В Oracle8 эти различные серверы были преобразованы в картриджи ("картридж" - это термин, введенный компанией для обозначения модуля объектных расширений, подключаемого к данным NCA или звену приложений). В настоящее время Oracle предлагает пять картриджей данных: ConText, Image/VIR, Spatial, Time Series и Video. Что касается общей поддержки объектов, то Oracle следует тактике Microsoft: объявить, поставить ровно столько, сколько достаточно и надеяться, что никто не заметит, что королю несколько маловато новое платье; после всего этого запланировать поставку всего, что было обещано, но только после того, как этого потребует рынок.

    Как отмечают в своей книге Дэвид Энсор и Ян Стивенсон (David Ensor and Ian Stevenson, Oracle8 Design Tips, O'Reilly, 1997), они не могли бы прямо сейчас рекомендовать использовать объектную поддержку Oracle8 в каких-либо реальных корпоративных приложениях. Эта поддержка не является полной; синтаксис сложен; могут применяться очень немногие распространенные инструментальные средства.

    Кроме того, в Oracle8 объектно-реляционная модель реализована не полностью. Инкапсуляция возможна только при использовании для программирования методов языка PL/SQL. Вложенность таблиц ограничена одним уровнем, не поддерживается наследование. Функции могут быть перегруженными, но нет динамического полиморфизма. Вызов внешних процедур, которые могут быть написаны исключительно на языке Си, допускается из PL/SQL, но не из SQL.


    И конечно, вызовы внешних процедур намного более накладны, чем вызовы процедур, прикомпонованных к серверу, но Oracle не обеспечивает второй возможности по соображениям безопасности. Усовершенствования, включающие Java VM (Virtual Machine), ожидаются в версии 8.1, выпуск которой обещан в конце 1998 г.

    . История Маленького Принца Антуана де Сент-Экзюпери начинается с того, как удав проглотил слона. Подобно этому, компания Informix оттеснила Sybase с позиции основного конкурента Oracle, проглотив пионерскую ОРСУБД Illustra Майкла Стоунбрейкера. Казалось, что этот брак совершен на небесах: объединение новаторской архитектуры объектных расширений с самым быстрым и наиболее масштабируемым традиционным реляционным ядром.

    Оптимизатор системы Illustra умеет работать с определенными пользователями типами и функциями, пространственными индексами в виде R-деревьев и обычными реляционными данными. В системе поддерживаются модули объектных расширений DataBlades, обеспечивающие управление полнотекстовыми, геопространственными, мутьтимедийными и другими данными. Основной продукт компании Online Dynamic Server (называемый теперь Informix-Dynamic Server 7.x) обладает наилучшими среди подобных систем возможностями распараллеливания на симметричных мультипроцессорах.

    Технология Informix-Dynamic Server в настоящее время является лучшей объектно-реляционной технологией, хотя в текущем выпуске 9.13 отсутствуют такие важные возможности как репликация, множественное наследование, объектные расширения с использованием Java и надежная поддержка типов коллекций. Кроме того, трудно заставить работать портированный оптимизатор Illustra так же хорошо, как он работал в исходной системе. Эти проблемы должны быть устранены в выпуске 9.2, ожидаемом летом 1998 г. Ожидается также появление новых интересных интерфейсов запросов и сервисов, обеспечивающих транзакционное управление внешними данными.

    . IBM является единственной компанией, технология и ресурсы которой могут позволить бросить вызов доминирующей позиции Oracle на рынке серверов баз данных.Применение новой технологии, перенос системы на платформы Windows NT и UNIX-платформы других производителей и агрессивная маркетинговая политика относительно DB2 Universal Database V.5 позволяют IBM занять представительную позицию на рынке открытых СУБД.

    DB2 Universal Database имеет репутацию надежной реализации ОРСУБД, которая в состоянии конкурировать с реализацией Informix. Единственно, что вызывает недовольство разработчиков,- это отсутствие возможности вызова SQL-операторов из определенных пользователями функций.


    Консультационная деятельность


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

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

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

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


    Краткий взгляд назад


    По поводу современного использования баз данных интересно заметить, что в начале этого десятилетия, как раз перед спадом активности бизнеса в Соединенных Штатах в 1990-м году, производители средств управления базами данных пытались выбросить на рынок результаты своих исследований и передовых разработок 80-х годов на мировой рынок. Предполагалось, что развитые средства управления информацией - распределенные базы данных, базы данных с "искусственным интеллектом" и первые гибридные объектно-реляционные базы данных - станут основой приложений во время приближения следующего тысячелетия.
    Однако, как это часто бывает, рынок внес свои коррективы в эти лучшем образом задуманные планы. Во-первых, совершилась революция "клиент-сервер", заставившая производителей и пользователей вступить в борьбу за обеспечение кросс-платформенного доступа к базам данных и выживание в реальном мире приложений. Пренебрегаемый многими вначале подход ODBC стал тем средством, которое обеспечило доступ к базам данным в среде "клиент-сервер", и значительная часть разработок компаний-производителей стала расходоваться на переделку централизованных СУБД для работы в распределенных, многоплатформенных средах.
    Феноменальный рост Internet от той точки, в которой можно было производить рекламные эксперименты с Web-страницами, до появления технологической среды разработки приложений следующего поколения снова вызвали борьбу в сообществе производителей. Усилия сосредоточились на новых поколениях корпоративных архитектур, поддерживающих взаимодействия между Web-серверами и серверами баз данных, равно как связью Java с базами данных.
    Существенные усилия были потрачены на превращение в продукты экспериментальных параллельных архитектур баз данных; на приспособление оптимизаторов запросов к обработке сложных запросов с многочисленными соединениями, распространенных для сред складов данных; на обеспечение интерфейсов между частными структурами данных, присущих, например, многомерным базам данных, и структурами, поддерживаемыми основными серверами баз данных.
    Оглядываясь назад, испытываешь ощущение, что совместные усилия сообществ деятелей рынка и разработчиков приложений, все еще ограниченные возможностям реляционной технологии, побудили мир бизнеса сделать нечто большее, чем первые шаги в направлении следующего поколения технологии баз данных.


    Логика, производительность и другие вопросы


    В конце этого обзора статьи Кодда 1970-го года я хочу рассмотреть несколько разнородных вопросов, которые не затрагивались в предыдущих разделах.
    Относительно использования логики предикатов и кванторов (EXISTS и FORALL) этой логики и языке доступа к данным Кодд говорит: "Поскольку каждое отношние в практическом банке данных является в каждый момент времени конечным множеством, кванторы существования и всеобщности могут быть выражены в терминах функции, которая пересчитывает элемента в любом конечном множестве". Как кажется, это замечание говорит о том, что на самом деле мы имеем дело с логикой высказываний, а не с полной логикой предикатов.
    Статья также включает следующее замечание по поводу производительности: "Система данных должна обеспечивать средства трансляции запросов пользователей... в ... эффективные ... действия над текущим хранимым представлением. Для языка данных высокого уровня это представляет сложную техническую проблему. Тем не менее, эта проблема должна быть решена. По мере возрастания числа пользователей, имеющих конкурентный доступ к большому банку данных ответственность за эффективное обеспечение ответов и за расход ресурсов переносится с ... пользователя на систему данных". Пророческие слова! Кодд отмечает необходимость в компоненте оптимизации СУБД и молчаливо полагает, что в этой области могут существовать некоторые интересные исследовательские вопросы.
    Кодд обсуждает также ловушку связи (connection trap). "Отсутствие понимания [семантики реляционных операций] привело нескольких разработчиков систем к тому, что можно назвать ловушкой связи . [Например, предположим, что у нас имеется нереляционная система, в которой] каждое описание каждого поставщика связывается указателями с описаниями каждой детали, поставляемой этим поставщиком, и описание каждой детали аналогичным образом связывается с описанием каждого проекта, в котором используется эта деталь. Из этого можно сделать заключение, которое, вообще говоря, является ошибочным: если все возможные детали поставляются данным поставщиком через [соответствующие] детали ...
    для проектов, в которых используются эти детали, то можно получить законный набор всех проектов, обеспечиваемых деталями от данного поставщика. Такое заключение корректно только в очень специальном случае, когда целевое отношение между проектами и проставщиками по-существу является естественной композицией двух других отношений."

    Чтобы попасть в ловушку связи, нам не обязательно иметь указатели; к сожалению, можно создать такую же логическую ошибку и в чисто реляционной системе. И в самом деле, многие авторы критикуют реляционные системы в точности за эту возможность. (См. [5].) Я полагаю, что подобная критика неосновательна, поскольку выдает печальное отсутствие понимания реляционной модели.

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

    Наконец, еще одно замечание из области истории.Недавно мне встретилась статья, датированная 1966 г. (!), с заголовком "A Relational Model for Information Retrieval and the Processing of Linguistic Data" [6]. Статья посвящена проблемам обработки естественных языков, а "реляционная модель" в заголовке - это формализм для представления некоторых английских фраз. Например, фраза "Джон любит Мери" можно было представить выражением "j L m". (Все отношения в статье - бинарные.) Эти идеи имеют точки соприкосновения с реляционной моделью Кодда. (Что естественно, поскольку они базируются на том же логическом основании.) Однако я думаю, что было справедливо сказать, что мы должны отдать должное Кодду за открытие реляционной модели данных в том смысле, как мы теперь ее понимаем.


    Лучшее из двух миров


    Если реализовать многомерную модель с использованием представлений (и индексов и сводных таблиц) поверх модели 3NF, то вы сможете получить быстроту выполнения и удобство "подготовленных" запросов и много средств, изолирующих пользователей от базовых таблиц и нудной работы (и ошибок) на SQL. Кроме того, вы сможете получить гибкость в расширении модели почти в любом направлении для включения преобретенных или других новых данных. При использовании модели 3NF физическая модель является логической моделью; преобразования очень просты и прямолинейны. Вы можете создать представления, позволяющие инструментальным средствам демонстрировать пользователю многомерную модель, облегчая понимаемость и упрощая использование. Наконец, вы можете обеспечить прямой доступ к нормализованной модели с помощью таких реляционных средств как BI/Query компании Hummingbird Communication Ltd. (www.hummingbird.com), или умудренные пользователи и профессионалы IT могут написать собственный SQL-код.
    Имеются все основания использовать преимущества других подходов к моделированию, если они представляют какую-то ценность. Например, псевдоключи (идея, заимствованная из многомерного моделирования) при корректном использовании упрощают пользовательский доступ, повышают эффективность выполнения запросов и снижают уровень требований к общей нагрузке системы.
    В Teradata используется этот гибрид физической модели 3NF и многомерных представлений, поскольку система очень хорошо обрабатывает соединения и обладает зрелым и надежным оптимизатором. Представления в Teradata не материализуются до выполнения соответствующих запросов, что делает возможным отражать в плане запроса с соединением потребности каждого индивидуального запроса, минимизировать объем данных, которые требуется перераспределять или дублицировать. Хэширование на первичном индексе упрощает разделение, и распределение памяти происходит только на уровне базы данных, а не на основе принципа таблица-раздел и индекс-раздел. В оптимизаторе Teradata используется пересечение индексов, что обеспечивает эффективность почти такого же уровня, который дают битовые индексы, без потребности в накладных расходах для их поддержки.
    Это означает, что Teradata нуждается в создании меньшего числа индексов, что приводит к дальнейшему сокращению требуемых объемов памяти и времени для поддержки индексов. Наличие возможности синхронного сканирования (sync scan) позволяет использовать время, требуемое для сканирования больших таблиц, для выполнения нескольких (и даже сотен и тысяч) параллельно выполняемых запросов, делающих одну и ту же работу, что повышает пропускную способность системы на несколько порядков. Это всего лишь несколько причин (к ним следует добавить параллелизм системы), благодаря которым Teradata минимизирует зависимость от сводных таблиц.

    Однако реальное преимущество Teradata происходит от фактического устранения избыточных многомерных моделей и вероятного уменьшения чрезмерных требований к аппаратуре, поддерживающей многочисленные лавки данных (data marts). Вследствие простого размещения данных на основе хэширования Teradata делает возможной реализацию практически всех комбинаций подходов 3NF и звезднообразных схем. Если для поддержки бизнеса требуются расширение возможностей и ренормализация, можно переключиться со звезднообразной схемы на 3NF.

    Оптимизация соединений малой и большой таблиц. Когда в 1988 г. Teradata впервые начала обслуживать сверхбольшие базы данных, обнаружились некоторые странные проблемы. Даже при использовании подхода с отказом от общих ресурсов (shared-nothing) для обработки и сканирования больших таблиц требуется большое время. В результате инженеры (включая меня) разработали методы, заставляющие оптимизатор сначала обрабатывать малые таблицы измерений, соединяя из с целью создания первичного индекса для большой таблицы фактов и сокращая тем самым время ответа для многих запросов. Эти методы были включены в оптимизатор Teradata выпуска 1990 г. Как показывает рис. 1, у большой таблицы (Sales) имеется составной первичный индекс, составленный из внешних ключей таблиц измерений Stores, Items и Weeks. В звезднообразной схеме все четыре таблицы логически (а иногда и физически) объединяются.


    На рисунке представлена физическая модель 3NF, и запрос, представленный на листинге 1, позволяет произвести выборку из Stores, Items и Weeks с пересечением с указанными данными из Sales. В частности, здесь мы хотим узнать общий объем продаж всех телевизоров в некоторой группе штатов (скажем Colorado и Minnesota) в течение двух недель перед Super Bowl, и мы хотим видеть это в соответствии с размером экрана телевизора и в лексикографическом порядке названий магазинов. Указанное представление эмулирует звезнообразную схему, в запросе не принимается во внимание базовая физическая модель, и запрос очень прост. (Особенности модели скрываются представлением.)

    SELECT store, SUM(sales$), SUM(salesQty), Substr(itemdesc, 1, 3) Named screensize, itemdesc FROM SalesStar WHERE weeknbr BETWEEN 9805 AND 9806 AND state IN ('CO', 'MN') AND subdept = 'Television' ORDER BY Sales$ Desc, store GROUP BY screensize;

    View: CREATE VIEW SalesStar AS SELECT (*) FROM SALES B, STORES S, ITEMS I, WEEKS W WHERE B.STORE_NBR = S.STORE_NBR AND B.ITEM_NBR = I..ITEM_NBR AND B.WEEK = W.WEEK;

    Листинг 1. Запрос к таблице Sales



    Рис. 1. Таблица Sales со звезднообразной схемой и составным первичным индексом

    Оптимизатор Teradata знает, что таблица Weeks содержит меньше всего строк, поэтому он выбирает только те недели, которые нас интересуют. Затем он копирует эти две строки в каждое виртуальное AMP (параллельное устройство Teradate), помещая их в кэш. Поскольку оптимизатор знает, что таблица Stores не содержит много строк, и имеется индекс на столбце state, он выбирает около 30 строк для указанных штатов, соединяет их с двумя строками уже в основной памяти и копирует результат в каждое AMP. Оптимизатор не знает, что нам требуется только немногая часть товаров из таблицы Item, содержащей два миллиона строк, пока не пройдет по индексу на столбце subdepartment и не выберет телевизоры.

    Теперь оптимизатор получает, скажем, 2433032 строк. Он перераспределяет эти строки с помощью хэширования (таким же образом, что и таблицу Sales) в соответствующие AMP, по ходу дела сортируя строки.



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

  • Каждое AMP производит выборку из таблицы Weeks по условию . Промежуточный результат (Spool) дублируется на всех AMP.
  • Все AMP производят выборку из таблицы Stores по условию . Выполняется соединение со Spool по фиктивному условию (). Spool дублируется на всех AMP.
  • Все AMP производят выборку из таблицы Items по условию . Выполняется соединение со Spool по фиктивному условию. Результат перераспределяется между всеми AMP и сортируется.
  • На всех AMP выполняется соединение Sales и Spool с использованием MERGE JOIN (сканирование строк с сопоставлением хэш-кодов).

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

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

    Новый индекс соединения. Индекс соединения, появившийся в Teradata V2R2.1, может комбинировать таблицы детальных данных (фактов) и связанные таблицы в одной индексной структуре, избавляя от потребности соединять таблицы во время выполнения. Можно рассматривать индекс соединения как комбинацию таблицы фактов и некоторого числа таблиц измерений, если внести в этот индекс достаточно выразительные данные. Teradata автоматически распространяет изменения в базовых таблицах в индекс соединения, так что дополнительные расходы на поддержку минимальны.


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

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

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


    March of the Data Marts


    Peter L. Brooks, management consultant with the Advanced
    Technology Group of Coopers & Lybrand Consulting

    E-mail:
    Организациям, которые ориентируются на корпоративные склады
    данных (datawarehouse), оказывается трудно строить и использовать
    их. Для реализации склада данных требуется большой штат
    сотрудников, мощная компьютерная аппаратура, сложное программное
    обеспечение, время и деньги. Пользователям трудно понять
    содержимое склада данных и ориентироваться в нем. По этим
    причинам вместо или в дополнение к складам данных организуются
    рынки данных (data mart).
    По мере расширения области применения рынков данных возрастает
    уровень требований. Для организации рынка данных недостаточно
    использовать небольшие базы данных с облегченным для конечных
    пользователей доступом. Современные рынки данных должны быть в
    состоянии хранить сотни гигабайт данных и обеспечивать сложные
    разновидности аналитической обработки, например, из области
    добычи данных (data mining). Должен быть обеспечен удаленный
    доступ к рынку данных для сотен пользователей - возможность,
    которую дешево обеспечивает технология Internet и Intranet.
    Наконец, организация должна быть в состоянии централизовано
    администрировать и управлять многими рынками данных, которые
    могут содержать несогласованные и конфликтующие данные.
    Хотя теперь трудно различать рынки и склады данных, исходя
    только из их размеров, некоторые различия остаются важными:
  • Рынок данных ориентирован только на одну предметную область или
    только на одну группу пользователей.
  • Организация может иметь один корпоративный склад данных, но
    много рынков данных.
  • В отличие от корпоративных складов данных, рынки данных не
    содержат оперативной информации.
  • Поскольку рынки данных содержат меньше информации, чем склад
    данных, они более понятны и более просто доступны пользователям.
    Компании-производители разрабатывают концепцию виртуального рынка
    данных, удовлетворяющего потребности в доступе к нескольким
    рынкам данных без необходимости репликации данных между рынками.

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

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

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

    данных, были новинкой и на рынок складов данных вышло

    бесчисленное количество производителей. В прошлом году компании

    Information Builders Inc. (IBI) и SAS Institute Inc. объявили

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

    данных,- Focus Fusion и SAS MDDB соответственно.

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

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

  • По мере роста рынка данных ухудшается эффективность доступа.

    Пользователи ожидают более короткого времени ответа при обращении

    к рынку данных, чем в случае склада данных.

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

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

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

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

    лучшее решение.

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

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

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

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

  • Если склад данных строится в течение нескольких лет, то для

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

    умеренными расходами. Для упрощения и сокращения срока (не более

    90 дней)разработки рынка данных разрабатываются средства типа

    "рынок данных в одной упаковке", включающие все необходимые

    компоненты.

    Решения рынков данных требуют применения двух- или трехуровневой

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

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

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

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

    организации виртуальных рынков данных компания Information

    Advantage Inc.


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

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

    любого рынка данных.

    Для достижения эффективности рынка данных необходимо

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

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

    продукте Red Brick Warehouse 5.0 компании Red Brick Systems Inc.

    достигнуто существенное увеличение производительности за счет

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

    Средство, называемое Continually Adaptive Indexing (TARGETindex),

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

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

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

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

    таблиц, а также таблиц существенно разного размера. SQL-запросы

    могут встраиваться в раздел FROM другого запроса. Начальные

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

    до формирования полного результата.

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

    Essbase компании Arbor Siftware Corp., поддерживают

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

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

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

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

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

    представляет собой долговременный процесс.

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

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

    продукте Pilot Decision Support Suite компании Pilot Software

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

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

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

    заранее. Имеется пример сокращения размера MDDB от 4 Гб до 200 Мб

    за счет использования этого подхода.



    Решение компании CrossZ Software под названием QueryObject,

    которое может равно относиться к области MDDB или области

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

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

    10000 к одному с сохранением 100% точности.

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

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

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

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

    эффективность процедуры загрузки данных и объем рынка данных.

    Без централизованного управления данные разных отделов корпорации

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

    информацией из разных рынков данных, и рынки данных слишком

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

    данных. Продукт DSS Administrator компании MicroStrategy Inc.

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

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

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

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

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

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

    в группы в соответствие с соображениями безопасности.

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

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

    ресурсов в любой момент времени. Поскольку метрические данные

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

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

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

    возможность оптимальной настройки. Продукт компании IBM Site

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

    исходящие от пользователя или ресурса, что позволяет установить

    оптимальную среду запросов. В частности, возможно принятие или

    непринятие конкретного запроса в зависимости от оценок



    администратора.

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

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

    Разработка концепции "рынка данных в одной упаковке" ("data mart

    in a box") призвана для минимизации уровня этих проблем, включая

    вопросы аппаратной организации, программного обеспечения и

    профессионального обслуживания

    Продукт компании IBM SmartMart дает возможность использования

    программного обеспечения промежуточного уровня (middleware) для

    извлечения данных из более чем 60 реляционных или

    файл-ориентированных источников в рынки данных, основанные на

    использовании Fusion MDDB компании IBM или одной из основных

    реляционных баз данных. Имеется также продукт WebFocus,

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

    Internet. В "упаковку" входят средства администрирования и

    хранения метаданных.

    Продукт Visual Warehouse компании IBM работает в средах OS/2 или

    Windows NT. Версия NT включает сервер Visual Warehouse, драйверы

    ODBC, связующее средство DDCS, средство поддержания репозитория

    метаданных DataGuide и средство Lotus Approach для проведения

    анализа конечными пользователями. Возможно использование всех

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

    источников данных.

    Пакет PowerMart 3.5 компании Informatica Corp. содержит следующие

    средства: Informica PowerMart Designer, Repository, Server

    Manager, PowerMart Server и компоненты семейства Change/Capture.

    Поддерживаются все популярные реляционные базы данных. В средстве

    Star Schema Design Wizard (ой, как хочется сказать, "кудесник

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

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

    Программа RightStar компании NCR Corp. разработана для того,

    чтобы обеспечить разработку рынка данных в течение 90 дней при

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

    данных. Продукт включает сервер WorldMark 5100S, операционную



    систему NCR Unix MP-RAS, средства управления базами данных

    (Teradata, Oracle или Informix), средства доступа к данным или их

    преобразования и профессиональные службы. Анонсировано

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

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

    Server.

    Internet/Intranet технологии обещают предоставить дешевый доступ

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

    MicroStrategy и Information Advantage обещают средства семейства

    ROLAP (Relational On-Line Analisis Processing) на основе

    Web-продуктов (то же самое относится к компаниям Arbor Software и

    Pilot Software). Основанный на Windows NT продукт Essbase Web

    Gateway поддерживает функциональные свойства OLAP для

    пользователей Essbase. Пакет Pilot Internet Publisher

    обеспечивает пользователей Pilot Decision Support доступом к

    данным через стандартные Web-браузеры. Основанный на Windows NT

    продукт DSS Web 4.1 компании Microstrategy включает базированный

    на языке Java пакет AutoPrompt, который позволяет внедрять

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

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

    работает на платформах Windows 3.1, Windows 95, Windows NT, OS/2,

    Macintosh, Unix.

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

    остаются следующие:

  • Короткое время ответа на запросы к масштабным рынкам данных.

  • Администрирование рынков данных.

  • Возможности быстрой реализации.

    Координаты компаний:

    Arbor Software Corp.:

    Blue Isle Software Corp.:

    CrossZ Software:

    IBM:

    Informatica Corp.:

    Information Advantage Inc.:

    Information Builders Inc.:

    MicroStrategy Inc.:

    NCR Corp.:

    Pilot Software Inc.:

    Red Brick Systems Inc.:

    Sagent Technology Inc.:

    SAS Institute Inc.:


    Масштабируемость, переносимость


    Oracle8 обладает очень высоким уровнем переносимости, будучи
    доступен на более двенадцати различных платформ. DB2
    ориентируется только на наиболее популярные платформы. Что
    касается масштабируемости, то оба продукта могут масштабироваться
    от однопроцессорных машин до симметричных мультипроцессоров и
    даже до кластеров и массивно параллельных процессоров. Общий
    программный код DB2 v.5 используется для платформ NT, UNIX и
    OS/2. Однако в семействе DB2 имеется еще три разновидности
    исходного кода: DB2 для OS/390, VM/VSE и OS/400. Еще одним
    отличием в версиях является то, что в версиях для мейнфреймов не
    поддерживаются мультимедийные расширения. (Планируется их
    появление в следующей версии DB2 для OS/390.) Оба продукта будут
    поддерживать большое число пользователей. Для DB2 v.5
    производилось тестирование с 64,000 одновременно работающих
    пользователей. Для Oracle8 обещается поддержка десятков тысяч
    пользователей, но тестовые результаты пока недоступны.


    Матрица объектно-реляционных свойств



    Свойство Server Informix-Universal Database IBM DB2 - Universal Oracle8
    Расширяемая система типов Да Да Да
    Поддержка строгой типизации Да Да Да
    Поддержка иерархии типов и расследования Да; простое наследование для именованных строчных типов и таблиц Нет; ожидается поддержка множественного наследования Нет; в 8.1 будет простое наследование
    Репликация данных Нет; планируется Нет; планируется -
    Определяемые пользователями функции Да Да Да
    Перегрузка функций Да Да Да
    Разрешение имени функции на основе типов параметров Да Да Да
    Расширяемая система индексирования Да Нет; планируется Нет; планируется в Database Extesibility Services
    Расширяемый оптимизатор запросов Да; таблично-управляемый Да; управляемый правилами, но интерфейс не открыт; планируется Нет; планируется в Database Extesibility Services
    Поддержка больших объектов Да; SQL-3 LOBs Да; SQL-3 LOBs Да; SQL-3 LOBs
    Поддержка внешних данных Да; только доступ; имеются планы обеспечить управление Да; только доступ; полное управление будет обеспечено Да; только доступ
    Расширяемая языковая поддержка
    3GL Да; Си/Си++ Да; Си/Си++ и любой язык с поддержкой Си-соглашений Да; Си/Си++
    4GL Нет Да PL/SQL
    Объектно-ориентированные языки Да - Java; ожидается Си++ Да - Java; другие - после появления Client Object Support Нет; Java планируется в Database Extesibility Services
    Доступные предопределенные расширения Да - Datablades Да; текст, видео, аудио от IBM, пространственные данные от ESRI Да; текст, видео, графика и т.д.
    Средства для добавления расширений (API, инструментальные наборы) Да Да Нет; SDK для расширяемости баз данных



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


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


    Microsoft


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


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


    OLAP (On-Line Analitical Processing - оперативная аналитическая
    обработка) и многомерный анализ представляют собой важные факторы
    систем поддержки принятия решений. Поддерживаемые в Oracle
    звезднообразные запросы с соединениями (star-query join)
    обеспечивают многомерное представление данных путем получения
    Декартова произведения таблиц измерений с последующим соединением
    результата с таблицей фактов. В DB2 используется модифицированный
    оптимизатор, использующий динамические побитные индексы и
    предварительное чтение списков для выборки строк из многомерной
    таблицы фактов. Использование побитных индексов позволяет
    повысить эффективность доступа к многомерным данным. В DB2 v.5
    побитные индексы могут создаваться динамически, в то время как в
    Oracle8 они должны быть предопределены. (Важно заметить, что
    реализация побитных индексов IBM и Oracle существенно
    различается.) Кроме того, в DB2 поддерживаются новые функции SQL
    ROLLUP и CUBE, облегчающие многомерный анализ. Пользователи могут
    "закатить" данные на более высокий уровень агрегации и видеть
    данные в структуре куба, а не в традиционных табличных
    структурах. Эти возможности расширяют функциональность языка SQL
    и облегчают жизнь пользователей. Компания Oracle интегрирует c
    Oracle8 продукт IRI Express для развития возможностей
    многомерного анализа. В ближайшем будущем IBM также будет
    обеспечивать полную поддержку многомерных данных за счет
    интеграции UDB с сервером Essbase OLAP компании Arbor Software.


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


    В традиционных методологиях моделирования реляционных баз данных
    обычно пренебрегают поддержки концептуального уровня.
    Моделирование "объект-роль" (ORM - Object-Role Modeling) - это
    привлекательная методология, направленная на отрицание этого
    правила. Понятия ORM известны в течение ряда лет, хотя
    методология стала привлекать широкое внимание относительно
    недавно в связи с работой Терри Хаплина (Terry Haplin) по
    реализации средства проектирования InfoModeler. Формальный язык
    моделирования "объект-роль" (FORML - Formal Object-Role Modeling
    Language) основан на концепциях ORM и поддерживает
    систематический и строгий подход к моделированию
    бизнес-концепций. Концептуальный моделер FORML позволяет
    вербализовать данные, представить их в символической или
    диаграммной форме, ограничить концептуальную модель фактами,
    иллюстрирующими утверждения и проверить правильность модели.


    Мотивация


    С самого начала язык Java позиционировался как язык программирования для использования в среде Web. На Java разрабатывалось много простых приложений (игры, часы, тикеры и т.д.) информативных, новаторских Web-узлов. Но следует заметить, что языковые компоненты и конструкции, первоначально внедренные в язык для расширения его функциональных возможностей как Web-ориентированного языка, могут применяться и в других областях. Язык Java обеспечивает разработчиков средствами, пригодными для создания новых сетевых приложений, приложений баз данных и графических пользовательских интерфейсов (GUI Graphical User Interface). Java и связанные с этим языком технологии, такие как API JDBC, драйверы JDBC, многопоточность и AWT обеспечивают поддержку разработки независимых от платформы и используемой базы данных приложений. Вот компоненты, которые играют важную роль при построении интерфейсов с базами данных:
  • JDBC. Модуль Java Database Connectivity предоставляет
    стандартизованное решение проблемы доступа к базам данных (JDBC
    входит в пакет поставки Java начиная с версии 1.1).
  • Java Threads. Java - это многопотоковый язык программирования.
    Поддерживается возможность создания и выполнения нескольких
    нитей (легковесных квази-процессов) при выполнении в то же время
    нескольких разных задач.
  • AWT. Набор инструментальных средств Abstract Window Toolkit
    позволяет строить независимые от платформы графические
    пользовательские интерфейсы.
    Комбинация перечисленных компонентов составляет базовые
    строительные блоки, используемые для разработки интерфейсов к
    распределенным базам данных. Пакет Java Distributed Query
    Dispatcher (JavaDQD) является независимым от платформы
    GUI-приложением, позволяющим направлять запросы одновременно к
    нескольким разнородным базам данных. В основе JavaDQD лежат
    следующие идеи:
  • JavaDQD устанавливает подключение к базе данных с
    использованием API и драйверов JDBC. Использование API дает
    возможность обеспечить единообразный доступ к любой базе данных,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


    Еще одна причина, которая заставляет автора считать инкапсуляцию не настолько важным понятием, как это полагается в литературе, состоит в следующем. Некоторые типы являются совсем не инкапсулированными, и это никому не мешает! В частности, это относится к "генерируемым" типам, которые определяются с использованием генераторов типов, такие как ARRAY, LIST, TUPLE и RELATION. Рассмотрим для определенности RELATION. Предположим, что теперь мы имеем дело с relvar (relation variable) POINT:
    VAR POINT ... RELATION { X ..., Y ... } ... ; /* для простоты типы атрибутов X и Y опущены */
    Замечание: Определение сформулировано на языке Tutorial D, который определен в Third Manifesto для иллюстративных целей. Многоточия в определении поставлено вместо конструкций, не являющихся существенными для этого обсуждения.
    В этом определении для указании (генерируемого) типа relvar используется генератор типов RELATION; это конкретный тип отношения, а именно:
    RELATION { X ..., Y ... } /* снова для простоты типы атрибутов X и Y опущены */
    И этот тип определенно не является инкапсулированным: у него имеются видимые пользователям компоненты - атрибуты X и Y. И именно наличие этих видимых пользователям компонентов позволяет выполнять над relvar POINT непредвиденные запросы; например, можно выполнить проецирование на атрибут Y, ограничение по условию "значение Y меньше пяти".
    Заметим мимоходом, что похожие наблюдение содержатся в книге Mike Stonebraker про объектно-реляционные СУБД: "Базовые типы полностью инкапсулированы. Единственный способ манипулировать [экземпляром] базового типа состоит в том, чтобы выбрать его и выполнить функцию, принимающую [экземпляр этого типа] в качестве аргумента. В противоположность этому, составные типы полностью прозрачны. Можно видеть все поля, и они легко доступны в языке запросов. Конечно, промежуточная позиция заключается в том, чтобы допустить в составном объекте наличие публичных (видимых) полей и приватных (инкапсулированных). Этот подход используется в Си++". Однако следует добавить, что остается неясным, проводит ли Стоунбрейкер четкое различие между реальными и возможными представлениями, как это делается в The Third Manifesto.
    Вернемся к основному аргументу. Тот факт, что типы отношений не искапсулированы, не означает потерю независимости данных! Например, в случае relvar POINT нет абсолютно никаких причин, по которым нельзя было бы физически представить эту relvar полярными координатами R и U, а не декартовыми координатами X и Y. (Вероятно, это невозможно сделать в сегодняшних продуктах SQL, но это недостаток продуктов. Сегодняшние продукты SQL вообще обеспечивают меньшую независимость данных, чем теоретически в состоянии обеспечить реляционная технология.) Другими словами, даже при использовании не инкапсулированных типов требуется четко различать типы и представления, и "отказ от инкапсуляции" не обязательно ведет к разрушению независимости данных.


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


    Грядущий мир объектно-реляционных VLDB предлагает разработчикам и
    конечным пользователям приложений богатые возможности получить
    более мощные, интуитивно понятные и продуктивные приложения.
    Однако, как это часто бывает при использовании новых технологий,
    прежде, чем такие приложения станут обычными, потребуется период
    изучения. Это изучение (и некоторые существенные изменения в
    реализации) должно быть произведено поставщиками СУБД, которые
    должны обеспечить функции манипулирования данными, определения
    данных, администрирования и также средства обучения. Требуются
    также значительные усилия для обеспечения всех необходимых типов
    данных и методов и оптимизации данных. Эти процессы будут в
    полном разгаре в 1998 г. и должны начать стабилизироваться в
    1999-2000 гг.


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


    Инкапсуляция вступает в некоторый конфликт с потребностью выполнять непредвиденные запросы. Инкапсуляция означает, что доступ к данным может быть произведен только через заранее определенные операции, а смысл непредвиденных запросов, почти по определению, состоит в том, что требуется доступ, способ которого невозможно предопределить. Например, пусть имеется тип данных POINT; предположим, что также имеется (предопределенная) операция для "взятия" (чтения или выборки) X-координаты заданной точки, но нет подобной операции для соответствующей Y-координаты. Тогда невозможно выполнить даже следующие простые запросы и множество подобных:
  • Получить Y-координату точки P
  • Выбрать все точки по оси X
  • Выбрать все точки со значением ординаты меньшим пяти.
    В Third Manifesto (3) Крис Дейт и Хью Дарвин для разрешения этого конфликта предлагают потребовать, чтобы для каждого заданного типа были определены операции, раскрывающие некоторое возможное представление экземпляров этого типа (авторы называют такие операции "THE_operators"). Для типа POINT, например, можно было бы определить операции THE_X и THE_Y, что позволило бы производить следующие действия:
    Q := THE_Y (P) ; /* получить Y-координату точки P и присвоить ее Q */ Z := SQRT ( THE_X (P) ** 2 + THE_Y (P) ** 2 ) ; /* получить расстояние до точки P от точки (0,0) и присвоить его Z */
    Таким образом, THE_X и THE_Y действительно раскрывают возможное представление - а именно, декартовы координаты X и Y - и обеспечивают возможность выполнять непредвиденные запросы с точками. Однако это не означает того, что внутри системы точки действительно представлены декартовыми координатами; это значит лишь то, что декартовы координаты являются возможным представлением. В реальном представлении могут использоваться декартовы координаты, полярные координаты R и U или что-нибудь совсем другое. Другими словами, THE_операции не нарушают инкапсуляцию и не подрывают независимость данных. Заметим, кстати, что типы данных DATE и TIME языка SQL представляют пример встроенных типов с раскрытием некоторых возможных представлений. Например, для дат раскрывается возможное представление с компонентами YEAR, MONTH и DAY. Хотя, вероятно, следует добавить, что эти "возможные" представления в SQL, к сожалению, близки к реальным представлениям; в SQL различие между типами и представлениями часто не является четким.


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


    Победитель - VisiBroker (Visigenic Software, )
    После поглощения компании PostModern Computing и ее продукта
    компания Visigenic заняла лидирующие позиции на рынке брокеров
    объектных заявок. Поддерживая такие Web-технологии как Java и
    IIOP, компания работает с мощной группой партнеров (Netscape,
    Novell, Oracle, Sybase, Borland, Hitachi), которые используют
    VisiBroker в своих продуктах.


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


    Победитель - ERwin (Logic Works Inc., )
    ERwin обеспечивает возможности сложного моделирования, генерации
    схемы, реинжениринга, а также позволяет интегрировать средства
    разработки. В настоящее время продукт расширяется, чтобы быть в
    состоянии моделировать сложные данные в универсальных серверах.


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


    Победитель - Crystal Reports (Seagate Software Inc.,
    )
    Crystal Reports обеспечивает доступ к десяткам источников данных,
    и базовый компонент системы может быть внедрен в приложения с
    использованием множества различных интерфейсов. В версии 6.0
    добавлены средства поддержки Web, так что могут производиться
    отчеты, доступные для браузеров.


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


    Победитель - ERwin (Logic Works Inc., )
    В этой номинации читатели DBMS выбрали ERwin компании Logic
    Works как предпочтительное CASE-средство, выделив исключительные
    качества технической поддержки.


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


    Победитель - Joe Celko
    Кто сказал, что язык SQL скучен? Колонка Joe Celko "SQL for
    Smarties" дает возможность читателям познакомиться с его
    уникальными и перспективными соображениями в области индустрии
    баз данных.
    Читателям предлагались еще и следующие номинации, но по причине
    малого числа поданных голосов награды не были присуждены:
  • "Средство тестирования для приложений "клиент/сервер" и
    "Internet/intranet""
  • "Средство миграции, преобразования и очистки данных для складов
    данных и других потребностей в миграции"
  • "Web-сервер как шлюз к базам данных или средство интеграции"


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


    Победитель - Tuxedo (BEA Systems Inc., )
    Tuxedo - это популярный монитор транзакций, работающий на
    различных UNIX-платформах и в среде Windows NT. Сегодня Tuxedo
    делает много больше, чем просто управляет транзакциями. Продукт
    отслеживает работу приложений, администрирует безопасность,
    управляет сообщениями и т.д.


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


    Победитель - ERwin (Logic Works Inc.)
    В ERwin 3.0 различаются логическая и физическая модели. В
    последней версии продукта улучшены возможности пользовательского
    интерфейса и введены практические усовершенствования, такие как
    поддержка представлений.


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


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


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


    Победитель - ObjectStore (Object Design Inc., )
    ObjectStore - это зрелая ООСУБД, побеждавшая и в прошлые годы.
    Сервер ObjectStore 5.0 обеспечивает интерфейсы для Java, ActiveX
    и C++.


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


    Победитель - Oracle Applications (Oracle Corp.)
    Продукт Oracle Applications включает более 30 интегрированных
    модулей для управления финансами, человеческими ресурсами,
    управления поставками и т.д.


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


    Победители - SQL Net (Oracle Corp.) и ODBC (Microsoft Corp.)
    При критическом значении, которое промежуточное программное
    обеспечение имеет для приложений, связанных с использованием баз
    данных, эта разновидность программного обеспечения должна
    оставаться прозрачным для конечных пользователей. Компания Oracle
    предлагает стандартную версию SQL Net в связке со своими
    популярными РСУБД. ODBC компании Microsoft претендует на большее:
    драйверы ODBC имеются практически для всех доступных источников
    данных (включая нереляционные) и почти все средства разработки
    поддерживают использование этих драйверов.


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


    Победитель - Oracle (Oracle Corp. )
    Читатели DBMS продолжают хранить верность Oracle7 и теперь
    Oracle8. РСУБД компании Oracle поддерживают большое число
    пользователей, выполняют большое число транзакций, позволяют
    работать с большими базами данных, обеспечивают высокий уровень
    доступности данных. Улучшенная производительность Oracle8 должна
    позволить компании остаться лидером в области OLTP.


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


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


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


    Победитель - Visual Basic (Microsoft Corp., )
    Появление Visual Basic революционизировало разработку приложений
    в среде Windows. Но до появления версии 3.0 Visual Basic не
    обеспечивал встроенную поддержку разработки приложений баз
    данных. Сегодня Visual Basic - это зрелый и мощный продукт для
    построения приложений масштаба предприятия, особенно при
    использовании его с новейшими компонентами Back Office, такими
    как Microsoft Transaction Server и Microsoft Message Queue
    Server.


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


    Победитель - BusinessObjects (Busines Objects SA,
    )
    Продукт может быть применен при использовании оперативных баз
    данных, складов и лавок данных, а теперь еще и внутри
    Web-браузеров. В последней версии (4.1) имеется возможность
    использования интеллектуальных агентов для оповещения
    пользователей об изменениях в базе данных.


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


    Победитель - SQL Enterprise Manager (Microsoft Corp.,
    )
    С годами Microsoft SQL Enterprise Manager стал мощной и
    популярной утилитой, позволяющей легко администрировать сложные
    реляционные СУБД.


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


    Победитель - CA-Unicenter TNG (Computer Associates International
    Inc., )
    CA-Unicenter TNG управляет ресурсами в широком диапазоне, включая
    сети, приложения, базы данных в среде различных операционных
    систем. Продукт поддерживает безопасность, отслеживает события,
    управляет распространением и обновлением программного обеспечения
    и выполняет множество других функций.


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


    Победитель - Access (Microsoft Corp., )
    Последние усовершенствования продукта в значительной степени
    облегчают его использование: имевшиеся ранее многочисленные
    многошаговые процедуры теперь существенно упрощены и убыстрены.
    Access близок к популярным средствам разработки уровня конечного
    пользователя.


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


    Победитель - Oracle (Oracle Corp.)
    После появления версии 7.3 Oracle7 РСУБД стала центром
    универсального сервера компании. Не удовлетворяясь более
    хранением только табличных данных, компания поставляет
    специализированные серверы, такие как ConText для
    интеллектуального управления текстовыми данными и Oracle Video
    Server. Теперь механизм картриджей обеспечивает другие средства
    для поддержки сложных типов данных в среде Oracle.


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


    Как уже отмечалось, наиболее значительным изменением изменением в статье 1970-го г. является та идея, что всегда следует нормализовывать отношения: их следует определять только на "доменах, элементы которых являются атомарными (не составными) значениями". Таким образом, "нормализация" означает "отсутствие повторяющихся групп" или то, что теперь называется первой нормальной формой - 1NF. (Нормальные формы более высокого порядка -- 2NF, 3NF и т.д. -- были определены позже.) Кодд настаивает на нормализации, потому что нормализованное отношение "может быть представлено в памяти в виде двумерного массива с однородными столбцами ... [хотя] для отношений необходимы некоторые более усложненные структуры данных [т.е. ненормализованность].
    Странно, что в своем первом аргументе в пользу нормализации Кодд сосредотачивается на простоте представления в памяти. Возможно, в действительности он имел в виду простое представление для пользователей. Немного странным является его использование термина "массив", поскольку доступ к элементам массива производится путем адресации их позиций, в то время как для элементов отношения (n-кортежей) это в основном не так.
    Кодд утверждает, что простота представления в виде массива обеспечивает преимущество "при обмене крупными порциями данных между системами, использующими различные представления данных. Для обмена данные могли бы представляться в виде сжатого представления на основе массивов и в этом представлении (a) следовало бы избегать использования указателей, (b) следовало бы избегать всех зависимостей от схем хэш-адресации и (c) не должны были бы содержаться индексы или упорядоченные поля" (цитата слегка перефразирована).
    Как кажется, второе утверждение является первым явным упоминанием Кодда того факта, что реляционная модель строго исключает использование указателей -- факта, который, как вы должны знать, впоследствии стал предметом многих споров. "Применение реляционной модели данных ...
    дает возможность разработки универсального подъязыка данных, основанного на прикладном исчислении предикатов. Если набор отношений находится в нормальной форме, оказывается достаточным исчисление предикатов первого порядка." Это важный момент! -- и в нем отражается основной отход от статьи 1969-го года, в которой обсуждалось исчисление предикатов второго порядка, а не первого. Для читателей, которые могут быть не знакомы с этими понятиями, позвольте мне сказать (в реляционных терминах) лишь то, что "первый порядок" означает, что мы квантифицируем только строки отношений, а "второй порядок" дает возможность расставлять кванторы над отношениями. Логика первого порядка позволяет формулировать такие запросы как "Существует ли поставщик S1 в отношении поставщиков?" Логика второго порядка дает возможность формулировать запросы типа "Существует ли поставщик S1 в каком-либо отношении?"

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


    Большие объекты. При использовании традиционных методов хранение в базе данных больших объектов (например, видео-клипов) может
    привести к существенной деградации производительности системы по
    причине слишком интенсивного использования таких ресурсов как
    буфера и журналы. Истинная объектно-реляционная система должна
    обеспечивать специальные средства для повышения эффективности
    приложений, связанных с большими объектами, и минимизации их
    влияния на системные ресурсы.
    В DB2 поддерживаются три типа данных для хранения больших
    объектов: BLOB для бинарных объектов, CLOB для символьных строк и
    DBCLOB для строк, в которых используются двухбайтовые наборы
    символов. Для каждого из этих типов данных можно хранить объекты
    объемом до 2 Гбт. Когда большие объекты сохраняется в столбце
    таблицы, то на самом деле столбец содержит "дескриптор" каждого
    такого значения; сами же большие объекты хранятся вне таблицы.
    Такой подход предотвращает влияние наличия больших объектов на
    физическую кластеризацию таблицы, которая может уменьшить число
    чтений страниц внешней памяти при просмотре таблицы. Опции
    оператора CREATE TABLE позволяют управлять расположением больших
    объектов на физическом носителе.
    Подсистема восстановления DB2 дает возможность создателю таблицу выключать обычную журнализацию изменений столбцов с большими
    объектами. При выключенной журнализации по отношению к таким
    столбцам гарантируется согласованность транзакций, но столбец не
    может участвовать в процедуре прямого восстановления (повторении
    операций зафиксированных транзакций при восстановлении базы
    данных от контрольной точки).
    По причине большого размера крайне желательно минимизировать
    число перемещений и копирований больших объектов. В среде DB2
    прикладная программа может объявить переменную-"локатор", которая
    представляет значение большого объекта, но реально его не
    содержит. Содержимое локатора является спецификацией того, как
    значение большого объекта может быть материализовано в случае

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    программы.


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


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

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

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

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


    Object Relational Reality Check


    , July 1998
    , a principal of , a consultancy specializing in database design and software development for Internet and decision-support applications
    Оригинал статьи можно найти по адресу
    Являются ли объектно-реляционные СУБД (ОРСУБД) "следующей большой волной"? При всем хорошем к ним отношении ответ автора статьи - "нет". Возможно, волны ОРСУБД будет биться о берег в течение нескольких следующих лет, но это не цунами. Ситуация объясняется природой объектно-реляционных моделей, существующих в контексте более широкой тенденции, которая опирается на распределенные объекты.
    Технологию объектно-реляционных баз данных нельзя считать устоявшейся, и, более того, она далеко не так развита, как обещалось. Первая значимая коммерческая ОРСУБД Illustra появилась в 1993 г., а в 1997 г. несколько ведущих компаний-поставщиков СУБД стали предлагать свои оъектно-реляционные продукты, но во всех них остаются большие дыры. В каждой из этих ОРСУБД (Oracle8, IBM DB2 Universal Database и Informix Universal Server) объектные расширения реляционной модели реализуются неполно и разными способами. Доступно лишь немного средств проектирования и разработки, пригодных для использования в объектно-реляционных средах, и рынок приложений, основанных на этом подходе, развивается медленно. В результате поставщики ОРСУБД переосмысляют свои маркетинговые и технологические стратегии в свете навеянного Internet бума в распределенных объектных вычислениях, а поставщики чистых РСУБД (такие как и ) принимают решение обойтись поддержкой объектов на основе промежуточного программного обеспечения (middleware), не входящего в состав СУБД.
    В статье кратко объясняется, как понятия объектно-реляционного подхода реализованы в разных продуктах, и описываются некоторые альтернативные подходы, обеспечивающие объектно-реляционное представление реляционных данных. После этого приводится обзор инструментальных средств ОРСУБД и некоторых ключевых прикладных областей.


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


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

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

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

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


    Обсуждение


    В заметке сделана попытка показать, что запросы с разделами GROUP BY и HAVING (GBH-запросы) и переменные с областью значений являются избыточными в языке SQL. Интересно заметить, что эти аспекты SQL относятся к числу тех, которые наиболее трудно изучаются, понимаются и правильно применяются. Если говорить конкретно о GBH-запросах, то кажется, что альтернативные формулировки часто бывают более предпочтительными. Рассмотрим еще раз запрос Q4 из первой части заметки.
    Q4: Выдать номер каждой детали, поставляемой более чем одним поставщиком.
    Вот формулировки этого запроса с GBH и без GBH:
    SELECT SP.P# FROM SP GROUP BY SP.P# HAVING COUNT(*) > 1 ;
    SELECT DISTINCT SP.P# FROM SP WHERE ( SELECT COUNT(*) FROM SP AS SPX WHERE SPX.P# = SP.P# ) > 1 ;
    По мнению Дейта,
  • Вариант без GBH по крайней мере логически понятнее и проще чем вариант с GBH, поскольку в нем не используются дополнительные языковые конструкции (разделы GROUP BY и HAVING)
  • Из исходной формулировки проблемы не видно, что именно группирование требуется для выражения запроса на SQL (и оно действительно не требуется)
  • Далеко не очевидно, что нужен раздел HAVING, а не раздел WHERE
    Вариант с GBH больше похож на предписание решения проблемы, т.е. набора шагов, которые необходимо предпринять для нахождения ответа, а не на описание самой проблемы. А общее назначение реляционной модели всегда состояло в том, чтобы можно было использовать декларативные, а не процедурные формулировки. Декларативные формулировки требуют работы системы, процедурные - работы пользователя.
    Конечно, нельзя отрицать, что вариант формулировки с GBH более короткий. Но если единственным преимуществом формулировок с GBH является краткость, то было бы лучше определять такие формулировки как сокращенную запись. Тогда, вероятно, не проявлялись бы отмеченные в заметке аномалии и реализация была бы проще. Замечание: следует упомянуть, что реляционный аналог разделов GROUP BY и HAVING языка SQL оператор SUMMARIZE определяется как сокращенная запись.

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

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

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

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


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


    , Центр Информационных Технологий
    В этом (1997) году исполняется десять лет одному из наиболее
    популярных и авторитетных журналов в области баз данных "Data
    Base Programming and Design". По этому поводу на журнала выпущена специальная, доступная только в
    электронной форме подборка материалов. Среди них, по нашему
    мнению, особый интерес представляет материал под названием
    "Звезды десятилетия" ("Stars of the Decade"). Редакция попросила
    своих ведущих авторов выделить наилучшие программные средства
    управления базами данных, которые появились в последние десять
    лет. Нам кажется, что краткий пересказ этих мнений будет
    интересен нашим читателям.
    Nagraj Alur

    DataBase Associates

    Contributing Editor, Client/Server Forum column (1993-96)
    Неоспоримым лидером среди поставщиков реляционных систем
    управления базами данных (РСУБД) для мейнфреймов была компания
    IBM с DB2 в среде MVS. Особое влияние на широкое признание
    системы оказал выпуск DB2/2 в апреле 1988 г. В этой версии
    системы сосуществовали возможности поддержки оперативных
    транзакционных приложений и приложений, ориентированных на
    системы принятия решений.
    Компания Sybase сыграла решающую роль во внедрении в сферу РСУБД
    аппаратуры микропроцессоров и технологии открытых систем на
    основе применения архитектуры "клиент-сервер". Используемая
    комбинация низкостоимостных персональных компьютеров и
    технологии открытых систем произвела сильное впечатление на
    индустрию баз данных. Необходимо также отметить значение
    PowerBuilder в развитии технологии "клиент-сервер" на уровне
    рабочих групп за счет возможности быстрой разработки приложения и
    обеспечения доступа к разнородным РСУБД.
    Компании Microsoft и Intel сосредоточились на том, чтобы
    обеспечить доминирование клиентских станций с Windows на рынке
    настольных компьютеров и сделать возможным создание корпоративных
    информационных систем на основе использования дешевых серверов NT
    и SQL-сервера.
    Агрессивная ценовая политика, разработка

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

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

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

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

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

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

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

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

    РСУБД.

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

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

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

    Joe Celko

    Northern Lights Software

    Contributing Editor on SQL column (1990-1992)

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

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

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

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

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

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

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

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

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

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

    Terry Moriarty

    Spectrum Technology Group Inc.

    Contributing Editor, Enterprise View column (1993-present)

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

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

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

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

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

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

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

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

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


    MS

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

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

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

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

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

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

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

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

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

    Patrick O'Neil

    University of Massachusetts

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

    Support", February 1997

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

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

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

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

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

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

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

    80-х.

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

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

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

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

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

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

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

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

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

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

    David Plotkin

    Longs Drug Stores

    Contributing Editor, Desktop Database column (1993-1995)

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Tim Quinlan

    Consultant

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    данных.

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

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

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

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

    Alan Simon

    CoreTech Consulting Group

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




    Focus Issue: December 1996

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

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

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

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

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

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

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

    Doug Thomson

    Pragmatek Consulting Group

    Contributing Editor, Corporate Developer column (1995-present)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Jay-Louise Weldon

    SHL Systemhouse

    Most recent DBPD feature: "Choosing Tools for Multidimensional




    Data", February 1996

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

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

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

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

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

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

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

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

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

    Paul Winsberg

    DataBase Associates

    Client/Server Forum column (1993-1996)

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

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

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

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

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

    ERwin.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Casey Young

    RYC Inc./International DB2 Users Group (IDUG)

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


    , vol.10, N 6, June 1997

    , Won Kim

    , Центр Информационных Технологий
    Существует путаница вокруг понятия универсального сервера баз
    данных, и стоит разобраться, что же свойственно истинной
    объектно-реляционной системе.
    Эра объектно-реляционной технологии баз данных началась в 1992 г.
    с выпуском системы баз данных UniSQL/X, сочетающей черты
    реляционной и объектно-ориентированной системы. Вскоре после
    этого компания Hewlett-Packard выпустила систему OpenOOB (позднее
    переименованную в Odapter), представляющую собой объектный слой
    над реляционной системой AllBase. В 1993 г. компания Montana
    Systems (переименованная впоследствии в Illustra) начала поставки
    первой коммерческой версии объектно-реляционной системы Postgres,
    в реализации которой наибольшее внимание уделялось управлению
    мультимедийными данными.
    Эти три производителя вскоре привлекли внимание аналитиков прессы
    и индустрии. Компания Informix поглотила Illustra Technology
    (интересуясь главным образом технологией DataBlade для расширения
    возможностей баз данных). Сегодня такие гиганты как Oracle,
    Informix, Sybase, IBM и Microsoft имеют объявленные планы
    преобразования своих реляционных продуктов в объектно-реляционные
    к концу 1997 г. В результате на рынке объектно-реляционных систем
    царствуют сомнения. Для этого есть несколько причин.
    Во-первых, в результате поглощения компанией Informix технологии
    Illustra и последующей маркетинговой активности в общей
    технологии объектно-реляционных систем чрезмерный вес был придан
    роли расширяемости типов данных. Во-вторых, озадачивает
    отсутствие меры "объектно-реляционной полноты системы", т.е.
    уровня поддержки возможностей объектно-реляционного моделирования
    и управления данными.
    В статье предлагается практическая метрика объектно-реляционной
    полноты; эта метрика может применяться для определения того,
    насколько продукт является истинным объектно-реляционным. Метрика
    состоит из семи основных категорий, в каждой из которых

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

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

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

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

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

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

    power).



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    OID)

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Следующие модельные понятия OMG являются менее важными:

  • Иерархия наследования классов как домен

    Семантика включения множеств, связанная с иерархией наследования

    классов, предполагает, что экземпляры подкласса логически

    принадлежат его суперклассу. Если домен атрибута специфицирован

    как ссылка на класс, то этот домен может включать не только

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

    экземпляры классов, являющихся прямыми или косвенными

    наследниками данного класса.

  • Атрибуты и методы класса

    Понятно, что экземпляр класса - это объект. Но следует ли

    относиться как к объекту к самому классу? Ответ - "да". При

    реализации этой идеи пользователи могут специфицировать атрибуты

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

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

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

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

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



    свойств всех его экземпляров (например, средний вес автомобиля);

    хранение значения, общего для всех экземпляров класса (например,

    число колес у автомобиля); спецификация значения атрибута

    экземпляра по умолчанию.

    Язык запросов (ObjectSQL)

    В ORDB должны поддерживаться ObjectSQL (язык баз данных с

    минимальными расширениями стандарта реляционного языка SQL) и

    соответствующие API (вызовы функций). Расширения SQL необходимы

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

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

    Если пользователь не нуждается в использовании возможностей

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

    Относительно стандарта ObjectSQL имеются два предложения: SQL3 и

    Object Query Language (OQL). Предпринимаются усилия по слиянию

    этих двух языков в единый международный стандарт. Стандарт SQL3,

    разрабатываемый комитетом ANSI X3H4, включает объектные

    расширения стандарта RDB SQL-92. OQL, возникший в результате

    усилий Object Data Management Group (ODMG) по стандартизации

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

    совместим с SQL3.



    Основные свойства ObjectSQL

  • SQL-92

    Поскольку текущим стандартом SQL является спецификация SQL-92,

    ObjectSQL для ORDB должен начинаться с SQL-92 и содержать

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

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

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

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

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

    HAVING и ORDER BY и запросы, включающие операции

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

  • Запросы с вложенными объектами

    Если пользователь создает класс (класс-1) с атрибутом, доменом

    которого является ссылка на другой класс (класс-2), и создает

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

    класса-2 в атрибуте класса-1, связывая тем самым экземпляр



    класса-1 с экземпляром класса-2. Пользователь должен иметь

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

    основе условий поиска на экземплярах класса-2 или же запросы

    выборки экземпляров класса-2, привязанных к экземплярам класса-1

    (удовлетворяющим условиям поиска на экземплярах класса-1).

    Конструкция запроса, называемая "выражением пути" ("path

    expression"), может позволить пользователю специфицировать

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

    домены атрибутов.

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

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

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

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

    элемент множества и любое его подмножество. ObjectSQL должен

    обеспечивать соответствующие средства запросов. Хорошим базисом

    для этого является конструкция "порождаемой таблицы" ("derived

    table") языка SQL-92, но в настоящее время в SQL-92 отсутствуют

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

  • Запросы с методами/функциями в предикатах поиска

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

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

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

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

    запроса.

  • Запросы и абстрактные типы данных

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

    поиска любой атрибут вне зависимости от вида его домена. В

    частности, доменом может являться ADT.

  • Представления

    "Представление" ("view") - это подмножество базы данных,

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

    представления создается при выполнении соответствующего запроса.

    В RDB представление логически эквивалентно таблице. В ORDB

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

    нужны по тем же причинам, что и в RDB.


    Должна иметься возможность

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

    расширения.

    Менее важные свойства ObjectSQL

  • Запросы и иерархия наследования

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

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

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

    иметь возможность специфицировать желаемый результат. Более того,

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

    исключить некоторые классы иерархии.

    Критически важные сервисы

    Объектные расширения реляционной модели вызывают далеко идущие

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

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

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

    факт, что запрос ObjectSQL может включать в своем условии поиска

    выражение пути, требует соответствующих расширений функций

    оптимизатора запросов. Поскольку пользователи могут требовать

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

    хэш-таблицу для отображения OID'ов в физические адреса объектов.

    Из-за того, что пользователи могут пожелать совместно

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

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

    или таблиц, как это делается в RDB. Далее перечисляются некоторые

    требуемые возможности расширенных RDB. Не обсуждаются такие

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

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

    автор считает, что возможности восстановления относятся к

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

    сбоям, являются менее важными.



    Первичные возможности: RDB, расширенная до ORDB

  • Автоматическая оптимизация запросов и обработка запросов

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

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

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



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

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

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

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

    базы данных для проведения оценок.

    Запрос, содержащий выражение пути, часто выполняется наилучшим

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

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

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

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

    сортировки со слиянием. Поэтому оптимизатор запросов RDB должен

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

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

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

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

    клиента или на стороне сервера (или и там, и там). Оптимизатор

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

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

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

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

    селективность условия поиска (отношение числа объектов,

    удовлетворяющих условию поиска, к общему числу объектов в

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

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

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

    приоритетов условий поиска; при этом условия с вызовом метода

    имеют высший приоритет.

  • Индексация на абстрактных типах данных

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

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

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

    B-дерева. Но индексы использовались только для алфавитно-цифровых

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

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



    Широко известны индексные структуры, такие как R-деревья,

    файлы-решетки (grid files) и k-d деревья, применяемые для

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

    линий).

  • Управление параллельным доступом

    В ORDB должны полностью использоваться все методы, употребляемые

    в RDB, включая двухфазные блокировки, протоколы установки и

    снятия блокировок, гранулированные блокировки, иерархические

    блокировки, логические и физические блокировки и режимы

    блокировок. Объектные расширения требуют некоторых добавок. Для

    поддержки запросов с иерархией наследования классов, динамической

    эволюцией этой иерархии требуются расширения техники управления

    параллельным доступом на основе блокировок. Простым решением,

    например, было бы блокирование всей грозди классов, растущей от

    данного класса, для того, чтобы избежать некоторых нежелательных

    ситуаций. Тот факт, что пользователь ORDB может использовать OID

    для доступа к одному объекту, означает, что объект, а не страница

    дискового пространства или класс должен быть наименьшей единицей

    блокировки в ORDB.

  • Авторизация

    В ORDB должен поддерживаться полный механизм авторизации,

    поддерживаемый в RDB, включая авторизацию на уровне атрибута,

    класса или представления; рекурсивную передачу и изъятие

    привилегий доступа; передачу привилегий индивидуальным

    пользователям, группам и сразу всем; авторизацию, привязанную к

    ресурсам и т.д.

    Объектные расширения вызывают добавление авторизации для

    выполнения методов и авторизации для одного объекта. Именно

    объект должен быть наименьшей единицей авторизации в ORDB.

  • Триггеры

    Триггеры настолько же важны в ORDB, как в RDB. Но объектные

    расширения не требуют существенных добавок, кроме как вызова

    методов при выполнении действия триггера.

  • Хранимые процедуры

    В ORDB методы присоединяются к конкретным классам и наследуются

    подклассами. Методы могут выполняться как клиентом, так и

    сервером. Хранимые процедуры настолько же важны в ORDB, как и в

    RDB. В RDB хранимая процедура не присоединяется к какой-либо



    таблице и поэтому не наследуется одной таблицей от другой. Но в

    ORDB хранимая процедура может рассматриваться как метод сервера,

    присоединенный к базе данных целиком, а не к какому-либо классу.

  • Динамическая эволюция схемы

    RDB позволяют пользователям динамически изменять схему базы

    данных; эти изменения обычно ограничены созданием и уничтожением

    таблицы и добавлением и уничтожением атрибута. В ORDB схема имеет

    больше составляющих, чем в RDB, и поэтому большее число элементов

    схемы может динамически изменяться. Расширения включают

    добавление метода класса и уничтожение метода, добавление и

    уничтожение связи суперкласс/подкласс и даже изменение домена

    атрибута.

    Менее важные возможности: RDB, расширенная до ORDB

  • Мандаторная безопасность

    Поддержка мандаторной безопасности всегда была важным вопросом

    для пользователей систем баз данных правительственных и военных

    учреждений. Внедрение объектных расширений усложняет эту задачу.

    Дополнительные трудности связаны главным образом с использованием

    методов и OID'ов.



    Вычислительная модель

    Многие приложения, такие как автоматизированные анализ,

    проектирование, моделирование и тестирование, могут выполнять

    операции с большими объемами данных в памяти. Эти приложения

    управляют большим числом объектов и должны выполнять обширные

    вычисления очень быстро, поэтому объекты должны находиться в

    памяти и быть заранее скомпонованными. OODB проектируются с

    учетом требования производительности, нужной таким приложениям,

    при дополнительном предположении, что сами приложения написаны на

    объектно-ориентированном языке. Для поддержки быстрого

    навигационного доступа к объектам в основной памяти OODB

    обеспечивают возможность автоматического управления большим

    числом объектов в памяти (это называется "жизненным кэшем" или

    "пулом объектных буферов"). OODB автоматически преобразуют

    форматы хранения объектов из формата базы данных в формат памяти,

    при загрузке в память преобразуют хранимые в объектах OID'ы в



    указатели по памяти и при окончании транзакции выталкивают в базу

    данных объекты, измененные в памяти. Опасность для приложений,

    связанная с использованием указателей по памяти, может быть

    сведена к минимуму за счет применения техники косвенных

    указателей на описатели объектов.

    RDB не поддерживают преобразование указателей и кэширование.

    Поэтому приложения RDB использовать явные запросы с соединением

    или хотя бы направленные к одной таблице для эмуляции простой

    навигации объектов. Более того, приложения RDB должны также

    отправлять измененные записи по одной в базу данных через

    интерфейс RDB.

    В ObjectSQL запросы и вызовы функций API могут использоваться в

    комбинации. Запрос ObjectSQL может использоваться для загрузки

    объектов в жизненный кэш; последующие вызовы API могут загрузить

    дополнительные объекты, на которые имеются ссылки из объектов,

    уже находящихся в кэше. При этом преобразование формата объектов,

    преобразование указателей, передача объектов из базы данных в

    кэш, сборка мусора и перемещение объектов из кэша в базу данных

    должны выполняться автоматически. Оператор End Transaction

    автоматически вытолкнет измененные объекты в базу данных.



    Производительность и масштабируемость

    ORDB должны быть нацелены на те сегменты рынка баз данных, в

    которых чистые RDB не справляются с трудностями моделирования

    сложных данных и управления мультимедийными данными, а также на

    те сегменты, потребностям которых не могут удовлетворить OODB по

    причине плохой масштабируемости и недостаточной развитости

    критически важных служб.

    Производительность системы баз данных, в конечном счете,

    определяет ее возможный успех и поэтому требования высокой

    производительности являются первичными. По отношению к ORDB

    требования производительности выглядят следующим образом:

  • При выполнении чисто реляционных операций производительность

    ORDB должна быть совместимой (с возможностью отклонения в

    пределах 20 процентов) с производительностью чистых RDB

  • При выполнении навигационного доступа к базе данных на основе



    OID или при навигации в памяти на основе указателей

    производительность должна быть совместимой (с возможностью

    отклонения в пределах 20 процентов) с производительностью OODB

  • Должна удовлетворяться возможность доступа к базам данных на

    основе объектных расширений SQL (выражения пути, атрибуты со

    значениями абстрактных типов, методы, определяемые пользователями

    функции и иерархия наследования).

    Масштабируемость тесно связана с производительностью;

    производительность (пропускная способность и/или время отклика)

    сервера баз данных должна соответствующим образом возрастать при

    добавлении дисков и процессоров. Для поддержки больших баз данных

    и большого числа пользователей ORDB должны соответствовать уровню

    масштабируемости, достигнутому в современных RDB. Основные RDB

    основываются теперь на трехзвенной архитектуре "клиент-сервер" и

    для поддержки большого числа пользователей связываются с

    мониторами транзакций (Tuxedo, Encina, TopEnd). Для увеличения

    пропускной способности RDB запускаются на симметричных

    мультипроцессорах (SMP), кластерах и даже массивно параллельных

    процессорах (MPP). Кроме того, в RDB используются методы

    распараллеливания, такие как архитектура множественных серверных

    процессов (в которой каждый процесс управляет несколькими

    нитями), асинхронные обмены с дисками, параллельный ввод/вывод,

    распараллеливание выполнения запросов, распараллеливание

    вспомогательных утилит (построения индексов, архивирование,

    восстановление, сжатие базы данных, обновление статистики базы

    данных, массовая загрузка).

    Все эти методы повышения уровня масштабируемости важны и должны

    использоваться и в ORDB. Однако, поскольку нельзя внедрить все

    сразу, полезно классифицировать методы на первичные и вторичные.

    (Поддержка MPP может не быть необходимой по причине

    преимущественного использования в настоящее время технологий SMP

    и кластеров.)

    Первичные требования (для масштабируемости):

  • Интеграция с трехзвенным промежуточным программным обеспечением



  • Поддержка SMP с параллельным выполнением нескольких запросов

    (без обеспечения распараллеливания индивидуальных запросов).

    Вторичные требования (для масштабируемости):

  • Асинхронные обмены с дисками

  • Архитектура множественных серверных процессов

  • Параллельные обмены с дисками

  • Поддержка кластеров

  • Распараллеливание выполнения утилит

  • Распараллеливание выполнения индивидуальных запросов



    Инструментальные средства баз данных

    Пользователи RDB осознают потребность в инструментальных

    средствах, выходящих за пределы непосредственных возможностей

    сервера баз данных с его интерфейсами уровня SQL и API, для

    поддержки цикла разработки приложений. Эти средства включают

    следующее:

  • Средства администрирования базы данных, настройки

    производительности и отслеживания использования ресурсов

  • Прекомпиляторы операторов SQL, встроенных в языки

    программирования

  • Процессор интерактивного SQL или графический генератор запросов

    для построения, редактирования и просмотра результатов запросов

  • Графические средства проектирования и просмотра для анализа и

    редактирования схемы базы данных

  • Средства разработки категории 4GL для быстрой разработки

    приложений, обладающих обычно графическим или ориентированным на

    формы пользовательским интерфейсом.

    Вообще говоря, средства для ORDB должны обладать расширенной

    функциональностью, в которой учитываются расширения, присущие

    объектному моделированию. В случае отсутствия средств,

    специфических для ORDB, в самом крайнем случае ORDB должна иметь

    интерфейсную связь с популярными продуктами RDB сторонних

    компаний, в которых учитываются возможности объектного

    моделирования.

    Далее приводится сводка необходимых объектных расширений

    инструментальных средств RDB. К наиболее важным возможностям

    объектного моделирования с точки зрения пользователей относятся

    атрибуты с множественными значениями, ADT и вложенные объекты;

    иерархия наследования и методы не столь важны. Поскольку

    инструментальные средства баз данных стали составной частью среды



    разработки приложений, большинство этих возможностей относится к

    первичной категории.



    Первичные возможности инструментальных средств баз данных

    Браузер/дизайнер базы данных должен позволять пользователям

    редактировать и просматривать схему ORDB с учетом иерархии

    наследования классов; иерархии вложенности классов на основе

    атрибутов, домены которых есть ссылки на другие классы; атрибутов

    с множественными значениями; методов и атрибутов со значениями

    абстрактных типов данных.

    Генератор запросов должен позволять пользователям конструировать

    объектные расширения SQL и просматривать результаты запросов,

    возвращающих атрибуты с множественными значениями, атрибуты со

    значениями абстрактных типов, вложенные объекты и экземпляры из

    иерархии наследования классов.

    Средство разработки 4GL должно позволять пользователям

    проектировать экраны для работы с атрибутами со множественными

    значениями, атрибутами со значениями абстрактных типов и

    вложенными объектами.

    Средства администрирования базы данных должно быть расширено так,

    чтобы, по меньшей мере, можно было распознавать планы выполнения

    запросов с выражениями пути, методами, иерархией наследования;

    кроме того, необходимы средства отслеживания ресурсов жизненного

    кэша.

    Разработанный компаниями Microsoft и Apple стандарт ODBC

    используется как интерфейс RDB для разнообразных приложений,

    выполняемых на PC. Если потребуется изменить эти приложения в

    расчете на использование объектных расширений ORDB,

    соответствующие расширения будут нужны и в ODBC.

    Сегодня средства просмотра и публикации Web внесли существенные

    изменения в среду разработки приложений. Эти изменения могут

    устранить потребность в некоторых средствах, являющихся частью

    традиционной среды разработки приложений.



    Использование мощности

    Объектные расширения в ORDB дают пользователям баз данных по

    меньшей мере две важных возможности, выходящих за пределы

    моделирования и манипулирования данными, - расширяемость базы

    данных и интеграция неоднородных баз данных.


    Средства расширения

    баз данных были широко оглашены под названиями DataBlades,

    Database Extenders и Data Catridges. Об интеграции разнородных

    баз данных говорят меньше, но эта тема также очень важна.

    Однако, поскольку обе возможности лежат за пределами

    ответственности сервера ORDB, их можно рассматривать как

    вторичные.



    Вторичные возможности "использования мощности"

  • Расширяемость баз данных

    Тема расширяемости баз данных была настолько раскручена

    компаниями Illustra и Informix, что некоторые люди полагают

    добавление к RDB DataBlades и других "расширителей" превращает

    реляционную систему в объектно-реляционную. Конечно, добавление

    средств DataBlades к серверу баз данных - это совсем неплохо. Но

    не следует забывать о том, что ORDB должна обеспечивать описанные

    выше возможности моделирования и управления и что DataBlades

    относятся к категории вторичных возможностей, делающих ORDB еще

    более мощной и полезной.

    В целом, расширяемость базы данных означает возможность добавлять

    любые новые возможности (например, алгоритмы обработки запросов,

    новые режимы блокировок, новые методы доступа) к коммерческому

    серверу баз данных. Однако для практических целей расширяемость в

    действительности включает возможность пользователей (не

    производителей) добавлять новые модули управления данными, типы

    данных (классы) и операции (методы). Новый модуль управления

    данными может быть источником данных стороннего поставщика

    (графической или текстовой информации) или механизмом управления

    источником данных (для распознавания образов или полнотекстового

    поиска). Целью расширения базы данных является обеспечение

    использования всех возможностей сервера базы данных (включая

    обработку запросов и блокировки) при управление доступными

    пользователям новыми данными.

    Возможность добавления новых типов данных и операций - это всего

    лишь логическое следствие парадигмы объектной ориентации, которая

    предполагает разрешение создания новых классов с атрибутами и



    методами, наследуемыми от существующих классов. Поэтому

    практическая важность расширяемости состоит не только в

    обеспечении возможности добавления на уровне пользователя новых

    модулей управления данными и новых типов данных, но также в

    доступности развитой библиотеки функций для конкретных типов

    данных, обеспечиваемой не пользователями, а производителями.

    Функции, привязываемые к некоторому типу данных, можно

    подразделить на "прикладные функции" и "методы доступа".

    Прикладные функции выполняют логику приложения с данными,

    выбранными из базы данных; функции-методы доступа производят

    хранение, поиск и поддержку данных в базе данных.

    Прикладные функции представляют собой разумные и полезные

    средства, которые разработчикам приложений следует добавлять к

    поставляемым производителями библиотекам. Хотя добавлять

    некоторые типы методов доступа (например, методы индексирования

    для полнотекстового поиска) могут и пользователи, обычно трудно,

    если не невозможно добавлять методы доступа для произвольных

    типов данных.

    Например, представим себе, что пользователь хочет добавить к

    серверу ORDB метод индексации, основанный на R-дереве, для

    поддержки геометрических данных. Каким образом после этого

    оптимизатор запросов ORDB распознает, что такой индекс теперь

    существует? Даже если оптимизатор сможет узнать об этом, как он

    сможет оценить селективность индекса при оптимизации

    геометрического запроса? Как, в конце концов, менеджер транзакций

    будет выполнять функции восстановления и синхронизации

    параллельного доступа по отношению к страницам R-дерева?

  • Интеграция неоднородных баз данных

    По определению модель ORDB является комбинацией реляционной

    модели данных и объектной модели. Объектная модель включает

    ключевые модельные концепции, которые использовались в

    иерархических и сетевых базах данных, такие как повторяющиеся

    группы (атрибуты с множественными значениями) и навигация по

    указателям (на основе OID). Поэтому модель ORDB представляет



    собой идеальную схему для интеграции схем все существующих

    разнородных баз данных, включая RDB, ORDB, иерархические и

    сетевые базы данных и даже плоские файлы.

    Ниже приводятся возможности, включение которых в ORDB делает

    объектно-реляционную систему возможной основой системы мультибаз

    данных (MDBS):

  • Возможность организации шлюзов к другим системам баз данных

  • Возможность представления единственной виртуальной глобальной

    схемы над существующими схемами разнородных баз данных

  • Возможность производить декомпозицию одного запроса на

    ObjectSQL в подзапросы, обрабатываемые существующими разнородными

    системами баз данных, и выполнять всю необходимую пост-обработку

    (сливать отдельные результаты, выполнять соединения между

    таблицами разных баз данных, сортировать и группировать отдельные

    результаты)

  • Возможность транзакционного контроля над существующими

    разнородными системами баз данных (в основном, двухфазная

    фиксация/откат)

    Логически MDBS является окончательным обобщением идеи шлюза;

    физически такая система управляет несколькими шлюзами, через

    которые производится управление удаленными базами данных. MDBS

    может иметь и свою собственную базу данных; например, данные,

    извлеченные из удаленных баз данных, могут быть сохранены в

    собственной базе данных MDBS - по сути дела, получает склад или

    лавка данных (datawarehouse или data mart). В любом случае MDBS

    представляет пользователям множество удаленных баз данных как

    одну "виртуальную" базу данных.


    Обзор статьи "DB2 V.5 and Oracle 8: What they've Got What They've Not"


    , August 1997

    , President of Bischoff Consulting Inc.

    , Центр Информационных Технологий
    IBM и Oracle стремятся к тому, чтобы обеспечить средства
    управления базами данных, удовлетворяющие всем возможным
    потребностям: интеграция с World Wide Web; intranets; поддержка
    сложных типов данных; поддержка всех приложений, связанных с
    оперативной обработкой транзакций (OLTP) и принятием решений.
    Хотя многие считают невозможным удовлетворение всех этих
    требований в одной СУБД, IBM и Oracle добились существенных
    успехов в этом направлении. Кроме того, обе компании обеспечивают
    поддержку больших баз данных, параллелизма, разделения данных,
    высокого уровня доступности и целостности данных.
    Компания Oracle объявила продукт Oracle8 в июне 1997 г., а IBM
    объявила DB2 Universal Database Version 5 (UDB) в декабре 1996 г.
    Хотя в обоих продуктах компании стремились обеспечить одни и те
    же возможности, для их реализации применяются разные методы.
    Существо подхода Oracle8 сосредоточено в движении в сторону
    чистого объектно-ориентированного подхода. С другой стороны, в
    UDB v.5 упор делается на интегрированную и масштабируемую
    поддерку сложных данных за счет средств расширения РСУБД, а также
    на интеграцию со средством доступа к Web Net.Data.


    Обзор статьи "Universal Servers: The Players, Part 2" DBMS, vol.10, N 7, July 1997,


    Judith R. Davis, principal with InfoIT Inc.,

    Обзор подготовлен С. Кузнецовым,
    В первой части статьи (, см. Также наш обзор) были сформулированы требования приложений, стимулирующие усилия по расширению функциональных возможностей реляционных СУБД (РСУБД) для управления сложными данными. Отмечалось, что универсальный сервер часто является лишь одним из компонентов расширяемой среды управления данными. Были также обсуждены базовые свойства, которыми должен обладать сервер баз данных для достижения расширяемости.

    Во второй части рассматривается, каким образом пять ведущих компаний-поставщиков РСУБД - Informix Software Inc., IBM Corp., Microsoft Corp., Oracle Corp. и Sybase Inc. - реально поддерживают расширяемость.


    Операции над отношениями


    В этом разделе статьи приводятся определения некоторых реляционных операций; другими словами, в нем описывается то, что позже стали называть манипуляционной частью реляционной модели. Прежде, чем вдаваться в определения, Дейт утверждает: "Эти операции не будут напрямую интересовать большинство пользователей. Однако проектировщики информационных и люди, отвечающими за управление банками данных, должны быть досконально знакомы [с ними]" (Курсив К.Дейта.) Как это верно! По моему опыту, к сожалению, люди, которым следует быть досконально знакомыми с этими операциями, слишком часто не обладают соответствующими знаниями.
    В число определенных Коддом операций входят перестановка (permutation), проекция (projection), соединение (join), связывание (tie) и композиция (composition) (в статье 1970-го г. добавлена операция ограничения (restriction), которую я описываю здесь для удобства). Интересно заметить, что определения ограничения и соединения отличаются от тех, которые используются сегодня, а операции связывания и композиции теперь редко принимаются во внимание. В том, что следует ниже, символы X, Y, ... (и т.д.) по мере необходимости обозначают либо индивидуальные атрибуты, либо комбинации атрибутов. Кроме того, по причинам, которые скоро будут понятны, определение соединения откладывается до конца раздела.
    Перестановка. Переупорядочение атрибутов отношения слева направо. (Как я отмечал в прошлом месяце, в статье 1969-го года предполагалась упорядоченность атрибутов отношения слева направо. В отличие от этого, в статье 1970-го года утверждается, что перестановка рассчитана исключительно на внутреннее использование, поскольку упорядоченность атрибутов слева направо не является -- или не должна являться -- существенной для пользователей.)
    Проекция. Понималась более или менее так же, как и сегодня (хотя синтаксис был другим; далее я буду использовать синтаксис R{X} для обозначения проекции R на X). Замечание: название "проекция" происходит из того факта, что отношение степени n можно рассматривать как представление точек в n-мерном пространстве, и к проекции этого отношения на m его атрибутов (mСвязывание.
    Для данного отношения A{X1,X2,...,Xn} связывание A - это ограничение A до тех строк, в которых A.Xn = A.X1 (если использовать термин "ограничение" в его современном смысле, а не в специальном смысле, определяемом ниже.)

    Композиция. Для данных отношений A{X,Y} и B{Y,Z} композицией A c B называется проекция на X и Z соединения (a join) A с B (причина, по которой я говорю "a join", а не "the join", объясняется ниже). Замечание: естественная композиция - это проекция на X и Z естественного соединения.

    Ограничение. Для данных отношений A{X,Y} и B{Y} ограничение A по B определяется как максимальное подмножество A такое, что A{Y} является подмножеством -- не обязательно точным -- B.

    Кодд также говорит, что "весь обычный набор операций [также] применим ... [но] результат может не являться отношением". Другими словами, когда Кодд писал свою статью 1969-го года, он оставил на будущее определения специализированных реляционных вариантов декартова произведения, объединения, пересечения и вычитания.

    Приступим теперь к определению соединения. Для данных отношений A{X,Y} и B{Y,Z} соединение A с B в статье определяется как любое отношение C{X,Y,Z} такое, что C{X,Y} = A и C{Y,Z} = B. Заметим, что следовательно A и B можно соединить (или они "соединяемы"), только если их проекции на Y идентичны -- т.е. только если A{Y} = B{Y}, условие, которое вряд ли удовлетворяется на практике. Также заметим, что если A и B соединяемы, то могут существовать различные соединения (в общем случае). Хорошо известное естественное соединение -- называемое в статье линейным естественным соединением, чтобы отличить его от другого вида, именуемого циклическим соединением -- это важный частный случай, но не единственно возможный.

    Однако странно то, что приводимое в статье определение естественного соединения не требует соединяемости A и B в приведенном специальном смысле! На самом деле, это определение почти такое же, как то, которое мы используем сегодня.



    Постараюсь объяснить, откуда берется это довольно ограничительное понятие "соединимости". Кодд начинает свое обсуждение соединений с важного вопроса: При каких условиях соединение двух отношений сохраняет всю информацию, содержащуюся в этих двух отношениях? И он показывает, что свойство "соединяемости" является достаточным для обеспечения сохранения всей информации (поскольку в результате соединения не теряется ни одна строка ни одного операнда). Далее он также показывает, что если A и B соединяемы, и либо A.X функционально зависит от A.Y либо B.Z функционально зависит от B.Y, то естественное соединение является единственным возможным соединением (хотя реально он не использует терминологию функциональных зависимостей -- это также оставлено на будущее). Другими словами, Кодд здесь закладывает фундамент важнейшей теории декомпозиции без потерь (которую он, конечно, развил в последующих статьях).

    Замечательно, что Кодд также приводит пример, показывающий, что уже в 1969 г. он осознавал тот факт, что некоторые отношения не могут быть декомпозированы без потерь в две проекции, но могут быть декомпозированы без потерь в три проекции! Этот пример был, очевидно, не замечен большинством первоначальных читателей статьи; во всяком случае для исследовательского сообщества оказалось неожиданностью повторное открытие этого факта несколькими годами позже. Именно это повторное открытие привело к изобретению Рональдом Фейджином окончательной нормальной формы 5NF, называемой также нормальной формы проекции-соединения (PJNF).


    Определяемые пользователями функции


    DB2 обеспечивает более 100 встроенных функций для выполнения
    различных вычислений над числами, строками, датами и другими
    типами данных, а также дает пользователям возможность создания
    собственных функций с использованием языков Си, Си++ и Бейзик.
    Определяемые пользователями функции (User-Defined Functions -
    UDF) могут принимать параметры и могут быть использованы в любом
    выражении SQL, где предполагается наличие скалярного значения.
    Поддерживается соглашение о передаче параметров UDF в
    поставляемую пользователем программу реализации функции. Этой
    программе передаются входные параметры функции, а также указатели
    на буфера, в которые должны быть возвращены результат функции и
    код статуса ее завершения. Создатель функции должен
    откомпилировать реализующую ее программу и поместить выполняемый
    файл в каталог, доступный серверу баз данных. После этого
    пользователь должен зарегистрировать UDF в каждой базе данных,
    где предполагается ее использование, путем выполнения оператора
    CREATE FUNCTION. В этом операторе определяются типы параметров и
    результата функции, указывается место расположения реализующей
    программы. Описание функции помещается в таблицы системного
    каталога. После этого при каждом вызове функции ее реализация
    будет динамически загружаться и выполняться. Важно обеспечить
    защиту выполняемого файла, поскольку он выполняется при вызове
    функции без дополнительных системных проверок.
    Комбинация имени функции и типов ее параметров называется
    "сигнатурой" функции. SQL позволяет "перегружать" имя функции,
    т.е. определять несколько функций с одним именем и разными типами
    параметров. При обработке вызова функции DB2 вызывает функцию,
    типы параметров которой строго соответствуют типам аргументов
    вызова.


    Определяемые пользователями типы


    В DB2 определяемые пользователями типы данных называются
    "индивидуальными типами" (distinct type"). В каждом из
    индивидуальных типов используется общее представление одного из
    встроенных типов (называемых "базовыми типами"), но может иметься
    собственный набор допустимых операций.
    Следующие операторы создают два индивидуальных типа с именами
    DOLLARS и YEN, базирующихся на встроенном типе Decimal. Фраза
    WITH COMPARISONS означает что можно сравнить любые два значения
    типа DOLLARS и любые два значения типа YEN, однако значение типа
    DOLLARS не может быть сравнено со значением типа YEN или с
    обычным десятичным значением.
    CREATE DISTINCT TYPE DOLLARS AS DECIMAL (10,2) WITH COMPARISONS;
    CREATE DISTINCT TYPE YEN AS DECIMAL (10,2) WITH COMPARISONS;
    При создании индивидуального типа DB2 генерирует функцию,
    преобразующие значение индивидуального типа в значение его
    базового типа и наоборот. Например, при создании типа DOLLARS
    создаются функции преобразования DOLLARS(DECIMAL) со значением
    типа DOLLARS и DECIMAL(DOLLARS) со значением типа DECIMAL(10,2).
    Сразу после создания индивидуального типа единственными
    операторами, применимыми к его значениям, являются операторы
    сравнения. Например, если SALARY и BONUS - это два столбца типа
    DOLLARS, то SALARY=BONUS и SALARY>BONUS являются допустимыми
    предикатами, но выражения SALARY+BONUS и SALARY*BONUS не
    допускаются, поскольку для типа DOLLARS не определены
    арифметические операции.
    Легко указать, какие из операций базового типа являются
    осмысленными для созданного на его основе индивидуального типа.
    Каждый встроенный оператор, такой как "+", реализуется функций с
    тем же именем, что и оператор. Чтобы сделать этот оператор
    применимым к индивидуальному типу, нужно просто создать функцию с
    тем же именем, что и оператор, принимающую параметры и/или
    возвращающую результат индивидуального типа данных. Функция,
    реализующая оператор, может основываться на функции, реализующей

    встроенный оператор. В следующих предложениях SQL определяются

    оператор "+" для двух значений типа DOLLARS и оператор "*" для

    значения целого типа и значения типа DOLLARS:

    CREATE FUNCTION "+" (DOLLARS,DOLLARS)

    RETURN DOLLARS

    SOURCE

    SYSIBM."+" (DECIMAL(),DECIMAL());

    CREATE FUNCTION "*" (INTEGER,DOLLARS)

    RETURN DOLLARS

    SOURCE

    SYSIBM."*" (INTEGER,DECIMAL());

    После выполнения этих предложений выражения SALARY+BONUS и

    2*SALARY будут допустимыми, но выражение SALARY*BUNUS останется

    недопустимым, поскольку оператор умножения не определен для двух

    значений типа DOLLARS.

    Конечно, может потребоваться расширить функциональность

    индивидуального типа за пределы набора операторов базового типа.

    Например, можно создать тип ADDRESS, основанный на встроенном

    типе VARCHAR(50). После этого можно создать определяемую

    пользователями функцию TIMEZONE(ADDRESS), вычисляющую временную

    зону этого адреса. Как и любая другая UDF, функция TIMEZONE может

    быть написана на языках Си, Си++ и Бейзик и должна быть

    зарегистрирована в соответствующей базе данных.


    Оптимизация


    Если сила Oracle заключается в средствах разработки, то IBM
    выигрывает в возможностях оптимизации. Хотя в обоих продуктах
    оптимизаторы используют оценки стоимости плана выполнения
    запроса, оптимизатор DB2 в дополнение к размерам таблиц и
    возможным путям доступа принимает во внимание скорость
    центрального процессора и дисковых устройств, а также полностью
    переписывает запросы, которые можно выполнить более эффективно в
    другой формулировке. Oracle продолжает работать над своим
    оптимизатором, пытаясь навести мосты между прежним оптимизатором,
    основанным на использовании правил, и средством, которое
    позволило бы пользователям включать в операторы SQL подсказки,
    ориентирующие оптимизатор на использование более эффективных
    путей доступа.


    OR-Compass


    В флагманском продукте компании Logic Works ERwin/ERX реализованы
    средства моделирования в стиле "сущность-связь" с поддержкой
    нотаций IDEF1X и IE. Обеспечивается прямая и обратная инженерия
    для всех ведущих реляционных СУБД, синхронизация логических
    моделей и физических схем. Система ModelMart обеспечивает
    управление моделью при ее групповой разработке. Компонент
    ERwin/OPEN поддерживает связи со средствами разработки
    приложений, включая PowerBuilder и VisualBasic. Кроме того, Logic
    Works предлагает средство обмена метаданными с системой
    моделирования объектов компании Retional Rose.
    OR-Compass - это новый продукт, который не является простым
    расширением ERwin/ERX, хотя и допускается импортирование
    ERX-модели. OR-Compass 1.0 работает с СУБД компании Informix
    (), но в начале 1998 г. обещана поддержка
    Oracle8 (), DB2 Universal Database компании IBM
    () и Adaptive Server компании Sybase ().
    В OR-Compass используется методология моделирования
    "сущность-связь" в нотации IDEF1X.
    Компоненты Row Type Wizard (RTW) и Functional Index Wizard (FIW)
    помогают моделировать объектно-реляционные свойства. RTW
    ориентирован на поддержку проектировщиков, мигрирующих от
    реляционных к объектно-реляционным базам данных, и позволяет
    произвести строчный тип на основе выбранных столбцов таблицы.
    Компонент не дает возможности просто определить строчный тип. FIW
    кажется более полезным, позволяя определить индекс для таблицы на
    основе вычисляемого поля.
    Полезным механизмом являются ModelBlades. Эти модули состоят из
    определений и документации объектов, входящих в состав DataBlades
    компании Informix, которые могут импортироваться из файлов
    ModelBlade или скриптов DDL (Data Definition Language).
    Импортируемые объекты могут включаться в определяемые
    пользователями модели.


    Oracle


    Компания объявила, что Oracle 8 будет уметь делать с объектами все, что умеет делать Informix-Universal Server, и даже больше. Однако это не так в первом выпуске Oracle 8 (этот выпуск был официально объявлен 24 июня 1997 г., см. сервер компании Oracle). В фокусе Oracle 8 находятся расширенная система типов и поддержка бизнес-объектов; появление других возможностей расширяемости ожидается в версии 8.1. Oracle концентрируется на реализации своей сетевой вычислительной архитектуры (NCA - Network Computing Architecture), и в Oracle 8 вносятся улучшенные возможности производительности, масштабируемости, доступности, репликации, разделения данных и т.д.
    NCA - это трехзвенная архитектурная структура, основанная на CORBA (Common Object Request Broker Architecture). В NCA используются расширяющие компоненты, называемые "картриджами", которые могут разрабатываться Oracle или сторонними поставщиками. Впервые использование картриджей приложений и картриджей баз данных
    потребовалось в Oracle Web Application Server для организации связи на основе CORBA. В контексте расширяемой среды данных Oracle будет обеспечивать компоненты на уровне промежуточного программного обеспечения приложений (например, компонент управления транзакциями в Web Application Server) и на уровне универсального сервера (Oracle 8). На объектном уровне Oracle 8 поддерживает объектные представления данных с использованием новых объектных типов и существующих реляционных данных. Кроме того, Oracle 8 поддерживает объектный кэш клиентов и навигацию между объектами по ссылкам. Транслятор объектных типов отображает объекты базы данных в соответствующие конструкции языка Си.

    Далее приводится сводка свойств, имеющихся в Oracle 8 и ожидаемых в версии 8.1.
  • Расширяемая система типов - поддерживаются объектные типы, типы коллекций (массивы переменного размера и вложенные таблицы) и ссылочные типы. Объектный тип может применяться либо к столбцу, либо к строке и может быть семантически эквивалентен именованному строчному типу SQL-3.
    Кроме того, Oracle 8 явно связывает с объектными типами методы. Пока поддерживается только один уровень вложенности таблиц (в 8.0), не поддерживаются полностью инкапсулированные ADT. Будет поддерживаться одиночное наследование. Отсутствует возможность репликации расширенных данных.

  • Определяемые пользователями функции - скалярные UDF, перегрузка и разрешение имени на основе типов параметров, параллельное выполнение UDF с определенными пользователями агрегатами (функции столбцов) находятся в стадии обсуждения.

  • Расширяемая система индексации - поддержка определяемых пользователями индексных структур и индексов на выражениях появится вместе с компонентом Database Extesibility Services.

  • Расширяемый оптимизатор - возможность указывать стоимость UDF и обеспечивать статистику об использовании определенных пользователями данных ожидается с появлением Database Extesibility Services. К расширенным типам пока не применяются параллельные операции.

  • Большие объекты и внешние данные - LOB могут храниться внутри базы данных или во внешних файлах. Oracle 8 не поддерживает доступа по чтению к внешним данным и не гарантирует их целостность. Большие объекты могут быть реплицированы, но таблицы с LOB реплицировать нельзя.

  • Расширяемая языковая поддержка - UDF и хранимые процедуры пишутся на PL/SQL или Си/Си++, причем подпрограммы на Си/Си++ выполняются вне адресного пространства сервера. Поддержка Java в сервере будет обеспечиваться в Database Extesibility Services (версия 8.1).

  • Предопределенные расширения - сервер Oracle 8 поддерживает хранение текстовых, пространственных и видео- данных; ожидается появление нового типа данных для хранения графической информации. Компания работает также с несколькими партнерами для тестирования и формализации API для Database Extesibility Services и разработки картриджей данных.


    Параллельное выполнение индивидуальных запросов


    В чисто реляционных базах данных для успешной работы с данными
    объемом более 250 Гбт требуется наивысшая степень параллельности
    при выполнении каждого индивидуального запроса. Первейшим ключом
    к распараллеливанию является структура самого языка запросов SQL.
    Этот язык предназначен для работы со множествами и накладывает
    немного ограничений на порядок выполнения запроса; поэтому
    оптимизаторы запросов реляционных СУБД обладают такой гибкостью
    при выборе планов выполнения запроса. По этой же причине SQL
    исключительно подходит для параллельного выполнения.
    Для использования этой возможности необходимо придумать стратегии
    выполнения, обеспечивающие оптимизированное параллельное
    выполнение индивидуального запроса, а не только обеспечить
    параллельное выполнение последовательных индивидуальных
    стратегий. Заметим, что и индивидуальные операции определения и
    манипулирования данными (а также утилиты архивирования и
    восстановления) должны выполняться параллельным образом.
    Поставщики реляционных СУБД выполнили большую часть работы для
    обеспечения такого распараллеливания. Более того, оказалось
    возможным поддерживать высокую степень прозрачности для
    приложений и администраторов баз данных. Этому значительно
    способствовали не только структура SQL, но также и то, что ядро
    языка и типы данных были в основном зафиксированы в 80-х и начале
    90-х гг. И тем не менее, от производителей требуется 2-3 года,
    чтобы внедрить внутреннее распараллеливание запросов в зрелую
    реляционную СУБД.
    Многие отмечают, что сложность внедрения параллелизма в VLDB
    связана с двумя аспектами. Первый аспект состоит в замене
    последовательных алгоритмов на параллельные. Второй аспект более
    тонкий. Для проектирования и разработки конкурентоспособного
    программного обеспечения требуется качественная перестройка
    образа мышления. Например, первым поползновением разработчика
    программы загрузки базы данных было бы использование функции
    INSERT. Этот метод работает для малых и средних баз данных, но не

    годится для больших: слишком медленно. Необходимо разработать

    метод, при котором происходит параллельная загрузка нескольких

    потоков данных, опираясь на возможность использования нескольких

    процессоров в архитектурах MPP или кластеры SMP. Если данные

    поступают из одного последовательного источника (например,

    устройства с магнитной лентой), первичная задача загрузки состоит

    в как можно более быстром помещении данных в память. После этого

    вся процессорная мощь должна быть использована в параллельном

    режиме для помещения каждого элемента данных в нужное место,

    поддержки индексов и т.д.

    С расширением использования ОР-баз данных проблема становится

    более сложной. Требуется учитывать наличие новых и потенциально

    экзотических типов данных. Должны быть написаны и оптимизированы

    для параллельного выполнения новые методы. Между экземплярами

    новых типов данных и даже между экземплярами стандартных типов

    SQL могут и будут существовать сложные связи. Для поддержки новых

    операций и типов данных требуются новые методы доступа к данным,

    и их тоже нужно оптимизировать для параллельного использования.

    Наконец, необходимо принимать во внимание то, что количество

    различающихся значений в одном столбце таблицы может в тысячу и

    более раз превосходить число разных значений в другом столбце.

    Для учета этого требуется применять новые подходы к хранению и

    буферизации данных как на стороне сервера, так и на стороне

    клиентов.


    Параллельный язык манипулирования данными (Data Manipulation Language - DML) SQL


    Для поддержки больших баз данных существенна поддержка
    параллельного выполнения операций вставки, модификации и удаления
    данных, и такая поддержка присутствует в обоих продуктах. Кроме
    того, в продуктах поддерживается параллельное сканирование
    индексов, но в Oracle имеются некоторые ограничения,
    отсутствующие в DB2:
  • Параллельное выполнение операторов DML не производится, если
    имеются определенные ограничения целостности: каскадное удаление;
    ограничение по ссылкам таблицы к самой себе; ограничения с
    отложенной проверкой
  • Для параллельно выполняемых операторов DML не поддерживаются
    триггеры
  • Параллельное выполнение не происходит при наличии объектных или
    LOB-столбцов.


    Переменные с областью значений (range variables)


    Замечание С.Кузнецова по поводу русскоязычной терминологии: На английском языке словосочетание "range variable" лаконично и правильно отражает суть понятия. К сожалению, до сих пор мне не удалось найти столь же лаконичный русский эквивалент, хотя было много попыток. Когда-то я пытался ввести в оборот термин "ранжированная переменная", но мне справедливо указали на отсутствие явного смысла в этом словосочетании. Если кто-нибудь знает, как лучше обозначать рассматривамое понятие на русском языке, дайте мне знать, пожалуйста.
    Рассмотрим следующий запрос:
    Q9: Выдать все пары номеров поставщиков, располагающихся в одном и том же городе
    На языке SQL возможна следующая формулировка этого запроса:
    SELECT FIRST.S# AS SX, SECOND.S# AS SY FROM S AS FIRST, S AS SECOND WHERE FIRST.CITY = SECOND.CITY
    FIRST и SECOND являются примерами того, что в SQL называется корреляционными именами. Однако заметим, что SQL ничего не говорит о том, что именно именуют эти имена! В отличие от этого, в реляционном исчислении такие имена определяются для ссылок на переменные с областью значения, и далее будет использоваться этот термин.
    Переменная с областью значений - это переменная, определенная на некоторой конкретной таблице; значениями переменной являются строки этой таблицы. Если областью значений переменной r является таблица R, то в каждый момент времени значением выражения "r" является некоторая строка R. В SQL переменные с областью значений вводятся посредством спецификации AS в разделе FROM (не нужно путать эту спецификацию со спецификацией AS в разделе SELECT, которая позволяет назначить имя столбцу результирующей таблицы).
    Покажем, что, подобно разделам GROUP BY и HAVING, переменные с областью значений являются логически избыточными в языке SQL (несмотря на то, что они активно использовались в предыдущих примерах). Для иллюстрации сначала приведем формулировку запроса Q9 без использования переменных с областью значений:
    SELECT SX, SY FROM ( SELECT S.S# AS SX, S.CITY FROM S) AS POINTLESS1 ) NATURAL JOIN ( SELECT S.S# AS SY, S.CITY FROM S) AS POINTLESS2 )

    Замечание С.Кузнецова: Напомним, что здесь используется SQL-92, в котором допустимы и такие "алгебраические" формулировки.

    Как видно, в этой формулировке на самом деле определяются две переменных с областью значений - POINTLESS1 и POINTLESS2, но логически они не требуются, поскольку отсутствуют ссылки на эти переменные. Они введены исключительно для того, чтобы удовлетворить синтаксические требования языка SQL.

    В качестве второго примера используем запрос Q1 из первой части заметки:

    Q1: Для каждой поставляемой детали выдать номер детали, максимальный и минимальный объем поставки этой детали.

    Вот формулировка этого запроса без использования переменных с областью значений (равно как и разделов GROUP BY и HAVING):

    SELECT DISTINCT PZ AS P#, ( SELECT MAX(SP.QTY) FROM SP WHERE SP.P# = PZ ) AS MXQ, ( SELECT MIN(SP.QTY) FROM SP WHERE SP.P# = PZ ) AS MNQ FROM ( SELECT SP.P# AS PZ FROM SP ) AS POINTLESS ;

    Как и в предыдущем примере, в этой формулировке вводится переменная с областью значений POINTLESS, но логически она не требуется, поскольку на эту переменную отсутствуют ссылки.

    В завершение раздела заметим, что переменные с областью значений должны быть необязательными в SQL, поскольку

  • В реляционной алгебре не используются переменные с областью значений
  • Для каждого выражения реляционной алгебры имеется логический эквивалент на языке SQL, в котором не используются переменные с областью значений (за исключением тех, на которые отсутствуют ссылки и которые вводятся исключительно для удовлетворения синтаксических правил SQL)
  • SQL не расширяет реляционную функциональность реляционной алгебры.


    Поддержка Web


    Явление Internet вызывает существенные изменения в способах
    ведения бизнеса. В Сети все равны. Трудно узнать, является ли
    бизнес-партнер в Internet большой многонациональной корпорацией
    или лавочкой, расположенной в подвале. В этих условиях
    конкуренция должна основываться на доступности продуктов, уровне
    цен и качестве сервиса. DB2 v.5 и Oracle8 встречают появление
    новой культуры рынка, обеспечивая развитую поддержку
    Web-технологии. Пакет DB2 включает Net.Data, мощную поддержку
    языка Java и средства интероперабельности со многими программными
    средствами поддержки Internet производства как IBM, так и
    других компаний. Oracle также предлагает развитую поддержку Web,
    но не поддерживает хранимые процедуры и определенные
    пользователями функции, написанные на языке Java. Продукт Web
    Server, существующий со времени выпуска Oracle7, очень похож на
    Net.Data и обеспечивает сопоставимые возможности за счет
    использования брокера заявок web (web request broker). Net.Data и
    Oracle Web Server упрощают написание интерактивных Web-приложений
    путем расширения языка HTML средствами определения логики,
    переменных, вызовов программ и производства отчетов.
    Поддерживаются условная логика, HTML и подстановка переменных, а
    также VRML.


    Появляющиеся технологии


    Что же будет дальше в мире промежуточного ПО? Коротко говоря,
    Web, распределенные объекты, Web, Java и снова Web. Появление
    Web-технологии применительно и к Internet, и к intranet дало
    новую жизнь бизнесу промежуточного ПО. В то время, как компании
    начинают связывать свои базы данных и другие ресурсы с Web,
    производители промежуточного ПО получают удачную возможность
    создать продукты, облегчающие этот процесс. Ирония ситуации
    состоит в том, что использование браузера в качестве общей
    платформы приложений "клиент-сервер" и HTTP в качестве общего
    промежуточного ПО снижает интерес к промежуточному ПО на стороне
    клиента. Анализируя возможности Web-технологии, нужно понимать,
    что наибольшая выгода от промежуточного ПО может быть получена на
    стороне сервера.
    Популярные продукты промежуточного ПО, основанные на Web, можно
    разделить на две категории - серверные и клиентские. Серверные
    продукты обеспечивают связь между Web-сервером и сервером баз
    данных с передачей данных клиенту на основе использования HTTP и
    HTML. Часто встречается промежуточное ПО, поддерживающее и
    разработки приложений, обеспечивая, например, возможность
    отображения атрибутов базы данных на Web-страницы. Категория
    серверных Web-продуктов промежуточного ПО включает, в частности,
    WebDBC компании и Internet Database Connector (IDC), входящий теперь в состав
    Microsoft Internet Information Server. Обычно такие продукты
    легко устанавливаются и просто используются, обеспечивая
    Web-мастеров и разработчиков приложений визуальной средой
    разработки публикации данных из баз данных. На переднем крае
    можно найти такие продукты как ActiveWeb компании , программная коммуникационная система,
    дающая разработчикам доступ к приложениям, базам данных и
    браузерам, поддерживающим Java, для обмена информацией через Web.
    Конечно, и другие серверные продукты промежуточного ПО
    обеспечивают разработчикам простой доступ к серверам приложений и
    даже к унаследованным системам.
    Криком моды являются клиентские Web-продукты промежуточного ПО.

    Эти продукты позволяют разработчикам связывать с удаленными

    базами данных выполняемые на стороне клиента Java-апплеты и

    программные компоненты ActiveX. Среди первых на рынке появился

    продукт JETConnect компании XDB Systems Inc. JETConnect дает

    возможность разработчикам подключаться к удаленным серверам баз

    данных на основе использования входящей в состав продукта

    библиотеки классов. С появлением JDBC разработчики, применяющие

    Java, получили стандартный механизм, дающий те же возможности,

    что и JETConnect. Сегодня JDBC-драйверы имеются для большинства

    популярных баз данных. Возможности JDBC встраиваются в средства

    разработки; примером такого продукта является JBuilder компании

    . Во многих отношениях JDBC похож на

    ODBC, и те компании, которые создавали драйверы ODBC, найдут свою

    нишу на новом рынке драйверов JDBC. В некоторых отношениях мир

    Java будет выглядеть и функционировать очень похоже на то, что

    сегодня представляет собой мир традиционного двухзвенного

    клиент-серверного промежуточного ПО.

    Производители промежуточного ПО вносят свой вклад и в развитие

    технологии Web-разработок. Например, компания только что объявила о выпуске продукта

    Ambrosia, представляющего собой управляемую событиями систему для

    разработки бизнес-приложений в Internet. В системе используется

    собственная реализация Java с гарантированной доставкой

    сообщений, исчерпывающей безопасностью и транзакционными

    возможностями.


    Пользовательский интерфейс


    Пользовательский интерфейс JDBC дает возможность строить
    распределенные запросы в графической среде таким образом, что
    несколько запрашиваемых баз данных представляются как одна база
    данных. От пользователей не требуется знание схемы каждой
    подключаемой базы данных. JavaDQD анализирует метаданные этих баз
    данных и предоставляет пользователям информация об их схемах.
    Диалог подключения к базе данных дает возможность подключиться к
    локальным или удаленным базам данных и к временной базе данных.
    Для выполнения подключения требуется указать URL базы данных и,
    если это требуется, имя пользователя и пароль. В URL базы данных
    указываются драйвер JDBC, источник данных и порт базы данных. Для
    упрощения действий URL и имя пользователя могут быть сохранены в
    конфигурационном файле, загружаемым во время инициализации
    JavaDQD.
    Для формулировки запросов и манипулирования данными используется
    интерфейс в стиле QBE, при разработке которого использованы
    средства GUI Java и MCT (Microline Component Toolkit). Компоненты
    GUI и наличие в JDBS API возможности зондирования схемы базы
    данных дают возможность динамического построения QBE-подобного
    интерфейса после подключения к базе данных. Интерфейс дает
    возможность создания и уничтожения объектов базы данных, а также
    выборки, занесения, модификации и удаления строк таблиц.
    Интерфейс создания таблицы состоит из трех основных компонентов.
    Во-первых, выдается список всех текущих баз данных. Пользователь
    может выбрать базу данных, в которой будет создана новая таблица.
    Во-вторых, выдается текстовое поле для ввода имени новой таблицы.
    В-третьих, выдается решетка, в которой можно определить столбцы
    таблицы: имя столбца, поддерживаемый тип данных и длину столбца.
    Поддерживаемые типы данных определяются динамически путем
    зондирования схемы выбранной базы данных.
    Интерфейс выборки позволяет пользователям выбрать данные из
    распределенной базы данных. Эти данные затем показываются во
    фрейме результата. Интерфейс выборки показывает список доступных

    таблиц, из которых могут быть выбраны данные. Этот список

    включает все таблицы всех баз данных, к которым к этому времени

    существуют подключения. Для идентификации таблицы используется

    URL и имя таблицы. После выбора таблицы конструируется решетка

    выборки для указания критерия, которому должны соответствовать

    результирующие данные. Через строку view можно указать, какие

    столбцы должны содержаться в результате. Кроме того, можно ввести

    пример того, как должна выглядеть строка результата. Для задания

    условия на значения столбца можно использовать предикаты =, <, >,

    <=, >=, LIKE и <> и литеральные значения (строки символов и

    числа). Условия, задаваемые в одной строке рассматриваются как

    конъюнктивные; условия, задаваемые в разных строках, составляют

    дизъюнкцию конъюнктов. Наконец, если из числа возможных таблиц

    выбираются две или более таблицы, но на экране появляется строка

    соединения, позволяющая задать условие соединения.

    Отмечая удобство использования средств Java и JDBC для разработки

    интерфейсов для доступа к базам данных, авторы указывают на ряд

    ограничений, имеющихся в их реализации JavaDQD. В основном эти

    ограничения сводятся к некоторым особым требованиям, которым

    должны удовлетворять драйверы ODBC.


    Порождаемость, избыточность и согласованность


    В этом разделе Кодд начинает обсуждать некоторые вопросы, которые позже вошли в целостную часть реляционной модели. Отношение называется порождаемым, если и только если оно является выражаемым в смысле предыдущего раздела. (Заметим, что это определение порождаемости не является точно тем же, которое я защищал выше, поскольку -- по крайней мере, неявно -- под него подпадают и базовые отношения.) Набор отношений называется строго избыточным, если включает по крайней мере одно отношение, порождаемое (в смысле Кодда) из других отношений этого набора.
    В статье 1970-го г. это определение слегка улучшено: Набор отношений называется строго избыточным, если включает по крайней мере одно отношение, некоторая проекция которого -- возможно, тождественная проекция, т.е. проекция на все атрибуты -- порождаема из других отношений этого набора. (Я взял на себя смелость несколько упростить определение Кодда, хотя, конечно, старался сохранить его исходный смысл.)
    Затем Кодд приводит наблюдение, что именованные отношения, вероятно, будут строго избыточны в этом смысле, потому что они, вероятно, будут включать как базовые отношения, так и представления, порождаемые из этих базовых отношений. (На самом деле, в статье говорится, что "[такая избыточность] может служить для улучшения доступности определенных видов информации, для которой существует большой спрос"; это один из способов сказать, что представления обеспечивают полезную сокращенную запись.)
    Однако хранимые отношения обычно не будут строго избыточны. Кодд развивает эту мысль в статье 1970-го г.: "Если ... строгая избыточность в именованном наборе прямо отражается ... на хранимом наборе ... то, вообще говоря, расходуются дополнительные пространство памяти и время обновления, [хотя может также достигаться] сокращение времени выполнения некоторых запросов и загрузки центральных процессоров."
    Лично я сказал бы, что базовые отношения определенно не должны быть строго избыточными, но хранимые отношения могут быть таковыми (в зависимости -- как всегда на уровне хранения -- от соображений эффективности).


    Повышение эффективности модели


    Можно произвести много изменений моделей для повышения их эффективности, и общие рассуждения следует основывать на некоторых общих принципах:
    Все СУБД функционируют на основе файлов. В случае реляционных СУБД файлы представляют таблицы, содержащие данные. Для приложения каждый файл или таблица, который СУБД должна содержать открытым или для которого требуется поддерживать указатель, составляет дополнительный накладной расход. Следовательно, чем меньше таблиц, тем выше эффективность. Все данные, выбираемые СУБД, должны обрабатываться в том порядке, который соответствует плану обработки. В зависимости от сложности физической структуры, которая должна обрабатываться, может потребоваться перемещение данных в разные компоненты СУБД. Другими словами, при наличии сложных и неэффективных структур данных СУБД приходится выполнять более сложные действия, вовлекающие большой объем ввода/вывода и снижающие пропускную способность.
    Полностью функциональные СУБД обладают автоматизированными механизмами восстановления единиц работы. Большая их часть основывается на использовании журнализации единиц работы. Хороший проект модели существенно влияет на размер связанных наборов данных, вовлекаемых в единицы работы. Чем больше и сложнее единицы работы, тем дольше длятся журнализация и восстановление.
    СУБД подобны мотору: чем лучше качество горючего, тем выше эффективность. Некоторые производители настраивают свои СУБД с целью частичного или полного распознавания последовательного ввода, чтобы использовать возможность упреждающего чтения блоков. Устранение непоследовательных, низкокачественных данных поможет серверу работать более эффективно.


    Практическая схема специальных значений


    Во введении я выражал желание увидеть схему с двузначной логикой
    и значениями по умолчанию, понятность и простота которой
    уравновешивала бы уменьшение выразительной мощности. Поскольку
    Дейт не дал нам такую схему, я кратко обрисую ее сам.
    Прежде всего, я согласен с Дейтом в том, что по возможности нам
    стоит устранить в своих базах данных атрибуты, допускающие
    неопределенные значения. С некоторыми оговорками (которые здесь
    не буду разъяснять) я согласен и с тем, что хорошим подходом
    является расщепление типа сущности с подобным атрибутом на два
    подтипа. В первом подтипе атрибут не сможет содержать
    неопределенные значения, а во втором не будет самого этого
    атрибута.
    Во-вторых, я полагаю, что для идентификации специальных значений
    следует зарезервировать одно или несколько значений из обычного
    домена атрибута. Все что требуется, это одно значение, которое
    означает, что "реальное значение отсутствует". Возможно,
    потребуется различать случаи неприменимости, неизвестности и "то
    или другое, не знаю точно что". В ответ на часто используемый
    Дейтом аргумент, что имеется произвольное число различных типов
    неопределенных значений и, следовательно, потребуется MVL с
    произвольным числом истинностных значений, я заметил бы, что мне
    кажется наивным полагать необходимость наличия формально
    отличаемого вида неопределенных значений для каждого способа
    формулировки условия отсутствия значения на естественном языке. В
    книге Atzeni и DeAntonellis "Relational Database Theory"
    (Benjamin/Cummings, 1993) показано, что любое такое условие можно
    свести к одному из упомянутых выше.
    При возможности, следует ввести бизнес-правила, гарантирующие,
    что выбираемое значение не будет омонимом (т.е. не будет
    использоваться в разном смысле). Например, если на предприятии
    действует правило, что размер счета не может быть нулевым, то
    можно использовать нули в атрибуте размера счета для индикации
    отсутствия реального значения.
    Однако иногда это невозможно.
    Если на предприятии допускаются

    счета нулевого размера, то наличие в столбце значения

    "$000,000,00" будет означать a) счет нулевого размера и b)

    "реальное значение отсутствует". Чтобы разобраться с подобными

    омонимами, требуются дополнительные расходы. Выходом из положения

    является добавления флага, отличающего нулевые счета ото всех

    остальных, или использование в качестве специального значения

    менее критичного и очень редко используемого реального значения

    (например, "$999,999,98"). В последнем случае мы не устраняем

    расходы на различение омономов, но существенно их сокращаем. На

    самом деле, этот вид стратегии удешевленного использования

    омонимов использовался десятки лет.

    Наконец, заметим, что стратегия избежания омонимов с

    использованием некоторого значения для идентификации "отсутствия

    реального значения", не значащего ничего больше, предоставляет ту

    же выразительную мощность (и те же сложности), что схема Дейта со

    специальными значениями. Собственно, стратегия состоит в том,

    чтобы найти представление UNK внутри обычного домена, а не

    заставлять производителей СУБД расширять этот домен.

    Новая схема Дейта является альтернативой MVL с неправильно

    определенной операцией сравнения по равенству, полным отсутствием

    операций сравнения на больше и меньше, невозможностью получать

    полную информацию из базы данных и существенным усложнением

    написания даже простых запросов. Более того, теперь, когда мы

    понимаем, как далека схема Дейта от реализации, видно, что наши

    дебаты не имеют непосредственного отношения к практической

    разработке и использованию баз данных. И проектировщики, и

    пользователи будут продолжать работать при наличии ограничений,

    свойственных применяемым диалектам SQL.

    Консерваторы будут избегать использовать неопределенные значения

    и MVL, осмотрительно остерегаясь сложности. Чтобы им помочь, я

    кратко изложил практический подход к управлению отсутствующей

    информации, который может быть использован при наличии

    сегодняшних продуктов баз данных. Этот подход не претендует на

    оригинальность и лишь немного расширяет существующую практику.

    Более рисковые пользователи будут использовать неопределенные

    значения и, возможно, иногда им придется обжигаться. Но

    постепенно у них составится понимание сути неопределенных

    значений и MVL, которое невозможно получить при чтении книг.


    Приложения


    Пользователи будут переходить к ОРСУБД, если их собственным или разработанным сторонними поставщиками приложениям потребуются объектные расширения. ОРСУБД приняты в ряде важных прикладных областей, но в их число не входят области, обеспечивающие хлеб для РСУБД.
    Success Story. Области, в которых у ОРСУБД дела обстоят хорошо, включают управление графической, аудио, видео, текстовой информацией, временными рядами, геопростраственными данными, а также Web-приложения. Для управления медиа-информацией требуется применение идейно простых методов к неструктурированным данным. В отличие от этого, управление временными рядами и геопространственными данными требует наличия относительно сложных структур данных и применения аналитических методов. Web-приложения занимают промежуточную позицию, основываясь на неструктурированных данных для представления шаблонов динамических страниц и усложненных методах управления переменными, логикой страниц и запросами к базам данных. Принятие для использования расширяемого языка разметки (eXtensible Markup Language - XML) поможет добиться большей структуризации шаблонов Web-страниц и других документов.
    До появления ОРСУБД управление временными рядами, текстовыми и геопространственными данными обычно проиводилось с помощью специализированного программного обеспечения с нестандартизованными интерфейсами и языками запросов. Медиа-данные (и часто тексты) хранились в файловых системах и индексировались с помощью специальных средств. ОРСУБД привнесли во все эти области возможности, которые дают возможность манипулировать данными с помощью стандартного языка, интегирующего запросы к обычным и экзотическим данным.
    OLAP и хранилища данных (datawarehousing). OLAP (On-Line Analitycal Processing) - это интерактивный, исследовательский анализ данных, основанный на выделении нужных слоев многомерных кубов и агрегировании по измерениям. Развитые OLAP-системы позволяют связывать индивидуальные значения с агрегатами и с другими значениями. Для этих систем важно то, что можно делать с данными, а не как они хранятся.
    Можно хранить кубы в специализированной многомерной базе данных или с помощью РСУБД. В последнем случае многомерное представление достигается с помощью реляционных OLAP-систем (ROLAP).

    У каждого поставщика ОРСУБД имеются OLAP-средства. Компания IBM интегрирует продукт Essbase компании с DB2 и обеспечивает использование своего продукта Visual Warehouse в продуктах компании . Informix продает средство Metacube ROLAP, которое основано на технологии, полученной от Stanford Technology Group. Oracle предлагает Express Server (купленный у компании , в просторечии IRI Software), история которого восходит к 1970 г. Однако перспективы встраивания функций OLAP в ОРСУБД кажутся отдаленными. Расширения собственных аналитических возможностей СУБД выглядят, в лучшем случае, неоднородными. К хорошим примерам относятся продукты SQL Expander для DB2 компании , обеспечивающий ряд аналитических функций для обычных данных DB2, и S-Plus DataBlade компании , предоставляющий возможности статистического анализа, моделирования и визуализации.

    Возможно, поставщики не имеют стимула, полагая, что их текущие реляционные и многомерные СУБД хорошо обслуживают приложения. Но имеются и технические проблемы, такие как написание эффективного кода для управления большими разреженными многомерными массивамм данных с множественными иерархиями и потребность в единообразных, быстрых, не ограниченных одним измерением вычислениях. Аналогичные трудности сохраняются для хранилищ данных, которые обычно основываются на многомерных моделях данных, реализуемых звездообразными схемами (или вариантами "снежинка" и "создездие"). В реализациях используются битовые индексы, доступные в традиционных СУБД. (Джерри Додж и Тим Горман (Gary Dorge and Tim Gorman, Oracle8 Data Warehousing, John Wiley & Sons, 1998) утверждают, что они осветили все возможности Oracle7 и Oracle8, но во всей книге не разу не упомянута поддержка объектов в Oracle8.)


    Проблемы моделирования


    На сегодня ОРСУБД добились наибольшего успеха в областях
    управления мультимедийными объектами и сложными данными, такими
    как геопространственные данные и временные ряды финансовых
    приложений. Системы часто используются в 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 не предлагает ОРСУБД. Стратегия компании, воплощенная в 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, и не требует дополнительных комментариев.


    Размышления о будущем


    Все возможности, описанные в этой статье были доступны в 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) в файлах, содержащих операторы определения данных.


    Статья 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.:


    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


    C.J. Date
    Оригинал статьи можно найти по адресу
    Воспоминания об исходных статьях Кодда и размышления об эволюции реляционной модели в сегодняшних лидирующих системах баз данных.
    It was thirty years ago today / Dr. Edgar showed the world the way ...
    - с извинениями перед Ленноном и МакКартни
    Прошу прощения за поэтическое заимствование, но около тридцати лет тому назад доктор Эдгар Ф. Кодд (Edgar F. Codd) начал работать над тем, что стало Реляционной Моделью Данных. В 1969 г. он опубликовал первую статью в блестящей серии оригинальных статей, описывающих эту работу - статей, которые сделали мир таким, как мы его знаем. Конечно, за это время многие люди внесли свой вклад (иногда весьма значительный) в исследования баз данных вообще и исследования реляционных баз данных в частности; однако ни одна из этих последовавших работ не была настолько существенна или фундаментальна, как исходная работа Кодда. Я уверен, что и через сотни лет системы баз данных будут основываться на реляционном фундаменте Кодда.


    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 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".

    Попытка Дейта убедить нас в том, что в реальном мире не

    используется трехзначная логика, опровергается наличием

    повседневных соображений такого рода. И снова Дейт

    проиллюстрировал истинность моего приведенного выше высказывания.


    В 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 г. Кодд говорил об идее представлений как "законсервированных запросов".

    "Решения, связанные с тем, какие отношения принадлежат к именованному набору, основываются ... на логических нуждах сообщества пользователей, и, в частности, в потребности возрастающих инвестиций в программы, использующие именованные отношения, по причине предыдущего членства ... в именованном наборе." Здесь Кодд говорит о том, что представления являются механизмом для обеспечения логической независимости данных -- механизмом, который, в частности, гарантирует продолжение возможности выполнять программы при развитии базы данных. И он продолжает: "С другой стороны, решения, связанные с тем, какие отношения принадлежат хранимому набору, основываются ... на ... требованиях к производительности ... и изменениях, возникающих в этих [требованиях]." Здесь Кодд проводит очень четкую грань между логическим и физическим уровнями.


    Зависимости данных в существующих системах


    Как уже отмечалось, статья 1970-го г. в гораздо большей степени касается вопроса независимости данных, чем ее предшественница 1969-го г. В аннотации Кодд говорит: "Пользователи больших банков данных должны быть избавлены от потребности знаний о том, как данные организованы в машине. На действия пользователей с терминалов и большинство прикладных программ не должно оказывать влияние изменение внутренних представлений данных". Другими словами, мы хотим иметь физическую независимость данных. Он продолжает: "[На такие действия и программы также не должно оказываться влияние] даже при изменении некоторых аспектов внешнего представления". Другими словами, мы хотим иметь и логическую независимость данных.
    Кодд рассматривает различные примеры отсутствия независимости данных в существовавших в то время системах баз данных; он также обсуждает зависимости, связанные с упорядочиванием, индексацией и путями доступа. Потом он приводит один пример, иллюстрирующий такие зависимости в системах, которые обеспечивают "древовидные или немного более общесетевые модели данных" (другими словами, иерархические системы, такие как IMS, и сетевые системы, такие как IDS). Замечание: IDS была предшественником более известной системы IDMS; Кодд писал статью до того, как IDMS появилась на сцене.
    Это говорит о том, как далеко мы ушли! С точки зрения пользователей решением проблемы зависимости от упорядочивания (в терминах SQL) является раздел ORDER BY; пользователи не ограничены предопределенным упорядочиванием, а в состоянии потребовать в динамике любое желательное упорядочивание. И если пользователи требуют упорядочивания, не отражаемого напрямую в хранимом варианте данных, то система должна быть в состоянии динамически сортировать или индексировать данные.
    Аналогично, решение проблемы независимости от индексации состоит в том, чтобы исключит ссылки на индексы из приложений. Вместо этого приложения должны запрашивать доступ к данным через любой предпочтительный метод, и компонент системы -- который теперь мы назвали бы оптимизатором -- берет на себя ответственность за решения использовать индексы, чтобы ответить за это требование доступа.
    Отдельные операции CREATE и DROP INDEX доступны для использование в любое время в независимости от существования приложений и их логических требований к данным.

    Подобно этому, решение проблемы зависимости от путей доступа заключается в том, чтобы исключить все пути доступа из пользовательского представления данных (как делается в реляционных системах, но не в системах типа IMS и IDS). Современных читателей может озадачить проводимое Коддом различие между зависимостями от индексации и от путей доступа; в конце концов, индекс - это всего лишь специальный случай пути доступа. Однако вот что имел в виду Кодд: данные, которые пользователь видит в иерархической или сетевой системе, включают некоторые конструкции (иногда зазываемые связями - links), которые -- неважно, что говорят их защитники -- на самом деле, были действительно путями доступа. Эти пути неизменно служили и путями физического доступа. Например, если такой "логический" путь доступа удалялся, то некоторые приложения могли бы перестать работать.


    

        Базы данных: Разработка - Управление - Excel