Построение хранилища данных

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

Построение хранилища данных

Оглавление

Введение

Глава 1. Теоретические предпосылки исследования

1.1 Методологические предпосылки исследования

1.2 Актуальность работы и элементы практической значимости

1.3 Предмет, объект, цель и задачи исследования

Глава 2. Методы и инструментальные средства поставленных задач

2.1 Обзор подходов к построению хранилищ данных

2.2 Процесс проектирования моделей хранилищ данных

2.3 Обзор методик моделирования хранилищ данных

2.4 Описание моделей данных

2.5 Выбор подхода к построению хранилища данных и методик моделирования

2.6 Выбор программного обеспечения для моделирования данных

2.7 Анализ предметной области и источников данных

Глава 3. Практическая реализация модели хранилища данных

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

3.2 Проектирование модели витрины данных мониторинга и анализа макроэкономических показателей

3.3 Применение моделей для построения хранилища данных

Заключение

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

Приложение 1. DDL-скрипт для построения хранилища данных

Приложение 2. DDL-скрипт для построения витрины данных для макроанализа



Введение

Исследование посвящено проектированию модели хранилища данных для анализа макроэкономических данных Российской Федерации по отраслям и регионам Российской Федерации.

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

Хранилище данных обеспечивает "единую версию правды", объединяя макроэкномические данные из разных источников как на федеральном уровне, так и на уровне регионов Российской Федерации и ее отраслей, необходимые для разностороннего анализа экономической ситуации. Хранилище является точкой входа для различных интеллектуальных систем, с помощью которых прогнозируются показатели, например, используя методы Data Mining. BI-платформы также используют хранилище данных в качестве источника для визуализации данных в различных представлениях, что упрощает анализ показателей в части выявления зависимостей и трендов, сравнений показателей по отраслям и регионам.

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

Согласно своду знаний по бизнес-анализу, моделирование данных является неотъемлемой частью процесса сбора и анализа требований на проектах по разработке хранилищ данных[1]. Именно разработке модели хранилища данных для макроэкономического анализа экономики Российской Федерации посвящена данная работа.

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

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

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



Глава 1. Теоретические предпосылки исследования

1.1 Методологические предпосылки исследования

Исследование посвящено процессу моделирования хранилища данных. Свод знаний по бизнес-анализу, или Business Analysis Body of Knowledge (BABOK) определяет модель как любое упрощенное представление сложной действительности, полезное для понимания этой действительности и для принятия решений относительно нее. Модель может иметь текстовый, графический смешанный вид (комбинация текстового и графического). К графическим моделям часто относят и диаграммы [1].

Концепция хранилищ данных была предложена еще в 90-х годах Биллом Инмоном. В своей книге "Building the Data Warehouse" он сформулировал отличительные черты хранилищ данных[2]:

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

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

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

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

На основании данных отличительных черт, Инмон сформировал определение хранилища данных. Согласно его определению, хранилище данных - это предметно-ориентированная, интегрированная, неизменяемая и поддерживающая хронологию электронная коллекция данных для обеспечения процесса принятия решений. [2]. Архитектуру хранилища данных можно представить в виде нескольких областей, представленных на рисунке 1:

Рисунок 1. Архитектура хранилища данных

Область стейджинга используется как временное хранилище, которое содержит копию информации из систем-источников, которая необходима перед началом интеграции. Различные схемы ведения бизнеса, регламенты работы систем, ограничения пропускной способности сетей не позволяют одномоментно выгружать данные из источников. Однако не все хранилище данных требуют использования данной области, так как возможно использовать ETL для загрузки данных в хранилище непосредственно из систем источников. В данной работе область стейджинга С англ. языка - Staging Area не используется в проектируемом хранилище данных, так как источниками данных являются Excel-файлы, информацию из которых можно загрузить напрямую в хранилище. макроэкономический российский хранилище данный

Область очистки данных является интерфейсом хранилища данных к системам источникам, отвечающий за извлечение преобразование и загрузку данных в хранилище. Данная область обычно представлена каким-либо ETL-инструментом. После процедур очистки и трансформации данные попадают в область детальных данных, которая является ядром всего хранилища. В нем хранятся данные из всех источников с определённой историчностью. Ядро хранилища является источником для последующих витрин данных. Витрины данных разрабатываются для нужд конкретного подразделения организации. Данные витрин в последствии используется пользователями с помощью SQL-запросов или BI-платформами для построения отчетности.

Впервые понятие модели данных встречается в работе Э.Кодда, однако Кодд не дает в своей работе какого-либо определения. В течение времени с развитием технологий баз данных появлялось все более осмысленное понятие модели данных. Изначально данное понятие употреблялось как синоним структуры данных в конкретной базе данных[3].

В проектировании моделей данных применяется метод семантического моделирования, который представляет собой моделирование структуры данных, опираясь на их смысл. В качестве инструмента семантического моделирования используется диаграмма "сущность-связь". Впервые вариант модели "сущность-связь" был предложен Питером Ченом в 1976 г.[4]. В дальнейшим другими авторами были разработаны другие вариант моделей "сущность-связь": нотация Мартина, нотация Баркера, нотация IDEF1X и другие. Все подобные диаграммы используют графическое отображение сущностей предметной области и их свойств (атрибутов), а также взаимосвязей между ними. Для моделирования витрин данных используется метод многомерного моделирования, предложенный Ральфом Кимбаллом. Его суть заключается в представлении данных в виде схемы "звезда" или "снежинка". В ходе проектирования хранилища данных зачастую строятся три модели: концептуальная модель, логическая модель и физическая модель. Подробное описание методик проектирования и моделей представлено в главе 2.

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

В макроэкномике существуют два вида экономического анализа: анализ ex post и анализ ex ante. Макроэкономический анализ ex post или национальное счетоводство, т.е. анализ статистических данных, что позволяет оценивать результаты экономической деятельности, выявлять проблемы и негативные явления, разрабатывать экономическую политику по их решению и преодолению, проводить сравнительный анализ экономических потенциалов разных стран. Макроэкономический анализ ex ante, т.е. прогнозное моделирование экономических процессов и явлений на основе определенных теоретических концепций, что позволяет определить закономерности развития экономических процессов и выявить причинно-следственные связи между экономическими явлениями и переменными[5].

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

1.2 Актуальность работы и элементы практической значимости

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

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

1.3 Предмет, объект, цель и задачи исследования

Объект исследования - процесс проектирования хранилища данных для анализа макроэкономических данных по отраслям и регионам Российской Федерации.

Предмет исследования - модель хранилища данных для выполнения макроэкономического анализа основных экономических показателей Российской Федерации.

Цель данной работы - проектирование модели хранилища данных для анализа макроэкономических данных по отраслям и регионам Российской Федерации.

Для достижения данной цели необходимо сформировать задачи работы:

1. Рассмотреть теоретические аспекты и методы проектирования моделей хранилища данных;

2. Проанализировать предметную область и источники данных;

3. Построить концептуальную, логическую и физическую модели данных;

4. Применить спроектированные модели для построения хранилища данных.

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

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



Глава 2. Методы и инструментальные средства поставленных задач

2.1 Обзор подходов к построению хранилищ данных

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

1. Подход "сверху вниз";

2. Подход "снизу-вверх";

3. Гибридный подход.

Подход "сверху вниз" предполагает разработку хранилища данных целиком и только потом происходит выбор среза предметной области для проектирования. После этого строятся следующие слои хранилища данных, необходимые для завершения его построения, например, витрины данных[6]. Зачастую данный подход предусматривает построение области стейджинга для сбора и хранения данных из источников в неизменном виде для последующей трансформации, очистки и загрузки в хранилище данных. Отдельная область загрузки может быть полезна при большом количестве систем-источников, больших объемах данных и коротких временных промежутках для извлечения данных из мастер-систем[7].

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

Основным сторонником подхода "сверху вниз" является Бил Инмон. В 1991 году он предложил методологию "нормализованное хранилище данных". Инмон утверждал, что хранилище данных должно основываться на нормализованной модели данных (3NF) и включать в себя сущности с атрибутами, отражающие суть деятельности организации.

Подход "снизу-вверх" начинается с проектирования витрин данных функциональных подразделений организации без предварительной разработки ИТ-инфраструктуры организации. Основной целью подхода "снизу-вверх" является разработка таких витрин как можно быстрее. Используется многомерные модели данных "звезда" или "снежинка" для удобства использования хранилища и оптимизации производительности запросов. При данном подходе каждая следующая витрина данных используется предыдущие измерения и факты[7].

Основным преимуществом данного подхода является гибкая структура данных, основанная на моделях "звезда" (star scheme) или "снежинка" (snowflake scheme). Кроме того, данный поход является более простым для реализации и требуется гораздо меньших временных затрат по сравнению с подходом "сверху-вниз". Однако, у данного подхода есть некоторые недостатки: данные могут дублироваться и быть несогласованными в разных витринах данных.

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

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

Примером гибридного подхода может являться методология "Data Vault", предложенная в 2001 году Дэном Линстедтом. Data Vault - набор уникально связанных нормализованных таблиц, содержащих детальные данные, отслеживающих историю изменений и предназначенных для поддержки одной или нескольких функциональных областей бизнеса. Это - гибридный подход, обобщающий лучшие свойства третьей нормальной формы (3NF) и схемы Звезда (Star schema). Дизайн Data Vault - гибок, масштабируем, последователен и приспосабливаем к потребностям предприятия. Это - модель данных, спроектированная специально для удовлетворения потребностей хранилищ данных предприятиях[9].

Выбор методологий построения хранилища данных для анализа макроэкономических данных по отраслям и регионам РФ в рамках данного исследования представлен в разделе 2.5.

2.2 Процесс проектирования моделей хранилищ данных

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

Рисунок 2. Процесс проектирования модели хранилища данных

Можно выделить следующие этапы:

1. Анализ предметной области, выделение объектов, необходимых включить в хранилище, и их словесное описание;

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

3. Концептуальная модель хранилища данных служит для отображения предметной области и описания главных сущностей;

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

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

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

Данное описание должно корректно определять все взаимосвязи между объектами предметной области.

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

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

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

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

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

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

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

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

2.3 Обзор методик моделирования хранилищ данных

На данный момент для проектирования хранилища данных применяются следующие методики:

1. ER-моделирование (моделирование "сущность-связь");

2. Многомерное моделирование;

3. Моделирование темпоральных данных;

Рассмотрим подробно каждый из представленных выше методов.

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

Сущность - реальный или воображаемый объект, имеющий существенное значение для рассматриваемой предметной области[10].

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

Рисунок 3. Пример графического изображения сущности в ПО ERWin

Каждая сущность должна обладать некоторыми свойствами:

· иметь уникальное имя;

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

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

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

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

Рисунок 4. Графическое изображение атрибутов сущности в ПО ERWin

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

Каждая связь может иметь один из следующих типов связи:

1. Один-к-одному;

2. Один-ко-многим;

3. Многие-ко-многим.

Для обеспечения связи между сущностями используются понятия ключей:

· первичный ключ:

· альтернативный ключ;

· внешний ключ.

Как уже было сказано выше Питер Чен впервые представил методику ER-моделирования в 1976 г, что стало революцией в представлении данных. Это была лишь первая версия и множество людей после него пытались улучшить данную методику, что породило множество различных графических представлений (нотаций) ER-моделей. В настоящее время существуют следующие нотации моделирования "сущность-связь":

1. Изначальная нотация Питера Чена;

2. Нотация Information Engineering;

3. Нотация Ричарда Баркера, используемая в корпорации Oracle;

4. Нотация IDEF1X.

Питер Чен изобрел ER-моделирование в середине 1970 гг. и его подход широко используется и сегодня. Данный подход уникален с точки зрения отображения связей и атрибутов. Например, связи изображаются отдельными фигурами в виде ромба на линии отношения, а атрибуты представлены в виде отдельных кругов вместо текстовых наименований внутри прямоугольника, изображающего сущность [4]. Пример графического изображения нотации П. Чена представлен на следующем рисунке:

Рисунок 5. Пример нотации Питера Чена

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

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

Хотя Чен и был автором первой нотации ER-моделирования, данная техника не могла учитывать всех особенностей, которые и были предложены будущими авторами. Например, она не позволяется описывать характеристики атрибутов и не дает возможности показать отношение зависимости, не жертвуя наименованием связи.

Нотация "Information Engineering" была разработана Кливом Финкерштейном в Австралии в конце 1970-х гг. Над методикой он работал совместно с Джеймсом Мартином, и она была опубликована в 1981 году [11].

Финкерштейн описывал сущность как "данные, которые должны быть сохранены для дальнейшего использования" [12]. Мартин определял сущность как "что-то (реальное или абстрактное), где мы храним данные" [20].

Сущности изображаются в виде прямоугольников с названием сущности внитри. Атрибуты в данной нотации не отображаются, они хранятся в отдельном документе, который называется "списком сущностей". Отношения представлены линиями с определенными символами на концах для отображения кардинальности (мощности связи). Уникальные идентификаторы так же, как и в нотации П. Чена не представлены в нотации "Information Engineering". Пример графического изображения нотации "Information Engineering" представлен на следующем рисунке:

Рисунок 6. Пример графического изображения нотации "Information Engineering"

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

Следующая нотация была разработана Ричардом Баркером в 1990 году [13], которая впоследствии была применена корпорацией Oracle для их метода "CASE*Method" Впоследствии переименован в «Custom Development Method». Сущности в данной нотации изображаются округлыми прямоугольниками с наименованием внутри. В отличие от двух предыдущих нотаций атрибуты могут быть изображены внутри прямоугольников, обозначающих сущности. Атрибуты, входящие в уникальный идентификатор сущности, обозначаются специальным символом (#). Связи представлены линиями, половина которых может быть пунктирной в зависимости от модальности связей. Пример графического изображения данной нотации представлен на следующем рисунке:

Рисунок 7. Графическое изображение нотации Баркера

Последней нотацией ER-моделирования, а также самой современной является нотация IDEF1X. Она была разработана С. Брюсом в 1992 году и используется многими департаментами Федерального Правительства США.

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

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

Рисунок 8. Графическое представление нотации IDEF1X

Многомерное моделирование является методом моделирования и визуализации данных как множества показателей или фактов, которые описывают деятельность организации. Метод многомерного моделирования базируется на следующих основных понятиях[17]:

· Факты;

· Атрибуты;

· Измерения;

· Метрики;

Факт -- это набор связанных элементов данных, содержащих метрики и описательные данные. В ХД факты сохраняются в базовых таблицах реляционной БД.

Атрибут - это описание характеристики реального объекта предметной области. Как правило, атрибут содержит заранее известное значение, характеризующее факт.

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

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

Существуют несколько схем для многомерного моделирования данных:

· схема "звезда";

· схема "снежинка".

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

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

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

Выбор методик моделирования, применяемых для проектирования хранилища данных для анализа макроэкономических данных по отраслям и регионам РФ в рамках данного исследования представлен в разделе 2.5.

2.4 Описание моделей данных

При проектировании хранилища данных зачастую строится три модели: концептуальная, логическая и физическая. Рассмотри каждую из моделей более подробно. Концептуальная модель определяет на высшем уровне отношения между сущностями. Концептуальная модель данных обычно представляет собой диаграмму "сущность-связь". Эта модель не является реляционной. Цель ее создания -- выявление, формализация и анализ потребностей организации в аспекте данных. Модели данного типа не отражают особенностей физической реализации (таких, как структуры хранения данных) или программных ограничений. Концептуальная модель состоит из сущностей, атрибутов и связей. Связи в концептуальной модели могут быть следующих типов: один ко многим и многие ко многим. Концептуальная модель -- это бизнес-модель высокого уровня. Как правило, при проектировании новой системы эта модель предшествует логической модели.

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

· Включает все сущности и отношения между ними;

· Все атрибуты для каждой сущности должны быть определены;

· Для каждой сущности должен быть определен первичный ключ;

· Определяются внешние ключи;

· На данном уровне появляется нормализация.

Пример логической модели представлен на рисунке 3:

Рисунок 9. Пример логической модели данных

Физическая модель данных, как правило, строится после логической. Она применяется для построения схемы базы данных, которая будет использоваться в информационной системе. В физической модели сущности становятся таблицы, а атрибуты -- столбцами таблиц, связи же реализуются в соответствии с используемыми в базе данных механизмами, такими как механизмы обеспечения ссылочной целостности и хранимые процедуры. При создании или генерации физической модели необходимо выбрать конкретную СУБД (например, Oracle 11g, или Microsoft SQL Server). Физическую модель часто используют для создания скрипта на языке описания данных DDL, который позволит автоматически создать или модифицировать базу данных.

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

· Является спецификацией всех таблиц и полей;

· Внешние ключи используются для определения отношений между таблицами;

· Может возникнуть необходимость в денормализации в соответствии с требованиями пользователей;

· Может отличаться от логической модели в связи с ограничениями на физическом уровне;

· Физическая модель будет различна для разных СУБД.

Пример физической модели данных представлен на рисунке 4:

Рисунок 10. Пример физической модели данных.



2.5 Выбор подхода к построению хранилища данных и методик моделирования

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

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

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

2.6 Выбор программного обеспечения для моделирования данных

В ходе исследования необходимо выбрать программное обеспечение (CASE-средство) для проектирования моделей хранилища данных. На данный момент два ведущих на рынке пакета - выпускаемый компанией CA ERwin Data Modeller и PowerDesigner от компании Sybase. Оба продукта позволяют создавать модели данных, воссоздавать модели из баз данных, документировать системы баз данных, формировать простые отчеты, а также создавать и редактировать диаграммы.

Компания CA предлагает следующее описание своего продукта: "CA ERwin Data Modeler -- это средство моделирования данных, позволяющее создавать и поддерживать базы и хранилища данных, а также модели корпоративных информационных ресурсов. Эти модели помогают визуализировать структуры данных, что позволяет эффективно организовывать данные, средства поддержки баз данных и информационные среды, управлять ими и умерять их сложность" [18].

Sybase описывает свой пакет следующим образом: "PowerDesigner обеспечивает уникальное сочетание ряда стандартных методов проектирования (UML, моделирование бизнес-процессов и передовые методы моделирования данных) с современными средами разработки, такими как .NET, Workspace, PowerBuilder, Java и Eclipse, что позволяет ввести средства бизнес-анализа и формализованного проектирования в типовой цикл разработки программного обеспечения. Пакет работает более чем с 60 РСУБД"[19].

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

Проанализировав, интерфейсы и возможности двух пакетов, выбор был сделан в пользу PowerDesginer. Его интерфейс является более дружелюбным для пользователя, и позволяет строить и не только логические и физические модели, как в ERWin Data Modeller, но также и концептуальную. Чтобы смоделировать систему полностью, необходимо объединить ее бизнес-анализ с технической реализацией. Моделирование данных требует использования концептуальных, логических и физических моделей данных.

2.7 Анализ предметной области и источников данных

Предметной областью являются макроэкономические данные Российской Федерации.

Хранилище данных проектируется для анализа макроэкономических данных по отраслям и регионам Российской Федерации. В хранилище данных экономические показатели макроэномики, региональные показатели, отраслевые показатели. Каждый показатель характеризуется следующими параметрами:

* код показателя;

* название на русском языке;

* название на английском языке;

* описание, например, методика расчета того или иного показателя;

* единица измерения.

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

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

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

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

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

Исходя из анализа предметной области можно выделить следующие сущности:

* Экономический показатель - сущность с экономическим показателями, характеризующимися наименование, описанием и единицей измерения;

* Регион - объект с информацией о регионах Российской Федерации;

* Отрасль - сущность с информацией об отраслях Российской Федерации;

* Валюта - объект с наименованием и кодами валют;

* Курс валют - сущность с курсами валют, полученными от Центрального Банка Российской Федерации;

* Источник - объект с информацией об источниках макроэкономических данных;

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

* Значения макроэкономических показателей;

* Прогнозные показатели.

Проанализировав источники данных такие как Росстат (Федеральная служба государственной статистики), Центральный Банк Российской Федерации, Министерства финансов и экономического развития РФ, можно сделать вывод, что значения макроэкномических показателей преимущественно содержится в Excel файлах.

Глава 3. Практическая реализация модели хранилища данных

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

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

3.1.1 Концептуальная модель

Первым этапом после анализа предметной области является проектирование концептуальной модели данных. Концептуальная Сущности были определены на этапе анализа. Определим связи между сущностями. Каждый экземпляр сущности ЗНАЧЕНИЯ МАКРОЭКОНОМИЧЕСКИХ ПОКАЗАТЕЛЕЙ рассчитывается для одного показателя из сущности ЭКОНОМИЧЕСКИЙ ПОКАЗАТЕЛЬ, то есть связь один-к-одному (1:1). Обратная же ситуация каждый ЭКОНОМИЧЕСКИЙ ПОКАЗАТЕЛЬ может быть равен многим значениям из сущности ЗНАЧЕНИЯ МАКРОЭКОНОМИЧЕСКИХ ПОКАЗАТЕЛЕЙ, то есть связь один-ко-многим (1:М).

Каждый экземпляр сущности ЗНАЧЕНИЯ МАКРОЭКОНОМИЧЕСКИХ ПОКАЗАТЕЛЕЙ рассчитывается для одного региона из сущности РЕГИОН, то есть связь один-к-одному (1:1). Такая же связь и между сущностями ЗНАЧЕНИЯ МАКРОЭКОНОМИЧЕСКИХ ПОКАЗАТЕЛЕЙ и ОТРАСЛЬ. Однако, у одного региона или отрасли может быть несколько показателей, то есть связь один-ко-многим (1:М).

Каждый экземпляр сущности ЗНАЧЕНИЯ МАКРОЭКОНОМИЧЕСКИХ ПОКАЗАТЕЛЕЙ может иметь только один источник данных из сущности ИСТОЧНИК, то есть связь один-к-одному (1:1). Обратная же ситуация один ИСТОЧНИК может содержать несколько значений из сущности ЗНАЧЕНИЯ МАКРОЭКОНОМИЧЕСКИХ ПОКАЗАТЕЛЕЙ, то есть связь один-ко-многим (1:М).

Каждое значение прогноза из сущности ПРОГНОЗНЫЕ ЗНАЧЕНИЯ ПОКАЗАТЕЛЕЙ получено с помощью одной модели из сущности МОДЕЛИ, связь данных сущностей один-к-одному (1:1). Обратно, модель может рассчитывать несколько значений прогнозных показателей, то есть связь (1:М). Такая же ситуация со связями между сущностями ПРОГНОЗНЫЕ ЗНАЧЕНИЯ ПОКАЗАТЕЛЕЙ и ЭКОНОМИЧЕСКИЙ ПОКАЗАТЕЛЬ.

Добавим выявленные сущности и связи на ER-диаграмму. Сущности и связи проектируемого хранилища представлены на следующем рисунке:



Рисунок 11. Сущности и связи хранилища данных для макроанализа экономики РФ по отраслям и регионам

Определим атрибуты для сущностей. Сущность ЭКОНОМИЧЕСКИЙ ПОКАЗАТЕЛЬ имеет следующие атрибуты:

- код показателя;

- название на русском языке;

- название на английском языке;

- описание;

- единица измерения.

Атрибуты сущности ЗНАЧЕНИЯ МАКРОЭКОНОМИЧЕСКИХ ПОКАЗАТЕЛЕЙ включают:

- показатель;

- регион;

- отрасль;

- источник;

- период;

- значение показателя.

Сущность РЕГИОН характеризуется следующими атрибутами:

- код региона;

- названием на русском языке;

- название на английском языке;

- федеральный округ;

- широта;

- долгота.

Сущность ОТРАСЛЬ включает атрибуты:

- код отрасли;

- название на русском языке;

- название на английском языке.

Сущность ИСТОЧНИК имеет следующие атрибуты:

- код источника;

- название источника.

Сущность ВАЛЮТА характеризуется атрибутами:

- код валюты;

- код валюты;

- название валюты.

Сущность КУРС ВАЛЮТ включает атрибуты:

- валюта;

- дата;

- курс валюты.

Сущность МОДЕЛЬ имеет атрибуты:

- код модели;

- название модели;

- описание.

Сущность ПРОГНОЗНЫЕ ЗНАЧЕНИЯ ПОКАЗАТЕЛЕЙ характеризуется атрибутами:

- показатель;

- модель, которая получила прогнозное значение;

- прогнозное значение показателя;

- период.

Добавим атрибуты в ER-модель. Результат представлен на следующем рисунке:

Рисунок 12. Концептуальная модель с атрибутами

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

В PowerDesigner есть встроенная функция проверки моделей на соответствие стандартам PowerDesigner - Сheck Model. Данная проверка происходит автоматически при генерации логической модели из концептуальной. Результат ручной проверки концептуальной модели представлен на следующем рисунке:

Рисунок 13. Результат проверки модели встроенным функционалом PowerDesigner

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

Следующим этапом является проектирование логической модели хранилища данных.

2 Логическая модель

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

Рисунок 14. Логическая модель, полученная сразу после генерации

Прежде всего необходимо разделить сущность ЗНАЧЕНИЯ МАКРОЭКОНОМИЧЕСКИХ ПОКАЗАТЕЛЕЙ на три отдельных сущностей: ПОКАЗАТЕЛИ МАКРОЭКНОМИКИ, РЕГИОНАЛЬНЫЕ ПОКАЗАТЕЛИ, ОТРАСЛЕВЫЕ ПОКАЗАТЕЛИ. Это необходимо для того, чтобы избавиться от неполноты данных. Так как для показателей макроэкономики, первичный ключ будет содержать NULL значения для идентификаторов регионов и отраслей. Для региональных показателей не будет заполнен идентификатор отраслей, а для отраслевых - идентификатор регионов.

Так как хранилище содержать историю значений показателей, необходимо применить методику моделирования темпоральных данных. Темпоральными сущностями в проектируемом хранилище являются: ПОКЗАТЕЛИ МАКРОЭКОНОМКИ, ПОКАЗАТЕЛИ РЕГИОНАЛЬНОЙ ЭКОНОМИКИ, ПОКАЗАТЕЛЬ ОТРАСЛЕВОЙ ЭКОНОМИКИ, КУРСЫ ВАЛЮТ. Для первых трех сущностей предлагается использовать подход с добавлением временного интервала для фиксации дата начала и даты окончания какого-либо состояния. В случае с темпоральными сущностями ПОКЗАТЕЛИ МАКРОЭКОНОМКИ, ПОКАЗАТЕЛИ РЕГИОНАЛЬНОЙ ЭКОНОМИКИ, ПОКАЗАТЕЛЬ ОТРАСЛЕВОЙ ЭКОНОМИКИ следует добавить атрибуты "начало периода" и "конец периода" для значения какого-либо показателя. Такой подход позволяет решить проблему различных временных периодов в расчетах экономических показателей. В данном случае атрибут "начало периода" должен входить в состав первичного ключа сущностей. В сущность КУРСЫ ВАЛЮТ следует добавить атрибут "дата", который будет показывать на какую дату определен курс валюты.

Результат изменений модели представлен на следующем рисунке:

Рисунок 15. Логическая модель хранилища данных после всех преобразований

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

...