Хранилища данных. Модель типового проекта создания хранилища данных. Бизнес-модель процесса разработки хранилища данных. Методы и модели организации хранилища данных. Типы хранилищ данных. Хранилища данных и системы бизнес-аналитики. Модели и методы добычи данных.

Индивидуальные онлайн уроки: Отправьте запрос сейчас: ut2018@protonmail.com    
Математика (ЕГЭ, ОГЭ), Английский язык (разговорный, грамматика, TOEFL)
Контрольные работы: по математике, IT, экономике, психологии





Хранилища данных

 

Лекция 5

 

Тема лекции: «Модель типового проекта создания хранилища данных»

1.            Бизнес-модель процесса разработки хранилища данных.

2.            Методы и модели организации хранилища данных.

3.            Типы хранилищ данных.

 

1.            БИЗНЕС-МОДЕЛЬ ПРОЦЕССА РАЗРАБОТКИ ХРАНИЛИЩА ДАННЫХ.

 

В лекции 4 «Архитектура хранилищ данных» была изложена абстрактная модель жизненного цикла разработки ХД – спиральная (итерационная) модель жизненного цикла. Ниже будет рассмотрена типовая модель бизнес-процессов разработки ХД, которая может быть положена в основу реализации такого проекта. Эта модель содержит минимально достаточное число обязательных этапов для реализации небольшого или среднего по масштабу проекта.

 

Проект разработки ХД начинается после того, как выбраны инструменты разработки и сформирована команда проекта.

 

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

 

1)            формулирование требований;

2)            создание вычислительной среды;

3)            моделирование данных;

4)            определение процедур извлечения, преобразования и загрузки данных (процедур ETL-процесса);

5)            проектирование аналитических отчетов;

6)            разработка приложений ХД;

7)            настройка производительности;

8)            проверка качества;

9)            передача системы ХД в эксплуатацию.

 

Опишем каждый типовой этап разработки ХД по следующей схеме.

 

ОПИСАНИЕ ЗАДАЧИ.

 

Что обычно должно быть достигнуто в течение данного этапа разработки ХД.

 

ВРЕМЕННЫЕ ТРЕБОВАНИЯ.

 

Приблизительная оценка количества времени для решения задачи данного этапа.

 

РЕЗУЛЬТАТ ВЫПОЛНЕНИЯ ЭТАПА.

 

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

 

ПОТЕНЦИАЛЬНЫЕ ОПАСНОСТИ.

Рассмотрим подробнее процессы проектного цикла разработки ХД.

 

1)           Формулирование требований.

 

ЗАДАЧА ЭТАПА.

 

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

 

На этом этапе определяются:

 

- масштаб проекта создания ХД (границы предметной области);

 

- перечень и содержание отчетов;

 

- требования по анализу данных (перечень задач анализа данных);

 

- требования к аппаратному обеспечению;

 

- требования к системному программному обеспечению;

 

- значения базовых параметров системы складирования данных (скорость обработки запросов, объемы используемых данных, актуализация данных, производительность системы и т.д.);

 

- требования к квалификации персонала (программа обучения персонала);

перечень источников данных;

 

- конкретизация плана реализации проекта разработки ХД (определяется дата завершения проекта).

 

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

 

ВРЕМЕННЫЕ ТРЕБОВАНИЯ.

 

Время выполнения этапа — от двух недель до двух месяцев.

 

РЕЗУЛЬТАТ ВЫПОЛНЕНИЯ ЭТАПА.

 

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

 

ПОТЕНЦИАЛЬНЫЕ ОПАСНОСТИ.

 

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

 

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

 

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

 

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

 

2)           Создание вычислительной среды для хранилища данных.

 

ЗАДАЧА ЭТАПА.

 

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

 

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

 

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

 

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

 

ВРЕМЕННЫЕ ТРЕБОВАНИЯ.

 

Закупка и установка серверов — до двух недель.

Монтажные работы на установке компьютерной сети — две-четыре недели.

 

РЕЗУЛЬТАТ ВЫПОЛНЕНИЯ ЭТАПА.

 

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

 

ПОТЕНЦИАЛЬНЫЕ ОПАСНОСТИ.

 

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

 

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

 

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

 

3)           Моделирование данных.

 

ЗАДАЧА ЭТАПА.

 

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

 

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

 

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

 

ВРЕМЕННЫЕ ТРЕБОВАНИЯ.

 

Время выполнения этого этапа — от двух недель до двух месяцев.

 

РЕЗУЛЬТАТ ВЫПОЛНЕНИЯ ЭТАПА.

 

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

 

ПОТЕНЦИАЛЬНЫЕ ОПАСНОСТИ.

 

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

 

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

 

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

 

4)           Определение процедур извлечения, преобразования и загрузки данных.

 

ЗАДАЧА ЭТАПА.

 

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

 

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

 

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

 

Напомним, что процесс переноса, включающий в себя этапы извлечения, преобразования и загрузки, называют ETL-процессом (Е — extraction, Т — transformation, L — loading: извлечение, преобразование и загрузка, соответственно).  Программные средства, обеспечивающие его выполнение, называются ETL-системами. Традиционно ETL-системы использовались для переноса информации из устаревших версий информационных систем в новые ИС. В настоящее время ETL-процесс находит все большее применение для  переноса данных из ОИД в ХД и ВД. Более подробно этапы ETL-процесса рассмотрены в лекции 1 «Технологии хранилища данных».

ВРЕМЕННЫЕ ТРЕБОВАНИЯ.

 

Время выполнения этапа — от одной недели до полутора месяцев.

 

РЕЗУЛЬТАТ ВЫПОЛНЕНИЯ ЭТАПА.

 

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

 

ПОТЕНЦИАЛЬНЫЕ ОПАСНОСТИ.

 

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

 

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

 

5)           Проектирование аналитических отчетов.

 

ЗАДАЧА ЭТАПА.

 

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

 

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

 

ВРЕМЕННЫЕ ТРЕБОВАНИЯ.

 

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

 

РЕЗУЛЬТАТ ВЫПОЛНЕНИЯ ЭТАПА.

 

Результатом выполнения этапа станут спецификация кубов данных (измерения и метрики) и разработанные отчеты.

 

ПОТЕНЦИАЛЬНЫЕ ОПАСНОСТИ.

 

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

 

Хороший способ избежать такой опасности — тестирование разработанных отчетов с целью минимизации времени их получения.

 

6)           Разработка приложений хранилища данных.

 

ЗАДАЧА ЭТАПА.

 

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

 

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

 

ВРЕМЕННЫЕ ТРЕБОВАНИЯ.

 

Срок выполнения этого этапа — от одной недели до месяца. При использовании тонкого клиента типа браузера следует исходить из того, что в среднем на разработку и отладку одной Web-страницы тратится полдня.

 

РЕЗУЛЬТАТ ВЫПОЛНЕНИЯ ЭТАПА.

 

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

 

ПОТЕНЦИАЛЬНЫЕ ОПАСНОСТИ.

 

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

 

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

 

7)           Настройка производительности.

 

ЗАДАЧА ЭТАПА.

 

Главная задача выполнения этого этапа — добиться оптимальной производительности ETL-процессов, производства отчетов и их доставки конечному пользователю.

 

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

 

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

 

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

 

ВРЕМЕННЫЕ ТРЕБОВАНИЯ.

 

Время выполнения этого этапа не должно превышать одну-две недели.

 

РЕЗУЛЬТАТ ВЫПОЛНЕНИЯ ЭТАПА.

 

Результатом выполнения этапа является перечень рекомендаций по настройке производительности.

 

ПОТЕНЦИАЛЬНЫЕ ОПАСНОСТИ.

 

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

 

8)           Проверка качества.

 

ЗАДАЧА ЭТАПА.

 

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

 

ВРЕМЕННЫЕ ТРЕБОВАНИЯ.

 

Срок выполнения этого этапа — от одной до четырех недель.

 

РЕЗУЛЬТАТ ВЫПОЛНЕНИЯ ЭТАПА.

 

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

 

ПОТЕНЦИАЛЬНЫЕ ОПАСНОСТИ.

 

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

 

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

 

9)           Передача системы складирования данных в эксплуатацию.

 

ЗАДАЧА ЭТАПА.

 

Главная задача этапа — передача системы складирования данных заказчику и представление ее конечным пользователям.

 

ВРЕМЕННЫЕ ТРЕБОВАНИЯ.

 

Срок выполнения этого этапа — от одного дня до нескольких недель.

РЕЗУЛЬТАТ ВЫПОЛНЕНИЯ ЭТАПА.

 

Результатом выполнения этапа является акт о приемке-сдаче программного продукта.

 

ПОТЕНЦИАЛЬНЫЕ ОПАСНОСТИ.

 

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

 

10)        Сопровождение и модификация хранилища данных.

 

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

 

2.            МЕТОДЫ И МОДЕЛИ ОРГАНИЗАЦИИ ХД.

 

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

 

2.1.        Методы построения хранилищ данных.

 

Существует два основных способа построения ХД предприятия: «сверху-вниз» (top down) и «снизу-вверх» (bottom up).

 

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

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

 

Начать следует с определения типа своей организации.

 

1.            Организации, руководствующиеся принципом «думай глобально, действуй глобально» (Think Globally , Act Globally).

 

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

 

2.            Организации, руководствующиеся принципом «думай глобально, действуй локально» (Think Globally , Act Locally).

 

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

 

3.            Организации, руководствующиеся принципом «думай локально, действуй локально» (Think Locally, Act Locally).

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

 

Из этих критериев необходимо определить рейтинг каждого, основываясь на приоритетах и реалиях. При его определении важно помнить, что «политические» и другие «мягкие» вопросы более критичны для достижения долгосрочного успеха или «поражения», чем любой «тяжелый» технический вопрос, связанный с хранилищем данных или витриной данных.

 

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

 

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

 

1.            Подход «сверху-вниз».

 

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

 

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

 

Если бы ХД создавалось в идеальных, «тепличных»  условиях, то полученное решение было мощной и удачной системой. К сожалению, вне пределов лабораторной среды это невозможно. В реальном мире разработчики ХД оказываются вовлечены в круговорот различных, часто взаимопротиворечащих факторов, «политических» мотивов, не выдерживаемых предельных конечных сроков, устаревших систем данных, неразумных требований пользователей. Несмотря на то, что пока не существует технических причин, по которым следует избегать этого подхода, многие «культурные» или «мягкие» («soft») вопросы оказались исключительно сложными для решения силами среднего IT-отдела.

 

Проблемы разработки хранилища данных предприятия «сверху-вниз».  

 

Основная проблема заключается во «все пересекающей» природе системы EDW. Из самого названия «хранилище данных предприятия», следует, что IT-специалисты должны задействовать все политические, функциональные, ведомственные, юридические, организационные и прочие аспекты в рамках всей организации. Успешное продвижение по этому «минному» полю требует недюжинной «политической» прозорливости, которое не так часто присутствует в группе разработки EDW. Если учесть требование к исключительной гибкости этой команды: ориентированность на пользователя на все 100%, способность к постоянным изменениям и умение бесконечно и беспрерывно перепродавать и заново продвигать систему ХД, то станет понятно, что все эти испытания под силу далеко не всем IT-группам.

 

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

 

Достоинства подхода «сверху-вниз» построения ХД предприятия.

 

Скоординированная среда и единственная точка управления и развития.

 

Недостатки подхода «сверху-вниз» построения ХД предприятия.

 

- «все пересекающая» природа проекта предприятия,

 

- «аналитический паралич»,

 

- управление масштабом,

 

- время до появления на рынке,

 

- риск и подверженность внешнему воздействию.

 

2.            Подход «снизу-вверх».


Этот подход предназначен для реализации огромного потенциала, присущего Хранилищу данных, с одновременным устранением недостатков, свойственных подходу «сверху-вниз».

 

При данном подходе разрабатывается Архитектура витрин данных предприятия (Enterprise Data Mart Architecture , EDMA) для обеспечения контекста работ по развитию. Несмотря на то, что в этом случае рассматривается масштаб всей системы на высоком уровне, подход «снизу-вверх» не так детален, как архитектура системы ХД предприятия, что позволяет избежать «аналитического паралича». По завершении EDMA, выбирается начальная область бизнес-проблем для первой постепенно развиваемой витрины данных. Архитектура витрин данных предприятия расширяется на эту область, чтобы включить полный диапазон деталей, необходимый для проектирования и разработки этого ADM. На последующих этапах происходит заполнение архитектуры витрин данных предприятия, пока отделы и организация не готовы построить ХД предприятия.

 

Благодаря этому подходу отделы могут разрабатывать методы и технологии, необходимые для организации ХД в условиях меньшего риска и меньшей подверженности внешнему воздействию, чем в случае проекта полномасштабного ХД предприятия. Кроме того, ADM разрабатывается быстрее по сравнению с системами EDW. Как правило, первая, постепенно развиваемая витрина данных создается за 6-9 месяцев, а на реализацию первой стадии системы ХД предприятия может уйти год-полтора. Эта скорость выхода на рынок особенно важна, когда нужно показать возврат инвестиций и истинную ценность ХД для организации.

 

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

 

Несмотря на то, что стоимость не является решающим фактором, такие ADM все же менее дорогостоящие по сравнению с системами ХД предприятия.

 

Достоинства подхода «снизу-вверх» построения хранилища данных предприятия.

 

- быстрый возврат инвестиций,

 

- незначительный риск, низкая подверженность внешнему воздействию,

 

- потребности в «политической» поддержке на более скромном уровне и на менее продолжительный срок,

 

- быстрое развертывание,

 

- для «сфокусированной проблемы» организуется специализированная группа,

 

- пошаговая природа.

 

Недостатки подхода «снизу-вверх» построения хранилища данных (ХД) предприятия.

 

- возможное «проклятие успеха» (т.е. полный успех подавляет ресурсы),

 

- необходимость в координировании многочисленных групп,

 

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

 

2.2.        Подходы к архитектуре ХД.

 

Рассмотрим следующие подходы к архитектуре ХД.

 

- ХД – корпоративная информационная фабрика (Corporate Information Factory, CIF) Билла Инмона;

 

- ХД с архитектурой шины (Data Warehouse Bus, BUS) Ральфа Кимболла (Ralph Kimball);

 

- распределенное ХД (Distributed Data Warehouse/Distributed Data Mart, DDW/DDM);

 

- объединенное (федеративное) ХД (Federated Data Warehouse/Federated Data Mart, FDW/FDM).

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

 

1) Корпоративное хранилище данных (Corporate Information Factory, CIF).

 

Ранее этот подход был известен под названием классического ХД (Enterprise Data Warehouse, EDW).

 

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

 

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

 

Корпоративное ХД –  это:

 

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

 

- не механическая коллекция Витрин Данных, а физически целостный объект.

 

Работа такого Хранилища начинается со скоординированного извлечения данных из источников.

 

После этого загружается реляционная база данных с третьей нормальной формой, содержащая атомарные данные.

 

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

 

Эти репозитории, в частности, включают специализированные Хранилища для изучения и «добычи данных» (Data Mining), а также Витрины Данных.

 

Реляционная база данных.

 

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

 

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

 

Атомарные данные остаются доступными через нормализованное ХД. Очевидно, что структура атомарных и суммарных данных при таком подходе существенно различается.

 

Пространственная модель - dimensional model.

 

Пространственная модель - это одна из моделей ХД, в которой данные организованы не по третьей нормальной форме, а в виде тематических таблиц, каждая из которых содержит характеристику отдельных категорий информации (dimensions). Основная цель пространственной модели - минимизировать время выполнения запроса, поэтому допускается денормализация данных. С этой же целью данные группируются вокруг центральной задачи (или вопроса), которую придется выполнять наиболее часто. Центральная таблица связана со всеми описательными таблицами, но последние напрямую не связаны между собой (так называемая архитектура «звезда»).

 

Отличительные характеристики подхода Билла Инмона к архитектуре корпоративного ХД:  

 

1)            Использование реляционной модели организации атомарных данных и пространственной - для организации суммарных данных.    

2)            Использование итеративного или «спирального» подхода при создании больших ХД, т.е. «строительство» не сразу, а по частям. Это позволяет при необходимости вносить изменения в небольшие блоки данных или программных кодов и избавляет от необходимости перепрограммировать значительные объемы данных в ХД. То же самое можно сказать и о потенциальных ошибках: они также будут локализованы в пределах сравнительно небольшого массива без риска испортить все ХД.

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

 

Достоинства архитектуры корпоративного хранилища данных (CIF).

 

- непротиворечивость информации;

 

- один набор процессов извлечения и бизнес-правил;

 

- общая семантика;

 

- централизованная, управляемая среда;

 

- легко создаваемые и наполняемые витрины данных;

 

- единый репозиторий метаданных.

 

Недостатки архитектуры корпоративного хранилища данных.  

 

- реализация требует больших затрат;

 

- высокая ресурсоемкость;

 

-потребность в системах и ресурсах в масштабе всего предприятия;

 

- рискованный сценарий («все поставлено на карту»).

 

2) ХД с архитектурой шины (Data Warehouse Bus).

 

Альтернативный подход к архитектуре ХД, известен как ХД с архитектурой шины или подход Ральфа Кимболла.

 

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

 

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

 

В отличие от подхода Билла Инмона, пространственные модели строятся для обслуживания бизнес-процессов (которые, в свою очередь, связаны с бизнес-показателями или бизнес-событиями), а не бизнес-отделов.

 

ПРИМЕР.

 

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

 

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

 

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

 

Типичные черты подхода Ральфа Кимболла:

 

1)            Использование пространственной модели организации данных с архитектурой «звезда» (star scheme).

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

 

ХД с архитектурой шины обладает следующими характеристиками:

 

1)            это  пространственное ХД;

2)            это ХД  включает как данные о транзакциях, так и суммарные данные;

3)            это ХД включает витрины данных, посвященные только одной предметной области или имеющие только одну таблицу фактов (fact table);

4)            это ХД может содержать множество витрин данных в пределах одной БД;

5)            это ХД не является единым физическим репозиторием (в отличие от подхода Билла Инмона). Это «виртуальное» ХД. Это коллекция витрин данных, каждая из которых имеет архитектуру типа «звезда».

 

3) Объединенное (федеративное) ХД (Federated Data Warehouse, FDW).

 

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

 

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

 

Обычный подход к улучшению информированности о бизнес-операциях - проведение стандартизации «сверху вниз» как структуры отчетности, так и модели данных. Однако с практической точки зрения стандартизация бизнес-структур оказывается для большинства организаций исключительно нецелесообразной - требуется слишком много средств, времени. Кроме того, данный подход может быть просто нереализуем, поскольку в любом бизнесе присутствует чрезвычайно мало простых и однообразных областей, которые не потребовали бы учета местной специфики. Если, например, можно стандартизировать коды валют по всей корпорации, введение полностью стандартизированной линейки продуктов редко оправданно, а в некоторых случаях - даже нежелательно.

 

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

 

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

 

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

 

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

 

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

 

Каждый из экземпляров ФХД хранит копию базовой бизнес-модели и общие основные данные (common master data), причем каждое ХД более высокого уровня содержит итоговые транзакционные данные более низкого уровня.

 

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

 

Суммарные данные о транзакциях отправляются «вверх», т.е. из локального ХД.

 

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

 

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

 

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

 

Достоинства архитектуры федеративного хранилища данных (FDW).  

 

- общая семантика и бизнес-правила;

 

- один набор процессов извлечения и бизнес-правил;

 

- децентрализованные ресурсы и управление;

 

- параллельная разработка.

 

Недостатки архитектуры федеративного хранилища данных (FDW). 

 

- необходимость в координировании работ;

 

- сложности в преодолении «политических» моментов и решении вопросов авторских прав;

 

- требуется согласованность среди различных отделов по вопросам архитектуры, бизнес правил и семантики;

 

- сложнейшая техническая среда;  

 

- очень часто наличие многочисленных репозиториев метаданных.

 

 

3.            ТИПЫ ХРАНИЛИЩ ДАННЫХ (ХД).

 

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

 

1.            Глобальные хранилища данных.

 

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

 

Различают три типа таких Хранилищ.

 

Типы глобальных хранилищ данных (ХД)

 

1)            Глобальные ХД с географически превалирующей обработкой данных. Например, необходимо интегрировать бизнес в Гонконге с бизнесом в Париже, который в свою очередь следует интегрировать с бизнесом в  Рио-де-Жанейро, а тот - с бизнесом в Нью-Йорке и т.д.

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

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

 

Особенности глобальных ХД.  

 

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

 

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

2.            Финансовые хранилища данных.

 

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

 

Достоинства финансовых хранилищ данных.

 

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

 

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

 

- финансы охватывают все аспекты функционирования корпорации и имеют один «общий знаменатель» - деньги.

 

- финансовые данные по своей природе имеют структуру, на которую напрямую влияет повседневная практика обработки финансовой информации.

 

Недостатки финансовых хранилищ данных.

 

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

 

- Меняются  отчетные периоды. Например, в операционной среде отчетный период завершается в конце месяца, в среде ХД заканчивается на корпоративном календаре.

 

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

 

- Меняются классификации данных.

 

- Меняются валюты. Операционные денежные средства соответствуют той валюте, в которой они обращаются: доллары, евро, рубли и так далее. В глобальной среде деньги преобразуются к одной общей валюте.

 

3.            Хранилища данных в области телекоммуникаций.

 

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

 

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

 

- хранение детальных данных на уровне звонка только за несколько месяцев;

 

- хранение множества детальных данных на уровне звонка, размещенных на различных носителях;

 

- резюмирование или агрегирование детальных данных на уровне звонка;

 

-  хранение только отобранных детальных данных на уровне звонка, и т.д.

4.            Хранилища данных  с возможностями Data Mining и Exploration.

 

ХД, поддерживающие технологию Data Mining (метод «добычи данных») и Exploration (метод исследования данных), являются гибридом классических Хранилищ. Такие Хранилища используются для выполнения мощной статистической обработки данных, т.к. являются: очень детальными, глубоко историческими и оптимизированными для статистического анализа.

 

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

 

 Еще одно важное отличие ХД с возможностями Data Mining / Data Mining и Exploration заключается в том, что эти Хранилища очень часто включают внешние данные. Такие данные очень полезны с точки зрения обеспечения бизнес-перспективы, которую не так легко увидеть без их участия.

 

5.            Хранилища данных в области страхования.

 

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

 

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

 

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

ПРИМЕРЫ.

 

В сфере розничной торговли основными являются: дата продажи, дата появления на складе, возможно, дата производства. В банковском деле основной является дата транзакции; в телекоммуникации - дата телефонного звонка.

 

В страховании же присутствуют даты всевозможных типов.

 

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

 

СПИСОК РЕКОМЕНДОВАННОЙ ЛИТЕРАТУРЫ.

 

[1] Барсегян А. А., Куприянов М. С. , Степаненко В. В., Холод И. И. Методы и модели анализа данных: OLAP и Data Mining. – СПб.: БХВ-Петербург, 2004. - 336 с.

 

[2] Борисов Д.Н.  Корпоративные информационные системы. Учебно-методическое пособие для вузов. Издательско-полиграфический центр Воронежского государственного университета. Воронеж, 2007. –  99 с.

[3] Спирли Э. Корпоративные хранилища данных. Планирование, разработка, реализация. Том 1. – М.: Издательский дом «Вильямс», 2001.

 

[4] Туманов В.Е. Проектирование хранилищ данных для систем бизнес-аналитики: учебное пособие. – М.:Интернет-Университет Информационных технологий: Бином. Лаборатория знаний, 2010. – 615 с.

 

[5] Фоменко Е.Ю. Хранилища данных. Анализ данных: Курс лекций. - М.: Ф-т ВМиК МГУ им. М.В. Ломоносова, 2007.