Факт / Тусклое время таблицы - PullRequest
1 голос
/ 07 января 2009

Я настраиваю таблицы Fact и Dim и пытаюсь найти наилучший способ настройки значений времени. AdventureworksDW использует временной ключ (UID) для каждой временной записи в таблице DimTime. Мне интересно, есть ли какая-то причина, по которой я не должен просто использовать вместо этого значение времени, то есть 0106090800 (моя детализация почасовая)?

Ответы [ 3 ]

3 голосов
/ 07 января 2009

«Интеллектуальные ключи» (в данном случае кодированная дата и номер часа) могут привести к проблемам, когда вы захотите изменить определения в своем измерении. Например, ваши пользователи могут настаивать на переходе с местного времени на UTC. Теперь ваш ключ больше не является полезным числом, это старое значение в измерении.

Кроме того, при проблеме переноса в полночь часть даты вашего интеллектуального ключа может не совпадать с фактической датой UTC относительно изменения местного времени.

Чтобы ключ не стал проблемой, его нельзя использовать для каких-либо расчетов. В этом случае это немного лучше, чем простой GUID или число с автоинкрементом.

Клавиши автоинкремента (или GUIDS) быстрые и простые. Самое главное, они тривиально согласованы во всех измерениях.

Время имеет числовое отображение, но это помогает понять, что это странное совпадение, а не основа для хорошего дизайна.

1 голос
/ 07 января 2009

Вот Ральф Кимбалл последний по измерению времени. Он датирован 2004 годом, но все еще хорош.

Этот тоже поможет.

0 голосов
/ 29 ноября 2009

Первичный ключ должен быть суррогатным, бессмысленным - однако использовать ГГГГММДД для ключа измерения даты трудно, а также легко разделять таблицы. Хитрость в том, что это все равно следует считать бессмысленным - тот факт, что это выглядит как дата, следует рассматривать как чисто случайное событие. Этот ключ никогда не должен передаваться бизнес-пользователям.

...