Die Datenbank verfeinern – der letzte Schliff vor dem Einsatz

Unsere Datenbank ist jetzt ähnlich wie ein Rohbau einzugsbereit und wartet darauf, mit Daten gefüllt zu werden. Den Vergleich mit dem Rohbau habe ich absichtlich gewählt, denn obwohl man die Datenbank schon benutzen könnte, sollte man sich vielleicht noch ein paar Gedanken darüber machen.

Die Tabellen können alle relevanten Daten aufnehmen, die Voraussetzungen für die dritte Normalform sind erfüllt, jede Tabelle hat einen Primärschlüssel, der sie eindeutig identifizierbar macht.

Solange die Datenbank von einer Person gepflegt wird, wird sie auch sehr gut funktionieren, was aber passiert, wenn mehrere Personen mit der Datenbank zur gleichen Zeit arbeiten?

Das einfachste Beispiel, zwei Personen sind damit beschäftigt Kunden anzulegen. Jede der beiden Personen hat 10 Kundendatensätze vor sich liegen und will diese nun anlegen. Wie wird die Kundennummer vergeben? Natürlich in diesem Beispiel, könnte man noch eine Aufteilung außerhalb des Systems vornehmen, indem man der ersten Person den Kundennummernkreis von 1 bis 10 und der zweiten Person den Kreis von 11 bis 20 zuordnet.

Kommen jetzt aber neue Datensätze hinzu, oder reizt einer der beiden auf Grund einer Stornierung seinen Nummernkreis nicht aus, können Inkonsistenzen entstehen.
Es wäre doch von Vorteil, würde der SQL-Server selbst die Verteilung übernehmen und die nächste freie Nummer automatisch wählen.

Das geht einfacher als man meinen möchte. Wir müssen der Tabelle mitteilen, dass wir etwas an ihr ändern möchten und legen dann fest, dass die Kundennummer sich mit jedem neuen Eintrag automatisch um 1 erhöhen soll.

ALTER TABLE kunde MODIFY kd_nr SMALLINT UNSIGNED AUTO_INCREMENT

mit ALTER TABLE kunde wählen wir die Tabelle aus und teilen dem SQL-Server mit, dass eine Änderung vorgenommen werden soll (mit diesem Aufruf können auch Primär- Fremdschlüssel nachträglich geändert werden), die Anweisung MODIFY gibt genau an, welches Attribut verändert werden soll. Wir wollen die kunden_nr anpassen, dazu führen wir den DATENTYP auf und fügen das Argument AUTO_INCREMENT hinzu.

Ein Inkrement, ist eine Funktion, die einen vorhandenen Wert um einen vorher festgelegten Wert erhöht. In der Regel um 1.

Angewandt auf unsere Kundentabelle bekommen wir mit der Describe-Anweisung nun folgende Ausgabe: AutoIncrement

Da nun das Problem geklärt ist, wie der Primärschlüssel weitergeführt wird, sollten wir das natürlich auch auf den anderen Tabellen anwenden.

Einzig bei der Tabelle “Ort” sollten wir von dem Auto_increment absehen. Hier wissen wir ja. welche Werte die PLZ annehmen kann und eine um 1 erhöhte PLZ wäre vielleicht nicht im Sinne unseres Versandhandels.

Man sollte sich also immer im Klaren darüber sein, welche Werte man automatisch erhöhen möchte und welche man lieber selbst einpflegt.

Somit haben wir die erste “Schwachstelle” unseres Entwurfes schon einmal ausgebessert. Natürlich können wir AUTO_INCREMENT auch direkt bei der Erstellung der Tabelle anwenden.

Alle Primärschlüssel sind nun offensichtlich und klar. Wir haben in (fast) jeder Tabelle neben dem Primärschlüssel aber auch noch Attribute, die in anderen Tabellen wiederum einen Primärschlüssel darstellen. Über diese Attribute werden die Tabellen verknüpft. Man hat somit ein “fremdes” Schlüsselattribut in der jeweiligen Tabelle. Das alleine macht aber noch keinen Fremdschlüssel aus. Dieser muss erst zugewiesen werden. Gehen wir zusätzlich davon aus, wir wollen unsere Datenbank vor falschen Eingaben schützen, wie zum Beispiel, einer Bestellung mit einer nicht vorhandenen Kundennummer.

Gehen wir davon aus, es geht eine Bestellung ein und diese wird in der Tabelle bestellungen erfasst. Es werden alle Artikel erfasst, die best_nr wird richtig vergeben, die re_nr wird erstellt, ABER die kd_nr ist nicht in der Tabelle kunden vorhanden. Somit haben wir eine reguläre Bestellung, die keinem Kunden zugeordnet werden kann. Dieses Problem kann mit der richtigen Wahl der Fremdschlüssel elegant gelöst werden.

ALTER TABLE bestellungen ADD FOREIGN KEY (kd) REFERENCES kunden (kd_nr);

Zur besseren Übersicht habe ich hier noch einmal alle Tabellen mit Primärschlüssel (grün) und entsprechendem Fremdschlüssel (gelb) aufgeführt.

TIPP: Speichert euch eure Tabellenentwürfe inkl. Datentypen und Schlüssel immer griffbereit ab, da ihr oft überprüfen müsst, welche Typen und Schlüssel ihr verwendet. Eine gedruckte Ausgabe der Tabellenentwürfe schadet auch nicht. Es macht die Arbeit erheblich einfacher.

 

Fremdschlüssel können ebenfalls auch direkt bei Erstellung einer Tabelle eingetragen werden. Hierfür sieht der Snytax folgendermaßen aus:

CREATE TABLE test_fremdschlüssel
(personen_nummer SMALLINT UNSIGNED AUTO_INCREMENT,
plz SMALLINT UNSIGNED,
name VARCHAR (45),
CONSTRAINT pk_test_fremdschlüssel PRIMARY KEY (personen_nr),
CONSTRAINT fk_plz FOREIGN KEY (plz)
REFERENCES ort
);

WICHTIG bei diesem Vorgehen ist folgendes: Legt man eine Tabelle an und will hier gleich einen Fremdschlüssel zuweisen, MUSS dieser Fremdschlüssel schon als Primärschlüssel in der referenzierten Tabelle existieren, sonst kann er nicht angelegt werden und es folgt eine Fehlermeldung. Dies kann schnell zu Frustrationen führen. Daher ist es einfacher, seine Tabellen anzulegen und die Fremdschlüssel anschließend mit der “ALTER”-Anweisung zu ergänzen.

 

Haben wir all diese Schritte abgearbeitet, sehen unsere Tabellen wie folgt aus:

kunden-richtig

rechnungen-richtig

bestellungen-richtig

artikel-richtig

lieferanten-richtig

ort-richtig

Jetzt haben wir es geschafft, die Datenbank steht.

 

 

 

 

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>