2010-10-11 4 views
0

Поэтому у меня есть два аспекта в моем хранилище данных:Как я могу моделировать эти отношения в хранилище данных в стиле Кимбалла?

dim_machine 
------------- 
machine_key 
machine_name 
machine_type 


dim_tool 
------------ 
tool_key 
tool_name 
machine_type 

То, что я хочу, чтобы убедиться в том, поле machine_type в обоих измерениях имеют одни и те же данные. Должен ли я создать третье измерение снежинки между ними или есть другая альтернатива?

ответ

2

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

Совершенно другой вариант будет «мини-размер» (термин Кимбалла), который содержит все возможные комбинации машин и инструментов. Если два измерения тесно связаны и часто используются вместе в поисках, то это может быть полезным способом их консолидации и упрощения. Но даже тогда я предполагаю, что вы будете проверять и очищать исходные данные, чтобы соответствовать типам машин.

+0

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

+0

Если есть связь между машинами и инструментами, кажется, что их комбинировать стоит рассмотреть. Я бы не сказал, что много строк - проблема: у нас есть 350K строк в одном измерении и вообще нет проблем. – Pondlife

+0

Спасибо за это - конечно, что-то рассмотреть. Причина, по которой я не рассматривал это раньше, состоит в том, что список допустимых комбинаций еще не создан полностью. – OpenDataAlex

3

Имейте в виду, что хранилище данных является де-нормированной структурой, поэтому для данных необходимо повторять измерения. Целостность должна предоставляться в операционной системе и в процессе ETL. Предположим, что у нас есть что-то вроде модели ниже.

alt text

Бизнес-процесс, который распределяет средства должен знать, какой инструмент может быть установлен на какой машине. Предположим, что неправильный инструмент каким-то образом установлен на машине. Лучше импортировать данные в соответствие с этим фактом и запустить отчет, который обнаружит ошибку в бизнес-процессе, чем разбить процесс ETL, потому что тип инструмента и машины не совпадают.

Например, запрос (отчет), подобный этому wold, обнаруживает несоответствие и окажется весьма полезным.

select 
     'tool-machine mismatch' as alarm 
    , full_date 
    , machine_name 
    , machine_type 
    , tool_name 
    , matching_machine_type 
    , employee_full_name 
from fact_installed_tools as f 
join dim_machine   as m on m.machine_key = f.machine_key 
join dim_tool    as t on t.tool_key  = f.installed_tool_key 
join dim_date    as d on d.date_key  = f.date_key 
join dim_employee   as e on e.employee_key = f.employee_key 
where machine_type != matching_machine_type ; 
+0

Спасибо за то, что Дамир, немного помог ^^ b – OpenDataAlex

 Смежные вопросы

  • Нет связанных вопросов^_^