Должен ли я применять историю типа 2 к таблицам с дублирующимися ключами? - PullRequest
Новая
       76

Должен ли я применять историю типа 2 к таблицам с дублирующимися ключами?

0 голосов
/ 20 февраля 2020

Я работаю над проектом хранилища данных, используя BigQuery. Мы загружаем ежедневные файлы, экспортируемые из различных систем мэйнфреймов. Большинство таблиц имеют уникальные ключи, которые мы можем использовать для создания истории типа 2, но некоторые таблицы, например таблица главной книги / позиций, могут иметь повторяющиеся строки. Эти файлы содержат полную информацию, извлекаемую из исходной системы каждый день.

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

Один человек в проекте предложил, что способ справиться с этим - "сравнить дубликаты", что означает, что если таблица DWH имеет 5 идентичных Строки и промежуточные таблицы имеют 6 одинаковых строк, затем мы просто вставляем еще одну, а если все наоборот, просто закрываем одну из записей в таблице DWH (устанавливая дату окончания до настоящего момента). Это может быть реализовано путем добавления дополнительного ключа «sub row» к набору данных следующим образом: 

Row_number() over(partition by “all data columns” order by SystemTime) as data_row_nr

Я пытался выяснить, является ли это хорошей практикой или нет, но без какой-либо удачи. Что-то в этом мне просто кажется неправильным, и я не могу понять, какие непредвиденные последствия могут возникнуть из-за этого.

Может кто-нибудь сказать мне, как лучше всего справиться с go при работе с полной нагрузкой? ежедневных данных бухгалтерской книги, для которых мы хотим вести какую-то историю в DWH?

1 Ответ

1 голос
/ 20 февраля 2020

Нет, я не думаю, что было бы хорошей идеей ввести искусственный первичный ключ на основе всех столбцов плюс индекс дублирующейся строки.

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

Но таблица без PK наиболее вероятно таблицы фактов (т.е. записи транзакций), которые обычно не полностью загружены , но загружены на основе некоторого критерия DELTA.

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

Итак, мой список задач

  • Проверьте, не является ли дублируемый объект намеренным или недействительным

  • Попробуйте найти критерий дельты для загрузки таблицы фактов

  • Если все не удается, создайте первичный ключ всех столбцов с одним атрибутом из числа дубликатов и создайте историю.

...