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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сбор требований: Структура продаж

Существуют два типа отделов сбыта - отдел корпоративных продаж (corporate sales office) и отдел розничной продажи (retail store). Отдел корпоративных продаж продает только оптовым покупателям. Оптовые покупатели определяются по закупочной цене (wholesale price), независимо от предоставленных скидок. Оптовый покупатель определяется 30 продажами. Организация в настоящий момент обслуживает 3000 оптовых покупателей.

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

Отдел корпоративных продаж отправляет документы в пункты приема оптовых покупателей. Если покупатель имеет несколько пунктов приема товара, то отдел корпоративных продаж направляет соответствующие документы в каждый. Отдел корпоративных продаж создает в среднем 500 счетов в день, 5 дней в неделю. Каждый счет включает в среднем 10 моделей продукции.

Сбор требований: Структура продаж

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

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

Слад розничной продажи генерирует в среднем 1000 счетов в день, семь дней в неделю. Каждый счет содержит оплату в среднем двух моделей продукции.

Сбор требований: Структура организации

Сбор требований: Определение доходов и расходов

Потенциальные пользователи системы анализируют показатели расхода и дохода. Для каждой модели продукции стоимость каждого компонента умножается на число компонент, используемых при производстве модели. Стоимость модели определяется как сумма стоимостей всех компонент модели. Для каждой модели установленная цена единицы товара (negotiated unit selling price) умножается на количество продаж. Суммирование результатов по всем позициям заказа (order lines) есть прибыль (revenue) от продажи данной модели.

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

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

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

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

Какова величина среднего остатка продукции на складе и уровень запасов, при котором подается заказ (reorder level) за текущий месяц для каждой модели на каждом заводе.

Какова величина суммарных затрат (total cost) и суммарной прибыли (revenue) по каждой модели, проданной сегодня, и просуммированной по отделу сбыта (outlet), типу отдела сбыта (outlet type), области (region) и по структуре продаж Компании (corporate sales levels)?

Какова величина суммарных затрат (total cost) и суммарной прибыли (revenue) для каждой модели, проданной сегодня, и просуммированной по заводам (manufacturing plant) и по областям (region)?

Какой процент моделей получили скидки, и какие из них были проданы по факту со скидкой (в процентах) по складам (store) для всех продаж (all sales) на этой неделе? В этом месяце?

Для каждой модели, проданной в текущем месяце, какой был процент продаж с розничной торговли, с оптовой торговли по безналичному расчету (order desk), с оптовой торговли через продавцов (salesperson)?

Какие модели и какого типа продукция не продавалась в течение последнего месяца? В течение последней недели?

Какие пять моделей, проданных за последний месяц, принесли наибольшую прибыль (total revenue)? По продажам за квартал (quantity sold)? По суммарным затратам?

Какие отделы сбыта (sales outlets) не имели продаж в течение последнего месяца для каждой модели в каждом из пяти топ-списков?

Какие продавцы не имели ни одной записи о продажах за последний месяц для каждой модели в каждом из трех списков 5 моделей?

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

Сбор данных: Корпоративная ER модель

Корпоративная ER модель OLTP Компании. Бизнес – аналитик и проектировщик ХД должны изучить эту модель для того, чтобы выяснить есть необходимые данные для удовлетворения бизнес – требований пользователей.

Структура записи по товарам

После определения бизнес - требований необходимо найти данные, необходимые для построения ХД, которые эти бизнес – требования удовлетворили.

Бизнес – аналитик изучает ER модель OLTP системы Компании, чтобы найти в ее БД объекты, содержание необходимую информацию.

Структура записи для товаров и моделей может иметь вид, как на слайде.

Структура записи по комплектующим

После определения бизнес - требований необходимо найти данные, необходимые для построения ХД, которые эти бизнес – требования удовлетворили.

Бизнес – аналитик изучает ER модель OLTP системы Компании, чтобы найти в ее БД объекты, содержание необходимую информацию.

Структура записи для товаров и моделей может иметь вид, как на слайде.

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