Приступаем к разработке ХД. Учебный пример.

• Тема: Сбор требований к хранилищу данных.
• Задачи:
  • Анализ деятельности компании;
  • Описание бизнес-процессов;
  • Формулировка требований к хранилищу данных;
  • Сбор данных из источников

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

Мы будем строить ХД на примере решения задачи анализа продаж некоторой гипотетической Компании.

Простая модель процесса разработки хранилища данных

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

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

Диаграмма жизненного цикла процесса является отправной точкой такой модели.

Что должен обязательно делать проектировщик хранилища данных.

Уметь собрать требования к ХД совместно с бизнес - аналитиком.

Уметь анализировать требования, возможно с бизнес - аналитиком.

Уметь проверять требования.

Создать эскиз многомерной модели на основе собранных требований.

Определение проекта создания ХД: Оценка ситуации в целом

• ХД заказывает организация - Компания, которая занимается производством и продажей телефонов.
• Компания создана недавно, около 10 лет назад. Сначала около 7 лет она занималась только производством телефонов, сбыт был организован через дистрибьютерскую сеть.
• Спрос на телефоны вырос, и Компания создала свою собственную сеть магазинов для продажи телефонов.
• Вывод: Бизнес - направления: производство и сбыт.
• История данных 7-10 лет.

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

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

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

Определение проекта создания ХД: Оценка ситуации в целом

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

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

Определение проекта создания ХД: Выводы

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

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

Определение проекта создания ХД

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

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

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

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

Теперь проектировщих ХД может приступить к решению задачи – сбор требований к хранилищу данных.

Сбор требований: направления бизнеса

• Допустим, что следующие важные направления деятельности Компании должны найти отражения в ХД:
  1. Жизненный цикл производства;
  2. Структура продаж;
  3. Структура организации;
  4. Определение затрат и прибыли;
  5. Что хочет делать потенциальный пользователь в ХД.

Для реализации проекта создается команда, которая включает специалистов предметной области и ИТ службы. Допустим, что эта команда определила следующие важные направления деятельности Компании, которые должны найти отражения в ХД:

Жизненный цикл производства

Структура продаж

Структура организации

Определение затрат и прибыли

Что хочет делать потенциальный пользователь в ХД.

Общая схема работы по сбору требований

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

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

Вернемся к нашему примеру о разработке ХД Компании.

Сбор требований: Вопросы

• Методы получения бизнес – требований могут быть разбиты на две категории:
  1. Управляемые пользователем. Основывается на определении требований исходя из функций, выполняемых пользователями.
  2. Управляемые источниками данных. Основывается на определении требования посредством использования имеющихся данных в оперативных системах.

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

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

Мы в нашем пример остановимся на использовании первого метода.

Сбор требований: Жизненный цикл производства

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

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

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

Пусть, Компания производит 200 моделей. Политика компании строится таким образом, что число выпускаемых моделей остается постоянным. Это означает, что количество новых моделей приблизительно равно количество моделей, снятых с производства.

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

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

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

Каждый завод управляет запасом продукции данной модели. Когда остаток (quantity on hand) продукции данной модели становится меньше определенного уровня, заказ на работу создается для производства продукции данной модели. После того, как продукция данной модели будет произведена, она остается на заводе до тех пор, она не будет затребована отделом сбыта (sales outlet). Отдел сбыта дает показатель продаваемости модели.

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

Данные о продукции удаляются в тот момент, когда удаляются данные о последней модели этой продукции.