Schritt 1: Identifizieren der Anwendungsfälle und des logischen Datenmodells

Ein Automobilunternehmen möchte ein Verwaltungssystem für Transaktionskomponenten aufbauen, um alle verfügbaren Autoteile zu speichern und nach ihnen zu suchen und Beziehungen zwischen verschiedenen Komponenten und Teilen aufzubauen. Ein Auto enthält beispielsweise mehrere Batterien, jede Batterie enthält mehrere High-Level-Module, jedes Modul enthält mehrere Zellen und jede Zelle enthält mehrere Low-Level-Komponenten.

Im Allgemeinen ist für den Aufbau eines hierarchischen Beziehungsmodells eine Graphdatenbank wie Amazon Neptune eine bessere Wahl. In einigen Fällen ist Amazon DynamoDB jedoch aufgrund seiner Flexibilität, Sicherheit, Leistung und Skalierbarkeit eine bessere Alternative für die hierarchische Datenmodellierung.

Sie könnten beispielsweise ein System erstellen, in dem 80–90 Prozent der Abfragen transaktionaler Natur sind, wofür DynamoDB gut geeignet ist. In diesem Beispiel sind die anderen 10–20 Prozent der Abfragen relational, wo eine Graphdatenbank wie Neptune besser passt. In diesem Fall könnte die Aufnahme einer zusätzlichen Datenbank in die Architektur, um nur 10–20 Prozent der Abfragen zu erfüllen, die Kosten erhöhen. Es erhöht auch den betrieblichen Aufwand, der mit der Wartung mehrerer Systeme und der Synchronisierung der Daten verbunden ist. Stattdessen können Sie diese 10 bis 20 Prozent relationalen Abfragen in DynamoDB modellieren.

Wenn Sie einen Beispielbaum für Fahrzeugkomponenten grafisch darstellen, können Sie die Beziehung zwischen diesen Komponenten besser abbilden. Das folgende Diagramm zeigt eine Abhängigkeitsgrafik mit vier Stufen. CM1 ist die oberste Komponente für das Beispielfahrzeug selbst. Sie besteht aus zwei Unterkomponenten für zwei Beispielbatterien, CM2 und CM3. Jede Batterie hat zwei Unterkomponenten, nämlich die Module. CM2 hat die Module CM4 und CM5 und CM3 hat die Module CM6 und CM7. Jedes Modul hat mehrere Unterkomponenten, nämlich die Zellen. Das CM4-Modul hat zwei Zellen, CM8 und CM9. CM5 hat eine Zelle, CM10. CM6 und CM7 haben noch keine zugehörigen Zellen.

In diesem Handbuch werden dieser Baum und seine Komponenten-IDs als Referenz verwendet. Eine der obersten Komponenten wird als Elternteil bezeichnet und eine Unterkomponente wird als Kind bezeichnet. Beispielsweise ist die oberste Komponente CM1 das Elternteil von CM2 und CM3. CM2 ist das Elternteil von CM4 und CM5. Dadurch werden die Eltern-Kind-Beziehungen grafisch dargestellt.

In der Baumstruktur können Sie das vollständige Abhängigkeitsdiagramm einer Komponente sehen. CM8 ist beispielsweise von CM4 abhängig, das von CM2 abhängig ist, das von CM1 abhängig ist. Der Baum definiert den vollständigen Abhängigkeitsgraphen als Pfad. Ein Pfad beschreibt zwei Dinge:

Ausfüllen der Vorlagen für Geschäftsanforderungen:

Geben Sie Informationen zu Ihren Benutzern an:

Geben Sie Informationen zu den Datenquellen an und wie Daten aufgenommen werden:

Geben Sie Informationen darüber an, wie Daten verbraucht werden: