2 Tabellen und Datenmodellierung

Transkript

1 2 Tabellen und Datenmodellierung Dieses Kapitel setzt Kenntnisse im grundlegenden Umgang mit Tabellen voraus. Darauf aufbauend erfahren Sie hier, wie Sie die Anforderungen an die geplante Anwendung in ein adäquates Datenmodell umsetzen. Dabei ist es wichtig, dass die Daten den Objekten der realen Welt entsprechend abgebildet und dazu in Relation gesetzt werden. Dabei helfen die Normalisierungsregeln, die manch einer vielleicht schon intuitiv einsetzt, und eine konsistente Benennung von Tabellen und Tabellenfeldern. Damit Sie nicht nur mit trockener Theorie abgespeist werden, finden Sie im mittleren Teil des Kapitels eine Menge Beispiele für Datenmodelle. Diese können Sie als Basis für eigene Anwendungen oder auch nur als Anregung verwenden. Hintergrund dieses Kapitels ist die Tatsache, dass viele (angehende) Entwickler ins kalte Access-Wasser geworfen werden und keine oder wenig Erfahrung in der Datenmodellierung haben. Zudem findet sich in den meisten Grundlagen-Büchern zu Access meist nur eine Beispielanwendung mit Datenmodell und das hält dann im ganzen restlichen Teil des Buches als Grundlage für Abfrage-, Formular-, Berichts- und VBA-Beispiele her. Dieses Kapitel hat verschiedene Ziele: Einführung einer Konvention für die Namen von Tabellen und Feldern Normalformen: Wozu dienen sie und wie normalisiert man ein Datenmodell? Begriffsklärung (Beziehungsarten, relationale Integrität, Primärschlüssel, Fremdschlüssel) Erläuterung der Beziehungsarten anhand praktischer Beispiele Vermittlung eines Gefühls für die jeweils richtige Beziehungsart anhand einiger Datenmodelle verschiedener Anwendungen Außerdem finden Sie am Ende dieses Kapitels ausführliche Informationen zum Speichern von Dateien und insbesondere von Bildern in Access-Datenbanken.

2 44 2 Tabellen und Datenmodellierung 2.1 Namenskonventionen für Tabellen und Felder Die Namenskonventionen für Tabellen enthalten Vorschläge für die Benennung von Tabellen und der enthaltenen Felder. Die nachfolgenden Abschnitte fassen dabei Elemente der Ungarischen Notation ( und einige weitere Regeln zusammen, die sich bewährt haben und von vielen Entwicklern so oder ähnlich berücksichtigt werden. Details zur Ungarischen Notation finden Sie unter dem oben genannten Link; ein Abdruck der recht umfangreichen Tabellen ist aus Platzgründen leider nicht möglich. Grundsätzlich gelten für die Vergabe von Namen an Access-Objekte, Feldnamen und Steuerelemente folgende Regeln: Der Name darf aus maximal 64 Zeichen bestehen. Der Name kann aus beliebigen Zeichen mit Ausnahme des Punktes (.), Ausrufezeichens (!), Gravis-Akzents (`), einfachen (') und doppelten Anführungszeichens (") und der eckigen Klammern ([]) bestehen. Leerzeichen dürfen nicht am Anfang oder am Ende des Namens stehen. Zu empfehlen ist darüber hinaus, dass Namen von Access-Objekten, Feldern und Steuerelementen gar keine Sonderzeichen enthalten, da Namen mit Sonderzeichen an manchen Stellen eine Spezialbehandlung erfordern beispielsweise müssen Sie diese in SQL-Ausdrücken und in VBA in eckige Klammern einfassen. Verwenden Sie außerdem besser keine Namen, die bereits für ein reserviertes Wort innerhalb von Access, VBA oder referenzierten Objektbibliotheken benutzt werden. Abschreckendes Beispiel ist die Verwendung von»name«als Feldname in Tabellen mit Kontaktdaten diese Bezeichnung ist bereits als Eigenschaft diverser Objekte vergeben. In Zweifelsfällen konsultieren Sie einfach den Objektkatalog und suchen nach dem fraglichen Namen wenn Sie ihn dort nicht finden, können Sie ihn einsetzen. Natürlich können Sie auch Sonderzeichen, Leerzeichen oder bereits als Schlüsselwort verwendete Namen aufgreifen. Sie müssen dann allerdings einige Regeln beachten etwa, dass Sie die Bezeichnungen von Feldern in SQL-Ausdrücken und in VBA in eckige Klammern setzen, wenn diese nicht ohnehin in Anführungszeichen stehen. Warum soll man eine Namenskonvention verwenden? Grundsätzlich können Sie Tabellen und die enthaltenen Felder nennen, wie Sie möchten. Abhängig davon, ob Sie eine Anwendung nur für das stille Kämmerlein oder für jemand anderen entwickeln, sollten Sie jedoch folgende Punkte beachten: Eine feste Systematik bei der Vergabe von Namen für Tabellen und Felder erleichtert Ihnen beim Programmieren das Leben. Wenn Ihre Tabellennamen etwa grund-

3 Namenskonventionen für Tabellen und Felder 45 sätzlich mit»tbl«beginnen und der Plural der darin beschriebenen Objekte angefügt ist, müssen Sie sich beim Referenzieren dieser Tabelle aus Formularen, Berichten oder aus VBA-Modulen niemals Gedanken machen, wie Sie die Tabelle genannt haben, wenn Sie nur wissen, welches Objekt darin beschrieben wird. Präfixe bei Objektnamen erlauben Ihnen auf einfache Weise, ein Objekt am Namen zu erkennen und gleiche Basisnamen für mehrere unterschiedliche Objekttypen zu verwenden. Wenn Sie eine Tabelle beispielsweise nur Bestellungen nennen, können Sie schon keine Abfrage gleichen Namens mehr verwenden. Daher verwenden Sie für die Tabelle den Namen tblbestellungen und für die Abfrage den Namen qrybestellungen. Wenn mehrere Entwickler die gleiche Konvention verwenden, erleichtert dies anderen Entwicklern das Analysieren und Bearbeiten der Anwendung und des enthaltenen Codes. Sie würden wahrscheinlich verrückt werden, wenn Sie eine Anwendung weiterentwickeln müssten, die eine völlig andere Konvention als die Ihnen vertraute verwendet. Verwenden alle Access-Entwickler die gleiche Konvention? Wenn Sie eine Anwendung oder eine Beispieldatenbank eines halbwegs professionellen Access-Entwicklers in die Finger bekommen, werden Sie feststellen, dass sich dort die Ungarische Notation durchgesetzt hat. Natürlich gibt es hier und da Abweichungen, die persönlichen Vorlieben oder einfach der Macht der Gewohnheit unterliegen, aber mit diesen kann man in der Regel gut leben. Sicher kommt ein Entwickler damit klar, wenn ein Bericht nicht das Präfix»rpt«hat, sondern mit»rep«beginnt. Auch nennen manche Entwickler eine Datensatzgruppe»rs «und nicht»rst «, aber es versteht trotzdem jeder, was gemeint ist Tabellennamen Tabellen haben genau wie alle anderen Objekte unter Access ein bestimmtes Präfix, damit man sie von anderen Objekten unterscheiden kann. Dieses Präfix lautet tbl. Der Rest des Tabellennamens soll möglichst gut beschreiben, was die Tabelle enthält. Dabei wählt man für diesen Teil des Tabellennamens in der Regel die Pluralform. Der Grund dafür ist, dass die meisten Tabellen auch mehrere Datensätze und damit Informationen über das betroffene Objekt enthalten. Man kann nicht oft genug erwähnen, das jede»normale«tabelle Informationen über ein reales Objekt enthalten sollte, wie beispielsweise Personen, Fahrzeuge, Projekte, Termine, Gebäude oder Artikel.

4 46 2 Tabellen und Datenmodellierung Tabellen mit realen Objekten Tabellen, die reale Objekte beschreiben, heißen beispielsweise folgendermaßen: tblartikel tblprojekte tblpersonen tblfahrzeuge Verknüpfungstabellen Wenn schon von»normalen«tabellen die Rede ist, sollen auch die anderen Typen vorgestellt werden: m:n-beziehungen erfordern die Verwendung von Verknüpfungstabellen, die mindestens jeweils das Primärschlüsselfeld der zu verknüpfenden Tabellen enthalten. In manchen Fällen lässt sich für solche Tabellen ein erstklassiger Name finden, doch eine Kombination der Namen der beteiligten Tabellen macht meist deutlich, was die Tabelle für Informationen enthält. Beispiele: tblfahrzeugesonderausstattungen tblbestellungenartikel (besser: tblbestelldetails) tblartikelfirmen (besser: tbllieferanten) Detailtabellen in 1:1-Beziehungen Und da wären noch die Tabellen, die zusätzliche Daten zu anderen Tabellen enthalten und per 1:1-Beziehung mit diesen verknüpft sind. Mit ein wenig objektorientierter Sichtweise bilden die»basistabelle«und die»erweiterungstabelle«eine neue Tabelle, die quasi von der»basistabelle«erbt. Wenn Sie beispielsweise eine Tabelle tblpersonen haben, die Kunden und Mitarbeiter zusammenfassen soll, können Sie die spezifischen Daten der beiden Personenarten in weiteren Tabellen speichern, die Sie 1:1 mit der»basistabelle«verknüpfen. Diese Tabellen könnten Sie tblkunden oder tblmitarbeiter nennen, aber daraus würde nicht deutlich, dass diese Tabellen lediglich Detaildaten zu einer weiteren Tabelle enthalten. Besser wären Bezeichnungen wie tblpersonenkunden und tblpersonenmitarbeiter. Lookup-Tabellen Die letzte Gruppe Tabellen, die nicht reale Objekte aus dem wirklichen Leben nachbilden, sind so genannte»lookup-tabellen«. Diese Tabellen enthalten Informationen, die eigentlich zu den»normalen«tabellen gehören, aber im Zuge der Normalisierung in eigene Tabellen ausgegrenzt wurden. Beispiele dafür sind Anrede, Geschlecht oder Kontaktart.

5 Namenskonventionen für Tabellen und Felder 47 Für diese Tabellen gelten die gleichen Regeln wie für»normale«tabellen, also beispielsweise folgende: tblanreden tblgeschlechter (der Plural liest sich merkwürdig, ist aber hier konsequent) tblkontaktarten Temporäre Tabellen Gelegentlich benötigen Sie eine Tabelle nur kurze Zeit und löschen diese nach der Verwendung wieder. Um diese Tabellen von anderen unterscheiden zu können, vor allem aber, damit Sie einen Überblick behalten, welche Tabellen nur vorübergehend benötigt werden, können Sie diese Tabellen kennzeichnen, indem Sie ihnen das Suffix Tmp oder Temp anhängen, etwa tblimporttemp. Eine Einsatzmöglichkeit für solche Tabellen ist etwa das Speichern des Ergebnisses von aufwändigen Abfragen (gegebenenfalls mit eingebauten und benutzerdefinierten Funktionen). Wenn die Ermittlung des Abfrageergebnisses lange dauert und das Ergebnis beziehungsweise die zugrunde liegenden Daten sich selten ändern, macht das Speichern des Ergebnisses in einer temporären Tabelle sehr viel Sinn Feldnamen Entgegen der bei Variablen üblichen Verwendung von Präfixen, anhand derer sich eine Aussage über den Datentyp der Variablen treffen lässt, verwendet man für Feldnamen im Allgemeinen kein Präfix. Das ist natürlich Geschmackssache; man findet jedoch kaum Datenbanken, in denen auch die Feldnamen mit einem entsprechenden Präfix versehen sind. Primärschlüsselfelder Der Name des Primärschlüsselfeldes setzt sich aus der Bezeichnung des durch die Tabelle abgebildeten Objekts im Singular und dem Suffix ID zusammen. Beispiele: tblartikel: ArtikelID tblpersonen: PersonID In Verknüpfungstabellen kommt es darauf an, ob die Tabelle einen eigenen Primärschlüssel hat oder ob sie aus den Fremdschlüsselfeldern zur Verknüpfung mit den jeweiligen Tabellen zusammengesetzt wird. Im ersteren Fall gibt es vermutlich auch einen sinnvollen Tabellennamen, der nicht aus den Namen der beiden verknüpften Tabellen besteht, wie etwa tblbestelldetails. Hier würde der Primärschlüssel (soweit vorhanden) BestelldetailID heißen.

6 48 2 Tabellen und Datenmodellierung In Tabellen, die zusätzliche Daten zu einer anderen Tabelle enthalten und per 1:1- Beziehung mit dieser verknüpft sind, verwendet man normalerweise den gleichen Namen für das Primärschlüsselfeld wie in der Basistabelle. Gegebenenfalls ist das Verknüpfungsfeld der Erweiterungstabelle nicht das Primärschlüsselfeld der Erweiterungstabelle, sondern lediglich ein eindeutiges Feld. In diesem Fall greift wieder die erstgenannte Regel: Primärschlüsselname = enthaltenes Objekt im Singular + ID. Fremdschlüsselfelder Für die Benennung von Fremdschlüsselfeldern gibt es in der Praxis zwei Ansätze: Der einfachere verwendet einfach den Namen des Primärschlüsselfeldes der verknüpften Tabelle. Der zweite Ansatz macht noch ein wenig deutlicher, dass es sich bei diesem Feld definitiv um ein Fremdschlüsselfeld handelt, indem er dem Namen dieses Feldes noch das Präfix ref verpasst. Die zweite Variante hat Vorteile, wenn es um m:n-beziehungen und 1:1-Beziehungen geht: Eine Tabelle mit zwei Feldern, die beide das Präfix ref enthalten, lässt sich zweifelsfrei als Verknüpfungstabelle identifizieren; und auch eine Tabelle, deren Primärschlüsselfeld das Präfix ref enthält, ist schnell als Erweiterungsteil einer 1:1-Beziehung enttarnt. Allgemein Sowohl für Feldnamen von Primärschlüsselfeldern, Fremdschlüsselfeldern als auch für alle anderen Felder gilt, dass der Name des Feldes sorgfältig gewählt sein will. Am besten ist es, wenn er grobe Informationen über den Datentyp enthält: Text: Vorname, Nachname Datum: Geburtsdatum, Einstellungsdatum, Erscheinungstermin Zahlen: Anzahl, Meldebestand, Lagerbestand Währung: Einzelpreis Boolean: MehrwertsteuerAusweisbar, Aktiv, InReihenfolge Unterstrich ja oder nein? Ob Sie in Tabellen- und Feldnamen den Unterstrich als Trennung zwischen einzelnen Wörtern verwenden oder die einzelnen Wörter einfach groß beginnen, ist reine Geschmacksache (in diesem Buch finden Sie übrigens ausschließlich letztere Variante). Wichtig ist, dass Sie es überhaupt hervorheben, wenn ein Tabellen- oder Variablenname aus mehr als einem Wort besteht.

7 Normalisierung 49 Beispiele: Anzahl_Datensaetze oder AnzahlDatensaetze Fahrzeug_ID oder FahrzeugID Man sollte es aber nicht übertreiben: Dem Autor sind schon Varianten untergekommen, in denen nicht nur jedes einzelne Wort, sondern fast jede Silbe groß geschrieben wurde (etwa MehrwertSteuersatz) wenn ein Wort im Deutschen zusammengeschrieben wird, sind auch keine Großbuchstaben erforderlich. Einen deutlichen Vorteil hat die Verwendung von Großbuchstaben zur Unterteilung mehrerer Wörter: Sie müssen sich nicht merken, was Sie groß und was Sie klein geschrieben haben. Access ist äußerst nachsichtig, was die Groß-/Kleinschreibung von Objektnamen angeht. Einen Unterstrich zu viel oder zu wenig wird Access Ihnen hingegen nicht verzeihen. Lang oder kurz mit oder ohne Abkürzung? Die Zeiten, in denen die beschränkte Länge von Variablennamen die Fantasie der Programmierer beflügelte, sind zum Glück vorbei und Gleiches gilt für Tabellen- und Feldnamen. Die in der Zwischenüberschrift gestellte Frage nach der Länge von Feldnamen ist leicht zu beantworten: So lang wie nötig und so kurz wie möglich. Der Feldname sollte nicht in die Irre führen, nur um ein paar Zeichen zu sparen, andererseits lassen sich zu lange Feldnamen nicht gut merken. Wenn Sie für die Zusammenstellung jeder einzelnen SQL-Anweisung erst das Beziehungsfenster öffnen müssen, wissen Sie, dass Sie an den Tabellen- und Feldnamen arbeiten müssen. 2.2 Normalisierung Unter Normalisierung versteht man die Überführung des Datenmodells in einen bestimmten Zustand. Dieser Zustand wird durch die Nummer der Normalform unterschieden. Meistens genügt das Erreichen der dritten Normalform, um Redundanzen und Inkonsistenzen vorzubeugen und dadurch die Wartung der enthaltenen Daten zu vereinfachen. Die Möglichkeit, Redundanzen und Inkonsistenzen zu vermeiden, ist eine der Haupteigenschaften von relationalen Datenbanksystemen. Jeder, der schon einmal eine Datenbank für einen Kunden entwickeln sollte, der die betroffenen Daten zuvor mit Excel verwaltet hat, und das Vergnügen hatte, auch den Import dieser Daten vorzunehmen, weiß, was Redundanzen und Inkonsistenzen sind (das soll keine Verunglimpfung der Möglichkeiten von Excel sein aber dessen Stärken liegen eher woanders).

8 50 2 Tabellen und Datenmodellierung Ein gern gesehenes Beispiel ist die Verwaltung von Rechnungen in einer einzigen Tabelle. Dort finden sich unter Umständen alle Rechnungs- und Kundendaten zu einer Rechnung in einer Zeile. Sobald zwei Rechnungen für den gleichen Kunden gespeichert werden, gibt es auch zwei Kopien der Kundendaten in der Tabelle. Ändern sich die Kundendaten, werden diese Änderungen möglicherweise nur in einer neuen Zeile vorgenommen. Sobald ein anderer Mitarbeiter eine Rechnung für diesen Kunden stellen soll, steht er vor mindestens zwei verschiedenen Kunden-Datensätzen und das Unheil nimmt seinen Lauf. Um solches Ungemach zu verhindern, gibt es relationale Datenbanken, die Normalformen und die referentielle Integrität. Halbautomatisches Normalisieren In den folgenden Abschnitten lernen Sie die unterschiedlichen Normalformen kennen und finden Beispiele für das Umwandeln nicht normalisierter Tabellen in die jeweilige Normalform. Die Zwischenüberschrift bezieht sich darauf, dass jeder Normalisierungsschritt nicht vollautomatisch abläuft. Genau genommen besteht jeder Schritt aus drei Teilen: Der erste passt das Datenmodell an und der zweite sorgt für die Umorganisierung der vorhandenen Daten. Der dritte Schritt räumt auf und löscht eventuell nicht mehr benötigte Felder. Das Anpassen des Datenmodells und damit des Tabellenentwurfs erfolgt manuell. Das Umorganisieren der Daten kann bei kleinen Datenmengen auch manuell erfolgen, aber das ist sicher keine Arbeit für einen Entwickler: Der baut sich eine kleine Routine, die diesen Vorgang mit ein paar Aktionsabfragen oder im schlimmsten Fall ein paar ADO- oder DAO-Anweisungen automatisch durchführt. Warum nicht direkt normalisieren? Der Grund für den Einsatz der Normalisierung liegt meist in Altlasten bezogen auf die Organisation der Daten vor der Erstellung einer Datenbankanwendung. Viele Datenbanken werden neu erstellt, weil bestehende Daten auf die bisherige Art und Weise nicht mehr verwaltet werden können entweder es sind keine Erweiterungen mehr möglich, es wurden immer wieder neue Tabellen und Felder an das bestehende Datenmodell angestückelt und die Anwendung läuft nicht mehr schnell genug oder die Daten liegen in einem nicht für diesen Zweck geeigneten Format vor etwa in Form von Excel-Tabellen. In diesen Fällen müssen Sie ein bestehendes Datenmodell normalisieren. Das bedeutet nicht, dass Sie mit spitzen Fingern an der Originaldatenbank herumschrauben müssen meist werden Sie eher eine neue Datenbank erstellen und ein neues Datenmodell aufsetzen, das alle in dem vorhandenen Datenmodell enthaltenen Informationen beinhaltet. Anschließend werden Sie die Daten in die neue Datenbank importieren natürlich entsprechend umorganisiert.

9 Normalisierung 51 Es kann natürlich auch sein, dass an einer bestehenden Datenbank hier und da ein kleines Problem besteht in dem Fall werden Sie kein komplett neues Datenmodell ersinnen, sondern punktuelle Änderungen vornehmen. Auch wenn Sie die folgenden Regeln nicht unter dem Schlagwort Normalisierung kennen, werden Sie die eine oder andere vermutlich bereits anwenden allein, weil sie einfach logisch erscheint und weil die meisten Entwickler, die Beispiele für Datenmodelle und damit Vorlagen für Gleichgesinnte veröffentlichen, wissen, wo es hapert. Damit Sie die Normalisierungsregeln gut verinnerlichen, finden Sie einige Beispiele für Datenmodelle, die diesen Regeln widersprechen; außerdem werden praktische Wege aufgezeigt, um solche Daten zu normalisieren Die erste Normalform Die erste Normalform fordert, dass jede in einem Feld gespeicherte Information atomar ist und nicht mehr in weitere Informationen unterteilt werden kann. Dadurch erreichen Sie, dass Sie die enthaltenen Werte einfach abfragen oder sortieren können. Beispiele für nicht atomare Informationen sind folgende in einem einzigen Feld gespeicherte Informationen: Vorname und Nachname Straße, Hausnummer, PLZ und Ort Wenn eine Tabelle ein Feld mit der Bezeichnung Name enthält und dieses sowohl den Vor- und den Nachnamen (in dieser Reihenfolge) wiedergibt, können Sie beispielsweise nur schwer nach dem Nachnamen sortieren. Vor- und der Nachname sind daher unbedingt in zwei Feldern zu speichern. Bei der Adresse bietet sich ein ähnliches Bild: Nach Datensätzen mit einem bestimmten Ort oder einer bestimmten PLZ wird oft gesucht. Diese Informationen sollten Sie daher in separaten Feldern speichern (siehe Abbildung 2.1 und Abbildung 2.2). Etwas anders sieht es bei der Straße und der Hausnummer aus: Die Angabe einer Straße hat ohne die Hausnummer zwar noch einen gewissen Informationsgehalt (wenn Sie zum nächsten IKEA fahren möchten, kommen Sie wahrscheinlich ohne die Angabe der Hausnummer aus), aber andersherum lässt sich mit einer Hausnummer allein wenig anfangen. Und das Sortieren danach macht in den meisten Fällen auch keinen Sinn. Fazit: Straße und Hausnummer sind quasi atomar und gehören deshalb normalerweise in ein Feld. Und dort, wo diese Regel durch eine Ausnahme bestätigt wird, werden die Anforderungen schon durchblicken lassen, dass die Informationen besser in getrennte Felder gehören.

10 52 2 Tabellen und Datenmodellierung Abbildung 2.1: Tabelle mit Personendaten vor... Abbildung 2.2:... und nach der Atomisierung Um den Inhalt des Feldes Name aus Abbildung 2.1 in die beiden Felder Vorname und Nachname aus Abbildung 2.2 zu überführen, ist zumindest eine regelmäßige Anordnung des zusammengesetzten Feldes erforderlich also entweder immer <Vorname> <Nachname> oder <Nachname>, <Vorname>. Dann lassen sich die Daten leicht von der einen in die andere Tabelle überführen, etwa mit folgender Prozedur: Public Sub NameAufteilen() Dim db As DAO.Database Dim rst As DAO.Recordset Dim longpos As Long Dim strname As String Dim strvorname As String Dim strnachname As String Dim strsql As String Dim lnglastspace As Long Set db = CurrentDb Set rst = db.openrecordset("tblpersonennichtnormalisiert", dbopendynaset) Do While Not rst.eof strname = rst!name lnglastspace = InStrRev(strName, " ") strvorname = Mid(strName, 1, lnglastspace)

11 Normalisierung 53 End Sub strnachname = Mid(strName, lnglastspace + 1) strsql = "INSERT INTO tblpersonennormalisiert(vorname, Nachname) " _ & " VALUES('" & strvorname & "','" & strnachname & "')" db.execute strsql rst.movenext Loop Listing 2.1: Extrahieren der Bestandteile des Feldes Name in Vor- und Nachname Die Prozedur geht davon aus, dass die Reihenfolge <Vorname> <Nachname> ist und dass der Nachname keine Leerzeichen enthält. Sie schreibt den Teil des Namens hinter dem letzten Leerzeichen in das Feld Nachname und den Rest in das Feld Vorname. Wenn der Name auch mal in der anderen Reihenfolge und durch Komma getrennt angegeben ist, können Sie dies durch eine entsprechende Verfeinerung der Prozedur abfangen. Aber Unarten, wie zuerst den Nachnamen und dann den Vornamen zu schreiben, ohne dazwischen ein Komma einzufügen, sind leider ebenfalls gängig; hier hilft wohl nur manuelles Nacharbeiten. Ein anderes Beispiel, das nach der ersten Normalform schreit, sind mehrere gleichartige Informationen in Listenform in einem einzigen Feld wie in Abbildung 2.3. Abbildung 2.3: Beispiel für nicht atomare Informationen Ein erster naiver Ansatz, die im Feld Lieferanten enthaltenen Daten in atomare Feldinhalte umzuwandeln, sieht wie in Abbildung 2.4 aus. Das ist eine oft zu beobachtende Variante, um gleichartige Informationen zu einem Datensatz zu speichern. Leider birgt diese Variante mindestens drei Schwächen: 1. Früher oder später gibt es einen Artikel, der mehr Lieferanten als dafür vorgesehene Felder hat. Dann heißt es: Felder anfügen, Abfragen anpassen, Formulare anpassen, Code anpassen.

12 54 2 Tabellen und Datenmodellierung 2. Wenn ein Artikel weniger Lieferanten als dafür vorgesehene Felder hat, bleiben diese leer und verschwenden unnötig Platz. 3. Wenn man nach Artikeln mit einem bestimmten Lieferanten sucht, muss man alle dafür vorgesehenen Felder durchgehen. Abbildung 2.4: Atomar, aber nicht optimal: Felder mit gleichartigen Informationen In diesem Fall gibt es nur eine Lösung: Da theoretisch jeder Artikel von jedem Lieferanten geliefert werden kann, muss eine m:n-beziehung her. Das bedeutet, dass die Lieferanten in einer eigenen Tabelle gespeichert werden. Welcher Lieferant welchen Artikel liefert, speichern Sie in einer Verknüpfungstabelle, die jeweils die Nummer des Artikels und des Lieferanten aufnimmt. Das aus der Tabelle in Abbildung 2.4 entstehende Datenmodell sieht wie in Abbildung 2.5 aus. Abbildung 2.5: Manchmal führt Atomatisieren zu m:n-beziehungen. Um Daten wie aus der Tabelle tblartikel_1 in Abbildung 2.4 in die Tabellen einer solchen m:n-beziehung zu überführen, verwenden Sie etwa den Code aus folgendem Listing. Public Sub AtomizeIntoMNRelation() Dim db As DAO.Database Dim rstartikel As DAO.Recordset Dim rstlieferanten As DAO.Recordset Dim strlieferant As String Dim fld As DAO.Field

13 Normalisierung 55 Dim lnglieferantid As Long Set db = CurrentDb Set rstartikel = db.openrecordset("tblartikel_1", dbopendynaset) 'Alle Datensätze der Datensatzgruppe rstartikel durchlaufen Do While Not rstartikel.eof Loop End Sub 'Für alle Felder der Tabelle... For Each fld In rstartikel.fields '...kontrolliere, ob der Name mit 'Lieferant' beginnt If Left(fld.Name, 9) = "Lieferant" _ And Not IsNull(fld.Value) Then 'Prüfen, ob schon ein Lieferant mit diesem Namen 'vorhanden ist strlieferant = fld.value Set rstlieferanten = db.openrecordset _ ("SELECT * FROM tbllieferanten WHERE Lieferant = '" _ & DoubleQuotes(strLieferant) & "'", dbopendynaset) End If 'Wenn noch nicht vorhanden, Lieferant 'in tbllieferanten anlegen If rstlieferanten.recordcount = 0 Then rstlieferanten.addnew rstlieferanten!lieferant = strlieferant 'LieferantID merken lnglieferantid = rstlieferanten!lieferantid rstlieferanten.update Else lnglieferantid = rstlieferanten!lieferantid End If 'Neuen Datensatz in Verknüpfungstabelle anlegen db.execute "INSERT INTO tblartikellieferanten(artikelid, " _ & "LieferantID) VALUES(" & rstartikel!artikelid _ & ", " & lnglieferantid & ")" Next fld rstartikel.movenext Listing 2.2: Aufbrechen nicht atomarer Informationen in eine m:n-beziehung

14 56 2 Tabellen und Datenmodellierung Das Resultat dieser Prozedur für die Daten aus der in Abbildung 2.4 gezeigten Tabelle finden Sie in Abbildung 2.6. Die Prozedur durchläuft alle Datensätze der ursprünglichen Tabelle und unterzieht die Inhalte aller Felder, deren Feldname mit Lieferant beginnt (also Lieferant1, Lieferant2, ) und deren Feldinhalt nicht leer ist, einer gesonderten Behandlung: Zunächst wird überprüft, ob die Tabelle tbllieferanten bereits einen Lieferanten mit dem angegebenen Namen enthält. Falls nein, wird ein entsprechender Datensatz in dieser Tabelle angelegt. Der Wert des Feldes LieferantID wird in jedem Fall festgehalten, um in einer abschließenden Aktionsabfrage einen neuen Datensatz in der Verknüpfungstabelle tblartikellieferanten anzulegen. Fast für jede Vorgehensweise gibt es Alternativen. Ein passendes Beispiel für das Anfügen verknüpfter Daten finden Sie in Abschnitt des Kapitels 11,»Fehlerbehandlung«. Abbildung 2.6: Diese Daten entsprechen der ersten Normalform Die zweite Normalform Die zweite Normalform besagt, dass alle Felder einer Tabelle vom Primärschlüssel beziehungsweise vom ganzen Primärschlüssel abhängig sein müssen.»ganzer«primärschlüssel bezieht sich auf Tabellen mit mehreren Primärschlüsseln das hört sich im ersten Augenblick unlogisch an, aber folgendes Beispiel wird verdeutlichen, wie das gemeint ist. Im Beispiel aus Abbildung 2.7 verwaltet jemand Kunden und Projekte in einer Excel- Tabelle. Jeder Datensatz dieser Tabelle ist durch die Kombination der Felder KundeID und ProjektID eindeutig identifizierbar.

15 Normalisierung 57 Wenn man die Felder der Tabelle auf ihre Abhängigkeit vom Primärschlüssel untersucht, stellt man schnell fest, dass nicht alle vom»ganzen«, also zusammengesetzten Primärschlüssel, abhängen. Die Kundendaten sind zwar vom Primärschlüsselfeld KundeID abhängig, aber nicht vom Feld ProjektID. Dadurch kann derselbe Kunde mehrmals in der Tabelle auftreten. Der in Abbildung 2.7 dargestellte Zustand heißt Redundanz. Unter diesen Bedingungen ist die Konsistenz der Daten gefährdet. Sobald man Informationen zu einem Kunden nur in einem der Datensätze ändert, ist die Konsistenz dahin und die Integrität der Daten verloren. Abbildung 2.7: Tabelle mit zwei Primärschlüsseln Wie leicht aus einer Tabelle mit redundanten Daten Inkonsistenzen entstehen können, zeigt Abbildung 2.8. Hier wurde in einem neuen Datensatz der Name des Kunden falsch geschrieben. Die Inkonsistenz würde sich hier bemerkbar machen, wenn man alle Projekte nach dem Kunden»Addison-Wesley«filtert. Der letzte Eintrag mit dem Kundennamen ohne Bindestrich würde nicht angezeigt. Abbildung 2.8: Tabelle mit inkonsistenten Daten

16 58 2 Tabellen und Datenmodellierung Überführung der Daten in die zweite Normalform Die Gefahr von Redundanzen und Inkonsistenzen lässt sich beheben, indem Sie die Daten so auf mehrere Tabellen aufteilen, dass alle Felder der Tabellen vom jeweiligen Primärschlüsselfeld beziehungsweise vom aus mehreren Feldern zusammengesetzten Primärschlüssel abhängen. Im obigen Beispiel gibt es zwei Primärschlüssel KundeID und ProjektID, die beide abhängige Felder aufweisen. Die Notwendigkeit einer zweiten Tabelle ist offensichtlich. Die beiden Tabellen sehen wie in Abbildung 2.9 aus. Abbildung 2.9: Tabellen mit ausschließlich vom Primärschlüssel abhängigen Feldern Jetzt fehlt allerdings die Information, welches Projekt zu welchem Kunden gehört. Da in der Regel jedes Projekt nur für einen Kunden durchgeführt wird, halten Sie diese Information in der Tabelle tblprojekte fest, indem Sie per Fremdschlüsselfeld auf den jeweiligen Primärschlüssel der Tabelle tblkunden verweisen. Abbildung 2.10 zeigt die Tabelle tblprojekte mit dem neuen Fremdschlüsselfeld, das mit dem Primärschlüsselfeld der Tabelle tblkunden verknüpft ist. Abbildung 2.10: Beziehung zwischen den Tabellen tblkunden und tblprojekte

17 Normalisierung Die dritte Normalform Die dritte Normalform sorgt dafür, dass es keine transitiven Abhängigkeiten innerhalb einer Tabelle gibt. Alle Nicht-Schlüssel-Felder müssen direkt vom Primärschlüssel der Tabelle abhängig sein. Oder andersherum: Es darf kein Feld geben, das Detailinformationen über ein anderes Feld enthält. Um sicherzugehen, dass eine Tabelle der dritten Normalform entspricht, prüfen Sie, ob Sie die Daten aller Felder mit Ausnahme des Primärschlüssels einzeln ändern können, ohne dass ein weiteres Feld in dieser Tabelle davon betroffen ist. Beispiel: Die Tabelle aus Abbildung 2.11 enthält neben dem Primärschlüsselfeld einige Felder, die von diesem abhängig sind. Im Falle des Feldes Verkaufsleiter besteht allerdings nur eine indirekte Abhängigkeit, da der Verkaufsleiter zunächst vom Feld Hersteller abhängt. Abbildung 2.11: Diese Tabelle beruht nicht auf der dritten Normalform. Lösung: Der Hersteller samt Verkaufsleiter wird in eine eigene Tabelle ausquartiert. Das Ergebnis sieht wie im Datenmodell aus Abbildung 2.12 aus. Abbildung 2.12: Die Tabelle aus Abbildung 2.11 in der dritten Normalform

18 60 2 Tabellen und Datenmodellierung Felder mit berechneten Werten widersprechen der dritten Normalform Eine schlechte Angewohnheit und nur in ganz wenigen Fällen sinnvoll ist das Speichern von berechneten Werten in einer Tabelle wie in folgendem Beispiel (siehe Abbildung 2.13). Hier ist der Bruttopreis das Produkt aus Einzelpreis und Mehrwertsteuer. Solch ein Tabellenentwurf ist sehr anfällig für Inkonsistenzen. Wenn Sie nur einen der drei Werte ändern, ohne die Abhängigkeit zu berücksichtigen, stimmt die Berechnung nicht mehr. Abbildung 2.13: Der Bruttopreis berechnet sich aus dem Einzelpreis und der Mehrwertsteuer. Die Änderung des Datenmodells fällt hier vergleichsweise einfach aus: Entfernen Sie das Feld Bruttopreis und verwenden Sie zu dessen Ermittlung eine Abfrage wie die folgende (siehe Abbildung 2.14). Das aus der Tabelle entfernte Feld wird durch ein in der Abfrage berechnetes Feld ersetzt. Sie brauchen lediglich das Format des berechneten Feldes auf Währung einzustellen, um ein mit der Ursprungstabelle identisches Ergebnis zu erhalten Weitere Normalformen Die übrigen Normalformen sind eher akademischer Natur und werden deshalb hier nicht behandelt Das richtige Maß treffen Wenn man die Normalisierung aus Sicht der Performance betrachtet, verhält es sich so wie mit der Verwendung von Indizes auf Tabellenfeldern (mehr dazu in Kapitel 12,»Performance«) manchmal ist weniger mehr. Je mehr Tabellen und Beziehungen in einer Abfrage referenziert werden, desto langsamer wird die Abfrage. Patentrezepte für das richtige Maß an Normalisierung gibt es nicht. Es gibt aber für die meisten Fälle bereits in der Praxis erprobte Datenmodelle, nach denen Sie sich bei der Modellierung der eigenen Datenbank richten können.

19 Integritätsregeln 61 Abbildung 2.14: Realisieren eines berechneten Feldes per Abfrage 2.3 Integritätsregeln Mit Integritätsregeln sorgen Sie dafür, dass die Tabellen einer Datenbank nur die für den jeweiligen Anwendungszweck gültigen Werte enthalten. Es gibt eine Menge unterschiedliche Arten von Integritätsregeln, die entsprechend auf unterschiedlichste Weise umgesetzt werden Integrität der Werte (Wertbereichsintegrität) Mit dem Datentyp eines Feldes schränken Sie die Menge der möglichen Eingaben schon relativ weit ein. Weitere Möglichkeiten bestehen in der Verwendung von Feldeigenschaften wie beispielsweise Gültigkeitsregel. Damit geben Sie eine Regel an, mit der die Gültigkeit der vorhandenen Daten geprüft wird. Dabei lassen sich durchaus flexible Ausdrücke eingeben. Beispiel: Es sollen keine Personen aufgenommen werden, deren Alter unter 18 Jahren liegt. Dazu stellen Sie die Eigenschaft Gültigkeitsprüfung auf den folgenden Ausdruck ein: <=DatAdd("jjjj";-18;Datum())

20 62 2 Tabellen und Datenmodellierung Verwenden Sie außerdem die Eigenschaft Gültigkeitsmeldung, damit Access bei Nichteinhalten der Regel eine entsprechende Meldung ausgibt (siehe Abbildung 2.15). Abbildung 2.15: Anwendung einer Gültigkeitsregel Auch die beiden Eigenschaften Eingabe erforderlich und Leere Zeichenfolge sorgen für die Integrität der eingegebenen Werte. Die beiden Werte kombiniert liefern unterschiedliche Anforderungen an die Werte für ein Feld. Interessant zum Einschränken des Wertebereichs sind die Kombinationen aus Tabelle 2.1:. Eingabe erforderlich Leere Zeichenfolge Resultat Ja Nein Wert darf nicht NULL sein. Ja Ja Wert kann eine leere Zeichenfolge sein. Tabelle 2.1: Relevante Kombinationen der Eigenschaften»Eingabe erforderlich«und»leere Zeichenfolge«2.3.2 Format der Werte (semantische Integrität) Im Tabellenentwurf können Sie für jedes Feld ein Format vorgeben, das bei der Eingabe eingehalten werden muss. Dies ist hilfreich, wenn die Werte ein bestimmtes Format haben müssen etwa wenn eine Postleitzahl mit führender Länderkennung und mit Bindestrich angegeben werden muss (beispielsweise D-47137). In diesem Fall verwenden Sie folgenden Ausdruck für die Eigenschaft Eingabeformat: >L\-00009

21 Integritätsregeln 63 Das Größer-Zeichen (>) sorgt dafür, dass alle enthaltenen Buchstaben automatisch groß gesetzt werden. Der Backslash signalisiert ein nachfolgendes Literal, die vier Nullen sind Pflichtzahlen und die Neun kennzeichnet eine freiwillige Zahl. Alle möglichen Zeichen und ihre Beschreibung finden Sie in Tabelle 2.2 (Quelle: Microsoft Access 2003, Online-Hilfe). Zeichen Beschreibung 0 Ziffer (0 bis 9, Eingabe erforderlich, Plus- [+] und Minuszeichen [ ] sind nicht erlaubt). 9 Ziffer oder Leerzeichen (Eingabe nicht erforderlich, Plus- und Minuszeichen sind nicht erlaubt). # Ziffer oder Leerzeichen (Eingabe nicht erforderlich, Leerzeichen werden als Leerzeichen im Bearbeitungsmodus angezeigt, aber beim Speichern der Daten entfernt, Plus- und Minuszeichen sind erlaubt). L Buchstabe (A bis Z, Eingabe erforderlich).? Buchstabe (A bis Z, Eingabe optional). A Buchstabe oder Ziffer (Eingabe erforderlich). a Buchstabe oder Ziffer (Eingabe nicht erforderlich). & Ein beliebiges Zeichen oder ein Leerzeichen (Eingabe erforderlich). C Ein beliebiges Zeichen oder ein Leerzeichen (Eingabe nicht erforderlich).., : ; / Platzhalter für Dezimaltrennzeichen sowie Tausender-, Datums- und Zeit-Trennzeichen (das tatsächlich verwendete Zeichen hängt von den Einstellungen im Dialogfeld Eigenschaften von Ländereinstellungen in der Systemsteuerung von Windows ab). < Alle Buchstaben werden in Kleinbuchstaben umgewandelt. > Alle Buchstaben werden in Großbuchstaben umgewandelt.! Bewirkt, dass die Anzeige im Eingabeformat von rechts nach links anstatt von links nach rechts erfolgt. Eingegebene Zeichen füllen das Eingabeformat immer von links nach rechts aus. Sie können das Ausrufezeichen-Symbol an jeder beliebigen Stelle im Eingabeformat einfügen. \ Das folgende Zeichen wird als Literal angezeigt, die Wirkung als Sonderzeichen wird ggf. dadurch aufgehoben (zum Beispiel wird \A als A angezeigt). Tabelle 2.2: Beschreibung der Zeichen für Eingabeformate Abhängigkeit von Feldinhalten (Attributintegrität) Sie können bei der Datendefinition auch festlegen, dass bestimmte Abhängigkeiten zwischen den Inhalten verschiedener Felder einzuhalten sind. Wenn Sie etwa sicherstellen möchten, dass der maximale Rabatt eines Artikels vom Preis abhängt, verwenden Sie die Eigenschaften Gültigkeitsregel und Gültigkeitsmeldung der Tabelle selbst.

22 64 2 Tabellen und Datenmodellierung Das Beispiel aus Abbildung 2.16 sorgt dafür, dass für Preise kleiner als EUR 1.000, nicht mehr als fünf Prozent Rabatt gewährt werden dürfen. Abbildung 2.16: Gültigkeitsregel für abhängige Feldinhalte Eindeutige Datensätze (Entitätsintegrität) Weiter oben haben Sie bereits erfahren, dass jeder Datensatz einer Tabelle eindeutig sein sollte dafür sorgen Sie unter Access im einfachsten Fall durch die Verwendung eines Primärschlüsselfeldes. Damit Sie sich keine Sorgen um die Auswahl eindeutiger Werte machen müssen, gibt es in Access den Datentyp Autowert. Neue Werte lassen sich entweder inkrementell oder per Zufall generieren für die entsprechende Einstellung ist die Eigenschaft Neue Werte zuständig (siehe Abbildung 2.17). Üblich ist bei einem Autowert die Verwendung inkrementeller neuer Werte Referentielle Integrität Referentielle Integrität sorgt für die Integrität der Beziehungen zwischen den Datensätzen verknüpfter Tabellen. Damit sorgen Sie beispielsweise dafür, dass der Benutzer kein Projekt anlegen kann, ohne einen Kunden ausgewählt zu haben.

23 Integritätsregeln 65 Abbildung 2.17: Inkrementelle oder zufällige neue Werte? Die Erstellung einer Beziehung mit referentieller Integrität erfordert, dass eines der beteiligten Felder das Primärschlüsselfeld seiner Tabelle oder zumindest ein eindeutiger Index ist, dass beide Felder kompatible Datentypen aufweisen und dass die beiden beteiligten Tabellen sich in der gleichen Datenbank befinden. Durch die Definition referentieller Integrität stellen Sie sicher, dass die in den Tabellen enthaltenen Daten in folgenden Punkten konsistent sind: Es gibt zu jedem Datensatz der Detailtabelle einen passenden Datensatz in der Mastertabelle. Datensätze der Mastertabelle, die mit mindestens einem Datensatz der Detailtabelle verknüpft sind, können standardmäßig nicht gelöscht werden. Access sorgt dafür, dass diese Grundsätze eingehalten werden, und gibt bei Verletzung dieser Regeln eine entsprechende Meldung aus. Optional lassen sich unter Access noch zwei weitere Automatismen einrichten: Löschweitergabe: Wenn ein Datensatz der Mastertabelle gelöscht wird, werden automatisch alle verknüpften Datensätze der Detailtabelle gelöscht. Aktualisierungsweitergabe: Wenn das Verknüpfungsfeld der Mastertabelle geändert wird, ändert Access automatisch das Verknüpfungsfeld aller Datensätze der Detailtabelle, die mit diesem Datensatz verknüpft sind.

24 66 2 Tabellen und Datenmodellierung Referentielle Integrität legen Sie im Beziehungen-Fenster der Datenbank-Anwendung fest. Das Fenster zeigt die benötigten Tabellen und eventuell bereits bestehende Beziehungen an. Um für eine Beziehung referentielle Integrität zu definieren, klicken Sie auf den Beziehungspfeil zwischen den beteiligten Tabellen und wählen per Kontextmenü den Eintrag Beziehung bearbeiten aus. Dort finden Sie die an der Beziehung beteiligten Felder, können referentielle Integrität definieren und Aktualisierungs- und Löschweitergabe festlegen. Außerdem finden Sie hier die Angabe des Beziehungstyps, der sich aus der Art der verknüpften Felder ergibt, und die Möglichkeit, den Verknüpfungstyp anzupassen (siehe Abbildung 2.18). Zu all diesen Optionen erfahren Sie weiter unten mehr. Abbildung 2.18: Bearbeiten einer Beziehung zwischen zwei Tabellen 2.4 Beziehungen Mit Beziehungen legen Sie die Verknüpfungen zwischen den Tabellen einer Datenbank fest. Sie sind das A und O bei relationalen Datenbanken, denn Sie können damit nicht nur festlegen, welche Felder der einen Tabelle mit den entsprechenden Feldern der anderen Tabelle verknüpft sind. Access bietet die Möglichkeit, etwa referentielle Integrität zu definieren und dabei unterschiedliche Eigenschaften für die Beziehung festzulegen.

25 Beziehungen 67 Voraussetzung für das Erstellen einer Beziehung ist, dass mindestens eines der Felder das Primärschlüsselfeld seiner Tabelle ist. Die Tabelle mit dem Primärschlüsselfeld spielt die Rolle der Mastertabelle (auch Parent-Tabelle genannt) der Beziehung. Das Verknüpfungsfeld der anderen Tabelle heißt Fremdschlüsselfeld, die Tabelle mit dem Fremdschlüsselfeld ist die Detailtabelle (auch Child-Tabelle genannt). Eigentlich sollte man meinen, dass die Tabelle mit dem Fremdschlüsselfeld die Mastertabelle sei und über die per Fremdschlüsselfeld referenzierte Tabelle Details enthielte und dementsprechend Detailtabelle hieße. Das erscheint zumindest bei jenen verknüpften Tabellen sinnvoll, die im Rahmen der Normalisierung ausgegliederte Informationen enthalten also beispielsweise Anreden, Geschlecht oder Titel. Tatsächlich ist es aber umgekehrt die Tabelle mit dem Primärschlüsselfeld in der Beziehung heißt Master- und die mit dem Fremdschlüsselfeld Detailtabelle. Beziehungen werden im Beziehungsfenster abgebildet und können dort auch erzeugt und bearbeitet werden. Es gibt aber auch die Möglichkeit, Beziehungen durch einen Assistenten erstellen zu lassen Benennen von Primär- und Fremdschlüsselfeldern Einen Vorschlag für die Namen von Primärschlüsselfeldern haben Sie bereits weiter oben kennen gelernt demnach soll das Primärschlüsselfeld aus dem Singular der Bezeichnung des mit den Tabellenfeldern beschriebenen Objekts plus der angehängten Zeichenkette»ID«bestehen also etwa»projektid«,»mitarbeiterid«,»kundeid«oder»artikelid«. Das Fremdschlüsselfeld einer Tabelle enthält einen Wert, der dem Wert des Primärschlüsselfeldes der zu verknüpfenden Tabelle entspricht deshalb sollten Sie es auch genauso nennen. Ein klassisches Beispiel sind Projekte und Kunden (siehe Abbildung 2.19). Die Projekte-Tabelle enthält hier ein Fremdschlüsselfeld, für das man den Wert des Primärschlüsselfeldes eines in der Tabelle tblkunden enthaltenen Datensatzes eintragen kann. Abbildung 2.19: Beziehung zwischen Kunden und Projekten

26 68 2 Tabellen und Datenmodellierung Natürlich gibt es auch hier Ausnahmen beispielsweise kommt es vor, dass eine Detailtabelle zwei Fremdschlüsselfelder enthält, die auf das gleiche Feld der Mastertabelle verweisen. Ein gutes Beispiel ist die Beziehung zwischen Artikeln und Firmen: Dort kann der eine Eintrag der Firmentabelle als Lieferant herhalten, während die andere Firma der Hersteller des Artikels ist (siehe Abbildung 2.20). HerstellerID und LieferantID scheinen hier adäquate Bezeichnungen zu sein, genauer wären allerdings HerstellerFirmaID und LieferantFirmaID auf diese Weise ließe sich deutlicher erkennen, wohin die Verknüpfung geht. Abbildung 2.20: Zwei Beziehungen zu der gleichen Tabelle erfordern unterschiedliche Fremdschlüsselnamen Die Beziehung aus Abbildung 2.20 zeigt das Beziehungen-Fenster übrigens nicht automatisch an; nachdem Sie die Artikel-Tabelle einmal und die Firmen-Tabelle zweimal in diese Ansicht eingefügt haben, wird lediglich eine der beiden Beziehungen angezeigt. Die zweite fügen Sie zu Fuß hinzu, indem Sie das Feld LieferantID auf das Feld FirmaID der Tabelle tblfirmen_1 ziehen. Die zweite Inkarnation der Firmen-Tabelle wird im Beziehungen-Fenster nur mit anderem Namen angezeigt, um Verwechslungen zu vermeiden tatsächlich existiert nur eine Tabelle namens tblfirmen in der Datenbank Halbautomatisches Festlegen von Beziehungen Es gibt eine Möglichkeit, Access dazu zu bringen, automatisch eine Beziehung zwischen zwei Tabellen festzulegen. Das ist immer dann der Fall, wenn Sie mit dem Nachschlage-Assistenten eine Verknüpfung zwischen zwei Tabellen erstellen. Wenn Sie beispielsweise eine Kunden- und eine Projekte-Tabelle miteinander verknüpfen und dabei das Feld KundeID für die Auswahl des dem Projekt zugeordneten Kunden verwendet werden soll, gehen Sie folgendermaßen vor: 1. Öffnen Sie die Tabelle tblkunden in der Entwurfsansicht. 2. Wählen Sie für das Feld, über das die Beziehung hergestellt werden soll, den Datentyp Nachschlage-Assistent aus. Damit öffnen Sie den Nachschlage-Assistenten.

27 Beziehungen Zum Herstellen der Beziehung zu einer anderen Tabelle wählen Sie im ersten Schritt die erste Option aus: Das Nachschlagefeld soll die Werte einer Tabelle oder Abfrage entnehmen. 4. Wählen Sie im nächsten Schritt die Tabelle aus, mit der Sie das Feld verknüpfen möchten in diesem Fall die Tabelle tblkunden. 5. Im folgenden Schritt legen Sie fest, welche Felder der verknüpften Tabelle im Nachschlagefeld angezeigt werden sollen. Normalerweise wählt man dort den Primärindex der Tabelle sowie ein Feld, dessen Inhalt den enthaltenen Datensatz am besten charakterisiert. Hier ist das der Name des Kunden, der im Feld Kunde gespeichert wird. Diese Einstellung können Sie später problemlos ändern. 6. In den letzten drei Schritten können Sie noch eine Sortierung festlegen, angeben, ob die Spalte mit dem Primärschlüsselwert ausgeblendet werden soll, und einen Namen für das Fremdschlüsselfeld eingeben. Nach der Eingabe der benötigten Informationen nimmt der Assistent folgende Änderungen am Fremdschlüsselfeld der Tabelle vor (siehe Abbildung 2.21): Ändern der Eigenschaft Steuerelement anzeigen auf den Eintrag Kombinationsfeld Einstellen einer Datensatzherkunft für dieses Steuerelement, hier: SELECT tblkunden.kundeid, tblkunden.kunde FROM tblkunden; Einstellen der Eigenschaften Spaltenanzahl und Spaltenbreiten auf die Werte 2 und 0cm;2,54cm. Dadurch wird nur die zweite Spalte der Datensatzherkunft angezeigt, während das in der Eigenschaft Gebundene Spalte angegebene erste Feld unsichtbar bleibt. Außerdem fügt der Assistent die Beziehung zwischen dem Fremdschlüsselfeld der bearbeiteten Tabelle und dem Primärschlüsselfeld der verknüpften Tabelle hinzu (siehe Abbildung 2.22) Festlegen referentieller Integrität Referentielle Integrität für die Beziehung zwischen zwei Tabellen können Sie ebenfalls im Beziehungen-Fenster festlegen. Dazu markieren Sie die Verbindungslinie zwischen den beteiligten Tabellen und wählen aus dem Kontextmenü den Eintrag Beziehung bearbeiten aus. Alternativ können Sie auch einfach doppelt auf den Beziehungspfeil klicken. Im nun erscheinenden Dialog Beziehungen bearbeiten aktivieren Sie mindestens die Option Mit referentieller Integrität.

28 70 2 Tabellen und Datenmodellierung Abbildung 2.21: Der Nachschlage-Assistent ändert einige Eigenschaften eines Tabellenfeldes und der Tabelle. Abbildung 2.22: Diese Verknüpfung wurde durch den Nachschlage-Assistenten erstellt. Falls Tabellen, für deren Verknüpfung referentielle Integrität definiert werden soll, bereits Datensätze enthalten, kann es an dieser Stelle zu einer Fehlermeldung kommen, falls die Daten nicht der referentiellen Integrität entsprechen. Entweder Sie leben damit und passen anschließend eventuell zu Null geänderte Inhalte von Fremdschlüsselfeldern an oder kümmern sich vorher um die Integrität der Daten. Die Option Aktualisierungsweitergabe an verwandte Felder sorgt dafür, dass Änderungen am Primärschlüssel der Mastertabelle der Beziehung auf das Fremdschlüsselfeld der Detailtabelle übertragen werden.

29 Beziehungen 71 Mit der Option Löschweitergabe an verwandte Datensätze legen Sie fest, dass beim Löschen eines Datensatzes der Mastertabelle auch alle Datensätze der Detailtabelle gelöscht werden. Im Beispiel Kunden und Projekte bedeutet das Folgendes: Wenn Sie einen Kunden löschen, entfernt Access auch alle dazugehörenden Projekte. Abbildung 2.23: Festlegen referentieller Integrität per Dialog :n-Beziehungen Die 1:n-Beziehung ist die Mutter aller Beziehungen. Alle weiteren Beziehungstypen sind Sonderfälle der 1:n-Beziehung, wie Sie weiter unten erfahren werden. Deshalb ist es auch kein Zufall, dass gerade dieser Beziehungstyp für die einführenden Abschnitte zum Thema Beziehungen ausgewählt wurde. Da Sie dort bereits die wichtigsten Grundlagen zu diesem Thema kennen gelernt haben, werden in diesem Abschnitt lediglich einige Beispiele für den Einsatz von 1:n-Beziehungen vorgestellt. In anderen Büchern, Fachbeiträgen oder im Internet stoßen Sie vielleicht auch auf die Bezeichnung n:1-beziehung. Prinzipiell ist daran nichts auszusetzen, da hier lediglich die Reihenfolge vertauscht wurde. In der in diesem Buch verwendeten Terminologie macht das allerdings sehr wohl einen Unterschied: Hier ist eine 1:n- Beziehung die Beziehung zwischen zwei Tabellen, die Eigenschaften eines Objekts enthalten also beispielsweise Kunden, Projekte, Artikel, Produkte, Unternehmen oder Fahrzeuge. Wenn Sie eine Beziehung zwischen zwei solchen Tabellen herstellen, heißt sie in diesem Buch 1:n-Beziehung. Die nachfolgend vorgestellten n:1- Beziehungen verknüpfen eine der eben genannten Tabellen mit ausgegliederten Daten wie Anrede, Geschlecht, Titel bei Adressen, Kategorie bei Artikeln oder Fahrzeugart bei Fahrzeugen. Eine andere nachfolgend verwendete Bezeichnung für diese Tabellen ist Lookup-Tabelle.

30 72 2 Tabellen und Datenmodellierung Beispiele für 1:n-Beziehungen Im Folgenden einige Beispiele für 1:n-Beziehungen: Unternehmen und Personen als Ansprechpartner Projekte und Kunden Projekte und Mitarbeiter als Projektleiter Artikel und Firmen als Lieferanten Artikel und Firmen als Hersteller Diese Liste ließe sich beliebig fortsetzen. Weitere Beispiele finden Sie weiter unten in Abschnitt 2.6,»Datenmodell-Muster« n:1-beziehungen oder Lookup-Beziehungen n:1-beziehungen verknüpfen Tabellen, deren Eigenschaften Objekte beschreiben, mit jenen, die ausgegliederte Eigenschaften dieses Objekts enthalten. Wenn Sie sich etwa eine Adresstabelle vorstellen, die ein Textfeld zur Angabe der Anrede enthält, würden Sie vermutlich ungern zu jedem Eintrag»Herr«oder»Frau«manuell hinzufügen wollen. Statt dessen finden Sie in der Regel ein Kombinationsfeld vor, mit dem sich der gewünschte Eintrag auswählen lässt. Das hat zwei entscheidende Vorteile: Erstens sparen Sie Tipparbeit bei der Eingabe dieses Feldes und zweitens sorgen Sie so dafür, dass nur die für das Feld vorgesehenen Einträge eingegeben werden können. Gleiches gilt für die Angabe des Geschlechts: In jeden Datensatz»männlich«oder»weiblich«einzutragen, ist eine sehr mühselige Arbeit, die Auswahl der Werte aber durchaus zumutbar. Bei der manuellen Eingabe dürfte sich außerdem früher oder später ein Tippfehler einschleichen, den Sie mit der Auswahlmöglichkeit ausschließen. Und diese Tippfehler können sich durchaus auswirken: Wenn Sie beispielsweise alle Datensätze der Tabelle ausgeben möchten, in denen das Feld Geschlecht den Wert»weiblich«hat, oder sich nur die Anzahl dieser Felder anzeigen lassen, sorgt eine einzige unrichtige Schreibweise für ein falsches Ergebnis. Daher sollten Sie immer, wenn ein Feld häufig den gleichen Wert annimmt, ein Kombinationsfeld zur Eingabe der Daten in Erwägung ziehen, das aus den Daten einer verknüpften Tabelle gefüttert wird. Es gibt auch die Möglichkeit, in der Felddefinition eine Wertliste als Datensatzherkunft für ein Kombinationsfeld anzugeben. Dazu stellen Sie die in Abbildung 2.24 abgebildeten Eigenschaften ein.