A amostra Northwind da Microsoft utiliza a tabela Detalhes do Pedido para estabelecer uma associação muitos-para-muitos entre Pedidos e Produtos.
Object to relational mapping specifications (ORMs), como ADO.NET Entity Framework e Java Persistence API (JPA), podem mapear as tabelas e os relacionamentos utilizando entidades. No entanto, esta arquitetura não é escalada. Tudo deve estar localizado na mesma máquina ou em um cluster de máquinas caro para uma boa execução.
Para criar uma versão escalável da amostra, as entidades devem ser modeladas de forma que cada entidade ou grupo de entidades relacionadas possa ser particionado com base em uma única chave. Ao criar partições em uma única chave, os pedidos podem ser espalhados entre vários servidores independentes. Para atingir essa configuração, as entidades foram divididas em duas árvores: a árvore Cliente e Ordem e a árvore Produto e Categoria. Neste modelo, cada árvore pode ser particionada de forma independente e, portanto, pode crescer a taxas diferentes, aumentando a escalabilidade.
Por exemplo, Order e Product têm números inteiros separados exclusivos como chaves. De fato, as tabelas Order e Product são realmente independentes uma da outra. Por exemplo, considere o efeito do tamanho de um catálogo, o número de produtos vendidos, com o número total de pedidos. Intuitivamente, pode parecer que ter muitos produtos implica também em ter muitas ordens, mas este não é necessariamente o caso. Se isso fosse verdade, você poderia facilmente aumentar as vendas incluindo mais produtos em seu catálogo. Orders e Products têm suas próprias tabelas independentes. É possível estender mais este conceito para que as ordens e os produtos tenham, cada um, suas próprias grades de dados separadas. Com grades de dados independente, é possível controlar o número de partições e servidores, além do tamanho de cada grade de dados separadamente para que seu aplicativo possa escalar. Se dobrar o tamanho de seu catálogo, a grade dados de produtos deverá ser dobrada, mas a grade de ordens pode permanecer inalterada. O contrário é verdade para um pico de pedidos ou pico de pedidos esperado.
No esquema, um Customer tem zero ou mais Orders, e um Order tem itens de linha (OrderDetail), cada um com um produto específico. Um Produto é identificado pelo ID (a chave do Produto) em cada OrderDetail. Uma única grade de dados armazena Clients, Orders e OrderDetails com o Client como a entidade raiz da grade de dados. É possível recuperar os Clientes pelo ID, mas é necessário obter as Ordens que começam com o ID do Cliente. Então, o ID do cliente é incluído na Ordem como parte de sua chave. Da mesma forma, o ID do cliente e o ID da ordem fazem parte do ID do OrderDetail.
No esquema Category e Product, Category é a raiz do esquema. Com este esquema, os clientes podem consultar os produtos por categoria. Consulte Recuperando e Atualizando Dados com o REST para obter detalhes adicionais sobre as principais associações e sua importância.