Связи измерения фактов
Иногда пользователи хотят иметь возможность вводить для мер измерения, которые образуются из элементов данных таблицы фактов, или создавать запросы к таблице фактов для получения специальных дополнительных сведений, таких как номера счетов или номера заказов на покупку, относящихся к конкретным фактам продаж. При определении измерения, основанного на подобных элементах таблиц фактов, оно называется измерением фактов. Измерения фактов также называют вырожденными измерениями. Измерения фактов полезны для группирования строк таблицы фактов, например для выбора всех строк, относящихся к определенному номеру счета. Хотя можно поместить эти сведения в отдельную таблицу измерения в реляционной базе данных, создание такой таблицы измерения не принесет пользы, потому что таблица измерения станет расти так же быстро, как и таблица фактов, что будет лишь порождать дублирование и приведет к необоснованной сложности таблицы.
Измерения фактов, обычно называемые вырожденными измерениями, представляют собой стандартные измерения, составленные из столбцов атрибутов в таблицах фактов, а не из столбцов атрибутов в таблицах измерений. Полезные данные измерений иногда хранятся в таблице фактов с целью снижения дублирования.
Например, на Рисунок 373 приведена таблица фактов FactResellerSales из образца базы данных Adventure Works DW.
Рисунок 373. Пример таблицы фактов с измерениями фактов
Эта таблица содержит данные об атрибутах не только для каждой строки заказа, оформленного посредником, но и для самого заказа. Атрибуты, обведенные на Рисунок 373, идентифицируют данные в таблице «FactResellerSales», которые можно использовать в качестве атрибутов в измерении. В этом случае два дополнительных элемента данных — сопроводительный номер перевозчика и номер заказа на покупку, оформленного посредником, представлены столбцами атрибутов «CarrierTrackingNumber» и «CustomerPONumber». Это весьма полезные сведения. Например, пользователи определенно будут заинтересованы в просмотре статистических сведений (например, суммарной стоимости продуктов) для всех заказов, поставляемых по одному сопроводительному номеру. Однако без измерения данные по этим двум атрибутам не могут быть ни организованы, ни статистически обработаны.
Теоретически можно создать таблицу измерения, использующую те же самые ключевые данные, что и таблица «FactResellerSales», и переместить два остальных столбца атрибутов, «CarrierTrackingNumber» и «CustomerPONumber», в эту таблицу измерения. Однако при этом произойдет дублирование значительной части данных, а также излишнее усложнение хранилища данных с целью представления всего двух атрибутов в отдельном измерении.
Службы Analysis Services позволяют указать, следует данные измерения фактов повторить в MOLAP-структуре измерения (это повышает производительность обработки запросов) или же определить измерение фактов как измерение ROLAP, чтобы сохранить место в хранилище за счет снижения производительности обработки запросов. При хранении измерения в режиме хранения MOLAP все элементы измерения, помимо хранения в секциях группы мер, хранятся в экземпляре служб Analysis Services в крайне сжатой структуре MOLAP. При хранении измерения в режиме хранения ROLAP только определение измерения хранится в структуре MOLAP, сами же элементы измерения запрашиваются из соответствующей реляционной таблицы фактов во время обработки запроса. Выбор подходящего режима хранения зависит от того, как часто обращаются с запросами к измерению фактов, сколько строк возвращает типичный запрос, каковы производительность обработки запроса и стоимость обработки. Определение измерения как ROLAP не требует, чтобы все кубы, использующие это измерение, также хранились в режиме ROLAP.
При определении измерения фактов можно задать связь между этим измерением и группой мер как связь фактов. К связям фактов применяются следующие ограничения:
атрибут гранулярности должен быть ключевым столбцом для измерения, что образует связь «один к одному» между измерением и фактами в таблице фактов;
измерение может иметь связь фактов только с одной группой мер.