Введение
Создание отличной семантической модели — одна из наиболее важных задач, которую может выполнять аналитик данных в Microsoft Power BI. Хорошо выполняя эту работу, вы помогаете людям понять ваши данные, что облегчает вам и им создание важных отчетов Power BI.
Страницы в этом модуле являются иллюстративными, а файлы данных не предоставляются. У вас есть возможность работать с реальными данными в лабораториях.
Хорошая семантическая модель обеспечивает следующие преимущества:
исследование данных выполняется быстрее;
проще строить агрегаты;
отчеты более точные;
создание отчетов занимает меньше времени;
отчеты легче поддерживать в будущем.
Предоставление правил набора для того, что делает хорошую семантику модели, сложно, так как все данные различаются, и использование этих данных меняется. Как правило, меньшая семантическая модель лучше, так как она работает быстрее и будет проще в использовании. Однако определение того, что влечет за собой меньшая семантическая модель, в равной степени проблематично, так как это эвристическая и субъективная концепция.
Как правило, семантическая модель меньшего размера состоит из меньшего количества таблиц и меньше столбцов в каждой таблице, которую может видеть пользователь. Если вы импортируете все необходимые таблицы из базы данных продаж и получите всего 30 таблиц, пользователь вряд ли сочтет такую модель интуитивно понятной. Сворачивание этих таблиц на пять таблиц делает семантическую модель более интуитивно понятной для пользователя, а если пользователь открывает таблицу и находит 100 столбцов, это может оказаться слишком большим. Удаление ненужных столбцов для предоставления более управляемого числа повышает вероятность того, что пользователь прочитает все имена столбцов. Подводя итог, следует стремиться к простоте при проектировании семантических моделей.
На следующем рисунке показан пример семантической модели. В прямоугольниках находятся таблицы данных, где каждая строка представляет столбец. Линии, соединяющие прямоугольники, представляют отношения между таблицами. Эти отношения могут быть сложными, даже в такой упрощенной модели. Семантическая модель может легко деорганизоваться, и общее число таблиц в модели может постепенно увеличиваться. Для обеспечения простой, комплексной и точной семантической модели требуются постоянные усилия.
Отношения между таблицами определяются с помощью первичных и внешних ключей. Первичные ключи — это столбцы, которые идентифицируют каждую уникальную непустую (не NULL) строку данных. Например, в таблице Customers может быть индекс, который идентифицирует каждого уникального клиента. Первая строка имеет идентификатор 1, вторая строка — идентификатор 2 и т. д. Каждой строке присваивается уникальное значение, по которому можно ссылаться на эту строку. Это значение и есть первичный ключ. Этот процесс становится важным, когда вы ссылаетесь на строки в другой таблице, что и делают внешние ключи. Отношения между таблицами формируются, когда у вас есть первичные и внешние ключи, общие для разных таблиц.
Power BI позволяет строить отношения из таблиц с разными источниками данных. Это мощная функция, которая позволяет извлекать одну таблицу из Microsoft Excel, а другую — из реляционной базы данных. Затем необходимо создать связь между этими двумя таблицами и рассматривать их как единую семантиковую модель.
Теперь, когда вы узнали о связях, составляющих схему данных, вы можете изучить конкретный тип схемы, схему star, оптимизированную для высокой производительности и удобства использования.
Схемы типа "звезда"
Схему типа "звезда" можно спроектировать для упрощения данных. Хотя этот способ упрощения данных не единственный, он очень распространен, поэтому каждый специалист по анализу данных Power BI должен его понимать. В схеме star каждая таблица в семантической модели определяется как измерение или таблица фактов, как показано в следующем визуальном элементе.
Таблицы фактов содержат значения данных наблюдений или событий: заказы на продажу, количество продуктов, цены, даты и время транзакций, а также количества. Таблицы фактов могут содержать повторяющиеся значения. Например, один продукт может быть указан несколько раз в нескольких строках для разных клиентов в разные даты. Эти значения можно агрегировать для создания визуальных объектов. Например, визуальный объект, представляющий общее количество заказов на продажу, является совокупностью всех заказов на продажу в таблице фактов. В таблицах фактов часто встречаются столбцы, заполненные числами и датами. Числа могут быть единицами измерения, такими как сумма продаж, или ключами, такими как идентификатор клиента. Даты представляют зарегистрированное время, например дату заказа или дату отгрузки.
Таблицы измерения содержат сведения о данных в таблицах фактов: продукты, местоположения, сотрудники и типы заказов. Эти таблицы связываются с таблицей фактов с помощью ключевых столбцов. Таблицы измерения используются для фильтрации и группирования данных в таблицах фактов. Таблицы фактов, с другой стороны, содержат измеримые данные, такие как продажи и доход, и каждая строка представляет собой уникальное сочетание значений из таблиц измерений. Для визуального объекта, представляющего общее количество заказов на продажу, можно группировать данные, чтобы увидеть общее количество заказов на продажу по продуктам, где продукты являются данными в таблице измерения.
Таблицы фактов намного больше таблиц измерений, так как в таблицах фактов происходят многочисленные события, например отдельные продажи. Таблицы измерения обычно меньше, потому что вы ограничены количеством элементов, которые можно фильтровать и группировать. Например, год содержит только столько месяцев, а США состоят только из определенного количества состояний.
Учитывая эту информацию о таблицах фактов и таблицах измерения, вы можете задаться вопросом, как создать этот визуальный объект в Power BI.
Соответствующие данные находятся в двух таблицах, Employee и Sales, как показано в следующей семантической модели. Так как таблица Sales содержит значения заказов на продажу, которые можно агрегировать, она считается таблицей фактов. Таблица Employee содержит конкретные имена сотрудников, по которым фильтруются заказы на продажу, поэтому это таблица измерения. Столбец EmployeeID является общим для этих двух таблиц и первичным ключом в таблице Employee, поэтому вы можете установить отношение между двумя таблицами на основе этого столбца.
При создании этого отношения можно построить визуальный объект в соответствии с требованиями, как показано на следующем рисунке. Если бы вы не установили это отношение, учитывая соответствие между этими двумя таблицами, вам было бы гораздо труднее построить визуальный объект.
Схемы типа "звезда" и базовая семантическая модель являются основой организованных отчетов; Чем больше времени вы тратите на создание этих подключений и проектирование, тем проще будет создавать и обслуживать отчеты.