Гранулярность в схеме звезд приводит к нескольким значениям в таблице фактов?

Question

Я пытаюсь понять звездную схему в настоящий момент & много борется с детализацией.

Скажите, что у меня есть таблица фактов, в которой есть session_id, user_id, order_id, product_id, и я хочу свернуть сеансы пользователя по неделям (имея в виду, что не каждый сеанс приведет к заказу или продукту & DW необходимо отслеживать сеансы для не-покупающих пользователей, а также тех, кто покупает).

Я не вижу причин для отслеживания order_ids или session_ids в таблице фактов, так что стало бы что-то вроде:

week_date, user_id, total_orders, total_sessions ...

Но как бы я тогда отслеживающие product_ids если пользователь совершает более одной покупки за неделю? Я предполагаю, что не могу хранить несколько идентификаторов продуктов в массиве (например: «20/02/2012», «5», «3», «PR01, PR32, PR22»)?

Я думаю, что его, возможно, нужно держать на уровне «каждая сессия», но это может привести к очень большому количеству данных. Как бы вы применили гранулярность для примера, такого как выше?

Answer 1

Требуется измерение размеров Размеры, а также факты.

Вам нужна дата/календарь измерение, которое включает в себя столбцы, как это:

calendar (id,cal_date,cal_year,cal_month,...) 

«Зерно» вашей таблицы фактов является ключом к хранению данных. Если у вас есть транзакции, транзакция должна быть зерном, и вы сохраняете одну строку за транзакцию. Используйте правильные (целые) суррогатные ключи для ваших измерений, и ваш стол будет не таким большим, как вы боитесь.

Теперь вы можете написать запрос, как это, чтобы подвести продажи продукта в год:

select product_name,cal_year,sum(purchase_amount) 
from fact_whatever 
     inner join calendar on id = fact_whatever.calendar_id 
     inner join product on id = fact_whatever.product_id 
group by product_name,cal_year