Microsoft Office Access 2007-Programmierung - Das Handbuch

HINWEIS

tion von Variablen ist hingegen problemlos möglich. Trigger sind im Unterschied zu einer Stored Proce-

dure immer an eine Tabelle gebunden.

Beachten Sie, dass zum Beispiel bei einem DELETE der Trigger nur einmal für alle zu löschenden Daten-

sätze aufgerufen wird! Zur Verwaltung dieser Datenmenge stehen Ihnen innerhalb des Triggers die virtu-

ellen Tabellen deleted und inserted zur Verfügung

1

.

NULL-Value

Mit NULL-Werten werden undefinierte Feldeinträge bezeichnet, z.B. wenn nichts eingetragen wurde. Ver-

wechseln Sie NULL-Werte niemals mit der numerischen Null (0) bzw. einem Leerstring ("")!

Ein NULL-Wert wäre beispielsweise eine fehlende Faxnummer in einem Adressbuch, denn nicht jeder hat

ein Faxgerät bzw. die Faxnummer könnte unbekannt sein.

In Feldern, die Sie als Primary Index verwenden, sind NULL-Werte unzulässig. Sollen trotzdem NULL-Werte

erlaubt sein, verwenden Sie einen eindeutigen Index.

In diesem Zusammenhang sei noch auf die Required-Eigenschaft (Eingabe erforderlich) von Tabellen-

feldern hingewiesen, mit der Sie die Eingabe von NULL-Werten kategorisch unterbinden können. Bei

numerischen Feldern bietet sich unter bestimmten Umständen auch die Vergabe eines Defaultwertes (0)

an.

Cursor und Recordset

Auf diese Begriffe sind Sie in den Kapiteln 6 (DAO) oder 7 (ADO) sicherlich besonders häufig gestoßen. Bei

einem Cursor handelt sich aber keinesfalls um einen »Datensatzzeiger«, wie oft fälschlich angenommen

wird, weil es der Name so suggeriert. Cursor ist vielmehr ein von »Current Set of Records« abgeleitetes

Kürzel, also die »aktuelle Datensatzmenge«. Viele SQL-Anweisungen (SELECT) liefern einen Cursor zu-

rück, d.h. eine bestimmte Anzahl von Datensätzen, also ein Recordset. Bei einem so genannten serverseitigen

Cursor bleibt das Recordset auf dem SQL Server liegen, bei einem clientseitigen Cursor wird es an das

Frontend übertragen.

Normalisieren von Tabellen

Zieht man die Tatsache in Betracht, dass die Lebensdauer der Stammdaten eines Unternehmens im Allge-

meinen weit über die von Hard- und Software hinausgeht, können die aus einem dilettantischen Daten-

bankentwurf resultierenden Verluste gewaltig sein.

Die optimale Aufteilung einer relationalen Datenbank in mehrere Tabellen ist ein schrittweiser Prozess, der

auch als Normalisierung bezeichnet wird. In diesem Kapitel werden wir eine »normalisierte« Datenbank

verwenden, ohne uns über die zweckmäßige Aufteilung der Tabellen einen Kopf gemacht zu haben. Das

hatte seinen guten Grund, denn ein effektiver Datenbankentwurf ist eine ziemlich komplexe Angelegenheit

und für den Einsteiger ziemlich abstrakt und abschreckend. Manche betrachten das Ganze sogar mehr als

Kunst denn als Wissenschaft. Das bedeutet, dass auch die Intuition eine größere Rolle dabei spielt.

1

Gilt für MS SQL Server, andere SQL Server verwenden beispielsweise old und new.

417

Etwas (Datenbank-)Theorie

Kapitel 8: SQL in Theorie und Praxis

Es gibt eine ziemlich abstrakte »Theorie des Datenbankentwurfs«, die allerdings Sache der Fachliteratur ist.

In diesem Zusammenhang sei auf einen gewissen E. F. Codd verwiesen, der 1970 das Modell der relatio-

nalen Datenbank definierte und dafür zwölf Regeln aufstellte. Ziel dieses Abschnitts soll es lediglich sein,

dem Einsteiger einen allgemeinen Überblick zu vermitteln, ohne ihn mit allzu vielen Details zu belästigen.

Wir wollen das am praktischen Beispiel einer Firmen-Datenbank nachvollziehen, deren Ziel das Abspei-

chern von Rechnungsdaten ist.

Ausgangstabelle

Wir notieren zunächst einmal aus dem Stegreif eine erste Version einer Tabelle mit dem Namen RECH-

NUNGEN, in welche wir alle benötigten Informationen hineinpacken (Rechnungsdatum, Rechnungs-

betrag, Kundennummer, Kundenname, Kundenort, Artikelnummer, Artikelname):

ReNr ReDatum ReBetrag KuNr KuName KuOrt ArtNr ArtName

1 12.09.01 1.500 2 Müller Berlin 2, 4, 11 Tisch, Stuhl, Lampe

2 15.10.01 950 5 Schultze München 3 Sofa

3 17.01.02 1.025 1 Mayer Hamburg 2, 4 Tisch, Stuhl

Tabelle 8.2 Rechnungen: Erster Entwurf

Aus Gründen der Übersichtlichkeit bleiben in unserem Beispiel diese Informationen auf das absolute Mini-

mum reduziert (Artikelpreis und -anzahl fehlen zum Beispiel, könnten aber problemlos ergänzt werden).

Nach näherem Hinsehen sticht uns bereits ein gravierender Mangel ins Auge:

In den Feldern ArtNr und ArtName sind mehrfache Merkmalswerte eingetragen. Wenn ein Kunde viele

Artikel kauft, passen diese möglicherweise nicht mehr alle in das dafür vorgesehene Feld. Wir müssen des-

halb die Tabelle umstrukturieren, um die Erste Normalform zu erreichen.

Erste Normalform

Eine Tabelle hat dann die erste Normalform (1NF), wenn sie nur einfache Merkmalswerte enthält.

Durch einfaches Umgruppieren der Daten erreichen wir die 1NF:

ReNr ReDatum ReBetrag KuNr KuName KuOrt ArtNr ArtName

1 12.09.01 1.500 2 Müller Berlin 2 Tisch

1 12.09.01 1.500 2 Müller Berlin 4 Stuhl

1 12.09.01 1.500 2 Müller Berlin 11 Lampe

2 15.10.01 950 5 Schultze München 3 Sofa

3 17.01.02 1.025 1 Mayer Hamburg 2 Tisch

3 17.01.02 1.025 1 Mayer Hamburg 4 Stuhl

Tabelle 8.3 Rechnungen: Erste Normalform

Mit diesem Anblick sollten wir uns aber keinesfalls zufrieden geben, da die gleichen Daten (Adresse des

Kunden, Artikelname) mehrfach abgespeichert sind, es liegen also viele überflüssige Informationen vor,

418