Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

КУРСОВАЯ РАБОТА

Аналитические системы. Хранилище данных

Введение

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

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

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

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

Задачи исследования

1. Характиристика функций и структур хранилищ данных.

2. Расмотрение типичной структуры хранилища данных.

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

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

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

Рис. 1 Пример хранилища данных

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

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

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

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

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

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

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

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

Перечислим главные преимущества хранилищ данных:

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

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

- Быстрота разработки: специфическая логическая организация хранилища и существующее специализированное ПО позволяют создавать аналитические системы с минимальными затратами на программирование.

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

- Историчность и стабильность: OLTP-системы оперируют с актуальными данными, срок применения и хранения которых обычно не превышает величины текущего бизнес-периода (полугода-год), в то время как информационное хранилище данных нацелено на долговременное хранение информации в течение 10-15 лет.

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

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

Основная идея OLAP заключается в построении многомерных кубов, которые будут доступны для пользовательских запросов. Однако исходные данные для построения OLAP-кубов обычно хранятся в реляционных базах данных. Нередко это специализированные реляционные базы данных, называемые также хранилищами данных (Data Warehouse). В отличие от так называемых оперативных баз данных, с которыми работают приложения, модифицирующие данные, хранилища данных предназначены исключительно для обработки и анализа информации, поэтому проектируются они таким образом, чтобы время выполнения запросов к ним было минимальным. Типичная структура хранилища данных существенно отличается от структуры обычной реляционной СУБД. Как правило, эта структура денормализована (это позволяет повысить скорость выполнения запросов), поэтому может допускать избыточность данных.

Для дальнейших примеров мы снова воспользуемся базой данных Northwind, входящей в комплекты поставки Microsoft SQL Server и Microsoft Access. Ее структура данных приведена на рис. 1.

Рисунок 1. Структура базы данных Northwind

Основными составляющими структуры хранилищ данных являются таблица фактов (fact table) и таблицы измерений (dimension tables).

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

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

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

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

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

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

Для примера рассмотрим факты, связанные с элементами документа (в данном случае счета, выставленного за товар).

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

Пример таблицы фактов, которая может быть построена на основе базы данных Northwind, приведен на рис. 2.



Рис. 2. Пример таблицы фактов

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

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

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

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

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

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

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

Пример таблицы измерений приведен на рис. 3.



Рис. 3. Пример таблицы измерений

Одно измерение куба может содержаться как в одной таблице (в том числе и при наличии нескольких уровней иерархии), так и в нескольких связанных таблицах, соответствующих различным уровням иерархии в измерении. Если каждое измерение содержится в одной таблице, такая схема хранилища данных носит название «звезда» (star schema). Пример такой схемы приведен на рис. 4.



Рисунок 4. Пример схемы «звезда»

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



Рис. 5. Пример схемы «снежинка»

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

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

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

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

1.3 Обзор технологий хранилищ данных

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

Это понятие является, наверное, наиболее широко трактуемым. для начала приведем ставшее уже классическим определение Б. Инмона: Хранилище данных (Data Warehouse) это - «предметно-ориентированный, интегрированный, неизменяемый, поддерживающий хронологию набор данных, организованный для целей поддержки принятия решений». Достаточно часто под ХД подразумевается не только набор данных, но также и вся технология использования ХД.

Витрина данных

Это понятие возникло несколько позже термина ХД, поэтому в некоторых источниках оно слито с понятием ХД. В данном материале под Витриной (или Киоском) данных (Data Mart) мы будем понимать сравнительно небольшое ХД, сконструированное для использования неким подразделением с одним существенным отличием от ХД - в Витрине данных конечный пользователь может создавать свои собственные структуры данных. Есть еще одна особенность у Витрин данных (ВД) - источником для большинства хранящихся там данных является ХД. Это приводит к тому, что при создании ВД редко используется инструменты по очистке, денормализации и унификации данных.

Технология

Под этим термином будем понимать технологию использования всех объектов связанных с ХД, как то:

· Хранилища данных

· Витрины данных

· Программное обеспечение

Программное обеспечение ХД делится на три основных категории:

· Средства Загрузки

· Средства Мониторинга

· Средства Создания и Развития

A. Средства Загрузки

для выполнения загрузки данных в ХД используется следующее ПО:

· диспетчер процессов

· Загрузчик данных

· Анализатор данных

1. Диспетчер процессов для нормального функционирования ИСНП необходима регулярная загрузка новых данных в ХД. Разработка регламента процессов загрузки данных из источников является необходимой частью построения логической структуры ХД. диспетчер осуществляет выполнение процессов загрузки согласно регламенту.

2. Загрузчик данных источниками данных для ХД могут служить самые разнообразные ОБД, а также внешние данные в других форматах. Важно что бы загрузчик данных имел возможность доступа к максимальному количеству СУБД и других форматов данных. В функции загрузчика входит также трансформация данных в заданный формат.

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

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

B. Средства Мониторинга

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

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

C. Средства Создания и Развития

Создание и развитие Хранилища данных требует следующих компонент ПО:

· СУБД Хранилища данных.

СУБД Хранилища данных должна быть ориентирована на особенности технологии ХД - работать с большими объемами данных, обеспечивать необходимую безопасность данных, позволять создавать очень сложные структуры данных (такие как многомерные базы данных), осуществлять быстрый многопользовательский доступ к данным.

· Средства управления структурой данных ХД.

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

· Средства задания источников данных.

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

· Средства построения Витрин данных.

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

1.4. Возможности применения ведущих СУБД для построения Хранилищ данных.

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

В основе концепции хранилища данных лежат две основные идеи:

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

(2) Разделение наборов данных и приложений, используемых для оперативной обработки и применяемых для решения задач анализа.

Компания IBM

Решение компании IBM называется A Data Warehouse Plus. Целью компании является обеспечение интегрированного набора программных продуктов и сервисов, основанных на единой архитектуре. Основой хранилищ данных является семейство СУБД DB2. Преимуществом IBM является то, что данные, которые нужно извлечь из оперативной базы данных и поместить в хранилище данных, находятся в системах IBM. Поэтому естественная тесная интеграция программных продуктов.

Предлагаются три решения для хранилищ данных:

(1) Изолированная витрина данных. Предназначен для решения отдельных задач вне связи с общим хранилищем корпорации.

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

(3) Глобальное хранилище данных. Корпоративное хранилище данных, которое полностью централизовано контролируется и управляется. Глобальное хранилище данных может храниться централизовано или состоять из нескольких распределенных в сети рынков данных.

Oracle

Решение компании Oracle в области хранилищ данных основывается на двух факторах: широкий ассортимент продуктов самой компании и деятельность партнеров в рамках программы Warehouse Technology Initiative. Возможности Oracle в области хранилищ данных базируются на следующих составляющих:

· наличие реляционной СУБД Oracle 7, которая постоянно совершенствуется для лучшего удовлетворения потребностей хранилищ данных;

· существование набора готовых приложений, обеспечивающих возможности разработки хранилища данных;

· высокий технологический потенциал компании в области анализа данных;

· доступность ряда продуктов, производимых другими компаниями.

Hewlett Packard

Работы, связанные с хранилищами данных, выполняются в рамках программы OpenWarehouse. Выполнение этой программы должно обеспечить возможность построения хранилищ данных на основе мощных компьютеров HP, аппаратуры других производителей и программных компонентов. Основой подхода HP являются Unix-платформы и программный продукт Intelligent Warehouse, который предназначен для управления хранилищами данных. Основа построения хранилищ данных, предлагаемая HP, оставляет свободу выбора реляционной СУБД, средств реинжиниринга и т.д.

NCR

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

Informix Software

Стратегия компании в отношение хранилищ данных направлена на расширение рынка для ее продуктаOn-Line Dinamic Parallel Server. Предлагаемая архитектура хранилища данных базируется на четырех технологиях: реляционные базы данных, программном обеспечении для управления хранилищем данных, средствах доступа к данным и платформе открытых систем. Три последние компонента разрабатываются партнерами компании. После выхода Универсального Сервера, основанного на объектно-реляционном подходе, можно ожидать, что и он будет использоваться для построения хранилищ данных.

SAS Institute

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

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

· преобразование данных и манипулирование ими с использованием 4GL;

· наличие сервера многомерных баз данных;

· большой набор методов и средств для аналитической обработки и статистического анализа.

Sybase

Стратегия компании в области хранилищ данных основывается на разработанной ей архитектуреWarehouse WORKS. В основе подхода находится реляционная СУБД Sybase System 11, средство для подключения и доступа к базам данных OmniCONNECT и средство разработки приложений PowerBuilder. Компания продолжает совершенствовать свою СУБД для лучшего удовлетворения потребностей хранилищ данных (например, введена побитная индексация).

Software AG

Деятельность компании в области хранилищ данных происходит в рамках программы Open Data Warehouse Initiative. Программа базируется на основных продуктах компании ADABAS и Natural 4GL, собственных и приобретенных средствах извлечения и анализа данных, средстве управления хранилищем данных SourcePoint. SourcePoint позволяет автоматизировать процесс извлечения и пересылки данных, а также их загрузки в хранилище данных.

2. Создание хранилища данных на основе бд Northwind

хранилище база управление данные

Структура данных этого хранилища приведена на рис. 4, а скрипт для создания базы данных с такой структурой (назовем ее Northwind_Mart) - в листинге 1 [листинг 1 находится в приложении 1]

Заполнение хранилища данных с помощью Data Transformation Services

Что представляют собой DTS



Рис. 5 DTS Import/Export Wizard

Data Transformation Services (DTS) - это набор служб SQL Server, предназначенных для организации импорта, экспорта, преобразования данных и переноса их между любыми источниками, доступными через интерфейсы OLE DB. С их помощью можно копировать структуры данных и сами данные из одной базы данных в другую, создавать средства для переноса данных, встроенные в приложения, а также пополнять хранилища данных из разнообразных источников (которые в общем случае вовсе не обязательно должны быть базами данных SQL Server).

Создать пакет DTS можно с помощью соответствующего редактора - DTS package editor. Для его запуска следует с помощью SQL Server Enterprise Manager соединиться с сервером, содержащим хранилище данных, найти в разделе Data Transformation Services элемент Meta Data Service Packages и выбрать опцию New Package из его контекстного меню.



Рис. 6 MS OLE DB Provider for SQL Server

Далее нам требуется описать базу данных, в которой находится наше хранилище. Для этого необходимо перенести на рабочее пространство редактора пакетов DTS пиктограмму Microsoft OLE DB Provider for SQL Server с палитры Data tool в левой части окна редактора. После этого появится диалоговая панель Connection Properties для описания источников данных OLE DB, в которой нужно выбрать базу данных Northwind_Mart, указать параметры доступа к ней (например, Use Windows NT authentication). Присвоим этому источнику данных имя NW_OLAP. Для наглядности создаваемой диаграммы сделаем копию этого же источника данных, перенеся на рабочее пространство редактора пакетов DTS еще одну такую же пиктограмму, отметив в диалоговой панели Connection Properties опцию Existing Connection и выбрав из списка имеющихся источников данных NW_OLAP.

Тем же способом опишем источник исходных данных - базу данных Northwind, присвоим ему имя NW и создадим еще пять его копий, так как в нашем хранилище данных содержится шесть таблиц, и нам потребуется шесть отдельных операций по их заполнению. Описание потоков данных и последовательности выполнения задач. В нашем примере перед заполнением таблиц в хранилище данных мы будем полностью очищать их содержимое. Для этой цели мы перенесем в рабочее пространство редактора пиктограмму Execute SQL Task. При этом на экране появится диалоговая панель Execute SQL Task Properties, в которой мы заполним поля Description (описание задачи) и SQL Statement (сюда мы добавим операторы для удаления данных из всех таблиц хранилища данных, рис. 7.

Рис. 7. Диалоговая панель Execute SQL Task Properties

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

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

Таким образом, мы создали задания для переноса данных в пять таблиц измерений нашего хранилища. Эти задачи могут выполняться параллельно, ведь таблицы измерений в нашем хранилище не связаны друг с другом. Однако они могут быть выполнены только после полной очистки всего хранилища. Чтобы описать это условие (такие условия определяются словосочетанием precedence constraint), нам следует одновременно выбрать пиктограмму Execute SQL Task и одну из пяти уже задействованных пиктограмм источника данных NW, а затем из контекстного меню источника данных NW выбрать опцию Workflow | On Success. Появившаяся зеленая пунктирная стрелка между пиктограммами означает, что перенос данных в соответствующую таблицу изменений будет осуществлен только после успешного завершения очистки хранилища. Далее следует повторить это действие с оставшимися четырьмя используемыми экземплярами источника данных NW.

Что же касается задачи заполнения данными таблицы фактов, она может быть выполнена только после того, как будут заполнены все таблицы измерений. Поэтому сначала мы выделим оставшиеся экземпляры источника данных NW и источника данных NW_OLAP, затем выберем опцию WorkFlow из контекстного меню этого экземпляра источника данных NW_OLAP - при этом пиктограммы окажутся соединены стрелкой, соответствующей задаче заполнения таблицы фактов. Далее нам следует одновременно выбрать пиктограмму NW_OLAP, участвующую в описании пяти задач заполнения таблиц измерений, и пиктограмму NW, участвующую в описании задачи заполнения таблицы фактов, а затем из контекстного меню выделенного источника данных NW выбрать опцию Workflow | On Success. Таким образом, мы указали, что заполнение таблицы фактов осуществляется только после успешного заполнения таблиц измерений (рис. 8).

Рис. 8. Описание последовательности выполнения задач заполнения хранилища данных

Описание преобразования данных

Далее нам следует описать, откуда берутся и как преобразовываются данные при переносе из оперативной базы данных в хранилище. Мы начнем с таблицы Time_Dim. Для этой цели дважды щелкнем мышью по одной из пяти стрелок, соответствующих задачам заполнения таблиц измерений. В появившейся диалоговой панели заполним поле Description, выберем опцию SQL Query и введем текст SQL-запроса, результат которого должен быть помещен в таблицу Time_Dim:

SELECT DISTINCT

S. ShippedDate AS TheDate,

DateName (dw, S. ShippedDate) AS DayOfWeek,

DatePart (mm, S. ShippedDate) AS [Month],

DatePart (yy, S. ShippedDate) AS [Year],

DatePart (qq, S. ShippedDate) AS [Quarter],

DatePart (dy, S. ShippedDate) AS DayOfYear,

'N' AS Holiday,

case DatePart (dw, S. ShippedDate)

when (1) then 'Y'

when (7) then 'Y'

else 'N'

end

AS Weekend,

DateName (month, S. ShippedDate) +

'_' + DateName (year, S. ShippedDate) AS YearMonth,

DatePart (wk, S. ShippedDate) AS WeekOfYear

FROM Orders S

WHERE S. ShippedDate IS NOT NULL

Щелкнем по закладке Destination и выберем из списка таблиц хранилища данных таблицу Time_Dim. Далее можно перейти на страницу Transformations и проверить правильность соответствий между полями исходного набора данных и таблицы Time_Dim. Если они не соответствуют желаемым, их можно отредактировать с помощью кнопок New, Edit, Delete (рис. 9).

Рис. 9. Описание преобразования данных для таблицы Time_Dim

Следующая таблица измерений, Customer_Dim, будет заполняться не результатами запроса, а данными из таблицы Customers. Поэтому на странице Source следует отметить опцию Table/View, выбрать таблицу Customers в списке таблиц базы данных Northwind, на странице Destination выбрать таблицу Customer_Dim и проверить правильность соответствий между полями исходного набора данных и таблицы Customer_Dim. Однако в этом случае было бы желательно преобразовать некоторые значения, содержащиеся в поле Region исходной таблицы (для одних стран это поле не содержит данных, тогда как для других может потребоваться анализ продаж по регионам или другим административным единицам). С этой целью мы удалим соответствие между полем Region обеих таблиц, нажмем кнопку New, из списка в диалоговом окне New Transformation выберем опцию ActiveX Script и в появившейся диалоговой панели ActiveX Script Transformation Properties отредактируем код на языке VBScript, описывающий преобразование данных в этом поле:

Function Main()

If IsNull (DTSSource(«Region»)) Then

DTSDestination («Region») = «Other»

Else

DTSDestination («Region») = DTSSource («Region»)

End If

Main = DTSTransformStat_OK

End Function

Здесь курсивом выделены фрагменты, добавленные к коду, сгенерированному по умолчанию (рис. 10).



Рис. 10. Описание преобразования данных для таблицы Customer_Dim с помощью скрипта

Для таблицы измерений Product_Dim последовательность действий сходна с той, что мы применяли при создании таблицы Time_Dim. Однако здесь, выбрав на странице Source диалоговой панели Transform Data Task Properties опцию SQL Query, мы нажмем кнопку Build Query и создадим запрос с помощью DTS Query Designer (рис. 11).

Рис. 11. Создание запроса к оперативной базе данных с помощью DTS Query Designer

В запросе используются таблицы Products и Categories базы данных Northwind, при этом поле UnitPrice таблицы Products переименовывается в ListUnitPrice.

Выбрав на странице Destination таблицу Product_Dim, проверим корректность соответствий между полями исходного набора данных и таблицы Products_Dim. В данном случае мы видим, что поля SupplierID и SupplierName - разных типов, при этом то и другое поле описывают, по существу, одно и то же свойство члена измерения. В этой ситуации нам поможет подстановка значений (lookup). Перейдем на страницу Lookups, нажмем кнопку Add, придумаем имя для подстановки, например SupplierLookup, щелкнем по кнопке Query и в появившемся редакторе DTS Que

SELECT CompanyName

FROM Suppliers

WHERE (SupplierID =?)

Далее на странице Transformations опишем соответствие между полями SupplierId и SupplierName. С этой целью нажмем кнопку New, из списка в диалоговом окне New Transformation выберем опцию ActiveX Script, укажем имена исходного и получаемого полей и в появившейся диалоговой панели ActiveX Script Transformation Properties отредактируем код на языке VBScript, описывающий преобразование данных в этом поле:

Function Main()

DTSDestination («SupplierName») = _

DTSLookups («SupplierLookup»).Execute (DTSSource(«SupplierID»).Value)

Main = DTSTransformStat_OK

End Function

Для заполнения данными следующей таблицы измерений, Employee_Dim, нам нужно указать, что два поля исходной таблицы Customers, FirstName и LastName, соответствуют одному полю EmployeeName таблицы Customer_Dim. Для этого нажмем кнопку New на странице Transformations, выберем опцию ActiveX Script и отметим оба поля, FirstName и LastName, в качестве исходных. Далее модифицируем код в диалоговой панели панели ActiveX Script Transformation Properties:

Function Main()

DTSDestination («EmployeeName») = DTSSource («FirstName») & _

«» & DTSSource («LastName»)

Main = DTSTransformStat_OK

End Function

И наконец, при описании преобразования данных для таблицы Shipper_Dim нам нужно проверить соответствие между полем CompanyName таблицы Shippers базы данных Northwind и полем ShipperName таблицы Shipper_Dim.

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

SELECT

Northwind_Mart.dbo. Time_Dim. TimeKey,

Northwind_Mart.dbo. Customer_Dim. CustomerKey,

Northwind_Mart.dbo. Shipper_Dim. ShipperKey,

Northwind_Mart.dbo. Product_Dim. ProductKey,

Northwind_Mart.dbo. Employee_Dim. EmployeeKey,

Northwind.dbo. Orders. RequiredDate,

Orders. Freight * [Order Details].Quantity /

(SELECT SUM(Quantity)

FROM [Order Details] od

WHERE od. OrderID = Orders. OrderID) AS LineItemFreight,

[Order Details].UnitPrice * [Order Details].Quantity

AS LineItemTotal,

[Order Details].Quantity AS LineItemQuantity,

[Order Details].Discount * [Order Details].UnitPrice *

[Order Details].Quantity AS LineItemDiscount

FROM Orders

INNER JOIN [Order Details]

ON Orders. OrderID = [Order Details].OrderID

INNER JOIN Northwind_Mart.dbo. Product_Dim

ON [Order Details].ProductID =

Northwind_Mart.dbo. Product_Dim. ProductID

INNER JOIN Northwind_Mart.dbo. Customer_Dim

ON Orders. CustomerID =

Northwind_Mart.dbo. Customer_Dim. CustomerID

INNER JOIN Northwind_Mart.dbo. Time_Dim

ON Orders. ShippedDate = Northwind_Mart.dbo. Time_Dim. TheDate

INNER JOIN Northwind_Mart.dbo. Shipper_Dim

ON Orders. ShipVia = Northwind_Mart.dbo. Shipper_Dim. ShipperID

INNER JOIN Northwind_Mart.dbo. Employee_Dim

ON Orders. EmployeeID =

Northwind_Mart.dbo. Employee_Dim. EmployeeID

WHERE (Orders. ShippedDate IS NOT NULL)

Созданный пакет DTS следует сохранить, выбрав опцию Package | Save из меню редактора пакетов DTS. Выполнить его можно, выбрав пункт меню Package | Execute. После этого начнется процесс преобразования данных и заполнения ими таблиц хранилища данных.

Для того чтобы данные в хранилище соответствовали текущему или недавнему состоянию оперативной базы данных, можно создать расписание, согласно которому будет автоматически выполняться данный пакет. Для этого следует выбрать его в Enterprise Manager и опцию Schedule Package - из контекстного меню. Далее следует выбрать нужный режим обновления данных в диалоговой панели Edit Recurring Job Schedule (рис. 7).

Рис. 12. Создание расписания выполнения пакета DTS

Заключение

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

Размещено на Allbest.ru