Всем привет!

Спасибо всем за помощь в моих преведущих постах!
Новый вопрос по оптимизации структуры куба.
Предлагаю рисунок с фрагментом OLTP базы данных и вариант построения куба.

Атомарная таблица – Article. Грубо говоря в ней хранятся все обьявления, статьи. Анализ ведется на этом атомарном уровне - статьи.
Каждый article имеет связь в mediainstance и через mediainstance со всей другой метадатой.
Metadata представляет собой следующий список:
Section (table Section). Media Name (table media), MediaType (table mediatype), Country(table Country), Region (table region) и так далее.
То есть каждый article связан одновременно со вcеми metadata.Это для того что бы на одном графике можно бы ло бы посмотреть метадату, distributed by другая metadata.
Таблица фактов:
CREATE TABLE [fact_article] (
[record_id] [bigint] IDENTITY (1, 1) NOT NULL ,
[article_id] [numeric](18, 0) NOT NULL ,
[media_id] [numeric](18, 0) NOT NULL ,
[media_type_id] [int] NOT NULL ,
[publication_date_id] [bigint] NOT NULL ,
[section_id] [bigint] NOT NULL DEFAULT ((-1)),
[country_id] [bigint] NOT NULL ,
[region_id] [bigint] NOT NULL DEFAULT ((-1)),
[cod_mediainstance] [numeric](18, 0) NOT NULL ,
[media_instance_circulation] [numeric](18, 0) NULL ,
[eav] [numeric](18, 0) NULL ,
)

То есть как видно из скрипта по созданию fact_article каждый article связан со всеми метадатами вместе. А эти id я нахожу во время вставки в fact_table через inner join всех таблиц (Section, Country..) вместе с mediainstance and article.

Каждая метадата образует dimension.
Но сейчас я задался вопросом что можно здесь оптимизировать. А видимо можно, оставив только один cod_mediainstance и оставив только один dimension, основанный допустим на view который все собирает вместе (Country, Section., Region и mediainstance).
Но вопрос тогда каже мне получить в этом случае один metadata distributed by another?
И уменьшется ли в этом случае количество dimensions ?
Интуитивно чувствую что здесь можно оптимизировать, но пока не знаю как.
У кого будут какие-то идеи ?

Рисунок 2. CUBE

Dmitry Biryukovдля начала можно сделать Optimize Schema в редакторе кубов и поудалять таблицы которые удаляются.
Потом можно с партишинами поиграться и с Storage Design Wizard

А что собственно не устраивиет? Откуда желание оптимизировать возникло?
Optimize Schema сказал что ничего нельзя оптимизировать.
Очень долго делется Rebuild Cube. Порядка 1 часа на 200 тысчах записей в fact table, а предпологается миллионы. В силу разных причин, делаю full rebuild вместе с галочкой Incremental Update Dimension.

Валекне понял смысл делать перестройку куба при каждой загрузке в куб, это следует из "Очень долго делется Rebuild Cube. Порядка 1 часа на 200 тысчах записей в fact table, а предпологается миллионы". Понимаю раз перестроить куб, и потом подгружать данные

К сожалению, такой случай не подходит. В задаче может быть так что данные в fact_table уже не актульны и могут быть удаленны посже. Каждый раз при при перестройке CUBE я чищу fact table на предмет соответсвия текущей ситуации.
Случай каждый день данные добавляются к уже существующим идеален, но к сожалению это не мой случай.