3
я кулачок по этой фразе:Star Schema Fact Не стоит хранить цену - Почему?
Мы всегда стремимся сделать факты Добавка по размерам и точно в соответствии с зерном. Обратите внимание, что мы не храним цену сканируемого продукта , потому что цена неаддитивная. Скорее, мы храним расширенную цену, которую можно бесплатно добавить через товары, магазины, время и все другие размеры.
Источник: Fact Tables - Kimball Site.
Я предполагаю, что факт является продаж таблицы фактов. Я понимаю разницу между аддитивными и неаддитивными мерами.
Цена товара добавка. Эта страница также считает это: SQLBI Fact Table Design.
Я не могу понять приведенное выше обоснование, почему цена не хранится в таблице фактов. Пожалуйста, объясните, можете ли вы это сделать. Спасибо.
В большинстве сценариев цена за единицу не является аддитивной. В данных продаж не имеет смысла суммировать цену за единицу с течением времени или линейку продуктов. Возможно, существуют ситуации, когда цена является полуаддитивной, но они не могут легко задуматься. У вас есть такой пример? Если да, то по каким измерениям вы ожидаете добавить цены на единицу? – sqlvogel
Ссылка на таблицу фактических таблиц SQLBI почти наверняка использует термин «SalesPrice», когда они означают «SalesAmount». Из их примера видно, что это то, что было предназначено, но автор использовал неправильную терминологию. Если вы посмотрите на их пример неаддитивного факта, то они используют «чистую прибыль%». Чистая прибыль арифметически определяется из стоимости единицы продукции и удельной стоимости. Себестоимость также не является дополнительной. Вы не можете вычесть один неаддитивный факт из другого, чтобы получить аддитивный факт. –
@sqlvogel, спасибо за ваш комментарий. У меня нет настоящего примера, но я вижу вашу мысль. Как насчет цены за единицу * Единицы этой комбинации выглядят полезными. Если да, почему бы не получить цену за штуку в таблице фактов? (Если вы хотите переместить свой комментарий в область ответа, я проголосую за него). – NoChance