Проектирование хранилища данных и инструментов анализа данных, Создание модели хранилища данных - Создание модели хранилища данных
Создание модели хранилища данных
Модель хранилища данных будет создаваться на основе описания предметной области, сделанного во 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:
На этом рисунке завершается этап построения структуры данных хранилища данных. Следующим шагом в работе с хранилищем данных является его наполнение данными, собранными на этапе поиска и моделирования данных. По методологии построения хранилищ данных файлы с собранной информацией являются внешними источниками по отношению к хранилищу данных. Применение инструментария, который обеспечит корректное наполнение хранилища, будет рассмотрено в следующей части.
Похожие статьи
-
Проектирование хранилища данных - Разработка объектов Хранилища
Процесс проектирования любого хранилища, как уже было сказано, делится на следующие составляющие: Выбор бизнеса процесса Выбор таблицы фактов Выбор...
-
Физическая Модель Данных Физическое проектирование -- создание схемы базы данных для конкретной СУБД. Специфика конкретной СУБД может включать в себя...
-
Сравнительный анализ известных инструментов моделирования Основной целью выбора стандарта функционального проектирования является соответствие...
-
Каждая СУБД имеет особенности в представлении структуры таблиц, связей, определении типов данных и т. д. которую необходимо учитывать при проектировании....
-
Введение - Создание модели хранилища данных
Особенностью Российской Федерации является резкое различие уровня развития регионов в зависимости от их территориальной принадлежности. Регионы...
-
Описание предметной области ООО ИСК "Волгастройинвест" является официальным представителем ряда отечественных и зарубежных фирм, предлагающих на...
-
Этапы проектирования и создания БД - Система управления базами данных
При разработке БД можно выделить следующие этапы работы. I этап. Постановка задачи. На этом этапе формируется задание по созданию БД. В нем подробно...
-
Проектирование систем оперативного анализа данных Современные системы поддержки принятия решений и информационные системы руководителей основаны на...
-
Поскольку клиентская часть представляет собой приложение на базе операционной системы Android, то для ее разработки был выбран рекомендуемый...
-
Проектирование модели данных - Создание аналога системной утилиты "Диспетчер задач"
При проектировании модели данных разработаем диаграмму вариантов использования, диаграмму деятельности. Диаграмма вариантов использования представляет...
-
Поиск данных в различных источниках - Создание модели хранилища данных
Коллекционирование данных является основой любого исследования. В данном исследовании необходима информация, в первую очередь, об объемах входящих и...
-
Областью применения базы данных является Гостиница. Задачей администратора гостиницы является отслеживание финансовой стороны работы гостиницы. Его...
-
Описание предметной области Для описания предметной области была использована методология IDEF0. IDEF0 -- (ICAM DEFinition language 0) -- Function...
-
Для разработки базы данных была выбрана СУБД Access так как, она имеет следующие преимущества перед другими СУБД: - Является реляционной; -...
-
Логическая модель данных Логическая модель данных представлена сущностями (таблицами). Таблицы - фундаментальные объекты реляционной базы данных, в...
-
Хранилище данных - Разработка аналитического приложения
Как система управления базами данных (СУБД) был выбран Microsoft SQL Management Studio. Данная СУБД обладает понятным интерфейсом, она проста в...
-
Теоретические предпосылки исследования Системы поддержки принятия решений Системы поддержки принятия решений (СППР), представляют собой приложения узкого...
-
Этапы проектирования базы данных - Автоматизация процесса работы руководства ООО "Сервис партнер"
Основная цель проектирования БД заключается в том, чтобы обеспечить пользователя более точными данными, полностью удовлетворяющими их информационные...
-
Этапы жизненного цикла БД включают: -Планирование БД - определяются принципы, задачи создания БД. -Проектирование БД. -Материализация БД -...
-
Физические модели хранения данных определяют методы размещения данных в памяти компьютера или на соответствующих носителях информации, а также способы...
-
Основная часть, Физические модели таблиц базы данных - Проблема организации и хранения данных
Физические модели таблиц базы данных Физическая модели таблицы базы данных предполагает описание свойств каждого поля таблицы. Для описания свойств полей...
-
Сетевая модель данных, Реляционная модель данных - Система управления базами данных
Отличие сетевой структуры от иерархической заключается в том, что каждый элемент в сетевой структуре может быть связан с любым другим элементом (рис. 8)....
-
2.2 Модель программного агента ресурсов - Средства для создания программных агентов
Программный агент в мультиагентной системе имеет свое описание в виде BDI модели, которая содержит его знания, планы и цели, которые агент выполняет по...
-
2.1 Процесс проектирования БД на основе принципов нормализации представляет собой последовательность переходов от неформального словесного описания...
-
Программная модель данных, получившая название "MapReduce", была создана несколько лет назад в компании Google, и там же была осуществлена первая...
-
Логический уровень описания базы данных (логическая модель) отражает логические связи между таблицами. Логическая модель базы данных "Прокат автомобилей"...
-
Комплекс инструментов Oracle Exalytics Комплексное решение Oracle Exalytics создано для обеспечения высокой производительности аналитических систем и...
-
За последние годы было разработано большое количество методологий и стандартов построения и описания различных уровней архитектуры организации, в том...
-
Основные понятия распределенных баз данных Распределение баз данных - набор логических связанных между собой разделяемых данных (и их описаний), которые...
-
В среде электронного ресурса ИИС "MD_SLAGMELT" (Рис. 6) для доступа к компоненту "моделирование" необходима учетная запись (пара логин/пароль) (Рис.7)....
-
Диаграмма сущность связь Диаграмма "сущность -- связь" (ER -- модель данных), которая обеспечивает способ определения данных и отношений между ними....
-
Формулировка основных задач работы - Создание модели хранилища данных
В данной работе лишь предпринимается попытка проанализировать авиатранспортную отрасль России в разрезе авиатранспортных потоков при помощи изученных...
-
Физическая модель данных При разработке структуры базы данных важным процессом является нормализация. Нормализация - это удаление избыточных данных из...
-
Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF(O), DFD...
-
3.2 Построение модели программного агента - Средства для создания программных агентов
В данной работе для построения программного модуля используется технология Jadex, которая позволяет моделировать BDI агентов с наборами фактов, целей,...
-
Начинать следует с определения структуры таблицы, соответствующей предметной области, т. е. с определения полей, которые надо включить в таблицу, типов...
-
Разработка концептуальной модели базы данных При проектировании программ выясняются запросы и пожелания клиента и определяется возможный подход к решению...
-
Объектно-ориентированное программирование (ООП) является парадигмой программирования, которая представляет понятия, как "объекты", которые имеют поля...
-
Инфологическое моделирование применяется на втором этапе проектирования БД, то есть после системного анализа предметной области. Это построение...
-
Технология создания баз данных в программе Microsoft Access
Введение Базы данных играют особую роль в современном мире. Любой из нас многократно начиная с детства, сталкивался с "базами данных". Это - всевозможные...
Проектирование хранилища данных и инструментов анализа данных, Создание модели хранилища данных - Создание модели хранилища данных