Лекция
Привет, Вы узнаете о том , что такое генерация куба данных, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое генерация куба данных, проектирование кубов данных , настоятельно рекомендую прочитать все из категории Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL.
Технология OLAP — это не отдельно взятый программный продукт, не язык программирования. Если постараться охватить OLAP во всех его проявлениях, то это совокупность концепций, принципов и требований, лежащих в основе программных продуктов, облегчающих аналитикам доступ к данным.
Аналитики являются основными потребителями корпоративной информации. Задача аналитика состоит в том, чтобы находить закономерности в больших массивах данных. Поэтому аналитик не будет обращать внимания на отдельно взятый факт, что в определенный день покупателю Иванову была продана партия шариковых авторучек, — ему нужна информация о сотнях и тысячах подобных событий. Одиночные факты в ХД могут заинтересовать, к примеру, бухгалтера или начальника отдела продаж, в компетенции которого находится сопровождение определенного контракта. Аналитику одной записи недостаточно — ему, например, может понадобиться информация обо всех контрактах точки продажи за месяц, квартал или год. Аналитика может не интересовать ИНН покупателя или его телефон, — он работает с конкретными числовыми данными, что составляет сущность его профессиональной деятельности.
Централизация и удобное структурирование — это далеко не все, что нужно аналитику. Ему требуется инструмент для просмотра, визуализации информации. Традиционные отчеты, даже построенные на основе единого ХД, лишены, однако, определенной гибкости. Их нельзя "покрутить", "развернуть" или "свернуть", чтобы получить необходимое представление данных. Чем больше "срезов" и "разрезов" данных аналитик может исследовать, тем больше у него идей, которые, в свою очередь, для проверки требуют все новых и новых "срезов". В качестве такого инструмента для исследования данных аналитиком выступает OLAP.
Хотя OLAP и не представляет собой необходимый атрибут ХД, он все чаще и чаще применяется для анализа накопленных в этом ХД сведений.
Оперативные данные собираются из различных источников, очищаются, интегрируются и складываются в ХД. При этом они уже доступны для анализа при помощи различных средств построения отчетов. Затем данные (полностью или частично) подготавливаются для OLAP-анализа. Они могут быть загружены в специальную БД OLAP или оставлены в реляционном ХД. Важнейшим элементом использования OLAP являются метаданные, т. е. информация о структуре, размещении и трансформации данных. Благодаря им обеспечивается эффективное взаимодействие различных компонентов хранилища.
Таким образом, OLAP можно определить как совокупность средств многомерного анализа данных, накопленных в ХД. Теоретически средства OLAP можно применять и непосредственно к оперативным данным или их точным копиям. Однако при этом существует риск подвергнуть анализу данные, которые для этого анализа не пригодны.
В основе OLAP лежит многомерный анализ данных. Он может быть произведен с помощью различных средств, которые условно можно разделить на клиентские и серверные OLAP-средства.
Клиентские OLAP-средства представляют собой приложения, осуществляющие вычисление агрегатных данных (сумм, средних величин, максимальных или минимальных значений) и их отображение, при этом сами агрегатные данные содержатся в кэше внутри адресного пространства такого OLAP-средства.
Game: Perform tasks and rest cool.13 people play!
Play gameЕсли исходные данные содержатся в настольной СУБД, вычисление агрегатных данных производится самим OLAP-средством. Если же источник исходных данных — серверная СУБД, многие из клиентских OLAP-средств посылают на сервер SQL-запросы, содержащие оператор GROUP BY, и в результате получают агрегатные данные, вычисленные на сервере.
Как правило, OLAP-функциональность реализована в средствах статистической обработки данных (из продуктов этого класса на российском рынке широко распространены продукты компаний Stat Soft и SPSS) и в некоторых электронных таблицах. В частности, неплохими средствами многомерного анализа обладает Microsoft Excel 2000. С помощью этого продукта можно создать и сохранить в виде файла небольшой локальный многомерный OLAP-куб и отобразить его двух- или трехмерные сечения.
Многие средства разработки содержат библиотеки классов или компонентов, позволяющие создавать приложения, реализующие простейшую OLAP-функциональность (такие, например, как компоненты Decision Cube в Borland Delphi и Borland C++Builder). Помимо этого многие компании предлагают элементы управления ActiveX и другие библиотеки, реализующие подобную функциональность.
Отметим, что клиентские OLAP-средства применяются, как правило, при малом числе измерений (обычно рекомендуется не более шести) и небольшом разнообразии значений этих параметров — ведь полученные агрегатные данные должны умещаться в адресном пространстве подобного средства, а их количество растет экспоненциально при увеличении числа измерений. Поэтому даже самые примитивные клиентские OLAP-средства, как правило, позволяют произвести предварительный подсчет объема требуемой оперативной памяти для создания в ней многомерного куба.
Многие (но не все) клиентские OLAP-средства позволяют сохранить содержимое кэша с агрегатными данными в виде файла, что, в свою очередь, позволяет не производить их повторное вычисление. Отметим, что нередко такая возможность используется для отчуждения агрегатных данных с целью передачи их другим организациям или для публикации. Типичным примером таких отчуждаемых агрегатных данных является статистика заболеваемости в разных регионах и в различных возрастных группах, которая является открытой информацией, публикуемой министерствами здравоохранения различных стран и Всемирной организацией здравоохранения. При этом собственно исходные данные, представляющие собой сведения о конкретных случаях заболеваний, являются конфиденциальными данными медицинских учреждений и ни в коем случае не должны попадать в руки страховых компаний и тем более становиться достоянием гласности.
Идея сохранения кэша с агрегатными данными в файле получила свое дальнейшее развитие в серверных OLAP-средствах, в которых сохранение и изменение агрегатных данных, а также поддержка содержащего их хранилища осуществляются отдельным приложением или процессом, называемым OLAP-сервером. Клиентские приложения могут запрашивать подобное многомерное хранилище и в ответ получать те или иные данные. Некоторые клиентские приложения могут также создавать такие хранилища или обновлять их в соответствии с изменившимися исходными данными.
Преимущества применения серверных OLAP-средств по сравнению с клиентскими OLAP-средствами сходны с преимуществами применения серверных СУБД по сравнению с настольными: в случае применения серверных средств вычисление и хранение агрегатных данных происходит на сервере, а клиентское приложение получает лишь результаты запросов к ним, что позволяет в общем случае снизить сетевой трафик, время выполнения запросов и требования к ресурсам, потребляемым клиентским приложением. Отметим, что средства анализа и обработка данных масштаба предприятия, как правило, базируются именно на серверных OLAP-средствах, например, таких как Oracle Express Server, Microsoft SQL Server 2000 Analysis Services, Hyperion Essbase, продуктах компаний Crystal Decisions, Business Objects, Cognos, SAS Institute. Поскольку все ведущие производители серверных СУБД производят (либо лицензировали у других компаний) те или иные серверные OLAP-средства, выбор их достаточно широк, и почти во всех случаях можно приобрести OLAP-сервер того же производителя, что и у самого сервера баз данных.
Отметим, что многие клиентские OLAP-средства (в частности, Microsoft Excel 2003, Seagate Analysis и др.) позволяют обращаться к серверным OLAP-хранилищам, выступая в этом случае в роли клиентских приложений, выполняющих подобные запросы. Помимо этого имеется немало продуктов, представляющих собой клиентские приложения к OLAP-средствам различных производителей.
В многомерных ХД содержатся агрегатные данные различной степени подробности, например, объемы продаж по дням, месяцам, годам, по категориям товаров и т.п. Цель хранения агрегатных данных — сократить время выполнения запросов, поскольку в большинстве случаев для анализа и прогнозов интересны не детальные, а суммарные данные. Поэтому при создании многомерной базы данных всегда вычисляются и сохраняются некоторые агрегатные данные.
Отметим, что сохранение всех агрегатных данных не всегда оправданно. Дело в том, что при добавлении новых измерений объем данных, составляющих куб, растет экспоненциально (иногда говорят о "взрывном росте" объема данных). Если говорить более точно, степень роста объема агрегатных данных зависит от количества измерений куба и членов измерений на различных уровнях иерархий этих измерений. Для решения проблемы "взрывного роста" применяются разнообразные схемы, позволяющие при вычислении далеко не всех возможных агрегатных данных достичь приемлемой скорости выполнения запросов.
Как исходные, так и агрегатные данные могут храниться либо в реляционных, либо в многомерных структурах. Поэтому в настоящее время применяются три способа хранения данных.
Некоторые OLAP-средства поддерживают хранение данных только в реляционных структурах, некоторые — только в многомерных. Однако большинство современных серверных OLAP-средств поддерживают все три способа хранения данных. Выбор способа хранения зависит от объема и структуры исходных данных, требований к скорости выполнения запросов и частоты обновления OLAP-кубов.
Отметим также, что подавляющее большинство современных OLAP-средств не хранит "пустых" значений (примером "пустого" значения может быть отсутствие продаж сезонного товара вне сезона).
Технология комплексного многомерного анализа данных получила название OLAP (On-Line Analytical Processing). OLAP — это ключевой компонент организации ХД. Концепция OLAP была описана в 1993 году Эдгаром Коддом, известным исследователем баз данных и автором реляционной модели данных. В 1995 году на основе требований, изложенных Коддом, был сформулирован так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information) — быстрый анализ разделяемой многомерной информации, включающий следующие требования к приложениям для многомерного анализа:
Следует отметить, что OLAP-функциональность может быть реализована различными способами, начиная с простейших средств анализа данных в офисных приложениях и заканчивая распределенными аналитическими системами, основанными на серверных продуктах.
OLAP предоставляет удобные быстродействующие средства доступа, просмотра и анализа деловой информации. Пользователь получает естественную, интуитивно понятную модель данных, организуя их в виде многомерных кубов (Cubes). Осями многомерной системы координат служат основные атрибуты анализируемого бизнес-процесса. Например, для продаж это могут быть товар, регион, тип покупателя. В качестве одного из измерений используется время. На пересечениях осей измерений (Dimensions) находятся данные, количественно характеризующие процесс — меры (Measures). Это могут быть объемы продаж в штуках или в денежном выражении, остатки на складе, издержки и т. п. Пользователь, анализирующий информацию, может "разрезать" куб по разным направлениям, получать сводные (например, по годам) или, наоборот, детальные (по неделям) сведения и осуществлять прочие манипуляции, которые ему придут в голову в процессе анализа.
В качестве мер в трехмерном кубе, изображенном на рис. 26.1, использованы суммы продаж, а в качестве измерений — время, товар и магазин. Измерения представлены на определенных уровнях группировки: товары группируются по категориям, магазины — по странам, а данные о времени совершения операций — по месяцам. Чуть позже мы рассмотрим уровни группировки ( иерархии ) подробнее.
Даже трехмерный куб сложно отобразить на экране компьютера так, чтобы были видны значения интересующих мер. Что уж говорить о кубах с количеством измерений, большим трех. Для визуализации данных, хранящихся в кубе, применяются, как правило, привычные двумерные, т. е. табличные представления, имеющие сложные иерархические заголовки строк и столбцов.
Двумерное представление куба можно получить, "разрезав" его поперек вдоль одной или нескольких осей ( измерений ): мы фиксируем значения всех измерений, кроме двух, — и получаем обычную двумерную таблицу. В горизонтальной оси таблицы (заголовки столбцов) представлено одно измерение, в вертикальной (заголовки строк) — другое, а в ячейках таблицы — значения мер. При этом набор мер фактически рассматривается как одно из измерений: мы либо выбираем для показа одну меру (и тогда можем разместить в заголовках строк и столбцов два измерения ), либо показываем несколько мер (и тогда одну из осей таблицы займут названия мер, а другую — значения единственного "неразрезанного" измерения ).
Взгляните на рис. 26.2. Здесь изображен двумерный срез куба для одной меры — Unit Sales (продано штук) и двух "неразрезанных" измерений — Store (Магазин) и Время (Time).
На рис. 26.3 представлено лишь одно "неразрезанное" измерение — Store, но зато отображаются значения нескольких мер — Unit Sales (продано штук), Store Sales (сумма продажи) и Store Cost (расходы магазина).
Двумерное представление куба возможно и тогда, когда "неразрезанными" остаются и более двух измерений. При этом на осях среза (строках и столбцах) будут размещены два или более измерений "разрезаемого" куба — см. рис. 26.4.
Значения, "откладываемые" вдоль измерений, называются членами или метками (members). Метки используются как для "разрезания" куба, так и для ограничения (фильтрации) выбираемых данных — когда в измерении, остающемся "неразрезанным", нас интересуют не все значения, а их подмножество, например, три города из нескольких десятков. Об этом говорит сайт https://intellect.icu . Значения меток отображаются в двумерном представлении куба как заголовки строк и столбцов.
Метки могут объединяться в иерархии, состоящие из одного или нескольких уровней (levels). Например, метки измерения "Магазин" (Store) естественно объединяются в иерархию с уровнями:
| All (Мир) |
| Country (Страна) |
| State (Штат) |
| City (Город) |
| Store (Магазин). |
В соответствии с уровнями иерархии вычисляются агрегатные значения, например, объем продаж для США (уровень "Country") или для штата Калифорния (уровень "State"). В одном измерении можно реализовать более одной иерархии — скажем, для времени: {Год, Квартал, Месяц, День} и {Год, Неделя, День}.
Отметим, что иерархии могут быть сбалансированными (balanced), как, например, иерархия, представленная на рис. 26.5, а также иерархии, основанные на данных типа "дата-время", и несбалансированными (unbalanced). Типичный пример несбалансированной иерархии — иерархия типа "начальник-подчиненный" (ее можно построить, например, используя значения поля Salesperson исходного набора данных из рассмотренного выше примера), как показано на рис. 26.6.
Иногда для таких иерархий используется термин Parent-child hierarchy.
Существуют также иерархии, занимающие промежуточное положение между сбалансированными и несбалансированными (они обозначаются термином ragged — "неровный"). Обычно они содержат такие члены, логические "родители" которых находятся непосредственно на вышестоящем уровне (например, в географической иерархии есть уровни Country, City и State, но при этом в наборе данных имеются страны, не имеющие штатов или регионов между уровнями Country и City ( рис. 26.7)).
Отметим, что несбалансированные и "неровные" иерархии поддерживаются далеко не всеми OLAP-средствами. Например, в Microsoft Analysis Services 2000 поддерживаются оба типа иерархии, а в Microsoft OLAP Services 7.0 — только сбалансированные. Различными в разных OLAP-средствах могут быть и число уровней иерархии, и максимально допустимое число членов одного уровня, и максимально возможное число самих измерений.
Все, что говорилось выше про OLAP, по сути, относилось к многомерному представлению данных. То, как данные хранятся, грубо говоря, не волнует ни конечного пользователя, ни разработчиков инструмента, которым клиент пользуется.
Многомерность в OLAP-приложениях может быть разделена на три уровня.
Первые два уровня в обязательном порядке присутствуют во всех OLAP-средствах. Третий уровень, хотя и является широко распространенным, не обязателен, так как данные для многомерного представления могут извлекаться и из обычных реляционных структур; процессор многомерных запросов в этом случае транслирует многомерные запросы в SQL-запросы, которые выполняются реляционной СУБД.
Конкретные OLAP-продукты, как правило, представляют собой либо средство многомерного представления данных (OLAP-клиент — например, Pivot Tables в Excel 2000 фирмы Microsoft или ProClarity фирмы Knosys), либо многомерную серверную СУБД (OLAP-сервер — например, Oracle Express Server или Microsoft OLAP Services).
Слой многомерной обработки обычно бывает встроен в OLAP-клиент и/или в OLAP-сервер, но может быть выделен в чистом виде, как, например, компонент Pivot Table Service фирмы Microsoft.
Рассмотрим методику проектирования кубов данных для OLAP-хранилищ данных с использованием CASE PowerDesigner компании Sybase. Отметим также, что при изложении материала мы будем опускать многие детали, оставив их для самостоятельного изучения в конкретной инструментальной среде CASE-средств. Нашей задачей является иллюстрация основных моментов методики проектирования и возможностей CASE-инструментов для проектирования многомерных схем данных.
Многомерная диаграмма (multidimensional diagram) представляет собой модель хозяйственной деятельности организации в терминах кубов данных и измерений. На этой диаграмме данные о хозяйственной деятельности организации представляются в одной из двух категорий. Числовые данные или метрики, такие как количество продаж, являются фактами хозяйственной деятельности. Представление хозяйственной деятельности в терминах географии, товаров и времени является измерениями.
Многомерная диаграмма служит основным инструментом проектировщика OLAP-хранилищ данных.
OLAP-хранилища заполняются данными из ХД или киосков данных. Такая передача данных осуществляется посредством отображения реляционного представления в многомерное представление данных. Таким образом, ХД выступают как источник данных для OLAP-хранилищ.
Основными пользователями таких OLAP-хранилищ данных являются бизнес-аналитики. Аналитики опрашивают OLAP-хранилища с целью извлечения коммерческой информации. Поэтому кубы данных проектируются для поддержки аналитических запросов и строятся в соответствии с определенными пользователями измерениями.
Многомерные аналитические запросы, как правило, включают в себя вычисления, например, вычисления скорости роста или падения, анализ временных рядов данных и т.д. Такие запросы преследуют цель определить тенденции изменения данных и скрытые взаимосвязи между данными.
На рис. 26.8 приведен пример многомерной диаграммы. Как видно из рисунка, данные о продажах (Sales) имеют измерения "Товар" (product), "Регион" (region), "Покупатель" (customer) и "Магазин" (store). Факты, например, итоговый объем продаж (sales totals), рассматриваются с точки зрения этих определенных пользователем измерений. Когда аналитик делает выборку об итоговых объемах продаж (sales total) по конкретному товару для конкретного региона, он изучает данные о продажах с точки зрения измерений "Товар" и "Регион". Наиболее часто применяемым измерением является время, поскольку основная цель выполнения аналитических запросов — нахождение трендов в данных.
Основными элементами многомерной диаграммы являются:
Только кубы данных, измерения и ассоциации представлены на палитре инструментов CASE.
Многомерная диаграмма создается следующим образом. Выбрать в меню File->New Model (на рабочем пространстве появится диалоговое окно "New Model", рис. 26.9). В этом окне нужно выбрать тип модели "физическая модель данных", в качестве СУБД мы выберем MS SQL Server из выпадающего списка СУБД, укажем многомерную диаграмму как класс физической модели, присвоим имя многомерной модели ( PhysicalDataModel_1 ) и нажжем кнопку "ОК".
Таким образом, многомерная модель создана, рабочее пространство и палитра инструментов доступны ( рис. 26.10).
Проектировщик ХД может установить свойства модели в пункте меню Tools.
Рассмотрим построение элементов модели более подробно.
Как уже указывалось выше, куб данных является набором метрик, соответствующее значение которых сохраняется в каждой его ячейке данных. Метрики организованы в соответствии с измерениями, для того чтобы выполнять быструю выборку данных или операции сверки-развертки ( drill-down ).
Как правило, кубы данных связаны с фактами, которые позволяют определить метрики для куба. На многомерной диаграмме кубы данных представляют OLAP-кубы.
Для построения куба данных можно использовать палитру инструментов. Выбираем на ней пиктограмму куба и щелчком левой кнопки мыши на рабочем пространстве создаем куб данных.
Далее двойным щелчком мыши на кубе данных откроем диалоговое окно для определения свойств куба данных ( рис. 26.11).
Для куба данных можно определить следующие свойства.
Дополнительными свойствами куба данных являются:
Присвоим кубу данных имя "Продажа" (Sale). На рис. 26.12 показан результат выполнения построения куба данных многомерной модели.
Измерения являются осями для анализа данных в многомерной структуре данных.
Измерение состоит из упорядоченного списка атрибутов, которые совместно определяют общий семантический смысл (своими значениями) в моделируемой предметной области. Каждый атрибут определяет единственную позицию вдоль оси куба данных.
Измерения могут быть отображены на таблицы и представления, что позволяет передавать данные в них из БД оперативных систем.
Измерения могут иметь несколько иерархий на множестве своих атрибутов.
Для построения измерения можно использовать палитру инструментов. Выбираем на ней пиктограмму измерения и щелчком левой кнопки мыши на рабочем пространстве создаем измерение.
Далее двойным щелчком мыши на измерении откроем диалоговое окно для определения свойств измерения ( рис. 26.13).
Присвоим измерению имя "Время" (Time).
Для измерения можно определить следующие свойства.
Определение измерения также включает следующие дополнительные свойства.
Атрибуты являются квалификаторами измерений в запросах. Например, измерение "Время" (Time) может содержать атрибуты "Год", "Квартал", "Месяц", "Неделя". Атрибуты могут быть организованы в иерархии.
Атрибуты измерения имеют следующие свойства.
Дополнительными свойствами атрибутов являются:
Для создания атрибутов измерения можно использовать диалоговое окно свойств измерения. Например, для измерения "Время" определим следующие атрибуты: "Год" (Year), "Квартал" (Quarter), "Месяц" (Month) и "Неделя" (Week) – как показано на рис. 26.15.
Атрибут может участвовать в определении другого атрибута, тем самым дополняя определение последнего. Уточняющие атрибуты находятся в списке атрибутов измерения и могут быть использованы в определении другого атрибута.
Например, в измерении "Покупатель" (Customer) атрибуты "Имя покупателя" (Cust_Name) и "Адрес покупателя" (Cust_Address) могут быть использованы для детализации атрибута "Идентификатор покупателя" (Cust_ID) ( рис. 26.16).
Для этого нужно в диалоговом окне свойств измерения выбрать список атрибутов, в списке атрибутов выбрать атрибут Cust_ID, открыть для него диалоговое окно свойств атрибута, на нем выбрать вкладку "Detail Attributes" и занести на нее атрибуты Cust_Name и Cust_Address, как показано на рис. 26.17.
Факт соответствует фокусу исследования данных для поддержки принятия решений руководство организации. Факт – это набор метрик куба данных. Например, фактами могут быть, как в нашем примере, "Продажи" (Sale) или доходы и бюджет. Одни и те же факты могут использоваться в различных кубах данных.
Факт добавляется в многомерную диаграмму следующим образом. Выберите пункт меню Model-> Facts и добавьте его в список в появившемся диалоговом окне "Список фактов " ( List of Facts ), как показано на рис. 26.18 и на рис. 26.19.
Факт имеет следующие свойства.
Дополнительными свойствами факта являются:
Метрика является переменной, которая соответствует фокусу исследования данных. Метрика описывает значение ячейки куба данных. Например, метрикой часто бывает цена товара или итоговое значение. Метрики могут быть результатом вычислений.
Метрика имеет следующие свойства.
Дополнительными свойствами метрики являются:
Для создания метрики можно из главного меню Model->Facts в диалоговом окне "Список фактов " ( List of Facts ) выбрать факт (в нашем случае Sale) и вызвать диалоговое окно "Свойства факта " ( Fact Properties ), в котором на вкладке " Метрика " ( Measure ) добавить необходимые метрики. В нашем пример добавим следующие метрики: "Итог" (Total), "Промежуточный итог" (Sudtotal) и "Еженедельный итог" (Weekly) – как показано на рис. 26.20.
Теперь куб данных нашего примера выглядит, как на рис. 26.21.
Иерархия определяет один или несколько путей доступа к данным через измерение. Различают два основных типа иерархий.
иерархия имеет следующие свойства.
Дополнительными свойствами иерархии являются:
Добавить иерархию в измерение можно, открыв окно свойств измерения на вкладке " Иерархии " (Hierarchies), как показано на рис. 26.22.
При создании иерархии назначается имя по умолчанию, включающее номер. Этот номер используется, как предполагается по умолчанию, при создании объекта.
Открыв диалоговое окно свойств иерархии, можно добавить атрибуты в иерархию, как показано на рис. 26.23.
Теперь на многомерной диаграмме измерение "Время" (Time) имеет вид, как на рис. 26.24.
Ассоциация связывает куб данных с измерением, которое его определяет. Ассоциация показывает аспект исследования куба данных по указанному измерению.
Например, можно связать куб данных "Продажи" (Sale) с измерением "Покупатель" (Customer) посредством ассоциации "Продажи" – "Покупатель" (Sale-Customer). Допускается только одна ассоциация между измерением и кубом данных.
Ассоциация имеет следующие свойства.
Ассоциацию можно создать при помощи палитры инструментов, выбрав пиктограмму ассоциации. Для нашего примера свяжем куб данных "Продажи" (Sale) с измерением "Покупатель" (Customer), как показано на рис. 26.25.
Добавим к многомерной модели нашего примера три измерения — "Магазин" (Store), "Регион" (Region) и "Товар" (Product). В результате получим многомерную диаграмму, как на рис. 26.8.
Однако это далеко не все, что нужно еще сделать для завершения построения модели. Полученное графическое преставление многомерной диаграммы пока еще практически бесполезно. Рассмотрим некоторые вопросы, которые нужно решить для завершения построения многомерной диаграммы.
Кубы данных в OLAP-хранилище данных должны наполняться данными из ХД, киосков данных или БД оперативных систем организации (источники данных). Мы должны, как говорят, заполнить (populate) куб данных.
На многомерной диаграмме каждый куб данных связан с запросом. Для каждого куба существует одно отображение на один источник данных. Запрос, определенный на кубе, используется для извлечения данных из источника и затем сохранения их в кубе OLAP-хранилища. Такая связь между источником данных и кубом данных называется отображением реляционной схемы в многомерную.
Прежде чем приступить к генерированию скрипта создания куба данных, его нужно связать с источником, т.е. построить отображение реляционной схемы в многомерную. Для решения этой задачи нужно иметь источник данных.
Пусть для нашего примера источником данных является киоск данных со схемой, приведенной на рис. 26.26.
Для построения отображения в PowerDesigner имеется редактор отображения (Mapping Editor), который вызывается из пункта меню Tools->Mapping Editor.
Определим имя источника данных как DataSource_1 и привяжем его к схеме, рис. 26.26, выполнив действия, предписываемые PowerDesigner. Далее установим связи между полями таблиц фактов и измерений источника и метриками, атрибутами куба данных и измерений многомерной диаграммы, как показано на рис. 26.27.
После выполнения описанных выше действий в диалоговом окне свойств куба данных "Продажи" ( Sale ) на вкладке Queries можно посмотреть запрос, который будет использован для извлечения данных из источника для помещения их в куб:
select
Customer.CustID "Cust_ID",
Customer.Cust_name "Cust_Name",
Customer.Cust_addr "Cust_Address",
Region.Country "Country",
Region.City "City",
Region.Addr "Address",
Store.Size "Size",
Store.Discount "Discount",
Product.Type "Type",
Product.Cftegory "Category",
Sale.Total "Total",
Sale.Subtotal "Subtotal",
Sale.Weekly "Weekly"
from Customer,
Region,
Store,
Product,
Sale
where Sale.RegionID = Region.RegionID and
Sale.CustID = Customer.CustID and
Sale.StoreID = Store.StoreID and
Sale.ProductID = Product.ProductID
Также в диалоговом окне свойств куба данных "Продажи" ( Sale ) на вкладке Preview можно посмотреть скрипт, который будет использован для создания куба данных:
CREATE CUBE Sale
(
DIMENSION Customer,
LEVEL Cust_ID TYPE Regular,
LEVEL Cust_Name TYPE Regular,
LEVEL Cust_Address TYPE Regular,
DIMENSION Region,
LEVEL Country TYPE Regular,
LEVEL City TYPE Regular,
LEVEL Address TYPE Regular,
DIMENSION Store,
LEVEL Size TYPE Regular,
LEVEL Discount TYPE Regular,
DIMENSION Product,
LEVEL Type TYPE Regular,
LEVEL Category TYPE Regular,
MEASURE Total,
MEASURE Subtotal,
MEASURE Weekly
)
Существует более простой способ создания многомерной диаграммы, используя диаграмму физической модели данных с помощью функции Rebuild Cubes, которая вызывается из пункта меню Tools->Multidimesion->Rebuild Cubes ( рис. 26.28).
Построенный куб данных показан на рис. 26.28. Как видно из рисунка, построенный куб данных отличается от построенного нами в учебном примере. В этом случае мы не применяли напрямую редактор отображений, поэтому все поля исходной схемы присутствуют на многомерной диаграмме.
Заметим, что в этом примере запрос:
select
Store.StoreID "StoreID",
Store.Name "Name",
Store.Size "Size",
Store.Discount "Discount",
Customer.CustID "CustID",
Customer.Cust_name "Cust_name",
Customer.Cust_addr "Cust_addr",
Region.RegionID "RegionID",
Region.Country "Country",
Region.City "City",
Region.Addr "Addr",
Product.ProductID "ProductID",
Product.Type "Type",
Product.Cftegory "Cftegory",
Product.Price "Price",
Sale.SaleID "SaleID",
Sale.Total "Total",
Sale.Subtotal "Subtotal",
Sale.Weekly "Weekly"
from Store,
Customer,
Region,
Product,
Sale
where Sale.RegionID = Region.RegionID and
Sale.CustID = Customer.CustID and
Sale.StoreID = Store.StoreID and
Sale.ProductID = Product.ProductID
также имеет отличия от построенного нами ранее. Отличается и команда построения куба данных:
CREATE CUBE Sale
(
DIMENSION Store,
LEVEL StoreID TYPE Regular,
DIMENSION Customer,
LEVEL CustID TYPE Regular,
DIMENSION Region,
LEVEL RegionID TYPE Regular,
DIMENSION Product,
LEVEL ProductID TYPE Regular,
MEASURE SaleID,
MEASURE Total,
MEASURE Subtotal,
MEASURE Weekly
).
В заключение следует отметить, что построение многомерной диаграммы носило иллюстративный характер — был пропущен ряд действий, которые сделали бы диаграмму работоспособной. Нашей целью было показать методику построения многомерной диаграммы и описать основные элементы многомерной диаграммы.
В данной работе мы ознакомились с основами OLAP. Мы узнали следующее.
Кроме этого, мы рассмотрели основные принципы логической организации OLAP-кубов, узнали основные термины и понятия, применяемые при многомерном анализе. И наконец, мы выяснили, что представляют собой различные типы иерархий в измерениях OLAP-кубов.
Были рассмотрены методика построения многомерной диаграммы в CASE-инструменте PowerDesigner и ее основные элементы: куб данных, измерение, ассоциация, иерархия, факт, метрики, атрибуты.
Исследование, описанное в статье про генерация куба данных, подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое генерация куба данных, проектирование кубов данных и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL
Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.
Комментарии
Оставить комментарий
Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL
Термины: Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL