#data-warehouse #dimensional-modeling #star-schema #kimball
Вопрос:
Я всегда задаюсь вопросом, является ли таблица FactInternetSale в AdventureWorksDW накопительной таблицей моментальных снимков. В нем есть дата-код корабля.
Согласно документации AdventureWorks OLTP, в ней говорится, что дата отправки руководителя отдела продаж-это дата, когда «заказ был отправлен клиенту». Я интерпретирую эту строку так, что при отправке заказа дата отправки будет обновлена.
Это также означает, что строки в DW FactInternetSale также необходимо будет обновить. Дата отгрузки отмечает важную веху заказа, и это явно поведение накапливающейся таблицы фактов моментального снимка.
Итак, следует ли считать эту таблицу сводной таблицей фактов моментального снимка? Если да, то есть ли какая-либо проблема в том, что нет реальной таблицы фактов транзакций?
В книге инструментария хранилища данных Кимбалла в такого рода задаче он очень строго разделяет таблицу фактов транзакции заказа и Таблицу Фактов доставки, при этом таблица фактов транзакции заказа содержит только информацию, которая записывается при оформлении заказа и не будет обновляться. Даты в таблице Фактов Проводки по заказу всегда являются ожидаемой датой, а не реальной датой. Таблица фактов доставки содержит истинную дату отгрузки товара. После этого появляется сводная таблица фактов моментального снимка, содержащая все важные этапы выполнения заказа. Не только дата отправки, но и другие важные вехи… Имея даты важных вех, мы, конечно, можем знать текущее состояние заказа.
По моему личному мнению, я считаю, что Таблица фактов заказа, которая не содержит текущего статуса, совершенно бесполезна. Какой смысл знать общее количество заказов, но не знать, сколько из них выполнено (отправлено), а сколько из невыполненных? По моему опыту, пользователи (аналитики данных) всегда будут просто использовать таблицу накопленных снимков для выполнения своей работы все время, так как предикат поиска «текущее состояние» никогда не отсутствует в их запросе.
В моем реальном мире я обычно оформляю эту таблицу фактов порядка (информации) как накопительный снимок напрямую, пропуская таблицу фактов транзакций (например, то, что делает Кимбалл, строго разделяет вещи), так как я чувствую, что это очень трудоемко и бесполезно. Таблицы фактов транзакций обычно представляют собой просто действия, выполненные с заказом (например, доставка).
Что вы думаете об этом?
Ответ №1:
Нет, это не сводная таблица фактов моментального снимка
Комментарии:
1. Можете ли вы объяснить, почему? Я только что снова прочитал описание от Microsoft, и кажется, что в этой таблице есть только «отправленный» заказ. Если это так, это означает, что данные попадут в таблицу только в том случае, если они достигли «холодного состояния», и они записаны только один раз, никогда не обновлялись, поэтому это должна быть таблица фактов транзакций. Дело только в том, что в нем содержится какая-то дата важного майл-стоуна. Но на самом деле организация, как правило, требует, чтобы данные поступали как можно быстрее, поэтому дата вехи будет доступна не сразу, но ее необходимо обновить позже, я считаю, что это явно поведение накопления факта моментального снимка
2. AdventureWorksDW не является реальной реализацией для реального бизнеса, это сконструированный пример для демонстрации функций/возможностей MS. Ты, кажется, переоцениваешь вещи