Relações de modelagem
Este artigo descreve o processo de modelagem para ajudar você a projetar suas soluções de armazenamento em Tabela do Azure.
A criação de modelos de domínio é uma etapa importante na criação de sistemas complexos. Normalmente, você usa o processo de modelagem para identificar entidades e as relações entre elas, como uma forma de compreender o domínio de negócios e informar o design do seu sistema. Esta seção se concentra em como você pode converter alguns dos tipos de relações comuns encontrados em modelos de domínio em designs para o serviço Tabela. O processo de mapeamento de um modelo de dados lógico para um modelo de dados baseado em NoSQL físico é diferente do usado durante a criação de um banco de dados relacional. Design de bancos de dados relacionais geralmente assume um processo de normalização de dados otimizado para minimizar a redundância – e uma funcionalidade de consulta declarativa que abstrai como a implementação do banco de dados funciona.
Relações um-para-muitos
Relações um-para-muitos entre objetos de domínio de negócios ocorrerem com frequência: por exemplo, um departamento tem muitos funcionários. Há várias maneiras de implementar relações um-para-muitos no serviço Tabela, cada com prós e contras que podem ser relevantes ao cenário específico.
Considere o exemplo de uma grande empresa multinacional/regional com dezenas de milhares de departamentos e entidades de funcionário em que cada departamento tem muitos funcionários e cada funcionário associado a um departamento específico. Uma abordagem é armazenar departamento separado e entidades de funcionário como estes:
Este exemplo mostra uma relação implícita de um-para-muitos entre os tipos com base no valor PartitionKey . Cada departamento pode ter muitos funcionários.
Este exemplo também mostra uma entidade de departamento e suas entidades de funcionário relacionadas na mesma partição. Você pode optar por usar diferentes partições, tabelas ou até mesmo contas de armazenamento para os diferentes tipos de entidade.
Uma abordagem alternativa é desnormalizar seus dados e armazenar apenas entidades de funcionário com dados desnormalizados de departamento, conforme mostrado no exemplo a seguir. Neste cenário específico, essa abordagem desnormalizada pode não ser a melhor se você precisar ser capaz de alterar os detalhes de um gerente de departamento, pois para isso você precisa atualizar todos os funcionários do departamento.
Para saber mais, confira Padrão de desnormalização mais adiante neste guia.
A tabela a seguir resume os prós e contras de cada uma das abordagens descritas acima para o armazenamento de entidades de funcionário e departamento que têm uma relação um-para-muitos. Você também deve considerar a frequência com que pretende executar várias operações: pode ser aceitável ter um projeto que inclui uma operação cara, se essa operação ocorrer apenas raramente.
| Abordagem | Vantagens | Desvantagens |
|---|---|---|
| Separar tipos de entidade, mesma partição, mesma tabela |
|
|
| Tipos de entidade separada, diferentes partições ou tabelas ou contas de armazenamento |
|
|
| Desnormalizar em um único tipo de entidade |
|
|
*para obter mais informações, confira Transações de grupo de entidade
Como escolher entre essas opções e quais os prós e contras são mais significativos, depende de seus cenários específicos do aplicativo. Por exemplo, com que frequência você modifica entidades de departamento; todas as consultas de funcionário precisam de informações departamentais adicionais; a que distância você está dos limites de escalabilidade em suas partições ou em sua conta de armazenamento?
Relações um-para-um
Modelos de domínio podem incluir relações um-para-um entre entidades. Se você precisar implementar uma relação individual no serviço Tabela, também deve escolher como vincular as duas entidades relacionadas, quando precisar recuperá-las. Esse link pode ser implícito, com base em uma convenção nos valores de chave, ou então explícito, armazenando um link na forma dos valores de PartitionKey e RowKey em cada entidade até sua entidade relacionada. Para ver uma discussão sobre a conveniência ou não de armazenar as entidades relacionadas na mesma partição, confira a seção Relações de um-para-muitos.
Também há considerações de implementação que podem levá-lo a implementar relações um-para-um no serviço Tabela:
- Controlando grandes entidades (para obter mais informações, consulte Padrão de grandes entidades).
- A implementação de controles de acesso (para saber mais, consulte Controlando o acesso com assinaturas de acesso compartilhado).
Unindo o cliente
Embora haja maneiras de modelar relações no serviço Tabela, você não deve se esquecer de que os dois motivos principais para usar o serviço Tabela são a escalabilidade e o desempenho. Se você achar que está modelando muitas relações que comprometem o desempenho e a escalabilidade de sua solução, deverá se perguntar se é necessário criar todas as relações de dados no design de tabela. Você poderá simplificar o design e melhorar a escalabilidade e o desempenho de sua solução se permitir que o aplicativo cliente execute as junções necessárias.
Por exemplo, se você tiver tabelas pequenas que contêm dados que não são alterados com frequência, você pode recuperar esses dados uma vez e armazená-los no cliente. Isso pode evitar idas e voltas repetidas para recuperar os mesmos dados. Nos exemplos que examinamos neste guia, o conjunto dos departamentos em uma pequena organização é provavelmente pequeno e alterado raramente, tornando-o um bom candidato para dados que o aplicativo cliente pode baixar uma vez e armazenar como dados de pesquisa.
Relações de herança
Se seu aplicativo cliente usa um conjunto de classes que fazem parte de uma relação de herança para representar entidades de negócios, você poderá persistir facilmente essas entidades no serviço Tabela. Por exemplo, você pode ter o seguinte conjunto de classes definidas em seu aplicativo cliente, em que Pessoa é uma classe abstrata.
Você pode persistir instâncias das duas classes concretas no serviço Tabela usando uma única tabela Pessoa com entidades que têm a seguinte aparência:
Para saber mais sobre como trabalhar com vários tipos de entidade na mesma tabela no código cliente, confira a seção Trabalhando com tipos de entidade heterogênea mais adiante neste guia. Isso fornece exemplos de como reconhecer o tipo de entidade no código do cliente.