Data Warehouse -- почувствуйте себя принимающим решение

Владимир Викторович Пржиялковский

независимый консультант, координатор ЕАГПО


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


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


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

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

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

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

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

Слова "хранилище данных" (DW) впервые были запущены в литературу в 1988 году Биллом Инмоном. Первоначально под ними разумелось вот что.

"Хранилище данных -- это набор данных, созданный для поддержки принятия решений управляющим персоналом, и обладающий следующими свойствами:

Данные, попав на склад, продолжают "жить" следующим образом:

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

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

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

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

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

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

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

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

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

Нам поможет доктор?

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

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

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

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

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

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

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

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


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



Hosted by uCoz