Факт / Тусклое время таблицы

Question

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

Answer 1

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

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

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

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

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

Answer 2

Вот последняя информация о времени . Он датирован 2004 годом, но все еще хорош.

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

Answer 3

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