Всем привет!
Такой вопрос, есть DWH на стадии "черновика", и встал вопрос как хранить и в каком виде status и потом его обновлять, т.е. в факте или отдельном измерении.
К примеру есть заказ, он может быть в статусе создан, принят, в работе и т.д., также есть три поля времени: когда создан, когда обновлен, когда завершен. За день заказ проходит все периоды, т.е. через 24 часа он будет завершен.
Тут есть несколько мыслей:
1 сделать Accumulating Snapshot Fact Tables
2 засунуть все это в отдельное измерение (т.е. измерение Order, где все эти поля + дополнительные) и обновлять во время загрузки. Здесь вопрос в производительности, dimension будет оч. большая.
3 Также поступало предложение просто не грузить последний день, т.к. 100% завтра все заказы будут в одном статусе, а в факте просто держать когда создано и закрыто.
Может еще что есть интересное.

Заранее всем спасибо.

Критик,

Анализ в общем.
Когда мы делаем загрузку из источника разумеется заказы могут быть в самом разном статусе, которые не завершены не интересны для отчетности, но необходимо сохранить когда создано и закрыто, для отчета необходимо время от поступления до закрытия, другие шаги пока не интересны.
Если сделать измерение orders, а атрибуты статус, дата закрытия (дата поступления разумеется не меняется) типа scd1, + другие атрибуты заказа, типа код причины отказа (к примеру по определенным причинам он может быть отказан и если будет создан новый, то это уже другой заказ) здесь вопрос в производительности. Да и вообще такой паттерн это не очень хорошо ( https://www.kimballgroup.com/2007/10/design-tip-95-patterns-to-avoid-when-modeling-headerline-item-transactions/), делать update на факте тоже не очень правильно, получается только вставляем новые строки, тогда здесь вопрос как определить строки у которых поменялся статус с последней загрузки.
Т.е. по итогу в факте нам интересна сумма заказа, это то что интересует бизнес, дальше им интересно разница между дата поступления и закрытия, также их интересует заказы (точнее сумма и причина) в статусе отказано.
Остальные измерения типа date, customer, manager и т.д. прочие и проблем не вызывают, вопрос как реализовать именно это.

Sutasu,

Ну не знаю... Мне кажется есть более красивый выход. Факт это все таки поступление заказа, если делать как вы пишите все ровно придется проверять статус в источнике и в факте, т.е. это что-то типа slowly change fact 1, в инете есть конечно подобные реализации, но я не представляю как это будет работать на большой таблице, а она будет большая. В источнике только текущее состояние и когда до него обновилось (как я писал 3 столбца, дата поступления, изменения и закрытия, у закрытого соответсвенно 2 последние равны).

Sutasu,

Нет, история не нужна, для анализа нужны заказы только в конечном статусе (отказано, закрыто), вопрос в том что при загрузке через ETL мы выгребаем все заказы во всех статусах, соответственно при следующей загрузке нам нужно обновить все заказы которые в хранилище находятся не в конечном статусе (также у них будет пустая дата закрытия), в этом и есть вопрос, как сделать это эффективно.
Также рассматривали в факте поместить, заказ, дата создания, изменения, закрытия, статус (отказано, выполнено будет 1, 0) и id_статуса (к примеру может быть 10, 20,30 это все отказано, но по разным причинам, если выполнено то просто 0), а на источник повесить CDC, но вопрос в производительности как загрузки так и источника, который OLTP система.

StarikNavy,

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

По поводу "лучше грузить последний день , просто для него ставить статус "обработка/еще не определенно"" немного не понял, поясните пожалуйста.

Ivan Durak,

С SCD3 в принципе идея, вопрос что тогда делать с датой закрытия не обновляя факт, при загрузке она будет null в источнике, и только после закрытия там будет значение.

aleksrov,

Пока у меня только одна идея, это упростит архитектуру DWH но усложнит ETL, это просто не грузить не законченные заказы. Т.е. во время выгрузки в staging будет забираться все, а из staging забираться только законченные, при сл. загрузке из staging удалять только строки которые попали в хранилище, т.е. завершенные заказы, у не завершенных проверяем статус, если он завершился, то грузим, если нет, то до сл. загрузки.

kaldorey,

Атрибуты не меняются, задним числом тоже не выйдет, timestap автоматом ставится.
Тут кстати про флаг говорили, подумал, в принципе тоже вариант. У нас есть поле last update, по нему и делать incremental загрузку.
У незавершенных заказов ставить флаг не завершен, при сл. загрузке, этот же заказ опять загрузиться, но уже завершенным, чтобы свести кол-во таких заказов к минимуму грузить только вчерашний день (бизнес это устраивает, к тому же если грузить сегодняшний там половина будет незавершенных). В таком случае PK сделать суррогатный ключ (не ID заказа).
Хранилище на MS SQL.
С Anchor не знаком, пошел учить :)