Объектно-ориентированные СУБД. Рассмотрим основные концепции объектно-ориентированного подхода.

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

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

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

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

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

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

Рис. 15. Схема строения объек­та с атрибутами и методами

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

Классы играют роль некого шаблона для определения набора подоб­ных объектов. Таким образом, объекты, которые имеют один и тот же набор атрибутов и отвечают на одни и те же сообщения, могут быть сгруппированы вместе с образованием класса. Атрибуты и связанные с ними методы определяются один раз для всего класса, а не отдельно для каждого объекта. Например, все объекты отделений компании описыва­ются единственным классом Branch. Объекты некоторого класса называются егоэкземп­лярами (instance). Каждый экземпляр обладает своими собственными значениями каждо­го из атрибутов, но совместно с другими экземплярами данного класса использует для этих атрибутов одни и те же имена и методы (рис. 16).

Рис. 16. Экземпляры класса, совместно ис­пользующие имена атрибутов и методы класса

Некоторые объекты могут иметь подобные, но не идентичные атрибуты и методы. Если степень такого подобия достаточно высока, то имеет смысл совместно использо­вать некоторые свойства (атрибуты и методы).Наследование (inheritance) позволяет определять один класс на основе более общего класса. Менее общие классы на­зываютсяподклассами, а более общие –суперклассами. Процесс образования су­перкласса называетсяобобщением (generalization), а процесс образования подклас­са –специализацией. По умолчанию подкласс наследует все свойства его суперклас­са и в дополнение к ним определяет свои собственные уникальные свойства. Однако, как мы вскоре увидим, подкласс также может переопределять унаследованные мето­ды. Все экземпляры подкласса являются также экземплярами суперкласса. Более того, согласно принципу подстановки, для любого метода и конструкции вместо эк­земпляра суперкласса всегда можно использовать экземпляр его подкласса.

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

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

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

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

Рассмотрим объектно-ориентированные системы управления базами данных (ООСУБД). ООСУБД появились сначала в инженерно-конструкторских приложениях и только недавно получили признание у разработчиков финансовых и телекоммуникаци­онных приложений. Хотя доля рынка ООСУБД все еще остается очень маленькой , тем не менее ООСУБД продолжают находить все новые области применения, например в World Wide Web. Действительно, по оценкам некоторых аналитиков, рынок ООСУБД ежегодно будет возрастать на 50%, что выше темпов роста всего рынка баз данных в целом.

Существует несколько определений ООБД. В частности, Ким предложил следующие определения для объектно-ориентированной модели данных (ООМД), объ­ектно-ориентированной базы данных (ООБД) и объектно-ориентированной СУБД (ООСУБД):

ООМД – логическая модель данных, которая учитывает семантику объектов, применяемую в объектно-ориентированном программировании;

ООДБ – перманентный, совместно используемый набор (коллекция) объектов, определенный средствами ООМД;

ООСУБД – система управления (менеджер) ООДБ.

Хошафян и Абноус предложили собственное определение объектно-ориентированной СУБД:

1. “Объектно-ориентированный подход” = “абстрактные типы данных” + “наследование” + “идентичность объектов”.

2. “Объектно-ориентированная СУБД” = “объектно-ориентированный подход” + “возможности базы данных”.

Ниже приводится еще одно определение ООСУБД, построенное посредством ука­зания ее обязательных компонентов:

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

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

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

4. “Объектно-ориентированная СУБД” = “объектно-ориентированная система” + “условия пунктов 1, 2 и 3”.

Существует несколько подходов для разработки ООСУБД, которые кратко могут быть определены следующим образом:

• Расширение существующего объектно-ориентированного языка програм­мирования возможностями работы с базой данных. В этом подходе тра­диционные функции базы данных добавляются в существующие объектно-ориентированные языки программирования, подобные Smalltalk, C++ или Java. Подобный подход используется в продукте GemStone, в котором расширяются возможности именно этих трех языков.

• Предоставление расширяемых объектно-ориентированных библиотек СУБД. В этом подходе также используется добавление традиционных функ­ций базы данных в существующий язык программирования. Однако вместо расширения функций самого языка здесь используются дополнительные библиотеки классов, поддерживающих объект­ные типы данных, транзакции, параллельность, безопасность и т.д. Именно этот подход используется в продуктах Ontos, Versant и ObjectStore.

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

• Разработка нового языка базы данных или модели данных. Это радикаль­ный подход, который начиная с нуля приводит к созданию совершенно нового языка баз данных и СУБД, обладающих объектно-ориентированными возможностями. Такой подход используется в системе SIM (Semantic Information Manager), которая основана на собственной се­мантической модели данных и обладает новыми языками определения и управления данным.

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

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

В настоящее время реляционные СУБД являются доминирующим типом систем управления базами данных, приблизительный ежегодный объем продажи которых со­ставляет 8–10 млрд. дол. США (или 25 млрд. дол. с учетом про­дажи инструментов для их разработки). Темпы роста объема продаж составляют до 25% в год. ООСУБД, которые рассматривались ранее, изначально нашли примене­ние в области инженерно-конструкторских работ и только недавно стали приобретать популярность в финансовых и телекоммуникационных приложениях. Хотя рынок ООСУБД все еще относительно мал (объем продаж за 1996 год составил около 150 млн. дол. США) и составляет лишь 3% от всего рынка баз данных (в 1997 году), тем не менее ООСУБД продолжают находить все новые области применения, например в среде World Wide Web. Некоторые аналитики оце­нивают темпы ежегодного прироста рынка ООСУБД на уровне 50%, что выше темпов роста для всего рынка баз данных в целом. Однако маловероятно, что в обозримом бу­дущем объемы продаж этих новых систем превзойдут объемы продаж реляционных СУБД, поскольку этот тип СУБД подходит для достаточно большого количе­ства компаний, инвестировавших в их развитие такие огромные средства и ресурсы, что любая замена становится практически невозможной.

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

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

Для систем с расширенной реляционной моделью данных используются самые разные термины. Сначала дляих описания применяли термин “расширенная реляционная СУБД” (Extended Relational DBMS – ERDBMS). Однако в последние годы ис­пользуется более информативный термин “объектно-реляционная СУБД”, или ООСУБД (Object-Relational DBMS – ORDBMS), в котором содержится указание на использо­вание в системе понятия “объект”. Наконец, совсем недавно стали использоваться тер­мины “универсальный сервер” (Universal Server), “универсальная СУБД”, или УСУБД (Universal DBMS). В этой главе будет использоваться термин “объектно-реляционная СУБД”, или ОРСУБД. Три ведущих фирмы в области разработки РСУБД, а именно “Oracle”, “Informix” и “IBM”, расширили свои системы до уровня ОРСУБД, хотя их функ­циональные возможности немного отличаются. Концепция ОРСУБД как комбина­ции ООСУБД и РСУБД, очень притягательна за счет применения всех тех богатей­ших знаний и опыта, которые были накоплены за время работы с РСУБД. Причем она настолько привлекательна, что некоторые аналитики предсказывают, что в неда­леком будущем рыночная доля ОРСУБД будет на 50% выше доли РСУБД.

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

Хранилища данных

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

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

Исходная концепция хранилища данных была предложена специалистами фирмы “IBM” в виде “информационного хранилища” и первоначально представлена ими как решение, обеспечивающее доступ к данным, накопленным в нереляционных системах. Предполагалось, что такое информационное хранилище позволит организациям использовать их архивы данных для эффективного решения бизнес-задач. Однако из-за чрезвычайной сложности и невысокой производительности подобных систем, соз­данных на начальных этапах, первые попытки создания информационных хранилищ в основном были отвергнуты. С тех пор к концепции хранилищ информации возвра­щались вновь и вновь, но только в последние годы потенциал технологии хранилищ данных стал рассматриваться как достаточно ценное и жизнеспособное решение. Наиболее упорным и удачливым сторонником технологии хранилищ данных оказал­ся Билл Инмон (Bill Inmon), который за активное продвижение этой концепции был удостоен почетного титула “отца – основателя хранилищ данных”.

Хранилище данных – предметно-ориентированный, интегрированный, привязанный ко времени и неизменяемый набор данных, предназначенный для под­держки принятия решений.

В определении Инмона указанные характери­стики данных понимаются следующим образом.

• Предметная ориентированность. Хранилище данных организовано вокруг основных предметов (или субъектов) организации (например, клиенты, това­ры и продажи), а не вокруг прикладных областей деятельности (выписка счета клиенту, контроль товарных запасов и продажа товаров). Это свойство отражает необходимость хранения данных, предназначенных для поддержки принятия решений, а не обычных оперативно-прикладных данных.

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

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

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

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

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

При успешной реализации хранилища данных в организации могут быть достиг­нуты определенные преимущества:

1. Потенциально высокая отдача от инвестиций. В случае применения данной технологии организации потребуется инвестировать значительные средства для того, чтобы гарантировать успешную реализацию проек­та. В зависимости от используемых технических решений необходимая сумма инве­стиций может варьироваться от 50 тыс. до 10 000 тыс. фунтов стерлингов. Однако по данным фирмы “International Data Corporation” (IDC), в 1996 году усредненная за 3 го­да прибыль на инвестированный капитал (ROI-прибыль – Return On Investment) в сфере хранилищ данных составила 401%, причем более 90% фирм, охваченных дан­ных исследованием, имели ROI-прибыль свыше 40%, половина фирм – свыше 160%, а четверть фирм – свыше 600%.

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

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

Технология OLAP

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

Оперативная аналитическая обработка (OLAP) –это динамический синтез, анализ и консолидация больших объемов многомерных данных.

Термин “OLAP” был предложен Коддом в 1993 году и определяет архитектуру, которая поддерживает сложные аналитические приложения. Большинство OLAP- приложений создается на основе специализированных многомерных СУБД или ММ СУБД (multi-dimensional DBMS) с ограниченным набором данных и настраиваемым пользовательским интерфейсом приложений. OLAP-архитектура предусматривает определенные уровни с четким разделением функций между приложением и СУБД. На основе этого разделения появилось новое поколение OLAP-инструментов, предос­тавляющих такие возможности, которые позволяют обычным СУБД конкурировать со специализированными технологиями ММ СУБД.

Рассмотрим нескольких альтернативных вариантов представления многомерных данных. Например, как лучше всего пред­ставить запрос типа: “Каким был общий доход от продаж объектов не­движимости в каждом городе в каждом квартале 1997 года?”. Соответствующие дан­ные можно разместить в реляционной таблице с тремя столбцами (рис. 17, а), однако они более естественно укладываются в двумерной матрице с раз­мерностями City (город) и Time (время) – в данном случае поквартально (рис. 17, б). Основаниями для выбора одного из этих представлений могут быть только типы запросов со стороны пользователей.

Если пользователь будет со­ставлять простые запросы типа: “Каким был доход, полученный в городе Глазго в первом квартале?” или другие подобные этому запросы, предназначенные для извле­чения единственного значения, то никакой потребности в создании и использовании многомерной базы данных нет. Однако если пользователь попробует составить запрос типа: “Каким был суммарный годовой доход для каждого города?” или “Каким был средний доход для каждого города?”, то для получения ответа потребуется извлечь большое количество значений и выполнить их обобщение.

a)

б)

в)

г)

Рис. 17. Представление многомерных данных

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

Рассмотрим теперь те же данные о доходах, но с учетом дополнительной размерности – а именно, типа недвижимости. В этом случае имеющиеся данные представляют общий доход, но в зависимости от типа объектов недвижимости (т.е. от размерности Ргорerty_Type, причем для простоты предположим, что это может быть только квартира (Flat) или дом (House)), города и времени (поквартально). В этом случае данные также могут быть размещены в таблице с четырьмя полями (рис. 17, в). Но более ес­тественно было бы разместить их в трехмерном кубе (рис. 17, г). В нем данные представлены в виде ячеек некоторого массива, где каждое значение дохода связано с размерностями Property_Type, City и Time. Отметим, что таблица в реляционной СУБД может представлять многомерные данные только в двух измерениях.

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

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

средний_доход_на_сотрудника = общий_доход / количество_сотрудников.

Время обработки многомерного запроса зависит от того количества ячеек, которые должны быть обработаны мгновенно. С ростом числа размерностей количество ячеек в кубе данных возрастает экспоненциально. Однако для большинства многомерных за­просов требуются только обобщенные данные высокого уровня. Следовательно, для соз­дания эффективной многомерной базы данных необходимо предварительно рассчитать (консолидировать) все логические промежуточные и основные итоговые значения, при­чем по всем размерностям. Такое предварительное обобщение может оказаться особен­но ценным, если типичные размерности имеют иерархическую структуру. Например, размерность времени может иерархически подразделяться на годы, кварталы, месяцы, недели и дни, а размерность географического расположения – на отделения компании, районы, города и страны. Наличие предопределенной иерархии внутри размерностей позволяет выполнять предварительное логическое обобщение и, наоборот, нисходящий (“drill-down”) логический анализ с переходом от значений годовых доходов к значени­ям квартальных доходов и дальше к значениям месячных доходов.

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

• Консолидация выполняет такие обобщающие операции, как простое суммирование значений (“свертка”) или расчет с использованием сложных выражений, включающих другие связанные данные. Например, показате­ли для отделений компании могут быть просто просуммированы с целью получения показателей для каждого города, а показатели для городов мо­гут быть “свернуты” до показателей по отдельным странам.

• Нисходящий анализ (“drill-down”). Операция, обратная консолидации, ко­торая включает отображение подробных сведений для рассматриваемых консолидированных данных.

• Разбиение с поворотом (slicing and dicing). Эта операция (которая также называется созданием сводной таблицы) позволяет получить представление данных с разных точек зрения. Например, один срез данных о доходах может отображать все сведения о доходах от продаж объектов недвижимо­сти указанного типа по каждому городу. Другой срез может представлять все данные о доходах отделений компании в каждом из городов. Разбиение с поворотом часто выполняется вдоль оси времени – с целью анализа тен­денций и поиска закономерностей.

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

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

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