Архитектура баз данных для хранилищ. Витрины данных.
На сегодняшний день предложено множество архитектур, опишу пять наиболее распространенных: 1. независимые витрины данных (independent data marts); 2. шина взаимосвязанных витрин данных(data-mart bus architecture with linked dimensional data marts); 3. архитектура «звезда» (hub-and-spoke); 4. централизованное хранилище данных (centralized data warehouse); 5. федеративная архитектура (federated architecture).
Независимые витрины данных
Нередка ситуация, когда каждое подразделение компании разрабатывает свою собственную витрину данных. Все эти витрины удовлетворяют потребностям, для которых создавались, но при этом не зависят друг от друга и не обеспечивают единого представления о ситуации в компании. В них несогласованно заданы данные, используются разные измерения и показатели, а следовательно, анализ данных между витринами затруднен.
Шина взаимосвязанных витрин данных
Создание такой архитектуры начинается с анализа требований для конкретных бизнес-процессов, таких как заказы, клиенты, счета и проч. Первая витрина данных строится для одного бизнес-процесса с использованием измерений и показателей, которые в дальнейшем будут применяться в других компонентах. Последующие витрины данных разрабатываются с использованием этих измерений, что в результате приводит к созданию логически интегрированных витрин.
Архитектура «Звезда»
Продвигается известным экспертом в области хранилищ данных Билом Инмоном (Bill Inmon). Представляет собой централизованное хранилище данных с зависимыми витринами данных. Эта архитектура разрабатывается на основе корпоративного анализа требований к данным. Тут важно обратить внимание на создание масштабируемой и поддерживаемой инфраструктуры. На основе использования корпоративного представления данных выполняется итеративная разработка архитектуры, при этом вовлекается одна предметная область за другой. Детальные данные хранятся в нормализованной форме в хранилище данных. Зависимые витрины данных получают данные из хранилища данных. Зависимые витрины данных разрабатываются для подразделений или конкретных функциональных областей, целей (например, для data mining) и могут быть как нормализованными, так и денормализованными, либо в виде любой агрегированной структуры данных. Большинство пользователей выполняет запросы на зависимых витринах данных. Иногда архитектуру hub-and-spoke называют подходом «сверху вниз», а шину витрин данных - подходом «снизу вверх». В этом есть некоторый смысл, так как первая ориентирована на исходно заданную инфраструктуру и процессы, а шина витрин данных - на разработку проекта, в котором решаются критические бизнес-задачи. Подходы «снизу вверх» и «сверху вниз» со временем сближаются. Сторонники первого из них утверждают важность поэтапной разработки и достижения «маленьких побед». Приверженцы второй методологии считают важным наличие корпоративного плана для интеграции поэтапно создаваемых витрин данных.
Централизованное хранилище данных (без зависимых витрин)
Эта архитектура похожа на архитектуру «звезда» за исключением отсутствия зависимых витрин данных. Хранилище данных содержит детальные данные, некоторое количество агрегированных данных и логические представления. Запросы и приложения выполняются как на реляционных данных, так и на многомерных представлениях.
Федеративная архитектура
В этой архитектуре используются уже существующие структуры поддержки принятия решений (операционные системы, витрины и хранилища данных). Данные извлекаются из перечисленных систем на основе бизнес-требований. Данные логически или физически интегрируются с помощью метаданных, распределенных запросов и других методов. Эта архитектура является практическим решением для компаний, которые уже пользуются аналитическими средствами и не хотят от них отказываться. У каждой из вышеописанных архитектур есть ряд активных сторонников, и выбор в каждом конкретном случае - непростая задача, грамотное решение которой становится ключевым фактором успеха проекта. Согласно исследованиям, существует несколько основных факторов, влияющих на выбор архитектуры.
Рациональные факторы
Информационная зависимость между организационными подразделениями Высокий уровень информационной зависимости возникает в тех организациях, где одно подразделение зависит от сведений, поступающих из другого. В этой ситуации возможность совместного использования и интеграции информации очень важна. Информационные потребности руководства
Высшему руководству часто требуется информация о более низких организационных уровнях. Иногда возникает потребность углубиться в детальные данные и разобраться в деятельности конкретного подразделения либо убедиться, что компания выполняет необходимые нормативные требования. Срочность внедрения хранилища данных
Иногда компании необходимо реализовать возможности хранилища данных в очень краткие сроки. Некоторые виды архитектур внедряются быстрее других. Характер пользовательских задач
Ряд пользователей выполняет сложные и нестандартные задачи. Для реализации их потребностей недостаточно структурированных запросов и отчетов. Им необходимо анализировать данные новыми способами, а следовательно, иметь в распоряжении такую архитектуру, которая позволит анализировать данные «на лету», нетривиальными методами.
Ограниченные ресурсы
Некоторые виды хранилищ данных требуют больше ресурсов, чем другие. В результате на выборе архитектуры может отразиться доступность IT-персонала, бизнес-сотрудников и материальных средств. Стратегическое представление хранилища данных до внедрения Разные компании имеют разные планы применения хранилища данных. Иногда необходимо «точечное решение» для конкретного подразделения, а иногда - инфраструктура поддержки принятия решений, содержащая множество приложений. В зависимости от стратегического назначения хранилища данных меняется и его архитектура. Совместимость с существующими системами
Для некоторых компаний очень важно внедрить решение, совместимое с
уже имеющимся программным обеспечением. Возможности персонала
Внедрение некоторых архитектур считается более сложным в зависимости от навыков и опыта технического персонала, наличия положительного опыта в аналогичных проектах и от уровня конфиденциальности.
Технические факторы
На выбор архитектуры влияет множество технических соображений. Это и возможность интеграции метаданных, и масштабируемость пользователей, и объемы данных, и эффективность запросов, и возможность поддержки исторических данных и адаптации к изменениям (например, в исходных системах). В зависимости от важности этих технических вопросов делается выбор в пользу той или иной архитектуры.
Социальные факторы
Один из социальных факторов - влияние экспертов. Принятие решения - это процесс переговоров, создания коалиций, где играет роль множество амбициозных целей. Нельзя сказать, что у каждой компании есть одна единая задача, которая влияет на выбор архитектуры. Для оптимизации и баланса целей, а следовательно, и для выбора архитектуры необходимо прибегать к помощи экспертов. Иногда в роли экспертов выступают консультанты, иногда собственные пользователи. В некоторых случаях информация черпается на семинарах, конференциях и прочих мероприятиях. Каждый из этих факторов в некоторой степени влияет на выбор архитектуры. Очень часто это субъективное влияние, связанное с личным успешным опытом специалиста. В результате исследований и опросов, было выяснено, что все вышеперечисленные факторы (относящиеся к каждой из трех групп) имеют свое значение. Самые важные факторы - взаимозависимость между организационными подразделениями, стратегическое представление о хранилище данных до его внедрения и информационные потребности высшего руководства. Возможности технического персонала - на последнем месте, однако они имеют определенный вес и играют далеко не самую малую роль.