2.2 Дата начала и Дата окончания
Если приведенный выше стиль не соответствует требованиям хранилища, то этот стиль может соответствовать парадигме немного лучше. В этом случае, нет места PIT таблицам и нет дополнительной работы в запросах. Иногда команда внедрения может взяться за разработку более сложных процессов загрузки. Когда эта происходит, то этот второй стиль лучше подходит для проекта. Кто интересовался Активным Хранилищем Данных (Active Data Warehousing) или Хранилищем Реального Времени (Real Time Data Warehousing), тот мог слышать эти слова: «Дата Начала Наблюдения» (Observation Start Date), «Дата Окончания Наблюдения» (Observation End Date). В данной статье мы полагаем, что эти, только что названные, термины эквивалентны «Дате Начала Загрузки» (Load Start Date) и «Дате Окончания Загрузки» (Load End Date).
Что представляет собой этот архитектурный тип?
Рисунок 2-3. Customer Hub, Name Satellite и таблица Address Satellite с датами окончания (Примечание: Поле «Record Source» не показано в Спутниках из-за экономии места. Имеем в виду, что оно должно присутствовать)
В данном примере представлены поля LOAD_DTS – «Дата Начала Загрузки» и LOAD_END_DTS – «Дата Окончания Загрузки». При выборе этого стиля, поле, содержащее дату окончания, не заполняется, пока не поступит следующее изменение. Это позволяет запросу вывести информацию, актуальную на определенную дату. Загрузка становится более сложной, так как при вставке новой записи нужно обновить значение даты окончания в предыдущей строке. Записи могут быть датированы будущим числом, если это предпочитаемая практика, хотя автор не рекомендует этого.
Что представляют собой запросы?
Select hub.cust_num, sat_1.name, sat_2.address from HUB_CUST hub, SAT_CUST_NAME sat_1, SAT_CUST_ADDR sat_2 where hub.CSID = sat_1.CSID and hub.CSID = sat_2.CSID and ‘12-1-2000 23:59:59’ between sat_1.LOAD_DTS and sat_1.LOAD_END_DTS and ‘12-1-2000 23:59:59’ between sat_2.LOAD_DTS and sat_2.LOAD_END_DTS
Запрос значительно упрощен. Но есть две проблемы, связанные с этим запросом:
1. Не обрабатывается значение NULL в поле LOAD_END_DATES
2. Не обрабатываются отсутствующие записи спутника до переданной в запрос даты.
Мы обсудим эти проблемы и их решения далее.
Заметьте, что запрос быстр, эффективен и основан на первичном ключе – всегда существует индекс по первичному ключу. Это происходит потому, что каждый первичный ключ Спутника создан на основе полей CSID и load_date. Оба этих поля эффективно используются в условиях на точное соответствие выражения «Where». Поскольку дата – константа – она может быть подобрана непосредственно по ключевым полям.
Что это означает для стратегии индексирования?
Стратегии индексации будет обсуждаться позже в другом документе. Однако основная идея заключается в том, чтобы иметь два индекса: первичный ключ и вторичный индекс по полю load_end_date (конечно, в том же порядке, что и у первичного индекса). Повторяясь, стратегии индексации будут рассматриваться в ближайшем будущем.
В целом, такой подход делает запросы проще и потенциально быстрее, однако, может осложнить цикл загрузки. Автор склоняется к следующему и заключительному подходу (стилю), который может использоваться при наличии требований о режиме близком к реальному времени. В рамках этого документа определение «близко к реальному времени» означает, что задержка в поступления новых данные составляет от 1 до 20 секунд.