В базе данных звездообразной схемы факты обычно собираются и хранятся с наивысшим качеством.
Итак, давайте возьмем пример SalesFact с рисунка 10 в http://www.ciobriefings.com/Publications/WhitePapers/DesigningtheStarSchemaDatabase/tabid/101/Default.aspx
Прямо сейчас,зерна это продукт, время (в день детализации), магазин.
Допустим, вы хотите, чтобы свертывание по месяцам, с предварительной агрегацией (этот конкретный пример вряд ли потребует предварительной агрегации, но если продажибыли детализированы клиентом, поминутно, может потребоваться предварительная агрегация.)
Тогда у вас будет SalesFactMonthly (или добавьте различие зерен в существующую таблицу фактов, поскольку измерения одинаковы - иногда в агрегациивы можете потерять размеры точно так же, как вы можете потерять зерно, например, если вы хотите только по магазину, а не по товару).
ProductID
TimeID (only linking to DayOfMonth = 1)
StoredID
SalesDollars
И вы получите это, выполнив:
INSERT INTO SalesFactMonthly (ProductID, TimeID, StoreID, SalesDollars)
SELECT sf.ProductID
,(SELECT TimeID FROM TimeDimension WHERE Year = td.Year AND Month = td.Month AND DayOfMonth = 1) -- One way to find the single month dimension row
,sf.StoreID
,SUM(sf.SalesDollars)
FROM SalesFact AS sf
INNER JOIN TimeDimension AS td
ON td.TimeID = sf.TimeID
GROUP BY td.Year, td.Month
Что происходит в кубах, так это то, что у вас в основном есть мелкозернистые звезды и предварительные агрегаты - но каждая реализация является проприетарной - иногда вы можете этого не делатьдаже имеют самые точные данные в кубе, поэтому о них нельзя сообщать.Но каждый раз, когда вы захотите нарезать данные, нужно хранить их в этом фрагменте, иначе вы не сможете произвести анализ таким образом.