Модель типового проекта создания хранилища данных

Разработка требований

Этап разработки требований к ХД ( рис. 3.2) включает в себя следующие стадии:

• определение требований владельца ХД;
• определение требований конечных пользователей;
• определение технологических требований;
• определение архитектурных требований.

увеличить изображение
Рис. 3.2. Этап разработки требований к хранилищу данных

Требования владельца связаны с уточнением предметно-ориентированной направленности ХД, требованиями потенциального роста предметной области по:

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

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

• маркетинговые исследования;
• анализ конкурентоспособности;
• анализ поведения покупателя;
• сегментация (рынка) реализации продукта;
• ценовые и бюджетные решения;
• решения по продукции;
• решения по продвижению;
• решения по каналам сбыта;
• прогнозирование тенденций;
• сертификация (Benchmarking).

Анализ выбранных выше направлений имеет дело со спецификацией предметных областей для отдела маркетинга, которыми в данном случае будут являться "Заказы", "Рынки", "Продажи", "Продвижение продукции", "Временные циклы".

Здесь важен такой параметр, как степень детализации (granularity) – чем ниже степень детализации, тем больше количество деталей. Это ключевая информация для проектировщика ХД, поскольку она определяет потенциальный объем ХД, скорость его роста, потенциальную производительность обработки запросов и т.д.

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

• временной цикл с детализацией "День", "Неделя", "Месяц", "Квартал", "Год";
• группы клиентов с детализацией "Покупатели", "Сегмент рынка", "Рынок", "Отрасль промышленности";
• семейство продуктов с детализацией "Продукция", "Семейство продуктов", "Линия продуктов";
• география и месторасположение с детализацией "Район", "Регион страны", "Страна", "Международный регион";
• структура организации с детализацией "Подразделение", "Отдел", "Филиал", "Организация".

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

На стадии определения требований по архитектуре ХД проводится планирование архитектуры в масштабе предприятия и по его структурным подразделениям, определяется архитектура данных в рамках принятой модели (например, ER-модели и т.д.), определяется архитектура приложений ХД, разрабатывается каталог приложений и функции каждого из них. На этой стадии полезно получить CRUD- (Create, Read, Update, Delete — создание, чтение, обновление, удаление) матрицу [44-49], чтобы на стадии проектирования физической структуры оценить частоту использования данных приложениями.

На стадии определения требований разработки создаются:

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

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

Например, классифицируются в операциях над ХД действия пользователей, такие как:

• разделение элементов данных по различным аспектам анализа (операции Slice and dice);
• развертывание и экспозиция элементов данных по уровням иерархии (операции Drill-down up);
• поиск скрытых закономерностей в данных (алгоритмы Data Mining);
• просмотр данных непредусмотренным образом (Datasurfing);
• загрузка и выполнение модификаций данных.

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

• с помощью стандартной визуализации в рамках реляционных СУБД (двумерные таблицы);
• с помощью многомерных кубов данных (OLAP);
• с помощью предусмотренных отчетов и диаграмм;
• на основе жизненных циклов элементов данных.

Главным результатом этого этапа является создание каталога требований.

Анализ

Располагая каталогом требований, можно приступить к реализации этапа анализа —получения согласованных по источникам логической модели и определения набора инструментальных средств для работы с ХД. Стадии этого этапа показаны на рис. 3.3.

Рис. 3.3. Этап анализа

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

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

Проектирование

После завершения стадии анализа переходят к реализации стадии проектирования ( рис. 3.4). Цель этого этапа — разработка физической модели ХД, проектирование процедур поступления данных в него и проектирование архитектуры приложений.

Проектирование ХД можно разложить на две равноценных стадии – проектирование архитектуры данных (логическое и физическое проектирование) и архитектуры приложений (анализ запросов и фиксация процессов взаимодействия хранилища данных с внешними источниками и пользователями).

увеличить изображение
Рис. 3.4. Этап проектирования хранилища данных

Детальное проектирование архитектуры данных включает в себя:

• логическое проектирование. Разработка логических моделей данных для ХД и киосков данных в рабочем пространстве базы данных. Отображение логических моделей данных источников данных в логические модели ХД и киосков данных;
• физическое проектирование. Отображение логических объектов в физическое описание ХД. Денормализация логической модели. Создание табличного пространства, секционирование, создание индексов и ограничений. Оценка объема физического ввода-вывода.

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

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

На стадии физического проектирования рассматриваются задачи размещения данных в БД для эффективной их выборки. На этой стадии (для реляционных хранилищ данных) реально пишутся SQL-операторы. Данные, собранные на стадии логического проектирования, превращаются в описание физической БД, включая таблицы, уникальные идентификаторы объектов – в первичные ключи, ограничения по значениям данных, взаимоотношения между объектами – во внешние ключи, индексы, табличные пространства, разбиения и представления.

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

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

Ограничения в ХД отличаются от ограничений в OLTP-системах. В системах складирования данных целостность и проверка данных обеспечивается на стадии загрузки данных. Поэтому роль ограничений в ХД не столь уж велика. Типичным ограничением в ХД является ограничение NOT NULL.

Параллельно с проектированием архитектуры данных начинается стадия детального проектирования структуры приложений, которая включает в себя определение:

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

Целью этой стадии является получение спецификаций всех приложений ХД.

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

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

Следующий этап проекта создания ХД — это построение ХД ( рис. 3.5).

увеличить изображение
Рис. 3.5. Построение хранилища данных

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

• программы, которые создают и модифицируют БД для ХД и киосков данных;
• программы, которые экстрагируют данные из источников данных;
• программы, которые выполняют преобразования данных, такие как интеграция, суммирование и агрегация;
• программы, которые выполняют обновление реляционных БД;
• программы, которые реализуют поиск в очень больших БД.

Результатом выполнения этого этапа является комплекс программ, работающих с ХД.

Внедрение

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

увеличить изображение
Рис. 3.6. Этап внедрения хранилища данных

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

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

Результатом выполнения этого этапа является всесторонняя подготовка перехода ХД в промышленную эксплуатацию.

Поддержка

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

На этом этапе ИТ-служба организации обеспечивает:

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

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

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

Временные затраты на реализацию этапов

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

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

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

В табл. 3.1 дана также приблизительная оценка временных затрат на каждый этап для типового проекта создания ХД средней сложности.