Предположим, у меня есть таблицы, как указано ниже. Я пытаюсь создать правильные таблицы фактов.
Если я объединим обе таблицы в одну таблицу фактов, я повторю показатель продаж, поскольку каждая продажа содержит как минимум два элемента (административная плата, уборка и т. д. — количество элементов может варьироваться), которые влияют на общую сумму продажи. Таким образом, для автомобиля 1 общая сумма продаж составит 5000 + 50 + 100. Я также не могу просто агрегировать, потому что продажи необходимо детализировать.
Нужно ли мне создавать две таблицы фактов или мне нужно подходить к этому совершенно по-другому? У меня возник соблазн связать таблицу продажи автомобилей с таблицей начислений по схеме 1:n.
Есть ли у вас какие-либо предложения?
Таблица продажи автомобилей
Таблица заряда
Если вы создаете Fact_Sales_Table, вы должны денормализовать данные и объединить их. Моделирование данных несколько субъективно и основано на требованиях.
Если вам нужна одна таблица фактов о продажах, возможно, подумайте об измерении типа продаж, которое описывает продажу постатейной позиции. Следовательно, в вашу основную таблицу фактов вы должны включить только сумму продаж каждой позиции в расчете на общую транзакцию с автомобилем.
Две таблицы фактов кажутся излишними, если только нет необходимости в разной зернистости или в двух разных таблицах фактов?
Возможно, попробуйте это как часть ваших усилий по моделированию:
Также, возможно, изменить dim_sale на другое имя (я просто что-то собрал)? Я иду по этому пути, так как предполагаю, что в данных есть нечто большее, чем предоставленные вами таблицы/поля.
Другой пример с идеей добавления транзакции "автомобиль" в качестве типа:
Денормализация мер (здесь sale
) - очень плохая идея (как вы заметили), это приведет к сбою вычисления суммы.
Но вам не нужно таким образом объединять две таблицы фактов.
Если ваша основная цель — рассчитать сводки по автомобилям, просто добавьте новый charge_id
(скажем, 100 — с type = sale
) и добавьте данные во вторую таблицу.
Таким образом, таблица фактов будет содержать три строки для car_id = 1
charge_id type amount
14 admin fee 50
15 cleaning 100
100 sales 5000
Первая таблица будет не нужна.
Расчет общей стоимости будет простым суммированием amount
на car_id
.
Вы захотите добавить некоторые другие атрибуты, такие как метки времени бронирования и срока действия.
Вы, безусловно, что-то понимаете, особенно если учесть, что здесь есть только один вариант: сохранить один факт в строке транзакции в соответствии с требованием OP. Транзакция, означающая покупку автомобиля + административный сбор + и т. д. + и т. п., которые затем объединяются. Что меня сбивает с толку, так это то, почему ваш подход подходит ко всем таблицам фактов. Почему бы не поощрять усилия по моделированию с помощью соответствующих размеров? Добавлять и составлять charge_id, а затем добавлять его в Fact кажется плохой практикой. Если модель масштабируется или ее необходимо поддерживать, это создаст проблему. Я думаю, что ваше решение в лучшем случае близорукое.
Справедливости ради, возможно, OP должен предоставить базовую модель, поскольку я не знаю, как были созданы эти две таблицы «фактов».
Любое размерное упражнение должно быть денормализовано в качестве наилучшей практики, не уверен, что именно означает «денормализация мер»? Кроме того, почему ваш факт должен содержать такой атрибут измерения, как тип? Быстрое чтение: kimballgroup.com/data-warehouse-business-intelligence-resources/… или en.wikipedia.org/wiki/Dimensional_modeling. Кроме того, почему вы добавляете ключ измерения, такой как charge_id = 100, не будет ли это еще одним вариантом использования измерения? Я думаю, что главная цель здесь — создать легитимную многомерную модель данных?