Способы и системы загрузки данных в хранилища временных данных

Способы и системы загрузки данных в хранилища временных данных

Иллюстрации

Показать все

Реферат

Уровень техники

Область настоящего изобретения относится в основном к хранилищу двоичных данных (CDW), и в частности к способам и системам сбора данных, управляемого метаданными, для хранилища временных нормализованных данных.

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

В настоящее время сложные пользовательские программы загрузки данных, обычно выполняющихся на больших внешних серверах приложений, являются решением, которое было реализовано в попытке загрузки хранилищ временных данных. Такие программы обрабатывают и загружают данные последовательно по первичному ключу, что может привести к долговременному выполнению программ и к всестороннему, относительно интрузивному обновлению целевых таблиц. В некоторых случаях, чтобы постоянно поддерживать пользователей, два набора целевых таблиц используются и откачиваются, когда загрузка завершена. Однако, в таких системах, как правило, некоторые данные, уже находящиеся в базе данных, выгружаются, обрабатываются внешне на сервере приложений наряду с входными данными и повторно загружаются, чтобы довести до конца загрузку данных, что дополнительно нагружает сеть и базу данных. Другие известные существующие решения также имеют тенденцию к размещению только в прогнозируемых ситуациях, а не во всех возможных ситуациях, и к нарушению, отмене загрузки или к отклонению данных в непредвиденных случаях (например, реальная временная связь в пределах первичного ключа).

Другие предполагаемые решения в общем имеют другие недостатки. Например, разработка, которая имеет жесткую кодировку для ввода частных типов входных данных и точных целевых схем, нежелательна из-за затрат на разработку. Кроме того, расходы по обслуживанию могут быть проблемой при обращении к первичному ключу или при изменении атрибутов источника данных, цели данных или способа взаимодействия. Применение средств извлечения, преобразования и загрузки (ETL) для выполнения работ за пределами базы данных на сервере является возможным решением, но неэффективным, и может влиять на объем сетевого трафика. Потери эффективности в предполагаемых решениях становятся особенно большими при использовании внешнего или последовательного решения на массивно-параллельной архитектуре (МРР), широко применяемой хранилищами данных. Кроме того, собственные инструментальные средства базы данных требуют специальных знаний и не переносимы на другие платформы (например, Oracle PL/SQL). Эти решения являются неэффективными для больших объемов данных, которые могут сделать близкую к реальному времени неинтрузивную загрузку невозможной и требуют разное кодирование для инициализации или больших объемов данных для достижения приемлемой производительности.

Сущность изобретения

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

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

Еще одним аспектом настоящего изобретения является компьютерный программный продукт. Компьютерный программный продукт включает неизменный во времени машиночитаемый носитель с внедренными в него машиноисполняемыми инструкциями для загрузки хранилища чистыми изменениями данных. Исполнение машиноисполняемых инструкций хотя бы одним процессором приводит к разбиению набора входных данных на множество разделов, включающих первый раздел и второй раздел. Каждый раздел из этого множества включает в себя множество записей данных. Исполнение машинных инструкций процессором также приводит к импортированию первого раздела в таблицу предварительной загрузки, импортированию второго раздела в таблицу предварительной загрузки и загрузке таблицы предварительной загрузки в хранилище данных.

Краткое описание чертежей

Фиг.1 представляет упрощенную блок-схему компьютерной системы.

Фиг.2 представляет блок-схему компьютерной сети.

Фиг.3 представляет схему последовательности операций процесса захвата изменений данных, представленного в качестве примера.

Фиг.4 представляет схему последовательности операций процесса загрузки разделов, представленного в качестве примера.

Фиг.5 представляет схему последовательности операций процесса загрузки данных, представленных в качестве примера.

Фиг.6 представляет схему потока данных, связанную с шагом 100, показанных на фиг.4.

Фиг.7 представляет схему потока данных, связанную с шагом 101, показанных на фиг.4.

Фиг.8 представляет схему потока данных, связанную с шагом 102, показанных на фиг.4.

Фиг.9 представляет схему потока данных, связанную с шагом 103, показанных на фиг.4.

Фиг.10 представляет схему потока данных, связанную с шагом 104, показанных на фиг.4.

Фиг.11 представляет схему потока данных, связанную с шагом 105, показанных на фиг.4.

Фиг.12 представляет схему потока данных, связанную с шагом 106, показанных на фиг.4.

Фиг.13 представляет схему потока данных, связанную с шагом 107, показанных на фиг.4.

Фиг.14 представляет схему потока данных, связанную с шагом 108, показанных на фиг.4.

Фиг.15 представляет схему потока данных, связанную с шагом 109, показанных на фиг.4.

Фиг.16 представляет схему потока данных, связанную с шагом 110, показанных на фиг.4.

Фиг.17 представляет схему потока данных, связанную с шагом 111, показанных на фиг.4.

Фиг.18 представляет схему потока данных, связанную с шагом 112, показанных на фиг.4.

Фиг.19 представляет схему потока данных, связанную с загрузочным шагом 202, показанного на фиг.5.

Фиг.20 представляет схему потока данных, связанную с загрузочным шагом 203, показанного на фиг.5.

Фиг.21 представляет схему потока данных, связанную с загрузочным шагом 204, показанного на фиг.5.

Фиг.22 представляет схему потока данных, связанную с загрузочным шагом 205, показанного на фиг.5.

Фиг.23 представляет схему потока данных, связанную с загрузочным шагом 206, показанного на фиг.5.

Фиг.24 представляет блок-схему вычислительного устройства, представленного в качестве примера.

Подробное описание

Варианты осуществления описаны в данном документе с применением процесса захвата изменений данных (CDC). В настоящем документе термин «CDC» означает процесс захвата и загрузки изменения в хранилище временных данных. Информация на входе в процесс CDC, набор входных данных, уже может быть преобразован, чтобы соответствовать модели данных целевого хранилища (например, нормализованный, бизнес или естественный ключ), но без временной обработки, такой как упорядоченность во времени, временная нормализация и/или временное разрешение конфликтных ситуаций. Набор входных данных уже может быть загружен в систему базы данных, так что он непосредственно доступен для обработки CDC.

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

Описанные системы пригодны для анализа набора входных данных, который может называться входным набором данных по отношению к указанным системам и к существующему хранилищу данных, идентификации и упорядочения чистых изменений данных относительно данных, уже хранящихся в хранилище данных, с применением набора операторов реляционной алгебры и применения обновления хранилища данных. Набор входных данных включает в себя множество записей данных, которые могут представлять собой снимок исходной базы данных (например, все записи данных в исходной базе данных в некоторый момент времени) и/или множество сообщений или транзакций (например, операции вставки, обновления и/или удаления), которые были выполнены по отношению к исходной базе данных.

Чтобы осуществить такой способ, код программного обеспечения, такой как язык структурированных запросов (SQL), соответствующий хранилищу данных, может быть сгенерирован, когда программное обеспечение, описанное в настоящем документе, создается (например, компилируется), когда программное обеспечение вводится в действие, и/или когда метаданные (например, структуры базы данных) пересматриваются. Сгенерированный код затем может быть исполнен системой каждый раз, когда данные загружаются в хранилище данных. В некоторых вариантах осуществления генерируемый код создается одним или несколькими хранимыми процедурами (например, функциональным кодом, сохраненным в базе данных и исполняемым ею), которые сохраняют генерируемый код в базе данных. Во время загрузки данных сгенерированные операторы извлекаются и исполняются над входными данными.

Рабочие характеристики, такие как время выполнения и/или использование вычислительных ресурсов, процесса загрузки входных данных в хранилище данных могут быть улучшены при использовании одного или нескольких оптимизационных опций. Использование вычислительных ресурсов может включать, без ограничения, использование процессора, использование памяти и/или использование сетевых ресурсов. Оптимизационные опции включают в себя, например, разбиение входных данных на разделы и раздельную обработку каждого раздела, импорт входных данных в энергозависимые таблицы перед загрузкой данных в целевые таблицы, фильтрация истории из целевой таблицы сравнений, когда они не требуются для входных данных, и способ нормализации по времени данных.

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

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

Иллюстративные технические действия в вариантах осуществления, описанных в данном документе, могут включать, без ограничения:

(a) разбиение набора входных данных на множество разделов, в том числе первый раздел и второй раздел, в котором каждый раздел этого множества включает в себя множество записей данных;

(b) разбиение набора входных данных, основанных на хеш-функции и заданного количества разделов;

(c) импортирование первого раздела и второго раздела в таблицу предварительной загрузки, либо последовательно во времени, либо параллельно (например, одновременно);

(d) загрузка таблицы предварительной загрузки в хранилище временных данных;

(e) импортирование разделов в соответствующие энергозависимые таблицы;

(f) копирование разделов из энергозависимой таблицы в таблицу предварительной загрузки;

(g) идентификацию записей данных в первом разделе, который включает множество полей, отличных от поля временной метки, таких же, как и неключевые поля, предыдущей импортированной записи данных;

(h) исключение идентифицированных записей при импорте первого раздела в таблицу предварительной загрузки;

(i) исключение неявного удаления активной записи данных, основанное на том, что активная запись данных в хранилище временных данных не связана с записью данных в набор входных данных;

(j) определение самой ранней исходной временной метки, соответствующей первой записи данных из набора входных данных;

(k) идентификацию набора первичных ключей, представляющих запись данных в хранилище временных данных, соответствующую исходной временной метке, непосредственно предшествующей самой ранней исходной временной метке, и одну или несколько записей данных в хранилище временных данных, которые соответствуют исходной временной метке более поздней, чем самая ранняя исходная временная метка; и

(I) импорт первого раздела и второго раздела на основе идентифицированного набора первичных ключей.

Варианты осуществления могут быть далее описаны со ссылкой на конкретные приложения, такие как хранилище данных, которое хранит информацию о спецификациях материалов (ВОМ) и/или сведения о деталях (например, механических деталях оборудования). Предполагается, что такие варианты осуществления, применимы к любому хранилищу временных данных.

На фиг.1 приведена упрощенная блок-схема иллюстративной системы 10, включающей серверную систему 12 и множество клиентских подсистем, также называемых клиентскими системами 14, подключенных к серверной системе 12. Автоматизированное моделирование и группировка инструментов, как описано ниже более подробно, хранятся в серверной системе 12, и могут быть доступны посредством запроса любой из клиентских систем 14 (например, компьютеров). Как показано на фиг.1, клиентскими системами являются компьютеры 14, включающие веб-браузер, так чтобы серверная система 12 была доступной для клиентских систем 14, использующих Интернет. Клиентские системы 14 связаны с Интернетом через множество интерфейсов, включающих сеть, такую как локальную вычислительную сеть (LAN) или глобальную сеть (WAN), подключение к сети по коммутируемой телефонной линии, кабельные модемы и специальные высокоскоростные ISDN линии. Клиентскими системами 14 могут быть любые устройства, способные обмениваться информацией с Интернетом, в том числе Интернет-телефон, электронная записная книжка (PDA) и другое веб-подключаемое оборудование. Сервер базы данных 16 подключается к базе данных 20, содержащей информацию о самых разнообразных вопросах, как описано ниже более подробно. В одном варианте осуществления, централизованная база данных 20 хранится на системном сервере 12 и может быть доступна потенциальным пользователям одной из клиентских систем 14 посредством регистрации на системном сервере 12 через одну из клиентских систем 14. В альтернативном варианте осуществления база данных 20 хранится удаленно от системного сервера 12 и может быть нецентрализованной.

На фиг.2 приведена развернутая блок-схема иллюстративного варианта осуществления системы 22. Система 22 является всего лишь одним примером подходящей вычислительной среды и не предназначена для какого-либо ограничения объема настоящего изобретения. Также систему 22 не следует интерпретировать как относящуюся к какой-либо одной компоненте или комбинации компонент, проиллюстрированных в настоящем документе. Компоненты в системе 22, идентичные компонентам системы 10 (показанной на фиг.1), указаны на фиг.2 с использованием тех же самых ссылочных номеров, что и на фиг.1. Система 22 включает в себя системный сервер 12 и клиентские системы 14. Системный сервер 12 включает еще сервер базы данных 16, сервер 24 приложений, веб-сервер 26, факс-сервер 28, сервер 30 каталогов и почтовый сервер 32. Блок 34 дисковых накопителей (который включает в себя базу данных 20) связан с сервером базы данных 16 и сервером 30 каталогов. Серверы 16, 24, 26, 28, 30 и 32 соединены в локальную вычислительную сеть (LAN) 36. Кроме того, рабочая станция 38 системного администратора, рабочая станция 40 пользователя и рабочая станция 42 руководителя подсоединены к локальной вычислительной сети 36. В альтернативном исполнении рабочие станции 38, 40 и 42 подключены к локальной сети 36 посредством Интернет-канала или соединены через Интернет. В некоторых вариантах исполнения сервер базы данных 16 связан с дисковым накопителем 34, который недоступен для других устройств, таких как сервер каталогов 30.

Каждая рабочая станция 38, 40 и 42 является персональным компьютером, имеющим веб-браузер. Хотя функции, выполняемые на рабочих станциях, обычно представляются как совершаемые на респектабельных рабочих станциях 38, 40 и 42, такие функции могут быть выполнены одним из многочисленных персональных компьютеров, связанных с локальной сетью 36. Рабочие станции 38, 40 и 42 проиллюстрированы как соотнесенные с отдельной функцией только для облегчения понимания различных типов функций, которые могут выполнять лица, имеющие доступ к LAN 36.

Серверная система 12 сконфигурирована так, чтобы быть коммуникативно связанной с различными лицами, включая сотрудников 44 и третьих лиц, например клиентами/контрактниками 46, использующими Интернет-подключение 48 через поставщика услуг Интернета (ISP). Связь в иллюстративном варианте осуществления показана как осуществляемая посредством Интернета, однако любой другой тип глобальных вычислительных сетей (WAN) может быть использован в других вариантах осуществления, т.е. системы и процессы, не ограничиваются практикой использования Интернета. Кроме того и даже скорее всего, вместо WAN 50 может быть использована локальная вычислительная сеть 36.

В иллюстративном варианте осуществления любое уполномоченное лицо, имеющее рабочую станцию 54, может получить доступ к системе 22. По меньшей мере одна из клиентских систем включает удаленную рабочую станцию 56 администратора. Рабочие станции 54 и 56 являются персональными компьютерами, имеющими веб-браузер. Кроме того, рабочие станции 54 и 56 сконфигурированы для осуществления связи с системным сервером 12. Кроме того, факс-сервер 28 осуществляет связь с удаленными клиентскими системами, включая рабочую станцию 56, посредством телефонной связи. Факс-сервер 28 сконфигурирован для осуществления связи с другими клиентскими системами и/или с рабочими станциями 38, 40 и 42.

Используя системы, изображенные на фиг.1 и фиг.2, высокоэффективные и относительно неинтрузивные работающие почти в реальном масштабе времени загрузки активируются заданными мини-пакетными прогонами без прерывания запросов пользователя. Процесс основан на стандартных операторах ANSI SQL, поэтому он применим к любой платформе базы данных, по-новому использующей мощность системы управления базы данных (СУБД), обеспечивающей сверхлинейную масштабируемость особенно на архитектурах с массивно параллельной обработкой (МРР), и не требует никакой обработки данных на внешних серверах (например, SQL-операторы могут быть вызваны из любого места). В одном из вариантов загрузка хранилища данных во время выполнения управляется полностью метаданными посредством использования заданий первичного ключа и табличных имен в качестве параметров. Еще одно преимущество заключается в том, что изменения схемы не требует повторной компиляции или перезагрузки системы захвата изменений данных и оперативные метаданные могут быть изменены в любое время (например, явное или неявное удаление формы, количество разделов и/или уровень параллелизма). В противном случае любой тип интерфейса и все таблицы в модели данных (реальное время включается в каждый первичный ключ) могут быть предоставлены посредством одной программы. Только строки-кандидаты требуются в качестве входных данных (колонки+реальная временная метка), при этом никакой идентификации того, что изменилось, если таковое произошло, не нужно иметь в качестве входных данных системы захвата изменений данных. Для интерфейсов снапшот ни в какой идентификации удаления нет необходимости. Связи реальных времен могут быть разорваны в пределах первичного ключа с очень короткими временами следования в наборах данных и многократными вызовами. Обновления, датированные задним числом и/или связанные с историей, выполняются путем обновления временной последовательности как входных, так и существующих данных.

Вышеуказанные усовершенствования реализованы посредством существующих решений, так как существующие решения часто настроены на тип интерфейса и обычно полностью жестко кодированы для каждого столбца в каждой таблице. Кроме того, существующие подходы к заданию временной последовательности являются построчными, а не массовыми, задаваемыми посредством набора операторов SQL (например, посредством реляционной алгебры набора операторов). Поэтому эти решения не являются сверхлинейными, как в системе захвата изменений данных. Например, варианты осуществления, описанные в данном изобретении, могут обрабатывать 1000 строк за менее чем десять промежутков времени, т.е. времени, необходимого для обработки 100 строк. В обычных вариантах никакие данные не удаляются из базы данных во время обработки и форма вызова системы захвата изменений данных может быть внешней (например, Perl) или внутренней процедурой базы данных.

Описанные варианты осуществления способствуют сокращению и потенциально исключению затраты на разработку, связанную с выявлением изменений (например, вставка, обновление, исключение, повторное подтверждение и/или обновление истории) и способствуют внесению изменений в хранилище временных данных, которые сохраняют историю посредством временного периода, задаваемого реальными временными метками типа начало-конец. Описывается эффективный и очень масштабируемый план, по-новому использующий механизм СУБД и архитектуру с набором операторов SQL, в отличие от существующих решений, которые используют неэффективные курсоры (строки за раз), серверы загрузки внешних данных и генерируют соответствующий сетевой трафик. Минимально интрузивный проект предоставляет непрерывные запросы во время загрузки посредством очень быстрого набора SQL операторов на загрузку транзакции, максимизированную для эффективного (одну и ту же структуру завершающей стадии и цели, чтобы минимизировать нагрузку и повысить пропускную способность СУБД) применения различных методологий запросов, включающих, но не ограничивающих, методы блокировки конечного пользователя и использования истории посредством SQL-модификаторов.

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

Ниже приведены определения некоторых терминов и сокращений, используемых в настоящем документе. Оперативная (онлайновая) обработка транзакций (OLTP) базы данных - это основанная на транзакции база данных, которая обычно включает нормализованные структуры базы данных. Например, запись данных (например, строка в таблице) в OLTP может включать ссылку на другую запись данных (например, строка еще в одной таблице), а не копию данных в указанной записи данных. Далее, база данных OLTP может воздействовать на целостность ссылочных данных для обеспечения того, чтобы такие ссылки были реальными (например, обращение к существующей записи данных и/или к записи данных определенного типа).

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

PK_Latest - это первичный ключ, исключая SOURCE_START_TS, который обычно является коммерческим ключом онлайновой системы обработки транзакций (предоставляемый в базе данных в виде CDW_PK_COLS_LATEST_V).

W-таблица - это целевой объект преобразования набора входных данных. В иллюстративных вариантах осуществления W-таблица включает копию вспомогательной таблицы с 2 парами стандартных временных меток начало-конец, отображающих оба опущенных временных периода, но с наличием временной метки исходной системы с именем SRC_START_TS. В случае, когда опция ALL_VT (более детально описанная ниже) имеет значение Y, может быть использована энергозависимая копия W-таблицы.

Х-таблица - это таблица предварительной загрузки, источник всех строк, которые загружаются в целевую таблицу. Х-таблица может быть копией целевой таблицы с добавлением столбца для сохранения назначенного действия (индикатор ETL) и двух исходных временных меток, обозначенных как src вместо source.

Целевой объект - это однослойное хранилище двоичных данных, соответствующее единой базе данных с однозначно именованными таблицами, которые представляют область применения хранилища данных. Вспомогательная таблица является примером целевой таблицы. Другие потенциальные слои таблицы базы данных являются основными (например, полностью интегрированные в третью нормальную форму, или 3NF) и производными (например, предварительно-присоединенными, агрегированными). Все процессы могут загружать эти три слоя, если не указано иное, полученными исходными данными возможно из вспомогательной или основной таблицы, но все еще представленные как входные данные W-таблицы до активации процесса. В случае, когда опция ALL_VT (более детально описанная ниже) имеет значение Y, может быть использована энергозависимая копия целевого объекта.

ALL_VT опция указывает, должна ли система использовать энергозависимые рабочие таблицы. Когда опция ALL_VT отключена (например, установлена в значение N), система использует две сгенерированные рабочие таблицы (например, в W_table и X_table) в промежуточной области базы данных, которые основаны на их целевых прототипах. Третья энергозависимая или нестабильная таблица может быть использована вплоть до выполнения процедуры загрузки W-таблицы, описанной в этом документе. Для каждой целевой таблицы могут быть созданы до трех скрипт-генерируемых вариантов этих таблиц, встроенных в промежуточные области базы данных, в дополнение к любым другим таблицам, используемым внешне для преобразования наборов входных данных, чтобы воспользоваться процессом CDC. Энергозависимые табличные копии этих вариантов создаются, когда ALL_VT опция включена (например, установлена в значение Y). Эти три таблицы являются дополнительными таблицами, которые могут и не быть непосредственно смоделированы средствами моделирования базы данных. Скорее, они могут быть встроены с помощью скрипта во время построения и включены в целевые скрипты построения, за исключением энергозависимых таблиц, которые сформированы во время прогона.

В иллюстративных вариантах осуществления, скрипт создает и именует каждую таблицу, как показано в Таблице 1.

W-таблица является целевой таблицей для всех промежуточных преобразований до вызова системы CDC, за исключением явных удалений. Х-таблица является непосредственным источником всех целевых данных и загружается либо из W-таблицы, либо посредством потенциально внешних процессов в случае явно выраженных или каскадных удалений. Загрузочная стадия CDC системы добавляет или использует коды индикатора ETL в Х-таблице, такие как I, О, U и D, которые заданы в другом месте настоящего документа. Коды, связанные с системой CDC, инициализируются или устанавливаются при перемещении данных из W-таблицы к Х-таблице и далее обновляются в Х-таблице вплоть до контроля окончательного внесения изменения в целевую базу данных.

В иллюстративных вариантах осуществления, когда опция ALL_VT включена, скрипт создает и обращается к таблицам, как показано в Таблице 2, где TNAME соответствует действующему имени целевой таблицы.

Операции извлечения, преобразования и загрузки (ETL) могут быть переданы с использованием ETL-индикаторов, приведенных в Таблице 3.

Как показано выше, индикаторы извлечения, преобразования и загрузки (ETL) представляют собой I, U, О, D, и каждый из них связан с действиями над одной или несколькими целевыми вспомогательными таблицами, такими как загрузка новой целевой строки или установка конечной временной метки на существующей строке. Для ETL-индикатора ′I′ вспомогательным действием является вставка новой строки, при этом конечная временная метка новой целевой строки равна NULL (самая поздняя строка, не имеет окончания периода фиксации), пока эта строка не заменена или логически не удалена. Для ETL-индикатора U вспомогательными действиями являются вставка новой строки, изменение конечной временной метки (если она еще не просрочена) самой поздней вспомогательной строки на начальную временную метку самой ранней U строки, которая находится в пределах первичного ключа (РК) в Х-таблице. Любая конечная временная метка поступает из записей другой Х-таблицы. Конечная временная метка новой целевой строки для индикатора U является NULL, если самая поздняя строка находится в пределах РК в X-таблице, или начальной временной меткой следующей строки Х-таблицы. Пока разрыв временного периода заранее явно не задан посредством логического удаления или иным образом, конечная временная метка или конец временного периода в строке обеспечивается начальной временной меткой последующей строки в пределах первичного ключа. Таким образом, конечная временная метка или период действия новых строк по умолчанию принимает значение ″до замены″.

Для ETL-индикатора О вспомогательными действиями являются вставка новой строки, которая находится вне последовательности обновления, в ту, которая не является самой поздней временной меткой в пределах самого позднего первичного ключа (PK_Latest), или это самая последняя строка, но ее начальная временная метка старше, чем самое позднее время фиксации в пределах первичного ключа. В любом случае, строка связана с конечной временной меткой (т.е. предварительно зафиксирована), либо в Х-таблице, либо после загрузки во вспомогательную таблицу. Для индикатора D (логическое удаление) вспомогательными действиями являются обновление самой поздней текущей строки целевой таблицы с незафиксированной конечной временной меткой или предшествующей Х-таблицы (в случае непосредственно предшествующей) и установка конечной временной метки из начальной временной метки строки Х-таблицы. Строка не загружается напрямую. Конечная временная метка новой целевой строки для индикатора D изначально равна NULL и позже может быть обновлена на основе более новой строки в Х-таблице.

В иллюстративных вариантах осуществления обработка ETL CDC и генераторы кода основаны на метаданных первичного ключа, предварительно занесенных в промежуточную таблицу. Два режима просмотра созданы для предоставления либо полного первичного ключа хранилища данных, включая SOURCE_START_TS, либо самый последний вид этого ключа, обычно бизнес-ключа OLTP, исключая SOURCE_START_TS. Кроме того, генераторы кода основываются на стандартных видах представления каталога базы данных, которые предоставляют информацию с описанием структур баз данных (например, базы данных, таблицы и/или столбцы). Первый вид, который может быть реализован только как вид, может быть назван CDW_PK_COLS_LATEST_V. Второй вид, который может быть видом базовой таблицы, может быть назван CDW_PK_COLS_V. Как первый вид, так и второй вид загружаются из первичных ключей в средства моделирования, делают запрос на предоставление DATA_LAYER и, как правило, используют вспомогательные, производные слои в обработке ETL.

Процесс захвата изменений данных функционирует на основе заданной стандартной