Запрос данных из хранилища данных, связанных с измерением времени - PullRequest
1 голос
/ 14 августа 2011

У меня есть две таблицы для измерения времени

дата (уникальная строка для каждого дня)
время суток (уникальная строка для каждой минуты дня)

Учитывая эту схему, как будет выглядеть запрос, если кто-то захочет получить факты за последние X часов, где X может быть любым числом больше 0.

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

РЕДАКТИРОВАТЬ: моя таблица фактов не имеет столбец отметки времени

Ответы [ 3 ]

2 голосов
/ 17 августа 2011

Таблицы фактов имеют (и должны иметь) исходную временную метку, чтобы избежать странных временных запросов, которые происходят за границей дня. Странно означает наличие некоторого типа сложной функции даты и времени в предложении WHERE.

В большинстве DW такие запросы очень редки, но вы, похоже, передаете данные в DW и одновременно используете их для отчетов.

Поэтому я бы предложил:

  1. Введите полную временную метку в таблицу фактов.

  2. Для старых записей заново создайте метку времени из ключей даты и времени.

Все запросы DW: не имеют каких-либо функций в предложении WHERE или, если требуется использовать функцию, убедитесь, что это SARGABLE .

0 голосов
/ 02 апреля 2012

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

  1. Подвыбор :

    ВЫБРАТЬ X ИЗ FOO, ГДЕ ВРЕМЯ ВХОДИТ (ВЫБЕРИТЕ ID ИЗ РАЗМЕРА, ГДЕ ЧАС> = DATEPART (ЧАС, CURRENT_TIMESTAMP ()) И DATEID В (ВЫБЕРИТЕ ID ИЗ DIMDATE ГДЕ ДАТА = GETDATE ())

  2. Внутреннее объединение :

    ВЫБЕРИТЕ X ИЗ ФИЛЬМА ВНУТРИ FOO DIMTIME ВРЕМЯ = DIMTIME.ID ГДЕ ЧАС> = DATEPART (HOUR, CURRENT_TIMESTAMP ()) INNER JOIN DIMDATE ON DATEID =DIMDATE.ID WHERE DATE = GETDATE ()

Ни один из этих вариантов не является действительно привлекательным.

Считаете ли вы, что вы можете запрашивать куб, предназначенный дляанализ свертки и не обязательно для анализа «последнего Х»?

Если это не куб свертывания, я согласен с другими постерами в том, что вам следует перепечатывать таблицы фактов с помощьюлучше ключи, и если вы на самом деле намеренычтобы часто выполнять поиск в нерабочее время, вам, вероятно, следует включить это в таблицу фактов, поскольку любая другая попытка, вероятно, сделает запрос неразборчивым (см. Что делает оператор SQL доступным для обработки? ).

Microsoft рекомендует в http://msdn.microsoft.com/en-us/library/aa902672%28v=sql.80%29.aspx что:

В отличие от суррогатных ключей, используемых в других таблицах измерений, ключи измерений даты и времени должны быть «умными». Рекомендуемый ключ дляизмерение даты имеет форму "ггггммдд".Этот формат легко запомнить и включить в запросы.Это также рекомендуемый формат суррогатного ключа для таблиц фактов, которые разбиты на несколько таблиц по дате.

Удачи!

0 голосов
/ 18 августа 2011

Вам, вероятно, будет лучше обслужить преобразование столбцов Start Date и End Date в TIMESTAMP и их заполнение.

Для нарезки таблицы потребуется соответствующий interval BETWEEN Start Date AND End Date. В Oracle interval будет что-то вроде SYSDATE - (4/24) или SYSDATE - NUMTODSINTERVAL(4, 'HOUR')

Это также можно переписать как:

Start Date <= (SYSDATE - (4/24)) AND End Date >= (SYSDATE - (4/24))
...