Моделирование отношений

В этой статье рассматривается процесс моделирования при разработке решений хранилища таблиц Azure.

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

Отношения "один ко многим"

Отношения "один-ко-многим" между бизнес-объектами являются распространенными. Например, в одном отделе работает много сотрудников. Существует несколько способов реализации отношений «один-ко-многим» в службе таблиц, каждый со своими преимуществами и недостатками, которые могут иметь определенное значение в конкретном сценарии.

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

В этом примере демонстрируется явное отношение «один-ко-многим» между типами на основе значения PartitionKey . В каждом отделе может работать много сотрудников.

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

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

Дополнительные сведения см. в разделе Шаблон денормализации.

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

Подход	Плюсы	Минусы
Отдельные типы сущностей, один раздел, одна таблица	Сущность отдела можно обновить с помощью одной операции. Если вам нужно изменять сущность отдела при каждом обновлении, вставке или удалении сущности сотрудника, в целях обеспечения согласованности можно использовать транзакции группы сущностей* (EGT). Например, в случае поддержки осведомленности о количестве сотрудников в каждом отделе.	Для некоторых действий на стороне клиента может потребоваться получить сущность как сотрудника, так и отдела. Операции хранения выполняются в одном разделе. При значительных объемах транзакций это может привести к формированию активной области. Транзакции группы сущностей нельзя использовать для перемещения сотрудника в другой отдел.
Отдельные типы сущностей, разные разделы или таблицы, или учетные записи хранилища	Сущность отдела или сущность сотрудника можно обновить с помощью одной операции. При значительных объемах транзакций это может помочь распределить нагрузку по нескольким разделам.	Для некоторых действий на стороне клиента может потребоваться получить сущность как сотрудника, так и отдела. Транзакции группы сущностей нельзя использовать для обеспечения согласованности при обновлении, вставке или удалении сотрудника или обновлении отдела. Например, для обновления количества сотрудников в сущности отдела. Транзакции группы сущностей нельзя использовать для перемещения сотрудника в другой отдел.
Денормализация в один тип сущности	Все необходимые данные можно извлечь с помощью одного запроса.	Если требуется обновить сведения об отделе (будет необходимо обновить всех сотрудников в отделе), обеспечение согласованности может оказаться ресурсоемким процессом.

* Дополнительные сведения см. в разделе Транзакции группы сущностей.

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

Отношения «один-к-одному»

В модель предметной области могут входить отношения между сущностями «один-к-одному». Чтобы реализовать отношение «один-к-одному» в службе таблиц, необходимо выбрать способ привязки двух связанных сущностей, если потребуется извлечь их обе. Эта связь может быть либо неявной (на основе соглашения в значениях ключа), либо явной с сохранением связи в форме значений PartitionKey и RowKey в каждой сущности. Сведения о необходимости хранения связанных сущностей в одном разделе см. в разделе Отношения "один-ко-многим".

Есть также ряд аспектов, которые могут привести к реализации отношений "один-к-одному" в службе таблиц.

• Обработка сущностей большого размера (дополнительные сведения см. в статье Шаблон для сущностей больших размеров).
• Внедрение средств управления доступом (см. раздел "Управление доступом с помощью подписей общего доступа").

Присоединение клиента

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

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

Отношения наследования

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

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

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

Следующие шаги

• Шаблоны для разработки таблиц
• Разработка для запросов
• Шифрование данных таблиц
• Разработка для изменения данных