Что такое OLAP-куб и принцип его настройки [Wiki]

Создавайте инновации для решения конкретных задач, экономьте средства и повышайте эффективность работы своей организации благодаря открытой и гибкой платформе облачных вычислений Microsoft Azure.

Начните воплощать свои идеи в жизнь с помощью продуктов и служб Azure

Объединение локальной, гибридной и многооблачной инфраструктуры

Azure Arc

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

Служба Azure OpenAI

Миграция и модернизация с использованием управляемых облачных баз данных Azure SQL

Azure SQL

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

Azure Synapse Analytics

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

Служба Azure OpenAI

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

Функции Azure

Создание, развертывание и масштабирование веб-приложений на полностью управляемой платформе

Служба приложений Azure

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

Функции Azure

Объединение локальной, гибридной и многооблачной инфраструктуры

Azure Arc

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

Azure Stack

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

Azure Sentinel

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

Azure IoT Edge

Защита оборудования и программного обеспечения Интернета вещей

Azure Sphere

Куб

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

  • Дата Заказа
  • Страна
  • Город
  • Название заказчика
  • Компания-доставщик
  • Название товара
  • Количество товара
  • Сумма заказа

Какие агрегатные данные мы можем получить на основе этого представления? Обычно это ответы на вопросы типа:

  • Какова суммарная стоимость заказов, сделанных клиентами из определенной страны?
  • Какова суммарная стоимость заказов, сделанных клиентами из определенной страны и доставленных определенной компанией?
  • Какова суммарная стоимость заказов, сделанных клиентами из определенной страны в заданном году и доставленных определенной компанией?

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

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

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

Если же нам захочется получить те же данные, но еще в разрезе годов, тогда появится еще одно изменение, т.е. набор данных станет трехмерным (условным тензором 3-го порядка или 3-х мерным «кубом»).

Очевидно, что максимальное количество измерений – это количество всех атрибутов (Дата, Страна, Заказчик и т.д.), описывающих наши агрегируемые данные (сумму заказов, количество товаров и т.п).

Так мы приходим к понятию многомерности и его воплощению – многомерному кубу. Такая таблица будет у нас называться «таблицей фактов». Измерения или Оси куба (dimensions) – это атрибуты, координаты которых – выражаются индивидуальными значениями этих атрибутов, присутствующих в таблице фактов. Т.е. например, если информация о заказах велась в системе с 2003 по 2010 год, то эта ось годов будет состоять из 8 соответствующих точек. Если заказы приходят из трех стран, то ось стран будет содержать 3 точки и т.д. Независимо от того, сколько стран заложено в справочнике Стран. Точки на оси называются ее «членами» (Members).

Сами агрегируемые данные в данном случае буду назваться «мерами» (Measure). Чтобы избежать путаницы с «измерениями», последние предпочтительней называть «осями». Набор мер образует еще одну ось «Меры» (Measures). В ней столько членов (точек), сколько мер (агрегируемых столбцов) в таблице фактов.

Члены измерений или осей могут быть объединены одной или несколькими иерархиями (hierarchy). Что такое иерархия, поясним на примере: города из заказов могут быть объединены в районы, районы в области, области страны, страны в континенты или другие образования. Т.е. налицо иерархическая структура – континент-страна-область-район-город – 5 уровней (Level). Для района данные агрегируются по всем городам, которые в него входят. Для области по всем районам, которые содержат все города и т.п. Зачем нужно несколько иерархий? Например, по оси с датой заказа мы можем хотеть группировать точки (т.е. дни) по иерархии Год-Месяц-День или по Год-Неделя-День: в обоих случаях по три уровня. Очевидно, что Неделя и Месяц по-разному группируют дни. Бывают также иерархии, количество уровней в которых не детерминировано и зависит от данных. Например, папки на компьютерном диске.

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

Перейдем к языку запросов в многомерных данных.

Язык SQL изначально был спроектирован не для программистов, а для аналитиков (и поэтому имеет синтаксис, напоминающий естественный язык). Но он со временем все больше усложнялся и теперь мало кто из аналитиков хорошо умеет им пользоваться, если умеет вообще. Он стал инструментом программистов. Язык запросов MDX, разработанный по слухам нашим бывшим соотечественником Мойшей (или Мошей) Посуманским (Mosha Pasumansky) в дебрях корпорации Майкрософт, тоже изначально должен был ориентирован на аналитиков, но его концепции и синтаксис (который отдаленно напоминает SQL, причем совершенно зря, т.к. это только путает), еще сложнее чем SQL. Тем не менее его основы все же понять несложно.

Мы рассмотрим его подробно потому что это единственный язык, который получил статус стандартного в рамках общего стандарта протокола XMLA, а во вторых потому что существует его open-source реализация в виде проекта Mondrian от компании Pentaho. Другие системы OLAP-анализа (например, Oracle OLAP Option) обычно используют свои расширения синтаксиса языка SQL, впрочем, декларируют поддержку и MDX.

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

В OLAP из многомерных кубов можно делать срезы – т.е. когда данные фильтруются по одной или нескольким осям, или проекции – когда по одному или нескольким осям куб «схлопывается», агрегируя данные. Например, наш первый пример с суммой заказов из стран – есть проекция куба на ось Страны. MDX запрос для этого случая будет выглядеть следующим образом:

select [Territory].[Cities by Countries].[All].Children on rowsfrom [invoices1]

Что здесь что?

Select – ключевое слово и в синтаксис входит исключительно для красоты.

[Territory] – это название оси. Все имена собственные в MDX пишутся в квадратных скобках.

[Cities by Countries] – это название иерархии. В нашем случае – это иерархия Страна-Город

[All] – это название члена оси на первом уровне иерархии (т.е. страны) All – это мета-член, объединяющий все члены оси. Такой мета-член есть в каждой оси. Например в оси годов есть «Все года» и т.п.

Children – это функция члена. У каждого члена есть несколько доступных функций. Таких как Parent. Level, Hierarchy, возвращающие соответственно предка, уровень в иерархии и саму иерархию, к которой относится в данном случае член. Children – возвращает набор членов-потомков данного члена. Т.е. в нашем случае – страны.

on rows – Указывает как расположить эти данные в итоговой таблице. В данном случае – в заголовке строк. Возможные значении здесь: on columns, on pages, on paragraphs и т.п. Возможно так же указание просто по индексам, начиная с 0.

from [invoices1] – это указание куба, из которого производится выборка.

Что если нам не нужны все страны, а нужно только пара конкретных? Для этого можно в запросе указать явно те страны которые нам нужны, а не выбирать все функцией Children.

select { [Territory].[Cities by Countries].[All].[Russia], [Territory].[Cities by Countries].[All].[Ukrain] } on rowsfrom [invoices1]

Фигурные скобки в данном случае – обявление набора (Set). Набор – это список, перечисление членов из одной оси.

Теперь напишем запрос для нашего второго примера – вывод в разрезе доставщика:

select [Territory].[Cities by Countries].[All].Children on rows [Shipper].Members on columnsfrom [invoices1]

Здесь добавилось:

[Shipper] – ось;

.Members – функция оси, которая возвращает все члены на ней. Такая же функция есть и у иерархии и у уровня. Т.к. в данной оси иерархия одна, то ее указание можно опустить, т.к. уровень и иерархии тоже один, то можно выводить все члены одним списком.

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

select [Territory.Cities by Countries].[All].Children on rows [Shipper].Members on columnsfrom [invoices1]where ([Date].[2007])

А где же тут фильтрация?

where – ключевое слово

[2007] – это один член иерархии [Date]. Полное имя с учетом всех терминов было бы таким: [Date.By months].[All dates].[2007], но т.к. имя этого члена в рамках оси уникально, то все промежуточные уточнения имени можно опустить.

Почему член даты в скобках? Круглые скобки – это кортеж (tuple). Кортеж – это один или несколько координат по различным осям. Например для фильтрации сразу по двум осям в круглых скобках мы перечислим два члена из разных измерений через запятую. Т. е. кортеж определяет «срез» куба (или «фильтрацию», если такая терминология ближе).

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

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

select crossjoin( [Territory].[Cities by Countries].[All].Children, [Date.By months].[All dates].Children ) on rows [Shipper].Members on columnsfrom [invoices1]where ([Date].[2007])

Crossjoin – это функция. Она возвращает набор (set) кортежей (да, набор может содержать кортежи!), полученный в результате декартового произведения двух наборов. Т.е. результирующий набор будет содержать все возможные сочетания Стран и Годов. Заголовки строк, таким образом, будут содержать пару значений: Страна-Год.

Вопрос, а где же указание какие числовые характеристики надо выводить? В данном случае используется мера по умолчанию, заданная для этого куба, т.е. Сумма заказа. Если мы хотим выводить другую меру, то мы вспоминаем, что меры – это члены измерения Measures. И действуем точно так же как и с остальными осями. Т.е. фильтрации запроса по одной из мер будет выводить именно эту меру в ячейках.

Вопрос: чем отличается фильтрация в where от фильтрации путем указания членов осей в on rows. Ответ: практически ничем. Просто в where указывается срез для тех осей, которые не участвуют в формировании заголовков. Т.е. одна и та же ось не может одновременно присутствовать и в on rows, и в where.

Вычисляемые члены

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

with member [Measures].[Part] as ‘[Territory].CurrentMember / [Territory].[Cities by Countries].[All]’, FORMAT_STRING=‘0.00%’select [Territory].[Cities by Countries].[All].Children on rowsfrom [invoices1]where [Measures].[Part]

Вычисление происходит в контексте ячейки, у которой известные все ее атрибуты-координаты. Соответствующие координаты (члены) могут быть получены функцией CurrentMember у каждой из осей куба. Здесь надо понимать, что выражение [Territory].CurrentMember / [Territory].[Cities by Countries].[All]’ не делит один член на другой, а делит соответствующие агрегированный данные срезов куба! Т.е. срез по текущей территории разделится на срез по всем территориям, т.е. суммарное значение всех заказов. FORMAT_STRING – задает формат вывода значений, т.е. %.

Другой пример вычисляемого члена, но уже по оси годов:

with member [Date].[2007 and 2006 difference] as ‘[Date].[2007] – [Date].[2006]’

Очевидно, что в отчете будет не единица, а разность соответствующих срезов, т.е. разность суммы заказов в эти два года.

Системы OLAP так или иначе базируются на какой-нибудь системе хранения и организации данных. Когда речь идет о РСУБД, то говорят о ROLAP (MOLAP и HOLAP оставим для самостоятельного изучения). ROLAP – OLAP на реляционной БД, т.е. описанная в виде обычных двумерных таблиц. Системы ROLAP преобразуют MDX запросы в SQL. Основная вычислительная проблема для БД – быстрая агрегация. Чтобы быстрее агрегировать, данные в БД как правило сильно денормализованы, т.е. хранятся не очень эффективно с точки зрения занимаемого места на диске и контроля целостности БД. Плюс дополнительно содержат вспомогательные таблицы, хранящие частично агрегированные данные. Поэтому для OLAP обычно создается отдельная схема БД, которая лишь частично повторяет структуру исходных транзакционных БД в части справочников.

Многие системы OLAP предлагают инструментарий интерактивной навигации по уже сформированному запросу (и соответственно выбранным данным). При этом используется так называемое «сверление» или «бурение» (drill). Более адекватным переводом на русский было бы слово «углубление». Но это дело вкуса., в некоторых средах закрепилось слово «дриллинг».

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

  • drill-down – фильтрация по одной из исходных осей отчета с выводом детальной информации по потомкам в рамках иерархии выбранного фильтрующего члена. Например, если имеется отчет по распределению заказов в разрезе Стран и Годов, то при щелчке на 2007-м году выведется отчет в разрезе тех же Стран и месяцев 2007 года.
  • drill-aside – фильтрация под одной или нескольким выбранным осям и снятие агрегации по одной или нескольким другим осям. Например, если имеется отчет по распределению заказов в разрезе Стран и Годов, то при щелчке на 2007-м году выведется другой отчет в разрезе, например, Стран и Поставщиков с фильтрацией по 2007 году.
  • drill-trough – снятие агрегации по всем осям и одновременная фильтрация по ним же – позволяет увидеть исходные данные из таблицы фактов, из которых получено значение в отчете. Т.е. при щелчке по значению ячейки выводится отчет со всеми заказами, которые дали эту сумму. Эдакое мгновенное бурение в самые «недра» куба.

На этом все. Теперь, если вы решили посвятить себя Business Intelligence и OLAP самое время приступать к чтению серьезной литературы.

OLAP на яблоках

Возьмём такую исходную таблицу (в терминологии ADVANTA – справочник):

Фрукт Количество
Яблоко 2
Груша 3
Апельсин 1
Яблоко 2
Груша 4
Апельсин 1
Яблоко 7
Груша 4
Апельсин 2

Первый этап преобразования – создать

показатель-запрос

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

Фрукт Количество
Яблоко 11
Груша 11
Апельсин 4

Усложним задачу. Предположим, что есть два разных проекта – проект Маши и проект Васи.

Проект Фрукт Количество
Маши Яблоко 2
Васи Груша 3
Маши Апельсин 1
Васи Яблоко 2
Маши Груша 4
Васи Апельсин 1
Маши Яблоко 7
Васи Груша 4
Маши Апельсин 2

Когда этот куб выстроится в виде OLAP-отчёта, получится:

Проект Фрукт Количество
Маши Яблоко 9
Груша 4
Апельсин 3
Васи Яблоко 2
Груша 7
Апельсин 1

Теперь представим, что измерений стало еще больше. Добавили критерий свежести.

Проект Фрукт Свежий Количество
Маши Яблоко да 2
Васи Груша да 3
Маши Апельсин нет 1
Васи Яблоко да 2
Маши Груша да 4
Васи Апельсин нет 1
Маши Яблоко да 7
Васи Груша да 4
Маши Апельсин нет 2
Маши Яблоко да 2
Васи Груша да 3
Маши Апельсин нет 1
Васи Яблоко да 2
Маши Груша да 4
Васи Апельсин да 1
Маши Яблоко нет 7
Васи Груша да 4
Маши Апельсин да 2

Но в OLAP-отчёте (или сводной таблице) просто появился еще один маркер “Свежесть”:

Проект Фрукт Свежий? Количество
Васи Апельсин да 1
нет 1
Груша да 14
Яблоко да 4
Маши Апельсин да 2
нет 4
Груша да 8
Яблоко да 11
нет 7

А можно показатели поменять местами…

Свежий? Фрукт Проект Количество
да Апельсин Васи 1
Маши 2
Груша Васи 14
Маши 8
Яблоко Васи 4
Маши 11
нет Апельсин Васи 1
Маши 4
Яблоко Маши 7

И так далее. Можно добавлять всё новые и новые измерения, по которым будет проводиться расчёт.
Измерений может быть не 2, как в обычной таблице, а не ограниченное количество:

Что такое OLAP и зачем нужны такие системы

OLAP — это online analytical processing, оно же — оперативный анализ данных. Давайте попробуем определить это понятие на человеческом языке.

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

Поэтому инженеры придумали системы, которые сами следят за всеми поставщиками данных и собирают всё, что надо знать менеджерам, в одном месте. Это и есть «анализ данных».

А почему «оперативный»? Допустим, вы управляете большим интернет-магазином и прямо сейчас тестируете на эффективность несколько рекламных кампаний. Из всех кампаний нужно отобрать самую эффективную и уже с ней работать дальше. Система обработки данных, конечно, позволит увидеть нужные цифры и принять правильные решения. Но данные из нее надо достать быстро — если построение отчета займет недели, то с такой задержкой хорошие решения принять нельзя.

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

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

Важные замечания

  • в тексте запроса не допускается использование констукций group by / order by – запрос из куба сохраняется в SQL базе как представление (view), в представлениях не допускается группировка и сортировка
  • запрос обязательно должен вернуть хотя бы одно числовое значение (int, float) поля – это ограничение накладывает движок куба в менеджерской. Куб требует наличие хотя бы одного факта и обязан считать итоги по факту, считать итоги по строковому полю невозможно
  • вложенные запросы некорректно обрабатываются при разборе запроса куба, решение  – собирать данные из таблиц через join и указывать нужные поля из общей выборки
  • в таблице GENERATEDPROPDATAS хранятся значения всех расширенных свойств для всех сущностей БД. Для ограничения типа сущности необходимо включать в запрос ссылку на справочник (OBJECTREFNO) и идентификатор свойства (RKTYPEIDENT)

Редакции платформы

Платформа Loginom предлагается в 5-ти редакциях:

Редакции платформыРисунок 2. Редакции платформы

Различия между редакциями связаны с кейсами использования и механизмами интеграции в корпоративную IT-среду.

Смотри также:

  • Официальный сайт производителя;

Статьи в разделе:

  • Сравнение редакций

Что такое OLAP?

Оперативная аналитическая обработка (OLAP) — это категория программного обеспечения, которая позволяет пользователям одновременно анализировать информацию из нескольких систем баз данных. Это технология, которая позволяет аналитикам извлекать и просматривать бизнес-данные с разных точек зрения.

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

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

В этом уроке вы узнаете

  • OLAP куб
  • Основные аналитические операции OLAP
  • Типы систем OLAP
  • ROLAP
  • MOLAP
  • Гибридный OLAP
  • Преимущества OLAP
  • Недостатки OLAP

Введение в объектную модель SQL DSO

Объекты SQL DSO представляют собой COM-серверы, предназначенные для управления объектами многомерных баз данных Microsoft SQL Server Analysis Services. С их помощью можно создавать многомерные базы данных, измерения, кубы и другие объекты, содержащиеся в таких базах данных.

DSO состоят из иерархически организованных групп объектов, соответствующих основным объектам многомерных баз данных. Иерархия этих объектов в основном соответствует той, что можно увидеть в левой части окна Analysis Manager (рис. 1).

Основным в объектной модели SQL DSO является объект DSO.Server, представляющий сервер Analysis Services. Он, в свою очередь, обладает свойством Databases — коллекцией объектов, представляющих многомерные базы данных, которыми управляет данный сервер. Каждый такой объект, в свою очередь, обладает коллекциями объектов, представляющих кубы различных типов, коллективные измерения, источники данных, роли.

С точки зрения DSO базы данных (объекты типа DSO.Database) и OLAP-кубы (объекты типа DSO.Cubes) обладают коллекциями MDStores, и создание баз данных, кубов, агрегатов производится путем добавления новых элементов в соответствующие коллекции.

Мы не будем подробно описывать объектную модель SQL DSO (найти ее подробное описание можно в Microsoft SQL Server Books On-Line), а рассмотрим несколько наиболее типичных задач, которые решаются с помощью этих объектов. Для этой цели мы воспользуемся Borland Delphi — пользователи Visual Basic смогут создать такие же примеры самостоятельно.

OLAP-куб:

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

Куб OLAP состоит из числовых фактов, называемых мерами, которые классифицируются по измерениям. OLAP Cube также называют гиперкубом .

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

Как это работает?

Хранилище данных будет извлекать информацию из нескольких источников данных и форматов, таких как текстовые файлы, таблицы Excel, мультимедийные файлы и т. Д.

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

OLAP и многомерный анализ данных

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

Поэтому OLAP позволяет строить гипотезы, выявлять причинно-следственные связи между разными параметрами, моделировать поведение системы при изменениях.

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

%D0%BA%D1%83%D0%B1.gifВот так выглядит многомерная модель данных. Источник

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

США Канада Мексика
Январь 20 000 4 000 2 000
Февраль 30 000 6 000 3 000
Март 50 000 10 000 5 000

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

OLAP-система собирает информацию из баз данных, ERP, CRM и других источников, а затем формирует многомерный массив данных. В общем виде структура OLAP выглядит так:

  1. Источники данных — реляционные или многомерные базы данных, хранилище данных.
  2. OLAP-сервер, управляющий многомерными массивами данных.
  3. Приложения, которые формируют отчеты, графики, диаграммы для пользователей.

Кто пользуется OLAP-системами

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

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

Или большие онлайн-магазины и ритейлеры. Наличие запасов на складе и показателей выручки важно знать здесь и сейчас — ведь даже за 10 минут торгового дня эти значения меняются очень быстро.

Думаю, на этих примерах вы мысленно примерили OLAP на свой бизнес. И уже поняли, насколько вам нужна такая система.

Недостатки OLAP

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