#data-warehouse #business-intelligence #dimensional-modeling
#хранилище данных #бизнес-аналитика #многомерное моделирование
Вопрос:
Я создаю многомерную модель для анализа продаж, которая имеет факт, называемый продажами, и связана с измерением продукта.
Дело в том, что за каждый день запасы продуктов будут меняться, и эта информация важна для них, чтобы проанализировать, почему конкретный продукт не был продан (например, в день XX / XX продукт 123456 не был продан, потому что на складе не было продуктов).
Я хотел бы знать наилучший вариант моделирования этой ситуации и, если возможно, краткое объяснение того, как это будет работать.
Заранее спасибо!
Ответ №1:
Это довольно широкий дискуссионный вопрос, поэтому вот некоторые обсуждения.
Таблицы измерений
-- Products -----
ProductId
Name
(etc.)
Содержит одну строку для каждого отслеживаемого продукта
ProductID должен быть суррогатным ключом
-- Time --------
TimeId
ReportingPeriod (Q1, week 17, whatever as desired)
(etc.)
Содержит одну строку для каждого отслеживаемого дня.
Как только результаты деятельности за день известны, их можно добавить на склад
Обратите внимание, что TimeId не обязательно должен быть суррогатным ключом
Таблицы фактов
-- Inventory -------------------------
ProductId
TimeId
Как только результаты действий за день известны, их можно добавить на склад
Одна строка (в день) для каждого продукта со списком запасов, доступных на конец этого дня
Но тогда это становится сложным: какие данные необходимы и какие данные доступны? Предполагая, что данные за один день, возможные факты для отслеживания и записи включают:
StartingInventory -- What you had at the start of the day
UnitsReceived -- Units received for storage today
UnitsSold -- Units sold (that cannot be sold again) but not yet shipped
UnitsShipped -- Units shipped (sold or otherwise)
EndingInventory -- Units in stock at end of day
Это быстро усложняется. Опять же, многое зависит от того, какая информация у вас есть и какие вопросы будут заданы вашему складу.
Комментарии:
1. Спасибо за ваше объяснение!! В нашем случае нашей таблицей фактов будут продажи (общее количество проданных продуктов, общая сумма продаж — на продукт, клиента, магазин и т. Д.). Насколько я понимаю, они хотят отслеживать проблему типа «Ок, на прошлой неделе этот продукт продавался примерно по 40 раз в день, а на этой неделе его продажи снизились на 70%. Было ли это потому, что в инвентаре его больше нет? «. Возможно, решение для отслеживания этой информации находится в исторической таблице, но я не уверен, как это будет работать.
2. Другое дело, что в таблице фактов будут другие показатели, такие как средний чек, среднее количество проданных товаров, максимальная уплаченная цена, минимальная уплаченная цена… В этом случае, как было бы лучше, если бы некоторые показатели не имели смысла в факте (например, средний билет на продукт: если факт детализирован по продукту, эта информация будет такой же, как «количество проданных продуктов», верно?)
3. Не совсем уверен, что означает «средний билет». Если это факт, к которому не относится отдельный продукт, создайте отдельную таблицу фактов (возможно, таблица DaySummary, столбец TimeId, итоговые продажи, средний билет и т. Д. ?)
4. Средний чек — это средняя сумма денег, заработанная за общее количество продаж (одна продажа в 3 доллара и одна в 7 долларов, MT = 5 долларов). Мой факт продаж будет иметь некоторые представления: по времени, магазину, продукту, региону, категории (продукта), бренду и т. Д.). Типы анализа, которые мы будем извлекать, такие как «какой продукт был продан больше всего за определенный период времени?» Или «сегодня, какие 10 самых продаваемых продуктов по часам?». Я не уверен, как мне следует структурировать свою таблицу фактов.
5. Звучит как вопрос о зерне. Если вы регистрируете каждую отдельную продажу на своем складе, вы можете рассчитать практически все; если вы сохраняете агрегированные данные (общие продажи за день), вы можете потерять точность (например, продано за час). На самом деле это выходит за рамки этого вопроса.