L'exemple Microsoft Northwind utilise la table OrderDetail pour établir une association plusieurs-à-plusieurs entre les commandes et les produits.
Les spécifications ORM (Object to relational mapping) comme l'ADO.NET Entity Framework et JPA (Java Persistence API) peuvent mapper les tables et les relations à l'aide d'entités. Mais cette architecture n'est pas évolutive. Pour bien fonctionner, tout doit se trouver sur la même machine ou sur un cluster coûteux de machines.
Pour que puisse être créée une version évolutive de l'exemple, les entités doivent être modélisées de manière à ce que chaque entité ou chaque groupe d'entités en rapport puissent être partitionnées à partir d'une seule clé. De ce fait, les demandes peuvent être réparties entre plusieurs serveurs indépendants. Pour y arriver, les entités ont été divisées en deux arborescences : l'arborescence Customer et l'arborescence Product. Dans ce modèle, chaque arborescence peut être partitionnée de manière indépendante et peut donc croître à des rythmes différents, d'où une plus grande évolutivité.
Par exemple, Order et Product ont tous les deux comme clés des entiers distincts et uniques. Et de fait, la table Order et la table Product sont deux tables réellement indépendantes l'une de l'autre. Par exemple, considérez l'effet de la taille d'un catalogue, le nombre de produits que vous vendez, avec le nombre total de commandes. A première vue, il peut sembler qu'avoir un grand nombre de produits implique d'avoir également un grand nombre de commandes, mais ce n'est pas nécessairement le cas. Si c'était vrai, il suffirait d'ajouter des produits au catalogue pour augmenter les ventes. Les commandes et les produits ont leurs propres tables indépendantes. L'on peut étendre ce concept en imaginant que les commandes et les produits aient chacun leurs propres grilles de données. Avec des grilles de données indépendantes, vous pouvez contrôler le nombre de partitions et de serveurs, en plus de la taille de chaque grille de données séparément afin que votre application puisse évoluer. Si vous doublez la taille du catalogue, vous devez doubler la grille de données de produits, mais la grille des commandes peut rester telle quelle. L'inverse est vrai pour un afflux de commandes.
Dans le schéma, un client a zéro ou plusieurs commandes et une commande a des articles (OrderDetail), chacun avec un produit spécifique. Un produit est identifié par un ID (la clé Product) dans chaque OrderDetail. Une grille de données unique stocke les clients, les commandes et les détails des commande, Customer étant l'entité racine de la grille de données. L'on peut extraire les clients à partir de leur ID, mais l'on doit faire partir les commandes des ID clients. L'ID client est donc ajouté à la commande comme partie de sa clé. De la même manière, l'ID client et l'ID commande font partie de l'ID du détail de commande.
Dans le schéma Category et Product, Category est la racine du schéma. Avec ce schéma, les clients peuvent rechercher des produits à partir de leur catégorie. Voir Extraction et actualisation des données avec REST pour d'autres détails sur les associations de clés et leur importance.