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-таблице.