Студопедия  
Главная страница | Контакты | Случайная страница

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

Хранилища данных с архитектурой шины данных

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

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

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

ХД с архитектурой шины данных состоит из набора взаимосвязанных киосков данных, которые созданы для обслуживания бизнес-процессов организации (См. рис. 2.11).


увеличить изображение
Рис. 2.11. Хранилище данных с архитектурой шины данных

Суммируя все вышесказанное, можно отметить типичные характеристики ХД с архитектурой шины данных.

  1. Использование многомерной модели организации данных с архитектурой "звезда" (star scheme).
  2. Использование двухуровневой архитектуры, которая включает стадию подготовки данных, недоступную для конечных пользователей, и собственно ХД с архитектурой шины. В состав последнего входят несколько киосков атомарных данных, несколько киосков агрегированных данных и персональный киоск данных, но оно не содержит одного физически целостного или централизованного ХД.
  3. ХД не является единым физическим репозиторием (в отличие от CIF). Это "виртуальное" ХД, представляющее коллекцию витрин данных, каждая из которых имеет архитектуру типа "звезда".

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

Обе эти архитектуры отличаются в основном способами представления данных. В CIF, они, как правило, нормализованы, а в ХД с архитектурой шины данных — нет.

 

14)

Алгоритм построения модели "Свод данных" (Data Vault)

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

  1. Сущности-концентраторы, которые должны содержать бизнес-ключи предметной области.
  2. Сущности-связи для поддержки взаимосвязей между бизнес-ключами, т. е. информация о деятельности организации в контексте бизнес-ключей.
  3. Сущности-сателлиты для описания полной картины деятельности организации с точки зрения бизнес-процедур.
  4. Сущности "Момент времени" для обеспечения поиска моментов времени изменения описательной информации.

При создании связей в структуре модели "Свод данных" следует соблюдать правила поддержки ссылочной целостности (referential integrity).

  1. Ключи концентраторов не могут мигрировать в другие концентраторы, т.е. не поддерживается отношение "родитель-потомок" для концентраторов.
  2. Концентраторы взаимодействуют между собой через сущности-связи.
  3. Сущность-связь может быть использована для связи более двух концентраторов.
  4. Сущности-связи могут быть связаны друг с другом.
  5. Сущности-связи должны связывать, по крайней мере, два концентратора.
  6. Суррогатные ключи могут использоваться для концентраторов и связей.
  7. Ключи концентраторов всегда мигрируют.
  8. Бизнес-ключи концентраторов никогда не изменяются, так же, как и их первичные ключи.
  9. Сателлиты могут связываться с концентраторами и сущностями-связями.
  10. Могут быть использованы стандартные таблицы временных меток (standalone table), такие как календарь, время, код и описание.
  11. Сателлиты всегда содержат либо временную метку загрузки, либо числовой указатель на временную метку загрузки (на стандартные таблицы временных меток)
  12. Сущности-связи могут иметь суррогатные ключи.
  13. Если концентратор имеет более двух сателлитов, то может быть создана сущность "Момент времени".
  14. В сателлитах не должно быть строк-дубликатов.
  15. Данные в сателлитах разделяются по типу информации или по скорости изменения.

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

Загрузка...

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

Теперь рассмотрим применение вышеизложенного алгоритма на учебном примере, т.е. построим модель "Свод данных" для схемы учебного примера.


Дата добавления: 2015-09-12; просмотров: 32 | Нарушение авторских прав

Действие OLAP | Концепция витрин данных | Для быстрой загрузки информации из оперативной базы данных, освобождая его как можно скорее. Все необходимые преобразования могут происходить без вмешательства в работу. | Использование | ПОДХОД СНИЗУ ВВЕРХ | Пользовательские иерархии | Неоднородные иерархии | Определение гранулярности данных таблиц фактов | Архитектура подсистемы ETL | Процессы извлечения данных |


lektsii.net - Лекции.Нет - 2014-2019 год. (0.009 сек.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав