.
Способы реализации olap-систем Реализации olap
Исторически первой многомерной системой управления базами данных, по существу являющейся OLAP-реализацией считается система Express, разработанная в 1970 годукомпанией IRI (позднее права на продукт были приобретены корпорацией Oracle и превращён в OLAP-опцию для Oracle Database)[2]. Термин OLAP ввёл Эдгар Кодд в публикации в журнале Computerworld в 1993 году[3], в которой он предложил 12 принципов аналитической обработки, по аналогии с 12 правилами для реляционных баз данных, сформулированными им же десятилетием ранее, в качестве референтного продукта, удовлетворяющего предложенным принципам, Кодд указал систему Essbase компании Arbor (поглощённой в 1997 году компанией Hyperion, которую, в свою очередь, в 2007 году купила Oracle). Примечательно, что впоследствии публикация была изъята из архивов Computerworld из-за возможного конфликта интересов, так как Кодд позднее оказывал консультационные услуги для Arbor[4].
Другие известные OLAP-продукты: Microsoft Analysis Services (ранее называвшиеся OLAP Services, часть SQL Server), SAS OLAP Server, TM1, PowerPlay, SAP BW, MicroStrategy Ingelligence Server, Mondrian, Аналитический комплекс ПРОГНОЗ[5].
C точки зрения реализации делятся на «физический OLAP» и «виртуальный» (реляционный, англ. Relational OLAP, ROLAP). «Физический», в свою очередь, в зависимости от реализации подразделяется на многомерный (англ. Multidimensional OLAP, MOLAP) и гибридный — (англ. Hybrid OLAP, HOLAP).
В первом случае наличествует программа, на этапе предварительной загрузки данных в OLAP из источников выполняющая предварительный расчёт агрегатов (вычислений по нескольким исходным значениям, например «Итог за месяц»), которые затем сохраняются в специальную многомерную базу данных, обеспечивающую быстрое извлечение и экономичное хранение. Примеры таких продуктов — Microsoft Analysis Services, Oracle OLAP Option, Essbase, SAS OLAP Server, TM1, PowerPlay.
Hybrid OLAP является комбинацией. Сами данные хранятся в реляционной базе данных, а агрегаты — в многомерной.
В ROLAP-реализациях все данные хранятся и обрабатываются реляционных системах управления базами данных, а агрегаты могут не существовать вообще или создаваться по первому запросу в СУБД или кэше аналитического ПО. Примеры таких продуктов — SAP BW, Microstrategy Intelligence Server, Mondrian.
С точки зрения пользователя все варианты выглядят похожими по возможностям. Наибольшее применение OLAP находит в продуктах для финансового планирования, хранилищах данных, решениях класса Business Intelligence.
Типы OLAP. Преимущества и недостатки
Выбор способа хранения данных зависит от объема и структуры детальных данных, требований к скорости выполнения запросов и частоты обновления OLAP-кубов. В настоящее время применяются три способа хранения данных:
MOLAP (Multidimensional OLAP)
Детальные и агрегированные данные хранятся в многомерной базе данных. Хранение данных в многомерных структурах позволяет манипулировать данными как многомерным массивом, благодаря чему скорость вычисления агрегатных значений одинакова для любого из измерений. Однако в этом случае многомерная база данных оказывается избыточной, так как многомерные данные полностью содержат детальные реляционные данные.
Преимущества MOLAP.
Высокая производительность. Поиск и выборка данных осуществляется значительно быстрее, чем при многомерном концептуальном взгляде на реляционную базу данных.
Структура и интерфейсы наилучшим образом соответствуют структуре аналитических запросов.
Многомерные СУБД легко справляются с задачами включения в информационную модель разнообразных встроенных функций.
Недостатки MOLAP.
MOLAP могут работать только со своими собственными многомерными БД и основываются на патентованных технологиях для многомерных СУБД, поэтому являются наиболее дорогими. Эти системы обеспечивают полный цикл OLAP-обработки и либо включают в себя, помимо серверного компонента, собственный интегрированный клиентский интерфейс, либо используют для связи с пользователем внешние программы работы с электронными таблицами.
По сравнению с реляционными, очень неэффективно используют внешнюю память, обладают худшими по сравнению с реляционными БД механизмами транзакций.
Отсутствуют единые стандарты на интерфейс, языки описания и манипулирования данными.
Не поддерживают репликацию данных, часто используемую в качестве механизма загрузки.
ROLAP (Relational OLAP)
ROLAP-системы позволяют представлять данные, хранимые в классической реляционной базе, в многомерной форме или в плоских локальных таблицах на файл-сервере, обеспечивая преобразование информации в многомерную модель через промежуточный слой метаданных. Агрегаты хранятся в той же БД в специально созданных служебных таблицах. В этом случае гиперкуб эмулируется СУБД на логическом уровне.
Преимущества ROLAP.
Реляционные СУБД имеют реальный опыт работы с очень большими БД и развитые средства администрирования. При использовании ROLAP размер хранилища не является таким критичным параметром, как в случае MOLAP.
При оперативной аналитической обработке содержимого хранилища данных инструменты ROLAP позволяют производить анализ непосредственно над хранилищем (потому что в подавляющем большинстве случаев корпоративные хранилища данных реализуются средствами реляционных СУБД).
В случае переменной размерности задачи, когда изменения в структуру измерений приходится вносить достаточно часто, ROLAP системы с динамическим представлением размерности являются оптимальным решением, так как в них такие модификации не требуют физической реорганизации БД, как в случае MOLAP.
Системы ROLAP могут функционировать на гораздо менее мощных клиентских станциях, чем системы MOLAP, поскольку основная вычислительная нагрузка в них ложится на сервер, где выполняются сложные аналитические SQL-запросы, формируемые системой.
Реляционные СУБД обеспечивают значительно более высокий уровень защиты данных и хорошие возможности разграничения прав доступа.
Недостатки ROLAP.
Ограниченные возможности с точки зрения расчета значений функционального типа.
Меньшая производительность, чем у MOLAP. Для обеспечения сравнимой с MOLAP производительности реляционные системы требуют тщательной проработки схемы БД и специальной настройки индексов. Но в результате этих операций производительность хорошо настроенных реляционных систем при использовании схемы "звезда" сравнима с производительностью систем на основе многомерных БД.
HOLAP (Hybrid OLAP)
Детальные данные остаются в той же реляционной базе данных, где они изначально находились, а агрегатные данные хранятся в многомерной базе данных.
Эволюция доступа к источникам данных: ODBC, DAO, RDO, OLE DB, ADO
ODBC
Интерфейс ODBC (Open Database Connectivity) был разработан фирмой Microsoft как открытый интерфейс доступа к базам данных. Он предоставляет унифицированные средства взаимодействия прикладной программы, называемой клиентом (или приложением-клиентом), с сервером - базой данных.
Архитектура ODBC
Архитектура ODBC представлена четырьмя компонентами:
Приложение-клиент, выполняющее вызов функций ODBC.
Менеджер драйверов, загружающий и освобождающий ODBC-драйверы, которые требуются для приложений-клиентов. Менеджер драйверов обрабатывает вызовы ODBC-функций или передает их драйверу.
ODBC-драйвер, обрабатывающий вызовы SQL-функций, передавая SQL-серверу выполняемый SQL-оператор, а приложению-клиенту - результат выполнения вызванной функции.
Источник данных, определяемый как конкретная локальная или удаленная база данных.
Основное назначение менеджера драйверов - загрузка драйвера, соответствующего подключаемому источнику данных, и инкапсуляция взаимодействия с различными типами источников данных посредством применения различных ODBC-драйверов.
ODBC-драйверы, принимая вызовы функций, взаимодействуют с приложением-клиентом, выполняя следующие задачи:
управление коммуникационными протоколами между приложением-клиентом и источником данных;
управление запросами к СУБД;
выполнение передачи данных от приложения-клиента в СУБД и из базы данных в приложение-клиент;
возвращение приложению-клиенту стандартной информации о выполненном вызове ODBC-функции в виде кода возврата;
поддерживает работу с курсорами и управляет транзакциями.
Приложение-клиент одновременно может устанавливать соединения с несколькими различными источниками данных, используя разные ODBC-драйверы, а также несколько соединений с одним и тем же источником данных, используя один и тот же ODBC-драйвер.
Функции ODBC API
Все функции ODBC API условно можно разделить на четыре группы:
основные функции ODBC, обеспечивающие взаимодействие с источником данных;
функции установки (setup DLL);
функции инсталляции (installer DLL) ODBC и источников данных;
функции преобразования данных (translation DLL).
DAO
Data Access Objects (DAO) — технология доступа к данным компании Microsoft
Корпорация Microsoft разработала DAO для обеспечения доступа к базе данных JET, которую использует Access. DAO представляет собой структуру объекта, базирующегося на модели СОМ. Позднее корпорация Microsoft расширила эту структуру для поддержания связности ODBC. DAO значительно легче использовать, чем его предшественников, базирующихся на CLI. Однако ориентация DAO на JET сделала его не вполне оптимальным для соединений с такими источниками данных ODBC, как SQL Server. Около двух лет назад корпорация Microsoft предприняла попытку усовершенствовать DAO, выпустив ODBC-Direct, расширение DAO, базирующееся на ODBC. Но к тому времени разработчикам уже полюбились удаленные объекты данных, RDO (Remote Data Objects).
RDO
OLE DB
OLE DB представляет собой набор COM-интерфейсов (Component Object Model), которые предоставляют приложению-клиенту унифицированный доступ к различным источникам данных.
OLE DB - это метод доступа к любым данным через стандартные COM-интерфейсы, вне зависимости от типа данных и места их расположения. В качестве данных могут выступать базы данных, простые документы, таблицы Excel и любые другие источники данных. В отличие от доступа, предоставляемого посредством драйверов OBDC, OLE DB позволяет реализовывать доступ к источникам данных, как с применением языка SQL (к SQL-серверам), так и к любым другим произвольным источникам данных.
Средства, предоставляющие доступ к источнику данных с использованием технологии OLE DB, называются OLE DB провайдерами. Программы-клиенты, использующие для доступа OLE DB провайдеры, называются потребителями данных.
В том случае, если существует только ODBC-драйвер для доступа к конкретному источнику данных, то для применения технологии OLE DB можно использовать OLE DB провайдер, предназначенный для доступа к ODBC-источнику данных.
Так как архитектура OLE DB основана на COM, то механизм создания результирующих наборов состоит из последовательностей шагов типа: 1. создание объекта -> 2. запрос указателя на интерфейс созданного объекта -> 3. вызов метода интерфейса.
ADO
ADO (от англ. ActiveX Data Objects — «объекты данных ActiveX») — интерфейс программирования приложений для доступа к данным, разработанный компанией Microsoft (MS Access, MS SQL Server) и основанный на технологии компонентов ActiveX. ADO позволяет представлять данные из разнообразных источников (реляционных баз данных, текстовых файлов и т. д.) в объектно-ориентированном виде.
Объектная модель ADO состоит из следующих объектов высокого уровня и семейств объектов:
Connection (представляет подключение к удалённому источнику данных)
Recordset (представляет набор строк, полученный от источника данных)
Command (используется для выполнения команд и SQL-запросов с параметрами)
Record (может представлять одну запись объекта Recordset или же иерархическую структуру, состоящую из текстовых данных)
Stream (используется для чтения и записи потоковых данных, например, документов XML или двоичных объектов)
Errors (представляет ошибки)
Fields (представляет столбцы таблицы базы данных)
Parameters (представляет набор параметров SQL-инструкции)
Properties (представляет набор свойств объекта)
Компоненты ADO используются в языках высокого уровня, таких как VBScript в ASP, JScript в WSH, Visual Basic, Delphi.
Последней версией ADO является версия 2.8. В рамках платформы Microsoft .NET интерфейс ADO заменён ADO.NET.