Распространенные заблуждения о хранилищах данных

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

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

В своей статье "Каким не бывает Хранилище"¹ , вышедшей в 2001 году, Уильям Инмон, родоначальник ХД, показывает различные ложные представления, связанные с самим термином "Хранилище данных", и факторы, влияющие на его интерпретации. Инмон рассказывает о заблуждениях, высказываемых как энтузиастами ХД, так и теми, кто хочет сделать "быстрые продажи" на этом классе программного обеспечения. "Воодушевление, вызванное появлением Хранилища так велико" - пишет он - "что этим именем называют вещи, которые никогда не были и не будут Хранилищем". С другой стороны, некоторые поставщики серверов высказывают заблуждение, что Хранилище - это просто собранные вместе данные, был бы только большой компьютер. В то же время поставщики Витрин данных² считают, что последние могут вырасти, объединиться и стать в результате ХД.

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

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

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

Авторы статьи рассказывают о заблуждениях, с которыми часто сталкиваются сотрудники Intersoft Lab, чтобы помочь читателям принять правильное решение при выборе ХД для своих организаций.

Хранилище данных - это большая база данных

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

Кроме базы данных Хранилище включает в себя сложную инфраструктуру:

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

Данные Хранилища не изменяемы

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

Опыт, приобретенный Intersoft Lab, и требования, поставленные организациями-клиентами, показывают, что нужны инструменты для изменения данных, загруженных в ХД. Всегда есть необходимость исправлять ошибочно загруженные данные, для исключения возможности выпуска неверных отчетов; выполнять ручной ввод данных, несуществующих в учетных системах; иметь возможность для ввода дополнительных аналитических признаков.

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

Структура Хранилища строится только в виде схемы "звезда" или "снежинка"

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

Это заблуждение может привести к созданию недостаточно информативных ХД или ХД, искажающих экономический смысл данных.

Специалистами Intersoft Lab для построения ХД используется более сложная модель, нежели "Снежинка", позволяющая получать глубокую детализацию показателей вплоть до проводок.

Редакторы ER-диаграмм являются пользовательскими средствами расширения Хранилища данных

В результате использования редактора ER-диаграмм программистом организации в качестве пользовательского средства расширения функциональности ХД будет создана принципиально НОВАЯ СИСТЕМА. При этом программистам потребуется дополнительно выполнить весь комплекс работ, характерных для разработки нового программного продукта от проектирования и перепрограммирования пользовательских интерфейсов до разработки новых процедур загрузки/выгрузки данных и модифицирования отчетов.

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

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

Для решения этой проблемы в составе ХД специалисты компании Intersoft Lab разработали технологию настройки ХД на уровне прикладных объектов. В результате расширять и развивать модель ХД могут его конечные пользователи, оперируя привычными им терминами прикладной области (счета, показатели, контрагенты и т.д.).

Сбор данных возможно настроить при помощи ETL-инструмента без программирования

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

Многие учетные системы (для банков - АБС, для предприятий - системы бухгалтерского учета) предоставляют единственное средство доступа к данным для внешних систем - встроенный язык программирования. К примеру, прямой доступ к базе данных не возможен, затруднен или не рекомендуется поставщиком в таких популярных системах, как 1С, SAP R3, RS-B, Diasoft 4ґ4. Поэтому в реальности наиболее экономичным способом сбора данных из разнородных источников является стандартизация форматов обмена данными и разработка процедуры выгрузки на языке исходной системы.

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

Специалисты Intersoft Lab разработали универсальный механизм обмена данными с внешними системами в виде XML-файлов (дополнительно поддерживается обмен файлами в CSV-формате). Необходимо только разработать процедуру выгрузки данных с помощью встроенного языка исходной OLTP-системы, который уже знаком программистам организации, в XML-формат, а процедуры загрузки универсальны и полностью готовы к эксплуатации.

В качестве интерфейса к Хранилищу данных достаточно одного OLAP-клиента

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

Поэтому ХД данных наряду с OLAP-инструментом должно предоставлять пользовательские генераторы жестких отчетов и среду программирования сложных отчетных форм.

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

В Хранилище данных нужно собирать отчеты

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

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

АБС можно использовать в качестве Хранилища данных

Использовать АБС для реализации функций ХД неэффективно.

Во-первых, инструмент АБС не предназначен для создания ХД. Даже, несмотря на то, что многие АБС имеют встроенные языки программирования и инструменты расширения состава атрибутов объектов, неизбежно получится неэффективная база данных с точки зрения анализа данных и получения управленческих отчетов.

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

Внедрение Хранилище данных - это дело автоматизаторов

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

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

Внедрение Хранилище данных - это дело аналитиков

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

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

Хранилище нельзя купить, его можно только создать

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

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

Создание Хранилища занимает минимум два года

Зачастую, основным фактором при принятии решения о создании ХД являются сроки его внедрения. Миф о длительности создания ХД приводит к тому, что многие отказываются от этой идеи и используют устаревшие технологии, а, как следствие, проигрывают в конкуренции с другими организациями.

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

Приведем пример ввода в эксплуатацию системы "Контур Корпорация" в АКИБ "УкрСиббанк" города Киева, который на сентябрь 2002 года имел 17 филиалов, куда входили 112 торговых точек в 37 городах Украины. Необходимо было построить на базе ХД системы "Контур Корпорация" систему управленческой отчетности банка. Установка системы была выполнена за 2.5 месяца силами сотрудников банка практически без присутствия специалистов компании.

И это не единственный случай быстрого создания ХД. Еще одним примеров внедрения системы "Контур Стандарт" является установка системы на предприятии "Мострансгаз". В течение месяца силами специалистов Intersoft Lab , "Мострансгаза" и аудиторской компании "ФБК" на базе "Контур Корпорация" была создана система сбора синтетических и аналитических налоговых регистров со всех филиалов компании в ХД, расчета сводных регистров, контроля данных и выпуска консолидированной отчетности по налогу на прибыль.

Как показывает практика создания ХД различными компаниями-разработчиками, многие первоначальные принципы построения ХД оказались несостоятельными. В том числе опыт Intersoft Lab показал, что те постулаты, которые на заре возникновения ХД выглядели неоспоримыми, в реальной жизни оказались просто заблуждениями.

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

Автор: В.Некрасов, О.Кононова

Источник: RM-Magazin, 2003, № 5