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

Оглавление

• Введение
• 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. Сравнение двух классических методологий создания ХД

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. Структура таблицы Хаб

2.2.2 Связи

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

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

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

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

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

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

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

Спутники

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

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

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

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

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. Описание таблиц источника данных

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. Список таблиц хранилища в соответствии с таблицами источника

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

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

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.

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

Модель витрины данных представляет собой схему Снежинка и представлена в общем виде на рис. 17.

3.6 Создание мета-слоя с использованием SAP Business Objects

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

В данной работе таким продуктом был выбран SAP Business Objects [15]. При помощи модуля Universe Designer можно создать, так называемый, юниверс - семантический слой, который изолирует конечного пользователя от технических подробностей структуры базы данных.

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

Слой метаданных или семантический слой основывается на парадигме юниверсов, классов и объектов.

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

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

Процесс создания юниверса начинается с настройки соединения с ХД. В первой фазе идет описание всех таблиц, колонок и связей. Во второй фазе создаются объекты бизнеса путем SQL-запросов.

Реляционная структура и логическое представление созданного юниверса представлены на рис. 18.

Рис. 18. Юниверс в Universe Designer

3.7 Визуализация данных в аналитических отчетах

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

Панель делится на три основных окна:

- Список объектов юниверса. Здесь расположены объекты, которые определены в юниверсе. Объекты сгруппированы по классам.

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

- Условия. В правом нижнем окне описываются ограничения, которые накладываются на запрос.

Синтаксис SQL генерируется в Web Intelligence автоматически после добавления объекта в запрос.

Далее представлены фрагменты разработанных отчетов (рис. 20-22).

Рис. 22. Фрагмент отчета «Продажи сотрудников за выбранный год»

Заключение

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

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

Были выполнены следующие задачи:

- Анализ источника данных с выявлением ключевых бизнес-процессов.

- Проектирование хранилища данных по методологии Data Vault.

- Создание ETL-процессов по очистке и загрузке данных из источника в хранилище.

- Построение виртуальной витрины данных.

- Разработка семантического слоя в приложении для бизнес-аналитики.

- Визуализация данных в отчетах.

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

Перечень сокращений

ИС - Информационная система

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

ETL - Extract Transform Load

3NF - Third Normal Form

CIF - Corporate Information Factory

BPMN - Business Process Model and Notation

ER - Entity Relationship

BI - Business Intelligence

JDBC - Java DataBase Connectivity

СУБД - Система управления базами данных

Список используемой литературы

1. Васильев Р.Б., Калянов Г.Н., Лёвочкина Г.А. Управление развитием информационных систем. -- М.: Горячая линия - Телеком, 2009.

2. Rainer, R. Introduction to Information System: Support and Transforming Business Fourth Edition. New Jersey: John Wiley and Sons, Inc., 2012.

3. Onlinecampus.bu.edu, 'Management Information Systems and Decision-Making: An Overview'. URL: https://onlinecampus.bu.edu/bbcswebdav/pid-843933-dt-content-rid-2221759_1/courses/13sprgmetad715_ol/module_03a/metad715_m03l02t02_managementinfosystems.html (дата обращения: 10.04.2016).

4. Devlin, B. 'Temporal data reality: In BI, time is of the essence'. URL: http://searchbusinessanalytics.techtarget.com/feature/Temporal-data-reality-In-BI-time-is-of-the-essence (дата обращения: 10.04.2016).

5. Inmon, W.H., Imhoff, C., Sousa R. Corporate Information Factory. New Jersey: Wiley, 2001.

6. Inmon W.H. 'The evolution of corporate information factory'. URL: http://www.ewsolutions.com/resource-center/rwds_folder/rwds-archives/rwds-2001-10/corporate-information-factory (дата обращения: 12.04.2016).

7. Centhala S. 'Comparison of Bill Inmon and Ralph Kimball paradigm', 2009. URL: http://srinicenthala.blogspot.ru/2009/01/comparison-of-bill-inmon-and-ralph.html (дата обращения: 13.04.2016).

8. Kimball, R., Ross, M. The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling. New Jersey: Wiley, 2013.

9. Zentut.com, 'Kimball vs. Inmon Data Warehouse Architectures'. URL: http://www.zentut.com/data-warehouse/kimball-and-inmon-data-warehouse-architectures/ (дата обращения: 13.04.2016).

10. Breslin, M. 'Data Warehousing Battle of Giants: Comparing the Basics of the Kimball and Inmon Models'. URL: http://www.olap.it/Articoli/Battle%20of%20the%20giants%20-%20comparing%20Kimball%20and%20Inmon.pdf (дата обращения: 16.04.2016).

11. Linstedt, D. 'Data Vault Series 1 - Overview', 2002. URL: http://tdan.com/data-vault-series-1-data-vault-overview/5054 (дата обращения: 17.04.2016).

12. Linstedt, D. Super Charge Your Data Warehouse. North Charslton: Createspace, 2011.

13. Linstedt, D. 'Data Vault Introduction and Overview', 2013. URL: http://biblogg.no/2013/02/15/data-vault-introduction-and-overview/ (дата обращения: 17.04.2016).

14. Businessstudio.ru, 'Нотация BPMN'. URL: http://www.businessstudio.ru/wiki/docs/v4/doku.php/ru/csdesign/bpmodeling/bpmn_notation (дата обращения: 19.04.2016).

15. Tadviser.ru, 'SAP Business Intelligence', 2015. URL: http://www.tadviser.ru/index.php/%D0%9F%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82:SAP_Business_Intelligence_(SAP_BI) (дата обращения: 28.04.2016).

Приложения

Приложение 1

SQL-скрипт создания и заполнения таблицы «Календарь»

Приложение 2

SQL-скрипт создания таблиц в хранилище данных Data Vault

create table HUB_Customer (

HUB_Customer_HSK char(32) not null,

cust_ID int,

HUB_Customer_LDTS datetime,

HUB_Customer_RSRC nvarchar(50),

PRIMARY KEY(HUB_Customer_HSK)

);

create table HUB_Company (

HUB_Company_HSK char(32) not null,

comp_ID int,

HUB_Company_LDTS datetime,

HUB_Company_RSRC nvarchar(50),

PRIMARY KEY(HUB_Company_HSK)

);

create table HUB_SalesContract (

HUB_SalesContract_HSK char(32) not null,

salesC_ID int,

HUB_SalesContract_LDTS datetime,

HUB_SalesContract_RSRC nvarchar(50),

PRIMARY KEY(HUB_SalesContract_HSK)

);

create table HUB_Warehouse (

HUB_Warehouse_HSK char(32) not null,

wareh_ID int,

HUB_Warehouse_LDTS datetime,

HUB_Warehouse_RSRC nvarchar(50),

PRIMARY KEY(HUB_Warehouse_HSK)

);

create table HUB_Supplier (

HUB_Supplier_HSK char(32) not null,

suppl_ID int,

HUB_Supplier_LDTS datetime,

HUB_Supplier_RSRC nvarchar(50),

PRIMARY KEY(HUB_Supplier_HSK)

);

create table HUB_Responsible (

HUB_Responsible_HSK char(32) not null,

resp_ID int,

HUB_Responsible_LDTS datetime,

HUB_Responsible_RSRC nvarchar(50),

PRIMARY KEY(HUB_Responsible_HSK)

);

create table HUB_SupplierContract (

HUB_SupplierContract_HSK char(32) not null,

supplC_ID int,

HUB_SupplierContract_LDTS datetime,

HUB_SupplierContract_RSRC nvarchar(50),

PRIMARY KEY(HUB_SupplierContract_HSK)

);

create table HUB_Product (

HUB_Product_HSK char(32) not null,

prod_ID int,

HUB_Product_LDTS datetime,

HUB_Product_RSRC nvarchar(50),

PRIMARY KEY(HUB_Product_HSK)

);

create table HUB_ProductLine (

HUB_ProductLine_HSK char(32) not null,

prodLine_ID int,

HUB_ProductLine_LDTS datetime,

HUB_ProductLine_RSRC nvarchar(50),

PRIMARY KEY(HUB_ProductLine_HSK)

);

create table HUB_ProductCategory (

HUB_ProductCategory_HSK char(32) not null,

prodCat_ID int,

HUB_ProductCategory_LDTS datetime,

HUB_ProductCategory_RSRC nvarchar(50),

PRIMARY KEY(HUB_ProductCategory_HSK)

);

create table HUB_Sales (

HUB_Sales_HSK char(32) not null,

sales_ID int,

HUB_Sales_LDTS datetime,

HUB_Sales_RSRC nvarchar(50),

PRIMARY KEY(HUB_Sales_HSK)

);

create table HUB_CustomerOrder (

HUB_CustomerOrder_HSK char(32) not null,

custOrd_ID int,

HUB_CustomerOrder_LDTS datetime,

HUB_CustomerOrder_RSRC nvarchar(50),

PRIMARY KEY(HUB_CustomerOrder_HSK)

);

create table HUB_SupplierOrder (

HUB_SupplierOrder_HSK char(32) not null,

supplOrd_ID int,

HUB_SupplierOrder_LDTS datetime,

HUB_SupplierOrder_RSRC nvarchar(50),

PRIMARY KEY(HUB_SupplierOrder_HSK)

);

create table LNK_Sales (

LNK_Sales_HSK char(32) not null,

LNK_Sales_LDTS datetime,

LNK_Sales_RSRC nvarchar(50),

HUB_Sales_HSK char(32) not null,

HUB_Company_HSK char(32) not null,

HUB_Customer_HSK char(32) not null,

HUB_Warehouse_HSK char(32) not null,

HUB_SalesContract_HSK char(32) not null,

HUB_Responsible_HSK char(32) not null

PRIMARY KEY (LNK_Sales_HSK)

);

create table LNK_CustomerOrder (

LNK_CustomerOrder_HSK char(32) not null,

LNK_CustomerOrder_LDTS datetime,

LNK_CustomerOrder_RSRC nvarchar(50),

HUB_CustomerOrder_HSK char(32) not null,

HUB_Company_HSK char(32) not null,

HUB_Customer_HSK char(32) not null,

HUB_Warehouse_HSK char(32) not null,

HUB_SalesContract_HSK char(32) not null,

HUB_Responsible_HSK char(32) not null

PRIMARY KEY (LNK_CustomerOrder_HSK)

);

create table LNK_SupplierOrder (

LNK_SupplierOrder_HSK char(32) not null,

LNK_SupplierOrder_LDTS datetime,

LNK_SupplierOrder_RSRC nvarchar(50),

HUB_SupplierOrder_HSK char(32) not null,

HUB_Company_HSK char(32) not null,

HUB_Supplier_HSK char(32) not null,

HUB_Warehouse_HSK char(32) not null,

HUB_SupplierContract_HSK char(32) not null,

HUB_Responsible_HSK char(32) not null

PRIMARY KEY (LNK_SupplierOrder_HSK)

);

create table LNK_Sales_Details (

LNK_Sales_Details_HSK char(32) not null,

LNK_Sales_Details_LDTS datetime,

LNK_Sales_Details_RSRC nvarchar(50),

HUB_Sales_HSK char(32) not null,

HUB_Product_HSK char(32) not null,

salesDID int,

PRIMARY KEY (LNK_Sales_Details_HSK)

);

create table LNK_CustomerOrder_Details (

LNK_CustomerOrder_Details_HSK char(32) not null,

LNK_CustomerOrder_Details_LDTS datetime,

LNK_CustomerOrder_Details_RSRC nvarchar(50),

HUB_CustomerOrder_HSK char(32) not null,

HUB_Product_HSK char(32) not null,

custODID int,

PRIMARY KEY (LNK_CustomerOrder_Details_HSK)

);

create table LNK_SupplierOrder_Details (

LNK_SupplierOrder_Details_HSK char(32) not null,

LNK_SupplierOrder_Details_LDTS datetime,

LNK_SupplierOrder_Details_RSRC nvarchar(50),

HUB_SupplierOrder_HSK char(32) not null,

HUB_Product_HSK char(32) not null,

suppODID int,

PRIMARY KEY (LNK_SupplierOrder_Details_HSK)

);

create table LNK_Product_PLine (

LNK_Product_PLine_HSK char(32) not null,

LNK_Product_PLine_LDTS datetime,

LNK_Product_PLine_RSRC nvarchar(50),

HUB_Product_HSK char(32) not null,

HUB_ProductLine_HSK char(32) not null,

PRIMARY KEY (LNK_Product_PLine_HSK)

);

create table LNK_PLine_PCategory (

LNK_PLine_PCategory_HSK char(32) not null,

LNK_PLine_PCategory_LDTS datetime,

LNK_PLine_PCategory_RSRC nvarchar(50),

HUB_ProductLine_HSK char(32) not null,

HUB_ProductCategory_HSK char(32) not null,

PRIMARY KEY (LNK_PLine_PCategory_HSK)

);

create table LNK_Company_Warehouse (

LNK_Company_Warehouse_HSK char(32) not null,

LNK_Company_Warehouse_LDTS datetime,

LNK_Company_Warehouse_RSRC nvarchar(50),

HUB_Company_HSK char(32) not null,

HUB_Warehouse_HSK char(32) not null,

PRIMARY KEY (LNK_Company_Warehouse_HSK)

);

create table LNK_Company_Contract (

LNK_Company_Contract_HSK char(32) not null,

LNK_Company_Contract_LDTS datetime,

LNK_Company_Contract_RSRC nvarchar(50),

HUB_Company_HSK char(32) not null,

HUB_SalesContract_HSK char(32) not null,

PRIMARY KEY (LNK_Company_Contract_HSK)

);

create table LNK_Supplier_Contract (

LNK_Supplier_Contract_HSK char(32) not null,

LNK_Supplier_Contract_LDTS datetime,

LNK_Supplier_Contract_RSRC nvarchar(50),

HUB_Supplier_HSK char(32) not null,

HUB_SupplierContract_HSK char(32) not null,

PRIMARY KEY (LNK_Supplier_Contract_HSK)

);

create table SAT_Product (

ProductName nvarchar(255) not null,

VendorCode nvarchar(50) not null,

Producer nvarchar(50) not null,

Price real not null,

HUB_Product_HSK char(32) not null,

SAT_Product_LDTS datetime not null,

SAT_Product_RSRC nvarchar(50),

SAT_Product_HDIFF char(32),

PRIMARY KEY (HUB_Product_HSK, SAT_Product_LDTS),

FOREIGN KEY (HUB_Product_HSK) REFERENCES HUB_Product (HUB_Product_HSK)

);

create table SAT_ProductLine (

ProductLineName nvarchar(100) not null,

HUB_ProductLine_HSK char(32) not null,

SAT_ProductLine_LDTS datetime not null,

SAT_ProductLine_RSRC nvarchar(50),

SAT_ProductLine_HDIFF char(32),

PRIMARY KEY (HUB_ProductLine_HSK, SAT_ProductLine_LDTS),

FOREIGN KEY (HUB_ProductLine_HSK) REFERENCES HUB_ProductLine (HUB_ProductLine_HSK)

);

create table SAT_ProductCategory (

ProductCategoryName nvarchar(50) not null,

HUB_ProductCategory_HSK char(32) not null,

SAT_ProductCategory_LDTS datetime not null,

SAT_ProductCategory_RSRC nvarchar(50),

SAT_ProductCategory_HDIFF char(32),

PRIMARY KEY (HUB_ProductCategory_HSK, SAT_ProductCategory_LDTS),

FOREIGN KEY (HUB_ProductCategory_HSK) REFERENCES HUB_ProductCategory (HUB_ProductCategory_HSK)

);

create table SAT_Responsible (

ResponsibleCode nvarchar(50) not null,

ResponsibleName nvarchar(50) not null,

Email nvarchar(50) not null,

Telephone nvarchar(20) not null,

HUB_Responsible_HSK char(32) not null,

SAT_Responsible_LDTS datetime not null,

SAT_Responsible_RSRC nvarchar(50),

SAT_Responsible_HDIFF char(32),

PRIMARY KEY (HUB_Responsible_HSK, SAT_Responsible_LDTS),

FOREIGN KEY (HUB_Responsible_HSK) REFERENCES HUB_Responsible (HUB_Responsible_HSK)

);

create table SAT_Supplier (

SupplierCode numeric(18) not null,

SupplierName nvarchar(50) not null,

Address nvarchar(100) not null,

INN numeric(32) not null,

HUB_Supplier_HSK char(32) not null,

SAT_Supplier_LDTS datetime not null,

SAT_Supplier_RSRC nvarchar(50),

SAT_Supplier_HDIFF char(32),

PRIMARY KEY (HUB_Supplier_HSK, SAT_Supplier_LDTS),

FOREIGN KEY (HUB_Supplier_HSK) REFERENCEs HUB_Supplier (HUB_Supplier_HSK)

);

create table SAT_SupplierContract (

ContractNumber nvarchar(50) not null,

Date date not null,

FinishDate date,

HUB_SupplierContract_HSK char(32) not null,

SAT_SupplierContract_LDTS datetime not null,

SAT_SupplierContract_RSRC nvarchar(50),

SAT_SupplierContract_HDIFF char(32),

PRIMARY KEY (HUB_SupplierContract_HSK, SAT_SupplierContract_LDTS),

FOREIGN KEY (HUB_SupplierContract_HSK) REFERENCEs HUB_SupplierContract (HUB_SupplierContract_HSK)

);

create table SAT_SalesContract (

ContractNumber nvarchar(50) not null,

Date date not null,

FinishDate date not null,

HUB_SalesContract_HSK char(32) not null,

SAT_SalesContract_LDTS datetime not null,

SAT_SalesContract_RSRC nvarchar(50),

SAT_SalesContract_HDIFF char(32),

PRIMARY KEY (HUB_SalesContract_HSK, SAT_SalesContract_LDTS),

FOREIGN KEY (HUB_SalesContract_HSK) REFERENCEs HUB_SalesContract (HUB_SalesContract_HSK)

);

create table SAT_Company (

CompanyCode nvarchar(50) not null,

CompanyName nvarchar(50) not null,

Address nvarchar(100) not null,

HUB_Company_HSK char(32) not null,

SAT_Company_LDTS datetime not null,

SAT_Company_RSRC nvarchar(50),

SAT_Company_HDIFF char(32),

PRIMARY KEY (HUB_Company_HSK, SAT_Company_LDTS),

FOREIGN KEY (HUB_Company_HSK) REFERENCEs HUB_Company (HUB_Company_HSK)

);

create table SAT_Warehouse (

WarehouseCode nvarchar(50) not null,

WarehouseName nvarchar(50) not null,

WarehouseType nvarchar(20) not null,

HUB_Warehouse_HSK char(32) not null,

SAT_Warehouse_LDTS datetime not null,

SAT_Warehouse_RSRC nvarchar(50),

SAT_Warehouse_HDIFF char(32),

PRIMARY KEY (HUB_Warehouse_HSK, SAT_Warehouse_LDTS),

FOREIGN KEY (HUB_Warehouse_HSK) REFERENCEs HUB_Warehouse (HUB_Warehouse_HSK)

);

create table SAT_Customer (

CustomerCode numeric(18) not null,

CustomerName nvarchar(50) not null,

Address nvarchar(100) not null,

Email nvarchar(50) not null,

HUB_Customer_HSK char(32) not null,

SAT_Customer_LDTS datetime not null,

SAT_Customer_RSRC nvarchar(50),

SAT_Customer_HDIFF char(32),

PRIMARY KEY (HUB_Customer_HSK, SAT_Customer_LDTS),

FOREIGN KEY (HUB_Customer_HSK) REFERENCEs HUB_Customer (HUB_Customer_HSK)

);

create table SAT_CustomerOrder (

CustomerOrderNumber numeric(18) not null,

OrderDate date not null,

HUB_CustomerOrder_HSK char(32) not null,

SAT_CustomerOrder_LDTS datetime not null,

SAT_CustomerOrder_RSRC nvarchar(50),

SAT_CustomerOrder_HDIFF char(32),

PRIMARY KEY (HUB_CustomerOrder_HSK, SAT_CustomerOrder_LDTS),

FOREIGN KEY (HUB_CustomerOrder_HSK) REFERENCEs HUB_CustomerOrder (HUB_CustomerOrder_HSK)

);

create table SAT_SupplierOrder (

SupplierOrderNumber numeric(18) not null,

OrderDate date not null,

HUB_SupplierOrder_HSK char(32) not null,

SAT_SupplierOrder_LDTS datetime not null,

SAT_SupplierOrder_RSRC nvarchar(50),

SAT_SupplierOrder_HDIFF char(32),

PRIMARY KEY (HUB_SupplierOrder_HSK, SAT_SupplierOrder_LDTS),

FOREIGN KEY (HUB_SupplierOrder_HSK) REFERENCEs HUB_SupplierOrder (HUB_SupplierOrder_HSK)

);

create table SAT_Sales (

SalesDocNumber numeric(18) not null,

DocumentDate date not null,

HUB_Sales_HSK char(32) not null,

SAT_Sales_LDTS datetime not null,

SAT_Sales_RSRC nvarchar(50),

SAT_Sales_HDIFF char(32),

PRIMARY KEY (HUB_Sales_HSK, SAT_Sales_LDTS),

FOREIGN KEY (HUB_Sales_HSK) REFERENCEs HUB_Sales (HUB_Sales_HSK)

);

create table SAT_Sales_Details (

Quantity numeric(18) not null,

Price real not null,

Summ real not null,

LNK_Sales_Details_HSK char(32) not null,

SAT_Sales_Details_LDTS datetime not null,

SAT_Sales_Details_RSRC nvarchar(50),

SAT_Sales_Details_HDIFF char(32),

PRIMARY KEY (LNK_Sales_Details_HSK, SAT_Sales_Details_LDTS),

FOREIGN KEY (LNK_Sales_Details_HSK) REFERENCEs LNK_Sales_Details (LNK_Sales_Details_HSK)

);

create table SAT_CustomerOrder_Details (

Quantity numeric(18) not null,

Price real not null,

Summ real not null,

LNK_CustomerOrder_Details_HSK char(32) not null,

SAT_CustomerOrder_Details_LDTS datetime not null,

SAT_CustomerOrder_Details_RSRC nvarchar(50),

SAT_CustomerOrder_Details_HDIFF char(32),

PRIMARY KEY (LNK_CustomerOrder_Details_HSK, SAT_CustomerOrder_Details_LDTS),

FOREIGN KEY (LNK_CustomerOrder_Details_HSK) REFERENCEs LNK_CustomerOrder_Details (LNK_CustomerOrder_Details_HSK)

);

create table SAT_SupplierOrder_Details (

Quantity numeric(18) not null,

Price real not null,

Summ real not null,

LNK_SupplierOrder_Details_HSK char(32) not null,

SAT_SupplierOrder_Details_LDTS datetime not null,

SAT_SupplierOrder_Details_RSRC nvarchar(50),

SAT_SupplierOrder_Details_HDIFF char(32),

PRIMARY KEY (LNK_SupplierOrder_Details_HSK, SAT_SupplierOrder_Details_LDTS),

FOREIGN KEY (LNK_SupplierOrder_Details_HSK) REFERENCEs LNK_SupplierOrder_Details (LNK_SupplierOrder_Details_HSK)

);

Приложение 3

SQL-скрипт создания представлений

USE DWH_DataVault go

CREATE VIEW dimCompany AS SELECT hc.HUB_Company_HSK AS CompanyHSK,sc.CompanyCode,sc.CompanyName,sc.Address,hc.comp_ID AS CompanyID

FROM HUB_Company hc, SAT_Company sc

WHERE hc.HUB_Company_HSK=sc.HUB_Company_HSK AND sc.SAT_Company_LDTS = (SELECT

MAX(sc2.SAT_Company_LDTS) FROM SAT_Company sc2 WHERE sc.HUB_Company_HSK=sc2.HUB_Company_HSK);

CREATE VIEW dimProduct AS SELECT hp.HUB_Product_HSK AS ProductHSK, lpp.HUB_ProductLine_HSK AS ProductLineHSK, sp.ProductName, sp.VendorCode,

sp.Producer, sp.Price, hp.prod_ID AS ProductID, hpl.prodLine_ID AS ProductLineID

FROM HUB_Product hp, SAT_Product sp, LNK_Product_PLine lpp, HUB_ProductLine hpl

WHERE hpl.HUB_ProductLine_HSK=lpp.HUB_ProductLine_HSK AND hp.HUB_Product_HSK=sp.HUB_Product_HSK AND lpp.HUB_Product_HSK=hp.HUB_Product_HSK AND sp.SAT_Product_LDTS = (SELECT

MAX(sp2.SAT_Product_LDTS) FROM SAT_Product sp2 WHERE sp.HUB_Product_HSK=sp2.HUB_Product_HSK) AND lpp.LNK_Product_PLine_LDTS = (SELECT

MAX(lpp2.LNK_Product_PLine_LDTS) FROM LNK_Product_PLine lpp2 WHERE lpp.HUB_Product_HSK=lpp2.HUB_Product_HSK);

CREATE VIEW dimCustomer AS SELECT hc.HUB_Customer_HSK AS CustomerHSK, sc.CustomerCode,sc.CustomerName,sc.Address,sc.Email,hc.cust_ID AS CustomerID

FROM HUB_Customer hc, SAT_Customer sc

WHERE hc.HUB_Customer_HSK=sc.HUB_Customer_HSK AND sc.SAT_Customer_LDTS = (SELECT

MAX (sc2.SAT_Customer_LDTS) FROM SAT_Customer sc2 WHERE sc.HUB_Customer_HSK=sc2.HUB_Customer_HSK);

CREATE VIEW dimProductCategory AS SELECT hpc.HUB_ProductCategory_HSK as ProductCategoryHSK,spc.ProductCategoryName,hpc.prodCat_ID as ProductCategoryID

FROM HUB_ProductCategory hpc,SAT_ProductCategory spc

WHERE hpc.HUB_ProductCategory_HSK=spc.HUB_ProductCategory_HSK AND spc.SAT_ProductCategory_LDTS = (SELECT

MAX (spc2.SAT_ProductCategory_LDTS) FROM SAT_ProductCategory spc2 WHERE spc.HUB_ProductCategory_HSK=spc2.HUB_ProductCategory_HSK);

CREATE VIEW dimProductLine AS SELECT hpl.HUB_ProductLine_HSK AS ProductLineHSK, lpp.HUB_ProductCategory_HSK AS ProductCategoryHSK, spl.ProductLineName,

hpl.prodLine_ID AS ProductLineID, hpc.prodCat_ID AS ProductCategoryID

FROM HUB_ProductLine hpl, SAT_ProductLine spl, LNK_PLine_PCategory lpp, HUB_ProductCategory hpc

WHERE hpc.HUB_ProductCategory_HSK=lpp.HUB_ProductCategory_HSK AND hpl.HUB_ProductLine_HSK=spl.HUB_ProductLine_HSK AND hpl.HUB_ProductLine_HSK=lpp.HUB_ProductLine_HSK AND spl.SAT_ProductLine_LDTS = (SELECT

MAX(spl2.SAT_ProductLine_LDTS) FROM SAT_ProductLine spl2 WHERE spl.HUB_ProductLine_HSK=spl2.HUB_ProductLine_HSK) AND lpp.LNK_PLine_PCategory_LDTS = (SELECT

MAX(lpp2.LNK_PLine_PCategory_LDTS) FROM LNK_PLine_PCategory lpp2 WHERE lpp.HUB_ProductLine_HSK=lpp2.HUB_ProductLine_HSK);

CREATE VIEW dimResponsible AS SELECT hr.HUB_Responsible_HSK AS ResponsibleHSK,sr.ResponsibleCode,sr.ResponsibleName,sr.Email,sr.Telephone,hr.resp_ID AS ResponsibleID

FROM HUB_Responsible hr, SAT_Responsible sr

WHERE hr.HUB_Responsible_HSK=sr.HUB_Responsible_HSK AND sr.SAT_Responsible_LDTS = (SELECT

MAX(sr2.SAT_Responsible_LDTS) FROM SAT_Responsible sr2 WHERE sr.HUB_Responsible_HSK=sr2.HUB_Responsible_HSK);

CREATE VIEW dimWarehouse AS SELECT hw.HUB_Warehouse_HSK AS WarehouseHSK,lcw.HUB_Company_HSK AS CompanyHSK,sw.WarehouseCode,sw.WarehouseName,sw.WarehouseType,

hw.wareh_ID AS WarehouseID,hc.comp_ID as CompanyID

FROM HUB_Warehouse hw, LNK_Company_Warehouse lcw, SAT_Warehouse sw, HUB_Company hc

WHERE hc.HUB_Company_HSK=lcw.HUB_Company_HSK AND hw.HUB_Warehouse_HSK=sw.HUB_Warehouse_HSK AND hw.HUB_Warehouse_HSK=lcw.HUB_Warehouse_HSK AND sw.SAT_Warehouse_LDTS = (SELECT

MAX(sw2.SAT_Warehouse_LDTS) FROM SAT_Warehouse sw2 WHERE sw.HUB_Warehouse_HSK=sw2.HUB_Warehouse_HSK) AND lcw.LNK_Company_Warehouse_LDTS = (SELECT

MAX(lcw2.LNK_Company_Warehouse_LDTS) FROM LNK_Company_Warehouse lcw2 WHERE lcw.HUB_Warehouse_HSK=lcw2.HUB_Warehouse_HSK);

CREATE VIEW dimSupplier AS SELECT hs.HUB_Supplier_HSK AS SupplierHSK,ss.SupplierCode,ss.SupplierName,ss.Address,ss.INN,hs.suppl_ID AS SupplierID

FROM HUB_Supplier hs, SAT_Supplier ss

WHERE hs.HUB_Supplier_HSK=ss.HUB_Supplier_HSK AND ss.SAT_Supplier_LDTS = (SELECT

MAX(ss2.SAT_Supplier_LDTS) FROM SAT_Supplier ss2 WHERE ss.HUB_Supplier_HSK=ss2.HUB_Supplier_HSK);

CREATE VIEW dimSalesContract AS SELECT hsc.HUB_SalesContract_HSK AS SalesContractHSK,lcc.HUB_Company_HSK AS CompanyHSK,ssc.ContractNumber,ssc.Date,ssc.FinishDate,

hsc.salesC_ID AS SalesContractID, hc.comp_ID as CompanyID

FROM HUB_SalesContract hsc, LNK_Company_Contract lcc, SAT_SalesContract ssc, HUB_Company hc

WHERE hc.HUB_Company_HSK=lcc.HUB_Company_HSK AND hsc.HUB_SalesContract_HSK=ssc.HUB_SalesContract_HSK AND hsc.HUB_SalesContract_HSK=lcc.HUB_SalesContract_HSK AND ssc.SAT_SalesContract_LDTS = (SELECT

MAX(ssc2.SAT_SalesContract_LDTS) FROM SAT_SalesContract ssc2 WHERE ssc.HUB_SalesContract_HSK=ssc2.HUB_SalesContract_HSK) AND lcc.LNK_Company_Contract_LDTS = (SELECT

MAX(lcc2.LNK_Company_Contract_LDTS) FROM LNK_Company_Contract lcc2 WHERE lcc.HUB_SalesContract_HSK=lcc2.HUB_SalesContract_HSK);

CREATE VIEW dimSupplierContract AS SELECT hsc.HUB_SupplierContract_HSK AS SupplierContractHSK,lsc.HUB_Supplier_HSK AS SupplierHSK,ssc.ContractNumber,ssc.Date,ssc.FinishDate,

hsc.supplC_ID AS SupplierContractID,hs.suppl_ID as SupplierID

FROM HUB_SupplierContract hsc, LNK_Supplier_Contract lsc, SAT_SupplierContract ssc, HUB_Supplier hs

WHERE hs.HUB_Supplier_HSK=lsc.HUB_Supplier_HSK AND hsc.HUB_SupplierContract_HSK=ssc.HUB_SupplierContract_HSK AND hsc.HUB_SupplierContract_HSK=lsc.HUB_SupplierContract_HSK AND ssc.SAT_SupplierContract_LDTS = (SELECT

MAX(ssc2.SAT_SupplierContract_LDTS) FROM SAT_SupplierContract ssc2 WHERE ssc.HUB_SupplierContract_HSK=ssc2.HUB_SupplierContract_HSK) AND lsc.LNK_Supplier_Contract_LDTS = (SELECT

MAX(lsc2.LNK_Supplier_Contract_LDTS) FROM LNK_Supplier_Contract lsc2 WHERE lsc.HUB_SupplierContract_HSK=lsc2.HUB_SupplierContract_HSK);

CREATE VIEW factSales AS SELECT hs.HUB_Sales_HSK AS SalesHSK, lsd.LNK_Sales_Details_HSK AS SalesDetailsHSK,ls.HUB_Company_HSK AS CompanyHSK,

ls.HUB_Customer_HSK AS CustomerHSK,ls.HUB_Warehouse_HSK as WarehouseHSK,ls.HUB_SalesContract_HSK as SalesContractHSK,

ls.HUB_Responsible_HSK AS ResponsibleHSK,lsd.HUB_Product_HSK AS ProductHSK,ss.DocumentDate,ssd.Quantity,ssd.Price,ssd.Summ,hs.sales_ID AS SalesID,

lsd.salesDID AS SalesDetailsID,hp.prod_ID AS ProductID

FROM HUB_Sales hs, LNK_Sales_Details lsd, SAT_Sales ss, SAT_Sales_Details ssd, LNK_Sales ls, HUB_Product hp

WHERE hp.HUB_Product_HSK=lsd.HUB_Product_HSK AND hs.HUB_Sales_HSK=ss.HUB_Sales_HSK AND hs.HUB_Sales_HSK=lsd.HUB_Sales_HSK AND ssd.LNK_Sales_Details_HSK=lsd.LNK_Sales_Details_HSK AND

ls.HUB_Sales_HSK=hs.HUB_Sales_HSK AND ss.SAT_Sales_LDTS = (SELECT MAX(ss2.SAT_Sales_LDTS) FROM SAT_Sales ss2 WHERE ss.HUB_Sales_HSK=ss2.HUB_Sales_HSK) AND

ssd.SAT_Sales_Details_LDTS = (SELECT MAX(ssd2.SAT_Sales_Details_LDTS) FROM SAT_Sales_Details ssd2 WHERE ssd.LNK_Sales_Details_HSK=ssd2.LNK_Sales_Details_HSK) AND

ls.LNK_Sales_LDTS = (SELECT MAX(ls2.LNK_Sales_LDTS) FROM LNK_Sales ls2 WHERE ls.HUB_Sales_HSK=ls2.HUB_Sales_HSK) AND

lsd.LNK_Sales_Details_LDTS = (SELECT MAX(lsd2.LNK_Sales_Details_LDTS) FROM LNK_Sales_Details lsd2 WHERE lsd.LNK_Sales_Details_HSK = lsd2.LNK_Sales_Details_HSK);

CREATE VIEW factCustomerOrder AS SELECT hco.HUB_CustomerOrder_HSK AS CustomerOrderHSK, lcod.LNK_CustomerOrder_Details_HSK as CustomerOrderDetailsHSK, lco.HUB_Company_HSK AS CompanyHSK,

lco.HUB_Customer_HSK AS CustomerHSK, lco.HUB_Warehouse_HSK as WarehouseHSK, lco.HUB_SalesContract_HSK AS SalesContractHSK, lco.HUB_Responsible_HSK AS ResponsibleHSK,

lcod.HUB_Product_HSK as ProductHSK, sco.OrderDate, scod.Quantity, scod.Price, scod.Summ,

hco.custOrd_ID as CustomerOrderID, lcod.custODID as CustomerOrderDetailsID, hp.prod_ID as ProductID

FROM HUB_CustomerOrder hco, LNK_CustomerOrder lco, LNK_CustomerOrder_Details lcod, SAT_CustomerOrder sco, SAT_CustomerOrder_Details scod, HUB_Product hp

WHERE hp.HUB_Product_HSK=lcod.HUB_Product_HSK AND hco.HUB_CustomerOrder_HSK=sco.HUB_CustomerOrder_HSK AND hco.HUB_CustomerOrder_HSK=lco.HUB_CustomerOrder_HSK AND

lcod.LNK_CustomerOrder_Details_HSK=scod.LNK_CustomerOrder_Details_HSK AND hco.HUB_CustomerOrder_HSK=lcod.HUB_CustomerOrder_HSK AND

sco.SAT_CustomerOrder_LDTS = (SELECT MAX(sco2.SAT_CustomerOrder_LDTS) FROM SAT_CustomerOrder sco2 WHERE sco.HUB_CustomerOrder_HSK=sco2.HUB_CustomerOrder_HSK) AND

scod.SAT_CustomerOrder_Details_LDTS = (SELECT MAX(scod2.SAT_CustomerOrder_Details_LDTS) FROM SAT_CustomerOrder_Details scod2 WHERE scod.LNK_CustomerOrder_Details_HSK=scod2.LNK_CustomerOrder_Details_HSK) AND

lco.LNK_CustomerOrder_LDTS = (SELECT MAX(lco2.LNK_CustomerOrder_LDTS) FROM LNK_CustomerOrder lco2 WHERE lco.HUB_CustomerOrder_HSK=lco2.HUB_CustomerOrder_HSK) AND

lcod.LNK_CustomerOrder_Details_LDTS = (SELECT MAX(lcod2.LNK_CustomerOrder_Details_LDTS) FROM LNK_CustomerOrder_Details lcod2 WHERE lcod.HUB_CustomerOrder_HSK=lcod2.HUB_CustomerOrder_HSK);

CREATE VIEW factSupplierOrder AS SELECT hso.HUB_SupplierOrder_HSK AS SupplierOrderHSK, lsod.LNK_SupplierOrder_Details_HSK as SupplierOrderDetailsHSK, lso.HUB_Company_HSK AS CompanyHSK,

lso.HUB_Supplier_HSK AS SupplierHSK, lso.HUB_Warehouse_HSK as WarehouseHSK, lso.HUB_SupplierContract_HSK AS SupplierContractHSK, lso.HUB_Responsible_HSK AS ResponsibleHSK,

lsod.HUB_Product_HSK as ProductHSK, sso.OrderDate, ssod.Quantity, ssod.Price, ssod.Summ,

hso.supplOrd_ID as SupplierOrderID, lsod.suppODID as SupplierOrderDetailsID, hp.prod_ID as ProductID

FROM HUB_SupplierOrder hso, LNK_SupplierOrder lso, LNK_SupplierOrder_Details lsod, SAT_SupplierOrder sso, SAT_SupplierOrder_Details ssod, HUB_Product hp

WHERE hp.HUB_Product_HSK=lsod.HUB_Product_HSK AND hso.HUB_SupplierOrder_HSK=sso.HUB_SupplierOrder_HSK AND hso.HUB_SupplierOrder_HSK=lso.HUB_SupplierOrder_HSK AND

lsod.LNK_SupplierOrder_Details_HSK=ssod.LNK_SupplierOrder_Details_HSK AND hso.HUB_SupplierOrder_HSK=lsod.HUB_SupplierOrder_HSK AND

sso.SAT_SupplierOrder_LDTS = (SELECT MAX(sso2.SAT_SupplierOrder_LDTS) FROM SAT_SupplierOrder sso2 WHERE sso.HUB_SupplierOrder_HSK=sso2.HUB_SupplierOrder_HSK) AND

ssod.SAT_SupplierOrder_Details_LDTS = (SELECT MAX(ssod2.SAT_SupplierOrder_Details_LDTS) FROM SAT_SupplierOrder_Details ssod2 WHERE ssod.LNK_SupplierOrder_Details_HSK=ssod2.LNK_SupplierOrder_Details_HSK) AND

lso.LNK_SupplierOrder_LDTS = (SELECT MAX(lso2.LNK_SupplierOrder_LDTS) FROM LNK_SupplierOrder lso2 WHERE lso.HUB_SupplierOrder_HSK=lso2.HUB_SupplierOrder_HSK) AND

lsod.LNK_SupplierOrder_Details_LDTS = (SELECT MAX(lsod2.LNK_SupplierOrder_Details_LDTS) FROM LNK_SupplierOrder_Details lsod2 WHERE lsod.HUB_SupplierOrder_HSK=lsod2.HUB_SupplierOrder_HSK);

CREATE VIEW dimSalesDocs AS SELECT hs.HUB_Sales_HSK AS SalesHSK,

ss.SalesDocNumber,ss.DocumentDate

FROM HUB_Sales hs, SAT_Sales ss

WHERE hs.HUB_Sales_HSK=ss.HUB_Sales_HSK AND

hs.HUB_Sales_HSK=ss.HUB_Sales_HSK AND ss.SAT_Sales_LDTS =

(SELECT MAX(ss2.SAT_Sales_LDTS) FROM SAT_Sales ss2 WHERE ss.HUB_Sales_HSK=ss2.HUB_Sales_HSK);

CREATE VIEW dimCustOrderDocs AS SELECT hc.HUB_CustomerOrder_HSK AS CustomerOrderHSK,

sc.CustomerOrderNumber,sc.OrderDate

FROM HUB_CustomerOrder hc, SAT_CustomerOrder sc

WHERE hc.HUB_CustomerOrder_HSK=sc.HUB_CustomerOrder_HSK AND

hc.HUB_CustomerOrder_HSK=sc.HUB_CustomerOrder_HSK AND sc.SAT_CustomerOrder_LDTS =

(SELECT MAX(sc2.SAT_CustomerOrder_LDTS) FROM SAT_CustomerOrder sc2 WHERE sc.HUB_CustomerOrder_HSK=sc2.HUB_CustomerOrder_HSK);

CREATE VIEW dimSuppOrderDocs AS SELECT hs.HUB_SupplierOrder_HSK AS SupplierOrderHSK,

ss.SupplierOrderNumber,ss.OrderDate

FROM HUB_SupplierOrder hs, SAT_SupplierOrder ss

WHERE hs.HUB_SupplierOrder_HSK=ss.HUB_SupplierOrder_HSK AND

hs.HUB_SupplierOrder_HSK=ss.HUB_SupplierOrder_HSK AND ss.SAT_SupplierOrder_LDTS =

(SELECT MAX(ss2.SAT_SupplierOrder_LDTS) FROM SAT_SupplierOrder ss2 WHERE ss.HUB_SupplierOrder_HSK=ss2.HUB_SupplierOrder_HSK);