Может ли таблица фактов в хранилище данных содержать две одинаковые записи?

Question

Если пользователь заказал один и тот же товар с двумя разными order_id;Заказы создаются с одинаковой гранулярностью даты-часа, например,

order#1 2019-05-05 17:23:21
order#2 2019-05-05 17:33:21

. В хранилище данных мы должны поместить их в две строки, подобные этой ( Вариант 1 ):

| id  | user_key | product_key | date_key | time_key | price | quantity |
|-----|----------|-------------|----------|----------|-------|----------|
| 001 | 1111     | 22          | 123      | 456      | 10    | 1        |
| 002 | 1111     | 22          | 123      | 456      | 10    | 2        |

Или просто поместите их в один ряд с агрегированным количеством ( Вариант 2 ):

| id  | user_key | product_key | date_key | time_key | price | quantity |
|-----|----------|-------------|----------|----------|-------|----------|
| 001 | 1111     | 22          | 123      | 456      | 10    | 3        |

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

Также я однажды прочитал статью, в которой говорится, что, когда все измерения отфильтрованы, в таблице фактов должна быть только одна строка данных.,Если это утверждение верно, выбор будет Option 2 .

Есть ли принцип, на который я могу сослаться?

Answer 1

Концептуально таблицы фактов в хранилище данных должны быть спроектированы с максимально подробной детализацией. Вы всегда можете агрегировать данные от более низкой гранулярности к более высокой, в то время как обратное неверно - если вы объединяете записи, некоторая информация теряется навсегда. Если вам когда-нибудь понадобится это позже (даже если вы не видите его сейчас), вы пожалеете о своем решении.

Я бы рекомендовал следующий подход: в хранилище данных сохраняйте номер заказа как вырожденное измерение. Затем, когда вы публикуете звездообразную схему, вы можете создать предварительно агрегированную версию таблицы (пропустить номер заказа, сгруппировать идентичные записи по дате / часу). Таким образом, вы можете иметь меньшую / более чистую таблицу фактов в вашей многомерной модели, и в то же время сохранить более подробные данные в DW.