Читайте также: |
|
Назначение этого документа – представить и обсудить заявленную на патент технологию под названием Data Vault™ (прим. переводчика: статья была написана в 2001 году, в предоставлении патента было отказано в январе 2005; сейчас архитектура Data Vault – общедоступна – FREE and PUBLIC DOMAIN). Data Vault™ – новый этап эволюции моделирования данных для хранилищ данных масштаба предприятия. Целевая аудитория этой статьи: проектировщики данных, желающие построить модель Data Vault, или специалисты в области хранилищ данных и BI, интересующиеся запросами к Data Vault. Здесь мы сосредотачиваемся исключительно на таблицах Связей и Спутниках, являющихся дочерними таблицами Связей, наряду с некоторыми методами запросов данных из Связей. Мы также обсуждаем проблемы, связанные со степенью детализации таблиц Связи, добавления новые Хабов и их влияния на масштабируемость. В этой статье рассмотрены следующие темы:
· Сущность Связь (Link).
· Спутники для сущности Связь.
· Факты и агрегаты, хранимые в структурах Связей.
· Изменение степени детализации в сущностях Связях.
· Операции соединения (join), использующие сущности Связи.
· Выводы и заключение.
Прочитав это документ, Вы можете узнать:
· Как моделировать различные составные ключи (сущности Связи).
· Как размещать факты в Спутниках.
· Как изменение степени детализации воздействуют на архитектуру.
· Что представляет собой сущность Связь.
· Некоторые из проблем, с которыми сталкиваются сущности Связи
В архитектуре Data Vault составные ключи всегда представляют собой отношения между двумя типами бизнес ключей. Эти ключи «расквартированы» по отдельным Хабам, а для того чтобы представить взаимоотношения между ними, архитектура обеспечивает табличную структуру, реализующую связь «многие ко многим». Помните, все это предназначено для хранилищ данных, а не для нормализованных OLTP систем – поэтому, архитектура была перепроектирована, чтобы удовлетворить эти потребности.
Единственное исключение в этом правиле о составных ключах – дата загрузки, которая используется как часть первичного ключа Спутников для фиксирования времени загрузки. Сущность Время (календарь) стоит особняком в модели Data Vault как один из нескольких типов таблиц, не связанных между собой. Если бы мы должны были связать сущность Время (календарь) с каждым Спутником, то модель была бы слишком сложной для чтения.
Под этим обликом архитектура обеспечивает таблицу «многие ко многим», которая играет важную роль в: гибкости, расширяемости, возможности изменений, и ассоциации между бизнес ключами. Сущность Связь может быть самым мощной сущностью в пределах архитектуры. Конечно, сущность Связь добавляет сложности на уровне движков СУБД, связанные с операциями соединения. Это может вызвать общие проблемы с производительностью хранилища данных – но не из-за архитектуры, а из-за проблем на уровне движка СУБД.
Дата добавления: 2014-12-15; просмотров: 25 | Поможем написать вашу работу | Нарушение авторских прав |