Каков наилучший способ хранения медленно меняющихся атрибутов в хранилище данных?

Question

В классическом реляционном хранилище данных медленно меняющиеся атрибуты (редко изменяющиеся атрибуты) хранятся в таблице со схемой, подобной следующей:

EntityKey, StartDate, EndDate, Attribute1, Attribute2, Attribute3 ...

(Это может быть в отличие от быстро меняющихся атрибутов, которые могут храниться как:
EntityKey, отметка времени, атрибут1, атрибут2, атрибут3 ... )

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

Конечно, вы можете создать одну такую ​​таблицу для каждого временного интервала (таблицу для еженедельных атрибутов, одну для ежемесячных, одну для годовых и т. Д.), Но в реальном мире различные атрибуты будут меняться в разные моменты времени, а не обязательно по любой схеме. Также для некоторых объектов один и тот же атрибут может меняться чаще, чем для других.

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

Answer 1

Что мне не нравится в этом подходе, так это много повторяющейся информации.

В этом смысл склада. Повторите информацию, чтобы представить (а) исторические факты по мере их возникновения и (б) уменьшить количество объединений.

Если Атрибут1 изменяется один раз в неделю, а Атрибут2 - только один раз в год, вы заканчиваете тем, что повторяете Атрибут2 каждую неделю с избыточностью. Если у вас много атрибутов, которые можно сложить.

Неправильно. Это не складывается очень быстро.

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

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