Читайте также:
|
Если приведенный выше стиль не соответствует требованиям хранилища, то этот стиль может соответствовать парадигме немного лучше. В этом случае, нет места 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. 1. Не обрабатывается значение NULL в поле LOAD_END_DATES
2. 2. Не обрабатываются отсутствующие записи спутника до переданной в запрос даты.
Мы обсудим эти проблемы и их решения далее.
Заметьте, что запрос быстр, эффективен и основан на первичном ключе – всегда существует индекс по первичному ключу. Это происходит потому, что каждый первичный ключ Спутника создан на основе полей CSID и load_date. Оба этих поля эффективно используются в условиях на точное соответствие выражения «Where». Поскольку дата – константа – она может быть подобрана непосредственно по ключевым полям.
Что это означает для стратегии индексирования?
Стратегии индексации будет обсуждаться позже в другом документе. Однако основная идея заключается в том, чтобы иметь два индекса: первичный ключ и вторичный индекс по полю load_end_date (конечно, в том же порядке, что и у первичного индекса). Повторяясь, стратегии индексации будут рассматриваться в ближайшем будущем.
В целом, такой подход делает запросы проще и потенциально быстрее, однако, может осложнить цикл загрузки. Автор склоняется к следующему и заключительному подходу (стилю), который может использоваться при наличии требований о режиме близком к реальному времени. В рамках этого документа определение «близко к реальному времени» означает, что задержка в поступления новых данные составляет от 1 до 20 секунд.
2.3 Комбинированный подход: даты окончания вместе с PIT таблицей
Это гибридный подход, применяющий оба предыдущих архитектурных стиля моделирования данных одновременно. Существует одно ухищрение: PIT-таблица не содержит долговременные данные. Иными словами, она становится полностью обновляемым Спутником, который пересоздается при каждой загрузке. Конечно, это один из вариантов. При желании (если позволяют объемы) можно просто обновлять существующие PIT-строки – что было бы приемлемой альтернативой пересоздания (rebuilding) всей таблицы.
По существу PIT-таблица используется для отслеживания только текущих или наиболее свежих (еще с не датированным окончанием) строк в каждом из Спутников. Под этим обликом, вставка новой строки может происходить с пустым значение поля LOAD_END_DATE и обновление наиболее свежей строки может быть довольно быстрым и легким. Это либо запрос, либо проход по всем строкам в PIT-таблице, обновляющий поля LOAD_END_DATE последним значением LOAD_DATE, таким образом, освежающий PIT-таблицу после загрузки.
Функция PIT-таблицы еще не обсуждалась с позиции запросов. Это придает таблице ряд преимуществ: 1) синхронность данных; 2) видимость конечному пользователю специфических «свежих данных» может быть спланированной по времени; 3) изолирует запросы конечных пользователей от данных подвергающихся изменению. Когда использовался исторический способ, PIT-таблица была гораздо полезнее для достижения этих целей. При использовании способа полного обновления (как показано в этом гибридном подходе), новая PIT-таблица должна быть построена с учетом изменений, а затем старая PIT-таблице удаляется. Это сохраняет согласованность данных в хранилище.
Почему предложен гибридный подход?
Использование единственного подхода – зачастую не самый лучший способ сделать образцовую модель для проекта, а то и напротив. В данном случае архитектура показывает свою гибкость. Кроме того, для обладателей достаточного дискового пространства и вычислительных мощностей, это действительно может быть полезным компонентом. На что это похоже?
Рисунок 2-4. Комбинированный подход: Даты окончания и Point-In-Time таблица
Обратите внимание, что поле LOAD_DTS ушло из PIT-таблицы. Это для того, чтобы хранить только наиболее свежую информации в спутнике. Если есть желание хранить историю в PIT-таблице, используя этот гибридный подход, то добавьте поле LOAD_DTS (дата загрузки) обратно в первичный ключ. Запрос, непосредственно выбирающий данные, может здесь измениться, чтобы приспособиться к некоторым ранее упомянутым проблемам (например, запрос более ранней даты или NULL в конечных датах). Также обратите внимание, всегда должна быть запись в PIT-таблице для каждого первичного ключа Хаба, независимо от решения хранить историю в PIT-таблице или нет. Запрос может выглядеть следующим образом:
-- GET MOST RECENT / CURRENT DATA ONLY
Select hub.cust_num, sat_1.name,sat_2.address
from HUB_CUST hub, SAT_CUST_PIT pit,SAT_CUST_NAME sat_1,SAT_CUST_ADDR sat_2
where hub.CSID = sat_1.CSID
and hub.CSID = sat_2.CSID
and pit.NAME_LOAD_DTS = sat_1.LOAD_DTS
and pit.ADDRESS_LOAD_DTS = sat_2.LOAD_DTS
Этот запрос является прямым соединением без каких-либо подзапросов, и всегда выбирает самую последнюю информацию (в соответствии с текущим обновлением PIT-таблицы). Запрос point-in-time (кроме текущего) по-прежнему нуждается либо в подзапросе, либо в выражении «between», или в исторической PIT-таблице.
Дата добавления: 2014-12-15; просмотров: 164 | Поможем написать вашу работу | Нарушение авторских прав |