технологии оперативного анализа данных
реклама
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ «САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ ЭКОНОМИЧЕСКИЙ УНИВЕРСИТЕТ» КАФЕДРА ИНФОРМАТИКИ Н.В. ПУШКИНА Ю.Б. БЕКАРЕВИЧ ТЕХНОЛОГИИ ОПЕРАТИВНОГО АНАЛИЗА ДАННЫХ Учебное пособие ИЗДАТЕЛЬСТВО САНКТ-ПЕТЕРБУРГСКОГО ГОСУДАРСТВЕННОГО ЭКОНОМИЧЕСКОГО УНИВЕРСИТЕТА 2013 Рекомендовано научно-методическим советом университета ББК 32.973.26-018.2 П 91 Пушкина Н.В. 2 П 91 Технологии оперативного анализа данных : учебное пособие / Н.В. Пушкина, Ю.Б. Бекаревич. – СПб. : Изд-во СПбГЭУ, 2013. – 104 с. В пособии рассматриваются вопросы оперативной аналитической обработки данных, которые являются важнейшими составляющими бизнес-аналитики, определяемой как инструменты и приложения для поиска, анализа, моделирования и доставки информации, необходимой для принятия решений. Рассмотрены задачи подготовки информации для анализа в едином источнике – многомерных хранилищах данных. Подробно описана разработка проектов службы Microsoft SQL Server 2005 Analysis Services, реализующих создание сложных решений оперативного анализа различных аспектов бизнеса. В пособии показано, как на практике выполнить определение источников данных и их представлений, измерений, атрибутов, иерархий и OLAP-кубов в проекте Analysis Services, обеспечить заполнение куба данными из хранилища данных и проанализировать данные куба, в том числе в сводных таблицах популярного приложения Microsoft Office Excel. Пособие предназначено для студентов и магистрантов, изучающих бизнесаналитику по программе “Информационная бизнес-аналитика”, а также может быть использовано при изучении информационных технологий по аналитической обработке данных в других направлениях. ББК 32.973.26-018.2 Рецензенты: профессор кафедры информационных систем в экономике СПбГЭУ, доктор технических наук И.А. Брусакова доцент кафедры прикладной информатики и математики СПбГАСУ, кандидат физико-математических наук Л.К. Нарбут Учебное издание Пушкина Нина Васильевна Бекаревич Юрий Борисович ТЕХНОЛОГИИ ОПЕРАТИВНОГО АНАЛИЗА ДАННЫХ Учебное пособие Редактор О.А. Масликова Подписано в печать 17.07.13. Формат 60х84 1/16. Усл. печ. л. 6,5. Уч.-изд. л. 3,1. Тираж 60 экз. Заказ 326. РТП изд-ва СПбГЭУ. Издательство СПбГЭУ. 191023, Санкт-Петербург, Садовая ул., д. 21. © СПбГЭУ, 2013 Введение Технология оперативной аналитической обработки данных (OnLine Analytical processing – OLAP) ориентирована на оказание помощи в 3 принятии своевременных решений руководителю. Принять любое управленческое решение невозможно, не обладая необходимой для этого информацией, обычно количественной. Для этого необходимо создание хранилищ данных (Data warehouses), то есть процесс сбора, отсеивания и предварительной обработки данных с целью предоставления результирующей информации пользователям для статистического анализа и создания аналитических отчетов. Средства OLAP позволяют осуществлять стратегический обзор ситуации, в реальном времени получать ответы на вопросы, интересующие аналитика, и представлять результаты этого анализа в удобном для восприятия и принятия решений виде. Эти средства предназначены как для быстрого получения ответов на произвольные запросы пользователейаналитиков, так и быстрого составления отчетности по агрегированным показателям процессов в различных разрезах и с произвольной глубиной детализации оперативных данных. Средства OLAP также используются для проверок, заранее сформулированных аналитиком гипотез. Технология OLAP использует методы и средства для сбора, хранения и анализа многомерных данных, представленных анализируемыми фактами, зависящими от большого числа характеризующих параметров, в целях поддержки процессов принятия решений. Такая технология реализует методику оперативного извлечения нужной информации из больших массивов данных и формирования соответствующих отчетов. OLAP неразрывно связан с хранилищем данных (Data Warehouse), которое, по определению Билла Инмона – основателя хранилищ данных, является “предметно-ориентированным, привязанным ко времени и неизменяемым собранием данных для поддержки процесса принятия управляющих решений”. 4 Данные в хранилище попадают из оперативных систем (OLTPсистем), которые предназначены для автоматизации бизнес-процессов. Кроме того, хранилище может пополняться данными за счет различных внешних источников самых разнообразных форматов и типов, например отдельных файлов офисных документов (Excel, Word), баз данных (Oracle, Access и др.), статистических отчетов. Основными преимуществами использования OLAP являются: наглядность представления структуры данных на основе фактов и измерений; гибкие механизмы детализации и агрегации данных по различным разрезам; высокая скорость ответа на запрос; мощная аналитическая и вычислительная платформа; возможность моделирования и быстрого создания аналитических отчетов, не прибегая к помощи программистов. Помимо централизации и удобного структурирования, анали- тику требуется инструмент для просмотра, визуализации информации. Традиционные отчеты, даже построенные на основе единого хранилища, не обладают достаточной гибкостью, не позволяют получить желаемое представление данных. Изменение макета отчета может потребовать значительного времени и привлечения программиста. В результате аналитик не сможет оперативно проверить свои идеи, требующие выполнения многочисленных и все новых срезов данных. OLAP предоставляет инструмент, который позволяет просто и удобно выполнять нерегламентированные запросы – получать ответы на нестандартные, сформированные «по требованию» вопросы. При этом анализируемые данные могут визуализироваться непосредственно OLAP-системой либо подвергаться обработке средствами аналитического приложения, которое и визуализирует результаты этой обработки. 5 Учитывая широту спектра аналитических задач, можно выделить три основных подхода к использованию хранилищ данных: регулярные отчеты – подготовка отчетов стандартных форм, получаемых многократно с определенной периодичностью; нерегламентированные запросы – возможность в интерактивном режиме быстро получать ответы на вопросы; интеллектуальный анализ данных – поддержка процесса интеллектуального анализа больших массивов данных с целью выявления скрытых закономерностей, структур и объектов, построения моделей, прогнозов и т.д. Без построения и использования хранилищ данных и OLAP не- возможно анализировать данные оперативных систем напрямую сложно, а зачастую и невозможно: данные разрозненны, хранятся в форматах различных СУБД и на разных серверах корпоративной сети, структуры хранения данных сложны и запутанны, детальная информация избыточна для анализа и принятия решений. Большие объемы данных оперативных систем приводят к длительности оперативного анализа информации. Сложные аналитические запросы к оперативной информации тормозят текущую работу компании, надолго блокируя таблицы и захватывая ресурсы сервера. При отсутствии хранилищ данных и OLAP невозможно получение бизнес-информации из оперативных систем без привлечения специалистов IТ-службы, усложняется анализ бизнес-информации, хранящейся в различных источниках и невозможно эффективное сопоставление и анализ исторических данных. 6 Основы многомерного представления данных Реальные бизнес-процессы в большинстве случаев описываются множеством показателей и параметров. Например, для описания процесса продаж могут понадобиться сведения о группах товаров, самих товарах, магазинах, городах, странах, где производятся продажи, о суммах и объемах продаж. Для контролирования процесса во времени необходимы сведения о датах, месяцах и годах продаж. Если собрать все эти сведения в плоской таблице, то она окажется сложной для визуального анализа и осмысления. Извлечение из такой таблицы полезной информации с целью анализа текущего состояния продаж и поиска путей совершенствования процесса торговли практически невозможно. Такая ситуация возникает вследствие того, что в плоской таблице хранятся многомерные данные. Выполняемая в реляционных моделях, которые используют соответствующие базы данных, декомпозиция информации в несколько более простых нормализованных таблиц, связанных определенными отношениями, также не обеспечивает должного уровня оптимизации с точки зрения анализа. В результате разработка многомерной модели представления данных, реализуемой с помощью многомерных кубов, стала естественным развитием технологий представления данных для анализа. Многомерные кубы, измерения и меры (факты) OLAP предоставляет пользователю удобные быстродействующие средства доступа, просмотра и анализа деловой информации за счет естественной, интуитивно понятной модели данных, представленной в 7 виде многомерных кубов (Cubes). Осями многомерной системы координат служат основные параметры анализируемого бизнес-процесса – измерения (Dimensions). Например, для продаж это могут быть товар, регион, покупатель. В качестве одного из измерений, как правило, используется время. Измерение – это набор значений одного из анализируемых параметров. Значения, откладываемые вдоль измерений, называются членами или метками (members). На пересечениях осей – измерений – находятся данные, количественно характеризующие пр оцесс, – меры или факты (Measures). Это могут быть объемы продаж в штуках или в денежном выражении, остатки на складе, издержки и т. п. С измерениями может связываться одна или несколько мер. Каждому значению измерения в многомерной модели соответствует одно или несколько значений мер. Измерения относятся к классификационным признакам, а меры являются количественной характеристикой. Метки используются как для “разрезания” куба, так и для фильтрации выбираемых данных, когда в измерении, остающемся “неразрезанным”, нас интересуют не все значения, а их подмножество, например три страны из нескольких десятков. Значения меток отображаются в двумерном представлении куба как заголовки строк и столбцов. В качестве мер в кубе, изображенном на рис. 1, использованы суммы продаж, а в качестве измерений – время, товар и магазин. Измерения представлены на определенных уровнях группировки: товары группируются по категориям, магазины – по странам, а данные о времени совершения операций – по годам. 8 Рис. 1. Пример представления данных в виде трехмерного куба Иерархии и уровни Измерение может быть представлено в виде иерархической структуры. Метки могут объединяться в иерархии, состоящие из одного или нескольких уровней (levels). Например: метки измерения Магазин естественно объединяются в иерархию с уровнями: магазин, город, регион, страна; метки измерения Товар – в иерархию с уровнями: товар, категория, группа; метки измерения Время – в иерархию с уровнями: день, месяц или неделя, квартал, год. В соответствии с уровнями иерархии вычисляются агрегатные значения мер, например, сумма или объем продаж для уровня Страна (например, Италия) или для уровня Город (например, Рим). В одном измерении можно реализовать более одной иерархии. При этом, как правило, для одних и тех же элементов поддерживается несколько ви- 9 дов иерархий: например, для времени: (День, Месяц, Квартал, Год) и (День, Неделя, Квартал, Год). Исходные данные берутся из нижних уровней иерархий, а затем суммируются для получения значений мер более высоких уровней. Для того чтобы ускорить процесс перехода, просуммированные значения для разных уровней хранятся в кубе. Таким образом, то, что со стороны пользователя выглядит одним кубом, грубо говоря, состоит из множества более простых кубов. Операции, выполняемые над кубом Пользователь, анализирующий информацию, может разрезать куб по разным направлениям, получать консолидированные (например, по годам) или, наоборот, детальные (по дням) сведения и осуществлять прочие манипуляции, которые ему понадобятся в процессе анализа. Срез куба Даже трехмерный куб сложно отобразить на экране компьютера так, чтобы были видны значения нужных мер. Кубы с количеством измерений больше трех тем более сложны для визуализации. Срез (Slice) данных представляет собой подкуб, в который входят только некоторые измерения. Срез является подмножеством многомерного массива данных, соответствующим единственному значению одного или нескольких параметров измерений, не входящих в это подмножество. Фиксируя значения всех измерений, кроме двух, получаем обычную двумерную таблицу. На горизонтальной оси таблицы (заголовки столбцов) представлены значения одного измерения (метки), на вертикальной (заголовки строк) – другого, а в ячейках таблицы – значения мер. 10 На рис. 2 изображен двумерный срез куба для единственного значения измерения Время, равного 2011 г., на осях которого представлены измерения – Магазин и Товар, а в ячейках значения мер – суммы продаж, агрегированные по странам, в которых находятся магазины. Рис. 2. Срез куба для одной меры Двумерное представление куба возможно и тогда, когда остается более двух измерений. При этом на осях среза (строках и/или столбцах) будут размещены два или более измерений куба (рис. 3). Рис. 3. Срез куба с несколькими измерениями на горизонтальной оси 11 На рис. 3 изображен срез куба для одной агрегированной меры – суммы продаж и трех измерений (Группа товаров, Магазины по странам, Время по годам). На рис. 4 представлено лишь одно измерение – Магазин (сгруппированы по странам), но зато здесь отображаются агрегированные значения нескольких мер – Сумма продаж, Продано штук, Расходы магазина. Рис. 4. Срез куба для трех мер При этом набор мер фактически рассматривается как одно из измерений: мы либо выбираем для показа одну меру и тогда можем разместить в заголовках строк и столбцов два измерения, либо показываем несколько мер, и тогда одну из осей таблицы займут названия мер, а другую – значения единственного нефиксированного измерения. Транспонирование Транспонирование (вращение) обычно применяется к плоским таблицам, полученным, например, в результате среза, и позволяет изменить порядок представления измерений таким образом, что измерения, отображавшиеся в столбцах, будут отображаться в строках, и наоборот. 12 В ряде случаев транспонирование позволяет сделать таблицу более наглядной. Агрегирование и детализация Агрегирование (Drill Up) и детализация (Drill Down) – это операции, которые определяют переход вверх от детального представления данных к агрегированному, и наоборот соответственно. Направление обобщения (так и детализации) может быть задано как по иерархии отдельных измерений, так и согласно прочим отношениям, установленным в рамках измерений. Например, если при анализе данных об объемах продаж в России выполнить операцию детализации для измерения Регион, то на экране будут отображены такие его элементы, как Москва, Самара, Ростов и т.д. В результате дальнейшей детализации элемента Москва будут отображены элементы (магазины) Лента, Ашан, Дикси и т.д. Операции агрегирования (группировки) и детализации возможны только тогда, когда имеет место иерархическая подчиненность значений измерений. При агрегировании одно или несколько подчиненных значений измерений заменяются теми значениями, которым они подчинены. При этом уровень обобщения данных увеличивается. Так, если отдельные товары образуют группы, например Напитки, то в результате агрегирования вместо отдельных наименований товаров будет указано наименование группы, а соответствующие им меры будут агрегированы. Проиллюстрируем результаты агрегирования: в табл. 1 представлена исходная таблица, а в табл. 2 – результат ее агрегирования по измерению Товар. 13 Таблица 1. Исходная таблица Группа Товар Сумма продаж Напитки Фанта 2 000 Сок яблочный 12 000 Минеральная вода 4500 Кока Кола 7400 Колбаса докторская 8200 Сыр пошехонский 7600 Творог домашний 2450 Гастрономия Молоко 780 Таблица 2. Результат агрегирования исходной таблицы по измерению Товар Группа Сумма продаж Напитки 25 900 Гастрономия 19 030 Детализация – это процедура, обратная агрегированию; уровень обобщения данных уменьшается. При этом значения измерений более высокого иерархического уровня заменяются одним или несколькими значениями более низкого уровня, то есть вместо наименований групп товаров отображаются наименования отдельных товаров. В кубе, показанном на рис. 1, данные о продажах агрегированы по группам товаров: мы видим не суммы по отдельным товарам, а значения, полученные их суммированием по группам товаров. Для более детального исследования может понадобиться информация о суммах, 14 полученных по каждому из товаров. Операция детализации позволит получить такую информацию. Следует отметить, что OLAP-куб представляет интерес как для визуального анализа данных, так и для поиска особенностей и закономерностей в данных. Задаваясь различными вопросами: “Какой товар пользовался наибольшей популярностью?”, “В какой стране (магазине) продажи были наилучшими и с чем это связано?” и т.п., аналитик, манипулируя заголовками измерений, выбирает такое представление куба, которое позволяет ответить на поставленные вопросы. Сопоставление данных, выявление закономерностей и связей между элементами данных, высказывание гипотез может быть обеспечено последовательным перебором возможных вариантов представления данных, доступных в кубе. Использование OLAP-анализа и работа с кубами позволяет грамотным аналитикам получать результаты даже в тех случаях, когда методы интеллектуального анализа Data Mining малоэффективны. Архитектура OLAP-систем OLAP-система включает два основных компонента: OLAP- сервер и OLAP-клиент. OLAP-сервер обеспечивает хранение данных, выполнение над ними необходимых операций и формирование многомерной модели на концептуальном уровне. OLAP-клиент обеспечивает работу аналитика с многомерной моделью. Требования к приложениям для многомерного анализа В формализованном виде критерии OLAP, которым должны удовлетворять продукты, позволяющие выполнять оперативную анали- 15 тическую обработку, были сформулированы в 1993 году Е.Ф. Коддом, создавшим сначала концепции реляционных СУБД, а затем и OLAP. Таких критериев 12. В 1995 г. он добавил к этим критериям еще 6 правил. Позже они были переработаны в так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information – быстрый анализ разделяемой многомерной информации), который определяет требования к приложениям для многомерного анализа: Fast (Быстрый) – анализ должен производиться одинаково быстро по всем аспектам информации. Приложение OLAP должно обеспечивать минимальное время доступа к аналитическим данным – в среднем около 5 секунд; Analysis (Анализ) – должна обеспечиваться возможность числового и статистического анализа. Приложение OLAP должно позволять пользователю произвольно определять новые специальные вычисления как часть анализа и формировать отчеты без необходимости программирования. При этом функциональные возможности анализа должны обеспечиваться понятным для конечного пользователя способом; Shared (Разделяемый доступ). Приложение OLAP должно предоставлять многопользовательский доступ к данным с поддержкой соответствующих механизмов блокировок и средств авторизованного доступа; Multidimensional (Многомерность). Ключевое требование OLAP: обеспечение многомерного концептуального представления данных, включая полную поддержку для иерархий и множественных иерархий; вычисления показателей для произвольного набора классификационных признаков. 16 Information (Информация). Приложение OLAP должно давать пользователю возможность получать нужную информацию, в каком бы электронном хранилище данных она ни находилась. Многомерность в OLAP-приложениях может быть разделена на три уровня: Многомерное представление данных – средства конечного пользователя, обеспечивающие многомерную визуализацию и манипулирование данными. Слой многомерного представления абстрагирован от физической структуры данных и воспринимает данные как многомерные. Этот уровень, как правило, реализуется OLAP-клиентом. Многомерная обработка – средство (язык) формулирования многомерных запросов (традиционный реляционный язык SQL здесь оказывается непригодным) и процессор, умеющий обработать и выполнить такой запрос. Этот уровень, как правило, реализуется OLAP-сервером. Многомерное хранение – средства физической организации данных, обеспечивающие эффективное выполнение многомерных запросов. Этот уровень может быть реализован как в OLAP-сервере, так и в хранилище данных. Первые два уровня в обязательном порядке присутствуют во всех OLAP-средствах. Третий уровень, хотя и является широко распространенным, не обязателен, так как данные для многомерного представления могут извлекаться и из обычных реляционных структур; процессор многомерных запросов в этом случае транслирует 17 многомерные запросы в SQL-запросы, которые выполняются реляционной СУБД. Для конечного пользователя не так важно, как хранятся данные, к тому же часто способ реализации многомерной модели на OLAPсервере скрыт от конечного пользователя. На OLAP-сервере формируется гиперкуб, с которым пользователи посредством OLAP-клиента выполняют все необходимые операции, анализируя данные. Между тем способ реализации очень важен, так как от него зависит и производительность, и занимаемые ресурсы. Способы хранения данных Выделяют три основных варианта хранения данных: MOLAP (Multidimensional OLAP) – для реализации многомерной модели используют многомерные хранилища данных. При этом и детальные данные, и агрегаты хранятся в многомерной БД. В этом случае получается наибольшая избыточность, так как многомерные данные полностью содержат реляционные. Режим хранения MOLAP дает значительные преимущества в производительности по сравнению с ROLAP и HOLAP. Недостатком этой модели является то, что ее можно использовать только в OLAP, и поэтому доступ к ней могут получить только OLAP-клиенты, ADO MD и Pivot Table Service. ROLAP (Relational OLAP) – для реализации многомерной модели используют реляционные хранилища данных. При этом детальные данные остаются там, где они были изначально – в реляционной БД; агрегаты хранятся в той же БД в специально созданных таблицах с индек- 18 сами. Реализация OLAP-куба с помощью обычной реляционной модели, по сути, является эмуляцией многомерного представления совокупностью плоских таблиц. Метод хранения ROLAP целесообразно использовать при большом объеме архивных данных, к которым обращаются нечасто. HOLAP (Hybrid OLAP) – для реализации многомерной модели используют гибридные хранилища данных. HOLAP является подходящим вариантом, если используется большое количество подробных данных, к которым приложению приходится часто обращаться. HOLAP позволяет использовать преимущества наращиваемости СУБД, так как оставляет подробные данные в реляционной базе данных. Агрегаты хранятся в многомерной БД, которая позволяет увеличить скорость выполнения запросов (поскольку при выполнении аналитических запросов уже не требуется вычислять агрегаты). Такая модель хранения данных, представляющая собой комбинацию реляционной и многомерной моделей, позволяет сочетать высокую производительность, характерную для многомерной модели, и возможность хранить сколь угодно большие массивы данных, присущую реляционной модели. Каждый из этих способов имеет свои преимущества и недостатки и должен применяться в зависимости от таких условий, как объем данных, мощность реляционной СУБД и др. На рис. 5 в общем виде представлена схема процесса аналитической обработки данных. 19 Рис. 5. Схема взаимодействия компонентов процесса аналитической обработки данных В принципе возможно непосредственное обращение клиентского приложения, отвечающего за представление результатов анализа данных, к хранилищу данных. Однако в этом случае в нем должны быть реализованы средства такого анализа, то есть по существу оно должно быть OLAP-средством. При всей простоте такого подхода к реализации OLAP он не лишен недостатков, связанных с ограничениями, налагаемыми на число измерений и количество членов в них. У серверных OLAP-средств таких недостатков нет. Поэтому более прогрессивным представляется подход, основанный на применении серверных OLAPсредств в качестве промежуточного звена между хранилищем данных в 20 виде реляционной СУБД и клиентским приложением. В этом случае OLAP-сервер должен превращать данные из реляционного хранилища в форму, более удобную для создания аналитических отчетов – в OLAPкубы. Хранилища данных Необходимость в хранилищах данных диктуется, прежде всего, тем, что анализировать данные оперативных систем напрямую невозможно или очень затруднительно. Это объясняется следующими причинами: разрозненностью данных, хранением их в форматах различных СУБД и в разных файлах корпоративной сети. Но даже если на предприятии все данные хранятся на центральном сервере БД (что бывает крайне редко), аналитику трудно разобраться в их сложных, подчас запутанных структурах; сложностью аналитических запросов к оперативной информации, которые тормозят текущую работу предприятия, надолго блокируя таблицы и захватывая ресурсы сервера; невозможностью получения быстрого отклика на сформулированные запросы. Задача хранилища – предоставить данные для анализа в одном месте и в простой, понятной структуре. Специализированные хранилища данных (ХД) являются наиболее предпочтительным решением, поскольку их структура и функционирование специально оптимизируются для работы с аналитической платформой. Большинство ХД обеспечивают высокую скорость обмена 21 данными с аналитическими приложениями, автоматически поддерживают целостность и непротиворечивость данных. Главное преимущество ХД перед остальными типами источников данных – наличие семантического слоя, который дает пользователю возможность оперировать терминами предметной области для формирования аналитических запросов к хранилищу. Хранилище данных – разновидность систем хранения, ориентированная на поддержку процесса анализа данных, обеспечивающая целостность, непротиворечивость и хронологию данных, а также высокую скорость выполнения аналитических запросов. Важнейшим элементом ХД является семантический слой – механизм, позволяющий аналитику оперировать данными посредством бизнес-терминов предметной области. Семантический слой дает пользователю возможность сосредоточиться на анализе и не задумываться о механизмах получения данных. Многомерные хранилища данных В основе построения многомерных хранилищ данных МХД лежит многомерная модель данных, которая опирается на концепцию многомерных кубов – гиперкубов. Эти кубы представляют собой упорядоченные многомерные массивы, называемые также многомерными OLAP-кубами. OLAP-серверы, или серверы многомерных БД могут хранить свои многомерные данные по-разному. В хранилище данных, наряду с детальными данными, извлекаемыми из оперативных систем, хранятся и суммарные показатели (агрегированные показатели, агрегаты), такие как суммы объемов продаж по месяцам, по категориям 22 товаров и т. п. Агрегаты хранятся в явном виде с единственной целью – ускорить выполнение запросов. В хранилище накапливается, как правило, очень большой объем данных, а аналитиков в большинстве случаев интересуют не детальные, а обобщенные показатели. И если каждый раз для вычисления суммы продаж за год пришлось бы суммировать миллионы индивидуальных продаж, скорость, скорее всего, была бы неприемлемой. Поэтому при загрузке данных в многомерную БД вычисляются и сохраняются все суммарные показатели или их часть. В результате скорость обработки запросов к суммарным данным достигает приемлемых показателей, однако за это приходится платить увеличением объемов данных и времени на их загрузку. Причем объем может увеличиваться в десятки раз. Степень "разбухания" данных при вычислении агрегатов зависит от количества измерений куба и структуры этих измерений, т. е. количества иерархий и уровней измерений. Для решения проблемы хранения агрегатов применяются подчас сложные схемы, позволяющие при вычислении далеко не всех возможных агрегатов достигать значительного повышения производительности выполнения запросов. Реляционные хранилища данных Применение реляционной модели при создании ХД в ряде случаев позволяет получить преимущества над многомерной технологией, особенно в части эффективности работы с большими массивами данных и использования памяти компьютера. На основе реляционных хранилищ данных (РХД) строятся ROLAP-системы, и эта идея, так же как разра- 23 ботка реляционной модели для баз данных принадлежит англоамериканскому ученому Э. Кодду. Напомним, что реляционная база данных (relational database) – совокупность отношений, содержащих всю информацию, которая должна храниться в базе. Физически это выражается в том, что информация хранится в виде двумерных таблиц, связанных с помощью ключевых полей. В основе технологии РХД лежит принцип, в соответствии с которым измерения хранятся в одних обычных плоских таблицах реляционных СУБД, а факты (агрегируемые данные) – в других отдельных таблицах этой же базы данных. При этом таблица фактов является основой для связанных с ней таблиц измерений. Она содержит количественные характеристики объектов и событий, совокупность которых предполагается в дальнейшем анализировать. Схемы построения РХД На логическом уровне различают две схемы построения РХД – «звезда» и «снежинка». При использовании схемы «звезда» многомерный куб представлен в хранилище таблицей фактов, с которой связаны все таблицы измерений. Измерения в таблице фактов представлены кодами. Данные для каждого измерения берутся из таблицы-справочника, в котором коду соответствует значение измерения. Размещение информация о каждом измерении в отдельной таблице упрощает их просмотр, а саму схему делает логически прозрачной и понятной пользователю (рис. 6). 24 Рис. 6. Схема построения РХД «звезда» Измерения OLAP существуют независимо от кубов OLAP и в приложениях OLAP могут быть использованы в нескольких кубах (рис.7). Для более эффективной работы с иерархическими измерениями была разработана модификация схемы «звезда», которая получила название «снежинка». Главной особенностью схемы «снежинка» является то, что информация об одном измерении может храниться в нескольких связанных таблицах. Например, если продаваемые товары объединены в группы (имеет место иерархия), то придется тем или иным способом показать, к какой группе относится каждый товар. 25 Рис. 7. Схемы использования одних и тех же измерений в двух кубах Использование одной таблицы приведет к многократному повторению названий групп для различных товаров. Это не только вызовет рост избыточности, но и повысит вероятность возникновения противоречий. Выделение характеристик групп в отдельную связанную таблицу позволит избежать этого. Таким образом, если хотя бы одна из таблиц измерений ссылается на другую таблицу измерений, говорят о применении схемы «снежинка» (рис. 8). 26 Рис. 8. Схема построения РХД «снежинка» Основное функциональное отличие схемы «снежинка» от схемы «звезда» – это явное выделение и возможность работы с иерархическими уровнями, определяющими степень детализации данных. В приведенном примере схема «снежинка» позволяет работать с данными на уровне максимальной детализации, например с каждым товаром отдельно, или использовать обобщенное представление по группам товаров с соответствующей агрегацией фактов. Выбор схемы для построения РХД зависит от используемых механизмов сбора и обработки данных. Каждая из схем имеет свои преимущества и недостатки, которые, однако, могут проявляться в большей или меньшей степени в зависимости от особенностей функционирова- 27 ния ХД в целом. Простота и логическая прозрачность модели схемы «звезда» являются несомненным ее преимуществом. Преимущества схемы «снежинка» таковы: схема ближе к представлению данных в многомерной модели; процедура загрузки из РХД в многомерные структуры более эффективна и проста, поскольку загрузка производится из отдельных таблиц; намного ниже вероятность появления ошибок, несоответствия данных; большая, по сравнению со схемой «звезда», компактность представления данных, поскольку все значения измерений упоминаются только один раз. К недостаткам схемы «снежинка» можно отнести более слож- ную для реализации и понимания структуру данных. РХД обладает следующими преимуществами: практически неограниченный объем хранимых данных; поскольку реляционные СУБД лежат в основе построения многих систем оперативной обработки (OLTP), которые обычно являются главными источниками данных для ХД, использование реляционной модели позволяет упростить процедуру загрузки и интеграции данных в хранилище; при добавлении новых измерений данных нет необходимости выполнять сложную физическую реорганизацию хранилища, в отличие от многомерных ХД; обеспечиваются высокий уровень защиты данных и широкие возможности разграничения прав доступа. Главный недостаток реляционных хранилищ данных заключа- ется в том, что при использовании высокого уровня обобщения данных и иерархичности измерений в таких хранилищах начинает значительно увеличиваться число таблиц агрегатов. В результате скорость выполнения запросов реляционным хранилищем замедляется. 28 В то же время в многомерных хранилищах, где данные хранятся в виде многомерных кубов, эта проблема практически не возникает и в большинстве случаев удается достичь более высокой скорости выполнения запросов. Таким образом, выбор реляционной модели при построении ХД целесообразен в следующих случаях. Значителен объем хранимых данных (многомерные ХД становятся неэффективными). Иерархия измерений несложная (другими словами, немного агрегированных данных). Требуется частое изменение размерности данных. При использовании реляционной модели можно ограничиться добавлением новых таблиц, а для многомерной модели придется выполнять сложную перестройку физической структуры хранилища. Гибридные хранилища данных Для обеспечения высокой производительности, характерной для многомерных моделей, и сохранения возможности эффективно работать со сколь угодно большими массивами данных, присущей реляционным моделям, была предложена гибридная модель хранилища данных – ГХД. Если данные, поступающие из OLTP-системы, имеют большой объем (несколько десятков тысяч записей в день и более) и высокую степень детализации, а для анализа используются в основном обобщенные данные, гибридная архитектура хранилища оказывается наиболее подходящей. Например, в гипермаркете, который ежедневно обслуживает десятки тысяч покупателей, используется OLTP-система. При этом в реляционной системе регистрируются детальные данные о покупке. По каждому чеку указываются коды, наименования, цена, стоимость това- 29 ров и общая сумма покупки. С точки зрения анализа представляют интерес обобщенные данные: по группам товаров, неделям, месяцам. Поэтому исходные детализированные данные агрегируются и вычисленные агрегаты сохраняются в многомерной структуре ГХД. На рис. 9 представлена схема гибридного хранилища данных. Рис. 9. Гибридное хранилище данных Недостатком гибридной модели является усложнение администрирования ХД из-за более сложного регламента его пополнения, поскольку при этом необходимо согласовывать изменения в реляционной и многомерной структурах. Однако ряд преимуществ делают гибридную модель ХД привлекательной. Хранение данных в реляционной структуре делает их в большей степени системно независимыми, что особенно важно при использовании в управлении предприятием экономической информации (показателей). Реляционная структура формирует устойчивые и непротиворечивые опорные точки для многомерного хранилища. Поскольку реляционное хранилище поддерживает актуальность и корректность данных, оно обеспечивает очень надежный 30 транспортный уровень для доставки информации в многомерное хранилище. Витрины данных Очень часто для анализа требуется не вся информация, содержащаяся в ХД, а только та, которая касается направления деятельности конкретного отдела, подразделения, а может быть и аналитика. При этом объем такой тематической информации невелик по сравнению с общим объемом хранилища и вполне эффективно может обслуживаться MOLAP-системой. Для выделения профильных данных в отдельный набор и организации их хранения в отдельной многомерной БД, подключенной к централизованному РХД, используются витрины данных (data marts). Использование в витрине данных небольшого объема многомерной модели обеспечивает более быстрый отклик на запросы, хотя в некоторых случаях используется и реляционная модель. На рис. 10 изображена система с использованием витрин данных. Использование витрин данных обеспечивает конечному пользователю следующие преимущества: содержание данных тематически ориентировано на конкретного пользователя; относительно небольшой объем хранимых данных, на организацию и поддержку которых не требуется значительных затрат; уменьшение времени отклика на запросы; улучшенные возможности в разграничении прав доступа пользователей, так как каждый из них работает только со своей витриной и имеет доступ только к информации, относящейся к определенному направлению деятельности; 31 Рис. 10. Централизованное хранилище данных с витринами данных снижение нагрузки на централизованное ХД; повышение достоверности данных, получаемых пользователями витрин, поскольку они получают данные из хранилищ, где автоматически поддерживается целостность и непротиворечивость данных и производится их очистка. Использование витрин данных наиболее эффективно в крупных организациях с большим количеством независимых подразделений, каждое из которых решает собственные аналитические задачи. В этом случае витрины данных могут применяться как самостоятельно, так и вместе с централизованным ХД. Следует отметить, что использование самостоятельных витрин данных сопряжено с такой проблемой, как многократное дублирование данных в различных витринах. 32 В настоящее время концепция витрин данных находит очень широкое применение при построении систем бизнес-аналитики, особенно для многопрофильных предприятий со сложной организационной структурой. Виртуальные хранилища данных В основе виртуальных хранилищ данных (ВХД) лежит использование для анализа данных непосредственно из локальных источников, внешнего окружения, баз данных и учетных систем, не консолидируя их в единое ХД физически. При этом данные извлекаются, преобразуются и интегрируются непосредственно при выполнении запроса в оперативной памяти компьютера. Фактически запросы адресуются непосредственно к источникам данных. Виртуальное хранилище эмулирует работу обычного хранилища данных, извлекая, преобразуя и интегрируя данные непосредственно в процессе выполнения запроса. ВХД существует только до тех пор, пока работает соответствующее приложение. Как только оно завершает работу, виртуальное хранилище прекращает существование. Использование ВХД не требует создания, как правило, дорогостоящих хранилищ и гарантирует актуальность данных, в то время как в хранилище они загружаются в соответствии с определенным регламентом. В то же время обращения аналитиков с нерегламентированными запросами увеличивают нагрузку на OLTP-систему, что может привести к потере производительность OLTP-системы. Делается практически невозможной работа с данными, накопленными за долгий период времени, поскольку в ВХД доступны данные только в пределах некоторого периода актуальности (как правило, в пределах отчетного 33 периода). OLTP-системы не хранят исторические данные. Кроме того, использование в источниках данных в различных форматах и кодировках может привести к ошибкам при их обработке и искажению информации, полученной в ответ на запрос. Применение ВХД целесообразно для предприятий, которые не имеют технических средств и квалифицированного персонала для поддержки физических ХД. Особенно велики преимущества ВХД при необходимости анализировать самую свежую информацию. В ВХД отсутствует этап загрузки данных, поэтому временной интервал между появлением информации в OLTP-системе и ее готовностью к анализу данных минимален. При этом следует учитывать, что, поскольку ВХД поддерживает историческую информацию только за период актуальности OLTP-систем, применение такого хранилища оправданно лишь тогда, когда исторические данные для анализа не требуются. Технические аспекты многомерного хранения данных OLAP-функциональность может быть реализована различными способами, начиная с простейших средств анализа данных в офисных приложениях и заканчивая распределенными аналитическими системами, основанными на серверных продуктах. В первом случае речь идет об OLAP-средствах, встроенных в настольные приложения и, как правило, обеспечивающих многомерное представление данных. Такие средства имеют множество ограничений: на количество измерений, на допустимые иерархии и так далее. К подобным средствам, например, относится модуль Pivot Table, позволяющий работать с кубами в Microsoft Excel. Pivot Table входит в Microsoft Office. Данные могут извлекаться и непосредственно из реляционной 34 СУБД. Очевидно, что эти средства целесообразно использовать для решения несложных аналитических задач на незначительных объемах данных. Во втором случае применяют двухступенчатую схему клиент/сервер. Сервер обеспечивает извлечение информации из СУБД или хранилища данные, необходимые для создания кубов. Серверный компонент инструмента OLAP должен быть достаточно интеллектуальным и обладать способностью строить общую концептуальную схему на основе обобщения и консолидации различных логических и физических схем корпоративных баз данных для обеспечения эффекта прозрачности. Специализированное же приложение-клиент предназначено для удобного и эффективного просмотра кубов и выявления аналитических закономерностей. В линейке продуктов Microsoft серверная часть представлена службой Analysis Services, которые входят в Microsoft SQL Server. Полноценные OLAP-серверы включены в СУБД Oracle, Informix и др. Все эти OLAP-продукты поддерживают реляционное, многомерное хранение, а также смешанный вид хранения данных. IT-менеджеры могут приобрести OLAP-сервер той же марки, что и основной сервер баз данных. В качестве клиента может быть использован MS Office Excel. Слой многомерной обработки часто встроен и в OLAP-сервер. Преимущества и недостатки использования хранилищ данных Главным преимуществом, которое дает использование хранилищ данных в аналитических технологиях, является повышение эффективности и достоверности анализа данных, особенно для поддержки принятия стратегических решений. Это достигается за счет оптимизации скорости доступа к данным, возможности интеграции данных раз- 35 личных форматов и типов, автоматической поддержки целостности и непротиворечивости, обеспечения хронологии и истории данных. Тем не менее некоторые организации не используют хранилища данных для консолидации анализируемой информации. При необходимости выполнения анализа данные загружаются в аналитическое приложение непосредственно из источников, где они содержатся. Причины отказа от использования ХД могут быть следующими: Организация не располагает достаточными для разработки, приобретения и поддержки ХД ресурсами (финансовыми, техническими, кадровыми). Унаследованная система аналитической обработки эффективно функционирует с использованием обычной реляционной СУБД, и руководство не видит смысла в дорогостоящем и трудоемком процессе внедрения ХД. Объем анализируемых данных невелик, а применяемые технологии анализа данных несложны. В частности, не требуется поддержка хронологии данных, для анализа используются только данные за актуальный период и т.д. В некоторых случаях отказ от ХД дает определенные преиму- щества: аналитический процесс становится проще и дешевле; нет необходимости разрабатывать концепцию его внедрения; не нужны сложный процесс ETL (Extraction, Transformation, Loading: извлечение, преобразование, загрузка) и другие сопутствующие затраты. Кроме того, процессы, связанные с поддержкой ХД, – интегрирование данных из различных источников и ETL, если они недостаточно продуманы и некачественно реализованы, способны не только свести на нет все преимущества, которые дает ХД, но и ухудшить ситуацию, породив массу ошибок и проблем с получением данных. Возможно также, что лучше 36 быстро реализовать аналитический процесс в упрощенном варианте, чем годами отлаживать взаимодействие OLTP-систем с ХД. Подготовка данных к анализу Ценность и достоверность анализа бизнес-данных зависит не только от эффективности используемых аналитических методов и алгоритмов, но и от того, насколько правильно подобраны и подготовлены исходные данные для анализа. Данные на предприятии могут быть расположены в различных источниках самых разнообразных форматов и типов. Они могут храниться в учетных системах («1С:Предприятие», «Галактика» и др.), в базах данных (MS SQL Server, Oracle, Access, dBase), в отдельных файлах офисных документов (Excel, Word, обычных текстовых файлах) и др. Для правильной обработки и анализа данные, как правило, требуют подготовки, поскольку в них имеются пропуски, дубликаты, аномальные значения и противоречия, они могут быть избыточными или, наоборот, недостаточными. Поэтому, прежде чем приступать к анализу данных, необходимо выполнить ряд процедур, цель которых – доведение данных до приемлемого уровня качества и информативности, а также организовать их интегрированное хранение в структурах, обеспечивающих их целостность, непротиворечивость, высокую скорость и гибкость выполнения аналитических запросов. Для извлечения данных из разнотипных источников, приведения их к единому формату, оценки их качества, очистки, обогащения и загрузки их в соответствующую базу или хранилище данных с целью дальнейшей аналитической обработки предназначен комплекс программных средств, называемый ETL-системой (Extraction, 37 Transformation, Loading: извлечение, преобразование, загрузка). Процесс в ETL-системе определяет последовательность операций при загрузке хранилища данных из источников данных. При этом крайне важно четко представлять структуру исходных данных и данных назначения. Приложения ETL извлекают информацию из исходных баз данных и др. источников, преобразуют ее в единый формат, поддерживаемый базой данных назначения или хранилищем данных, а затем загружают в него преобразованную информацию. Для того чтобы инициировать процесс ETL, применяются программы извлечения записей данных из исходных источников и подготовки информации, хранящейся в этих записях, к процессу преобразования. Чтобы извлечь данные из исходного источника, можно создать собственные программы, обратиться к готовому специализированному инструментарию ETL или использовать сочетание и того и другого. Во многих случаях существующий инструментарий ETL способен удовлетворить большую часть требований к переносу данных. В общем случае процесс ETL преобразует совокупность таблиц оперативной системы и дополнительных источников в многомерную модель хранилища данных с требуемыми измерениями. Движение данных от источника к приёмнику называют потоком данных. Необходимые потоки данных формирует и описывает аналитик. На рис. 11 представлен ETL-процесс консолидации данных с целью их дальнейшего анализа. Консолидация данных является начальным этапом реализации любой аналитической задачи или проекта. В основе консолидации лежит процесс сбора и организации хранения данных в виде, оптимальном с точки зрения их обработки на конкретной аналитической платформе 38 или решения конкретной аналитической задачи. Сопутствующими задачами консолидации являются оценка качества данных и их обогащение. Рис. 11. Обобщенная схема ETL-процесса консолидации данных 39 Процесс консолидации начинается с определения источника данных – объекта, содержащего структурированные данные, которые могут оказаться полезными для решения аналитической задачи. Необходимо, чтобы используемая аналитическая платформа могла осуществлять доступ к данным из этого объекта непосредственно либо после их преобразования. Поскольку аналитические приложения, как правило, не содержат развитых средств ввода и редактирования данных, а работают с уже сформированными выборками, формирование массивов данных для анализа является задачей систем подготовки данных для анализа. Процесс консолидации начинается с определения источника данных – объекта, содержащего структурированные данные, которые могут оказаться полезными для решения аналитической задачи. Необходимо, чтобы используемая аналитическая платформа могла осуществлять доступ к данным из этого объекта непосредственно либо после их преобразования. Поскольку аналитические приложения, как правило, не содержат развитых средств ввода и редактирования данных, а работают с уже сформированными выборками, формирование массивов данных для анализа является задачей систем подготовки данных для анализа. Массивы данных, подготовленные для анализа, должны обеспечивать: высокую скорость доступа к данным; компактность хранения; автоматическую поддержку целостности структур данных; контроль непротиворечивости данных. Основные задачи консолидации данных В процессе консолидации данных решаются следующие задачи: выбор используемых источников данных и извлечение данных из разнотипных источников; 40 разработка стратегии консолидации; оценка качества данных; очистка; обогащение; перенос в хранилище данных. Процесс сбора, хранения и оперативной обработки данных на типичном предприятии обычно содержит несколько уровней. На верхнем уровне располагаются реляционные SQL-ориентированные СУБД типа Microsoft SQL Server, Oracle и т.д. На втором – файловые серверы с некоторой системой оперативной обработки или сетевые версии персональных СУБД типа Access, dBase, FoxPro и т.д. И наконец, на самом нижнем уровне расположены локальные ПК отдельных пользователей с персональными источниками данных. Чаще всего информация на них собирается в виде файлов офисных приложений – Word, Excel, текстовых файлов. Для данных, сохраняемых в базах данных различных СУБД, обеспечивается высокая скорость доступа к данным, компактность представления, поддерживается целостность данных, поскольку тип и свойства их полей жестко задаются при построении таблиц. В то же время для создания и администрирования БД требуются специалисты с высоким уровнем подготовки. Если исходные данные хранятся в отдельных файлах офисных приложений, они должны быть организованы в виде столбцов и записей. Столбцы должны содержать данные одного типа, например только текстовые или только числовые. Такие источники создаются и редактируются с помощью простых и общедоступных офисных приложений, которые не требуют высокой квалификации персонала и высокой производительности систем. Однако они далеко не всегда обеспечивают нужную скорость доступа к данным, компактность представления и 41 поддержку структурной целостности данных. Кроме того, пользователи офисных приложений могут допускать ошибки, пропуски, вводить противоречивые данные и т.д., использовать неверные типы данных и не связывать вводимые ими данные с задачами будущего анализа. Например, пользователь табличного процессора может разместить в одном столбце данные различных типов (числовые и текстовые), что впоследствии обязательно приведет к проблемам при их обработке в аналитическом приложении. Следует отметить, что текстовые файлы имеют произвольную структуру данных, поэтому они наиболее уязвимы с точки зрения нарушения структуры, использования некорректных форматов и представлений данных. Поэтому загрузка и очистка текстовых файлов может вызвать самые серьезные проблемы, несмотря на то что эти файлы очень просты в создании. Несмотря на то что возможность загрузки данных из файлов Excel предусмотрена практически в любой аналитической системе, следует учитывать, что в одном столбце таблицы Excel могут содержаться данные различных типов и форматов, допускаться неправильное использование разделителей целой и дробной частей. Поэтому к ним следует относиться так же внимательно, как и к данным из текстовых файлов. Данные реляционных СУБД вызывают меньше всего проблем для пользователей аналитических систем. Структура данных в таблицах реляционных СУБД жестко задана, поля строго типизированы, форматы данных соответствуют стандартам. В большинстве СУБД поддерживается автоматический контроль целостности, непротиворечивости и уникальности данных. Для загрузки данных, например из файла Access, 42 достаточно указать имя файла и таблицу, из которой нужно взять данные. Из источников данных всех уровней информация в соответствии с некоторым регламентом должна перемещаться в хранилище данных. Для этого необходимо обеспечить выгрузку данных из источников, провести их преобразование к виду, соответствующему структуре хранилища данных, а при необходимости выполнить их очистку и обогащение. Выбрав источники, содержащие исходные данные, которые могут иметь отношение к решаемым задачам, определяют, как будут храниться данные для анализа и методику организации доступа к ним. Определяют способ организации хранения данных. При этом выбранное решение должно обеспечивать оптимизацию структуры и функционирования хранилища данных специально для работы с аналитической платформой, обеспечение высокой скорости обмена данными с аналитическими приложениями, автоматическую поддержку целостности и непротиворечивости данных. Главное преимущество хранилищ данных перед остальными типами источников данных для аналитических систем – наличие семантического слоя, который дает пользователю возможность оперировать терминами предметной области для формирования аналитических запросов к хранилищу. Извлечение данных из источников самых разнообразных типов связано с проблемами преобразования форматов данных, созданных в различных приложениях и, возможно, использующих различную кодировку, в единый универсальный формат, который поддерживается хранилищем данных и аналитическим приложением. Кроме того, данные в источниках обычно излишне детализированы, тогда как для решения задач анализа в большинстве случаев требуются обобщенные данные, и 43 исходные данные, как правило, содержат различные факторы, которые мешают их корректному анализу. При разработке стратегии консолидации данных необходимо учитывать характер расположения источников данных – локальный, когда они размещены на том же ПК, что и аналитическое приложение, либо удаленный, если источники доступны только через локальную или глобальную компьютерные сети. Характер расположения источников данных может существенно повлиять на качество собранных данных (несогласованность во времени обновления, противоречивость и т.д.). Другой важной задачей, которую требуется решить в рамках консолидации, является оценка качества данных с точки зрения их пригодности для обработки с помощью различных аналитических алгоритмов и методов. В большинстве случаев исходные данные содержат факторы, не позволяющие их корректно анализировать, устанавливать связи между элементами данных и выполнять другие действия, которые могут потребоваться для получения аналитического решения. К таким факторам относятся ошибки ввода, пропуски, аномальные значения, шумы, противоречия и т.д. Поэтому перед тем, как приступить к анализу данных, необходимо оценить их качество и соответствие требованиям, предъявляемым аналитической платформой. Если в процессе оценки качества будут выявлены факторы, которые не позволяют корректно применить к данным те или иные аналитические методы, необходимо выполнить соответствующую очистку данных. Очистка данных – комплекс методов и процедур, направленных на устранение причин, мешающих корректной обработке: аномалий, пропусков, дубликатов, противоречий, шумов и т.д. Если данные содержат недостаточно информации для удовлетворительного решения определенной задачи анализа, необходимо дополнить 44 данные некоторой информацией, позволяющей повысить информационную насыщенность и, как следствие, значимость для решения аналитической задачи. Такой процесс дополнения данных называется обогащением. Поскольку ХД могут строиться на основе различных моделей данных (многомерных, реляционных, гибридных), процесс ETL должен разрабатываться с учетом всех особенностей используемой в хранилище данных модели. Кроме того, желательно, чтобы ETL-система была универсальной, то есть могла извлекать и переносить данные как можно большего числа типов и форматов. Таким образом, консолидация данных является сложной многоступенчатой процедурой и важнейшей составляющей аналитического процесса, обеспечивающей высокий уровень аналитических решений. Процесс ETL – извлечение, преобразование, загрузка Независимо от особенностей построения и функционирования ETL-система должна обеспечивать выполнение трех основных этапов процесса переноса данных (ETL-процесса). Извлечение данных. На этом этапе данные извлекаются из одного или нескольких источников и подготавливаются к преобразованию. При этом они загружаются в промежуточную область, как правило, в виде вспомогательных таблиц, и подвергаются проверке на соответствие спецификациям и возможность последующей загрузки в хранилище данных. Следует отметить, что для корректного представления данных после их загрузки в хранилище данных из источников должны извлекаться не только сами данные, но и информация, описывающая их структуру, из которой будут сформированы метаданные для хранилища. Преобразование данных. Производится преобразование форматов и кодировки данных, а также их обобщение и очистка. В 45 процессе преобразования данные группируются и преобразуются к виду, соответствующему структуре хранилища данных. Загрузка данных – запись преобразованных данных в соответствующую систему хранения. Данные распределяются на несколько потоков в соответствии с особенностями организации процесса их загрузки и загружаются в хранилище-получатель. Требования к организации данных описываются аналитиком. Опытный аналитик знает особенности и характер данных, циркулирующих на различных уровнях корпоративной информационной системы, частоту их обновления, степень «загрязненности», уровень их значимости и т.д. Это дает ему возможность с помощью комбинации различных методов преобразования данных в ETL добиться достаточного уровня обобщения и качества данных, попавших в хранилище, выбрать оптимальный регламент и технические требования его пополнения. Последнее особенно важно для организаций со сложной многоуровневой филиальной структурой и большим количеством подразделений. Таким образом, ETL следует рассматривать не только как процесс переноса данных из одного приложения в другое, но и как инструмент их подготовки к анализу. Извлечение данных в ETL При разработке процедуры извлечения данных прежде всего необходимо определить регламент загрузки ХД и соответственно частоту выгрузки данных из OLTP-систем или отдельных источников. Выгрузка может производиться по истечении заданного временного интервала (день, неделя, месяц или квартал). Время выгрузки данных зависит от объема извлекаемых данных, сложности доступа к ним и скорости работы оборудования. В периоды выгрузки может резко увеличиваться нагрузка на компьютерную сеть организации, возрасти время ожидания 46 отклика в OLTP-системе. Для минимального влияния выгрузки на рабочий процесс время выбирают, например, в обеденный перерыв, сразу по завершении рабочего дня или ночью. Если выгрузку данных производить более часто, то количество выгрузок увеличивается, но поскольку за меньший период в OLTPсистеме накапливается меньше изменений, время выгрузки становится короче и нагрузка на систему – ниже. Для извлечения данных можно использовать специализированные программные средства или средства той системы, в которой они хранятся. После извлечения данные помещаются в так называемую промежуточную область, где для каждого источника данных создается своя таблица или отдельный файл. В некоторых случаях, когда требуется выгрузить данные из нескольких источников одного типа, для них создается общая таблица; одно из ее полей указывает на источник, из которого были взяты данные. Пример подобной выгрузки приведен на рис. 12. Рис. 12. Схема организации выгрузки 47 В процессе извлечения данных используется имя набора данных, из которого следует извлечь записи; номер записи, с которой начинается извлечение; количество извлекаемых записей; формат представления данных; максимальная длина записи, доступная для извлечения, и т.д. При извлечении данных необходимо определить, все ли имеющиеся в источниках данные нужны в хранилище данных. Если извлекать нужно не все записи подряд, а только определенные, аналитик может описать набор условий, которые позволят отобрать только записи, представляющие интерес. Например, можно поставить условие, что записи, которые содержат информацию о продажах на сумму меньше заданной, извлекать и помещать в хранилище данных не нужно, поскольку их влияние на результат анализа ничтожно. При начальной загрузке хранилища требуется определить глубину выгрузки – период времени, в котором извлекаемая информация является актуальной для анализа. В простейшем случае, когда никаких соображений на этот счет нет, можно загрузить все имеющиеся записи. Однако этот подход не всегда оптимален, поскольку в хранилище может оказаться много информации, не представляющей ценности для анализа в связи с потерей актуальности. Таким образом, выбор глубины выгрузки исторических данных должен обеспечить компромисс между объемом выгружаемых данных и их ценностью с точки зрения анализа. В процессе пополнения хранилища данных из источников должны извлекаться лишь те записи, которые добавлялись или изменялись после прошлого извлечения. При повторных загрузках ХД важно не только определить глубину выгрузки, но и организовать поиск измененных данных. Для этой цели разработаны различные методики, например использование меток времени для каждой измененной записи. 48 Если источником данных является реляционная СУБД, то часто используются триггеры (triggers) – специальные процедуры, запускаемые автоматически при выполнении операций вставки, обновления или удаления. Триггеры позволяют сохранять измененные записи в специальной таблице изменений, из которой они могут быть извлечены при следующей выгрузке. Однако использование триггеров может увеличивать нагрузку на систему. Преобразование данных в ETL В процессе извлечения данные из источников загружаются в промежуточную область, где и хранятся в виде таблиц. На следующем этапе ETL-процесса выполняется преобразование данных, их подготовка к загрузке в ХД и приведение их к виду, наиболее удобному для последующего анализа. В процессе преобразования может быть задействован самый разнообразный инструментарий, начиная от простейших средств ручного редактирования данных до систем, реализующих весьма сложные методы обработки и очистки данных. В процессе преобразования данных в рамках ETL чаще всего выполняются следующие операции, представленные на рис. 13. Рис. 13. Процесс преобразования данных в ETL Агрегирование данных. Общим свойством всех ранее перечисленных источников с исходными данными является то, что они со- 49 держат данные с максимальной степенью детализации – сведения о каждом факте продажи в отдельности, об обслуживании каждого клиента и т.д. Элементарные события, из которых состоит бизнес-процесс, которые также называют атомарными (неделимыми), по своей сути являются случайными величинами, подверженными влиянию множества различных случайных факторов. Следовательно, информация о каждом отдельном событии в бизнес-процессе практически не имеет ценности. Действительно, на основании информации о продажах за один день нельзя сделать вывод обо всех особенностях торговли. Точно так же нельзя выработать стратегию работы с клиентами на основе исследования поведения одного клиента. Иными словами, для достоверного описания предметной области использование данных с максимальным уровнем детализации не всегда целесообразно, поэтому наибольший интерес для анализа представляют данные, обобщенные по некоторому интервалу времени, по группе клиентов, товаров и т.д. Такие обобщенные данные называются агрегированными (агрегатами), а сам процесс их вычисления – агрегированием. При этом многочисленные детальные данные заменяются относительно небольшим числом агрегированных данных. Например, данные о продажах за год занимают в БД несколько тысяч записей. После агрегирования данные преобразуются в меньшее число записей с агрегированными значениями, которые будут перенесены в хранилище. Например, вместо информации о каждой из 365 ежедневных продаж в году в результате агрегирования будут храниться 52 записи с обобщением по неделям, 12 – по месяцам или 1 – за год. Если цель анализа – разработка прогноза продаж, то для краткосрочного оперативного прогноза достаточно использовать данные по неделям, а для долгосрочного стратегического прогноза – по месяцам или даже по годам. 50 Фактически при агрегировании производится группировка нескольких записей и объединение их в одну с вычислением агрегированного значения на основе значений каждой записи. При вычислении агрегатов может быть использована одна из статистических функций. Сумма: группа агрегируемых записей заменяется одной, в которой указывается сумма агрегируемых значений. Среднее: для группы агрегируемых записей вычисляется среднее значение, которое и заменяет все записи группы. Максимум, Минимум: в результирующей записи остается максимальное, минимальное значение некоторого поля из всех агрегируемых записей. Количество уникальных значений: результатом агрегирования будет число уникальных значений, появляющихся в ячейках одного и того же поля. Количество: результатом агрегирования будет число записей, содержащихся в группе агрегируемых записей. Медиана: вычисляется медиана агрегируемых значений. Медиана представляет собой порядковую статистику, рассчитываемую следующим образом. Набор агрегируемых значений, например продажи по дням недели, сортируется в порядке возрастания. Тогда медианой будет центральный элемент упорядоченного набора, если этот набор содержит нечетное количество значений или среднее двух центральных элементов, если число элементов четное. Выбор нужных агрегатов всегда определяется особенностями бизнеса. При этом следует помнить, что агрегаты, требуемые для анализа, могут быть вычислены и непосредственно при выполнении аналитического запроса к хранилищу данных. Увеличение числа агрегатов в ХД приводит к увеличению его размеров и сложности структуры данных. Снижение числа агрегатов в ХД может увеличить время ожидания пользователя при выполнении аналитических запросов. Следовательно, 51 необходимо обеспечить разумный компромисс между этими факторами и создавать только те агрегаты, которые с большой долей вероятности понадобятся при анализе данных. Перевод значений. Данные в источниках часто хранятся в закодированном виде, что позволяет сократить избыточность данных и объем памяти для их хранения. Так, наименования объектов, их свойств и признаков могут храниться в сокращенном виде. В этом случае перед загрузкой данных в хранилище требуется заменить такие сокращенные значения на более понятные. Например, согласно заведенному в организации порядку идентификационный номер операции может быть закодирован в виде 06–04– 12–62, где 06–04 – число и месяц, 12 – код товара, 62 – код региона. Для заполнения соответствующих измерений в многомерной модели такую компактную запись необходимо декодировать. Кроме того, часто возникает необходимость преобразовать числовые данные, например, вещественные в целые, уменьшить избыточную точность представления чисел и т.д. Создание новых данных. В процессе загрузки в ХД может понадобиться вычисление некоторых новых данных на основе существующих, что обычно сопровождается созданием новых полей. Например, OLTP-система содержит поля о количестве и цене проданного товара, а в целевой таблице хранилища данных есть поле Сумма. Тогда в процессе преобразования необходимо вычислить сумму как произведение цены на количество проданных единиц товара. Таким образом, будет создано поле, содержащее новую информацию. Еще одним возможным примером новых данных, создаваемых в процессе обработки, являются экономические, финансовые и другие показатели, которые могут быть вычислены на основе имеющихся дан- 52 ных. Так, на основе данных о продажах можно рассчитать рейтинг популярности товаров и создать новое поле, в котором для каждого товара будет указано соответствующее рейтинговое значение (например, по пятибалльной системе). Создание новых данных на основе имеющихся тесно связано с таким важным процессом, как обогащение данных, которое может производиться на этапе преобразования данных в ETL. Агрегирование также может рассматриваться как создание новых данных. Очистка данных в ETL Очистка данных обязательна при их переносе в хранилище. Сбор данных в процессе ETL производится из большого числа источников, многие из которых не содержат автоматических средств поддержки целостности, непротиворечивости и корректного представления данных. В связи с этим данные могут стать причиной неправильных результатов анализа и даже сделать невозможным применение некоторых аналитических алгоритмов и методов. Поэтому при разработке стратегии ETL очистке уделяется большое внимание. Очистка данных – одна из наиболее важных и в то же время наиболее сложных и трудно поддающихся формализации задач ETL-процесса. Особое внимание уделяется данным, содержащим критичные ошибки, из-за которых они в принципе не могут быть загружены в хранилище данных: нарушения структуры и некорректные форматы данных (например, буква или пробел в числовом значении, неправильный разделитель целой и дробной частей числа и т.д.). Критичными являются ошибки, которые делают невозможной дальнейшую работу с данными. Следует отметить, что, помимо очистки данных перед их загрузкой в хранилище, пользователь может выполнить дополнительную очистку средствами аналитической системы уже 53 после выполнения запроса к ХД. Такое дублирование вполне оправданно, поскольку некоторые виды ошибок (например, пропуски, противоречия и дубликаты) могут быть обнаружены только после консолидации данных. Кроме того, в ряде случаев целесообразность применения того или иного метода очистки данных может быть определена пользователем, исходя из особенностей конкретной задачи анализа и результатов, полученных по запросу данных из хранилища. Первичная очистка данных в процессе ETL носит в большей степени технический характер и направлена на выявление и удаление ошибок и несоответствий в данных с целью улучшения их качества. Очистка также применяется для согласования полей с атрибутами базы данных назначения. Ее основная задача – подготовить данные к загрузке в хранилище. Вторичная очистка в аналитической системе является пользовательской и направлена на подготовку данных к решению конкретной аналитической задачи. Выявляются данные с ошибками, не критичными с точки зрения их загрузки в хранилище, но при этом некорректными с точки зрения их анализа (аномальные значения, пропуски, дубликаты, противоречия и т.д.). Поэтому оба этапа очистки одинаково важны и необходимы. Наиболее широко распространены проблемы, из-за которых данные нуждаются в очистке, связанные с нарушением структуры данных: корректность форматов и представлений данных; уникальность первичных ключей в таблицах БД; полнота и целостность данных; полнота связей; соответствие некоторым аналитическим ограничениям. 54 Для каждого структурного уровня данных – отдельной ячейки, записи, целой таблицы, отдельной БД или множества БД – характерны свои факторы, снижающие качество данных. Обогащение данных Очевидно, что данные, собираемые для задач анализа, должны быть полными и достоверными, поскольку на основе неполных или недостоверных данных нельзя сделать правильные выводы о состоянии бизнеса и путях его совершенствования. Помимо достоверности и полноты данных, существует еще один фактор, непосредственно влияющий на эффективность их анализа, – информационная насыщенность. Обогащение данных – процесс насыщения данных новой информацией, которая позволяет сделать их более ценными и значимыми с точки зрения решения той или иной аналитической задачи. Можно выделить два основных метода обогащения данных – внешнее обогащение и внутреннее. Внешнее обогащение предполагает привлечение дополнительной информации из внешних источников. Повышение значимости данных означает, что на основе их анализа можно будет принимать управленческие решения принципиально нового уровня. Например, обычные данные о текущей работе предприятия позволяют оптимизировать товарные потоки, работу с клиентами, политику скидок, гарантий и т.д. Поскольку у конкурентов тоже созданы аналитические службы, больших конкурентных преимуществ анализ только оперативной информации не принесет. Поднять работу предприятия на качественно новый уровень и существенно увеличить продажи, а соответственно, и прибыль можно 55 на основании результатов стратегического анализа. Для поддержки успешного решения стратегических бизнес-задач необходимо использовать соответствующий уровень анализа данных. Данных из обычных OLTP или учетных систем предприятия для такого анализа, как правило, недостаточно. В этом случае следует привлекать дополнительную информацию из внешних источников. Она позволит обогатить внутренние данные, имеющиеся в распоряжении аналитиков фирмы, до уровня информативности и значимости, который позволит решать задачи стратегического анализа с соответствующим уровнем достоверности. Внешними источниками могут быть: другие предприятия и организации, работающие в этой же сфере деятельности или в смежных сферах, причем как партнеры, так и конкуренты; финансово-кредитные учреждения, банки, страховые компании; государственные налоговые и статистические службы; органы государственного и муниципального управления; различные службы социальной сферы: миграционная служба, органы труда и занятости, система здравоохранения, пенсионные фонды и т.д. Внутреннее обогащение не предполагает привлечения внеш- ней информации. В этом случае повышение информативности и значимости данных может быть достигнуто за счет изменения их организации. Не следует путать внутреннее обогащение с обычным преобразованием данных, выполняемым в процессе их загрузки в ХД или при подготовке к анализу в аналитическом приложении. Преобразование данных изначально связано с оптимизацией занимаемого ими объема, скорости доступа к ним, удобства представления для пользователя, обеспечения целостности и непротиворечивости данных, удаления факторов, которые мешают их корректно обрабатывать, и т.д. Такая обра- 56 ботка не преследует цель обогатить данные информацией, а только решает определенные технические проблемы. Внутреннее обогащение обычно связано с получением и включением в набор данных полезной информации, которая отсутствует в явном виде, но может быть тем или иным способом получена с помощью манипуляций с имеющимися данными. Затем эта информация встраивается в виде новых полей или даже таблиц в ХД и может быть использована для дальнейшего анализа. Для обогащения данных также может использоваться информация, полученная в процессе их анализа. Рассмотрим пример внутреннего обогащения. Руководство предприятия поставило задачу выработать новую политику взаимодействия с поставщиками в зависимости от их надежности. Были разработаны критерии, в соответствии с которыми определялась степень надежности поставщиков, в результате чего все поставщики разбивались на три категории – надежные, средние и ненадежные. Степень надежности конкретного поставщика определялась как отношение общего числа дней задержки поставок за квартал к стоимости поставок. То есть поставщик, часто задерживающий мелкие поставки, но в целом соблюдающий график серьезных поставок, будет рассматриваться как надежный партнер. В то же время поставщик, который задерживает крупные поставки, пусть даже и редко, но соблюдает график мелких поставок, будет рассматриваться как потенциально ненадежный партнер. Информацию о задержках и суммах поставок можно получить из документов о поступлении товара в учетной системе. После соответствующих вычислений и сравнений в таблицу ХД, где находится информация о поставщиках, будет добавлено новое поле, в котором для каждого из них будет указана категория надежности. Дальнейший анализ в области поставок может производиться с использованием новых данных. 57 Таким же образом можно создавать рейтинги сотрудников для их поощрения и продвижения по службе, рейтинги популярности товаров и т.д. Применение обогащения данных из внешних источников обычно связано со сбором информации об объектах предметной области, участвующих в исследуемом бизнес-процессе. Для предприятий и организаций это могут быть экономические показатели (прибыль, численность работников, объем продаж и др.). При исследовании клиентов – физических лиц наибольший интерес представляют признаки, позволяющие распределить их по группам, например с точки зрения их активности как покупателей или потребителей каких-либо услуг. В этом случае выясняются пол, возраст, род занятий и увлечений, наличие семьи и детей, медиапредпочтения и т.д. Например, сеть магазинов, торгующих недорогой повседневной одеждой, решила провести рекламную кампанию с целью привлечения большего числа покупателей. При этом организаторы кампании посчитали, что реклама должна быть направлена на те категории населения, которые являются самыми активными клиентами. Чтобы узнать, представители каких слоев общества наиболее активно приобретают товары этой сети магазинов, были проведены следующие мероприятия. Клиентам предлагалась дисконтная карта, при получении которой нужно было заполнить анкету и указать пол, возраст, профессию, семейное положение, род занятий, увлечения, наличие детей, предпочтения в стилях одежды. Затем по номеру дисконтной карты контролировались продажи. По итогам квартала были сопоставлены анкетные данные и собранная информация о продажах. В результате выяснилось, что более 70 % клиентов сети магазинов составляют студенты и молодые специалисты в возрасте до 25–27 лет, предпочитающие современный стиль в одежде 58 и ведущие активный образ жизни. Поэтому рекламную кампанию было решено направить именно на эту категорию клиентов. Обогащение – один из важнейших этапов подготовки данных к анализу. Использование этой процедуры во многих случаях позволяет поднять качество анализа на принципиально новый уровень, особенно при решении нестандартных задач, даже в условиях недостаточной информативности данных, поступающих из OLTP и учетных систем. Кроме того, обогащение данных в какой-то мере позволяет компенсировать просчеты в стратегии сбора и консолидации аналитических данных. Загрузка данных в хранилище После того как данные извлечены из различных источников и выполнены преобразование, агрегация и очистка данных, осуществляется последний этап ETL – загрузка данных в хранилище. Процесс загрузки заключается в переносе данных из промежуточных таблиц в структуры хранилища данных. От продуманности и оптимальности процесса загрузки данных во многом зависит время, требуемое для полного цикла обновления данных в хранилище, а также полнота и корректность данных в хранилище. Первыми в процессе загрузки данных в хранилище обычно загружаются таблицы измерений, которые содержат ключи и описательную информацию, необходимую для таблиц фактов. При загрузке таблиц измерений требуется добавлять новые записи и изменять существующие. Например, измерение Клиент может содержать десятки тысяч клиентов, при этом информация меняется только для незначительного их числа (не более 10%). Нужно добавить данные о новых клиентах и одновременно модифицировать информацию о существующих. 59 После завершения загрузки, перед тем как сделать их доступными для анализа, полезно убедиться в их корректности и достоверности. Для этого целесообразно после загрузки данных в хранилище выполнить дополнительные операции, которые позволят сравнивать данные как в различных разрезах, так и с источниками данных. Например: итоговый показатель за месяц должен соответствовать сумме ежедневных или еженедельных показателей в этом месяце; суммарная выручка по всем регионам за текущий месяц должна соответствовать сумме продаж по всем региональным дилерским центрам. Типичные задачи, решаемые на базе OLAP-технологий OLAP-технологии используют различные организации – промышленные, торговые, финансовые, научные, сферы услуг и другие – для решения типичных задач. Такие решения позволяют получить единую и непротиворечивую картину работы предприятия, необходимую для принятия решений, проанализировать тенденции в работе. Торговые организации исследуют объемы продаж в разрезе номенклатуры товаров и торговых марок, анализируют тенденции динамики продажи товаров за определенный период времени. Например, в сфере продаж с применением OLAP-технологий можно получить сравнительные характеристики торговых точек в разные периоды времени, с разной номенклатурой продукции, с разной сезонностью и т.д.; выполнить сравнение результатов продаж во времени, или за заданный период, или для заданной группы товаров, сравнение объемов продаж разных товаров во времени, выявить тенденции, сезонные колебания; ана- 60 лиз структуры продаж для выявления важнейших составляющих в интересующем разрезе. В торговле, наряду с продажами, обычно в OLAP-системе анализируются закупки, склады. Задачи анализа закупок противоположны анализу продаж. Многие предприятия закупают комплектующие и материалы у поставщиков. Торговые предприятия закупают товары для перепродажи. Возможных задач при анализе закупок множество: от планирования денежных средств на основе прошлого опыта до контроля за менеджерами, выбирающими поставщиков. Анализ структуры товарного запаса на складах в разрезе видов товаров, складов, анализ сроков хранения товаров, анализ отгрузки по получателям, выявление неликвидных товарных запасов и многие другие важные для предприятия виды анализов актуальны при наличии в организации складского учета. Финансовые учреждения анализируют внутреннюю отчетность банка, бюджетирование, активы и пассивы и клиентскую базу, следят за работой филиалов. В банках решения на базе OLAP-технологий позволяют автоматизировать процессы выработки решений по клиентам банка, находить закономерности в огромных объемах данных и эффективно управлять рисками, на основе информации об ежедневных остатках на расчетных счетах клиентов прогнозировать остатки на будущее. Производственные предприятия применяют OLAP-системы для контроля отгрузки товаров по сотням показателей номенклатуры, проводят сверку налоговой отчетности. Важное значение приобретает аналитика отношений с клиентами и конкурентами, аналитика в сфере персонала. 61 Государственные организации, накапливая в хранилищах данных огромные массивы, используют эти данные для анализа, например структуры населения страны или региона в различных разрезах, кадастра земель, паспортов предприятий и т. п. Маркетинговые и консалтинговые фирмы предоставляют отчеты об исследованиях рынка, выполненные по технологии OLAP, своим клиентам. Различные информационные агентства, инвестиционные компании, электронные биржи, интернет-магазины, фонды предоставляют своим клиентам всевозможные сводки и отчеты, подготовленные с помощью OLAP-инструментов. Разработка и развертывание приложений бизнес-аналитики средствами аналитической службы Microsoft SQL Server В этом разделе рассматривается работа с OLAP-системой клиент/серверной архитектуры. Сервер обеспечивает извлечение информации из реляционных хранилищ данных, создание измерений и кубов, а также доступ к ним из клиентских приложений. Приложение Клиент обеспечивает удобный и эффективный просмотр кубов и выявление аналитических закономерностей. В линейке программных продуктов Microsoft серверная часть OLAP-системы представлена – аналитической службой Microsoft SQL Server 2005 Analysis Services (SSAS), а клиентская часть Microsoft Office Excel. Заметим, что службы SSAS включают не только средства оперативного анализа 62 данных (OLAP), но и средства интеллектуального анализа данных Data Mining. Analysis Services предназначен для разработки, обслуживания и развертывания сложных приложений бизнес-аналитики (business intelligence – BI), обеспечивающих выполнение всестороннего анализа данных предприятия. Эта служба обеспечивает проектирование и формирование многомерной модели – кубов OLAP из хранилищ данных и их хранение в многомерной базе данных на сервере, а также доступ к ним из клиентских приложений. Структура данных куба OLAP ориентирована на выполнение оперативного анализа. OLAP-куб, созданный с помощью Analysis Services, может содержать все данные из таблицы фактов плюс агрегатные значения для тех групп записей из этой таблицы, которые соответствуют уровням иерархии измерений. Данные с нижних уровней иерархии могут храниться в самом кубе, что соответствует способу хранения данных Multidimensional OLAP, или они будут считываться из таблицы фактов хранилища данных, что соответствует способам хранения данных Relational OLAP и Hybrid OLAP. С точки зрения пользователя, различий между этими способами хранения нет, не считая разницы в производительности обращающихся к этим кубам приложений. При добавлении в таблицу фактов новых записей можно выполнить динамическое обновление куба. Использование в качестве клиента Excel обеспечивает работу аналитика с многомерной моделью. С помощью Excel можно обращаться к серверным OLAP-кубам, получая их сечения на листах рабочих книг Excel в виде отчетов сводных таблиц и диаграмм, а также создавать локальные OLAP-кубы в виде файлов. Excel легко интегрируется с Analysis Services и играет центральную роль в обеспечении конечных пользователей инструментами 63 для анализа данных: создания отчетов сводных таблиц и диаграмм, а также алгоритмов добычи данных. Приложения, предназначенные для чтения OLAP-данных, при взаимодействии с аналитическими службами обязательно используют PivotTable Service – библиотеки, загружаемые в адресное пространство клиентского приложения. Эти библиотеки автоматически устанавливаются вместе с аналитическими службами, а также вместе с Microsoft Office. PivotTable Service можно использовать для просмотра серверных OLAP-кубов, а также для создания, модификации и чтения локальных OLAP-кубов, созданных в клиентском приложении, реализуя таким образом клиентскую OLAP-функциональность. Для взаимодействия с PivotTable Service клиентское приложение может использовать OLE DB for OLAP – расширение универсального механизма доступа к данным OLE DB, позволяющее обращаться к многомерным данным, а также ADO MD – библиотеки, представляющие собой надстройку над OLE DB for OLAP и являющиеся COMсерверами для доступа к многомерным данным, удобным для применения в клиентских приложениях. Analysis Services 2005 ориентирован на большие объемы данных, сохраняемых в многочисленных и разнородных источниках, и позволяет создать аналитическую инфраструктуру с нуля. Концепции, реализованные в Analysis Services, позволяют рассматривать хранилище данных как систему, которая получает бизнес-данные из оперативных баз данных предприятия и других источников и трансформирует их в структуру, подходящую для анализа данных. К по-новому структурированным и организованным данным применяются математические операции, позволяющие сделать их максимально полезными для принятия 64 решений по различным вопросам. Данные делаются доступными пользователю для эффективного просмотра и получения ответов на деловые запросы за минимальное время. Программный продукт Analysis Services является средством бизнес-аналитики промышленного класса, предназначенным для разработки, создания, тестирования и развертывания многомерных баз данных и управления ими. Инструментом разработки многомерной базы данных в BIпроекте, в которой определяются кубы данных, измерения и другие объекты оперативного анализа данных, является устанавливаемая вместе с Analysis Services утилита Business Intelligence Development Studio (BIDS), интегрированная в Microsoft Visual Studio и доступная из меню. Для работы с многомерными кубами Analysis Services поддерживает язык запросов к многомерным данным – MDX (MultiDimensional eXpressions), подобный SQL, который служит для создания запросов в реляционных базах данных. MDX является основным инструментом программирования для Microsoft SQL Server Analysis Services. Язык MDX является компонентом OLE DB для спецификации OLAP и поддерживается другими производителями средств аналитики. В Analysis Services 2005 для взаимодействия клиента с сервером аналитики используется спецификация XML\A (XML for Analysis). Инструменты самого Analysis Services 2005 также обращаются к серверу с помощью XML\A. После того как разработана многомерная база данных, на сервер отправляется ее описание. При этом инструменты Analysis Services используют XML\A. Использование в качестве коммуникационного интерфейса, связывающего клиента с Analysis Services, XML способствует функциональной совместимости между различными клиентами и Analysis Services. 65 Рассмотрим разработку и развертывание проекта служб Analysis Services, обеспечивающего выполнение оперативного анализа деятельности некоторого предприятия Adventure Works Cycles, занимающейся продажами велосипедов. В качестве источника данных проекта используется учебная реляционная база данных AdventureWorksDW, поставляемая в комплекте с Microsoft SQL Server 2005. База данных AdventureWorksDW содержит информацию о продажах продукции компанией. В приведенных ниже заданиях рассматривается создание проекта для анализа интернет-продаж на основе таблицы фактов FactResellerSales и связанных с ней таблиц измерений. При этом показано, как выполнить определение источников данных и их представлений, фактов, измерений, атрибутов, иерархий и кубов в проекте служб Analysis Services в среде BI Development Studio. Кроме того, объясняется, как просмотреть данные куба с помощью проекта служб Analysis Services, развернутого на экземпляре Analysis Services, и как впоследствии заполнять развернутые объекты данными из базового источника данных. Показано, как изменять меры, измерения, иерархии, атрибуты и группы мер в проекте служб Analysis Services. Примечание. Для успешного выполнения заданий необходимо быть членом локальной группы Администраторы на компьютере с установленными службами Analysis Services или членом роли Сервер в экземпляре Analysis Services. Кроме того, необходимо иметь разрешения на чтение в базе данных SQL Server 2005 AdventureWorks DW. Задание 1. Создание проекта, источника данных и представления Создать новый проект Microsoft SQL Server 2005 Analysis Services (SSAS) под именем “Учебный проект”, основанный на шаблоне 66 проекта служб Analysis Services, используя среду Business Intelligence Development Studio. Создание нового проекта служб Analysis Services 1. Нажмите кнопку Пуск и последовательно выберите пункты Все программы, Microsoft SQL Server 2005 и SQL Server Business Intelligence Development Studio. Будет открыта среда разработки Microsoft Visual Studio 2005. 2. Закройте вкладку Start Page. В меню File среды Visual Studio последовательно выберите команды New и Project. 3. В диалоговом окне New Project выбирается один из типов проектов. Для создания проекта аналитики на панели Project types выберите значение Business Intelligence Projects, а на панели Templates укажите Analysis Services Project. Обратите внимание, что в нижней части этого диалогового окна отображаются установленные по умолчанию имя проекта, имя решения и путь к проекту. По умолчанию для решения создается новый каталог. Решение может содержать несколько проектов. 4. Измените имя проекта на “Учебный проект” (при этом изменится и имя решения) и нажмите кнопку ОК. На этом создание проекта служб Analysis Services в рамках но- вого решения завершается. На рис. 14 показан “Учебный проект” в среде разработки Visual Studio. Окно Solution Explorer (Обозреватель решений) содержит определения объектов проекта аналитики: Data Sources (Источники данных), Data Source Views (Представления источников данных), Cubes (Кубы), Dimensions (Измерения), Mining Structures (Структуры интеллектуаль- 67 ного анализа данных), Roles (Роли) и Assembles (Сборки). Объекты создаются на основе сведений, содержащихся в шаблоне, использованном при создании проекта. Для всех типов объектов в проекте создаются папки. В окне Properties (Свойства) можно просмотреть и настроить свойства объекта, выбранного в окне Solution Explorer. Рис. 14. Учебный проект в среде разработки Visual Studio Примечание. Для контекстной подсказки используется окно динамической справки. Его содержимое изменяется в зависимости от текущего положения курсора или указателя мыши и помогает пользователю освоиться с новым приложением. 68 Определение источника данных Работа с проектом начинается с определения одного или нескольких источников данных, которые будут использоваться в этом проекте. При работе в реальных системах бизнес-анализа, как правило, необходимо использовать несколько реляционных источников данных. Основными источниками данных для баз данных Analysis Services являются реляционные базы данных Microsoft SQL Server, DB2 фирмы IBM, Taradata и Oracle. Информация обо всех источниках данных, необходимых для построения кубов и измерений внутри базы данных, хранится в базе данных Analysis Services 2005 в совокупности объектов Data Sources. Используйте для проекта в качестве источника данных базу данных AdventureWorksDW, которая расположена на SQL Server. 1. В обозревателе решений – Solution Explorer в контекстном меню элемента Data Sources (Источники данных) выберите команду New Data Source (Создать источник данных). Откроется мастер источников данных. 2. В окне Data Source Wizard (Мастер источников данных) нажмите кнопку Next (Далее). 3. В окне Select how to define the connection (Выбор метода определения соединения) убедитесь, что установлен флажок Create a Data Source based on an existing or new connection (Создать источник данных на основе существующего или нового соединения), а затем нажмите кнопку New (Создать). Появится диалоговое окно Connection Manager (Диспетчер со- единений). 69 4. В списке Provider (Поставщик) убедитесь, что выбран Native OLE DB\SQL Native Client (Собственный поставщик данных OLE DB\Собственный клиент SQL). 5. В текстовом поле Server name (Имя сервера) введите, например, sirius-c. 6. Убедитесь, что выбран параметр Use Windows Authentication (Использовать проверку подлинности Windows). В списке Select or enter a database name (Выберите или введите имя базы данных) выберите AdventureWorksDW. На рис. 15 показано окно Connection Manager (Диспетчер со- единений) с конфигурацией выбранных параметров. Рис. 15. Выбор в качестве источника данных базы AdventureWorksDW 70 7. Нажмите кнопку ОК, а затем нажмите кнопку Next (Далее). Появится окно Impersonation Information (Сведения об олицетворении). 8. Выберите параметр Use the service account (Использовать учетную запись службы) и нажмите кнопку Next (Далее). На рис. 16 показано окно Completing the Wizard (Завершение работы мастера). Рис. 16. Окно завершения работы мастера определения источника данных 9. Нажмите кнопку Finish (Готово), чтобы создать новый источник данных с именем Adventure Works DW. 71 На рис. 17 показан новый источник данных в папке Date Sources (Источники данных) в обозревателе решений. На этом завершается определение источника данных Adventure Works DW для проекта. Примечание. Чтобы изменить свойства существующего источника данных, дважды щелкните этот источник в папке Date Sources (Источники данных). Откроется окно Date Source Designer (Конструктор источников данных). Рис. 17. Отображение созданного источника данных в обозревателе решений 72 Определение представления источника данных После определения источников данных, используемых в проекте служб Analysis Services, определяется представление источника данных для этого проекта. Представление создается на метаданных, определенных в качестве источника данных для проекта и указанных в конкретных таблицах и представлениях. Хранение метаданных в представлении источника данных позволяет работать с метаданными в процессе разработки, не устанавливая соединений с базовыми источниками данных. Кроме того, такое представление позволяет в процессе разработки кубов обеспечить визуализацию структуры: отображение схемы, содержащей факты и измерения. Определите представление источника данных, которое содержит пять таблиц из базы данных Adventure Works DW, образующих схему звезда. Одна из таблиц является таблицей фактов, а четыре оставшихся – связанными с ней таблицами измерений. Схема “звезда” иллюстрирует отношения между необходимыми для анализа бизнесобъектами в простой и доступной для понимания форме. 1. В обозревателе решений в контекстном меню Data source Views (Представления источников данных) выберите New Data source View (Создать представление источника данных). Откроется мастер представлений источников данных. 2. В окне Welcome to the Data source View Wizard (Вас приветствует мастер представления источника данных) нажмите кнопку Next (Далее). Будет открыто окно Select a Data Source (Выбор источника данных). В группе Relational data sources (Источник реляционных данных) выбран источник данных Adventure Works DW. 3. Нажмите кнопку Next (Далее). 73 Появится окно Select Tables and Views (Выбор таблиц и представлений). Здесь можно выбрать таблицы и представления из списка объектов, доступных в выбранном источнике данных. 4. В списке Available Objects (Доступные объекты) выберите следующие таблицы, удерживая нажатой клавишу CTRL, чтобы одновременно выбрать несколько таблиц. 5. dbo.DimCustomer dbo.DimGeography dbo.DimProduct dbo.DimTime dbo.FactInternetSales Нажмите кнопку >, чтобы добавить выбранные таблицы к списку Included Objects (Включенные объекты). На рис. 18 показано окно Select Tables and Views (Выбор таблиц и представлений) после добавления таблиц в список включенных объектов. 6. Нажмите кнопку Next (Далее), а затем кнопку Finish (Готово), чтобы определить представление источника данных Adventure Works DW. Представление источника данных Adventure Works DW будет выведено в папке Data source Views (Представления источников данных) обозревателя решений. Содержимое представления источника данных отображается в конструкторе представлений источников данных в среде Business Intelligence Development Studio. В этом конструкторе содержатся следующие элементы: Панель Diagram (Диаграмма), на которой представлены в графическом виде таблицы и их связи. 74 Панель Tables (Таблицы), на которой отображаются в виде дерева таблицы и их поля. Панель Diagram Organizer (Организатор схем), на которой можно создавать вложенные диаграммы, позволяющие просматривать поднаборы этого представления источника данных. Панель инструментов конструктора представлений источников данных Рис. 18. Выбор таблиц представления источника данных На рис. 19 показано представление источника данных Adventure Works DW в окне конструктора представления источника данных Adventure Works DW. dsv (Design)*. 75 7. Нажмите кнопку Развернуть, чтобы развернуть окно среды разработки Microsoft Visual Studio. 8. На панели инструментов в верхней части конструктора представлений источников данных щелкните Zoom 50% (Масштаб), чтобы просмотреть таблицы на панели Diagram (Диаграмма) в масштабе 50%. При этом будут скрыты сведения в полях таблиц. Рис. 19. Представление источника данных Adventure Works DW 9. Нажмите кнопку Auto Hide (Автоматически скрыть), на которой изображен значок кнопки, в заголовке обозревателя решений. 76 Обозреватель решений будет свернут и примет вид вкладки, расположенной в правой части среды разработки. Чтобы вернуться в обозреватель решений, установите указатель мыши на вкладке Solution Explorer (Обозреватель решений). Чтобы раскрыть обозреватель решений, вновь нажмите кнопку Auto Hide (Автоматически скрыть). 10. Нажмите кнопку Auto Hide (Автоматически скрыть) в заголовке окна свойств, если по умолчанию это окно не скрыто. Теперь все таблицы и связи между ними можно легко просматривать на панели Диаграмма. Обратите внимание, что имеется целых три связи между таблицами FactInternetSales и DimTime. С каждой продажей связано три даты: дата заказа, дата оплаты и дата отгрузки. Чтобы просмотреть подробные сведения по связи, дважды щелкните стрелку этой связи на панели Диаграмма. На рис. 20 показана панель Диаграмма в конструкторе представлений источников данных после выполнения в задании пунктов 7-10. На этом завершается создание представления источника данных Adventure Works DW, в котором содержатся метаданные из пяти таблиц этого источника данных. Для добавления таблиц в существующее представление источника данных щелкните правой кнопкой мыши панель Диаграмма или панель Таблицы, а затем выберите команду Add\Remove Tables (Добавить или удалить таблицы). Чтобы не усложнять представление источника данных, всегда добавляйте в него только те таблицы и 77 представления, которые действительно будут использоваться в проекте. Рис. 20. Представление источника данных в конструкторе Изменение имен таблиц по умолчанию Метаданные для таблиц, находящихся в представлении источника данных, создаются на основе метаданных для этих объектов в базовых источниках данных. В среде BI Development Studio метаданные 78 объектов в представлении источника данных используются для определения измерений, атрибутов и групп мер. Однако вместо свойства Name используется свойство FriendlyName. В представлении источника данных можно изменять значение свойств объектов FriendlyName, чтобы сделать более понятными имена объектов, создаваемых в этом представлении. Имена этих объектов можно изменять и после того, как они были определены. Измените имена каждой таблицы в представлении источника данных DW Adventure Works, удалив из названий этих таблиц префиксы «dim» и «fact». Примечание. Также в представлении источника данных можно присваивать понятные имена столбцам, определять вычисляемые столбцы, соединять таблицы и представления, чтобы сделать их более удобными в работе. 1. На панели Диаграмма в окне Конструктора представления источника данных щелкните правой кнопкой мыши таблицу FactInternetSales и выберите команду Properties (Свойства). 2. Измените свойство FriendlyName объекта FactInternetSales на InternetSales. Изменение будет применено, если щелкнуть вне ячейки свойства FriendlyName. 3. В окне Properties (Свойства) в поле списка последовательно выбирайте таблицы, затем изменяйте свойство FriendlyName, указав новое значение. На рис. 21. показано представление источника данных, содержащее измененные имена объектов. 79 Рис. 21. Представление источника данных с измененными именами объектов 4. В меню File (Файл) или на панели инструментов среды BI Development Studio выберите команду Save All (Сохранить все). При этом будут сохранены изменения, внесенные к текущему моменту в проекте служб Analysis Services, что позволяет прервать разработку и возобновить ее позже. 80 Задание 2. Создание OLAP-куба После определения в проекте представления источника данных можно создать OLAP-куб. При разработке проекта, состоящего из нескольких кубов, в которых совместно используются измерения из общей базы данных, обычно в первую очередь определяют эти измерения на уровне базы данных, а затем определяют один или несколько кубов, которые используют эти измерения. Используя мастера кубов в среде BI Development Studio, можно определить куб и его измерения за один проход. Создайте с помощью мастера куб, основанный на ранее определенном источнике данных. При этом будут созданы атрибуты и определены иерархии измерений, а также назначено измерение времени, столбцы которого будут сопоставлены со свойствами времени. 1. В обозревателе решений в контекстном меню элемента Cubes (Кубы) выберите команду New Cube (Создать куб). 2. На странице мастера кубов Welcome to the Cube Wizard (Вас приветствует мастер кубов) нажмите кнопку Next (Далее). 3. В окне Select Build Method (Выбор метода построения) убедитесь, что выбраны параметры Build the Cube using a data source (Построить куб с использованием источника данных) и Auto build (Автоматическое построение). В поле Auto build выберите Create Attributes and Hierarchies (Создание атрибутов и иерархий) нажмите кнопку Next (Далее). 4. В окне Select Data Source View (Выбор представления источника данных) убедитесь, что выбрано представление источника данных Adventure Works DW. Примечание. Если при сборке кубов в мастере на странице Select Data Source View (Выбор представления источника данных) нажать 81 кнопку Finish (Готово), мастер самостоятельно определит все оставшиеся свойства куба. После этого откроется страница Завершение работы мастера, на которой можно дать название созданному кубу и просмотреть его структуру. Мастер настроит куб с использованием параметров по умолчанию и данных, запрошенных из объекта базового источника данных. 5. Нажмите кнопку Next (Далее), чтобы продолжить работу с мастером и изменить заданные мастером параметры куба. Мастер просматривает таблицы базы данных, которые определе- ны в объекте источника данных, чтобы идентифицировать таблицы фактов и измерений. Таблицы фактов содержат интересующие меры, такие как количество проданных единиц. Таблицы измерений содержат сведения об этих мерах, таких как проданный товар, месяц продажи и так далее. 6. В окне Detecting Fact and Dimension Tables (Определение таблиц фактов и измерений) нажмите кнопку Next (Далее), когда мастер закончит поиск таблиц фактов и измерений. 7. В окне Identify Fact and Dimension Tables (Определение таблиц фактов и измерений) будут выведены найденные мастером таблицы. В разрабатываемом проекте мастер выявил четыре таблицы из- мерений и одну таблицу фактов. Для таблицы фактов определена группа мер. Если обнаружены несколько таблиц фактов, будут определены несколько групп мер. Каждая таблица измерения должна быть связана с таблицей фактов того же куба. Таблицы измерений имеют один из следующих типов связей. Прямая связь типа «первичный ключ – внешний ключ» с таблицей фактов. Такая связь называется схемой “звезда”. 82 Косвенная связь типа «первичный ключ – внешний ключ» с таблицей фактов через другую таблицу. Такая связь называется схемой «снежинка». На рис. 22 показано окно Identify Fact and Dimension Tables (Определение таблиц фактов и измерений) с выбранными для проекта таблицами фактов и таблицами измерений. Рис. 22. Определение таблиц фактов и измерений 8. В окне Identify Fact and Dimension Tables (Определение таблиц фактов и измерений) в списке Time Dimension Table (Таблица измерения времени) выберите значение Time (Время) и нажмите кнопку Next (Далее). 83 9. В окне Select Time Periods (Выбор временных периодов) сопоставьте имена свойств времени со столбцами таблицы измерения, которая является базовой для этого измерения, в результате чего это измерение будет выбрано как измерение Time. Сопоставьте свойства в соответствии со следующим ниже списком. Сопоставьте свойство Year (Год) со столбцом CalendarYear. Сопоставьте свойство Half Year (Полугодие) со столбцом CalendarSemester. Сопоставьте свойство Quarter (Квартал) со столбцом CalendarQuarter. Сопоставьте свойство Month (Месяц) со столбцом EnglishMonthName. Сопоставьте свойство Date (Дата) со столбцом FullDateAlternateKey. На рис. 23 показано выполненное в мастере кубов сопоставление. 10. Нажмите кнопку Next (Далее), чтобы перейти к следующему окну мастера. Будет открыто окно Select Measures (Выбор мер), в котором отображаются меры, выбранные мастером. Мастер выбрал в качестве мер все числовые поля в таблице фактов, которые не связаны с измерениями. В этом проекте определена только одна группа мер. 11. В окне Select Measures (Выбор мер) просмотрите выбранные меры в группе мер Internet Sales и снимите флажки для следующих мер: Promotion Key. Currency Key. Sales Territory Key. Revision Number. 84 Рис. 23. Сопоставление имен свойств времени с полями таблицы измерения Time Эти четыре столбца не являются фактическими мерами. Первые три представляют собой ключевые значения, связывающие таблицу фактов с таблицами измерений, которые не используются в этом кубе. На рис. 24 показаны снятые флажки и оставшиеся выбранными меры в окне Select Measures (Выбор мер). 85 Рис. 24. Выбор мер в таблице фактов FactInternetSales 12. Нажмите кнопку Next (Далее). Далее мастер начнет просмотр иерархий, так как ранее был выбран параметр Auto build (Автоматическое построение). При этом сравнивают записи в каждом поле таблиц, указанных как таблицы измерений, чтобы определить наличие иерархических связей между этими полями. Иерархическая связь представляет собой связь «многие к одному», такая связь, например, существует между городом и штатом. 13. В окне Detecting Hierarchies (Поиск иерархий), после того как мастер закончит просмотр измерений и выявление иерархий, нажмите кнопку Next (Далее). 86 14. В окне Review New Dimensions (Просмотр новых измерений) просмотрите структуру иерархий трех измерений, раскрывая узлы списка в виде дерева, с помощью которого можно просматривать иерархии и атрибуты, обнаруженные мастером в каждом из измерений. На рис. 25 показаны три измерения, определенные мастером. Рис. 25. Измерения, в которых обнаружены иерархические связи между полями 87 15. Раскройте измерение Product, раскройте узел Attributes (Атрибуты) и снимите флажок для параметра Large Photo (Большое фото). Нажмите кнопку Next (Далее). Столбец Large Photo не используется в кубе этого проекта. 16. В окне Completing to Wizard (Завершение работы мастера) измените имя куба на ИнтернетПродажи. Здесь также можно просмотреть группы мер, меры, измерения, иерархии и атрибуты этого куба. 17. Для завершения работы мастера нажмите кнопку Finish (Готово). В обозревателе решений в проекте Учебный проект в папке Cubes (Кубы) появится куб ИнтернетПродажи, а также три измерения базы данных в папке Dimensions (Измерения). Кроме того, в центре среды разработки в конструкторе кубов будет отображен куб ИнтернетПродажи служб Analysis Services. 18. На панели инструментов конструктора кубов измените значение Zoom (Масштаб) на 50 %, чтобы более подробно рассмотреть таблицы измерений и фактов этого куба. На рис. 26 показан вид таблиц измерений и фактов в конструкторе. Обратите внимание, что таблицы фактов выделены желтым цветом, а таблицы измерений – синим. 19. В меню File (Файл) или на панели инструментов среды BI Development Studio выберите команду Save All (Сохранить все). При этом будут сохранены изменения, внесенные к текущему моменту в проект. На этом завершается построение куба. 88 Рис. 26. Куб ИнтернетПродажи в окне конструктора кубов Задание 3. Развертывание проекта и просмотр куба Для просмотра куба проект должен быть развернут. Выполните развертывание проекта в экземпляре служб Analysis Services. Это позволит заполнить куб реальными данными. По завершении разработки проекта бизнес-аналитики обычно используется мастер развертывания служб Analysis Services, который развертывает данные на рабочем сервере. Развертывание проекта создает определенные объекты в экземпляре служб Analysis Services и производит копирование данных из базовых источников данных в объекты куба. 89 1. В обозревателе решений щелкните правой кнопкой мыши проект Учебный проект и выберите команду Deploy (Развернуть) либо выберите команду Deploy Учебный проект (Развернуть Учебный проект) в меню Build (Сборка). В среде BI Development Studio собирается и развертывается проект Учебный проект. Ход выполнения развертывания отображается в окне Deployment Progress – Учебный проект (Выполнение развертывания), где представляются подробные сведения о каждом шаге, выполняемом в процессе развертывания. На рис. 27 показано это окно по завершении развертывания проекта. Рис. 27. Развертывание проекта Учебный проект на сервере 90 Просмотр развернутого куба После успешного развертывания для просмотра данных куба перейдите на вкладку Browser (Обозреватель) конструктора кубов. Вкладка обозревателя содержит три панели – панель Метаданные, панель Фильтр и панель Данные. На рис. 28 выделены отдельные области в конструкторе кубов. Рис. 28. Окно просмотра данных куба Используйте панель Метаданные для анализа структуры куба, представленной в формате дерева. Используйте панель Фильтр для оп- 91 ределения вложенного куба, который необходимо просмотреть. Используйте панель Данные для анализа данных и детализации иерархии измерений. В конструкторе кубов можно быстро просмотреть куб так, как его видят конечные пользователи в средствах для создания отчетов и таких клиентских приложениях, как сводные таблицы Microsoft Office Excel. При просмотре данных куба можно увидеть различные измерения, детализировать их до уровня элементов и осуществить срез измерений. Можно использовать это представление для анализа структуры куба и проверки данных, вычислений, форматирования и безопасности объектов базы данных. 1. В области Метаданные раскройте элемент Measures, раскройте Internet Sales и перетащите меру Sales Amount в область Drop Totals or Detail Fields Here (Перетащите сюда поля итогов или деталей) области Данные. 2. В области Метаданные раскройте узел Customer. Обратите внимание, что в области Метаданные отображаются все иерархии атрибутов в измерении Customer. Список измерения Customer также включает пользовательскую иерархию State Province Name – Geography. Можно использовать любое количество иерархий атрибутов для определения измерений куба. Однако просмотр большого количества иерархий для каждого из измерений на одном уровне может быть обременительным для пользователя. 3. Перетащите иерархию атрибута English Country Region Name в поле Drop Row Fields Here (Перетащите сюда поля строк) области Данные. 92 На рис. 29 показано, как теперь мера Internet Sales упорядочена по странам заказчиков. Рис. 29. Представление сумм продаж по атрибуту измерения – страна заказчиков 4. В области Метаданные сверните элементы Customer и Measures, раскройте элемент Product, щелкните правой кнопкой мыши элемент Product Line и выберите команду Add to Column Area (Добавить в область столбцов). Теперь мера Internet Sales упорядочена по странам и линиям то- варов. Обратите внимание, что каждая линия продуктов отображается одной буквой вместо полного названия линии товаров. 93 На рис. 30 показана мера Internet Sales, упорядоченная по странам и линиям товаров. Рис. 30. Представление сумм продаж по атрибутам двух измерений – страна заказчиков и линия товаров 5. В области Метаданные сверните элемент Product, раскройте элемент Order Date и перетяните Order Date.Calendar Quarter в поле Drop Filter Fields Here (Перетащите сюда поля фильтра) области Данные. 6. В разделе полей фильтра области Данные щелкните направленную вниз стрелку рядом с элементом Order Date.Calendar Quarter, снимите флажок рядом с (All), установите флажок рядом с 1 и нажмите кнопку ОК. Теперь мера Internet Sales упорядочена по странам и линиям то- варов для первого календарного квартала. Однако значения представлены для первого календарного квартала каждого календарного года, а не для отдельного календарного года. На рис. 31 показано распределение меры Internet Sales по странам и линиям товаров для первого квартала каждого года. 94 Рис. 31. Представление сумм продаж по атрибутам трех измерений – странам заказчиков и линиям товаров для первого квартала каждого года 7. В области Метаданные раскройте элемент Order Date.Calendar Year, а затем элемент CalendarYear. 8. Щелкните правой кнопкой мыши элемент 2002 иерархии атрибута Calendar Year и выберите команду Add to Subcube Area (Добавить в область вложенных кубов). Элемент 2002 измерения Order Date отображен в области Фильтр, расположенной над областью Данные. Он ограничивает значения, отображаемые в области Данные. Значения за первый календарный квартал для объемов продаж каждой линии товаров через Интернет, упорядоченные по странам, теперь ограничены 2002 годом, как показано на рис. 32. После завершения просмотра куба закройте проект. Закройте среду разработки кубов. В Microsoft SQL Server Management Studio подключитесь к Analysis Services. Разверните Учебный проект и Cubes ИнтернетПродажи. Откроется Browse (Обозреватель) кубов. 95 Рис. 32. Представление сумм продаж по атрибутам трех измерений – странам заказчиков и линиям товаров для 1 квартала 2002 года В этом окне постройте сводную таблицу для анализа количества заказов (Order Quantity) через Интернет каждой линии товаров, упорядоченных по странам, ограниченных 2 кварталом 2003 года, как показано на рис. 33. Рис. 33. Представление количества заказов по атрибутам трех измерений – странам заказчиков и линиям товаров для 2 квартала 2003 года 96 Задание 4. Изменение мер и измерений Изменение мер Для изменения формата отображения значений мер в представлении куба выполните следующее: 1. Перейдите на вкладку Cube Structure (Структура куба) конструктора кубов, раскройте группу мер Internet Sales на панели Measures (Меры), щелкните правой кнопкой мыши меру Sales Amount и выберите команду Properties (Свойства). 2. В окне свойств в списке FormatString выберите значение Currency (Валюта). При необходимости изменить формат нескольких элементов воспользуйтесь сеткой мер: 3. На панели инструментов вкладки Cube Structure (Структура куба) нажмите кнопку Show Measures Grid (Показывать сетку мер). 4. Выберите несколько следующих мер одновременно, удерживая нажатой клавишу CTRL: 5. Unit Price Extended Amount Discount Amount Product Standard Cost Total Product Cost Tax Amt Freight В окне свойств в списке FormatString выберите значение Currency (Валюта). 97 6. В раскрывающемся списке в верхней части окна свойств выберите меру Unit Price Discount Pct (Процент скидки для цены за единицу), а затем выберите в списке FormatString параметр Percent (Процент). 7. В окне свойств измените свойство Name (Имя) меры Unit Price Discount Pct на Unit Price Discount Percentage. 8. На панели Measures (Меры) щелкните Tax Amount и измените имя меры. Изменение имени меры таким способом аналогично изменению свойства Name (Имя) меры в окне свойств. 9. Нажмите кнопку Show Measures Tree (Показывать дерево мер) на вкладке панели инструментов Cube Structure (Структура куба). 10. В меню Build (Сборка) среды BI Development Studio выберите команду Deploy Учебный проект (Развернуть Учебный проект). Изменения, которые были сделаны в проекте с момента прошлого развертывания, будут развернуты для данного экземпляра служб Analysis Services. 11. После успешного завершения развертывания перейдите на вкладку Browser (Обозреватель) конструктора кубов. 12. Для отображения обновленного куба нажмите кнопку Reconnect (Повторное подключение) на панели инструментов вкладки Browser (Обозреватель). Теперь на панели Данные для меры Sales Amount будут показаны значения в долларах (формат валюты определяется языковым стандартом страны) рис. 34. 98 Рис. 34. Представление сумм продаж после изменения формата отображения 13. В меню File (Файл) выберите команду Save All (Сохранить все). Изменение измерения Customer Некоторые из атрибутов измерения Customer в исходном варианте куба не используются и поэтому могут быть удалены. 1. Переключитесь на измерение Customer в конструкторе кубов в среде BI Development Studio и перейдите на вкладку Dimensions (Структура измерения). 2. В области Atributes (Атрибуты) выберите и удалите следующие атрибуты: Address Line1; Address Line2; Country Region Code; Customer Alternate Key; 99 First Name; French Country Region Name; French Education; French Occupation; Last Name; Middle Name; Name Style; Sales Territory Key; Spanish Country Region Name; Spanish Education; Spanish Occupation; State Province Code; Suffix; Title. Помимо удаления из измерения ненужных атрибутов, можно изменить их имена, а также добавить атрибуты в пользовательскую иерархию или удалить их из нее. По умолчанию уровни в пользовательской иерархии имеют те же имена, что и атрибуты, на которых они основаны. Однако можно переименовать уровень иерархии, при этом имя базового атрибута не изменится. 1. В области Atributes (Атрибуты) щелкните правой кнопкой мыши атрибут English Country Region Name и выберите команду Rename (Переименовать). Измените имя атрибута на Country-Region. 2. Аналогичным образом измените имена следующих атрибутов. o Имя атрибута English Education замените на Education. 100 o Имя атрибута English Occupation замените на Occupation. o Имя атрибута State Province Name замените на StateProvince. 3. В области Иерархии и уровни вкладки Структура измерения выберите иерархию State Province Name – Geography. В окне свойств измените свойство Name (Имя) для этой пользовательской иерархии на Customer Geography. Теперь пользовательская иерархия называется Customer Geography. 4. Перетащите атрибут Country-Region из области Атрибуты в пользовательскую иерархию Customer Geography выше уровня State Province Name. Теперь иерархия Customer Geography содержит уровень Coun- try-Region. 5. В пользовательской иерархии Customer Geography измените имя уровня State Province Name на State-Province. 6. Перетащите атрибут City из области Atributes (Атрибуты) в пользовательскую иерархию Customer Geography выше уровня Customer. Пользовательская иерархия Customer Geography теперь со- держит уровень City. 7. Удалите уровень Geography из пользовательской иерархии Customer Geography. На рис. 35 показаны атрибуты, иерархии и уровни, образован- ные в результате внесения изменений. 101 Рис. 35. Окно создания и изменения иерархий и уровней Изменение измерения Product Для отображения в представлении куба значений атрибута Product Line описательными именами используйте именованные вычисления. Выполните в измерении Product следующее. В окне обозревателя решений дважды щелкните элемент Product узла Dimensions (Измерения), чтобы открыть конструктор измерений для измерения Product. 1. Переключитесь в конструктор представлений источника данных на Adventure Works DW, дважды щелкнув на нем в окне обозревателя решений. 2. На панели Диаграмма щелкните правой кнопкой мыши таблицу Product и выберите пункт New Named Calculation (Создать именованное вычисление). Будет открыто соответствующее диалоговое окно. Это диалого- вое окно позволяет создать именованное вычисление, которое исполь- 102 зуется для отображения полного имени линии товаров вместо кодового имени. 3. В диалоговом окне Create Named Calculation (Создание именованного вычисления) в поле Column Name (Имя столбца) введите ProductLineName. 4. В поле Description (Выражение) введите следующий код SQL: CASE ProductLine WHEN 'M' THEN 'Mountain' WHEN 'R' THEN 'Road' WHEN 'S' THEN 'Accessory' WHEN 'T' THEN 'Touring' ELSE 'Components' END Данный код SQL создает понятные пользователю имена для каждой линии товара в кубе. 5. Нажмите кнопку ОК. Создание именованного вычисления ProductLineName завер- шено. 6. Переключитесь в конструктор измерений на измерение Product, выберите параметр Product Line на панели Atributes (Атрибуты) вкладки Структура измерений, после этого в окне отображения свойств измените значение свойства NameColumn на DimProduct.ProductLineName (WChar) и нажмите кнопку ОК После развертывания проекта элементы атрибута Product Line будут отображать полные имена линий товаров вместо сокращенных. 103 Задание 5. Создание сводной таблицы Excel, связанной с кубом OLAP-сервера Выполните анализ данных куба Analysis Services в отчетах сводных таблиц и диаграмм Microsoft Office Excel. Для подключения книги Excel к базе данных службы Microsoft SQL Server Analysis Services используйте соответствующее задание методических указаний «Хранилища данных и OLAP-системы». Действия по определению макета сводной таблицы Excel и диаграммы, синхронизированной со сводной таблицей, описаны в тех же указаниях. Задание 6. Создание в Excel файла автономного куба из базы данных OLAP-сервера Для выполнения анализа данных с помощью с отчетов сводных таблиц и диаграмм Excel при отсутствии подключения к серверу OLAP создайте на локальном жестком диске или сетевом ресурсе файл автономного куба .CUB, содержащий подмножество данных серверного куба. Соответствующее задание приведено в методических указаниях «Хранилища данных и OLAP-системы». 104 Оглавление Введение ................................................................................................ 2 Основы многомерного представления данных..................................... 6 Многомерные кубы, измерения и меры (факты) .............................. 6 Иерархии и уровни ............................................................................ 8 Операции, выполняемые над кубом.................................................. 9 Архитектура OLAP-систем ................................................................. 14 Требования к приложениям для многомерного анализа ................ 14 Способы хранения данных .............................................................. 17 Хранилища данных ............................................................................. 20 Многомерные хранилища данных .................................................. 21 Реляционные хранилища данных.................................................... 22 Гибридные хранилища данных ....................................................... 28 Витрины данных.............................................................................. 30 Виртуальные хранилища данных .................................................... 32 Технические аспекты многомерного хранения данных ................. 33 Преимущества и недостатки использования хранилищ данных .... 34 Подготовка данных к анализу............................................................. 36 Основные задачи консолидации данных ........................................ 39 Процесс ETL – извлечение, преобразование, загрузка ................... 44 Извлечение данных в ETL............................................................... 45 Преобразование данных в ETL ....................................................... 48 Очистка данных в ETL .................................................................... 52 Обогащение данных ........................................................................ 54 Загрузка данных в хранилище......................................................... 58 Типичные задачи, решаемые на базе OLAP-технологий ................... 59 Разработка и развертывание приложений бизнес-аналитики средствами аналитической службы Microsoft SQL Server ................. 61 Задание 1. Создание проекта, источника данных и представления ............................................................................... 65 Задание 2. Создание OLAP-куба ..................................................... 80 Задание 3. Развертывание проекта и просмотр куба ...................... 88 Задание 4. Изменение мер и измерений .......................................... 96 Задание 5. Создание сводной таблицы Excel, связанной с кубом OLAP-сервера .................................................................................103 Задание 6. Создание в Excel файла автономного куба из базы данных OLAP-сервера ....................................................................103
