Проектирование схемы графа в Microsoft Fabric

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

Используйте эти рекомендации перед началом моделирования в редакторе моделей графа. Пошаговые инструкции по созданию узлов и ребер см. в руководстве по графу. Примеры в этой статье используют пример набора данных Adventure Works.

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

Это важно

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

Необходимые условия

Понятие типов узлов и типов рёбер

Прежде чем разрабатывать схему, ознакомьтесь с этими основными понятиями:

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

  • Метка узла, которая определяет эту категорию узла. Например: Customer. Метка используется в запросах для ссылки на узлы этого типа.
  • Исходная таблица, которая представляет собой таблицу Lakehouse, которая предоставляет исходные данные для типа узла. Например, таблица adventureworks_customers .
  • Ключевой столбец, который однозначно идентифицирует каждый узел. Например: CustomerID_K.
  • Свойства, которые являются столбцами из таблицы, которую можно добавить в качестве атрибутов на каждом узле. Например, FirstName, LastNameи EmailAddress.

Узел — это отдельный экземпляр типа узла — одна строка в исходной таблице. Например, каждая строка в adventureworks_customers становится узлом Customer .

Тип края определяет тип связи между двумя типами узлов. Она состоит из перечисленных ниже элементов.

  • Граничная метка, которая является именем, определяющим эту категорию отношений. Например: purchases.
  • Исходная таблица, содержащая данные связи между источником и целевыми узлами. Например, таблица adventureworks_orders .
  • Тип исходного узла и тип целевого узла, которые соединяет ребро. Например, Customer в качестве источника и Order в качестве целевого объекта.

Ребро — это отдельный экземпляр типа ребра — одна строка в исходной таблице, которая соединяет два конкретных узла.

Замечание

В редакторе моделей графов кнопки "Добавить узел " и " Добавить пограничные кнопки" создают типы узлов и типы ребер, а не отдельные узлы или края.

Определение сущностей и связей

Начните с идентификации сущностей (вещей) и связей (подключений) в данных. Сущности становятся типами узлов. Соединения между сущностями становятся типами связей.

Задайте следующие вопросы о исходных таблицах:

  • Что такое основные сущности? Строки, представляющие различные реальные вещи, являются кандидатами на типы узлов. Например, клиенты, продукты, заказы и сотрудники.
  • Как эти сущности связаны друг с другом? Столбцы, ссылающиеся на строки в другой таблице (внешние ключи), указывают на типы ребер. Например, CustomerID_FK в orders таблице указывает на customers таблицу, которая предлагает моделирование purchases края.
  • Существуют ли внедренные сущности? Столбец в таблице может представлять собой самостоятельную сущность, которую имеет смысл извлечь в отдельный тип узла. Пример см. в разделе "Выбор типов узлов". Пошаговые инструкции см. в разделе Добавление нескольких типов узлов и ребер из одной исходной таблицы.

Выбор типов узлов

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

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

Пример: В наборе данных Adventure Works Country начинается как столбец на таблице employees. Если вам нужно запросить "какие сотрудники живут в той же стране?" или "какие страны имеют больше всего сотрудников?", извлеките Country в свой собственный тип узла. Если вам нужно отобразить только страну сотрудника в качестве метки, оставьте это свойством.

Выбор ключевых столбцов

Для каждого типа узла требуется ключевой столбец (или составной ключ), который однозначно идентифицирует каждый узел. Тщательно выберите ключи:

  • Используйте существующие уникальные идентификаторы из исходных таблиц. Например, CustomerID_K или ProductID_K.
  • Избегайте суррогатных ключей, которые не имеют бизнес-смысла , если не существует естественного ключа. Например, отдайте предпочтение CustomerID перед автоинкрементом номера строки.
  • Используйте составные ключи , если один столбец не гарантирует уникальность. Например, узлу может потребоваться и ProductVersion, и ProductID в качестве ключей для VersionNumber.
  • Сопоставление типов данных между ключевыми столбцами и столбцами внешнего ключа, используемыми в пограничных сопоставлениях. Несогласованные типы вызывают сбои создания пограничных вычислений.

Добавление свойств узла

При создании типа узла выберите свойства из исходной таблицы, которые необходимо включить в тип узла, особенно свойства, для которых правила доступа OneLake Security были применены к базовой исходной таблице.

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

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

Для каждого типа узла сохраняйте только свойства, которые:

  • Требуется для уникальности узла (ключевые столбцы)
  • Используется в WHERE фильтрах или RETURN проекциях в запросах
  • Требуется для последующего анализа или визуализации

Дополнительные сведения о том, как число свойств влияет на производительность запросов, см. в разделе "Возвращать только необходимые свойства".

Выбор типов данных

Выберите типы данных, представляющие исходные значения и операции, выполняемые запросами:

  • Используйте INT для идентификаторов целых чисел и счётов, когда исходные значения числовые.
  • Используйте ZONED DATETIME для меток времени вместо строковых дат.
  • Используйте BOOLEAN для флагов true/false вместо строковых значений, например "yes" или "no".

Полный список поддерживаемых типов см. в разделе "Текущие ограничения" — типы данных.

Выбор типов рёбер

Типы рёбер определяют связи между типами узлов. Каждый тип ребра связывает тип исходного узла с типом целевого узла через исходную таблицу.

Следуйте этим рекомендациям:

  • Используйте описательные метки , которые считываются как глаголы или фразы глаголов. Например, purchases, sells, livesIn, и belongsTo. Хорошо именованный край упрощает чтение запросов.
  • Внимательно рассмотрим направление. Ребра в графе ориентированные. Выберите направление, которое лучше всего представляет реальные отношения. Например, Customer — -- выглядит более естественно, >Order чем Order --приобретеноКем — >Customer.
  • Присвойте разные имена типам связей, которые соединяют разные пары типов узлов. Если и "сотрудник продает заказ", и "клиент покупает заказ" подключаются к Order, назовите их sells и purchases, чтобы не давать им одинаковые метки. Дополнительные сведения см. в разделе об ограничениях на создание сетей типа edge.

Добавление свойств к типам рёбер

Как и узлы, типы ребер начинаются без свойств. При необходимости можно добавить свойства, когда данные описывают саму связь, а не любую конечную точку. Свойства edge наиболее полезны при написании запросов GQL, которые должны фильтровать, агрегировать или возвращать данные о самой связи.

Чтобы добавить свойство, дважды щелкните тип края в редакторе моделей графа, чтобы открыть диалоговое окно редактирования края и выберите "Изменить определение". Выберите "Добавить свойство" и выберите столбцы из исходной таблицы.

Когда добавлять свойства ребра: Если столбец отвечает на вопрос «сколько?», «когда?» или «каким образом?» о связи между двумя узлами, его следует отнести к ребру, а не к одному из узлов.

Пример: В наборе данных Adventure Works ребро соединяет с contains через таблицу Order. Столбцы, такие как OrderQty, UnitPrice и LineTotal, описывают взаимосвязь: сколько единиц товара было в конкретном заказе и по какой цене. Столбцы, такие как OrderDate или ShipDate, которые описывают сам порядок и принадлежат типу узла Order, а не ребру.

Это важно

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

Распространенные шаблоны преобразования таблиц в графы

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

Табличная структура Результат графа Пример
Один ко многим: Родительская таблица и дочерняя таблица с внешним ключом Два типа узлов, подключенные к пограничному типу. Customer -- покупки->Order
Многие ко многим: Посредническая таблица, связывающая две таблицы Пограничный тип между двумя типами узлов. Vendor -- производит-->Product
Внедренная сущность: Столбец, представляющий общую сущность Извлеченный тип узла с краем. Employee -- живёт в-->Country
Иерархии: Цепочка родительских дочерних таблиц Типы узлов, связанные ребрами на каждом уровне. Product -- isOfType-->Subcategory --принадлежит-->Category

Пошаговое руководство по встроенному шаблону сущностей см. в разделе "Добавление нескольких типов узлов и ребер" из одной исходной таблицы.

Изменение схемы графа

Graph не применяет структурные изменения постепенно. При изменении типов узлов, типов рёбер, свойств, ключей или отображений, сохранение существующей модели графа перезагружает все её данные и восстанавливает запрашиваемый граф.

Чтобы изменить схему графа, выполните приведенные действия.

  1. Откройте существующий элемент графа в редакторе моделей графов.
  2. Добавляйте, редактируйте или удаляйте типы узлов, ребер, свойства, ключи и отображения по мере необходимости.
  3. Выберите «Сохранить» для проверки обновлённой модели и загрузки всех данных графа.
  4. После завершения перезагрузки выполните репрезентативные запросы для проверки обновлённой структуры и данных.

Связанный контент

  • Последнее обновление: