Разработка измерения с несколькими источниками данных

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

Мой пример: у меня есть 2 источника данных - система заказов и система исполнения. В системе заказов есть подробная информация об оплате и о том, что должно произойти; в системе исполнения есть подробная информация о том, что на самом деле произошло (сколько времени это заняло и т. д., кто выполнил заказ). Данные из обеих систем необходимы для создания единого факта.

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

Как вы разрабатываете SCD, чтобы учесть изменения обеих систем в измерении?

Мы следуем довольно строгой методологии Кимбалла — к вашему сведению, но я готов рассмотреть решения каждого.


data-warehouse etl scd
person tember    schedule 26.07.2016    source источник
comment
У вас есть запись измерения для исходной системы или вы заранее объединяете местоположения и загружаете только одно местоположение?   -  person Nick.McDermaid    schedule 27.07.2016
comment
в постановке у меня есть две записи измерений для одного местоположения - по одному из каждой исходной системы. Физически это одно место - я не уверен, как лучше всего обращаться с этим в DW. Это одномерная запись с двумя суррогатными бизнес-ключами? Это одна запись с таблицей внешних ссылок с перечисленными там суррогатными бизнес-ключами? Или это двухмерные записи? Или по другому..?   -  person tember    schedule 27.07.2016
comment
Я не могу редактировать комментарий ... везде, где я говорил суррогатный бизнес-ключ, он должен был просто говорить бизнес-ключ   -  person tember    schedule 27.07.2016

Ответы (2)


arrow_upward
1
arrow_downward

Не обязательно ответ, но вот мои мысли:

Вы уже описали реальные варианты в своем комментарии. Либо:

A. Объедините это заранее

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

OR

B. Объедините его в измерение

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

Однако у вас есть два ограничения, которые, как мне кажется, делают выбор между A и B более четким.

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

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

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

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

person Nick.McDermaid    schedule 27.07.2016
comment
Спасибо за ответ. Я обработаю это на стадии подготовки, но я до сих пор не знаю, какое значение лучше всего подходит в качестве бизнес-ключа в таблице измерений. И я все еще хотел бы увидеть некоторые примеры того, как это реализовано, или то, что считается лучшей практикой. Потому что, я согласен, это должна быть общая проблема, и должен быть документ о том, как лучше всего с ней справиться.... - person tember; 03.08.2016
comment
Я бы тоже хотел увидеть пример. На самом деле то, что вы делаете, — это слияние, и Кимбалл предлагает создать «надежный ключ». Нижний раздел этой статьи, вероятно, вас заинтересует: kimballgroup.com/2012/07/ Я не знаю, есть ли у Кимбалла ответы на все вопросы, но он единственный предлагает возможные решения. - person Nick.McDermaid; 04.08.2016

arrow_upward
0
arrow_downward

Мое мышление на самом деле очень тривиально. Сначала вам нужно сделать вывод о том, каков ваш основной набор данных с точки зрения гео+местоположения и детализации.

Мой метод будет:

Загрузка DIM

Скажем, ниже моя цель

Dim_Location = {Business_key, Longitude, Latitude, Location Name}

Словарь

Business_key = Всегда сопоставляется с основной записью из исходной системы (в данном случае это исполнительная система). Представьте, что теперь для этой таблицы объединен уникальный ключ от бизнеса (долгота, широта).

Имя местоположения = Опять же, поскольку мы предполагаем, что «система выполнения» является главной для наших данных, она будет размещаться из Source = «Система выполнения».

Приведенная выше таблица теперь загружена для поиска фактов.

Загрузка фактов

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

Сложные сценарии

Что делать, если в системе исполнения есть записи о позднем поступлении заказов? Что, если одно и то же geo_location указывает на несколько названий местоположений? Невозможно, но стоит профилировать данные на наличие ошибок.

person Sunil Soceite Generale    schedule 01.08.2018