Хранилища данных, гибкие запросы и другие способы разорить компанию

Пол Дорсей, Oracle Magazine/RE, #2/1998

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

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

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

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

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

Разработка хранилищ данных

За реализацию проекта создания хранилища данных руководитель организации обычно берется после поездки на конференцию, где он своими глазами видит безупречно работающие гибкие запросы. После этого организация устанавливает набор критериев (обычно технического порядка) и покупает инструментальное средство. Заметим, что средство закупается без какого-либо предварительного изучения пожеланий и требований пользователей. Если в компании работают специалисты, обладающие хоть толикой здравого смысла, то сначала будет разработан небольшой пилотный проект. После этого настает черед проектирования и построения основного хранилища данных предприятия; причем вести этот проект будет поручено администратору баз данных. На заключительной стадии проект представляют сообществу пользователей. Далее же руководству организации останется лишь недоумевать: почему никто не пользуется таким дорогостоящим проектом? Конечно, основная причина состоит в том, что проект выполнялся без тщательного анализа требований пользователей. Почему-то вся коллективная мудрость, накопленная за последние 30 лет разработки традиционных систем и заключающаяся в необходимости проведения подробного и аккуратного анализа требований, куда-то улетучивается при переходе к проекту хранилища данных.

Что такое хранилище данных

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

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

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

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

Зачем создавать хранилища данных

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

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

Для чего служит хранилище данных

Существуют четыре аспекта реализации, которые необходимо рассмотреть в ходе проработки проекта хранилища данных:

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

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

Причины неудач средств обработки гибких запросов

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

Пользователь должен знать булеву алгебру

Компьютерное и человеческое восприятие "и/или" принципиально различаются. Один из моих любимых примеров: попросите кого-либо из руководителей-администраторов выбрать из предложенных вариантов выражение, которое правильно описывает задачу "Выдать список служащих не из Нью-Йорка или Чикаго":

(Место проживания /= 'Нью-Йорк') И (Место проживания /= 'Чикаго')
( НЕ (Место проживания = 'Нью-Йорк') И (Место проживания = 'Чикаго'))
(Место проживания /= 'Нью-Йорк') ИЛИ (Место проживания /- 'Чикаго')
( НЕ (Место проживания = 'Нью-Йорк') ИЛИ (Место проживания = 'Чикаго'))

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

Пользователь должен знать основы sql и реляционной теории

За очень редкими исключениями такие средства основаны на применении пользователями SQL. Если пользователь незнаком с концепцией таблиц и внешних ключей, вряд ли он сможет грамотно использовать опцию group by.

Пользователь должен знать средства формирования гибких запросов

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

Пользователь должен знать структуру и особенности базы данных

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

Пользователь должен понимать итерации обработки запросов

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

Установка метаслоя

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

Типы средств обработки гибких запросов

Мир инструментария гибких запросов на порядок сложнее, чем обычно представляется. Здесь имеется не просто масса средств - речь идет о множестве типов средств. Члены команды разработчиков хранилищ данных, как правило, знакомы с одним-двумя такими средствами. Подробное обсуждение каждого из перечисленных в таблице средств выходит за рамки данной статьи. У всех без исключения средств есть своя область применения. Обычно для удовлетворения всех потребностей пользователей необходимо объединить "представителей" разных категорий.

Внедрение хранилищ данных

Проект хранилищ данных может использовать различные способы организации серверной части:

• представления промышленной системы;
  
• представления промышленной системы некоторыми избыточными столбцами и таблицами;
  
• нормализованная до третьей нормальной формы копия промышленной системы;
  
• агрегированное хранилище данных - OLAP;
  
• витрины данных.
  

С этими способами связан целый спектр значений стоимости разработки - от самого дешевого (использование представлений промышленной системы) до наиболее дорогого (создание витрин данных). Как это ни парадоксально, те варианты, которые чаще всего выбираются, оказываются самыми дорогими.

Клиентская часть может быть реализована четырьмя способами:

• системой гибких отчетов;
  
• заранее заготовленными запросами;
  
• гибкими отчетами на основе одной таблицы;
  
• полным инструментарием гибких запросов.
  

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

Миграция данных: скрытый кошмар

Загрузка информации из промышленно эксплуатируемой системы - всегда сложная задача. К сожалению, обычно для этого используется программное обеспечение эксплуатируемой системы, то есть для построения плоских образов таблиц хранилищ данных пишутся программы на Коболе. Большинство утилит миграции данных построены по этой модели. Выполнение миграции данных таким образом может привести к катастрофе. Припоминаю случай, когда для заполнения 10 таблиц хранилища данных пилотного проекта была написана утилита на Коболе длиной в 2000 страниц! К счастью, чаще используется гораздо более удачное решение - сложные программы миграции данных создаются на стороне хранилища данных, а не на стороне системы OLTP. Простые таблицы действующей системы извлекаются в Oracle, где намного легче выполнить сложные процедуры миграции.

Перевод упомянутой выше программы миграции данных на Коболе в 2000 страниц на сторону Oracle потребовал всего около 100 страниц кода. В дополнение, пользуясь Oracle Forms, мы написали генератор миграции данных. Он и сгенерировал автоматически почти 95% кода на PL/SQL.

Десять причин, по которым проект хранилищ данных может потерпеть неудачу

Все приведенные ниже ситуации взяты из реальной жизни.

1. Наиболее распространенная причина неудач заключается в том, что разработка хранилищ данных начинается еще до того, как закончится сбор требований, предъявляемых пользователями к хранилищу данных. То, что всеми признано абсолютно нелогичным в разработке систем OLTP, довольно часто имеет место при разработке хранилищ.
   
2. Если при выборе инструментария пользователей исходить только из соображений снижения стоимости проекта, не учитывая потребности пользователей, это зачастую может стать причиной провала. Проекты хранилищ данных столь велики и требуют таких огромных вложений, а результаты их внедрения так впечатляющи, что затраты на пользовательский инструментарий представляются несущественными.
   
3. Если ставка делается на то, что пользователи освоят булеву логику, это, как уже говорилось выше, может стать причиной провала проекта в целом.
   
4. Предоставление пользователям слишком большого числа таблиц и формирование слишком сложной рабочей среды может сослужить плохую службу.
   
5. Не исключено, что миграция программ на Коболе может потребовать до 80% бюджета нового проекта.
   
6. Написание отчетов конечных пользователей на Коболе и отказ от освоения новых систем составления отчетов, обусловленный лишь тем, что местные программисты давно изучили Кобол, могут оказаться для проекта пагубными, поскольку современные генераторы отчетов намного эффективнее.
   
7. Разработка проекта хранилищ данных не должна начинаться с перехода на Oracle. Если организация решила перейти на Oracle, то не следует в качестве первого шага разрабатывать хранилище данных.
   
8. Недостаточный объем данных, помещенных в хранилище, также может вызвать крах. При проектировании хранилищ данных разработчики используют, как правило, схему базы данных в виде "звезды" либо "снежинки". Проект хранилищ данных отличается от схем баз данных для систем OLTP. Обсуждение этих архитектурных особенностей выходит за рамки настоящей статьи. Вкратце аргументация сводится к тому, что если хранилище данных не предназначено для выполнения этих функций, то отпадает необходимость в бизнес-правилах проверки вводимых данных. Если же не нужно поддерживать целостность данных, это позволяет значительно упростить структуры данных. Схемы "звезды" и "снежинки" могут служить примерами такого упрощения. При использовании таких структур распространенная ошибка заключается в том, что в хранилище данных помещается недостаточно данных для пользователей. Обычно в таких структурах агрегирование проводится на слишком высоком уровне, данные неполны и не позволяют адекватно удовлетворять потребности пользователей, возникающие сразу после сдачи системы в промышленную эксплуатацию. Это еще одно из последствий недостаточного внимания к требованиям пользователей.
   
9. Развертывание первого проекта хранилища данных сразу в масштабах всею предприятия может дискредитировать саму идею хранилищ. Прежде чем приступать к реализации большого проекта, следует выполнить первый проект для небольшого подразделения предприятия.
   
10. В случае неудачи пилотного проекта не следует думать, что накопленный опыт позволит вам в дальнейшем не повторить прежних ошибок, а значит, можно смело приступить к реализации большого проекта. Рекомендуется выполнить еще один пилотный проект.
    

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

• Руководитель проекта должен не только иметь опыт успешного создания нескольких хранилищ данных, но и ориентироваться в различных типах инструментария конечных пользователей: гибких отчетах, гибких запросах и OLAP.
  
• Решающим фактором является тщательный сбор и анализ требований пользователей, включая наследуемые отчеты. Очень важно проверить, какие отчеты используются в действительности. Недостаточно лишь перечислить названия отчетов. Надо также проанализировать все разовые справки, потребность в которых возникала ранее. Особый интерес представляют отчеты, предлагаемые пользователям в виде файлов ASCII для включения их в отчеты Excel или SAS, чтобы выяснить, как пользователи применяют эти материалы.
  
• Разработайте методику использования пользователями новых инструментов гибких запросов. Можно предоставить пользователям журнал, в который они записывали бы пожелания к новой системе. Отслеживайте не только отчеты, которые им хотелось бы иметь, но и решения, принимающиеся с их помощью. Это позволит оценить важность тех или иных видов информации, что необходимо в первую очередь для принятия решений о помещении информации в хранилище данных.
  
• Создайте пилотный проект. Выберите наиболее инициативных пользователей для серьезного анализа требований. Опробуйте несколько различных средств миграции данных, а также клиентских и серверных программных средств. Не следует жалеть денег на пилотный проект - это в конечном итоге все равно выгоднее, чем вложить значительно более крупные суммы в полномасштабный проект, который затем провалится. Будьте готовы к тому, что первый пилотный проект провалится. Если это произошло, выполните еще один пилотный проект.
  
• Осчастливьте пользователей! Проекты хранилищ данных намного более "чувствительны" к настроениям пользователей, нежели какие-либо другие проекты. Полученная система должна быть проста в использовании и обеспечивать точные результаты. Если хотя бы один пользователь останется недоволен ее работой, репутация системы будет безнадежно испорчена.
  

Заключение

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

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

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

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

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