Я согласен с комментарием выше: ключ «исходная система» представляет собой составной ключ из исходной системы + еще одна строка или int, идентифицирующая фактическую исходную систему. Это отдельно от суррогатного ключа, упомянутого в предыдущих ответах. У вас действительно есть два ключа в вашем измерении. Один из них — стандартный суррогатный ключ IDENTITY
— никаких сюрпризов.
Другой — составной ключ, состоящий из ключа из исходной системы и идентификатора (на самом деле я обычно просто использую строку), указывающего, из какой системы он исходит.
Итак, ваше измерение выглядит так:
Customer_SK SRC_Key SRC_System Customer Name
1 5 SAP Jim
2 5 MYOB Joe
- Ваш код ETL из MYOB> DW знает, что нужно смотреть только данные MYOB
- Ваш код ETL из SAP> DW знает, что нужно смотреть только данные SAP
- В вашем хранилище данных используется только суррогатный ключ Customer_SK.
По мере развития вашего DW и появления новых исходных систем вы просто продолжаете добавлять SRC_Systems.
Вы можете поместить их в разные столбцы, как предложено в другом ответе, но тогда вы получите следующее:
Customer_SK SRC_Key_SAP SRC_Key_MYOB Customer Name
1 5 NULL Jim
2 NULL 5 Joe
Что кажется немного расточительным и требует, чтобы вы добавляли столбец каждый раз, когда новая система подключается к сети.
Важный вопрос: существует ли один и тот же клиент в обеих исходных системах? Этот дизайн фактически позволяет объединять строки, если они это делают.
Также убедитесь, что вы наложили уникальное ограничение на SRC_Key
, SRC_System
, так как это повышает производительность, обеспечивает целостность и самостоятельно документирует ключ.
person
Nick.McDermaid
schedule
06.06.2016