Как смоделировать процесс и историю состояния в хранилище данных?

Question

Предположим, что у нас есть D_PROCESS, D_WORKER и D_STATUS как размеры, так и факт F_EVENT, который связывает процесс (что) с рабочим (кто является ответственным) и «текущим» статусом.

Состояние процесса изменяется со временем. Shoud мы сохраняем в F_EVENT одну строку за процесс/статус/работник или одну строку для каждого процесса/работника и «где-то еще» одну строку для изменения статуса для данного процесса/работника?

Я новичок в Datawarehouse, и трудно найти лучшие практики/учебники, связанные с моделированием данных.

Answer 1

Прочитано The Data Warehouse Toolkit от Ralph Kimball за хорошее введение в моделирование размеров.

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

EDIT:

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

Для D_PROCESS моделирование «процесса» обычно не моделируется как измерение, и вы назвали его «что», поэтому я переименую его в «D_ACCOUNT».

Основная модель данных будет для «системы обработки налогов», в которой WORKERS обрабатывают ACCOUNTS, и каждая комбинация ACCOUNT/WORKER имеет несколько возможных «СОСТОЯНИЙ», где этот процесс в настоящее время стоит.

D_ACCOUNT 
    ACCOUNT_NUMBER 
    ACCOUNT_TYPE 

D_WORKER 
    WORKER_ID 
    FIRST_NAME 
    LAST_NAME 
    BADGE_NUMBER 
    SHIFT 

D_STATUS 
    STATUS_ID 
    STATUS_NAME 

Теперь, если я хочу сообщить о всех «событиях», которые произошли с аккаунтом, выполняемых работником, я могу построить Транзакцию уровень таблицы фактов F_EVENT:

F_EVENT 
    ACCOUNT_ID 
    WORKER_ID 
    STATUS_ID 
    EVENT_TIME_ID 
    Metrics taken at time of the measurement (Cost, Worker time spent, etc) 

Мы называем уникальная комбинация размеров, которая идентифицирует ряд Гранулярность или Зерно таблицы фактов.

Зерна этой таблицы - это учетная запись, рабочий, статус и время. Он отвечает на такие вопросы, как «Сколько времени мои работники на смену 3 тратят на обработку счетов в среду?» или «Сколько событий произошло, что изменило статус обработки на„ЗАКРЫТО“?

Я не уверен, насколько этот тип таблицы поможет.

Вместо этого, говорят, что вы заинтересованы в отслеживании процесса сам как он переходит через различные статусы. Я буду предполагать, что статус всегда движется вперед во времени, от «НЕ НАЧАЛСЯ» до «В ПРОЦЕССЕ» до «ЗАКРЫТО».

Я построю то, что Кимбалл называет «Накопительным Таблица фактов моментальных снимков.

F_TAXPROCESSING 
    ACCOUNT_ID 
    WORKER_ID 
    CURRENT_STATUS_ID 
    NOT_STARTED_DTTM 
    NOT_STARTED_FLAG 
    IN_PROCESS_DTTM 
    IN_PROCESS_FLAG 
    CLOSED_DTTM 
    CLOSED_FLAG 

Зерно этой таблицы - это учетная запись, рабочий. Эта таблица отслеживает «процесс», обновляя дату/время изменения состояния и флаг, когда этот статус был достигнут.

Это позволяет отслеживать процесс с течением времени, позволяя вам видеть, сколько учетных записей отреагировали на статус «IN PROCESS», сколько времени потребовалось, чтобы добраться туда и т. Д.