Настройка относительного измерения?

У меня довольно простой сценарий, но очень большой набор данных (используя еще более простой пример ниже, чтобы проиллюстрировать мою проблему).

Допустим, у меня есть куб, состоящий из таблицы стран (фактов), которая имеет одно измерение, называемое континентом.

введите здесь описание изображения

Благодаря этому я могу агрегировать данные по странам по континентам.

Но допустим, в каждой стране есть город:

введите здесь описание изображения

Здесь я не могу назначить измерение континента непосредственно городу, потому что у города нет свойства континента. Это упрощенный пример, и было бы тривиально добавить информацию о стране при заполнении таблицы фактов о городе. Однако мое приложение использует очень большой набор данных, для запроса которого требуется много времени, и я пытаюсь избежать необходимости присоединения к стране, чтобы получить идентификатор континента. Мне нужно иметь возможность написать простой запрос MDX, чтобы получить подсчет населения по стране или по городу.

Как я могу настроить свой куб, чтобы отношения измерений в приведенном выше сценарии можно было установить между городом и континентом, не добавляя идентификатор континента к городу?

Обновить

Как предложил Брайан, я мог бы сделать страну измерением. Вот как я сделал это изначально, и, возможно, я сделал это неправильно, но это было ударом по производительности, потому что: приведенный выше пример прост, но в моем случае у меня есть 15 свойств (таких как континент выше), которые мне нужно агрегировать. мои данные о. Если я создам измерение страны и укажу эти 15 свойств в качестве атрибутов измерения, каждый раз, когда я обрабатываю свой куб, он будет выполнять «выбор отдельного континента из страны» x15 (один раз для каждого атрибута), чтобы получить этот отдельный список континентов. . если таблица Country огромна (в моем случае это представление, состоящее из множества больших таблиц), потребуется очень много времени, чтобы просто получить этот список различных значений для каждого измерения.

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


person Sonic Soul    schedule 26.09.2011    source источник
comment
если таблица Country огромна (в моем случае это представление, состоящее из множества больших таблиц). Это наводит меня на мысль, что либо а) вы читаете данные из оперативного источника данных, либо б) хранилище данных не было спроектировано должным образом. Факт должен быть измеримым процессом, состоящим из показателей (числа, даты, деньги...) и контекста измерения (ключи, связанные с измерениями). Измерение должно быть одной таблицей с кластеризованным первичным ключом и некластеризованным, когда вам нужны отдельные значения. Наличие нескольких источников еще больше усложнит эту задачу.   -  person brian    schedule 27.09.2011
comment
да, я читаю из оперативного источника данных. Этот источник данных считывает данные из действующих и архивных баз данных. выделенное хранилище данных было бы идеальным решением, однако в настоящее время у нас нет ресурсов для создания нового хранилища для этого куба. Я пытаюсь оптимизировать его настолько, насколько могу, работая с тем, что у меня есть.   -  person Sonic Soul    schedule 27.09.2011
comment
может быть полезна таблица сопоставления со ссылкой на ключи/представление   -  person Shiwangini    schedule 24.05.2020


Ответы (1)


Не похоже, чтобы размерная модель была хорошо продумана.

Помощником для решения проблемы может стать Country Dimension. Страна является общей как для страны, так и для города.

Я уверен, что проблема намного сложнее, чем эта, но вы перечислили очень простую проблему.

Насколько я знаю, никакое количество MDX (или любой другой технологии) не может решить проблемы с плохим дизайном. Многомерная модель является основой производительности хранилища данных. Очень важно сделать это правильно заранее.

person brian    schedule 26.09.2011
comment
да, я как бы начал со страны в качестве решения для измерения, но собираюсь разделить таблицы измерений для повышения производительности... обновлю свой вопрос, указав именно то, что я имею в виду. - person Sonic Soul; 27.09.2011