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
Оригинал статьи можно найти по адресу

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

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

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

ACM SIGMOD Record

Volume 27, , March 1998
Volume 27, , 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.

C.J. Date

, September 1998
Оригинал статьи можно найти по адресу

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

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

Проектирование баз данных. Несколько компаний сделало шаги по направлению к объектно-реляционному подходу. Компания недавно поглотила компанию 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), является единственным известным автору пакетом средств разработки приложений, поставляемый независимым производителем и способным работать с ОРСУБД.

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

Распределенные объектные вычисления, развитие которых стимулировалось взрывообразным ростом Internet, являются превалирующей тенденцией середины и конца 90-х: настоящая следующая большая волна. Сегодняшние сражения происходят не в связи с настольными операционными системами или офисным программным обеспечением (до следующей смены парадигмы лидером в этих областях останется Microsoft), не в связи с браузерами или СУБД. Реальные баталии ведутся по поводу объектных моделей: COM против JavaBeans против CORBA/IIOP (если еще не слишком поздно).

Потенциально ОРСУБД могут играть роль центра в распределенной сети объектов. При наличии в ОРСУБД надежного управления транзакциями, масштабируемости, интерфейсов CORBA, COM, Java RMI и Beans, эти системы могут служить естественным выбором для поддержки брокеров объектных заявок и управления неоднородными распределенными транзакциями. Имеются признаки того, что IBM и Informix развивают свои СУБД для обеспечения этих сервисов. Это особенно критично для компании Informix, которой нужно дождаться развития рынка приложений ОРСУБД. Следует ожидать интересных результатов.

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

Говорят, что тип данных инкапсулирован, если экземпляры этого типа не имеют видимых пользователям компонентов. (Термин "экземпляр" используется как удобное, хотя и неуклюжее сокращение для "значение или переменная".) Например, в своей книге 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) Но, по мнению автора, такая интерпретация термина приводит с перемешиванию модельных и реализационных вопросов. Пользователь не должен беспокоиться, у него не должно возникать поводов для беспокойства по поводу того, "упакованы ли вместе" код и данные. Убеждение автора состоит в том, что с точки зрения пользователя, т.е. с модельной точки зрения, инкапсуляция означает, что данные не содержат видимых пользователям компонентов и могут быть доступны только через посредство уместных операций.

Что реально ставится на карту

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

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

Если говорить по-простому, промежуточное ПО обеспечивает простой

для использования 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. Между объектной моделью приложения и

моделью базы данных устанавливаются мосты на основе "общей

метамодели".

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

моделирования имеют много общего с тремя основными ОРСУБД: они

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

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

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

Двадцать пять заповедей SQL

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

С уважением,

Две первые статьи

Как я уже отметил, первая статья Кодда "Derivability, Redundency, and Consistency of Relations Stored in Large Data Banks" была опубликована в 1969 г. К сожалению, эта статья являлась исследовательским отчетом IBM; поэтому к ней применялось Limited Distribution Notice, и ее не смогло увидеть столько людей, сколько должно было увидеть. (И правда, статья стала чем-то вроде предмета для коллекционирования.) Но на следующий год пересмотренный вариант этой первой статьи был напечатан в Communications of the ACM, и эта статья была гораздо более широко распространенной и получила гораздо большее внимание (по крайней мере, в академических кругах). Действительно, обычно считается, что эта версия 1970 г. "A Relational Model of Data for Large Shared Data Banks" положила начало всему направлению, хотя, возможно, это немного несправедливо по отношению к предшествовавшей статье. Эти две первые статьи Кодда являются необычными в одном отношении: они читаются и перечитываются спустя почти тридцать лет после публикации! Про сколько статей можно сказать то же самое? В то же время, необходимо сказать, что эти статьи не очень-то легко читать. Статьи изложены кратко и немного сухо, стиль изложения теоретический и академический, обозначения и примеры приводятся в математической манере. Я уверен, что буду прав, если скажу, что к сегодняшнему дню только незначительная часть профессионалов в области баз данных действительно читала эти статьи. Поэтому я подумал, что было бы интересно и полезно посвятить короткую серию статей тщательному и беспристрастному ретроспективному обзору и оценке первых двух статей Кодда.

Однако, когда я начал писать этот обзор, я пришел к выводу, что было бы лучше не ограничивать себя только первыми двумя статьями, а взглянуть на все ранние публикации Кодда, посвященные реляционным базам данных. В следующие несколько месяцев я планирую рассмотреть, кроме уже упомянутых, следующие важные статьи Кодда: "Relational Completeness of Data Base Sublanguages", "A Data Base Sublanguage Founded on the Relational Calculus", "Further Normalization of the Data Base Relational Model", "Interactive Support for Nonprogrammers: The Relational and Network Approaches" и "Extending the Relational Database Model to Capture More Meaning". Одно предварительное замечание. Я не собираюсь утверждать, что ранние статьи Кодда были абсолютно правильными вплоть до последней детали или что сам Кодд предвидел все последствия своих идей. Было бы удивительно, если бы все было именно так. Наличие небольших ошибок и некоторой степени путаницы является нормальным и естественным, когда крупное изобретение впервые видит свет; подумайте о телефоне, автомобиле или телевидении (или даже о самих компьютерах; вы помните предсказание, что трех компьютеров хватит, чтобы удовлетворить все вычислительные потребности Соединенных Штатов?). Как бы то ни было, в дальнейшем изложении я, конечно, буду применять принцип "уравновешенного взгляда в прошлое" ("20/20 hindsight"). Я действительно думаю, что интересно посмотреть, как развивались во времени некоторые аспекты реляционной модели.

Essential Modelling Options

Independent consultant, over the last 11 years has built and consulted on dozens of warehouses, using various databases.

Оригинал статьи можно найти по адресу

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

Когда меня спрашивают сегодня, какую позицию я занимаю в сражении между звезднообразной схемой и третьей нормальной формой (3NF), я упорно отвечаю: "ровно по середине". Некоторые полагают, что пригоден один из подходов, но на самом деле имеется место для каждого из них. Я прислушиваюсь к аргументам, читаю статьи и обзоры дискуссий, реализую разнообразные модели, но не думаю, что любой узкий выбор пригоден для всех ситуаций.

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

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

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

F: Против

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

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

F: За

Нормализованное представление вселенной является математической моделью, основанной на сущностях и их связях. Атрибуты каждой сущности описываются только один раз -- они соответствуют "ключу, ключу целиком и ничему, кроме ключа". Нормализация допускает задание творческих запросов, выходящих за рамки заранее предписанных измерений звездообразной схемы. Например, при использовании нормализованной модели можно увидеть, как связаны погодные условия с продажей определенных товаров или кредитоспособностью заказчика. При применении многомерной модели или средства оперативной аналитической обработки (On-Line Analytical Processing - OLAP) вы не можете просто добавить новую таблицу или источник данных. Вы должны либо денормализовать ее до таблицы фактов (представьте, какой объем дополнительной работы понадобится для этого), либо создать для нее новое измерение. Другим способом является добавление строк, что вызовет многократное увеличение таблицы против ее исходного размера. Вспомните, что во многих РСУБД понадобится согласовывать разделение и распределение дискового пространства. (См. вкладку "Как задать запрос вне звезды".)

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

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

Фундаментальный вклад Кодда

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

Таким образом Кодд привнес в область баз данных желанную и очень потребную ноту ясности и строгости. Более точно, он ввел не только конкретную реляционную модель, но идею моделей данных вообще. Он подчеркивал важность различия (к прискорбию, до сих пор многими не понятого) между моделью и реализацией. Он обнаружил потенциал в использовании идей логики предикатов как основы управления базами данных и определил реляционную алгебру и реляционное исчисление как базисные средства работы с данными в реляционной форме. В дополнение к этому, он определил (неформально) то, что, вероятно, было первым реляционным языком, - "Data Sublanguage ALPHA"; ввел понятие функциональной зависимости и определил три первые нормальные формы (1NF, 2NF, 3NF); определил ключевое понятие существенности.

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

Предположим, что простая база данных 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 не очень "осмысленны".

И, может быть, лучше было бы отказаться от этого термина

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

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.

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

История

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

В область усилий Васкевича входило желание Microsoft образовать исследовательскую группу баз данных. Вице-призидент Microsoft по исследовательской работе Рик Рашид (Rick Rashid) сотрудничал с Васкевичем в переманивании Дэвида Ломета из Digital's Cambridge Research Lab, чтобы начать работу исследовательской группы баз данных. Ломет поступил на работу в Microsoft Research в январе 1995 г. Тем самым, к настоящему времени возраст исследовательской группы баз данных составляет немногим более трех с половиной лет.

Один человек не составляет группу. Продолжались усилия по переманиванию. Сараджит Чаудхари, исследователь из HP Labs, присоединился к группе баз данных в феврале 1996 г. Пол Ларсон, профессор университета Ватерлоо, - в мае этого года. Вивек Нарасайа, который летом 1996 г. проходил интернатуру как дипломник Вашингтонского университете, официально вошел в состав группы в апреле 1997 г. Новичек группы Роджер Барга, получивший степень Ph.D. в Oregon Graduate Institute, присоединился к группе в декабре 1997 г.

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

Предположим, что у нас имеется многомерная модель для заказанных товаров (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 с базами данных.

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

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

Литература

Codd, E.F. "Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks." IBM Research Report RJ599, August 19, 1969. Codd, E.F. "A Relational Model of Data for Large Shared Data Banks." CACM 13, No 6, June 1970. Republished in Milestones of Research: Selected Papers 1958-1982. CACM 25th Anniversary Issue, CACM 26, No 1, January 1983. (Перевод на русский язык опубликован в журнале "СУБД", No 1, 1995, www.osp.ru/dbms/1995/01/source/codd.htm). Darwen, Hugh and C.J. Date. "The Third Manifesto." ACM SIGMOD Record 24, No 1, March 1995. (Перевод на русский язык опубликован в журнале "", No 1, 1996,). Darwen, Hugh. "Relational-Valued Arributes; or, Will the Real First Normal Form Please Stand Up?" in C.J. Date and Hugh Darwen, Relational Database Writings 1989-1991. Addison-Weslwy, 1992. Martin, James. "Semantic Disintegrity in Relational Operations". Fourth-Generation Languages Volume I: Principles . Prentice-Hall, 1985. Bell, Colin J. "A Relational Model for Information Retrieval and the Processing of Linguistic Data". IBM Research Report RC1705, November 3, 1996.

Date, C.J. An Introduction to Database Systems (6th edition). Addison-Wesley, 1995. (Имеется русский перевод под названием "Введение в системы баз данных".) Date, C.J. What's Wrong with SQL? Relational Database Writings 1985-1989. Addison-Wesley, 1990. Darwen, H. The Askew Wall: A Personal Perspective. Relational Database Writings 1989-1991. Addison-Wesley, 1992.

Все эти и другие книги Кристофера Дейта можно заказать в электронном магазине

Zdonik, S.B. and D. Maier. "Fundamentals of Object-Oriented Databases". Readings in Object-Oriented Database Systems. Morgan Kaufmann, 1990. Barry, D.K. The Object Database Handbook: How to Select, Implement, and Use Object-Oriented Databases. John Wiley & Sons, 1996. Date, C.J. and H. Darven. Foundations for Object/Relational Databases: The Third Manifesto. Addison-Wesley, 1998. Stonebraker, M. (with D. Moore). Object-Relational DBMSs: The Next Great Wave. Morgan Kaufmann, 1996.

Chaudhuri, S., Narasayya V. "An Efficient, Cost-Driven Index Selection Tool for Microsoft SQL Server". Proceedings of the 23rd VLDB Conference. Athens, Greece, 1997, pages 146-155. Chaudhuri S., Motwani R., Narasayya V. "Random Sampling for Histogram Constraction: How much is enough?" Proceedings of the ACM SIGMOD International Conference on Management of Data, 1998. Chaudhari S., Narasayya V. "AutoAdmin 'What-If' Index Analysis Utility". Proceedings of the ACM SIGMOD International Conference on Management of Data, 1998. CN98-wp Chaudhari S., Narasayya V. "Index Tuning Wizard for Microsoft SQL Server". Microsoft White Paper.

LT95 Lomet, D and Tuttle, M. Redo Recovery after System Crashes, VLDB Conference (Sept. 1995). Zurich, Switzerland, 457-468.

Lomet, D.B. Application Recovery: Advances toward an Elisive Goal. Workshop on High Performance Transaction Systems (HPTS97). Asilomar, CA (September, 1997).

Lomet, D.B. Persistent Applications Using Generalized Redo Recovery. International Conference on Data Engineering, Orlando, FL (Feb. 1998), 154-163. Lomet, D.B. and Weikum, G. Efficient Transparent Application Recovery in Client-Server Information Systems. ACM SIGMOD Conference, Seattle, WA (June 1998) (best paper award).

Логические ошибки

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

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

В конце этого обзора статьи Кодда 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 по условию <Week selection criteria>. Промежуточный результат (Spool) дублируется на всех AMP. Все AMP производят выборку из таблицы Stores по условию <Store selection criteria>. Выполняется соединение со Spool по фиктивному условию (). Spool дублируется на всех AMP. Все AMP производят выборку из таблицы Items по условию <Item selection condition>. Выполняется соединение со 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 для расширяемости баз данных

---

---