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

Цель лекции

Изучив материал настоящей лекции, вы будете знать:

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

и научитесь:

• планировать деятельность проектировщика хранилищ данных;
• выполнить предварительное планирование проектирования хранилища данных в рамках конкретного ИТ-проекта.

Литература: [29], [43], [50].

Введение

Зачем проектировщику ХД знать, как организован проект создания ХД? Сложные компьютерные системы, к которым относятся информационные системы с ХД (системы складирования данных, информационно-аналитические системы, BI-системы и системы бизнес-аналитики), создаются командами ИТ-специалистов. Работа команды является процессом, который требует тонкой психологической настройки, мобилизации усилий каждого члена команды для реализации поставленных в проекте целей. Каждый член такой команды должен знать, какова цель проекта, какие задачи решаются в рамках проекта, какие задачи и в какие сроки должен решить каждый член команды. Помимо решения своих непосредственных задач, проектировщик ХД должен четко представлять себе:

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

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

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

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

Жизненный цикл разработки хранилища данных

Для чего создаются хранилища данных

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

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

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

Таким образом, ХД создаются для информационного обеспечения в решении стратегических задач по определенным направлениям бизнеса (для удовлетворения потребностей руководства и бизнес-аналитиков организации), а не для удовлетворения потребностей в автоматизации ежедневных процедур обработки бизнес-информации сотрудников структурных подразделений организации. В этом и состоит главное и коренное отличие систем складирования данных и систем бизнес-аналитики, использующих технологию ХД, от систем оперативной обработки информации (OLTP-систем, или On-Line Trasactions Proccessing).

Факторы, влияющие на структуру проекта создания хранилища данных

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

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

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

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

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

Модель жизненного цикла хранилища данных

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

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

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

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

Процесс создания и разработки ХД (жизненный цикл разработки хранилища данных) в общем случае можно представить состоящим из следующих основных стадий:

• планирование;
• формулирование требований к системе складирования данных;
• анализ;
• проектирование;
• конструирование;
• внедрение;
• поддержка.

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

Охарактеризуем кратко задачи каждого из этих этапов.

Планирование

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

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

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

Выбор стратегии реализации определяет подход, который будет использован при создании ХД. Обычно используют следующие подходы: Top Down ("сверху вниз"), Bottom Up ("снизу вверх"), Middle In ("из середины") и комбинированный подход, который в последнее время становится все более популярным. Подход "сверху вниз" выбирается для вновь создаваемого ХД, т.е. когда "с нуля" принимаются все решения о технологической реализации объекта (аппаратура, программное обеспечение и т.д.). Подход "снизу вверх" используется, когда уже есть определенная вычислительная среда и объекты, из которых можно построить новый объект. Подход "из середины" предполагает эволюционное, поэтапное создание объекта, когда сначала разрабатывается так называемое ядро объекта, которое на следующих этапах наращивается новой функциональностью. Комбинированный подход применяет комбинацию выше перечисленных подходов.

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

Выбор методологии создания ХД определяет, образно говоря, язык проекта, на котором будут разговаривать члены проектной команды, как будет оформлена техническая документация, какие принципы разработки будут использоваться. Это могут быть метод структурного анализа и проектирования (SADT), спиральный метод, методы, основанные на применении UML (язык объектно-ориентированного моделирования), и т.п.

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

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

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

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

Определение предметной (тематической) ориентации ХД является одной из самых главных задач на этом этапе. В рамках каждого фрагмента предметной области определяется:

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

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

Выбор архитектурных решений должен задать такие ограничения:

• степень использования данных систем оперативной обработки;
• только хранилище данных;
• только киоски данных;
• хранилище и киоски данных;
• инфраструктура секционирования данных;
• использование архитектуры клиент-сервер (двухзвенная или трехзвенная архитектура).

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

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

На этом этапе разработчики ХД должны работать в тесном взаимодействии с экспертами и экономистами.

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

Обычно анализ сценариев строится по следующей схеме. Каждый сценарий состоит из:

• четко определенного конечного пользователя с точно определенной его ролью в бизнес-процессах;
• тематической области, которая представляется в хранилище или киоске данных и будет использоваться данным конечным пользователем;
• одного или более вопросов (задач) по ключевым проблемам тематической области, которые воплощены неудовлетворительно в существующих ИС и полезны для решения следующих задач:
  • построение адекватных критериев запросов для ХД;
  • идентификация метамодели ХД;
  • идентификация объема необходимой хронологической информации;
  • идентификация точек зрения пользователя на данные (измерений);
  • идентификация потребностей по данным киосков и ХД.

Цель настоящего этапа — очертить круг вопросов, на которые должна отвечать система складирования данных.

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

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