Информационная система управления

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

Оглавление

• Введение
• 1. Анализ существующих решений
• 1.1 Хранилище данных в 3NF Билла Инмона
• 1.2 Star Schema Ральфа Кимбалла
• 1.3 Результаты анализа
• 2. Выбранный метод решения
• 2.1 Общие сведения о модели Data Vault
• 2.2 Компоненты Data Vault
• 2.2.1 Хабы
• 2.2.2 Связи
• 2.3 Методология Data Vault
• 2.4 Архитектура Data Vault
• 2.5 Принципы загрузки данных
• 2.6 Преимущества
• 2.7 Возможные области применения
• 3. Создание информационной системы
• 3.1 Обоснование выбора применяемых инструментов
• 3.2 Анализ источника данных
• 3.3 Проектирование хранилища данных
• 3.4 Загрузка данных из источника средствами ETL
• 3.5 Создание витрины данных
• 3.6 Создание мета-слоя с использованием SAP Business Objects
• 3.7 Визуализация данных в аналитических отчетах
• Заключение
• Перечень сокращений
• Список используемой литературы
• Приложение


Введение

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

Информационная система (ИС) - любая организованная система для сбора, организации, хранения и передачи информации.

Информационная система включает в себя следующие компоненты:

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

- Программное обеспечение. Сюда включаются все программы для работы с данными и руководства к ним.

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

- Процедуры. Нотации, которые регулируют работу компьютерной системы.

- Люди. Любая ИС приносит пользу, когда ей управляет опытный работник [1].

Классификация информационных систем, изображенная на рис. 1, представлена в виде пирамиды, которая отображает иерархию организации. Как правило, системы обработки транзакций (Transaction Processing Systems) расположены в нижней части пирамиды. Затем идут системы управления (Management Information Systems) и системы по поддержке принятия решений (Decision Support System). На верхушке пирамиды расположены информационные системы для руководящего персонала (Executive Information Systems - EIS) [2].

Рис. 1. Классификация ИС

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

- Источники данных;

- ETL-модуль;

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

- Приложение для анализа данных;

- Отчетность.

Структура системы изображена на рис. 2 [3].



Рис. 2. Схема общей структуры ИС управления

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

На первый план выдвинуты такие характеристики ХД, как поддержка темпоральности [4] (зависимость данных от времени) и способность к расширяемости. Во-первых, отслеживание изменений в данных влияет на точность анализируемой информации. Во-вторых, в данной работе ИС разрабатывается для применения в онлайн-магазине, а изменения в интернет-коммерции могут происходить достаточно часто, и структуру хранения данных необходимо постоянно модернизировать.

В работе рассмотрены два классических подхода к построению ХД: 3NF Билла Инмона и Star Scheme Ральфа Кимбалла, а также гибридная методология Data Vault, разработанная Дэном Линдстедом и обладающая лучшими свойствами первых двух подходов, которая наиболее подходит для достижения поставленных целей.

Основными целями работы являются:

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

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

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

- Построить модель источника данных, спроектировать и создать OLTP базу данных.

- Спроектировать и реализовать хранилище данных на основе выбранной методологии.

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

- Построить слой метаданных, с которым будет работать конечный пользователь

- Визуализировать данные для анализа путем создания бизнес-отчетов.



1. Анализ существующих решений

1.1 Хранилище данных в 3NF Билла Инмона

• информационный хранилище данные управление
• Спроектированная Инмоном структура включает в себя все информационные системы и их базы данных, используемые в данной организации. Инмон называет свой подход Корпоративная Информационная Фабрика (Corporate Information Factory - CIF) [5].

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

- Оперативный уровень;

- Хранилище с атомарными данными;

- Ведомственный уровень;

- Индивидуальный уровень.

Последние три уровня включают в себя непосредственно хранилище данных. Первый уровень содержит данные из систем обработки транзакций и предназначен для поддержки ежедневного функционирования организации. Данные из оперативных систем приводятся к единообразию и затем загружаются в хранилище с атомарными данными. Данные, хранящиеся на ведомственном уровне, могут быть слабо или сильно агрегированы, в зависимости от требований к информации, заданных определенным отделом. Архитектура Инмона гарантирует согласованность данных, т.к. все ведомственные данные поступают из атомарного хранилища. Отдельные пользователи создают четвертый и конечный уровень архитектуры среды, когда создают ad-hoc наборы данных в рамках анализа поддержки принятия решений. Четвертый уровень, как правило, носит временный характер и и размещается на персональных компьютерах пользователей.

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

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

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

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

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

- Интегрированность: хранилище содержит данные из большинства или всех операционных приложений организации, эти данные консолидированы и приведены в соответствие друг с другом [6].

Архитектура 3NF Инмона представлена на рис. 3.

Рис. 3. 3NF Билла Инмона

Достоинства подхода:

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

- Единое хранилище данных на физическом уровне;

- Быстрота создания хранилища при помощи итерационного метода;

- Высокая степень детализации данных;

- Централизованное управление деятельностью организации.

Недостатки подхода:

- Отсутствие прямого доступа в ХД;

- Сложность в использовании системы обычными пользователями;

- Затраты больших объемов ресурсов на создание и поддержание системы [7].

1.2 Star Schema Ральфа Кимбалла

В отличие от методологии Билла Инмона, Ральф Кимбалл рекомендует строить хранилище данных, следуя подходу «снизу-вверх» [8]. Хранилище по Кимбаллу начинается с построения витрин данных. Каждая витрина содержит данные как на атомарном, так и на агрегированном уровнях, предоставляя актуальную информацию. Различные витрины данных соединены через, так называемую, шину измерений, что позволяет пользователю получить доступ ко всем данным во всех витринах.

Кимбалл выделяет следующие цели для хранилища данных:

- Сделать информацию легко доступной;

- Предоставлять информацию организации в целостном виде;

- Быть адаптивным и устойчивым к изменениям;

- Защищать информацию;

- Служить основой для увеличения качества принятия решений.

Рассмотрим принцип построения ХД, предложенный Ральфом Кимбаллом, поподробнее.

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

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

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

Методология разработки хранилища по Кимбаллу включает в себя 4 шага. В качестве первого шага необходимо выбрать бизнес-процесс. Затем следует решить, какой уровень детализации данных будет содержать хранилище. Самый низкий уровень называется атомарным, а это означает, что он не может быть более разделен. Следующим шагом является выбор измерений. Это могут быть «Дата», «магазин», «продукт» и т.д. Каждая таблица измерений имеет большое количество атрибутов. Но, т.к. данные в таких таблицах хранятся в денормализованном виде, объем данных за десятилетний период, по подсчетам Кимбалла, измеряется в килобайтах. Четвертый и последний этап заключается в выборе фактов. Примерами фактов служат «цена продукта», «количество продукта», «доход» и т.д [9].

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

Рис. 4. Star Schema Ральфа Кимбалла

Достоинства подхода:

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

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

- Простота в использовании системы обычными пользователями;

- Виртуальные витрины данных.

Недостатки подхода:

- Неспособность системы к расширяемости;

- Отсутствие целостного хранилища данных;

- Затруднительный процесс обработки изменений в хранилище ввиду особенностей его построения [10].

1.3 Результаты анализа

Таблица 1. Сравнение двух классических методологий создания ХД

Критерий	3NF Инмона	Star Schema Кимбалла
Общий подход	«сверху-вниз»	«снизу-вверх»
Структура	Общее хранилище данных на физическом уровне	Витрины данных, моделирующие отдельные бизнес-процессы; общность достигается за счет архитектуры шины и согласованных измерений
Сложность метода	Достаточно сложный	Простой
Целевая аудитория	IT-специалисты	Пользователи
Характер требований к поддержке принятия решений	Стратегический	Тактический
Требования к интеграции данных	Интеграция всей деятельности компании	Отдельные направления деятельности
Масштабируемость	Растущие масштабы и изменяющиеся требования имеют решающее значение	Необходимость адаптироваться к высокой волатильности потребностей в ограниченном объеме
Постоянство данных	Высокая скорость изменения в исходных системах	Системы-источники относительно стабильны
Стоимость развертывания	Высокие начальные затраты, более низкие затраты на разработку последующих проектов	Низкие начальные затраты, с каждым последующим проектом стоимость существенно не изменяется
Хранение данных	Разграничение хранения данных: атомарные данные хранятся в ХД 3NF, суммированные данные хранятся в витринах.	Суммарные и атомарные данные хранятся совместно в виртуальных витринах, построенных по модели «звезда».
Производительность	Прямые запросы к ХД 3NF занимают большое кол-во времени. Для выполнения запросов и создания отчетности необходимо наличие витрин данных	Высокая производительность благодаря прямому доступу как к атомарным, так и к суммарным данным в витрине
Отслеживание изменения данных	Наличие меток времени для отслеживания времени валидности данных, а также времени транзакций	Использование концепции медленно изменяющихся измерений, чтобы отследить исторические изменения



2. Выбранный метод решения

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

Данная методология изначально была задумана Дэном Линстедом в 1990 и выпущена в свободном доступе в 2000 году. Правила метода Data Vault были освещены и разъяснены в серии из пяти статей на официальном сайте автора. В последующих разделах приведено описание метода с указанием его отличительных особенностей.

2.1 Общие сведения о модели Data Vault

Data Vault представляет собой метод моделирования ХД, который предназначен для обеспечения долгосрочного хранения исторических данных, поступающих из операционных систем, и решения проблем отслеживания данных, скорости загрузки и устойчивости к изменениям [11].

Данная методология имеет ряд следующих особенностей:

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

- Отсутствие разделения на «чистые» и «грязные» (не соответствующие бизнес-правилам) данные. Это означает, что в ХД хранится «единая версия фактов», т.е. все данные компании, в отличие от практики других методов хранения «единой версии истины», где данные, не соответствующие определениям, удаляются или «очищаются».

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

- Обеспечение параллельной загрузки.

В двух основных методологиях построения хранилищ данных, рассмотренных в первой главе, - модели Билла Инмона и модели Ральфа Кимбалла - возникают проблемы при работе с изменениями в системах-источниках. Перед загрузкой данных в хранилище в обоих методах необходима предварительная очистка, что в ряде случаев нежелательно, т.к. неизбежно ведет к потере информации. Data Vault спроектирован таким образом, чтобы избежать или свести к минимуму воздействие этих проблем путем выделения структурных элементов, таких как бизнес-ключи, от описательной информации. Очистка же в Data Vault происходит на этапе перегрузки данных из непосредственно хранилища в витрины данных.

Дэн Линстед описывает разработанный метод следующим образом:

«Data Vault - набор уникально связанных нормализованных таблиц, содержащих детальные данные, отслеживающих историю изменений и предназначенных для поддержки одной или нескольких функциональных областей бизнеса. Это - гибридный подход, обобщающий лучшие свойства третьей нормальной формы и схемы Звезда. Дизайн Data Vault - гибок, масштабируем, последователен и приспосабливаем к потребностям предприятия» [12].

Философия Data Vault заключается в том, что все данные являются релевантными, даже если они не соответствуют установленным бизнес-правилам. Несоответствие данных есть проблема бизнеса, а не хранилища данных. В Data Vault заносятся все данные со всех источников, и только при составлении отчетов и извлечении данных из хранилища они проходят очистку.

2.2 Компоненты Data Vault

В представленной методологии проблема регистрирования изменений в производственной среде компании решается путем разделения бизнес-ключей (модифицируются редко, т.к. однозначно идентифицируют бизнес-сущность) и связей между ними от описательных атрибутов этих ключей. Бизнес-ключи их связи являются структурными элементами, образующими «скелет» модели данных. Методология Data Vault в качестве одной из своих аксиом утверждает, что реальные бизнес-ключи меняются только тогда, когда происходят изменения в основном направлении бизнеса, а соответственно являются наиболее стабильными элементами, из которых можно вывести структуру исторического ХД. Используя эти ключи в качестве основы хранилища, можно организовать остальные данные вокруг них. Таблицы, хранящие в себе бизнес-ключи, называются Хабами (Hubs). Таблицы, которые представляют собой ассоциации между бизнес-ключами, называются Связями (Links). Таблицы с описательными атрибутами - Спутники (Satellites).

2.2.1 Хабы

Таблицы Хабы содержат список уникальных бизнес-ключей с минимальной склонностью к изменениям. Также в Хабах хранятся суррогатный ключ для каждого элемента Хаба, время и дата загрузки каждой строки в таблицу и метаданные, описывающие происхождение бизнес-ключа (обычно сюда записывается название таблицы из базы данных источника). После выхода в 2013 году модели Data Vault версии 2.0 суррогатные ключи во всех таблицах хранятся в виде хеш-функции на основе алгоритма MD5 с фиксированной длиной CHAR32.

Хаб содержит как минимум следующие столбцы (табл. 2):

- Суррогатный ключ. Используется для связи с другими таблицами в ХД.

- Бизнес-ключ. Основной компонент Хаба.

- Источник записи. Используется для отслеживания источника данных.

- Дата загрузки. Обеспечивает поддержку темпоральности ХД.



Таблица 2. Структура таблицы Хаб

Название столбца	Описание
HUB_***_HSK	Суррогатный ключ
HUB_***_ID	Бизнес-ключ
HUB_***_RSRC	Данные об источнике
HUB_***_LDTS	Дата загрузки записи

2.2.2 Связи

Ассоциации или транзакции между бизнес-ключами (например, отношение Хабов «Покупатель» и «Продукт» в контексте сделки купли-продажи) моделируются с помощью таблиц Связей. В основном, Связи представляют собой соединения «многие-ко-многим».

Таблицы Связи содержат (табл. 3):

- Суррогатные ключи Хабов, ассоциации которых они представляют;

- Свой собственный суррогатный ключ;

- Метаданные, описывающие происхождение ассоциации, т.е. таблицу-источник

- Дату загрузки записи в таблицу.

Таблица 3. Структура таблицы Связь

Название столбца	Описание
LNK_***_HSK	Собственный суррогатный ключ
LNK_***_RSRC	Данные об источнике
LNK_***_LDTS	Дата загрузки записи
HUB_***_HSK(1)	Суррогатный ключ Хаба, первый якорь связи
…
HUB_***_HSK(N)	Суррогатный ключ Хаба, N-ный якорь связи

Спутники

Хабы и Связи образуют структуру модели, но не имеют никакой описательной информации. Она хранится в отдельных таблицах, называемых Спутниками. Помимо описательных атрибутов, Спутники состоят из метаданных, связывающих их с родительским Хабом или Связью и хранящих наименование источника (табл. 4).

Спутники обеспечивают «мясо» модели данных, контекст для бизнес-процессов, которые фиксируются в Хабах и Связях.

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

Таблица 4. Структура таблицы Спутник

Название столбца	Описание
HUB_***_HSK	Суррогатный ключ родительского Хаба
SAT_***_LDTS	Дата загрузки записи
SAT_***_RSRC	Данные об источнике
SAT_***_HDIFF	Хеш-ключ для отслеживания изменений в атрибутах
Product_name Category	Атрибуты

2.3 Методология Data Vault

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

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

Считается, что жесткие правила бизнеса включают в себя нормализацию, значения по умолчанию (замена NULL-значений) и согласование типов данных. Жесткие правила выполняются на пути в модель Data Vault или, иногда, на пути к области подготовки данных.

Методология вобрала в себя лучшие свойства концепций Six Sigma, TQM, SEI/CMMI Level 5 и PMP. Она максимально приближает усилия, приложенные на проектирование хранилища данных, к результатам, которые ожидаются при применении оптимизации бизнес-процессов.

Применение методики опытными сотрудниками позволяет сделать процесс построения ХД относительно простым, последовательным и измеримым по времени.

Agile-процесс по построению модели Data Vault включает в себя следующие шаги:

а) Выбрать вид отчетности для последующего его создания ~1 ч;

б) Определить исходные информационные системы, таблицы-источники ~2 ч;

в) Спроектировать ER-модель Data Vault ~1 ч;

г) Добавить атрибуты к существующей ER-модели ~5 ч;

д) Создать ETL-процедуры загрузки данных в Data Vault ~16 ч;

е) Спроектировать модель витрины данных для отчетности ~2 ч;

ж) Загрузить данные в витрины путем создания ETL-процедур или SQL-скриптов ~32 ч;

з) Построить отчеты на основе витрин данных ~16 ч;

и) Протестировать корректность данных в отчетах ~5 ч.



2.4 Архитектура Data Vault

Система Data Vault основана на трёхъярусной архитектуре. Исходное корпоративное хранилище данных отделяется от бизнес-пользователей и используемых ими слоев данных (например, схем «звезда»). Эта изоляция дополнительно снижает затраты и накладные расходы, связанные с изменениями, которые происходят на уровне бизнеса.

Тремя ярусами в данной архитектуре являются:

- Область подготовки данных (только для пакетов исходных данных);

- Корпоративное хранилище Data Vault;

- Витрины данных (рис. 5).

Рис. 5. Общий вид архитектуры Data Vault

В настоящих обрабатывающих системах реального времени ХД на основе Data Vault становится абонентом и инициатором ESB (Enterprise Service Bus, Сервисная Шина Предприятия). Сообщения в режиме реального времени не останавливаются в области подготовки данных, а направляются в ХД напрямую.

Путем разделения представительского слоя от слоя хранения всех корпоративных данных можно достичь согласованности в наборах результатов, а также внедрить, так называемый, self-service BI. Такое «разъединение» слоев дает возможность построить виртуальный слой витрин данных поверх ХД. Бизнес-пользователи получают право напрямую управлять этим виртуальным слоем и изменять его. Отсюда и термин: self-service BI.

Архитектура модели играет ключевую роль в разделении обязанностей, позволяя каждому компоненту быть масштабируемым надлежащим образом для того, чтобы удовлетворять постоянно меняющиеся потребности бизнеса. Обычно, говоря о масштабе, на ум приходят термины BIG DATA и NoSQL. За счет внедрения стандартов и спецификаций Data Vault 2.0 можно легко согласовать неструктурированные и полуструктурированные данные непосредственно в ХД.

2.5 Принципы загрузки данных

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

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

Разработка ETL для Data Vault ввиду несложной реализации позволяет создавать шаблоны и автоматизировать процесс. Сложности могут возникнуть только в случае, если таблицы Связи соединены друг с другом, а избежать данных ситуаций можно путем реорганизации модели, что является рекомендуемым решением.

Данные никогда не удаляются из хранилища Data Vault, за исключением случая, когда возникают технические ошибки во время загрузки данных [13].

2.6 Преимущества

В качестве подведения итогов рассмотрения модели Data Vault, выбранной в данной работе для построения хранилища данных в ИС, выделим ее основные преимущества перед аналогами.

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

- Поддержка больших объемов данных. Data Vault нотации 2.0 включает в себя полную интеграцию Big Data наряду с методологией, архитектурой и основными способами реализации. С помощью этого обновления большие данные могут быть легко включены в состав ХД.

- Простота построения корпоративного хранилища данных. Создание эффективной модели Data Vault может быть легко и быстро осуществлено с помощью трех основных типов таблиц: Хабов, Связей и Спутников. Загрузка данных также происходит быстро, т.к. может быть распараллелена ввиду особенностей модели.

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

2.7 Возможные области применения

Благодаря своей универсальности, методология Data Vault может быть применена во многих проектах и областях бизнеса.

Примеры некоторых структурных решений, использующих в своей основе Data Vault:

- Динамическое хранилище данных - ХД на основе автоматизированных изменений структуры и процессов в реальном времени.

- In-Database Data Mining - позволяет инструментам интеллектуального анализа использовать исторические данные из хранилища.

- Быстрая связь внешней информации - способность быстро адаптировать поступившие извне данные для анализа в ХД без нарушения целостности существующего содержимого.

Многие зарубежные крупные компании с мировой известностью используют корпоративные хранилища данных, построенные на архитектуре Data Vault. Примерами таких компаний служат Logica, Microsoft, SNS Bank и другие. В России методология Data Vault малоизвестна. Тем не менее, некоторые передовые организации, такие как Tele2 и Wildberries.ru, уже внедрили ее в свои аналитические системы. В данной работе рассматривается розничный интернет-магазин. Эволюция онлайн-торговли происходит с невероятной скоростью, а значит, направление развития компании, структура и логика бизнеса могут постоянно меняться. В таком случае легко расширяемая, хранящая все исторические данные методология отлично подойдет для успешного и удобного ведения бизнеса.



3. Создание информационной системы

3.1 Обоснование выбора применяемых инструментов

При создании любой информационной системы важно со всей ответственностью подойти к вопросу хранения данных. Организация темпорального ХД подразумевает под собой оперирование большими объемами данных, требует высокой производительности и безопасности. Здесь подходящим решением является СУБД Microsoft SQL Server 2012. Данная СУБД обладает высокой степенью надежности, достигаемой за счет применения таких технологий, как зеркалирование, средства управления журналами и кластеризация. Еще одно несомненное преимущество MS SQL Server заключается в ее возможности по масштабированию и высокой производительности. Функция партиционирования позволяет разбивать большие таблицы, в результате чего данные размещаются на разных физических носителях и, таким образом, операции чтения и записи ведутся параллельно. Безопасность данных в СУБД реализована с помощью поддержки современных алгоритмов шифрования. Все данные на жестком диске хранятся в зашифрованном виде. А также, MS SQL Server имеет клиентскую программу с удобным графическим интерфейсом и классическим языком запросов Transact SQL.

В качестве ETL-модуля был выбран Talend Data Integrator. Преимущества данного продукта заключаются в том, что это бесплатное программное обеспечение, обладающее широким функционалом и поддерживающее огромное количество реляционных и NoSQL СУБД. Все процессы трансформации данных создаются с помощью простейшего drag & drop, а, т.к. исходный код продукта написан на Java, то создать дополнительные процедуры по обработке данных не составляет труда при базовых знаниях языка программирования. Также Talend обладает высокой производительностью и способен запускать трансформации параллельно.

Для визуализации данных в работе использованы два приложения модуля Business Objects от компании SAP. Во-первых, Universe Designer - приложение для создания мета-слоя, набора данных, ограниченного понятной конечному пользователю предметной областью. Во-вторых, Web Intelligence - приложение для формирования аналитических отчетов на основе вышеупомянутого мета-слоя. Продукты SAP BO имеют интуитивно понятный интерфейс, удобный сервис обслуживания, мощную систему анализа данных, позволяющую получить более глубокое понимание бизнеса.

3.2 Анализ источника данных

Как правило, источником данных для информационной системы управления служат транзакционные системы организации, excel-таблицы или плоские файлы. В данной работе в качестве основы для анализа источника была взята OLTP-база данных реального магазина «profposuda.ru», занимающегося продажей ресторанного оборудования. Все наименования товаров реальны, а остальные данные обезличены, т.к. это коммерческая тайна компании.

При анализе источника данных были выделены следующие бизнес-процессы:

- Заказы поставщикам;

- Заказы покупателей;

- Продажи.

Далее представлена инфологическая модель бизнес-процессов в нотации BPMN [14] (рис. 6).



Рис. 6. Инфологическая модель бизнес-процессов

Логическая модель источника, построенная в нотации IDEF1X, разделена по бизнес-процессам и изображена на рис. 7 и 8.



Рис. 7. Продажи и заказы покупателей

Рис. 8. Заказы поставщику

Рисунок 9 изображает физическую схему базы данных.



Рис. 9. Физическая схема БД

Ниже приведено полное описание таблиц источника (табл. 5).

Таблица 5. Описание таблиц источника данных

Название таблицы	Название колонки	Первичный ключ	Внешний ключ	Тип данных
Company	CompanyID	P		NUMERIC (18)
	CompanyCode			NVARCHAR (50)
	CompanyName			NVARCHAR (50)
	Address			NVARCHAR (100)
Customer	CustomerID	P		NUMERIC (18)
	CustomerCode			NUMERIC (18)
	CustomerName			NVARCHAR (50)
	Address			NVARCHAR (100)
	Email			NVARCHAR (50)
CustomerOrder_Details	CustomerOrderDetailsID	P		NUMERIC (18)
	CustomerOrderHeaderID		F	NUMERIC (18)
	ProductID		F	NUMERIC (18)
	Quantity			NUMERIC (18)
	Price			REAL
	Summ			REAL
CustomerOrder_Header	CustomerOrderHeaderID	P		NUMERIC (18)
	CustomerOrderNumber			NUMERIC (18)
	OrderDate			Date
	SalesContractID		F	NUMERIC (18)
	CompanyID		F	NUMERIC (18)
	CustomerID		F	NUMERIC (18)
	WarehouseID		F	NUMERIC (18)
	ResponsibleID		F	NUMERIC (18)
Product	ProductID	P		NUMERIC (18
	ProductName			NVARCHAR (255)
	VendorCode			NVARCHAR (50)
	ProductLineID		F	NUMERIC (18)
	Producer			NVARCHAR (50)
	Price			REAL
ProductCategory	ProductCategoryID	P		NUMERIC (18)
	ProductCategoryName			NVARCHAR (50)
ProductLine	ProductLineID	P		NUMERIC (18)
	ProductLineName			NVARCHAR (100)
	ProductCategoryID		F	NUMERIC (18)
Responsible	ResponsibleID	P		NUMERIC (18)
	ResponsibleCode			NVARCHAR (50)
	ResponsibleName			NVARCHAR (50)
	Email			NVARCHAR (50)
	Telephone			NVARCHAR (20)
SalesContract	SalesContractID	P		NUMERIC (18)
	ConctractNumber			NVARCHAR (50)
	Date			Date
	FinishDate			Date
	CompanyID		F	NUMERIC (18)
Sales_Details	SalesDetailsID	P		NUMERIC (18)
	SalesHeaderID		F	NUMERIC (18)
	ProductID		F	NUMERIC (18)
	Quantity			NUMERIC (18)
	Price			REAL
	Summ			REAL
Sales_Header	SalesHeaderID	P		NUMERIC (18)
	SalesDocNumber			NUMERIC (18)
	DocumentDate			Date
	SalesContractID		F	NUMERIC (18)
	CompanyID		F	NUMERIC (18)
	CustomerID		F	NUMERIC (18)
	WarehouseID		F	NUMERIC (18)
	ResponsibleID		F	NUMERIC (18)
SupplierContract	SupplierContractID	P		NUMERIC (18)
	ContractNumber			NVARCHAR (50)
	Date			Date
	FinishDate			Date
	SupplierID		F	NUMERIC (18)
SupplierOrder_Details	SupplierOrderDetailsID	P		NUMERIC (18)
	SupplierOrderHeaderID		F	NUMERIC (18)
	ProductID		F	NUMERIC (18)
	Quantity			NUMERIC (18)
	Price			REAL
	Summ			REAL
SupplierOrder_Header	SupplierOrderHeaderID	P		NUMERIC (18)
	SupplierOrderNumber			NUMERIC (18)
	OrderDate			Date
	SupplierContractID		F	NUMERIC (18)
	CompanyID		F	NUMERIC (18)
	SupplierID		F	NUMERIC (18)
	WarehouseID		F	NUMERIC (18)
	ResponsibleID		F	NUMERIC (18)
Supplier	SupplierID	P		NUMERIC (18)
	SupplierCode			NUMERIC (18)
	SupplierName			NVARCHAR (50)
	Address			NVARCHAR (100)
	INN			NUMERIC (32)
Warehouse	WarehouseID	P		NUMERIC (18)
	WarehouseCode			NVARCHAR(50)
	WarehouseName			NVARCHAR (50)
	WarehouseType			NVARCHAR (20)
	CompanyID		F	NUMERIC (18)

3.3 Проектирование хранилища данных

В состав схемы базы данных источника включены 10 таблиц справочников:

- Company;

- Customer;

- Product;

- ProductCategory;

- ProductLine;

- Responsible;

- SalesContract;

- SupplierContract;

- Supplier;

- Warehouse.

3 заголовочных таблицы фактов:

- CustomerOrder_Header;

- Sales_Header;

- SupplierOrder_Header.

И 3 детальных таблицы фактов:

- CustomerOrder_Details;

- Sales_Details;

- SupplierOrder_Details.

При проектировании хранилища типа Data Vault необходимо создать:

а) Хабы на основе таблиц справочников и заголовков фактов, выделив из них бизнес-ключи. Принято, что Хабы на основе детальных таблиц фактов не создаются. Все их первичные и внешние ключи входят в состав таблицы Связи.

б) Связи на основе всех таблиц, в составе которых имеются внешние ключи.

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

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

Далее представлена таблица, на которой отражено соответствие таблиц источника таблицам в хранилище Data Vault (табл. 6).

Таблица 6. Список таблиц хранилища в соответствии с таблицами источника

Название таблицы источника	Название таблицы в хранилище
Company	HUB_Company SAT_Company
Customer	HUB_Customer SAT_Customer
CustomerOrder_Details	LNK_CustomerOrder_Details SAT_CustomerOrder_Details
CustomerOrder_Header	HUB_CustomerOrder LNK_CustomerOrder SAT_CustomerOrder
Product	HUB_Product LNK_Product_PLine SAT_Product
ProductCategory	HUB_ProductCategory SAT_ProductCategory
ProductLine	HUB_ProductLine LNK_PLine_PCategory SAT_ProductLine
Responsible	HUB_Responsible SAT_Responsible
SalesContract	HUB_SalesContract LNK_Company_Contract SAT_SalesContract
Sales_Details	LNK_Sales_Details SAT_Sales_Details
Sales_Header	HUB_Sales LNK_Sales SAT_Sales
SupplierContract	HUB_SupplierContract LNK_Supplier_Contract SAT_SupplierContract
SupplierOrder_Details	LNK_SupplierOrder_Details SAT_SupplierOrder_Details
SupplierOrder_Header	HUB_SupplierOrder LNK_SupplierOrder SAT_SupplierOrder
Supplier	HUB_Supplier SAT_Supplier
Warehouse	HUB_Warehouse LNK_Company_Warehouse SAT_Warehouse
	REF_Calendar

Табл. 7 отображает полное описание физической реализации хранилища Data Vault.

Таблица 7. Описание таблиц хранилища данных

Название таблицы	Название колонки	Первичный ключ	Внешний ключ	Тип данных
HUB_Company	HUB_Company_HSK	P		CHAR (32)
	comp_ID			Integer
	HUB_Company_LDTS			Datetime
	HUB_Company_RSRC			NVARCHAR (50)
HUB_Customer	HUB_Customer_HSK	P		CHAR (32)
	cust_ID			Integer
	HUB_Customer_LDTS			Datetime
	HUB_Customer_RSRC			NVARCHAR (50)
HUB_CustomerOrder	HUB_CustomerOrder_HSK	P		CHAR (32)
	custOrd_ID			Integer
	HUB_CustomerOrder_LDTS			Datetime
	HUB_CustomerOrder_RSRC			NVARCHAR (50)
HUB_Product	HUB_Product_HSK	P		CHAR (32)
	prod_ID			Integer
	HUB_Product_LDTS			Datetime
	HUB_Product_RSRC			NVARCHAR (50)
HUB_ProductCategory	HUB_ProductCategory_HSK	P		CHAR (32)
	prodCat_ID			Integer
	HUB_ProductCategory_LDTS			Datetime
	HUB_ProductCategory_RSRC			NVARCHAR (50)
HUB_ProductLine	HUB_ProductLine_HSK	P		CHAR (32)
	prodLine_ID			Integer
	HUB_ProductLine_LDTS			Datetime
	HUB_ProductLine_RSRC			NVARCHAR (50)
HUB_Responsible	HUB_Responsible_HSK	P		CHAR (32)
	resp_ID			Integer
	HUB_Responsible_LDTS			Datetime
	HUB_Responsible_RSRC			NVARCHAR (50)
HUB_Sales	HUB_Sales_HSK	P		CHAR (32)
	sales_ID			Integer
	HUB_Sales_LDTS			Datetime
	HUB_Sales_RSRC			NVARCHAR (50)
HUB_SalesContract	HUB_SalesContract_HSK	P		CHAR (32)
	salesC_ID			Integer
	HUB_SalesContract_LDTS			Datetime
	HUB_SalesContract_RSRC			NVARCHAR (50)
HUB_Supplier	HUB_Supplier_HSK	P		CHAR (32)
	suppl_ID			Integer
	HUB_Supplier_LDTS			Datetime
	HUB_Supplier_RSRC			NVARCHAR (50)
HUB_SupplierContract	HUB_SupplierContract_HSK	P		CHAR (32)
	supplC_ID			Integer
	HUB_SupplierContract_LDTS			Datetime
	HUB_SupplierContract_RSRC			NVARCHAR (50)
HUB_SupplierOrder	HUB_SupplierOrder_HSK	P		CHAR (32)
	supplOrd_ID			Integer
	HUB_SupplierOrder_LDTS			Datetime
	HUB_SupplierOrder_RSRC			NVARCHAR (50)
HUB_Warehouse	HUB_Warehouse_HSK	P		CHAR (32)
	wareh_ID			Integer
	HUB_Warehouse_LDTS			Datetime
	HUB_Warehouse_RSRC			NVARCHAR (50)
LNK_Company_Contract	LNK_Company_Contract_HSK	P		CHAR (32)
	LNK_Company_Contract_LDTS			Datetime
	LNK_Company_Contract_RSRC			NVARCHAR (50)
	HUB_Company_HSK		F	CHAR (32)
	HUB_SalesContract_HSK		F	CHAR (32)
LNK_Company_Warehouse	LNK_Company_Warehouse_HSK	P		CHAR (32)
	LNK_Company_Warehouse_LDTS			Datetime
	LNK_Company_Warehouse_RSRC			NVARCHAR (50)
	HUB_Company_HSK		F	CHAR (32)
	HUB_Warehouse_HSK		F	CHAR (32)
LNK_CustomerOrder	LNK_CustomerOrder_HSK	P		CHAR (32)
	LNK_CustomerOrder_LDTS			Datetime
	LNK_CustomerOrder_RSRC			NVARCHAR (50)
	HUB_CustomerOrder_HSK		F	CHAR (32)
	HUB_Company_HSK		F	CHAR (32)
	HUB_Customer_HSK		F	CHAR (32)
	HUB_Warehouse_HSK		F	CHAR (32)
	HUB_SalesContract_HSK		F	CHAR (32)
	HUB_Responsible_HSK		F	CHAR (32)
LNK_CustomerOrder_Details	LNK_CustomerOrder_Details_HSK	P		CHAR (32)
	LNK_CustomerOrder_Details_LDTS			Datetime
	LNK_CustomerOrder_Details_RSRC			NVARCHAR (50)
	HUB_CustomerOrder_HSK		F	CHAR (32)
	HUB_Product_HSK		F	CHAR (32)
LNK_PLine_PCategory	LNK_PLine_PCategory_HSK	P		CHAR (32)
	LNK_PLine_PCategory_LDTS			Datetime
	LNK_PLine_PCategory_RSRC			NVARCHAR (50)
	HUB_ProductLine_HSK		F	CHAR (32)
	HUB_ProductCategory_HSK		F	CHAR (32)
LNK_Product_PLine	LNK_Product_PLine_HSK	P		CHAR (32)
	LNK_Product_PLine_LDTS			Datetime
	LNK_Product_PLine_RSRC			NVARCHAR (50)
	HUB_Product_HSK		F	CHAR (32)
	HUB_ProductLine_HSK		F	CHAR (32)
LNK_Sales	LNK_Sales_HSK	P		CHAR (32)
	LNK_Sales_LDTS			Datetime
	LNK_Sales_RSRC			NVARCHAR (50)
	HUB_Sales_HSK		F	CHAR (32)
	HUB_Company_HSK		F	CHAR (32)
	HUB_Customer_HSK		F	CHAR (32)
	HUB_Warehouse_HSK		F	CHAR (32)
	HUB_SalesContract_HSK		F	CHAR (32)
	HUB_Responsible_HSK		F	CHAR (32)
LNK_Sales_Details	LNK_Sales_Details_HSK	P		CHAR (32)
	LNK_Sales_Details_LDTS			Datetime
	LNK_Sales_Details_RSRC			NVARCHAR (50)
	HUB_Sales_HSK		F	CHAR (32)
	HUB_Product_HSK		F	CHAR (32)
LNK_SupplierOrder	LNK_SupplierOrder_HSK	P		CHAR (32)
	LNK_SupplierOrder_LDTS			Datetime
	LNK_SupplierOrder_RSRC			NVARCHAR (50)
	HUB_SupplierOrder_HSK		F	CHAR (32)
	HUB_Company_HSK		F	CHAR (32)
	HUB_Supplier_HSK		F	CHAR (32)
	HUB_Warehouse_HSK		F	CHAR (32)
	HUB_SupplierContract_HSK		F	CHAR (32)
	HUB_Responsible_HSK		F	CHAR (32)
LNK_SupplierOrder_Details	LNK_SupplierOrder_Details_HSK	P		CHAR (32)
	LNK_SupplierOrder_Details_LDTS			Datetime
	LNK_SupplierOrder_Details_RSRC			NVARCHAR (50)
	HUB_SupplierOrder_HSK		F	CHAR (32)
	HUB_Product_HSK		F	CHAR (32)
LNK_Supplier_Contract	LNK_Supplier_Contract_HSK	P		CHAR (32)
	LNK_Supplier_Contract_LDTS			Datetime
	LNK_Supplier_Contract_RSRC			NVARCHAR (50)
	HUB_Supplier_HSK		F	CHAR (32)
	HUB_SupplierContract_HSK		F	CHAR (32)
REF_Calendar	DateID	P		Integer
	Day			CHAR (2)
	DaySuffix			NVARCHAR (4)
	DayOfWeek			NVARCHAR (9)
	DOWInMonth			Integer
	DayOfYear			Integer
	WeekOfYear			Integer
	WeekOfMonth			Integer
	Month			CHAR (2)
	MonthName			NVARCHAR (9)
	Quarter			Integer
	QuarterName			NVARCHAR (6)
	Year			CHAR (4)
SAT_Company	CompanyCode			NVARCHAR (50)
	CompanyName			NVARCHAR (50)
	Address			NVARCHAR (100)
	HUB_Company_HSK	P	F	CHAR (32)
	SAT_Company_LDTS	P		Datetime
	SAT_Company_RSRC			NVARCHAR (50)
	SAT_Company_HDIFF			CHAR (32)
SAT_Customer	CustomerCode			NUMERIC (18)
	CustomerName			NVARCHAR (50)
	Address			NVARCHAR (100)
	Email			NVARCHAR (50)
	HUB_Customer_HSK	P	F	CHAR (32)
	SAT_Customer_LDTS	P		Datetime
	SAT_Customer_RSRC			NVARCHAR (50)
	SAT_Customer_HDIFF			CHAR (32)
SAT_CustomerOrder	CustomerOrderNumber			NUMERIC (18)
	OrderDate			Date
	HUB_CustomerOrder_HSK	P	F	CHAR (32)
	SAT_CustomerOrder_LDTS	P		Datetime
	SAT_CustomerOrder_RSRC			NVARCHAR (50)
	SAT_CustomerOrder_HDIFF			CHAR (32)
SAT_CustomerOrder_Details	Quantity			NUMERIC (18)
	Price			REAL
	Summ			REAL
	LNK_CustomerOrder_Details_HSK	P	F	CHAR (32)
	SAT_CustomerOrder_Details_LDTS	P		Datetime
	SAT_CustomerOrder_Details_RSRC			NVARCHAR (50)
	SAT_CustomerOrder_Details_HDIFF			CHAR (32)
SAT_Product	ProductName			NVARCHAR (255)
	VendorCode			NVARCHAR (50)
	Producer			NVARCHAR (50)
	Price			REAL
	HUB_Product_HSK	P	F	CHAR (32)
	SAT_Product_LDTS	P		Datetime
	SAT_Product_RSRC			NVARCHAR (50)
	SAT_Product_HDIFF			CHAR (32)
SAT_ProductCategory	ProductCategoryName			NVARCHAR (50)
	HUB_ProductCategory_HSK	P	F	CHAR (32)
	SAT_ProductCategory_LDTS	P		Datetime
	SAT_ProductCategory_RSRC			NVARCHAR (50)
	SAT_ProductCategory_HDIFF			CHAR (32)
SAT_ProductLine	ProductLineName			NVARCHAR (100)
	HUB_ProductLine_HSK	P	F	CHAR (32)
	SAT_ProductLine_LDTS	P		Datetime
	SAT_ProductLine_RSRC			NVARCHAR (50)
	SAT_ProductLine_HDIFF			CHAR (32)
SAT_Responsible	ResponsibleCode			NVARCHAR (50)
	ResponsibleName			NVARCHAR (50)
	Email			NVARCHAR (50)
	Telephone			NVARCHAR (20)
	HUB_Responsible_HSK	P	F	CHAR (32)
	SAT_Responsible_LDTS	P		Datetime
	SAT_Responsible_RSRC			NVARCHAR (50)
	SAT_Responsible_HDIFF			CHAR (32)
SAT_Sales	SalesDocNumber			NUMERIC (18)
	DocumentDate			Date
	HUB_Sales_HSK	P	F	CHAR (32)
	SAT_Sales_LDTS	P		Datetime
	SAT_Sales_RSRC			NVARCHAR (50)
	SAT_Sales_HDIFF			CHAR (32)
SAT_SalesContract	ContractNumber			NVARCHAR (50)
	Date			Date
	FinishDate			Date
	HUB_SalesContract_HSK	P	F	CHAR (32)
	SAT_SalesContract_LDTS	P		Datetime
	SAT_SalesContract_RSRC			NVARCHAR (50)
	SAT_SalesContract_HDIFF			CHAR (32)
SAT_Sales_Details	Quantity			NUMERIC (18)
	Price			REAL
	Summ			REAL
	LNK_Sales_Details_HSK	P	F	CHAR (32)
	SAT_Sales_Details_LDTS	P		Datetime
	SAT_Sales_Details_RSRC			NVARCHAR (50)
	SAT_Sales_Details_HDIFF			CHAR (32)
SAT_Supplier	SupplierCode			NUMERIC (18)
	SupplierName			NVARCHAR (50)
	Address			NVARCHAR (100)
	INN			NUMERIC (32)
	HUB_Supplier_HSK	P	F	CHAR (32)
	SAT_Supplier_LDTS	P		Datetime
	SAT_Supplier_RSRC			NVARCHAR (50)
	SAT_Supplier_HDIFF			CHAR (32)
SAT_SupplierContract	ContractNumber			NVARCHAR (50)
	Date			Date
	FinishDate			Date
	HUB_SupplierContract_HSK	P	F	CHAR (32)
	SAT_SupplierContract_LDTS	P		Datetime
	SAT_SupplierContract_RSRC			NVARCHAR (50)
	SAT_SupplierContract_HDIFF			CHAR (32)
SAT_SupplierOrder	SupplierOrderNumber			NUMERIC (18)
	OrderDate			Date
	HUB_SupplierOrder_HSK	P	F	CHAR (32)
	SAT_SupplierOrder_LDTS	P		Datetime
	SAT_SupplierOrder_RSRC			NVARCHAR (50)
	SAT_SupplierOrder_HDIFF			CHAR (32)
SAT_SupplierOrder_Details	Quantity			NUMERIC (18)
	Price			REAL
	Summ			REAL
	LNK_SupplierOrder_Details_HSK	P	F	CHAR (32)
	SAT_SupplierOrder_Details_LDTS	P		Datetime
	SAT_SupplierOrder_Details_RSRC			NVARCHAR (50)
	SAT_SupplierOrder_Details_HDIFF			CHAR (32)
SAT_Warehouse	WarehouseCode			NVARCHAR (50)
	WarehouseName			NVARCHAR (50)
	WarehouseType			NVARCHAR (20)
	HUB_Warehouse_HSK	P	F	CHAR (32)
	SAT_Warehouse_LDTS	P		Datetime
	SAT_Warehouse_RSRC			NVARCHAR (50)
	SAT_Warehouse_HDIFF			CHAR (32)



DDL скрипт создания таблиц приведен в Приложении 2.

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

3.4 Загрузка данных из источника средствами ETL

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

Приступить к созданию ETL-процесса необходимо с настройки соединения к базе данных источника и к, собственно, целевому ХД. В данном случае удобнее всего воспользоваться JDBC-драйвером, как показано на рис. 11.



Рис. 11. Окно настройки соединения в Talend Data Integrator

Загрузка данных в Data Vault происходит в три шага. Первыми грузятся параллельно все Хабы, затем Связи, и последними загружаются Спутники. Т.к. все процессы по загрузке таблиц каждого типа идентичны, рассмотрим особенности всех трансформаций на примере таблицы источника Sales_Header.

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



Рис. 12. Процесс загрузки Хаба

Суррогатный ключ Хаба формируется на основе бизнес-ключа таблицы источника. Во взятой для примера таблице Sales_Header таким ключом является поле SalesHeaderID. SQL-код создания суррогатного ключа Хаба представлен ниже:

UPPER(CONVERT(char(32),HASHBYTES('MD5',UPPER(RTRIM(LTRIM(CONVERT(varchar, COALESCE(Sales_Header.SalesHeaderID, '')))))),2))

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

Рис. 13. Процесс загрузки Связи

В формирование суррогатного ключа Связи помимо бизнес-ключа исходной таблицы включаются все внешние ключи. В таблице Sales_Header это CompanyID, CustomerID, SalesContractID, ResponsibleID, WarehouseID. SQL-код создания ключа:

UPPER(CONVERT(char(32),HASHBYTES('MD5',UPPER(RTRIM(LTRIM(CONVERT(varchar,COALESCE(Sales_Header.SalesHeaderID,'')))))+'|'+UPPER(RTRIM(LTRIM(CONVERT(varchar,COALESCE(Sales_Header.SalesContractID, '')))))+'|'+UPPER(RTRIM(LTRIM(CONVERT(varchar,COALESCE(Sales_Header.CompanyID, '')))))+'|'+ UPPER(RTRIM(LTRIM(CONVERT(varchar,COALESCE(Sales_Header.CustomerID,'')))))+'|'+ UPPER(RTRIM(LTRIM(CONVERT(varchar,COALESCE(Sales_Header.WarehouseID,'')))))+'|'+(UPPER(RTRIM(LTRIM(CONVERT(varchar,COALESCE(Sales_Header.ResponsibleID, ''))))))),2))

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

SELECT l1.LNK_Sales_HSK,

l1.LNK_Sales_LDTS,

l1.LNK_Sales_RSRC,

l1.HUB_Sales_HSK,

l1.HUB_Company_HSK,

l1.HUB_Customer_HSK,

l1.HUB_Warehouse_HSK,

l1.HUB_SalesContract_HSK,

l1.HUB_Responsible_HSK

FROMLNK_Sales l1

WHERE l1.LNK_Sales_LDTS = (SELECT

MAX(l2.LNK_Sales_LDTS) as max from LNK_Sales l2

WHERE l1.LNK_Sales_HSK = l2.LNK_Sales_HSK)

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

Процесс загрузки Спутников отличается лишь отсутствием собственного суррогатного ключа. Спутники имеют составной первичный ключ из суррогатного ключа Хаба, атрибуты которого он хранит, и временной метки. Однако, у Спутника есть дополнительное поле, отслеживающее изменения в вышеупомянутых атрибутах. Запись в данное поле формируется также с помощью алгоритма MD5, но включает в себя бизнес-ключ таблицы источника и все описательные поля. В таблице Sales_Header описательными являются поля SalesDocNum и DocumentDate. SQL-код здесь выглядит следующим образом:

UPPER(CONVERT(char(32),HASHBYTES('MD5',UPPER(RTRIM(LTRIM(CONVERT(varchar,COALESCE(Sales_Header.SalesHeaderID, '')))))+'|'+ UPPER(RTRIM(LTRIM(CONVERT(varchar,COALESCE(Sales_Header.SalesDocNumber, '')))))+'|'+(UPPER(RTRIM(LTRIM(CONVERT(varchar, COALESCE(Sales_Header.DocumentDate, ''))))))),2))

Пример ETL-процесса для Спутника (рис. 14):



Рис. 14. Процесс загрузки Спутника

Talend Data Integrator позволяет выполнять несколько процессов в параллельном режиме, что намного ускоряет загрузку данных. Ниже представлен пример параллельной загрузки всех таблиц Связей (рис. 15).

Рис. 15. Параллельная загрузка всех Связей

Далее необходимо создать главный процесс, при запуске которого пользователь будет обновлять все данные в хранилище. Такой процесс будет последовательно запускать загрузку Хабов, затем Связей и, наконец, Спутников (рис. 16).



Рис. 16. Главный (Main) процесс

3.5 Создание витрины данных

Данные в хранилище Data Vault хранятся в сильно нормализованном виде 3NF в большом количестве разделенных таблиц, что затрудняет доступ к ним. Как упоминалось ранее во втором разделе данной работы, архитектура Data Vault включает в себя три яруса, последним из которых являются витрины данных. Для их реализации необходимо написать SQL-запросы по созданию представлений (views) на основе модели ХД, объединив бизнес-ключи Хабов с атрибутами Спутников. Код создания представлений приведен в Приложении 3.