У меня есть две таблицы для измерения времени
дата (уникальная строка для каждого дня)
время дня (уникальная строка для каждой минуты в день)
Учитывая эту схему, как будет выглядеть запрос, если кто-то хочет получить факты за последние X часов, где X может быть любым числом больше 0.
Все начинает усложняться, когда время начала и время окончания приходится на два разных дня в году.
РЕДАКТИРОВАТЬ: в моей таблице фактов нет столбца с отметкой времени
Таблицы фактов имеют (и должны иметь) исходную метку времени, чтобы избежать странных запросов по времени, которые происходят за границей дня. Странный означает наличие сложной функции даты и времени в предложении WHERE.
В большинстве хранилищ данных запросы такого типа встречаются очень редко, но кажется, что вы одновременно передаете данные в свой хранилище данных и используете их для отчетов.
Поэтому я бы посоветовал:
Добавьте полную метку времени в таблицу фактов.
Для старых записей воссоздайте метку времени с помощью ключей даты и времени.
Все запросы DW связаны с отсутствием каких-либо функций в предложении WHERE, или, если функция должна использоваться, убедитесь, что это SARGABLE.
Вам, вероятно, будет лучше преобразовать столбцы 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))
Мне кажется, что с учетом текущей схемы, которая у вас есть, вам нужно будет получить соответствующие идентификаторы времени из таблицы измерения времени, которые соответствуют вашим критериям поиска, а затем выполнить поиск совпадающих строк в таблице фактов. В зависимости от степени детализации вашего измерения времени вы можете проверить производительность одного из них (примеры SQL Server):
Подвыбор:
ВЫБЕРИТЕ X ИЗ FOO, ГДЕ TIMEID IN (ВЫБЕРИТЕ ID ИЗ DIMTIME, ГДЕ ЧАС> = DATEPART (HOUR, CURRENT_TIMESTAMP ()) И DATEID IN (ВЫБЕРИТЕ ID ИЗ DIMDATE, WHERE DATE = GETDATE ())
Внутреннее соединение:
ВЫБРАТЬ X ИЗ FOO INNER JOIN DIMTIME ON TIMEID = DIMTIME.ID WHERE HOUR> = DATEPART (HOUR, CURRENT_TIMESTAMP ()) INNER JOIN DIMDATE ON DATEID = DIMDATE.ID WHERE DATE = GETDATE ()
Ни один из этих вариантов не является действительно привлекательным.
Задумывались ли вы, что вы можете запрашивать куб, который предназначен для сводного анализа, а не обязательно для анализа «последнего X»?
Если это не "свертываемый" куб, я бы согласился с другими плакатами в том, что вам следует повторно штамповать свои таблицы фактов с более качественными ключами, и если вы действительно собираетесь часто искать в нерабочее время, вам, вероятно, следует включите это в таблицу фактов, поскольку любая другая попытка, вероятно, сделает запрос несаргируемым (см. Что делает оператор SQL доступным для рассылки?).
Microsoft рекомендует на странице http://msdn.microsoft.com/en-us/library/aa902672%28v=sql.80%29.aspx, что:
В отличие от суррогатных ключей, используемых в других таблицах измерений, ключи измерений даты и времени должны быть «умными». Предлагаемый ключ для измерения даты имеет форму «ггггммдд». Этот формат легко запомнить и использовать в запросах. Это также рекомендуемый формат суррогатного ключа для таблиц фактов, которые разбиты на несколько таблиц по дате.
Удачи!
