Дизайн таблицы для данных с множественной степенью детализации

#data-modeling #data-warehouse

#моделирование данных #хранилище данных

Вопрос:

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

2 Структура таблицы

Таблица 1

 TransactionID   Transaction_Dt  ProductID   Items   Cost_Total
11111           1/1/2020        1           10      100
11111           1/1/2020        2           5       200
11111           1/1/2020        3           4       400
11111           1/1/2020        4           5       100
11111           1/1/2020        5           6       600
11111           1/1/2020        6           10      100
 

Таблица 2 (агрегированная)

 TransactionID   Transaction_Dt  Total_Items Cost_Total
11111           1/1/2020        40          1500
 

Структура одной таблицы

Агрегированные данные в таблице

 TransactionID   Transaction_Dt  ProductID   Items   Cost_Total  Type
11111           1/1/2020        1           10      100         ind_Item
11111           1/1/2020        2           5       200         ind_Item
11111           1/1/2020        3           4       400         ind_Item
11111           1/1/2020        4           5       100         ind_Item
11111           1/1/2020        5           6       600         ind_Item
11111           1/1/2020        6           10      100         ind_Item
**11111         1/1/2020        ALL         40      1500        all_Item**
 

Здесь у нас есть одна запись для всей транзакции с суммой всех товаров и суммой всех затрат.

Кто-нибудь может помочь мне в отношении недостатков 2-го подхода, когда у нас есть агрегированные данные в одной таблице

Комментарии:

1. Просто запросите общую стоимость транзакции в вашей объединенной таблице, и вы получите, скорее всего, вдвое больший результат. Этого достаточно для ОТКАЗА .

Ответ №1:

Некоторые мысли по этому поводу:

  1. Я не сторонник хранения данных на нескольких уровнях агрегирования в одной таблице по той причине, которую предложил @Marmite Bomber — если вы выполните select sum и не отфильтруете агрегированные данные, вы получите кратный ответ, который вы ищете.
  2. Если вы все еще хотите поместить все в одну таблицу, я бы добавил еще один столбец, возможно, с именем agg_level, и указал уровень агрегации строки в этой таблице. (вы уже вроде как делаете это со своим столбцом «Тип», хотя «Тип» — очень неоднозначный термин).
  3. Я бы не рекомендовал изменять значение TransactionID (вы предлагаете добавить несколько звездочек, чтобы указать, что это агрегат). Ее изменение затруднит поиск нужной вам таблицы, и пользователям придется понимать вашу нотацию, чтобы получить правильные записи. Если вы добавите столбец agg_level и оставите идентификаторы транзакций в их первоначальном виде, вы можете поместить легко узнаваемый термин в столбец agg_level. Например, запись может содержать «необработанный», или «Общая сумма транзакций», или «Ежемесячный совокупный показатель»…
  4. Если вам нужно поместить свои агрегированные данные в базовую таблицу данных, как вы показали, вам следует рассмотреть возможность создания представлений поверх таблицы, каждое представление предоставляет только детали на одном уровне агрегирования. Скорее всего, вы предоставите пользователям доступ только к этим представлениям, а не к базовым данным. Таким образом, вы храните все данные в одной таблице, но для пользователей это выглядит так, как будто у вас несколько таблиц, и вам не нужно беспокоиться о том, что пользователь случайно неправильно сформирует запрос, который вернет повторяющиеся итоги.

Это хороший вопрос, Снехасиш, и он показывает, что вы над ним подумали. Желаю удачи, когда вы ориентируетесь в будущих потребностях!