Хранилища данных — основа для принятия решений

Информационные хранилища (Data Warehouse - DW) сегодня являются хитом рынка информационных технологий. Еще совсем недавно мало кому известная технология стала предметом всеобщего внимания. Ведущие фирмы-производители СУБД наперебой предлагают свои DW, не считая фирм, вышедших с ними на рынок информационных технологий.

Интерес к DW иллюстрируют исследования, проведенные Meta Group, согласно которым, в настоящее время 90% компаний из числа Global 2000 так или иначе реализуют проекты, связанные с DW. Для сравнения, в 1993 г. интерес к ним проявило лишь 5%.

По прогнозам Gartner Group, к 1999 г. объем рынка DW достигнет 7 млрд. долл. Чем обусловлен такой ажиотаж, почему потребителей не удовлетворяют традиционные (реляционные) базы данных? Что представляют собой DW и чем они отличаются от реляционных БД?

Потребителями DW, являются менеджеры всех уровней, использующие их для анализа и принятия решений в различных сферах бизнеса. Как правило, менеджеры работают в той или иной системе поддержки принятия решений (Decision Support System — DSS). DW хранят данные для эффективной работы в DSS и дают возможность решать следующие основные проблемы:

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

Современные DSS, в основе которых лежат DW, позволяют прослеживать новые тенденции, новые взаимосвязи между данными и новые аналитические возможности.

Давайте посмотрим, в чем состоит различие между данными, предназначенными для операционной и аналитической обработок. Операционная обработка ориентирована на поддержку ежедневной деятельности компаний. В ее функции входят ввод заказов и отслеживание их выполнения, оформление платежей за товары и услуги и т. д. Испокон веков подобными вещами занимались системы, называемые сейчас обработкой транзакций в реальном времени (On-Line Transaction Processing — OLTP). Аналитическая обработка ориентирована на решение стратегических вопросов жизнедеятельности компаний в целом, чем всегда занимались в рамках систем поддержки принятия решений. Она получила название систем аналитической обработки в реальном времени (On-Line Analytical Processing — OLAP). Но именно они никогда не оперируют данными реального времени. Эти данные постоянно изменяются, и поэтому строить анализ на них невозможно. Например, пользователь хотел бы выявить своего лучшего торгового агента. Поскольку таких у него десятки (а может быть, и сотни), он начинает последовательно собирать сведения о количестве продаж, сделанных каждым. Тот агент, который находится в конце списка, всегда будет в выигрышном положении, пока дойдет очередь до него, он успеет сделать еще несколько продаж. Это подтверждает, что OLAP не только не работают, но и не могут работать с подобными данными. В рамках DSS обычно проводится сравнительный анализ, для которого нужны данные, не изменяющиеся во времени. Таким образом, операционные БД хранят данные, актуальные до минут и секунд, впоследствии они могут неоднократно модифицироваться. Актуальность сохраняется до конца отчетного периода (например, в течение года). БД для аналитической обработки должны хранить данные, актуальные на определенный период времени (день, но не минуту), и в дальнейшем не изменяющиеся. Продолжительность хранения исчисляется годами (примерно 5—10 лет). Кроме того, операционные данные всегда детальны, специфичны, локализованы. В самом деле, в OLTP задаются решением частных вопросов: ушел ли конкретный груз; каков счет со всеми деталями его образования в конкретном банке и т. д. OLAP оперирует итоговыми значениями: каков общий объем продаж за определенный период времени, без учета всякой специфики (например, особенностей отдельных продаж).

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

Первые операционные БД (иерархические и сетевые) удовлетворяли с точки зрения быстродействия, но были мало пригодны для сложных и гибких типов анализа (не предназначались для этого). Затем появились реляционные БД, в них стало возможным делать самые изощренные запросы для последующего анализа. Почему же их не приняли на вооружение в DSS? Поскольку альтернативы им не было, то приходилось работать с ними, даже без особого желания. Вся беда была в их структуре. Реляционные БД состоят из множества связанных между собою таблиц. Связь осуществляется посредством первичных и внешних ключей. Недостаток состоит в том, что при каждом запросе для соединения (join) таблиц связь будет заново устанавливаться. Это очень понижает быстродействие. В какой-то мере могут помочь всевозможные методы индексации, но проблема остается, особенно когда необходимо связать несколько десятков таблиц.

Другой недостаток реляционных БД заключается в том, что необходимо нормализовать их структуры — святая святых реляционного мира — для устранения избыточности (и по связям, и по содержанию таблиц). Это приводит к образованию очень сложных структур. Разобраться в них трудно даже специалистам, не говоря о пользователях. И наконец, последнее. Допустим, приложение с реляционным БД разработано и сдано в эксплуатацию. В нем фиксированы структура БД и запросы, которые пользователь может сделать. А если возникнет необходимость в нереализованном (ad hoc) запросе? Вряд ли пользователь сам станет выписывать нужный запрос на SQL, который для него не проще китайской грамоты. А вдруг ему понадобятся данные, которых нет в существующей БД, и потребуется хоть и немного, но переделать ее? Об этом пользователь может лишь мечтать, особенно если такая потребность временная.

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

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

Итак, разница между операционными и аналитическими данными достаточно существенная для разделения их друг от друга. Теперь посмотрим, как устроены БД для аналитических данных DW.

По способу получения они могут быть унаследованными (legacy), операционными (operational) или внешними (external). Унаследованные — те, которые достались из прошлого и могут находиться на БД мэйнфреймов, в реляционных БД и т. д. Об операционных мы уже говорили, источники внешних не требуют объяснения.

Форматы всех этих данных различны, и для сбора их под одной крышей необходимо ПО промежуточного слоя (midleware, часто переводится как «связующее ПО»). Полученные унифицированные данные складируются в DW (отсюда и название). Доставка их конечному пользователю может быть прямой либо через «информационные витрины» (data mart). В последних находятся подмножества данных из DW, собранные по некоторому тематическому признаку. Наличие информационных витрин необязательно, но поскольку каждый менеджер занят в узкой области деятельности, то у него нет необходимости во всей информации из DW. Иллюстрацией этого является рис. 1.

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

На рисунке вы видите общую архитектуру, показывающую DW и среду ее «обитания». Если рассматривать архитектуру на более детальном уровне, то ее реализация возможна, как правило, в двух вариантах. В самом простом случае это два звена. Одно — сервер DW, а другое — клиентское, на котором находятся инструментальные средства анализа и поддержки принятия решений. Более сложный вариант — три звена: два прежние с таким же назначением, но между ними помещается OLAP-машина.

Центральным элементом архитектуры, разумеется, является собственно информационное хранилище (DW). Модель данных его может быть как многомерной, так и реляционной (плоской). В последнем случае речь идет о реляционной OLAP (Relational OLAP - ROLAP). Нет, это не описка, о тех самых реляционных БД, которым было уделено так много места для критики. Но, во-первых, мы рассматривали только их недостатки, совсем игнорируя достоинства (они общеизвестны). Во-вторых, мы имели в виду традиционное использование реляционного подхода, а он действительно мало пригоден для OLAP. Причем говорилось также о том, что аналитические данные должны быть иначе сконструированы. Именно по этому пути пошли приверженцы реляционных БД для применения их в качестве DW. Оказалось, что недостатков можно избежать (почти) при сохранении всех достоинств. Другой путь выбрали противники реляционного подхода, руководствуясь принципом «новые базы данных для новых решений старых проблем». Они начали активно разрабатывать технологию многомерных баз данных (MultiDimentional Database — MDD), исходя из предпосылки, что многомерному взгляду на данные (о природе термина чуть позже) должно соответствовать их многомерное хранение. В этом варианте данные хранятся как совокупность логически упорядоченных массивов, отражающих их многомерную природу.

Удалось частично решить одну из главных проблем OLAP: низкую скорость обработки запросов. С одной стороны, за счет избыточности хранимых данных, с другой — за счет более простой и эффективной системы индексации. Поскольку отдельный элемент хранения в многомерной БД крупнее, чем в реляционной, индекс, ему соответствующий, имеет меньший размер. Однако ряд недостатков ставит под сомнение будущее MDD. Во-первых, избыточность информации может быть слишком большой. Как показали некоторые эксперименты, входной файл размером 200 MB после его загрузки в MDD может разрастись до 5 GB. Кроме того, потребность в незначительной модификации структур данных приводит к очень серьезной перестройке БД. Перечень достоинств и недостатков как реляционных, так и многомерных БД можно продолжить. По этой причине оба подхода имеют своих сторонников.

Теперь рассмотрим, как конструируются структуры данных для DW. Основой реализации содержимого DW является многомерная модель. Она не зависит от физической природы DW. Строительными блоками реляционной модели являются сущности (entity), каждая из которых впоследствии представляет собой отдельную таблицу. Строительными блоками многомерной модели являются таблицы фактов (иногда называемые таблицами показателей, measure) и измерений. Последние включают характерные для данной сферы бизнеса понятия: рынок сбыта, временные периоды, продукты и т. д. Таблица фактов содержит в численном выражении то, что в результате вы хотите выяснить. Например, количество продаж, затраты, чистая прибыль и пр.

Почему модель данных называется многомерной? Допустим, вас интересует, на какую сумму на текущий момент продан определенный продукт. Продукты закодированы цифрами от 1 до 4. В данном случае мы имеем дело с одним измерением «Продукт» (соответственно с одномерной моделью данных). Сумма продаж по каждому не является измерением, поскольку в каждый текущий момент она — величина постоянная. На рис. 2 это вариант слева. Каждому продукту в измерении соответствует интервал, под которым цифрой указан шифр продукта. Над интервалом можно проставить сумму его продаж. Но мы уже говорили, что подобные запросы интересны в OLTP. В OLAP нас, по крайней мере, заинтересует сумма продаж каждого продукта по годам, допустим, в интервале с 1993 г. по 1996 г. (рис. 2, в центре).

Одна ось измерения, по-прежнему, «Продукт», но добавилось другое — «Время». Получили двухмерную модель. В каждом квадратике будет находиться сумма продаж продукта за определенный год. А если нужно узнать сумму продаж указанного перечня продуктов по годам и регионам сбыта? Тогда придется иметь дело с трехмерным кубом. В трехмерной модели появилось третье измерение «Регион сбыта», информация находится в маленьких кубиках (контейнерах), составляющих большой куб. Например, закрашенный кубик соответствует запросу: «Каков объем продаж продукта с шифром 4 в центральном регионе за 1996 г.?». Можно усложнить запрос: «Каков объем продаж продукта с шифром 4 в центральном регионе за 1996 г. для клиента с шифром А?». Добавится еще одно измерение — и куб превратится в четырехмерный. Сложно? А если таких измерений пять и более? Необходим некий аналог подобным многомерным конструкциям. Ими являются таблицы фактов и измерений, организованные в специальные структуры данных (схемы). Основные из них — схемы звездочки (star schema), наиболее популярные во многомерном моделировании, и снежинки (snowflake schema). Примеры приведены для ROLAP.

Как видно из рис. 3, таблица фактов «Продажи», кроме собственно фактов, содержит связи со всеми измерениями с помощью ключей (код местонахождения, времени и продукта). В схеме звездочки такая таблица всегда одна, а вот измерений может быть сколько угодно. Например, три: «Продукт», «Местонахождение» и «Время» (наиболее часто задаваемые в DSS вопросы: что, где, когда).

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

Элементы отражают иерархию измерения. Дни, недели и месяцы составляют иерархию «Время». Элементы более низкого уровня могут быть свернуты в элементы более высокого. В одном измерении может быть несколько иерархий. Скажем, дни свернуты в недели и месяцы, а недели в месяц свернуть нельзя, поскольку он не делится без остатка на недели. Поэтому в одном измерении имеются две ветки иерархии. Значение иерархий заключается в том, что их можно применять для детализации (drill-down) и обобщения (drill-up) анализа. Например, после просмотра продаж по регионам пользователь может детализировать его до области или города. Кроме того, элементы можно использовать для фильтрации данных. Предположим, необходимо выяснить объем продаж продукта некоторой марки («Продукт») по месяцам («Время»), но только в западном регионе («Местонахождение»). В этом случае элементы измерений «Имя марки продукта» и «Месяц» служат для группирования данных, тогда как фильтр, размещенный на элементе «Регион» измерения «Местонахождение», возвратит данные только по западному региону.

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

Теперь рассмотрим особенности многомерной модели и ее отличие от реляционной (рис. 4, 5).

Данные, содержащиеся в обеих моделях, одни и те же. В первом случае они представлены в двух нормализованных таблицах (имя менеджера марки в базе данных фигурирует один раз), связь между которыми осуществляется посредством ключа «Код марки продукта». Во втором случае две таблицы объединены в одну. Теперь имя менеджера марки повторяется столько раз, сколько встречается код марки. Налицо избыточность, присущая многомерному моделированию. Какими бы ни были оправдания, избыточность может быть значительной. Предположим, имеется 10000 наименований продуктов (10 марок), которые, в свою очередь, разбиты на семейства. В таблице «Продукт» для них отведено 10000 строк, в каждой из которых присутствует имя менеджера марки (хотя их всего не более 10, к примеру, по одному на каждую марку). Это справедливо также для атрибутов других элементов измерений. Вот почему следующей популярной схемой представления данных (после схемы звездочки) является схема снежинки, та же схема звездочки, но с нормализованными таблицами измерений. В ней атрибуты элементов выносятся в отдельные таблицы. Измерения с теми же названиями сохраняются, но служат для связи с таблицами фактов и атрибутов (по одной на каждый элемент измерения). Скорость выполнения запросов несколько уменьшится, но только в том случае, когда необходимы таблицы фактов. А если речь идет о манипуляциях с таблицами измерений, скорость обработки, наоборот, резко увеличится за счет уменьшения количества обрабатываемых строк. Значительно сокращается размер памяти, требуемый для хранения. К недостаткам следует отнести усложнение схемы данных.

И, наконец, в качестве компромисса используется схема неполной снежинки (partial snowflake schema). В ней нормализации подвергаются лишь отдельные измерения. Это дает возможность повысить производительность при некоторой экономии дискового пространства.

Уже говорилось, что DW ориентированы на конечного пользователя. Если моделирование многомерных структур и перекачка данных из операционных БД в DW — удел специалистов, то дальнейшая работа должна проводиться самим пользователем. Для этого ему необходимо полное и ясное описание данных и их структур, чтобы иметь возможность делать корректные запросы к DW. Такой цели служат метаданные (metadata), в которых содержится вся информация о данных DW. Описание метаданных завершает процедуру формирования DW.

Все, о чем мы говорили до сих пор, относится к подготовительному этапу работы в DSS. Теперь можно перейти к анализу, к тому, ради чего все это и затевалось. Возможны два варианта. Простейшие средства анализа осуществляются так называемыми машинами (engine) OLAP. Они позволяют осуществлять навигацию по структурам данных, при необходимости вычисляют итоговые значения и, конечно, реализуют запросы к DW. К более сложным средствам анализа данных относятся интеллектуальные методы обработки (data mining). Именно они помогают выявлять закономерности для углубленного анализа. Существует несколько способов поиска закономерностей. Например, для группирования клиентов применяется способ классификации, посредством чего можно выявить признаки, характеризующие конкретного клиента. Далее можно детально проанализировать стереотипы поведения группы. На этой основе выработать оптимальный вариант обслуживания клиента, после чего никакой ваш конкурент не переманит его к себе.

Теперь, когда рассмотрены основные проблемы, связанные с DW, обратим внимание в самом общем виде на подходы к реализации DW некоторыми ведущими фирмами: Informix, Oracle и Sybase. Наш выбор обусловлен двумя причинами. Во-первых, эти фирмы давно и прочно обосновались на украинском рынке. Во-вторых, на их примерах можно продемонстрировать различия в подходах к реализации DW.

С точки зрения базового подхода, Informix и Sybase являются приверженцами ROLAP, тогда как Oracle больше склоняется к OLAP на основе многомерных баз данных (не отказываясь полностью от реляционной БД). При этом Informix и Oracle поставляют готовые продукты, a Sybase, в большей степени, — технологию для разработки DW. Однако Informix и Oracle поставляют также мощные инструментальные средства разработки, поэтому можно рассматривать их DW как полуфабрикат и развивать в любом желаемом направлении. Точно также, взяв базовый продукт Sybase, можно доукомплектовать его до полноценного DW продуктами ее партнеров. В плане архитектурных решений Informix следует классической схеме сверху-вниз, когда сначала строится DW, а на его основе — информационные витрины. Sybase придерживается прямо противоположной точки зрения, предлагая строить информационные витрины с последующим их объединением в DW. Oracle, похоже, рассматривает DW и информационные витрины как отдельные архитектурные решения и поставляет для их построения отдельные инструментальные средства.

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

Итак, добро пожаловать в мир информационных хранилищ.