Недавно началось внедрение многомерной модели в SSAS. OLTP имеет таблицу, в которой хранятся множественные меры на основе столбцов Attribute и Entity. Столбец атрибутов имеет различные имена измерений. Если в строке значение атрибута равно Dim1, то столбец Entity будет иметь значение Dim1. Аналогично, столбец атрибутов может иметь любое имя измерения и его значение будет находиться в столбце Entity. У нас также есть несколько таблиц, где мы имеем несколько столбцов атрибутов и сущностей. например Атрибут1 и Атрибут2. Оба являются именами измерения, а entity1 и entity2 сохраняют свои соответствующие значения. Меры также зависят от порядка размеров. Чтобы быть конкретным, таблицы хранят значения Value at the Risk (VAR), рассчитанные при различном сжатии. VAR, рассчитанный по фонду и сжатию сектора, отличается от VAR, рассчитанного на Сектор и сжатие фонда. OLTP хранит его как атрибут1 (фонд), атрибут2 (сектор) и сущность1 (значение Фонда) и Entity2 (значение сектора). Запросить это также легко, когда caluse [где attribute1 = 'Fund' и attribute2 = 'Sector'] или [where attribute1 = 'Sector' и attribute2 = 'Fund']
Как это можно эффективно смоделировать в кубе?Многомерная модель SSAS Cube
Мой текущий подход создает таблицу фактов, которая имеет отдельный столбец с ненужным внешним ключом для каждого измерения. Если мне нужно сохранить данные для измерения1, то его значение внешнего ключа будет сохранено в size1 (которое является внешним ключом в таблице Dimension1), другие ключи измерения (размер2, размер3 ..) будут указывать на значение N/A соответствующего измерения.
Как можно улучшить этот подход? За и против ? Как упорядочение размеров может быть достигнуто в конструкции куба
Как сказал SebTHU, было бы полезно, если бы вы могли отредактировать это, чтобы сказать, какие различные бизнес-концепции вы пытаетесь моделировать. Вы упомянули «Сектор», «Фонд» и «VAR» - есть ли еще, или только те? Я думаю, что возможно, что вы слишком сильно основываетесь на структуре базы данных OLTP, когда то, что вам нужно для моделирования, - это бизнес-процессы и концепции, но трудно сказать, когда просто обсуждаете общие параметры. –
Кроме того, если вы думаете, что было бы полезно узнать структуру ваших текущих таблиц, не могли бы вы показать нам фактические структуры (с измененными именами, если вам нужно анонимизировать вещи), а не описывать их? –
@Jo Douglass: Вопрос уже отредактирован. У нас есть несколько таких мер, как ImpliedVol, Vol, VAR и т. Д., А размеры - это Фонд, Символ, Сектор, Подсектор, Страна, Мастерфонд и т. Д. Нам нужна таблица фактов, где эти меры могут храниться для различного сжатия, например, Фонд, Символ, Фонд и Символ, символ и фонд, сектор и фонд. Когда у нас есть сжатие фонда, внешний ключ для другого коментария (размерности) будет указывать на значение N/A этого измерения. Как сохранить порядок заказа (фонд и символ) или (символ и фонд) при получении данных? – 107