 |
 
|
 |
Введение в хранилища данных Oracle. Technical white paper.ОбзорВ постоянно меняющейся и все более конкурентном деловом окружении у руководителя постоянно есть потребность в бизнес анализе. Будем использовать термин бизнес аналитика в качестве синонима английского понятия Business Intelligence (BI) – аналитическая платформа компании и технологии, ее поддерживающие, такие, как хранилища данных. Средства бизнес аналитики дают возможность людям, принимающим решения, действовать на основе достоверной информации и делают продукты и услуги компании более конкурентоспособными. Какова бы ни была отрасль деятельности, Вам требуются полные знания о деятельности компании, ее клиентах для оценки потенциальных возможностей и рисков. Для построения корпоративной BI системы ИТ специалисты используют решения на основе набора различных продуктов от разных проиводителей (лоскутная автоматизация). К несчастью, такие лоскутные решения со временем становятся все более сложными и требуют все больших расходов на поддержку. Например, каждое обновление потребует разбора и перенастройки всей системы. Более того, когда множество отдельных производителей обновляют свои продукты, они редко учитывают взаимное влияние на продукты других производителей, которые используются в Вашем решении. Чтобы заставить всю систему работать как одно целое, требуется больше времени, усилий и средств, чем при использовании интегрированного решения.
Что еще более важно – кроме больших затрат на сопровождение, использование нескольких не интегрированных систем может оказывать прямое влияние на бизнес. Имея набор различных инструментов, которые используют каждый свои метаданные (описания данных и их значений), Вы можете получить множество пользователей, которые используют одни и те же данные, но приходят к разным заключениям. Рассмотрим, например, реорганизацию территориального деления продаж (изменение географических границ). Если Ваше CRM приложение использует информацию о новом делении, а финансовое – о старом, одинаковые отчеты о доходах по регионам дадут разные результаты. Представьте себе оживленную дискуссию на собрании между директорами по финансам и маркетингу, когда они обсуждают дальнейшее развитие бизнеса, каждый опираясь на свои цифры.
Oracle предлагает интегрированное BI решение, которое обеспечивает Вашим бизнес пользователям полную картину бизнеса в рамках всей компании. С интегрированным решением от одного производителя Вы получаете:
Решение BI от Oracle было создано для того, чтобы легко и быстро интегрировать различные источники данных, находить информацию в базе данных, распределять найденную информацию и исследовать данные для того, чтобы получать новые знания о бизнесе и клиентах.
ВведениеПостроение типичной BI системы включает такие фазы, как консолидация, исследование и публикация. В дополнение к этому BI решение должно быть создано с учетом возможности расширения и наращивания, чтобы соответствовать изменяющимся требованиям бизнеса. На первый взгляд эти три фазы могут выглядеть простыми, но при ближайшем рассмотрении в каждой из фаз обнаруживаются потенциальные сложности реализации. Например, в первой фазе, консолидация, сложности возникают при увеличении количества разных типов источников данных. Вдобавок к этому данные обычно требуют обработки и трансформации или очистки персональных и адресных данных в процессе консолидации. Как только консолидированные данные готовы для исследования, бесчисленные инструменты для получения отчетов должны быть интегрированы для доставки BI соответствующему бизнес лицу, принимающему решение. Эти средства доступа к данным включают аналитические приложения, запросы и анализ, корпоративную отчетность и т.д. Наконец, каждый инструмент может иметь свой собственные высокопроизводительные средства для ускорения работы, которые тоже должен быть интегрирован в BI систему.
При интеграции таких замысловатых сложных систем, которые включают управление данными, инструменты для получения отчетности, и высокопроизводительные средства для ускорения работы разных производителей, Ваша компания сталкивается с:
К счастью, Oracle создал единую интегрированную платформу для BI.
Архитектура хранилища данныхХранилище данных состоит из четырех компонентов: источники данных (как правило это оперативные системы), область преобразования, область презентации и средства доступа к данным. Оперативные системы служат для ежедневной поддержки бизнеса. К таким системам относятся, например, системы класса ERPM. Данные из источников извлекаются в область преобразования, где они приводятся к общему формату и затем попадают в область презентации, где они становятся доступными для бизнес пользователей с помощью средств доступа.
Все компоненты хранилища могут быть разделены логически, административно и физически. Каждый компонент несет ответственность за выполнение своих задач. Рассмотрим эти задачи более подробно.
Источники данных.
В обязанности компонента источники данных входит предоставление данных компоненту область преобразования. Данные могут быть предоставлены через программные интерфейсы, файловую систему, http протокол, ftp протокол, log файлы базы данных и другие средства коммуникации. В последнее время стали популярными системы интеграции приложений. Наличие таких систем может облегчить построение хранилища.
Область преобразования.
Область преобразования данных включает в себя место для хранения данных и программы извлечения, преобразования и загрузки (ETL). Область преобразования регулярно обращается к источникам данных с запросом на предоставление ей новых данных. Новизна данных может определятся: по колонке дата транзакции, которая обычно присутствует в таблицах транзакций оперативных систем, путем сравнения старых и новых данных (типично для справочников), с помощью поддержки протокола подписка-оповещение, когда оперативная система сообщает, когда и какие данные изменились всем заинтересованным подписчикам.
В области преобразования данных содержатся кросс таблицы, отображающие справочные данные (размерности) из оперативных систем на данные хранилища . В обязанность таких таблиц входит: подстановка суррогатных ключей вместо первичных ключей (кодов) оперативных систем и отслеживание изменений атрибутов. Так, если у служащей изменится фамилия, то компонент область преобразования должен это обнаружить. Есть три основных (и несколько смешанных) реакций на такие изменения атрибутов.
Тип 1 или перезапись. Пользователь не может видеть истории. Старые значения атрибутов перезаписываются. Если у сотрудника сменился телефон, то старое значение пропадает. Применяется для тех атрибутов, которые не нуждаются в отслеживании изменений.
Тип 2 или новая запись. Пользователь может видеть старые данные по-старому а новые – по-новому. Глубина истории не ограничена. Пусть 1 января 2004 года сотрудника повысили с руководителя отдела до руководителя департамента. Тогда по данным хранилища до 1 января он будет считаться руководителем отдела а после первого – руководителем департамента. Если его еще раз повысят то сохранятся все три значения и т.д. Это основной тип отслеживания изменений атрибутов.
Тип 3 или новая колонка. Пользователь может видеть данные и по-старому и по-новому. Глубина истории ограничена обычно одним изменением. Пусть до 1 января 2004 сенсорные киоски продавал отдел перспективных разработок, а после 1 числа – отдел мультимедийных систем. Тогда на продажи киосков можно взглянуть и с новой точки зрения: все киоски продал отдел мультимедийных систем и со старой: все киоски продал отдел перспективных разработок. Некоторые называют этот вид изменений альтернативной реальностью. Этот тип часто применяется в случае реорганизации.
Есть еще один важный тип, это гибрид типа 1 с типом 2, который сочетает достоинства этих двух методов.
Пользователь хранилища данных не имеет доступа в область преобразования и не может адресовать ей бизнес вопросы.
Область презентации данных.
Данные в области презентации организованны для быстрого выполнения запросов бизнес пользователей. Иногда именно эту область называют хранилищем.
Хранилище состоит из серии интегрированных витрин данных. Витрина данных это информация об одном бизнес процессе.
База данных в области презентации данных спроектирована в размерной модели. В размерной модели существует два вида таблиц: таблицы фактов и таблицы размерностей. Таблица размерности состоит из ключа (суррогатного) и набора атрибутов. Атрибуты это обычно понятные пользователю текстовые описания. Например в хранилище могут быть такие размерности: клиент, товар, магазин, место продажи, дата продажи. Таблица фактов состоит из ссылок на таблицы размерностей и показателей (фактов). Если таблица фактов ссылается на размерность, то можно говорить, что она измеряется по данной размерности, например в таблице фактов Продажи (дата, магазин, товар, сумма продажи, себестоимость) есть два показателя: сумма продажи и себестоимость. Размерности часто устроены иерархично. Например, таблица география может иметь уровни – страна, область, район, город. Размерности в средствах доступа к данным используются для представления данных пользователям.
Для выполнения нерегламентированных, заранее не известных запросов, данные в области презентации должны быть атомарными. Атомарность значит наличие исходных данных на самом детализированном уровне. Например, в случае с хранилищем данных для супермаркета таким атомарным событием будет прохождение единицы товара через кассу и этому событию будет соответствовать одна запись в базе данных. Хранение данных на атомарном уровне позволяет получать в будущем ответы на все возможные вопросы и проводить анализ таких данных в любых разрезах. Так как построить и хранить все возможные агрегаты очень накладно, то при использовании агрегированных данных мы будем лишены такой гибкости и неизбежно будем ограничены в характере запросов, ответы на которые можно получить из наших данных. Одновременно с этим в области презентации присутствуют некоторые комбинации агрегированных данных. Базы данных могут обладать специальными средствами для построения агрегированных данных. Агрегаты могут строиться на основе статистики или типичных сценариев использования. Для пользователя наличие или отсутствие агрегата по какой-либо комбинации прозрачно. Для достижения такой прозрачности используются средства на уровне базы данных (перезапись запросов) или на уровне средств доступа к данным.
Все витрины данных должны быть построены с использованием общих размерностей и фактов. Такой подход к использованию согласованных для различных таблиц фактов общих размерностей называется использованием шинной архитектуры. Это позволяет использовать одни и те же единицы измерения (размерности) при анализе различных таблиц фактов. Таблицы фактов представляют собой отображение одного бизнес процесса, таким образом использование шинной архитектуры позволяет проводить сложный сравнительный анализ и переходить от одной таблицы фактов к другой, например посмотреть зависимость затрат от продаж. При построении новой витрины данных должны быть пересмотрены существующие размерности и факты. Шинная архитектура позволяет легко добавлять новые бизнес процессы в существующее хранилище данных.
Средства доступа к данным.
Средства доступа к данным обращаются только к области презентации данных. Их можно разделить на:
Реализация хранилища данныхРассмотрим пример реализации хранилища данных на аналитической платформе Oracle. Как уже упоминалось выше, построение системы бизнес аналитики включает три фазы: консолидацию, исследование и распределение. Остановимся более подробно на каждой фазе.
Фаза 1: Консолидация.
Консолидация данных становится все более сложной из-за таких процессов, как реорганизации, слияния, приобретения и глобализация. Данные стремятся к тому, чтобы распространиться по всей организации по множеству источников данных, что делает еще более сложным их использование для бизнес аналитики. Компонент Oracle Warehouse Builder (OWB) предназначен для консолидации различных источников данных, осуществления преобразований данных, управления жизненным циклом хранилища и совместного использования со средствами доступа.
Шаг 1: Отображение источников данных (оперативных систем) на целевое хранилище данных.
После определения бизнес вопросов и требований к данным со стороны пользователей, ИТ специалисты определяют источники данных, которые содержат данные, соответствующие потребностям пользователей и подключаются к ним. Подключение к источникам в виде плоских файлов, или к реляционным источникам, таким, как Oracle, DB2, Informix, MS SQL Server, Sybase и SAP/R3 возможно при помощи простого выбора соответствующего интегратора OWB. Затем разработчик создает модули источника, которые хранят определения данных, содержащие как информацию о соединении, так и описание таблиц. После подключения к источнику данных интегратор используется OWB для того, чтобы извлечь данные и метаданные из этого источника. Другой тип модуля, который разработчик создает в OWB, это модуль хранилища, которые содержит определения фактов, размерностей, таблиц преобразования и т.д., то есть все, что составляет хранилище данных.
Вместе, эти два типа модулей формируют основные элементы, используемые при создании хранилища. В среде OWB разработчик может просто перемещать объекты модулей, чтобы использовать их как строительные блоки в создании целевого хранилища. После выбора соответствующих объектов OWB предоставляет графическое изображение для отображения таблиц источников на целевые таблицы хранилища (mapping). Разработчик может моделировать все аспекты преобразования данных в форме диаграмм потоков данных. Отображение включает таблицы-источники, целевые таблицы и все операции, которые производятся в процессе ETL. OWB может осуществлять операцию ETL за один конечный шаг, что делает внедрение хранилища быстрым и легким.
Использование OWB для отображения источников данных на цели просто выполнить с помощью графического редактора отображений, в котором пользователь визуально создает или моделирует все аспекты операции ETL. Производительность работы разработчика возрастает из-за возможности визуально реализовывать сложные трансформации, потоковые выражения, множественные соединения, агрегирование и т.д. без необходимости специального знания SQL.
Шаг 2: Генерация кода для извлечения, трансформации и загрузки данных.
После завершения моделей отображения OWB может сгенерировать SQL и PL/SQL код для загрузки и заполнения хранилища данных. Это сохраняет время и снижает требования к опыту разработчика, требуемые для программирования SQL кода. Более того, OWB позволяет разработчику изучать и модифицировать код на любом шаге операции. В дополнение генератор кода OWB может генерировать код, который оптимизирован с учетом характера источника данных. Например, если данные чистые и конфликты не ожидаются, разработчик просто выбирает соответствующую опцию и высокопроизводительный код генерируется для загрузки сразу всего множества данных. С другой стороны, если есть высокая вероятность того, что данные будут нарушать ограничения целостности или повлекут другие ошибки загрузки, разработчик будет использовать опцию построчной генерации и код будет мгновенно переписан для последовательной построчной загрузки. Так генерация пакетов PL/SQL для загрузки происходит автоматически и не требует специальных навыков программирования на PL/SQL, этот инструмент может использовать большое количество разработчиков.
Шаг 3: Генерация бизнес области.
Теперь, когда данные консолидированы и загружены в целевое хранилище, размерная модель данных легко становится доступной для средств доступа Oracle. Все репозитарии и метаданные среды выполнения доступны через публичные представления. Это означает, что средства доступа Oracle «понимают» размерности и иерархии, так же, как и имена таблиц и заголовки столбцов. Как результат, экономится время на программирование, потому что разработчику нет необходимости воссоздавать метаданные, когда используются средства доступа Oracle.
Управление жизненным циклом хранилища.
После внедрения хранилища необходимо управлять изменениями. Изменения представляют собой добавления, удаления или модификацию таблиц, столбцов и представлений в источниках данных. Когда происходят такие изменения, большинство инструментов могут лишь определить, что есть несоответствия между источником и целью. Разрешение конфликтов остается разработчику. OWB, с другой стороны, согласует любые изменения. Например, если изменение происходит после того, как модуль источника создан в репозитарии OWB, определения в репозитарии не синхронизированы с соответствующими им объектами. Функция повторного импортирования позволяет автоматически согласовывать и восстанавливать синхронность определений в репозитарии для объектов.
Фаза 2: Исследование.
Теперь, когда данные находятся в одном централизованном хранилище, мощный инструмент для нерегламентированных запросов и анализа, Oracle Discoverer, позволит изучить потенциальные возможности и риски, которые связаны c Вашими продуктами, клиентами и рыночным окружением.
Бизнес область создается (определяется) автоматически.
Средство доступа к данным Oracle Discoverer предназначено для бизнес-пользователя. Поэтому для описания анализируемых данных используется понятие бизнес области, которая создается администратором. Таким образом, пользователь манипулирует данными, используя привычную терминологию, а не загадочные названия таблиц и столбцов и сложные запросы для получения данных из нескольких таблиц.
Тесная интеграция между OWB и Discoverer позволяет разработчику легко наполнять бизнес область при помощи интерфейса мастера. Размерности и иерархии, созданные в OWB, понимаются Discoverer, что обеспечивает быстрое развертывание средств доступа для конечных пользователей.
Использование аналитических функций базы данных.
Одним из наиболее важных усовершенствований реляционной базы данных для хранилищ данных было появление аналитических функций. Discoverer использует и расширяет набор аналитических функций базы данных Oracle, что позволяет пользователям отвечать на сложные бизнес вопросы. Мощная поддержка аналитических функций, таких, как ранжирование, сравнение по периодам, скользящее среднее, теперь доступна администраторам и пользователям. В дополнение, пользователи могут сортировать данные, вращать их и производить переход по иерархии. Discoverer добавляет еще больше гибкости, позволяя вставлять такие функции как вычисление процента роста между двумя наборами данных и их одновременного ранжирования. Например, пользователь может ранжировать в порядке убывания наиболее быстро растущие продукты в этом году в сравнении с прошлым годом в одном вычислении. Вложенные вычисления значительно снижают время, которое пользователи тратят на то, чтобы найти ответы на сложные бизнес вопросы.
Проверка достоверности по требованию.
Благодаря интеграции OWB и Discoverer пользователи могут просматривать метаданные определений в OWB и определять объекты, на которые влияет определенная трансформация данных. Например, если агрегированный доход от зарубежного филиала вызывает сомнения, пользователь может отследить в графическом представлении все вычисления или другие трансформации, после которых получилась это число. Теперь пользователь может создать свой собственный запрос и легко проверить правильность результатов в той же сессии.
Веб анализ.
Oracle Clickstream Intelligence предоставляет возможности анализа журналов веб-сайтов. Это готовые витрины данных, размерности и шаблоны отчетов для такого анализа.
Результаты запросов распространяются по компании.
Discoverer тесно интегрирован со средством получения регламентных отчетов – Oracle Reports. Он позволяет экспортировать готовые отчеты в формате XML для дальнейшего распространения.
Фаза 3: Распространение данных.
Часто большое количество времени и усилий пользователей тратится в фазе исследования на то, чтобы найти правильные запросы и проанализировать их. Эта ценная информация должна быть распространена по организации до того, как она устареет. Информация может поступать из разных источников (например реляционного и XML). Oracle Reports позволяет выполнять множество запросов в одном отчете, при этом каждый запрос может быть основан на своем источнике данных.
Сгенерировать один раз и доставить в любом формате.
Отчеты всегда были мощным инструментом для публикации данных из базы в различных форматах: PDF, XML, HTML, HTMLCSS, Postcript, PCL, текст с разделителями и RTF. Сегодня пользователи могут публиковать данные с использованием отраслевого стандарта JSP. Это означает, что разработчик может создать шаблон веб-страницы, использую HTML-редактор, затем перенести его в окружение Oracle Reports и включить данные из разных источников данных в эту страницу. Таким образом наша страница будет динамически обновляться при обновлении отчета.
Сгенерировать одни раз и доставить в любое место назначения.
В качестве места назначения для отчета могут выступать принтер, веб, файловая система, электронная почта и Oracle Portal.
Фаза 4: Расширение возможностей.
Быстрая реакция на потребности бизнеса является критическим фактором успеха. Иногда возникает необходимость в разработке заказного приложения для поддержки принятия решений. Компонент Oracle BI Beans в Oracle JDeveloper создан специально для этой цели. Разработчик может быстро собрать BI приложение из высокоуровневых, повторно используемых компонент и воспользоваться свойствами Oracle OLAP.
Быстрая разработка заказных приложений.
JDeveloper и BI Beans обеспечивают наиболее продуктивную среду для разработки приложений для бизнес аналитики.
Интегрированный OLAP.
Oracle OLAP обеспечивает централизованную аналитическую обработку в масштабируемом и безопасном окружении. Это сервер OLAP, встроенный непосредственно в базу данных. Доступ к его функциям осуществляется через Java API или на более высоком уровне – BI Beans.
Data Mining.
Поддержка Oracle Data Mining (ODM) встроена в базу данных. Его функциональность поддерживает алгоритмы классификации, предсказаний и ассоциации. Это позволяет разработчикам встраивать необходимую функциональность в свои приложения для того, чтобы:
ЗаключениеПри создании корпоративного хранилища очень важным является выбор аналитической платформы. Новые возможности, включенные в базу данных и другие продукты Oracle предоставляют большой набор средств для поддержки такой платформы. Сегодня руководители и аналитики погребены под грузом информации и находятся в условиях жестких временных ограничений. Им необходимы визуальные средства для идентификации самых последних тенденций бизнеса и принятия правильных решений. Эта информация должна быть своевременно доставлена тем, кто в ней нуждается. Когда используются база данных, сервер приложений, инструменты для консолидации данных, анализа данных и корпоративной отчетности, которые тесно интегрированы и от одного производителя, такого, как Oracle, то организация имеет солидную платформу для достижения успеха. Такое решение будет наиболее эффективным и с точки зрения стоимости и поддержки.
Литература
Компания "Улис Системс" предлагает услуги по разработке хранилищ данных. В компании работают:
|
| © ULYS Systems, 2006 | ООО “УЛИС Системс”, Киев 02156 ул. Киото, 27 Тел. (044) 544-44-92 |