Создание бизнес-аналитических структур данных средствами MS SQL Server

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

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

1. Хранилище данных

данная хранилище мicrosoft

Концепция ХД была предложена в начале 90-х годов прошлого столетия как основа методологии организации данных в системах поддержки и принятия решений.

Хранилище данных (англ. Data Warehouse) — предметно-ориентированная информационная база данных, специально разработанная и предназначенная для подготовки отчётов и бизнес-анализа с целью поддержки принятия решений в организации. Строится на базе систем управления базами данных и систем поддержки принятия решений. Данные, поступающие в хранилище данных, как правило, доступны только для чтения. Данные из OLTP-системы копируются в хранилище данных таким образом, чтобы построение отчётов и OLAP-анализ не использовал ресурсы транзакционной системы и не нарушал её стабильность. Как правило, данные загружаются в хранилище с определённой периодичностью, поэтому актуальность данных может несколько отставать от OLTP-системы.

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

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

Некорректируемость. Данные в хранилище данных не создаются: т. е. поступают из внешних источников, не корректируются и не удаляются.

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

Процессы работы с данными Источниками данных могут быть:

Традиционные системы регистрации операций Отдельные документы Наборы данных Операции с данными:

Извлечение — перемещение информации от источников данных в отдельную БД, приведение их к единому формату.

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

Загрузка — помещение данных в хранилище, производится атомарно, путем добавления новых фактов или корректировкой существующих.

Анализ — OLAP, Data Mining, сводные отчёты.

Представление результатов анализа.

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

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

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

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

Логическая структура данных хранилища данных отличается от структуры данных источников данных.

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

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

Кроме извлечения данных из БД, принятия решений важен процесс извлечения знаний, в соответствии с информационными потребностями пользователя.

С точки зрения пользователя в процессе извлечения знаний из БД должны решаться следующие преобразования: данные > информация > знания > полученные решения.

2. Технология обработки данных

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

Технология комплексного многомерного анализа данных получила название OLAP (On-Line Analytical Processing).

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

Основным преимуществом использования OLAP являются:

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

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

Гибкий механизм проваливания в детали и агрегации данных по различным разрезам.

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

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

OLAP-структура

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

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

Схема «звезды», схема звёздного соединения, звездоподобная схема, звёздная схема (от англ. star schema) — специальная организация реляционных таблиц, удобная для хранения многомерных показателей.

Модель данных состоит из двух типов таблиц: одной таблицы фактов (fact table) — центр «звезды» — и нескольких таблиц измерений (dimension table) по числу измерений в модели данных — лучи «звезды».

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

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

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

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

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

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

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

Таблицы измерений расшифровывают ключи, на которые ссылается таблица фактов; например, таблица «products» измерения «товары» базы данных торговой компании может содержать сведения о названии товара, его производителе, типе товара. За счёт использования специальной структуры таблицы измерений реализуется иерархия измерений, в том числе ветвящаяся.

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

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

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

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

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

OLAP со многими измерениями (Multidimensional OLAP — MOLAP);

реляционный OLAP (Relational OLAP — ROLAP);

гибридный OLAP (Hybrid OLAP — HOLAP).

MOLAP — это классическая форма OLAP, так что её часто называют просто OLAP. Она использует суммирующую БД, специальный вариант процессора пространственных БД и создаёт требуемую пространственную схему данных с сохранением как базовых данных, так и агрегатов. ROLAP работает напрямую с реляционным хранилищем, факты и таблицы с измерениями хранятся в реляционных таблицах, и для хранения агрегатов создаются дополнительные реляционные таблицы. HOLAP использует реляционные таблицы для хранения базовых данных и многомерные таблицы для агрегатов. Особым случаем ROLAP является ROLAP реального времени (Real-time ROLAP — R-ROLAP). В отличие от ROLAP в R-ROLAP для хранения агрегатов не создаются дополнительные реляционные таблицы, а агрегаты рассчитываются в момент запроса. При этом многомерный запрос к OLAP-системе автоматически преобразуется в SQL-запрос к реляционным данным.

Каждый тип хранения имеет определённые преимущества, хотя есть разногласия в их оценке у разных производителей. MOLAP лучше всего подходит для небольших наборов данных, он быстро рассчитывает агрегаты и возвращает ответы, но при этом генерируются огромные объёмы данных. ROLAP оценивается как более масштабируемое решение, использующее к тому же наименьшее возможное пространство. При этом скорость обработки значительно снижается. HOLAP находится посреди этих двух подходов, он достаточно хорошо масштабируется и быстро обрабатывается. Архитектура R-ROLAP позволяет производить многомерный анализ OLTP-данных в режиме реального времени.

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

3. Средства MS SQL Server для работы с киосками данных

Среда Business Intelligence Development Studio представляет собой версию MicrosoftVisual Studio 2008 с дополнительными типами проектов, характерными для работы с бизнес-аналитикой в SQL Server. Среда Business Intelligence Development Studio является основной средой для разработки бизнес-решений, в состав которых входят проекты служб Службы Analysis Services, Integration Services и Службы Reporting Services. Каждый тип проектов содержит шаблоны для создания объектов, необходимых для решений бизнес-аналитики, и предоставляет различные типы конструкторов, средств и мастеров для работы с такими объектами.

Таблица 1 — Компоненты BI-решения Microsoft

Integration Services

Службы SQL Server Integration Services (SSIS) представляют собой платформу для построения высокопроизводительных решений интеграции данных и решений потока операций, включая операции извлечения, преобразования и загрузки (Extract, Transform, Load — ETL) для хранилищ данных.

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

выполнение инструкций SQL и работа с сообщениями электронной почты;

источники данных и назначения для извлечения и загрузки данных;

преобразования для очистки, статистической обработки, слияния и копирования данных;

службу управления, службу SSIS для администрирования пакетов служб SSIS;

API-интерфейсы для программирования объектной модели служб SSIS.

Типичные случаи применения пакетов служб SSIS совместно с SSAS включают в себя:

слияние данных из разнородных хранилищ данных;

заполнение хранилищ данных и витрин данных;

очистка и стандартизация данных.

Слияние данных из разнородных хранилищ данных

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

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

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

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

Службы SSIS могут подключиться ко многим типам источников данных, включая несколько источников данных одного пакета. Пакет может подключиться к реляционным базам данных, используя поставщиков .NET и OLE DB, а также ко множеству традиционных баз данных, используя драйверы ODBC. Он также может подключиться к плоским файлам, файлам Excel и проектам служб SSAS.

Службы SSIS содержат компоненты источника, осуществляющие работу по извлечению данных из плоских файлов, рабочих листов Excel, XML-документов, а также таблиц и представлений реляционных БД из источника данных, к которому подключается пакет.

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

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

Заполнение хранилищ данных и витрин данных

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

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

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

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

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

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

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

Analysis Services

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

Для управления кубами OLAP и работы с ними используется среда Среда SQL Server Management Studio. Для создания новых кубов OLAP используется среда Business Intelligence Development Studio.

UDM

SSAS построены на основе Унифицированной Многомерной Модели (Unified Dimensional Model, UDM), появившейся в версии 2005, которая позволяет различным типам клиентских приложений получать доступ к данным как из реляционных, так и из многомерных баз данных без использования отдельных моделей для каждого типа баз данных.

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

UDM предоставляет возможность использовать множество источников данных (data sources) для создания многомерной модели.

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

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

Масштабируемость и производительность

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

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

Кубы служб SSAS — это многомерные структуры, обеспечивающие высокоскоростной доступ к большим объемам предварительно объединенных данных, и позволяющие конечным пользователям получать интересующие их бизнес-данные в реальном времени. В службах SSAS хранятся бизнес-данные в формате MOLAP, предоставляющем возможность высокой степени оптимизации и сжатия. Присущая этому формату гибкость дает также возможность частично или полностью хранить данные в реляционной базе данных в режиме реляционного OLAP (ROLAP) или в смешанном режиме, называемом гибридным OLAP (HOLAP). Режим MOLAP обеспечивает значительно более высокую производительность, чем режимы ROLAP и HOLAP.

Представление источника данных

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

Reporting Services

Конструктор отчетов — это набор графических средств построения запросов и проектирования отчетов, размещенный в среде Microsoft Visual Studio. В конструкторе отчетов для интерактивного создания отчетов предусмотрена панель «Данные отчета» (где в упорядоченном виде отображаются используемые в отчете данные) и представления с вкладками для режимов конструктора и предварительного просмотра. Кроме того, конструктор отчетов содержит конструкторы запросов, которые помогают уточнить данные для получения из источника данных, и диалоговое окно «Выражение» для определения данных, которые будут использованы в макете отчета.

Конструктор отчетов работает в среде Business Intelligence Development Studio, которая полностью интегрирована со средой разработки Microsoft Visual Studio. Если среда Visual Studio 2008 не установлена, то программа установки SQL Server установит оболочку, необходимую для запуска конструктора отчетов.

Конструктор отчетов поддерживает создание табличных и матричных отчетов, а также списочных отчетов в свободной форме. Кроме того, он поддерживает работу с диаграммами, датчиками и картами. Все возможности, которые могут быть использованы в отчете, определяются языком определения отчетов. Файлы на языке определения отчетов можно изменять и сохранять непосредственно, либо можно вносить изменения в отчет с помощью конструктора отчетов. При конструировании отчета существует возможность его локальной проверки до публикации на сервере отчетов. При переходе на вкладку предварительного просмотра конструктор отчетов запускает отчет с помощью тех же модулей обработки и подготовки к просмотру, которые используются сервером отчетов, обеспечивая просмотр отчета в том виде, в каком он будет выполняться. После того как отчет будет готов, можно с помощью конструктора отчетов опубликовать его на сервере отчетов. Публикация отчета заключается в копировании его определения (файла с расширением RDL) с жесткого диска в базу данных сервера отчетов. После публикации отчета его обработка и защита осуществляется независимо от файла определения отчета, который был создан в среде Visual Studio. Для публикации отчета можно использовать команды построения и развертывания, доступные в среде Visual Studio.

В службах Reporting Services предусмотрено много способов просмотра отчета после его публикации. Отчет можно просматривать непосредственно с помощью браузера и диспетчера отчетов, создавать подписки на доставку отчетов, экспортировать отчет в другой формат (например, Microsoft Excel или Microsoft Word).После публикации отчета можно управлять им и его источниками данных независимо. Можно создавать моментальные снимки отчета, устанавливать свойства кэширования, задавать новые наборы параметров для того же отчета и изменять источники данных отчета.

Возможности систем с использованием технологий Microsoft:

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

Пример В качестве примера разработки бизнес — аналитической структуры рассмотрим информационную систему продажи товаров.

Рис. 1 — Нормализованные исходные таблицы В итоге имеем готовый список таблиц:

Продажа — определяет кто, когда, у кого и что именно покупал.

Клиент — содержит список и информацию о клиентах.

Город — содержит список городов, в которых сосредоточены клиенты.

Дата — определяет нужные атрибуты времени.

Сотрудник — содержит список сотрудников.

Поставщик — хранит информацию о поставщиках.

Товар — хранит информацию о товарах.

Тип — содержит список всех видов товаров.

Для разработки баз данных и куба мы использовали средства Microsoft SQL Server 2008 Enterprise Edition. Базы данных создавались при помощи Microsoft SQL Server Management Studio. Для создания куба данных использовалась схема «Снежинка».

Рис. 2 — Схема снежинка Для создания пакета передачи данных, который будет только перекачивать данные с одного источника на другой, воспользуемся мастером SQL Server Import and Export Wizard.

Запускаем Business Intelligence Studio, меню File->New->Project, выбираем Integration Services Project в закладке Business Intelligence Projects. Окно SSIS Designer откроется автоматически (Рис. 3 «Solution Explorer»).

Рис. 3 — Solution Explorer

В SQL Server Management Studio в контекстном меню контейнера базы данных в обозревателе объектов выбрать пункт Tasks|Import Data (для импорта) или Tasks|Export Data (для экспорта). А в Integration Services Project в Solution Explorer в контекстном меню папки SSIS Packages выбрать SSIS Import and Export Wizard.

В окне мастера Choose a Data Source нужно указать, откуда будут извлекаться данные (Рис. 4 «Choose a Data Source»). После выбора источника данных в окне мастера появятся параметры, которые относятся к файлам указанного типа.

Рис. 4 — Choose a Data Source

В следующем окне Choose a destination нужно указать назначение импорта (куда данные будут перемещены). Choose a destination нужно указать назначение импорта (куда данные будут перемещены).

На странице Specify Table Copy or Query потребуется выбрать, будут ли загружаться все данные или только те, которые возвращает определенный запрос.

Далее на странице Select Source Tables and Views можно сопоставить таблицы и представления на источнике с таблицами на получателе данных (Рис. 5 «Select Source Tables and Views»).

Рис. 5 — Select Source Tables and Views

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

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

Далее в окне Save SSIS Package необходимо определить параметры сохранения: имя пакета, его описание и сервер.

После нажатия на кнопку Finish появится окно содержащие данные об успешности работы пакета передачи данных (Рис. 6 «Успешность работы пакета»).

Рис. 6 — Успешность работы пакета

Для того, чтобы создать OLAP куб, нам понадобится:

SQL Server, на котором хранится реляционная база данных;

Microsoft SQL Server, с запущенными Analysis Services (2005/2008);

Business Intelligence Studio, которая входит в пакет клиентских приложений для Microsoft SQL Server-а, и интегрируется с Visual Studio, если она у вас установлена (2005/2008);

Запускаем Business Intelligence Studio, меню File->New->Project, выбираем Analysis Services Project в закладке Business Intelligence Projects (Рис. 7 «New Project»).

Рис. 7 — New Project

Называем проект. В созданном проекте, в Solution Explorer видим:

Рис. 8 — Solution Explorer

Правый клик на папке Data Sources -> New Data Sources. В окне Data Source Wizard создаем connection к базе данных Kurs правый клик на папочке Data Source Views -> New Data Source View (Рис. 9 «Data Source Wizard»).

Рис. 9 — Data Source Wizard

В окне Data Source View Wizard выбираем нами созданный connection к Mobile и на следующей странице видим таблички нашего хранилища (Рис. 10 «Data Source View Wizard»).

Рис. 10 — Data Source View Wizard

В случае, если ваше хранилище содержит очень много таблиц, иногда сложно выбрать именно те, которые будут нужны для куба. Кнопка Add Related Tables добавляет все таблицы, от которых зависит выбранная в данный момент, то есть, выбрав, например, таблицу фактов, можно за один клик перенести таблицы измерений, которые нужны для данных фактов. Правый клик на папочке Cube -> New Cube. В окне Cube Wizard оставляем, выбранный по умолчанию, режим создания куба. Далее надо выбрать базу данных и таблицу фактов (Рис. 11 «Cube Wizard»).

Рис. 11 — Cube Wizard

Следующая страница показывает нам те числовые данные (Measures), которые мы сможем анализировать в кубе (Рис. 12 «Cube Wizard»).

Рис. 12 — Cube Wizard

На последнем странице, даем название нашему кубу и нажимаем кнопку Finish. Solution Explorer теперь принимает следующий вид:

Рис. 13 — Solution Explorer

Правый клик на проекте Mobileвыбираем Properties и на закладке Deployment, указываем Server, на котором запущены Analysis Services и имя базы данных куба. Правый клик на проекте Mobile, выбираем Deploy.

Рис. 14 — Browser

1. http://www.ci.ru/inform4₉₇/astr1.htm

2. http://www.trisoftrus.com/DesktopDefault.aspx?tabid=101&Mnu=2.101

3. http://www.osp.ru/win2000/2011/01/13 008 265/

4. http://www.intuit.ru/department/database/bispowerd/1/1.htmlинтернет университет

5. http://www.olap.ru/basic/kiosk.asp

6. http://habrahabr.ru/tag/OLAP/