Многочисленные Хранилища данных в одной компании

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

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

Архитектурный грех?

Поскольку практика создания многочисленных Хранилищ данных набирает обороты, администраторам Хранилищ часто приходится отвечать на целый ряд вопросов, а именно: не является ли построение нескольких Хранилищ данных своеобразным архитектурным грехом? Как данная тенденция соотносится с понятием надежной архитектуры системы поддержки принятия решения (Decision Support System, DSS)? Не возникнет ли ситуации, когда слишком хорошо уже нехорошо?

Многочисленные Хранилища данных

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

• Хранилище данных, детализированное на уровне исходных систем, в котором собраны и интегрированы структурированные атомарные данные (granular atomic data). Этот тип Хранилища служит основным источником данных, такое Хранилище является общим для многих подразделений корпорации и часто содержит огромное количество данных. Текущий уровень хранит детальную историю за два года.
• Витрины данных, в которых различные отделы собирают данные для своих частных целей. Витрины данных обычно содержат как итоговые (summarized), так и заказные (customized) данные, которые отражают индивидуальные пристрастия и потребности вышестоящие отделов, таких как финансовый, маркетинговый отделы, отдел продаж и так далее.

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

Многочисленные Хранилища детальных данных

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

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

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

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

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

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

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

Многочисленные аппаратные средства и платформы программного обеспечения

Еще один важный вопрос, связанный с обсуждаемой темой, состоит в том, возможна ли совместимость платформ аппаратных средств и систем управления базами данных (DBMS) среди многих Хранилищ данных корпорации. Разумеется, что для витрин данных и Хранилища детальных данных речь идет о различных платформах и системах управления базами данных. Некоторые технологии оптимальны для управления крупными объемами детальных данных, другие же - для обслуживания чрезвычайно изменчивых потребностей отдела. По причине высокой специализации различных платформ и технологии DBMS очевидно, что среди этих витрин и Хранилища данных будут распространены многочисленные платформы и системы управления базами данных.

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

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

Просто витрины данных

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

• Высокая избыточность данных от одной витрины данных к другой. Каждая витрина данных собирает свои собственные детализированные данные из среды устаревших приложений. В результате, одни и те же данные собираются несколько раз.
• Отсутствие основы для интеграции. Каждая витрина данных создает свою собственную отдельную интерпретацию данных, и отсутствуют основания для перехода к интерпретации и согласованию.
• Интерфейсы между витринами данных и устаревшими приложениями становятся запутанными, поскольку между каждой витриной и приложением будет свой уникальный набор интерфейсов. Если имеется m приложений и n витрин данных, потребуется n x m интерфейсов. Если же витрины построены на основании Хранилища данных (например, Хранилища детальных данных), потребуется m + n таких интерфейсов. Только одного вопроса об управлении интерфейсами уже достаточно для того, чтобы убедиться в необходимости создания витрин данных на Хранилище данных.

Заключение

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

Автор: Уильям Инмон (William Inmon)