Однако и принять решение о построении такой системы бывает очень не просто.

Терминологическая прелюдия. В этой статье термин "хранилище данных" означает традиционный, но вольный перевод английского data warehouse и используется здесь лишь для совместимости с другими публикациями; термин "витрина данных" — традиционный перевод data mart; термин "нерегламентированный" [запрос] — перевод латинского ad hoc [query].

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

Цифры завораживают и заказчика, тем более что по хранилищам данных и их "меньшим братьям", витринам, написана масса увлекательных книг, статей и рекламы. Он начинает колебаться — и соглашается потратить на это пару лет и пару миллионов. Исполнитель (нередко он же и заказчик одновременно) не в проигрыше: или на два года денег не хватит, и тогда какие претензии, или про хранилище данных все забудут, или, если проект будет успешно доведен до провала, можно будет оправдаться мировой статистикой 80%-ных неудач подобных проектов. Но при любом исходе не одно резюме обогатится новой респектабельной записью.

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

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

В начале было слово

Слова "хранилище данных" (DW) впервые были запущены в литературу в 1988 году Биллом Инмоном. Первоначально под ними разумелось вот что. "Хранилище данных — это набор данных, созданный для поддержки принятия решений управляющим персоналом и обладающий следующими свойствами:

  • данные предметно-ориентированы;
  • интегрированы;
  • привязаны к разным моментам времени;
  • малоизменчивы".

Об этих свойствах написано немало. Чтобы оценить степень "новизны" понятия DW, cкажем несколько слов только о последнем из них. Оно не означает, что данные, попав на склад, "омертвевают" (и достойны, как считают некоторые, только компакт-диска); они продолжают "жить" следующим образом:

  • при необходимости удаляться;
  • агрегироваться;
  • архивироваться.

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

При этом характер данных на складе таков:

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

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

А если читать не только Инмона, то можно заметить, что "разбежались по сторонам" и сами принципы. Так, в отчете Энтони Гэнди и Криса Чепмена "Складирование данных: освобождение силы пользовательской информации" (вышедшем не ранее 1997 года и профинансированном фирмами MicroStrategy и Tandem) можно найти, например, три принципа, звучащие так:

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

Ну а понятие витрины данных еще более интуитивно, так как отталкивается от понятия склада; в результате даже эксперты на страницах печатных изданий порою запутываются в этой "игре в понятия" и простодушно заявляют, что "дело не в названиях", а в том, чтобы "система помогала эффективно принимать решения" (см., например, Oracle Magazine, 1998, № 1, vol. 12, с. 144).

"Хранилище" или "база"?

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

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

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

Представление о современных реализациях идеи DW можно получить из статьи "Витринам данных не мешает похудеть", опубликованной в предыдущем выпуске рубрики "Директору информационной службы". Некоторые впечатления о ней, в свете обсуждаемого, хотелось бы высказать. Во-первых, статья конечно же отражает и обобщает некоторый опыт конкретных работ. Это помогает не набить себе лишних шишек. Во-вторых, видно, что вокруг витрин/хранилищ данных сложилась целая индустрия разработчиков и консультантов, с одной стороны, и обширная клиентская база — с другой. В-третьих, в статье, хоть и вскользь, но все же затрагиваются — кроме технологических — еще и методологические вопросы, но вот тут-то и может зародиться недоумение. Например, как прикажете относиться к приведенной в статье метафоре "Lego-витрин"? Не иначе как к попытке "на пальцах" изложить давно сформулированную разницу между концептуальной и внешней схемой в базах данных. Известен и механизм задания внешних схем в реляционных СУБД — механизм представлений (view). Конечно, дополнительную окраску дает аспект распределения витрин по разным серверам внутри предприятия (если такое распределение присутствует), но ведь и реляционный подход не чурается распределенной БД. Насторожиться же нужно не потому, что идея представлений плоха, а потому, что предлагаемая технология выдается за новую, а ведь старые идеи имеют по определению больше времени на проработку. Правильно ли разбивать преемственность методологической базы и начинать проработку известных проблем с нуля?

Доктор нам поможет

Не скрою, что одним из стимулов к написанию этой статьи послужила опубликованная в русском переводе в Oracle Magazine/Russian Edition №2, 1998 заметка Пола Дорси "Хранилища данных, гибкие запросы и другие способы разрушить компанию". Я настоятельно рекомендую всем руководителям, связанным с проектами по созданию DW, прочесть этот материал. Доктор Дорси не является игроком на стороне "большого бизнеса", и поэтому его публичные выступления временами звучат диссонансом в общем унисоне голосов. Но кроме того, доктор Дорси — истинный американец и не позволяет себе ограничиться лишь развенчанием современного положения дел; он пытается найти в этом массовом явлении "рациональное зерно", коль скоро таковое существует.

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

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

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

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

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

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

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

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

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

Так каков же финал? Учитывая существующую разноголосицу в суждениях, стоит ли директору ИС заводить у себя в организации хранилище данных? Решение о разворачивании проекта системы поддержки принятия решений остается за ним. Это самое трудное, а дело различных публикаций — помочь ему в этом. Здесь мало говорилось о привлекательной стороне хранилищ данных, но на эту тему, хотя и не всегда корректно, в избытке написано в компьютерной литературе. Если все же идея DW вас серьезно увлекла, перечитайте советы "от доктора Дорси и других", которые включены в эту статью.

Советы по разработке хранилища данных — от доктора Дорси и других

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