Читайте также:
|
Как упоминалось ранее, может возникнуть необходимость искать более «ранние» данные, чем существуют. И в некоторых случаях, может не оказаться никаких соответствующих данных в Спутнике. В этом случае предложенные нами ранее запросы не возвращают данные. Один из самых быстрых способов решения этой проблемы является изменение запроса включением внешнего соединения (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 использовалось только как хранилище данных – без доступа пользователей, за исключением, возможно, особо технически грамотных пользователей.
Заключение
Различные стили моделирования конечных дат предоставляют архитектуре гибкость в парадигме запросов и производительности. Гибридный подход вобрал лучшее из обоих миров, позволяя как исторический, так и неисторический захват данных в PIT таблицу. Работа с соединениями важна, в плане наблюдения за задаваемыми условиями и существованием или отсутствием данных в Спутниках. Это важно для выбора соответствующего стиля моделирования конечных дат и поддержки выбранного стиля, в качестве стандарта, при создании Data Vault в организации. Как только стандарт установлен, тогда архитектура становится универсальной – для выполнения доступа, запросов, загрузки, удаление, и обновление.
Как отмечалось выше, создавайте сложные запросы с помощь представлений (view). Если это необходимо, используйте вложенные представления. Стройте представления на основе Хабов и соответствующих им Спутников, Ссылок и их Спутников. Это позволит свести доступ к минимуму и наладить стандарты. Разграничьте доступы к текущей информации и к исторической, чтобы запросы были как можно быстрее. Когда возможно используйте значения NULL в ваших полях с датами – это поможет сохранить истинную природу данных. В следующей статье мы углубимся в таблицы Связей, их объединение и их Спутники.
Дата добавления: 2014-12-15; просмотров: 38 | Поможем написать вашу работу | Нарушение авторских прав |