Проектирование хранилища данных и инструментов анализа данных, Создание модели хранилища данных - Создание модели хранилища данных

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

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

Хранилища данных (Data Warehouse) представляют собой специализированные базы данных, предназначенные для хранения данных, которые редко меняются, но на основе которых часто требуется выполнение сложных запросов [2]. Обычно они ориентированы на выполнение аналитических запросов, которые обеспечивают поддержку принятия решений для руководителей и менеджеров. Хранилища данных позволяют разгрузить промышленные базы данных, и тем самым позволяют пользователям более эффективно и быстро извлекать необходимую информацию. Как правило, хранилища данных оперируют с огромными объемами информации, что предъявляет к их проектированию и реализации повышенные требования.

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

    1. Хранилище данных в 3-НФ (третья нормальная форма) [2]. Структура представлена в третьей нормальной форме, что значительно снижает скорость ответа серверов при обработке больших объемов данных. Концепция была предложена американским ученым в сфере ИТ Биллом Инмоном в 1992 году. По утверждению Б. Инмона хранилище данных должно проектироваться с использованием нормализованной модели. К основным недостаткам реляционной модели относятся: (1) сложность для пользователей получить целостную информацию о бизнес объектах, (2) низкая производительность при больших объемах данных. 2. Многомерный (Dimensional) подход, предложенный Ральфом Кимбаллом в 1996 году [1]. Данная методология является самой распространенной на сегодняшний день благодаря своей простоте, понятности для пользователей, производительности. По Кимбаллу хранилище данных представляет собой денормализованную структуру с таблицей фактов и таблицами измерений. Факты содержат в себе меры (например, доход, количество, процент) и суррогатные ключи измерений. Измерения являются контекстной информацией (например, измерение "Клиент", "Магазин") для описания определенного факта. Однако, возможно возникновение трудностей при загрузке данных из внешних источников в хранилище в контексте интеграции данных в таблице фактов и таблицах измерений. 3. Data Vault [22]. Эта методология предполагает наличие трех видов сущностей в хранилище: узел (hub), спутник (satellite) и link (связь). Узлы содержат в себе лишь суррогатные ключи, бизнес ключи и информацию о дате загрузки объекта и об источнике. Все свойства и атрибуты хаба хранятся в спутниках. Связи отражают взаимоотношения бизнес объектов, описанных в хабах; они также могут иметь свои спутники. Примеры хаба: Клиент, Поставщик; примеры спутника: адрес клиента, имя клиента. Примеры связи: заказ, покупка, поставка. Система, спроектированная по этой методологии, характеризуется высокой степенью гибкости и масштабируемостью. Также методология обеспечивает долгосрочное хранение истории о загрузках объектов и об источниках. Авторы методологии утверждают, что Data Vault является чем-то средним между проектированием хранилищ данных в 3 нормальной форме (3NF) и проектированием хранилищ данных в форме "Звезды" (Dimensional). Однако структура Data Vault в некоторых случаях может оказаться чрезмерно сложной для предприятия, а также могут возникать проблемы во время применения аналитических инструментов из-за слишком большого количества таблиц. 4. Entity-Attribute-Value (EAV) или Сущность-Атрибут-Значение [23] это методология, основанная на описании сущностей с большим количеством потенциальных свойств (атрибутов), из которых используется лишь некоторая часть. EAV используется в системах-конструкторах, в которых структуру базу данных определяет конечный пользователь, например в интернет-магазинах. Только в таких случаях есть смысл использовать такую модель данных, характеризующуюся очень высокой гибкостью, масштабируемостью. Но такая модель данных очень сложна в смысле понимания для разработчиков и администраторов баз данных, что зачастую является причиной отказа от этой методологии.

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

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

Первым шагом при моделировании структуры хранилища данных является описание таблиц измерений. Ниже представлены названия таблиц измерений, их поля с типами данных с учетом специфики выбранной СУБД (MS SQL Server 2008).

1. Dim_date -- временное измерение

Поля:

Date_id -- идентификатор экземпляра даты (суррогатный ключ)

Date_date - дата (начало каждого квартала: например, 1.1.2012, 1.4.2012, 1.7.2012, 1.10.2012)

Date_year - год

Date_quater - квартал (делать более глубокую детализацию для решения задачи работы нет смысла. Отчетность идет поквартально)

2. Dim_place -- абстракция "регион"

Поля:

Place_id int primary key, - идентификатор региона (суррогатный ключ)

Place_fed_distinct varchar(50), - название федерального округа

Place_region varchar(50), - название региона

Place_center varchar(50) -- региональный центр (название города)

3. Dim_direction -- измерение "направление грузового потока"

Поля:

Direction_id int primary key, - идентификатор (суррогатный ключ)

Direction_title varchar(15), - наименование направления (возможные значения: входящий поток, исходящий поток)

Direction_desc varchar(100) -- описание (определение)

4. Dim_transportation_type -- измерение "тип авиаперевозки"

Поля:

Tr_type_id int primary key, - идентификатор (суррогатный ключ)

Tr_type_title varchar(30), - наименование типа (возможные значения: пассажиры, груз, почта), (В системе будут фигурировать факты только со значением данного измерения "груз")

Tr_units varchar(20) -- единицы измерения

5. Dim_company -- измерение "Авиакомпании"

Поля:

Company_id int primary key, - идентификатор (суррогатный ключ)

Company_title_rus varchar(50), - наименование компании на русском (Как было отмечено в главе, посвященной описанию предметной области, система не предусматривает рассмотрение авиаперевозок в разрезе компаний. Все авиационные потоки будут относиться к модельному экземпляру авиакомпании с атрибутами (1, компания_модель, company_model, company-model-site. com). Данное измерение введено для потенциального совершенствования системы в будущем)

Company_title_eng varchar(50), - наименование компании на английском

Company_web_site varchar(50) -- веб-сайт компании

После описания всех таблиц измерений следует описать таблицу фактов:

FactTransportation -- факт авиаперевозки

Поля:

Trans_id int primary key, - идентификатор факта (суррогатный ключ)

Date_id int - внешний (суррогатный) ключ к измерению dim_date

Place_id int - внешний (суррогатный) ключ к измерению dim_place

Direction_id int - внешний (суррогатный) ключ к измерению dim_direction

Tr_type_id int - внешний (суррогатный) ключ к измерению dim_transportation_type

Company_id int - внешний (суррогатный) ключ к измерению dim_company

Value real -- объем перевозки (например, 1000 пассажиров или 3,4 тонны грузов)

По методологии Кимбалла таблицы измерений связываются только с таблицей фактов через суррогатные ключи с использованием связи "Один-ко-Многим". После описания таблицы фактов и таблиц измерений было написано SQL описание для генерации таблиц и связей между ними. Это описание представлено в приложении 1.

В результате выполнения данного SQL-описания была получена следующая структура в форме "Звезда" (star-schema). Эта схема представлена на иллюстрации 4:

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

Похожие статьи




Проектирование хранилища данных и инструментов анализа данных, Создание модели хранилища данных - Создание модели хранилища данных

Предыдущая | Следующая