OLAP-системы

Types of OLAP Database Systems

OLAP systems vary quite a lot, and they have generally been distinguished by a letter onto the front of the acronym “OLAP,” for On-Line Analytical Processing.

MOLAP and ROLAP have classically been the most established types, and the other distinctions represent little more than the marketing programs on the part of the vendors to distinguish themselves, for example, SOLAP and DOLAP.

Here, we aim to give you an idea of what these distinctions have meant.

The New Direction in OLAP Technology:

The newest software in the OLAP and Business Intelligence world combines, in real-time, the benefits of both relational tables and multidimensional business data modeling.

 The latest technology removes the proprietary format of its MOLAP predecessors by living/saving in source relational tables, SQL Server.

If you the sound of that, check out Olation® from PARIS Tech, the sponsor of OLAP.com

Major OLAP Technology Types:

 Hybrid Transaction / Analytical Processing (HTAP)

Gartner coined the term HTAP in a paper in the beginning of 2014 to describe new in-memory data systems that do both online transaction processing (OLTP)  and online analytical processing (OLAP).

HTAP relies on newer and much more powerful, often distributed, processing: sometimes it involves a new hardware “appliance”, and it almost always requires a new software platform.

Beyond this, the key point seems to be that all the technology is sited in the relational database.

  And so, there’s no more data replication, and new transactional information becomes part of an analytical model in as fast a time as is technologically possible.

HTAP represents a new way to tie data together in a way that hasn’t been possible before– a real uniting of relational data stored in tables with the data models that are used for decision making by the business leaders.

For an example of an HTAP product, check out Olation® from PARIS Tech, the sponsor of OLAP.com. Olation can be categorized as an HTAP product — even the name Olation implies the combination of “OLAP” and “relational” technologies.

Multidimensional OLAP (MOLAP) – Cube based

MOLAP products enable end-users to model data in a multidimensional environment, rather than providing a multidimensional view of relational data, as ROLAP products do (see next tab).

Cubes modeled in a multidimensional database extend the concept associated with spreadsheets: just as a cell in a spreadsheet represents the intersection of two dimensions (sales of product by region), a cell in a cube represents the intersection of an infinite number of dimension members (e.

g., Products, Customers, Regions, Months …nth dimension). As in a spreadsheet, a cell might be calculated by formulas involving other cells.

In short, multidimensional databases allow users to add extra dimensions, rather than additional tables, as in a relational model. And the MOLAP cube structure allows for particularly fast, flexible data-modeling and calculations.

For one, locating cells is vastly simplified—an application can identify a cell location by name (at the intersection of dimension members) rather than by searching an index or the entire model (via SQL SELECT statements), as in a relational database.  Further, multidimensional models incorporate advanced array-processing techniques and algorithms for managing data and calculations.

As a result, multidimensional databases can store data very efficiently and process calculations in a fraction of the time required of relational-based products.

What are the perceived drawbacks of MOLAP tools?

For one, relevant data must be transferred from relational systems,which is aa potentially “redundant” re-creation of data in another (multidimensional) database.

Once data has been transferred, there may be no simple means for updating the MOLAP “engine” as individual transactions are recorded by the RDBMS. Also, MOLAP products are typically proprietary systems.

For a good example of a fast, scalable MOLAP product, check out PowerOLAP® from PARIS Tech, the sponsor of OLAP.com.

ROLAP products (for Relational OLAP) are credited with being able to directly access data stored in relational databases.

The notion is that they can readily retrieve transactional data, although this becomes suspect when very large data sets are in play, or if more complex calculations are to be delivered, the transactional data.

ROLAP products enable organizations to leverage their existing investments in RDBMS (relational database management system) software.

ROLAP products access a relational database by using SQL (structured query language), which is the standard language that is used to define and manipulate data in an RDBMS. Subsequent processing may occur in the RDBMS or within a mid-tier server, which accepts requests from clients, translates them into SQL statements, and passes them on to the RDBMS.

ROLAP products provide GUIs and generate SQL execution plans that typically remove end-users from the SQL writing process. However, this over-reliance on processing via SQL statements—including processing for multidimensional analysis—is a drawback.

Whether it is generated “transparently” or not, SQL is the language of relational tables: SQL’s vocabulary is limited and its grammar often inflexible, at least to accommodate the most sophisticated modeling required for multidimensional analyses.

One advantage of ROLAP over the other styles of OLAP analytic tools is that it is deemed to be more scalable in handling huge amounts of data. ROLAP sits on top of relational databases therefore enabling it to leverage several functionalities that a relational database is capable of.

HOLAP is the product of the attempt to incorporate the best features of MOLAP and ROLAP into a single architecture.

This kind of tool tries to bridge the technology gap of both products by enabling access to or use of both multidimensional database (MDDB) and Relational Database Management System (RDBMS) data stores.

HOLAP systems store larger quantities of detailed data in the relational tables while the aggregations are stored in the pre-calculated cubes. HOLAP also has the capacity to “drill through” from the cube down to the relational tables for delineated data.

Some of the advantages of this system are better scalability, quick data processing and flexibility in accessing of data sources. The issue with HOLAP systems lies precisely in the fact that they are hybrids: at best they partake of the strengths of other systems…but they also evince the weaknesses of each, in an attempted mashup of two distinct technologies.

Other Types:

There are also less popular kinds of OLAP technology that one might encounter every so often, listed below. Some of these self-designated product types do not really exist any longer.

(An example is WOLAP, since nearly all products provide a Web interface, to meet market demand.

) But they are included, to help provide a backgrounder in how vendors have tried to set themselves apart, and also how the OLAP market developed over time.

• DOLAP
• WOLAP
• Mobile OLAP
• SOLAP

 

Desktop OLAP, or “DOLAP,” is the idea that user can download a section of an OLAP model from another source, and work with that dataset locally, on their desktop. DOLAP is purportedly easier to deploy, with a potential lower cost, but almost by definition comes with a limited functionality in comparison with other OLAP applications.

Simply put, a WOLAP signifies a Web browser – based OLAP technology. And it suggests a technology that is Web-ly, without any kind of option for a local install or local client to access data.

 The most appealing features of this style of OLAP was (past tense intended, since few products categorize themselves this way) the considerably lower investment involved on the client side (“all that’s needed is a browser”) and enhanced accessibility to connect to the data.

Mobile OLAP is merely refers to OLAP functionalities on a wireless or mobile device. This enables users to access and work on OLAP data and applications remotely thorough the use of their mobile devices.

The aim of Spatial OLAP (thus, SOLAP) is to integrate the capabilities of both Geographic Information Systems (GIS) and OLAP into a unified solution, thus facilitating the management of both spatial and non-spatial data.

The driving idea is to provide quick exploration of data that can point to trends and analysis in a geographic context, whether place-names sourced from a GIS or overlaying maps that show, for example, customer purchase behavior.

Источник: https://olap.com/types-of-olap-systems/

Применение OLAP – систем

На данное время разработан довольно много аналитических систем, сконструированных с использованием OLAP-технологии (Нурегіоn OLAP, Elite OLAP, Oracle Express и много других). Рынок программных OLAP-продуктов постоянно расширяется.

Современные системы оперативной аналитической обработки дают пользователям возможность решать ключевые задачи управления бизнесом-процессом, в частности прикладные программы Нурегіоn OLAP разрешают выполнять анализ прибыльности; анализ направлений развития продукции; анализ продажи; анализ положения на рынке; анализ ассортимента продуктов; анализ риска; анализ конкурентоспособности; складывания отчетов из производительности; моделирования сценария; анализ бюджета и прогнозов и т.п.

Следует отметить, что в соответствии с современными взглядами на создание информационных систем OLAP-системы должны базироваться на специальной базе данных — ХД.

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

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

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

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

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

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

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

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

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

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

Пример.

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

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

Ниже перечислены наиболее важные сферы применения OLAP-технологий.

Продажи

Ключевой вопрос отдела сбыта любого предприятия: “Какое количество изделий продано?”, “На какую сумму реализовано?” расширяются по мере усложнения бизнеса и накопления исторических данных до некоторого множества факторов, или разрезов: регион поставок, .

в прошлом месяце, квартале, по сравнению с нынешним,. через канал сбыта А, по сравнению с каналом Б и т.д.

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

Закупки

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

Маркетинг

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

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

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

Движение денежных средств

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

Бюджет

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

Большинство бюджетных отчетов легко строятся на основе OLAP-систем.

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

Финансовая отчетность

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

Некоторые страны уже перешли на такую технологию сбора данных.

В некоторых отечественных контролирующих органах существуют планы перехода от ГОСТ-овских стандартов отчетов с многоэтажными шапками и алгоритмами типа “Итого, исключая строку 234 и включая строку 598 из отчета №987” к системе к сбору показателей и выпуску отчетов по OLAP-технологии.

Результаты социологических опросов

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

Объемы производства

Это еще один пример статистического анализа. Таким образом, можно анализировать объемы выращенного картофеля, выплавленной стали, сваренного пива и пр.

Потребление расходных материалов

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

Заработная плата

Анализ расходов на зарплату, сравнение расходов по специальностям, филиалам, людям, динамика фонда ЗП.

Текучесть кадров на предприятии

Анализ текучести кадров в отделе, цехе, филиале по предприятию в целом в разрезе профессий, уровня образования, пола, возраста, времени.

Пассажирские перевозки

Анализ количества проданных билетов и сумм в разрезе сезонов, направлений, видов вагонов (классов), типов поездов (самолетов).

Грузовые перевозки

Анализ объемов перевозок, платы в разрезе сезонов, направлений, видов вагонов, грузов, грузоотправителей, грузополучателей, станций отправления, станций получения.

Простои транспорта (вагонов, самолетов, пароходов, грузовиков)

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

Заболеваемость персонала (учащихся, трудящихся)

Измерения -категории сотрудников (граждан), регион, отдел, профессия, возраст, дата. Факт -количество дней в году, в течение которых люди были не-трудоспособны.

Выбор недвижимости (офисов, складов, квартир)

Измерения -обычные для этого рынка. Город, Район, Количество комнат, Расстояние до метро, Этаж, Тип дома, Дата и т.д. Фактов три -средняя цена, максимальная цена, минимальная цена. Манипулируя измерениями, покупатель может определиться со своими возможностями, а продавец проанализировать зависимости цен, динамику цен и назначить правильную цену.

Урожайности агрокультур

Измерения – Сорт, Регион, Почва, Удобрение, Средняя температура воздуха, уровень осадков, Год, другие факторы, влияющие на урожайность. Факт -количество центнеров с гектара. Анализ позволит выявить лучшие сорта для данного региона, лучшие удобрения для данной почвы и прочие зависимости.

Источник: http://itstan.ru/it-i-is/primenenie-olap-sistem.html

Системы OLAP – это что такое?

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

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

Типичными задачами, которые реализуют посредством OLAP систем являются:

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

Храниться и обрабатываться данные могут на локальных компьютерах или на специально отведенных серверах.

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

Источник: https://www.softservebs.com/solutions/sistema-otchetnosti/

Финансовая Академия при правительстве РФ

Кафедра «Информационных технологий»

Реферат на тему

«Olap – технологии»

Выполнил студент

группы ГМУ 1-1

Стефанов Олег

Оглавление

Оглавление 2

Olap – технологии 3

Что такое хранилище данных? 4

Типичная структура хранилищ данных 4

Таблица фактов 5

Таблицы измерений 5

Кубы 6

“Разрезание” куба 6

Метки 6

Иерархии и уровни 7

Архитектура OLAP приложений 7

Список использованных материалов 9

Olap – технологии

Согласно недавно проведенному опросу финансовых директоров, большинство из них (81%) считает, что сегодня наиболее важной задачей является достижение высокой точности прогнозирования доходов и поступлений. Примечательно, что при этом более половины из них (63%) не удовлетворены качеством своих систем бюджетирования и прогнозирования.

Чем объясняются подобные пессимистичные настроения работников финансовой сферы? Дело в том, что сегодня финансовые директора оказываются под постоянно растущим “давлением” – новые реалии бизнеса требуют более надежной, значимой и точной финансовой информации:

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

При этом, как выяснилось в результате еще одного опроса, две трети “мировых” и 90% “средних” компаний не уверены в точности и надежности своих прогнозов и отчетов. Возникает вопрос: почему? В качестве ответа необходимо рассмотреть два момента:

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

Все больше и больше исследований свидетельствуют о наличие проблем, связанные с использованием электронных таблиц. Другими словами, электронные системы, вероятно, далеко не самая лучшая система для финансовых отделов. Здесь логично задать вопрос: “Могут ли другие технологии заменить электронные таблицы, используемые в финансовом отделе?”

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

Термин OLAP – расшифровывается как OnLine Analytical Processing. То есть примерно можно перевести как “Обработка данных в реальном времени”. Это не упоминание какой то конкретной технологии или архитектуры, а как бы формулировка задачи.

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

Термин был введен в употребление в 1993 году Эдгаром Коддом, “отцом” реляционных СУБД (система управления базами данных). Он также сформулировал 12 правил OLAP1, которым должна удовлетворять OLAP система.

Они на экране.

Что такое хранилище данных?

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

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

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

Типичная структура хранилищ данных

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

Однако исходные данные для построения OLAP-кубов обычно хранятся в реляционных базах данных. Нередко это специализированные реляционные базы данных, называемые также хранилищами данных (Data Warehouse).

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

Типичная структура хранилища приведена на слайде.

Таблица фактов

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

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

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

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

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

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

Каждая таблица измерений должна находиться в отношении «один ко многим» с таблицей фактов. Пример на экране.

Кубы

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

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

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

“Разрезание” куба

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

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

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

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

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

Метки

Значения, “откладываемые” вдоль измерений, называются членами или метками (members).

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

Иерархии и уровни

Метки могут объединяться в иерархии, состоящие из одного или нескольких уровней (levels). Например, метки измерения “Магазин” (Store) естественно объединяются в иерархию с уровнями:

All (Мир)

Country (Страна)

State (Штат)

City (Город)

Store (Магазин).

В соответствии с уровнями иерархии вычисляются агрегатные значения, например объем продаж для USA (уровень “Country”) или для штата California (уровень “State”). В одном измерении можно реализовать более одной иерархии – скажем, для времени: {Год, Квартал, Месяц, День} и {Год, Неделя, День}.

Отметим, что иерархии могут быть сбалансированными (balanced), плюс иерархии, основанные на данных типа “дата—время”, и несбалансированными (unbalanced). Типичный пример несбалансированной иерархии — иерархия типа “начальник—подчиненный”.

Существуют также иерархии, занимающие промежуточное положение между сбалансированными и несбалансированными (они обозначаются термином ragged — “неровный”).

Обычно они содержат такие члены, логические “родители” которых находятся не на непосредственно вышестоящем уровне (например, в географической иерархии есть уровни Country, City и State, но при этом в наборе данных имеются страны, не имеющие штатов или регионов между уровнями Country и City.

Архитектура OLAP приложений

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

Многомерность в OLAP-приложениях может быть разделена на три уровня:

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

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

.

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

Если для нас являются критичными вопросы быстродействия, мы можем выбрать MOLAP, если мы не хотим забирать дополнительное место на диске за счет переноса детальных данных – можно выбрать ROLAP, если мы хотим взять лучшее из двух – то HOLAP.

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

Список использованных материалов

http://www.infology.ru/2008/06/03/447/

http://www.olap.ru/basic/OLAP_intro1.asp

http://corportal.ru/Articles/DataTech/OLAP/OLAPDI.aspx

http://www.olap.ru/home.asp?artId=92

http://www.tconto.ru/node/12

Источник: http://www.shkola.of.by/olap-tehnologii.html

Источник: https://businessizakon.ru/sistemy-olap-eto-chto-takoe.html

Ядро OLAP системы. Часть 1 — принципы построения

Механизм OLAP является на сегодня одним из популярных методов анализа данных. Есть два основных подхода к решению этой задачи.

Первый из них называется Multidimensional OLAP (MOLAP) – реализация механизма при помощи многомерной базы данных на стороне сервера, а второй Relational OLAP (ROLAP) – построение кубов “на лету” на основе SQL запросов к реляционной СУБД.

Каждый из этих подходов имеет свои плюсы и минусы. Их сравнительный анализ выходит за рамки этой статьи. Мы же опишем нашу реализацию ядра настольного ROLAP модуля.

Такая задача возникла после применения ROLAP системы, построенной на основе компонентов Decision Cube, входящих в состав Borland Delphi.

К сожалению, использование этого набора компонент показало низкую производительность на больших объемах данных.

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

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

Схема работы

Общую схему работы настольной OLAP системы можно представить следующим образом:

Алгоритм работы следующий:

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

Рассмотрим как подобная система может быть устроена внутри. Начнем мы это с той стороны, которую можно посмотреть и пощупать, то есть с отображений.

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

Кросс-таблица

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

Таким образом, таблицу можно разделить на следующие элементы, с которыми мы и будем работать в дальнейшем:

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

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

При этом нужно отметить то, что полученная матрица будет сильно разреженной, почему ее организация в виде двумерного массива (вариант, лежащий на поверхности) не только нерациональна, но, скорее всего, и невозможна в связи с большой размерностью этой матрицы, для хранения которой не хватит никакого объема оперативной памяти. Например, если наш куб содержит информацию о продажах за один год, и если в нем будет всего 3 измерения – Клиенты (250), Продукты (500) и Дата (365), то мы получим матрицу фактов следующих размеров:

Кол-во элементов = 250 х 500 х 365 = 45 625 000

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

Поэтому, для работы с этой матрицей нужно применить специальные механизмы работы с разреженными матрицами. Возможны различные варианты организации разреженной матрицы. Они довольно хорошо описаны в литературе по программированию, например, в первом томе классической книги “Искусство программирования” Дональда Кнута.

Рассмотрим теперь, как можно определить координаты факта, зная соответствующие ему измерения. Для этого рассмотрим подробнее структуру заголовка:

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

Подготовка данных

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

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

Тогда для их хранения можно предложить следующую структуру:

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

Библиотека компонентов CubeBase

Описанные выше идеи были положены в основу при создании библиотеки компонентов CubeBase.

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

Фактически, он является OLAP-машиной, осуществляющей преобразование плоской таблицы в многомерный набор данных. Компонент TCubeGrid выполняет вывод на экран кросс-таблицы и управление отображением гиперкуба.

TСubeChart позволяет увидеть гиперкуб в виде графиков, а компонент TСubePivote управляет работой ядра куба.

Сравнение производительности

Данный набор компонент показал намного более высокое быстродействие, чем Decision Cube. Так на наборе из 45 тыс. записей компоненты Decision Cube потребовали 8 мин. на построение сводной таблицы.

CubeBase осуществил загрузку данных за 7сек. и построение сводной таблицы за 4 сек. При тестировании на 700 тыс. записей Decision Cube мы не дождались отклика в течение 30 минут, после чего сняли задачу.

CubeBase осуществил загрузку данных за 45 сек. и построение куба за 15 сек.

На объемах данных в тысячи записей CubeBase отрабатывал в десятки раз быстрее Decision Cube. На таблицах в сотни тысяч записей – в сотни раз быстрее. А высокая производительность – один из самых важных показателей OLAP систем.

Дополнительно см.

Ядро OLAP системы. Часть 2 – внутри гиперкуба

Ядро OLAP системы. Часть 3 – построение срезов куба

Источник: https://basegroup.ru/community/articles/olap-core-part1