Гранулярность данных что это
Русские Блоги
Эта статья была одобрена автором Wang Wenkai для публикации в облачном сообществе NetEase.
Добро пожаловать в гостиСообщество Netease CloudЧтобы узнать больше об опыте работы с технологическим продуктом NetEase.
1. Что такое детализация данных?
2. В NetEase есть несколько мест, которые влияют на детализацию данных представления.
1. Какова гранулярность данных?
Мы предполагаем, что есть таблица, которая содержит следующие поля: OrderID, Имя клиента и Продажи. Всего 12 записей:
Details Основные детали
В этих табличных данных OrderID является первичным ключом, поэтому наиболее детальной гранулярностью данных этой таблицы является поле OrderID, поскольку это поле может различать каждую запись в таблице. Так что это можно понять так:
Поле, которое может различать каждую строку данных, называется тончайшей детализацией данных.
В этом примере мы усредняем поле «Продажи». Согласно самой точной детализации данных, мы усредняем все 12 записей.
Я агрегировал весь столбец «Продажи», а затем разделил его на общее количество строк, которое составляет 3 059,00, разделенное на 12. В результате средний объем продаж на одну запись составляет 254,92.
В NetEase, если просто перетащить поле «Продажи» на диаграмму и выбрать «Среднее» для метода агрегирования, не помещая никаких других измерений, вы увидите, что NetEase имеет расчет по умолчанию с самой высокой степенью детализации.
Мы можем видеть, что это то же самое, что разместить «OrderID» на оси Y и затем усреднить «Sales».
Далее мы рассмотрим использование измерения «Имя клиента» в исходных данных, чтобы изменить гранулярность агрегирования «Продажи». Например, я поднял следующие вопросы в NetEase:
Каковы средние продажи на одного клиента?
Теперь мы сначала отсортируем по полю «Имя клиента» и перегруппируем данные в нашей таблице.
Сортировка по имени клиента
Далее сгруппируем все наши заказы по полю «Имя клиента» и подведем итоги по продажам клиента.
То есть, когда в настоящее время вычисляется среднее значение «Продажи», гранулярность расчета меняется с исходного «Идентификатора заказа» на «Имя клиента»,
Когда мы вычисляем агрегацию любой меры, мы используем текущее измерение для разделения данных.
Во-вторых, гранулярность NetEase
Представление может быть просто понято как диаграмма.
На панели данных диаграммы NetEase есть две области, которые могут определять гранулярность вашей диаграммы.
2 Да, панель свойств
1. Это ось X и Y.
Например, я поместил «регион» на ось Y, поле «продажи» на оси X и выбрал «среднее» для метода агрегации «продажи»
Ось X Ось Y Ось X Ось Y Ось X Ось X Ось Y Ось X Ось Y
Тогда вы получите следующую картину, которая эквивалентна среднему значению «продаж» при гранулярности «региона»,
То есть каждая запись в каждой области сначала суммируется, а затем делится на количество строк записи в этой области.
Графики Графики Графики Графики Графики Графики Графики Графики
2. Панель свойств
Панель атрибутов также может разделить детализацию измерения.Например, сначала вы помещаете «прибыль» и «продажи» соответственно на оси X и Y и получаете следующий рисунок, так как отсутствует измерение для разделения двух индикаторов. Он представляет собой сумму продаж и прибыли всех рядов, поэтому он будет объединен в одну точку.
• Отношения между прибылью и продажами 1
Будь то ось X, ось Y или панель свойств, размещение полей в них изменит стиль диаграммы. Есть ли способ поддержать анализ, чтобы свободно определить гранулярность расчета метрики без влияния на гранулярность текущего представления диаграммы?
Это функция вычисления кросс-гранулярности в NetEase. Преимущество CGC заключается в том, что вы можете выполнять это вычисление независимо от размеров текущего представления. Если я перетащу поле на ось X, ось Y или панель свойств, это повлияет на весь вид. CGC позволяет нам устанавливать уровень детализации независимо от текущего представления.
Существует три типа выражений вычисления CGC, а именно: FIXED, INCLUDE и EXCLUDE. В следующей статье я подробно опишу эти три выражения.
NetEase имеет много: Платформа для анализа визуализации больших данных на уровне предприятия, с комплексной безопасностью, мощной производительностью больших данных, расширенным интеллектуальным анализом и удобным совместным доступом.Нажмите для бесплатной пробной версии
Университет Kimball: 10 основных правил многомерного моделирования
Марги Росс (Margy Ross) — Президент Kimball Group.
Соблюдайте следующие правила чтобы гарантировать гранулированность данных, а так же гибкость и доступность информационного ресурса в будущем. Нарушайте правила, и бросайте смятённых пользователей на глухие неприступные стены вашего хранилища данных.
Студенты, посещающие лекции Kimball Group по многомерному моделированию, попросили у меня список «заповедей Kimball» для многомерного моделирования. Воздержимся от использования религиозной терминологии. Поэтому, нижеследующее, добытое методом проб и ошибок, назовём не слишком строгими рекомендациями и правилами «как-ничего-не-сломать».
Правило № 1: Загружайте в многомерные структуры подробные атомарные данные.
С учётом непредсказуемости запросов бизнес-пользователей, для обеспечения всевозможной фильтрации и группировки, многомерные модели должны быть заполнены самыми подробными сведениями какими только возможно. Это тот фундамент, на котором всё будет держаться. Пользователям, как правило, нужно видеть больше одной записи разом. И Вы не можете знать всё то множество произвольных, практически непредсказуемых, вариантов развёртывания/свёртывания элементов отчёта. Если доступны только обобщенные данные, то уже сейчас можно предположить случаи, когда пользователи упрутся в кусок кирпичной стены, при попытке закопаться в детали поглубже. Конечно, для увеличения производительности частых запросов к агрегированным данным, атомарная детализация может быть дополнена сводными многомерными моделями. Но бизнес-пользователи не могут жить только с суммированными данными. Чтобы свободно отвечать на постоянно меняющиеся вопросы, им необходимо как можно больше подробностей, вплоть до кровавых.
Правило № 2: Стройте многомерную модель вокруг бизнес-процессов.
Бизнес-процессы это различные деятельности, осуществляемые в организации и представляют из себя ряд измеряемых событий. Примеры: получение заказов или выставление счетов клиенту. Обычно, бизнес-процессы фиксируют или порождают уникальные, связанные с каждым событием, показатели эффективности. Такие показатели интерпретируются как факты, расфасованные в отдельные (для каждого бизнес-процесса) таблицы атомарных фактов. В дополнение к таблицам фактов отдельного процесса, иногда создаются сводные таблицы фактов, объединяющие данные множества бизнес-процессов в одну таблицу фактов, но с общим уровнем детализации. Повторюсь, сводные таблицы фактов дополняют детализированные таблицы бизнес-процессов, но никак не заменяют их.
Правило № 3: Убедитесь, что каждая таблица фактов связана с таблицей размерностей времени.
Измеряемые события, описанные в Правиле № 2, всегда имеют разнообразные отметки дат, связанные с ними. Например, срез ежемесячного баланса или денежного перевода, зафиксированный до сотых долей секунды. Каждая таблица фактов должна иметь, по крайней мере, один внешний ключ к связанной таблице с размерностями времени. Эта таблица должна быть с гранулярностью в один день, с атрибутами календаря и какими-либо нестандартными характеристиками, которые описывают дату измеряемого события. В качестве примеров: финансовый месяц и указатель корпоративных праздников. Бывает, что в таблице фактов представлены несколько внешних дат-ключей.
Правило № 4: Убедитесь, что все факты в отдельной таблице фактов, одинаковой гранулярности или уровня детализации.
Все таблицы фактов можно классифицировать по трём основным видам гранулярности: транзакционные, периодические срезы, или срезы с накоплением. Независимо от типа гранулярности, каждое измерение в таблице фактов должно быть в точности на одном и том же уровне детализации. Комбинирование фактов из одной таблицы, но представляющих различные уровни детализации, обязательно вызовет путаницу у бизнес-пользователей. А инструменты бизнес-аналитики станут подвержены завышениям, дублированию и другим ошибкам в результатах расчётов.
Правило № 5: В таблицах фактов избавляйтесь от отношений многие-ко-многим.
Поскольку таблицы фактов хранят результаты событий бизнес-процессов, то зачастую они строятся на отношении «многие-ко-многим (M:M) между внешними ключами, так, например, множество продуктов продаются во многих магазинах много дней. Эти поля внешних ключей никогда не должны иметь неопределенных значений (Null). Иногда размерности могут содержать множество значений для единственного события-показателя. Например, множество диагнозов, связанных с посещением организации здравоохранения или множество клиентов, связанных с банковским счетом. В таких случаях, неразумно решать проблему размерностей со множеством значений непосредственно в таблице фактов, поскольку это нарушит нормальную гранулярность измеряемого события. Поэтому, соединение с таблицей фактов, отношением многие-ко-многим, происходит через промежуточную таблицу (Bridge) с двойным ключом.
Правило № 6: Избавляйтесь от отношений многие-к-одному между таблицами размерностей.
Иерархические с фиксированной глубиной отношения многие-к-одному (М:1) между атрибутами, как правило, денормализуются или сворачиваются в плоскую таблицу размерностей. Если Вы провели большую часть карьеры, проектируя модели с сущностными связями для традиционных систем с обработкой транзакций, то сопротивляйтесь инстинктивному стремлению к нормализации отношений М:1 или дроблению на более мелкие подразмерности вида „снежинка“ (прим.пер.: стремитесь к схеме „звезда“). Денормализация размерностей — это и есть игра под названием „многомерное моделирование“.
Множество отношений М:1, представленых в одной таблице размерностей, является общепринятой практикой. Также, в таблице размерностей встречаются отношения один-к-одному, такие как уникальное описание продукта, связанное с кодом продукта. Иногда, в случае очень подробных таблиц размерностей с миллионами строк и часто меняющимися атрибутами свёртки, разрешается иметь отношения многие-к-одному в таблице фактов. Однако, подходить к такому использованию таблицы фактов необходимо очень и очень осторожно, тщательно всё взвесив и обдумав.
Правило № 7: Храните в таблицах размерностей заголовки для отчётов и области значений для фильтров.
Коды и, что более важно, сопутствующие расшифровки и описания, использованные для формирования меток и фильтрующих запросов, должны быть собраны в таблицы размерностей. Не храните поля с непонятными кодами или громоздкие описательные поля непосредственно в таблице фактов. Но, мало просто запихнуть код в таблицу размерностей. Не надейтесь, что они автоматически будут корректно поддерживаться в инструменте BI, а пользователям не будут нужны поясняющие расшифровки. Если это заголовок строки/столбца или фильтр из выпадающего меню, то они должны храниться как атрибут размерности.
Т.к. в Правиле № 5 мы заявили, что внешние ключи таблицы фактов никогда не могут содержать неопределеных значений, то разумно избегать неопределенных значений и в полях атрибутов в таблице размерностей. Заменяйте значение Null в атрибуте на какое-то значение по умолчанию, например, NA или любое другое по вашему вкусу. Вы, как распорядитель(прим.пер.: здесь обыгрывается ситуация с неким слугой или дворецким, а не простым суровым админом) по источнику данных, насколько это возможно, предотвращаете замешательство пользователей.
Правило № 8: Убедитесь, что таблицы размерностей используют суррогатный ключ.
Невыразительные, заданные последовательно суррогатные ключи (за исключением размерности с датами, где приняты более выразительные хронологические ключи (прим.пер.: хотя, по-идее, хронология — это тоже последовательность)) предоставляют ряд эксплуатационных преимуществ. Такие ключи получаются меньшего размера, а это, в свою очередь, уменьшает таблицы фактов и индексы, но повышает производительность. Суррогатные ключи абсолютно необходимы, если Вы сопровождаете изменения атрибута размерности, добавлением новой записи в размерность, при каждом профильном изменении. Даже если Ваши бизнес-пользователи, изначально не планировали визуализировать изменения отслеживаемого атрибута, используя суррогаты вам будет проще внести поправки, если ветер подует в другую сторону. Суррогаты также позволяют привести множество действующих ключей к общему профилю (прим. пер.: имеется ввиду, к некому стандартному виду), а также смягчат последствия неожиданной эксплуатационной деятельности, такой как утилизация устаревших номеров продукта или приобретение другой компании, со своей собственной схемой кодирования.
Правило № 9: Создавайте согласованные размерности для интеграции данных в масштабах предприятия.
Согласованные размерности (также известные, как общие/common, главные/master, стандартные/standard или ссылочные/reference) имеют важное значение для корпоративных хранилищ данных. Однажды загруженные в ETL-систему, а затем повторно использумые во множестве таблиц фактов, согласованные размерности снабжают непротиворечивыми описательными атрибутами все многомерные модели и дают возможность исследовать(drill) и интегрировать между собой данные из множества различных бизнес-процессов. Шинная матрица хранилища данных предприятия (Enterprise Data Warehouse Bus Matrix) является ключевым архитектурным шаблоном для представления основных бизнес-процессов предприятия и связанных с ними размерностей. Повторное использование согласованных размерностей, в конечном итоге, сокращает время выхода на рынок за счет устранения избыточного проектирования и усилий в области разработки; однако, согласованные размерности требуют соблюдения некоторых обязательств (commitment), а также инвестиций в должность распорядителя данных (прим.пер.: это не администратор в привычном понимании, и вообще, может быть даже, не технический специалист, но человек, хорошо знакомый с предметной областью, например, бизнес-аналитик) и систему управления (data stewardship and governance), даже если вам не нужно договариваться со всеми и каждым по каждому атрибуту размерности для достижения полной согласованности.
Правило № 10: Непрерывно соотносите требования с действительностью, чтобы предоставить бизнес-пользователями подходящий DW/BI-инструмент, помогающий им принимать решения.
Разработчики многомерных моделей должны постоянно балансировать между требованиями бизнес-пользователей и, заложенными в фундамент, реалиями имеющегося источника данных. Только в этом случае, производимый проект, будет успешно реализован и, что более важно, имеет реальный шанс пойти в дело и приносить пользу. Соблюдение баланса „требования-против-действительности“ — это сущность жизни для DW/BI-профессионалов, на чём бы Вы не были сосредоточены: многомерных моделях, стратегиях проекта, технических/ETL/BI архитектурах или планах развертывания/обслуживания.
Если Вы регулярно читали наши статьи Intelligent Enterprise, Toolkit books или ежемесячно Design Tips, то эти правила не должны быть для Вас в новинку. Сейчас мы собрали наши правила в единый свод, к которому можно обратиться, когда соберётесь проектировать или перепроверять ваши модели.
Определение гранулярности данных таблиц фактов
Состава измерений, связанных с таблицей фактов;
Состава иерархий измерений, по которым планируется осуществлять анализ данных.
Состав измерений определяется на этапе формирования концептуальной модели данных и уточняется на этапе формирования логической модели. Определить состав измерений таблицы фактов, как правило, достаточно просто, т.к. таблица фактов не создается сама для себя, а создается для использования хранящихся в них данных в процессе принятия определенных решений. В связи с этим, состав аналитических измерений таблиц фактов определяется потребностями бизнеса.
Приведем простой пример. В корпоративном хранилище данных компании, осуществляющей розничную торговлю, с таблицей фактов продаж, как правило, связаны следующие основные измерения: “Время”, “Товар”, “Точки продаж”. Но если в компании действует (или планируется к внедрению) система накопительных карт для покупателей, позволяющих предоставлять скидку в зависимости от общей накопленной суммы покупок, то в таблицу фактов продаж добавляется измерение “Клиент” (хотя измерение “Клиент” почти всегда также является основным).
Решение вопроса гранулярности данных таблицы фактов является зачастую компромиссным с решением вопроса размера корпоративного хранилища данных. Чем более детальные данные мы планируем использовать при анализе, тем больше места они занимают и требуют большего числа вычислительных ресурсов для их обработки. Но при нынешней относительно небольшой стоимости вычислительных ресурсов и систем хранения следует все же придерживаться правила загрузки и хранения самых детальных данных, получаемых из систем-источников. Это позволит избежать в будущем кардинального изменения модели данных хранилища (как следствие, структуры базы данных) и ETL-процессов в случае возникновения необходимости анализа детальных данных.
Дата добавления: 2015-09-12 ; просмотров: 5 | Нарушение авторских прав
Основные понятия многомерных выражений (службы Analysis Services)
Область применения: 
SQL Server Analysis Services 
Azure Analysis Services Power BI Premium
Прежде чем приступить к использованию многомерных выражений (MDX) для выполнения запросов к многомерным данным или для создания выражений MDX в кубе, следует понять соответствующие принципы действия и термины.
Рекомендуется начать с уже известного примера обобщения данных, а затем посмотреть связь с MDX. ниже приведена сводная таблица, созданная в Excel, заполненная данными из Analysis Services образца куба.
Меры и измерения
Куб служб Analysis Services состоит из мер, измерений и атрибутов измерений, которые присутствуют в сводной таблице.
Меры — это находящиеся в ячейках числовые значения данных, выраженные в виде сумм, количеств, процентов, минимальных значений, максимальных значений, средних значений. Значения мер являются динамичными, вычисляются в режиме реального времени согласно переходам пользователя по таблице и работе с ней. В этом примере в ячейках показаны суммы продаж торговых посредников, которые увеличиваются или уменьшаются в зависимости от того, разворачиваются оси или сворачиваются. Для любой комбинации даты (год, квартал, месяц или дата) и территории продаж (группа стран, страна, регион) можно получить значение суммы продаж торговых посредников, вычисленной для данной конкретной ситуации. Другие термины, которые являются синонимами мер, — это факты (в хранилищах данных) и вычисляемые поля (в табличной модели и модели данных Excel).
Измерения находятся на осях столбцов и строк сводной таблицы и определяют значение меры. Измерения аналогичны таблицам в реляционной модели данных. Распространенные примеры измерения — время, география, продукты, клиенты, сотрудники и т. д. В этом примере существует два измерения — «Территория продаж» в строках и «Дата» в верхней части. Однако вы можете легко перетаскивать другие измерения, связанные с компонентом «Продажи торгового посредника», такие как «Рекламные акции» или «Продукты», чтобы просматривать эффективность продаж по этим измерениям. Возможность изучения данных интересными способами зависит от создаваемых измерений и от того, будут ли они связаны с таблицами фактов в источнике данных.
Атрибуты измерения — это именованные элементы в измерении, схожие со столбцами в таблице. В этом примере используются следующие атрибуты измерения «Территория продаж»: «Группа стран» (Европа, Северная Америка, Тихоокеанский регион), «Страна» (Канада, США) и «Регион» (центральный, северо-восточный, северо-западный, юго-восточный и юго-западный).
Каждый атрибут имеет связанный с ним набор значений данных или элементов. В этом примере элементами атрибута «Группа стран» являются Европа, Северная Америка и Тихоокеанский регион. Элементы — это реальные значения данных, принадлежащие атрибуту.
Одним из аспектов моделирования данных является оформление шаблонов и отношений, уже существующих в данных. При работе с данными, входящими в естественную иерархию, как в случае со странами-регионами-городами, это отношение можно оформить путем создания связи атрибутов. Связь атрибутов — это связь типа «один ко многим» между атрибутами, например связь между штатом и городом — в штате есть много городов, но город принадлежит только одному штату. Создание связей атрибутов в модели ускоряет производительность запросов, поэтому рекомендуется создавать их, если они поддерживаются данными. Связь атрибутов создается в конструкторе измерений в SQL Server Data Tools. См. Define Attribute Relationships.
В приложении Excel модель метаданных отображается в списке полей сводной таблицы. Сравните приведенную выше сводную таблицу с расположенным ниже списком полей. Обратите внимание, что список полей содержит компоненты «Территория продаж», «Группа», «Страна», «Регион» (метаданные), тогда как в сводной таблице находятся только элементы (значения данных). Зная, как выглядит значок, можно без труда соотнести части многомерной модели со сводной таблицей в Excel.
Иерархии атрибутов
Нам известно, что при разворачивании и сворачивании уровней по каждой оси значения в сводной таблице изменяются. Почему это происходит? Ответ следует искать в иерархии атрибутов.
Сверните все уровни и обратите внимание на общие итоги для каждого компонента «Группа стран» и «Календарный год». Это значение получено из объекта элемент (Все) в иерархии. Это вычисленное значение всех элементов в иерархии.
Подобные агрегаты предварительно вычисляются и заранее сохраняются. Именно поэтому службам Analysis Services свойственна высокая скорость обработки запросов.
Разверните иерархию и вы увидите самый нижний уровень. Он называется конечным элементом. У конечного элемента в иерархии нет дочерних элементов. В этом примере Юго-Запад является конечным элементом.
Все, что выше этого элемента, называется родительским элементом. США является родительским по отношению к юго-западу.
Компоненты иерархии атрибута
Все эти компоненты работают на формирование понятия иерархии атрибута. Иерархия атрибута представляет собой дерево элементов атрибута, содержащих следующие уровни.
Конечный уровень, содержащий все отдельные элементы атрибута, и все элементы конечного уровня ( конечные элементы).
Промежуточные уровни, если иерархия атрибута является иерархией родительских и дочерних элементов (подробнее об этом позже).
Элемент (Все), содержащий совокупное значение всех дочерних атрибутов. При необходимости можно скрыть или отключить уровень (все), если он не имеет смысла для данных. Например, хотя код продукта является числовым, он не имеет смысла суммировать или усреднить или иным образом агрегировать все коды продуктов.
Иерархии навигации
В сводной таблице (по крайней мере в этом примере) расширение осей строк и столбцов позволяет просмотреть нижние уровни атрибутов. Расширяемая структура достигается за счет навигационных иерархий, создаваемых в модели. В примере модели AdventureWorks измерение «Территория продаж» имеет многоуровневую иерархию, которая начинается с атрибута «Группа стран», затем идет «Страна», а потом — «Регион».
Как видно, иерархии используются для предоставления пути навигации в сводной таблице или других объектов обобщения данных. Существует два основных типа: сбалансированная и несбалансированная.
Сбалансированные иерархии
Сбалансированная иерархия — это иерархия, в которой между верхним уровнем и любым из конечных элементов существует одинаковое количество уровней.
Естественная иерархия — это иерархия, которая естественным образом развивается на основе базовых данных. Распространенным примером является «Страна-Регион-Область», «Год-Месяц-День» или «Категория-Подкатегория-Модель», где каждый подчиненный уровень предсказуемо происходит от родительского.
В многомерной модели большинство иерархии являются сбалансированными и многие из них — естественными.
Следует упомянуть еще один связанный термин моделирования, пользовательская иерархия, часто противопоставляемый иерархиям атрибута. Он просто означает иерархию, созданную разработчиком BI, в отличие от иерархий атрибутов, которые автоматически генерируются службами Analysis Services при определении атрибута.
Несбалансированные иерархии
Неоднородная или несбалансированная иерархия — это иерархия, в которой между элементами верхнего уровня и конечными элементами существует разное количество уровней. Опять же, это иерархия, созданная разработчиком BI, но в данном случае в данных присутствуют пропуски.
В примере модели AdventureWorks «Территория продаж» демонстрирует неоднородную иерархию, поскольку США имеют дополнительный уровень («Регионы»), который не существует для других стран в этом примере.
Ключевые атрибуты
Модели представляют собой наборы связанных объектов, которые для создания ассоциаций используют ключи и индексы. Модели служб Analysis Services не отличаются друг от друга. Для каждого измерения (напомним, что оно эквивалентно таблице в реляционной модели) существует ключевой атрибут. Ключевой атрибут используется в отношениях внешнего ключа к таблице фактов (группе мер). Все неключевые атрибуты в измерении связаны (прямую или косвенно) с ключевым атрибутом.
Часто, но не всегда, ключевой атрибут может быть атрибутом гранулярности. Гранулярность — это уровень детализации или точности в данных. Общий пример является самым быстрым способом понять все значения. Рассмотрим следующие значения данных. Для ежедневных продаж требуются значения дат, заданные для дня. Для квот достаточно указать квартал. Но если аналитические данные содержат результаты состязания из спортивного мероприятия, гран следует указать в миллисекундах. Гран будет представлять уровень точности в значениях данных.
Другой пример: финансовая программа может отформатировать денежные значения во многих десятичных разрядах, в то время как в вашем местном учебном заведении требуются только значения для ближайшего доллара. Чтобы избежать хранения ненужных данных, очень важно понимать смысл грана. Исключение миллисекунд из отметки времени или копеек из суммы объема продаж может сэкономить пространство хранения и время обработки, если подобный уровень детализации не имеет отношения к выполняемому анализу.
Чтобы задать атрибут гранулярности, воспользуйтесь вкладкой «Использование измерений» в конструкторе кубов в SQL Server Data Tools. В примере модели AdventureWorks ключевым атрибутом измерения «Дата» является ключ «Дата». Для компонента «Заказы на продажу» атрибут гранулярности эквивалентен ключевому атрибуту. Для компонента «Цели продаж» уровнем гранулярности является квартал, поэтому атрибуту гранулярности задано значение «Календарный квартал».
Если атрибут гранулярности отличается от ключевого атрибута, все неключевые атрибуты должны быть напрямую или косвенно связаны атрибутом гранулярности. Внутри куба атрибут гранулярности определяет гранулярность измерения.
Область запроса (пространство куба)
Область запроса определяется границами, в пределах которых происходит выбор данных. Ее размеры могут варьироваться от куба целиком (куб является крупнейшим объектом запроса) до ячейки.
Пространство куба — это совокупность элементов иерархий атрибутов куба с мерами куба.
Вложенный куб — это подмножество куба, представляющее отфильтрованное представление куба. Вложенные кубы можно определить в инструкции SCOPE в скрипте вычисления MDX, или в предложении SUBSELECT, или в запросе MDX, или как куб сеанса.
Ячейка — это пространство на пересечении элемента измерения мер и элемента из каждой иерархии атрибута в кубе.
Другие термины моделирования
Этот раздел представляет собой набор концепций и терминов, которые не помещаются в другие разделы, но по-прежнему необходимо знать о.
Вычисляемый элемент — это элемент измерения, который определяется и вычисляется во время обработки запроса. Вычисляемый элемент может быть определен в пользовательском запросе или в скрипте вычисления многомерного выражения и храниться на сервере. Вычисляемый элемент соответствует строкам в таблице измерения, в котором он определен.
Число различных объектов — это особый тип меры, используемый для элементов данных, которые следует подсчитывать только один раз. В примере модели AdventureWorks можно увидеть меры числа различных объектов для компонентов «Заказы через Интернет», «Заказы торгового посредника» и «Заказы на продажу».
Группы мер — это набор, состоящий из одной или нескольких мер. В основном эти группы определяются пользователями и используются для хранения связанных мер вместе. Меры числа различных объектов являются исключением. Они всегда размещаются в специальной группе мер, содержащей только явные меры. Вы не видите группу мер в примере сводной таблицы, но она отображается в списке полей сводной таблицы как именованная коллекция мер.
Измерение мер — это измерение, содержащее все меры в кубе. он не предоставляется в многомерной модели, построенной в SQL Server Data Tools, но она существует только один раз. Поскольку оно содержит меры, все элементы измерения мер, как правило, объединены (обычно по сумме или по числу).
Измерения базы данных и измерения куба. В рамках модели можно определить отдельные измерения, которые затем включаются в любое количество кубов в этой модели. При добавлении измерения в куб оно называется измерением куба. Сам по себе в рамках проекта, как отдельный элемент в обозревателе объектов, называется измерением базы данных. Зачем проводить различие? Это связано с возможностью независимого задания свойств для каждого из типов измерений. В документации по продукту вы увидите оба используемых термина, поэтому важно понимать, что они значат.
Следующие шаги
Получив представление о важных понятиях и терминологии, можно перейти к дополнительным разделам, содержащим дальнейшие сведения об основных принципах работы служб Analysis Services.