2 Tabellen und Datenmodellierung - access … · 2 Tabellen und Datenmodellierung Dieses Kapitel...

2 Tabellen und Datenmodellierung

Dieses Kapitel setzt Kenntnisse im grundlegenden Umgang mit Tabellen voraus. Da-rauf aufbauend erfahren Sie hier, wie Sie die Anforderungen an die geplante Anwen-dung in ein adäquates Datenmodell umsetzen. Dabei ist es wichtig, dass die Daten denObjekten der realen Welt entsprechend abgebildet und dazu in Relation gesetzt wer-den. Dabei helfen die Normalisierungsregeln, die manch einer vielleicht schon intuitiveinsetzt, und eine konsistente Benennung von Tabellen und Tabellenfeldern. Damit Sienicht nur mit trockener Theorie abgespeist werden, finden Sie im mittleren Teil desKapitels eine Menge Beispiele für Datenmodelle. Diese können Sie als Basis für eigeneAnwendungen oder auch nur als Anregung verwenden.

Hintergrund dieses Kapitels ist die Tatsache, dass viele (angehende) Entwickler inskalte Access-Wasser geworfen werden und keine oder wenig Erfahrung in der Daten-modellierung haben. Zudem findet sich in den meisten Grundlagen-Büchern zuAccess meist nur eine Beispielanwendung mit Datenmodell – und das hält dann imganzen restlichen Teil des Buches als Grundlage für Abfrage-, Formular-, Berichts- undVBA-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, Fremd-schlüssel)

� Erläuterung der Beziehungsarten anhand praktischer Beispiele

� Vermittlung eines Gefühls für die jeweils richtige Beziehungsart anhand einigerDatenmodelle verschiedener Anwendungen

Außerdem finden Sie am Ende dieses Kapitels ausführliche Informationen zum Spei-chern von Dateien und insbesondere von Bildern in Access-Datenbanken.

2265.book Seite 43 Donnerstag, 22. September 2005 3:34 15

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 vonTabellen und der enthaltenen Felder. Die nachfolgenden Abschnitte fassen dabei Ele-mente der Ungarischen Notation (http://www.xoc.net/standards/rvbanc.asp)und einige weitere Regeln zusammen, die sich bewährt haben und von vielen Ent-wicklern so oder ähnlich berücksichtigt werden. Details zur Ungarischen Notation fin-den Sie unter dem oben genannten Link; ein Abdruck der recht umfangreichenTabellen ist aus Platzgründen leider nicht möglich.

Grundsätzlich gelten für die Vergabe von Namen an Access-Objekte, Feldnamen undSteuerelemente folgende Regeln:

� Der Name darf aus maximal 64 Zeichen bestehen.

� Der Name kann aus beliebigen Zeichen mit Ausnahme des Punktes (.), Ausrufezei-chens (!), 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 undSteuerelementen gar keine Sonderzeichen enthalten, da Namen mit Sonderzeichen anmanchen Stellen eine Spezialbehandlung erfordern – beispielsweise müssen Sie diesein SQL-Ausdrücken und in VBA in eckige Klammern einfassen.

Verwenden Sie außerdem besser keine Namen, die bereits für ein reserviertes Wortinnerhalb von Access, VBA oder referenzierten Objektbibliotheken benutzt werden.Abschreckendes Beispiel ist die Verwendung von »Name« als Feldname in Tabellenmit Kontaktdaten – diese Bezeichnung ist bereits als Eigenschaft diverser Objekte ver-geben. In Zweifelsfällen konsultieren Sie einfach den Objektkatalog und suchen nachdem 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üsselwortverwendete Namen aufgreifen. Sie müssen dann allerdings einige Regeln beachten –etwa, dass Sie die Bezeichnungen von Feldern in SQL-Ausdrücken und in VBA ineckige 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öch-ten. Abhängig davon, ob Sie eine Anwendung nur für das stille Kämmerlein oder fürjemand anderen entwickeln, sollten Sie jedoch folgende Punkte beachten:

� Eine feste Systematik bei der Vergabe von Namen für Tabellen und Felder erleich-tert Ihnen beim Programmieren das Leben. Wenn Ihre Tabellennamen etwa grund-


Namenskonventionen für Tabellen und Felder 45

sätzlich mit »tbl« beginnen und der Plural der darin beschriebenen Objekteangefügt ist, müssen Sie sich beim Referenzieren dieser Tabelle aus Formularen,Berichten oder aus VBA-Modulen niemals Gedanken machen, wie Sie die Tabellegenannt haben, wenn Sie nur wissen, welches Objekt darin beschrieben wird.

� Präfixe bei Objektnamen erlauben Ihnen auf einfache Weise, ein Objekt am Namenzu erkennen und gleiche Basisnamen für mehrere unterschiedliche Objekttypen zuverwenden. Wenn Sie eine Tabelle beispielsweise nur Bestellungen nennen, könnenSie schon keine Abfrage gleichen Namens mehr verwenden. Daher verwendenSie für die Tabelle den Namen tblBestellungen und für die Abfrage den NamenqryBestellungen.

� Wenn mehrere Entwickler die gleiche Konvention verwenden, erleichtert diesanderen Entwicklern das Analysieren und Bearbeiten der Anwendung und desenthaltenen Codes. Sie würden wahrscheinlich verrückt werden, wenn Sie eineAnwendung weiterentwickeln müssten, die eine völlig andere Konvention als dieIhnen vertraute verwendet.

Verwenden alle Access-Entwickler die gleiche Konvention?

Wenn Sie eine Anwendung oder eine Beispieldatenbank eines halbwegs professionel-len Access-Entwicklers in die Finger bekommen, werden Sie feststellen, dass sich dortdie Ungarische Notation durchgesetzt hat. Natürlich gibt es hier und da Abweichun-gen, 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 damitklar, wenn ein Bericht nicht das Präfix »rpt« hat, sondern mit »rep« beginnt. Auch nen-nen manche Entwickler eine Datensatzgruppe »rs…« und nicht »rst…«, aber es ver-steht trotzdem jeder, was gemeint ist.

2.1.1 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. DerGrund dafür ist, dass die meisten Tabellen auch mehrere Datensätze und damitInformationen über das betroffene Objekt enthalten. Man kann nicht oft genug erwäh-nen, das jede »normale« Tabelle Informationen über ein reales Objekt enthalten sollte,wie beispielsweise Personen, Fahrzeuge, Projekte, Termine, Gebäude oder Artikel.



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 vor-gestellt werden: m:n-Beziehungen erfordern die Verwendung von Verknüpfungstabel-len, die mindestens jeweils das Primärschlüsselfeld der zu verknüpfenden Tabellenenthalten. In manchen Fällen lässt sich für solche Tabellen ein erstklassiger Name fin-den, 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 enthaltenund per 1:1-Beziehung mit diesen verknüpft sind. Mit ein wenig objektorientierterSichtweise 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 Mitarbeiterzusammenfassen soll, können Sie die spezifischen Daten der beiden Personenarten inweiteren Tabellen speichern, die Sie 1:1 mit der »Basistabelle« verknüpfen. Diese Tabel-len könnten Sie tblKunden oder tblMitarbeiter nennen, aber daraus würde nicht deut-lich, 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 eigent-lich zu den »normalen« Tabellen gehören, aber im Zuge der Normalisierung in eigeneTabellen ausgegrenzt wurden. Beispiele dafür sind Anrede, Geschlecht oder Kontaktart.


Namenskonventionen für Tabellen und Felder 47

Für diese Tabellen gelten die gleichen Regeln wie für »normale« Tabellen, also bei-spielsweise 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 Ver-wendung wieder. Um diese Tabellen von anderen unterscheiden zu können, vor allemaber, damit Sie einen Überblick behalten, welche Tabellen nur vorübergehend benötigtwerden, können Sie diese Tabellen kennzeichnen, indem Sie ihnen das Suffix Tmp oderTemp anhängen, etwa tblImportTemp.

Eine Einsatzmöglichkeit für solche Tabellen ist etwa das Speichern des Ergebnisses vonaufwändigen Abfragen (gegebenenfalls mit eingebauten und benutzerdefiniertenFunktionen). Wenn die Ermittlung des Abfrageergebnisses lange dauert und dasErgebnis beziehungsweise die zugrunde liegenden Daten sich selten ändern, machtdas Speichern des Ergebnisses in einer temporären Tabelle sehr viel Sinn.

2.1.2 Feldnamen

Entgegen der bei Variablen üblichen Verwendung von Präfixen, anhand derer sich eineAussage über den Datentyp der Variablen treffen lässt, verwendet man für Feldnamenim Allgemeinen kein Präfix. Das ist natürlich Geschmackssache; man findet jedochkaum Datenbanken, in denen auch die Feldnamen mit einem entsprechenden Präfixversehen sind.

Primärschlüsselfelder

Der Name des Primärschlüsselfeldes setzt sich aus der Bezeichnung des durch dieTabelle 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är-schlüssel hat oder ob sie aus den Fremdschlüsselfeldern zur Verknüpfung mit denjeweiligen Tabellen zusammengesetzt wird. Im ersteren Fall gibt es vermutlich aucheinen sinnvollen Tabellennamen, der nicht aus den Namen der beiden verknüpftenTabellen besteht, wie etwa tblBestelldetails. Hier würde der Primärschlüssel (soweit vor-handen) BestelldetailID heißen.



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 gleichenNamen für das Primärschlüsselfeld wie in der Basistabelle. Gegebenenfalls ist das Ver-knüpfungsfeld der Erweiterungstabelle nicht das Primärschlüsselfeld der Erweite-rungstabelle, sondern lediglich ein eindeutiges Feld. In diesem Fall greift wieder dieerstgenannte 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: Dereinfachere verwendet einfach den Namen des Primärschlüsselfeldes der verknüpftenTabelle. Der zweite Ansatz macht noch ein wenig deutlicher, dass es sich bei diesemFeld definitiv um ein Fremdschlüsselfeld handelt, indem er dem Namen dieses Feldesnoch das Präfix ref verpasst.

Die zweite Variante hat Vorteile, wenn es um m:n-Beziehungen und 1:1-Beziehungengeht: Eine Tabelle mit zwei Feldern, die beide das Präfix ref enthalten, lässt sich zwei-felsfrei als Verknüpfungstabelle identifizieren; und auch eine Tabelle, deren Primär-schlüsselfeld das Präfix ref enthält, ist schnell als Erweiterungsteil einer 1:1-Beziehungenttarnt.

Allgemein

Sowohl für Feldnamen von Primärschlüsselfeldern, Fremdschlüsselfeldern als auchfür alle anderen Felder gilt, dass der Name des Feldes sorgfältig gewählt sein will. Ambesten 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 einzelnenWörtern verwenden oder die einzelnen Wörter einfach groß beginnen, ist reineGeschmacksache (in diesem Buch finden Sie übrigens ausschließlich letztere Variante).Wichtig ist, dass Sie es überhaupt hervorheben, wenn ein Tabellen- oder Variablen-name aus mehr als einem Wort besteht.


Normalisierung 49

Beispiele:

� Anzahl_Datensaetze oder AnzahlDatensaetze

� Fahrzeug_ID oder FahrzeugID

Man sollte es aber nicht übertreiben: Dem Autor sind schon Varianten untergekom-men, in denen nicht nur jedes einzelne Wort, sondern fast jede Silbe groß geschriebenwurde (etwa MehrwertSteuersatz) – wenn ein Wort im Deutschen zusammengeschrie-ben wird, sind auch keine Großbuchstaben erforderlich.

Einen deutlichen Vorteil hat die Verwendung von Großbuchstaben zur Unterteilungmehrerer Wörter: Sie müssen sich nicht merken, was Sie groß und was Sie kleingeschrieben haben. Access ist äußerst nachsichtig, was die Groß-/Kleinschreibung vonObjektnamen angeht. Einen Unterstrich zu viel oder zu wenig wird Access Ihnen hin-gegen nicht verzeihen.

Lang oder kurz – mit oder ohne Abkürzung?

Die Zeiten, in denen die beschränkte Länge von Variablennamen die Fantasie der Pro-grammierer beflügelte, sind zum Glück vorbei – und Gleiches gilt für Tabellen- undFeldnamen. Die in der Zwischenüberschrift gestellte Frage nach der Länge von Feldna-men ist leicht zu beantworten: So lang wie nötig und so kurz wie möglich. Der Feld-name sollte nicht in die Irre führen, nur um ein paar Zeichen zu sparen, andererseitslassen sich zu lange Feldnamen nicht gut merken. Wenn Sie für die Zusammenstellungjeder 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 einenbestimmten Zustand. Dieser Zustand wird durch die Nummer der Normalform unter-schieden. Meistens genügt das Erreichen der dritten Normalform, um Redundanzenund Inkonsistenzen vorzubeugen und dadurch die Wartung der enthaltenen Daten zuvereinfachen.

Die Möglichkeit, Redundanzen und Inkonsistenzen zu vermeiden, ist eine der Haupt-eigenschaften von relationalen Datenbanksystemen. Jeder, der schon einmal eineDatenbank für einen Kunden entwickeln sollte, der die betroffenen Daten zuvor mitExcel verwaltet hat, und das Vergnügen hatte, auch den Import dieser Daten vorzu-nehmen, weiß, was Redundanzen und Inkonsistenzen sind (das soll keine Verun-glimpfung der Möglichkeiten von Excel sein – aber dessen Stärken liegen eherwoanders).



Ein gern gesehenes Beispiel ist die Verwaltung von Rechnungen in einer einzigenTabelle. Dort finden sich unter Umständen alle Rechnungs- und Kundendaten zu einerRechnung in einer Zeile. Sobald zwei Rechnungen für den gleichen Kunden gespei-chert werden, gibt es auch zwei Kopien der Kundendaten in der Tabelle. Ändern sichdie Kundendaten, werden diese Änderungen möglicherweise nur in einer neuen Zeilevorgenommen. Sobald ein anderer Mitarbeiter eine Rechnung für diesen Kunden stel-len soll, steht er vor mindestens zwei verschiedenen Kunden-Datensätzen und dasUnheil nimmt seinen Lauf.

Um solches Ungemach zu verhindern, gibt es relationale Datenbanken, die Normalfor-men und die referentielle Integrität.

Halbautomatisches Normalisieren

In den folgenden Abschnitten lernen Sie die unterschiedlichen Normalformen kennenund finden Beispiele für das Umwandeln nicht normalisierter Tabellen in die jeweiligeNormalform.

Die Zwischenüberschrift bezieht sich darauf, dass jeder Normalisierungsschritt nichtvollautomatisch abläuft. Genau genommen besteht jeder Schritt aus drei Teilen: Dererste passt das Datenmodell an und der zweite sorgt für die Umorganisierung der vor-handenen Daten. Der dritte Schritt räumt auf und löscht eventuell nicht mehr benö-tigte Felder. Das Anpassen des Datenmodells und damit des Tabellenentwurfs erfolgtmanuell. Das Umorganisieren der Daten kann – bei kleinen Datenmengen – auchmanuell erfolgen, aber das ist sicher keine Arbeit für einen Entwickler: Der baut sicheine kleine Routine, die diesen Vorgang mit ein paar Aktionsabfragen oder imschlimmsten 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 dieOrganisation der Daten vor der Erstellung einer Datenbankanwendung. Viele Daten-banken werden neu erstellt, weil bestehende Daten auf die bisherige Art und Weisenicht mehr verwaltet werden können – entweder es sind keine Erweiterungen mehrmöglich, es wurden immer wieder neue Tabellen und Felder an das bestehende Daten-modell angestückelt und die Anwendung läuft nicht mehr schnell genug oder dieDaten liegen in einem nicht für diesen Zweck geeigneten Format vor – etwa in Formvon Excel-Tabellen.

In diesen Fällen müssen Sie ein bestehendes Datenmodell normalisieren. Das bedeutetnicht, dass Sie mit spitzen Fingern an der Originaldatenbank herumschrauben müssen– meist werden Sie eher eine neue Datenbank erstellen und ein neues Datenmodellaufsetzen, das alle in dem vorhandenen Datenmodell enthaltenen Informationen bein-haltet. Anschließend werden Sie die Daten in die neue Datenbank importieren – natür-lich entsprechend umorganisiert.


Normalisierung 51

Es kann natürlich auch sein, dass an einer bestehenden Datenbank hier und da ein klei-nes Problem besteht – in dem Fall werden Sie kein komplett neues Datenmodell ersin-nen, sondern punktuelle Änderungen vornehmen.

Auch wenn Sie die folgenden Regeln nicht unter dem Schlagwort Normalisierung ken-nen, werden Sie die eine oder andere vermutlich bereits anwenden – allein, weil sieeinfach logisch erscheint und weil die meisten Entwickler, die Beispiele für Datenmo-delle und damit Vorlagen für Gleichgesinnte veröffentlichen, wissen, wo es hapert.

Damit Sie die Normalisierungsregeln gut verinnerlichen, finden Sie einige Beispielefür Datenmodelle, die diesen Regeln widersprechen; außerdem werden praktischeWege aufgezeigt, um solche Daten zu normalisieren.

2.2.1 Die erste Normalform

Die erste Normalform fordert, dass jede in einem Feld gespeicherte Information ato-mar ist und nicht mehr in weitere Informationen unterteilt werden kann. Dadurcherreichen Sie, dass Sie die enthaltenen Werte einfach abfragen oder sortieren können.

Beispiele für nicht atomare Informationen sind folgende in einem einzigen Feld gespei-cherte Informationen:

� Vorname und Nachname

� Straße, Hausnummer, PLZ und Ort

Wenn eine Tabelle ein Feld mit der Bezeichnung Name enthält und dieses sowohl denVor- und den Nachnamen (in dieser Reihenfolge) wiedergibt, können Sie beispiels-weise nur schwer nach dem Nachnamen sortieren. Vor- und der Nachname sind daherunbedingt in zwei Feldern zu speichern.

Bei der Adresse bietet sich ein ähnliches Bild: Nach Datensätzen mit einem bestimmtenOrt oder einer bestimmten PLZ wird oft gesucht. Diese Informationen sollten Sie daherin 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 einerStraße hat ohne die Hausnummer zwar noch einen gewissen Informationsgehalt(wenn Sie zum nächsten IKEA fahren möchten, kommen Sie wahrscheinlich ohne dieAngabe der Hausnummer aus), aber andersherum lässt sich mit einer Hausnummerallein wenig anfangen. Und das Sortieren danach macht in den meisten Fällen auchkeinen Sinn. Fazit: Straße und Hausnummer sind quasi atomar und gehören deshalbnormalerweise in ein Feld. Und dort, wo diese Regel durch eine Ausnahme bestätigtwird, werden die Anforderungen schon durchblicken lassen, dass die Informationenbesser in getrennte Felder gehören.



Um den Inhalt des Feldes Name aus Abbildung 2.1 in die beiden Felder Vorname undNachname aus Abbildung 2.2 zu überführen, ist zumindest eine regelmäßige Anord-nung des zusammengesetzten Feldes erforderlich – also entweder immer <Vorname><Nachname> oder <Nachname>, <Vorname>. Dann lassen sich die Daten leicht von dereinen 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)

Abbildung 2.1: Tabelle mit Personendaten vor ...

Abbildung 2.2: ... und nach der Atomisierung


Normalisierung 53

strNachname = Mid(strName, lngLastSpace + 1) strSQL = "INSERT INTO tblPersonenNormalisiert(Vorname, Nachname) " _ & " VALUES('" & strVorname & "','" & strNachname & "')" db.Execute strSQL rst.MoveNext Loop

End Sub

Listing 2.1: Extrahieren der Bestandteile des Feldes Name in Vor- und Nachname

Die Prozedur geht davon aus, dass die Reihenfolge <Vorname> <Nachname> ist unddass der Nachname keine Leerzeichen enthält. Sie schreibt den Teil des Namens hinterdem 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 getrenntangegeben ist, können Sie dies durch eine entsprechende Verfeinerung der Prozedurabfangen. Aber Unarten, wie zuerst den Nachnamen und dann den Vornamen zuschreiben, ohne dazwischen ein Komma einzufügen, sind leider ebenfalls gängig; hierhilft wohl nur manuelles Nacharbeiten.

Ein anderes Beispiel, das nach der ersten Normalform schreit, sind mehrere gleich-artige Informationen in Listenform in einem einzigen Feld wie in Abbildung 2.3.

Ein erster naiver Ansatz, die im Feld Lieferanten enthaltenen Daten in atomare Feld-inhalte umzuwandeln, sieht wie in Abbildung 2.4 aus. Das ist eine oft zu beobachtendeVariante, um gleichartige Informationen zu einem Datensatz zu speichern. Leider birgtdiese Variante mindestens drei Schwächen:

1. Früher oder später gibt es einen Artikel, der mehr Lieferanten als dafür vorgese-hene Felder hat. Dann heißt es: Felder anfügen, Abfragen anpassen, Formulareanpassen, Code anpassen.

Abbildung 2.3: Beispiel für nicht atomare Informationen



2. Wenn ein Artikel weniger Lieferanten als dafür vorgesehene Felder hat, bleibendiese leer und verschwenden unnötig Platz.

3. Wenn man nach Artikeln mit einem bestimmten Lieferanten sucht, muss man alledafür vorgesehenen Felder durchgehen.

In diesem Fall gibt es nur eine Lösung: Da theoretisch jeder Artikel von jedem Liefe-ranten geliefert werden kann, muss eine m:n-Beziehung her. Das bedeutet, dass dieLieferanten in einer eigenen Tabelle gespeichert werden. Welcher Lieferant welchenArtikel liefert, speichern Sie in einer Verknüpfungstabelle, die jeweils die Nummer desArtikels und des Lieferanten aufnimmt. Das aus der Tabelle in Abbildung 2.4 entste-hende Datenmodell sieht wie in Abbildung 2.5 aus.

Um Daten wie aus der Tabelle tblArtikel_1 in Abbildung 2.4 in die Tabellen einer solchenm: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

Abbildung 2.4: Atomar, aber nicht optimal: Felder mit gleichartigen Informationen

Abbildung 2.5: Manchmal führt Atomatisieren zu m:n-Beziehungen.


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 '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) '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 End If 'Neuen Datensatz in Verknüpfungstabelle anlegen db.Execute "INSERT INTO tblArtikelLieferanten(ArtikelID, " _ & "LieferantID) VALUES(" & rstArtikel!ArtikelID _ & ", " & lngLieferantID & ")" Next fld rstArtikel.MoveNext Loop

End Sub

Listing 2.2: Aufbrechen nicht atomarer Informationen in eine m:n-Beziehung



Das Resultat dieser Prozedur für die Daten aus der in Abbildung 2.4 gezeigten Tabellefinden Sie in Abbildung 2.6. Die Prozedur durchläuft alle Datensätze der ursprüngli-chen Tabelle und unterzieht die Inhalte aller Felder, deren Feldname mit Lieferantbeginnt (also Lieferant1, Lieferant2, …) und deren Feldinhalt nicht leer ist, einer geson-derten Behandlung: Zunächst wird überprüft, ob die Tabelle tblLieferanten bereits einenLieferanten mit dem angegebenen Namen enthält. Falls nein, wird ein entsprechenderDatensatz in dieser Tabelle angelegt. Der Wert des Feldes LieferantID wird in jedem Fallfestgehalten, um in einer abschließenden Aktionsabfrage einen neuen Datensatz in derVerknüpfungstabelle tblArtikelLieferanten anzulegen.

2.2.2 Die zweite Normalform

Die zweite Normalform besagt, dass alle Felder einer Tabelle vom Primärschlüsselbeziehungsweise vom ganzen Primärschlüssel abhängig sein müssen. »Ganzer« Pri-märschlüssel bezieht sich auf Tabellen mit mehreren Primärschlüsseln – das hört sichim ersten Augenblick unlogisch an, aber folgendes Beispiel wird verdeutlichen, wiedas 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 KundeIDund ProjektID eindeutig identifizierbar.

Fast für jede Vorgehensweise gibt es Alternativen. Ein passendes Beispiel für dasAnfügen verknüpfter Daten finden Sie in Abschnitt 11.3.3 des Kapitels 11, »Fehler-behandlung«.

Abbildung 2.6: Diese Daten entsprechen der ersten Normalform.


Normalisierung 57

Wenn man die Felder der Tabelle auf ihre Abhängigkeit vom Primärschlüssel unter-sucht, stellt man schnell fest, dass nicht alle vom »ganzen«, also zusammengesetztenPrimärschlüssel, abhängen. Die Kundendaten sind zwar vom PrimärschlüsselfeldKundeID abhängig, aber nicht vom Feld ProjektID.

Dadurch kann derselbe Kunde mehrmals in der Tabelle auftreten. Der in Abbildung2.7 dargestellte Zustand heißt Redundanz. Unter diesen Bedingungen ist die Konsis-tenz der Daten gefährdet. Sobald man Informationen zu einem Kunden nur in einemder Datensätze ändert, ist die Konsistenz dahin und die Integrität der Daten verloren.

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 Kundenfalsch geschrieben. Die Inkonsistenz würde sich hier bemerkbar machen, wenn manalle Projekte nach dem Kunden »Addison-Wesley« filtert. Der letzte Eintrag mit demKundennamen ohne Bindestrich würde nicht angezeigt.

Abbildung 2.7: Tabelle mit zwei Primärschlüsseln

Abbildung 2.8: Tabelle mit inkonsistenten Daten



Überführung der Daten in die zweite Normalform

Die Gefahr von Redundanzen und Inkonsistenzen lässt sich beheben, indem Sie dieDaten so auf mehrere Tabellen aufteilen, dass alle Felder der Tabellen vom jeweiligenPrimärschlüsselfeld beziehungsweise vom aus mehreren Feldern zusammengesetztenPrimärschlüssel abhängen. Im obigen Beispiel gibt es zwei Primärschlüssel – KundeIDund ProjektID –, die beide abhängige Felder aufweisen. Die Notwendigkeit einer zwei-ten Tabelle ist offensichtlich. Die beiden Tabellen sehen wie in Abbildung 2.9 aus.

Jetzt fehlt allerdings die Information, welches Projekt zu welchem Kunden gehört. Dain der Regel jedes Projekt nur für einen Kunden durchgeführt wird, halten Sie dieseInformation in der Tabelle tblProjekte fest, indem Sie per Fremdschlüsselfeld auf denjeweiligen Primärschlüssel der Tabelle tblKunden verweisen.

Abbildung 2.10 zeigt die Tabelle tblProjekte mit dem neuen Fremdschlüsselfeld, das mitdem Primärschlüsselfeld der Tabelle tblKunden verknüpft ist.

Abbildung 2.9: Tabellen mit ausschließlich vom Primärschlüssel abhängigen Feldern

Abbildung 2.10: Beziehung zwischen den Tabellen tblKunden und tblProjekte


Normalisierung 59

2.2.3 Die dritte Normalform

Die dritte Normalform sorgt dafür, dass es keine transitiven Abhängigkeiten innerhalbeiner Tabelle gibt. Alle Nicht-Schlüssel-Felder müssen direkt vom Primärschlüssel derTabelle abhängig sein. Oder andersherum: Es darf kein Feld geben, das Detailinforma-tionen über ein anderes Feld enthält.

Um sicherzugehen, dass eine Tabelle der dritten Normalform entspricht, prüfen Sie, obSie 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 einigeFelder, die von diesem abhängig sind. Im Falle des Feldes Verkaufsleiter besteht aller-dings nur eine indirekte Abhängigkeit, da der Verkaufsleiter zunächst vom Feld Her-steller abhängt.

Lösung: Der Hersteller samt Verkaufsleiter wird in eine eigene Tabelle ausquartiert. DasErgebnis sieht wie im Datenmodell aus Abbildung 2.12 aus.

Abbildung 2.11: Diese Tabelle beruht nicht auf der dritten Normalform.

Abbildung 2.12: Die Tabelle aus Abbildung 2.11 in der dritten Normalform



Felder mit berechneten Werten widersprechen der dritten Normalform

Eine schlechte Angewohnheit und nur in ganz wenigen Fällen sinnvoll ist das Spei-chern von berechneten Werten in einer Tabelle wie in folgendem Beispiel (siehe Abbil-dung 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 derdrei Werte ändern, ohne die Abhängigkeit zu berücksichtigen, stimmt die Berechnungnicht mehr.

Die Änderung des Datenmodells fällt hier vergleichsweise einfach aus: Entfernen Siedas Feld Bruttopreis und verwenden Sie zu dessen Ermittlung eine Abfrage wie die fol-gende (siehe Abbildung 2.14). Das aus der Tabelle entfernte Feld wird durch ein in derAbfrage berechnetes Feld ersetzt. Sie brauchen lediglich das Format des berechnetenFeldes auf Währung einzustellen, um ein mit der Ursprungstabelle identisches Ergeb-nis zu erhalten.

2.2.4 Weitere Normalformen

Die übrigen Normalformen sind eher akademischer Natur und werden deshalb hiernicht behandelt.

2.2.5 Das richtige Maß treffen

Wenn man die Normalisierung aus Sicht der Performance betrachtet, verhält es sich sowie mit der Verwendung von Indizes auf Tabellenfeldern (mehr dazu in Kapitel 12,»Performance«) – manchmal ist weniger mehr. Je mehr Tabellen und Beziehungen ineiner Abfrage referenziert werden, desto langsamer wird die Abfrage. Patentrezeptefür das richtige Maß an Normalisierung gibt es nicht. Es gibt aber für die meisten Fällebereits in der Praxis erprobte Datenmodelle, nach denen Sie sich bei der Modellierungder eigenen Datenbank richten können.

Abbildung 2.13: Der Bruttopreis berechnet sich aus dem Einzelpreis und der Mehrwertsteuer.


Integritätsregeln 61

2.3 Integritätsregeln

Mit Integritätsregeln sorgen Sie dafür, dass die Tabellen einer Datenbank nur die fürden jeweiligen Anwendungszweck gültigen Werte enthalten. Es gibt eine Mengeunterschiedliche Arten von Integritätsregeln, die entsprechend auf unterschiedlichsteWeise umgesetzt werden.

2.3.1 Integrität der Werte (Wertbereichsintegrität)

Mit dem Datentyp eines Feldes schränken Sie die Menge der möglichen Eingabenschon relativ weit ein. Weitere Möglichkeiten bestehen in der Verwendung von Feld-eigenschaften wie beispielsweise Gültigkeitsregel. Damit geben Sie eine Regel an, mitder die Gültigkeit der vorhandenen Daten geprüft wird. Dabei lassen sich durchausflexible Ausdrücke eingeben.

Beispiel: Es sollen keine Personen aufgenommen werden, deren Alter unter 18 Jahrenliegt. Dazu stellen Sie die Eigenschaft Gültigkeitsprüfung auf den folgenden Ausdruckein:

<=DatAdd("jjjj";-18;Datum())

Abbildung 2.14: Realisieren eines berechneten Feldes per Abfrage



Verwenden Sie außerdem die Eigenschaft Gültigkeitsmeldung, damit Access bei Nicht-einhalten der Regel eine entsprechende Meldung ausgibt (siehe Abbildung 2.15).

Auch die beiden Eigenschaften Eingabe erforderlich und Leere Zeichenfolge sorgen für dieIntegrität der eingegebenen Werte. Die beiden Werte kombiniert liefern unterschied-liche Anforderungen an die Werte für ein Feld. Interessant zum Einschränken desWertebereichs sind die Kombinationen aus Tabelle 2.1:.

2.3.2 Format der Werte (semantische Integrität)

Im Tabellenentwurf können Sie für jedes Feld ein Format vorgeben, das bei der Ein-gabe eingehalten werden muss. Dies ist hilfreich, wenn die Werte ein bestimmtes For-mat haben müssen – etwa wenn eine Postleitzahl mit führender Länderkennung undmit Bindestrich angegeben werden muss (beispielsweise D-47137).

In diesem Fall verwenden Sie folgenden Ausdruck für die Eigenschaft Eingabeformat:

>L\-00009

Abbildung 2.15: Anwendung einer Gültigkeitsregel

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«



Das Größer-Zeichen (>) sorgt dafür, dass alle enthaltenen Buchstaben automatischgroß gesetzt werden. Der Backslash signalisiert ein nachfolgendes Literal, die vier Nul-len sind Pflichtzahlen und die Neun kennzeichnet eine freiwillige Zahl.

Alle möglichen Zeichen und ihre Beschreibung finden Sie in Tabelle 2.2 (Quelle: Micro-soft Access 2003, Online-Hilfe).

2.3.3 Abhängigkeit von Feldinhalten (Attributintegrität)

Sie können bei der Datendefinition auch festlegen, dass bestimmte Abhängigkeitenzwischen den Inhalten verschiedener Felder einzuhalten sind. Wenn Sie etwa sicher-stellen möchten, dass der maximale Rabatt eines Artikels vom Preis abhängt, verwen-den Sie die Eigenschaften Gültigkeitsregel und Gültigkeitsmeldung der Tabelle selbst.

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 Eigenschaf-ten 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



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.

2.3.4 Eindeutige Datensätze (Entitätsintegrität)

Weiter oben haben Sie bereits erfahren, dass jeder Datensatz einer Tabelle eindeutigsein sollte – dafür sorgen Sie unter Access im einfachsten Fall durch die Verwendungeines Primärschlüsselfeldes. Damit Sie sich keine Sorgen um die Auswahl eindeutigerWerte machen müssen, gibt es in Access den Datentyp Autowert. Neue Werte lassensich entweder inkrementell oder per Zufall generieren – für die entsprechende Einstel-lung ist die Eigenschaft Neue Werte zuständig (siehe Abbildung 2.17). Üblich ist beieinem Autowert die Verwendung inkrementeller neuer Werte.

2.3.5 Referentielle Integrität

Referentielle Integrität sorgt für die Integrität der Beziehungen zwischen den Daten-sätzen verknüpfter Tabellen. Damit sorgen Sie beispielsweise dafür, dass der Benutzerkein Projekt anlegen kann, ohne einen Kunden ausgewählt zu haben.

Abbildung 2.16: Gültigkeitsregel für abhängige Feldinhalte



Die Erstellung einer Beziehung mit referentieller Integrität erfordert, dass eines derbeteiligten Felder das Primärschlüsselfeld seiner Tabelle oder zumindest ein eindeuti-ger Index ist, dass beide Felder kompatible Datentypen aufweisen und dass die beidenbeteiligten Tabellen sich in der gleichen Datenbank befinden.

Durch die Definition referentieller Integrität stellen Sie sicher, dass die in den Tabellenenthaltenen Daten in folgenden Punkten konsistent sind:

� Es gibt zu jedem Datensatz der Detailtabelle einen passenden Datensatz in derMastertabelle.

� Datensätze der Mastertabelle, die mit mindestens einem Datensatz der Detailta-belle verknüpft sind, können standardmäßig nicht gelöscht werden.

Access sorgt dafür, dass diese Grundsätze eingehalten werden, und gibt bei Verletzungdieser 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, werdenautomatisch alle verknüpften Datensätze der Detailtabelle gelöscht.

� Aktualisierungsweitergabe: Wenn das Verknüpfungsfeld der Mastertabelle geän-dert wird, ändert Access automatisch das Verknüpfungsfeld aller Datensätze derDetailtabelle, die mit diesem Datensatz verknüpft sind.

Abbildung 2.17: Inkrementelle oder zufällige neue Werte?



Referentielle Integrität legen Sie im Beziehungen-Fenster der Datenbank-Anwendungfest. Das Fenster zeigt die benötigten Tabellen und eventuell bereits bestehende Bezie-hungen an. Um für eine Beziehung referentielle Integrität zu definieren, klicken Sie aufden Beziehungspfeil zwischen den beteiligten Tabellen und wählen per Kontextmenüden Eintrag Beziehung bearbeiten… aus. Dort finden Sie die an der Beziehung beteiligtenFelder, können referentielle Integrität definieren und Aktualisierungs- und Löschweiter-gabe festlegen. Außerdem finden Sie hier die Angabe des Beziehungstyps, der sich ausder Art der verknüpften Felder ergibt, und die Möglichkeit, den Verknüpfungstyp anzu-passen (siehe Abbildung 2.18). Zu all diesen Optionen erfahren Sie weiter unten mehr.

2.4 Beziehungen

Mit Beziehungen legen Sie die Verknüpfungen zwischen den Tabellen einer Datenbankfest. Sie sind das A und O bei relationalen Datenbanken, denn Sie können damit nichtnur festlegen, welche Felder der einen Tabelle mit den entsprechenden Feldern deranderen Tabelle verknüpft sind. Access bietet die Möglichkeit, etwa referentielle Inte-grität zu definieren und dabei unterschiedliche Eigenschaften für die Beziehung fest-zulegen.

Abbildung 2.18: Bearbeiten einer Beziehung zwischen zwei Tabellen


Beziehungen 67

Voraussetzung für das Erstellen einer Beziehung ist, dass mindestens eines der Felderdas Primärschlüsselfeld seiner Tabelle ist. Die Tabelle mit dem Primärschlüsselfeld spieltdie Rolle der Mastertabelle (auch Parent-Tabelle genannt) der Beziehung. Das Verknüp-fungsfeld der anderen Tabelle heißt Fremdschlüsselfeld, die Tabelle mit dem Fremd-schlüsselfeld ist die Detailtabelle (auch Child-Tabelle genannt).

Beziehungen werden im Beziehungsfenster abgebildet und können dort auch erzeugtund bearbeitet werden. Es gibt aber auch die Möglichkeit, Beziehungen durch einenAssistenten erstellen zu lassen.

2.4.1 Benennen von Primär- und Fremdschlüsselfeldern

Einen Vorschlag für die Namen von Primärschlüsselfeldern haben Sie bereits weiteroben kennen gelernt – demnach soll das Primärschlüsselfeld aus dem Singular derBezeichnung des mit den Tabellenfeldern beschriebenen Objekts plus der angehängtenZeichenkette »ID« bestehen – also etwa »ProjektID«, »MitarbeiterID«, »KundeID« oder»ArtikelID«.

Das Fremdschlüsselfeld einer Tabelle enthält einen Wert, der dem Wert des Primär-schlüsselfeldes der zu verknüpfenden Tabelle entspricht – deshalb sollten Sie es auchgenauso nennen. Ein klassisches Beispiel sind Projekte und Kunden (siehe Abbildung2.19). Die Projekte-Tabelle enthält hier ein Fremdschlüsselfeld, für das man den Wertdes Primärschlüsselfeldes eines in der Tabelle tblKunden enthaltenen Datensatzes ein-tragen kann.

Eigentlich sollte man meinen, dass die Tabelle mit dem Fremdschlüsselfeld dieMastertabelle sei und über die per Fremdschlüsselfeld referenzierte Tabelle Detailsenthielte und dementsprechend Detailtabelle hieße. Das erscheint zumindest beijenen verknüpften Tabellen sinnvoll, die im Rahmen der Normalisierung ausgeglie-derte Informationen enthalten – also beispielsweise Anreden, Geschlecht oder Titel.Tatsächlich ist es aber umgekehrt – die Tabelle mit dem Primärschlüsselfeld in derBeziehung heißt Master- und die mit dem Fremdschlüsselfeld Detailtabelle.

Abbildung 2.19: Beziehung zwischen Kunden und Projekten



Natürlich gibt es auch hier Ausnahmen – beispielsweise kommt es vor, dass eineDetailtabelle zwei Fremdschlüsselfelder enthält, die auf das gleiche Feld der Masterta-belle verweisen. Ein gutes Beispiel ist die Beziehung zwischen Artikeln und Firmen:Dort kann der eine Eintrag der Firmentabelle als Lieferant herhalten, während dieandere Firma der Hersteller des Artikels ist (siehe Abbildung 2.20). HerstellerID undLieferantID scheinen hier adäquate Bezeichnungen zu sein, genauer wären allerdingsHerstellerFirmaID und LieferantFirmaID – auf diese Weise ließe sich deutlicher erken-nen, wohin die Verknüpfung geht.

Die Beziehung aus Abbildung 2.20 zeigt das Beziehungen-Fenster übrigens nicht auto-matisch an; nachdem Sie die Artikel-Tabelle einmal und die Firmen-Tabelle zweimal indiese 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 FirmaIDder Tabelle tblFirmen_1 ziehen. Die zweite Inkarnation der Firmen-Tabelle wird imBeziehungen-Fenster nur mit anderem Namen angezeigt, um Verwechslungen zu ver-meiden – tatsächlich existiert nur eine Tabelle namens tblFirmen in der Datenbank.

2.4.2 Halbautomatisches Festlegen von Beziehungen

Es gibt eine Möglichkeit, Access dazu zu bringen, automatisch eine Beziehung zwi-schen zwei Tabellen festzulegen. Das ist immer dann der Fall, wenn Sie mit dem Nach-schlage-Assistenten eine Verknüpfung zwischen zwei Tabellen erstellen. Wenn Siebeispielsweise eine Kunden- und eine Projekte-Tabelle miteinander verknüpfen unddabei das Feld KundeID für die Auswahl des dem Projekt zugeordneten Kunden ver-wendet 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, denDatentyp Nachschlage-Assistent aus. Damit öffnen Sie den Nachschlage-Assistenten.

Abbildung 2.20: Zwei Beziehungen zu der gleichen Tabelle erfordern unterschiedliche Fremdschlüsselnamen


Beziehungen 69

3. Zum Herstellen der Beziehung zu einer anderen Tabelle wählen Sie im erstenSchritt die erste Option aus: Das Nachschlagefeld soll die Werte einer Tabelle oderAbfrage entnehmen.

4. Wählen Sie im nächsten Schritt die Tabelle aus, mit der Sie das Feld verknüpfenmöchten – in diesem Fall die Tabelle tblKunden.

5. Im folgenden Schritt legen Sie fest, welche Felder der verknüpften Tabelle im Nach-schlagefeld angezeigt werden sollen. Normalerweise wählt man dort den Primärin-dex der Tabelle sowie ein Feld, dessen Inhalt den enthaltenen Datensatz am bestencharakterisiert. Hier ist das der Name des Kunden, der im Feld Kunde gespeichertwird. Diese Einstellung können Sie später problemlos ändern.

6. In den letzten drei Schritten können Sie noch eine Sortierung festlegen, angeben, obdie Spalte mit dem Primärschlüsselwert ausgeblendet werden soll, und einenNamen für das Fremdschlüsselfeld eingeben.

Nach der Eingabe der benötigten Informationen nimmt der Assistent folgende Ände-rungen 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 und0cm;2,54cm. Dadurch wird nur die zweite Spalte der Datensatzherkunft angezeigt,während das in der Eigenschaft Gebundene Spalte angegebene erste Feld unsichtbarbleibt.

Außerdem fügt der Assistent die Beziehung zwischen dem Fremdschlüsselfeld derbearbeiteten Tabelle und dem Primärschlüsselfeld der verknüpften Tabelle hinzu(siehe Abbildung 2.22).

2.4.3 Festlegen referentieller Integrität

Referentielle Integrität für die Beziehung zwischen zwei Tabellen können Sie ebenfallsim Beziehungen-Fenster festlegen. Dazu markieren Sie die Verbindungslinie zwischenden beteiligten Tabellen und wählen aus dem Kontextmenü den Eintrag Beziehungbearbeiten… aus. Alternativ können Sie auch einfach doppelt auf den Beziehungspfeilklicken.

Im nun erscheinenden Dialog Beziehungen bearbeiten aktivieren Sie mindestens dieOption Mit referentieller Integrität.



Die Option Aktualisierungsweitergabe an verwandte Felder sorgt dafür, dass Änderungenam Primärschlüssel der Mastertabelle der Beziehung auf das Fremdschlüsselfeld derDetailtabelle übertragen werden.

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 kom-men, falls die Daten nicht der referentiellen Integrität entsprechen. Entweder Sieleben damit und passen anschließend eventuell zu Null geänderte Inhalte vonFremdschlüsselfeldern an oder kümmern sich vorher um die Integrität der Daten.


Beziehungen 71

Mit der Option Löschweitergabe an verwandte Datensätze legen Sie fest, dass beimLöschen eines Datensatzes der Mastertabelle auch alle Datensätze der Detailtabellegelöscht werden. Im Beispiel Kunden und Projekte bedeutet das Folgendes: Wenn Sieeinen Kunden löschen, entfernt Access auch alle dazugehörenden Projekte.

2.4.4 1:n-Beziehungen

Die 1:n-Beziehung ist die Mutter aller Beziehungen. Alle weiteren Beziehungstypensind Sonderfälle der 1:n-Beziehung, wie Sie weiter unten erfahren werden. Deshalb istes auch kein Zufall, dass gerade dieser Beziehungstyp für die einführenden Abschnittezum Thema Beziehungen ausgewählt wurde. Da Sie dort bereits die wichtigstenGrundlagen zu diesem Thema kennen gelernt haben, werden in diesem Abschnittlediglich einige Beispiele für den Einsatz von 1:n-Beziehungen vorgestellt.

Abbildung 2.23: Festlegen referentieller Integrität per Dialog

In anderen Büchern, Fachbeiträgen oder im Internet stoßen Sie vielleicht auch aufdie Bezeichnung n:1-Beziehung. Prinzipiell ist daran nichts auszusetzen, da hierlediglich die Reihenfolge vertauscht wurde. In der in diesem Buch verwendetenTerminologie macht das allerdings sehr wohl einen Unterschied: Hier ist eine 1:n-Beziehung die Beziehung zwischen zwei Tabellen, die Eigenschaften eines Objektsenthalten – also beispielsweise Kunden, Projekte, Artikel, Produkte, Unternehmenoder Fahrzeuge. Wenn Sie eine Beziehung zwischen zwei solchen Tabellen herstel-len, heißt sie in diesem Buch 1:n-Beziehung. Die nachfolgend vorgestellten n:1-Beziehungen verknüpfen eine der eben genannten Tabellen mit ausgegliedertenDaten wie Anrede, Geschlecht, Titel bei Adressen, Kategorie bei Artikeln oder Fahr-zeugart bei Fahrzeugen. Eine andere nachfolgend verwendete Bezeichnung fürdiese Tabellen ist Lookup-Tabelle.



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 inAbschnitt 2.6, »Datenmodell-Muster«.

2.4.5 n:1-Beziehungen oder Lookup-Beziehungen

n:1-Beziehungen verknüpfen Tabellen, deren Eigenschaften Objekte beschreiben, mitjenen, die ausgegliederte Eigenschaften dieses Objekts enthalten. Wenn Sie sich etwaeine Adresstabelle vorstellen, die ein Textfeld zur Angabe der Anrede enthält, würdenSie vermutlich ungern zu jedem Eintrag »Herr« oder »Frau« manuell hinzufügen wol-len. Statt dessen finden Sie in der Regel ein Kombinationsfeld vor, mit dem sich dergewünschte Eintrag auswählen lässt.

Das hat zwei entscheidende Vorteile: Erstens sparen Sie Tipparbeit bei der Eingabe die-ses Feldes und zweitens sorgen Sie so dafür, dass nur die für das Feld vorgesehenenEinträ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 aberdurchaus 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 alleDatensä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 ein-zige unrichtige Schreibweise für ein falsches Ergebnis.

Daher sollten Sie immer, wenn ein Feld häufig den gleichen Wert annimmt, ein Kombi-nationsfeld zur Eingabe der Daten in Erwägung ziehen, das aus den Daten einer ver-knüpften Tabelle gefüttert wird.

Es gibt auch die Möglichkeit, in der Felddefinition eine Wertliste als Datensatzherkunftfür ein Kombinationsfeld anzugeben. Dazu stellen Sie die in Abbildung 2.24 abgebilde-ten Eigenschaften ein.


Beziehungen 73

Ausgliedern eines Feldes in eine separate Tabelle

Folgendes Beispiel zeigt, wie Sie ein Feld aus einer Tabelle in eine neue Tabelle ausglie-dern. Ausgangspunkt ist die Tabelle aus Abbildung 2.25, die das Feld Anrede für diemanuelle Eingabe bereitstellt.

Um das Feld auszugliedern, legen Sie zunächst eine neue Tabelle namens tblAnredenmit den beiden Feldern AnredeID und Anrede an.

Legen Sie außerdem in der Tabelle tblAdressen ein neues Feld namens AnredeID mitdem Datentyp Zahl zum Herstellen der Verknüpfung an.

Nun brauchen Sie nur noch die verschiedenen Einträge des Feldes Anrede der TabelletblAdressen in die Tabelle tblAnreden zu übertragen und die dort verwendeten Werte fürdas Feld AnredeID in das gleichnamige neue Feld der Tabelle tblAdressen einzutragen.

Abbildung 2.24: Kombinationsfeldeinträge per Wertliste

Abbildung 2.25: Adressentabelle mit »hart codierten« Anreden



Keine Frage, dass Sie das für wenige Datensätze von Hand erledigen können, aberwenn die Adressen-Tabelle mehrere hundert Datensätze enthält, verwenden Sie viel-leicht besser zwei Aktionsabfragen oder die folgende VBA-Prozedur. Der Aufruf fürden hier vorliegenden Fall lautet folgendermaßen:

FeldAusgliedern "tblAdressen", "tblAnreden", "AnredeID", "Anrede"

Die Prozedur erwartet den Namen der Ausgangstabelle und der Zieltabelle sowie denNamen des Primärschlüsselfeldes der Zieltabelle und des Zielfeldes der auszuglie-dernden Daten. Diese beiden Felder heißen hier AnredeID und Anrede und müssen inder Ziel- und in der Ausgangstabelle gleich benannt sein:

Public Sub FeldAusgliedern(strAusgangstabelle As String, strZieltabelle _ As String, strSchluesselfeld As String, strFeldname As String)

Dim db As DAO.Database Dim rst As DAO.Recordset Dim lngSchluesselfeld As String Set db = CurrentDb Set rst = db.OpenRecordset(strAusgangstabelle, dbOpenDynaset) Do While Not rst.EOF 'Ermitteln, ob Eintrag schon in Lookuptabelle vorhanden ist lngSchluesselfeld = Nz(DLookup(strSchluesselfeld, strZieltabelle, _ strFeldname & " = '" & rst(strFeldname) & "'"), 0) 'Falls nicht, diesen Eintrag hinzufügen... If lngSchluesselfeld = 0 Then db.Execute "INSERT INTO " & strZieltabelle & "(" & strFeldname _ & ") VALUES('" & rst(strFeldname) & "')"

'...und Primärschlüssel ermitteln lngSchluesselfeld = Nz(DLookup(strSchluesselfeld, _ strZieltabelle, strFeldname & " = '" & rst(strFeldname) _ & "'"), 0) End If 'Verweisfeld auf Lookuptabelle mit Wert füllen rst.Edit rst(strSchluesselfeld) = lngSchluesselfeld rst.Update rst.MoveNext Loop


Beziehungen 75

Set rst = Nothing Set db = Nothing

End Sub

Listing 2.3: Ausgliedern von Daten in eine Lookup-Tabelle

Abbildung 2.26 zeigt das Ergebnis der Ausgliederung. Die im Feld Anrede vorhande-nen Werte wurden in die Tabelle tblAnreden eingetragen und die Werte des dortigenPrimärschlüsselfeldes in das neue Fremdschlüsselfeld AnredeID der Tabelle tblAdres-sen. Zur Kontrolle ist das alte Feld Anrede noch in der Ausgangstabelle vorhanden, die-ses können Sie aber ohne Bedenken löschen.

Damit Sie die Werte auch per Kombinationsfeld aus der Lookup-Tabelle auswählenkönnen, legen Sie mit dem Nachschlage-Assistenten eine Beziehung zwischen den bei-den Tabellen an. Wie das funktioniert, haben Sie bereits in Abschnitt 2.4.2, »Halbauto-matisches Festlegen von Beziehungen« erfahren.

2.4.6 m:n-Beziehungen

m:n-Beziehungen sind nichts weiter als zwei 1:n-Beziehungen, die zwei Tabellen übereine Hilfstabelle miteinander verknüpfen. Im Gegensatz zu einer einzelnen 1:n-Bezie-hung, mit der sich beliebig viele Datensätze der einen Mastertabelle mit einem Daten-satz der Detailtabelle verknüpfen lassen, ist das Ziel der m:n-Beziehung, dass sichjeder Datensatz der ersten Tabelle mit beliebig vielen Datensätzen der zweiten Tabelleverknüpfen lässt und umgekehrt.

Abbildung 2.26: Ergebnis der Ausgliederung eines Feldes in eine zusätzliche Tabelle



Beispiele für solche Beziehungen gibt es viele. Das bekannteste ist wohl die Verknüp-fung der Bestellungen-Tabelle mit der Artikel-Tabelle über eine Bestelldetails-Tabelle wiein der Nordwind-Datenbank (siehe Abbildung 2.27).

Diese Variante ist zugleich eine kompliziertere Form der m:n-Beziehung, die in derVerknüpfungstabelle zusätzliche Daten speichert.

m:n-Beziehung am Beispiel von Fahrzeugen und Sonderausstattungen

Ein einfacheres Beispiel sind Ausstattungsmerkmale von Fahrzeugen. Fahrzeuge habeneinige unveränderliche Eigenschaften wie Marke, Modell, Leistung und so weiter.Außerdem besitzt jedes Fahrzeug verschiedene Ausstattungsmerkmale, die aber beidem einen vorhanden und bei dem anderen nicht vorhanden sind. Ein nicht normali-siertes Datenmodell würde aus einer einzigen Tabelle mit einigen Dutzend Ja/Nein-Fel-dern für die einzelnen Ausstattungsmerkmale bestehen. Das ist legitim, kann aber zuProblemen führen: Zwar ändern sich die gängigen Ausstattungsmerkmale nur alleJubeljahre, aber sie ändern sich, und damit müssten Sie auch die komplette Datenbankvon der Tabelle bis zu den Formularen, Berichten und VBA-Modulen anpassen. Außer-dem wird für jede Ausstattung, die nicht vorhanden ist, Speicherplatz verschwendet.

Also legen Sie eine Tabelle mit sämtlichen Ausstattungsmerkmalen an und sorgen miteiner Verknüpfungstabelle dafür, dass Sie alle Fahrzeuge mit allen Ausstattungsmerk-malen kombinieren können (siehe Abbildung 2.28).

Die Verknüpfungstabelle ist dabei nichts anderes als eine Tabelle mit zwei Fremd-schlüsselfeldern, die die beiden Primärschlüsselfelder der zu verknüpfenden Tabellenreferenzieren. In der Entwurfsansicht sieht die Verknüpfungstabelle wie in Abbildung2.29 aus. Dort wird Ihnen vermutlich zuerst auffallen, dass es dort zwei als Primär-schlüssel gekennzeichnete Felder gibt. Genau genommen ist dies ein zusammenge-setzter Primärschlüssel, der verhindert, dass eine Kombination der beiden Felderzweimal eingegeben wird. Schließlich soll jedes Ausstattungsmerkmal jedem Fahr-zeug nur einmal zugewiesen werden.

Abbildung 2.27: Klassisches Beispiel einer m:n-Beziehung: Bestellungen und Artikel in der Nordwind-Datenbank


Beziehungen 77

Verknüpfungstabellen mit zusätzlichen Daten: Bestellungen und Artikel

Nun können Sie sich der Bestelldetails-Tabelle der Nordwind-Datenbank zuwenden, diebereits weiter oben kurz vorgestellt wurde. Dort befinden sich neben den beiden Fremd-schlüsselfeldern zum Herstellen der Beziehung noch weitere Felder zum Speichern vonEinzelpreis, Anzahl und Rabatt des jeweiligen Artikels. Dabei handelt es sich um indivi-duelle Daten für jede Kombination aus Bestellung und Artikel. Dass die Anzahl flexibelsein muss, ist klar, aber warum Einzelpreis und Rabatt? Der Einzelpreis ist zwar bereitsin der Tabelle Artikel festgelegt, es aber kann durchaus sein, dass der Preis sich einmaländert. Und wenn Sie diesen dann nur in der Artikel-Tabelle gespeichert haben und ihndort aktualisieren, dann wirkt sich das auch auf die Rechnungsbeträge aller bisherigenBestellungen aus. Daher muss der Preis unbedingt in Zusammenhang mit der Kombina-

Abbildung 2.28: m:n-Beziehung am Beispiel von Fahrzeugen und ihrer Ausstattung

Abbildung 2.29: Entwurfsansicht einer m:n-Verknüpfungstabelle



tion aus Bestellung und Artikel gespeichert werden. Und der Rabatt ist ohnehin eineGröße, die je nach Kunde oder je nach Angebot flexibel gestaltet wird – daher machtauch die Aufnahme dieses Feldes in die Verknüpfungstabelle Sinn.

Weitere Beispiele für m:n-Beziehungen

m:n-Beziehungen treten an vielen Stellen auf. Hier finden Sie zwei weitere Beispiele:

� Verteiler: Jeder Verteiler basiert auf einer m:n-Beziehung. Die beiden zu verknüp-fenden Tabellen enthalten die Publikation auf der einen und die Adressaten auf deranderen Seite. Die Verknüpfungstabelle ist einfach, es sind außer den beidenFremdschlüsselfeldern keine weiteren Felder notwendig.

� Projektteams: Jedes Projektteam besteht aus einem oder mehreren Mitarbeitern, undjeder Mitarbeiter gehört zu einem oder mehreren Projektteams. Der Verknüpfungs-tabelle könnte man eine dritte Verknüpfung hinzufügen, um die Funktion des jewei-ligen Teammitglieds festzulegen. Abbildung 2.30 zeigt das Datenmodell dieserVerknüpfung, bei der es sich eigentlich sogar um eine m:n:o-Verknüpfung handelt.

2.4.7 1:1-Beziehungen

1:1-Beziehungen trifft man relativ selten an, obwohl sie sehr hilfreich sein können. Eine1:1-Beziehung verknüpft jeden Datensatz mit nur einem Datensatz der verknüpftenTabelle und umgekehrt. Wozu soll das nun hilfreich sein? Solche Daten kann man dochauch in eine Tabelle schreiben? Diese Fragen sind durchaus berechtigt. Deshalb lernenSie nun die Gründe und Einsatzmöglichkeiten für 1:1-Beziehungen kennen.

Abbildung 2.30: m:n-Verknüpfung mit dritter Verknüpfung


Beziehungen 79

Es gibt häufig Fälle, in denen Tabellen aus endlos vielen Feldern bestehen. Das liegt oftdaran, dass die Tabellen recht verschiedenartige Daten enthalten sollen, von denenjede Art eigene Eigenschaften besitzt und damit neue Felder erzeugt.

Beispiel: Unterschiedliche Mitarbeiterarten

Ein Unternehmen sammelt die Daten aller Mitarbeiter in einer Tabelle und unterschei-det dabei zunächst nicht zwischen fest angestellten und freien Mitarbeitern. DieTabelle sieht wie in Abbildung 2.31 aus.

Enthält die Tabelle einen Angestellten, wird das Feld Stundensatz nicht benötigt, weilder Angestellte ein Gehalt bekommt. Handelt es sich um einen freien Mitarbeiter, sinddie Felder Personalnummer, Gehalt und AbteilungID überflüssig. Eine reale Mitarbeiter-tabelle enthält sicher noch viele weitere nützliche Felder für den Angestellten und denfreien Mitarbeiter, die aber im jeweils anderen Fall nicht benötigt werden. Oder kon-kret ausgedrückt: Hier wird einiges an Speicherplatz verschenkt.

Tabellen aufteilen und wieder verknüpfen

Um dies zu verhindern, trennt man einfach die nur für den Angestellten oder denfreien Mitarbeiter vorgesehenen Felder aus der Tabelle heraus und fügt diese in zweiweitere Tabellen namens tblAngestellte und tblFreieMitarbeiter ein.

Die Tabellen sehen nun so wie in Abbildung 2.32 aus. Die Tabelle tblMitarbeiter enthältnur noch die Daten, die für beide Mitarbeiterarten gelten. Die Tabelle tblFreieMitarbeiterenthält ein eigenes Primärschlüsselfeld, ein eindeutiges Feld namens PersonID zurHerstellung der 1:1-Beziehung und ein Feld mit den speziellen Informationen zu freienMitarbeitern – hier den Stundensatz. Die Tabelle tblAngestellte ist genauso aufgebaut,enthält aber die angestellten-spezifischen Informationen.

Abbildung 2.31: Entwurf einer Tabelle mit teilweise nicht benötigten Daten



Voraussetzung: Eindeutige Schlüsselfelder auf beiden Seiten der Beziehung

1:1-Beziehungen verbinden zwei Tabellen über eindeutige Felder. Primärindexfeldersind eindeutig und auch andere Felder können Sie als eindeutig festlegen. Dazu erstel-len Sie einfach einen entsprechenden Index über den Indizes-Dialog. Diesen zeigen Siean, indem Sie die gewünschte Tabelle in der Entwurfsansicht öffnen und den Menüein-trag Ansicht/Indizes auswählen.

Nach dem Öffnen dieses Dialogs werden Sie vermutlich verwundert sein, dass Accessnicht nur für das Primärschlüsselfeld, sondern auch noch für einige andere Felderscheinbar willkürlich Indizes angelegt hat (siehe Abbildung 2.33). Die Willkür hält sichaber in Grenzen: Access legt standardmäßig für alle Felder, deren Name eine der Zei-chenketten »ID«, »Schlüssel«, »Code« oder »Nummer« enthält, einen Index an. DieseEinstellung können Sie auf der Registerseite Tabellen/Abfragen des Optionen-Dialogs mitder Eigenschaft Autoindex beim Importieren/Erstellen anpassen (siehe Abbildung 2.34).

Wenn Sie in beiden Tabellen einen eindeutigen Index für das Feld PersonID angelegthaben, können Sie zum Verknüpfen schreiten. Dazu zeigen Sie wie gewohnt die zuverknüpfenden Tabellen im Beziehungen-Fenster an.

Nun kommt der wichtigste Schritt und hier müssen Sie besonders auf die Reihenfolgeachten: Ziehen Sie das Feld PersonID der Ausgangstabelle, also der Tabelle tblPersonen, indas Feld PersonID der Tabelle tblAngestellte. Definieren Sie referentielle Integrität undaktivieren Sie die Option Löschweitergabe an verwandte Datensätze. Hierfür ist die Reihen-folge wichtig: Der Dialog Beziehungen bearbeiten zeigt unter Tabelle/Abfrage die Ausgangs-tabelle und unter Verwandte Tabelle/Abfrage die Zieltabelle einer Löschweitergabe an. DieLöschweitergabe soll von der Tabelle tblPersonen ausgehen und nicht umgekehrt, dahermuss auch der Beziehungspfeil von dieser Tabelle ausgehen (siehe Abbildung 2.35).

Abbildung 2.32: Aufteilung einer Tabelle in eine Haupt- und zwei Untertabellen


Beziehungen 81

Abbildung 2.33: Einstellen eines eindeutigen Index

Abbildung 2.34: Anpassen der Feldnamen, die das automatische Anlegen eines Index forcieren



Übrigens: Sollte der Dialog Beziehungen bearbeiten im unteren Bereich nicht 1:1 als Bezie-hungstyp anzeigen, müssen Sie nochmals die Eindeutigkeit der beteiligten Tabellenprüfen.

Nach dem Anlegen der beiden 1:1-Beziehungen sieht das Ergebnis wie in Abbildung2.36 aus.

Abbildung 2.35: 1:1-Beziehung zwischen zwei Tabellen

Abbildung 2.36: Tabelle mit zwei 1:1-Beziehungen


Beziehungen 83

Wie arbeitet man mit per 1:1-Beziehung verknüpften Tabellen?

Eine solche Beziehung können Sie prinzipiell wie eine ganz normale Tabelle behandeln– Sie müssen nur eine geeignete Abfrage anlegen, um die Daten wieder zusammenzu-führen. Wie dies funktioniert und wie Sie Formulare nutzen, um solche Daten zu bear-beiten, erfahren Sie in Abschnitt 3.5 des Kapitels 3, »Abfragen«, und in Abschnitt 4.4.5 desKapitels 4, »Formulare«.

Wo kommen 1:1-Beziehungen sonst noch zum Einsatz?

Neben der »Spezialisierung« von Tabellen durch Anhängen von Tabellen mit weiterenInformationen gibt es noch weitere Gründe für den Einsatz von 1:1-Beziehungen:

� Eine Tabelle hat mehr als 255 Felder. Sicher gibt es Objekte, die so viele Eigenschaf-ten mitbringen. In der Regel sollte man aber das Datenmodell einer genaueren Prü-fung unterziehen, wenn eine Tabelle derart viele Felder besitzt.

� Eine Tabelle enthält eine Menge Felder, die aber nur selten benötigt werden. Diesegliedert man wie in obigem Beispiel in eine weitere Tabelle aus und gibt dort beiBedarf Daten ein. Beispiel: Ein Ja/Nein-Feld, das Datensätze beispielsweise zumDrucken festlegt. Dieses Feld benötigt man nie, außer wenn man zu druckendeDatensätze festlegen oder die ausgewählten Datensätze drucken möchte. Alsoerstellen Sie einfach eine eigene Tabelle und verknüpfen diese mit der Zieltabelle.

2.4.8 Reflexive Beziehungen

Reflexive Beziehungen sind Beziehungen, die Datensätze einer Tabelle mit Datensät-zen der gleichen Tabelle verknüpfen. Dabei enthalten die verknüpften Datensätzemeist unterschiedliche Rollen, etwa Vorgesetzter und Untergebener. Dabei handelt essich prinzipiell um eine klassische 1:n-Beziehung – es befindet sich lediglich die glei-che Tabelle auf beiden Seiten. Reflexive Beziehungen (manchmal auch rekursive Bezie-hungen genannt) können auch über eine Zwischentabelle hergestellt werden, um einereflexive m:n-Beziehung zu realisieren.

Reflexive 1:n-Beziehungen

Die Tabelle in Abbildung 2.37 greift das oben genannte Beispiel der Beziehung zwi-schen Mitarbeitern und Vorgesetzten auf. Dazu enthält die Tabelle tblMitarbeiterMit-Vorgesetzten ein Feld namens VorgesetzterID mit dem Datentyp Zahl.

Wer nun versucht, den Nachschlage-Assistenten zum Erstellen der gewünschtenBeziehung zu bewegen, wird feststellen, dass dieser nur andere Tabellen zum Erstellenvon Beziehungen anbietet, aber nicht die, für die eine Beziehung erstellt werden soll.



Hier ist also Handarbeit angesagt: Öffnen Sie also den Beziehungen-Dialog und fügenSie die Tabelle tblMitarbeiterMitVorgesetzten hinzu. Da sich auch dieser Dialog etwasbockig anstellt, wenn man die Tabelle mit sich selbst verknüpfen möchte, hilft nurnoch ein Trick: Fügen Sie eine zweite Instanz der Tabelle hinzu, indem Sie die TabelletblMitarbeiterMitVorgesetzten noch einmal einfügen.

Anschließend können Sie die Beziehung wie bei einer normalen 1:n-Beziehung hinzu-setzen; auch referentielle Integrität lässt sich problemlos festlegen (siehe Abbildung2.43). Das Aktivieren der Löschweitergabe ist übrigens nicht zu empfehlen – wennbeim Löschen des Chefs auch gleich alle Untergebenen aus der Datenbank verschwin-den, wird der neue Chef nicht besonders glücklich sein …

Reflexive m:n-Beziehungen

Weniger bekannt, da sehr selten verwendet, sind reflexive m:n-Beziehungen. Eines derrar gesäten Beispiele sind die Teile einer Produktdatenbank. Ein Produkt besteht ausmehreren Teilen, die wiederum aus anderen Teilen zusammengesetzt sind. Hier wer-

Abbildung 2.37: Entwurf einer Tabelle mit reflexiver Beziehung

Abbildung 2.38: Rekursive Beziehungen lassen sich im Beziehungen-Fenster nur über mehrere Instanzen derselben Tabelle anlegen.

Informationen über die Anzeige von Datensätzen, die in reflexiver Beziehung zu-einander stehen, finden Sie in Abschnitt 4.4.12 , Kapitel 4, »Formulare«.


Autowerte als Long oder GUID? 85

den also nicht nur Endprodukte verwaltet, die aus hunderten von Einzelteilen beste-hen, sondern auch Baugruppen, die Bestandteil anderer Baugruppen sind undwiederum weitere Baugruppen enthalten können.

Warum reicht hier eine reflexive 1:n-Beziehung nicht aus? Ganz einfach: Weil ein Teiloder eine Baugruppe nicht einer anderen Baugruppe, sondern mehreren Baugruppenals Bestandteil zur Verfügung stehen soll.

Und wie realisieren Sie eine reflexive m:n-Beziehung? Wie eine ganz normale m:n-Beziehung! Der einzige Unterschied ist, dass Sie zwei Instanzen der Tabelle tblProduktestatt zwei unterschiedliche Tabellen verwenden (siehe Abbildung 2.39).

Die Verknüpfungstabelle enthält – da die Namen der Primärschlüsselfelder beider ver-knüpften Tabellen gleich sind – Fremdschlüsselfelder mit Namen, die den Datensätzender verknüpften Tabellen gleichzeitig die Rolle in der Verknüpfung zuweisen. In die-sem Fall ist das übergeordnete Element die Baugruppe und das untergeordnete Ele-ment ein Teil. Zusätzlich enthält die Verknüpfungstabelle ein Feld namens Anzahl,damit man festlegen kann, wie viele Teile einer Sorte die Baugruppe enthält.

2.5 Autowerte als Long oder GUID?

In Access ist die Verwendung von Autowerten als Primärschlüssel praktisch als Stan-dard anzusehen. In manchen Fällen leisten GUIDs allerdings wertvolle Dienste, dieAutowerte nicht leisten können. So macht es beispielsweise sehr viel Sinn, Tabellen miteiner GUID als Autowert zu versehen, deren Daten gelegentlich archiviert und dazu ineine andere Tabelle übertragen und aus der ursprünglichen Tabelle gelöscht werden –gegebenenfalls befindet sich die Archivtabelle sogar in einer anderen Datenbank.

Sollten Sie diese Daten noch einmal in der Originaltabelle benötigen, müssen Sie sicher-stellen, dass die Daten unter dem alten Primärschlüssel eingetragen werden können.Das ist mit herkömmlichen Autowerten nicht möglich. Wenn Sie etwa den neuesten

Abbildung 2.39: Reflexive m:n-Beziehung



Datensatz einer Tabelle in die Archivdatenbank übertragen und die Originaldatenbankkomprimieren, wird der Autowertzähler so eingestellt, dass er als Nächstes die Zahlverwendet, die um eins größer als die bisher größte verwendete Zahl ist. Das heißt, dassunter Umständen der Primärschlüsselwert des archivierten Datensatzes bereits ver-geben ist.

Bei der Verwendung von GUIDs als Primärschlüssel können Sie archivierte Datensätzeproblemlos wieder einfügen. Das liegt daran, dass ein Wert des Typs GUID weltweiteinzigartig ist. Wenn Sie sich ein Beispiel für einen solchen Wert ansehen, verstehenSie, warum das tatsächlich wahr sein kann:

{B9FF24C2-C32D-4053-B5FB-FCAF8AC8C7FC}

Ein GUID besteht aus 32 Zeichen, von denen jedes Zeichen mit einer Zahl von 0 bis 9oder einem Buchstaben von A bis F gefüllt werden kann – also mit einer hexadezima-len Zahl. Das ergibt insgesamt 3,4 x 1038 Möglichkeiten.

Ein weiterer Anwendungszweck für GUIDs ist die Replikation und Synchronisation.Bei der Replikation kann man eine oder mehrere Kopien einer Datenbank erstellen, diedann unabhängig voneinander geändert und anschließend synchronisiert werden kön-nen. Dazu gehört auch, dass man in den unterschiedlichen Replikationen neue Daten-sätze anlegt. Auch dort werden GUIDs zur eindeutigen Kennzeichnung der Datensätzeverwendet. Weitere Informationen zur Replikation erhalten Sie in Abschnitt 17.6 desKapitels 17, »Installation, Betrieb und Wartung«.

2.6 Datenmodell-MusterAuch die Kenntniss der einzelnen Beziehungstypen und der Normalisierung garan-tiert noch lange kein perfektes Datenmodell. Dazu gehört auch eine Menge Erfahrungoder eine Vorlage, von der man weiß, dass sie bereits erfolgreich in der Praxis einge-setzt wurde. Die gute Nachricht ist, dass es bei den meisten Anwendungen nur einenWeg gibt, um das Datenmodell umzusetzen – natürlich unter Berücksichtigung derNormalisierung. Den muss man allerdings erst einmal finden – und dabei soll dienachfolgende Sammlung von Datenmodell-Mustern helfen.

Es handelt sich dabei um grundlegende Datenmodelle für verschiedene Anwendungs-fälle – wobei nicht nur geschäftliche Themen betrachtet werden, sondern auch die eineoder andere Heimanwendung unter die Lupe genommen wird.

2.6.1 Adressen-/Kundenverwaltung

Wer mit Access arbeitet, hat in den meisten Fällen auch schon einmal eine Adressver-waltung programmiert, wenn er sich nicht sogar am Beispiel einer Adressverwaltungin Access einarbeiten durfte. So trivial wie diese Anwendung zunächst scheint, so


Datenmodell-Muster 87

kompliziert kann sie in bestimmten Fällen werden. Das gilt insbesondere dann, wennnicht nur Adressen mit den üblichen Daten wie Name, Straße, PLZ, Ort und den Kon-taktdaten wie Telefon- oder E-Mail gefragt sind, sondern auch die Unternehmen derjeweiligen Personen ins Spiel kommen. All diese Daten lassen sich leicht in einerTabelle unterbringen, die beispielsweise tblPersonen heißt. Unter Umständen hängt andieser Tabelle noch eine Lookup-Tabelle mit den Anreden (siehe Abbildung 2.40).

Was auffällt, sind die vielen Kontaktmöglichkeiten via Telefon oder E-Mail. Diese las-sen sich leicht in eine weitere Tabelle ausgliedern, die per 1:n-Beziehung mit derTabelle tblPersonen_1 verknüpft wird (siehe Abbildung 2.41).

Wenn Sie aber mehr aus den Adressen machen möchten – etwa um sich in RichtungCustomer Relation Management zu bewegen – wird es komplizierter. Der erste Schritt indiese Richtung ist, dass Sie die im Feld Firma gespeicherten Unternehmen in einereigenen Tabelle speichern und von der Tabelle tblPersonen auf diese Tabelle verweisen.Dadurch können Sie alle Unternehmensdaten in einer einzigen Tabelle unterbringenund diese konsistent halten.

Abbildung 2.42 zeigt, wie das Datenmodell nach dieser weiteren Änderung aussieht.Die Unternehmensdaten sind komplett in der Tabelle tblUnternehmen_2 untergebracht,auf die nun von der Tabelle tblPersonen_2 verwiesen wird. Dies ist ein Zustand, aufdem man eine CRM-Anwendung aufbauen kann – Unternehmen und Personen befin-den sich in einzelnen, miteinander verknüpften Tabellen.

Abbildung 2.40: Datenmodell einer einfachen Adressverwaltung



Damit ist sichergestellt, dass nicht zwei Datensätze der Personen-Tabelle unterschied-liche Firmendaten enthalten, wie das noch in der Fassung in Abbildung 2.41 möglichwar. Außerdem können Sie jedem Unternehmen beliebig viele Personen zuordnen.

Abbildung 2.41: Adressentabelle mit ausgegliederten Kontaktmöglichkeiten

Abbildung 2.42: Personen und Unternehmen



Das Ende der Fahnenstange ist damit allerdings noch lange nicht erreicht. Die Unter-nehmen lassen sich noch zu Konzernen zusammenfassen, was eine weitere Tabelleerfordern würde. Auch über die Beziehung zwischen Personen und Unternehmen istnoch nicht das letzte Wort gesprochen: Was ist beispielsweise mit freien Mitarbeitern,die Sie schließlich auch unter einer beruflichen Telefonnummer erreichen möchten?Freie Mitarbeiter sind ja gerade deshalb »frei«, weil sie nicht nur für ein Unternehmenarbeiten. Theoretisch müssten Sie also zwischen Personen und Unternehmen eine m:n-Beziehung erstellen.

Und wie gehen Sie vor, wenn Sie eine Liste nicht nur aller Unternehmen oder aller Per-sonen, sondern etwa eine Gesamtliste von Unternehmen und Personen ausgebenmöchten? Gegebenenfalls könnten Sie die gewünschten Daten per UNION-Abfragezusammenfassen (was eine UNION-Abfrage ist, erfahren Sie in Abschnitt 3.3 des Kapi-tels 3, »Abfragen«).

Wie Sie sehen, ist die Verwendung der Adressdaten von Unternehmen und Personenkeine triviale Angelegenheit. Die genannten Konfigurationen sind Beispiele, die Siebeim Erstellen einer Adressenverwaltung nach Sichtung der individuellen Gegeben-heiten berücksichtigen können.

2.6.2 Rezepteverwaltung

Um zu ermitteln, welche Daten eine Rezepteverwaltung enthalten muss, schlagen Sieeinfach ein beliebiges Kochbuch auf und schauen sich an, welche Informationen dortpro Rezept enthalten sind. Jedes Rezept enthält die Angabe der benötigten Zutaten mitMenge und Einheit, die Beschreibung, die Zubereitungsdauer, die Anzahl der Perso-nen, die sich an dem Ergebnis laben kann, und vielleicht noch ein Foto. Da ein Koch-buch meist von einem einzigen Autor stammt, wird dieser nicht explizit für jedesRezept angegeben – das wäre das einzige Feature, das man seinem Datenmodell nochzusätzlich gönnen sollte. Vermutlich möchten Sie Rezepte verschiedener Autoren ineiner Datenbank sammeln.

Diese Informationen werden allerdings bereits im ersten Ansatz auf insgesamt siebenTabellen aufgeteilt (siehe Abbildung 2.43) – und hier sind noch Verfeinerungen mög-lich. Doch zunächst zu dieser Version des Datenmodells: Informationen wie dieBeschreibung, die Dauer der Zubereitung, die Anzahl Portionen, der Autor und derPfad zu einer Abbildung befinden sich in der Haupttabelle tblRezepte. Da mehrereRezepte vom gleichen Autor stammen können, wird dessen Name noch in eine Lookup-Tabelle namens tblAutoren ausgegliedert.

Beispieldatenbank: Eine Datenbank mit vorbereitetem Datenmodell finden Sie aufder Buch-CD unter /Kap_02/Adressverwaltung.mdb.



Eine nützliche Geschichte für eine Rezeptesammlung ist die Angabe einer oder mehre-rer Kategorien wie Fleischgerichte, vegetarische Gerichte, Salate, Nudelgerichte oderSuppen. Für ausreichend Flexibilität – etwa, wenn sich einmal ein Gericht nicht ein-deutig zuordnen lässt – verknüpften Sie die Tabelle tblKategorien nicht direkt mit derTabelle tblRezepte, sondern über eine Zwischentabelle namens tblRezepteKategorien. Mitdieser m:n-Beziehung lassen sich jedem Rezept mehrere Kategorien zuordnen.

Das Wichtigste sind natürlich die Zutaten: Diese werden zunächst in einer eigenenTabelle namens tblZutaten erfasst. Über die Zwischentabelle tblRezepteZutaten werdennicht nur die Zutaten zu einem Rezept, sondern auch noch Menge und Einheit festge-legt. Die Einheiten sollten – wie der Name schon sagt – immer einheitlich gewählt wer-den, weshalb Sie diese in die Tabelle tblEinheiten auslagern und mit der TabelletblRezepteZutaten verknüpfen.

Dieses Datenmodell ermöglicht nicht nur die Ausgabe von Rezepten mit den angege-benen Informationen, sondern auch noch die Berechnung von Rezepten für eineandere Anzahl hungriger Esser als im Feld AnzahlPortionen angegeben. Um solch einalternatives Rezept zu berechnen, müssen Sie lediglich die in der Tabelle tblRezepteZu-taten angegebene Menge je Zutat durch die Anzahl zu verköstigenden Personen teilenund mit der Zahl der gewünschten Mahlzeiten multiplizieren.

Abbildung 2.43: Datenmodell einer Rezepteverwaltung



Erweiterungsmöglichkeiten

Das Datenmodell bietet noch die Erweiterungsmöglichkeit, mehrere Bilder zu einemRezept zu speichern oder die einzelnen Schritte der Rezeptbeschreibung in einer eige-nen Tabelle zu speichern. Wie grob man dies vornimmt, bleibt jedem selbst überlassen– sinnvoll könnte aber auf jeden Fall die Aufteilung in einzelne Elemente wie »Fleisch-zubereitung«, »Beilagen« und »Sauce« sein. Das führt aber spätestens bei Gerichten, indenen zur Optimierung der Zubereitungszeit mehrere Elemente gleichzeitig zubereitetwerden, zu Problemen – das Speichern der Beschreibung in einem einzigen Feldscheint also sinnvoller zu sein.

2.6.3 Artikelverwaltung

Mit der Nordwind-Datenbank als Bestandteil von Access bietet Microsoft ein Beispielfür eine Artikelverwaltung, die sich von Version zu Version jeglicher Namenskonven-tion widersetzt. Immerhin liefert das Datenmodell Beispiele für fast alle gebräuchli-chen Beziehungstypen mit Ausnahme der 1:1-Beziehung. Nicht auf den ersten Blick zuerkennen ist die reflexive Beziehung in der Personal-Tabelle. Dort lässt sich als Wert desFeldes Vorgesetzte(r) ein Eintrag der gleichen Tabelle auswählen (siehe Abbildung 2.44).

Das Datenmodell ist für eine Beispieldatenbank durchaus in Ordnung, der täglicheEinsatz dürfte jedoch noch einige Erweiterungen verlangen. So wäre es beispielsweisepraktisch, wenn man die bestellten Artikel direkt in die Bestandsverwaltung einbezie-hen könnte. Diese würde also nicht nur die Ausgänge der bestellten und anschließendverkauften Artikel verwalten, sondern auch den Wareneingang, und gegebenenfallsnotwendige Umbuchungen erfassen, etwa zurückgelieferte Ware oder bei Inventurenfestgestellte Fehlmengen.

Natürlich könnten Sie dies mit zwei weiteren Tabellen erledigen, die ähnlich wie dieTabelle Bestelldetails aufgebaut sind, und für Bestandserfassungen die bewegten Warenper Union-Abfrage zusammenfassen.

Eine andere Möglichkeit ist die aus Abbildung 2.45. Mit diesem Datenmodell gehenSie das Problem von einer anderen Warte an: Hier werden alle Bewegungen in einereinzigen Tabelle namens tblBestandsaenderungen erfasst. Die Tabelle ist per 1:1-Bezie-hung etwa mit einer Tabelle namens tblPositionen verknüpft. Zusammen enthaltendiese beiden Tabellen genau die gleichen Daten wie die Tabelle Bestelldetails in derNordwind-Datenbank. Arbeiten können Sie mit diesen Daten – wie bereits weiter obenerwähnt – indem Sie diese einfach per Abfrage zusammenfassen.

Beispieldatenbank: Eine Datenbank mit vorbereitetem Datenmodell finden Sie aufder Buch-CD unter /Kap_02/Rezeptverwaltung.mdb.



Der Vorteil dieser Vorgehensweise ist, dass sich die für die Erfassung der Warenein-gänge und der Umbuchungen benötigten Informationen in Form der ZusatztabellentblWareneingang und tblUmbuchungen ebenfalls per 1:1-Beziehungen an die TabelletblBestandsaenderungen anfügen lassen. Die Bestandsänderungen sind dennoch alle ineiner einzigen Tabelle verfügbar. Unterschiede zwischen Ein- und Ausgängen markiertdas Feld Vorzeichen, das bei Ausgängen den Wert –1 enthält und bei Eingängen denWert 1.

2.6.4 CD-Verwaltung

»In welchem Fach von welchem Schrank ist noch mal die Depeche Mode-CD mit demSong Photographic versteckt?« – so oder ähnlich fragen begeisterte CD-Sammler. Undwer seine Sammlung sicher verwalten und jederzeit die gewünschten Titel findenmöchte, baut natürlich eine eigene CD-Verwaltung auf Access-Basis auf.

Und dabei muss man noch nicht einmal alle CDs und Tracks selbst erfassen, denn imInternet finden sich Datenserver, die zu einer eindeutigen ID einer CD online alleDaten zur Verfügung stellen. Ein Beispiel für diesen Service, der praktischerweise nochein .ocx-Steuerelement für die Verwendung unter VBA mitliefert, findet sich unter derInternetadresse http://freedb.org.

Diesem System lehnt sich auch das folgende Datenmodell an: Es enthält lediglich dreiTabellen, wobei die CDs und die Tracks in je einer Tabelle gespeichert werden undbeide die Interpreten aus einer Lookup-Tabelle beziehen (siehe Abbildung 2.46).

Abbildung 2.44: Das Datenmodell der Nordwind-Datenbank



Zwischen CDs und Tracks ergibt sich eine klassische 1:n-Beziehung, da jeder Track sichgenau einer CD zuordnen lässt, jede CD aber aus mehreren Tracks besteht. Aber ist daswirklich so? Kann nicht ein Track auf einem Album, auf einer Maxi-CD und vielleichtnoch auf verschiedenen Samplern vorhanden sein? Natürlich ist das möglich, aber dasich hier meist auch noch die Spieldauer und die Version unterscheiden, scheint einem:n-Beziehung hier doch unangemessen.

Die Felder sind im Gegensatz zu den sonstigen Gepflogenheiten dieses Buchs nicht mitdeutschen Namen versehen. Namensgeber war in diesem Fall das Objektmodell deruFreeDB-Bibliothek.

Abbildung 2.45: Erweiterung der Bestellverwaltung um Wareneingang und Umbuchungen

Abbildung 2.46: Datenmodell einer CD-Verwaltung



2.6.5 Projektverwaltung

Wer keine professionelle Software für die Verwaltung von Projekten verwendenmöchte, kann sich mit einer passenden Access-Anwendung helfen. Abbildung 2.47zeigt ein rudimentäres Datenmodell für eine solche Projektverwaltung.

Es basiert darauf, dass jedes Projekt von einem Kunden in Auftrag gegeben wird,wobei für interne Projekte einfach das eigene Unternehmen als Kunde eingetragenwerden kann. Jedem Kunden können Sie mehrere Projekte zuweisen, daher sind dieTabellen tblKunden und tblProjekte mit einer 1:n-Beziehung verknüpft. Projekte habeneinen Namen, eine Dauer, eine Leitung und vor allem einzelne Projektphasen (mindes-tens aber eine). Die Projektphasen haben wiederum eine Bezeichnung, eine Leitungsowie ein Start- und ein Enddatum. Konkreter wird es auf der nächsten Ebene: Projekt-phasen gliedern sich in Tätigkeiten, die in der Tabelle tblTaetigkeiten gespeichert wer-den. Diese sind immer auf einen Tag begrenzt, daher enthält die Tabelle einDatumsfeld sowie zwei weitere Felder zur Angabe der Start- und der End-Uhrzeit.Außerdem werden hier eine Tätigkeitsbeschreibung und der Tätigkeitstyp eingegeben.

Beispieldatenbank: Eine Datenbank mit vorbereitetem Datenmodell finden Sie aufder Buch-CD unter /Kap_02/CD-Verwaltung.mdb.

Abbildung 2.47: Datenmodell einer Projektverwaltung



2.6.6 Mitarbeiterverwaltung

Das Datenmodell aus Abbildung 2.48 zeigt ein rudimentäres Abbild dessen, was Siebei einer Mitbearbeiterverwaltung berücksichtigen müssen. Wichtig ist hier vor allemdie Aufteilung der Informationen über einen Mitarbeiter auf die Mitarbeiterdaten undauf die Beschäftigungsdaten.

Die Daten in der Tabelle tblMitarbeiter können sich ändern, ohne dass sich dies auf dasBeschäftigungsverhältnis auswirkt – der Mitarbeiter kann seinen Wohnsitz, seineBankverbindung, seine Telefonnummern wechseln und es werden einfach die aktuel-len Daten weiter verwendet. Für die Personalabteilung ist es viel interessanter, wannder Mitarbeiter in welcher Position und in welcher Abteilung gearbeitet hat.

Deshalb finden Sie im Datenmodell eine Tabelle namens tblBeschaeftigungen, die alleInformationen über die einzelnen Beschäftigungsverhältnisse enthält. Neben Abtei-lung und Position finden sich auch Details darüber, in welchen Räumlichkeiten derMitarbeiter sein Unwesen treibt und wer sein Vorgesetzter ist. Das Feld VorgesetzterIDist übrigens auch mit der Tabelle tblMitarbeiter verknüpft; aus Platzgründen wurdediese Tabelle jedoch nicht noch einmal zusätzlich abgebildet.

In die beiden Felder Eintrittsdatum und Austrittsdatum tragen Sie ein, wie lange diejeweiligen Beschäftigungsverhältnisse gedauert haben.

Erweiterungsmöglichkeiten bieten sich hier in ausreichender Menge – so können SieDaten zu Lohn/Gehalt ebenfalls in der Tabelle tblBeschaeftigungen unterbringen oderauch Verweise auf die Standorte der jeweiligen Arbeitsverträge hinterlegen.

2.6.7 Literaturverwaltung

Wenn ein Unternehmen Fachbücher, Magazine und sonstige Literatur zentral einkauftund lagert, macht eine Literaturverwaltung Sinn. Im Mittelpunkt des Datenmodellseiner solchen Verwaltung steht die Tabelle tblLiteratur. Sie enthält die wichtigstenInformationen über die einzelnen Werke wie Titel, Erscheinungsjahr, Schlagwörteroder einen Abstract. Weitere Informationen wie Verlag und Dokumenttyp befinden sichin Lookup-Tabellen (siehe Abbildung 2.49).

Beispieldatenbank: Eine Datenbank mit vorbereitetem Datenmodell finden Sie aufder Buch-CD unter /Kap_02/Mitarbeiterverwaltung.mdb.



Für die Angabe der Autoren ist hingegen eine m:n-Beziehung erforderlich, denn ers-tens kann es mehrere Autoren je Werk geben und zweitens schreiben Autoren unterUmständen für mehr als eine Publikation. Zusätzlich liefert das Datenmodell denKomfort, dass man der Kombination aus Veröffentlichung und Autor noch die Funk-tion des Autors hinzufügen kann – unter Umständen gibt es Haupt- und Co-Autoren,die Sie ebenfalls in der Datenbank speichern möchten.

Wichtig ist vor allem in größeren Unternehmen die Verwaltung der Standorte: WennSie schon den Literaturbestand in einer Datenbank verwalten, möchten Sie vielleichtauch wissen, wo sich die einzelnen Werke zu einem bestimmten Zeitpunkt befinden.Dazu legen Sie in der Tabelle tblStandorte alle vorhandenen Standorte fest und ver-knüpfen diese wiederum mit einer m:n-Beziehung mit der Tabelle tblLiteratur. Warumnun mit einer m:n-Beziehung – eine Veröffentlichung hat doch in der Regel auch nureinen Standort? Das ist richtig, aber wer zum Beispiel Zeitschriften in der Literaturver-waltung hütet, möchte vielleicht auch deren Rundlauf durch die Abteilungen verfol-gen, bevor diese ihren endgültigen Platz finden.

Wer es den Benutzern ganz besonders angenehm machen möchte, kann auch noch diein einem Buch enthaltenen Verweise auswerten und eine reflexive Verknüpfung erstel-len. In diesem Fall wird dort noch die Tabelle tblVerweise zwischengeschaltet, um ge-gebenenfalls Bemerkungen unterzubringen (zum Beispiel »Das Buch … liefertweiterführende Informationen zum Thema …«).

Abbildung 2.48: Datenmodell einer Mitarbeiterverwaltung



2.6.8 Mitgliederverwaltung

Wegen der hohen Anzahl Vereine in Deutschland sollte man meinen, dass Mitglieder-verwaltungen eine der meistgebrauchten Anwendungen überhaupt sind. Mit einemgewissen Grundstock können Sie Mitgliederverwaltungen für alle möglichen Vereineerstellen.

Abbildung 2.50 liefert eine solche Grundausstattung: Im Mittelpunkt steht hier dieTabelle tblMitglieder, in der prinzipiell alle Daten erfasst werden. Neben dieser Tabellegibt es nur einige Lookup-Tabellen zur Auswahl von Daten.

Wichtig ist: Mitglieder – vor allem von Sportvereinen – wollen sich untereinanderimmer und überall erreichen können, um Wettkämpfe und/oder gesellschaftlicheAnlässe zu verabreden. Im Gegensatz zur Kontaktverwaltung in Unternehmen sollenhier möglichst die private, die geschäftliche und die mobile Telefonnummer gepflegt

Abbildung 2.49: Datenmodell einer Literaturverwaltung

Beispieldatenbank: Eine Datenbank mit vorbereitetem Datenmodell finden Sie aufder Buch-CD unter /Kap_02/Literaturverwaltung.mdb.



werden. Da hierfür eine ganze Menge Felder draufgehen können, sind diese Daten inzwei weitere Tabellen ausgelagert.

Dabei dient die Tabelle tblTelefonnummern als Verknüpfungstabelle zwischen denTabellen tblMitglieder und tblTelefonnummerarten. Letztere enthält Einträge wie Privat(Festnetz), Privat (Mobil), Privat (Fax), Geschäftlich (Festnetz), Geschäftlich (Mobil)oder Geschäftlich (Fax). Die Tabelle tblTelefonnummern speichert das Mitglied und dieTelefonnummerart sowie die eigentliche Telefonnummer.

Die Lookup-Tabellen sind weitgehend selbsterklärend. Die Tabelle tblZahlungsartenenthält Informationen wie Bankeinzug oder Überweisung, die Tabelle tblFunktionendie Aufgabe innerhalb des Vereins (erster Vorsitzender, Schriftführer, Jugendwart etc.),die Tabelle tblBeitragsklassen Einträge wie Jugendlicher oder Erwachsener und dieTabelle tblMitgliedsarten gibt an, ob es sich um ein aktives oder passives Mitgliedhandelt.

Abbildung 2.50: Datenmodell einer Mitgliederverwaltung

Beispieldatenbank: Eine Datenbank mit vorbereitetem Datenmodell finden Sie aufder Buch-CD unter /Kap_02/Vereinsverwaltung.mdb.



2.6.9 Urlaubsverwaltung

Die Verwaltung von Urlaub ist gerade in der Sommerzeit eine knifflige Angelegenheit.Mit einer passenden Access-Anwendung haben Sie nicht nur die verbleibendenUrlaubstage im Griff, sondern können sich auch per Bericht ausgeben lassen, wo esbesonders eng wird. Eine weitere mögliche Funktion ist das Festlegen von Stellvertre-tern für die Zeit des Urlaubs eines Mitarbeiters.

Das Datenmodell aus Abbildung 2.51 sorgt hier für die Grundlage. Im Mittelpunkt ste-hen die Mitarbeiter, die in der Tabelle tblMitarbeiter gespeichert werden. Dazu gehörenInformationen wie Name, Position, Abteilung, Kontakt- und Firmenzugehörigkeits-daten.

Mit den beiden Tabellen tblAbwesenheiten und tblAbwesenheitsarten pflegen Sie nichtnur die Urlaubstage, sondern auch übrige Abwesenheitszeiten durch Krankheit oderFortbildungen – weiteren Variationen öffnen Erweiterungen der Tabelle tblAbwesen-heitsarten Tür und Tor.

Durch eine zusätzliche Verknüpfung von der Tabelle tblAbwesenheiten zur TabelletblMitarbeiter – in der Abbildung durch die Tabelle tblMitarbeiter_1 repräsentiert –ermöglichen Sie das Zuweisen eines Stellvertreters für die Zeit der Abwesenheit.

Und damit niemand mehr Urlaub nimmt, als er darf, speichert die Tabelle tblUr-laubsanspruch den individuellen Anspruch pro Mitarbeiter und pro Jahr. Das FeldJahrID dieser Tabelle und die Verknüpfung zur Tabelle tblJahre sorgen dafür, dass Sieden Mitarbeitern über die Jahre eine unterschiedliche (in der Regel steigende) AnzahlUrlaubstage zuweisen können. So lassen sich auch im Nachhinein die verfallenen oderins Folgejahr übertragenen Urlaubstage genau nachhalten.

2.6.10 Aufgabenverwaltung

Für Entwickler – egal, ob als Einzelgänger oder im Rudel – kann eine Aufgabenverwal-tung eine sehr sinnvolle Sache sein. Damit lassen sich Aufgaben in eine Datenbank ein-tragen und mit wichtigen Informationen versehen: eine Priorität für das Abarbeiten inder richtigen Reihenfolge, ein Status für den Projektmanager, Informationen über denUrheber und den Ausführenden der Aufgabe, das geplante Enddatum für die Fertig-stellung und mehr. All diese Informationen werden in der Tabelle tblAufgaben gespei-chert (siehe Abbildung 2.52).

Beispieldatenbank: Eine Datenbank mit vorbereitetem Datenmodell finden Sie aufder Buch-CD unter /Kap_02/Urlaubsverwaltung.mdb.



Von dort aus gibt es zwei Verknüpfungen zur Tabelle tblBenutzer: eine, um den Benut-zer festzulegen, der die Aufgabe erstellt hat, und eine, um den Ausführenden zu kenn-zeichnen.

Jede Aufgabe lässt sich noch in einzelne Aktionen zerlegen, weshalb eine weitereTabelle namens tblAktionen mit einer 1:n-Beziehung an die Tabelle tblAufgaben ange-hängt wird. Hier finden sich einige Felder der Tabelle tblAufgaben wieder. Interessantist hier vor allem das Feld Verbrauchte Zeit. Über die Summe der Zeiten aller Aktioneneiner Aufgabe lässt sich ermitteln, ob die in der Tabelle tblAufgaben gemachte Angabeüber die erwartete Dauer realistisch war oder nicht und wo es gegebenenfalls gehakthat.

2.6.11 Projektzeitverwaltung

In eine ähnliche Richtung wie die Aufgabenplanung geht die Projektzeitverwaltung.Allerdings ist diese ein wenig projektorientierter und zielt konkret auf die Ermittlungdes zeitlichen Aufwands zu Abrechnungszwecken ab. Im Mittelpunkt stehen die Pro-jektzeiten – das sind die Zeiten, die ein Mitarbeiter mit dem Bearbeiten eines bestimm-ten Projekts verbringt.

Abbildung 2.51: Datenmodell einer Urlaubsverwaltung

Beispieldatenbank: Eine Datenbank mit vorbereitetem Datenmodell finden Sie aufder Buch-CD unter /Kap_02/Aufgabenverwaltung.mdb.



Die Tabelle tblProjektzeiten erfasst das Projekt, die Mitarbeiter, Startzeit und Endzeitsowie Tätigkeitsbeschreibung und Tätigkeitsart (siehe Abbildung 2.53). Die Projekteund Mitarbeiter stammen aus den verknüpften Tabellen tblProjekte und tblMitarbeiter.An der Tabelle tblProjekte hängt vorsichtshalber direkt die Tabelle mit den Kunden –falls Sie einmal das Budget überschreiten und den Kunden benachrichtigen müssen,haben Sie die notwendigen Informationen sofort zur Hand …

Die Tabelle der Projekte enthält eine Projektbezeichnung und eine Beschreibung, Start-und Enddatum sowie die Angabe, welcher Mitarbeiter Projektleiter und damit verant-wortlich für die Zuweisung der Zeiten ist.

Die Erfassung von Zeiten macht natürlich nur Sinn, wenn die Mitarbeiter diese konti-nuierlich pflegen – und das machen sie vermutlich lieber, wenn dies schnell geht undnicht viel Zeit kostet. Dazu sollte der Mitarbeiter nicht erst lange nach »seinen« Projek-

Abbildung 2.52: Datenmodell einer Aufgabenverwaltung



ten suchen müssen, sondern alle Projekte, an denen er beteiligt ist, direkt vorliegenhaben und möglichst selbst sortieren können. Die Voraussetzung schaffen Sie mit derTabelle tblProjekteMitarbeiter, mit der Sie erstens überhaupt festlegen, welcher Mitarbei-ter Projektzeiten für welche Projekte anlegen kann. Zweitens können die Mitarbeiter»ihre« Projekte mit dem Feld Aktiviert ein- oder ausblenden und mit dem Feld Reihen-folgeID nach ihren eigenen Wünschen anordnen.

2.6.12 Kunden und Weihnachtsgeschenke

Alle Jahre wieder nähert sich das Weihnachtsfest und Hektik macht sich breit – unddas nicht nur in Innenstädten und Einkaufszentren, sondern auch in bestimmtenAbteilungen der Unternehmen. Dort sollen nämlich die alljährlichen Weihnachtsge-schenke zusammengestellt werden – und zwar möglichst nicht jedes Jahr das Gleicheund nach Beliebtheit der Kunden sortiert, sprich nach dem Umsatz.

Abbildung 2.53: Datenmodell einer Projektzeitverwaltung

Beispieldatenbank: Eine Datenbank mit vorbereitetem Datenmodell finden Sie aufder Buch-CD unter /Kap_02/Projektzeitverwaltung.mdb.



Das folgende Datenmodell liefert nicht nur die Ansprechpartner der einzelnen Unter-nehmen (tblPersonen und tblUnternehmen), sondern auch noch zwei Tabellen zum Ver-walten der Präsente (siehe Abbildung 2.54).

Dabei ist die Tabelle tblPersonenPraesente eine Verknüpfungstabelle zur Realisierungeiner m:n-Beziehung zwischen den Tabellen tblPersonen und tblPraesente. Auf dieseWeise lässt sich mehreren Personen das gleiche Präsent zuweisen, aber auch einer Per-son mehrere Präsente.

Der Clou ist das zusätzliche Feld Jahr in der Verknüpfungstabelle: Darüber halten Siezusätzlich nach, wer in welchem Jahr womit beglückt wurde – nicht, dass jemanddenkt, er sei in der Gunst gesunken, nur weil er eine Flasche Wein weniger bekommt.

Als Präsent können Sie hier im Übrigen auch die Weihnachtskarten erfassen.

Abbildung 2.54: Datenmodell einer Präsenteverwaltung

Beispieldatenbank: Eine Datenbank mit vorbereitetem Datenmodell finden Sie aufder Buch-CD unter /Kap_02/Praesenteverwaltung.mdb.



2.6.13 Fahrtenbuch

Ein Fahrtenbuch zu führen, ist eigentlich kein Problem. Man fährt, trägt seinen Namen,die Strecke und ein paar weitere Informationen ein und schon ist man fertig. Arbeit hatdann derjenige, der die im Fahrtenbuch enthaltenen Informationen für den Arbeitge-ber oder das Finanzamt auswerten muss.

Einfacher geht das mit einem elektronischen Fahrtenbuch – natürlich auf Access-Basis.Die Tabelle tblFahrten enthält den größten Teil der benötigten Informationen. Sie ent-hält zwei Verknüpfungen zu den Lookup-Tabellen tblFahrer und tblNutzungsarten undist per 1:n-Beziehung mit der Tabelle tblFahrzeuge verknüpft. Diese sorgt dafür, dassdas Datenmodell mehr als ein Fahrzeug verträgt und Fahrtenbücher für einen beliebiggroßen Fuhrpark verwalten kann (siehe Abbildung 2.55). In Zusammenhang mit denFahrzeugen sind noch weitere Informationen interessant: Zum Beispiel Ausgaben fürReparaturen, Autowäsche und sonstiges Zubehör. Unter Ausgaben fallen eigentlichauch die Tankvorgänge. Wegen der vielen speziellen Informationen werden dieseallerdings in einer eigenen Tabelle namens tblTankvorgaenge gespeichert. Zu diesenInformationen zählen das Datum, der Kilometerstand, die Anzahl Liter und der Preisje Liter. Durch das Boolean-Feld Vollgetankt lässt sich später der durchschnittliche Ver-brauch zwischen mehreren Vollbetankungen ermitteln.

Abbildung 2.55: Datenmodell eines Fahrtenbuchs


Bilder und Dateien in Tabellen speichern 105

2.7 Bilder und Dateien in Tabellen speichern

Probleme mit dem Speichern von Dateien und insbesondere von Bildern in Dateiengehören in den Newsgroups und Foren zum täglichen Leben. Access bietet mit demDatentyp OLE-Objekt die Möglichkeit, auch Dateien in einer Tabelle zu speichern(siehe Abbildung 2.56). Leider gibt es in Access keine eingebaute einfache Funktion,um Dateien ohne Weiteres in einer Tabelle zu speichern – zumindest keine, die nichtfrüher oder später die Größe der Datenbankdatei explodieren lässt.

Beispieldatenbank: Eine Datenbank mit vorbereitetem Datenmodell finden Sie aufder Buch-CD unter /Kap_02/Fahrtenbuch.mdb.

Achtung: Wenn Sie mit dem Gedanken spielen, künftig mit einem per Rechnererstellten Fahrtenbuch beim Finanzamt vorstellig zu werden, erkundigen Sie sichdort auf jeden Fall vorher, welche Bedingungen dabei genau zu erfüllen sind.

Beispieldatenbank: Die Tabellen tblBilder und tblDateien, die Formulare frmBilder,frmBilderBinaer, frmVerknuepfteBilder und frmDateien sowie die Module mdlDateien-UndTabellen und mdlTools finden Sie unter Kap_02\TabellenDatenmodellierung.mdb.

Abbildung 2.56: Datentyp für Dateien und Bilder



2.7.1 Bilder im OLE-Feld speichern

Wenn Sie beispielsweise ein Formular an die Tabelle aus Abbildung 2.56 binden undalle Felder in den Detailbereich des Entwurfs ziehen, können Sie der Tabelle bereitsDateien hinzufügen. Dazu wählen Sie einfach den Eintrag Objekt einfügen… des Kon-textmenüs des entsprechenden Steuerelements aus (siehe Abbildung 2.57) und gebenim nächsten Dialog an, welche Datei Sie darin speichern möchten.

Da das Formular direkt an die Tabelle gebunden ist, wird die Datei direkt in derTabelle gespeichert. Der hier verwendete Eintrag des Kontextmenüs steht auch in derDatenblattansicht der Tabelle zur Verfügung. Es gibt aber keinen Anlass, irgendeineAktion direkt auf einer Tabelle auszuführen.

Benutzerfreundlich wäre diese Variante allerdings nicht – einen Eintrag namens Objekteinfügen…im Kontextmenü eines Steuerelements kann man nicht gerade »intuitiv«nennen.

Die Möglichkeit zum Speichern von Dateien in einer Access-Datenbank wird meistzum Speichern von Bilddateien verwendet. Die folgenden Ausführungen beziehensich größtenteils auf das Speichern von Bildern, die dabei vorgestellten Technikenlassen sich aber auch für andere Dateitypen verwenden.

Abbildung 2.57: Einfügen eines Objekts



OLE-Felder = Einbahnstraße?

Einmal in ein OLE-Feld eingebettete Dateien lassen sich dort nicht ohne Weiteres wie-der herausholen. Es gibt zwar verschiedene Verfahren, aber der Aufwand ist relativhoch. Sie könnten das Objekt etwa per Doppelklick in der dafür vorgesehenen Anwen-dung öffnen und dann speichern, aber wenn Sie diesen Vorgang mehrere hundert odergar tausend Mal durchführen müssen, um beispielsweise Ihre Urlaubsbildersammlungauf CD zu brennen, werden Sie wünschen, die Dateien niemals in der Datenbankuntergebracht zu haben.

Außerdem kann es hier weitere Probleme geben: Dateien, die über die Objekt einfü-gen-Funktion von Access in ein Tabellenfeld eingefügt wurden, benötigen einen OLE-Server, um bearbeitet oder wieder in eine Datei umgewandelt werden zu können. Dasist die Anwendung, die auf dem aktuellen Windows-System für die jeweilige Dateien-dung zuständig ist. Wenn keine für diese Dateiendung passende Anwendung einge-tragen ist, wird die Datei als »Paket« in dem Feld gespeichert. In diesem Fall ist der»Objekt-Manager« von Windows der für das Paket zuständige OLE-Server und damitauch für die Wiederherstellung der Datei verantwortlich. Das ist der günstigere Fall,denn falls die Datei auf dem Ausgangssystem mit einem konkreten OLE-Server ver-knüpft ist, muss die entsprechende Anwendung auch auf anderen Rechnern vorhan-den sein, um die Datei öffnen oder speichern zu können.

Bilder lassen die Datenbank wachsen

Wenn es sich bei den zu speichernden Dateien um Bilder handelt, gibt es noch einenweiteren Nachteil: Bilddateien werden datenbankintern in einem speziellen bitmap-ähnlichen Format gespeichert, das wesentlich mehr Speicherplatz frisst als etwa dasgängige für Fotos verwendete Format .jpg. Die Datenbank und die darin enthaltenenBilder nehmen dann einen um ein Vielfaches größeren Platz auf der Festplatte ein alsdie Bilder im Ursprungsformat.

2.7.2 Dateien nicht in der Datenbank speichern

Je nachdem, ob Sie die gewünschten Dateien einfach nur in Formularen oder Berichtender Datenbank anzeigen möchten, können Sie sich mit sehr einfachen Mitteln behelfen.Speichern Sie die Dateien einfach gar nicht erst in der Datenbank, sondern belassen Siediese im Dateisystem. Statt der Datei speichern Sie lediglich den Pfad zu der gewünsch-ten Datei und verwenden die Pfadangabe, um eine Datei in einem entsprechendenSteuerelement zu öffnen.

Praktisch ist es dabei, wenn man die Dateien im Datenbankverzeichnis oder in einemdarunter liegenden Verzeichnis speichert. Auf diese Weise können Sie die Daten zusam-men weitergeben und gleichzeitig sicherstellen, dass die Datenbank die Dateien amgleichen Ort (relativ zum Datenbankverzeichnis) wie beim Anlegen der Datei findet.



Ab Access 2000 liefert die Funktion CurrentProject.Path den gewünschten Pfadzurück. Für Access 97 bietet die folgende Funktion einen guten Ersatz:

Public Function Datenbankpfad() Datenbankpfad = Left(CurrentDb.Name, Len(CurrentDb.Name) _ - Len(Dir(CurrentDb.Name)))End Function

Listing 2.4: Hilfsfunktion zum Ermitteln des Datenbankpfades

Wohin mit dem Dateipfad?

Wenn Sie nur den Dateipfad in der Datenbank speichern, stehen Sie vor der Frage, wieSie die enthaltenen Informationen aufteilen. Es gibt verschiedene Varianten:

� Sie speichern den kompletten Pfad inklusive Dateiname in einem Feld. Nachteil:Änderungen am Verzeichnis erfordern immer den Einsatz von Zeichenketten-Funktionen.

� Sie speichern Verzeichnis und Dateiname in zwei Feldern.

� Sie legen zwei eigene Tabellen für Verzeichnisse und Dateinamen an und verknüp-fen diese per 1:n-Beziehung. Vorteil: Änderungen an Verzeichnissen erfolgen aufeinen Schlag. Nachteil: Änderungen an einzelnen Verzeichnissen bereiten mehrAufwand.

Anzeigen externer Bilddateien im Formular

Da sich Bilddateien nicht nur für das Speichern in einer Datenbank, sondern besonderszur Anzeige in Formularen und Berichten eignen, beschäftigt sich das folgende Bei-spiel mit der Anzeige von extern gespeicherten Bilddateien.

Die Tabelle aus Abbildung 2.58 enthält neben dem Primärschlüsselfeld BildID nur einFeld für eine Bezeichnung des Bildes und eines für den Dateinamen.

In das Feld Dateiname tragen Sie entweder den kompletten Pfad ein oder Sie gehendavon aus, dass die Bilddateien irgendwo im gleichen Verzeichnis wie die Datenbankselbst liegen. Letzterer Ansatz scheint sinnvoller, da auf diese Weise Datenbank und

Abbildung 2.58: Tabelle zum Speichern von Bildverknüpfungen



Bilder leicht im Dateisystem verschoben oder weitergegeben werden können. Da dieerste Variante aber einfacher zu realisieren ist, erhält sie für folgendes Beispiel denVorzug.

Zum Anzeigen der Bilder verwenden Sie ein Formular mit der Tabelle tblBildverknuep-fungen als Datenherkunft. Das Formular soll alle Felder der Tabelle enthalten und –falls vorhanden – das angegebene Bild anzeigen. Dazu fügen Sie zusätzlich ein Bild-steuerelement hinzu.

Dabei müssen Sie direkt die anzuzeigende Datei angeben – wählen Sie dazu irgendeinDummybild aus (im Verzeichnis der Nordwind-Datenbank befinden sich üblicherweiseeinige). Anschließend lassen Sie dieses wieder verschwinden, indem Sie in der Ent-wurfsansicht des Formulars die Eigenschaft Bild des Bildsteuerelements leeren. StellenSie außerdem den Namen des Bildsteuerelements auf ctlBild ein (siehe Abbildung 2.59).

Nun müssen Sie noch dafür sorgen, dass das Bildsteuerelement die im Feld Dateinameangegebene Bilddatei anzeigt. Das Bildsteuerelement soll beim Anzeigen jedes Daten-satzes aktualisiert werden, daher ist die Ereigniseigenschaft Beim Anzeigen der richtigeOrt für die entsprechende Prozedur.

Aber nicht nur beim Wechseln des Datensatzes, sondern auch nach der Eingabe desDateinamens soll das Bild direkt angezeigt werden. Daher lagern Sie die Funktionalitätzum Aktualisieren des Bildsteuerelements in eine eigene Prozedur aus, die Sie vonmehreren Orten aus aufrufen können.

Abbildung 2.59: Formular mit ungebundenem Bildsteuerelement



Die Prozedur BildAktualisieren sorgt dafür, dass das Bildsteuerelement das aktuellunter Dateiname angegebene Bild anzeigt. Die Prozedur stellt sicher, dass das Bild-steuerelement leer ist, wenn kein Dateiname angegeben ist (das ist nicht selbstver-ständlich – wenn man den Datensatz wechselt, ohne den Inhalt des Bildsteuerelementszu leeren, zeigt es weiterhin das vorherige Bild an). Außerdem prüft die Prozedur, obeine Bilddatei mit dem angegebenen Namen vorhanden ist. Wenn die Datei nicht exis-tiert, leert die Prozedur nicht nur das Bildsteuerelement, sondern auch das Feld Datei-name.

Private Sub BildAktualisieren() Dim strDateiname As String Dim strPicture As String 'Prüfen, ob Dateiname vorhanden ist If Not IsNull(Me!Dateiname) Then strDateiname = Me!Dateiname 'Prüfen, ob das angegebene Bild existiert... If Not Dir(strDateiname) = "" Then '... und Bild festlegen strPicture = strDateiname Else '... oder Meldung ausgeben 'und Textfeld Dateiname leeren MsgBox "Das Bild ist nicht vorhanden." Me!Dateiname = "" End If End If Me!ctlBild.Picture = strPictureEnd Sub

Listing 2.5: Prozedur zum Aktualisieren des Bildsteuerelements

Der Aufruf dieser Prozedur erfolgt etwa beim Eintreten des Ereignisses Beim Anzeigendes Formulars oder Nach Aktualisierung des Textfeldes Dateiname:

Private Sub Dateiname_AfterUpdate() BildAktualisierenEnd Sub

Private Sub Form_Current() BildAktualisierenEnd Sub

Listing 2.6: Aufruf der Prozedur BildAktualisieren durch verschiedene Ereignisprozeduren



Das komplette Formular auf der Buch-CD enthält auch noch eine Schaltfläche, mit dersich ein Dialog zum Auswählen der Bilddatei anzeigen lässt (siehe Abbildung 2.60). Auchnach dem Auswählen der Datei ruft das Formular die Prozedur BildAktualisieren auf.

Anzeige externer Bilddateien in Berichten

In Berichten ist die Vorgehensweise etwas anders. Hier sorgt lediglich das EreignisBeim Drucken für das Füllen des Bildsteuerelements mit dem entsprechenden Bild(siehe Abbildung 2.61).

Die Ereignisprozedur hat folgendes Aussehen:

Private Sub Detailbereich_Print(Cancel As Integer, PrintCount As Integer) Dim strDateiname As String Dim strPicture As String 'Prüfen, ob Dateiname vorhanden ist If Not IsNull(Me!Dateiname) Then strDateiname = Me!Dateiname 'Prüfen, ob das angegebene Bild existiert... If Not Dir(strDateiname) = "" Then '... und Bild festlegen strPicture = strDateiname End If End If 'Bildname dem Bildsteuerelement zuweisen Me!ctlBild.Picture = strPictureEnd Sub

Listing 2.7: Ereignisprozedur zum Füllen des Bildsteuerelements eines Berichts

Abbildung 2.60: Das fertige Formular zur Anzeige verknüpfter Bilddateien



Wenn Bilder nicht angezeigt werden wollen …

Manche .jpg-Datei und Bilddatei anderer Formate kann Access nicht in dem dafür vor-gesehenen Bildsteuerelement anzeigen. In diesem Fall erscheint die Fehlermeldungaus Abbildung 2.62.

Das Problem liegt entweder tatsächlich in dem fehlenden Grafikfilter oder aber dasFormat der Datei stimmt nicht exakt mit dem erwarteten Format überein.

Im ersten Fall hilft das Nachinstallieren der benötigten Grafikfilter oder das Konvertie-ren der Bilder in ein anderes Format. Ersteres hilft allerdings nur auf dem lokalenRechner weiter und schließt Probleme beim Einsatz auf anderen Rechnern nicht ausund Letzteres dürfte bei größeren Bildmengen wenig Spaß machen.

Wenn das Bildsteuerelement allerdings manche .jpg-Dateien anzeigt, andere wie-derum nicht, spricht vieles für Probleme mit dem Format der widerspenstigen Bilder.

Abbildung 2.61: Verknüpfte Bilddateien im Bericht



Alternative zum Bildsteuerelement von Access

Abhilfe schafft das Image-Steuerelement der MSForms-Bibliothek, die bei jeder Access-Installation – auch bei Runtimes – mitinstalliert wird. Dieses Steuerelement fügen Sieüber den Dialog ActiveX-Steuerelement einfügen ein (siehe Abbildung 2.63).

Um in diesem Steuerelement ein Bildobjekt anzuzeigen, reicht ein Einzeiler, wobeistrPicture wiederum der Pfad zur Bilddatei ist:

Me!ctlBild.Picture = stdole.LoadPicture(strPicture)

Abbildung 2.62: Dieser Fehler tritt gelegentlich beim Anzeigen von .jpg-Dateien im Bildsteuerelement auf.

Abbildung 2.63: Einfügen eines Image-Steuerelements



2.7.3 Dateien als Binärstrom in der Datenbank speichern

Die Lösung, lediglich den Pfad zu einer Bilddatei zu speichern und diese bei Bedarfanzuzeigen, ist in vielen Fällen ausreichend – vor allem bei der Verwendung von Bild-dateien. Andererseits ist die Vorstellung, die komplette Bildersammlung in einerDatenbankdatei zu speichern oder diese als Dokumenten-Management-System zumissbrauchen, schon interessant.

In den folgenden Abschnitten lernen Sie einige Funktionen kennen, mit denen SieDateien in ein Feld einer Access-Datenbank importieren und die Datei wieder imDateisystem speichern können.

Importieren einer Datei in ein OLE-Feld einer Tabelle

Die Funktion DateiInTabelleSpeichern importiert eine Datei in ein OLE-Feld einerTabelle. Die Funktion erwartet folgende Parameter:

� strTabelle: Tabelle, die das OLE-Feld enthält

� strPrimaerschluessel: Name des Primärschlüsselfelds dieser Tabelle

� strZiel: OLE-Feld, in das die Datei importiert werden soll

� lngID: Wert des Primärschlüssels des Datensatzes, in den das Feld importiert wer-den soll

� strFeldDateiname (optional): Feld, in dem sich der Dateiname der zu importieren-den Datei befindet

� strDateiname (optional): Dateiname der zu importierenden Datei (alternativ zustrFeldDateiname)

� bolImDatenbankpfad (optional): Gibt an, ob dem Dateinamen aus strFeldDateinameoder strDateiname der aktuelle Datenbankpfad vorangestellt werden soll

Die Funktion wertet zunächst den Parameter strFeldDateiname aus. Enthält er einenWert, liest die Funktion den Speicherort der zu importierenden Datei aus dem angege-benen Feld der Tabelle ein.

Dazu füllt sie im nächsten Schritt ein Recordset-Objekt mit dem Datensatz mit dem Pri-märschlüsselwert lngID der Tabelle strTabelle. Dabei liest sie nur die in den in denParametern strZiel und strFeldDateiname angegebenen Feldern enthaltenen Werteein.

Ist der Parameter strFeldDateiname gefüllt, verwendet die Funktion den enthaltenenWert als Speicherort, sonst den Wert aus dem Parameter strSpeicherort.



In manchen Fällen liegen die zu importierenden Dateien im Datenbankverzeichnis.Trifft das zu, stellen Sie den Wert des Parameters bolImDatenbankpfad auf den WertTrue ein. Die Funktion fügt den aktuellen Datenbankpfad dann vorne an den vorhan-denen Speicherort an.

Nach einer Prüfung, ob die angegebene Datei vorhanden ist, ruft die Routine eine wei-tere Funktion namens DateiInFeld auf und übergibt das Recordset-Objekt und denNamen des Feldes, in das die Datei importiert werden soll, und den Dateinamen.

Public Function DateiInTabellenfeld(strTabelle As String, _ strPrimaerschluessel As String, strZielfeld As String, lngID As Long, _ Optional strFeldDateiname As String, _ Optional strDateiname As String, _ Optional bolImDatenbankpfad As Boolean) As Long Dim db As DAO.Database Dim rst As DAO.Recordset Dim strDateinameTemp As String On Error GoTo DateiInTabellenfeld_Err Set db = CurrentDb 'Ist der Speicherort in einem Feld der Tabelle gespeichert? If Not strFeldDateiname = "" Then strDateinameTemp = ", " & strFeldDateiname Else strDateinameTemp = "" End If 'Datensatzgruppe mit dem Zielfeld für die Datei öffnen Set rst = db.OpenRecordset("SELECT " & strZielfeld & strDateinameTemp _ & " FROM " & strTabelle _ & " WHERE " & strPrimaerschluessel & " = " & lngID, dbOpenDynaset) 'Speicherort aus der Tabelle auslesen, wenn Feld angegeben, 'sonst Speicherort aus dem Parameter strSpeicherort verwenden If Not strFeldDateiname = "" Then strDateiname = rst(strFeldDateiname) End If 'Falls relative Pfadangabe: Datenbankpfad voranstellen If bolImDatenbankpfad = True Then strDateiname = CurrentProject.Path & "\" & strDateiname End If 'Meldung, falls Datei nicht vorhanden ist If Dir(strDateiname) = "" Then



MsgBox "Die Datei '" & strDateiname & "' existiert nicht." Exit Function End If 'Bearbeitung des Datensatzes beginnen rst.Edit 'Funktion zum Füllen des Feldes aufrufen If DateiInFeld(strDateiname, strZielfeld, rst) = True Then DateiInTabellenfeld = True End If 'Recordset aktualisieren rst.Update DateiInTabellenfeld_Exit:

On Error Resume Next rst.Close Set rst = Nothing Set db = Nothing Exit Function DateiInTabellenfeld_Err: DateiInTabellenfeld = Err.Number Resume DateiInTabellenfeld_ExitEnd Function

Listing 2.8: Funktion zum Importieren einer Datei in ein OLE-Feld einer Tabelle

Die Funktion DateiInFeld öffnet die Datei für den binären Zugriff, ermittelt die Größeder Datei, dimensioniert eine temporäre Variable (Byte-Array) entsprechend groß undverwendet dann die Get-Anweisung, um die Datei in einem Rutsch in die temporäreVariable einzulesen. Dann kommt die AppendChunk-Methode zum Einsatz und schreibtden Inhalt der Variablen in das angegebene Feld des übergebenen Recordset-Objekts.

Public Function DateiInFeld(strDateiname As String, strZielfeld As String, _ rst As DAO.Recordset) Dim lngExportdateiID As Long Dim Buffer() As Byte Dim lngDateigroesse As Long On Error GoTo DateiInFeld_Err 'Dateinummer für die Dateioperationen festlegen lngExportdateiID = FreeFile 'Zu importierende Datei für den binären Zugriff öffnen



Open strDateiname For Binary Access Read Lock Read Write _ As lngExportdateiID 'Dateigröße ermitteln lngDateigroesse = LOF(lngExportdateiID) 'Größe der Variablen für den Dateiinhalt anpassen ReDim Buffer(lngDateigroesse) 'Zielfeld leeren rst(strZielfeld) = Null 'Inhalt der Datei in Variable "Buffer" schreiben Get lngExportdateiID, , Buffer 'Inhalt der Variablen in das Zielfeld schreiben rst(strZielfeld).AppendChunk Buffer

'Datei schließen DateiInFeld = True

DateiInFeld_Exit: Close lngExportdateiID Exit Function

DateiInFeld_Err: Resume DateiInFeld_Exit

End Function

Listing 2.9: Die Funktion DateiInFeld speichert eine Datei in das angegebene Feld-Objekt.

Beispiele für den Import einer Datei

Nachfolgend finden Sie einige Beispiele für das Importieren von Dateien in eineTabelle.

Im ersten Fall enthält die Tabelle keinen Dateinamen und ist wie in Abbildung 2.64aufgebaut. Eine .pdf-Datei soll in das Feld Datei importiert werden.

Abbildung 2.64: Zieltabelle des Datei-Imports



Der Aufruf sieht folgendermaßen aus und kann beispielsweise im Direktfenster abge-setzt werden:

Debug.Print DateiInTabellenfeld ("tblDateien", "DateiID", "Datei", 1, ,"c:\Kapitel_2.pdf")

Sofern die Datei vorhanden und nicht zum Bearbeiten geöffnet ist (sonst kann sie nichtfür den binären Zugriff geöffnet werden), liefert die Funktion den Wert -1 zurück unddie Tabelle sieht nun wie in Abbildung 2.65 aus – das Feld Datei ist gefüllt.

Ob dieses Feld nun wirklich die angegebene .pdf-Datei enthält, kann abschließend nurder Gegenversuch mit der Funktion TabellenfeldInDateiAusgeben klären – so weit istes allerdings noch nicht.

Im zweiten Beispiel ist der Dateiname bereits in der Tabelle gespeichert (siehe Abbil-dung 2.66). Daher lässt der folgende Aufruf den Parameter strDateiname aus und gibtden Namen des Feldes an, in dem der Dateiname gespeichert ist:

Debug.Print DateiInTabellenfeld ("tblDateien", "DateiID", "Datei", 1, ,"c:\Kapitel_2.pdf")

Fehlen noch zwei Varianten, denn die beiden vorherigen Beispiele lassen sich noch mitder Option bolImDatenbankpfad kombinieren. Wenn Sie für diesen Parameter den WertTrue übergeben, stellt die Funktion dem per strDateiname übergebenen oder dem imFeld strFeldDateiname enthaltenen Dateinamen noch den Pfad der aktuellen Daten-bank voran. Natürlich muss der Wert des Parameters strSpeicherort beziehungsweise

Abbildung 2.65: Datensatz einer Tabelle nach dem Importieren einer Datei

Abbildung 2.66: Dateidatensatz mit Dateiname



des Feldes strFeldDateiname dann eine relative Pfadangabe enthalten, also etwa»Kapitel_2.pdf« oder »Buch\Kapitel_2.pdf«.

Der Aufruf sieht dann beispielsweise folgendermaßen aus:

Debug.Print DateiInTabellenfeld("tblDateien", "DateiID", "Datei", 1, , "Kapitel_2.pdf", True)

Die Funktion setzt den Pfad der Datei dann in dieser Zeile aus dem aktuellen Daten-bankverzeichnis und dem angegebenen Dateinamen zusammen:

strDateiname = CurrentProject.Path & "\" & strDateiname

Die letzte Variante ist die Kombination eines in der Datenbank gespeicherten Datei-namens mit dem aktuellen Datenbankpfad.

Speichern einer Datei aus einem OLE-Feld im Dateisystem

Die Funktion TabellenfeldInDatei hilft nun zunächst dabei, die Funktionstüchtigkeitder Routine DateiInTabellenfeld zu beweisen. Darüber hinaus stellt sie natürlich die inder Datenbank gespeicherten Dateien wieder her.

Dabei weist diese Funktion genauso viel Flexibilität wie die obige Funktion auf, wassich in genau den gleichen Parametern widerspiegelt. Deren Zweck sieht allerdings einwenig anders aus: Die Parameter strTabelle, strPrimaerschluessel, strQuelle undlngID geben nun keine Informationen mehr über das Ziel, sondern die Herkunft derDatei und die Parameter strFeldDateiname, strDateiname und bolDatenbankpfad gebenan, wo die Datei gespeichert werden soll.

Dementsprechend ist auch die Funktion sehr ähnlich aufgebaut und tauscht imWesentlichen Quelle und Ziel der Datei gegeneinander aus. Für weitere Informationensei daher auf die Kommentare im Quelltext des folgenden Listings verwiesen.

Public Function TabellenfeldInDatei(strTabelle As String, _ strPrimaerschluessel As String, strQuellfeld As String, lngID As Long, _ Optional strFeldDateiname As String, _ Optional strDateiname As String, _ Optional bolImDatenbankpfad As Boolean) As Long Dim db As DAO.Database Dim rst As DAO.Recordset Dim strDateinameTemp As String On Error GoTo TabellenfeldInDatei_Err Set db = CurrentDb 'Prüfen, ob der Dateiname in einem Feld der Tabelle gespeichert ist



If Not strFeldDateiname = "" Then strDateinameTemp = ", " & strFeldDateiname Else strDateinameTemp = "" End If 'Datensatz mit der angegebenen ID öffnen Set rst = db.OpenRecordset("SELECT " & strQuellfeld & strDateinameTemp _ & " FROM " & strTabelle _ & " WHERE " & strPrimaerschluessel & " = " & lngID, dbOpenDynaset) 'Wenn Speicherort der Datei in der Tabelle gespeichert ist, 'wird dieser ausgelesen und ansonsten der im Parameter 'strFeldSpeicherort angegebene Speicherort verwendet If Not strFeldDateiname = "" Then strDateiname = rst(strFeldDateiname) End If 'Gegebenenfalls den aktuellen Datenbankpfad vor dem Dateinamen einfügen If bolImDatenbankpfad = True Then strDateiname = Datenbankpfad & strDateiname End If If FeldInDatei(strDateiname, strQuellfeld, rst) = True Then TabellenfeldInDatei = True End If

TabellenfeldInDatei_Exit: rst.Close Set rst = Nothing Set db = Nothing Exit Function

TabellenfeldInDatei_Err: TabellenfeldInDatei = Err.Number Resume TabellenfeldInDatei_Exit

End Function

Listing 2.10: Funktion zum Exportieren einer Datei aus einer Tabelle in das Dateisystem

Auch diese Routine ruft eine weitere Funktion auf. Diese heißt FeldInDatei und über-nimmt die Feinarbeit: Das Auslesen des Inhalts des OLE-Felds und das Schreiben indie angegebene Datei.

Public Function FeldInDatei(strDateiname As String, strQuellfeld As String, rst As DAO.Recordset) Dim lngExportdateiID As Long



Dim Buffer() As Byte Dim lngDateigroesse As Long On Error GoTo FeldInDatei_Err 'Dateinummer für den Zugriff auf die zu erzeugende Datei ermitteln lngExportdateiID = FreeFile 'Dateigröße ermitteln lngDateigroesse = Nz(LenB(rst(strQuellfeld)), 0) 'Wenn die Dateigröße größer 0 ist: If lngDateigroesse > 0 Then 'Größe der Variable "Buffer" anpassen ReDim Buffer(lngDateigroesse) 'Datei zum Schreiben öffnen Open strDateiname For Binary Access Write As lngExportdateiID 'Feldinhalt in die Variable "Buffer" schreiben Buffer = rst(strQuellfeld).GetChunk(0, lngDateigroesse) 'Inhalt der Variablen "Buffer" in die Datei schreiben Put lngExportdateiID, , Buffer End If FeldInDatei = True FeldInDatei_Exit: 'Datei schließen Close lngExportdateiID Exit Function

FeldInDatei_Err: Resume FeldInDatei_Exit

End Function

Listing 2.11: Die Funktion FeldInDatei speichert den Inhalt des angegebenen OLE-Felds in einer Datei.

Beispiele für das Speichern einer als OLE-Objekt vorliegenden Datei

Die nachfolgenden Beispiele setzen voraus, dass Sie bereits eine oder mehrere Dateienin einer Tabelle ähnlich der in Abbildung 2.67 gespeichert haben.

Die folgende Anweisung speichert die Datei im Datenbankverzeichnis unter demDateinamen, der im Feld Dateiname der Tabelle angegeben ist:

Debug.Print TabellenfeldInDatei("tblDateien", "DateiID", "Datei", 1,"Dateiname", , True)



Beachten Sie, dass die Prozedur vorhandene Dateien ohne Rückfrage überschreibt.

Die übrigen Varianten sehen ähnlich wie für die Funktion DateiInTabellenfeld aus.

Als Binärstrom gespeicherte Bilder verfügbar machen

In der Praxis sieht es so aus, dass Sie die Funktionen vermutlich von anderen Prozedu-ren aus aufrufen werden. Das folgende Beispiel nimmt sich nochmals die Bildverwal-tung vor die Brust. In diesem Fall geht es um eine Kombination der beiden vorherigenBeispiele zur Bildverwaltung – die Bilder sollen zwar in der Datenbank gespeichertwerden, aber nicht in dem Platz fressenden Bildformat von Access.

Natürlich sollen sie dennoch im Formular oder Bericht angezeigt werden können –was aber nicht direkt aus der Tabelle heraus funktioniert. Daher werden die Bild-dateien vor dem Anzeigen aus der Tabelle ins Dateisystem exportiert und erst dann imBildsteuerelement angezeigt.

Das Beispielformular frmBilderBinaer sieht wie in Abbildung 2.68 aus und hat dieTabelle aus Abbildung 2.67 als Datenherkunft. Die Textfelder sind an die Felder BildID,Bezeichnung und Dateiname gebunden. Das Bildsteuerelement ist ungebunden.

Abbildung 2.67: Tabelle mit einer im OLE-Feld gespeicherten Datei

Abbildung 2.68: Formular zur Anzeige von temporär gespeicherten Abbildungen



Hinter der Schaltfläche mit der Beschriftung Neues Bild verbirgt sich die folgendeEreignisprozedur:

Private Sub cmdNeuesBild_Click() Dim strDateiname As String Dim rst As DAO.Recordset 'Dateiname der zu importierenden Datei ermitteln strDateiname = DateiAuswaehlen Me!Dateiname = strDateiname 'Datensatz zwischenspeichern DoCmd.RunCommand acCmdSaveRecord 'Kopie der Datensatzgruppe anlegen... Set rst = Me.RecordsetClone '...und auf den aktuellen Datensatz einstellen rst.Bookmark = Me.Bookmark 'Datensatz zur Bearbeitung vorbereiten rst.Edit 'Funktion zum Importieren der angegebenen Bilddatei aufrufen If DateiInFeld(strDateiname, "Bild", Me.RecordsetClone) = -1 Then 'Datensatz speichern rst.Update 'Aktuelles Bild anzeigen BildAktualisieren Else MsgBox "Beim Import der Bilddatei ist ein Fehler aufgetreten." End If End Sub

Listing 2.12: Prozedur zum Laden einer neuen Abbildung in das Bildsteuerelement

Die Prozedur ermittelt zunächst über die Funktion DateiAuswaehlen den Pfad dergewünschten Bilddatei. Diese Funktion verwendet das FileDialog-Objekt, das seitOffice XP Bestandteil der Office-Objektbibliothek ist, zur Auswahl der Bilddatei:

Private Function DateiAuswaehlen() As String

Dim objFiledialog As Office.FileDialog Dim strDateiname As String Dim strDatenbankpfad As String



'Pfad der aktuellen Datenbank ermitteln strDatenbankpfad = CurrentProject.Path 'Filedialog-Objekt festlegen Set objFiledialog = FileDialog(msoFileDialogOpen) With objFiledialog 'Auswahl auf ein Element beschränken .AllowMultiSelect = False 'Thumbnail-Ansicht aktivieren .InitialView = msoFileDialogViewThumbnail 'Aktueller Datenbankpfad als Standardpfad .InitialFileName = strDatenbankpfad 'Titel festlegen .Title = "Bild auswählen" 'Filter hinzufügen .Filters.Add "Alle Bilddateien", "*.*", 1 .Filters.Add "Windows Bitmap", "*.bmp", 2 .Filters.Add "JPEG", "*.jpg; *.jpeg", 3 .Filters.Add "TIFF", "*.tif; *.tiff", 4 .Filters.Add "GIF", "*.gif", 5 'Wenn Auswahl getroffen, erstes und einziges Element ermitteln If .Show = -1 Then strDateiname = .SelectedItems(1) End If End With

DateiAuswaehlen = strDateiname Set objFiledialog = Nothing End Function

Listing 2.13: Auswählen der Bilddatei mit dem FileDialog-Objekt

Es gibt allerdings noch eine wesentlich kürzere Variante, um einen Dialog zur Aus-wahl einer Datei zu öffnen. Dazu verwenden Sie ein nicht dokumentiertes Objektnamens WizHook (ab Access 2000). Wie bei nicht dokumentierten Funktionen üblich,besteht keine Garantie, dass es diese in den nächsten Versionen von Access noch gibt,daher erfolgt der Einsatz auf eigene Gefahr:

Private Function DateiAuswaehlen() As String

Dim strDateiname As String

WizHook.Key = 51488399



Call WizHook.OpenPictureFile(strDateiname, False) DateiAuswaehlen = strDateiname

End Function

Listing 2.14: File-Dialog in aller Kürze dank versteckter Funktion

Nach der Auswahl der Quelldatei schreibt die Funktion cmdNeuesBild_Click derenNamen in das Feld Dateiname und speichert den aktuellen Datensatz zwischen, dasonst beim folgenden Schreibzugriff ein Konflikt auftritt. Die Funktion erzeugt einRecordset-Objekt aus dem RecordsetClone des Formulars, stellt dessen aktuellenDatensatz auf den aktuellen Datensatz des Formulars ein und aktiviert den Bearbei-tungsmodus für das Recordset-Objekt. Dann übergibt sie das Recordset-Objekt sowieden Dateinamen und den Namen des Zielfelds an die weiter oben vorgestellte RoutineDateiInFeld, die für den Import der Datei in das angegebene Feld zuständig ist. Fehltnur noch das Speichern des Datensatzes und das Anzeigen des Bildes – das wiederumerledigt die Funktion BildAktualisieren.

Die Funktion speichert die Bilddatei als temporäre Datei im gleichen Verzeichnis wiedie Datenbank und zeigt diese im Bildsteuerelement an:

Private Sub BildAktualisieren() Dim strDateiname As String Dim strDateiendung As String 'Wenn das Feld Bild Daten enthält... If Not IsNull(Me!Bild) Then '...falls ja: 'Dateiname ermitteln strDateiname = Me.Dateiname 'Dateiendung ermitteln strDateiendung = Mid(strDateiname, InStrRev(strDateiname, ".") + 1) 'Feld in eine temporäre Datei mit der passenden Endung speichern FeldInDatei "pic." & strDateiendung, "Bild", Me.Recordset 'Bildsteuerelement mit der temporären Bilddatei füllen Me!ctlBild.Picture = Datenbankpfad & "pic." & strDateiendung Else '... wenn kein Bild gespeichert ist, Bildsteuerelement leeren Me!ctlBild.Picture = ""



End If

End Sub

Listing 2.15: Die Prozedur BildAktualisieren füllt das Bildsteuerelement mit einer zuvor temporär gespeicherten Bilddatei.

Mit der folgenden kleinen Prozedur, die beim Entladen des Formulars ausgelöst wird,sorgen Sie für die Beseitigung der Rückstände – sprich der temporären Bilddateien aufder Festplatte:

Private Sub Form_Unload(Cancel As Integer) Kill CurrentProject.Path & "\pic.*"End Sub

Listing 2.16: Entfernen temporärer Bilder von der Festplatte

Weitere Einsatzmöglichkeiten

Aus den hier vorgestellten Funktionen zum Speichern von Dateien in der Datenbankund zum Extrahieren von in der Datenbank gespeicherten Dateien lassen sich weitereAnwendungen ableiten:

� Verwenden einer Access-Datenbank für die Verwaltung von Dokumenten, MP3-Dateien, Bildern etc.

� Bereitstellen von Symbolbildern für Schaltflächen oder Symbolleisten der Daten-bank (siehe auch Kapitel 10, »Menüleisten«)

� Integration von setup-ähnlichen Funktionen, etwa um für das Benutzen einerAnwendung notwendige Tools oder .dlls automatisch bereitzustellen. Auf dieseWeise ließe sich auch leicht ein Anwendungssymbol mit einer Datenbank mitlie-fern, ohne mehr als die reine .mdb-Datei zu übergeben.

Wenn Sie binär gespeicherte Bilder in einem Bericht anzeigen möchten, gehen Siegenauso wie in Kapitel 2.7.2, »Dateien nicht in der Datenbank speichern«, Abschnitt»Anzeige externer Bilddateien in Berichten«, vor. Sie müssen lediglich, wie soebenbeschrieben, die Bilddatei vor der Anzeige aus der Datenherkunft auf die Festplattekopieren.


2 Tabellen und Datenmodellierung - access … · 2 Tabellen und Datenmodellierung Dieses Kapitel...

Documents

Transcript of 2 Tabellen und Datenmodellierung - access … · 2 Tabellen und Datenmodellierung Dieses Kapitel...