Сопоставление фактических данных с недублированными записями измерений

Question

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

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

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

1. Если у меня есть три местоположения, напишите три отдельных суррогатных ключа в одну запись измерения. Это сделало бы сопоставление в процессе ETL простым, но не очень масштабируемым, потому что дополнительные местоположения могут и, вероятно, будут добавлены. Для каждого нового местоположения, которое появилось в сети, мне нужно было бы добавить дополнительное поле естественного ключа к каждой таблице измерений с такими дедуплицированными записями.

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

Любая информация о том, как вышеупомянутый сценарий может быть обработан, будет принята с благодарностью.

Answer 1

Мы используем подход 2. Представьте себе, что однажды у вас будут сотни локаций, и вы увидите, что о подходе 1 просто не может быть и речи.

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