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

Замечание

Эта функция сейчас доступна в общедоступной предварительной версии. Эта предварительная версия предоставляется без соглашения об уровне обслуживания и не следует использовать для производственных нагрузок. Некоторые функции могут не поддерживаться или их возможности могут быть ограничены. Дополнительные сведения см. в разделе Supplemental Terms of Use for Microsoft Azure Previews.

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

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

Это важно

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

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

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

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

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

  • Метка, которая определяет эту категорию узла. Например: 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.
  • Сопоставление типов данных между ключевыми столбцами и столбцами внешнего ключа, используемыми в пограничных сопоставлениях. Несогласованные типы вызывают сбои создания пограничных вычислений.

Подсказка

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

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

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

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

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

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

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

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

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

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

Это важно

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

Удаление ненужных свойств

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

Замечание

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

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

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

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

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

Выберите наиболее конкретный тип данных для каждого свойства. Правильные типы повышают эффективность хранения и производительность запросов:

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

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

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

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

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

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

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

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

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

  1. В рабочей области создайте новый элемент графа, который подключается к тому же lakehouse.
  2. В редакторе моделей графа добавьте необходимые типы узлов и типы ребер, включая любые новые или измененные свойства.
  3. Настройте ключевые столбцы и отображения ребер. Убедитесь, что типы данных соответствуют ключевым столбцам и внешним ключевым столбцам.
  4. Выберите "Сохранить " для приема данных и создайте новый граф.
  5. Обновите все наборы запросов, чтобы указать на новый граф.
  6. Убедившись, что новый граф работает должным образом, удалите исходный элемент графа, если он не нужен.

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

  • Last updated on