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

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

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

Связи "один ко многим"

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

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

В этом примере показана неявная связь "один ко многим" между типами на основе значения PartitionKey . У каждого отдела может быть много сотрудников.

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

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

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

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

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

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

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

Связи "один к одному"

Модели предметных областей могут включать связи "один к одному" между сущностями. Если необходимо реализовать связь "один к одному" в службе таблиц, необходимо также выбрать способ связывания двух связанных сущностей при необходимости их извлечения. Эта ссылка может быть либо неявной, основанной на соглашении в ключевых значениях, либо явным путем хранения ссылки в виде значений PartitionKey и RowKey в каждой сущности для связанной сущности. Сведения о том, следует ли хранить связанные сущности в одном разделе, см. раздел "Один ко многим".

Существуют также рекомендации по реализации, которые могут привести к реализации связей "один к одному" в службе таблиц:

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

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

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

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

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

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

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

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

Дальнейшие действия

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