Im Beispiel "Microsoft Northwind" wird die Tabelle "Order Detail" verwendet, um eine N:N-Assoziation zwischen "Orders" und "Products" herzustellen.
Mit Hilfe von ORM-Spezifikationen (Object to Relational Mapping) wie ADO.NET Entity Framework und Java Persistence API (JPA) können die Tabellen und Beziehungen über Entitäten zugeordnet werden. Diese Architektur ist jedoch nicht skalierbar. Alle Komponenten müssen sich auf derselben Maschine oder in einem kostenintensiven Maschinencluster finden, um eine angemessene Leistung zu erzielen.
Zum Erstellen einer skalierbaren Version des Beispiels müssen die Entitäten so modelliert werden, dass jede Entität oder Gruppe zusammengehöriger Entitäten auf der Basis eines einzigen Schlüssels partitioniert werden können. Durch die Erstellung von Partitionen auf der Basis eines einzigen Schlüssels können Anforderungen auf mehrere unabhängige Server verteilt werden. Für diese Konfiguration wurden die Entitäten in zwei Baumstrukturen aufgeteilt, in die Baumstruktur "Customer und Order" und in die Baumstruktur "Product und Category". In diesem Modell können beide Baumstrukturen unabhängig voneinander partitioniert werden und deshalb unterschiedlich anwachsen, was die Skalierbarkeit erhöht.
Order und Product haben eindeutige, separate ganze Zahlen als Schlüssel. Die Tabellen "Order" und "Product" sind also voneinander unabhängig. Stellen Sie sich beispielsweise die Auswirkungen der Größe eines Katalogs, d. h. die Anzahl der von Ihnen vertriebenen Produkte, mit der Gesamtanzahl an Bestellungen vor. Intuitiv geht man davon aus, dass das Vorhandensein vieler Produkte bedeutet, dass auch viele Bestellungen vorhanden sind, aber das muss nicht unbedingt der Fall sein. Würde diese Annahme stimmen, könnten Sie Ihre Verkaufszahlen problemlos steigern, indem Sie Ihrem Katalog einfach weitere Produkte hinzufügen. Bestellungen und Produkte haben eigene voneinander unabhängige Tabellen. Sie können dieses Konzept noch erweitern und für Bestellungen und Produkte jeweils eigene separate Datengrids verwenden. Mit unabhängigen Datengrids können Sie die Anzahl der Partitionen und Servern sowie die Größe jedes Datengrids gesondert steuern, so dass Ihre Anwendung skalieren kann. Wenn Sie die Größe Ihres Katalogs verdoppeln, müssen Sie das Produktdatengrid verdoppeln, aber das Grid für die Bestellungen bleibt unverändert. Der umgekehrte Fall gilt für eine Bestellspitze oder eine erwartete Bestellspitze.
In dem Schema hat ein Kunde (Customer) null oder mehr Bestellungen (Order), und eine Bestellung Bestellpositionen (OrderDetail), jeweils mit einem bestimmten Produkt. Ein Produkt (Product) wird in jedem OrderDetail anhand seiner ID (dem Produktschlüssel) identifiziert. Customer, Order und OrderDetails werden in einzigen Datengrid gespeichert, mit Customer als Stammentität des Datengrids. Sie können Kunden nach ID abrufen, müssen Bestellungen aber anhand der Kunden-ID abrufen. Deshalb wird die Kunden-ID der Bestellung im Schlüssel hinzugefügt. Analog dazu sind Kunden-ID und Bestell-ID Teil der OrderDetail-ID.
Im Schema "Category and Product" ist "Category" der Schemastamm. Mit diesem Schema können Kunden Produkte nach Kategorie abfragen. Weitere Einzelheiten zu Schlüsselassoziationen und deren Bedeutung finden Sie unter Daten mit REST abrufen und aktualisieren.