OLAP системы

Содержание

Ведение ……………………………………………………………………….…..3

1. Сущность и построение хранилища данных ………………………………...5

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

1.2. Организация хранилищ данных ……………………………….……….…..11

2. OLAP системы ………………………………………………….……………..16

2.1. Определение OLAP-систем …………………………………………….…..16

2.2. Архитектура OLAP-систем …………………………………………………21

Заключение ………………………………………………………….……………29

Глоссарий ……………………………………………………………………...….31

Список использованных источников …………………………………….……..33

Приложения ………………………………………………………………………34

 

Введение

 

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

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

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

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

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

Построение хранилищ данных – процесс сложный по самой своей природе и поэтому обычно дорогостоящий и длительный.

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

Объектом курсовой работы выступает хранилище данных.

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

Исходя из целей курсовой работы, ее задачами являются:

- обозначить сущность хранилища  данных;

- проанализировать процесс создания  хранилища данных;

- рассмотреть архитектуры хранилищ  данных;

- дать определение метаданным  хранилища данных

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

 

Основная часть

1 Сущность и построение хранилища данных

Хранилище данных (data warehouse) по сути, представляет собой центр, в который собирается вся необходимая информация из различных подразделений предприятия. Прежде чем попасть в хранилище, данные должны быть соответствующим образом обработаны. Базы данных, в которых происходит накопление, обработка первичных данных, на основании которых строится хранилище, будем далее называть транзакционными (Приложение А). Разные отделы могут использовать неодинаковые системы обработки со своими транзакционными БД. Соответственно, прежде чем использовать эти разрозненные данные, их нужно проанализировать. Этот процесс занимает весьма длительный период в процессе подготовки к созданию хранилища.

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

Хранилище данных должно решать определенные задачи:

- получение полной информации  о клиенте,

- предоставление конкретных данных для последующего анализа определенного сегмента рынка и т.д.

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

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

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

 

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

 

Ральф Кимбалл (Ralph Kimball), один из авторов концепции хранилищ данных, описывал хранилище данных как «место, где люди могут получить доступ к своим данным»1. Он же сформулировал и основные требования к хранилищам данных:

- поддержка высокой скорости получения данных из хранилища;

- поддержка внутренней непротиворечивости данных;

- возможность получения и сравнения так называемых срезов данных (slice and dice);

- наличие удобных утилит просмотра данных в хранилище;

- полнота и достоверность хранимых данных;

- поддержка качественного процесса пополнения данных

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

Типичная структура хранилища данных существенно отличается от структуры обычной реляционной БД. Как правило, эта структура денормализована (это позволяет повысить скорость выполнения запросов), поэтому может допускать избыточность данных.

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

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

Рисунок 1. Типичная структура хранилища данных - схема «звезда»

 

Реализация OLАР-кубов может быть различной. В последнее время наиболее распространенным вариантом является использование денормализованной реляционной структуры. В этом случае основными составляющими структуры хранилищ данных (рис.3.13) являются таблица фактов (fact table) и таблицы измерений (dimension tables), соединенные по схеме «звезда» (star schema). Название «звезда» используется в том случае, если каждое измерение содержится в одной таблице размерности.

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

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

• факты, связанные с «моментальными снимками» (Snapshot facts). Ос¬нованы на состоянии объекта (например, банковского счета) в определенные моменты времени, например на конец дня или месяца. Ти¬пичными примерами таких фактов являются объем продаж за день или дневная выручка;

• факты, связанные с элементами документа (Line-item facts). Основаны на том или ином документе (например, счете за товар или услуги) и содержат подробную информацию об элементах этого документа (например, количестве, цене, проценте скидки);

• факты, связанные с событиями или состоянием объекта (Event or state facts). Представляют возникновение события без подробностей о нем (например, просто факт продажи или факт отсутствия таковой без иных подробностей).

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

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

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

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

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

Если хотя бы одно из измерений содержится в нескольких связанных таблицах, такая схема хранилища данных носит название «снежинка» (snowflake schema). Дополнительные таблицы измерений в такой схеме, обычно соответствующие верхним уровням иерархии измерения и находя¬щиеся в соотношении «один ко многим» с таблицей измерений, соответствующей нижнему уровню иерархии, иногда называют консольными таблицами (outrigger table). Схема «снежинка» изображена на рисунке 2.

Рисунок 2. Структура хранилища данных – схема «снежинка»

 

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