Читайте также:
|
|
3NF и схема Звезда, когда они используются для хранилищ данных предприятия, могут причинять бизнесу боль, потому что они не были изначально предназначены для целей хранилищ. Есть проблемы, связанные с масштабируемостью, гибкостью и степенью детализации данных, интеграцией и объемом. Объем информации, которую хранилища обязаны хранить сегодня, увеличивается по экспоненте каждый год. Приложения CRM, SCM, ERP и все другие большие системы приводят к увеличению объемов информации в хранилищах. Существующие модели данных, основанные на 3NF или схеме Звезда, оказывается, трудно изменять, поддерживать и анализировать, не говоря уже о резервном копировании и восстановлении.
В ранее приведенном примере мы реализовали хранилище Data Vault, состоящее из единственного Хаба и нескольких Спутников и ограниченное рамками хранения истории о транспортных средствах и соответствующих им атрибутах. Если год спустя бизнес захочет видеть в хранилище контракты по этим транспортным средствам, то необходимые Хабы и Связи могут быть легко добавлены. Не беспокойтесь о степени детализации. Этот тип модели расширяем верх и вширь (реализация «снизу вверх», проектирование «сверху вниз»). Конечный результат всегда строго фундаментирован и может создаваться итерационным подходом к разработке.
Другой пример – сильные возможности сущности Связь. Предположим, что сегодня компания, продающая продукцию, имеет Хаб Продукты, Хаб Счет и Связь между ними. Затем компания решает продавать услуги. Модель данных позволяет ввести новый Хаб Услуги, заполнить дату окончания в продуктовые Связи и начать новую Связь между услугами и счетами. Никакие данные не потеряны, и все данные, накопленные в течение долгого времени сохранены и отражают изменения бизнеса. Это лишь одна из многочисленных возможностей для обработки подобной ситуации.
Большой объем данных приводит к проблемам с запросами, особенно это касается схем Звезда, но в меньшей степени и 3NF. Нарушается производительность запросов при больших объемах информации в согласованных измерениях и согласованных таблицах фактов. Часто требуется делать партиционирование и непрерывно переделывать структуры, чтобы предоставить дополнительную степень детализации бизнес пользователям. Это обеспечивает кошмар обслуживания и управления. Перезагрузка постоянно меняющихся звезд является трудной задачей – не говоря уже о попытке выполнить это с большим объемом данных (свыше 1 Терабайт, например). Data Vault уходит корнями в математические основы нормализованной модели данных. Сокращения избыточности и учет темпов изменения наборов данных способствует повышению производительности и простоте в управлении. Архитектура Data Vault не ограничивается применением какой-либо одной платформы. Архитектура так же позволяет использовать распределенный взаимосвязанный набор информации.
Хранилищам данных часто приходится дело с утверждением: «То, что я (пользователь) дам Вам – это никогда не приходит из исходных систем». И они предоставляют крупноформатную таблицу со своей ежедневно поддерживаемой интерпретацией информации. Другими словами: «Я (заказчик) хочу видеть все номера VIN, которые начинаются с "X", сгруппированными под названием "BIG TRUCKS" ("БОЛЬШИЕ ГРУЗОВИКИ")». В Data Vault предусмотрена такая возможность с помощью Набора Пользовательских Группировок (User Grouping Set). Это еще один Хаб (с названием Big Trucks) со Спутником, описывающим номера VIN, группируемые под этим лейблом, и Связь с номерами VIN. Таким образом, сохранены оригинальные данные из исходной системы, в то же время можно получить информацию в манере, соответствующей пользовательским потребностям. Когда все будет сказано и сделано, хранилище данных является успешным, так как оно отвечает потребностям пользователей.
Дата добавления: 2014-12-15; просмотров: 19 | Поможем написать вашу работу | Нарушение авторских прав |