Web Services: Datenbank-Design

Wenn man den SQL Query Analyzer öffnet und die folgenden SQL-Scripts für die entsprechende Datenbank ausführt, werden die für die beiden Anwendungen erforderlichen gespeicherten Prozeduren erzeugt. Man muss nur aufpassen, dass man Johns Script auch auf Johns Datenbank anwendet und das von Tom auf dessen Datenbank.

• Script für Johns gespeicherte Prozeduren: (Listing D)
• Script für Toms gespeicherte Prozeduren: (Listing E)

Schließlich gibt es noch drei Tabellen, in die Standardwerte eingetragen werden müssen. Die folgenden Scripts fügen einfach einige Standardwerte in bestimmte Tabellen ein, so dass man auch über Daten verfügt, um mit der Anwendung arbeiten zu können:

• Listing F erzeugt die standardmäßigen Werte zur Verfügbarkeit der Bücher. Jedes Buch weist einen entsprechenden Eintrag auf.
• Listing G erzeugt eine Standardliste mit Büchern, die man bestellen kann.
• Listing H erzeugt einen Eintrag für Tom. Da Tom ein Kunde von John ist, muss er in dieser Tabelle vorhanden sein, sonst könnte Tom keine Bestellungen in Johns Anwendung aufgeben

Als Nächstes muss man die DbTier-Klassen für jede Dateneinheit erstellen. Ausgehend von den formulierten Anforderungen gibt es für jede Dateneinheit bestimmte Operationen, die ausgeführt werden müssen. Hierzu fügt man die folgenden Klassen der DbTier-Komponente der jeweiligen Anwendung hinzu:

• Johns Anwendung (Listing I)
• Toms Anwendung (Listing J)

Jeder erstellten Datenbanktabelle ist eine Datenschicht-Klasse zugeordnet. Dies ist die einfachste Möglichkeit zur Modellierung der Datenschicht und sorgt für eine präziser strukturierte Komponente, als wenn man einfach eine willkürliche Reihe von Methoden erstellt, um die gespeicherten Prozeduren auszuführen.

Wenn man genau hinschaut, wird einem das wiederverwendbare Muster auffallen, das in jeder Datenschicht-Klasse zu finden ist. Man kann statische Konstanten zur Repräsentation fast aller Daten in der Datenbank verwenden. Durch die Erstellung einer separaten Klasse für jede Tabelle kann man Variablen an Namen oder Parameter von gespeicherten Prozeduren, Feldnamen etc. binden.

Jede Datenschicht-Klasse weist das folgende Header-Format auf:

• Namen von gespeicherten Prozeduren: Hier definiert man die Namen für jede gespeicherte Prozedur, die von der Klasse ausgeführt werden kann. Sollte sich der Name einer gespeicherten Prozedur jemals ändern, muss man diese Änderung nur an einer Stelle vorzunehmen.
• Parameter von gespeicherten Prozeduren: Für jeden Parameter legt man Namen und Größe fest. Wieder braucht man dank der Verwendung von Konstanten eventuelle Änderungen von Werten nur an einer Stelle vorzunehmen, z. B. wenn sich die Feldlänge von 10 auf 15 Zeichen ändert, statt hierfür alle Methoden durchforsten zu müssen.
• Feldnamen: Die öffentlichen Konstanten erlauben anderen Komponenten den Zugriff auf die Feldnamen der Tabelle, die durch diese Klasse repräsentiert wird. Man kann diese Konstanten benutzen, um Daten per Namen aus einem Datensatz zu extrahieren, statt mit Indizes arbeiten zu müssen.

In jeder Methode referenziert man einfach diese Konstanten, um die gespeicherten Prozeduren auszuführen und diesen Werte zu übergeben. Die Einfachheit und Wiederverwendbarkeit dieses Designmusters sorgt für einen äußerst entwicklerfreundlichen Code. Dieses Format wird für jede Datenschicht-Klasse benutzt und kann auf fast jede durchschnittlich große Anwendung angewandt werden.

Ein weiterer Vorteil ist, dass man nicht auf die Beziehungen von Fremdschlüsseln achten muss. Falls eine Klasse einen Fremdschlüssel zu einer anderen Tabelle benötigt, referenziert man einfach die Datenschicht-Klasse des Fremdschlüssels und greift auf die gewünschte ID zu. Um z. B. OrderId aus der Datenschicht-Klasse Customer zu verwenden, benutzt man OrderDb.PARAM_ORDER_ID_NAME. Die Datenschicht-Klassen müssen über ihre Beziehungen zu anderen Dateneinheiten nicht Bescheid wissen.