Modelar relações

Este artigo discute o processo de modelagem para ajudá-lo a projetar suas soluções de armazenamento de Tabela do Azure.

A construção de modelos de domínio é uma etapa fundamental no projeto de sistemas complexos. Normalmente, você usa o processo de modelagem para identificar entidades e as relações entre elas como uma forma de entender o domínio de negócios e informar o design do seu sistema. Esta seção se concentra em como você pode traduzir alguns dos tipos de relacionamento comuns encontrados em modelos de domínio para designs para o serviço Tabela. O processo de mapeamento de um modelo de dados lógico para um modelo de dados físico baseado em NoSQL é diferente daquele usado ao projetar um banco de dados relacional. O design de bancos de dados relacionais normalmente pressupõe um processo de normalização de dados otimizado para minimizar a redundância – e um recurso de consulta declarativa que abstrai como a implementação de como o banco de dados funciona.

Relações um-para-muitos

As relações um-para-muitos entre objetos de domínio de negócios ocorrem 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 uma com prós e contras que podem ser relevantes para o cenário específico.

Considere o exemplo de uma grande corporação multinacional/regional com dezenas de milhares de departamentos e entidades de funcionários, onde cada departamento tem muitos funcionários e cada funcionário está associado a um departamento específico. Uma abordagem é armazenar entidades separadas de departamentos e funcionários, como estas:

Este exemplo mostra uma relação implícita 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ários relacionadas na mesma partição. Você pode optar por usar partições, tabelas ou até mesmo contas de armazenamento diferentes para os diferentes tipos de entidade.

Uma abordagem alternativa é desnormalizar seus dados e armazenar apenas entidades de funcionários com dados de departamento desnormalizados, conforme mostrado no exemplo a seguir. Neste cenário específico, essa abordagem desnormalizada pode não ser a melhor se você tiver um requisito para poder alterar os detalhes de um gerente de departamento, porque para fazer isso você precisa atualizar todos os funcionários do departamento.

Para obter mais informações, consulte o 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 armazenar entidades de funcionários e departamentos que têm um relacionamento um-para-muitos. Você também deve considerar a frequência com que espera executar várias operações: pode ser aceitável ter um design que inclua uma operação cara se essa operação acontecer com pouca frequência.

Abordagem	Prós	Contras
Tipos de entidade separados, mesma partição, mesma tabela	Você pode atualizar uma entidade de departamento com uma única operação. Você pode usar uma Transação de Grupo de Entidades* (EGT) para manter a consistência se tiver um requisito para modificar uma entidade de departamento sempre que atualizar/inserir/excluir uma entidade de funcionário. Por exemplo, se você mantiver uma contagem de funcionários departamentais para cada departamento.	Talvez seja necessário recuperar um funcionário e uma entidade de departamento para algumas atividades do cliente. As operações de armazenamento acontecem na mesma partição. Em volumes de transações elevados, isso pode resultar em um ponto crítico. Não é possível transferir um funcionário para um novo departamento usando um EGT.
Tipos de entidade separados, partições ou tabelas diferentes ou contas de armazenamento	Você pode atualizar uma entidade de departamento ou entidade de funcionário com uma única operação. Em altos volumes de transações, isso pode ajudar a distribuir a carga por mais partições.	Talvez seja necessário recuperar um funcionário e uma entidade de departamento para algumas atividades do cliente. Não é possível usar EGTs para manter a consistência ao atualizar/inserir/excluir um funcionário e atualizar um departamento. Por exemplo, atualizar uma contagem de funcionários em uma entidade de departamento. Não é possível transferir um funcionário para um novo departamento usando um EGT.
Desnormalizar em tipo de entidade única	Você pode recuperar todas as informações de que precisa com uma única solicitação.	Pode ser caro manter a consistência se você precisar atualizar as informações do departamento (isso exigiria que você atualizasse todos os funcionários de um departamento).

*para obter mais informações, consulte Transações de grupo de entidades

A forma como você escolhe entre essas opções e quais dos prós e contras são mais significativos depende dos cenários específicos do seu aplicativo. Por exemplo, com que frequência você modifica entidades de departamento; fazer todas as suas consultas de funcionários precisam de informações departamentais adicionais; Quão perto você está dos limites de escalabilidade em suas partições ou sua conta de armazenamento?

Relações um-para-um

Os modelos de domínio podem incluir relações um-para-um entre entidades. Se você precisar implementar uma relação um-para-um no serviço Tabela, também deverá escolher como vincular as duas entidades relacionadas quando precisar recuperá-las. Esse link pode ser implícito, baseado em uma convenção nos valores de chave, ou explícito armazenando um link na forma de valores PartitionKey e RowKey em cada entidade para sua entidade relacionada. Para uma discussão sobre se você deve armazenar as entidades relacionadas na mesma partição, consulte a seção Relações um-para-muitos.

Há também considerações de implementação que podem levá-lo a implementar relações um-para-um no serviço Tabela:

• Manipulação de entidades grandes (para obter mais informações, consulte Padrão de entidades grandes).
• Implementando controles de acesso (para obter mais informações, consulte Controlando o acesso com assinaturas de acesso compartilhado).

Junte-se ao cliente

Embora existam maneiras de modelar relacionamentos no serviço Tabela, você não deve esquecer que os dois principais motivos para usar o serviço Tabela são escalabilidade e desempenho. Se você achar que está modelando muitos relacionamentos que comprometem o desempenho e a escalabilidade de sua solução, você deve se perguntar se é necessário criar todos os relacionamentos de dados em seu design de tabela. Você pode simplificar o design e melhorar a escalabilidade e o desempenho de sua solução se permitir que seu 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, poderá recuperar esses dados uma vez e armazená-los em cache no cliente. Isso pode evitar viagens de ida e volta repetidas para recuperar os mesmos dados. Nos exemplos que analisamos neste guia, o conjunto de departamentos em uma organização pequena provavelmente será pequeno e mudará com pouca frequência, tornando-o um bom candidato para dados que o aplicativo cliente pode baixar uma vez e armazenar em cache 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 comerciais, você pode facilmente persistir essas entidades no serviço Tabela. Por exemplo, você pode ter o seguinte conjunto de classes definidas em seu aplicativo cliente, onde Person é uma classe abstrata.

Você pode persistir instâncias das duas classes concretas no serviço Table usando uma única tabela Person usando entidades com esta aparência:

Para obter mais informações sobre como trabalhar com vários tipos de entidade na mesma tabela no código do cliente, consulte a seção Trabalhando com tipos de entidade heterogêneos mais adiante neste guia. Isso fornece exemplos de como reconhecer o tipo de entidade no código do cliente.

Próximos passos

• Padrões de design de tabela
• Design para consulta
• Criptografar dados da tabela
• Design para modificação de dados