2.4 Запросы к Спутнику при несогласованных данных

Как упоминалось ранее, может возникнуть необходимость искать более «ранние» данные, чем существуют. И в некоторых случаях, может не оказаться никаких соответствующих данных в Спутнике. В этом случае предложенные нами ранее запросы не возвращают данные. Один из самых быстрых способов решения этой проблемы является изменение запроса включением внешнего соединения (outside join). Это не всегда лучшая альтернатива; здесь мы дадим введение о вариантах размещения данных, а подробное обсуждение будет позже в другом документе.

Предположим, у нас есть то, что показано на Рисунке 2-1, и мы хотим получить данные по состоянию на 10-05-2000. Первоначальный запрос выглядел следующим образом:

Select * from HUB_CUST, SAT_CUST_NAME scst Where hub_cust.CSID = scst.CSID And scst.load_dts <= (select max(z.LOAD_DTS) from SAT_CUST_NAME z where scst.CSID = z.CSID and z.LOAD_DTS <= ’12-1-2000 23:59:59’)

Новый запрос выглядит вот так:

-- NEW QUERY Select * from HUB_CUST, SAT_CUST_NAME scst Where hub_cust.CSID *= scst.CSID And scst.load_dts =* (select max(z.LOAD_DTS) from SAT_CUST_NAME z where z.CSID = hub_cust.CSID and z.LOAD_DTS <= ’10-05-2000 23:59:59’)

Это позволит выбрать все строки Хаба независимо от того, имеют ли они соответствие в Спутниках. Если строки Спутника не будут соответствовать ограничению даты, запрос вернет NULL для этих ключей Хаба. Одна из проблем в этом запросе – высокая стоимость подзапроса, выбирающего максимальную дату. При использовании PIT-таблицы с историей, запрос будет выглядеть следующим образом:

select * from HUB_CUST a, SAT_CUST_PIT b, SAT_CUST_NAME c, SAT_CUST_ADDR d where a.CSID = b.CSID and a.CSID *= c.CSID and a.CSID *= d.CSID and b.LOAD_DTS = (select max(z.LOAD_DTS) from SAT_CUST_PIT z where a.CSID = z.CSID and z.LOAD_DTS <= '10-11-2000') and c.LOAD_DTS =* b.NAME_LOAD_DTS and d.LOAD_DTS =* b.ADDR_LOAD_DTS

Если вы хотите получить все строки истории за все время, подзапрос, возвращающий значение для b.LOAD_DTS, удаляется из запроса. Одно условие заключается в том, что PIT-таблица должна содержать все идентификаторы клиента, которые существуют в Хабе. Условие внешнего соединения (outside join condition) позволяет нам выполнить запрос без необходимости существования строк в Спутнике для каждого ключа. Это быстрое решение, и работает очень хорошо, даже в условиях нагрузки.

Обратите внимание, что во всех ситуациях использовалась не «легкая» для конечных пользователей логика. Поэтому мы рекомендуем, чтобы Data Vault использовалось только как хранилище данных – без доступа пользователей, за исключением, возможно, особо технически грамотных пользователей.

3.0 Заключение

Различные стили моделирования конечных дат предоставляют архитектуре гибкость в парадигме запросов и производительности. Гибридный подход вобрал лучшее из обоих миров, позволяя как исторический, так и неисторический захват данных в PIT таблицу. Работа с соединениями важна, в плане наблюдения за задаваемыми условиями и существованием или отсутствием данных в Спутниках. Это важно для выбора соответствующего стиля моделирования конечных дат и поддержки выбранного стиля, в качестве стандарта, при создании Data Vault в организации. Как только стандарт установлен, тогда архитектура становится универсальной – для выполнения доступа, запросов, загрузки, удаление, и обновление.

Как отмечалось выше, создавайте сложные запросы с помощь представлений (view). Если это необходимо, используйте вложенные представления. Стройте представления на основе Хабов и соответствующих им Спутников, Ссылок и их Спутников. Это позволит свести доступ к минимуму и наладить стандарты. Разграничьте доступы к текущей информации и к исторической, чтобы запросы были как можно быстрее. Когда возможно используйте значения NULL в ваших полях с датами – это поможет сохранить истинную природу данных. В следующей статье мы углубимся в таблицы Связей, их объединение и их Спутники.