Имейте в виду, что хранилище данных является де-нормированной структурой, поэтому для данных необходимо повторять измерения. Целостность должна предоставляться в операционной системе и в процессе ETL. Предположим, что у нас есть что-то вроде модели ниже.
Бизнес-процесс, который распределяет средства должен знать, какой инструмент может быть установлен на какой машине. Предположим, что неправильный инструмент каким-то образом установлен на машине. Лучше импортировать данные в соответствие с этим фактом и запустить отчет, который обнаружит ошибку в бизнес-процессе, чем разбить процесс 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 ;
Я пытаюсь решить проблему, связанную с машиной и инструментом. Я знаю, что могу оставить размеры в покое, и все будет хорошо. Просто не знал, как далеко отменить нормализацию данных (т. Е. Построить измерение machine_type и связать три измерения вместе). В то время как мини-измерение можно было сделать, мы рассматриваем сотни тысяч комбинаций. – OpenDataAlex
Если есть связь между машинами и инструментами, кажется, что их комбинировать стоит рассмотреть. Я бы не сказал, что много строк - проблема: у нас есть 350K строк в одном измерении и вообще нет проблем. – Pondlife
Спасибо за это - конечно, что-то рассмотреть. Причина, по которой я не рассматривал это раньше, состоит в том, что список допустимых комбинаций еще не создан полностью. – OpenDataAlex