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

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

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

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

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

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

Объект инкапсулирует данные и функции в замкнутом пакете. В объектной технологии функции обычно называютсяметодами. На рисунке 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, б). Основаниями для выбора одного из этих представлений могут быть только типы запросов со стороны пользователей.

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

б)

в)

г)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Статьи к прочтению:

Что такое Я-концепция и как ее можно изменить

Похожие статьи: