Объединить факты из разных источников? Или загрузить отдельно?

Question

У нас есть данные двух разных источников: некоторые поступают от клиентов, некоторые от разных поставщиков. В настоящее время мы физически «объединяем» эти данные в массивную таблицу с почти сотней столбцов, десятками тысяч строк и без формального разделения двух измерений. Следовательно, мы не можем использовать эту таблицу для многих.

Я собираюсь изменить этот беспорядок в правильную, но маленькую звездную схему.

Два измерения очевидны. Один из них, например, время.

Данные, предоставленные клиентом, предоставляют ряд значений фактов. Каждый поставщик может (или не может) предоставлять дополнительные значения фактов, которые соответствуют тем же измерениям.

Все эти данные факта имеют одинаковую гранулярность. Его можно назвать «разреженным», потому что мы не часто получаем информацию от всех поставщиков.

Вот моя дилемма.

Заполнена ли эта таблица фактов с несколькими нулями из разных источников?

Или это n + 1 таблиц фактов - одна заполняется от клиента, другие заполняются от каждого поставщика?

У каждого дизайна есть свои плюсы и минусы. Мне нужно второе мнение о выборе между «объединить» или «загрузить отдельно».

---

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

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

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

Некоторые транзакции будут иметь обоих поставщиков. У нескольких транзакций не будет ни одного поставщика.

Одна таблица с нулями? Три стола?

Answer 1

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

Answer 2

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

На самом деле вы находитесь в отличной точке в приложении «brownfield». Вы можете посмотреть на то, что существует сегодня, и использовать опыт, чтобы создать лучший дизайн. Это самое важное время, чтобы выбрать лучшее зерно, которое, мы надеемся, не изменится в течение срока службы DW.

Answer 3

Из того, что вы описываете, звучит так, будто единственная таблица фактов - это путь.

Звучит так, как будто в таблице фактов есть зерно времени x транзакция x клиент (?).

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

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