Главная страница | Контакты | Случайная страница Автомобили Астрономия Биология География Дом и сад Другие языки Другое Информатика История Культура Литература Логика Математика Медицина Металлургия Механика Образование Охрана труда Педагогика Политика Право Психология Религия Риторика Социология Спорт Строительство Технология Туризм Физика Философия Финансы Химия Черчение Экология Экономика Электроника

Дата загрузки и структуры Point-In Time.

Как уже обсуждалось в 1-ой статье серии, первый возможный стиль моделирования дат окончания заключается в том, чтобы поместить поле, содержащее значение даты загрузки, в первичном ключе каждого из Спутников. Поскольку функция Спутника заключается в том, чтобы хранить информацию только об изменении (дельте), то каждая строка действительна до появления следующей строки-дельты. Разница между этими датами двух строк Спутника может быть вычислена и фигурировать в качестве эффективного периода жизни данной информации.

Почему используются «Даты Загрузки»?

Необходимо применять Даты Загрузки (Load Date) или Даты Начала Наблюдения (Observation Start Date), чтобы вся информация, внесенная в хранилище, оставалась согласованной по временной шкале. Без использования даты о появлении информации в хранилище, такие действия, как восстановление, отмена, удаление или сворачивание старых данных, будут трудноосуществимы или невозможны. Это не единственная причина. Запросы конечного пользователя требуют данных, бывших действительными в определенный момент времени. Эта возможность выбирать данные за определенный период должна присутствовать в хранилище.

Что, если мои исходные системы имеют даты создания и даты обновления, разве я не могу использовать их?

Это не рекомендуется, однако если необходимо использовать именно это, пусть так оно и будет. Как правило, это – не вариант, поскольку большинство имеющихся на предприятии систем-источников не содержат дат создания или дат обновления, и даже если содержат, то не хранят историю изменений. Вами должен быть разработан единый согласованный метод фиксации даты/времени. Абсолютно обязательно, чтобы все строки содержали дату последнего обновления в едином стандарте.

Если у меня есть несколько Data Vaults географически распределенных по различным часовым поясам, то это означает, что я должен синхронизировать часы серверов?

Этого не требуется, потому что, обычно, когда объединяются данные различных хранилищ Data Vaults, то преобразование часовых поясов может делаться согласно Среднему времени по Гринвичу (GMT). Однако, может быть полезным синхронизировать часы всех серверов по стандарту «Гринвич + X», чтобы загрузка временных отметок была точной. Фактически, как только часы синхронизированы, становится намного легче объединять информацию из географически распределенных хранилищ и избежать проблем, связанных со значениями времени.

Хорошо, теперь я понимаю, почему дата загрузки необходима, но как она работает?

Этот метод легок для загрузки, но может вызвать проблемы при запросах информации. Для того чтобы получить последнюю строку на определенную дату, запрос без структуры Point-in-time (PIT) должен иметь вложенные подзапросы. Примечание: Мы используем термины PIT (point in time), PIC (picture table), and SOR (system of record) как синонимы. Ниже для примера приведен Спутник, содержащий несколько строк

Рисунок 2-1. Customer Name Hub и Satellite

В случае отсутствия PIT-таблицы, запрос к этому Спутнику должен выглядеть следующим образом (на дату: 1-ое декабря 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’)

У этого запроса есть один изъян. Если в Спутнике не существуют строки с названием клиента и в условии задана дата, более ранняя, чем первая строка для этого клиента, equal-join не вернет никаких результатов. Даже если мы включим в запрос и другие Спутники, такие как Адрес. Например, если мы изменим дату в условии запроса на 1-ое октября 2000 г. (10-1-2000), мы не получим строк, независимо от количества присоединенных Спутников. Далее мы обсудим эту проблему и ее решение.

Этот запрос будет выбирать все текущие названия для всех клиентов по состоянию на 1 декабря 2000. Проблема заключается не в отдельном Спутнике. Каждый Спутник, необходимый для подробностей о состоянии на определенный момент времени, требует вложенных подзапросов такого же типа. Это является проблематичным, по крайней мере, в двух основных случаях: 1) таблиц в запросе две, одна для внешнего запроса, одна для подзапроса. Для некоторых СУБД максимальное количество таблиц в запросе составляет 16; и 2) возможность соединения в пределах одной таблицы. В таком случае может произойти полное сканированию таблицы, если не будет должного индекса.

При таком подходе загрузка очень проста. Мы запускаем дельта-сравнение «последней картинки» каждой строки (с учетом конкретного ключа), и, если существуют какие-нибудь различия, мы вставим новую строку. Никаких обновлений, никаких удалений не требуется. Однако, как мы видели, запросы могут быть сложными. Чтобы способствовать запросам, мы вводим то, что называется point-in-time таблицей (или system of record таблицей). Она выглядит следующим образом:

Рисунок 2-2. Customer Hub, Name Satellite и таблица Point-In-Time Table

Таблица point-in-time позволяет нам сохранить точное описание истории ВСЕХ произошедших изменений. Бизнес-правила будут диктовать, когда текущий снимок данных должен быть сделан, и соответствующий процесс будет делать обновление PIT таблицы. В этом случае, отслеживаются оба изменения: наименования и адреса. Конечно, это не зависит от времени поступления информацией в каждый спутник. Это позволяет загружать спутники в режиме близком к реальному времени, и при этом полностью оставаясь в рамках ограничений ссылочной целостности, и при этом без воздействий на:
а) систему запросов витрины данных;
б) зависимую цепочку (нижележащие зависимости, отношения родитель-потомок),
или
в) частоту загрузки каждого спутника.
Иными словами, имена могут изменяться каждые 15 минут, в то время как адреса могут измениться один раз в день.

Таблица point-in-time (PIT) позволяет нам соединиться с одной таблицей, выбрав point-in-time, как систему записей (system of record), а затем непосредственно соединиться со спутниками. Измененный код SQL:

Select hub.cust_num, sat_1.name, sat_2.address
from HUB_CUST hub, SAT_CUST_PIT sat_pit, SAT_CUST_NAME sat_1, SAT_CUST_ADDR sat_2
where hub.CSID = sat_pit.CSID and hub.CSID = sat_1.CSID and hub.CSID = sat_2.CSID and sat_pit.NAME_LOAD_DTS = sat_1.LOAD_DTS and sat_pit.ADDRESS_LOAD_DTS = sat_2.LOAD_DTS and sat_pit.load_dts <=
(select max(z.LOAD_DTS) from SAT_CUST_PIT z where sat_pit.CSID = z.CSID and z.LOAD_DTS <= ’12-1-2000 23:59:59’)

Опять же, у нас есть фундаментальная проблема с датами – если в качестве условия задана слишком ранняя дата, то не получим строк для этого идентификатора клиента. Другая проблема: Что, если у клиента вообще нет записей в адресном Спутнике? Тогда, этот клиент будет также полностью выпадать из этого соединения. Мы обсудим эту проблему и ее решение далее в этом документе.

У нас все также 5 таблиц участвуют в соединение (joined) – но только одна таблица используется для ограничения временного интервала. Иными словами, кроме таблицы PIT, все соединения используют равенство в условиях соединения. Это прекрасно работает, если два или более спутника привязаны к табличной структуре хабов или связей. Если бы у нас было только два спутника без таблицы PIT, то запрос выглядел бы так:

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_2.CSID and sat_1.LOAD_DTS <=
(select max(z.LOAD_DTS) from SAT_CUST_NAME z where sat_1.CSID = z.CSID and z.LOAD_DTS <= ’12-1-2000 23:59:59’)
AND sat_2.LOAD_DTS <=
(select max(z.LOAD_DTS) from SAT_CUST_ADDR z where sat_2.CSID = z.CSID and z.LOAD_DTS <= ’12-1-2000 23:59:59’)

В этом случае у нас в запросе есть два вложенных подзапроса и пять таблиц. Проблема по настоящему проявляется, когда модель содержит три или четыре спутника. Тогда большое количество связанных таблиц требует много работы во вложенных подзапросах.

Что происходит в этих вложенных подзапросах? С академической точки зрения, индекс соответствует ключу, вследствие чего, чтобы найти максимальную дату загрузки, индекс сканируется. Конечно, это зависит от того, как индексы были созданы, и, имеет ли спутник кластерный ключ или нет. Дело в том, что один подзапрос с соединением по условию равенства (equal-joins) обычно дешевле, чем несколько вложенных подзапросов с условием по диапазону (range joins). Это – только один из двух стилей, которые естественно соответствуют архитектуре Data Vault.

Резюмируя: наличие PIT таблицы помогает уменьшить работу по обработке вложенных запросов и соединений, только если есть два или более Спутников у одного Хаба. Использование стиля 1 означает, что отсутствует дата окончания в строках и не используется выражение «between» в SQL выборках. Это означает, что строки являются активными, пока не вставлена следующая картина (дельта).

Что еще может обеспечить point-in-time таблица?

PIT таблица может обеспечить следующее:

· Темпы изменения истории без сканирования какого-либо из Спутников.

· Временные разницы между изменениями в каждом Спутнике

· Контроль над соединениями по равенству (equal-join) со Спутниками

· Отметки о датах резервного копирования, восстановления или обновлений (при желании можно расширить перечень этих элементов).

Больше особо нечего сказать об этом стиле, разве что, используется генерируемые временные отметки. Не рекомендуется использовать дату создания из систем источников. Конечно, остается вопрос: как и где, следует хранить информационные данные типа «дата»? Это мы рассмотрим далее в этой статье.