Модели данных в хранилище

  • 7 мин

Без моделирования данных каждый consumer должен выяснить, какие таблицы связаны друг с другом, написать собственную логику агрегирования и угадать значения столбцов. Моделирование данных решает эту проблему путем внедрения структуры, бизнес-логики и документации непосредственно в хранилище. В хранилище Microsoft Fabric вы подготавливаете данные для повышения ясности, определяете связи между таблицами, стандартизируете доступ с помощью представлений и мер, и публикуете семантические модели для создания отчетов. Эти варианты моделирования влияют на каждый подчиненный интерфейс, включая запросы T-SQL, отчеты Power BI и аналитику естественного языка на основе ИИ.

Подготовка данных к использованию

Перед определением связей или добавлением вычислений необходимо очистить то, что видят потребители. Таблицы необработанного хранилища часто содержат промежуточные таблицы, суррогатные ключевые столбцы и внутренние флаги, предназначенные для обработки ETL, а не для анализа. Эти объекты создают шум при просмотре данных потребителями. Подготовка склада для использования предполагает отображение только того, что актуально, и делание этого понятным.

В представлении модели можно выполнить несколько действий, чтобы улучшить пользовательский интерфейс.

  • Скрыть внутренние объекты, такие как промежуточные таблицы, столбцы суррогатных ключей и артефакты ETL, которые загромождают список полей.
  • Переименуйте столбцы , чтобы использовать понятные для бизнеса имена столбцов, в которых имена столбцов хранилища являются техническими или сокращенными. Например, переименуйте CustRgn в Customer Region.
  • Добавьте описания в таблицы и столбцы, чтобы потребители понимали, какие данные представляются без ссылки на внешнюю документацию.

Эти шаги имеют большее значение, чем просто опрятность. Copilot в Power BI и агенты данных Fabric IQ используют имена таблиц, имена столбцов и описания, чтобы интерпретировать вопросы на естественном языке и создавать точные SQL или DAX. Столбец Customer Region с таким описанием, как "Географический регион основного адреса клиента", создает лучшие результаты естественного языка, чем CustRgn без описания.

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

Общие сведения о связях между таблицами

Связь — это логическое соединение между двумя таблицами, которые позволяют фильтровать, группировать и агрегировать между этими таблицами. В схеме звездочки связи соединяют таблицы фактов с таблицами измерений с помощью общих ключевых столбцов.

Например, CustomerKey столбец, который существует как в FactSales, так и в DimCustomer, устанавливает связь, позволяющую анализировать продажи по атрибутам клиента, таким как регион, сегмент или тип учетной записи.

Каждая связь имеет два важных свойства.

  • Кратность описывает, как строки в двух таблицах соответствуют друг другу. В звёздчатой схеме связи между фактами и измерениями обычно имеют тип «многие к одному», что означает, что множество строк фактов сопоставляются с одной строкой измерения.
  • Направление перекрестной фильтрации определяет способ распространения фильтров между таблицами. Однонаправленная фильтрация, при которой размерность фильтрует таблицу фактов, является стандартным параметром для большинства звёздчатых схем, так как она сохраняет предсказуемость поведения фильтра и производительность.

Без определенных связей каждый потребитель, который хочет объединить данные между таблицами, должен писать явную логику JOIN. Связи устраняют это повторение, кодируя связь единожды. При создании семантической модели из хранилища эти связи сообщают о том, как агенты данных Power BI, Copilot и Fabric IQ интерпретируют данные. Например, агенты данных используют связи для создания точных соединений при переводе вопросов естественного языка в SQL.

Примечание.

Большинство хранилищ данных используют моделирование измерений. Связи можно создать для формирования схемы звезды, которая является идеальной моделью для аналитики. Для получения дополнительной информации см. модуль Проектирование размерных моделей в Microsoft Fabric.

Стандартизируйте доступ к данным с помощью представлений и измерений

Теперь, когда таблицы чисты и подключены, следующим шагом является предоставление потребителям надежных, согласованных способов запроса и вычисления данных. Без стандартизации каждая команда пишет собственную логику соединения, применяет собственные фильтры и определяет свои собственные формулы, что приводит к конфликтующим результатам.

Представления обеспечивают эту согласованность для потребителей T-SQL. Представление инкапсулирует логику соединения, фильтры и выбранные столбцы в многократно используемый запрос, используемый потребителями подобно таблице. Например, представление данных, которое объединяет таблицы фактов и измерений, фильтрует завершенные заказы и отображает только те столбцы, которые необходимы аналитикам, предоставляя каждому пользователю T-SQL надежную отправную точку. Представления также служат стабильными источниками данных для отчетов. Вместо создания отчетов непосредственно в базовых таблицах, которые могут измениться, можно направлять отчеты на представления, которые представляют согласованную форму.

Меры обеспечивают ту же согласованность для вычислений DAX. Мера — это повторно используемое выражение DAX, определяющее вычисление, такие как общее, среднее, соотношение или подсчет. Вы создаете меры непосредственно в представлении модели хранилища, выбрав таблицу и добавив новую меру. Например, мера Total Sales, которая суммирует столбец SalesAmount, гарантирует, что каждый потребитель использует одни и те же вычисления.

Так как определение меры живет с данными, оно становится единственным источником истины для этой метрики. Когда бизнес изменяет способ вычисления выручки, вы обновляете меру в одном месте, а не отслеживаете каждый отчет, содержащий собственную формулу.

Вместе представления и меры охватывают обе стороны потребления: представления стандартизуют, как потребители T-SQL получают доступ и запрашивают данные, а меры стандартизируют, как бизнес-расчеты отображаются в отчетах и панелях управления.

Совет

Формулы DAX и расширенный дизайн мер подробно рассматриваются в последующих модулях. Сведения о представлениях и хранимых процедурах см. в предыдущем уроке по запросу и преобразованию данных.

Создание семантической модели для отчетов Power BI

С подготовленными таблицами, определенными связями и стандартизированными представлениями и мерами хранилище данных готово для последующих отчетов. Команды, которые запрашивают хранилище напрямую с помощью T-SQL или подключаются через сторонние инструменты, могут работать с моделью хранилища без изменений. Однако при создании интерактивных отчетов и панелей мониторинга Power BI создание семантической модели является следующим шагом.

Семантические модели, созданные из хранилища Fabric, используют режим Direct Lake. В отличие от традиционного режима импорта, который копирует данные в память Power BI, Direct Lake считывает данные непосредственно из файлов OneLake Parquet. Это означает, что отчеты отражают последние данные хранилища без необходимости запланированных обновлений. Это также означает, что вы избегаете накладных расходов на хранение и обработку содержания отдельной копии данных.

Снимок экрана: отчет Power BI.

Совет

Семантическое проектирование моделей и шаблоны масштабируемости рассматриваются более подробно в Спроектируйте масштабируемые семантические модели. В этом уроке основное внимание уделяется моделированию данных в самом хранилище.