Access Design:Datenmodell

Aus DBWiki
Wechseln zu: Navigation, Suche

Gedanken beim Anlegen neuer Datenbanken, Tabellen und Felder

Papier, Bleistift, Radiergummi

Beginnen Sie Ihr Konzept nicht sofort in Access, sondern planen Sie auf Papier (oder in Spezialprogrammen für diesen Zweck). Grund: im Verlauf des Aufbaus werden Sie oft im Nachhinein Dinge hinzufügen oder ändern müssen!

Entitäten („Dinge“) und deren Eigenschaften erkennen

Gerade wenn Ihnen die abzubildenden Sachverhalte aus der täglichen Arbeit vertraut sind, sitzen Sie doch oft zu dicht vor den Fakten, um taugliche Tabellen- und Feldstrukturen sofort zu erkennen. Ein Entität-Beziehung-Modell (ER-Modell) kann Ihnen helfen, Abstand zu gewinnen und das ganze Bild Ihrer Datenbank zu erkennen. Näheres dazu in Wikipedia unter ER-Modell.
ER-Diagramm
Darin sind

  • Rechtecke = Entitäten = „Dinge“ aus Ihrem Sachverhalt; das werden später Tabellen.
  • Ovale = Attribute = Eigenschaften der Entitäten: was für Werte fallen für einen Angestellten, ein Projekt oder ein Buch an? Das werden später Felder (Spalten) der Tabellen.
  • Rauten = Relationen = Verben, die das Zusammenspiel der Entitäten verdeutlichen. Das werden später Beziehungen oder (im Falle von m:n-Beziehungen oder bei zusätzlichen Detailangaben) weitere Tabellen. Die Symbole an den Linien, die an den Rauten anschließen, sind ein erster Hinweis auf die 1- bzw. n-Seiten der entstehenden Beziehungen. Rauten zwischen Sternen

(*-*) deuten m:n-Beziehungen an und müssen durch Zwischentabellen aufgelöst werden.

Beginnen Sie Ihre Datenbank mit einem großen Blatt Papier, auf dem Sie ein solches ER-Diagramm zeichnen, oder nutzen Sie ein spezielles Zeichenprogramm. Lassen Sie Platz, damit Sie unvorhergesehene Teile noch einfügen können – so ein Diagramm wächst bis zur Reife.

Häufige Denkfehler und Fallen im Datenmodell

Durchnumerierte Felder (Mehrfachfelder)

Durchnumerierte Feldnamen wie „Artikel1, Artikel2, Artikel3“ oder „Sprache1, Sprache2“ sind Anzeichen dafür, dass eine Detailtabelle fehlt. Das, was Sie da durchnumerieren, ist die n-Seite einer noch unerkannten Beziehung, und die Tabelle, in der diese Felder bisher vorkommen, ist die 1-Seite dieser Beziehung. Versuchen Sie, die durchnumerierten Felder in Datensätze einer neuen Tabelle zu wandeln: Artikel1, Artikel2 und Artikel3 sind dann Sätze in der neuen Tabelle Sortiment (wer hat was); „Sprache1, Sprache2, Sprache3“ sind Sätze in der neuen Tabelle MitarbeiterSprachkenntnisse (wer spricht was).

Vorratswerte als Feldnamen / „Excel-Denke“ / Matrix-Ansatz

Sie sollten misstrauisch werden, wenn Ihre Feldnamen Einzelwerte einer übergeordneten Vorratsmenge sind. Die Felder „Deutsch, Englisch, Französisch“ etwa sind Elemente eines Vorrats, nämlich der Sprachen. Dieser Tipp ähnelt dem ersten Tipp, nur dass hier die Feldnamen nicht durch eine interne Numerierung auffällig werden, sondern durch ihre Zugehörigkeit zum gleichen Oberbegriff. Ein anderes Indiz: Eine neue Sprache macht ein neues Feld nötig; das sollte in einer guten Datenbank nicht nötig sein, denn das ist Techniker-Arbeit, gleichsam ein Werkstattaufenthalt. Ein „Mehr desselben“, also eine neue Sprache, darf nur zu neuen Zeilen, nicht zu neuen Spalten führen. Eine solche Struktur entsteht besonders gerne, wenn Sie Ihre Daten bisher in Excel geführt und dabei folgenden Aufbau genutzt haben – die typische „Excel-Denke“ in Matrixform:
Excel_Matrix
In Access ist so ein Feldaufbau tödlich! In Access verdient jedes „X“ eine Zeile in der Tabelle „Sprachkenntnisse“, die zwischen den Tabellen Sprachen und Mitarbeiter steht (m:n-Auflösung).

Häufig wiederholte Eingaben / Eingaben mit begrenzten Möglichkeiten

Sie sollten stutzig werden, wenn Sie bemerken, dass Sie oft Informationen eingeben, die sich wiederholen oder die nur mit bestimmten Werten gefüllt werden sollen. Wenn Sie bei 50 Artikeln im Feld Kategorie den Textwert „Gewürz“ eingeben, werden Sie sich irgendwann vertippen – da steht dann „Gwürz“ oder „Gewüz“. Wenn Sie später nach „Gewürz“ suchen, werden diese Tippfehler dann natürlich nicht gefunden… Erkennen Sie, dass „Gewürz“ ein Wert aus einem Wertevorrat ist – dem Vorrat der Kategorien? Diesen Kategorievorrat können Sie zwar jederzeit ergänzen oder ändern, aber „es gibt immer nur bestimmte Kategorien zur Auswahl, nämlich die in der Tabelle Kategorien“, so dass Tippfehler dann keine Chance mehr haben. Kein Wertevorrat hingegen sind Werte, bei denen Wiederholungen nur zufällig sind: wenn Sie 50 Kunden namens Meier haben, haben diese Leute nichts gemeinsam außer dem Nachnamen – der Nachname ist Zufall, kein Wertevorrat! Ebenso sind z.B. Preise oder Geburtsdaten „echte“ Fakten ohne Vorrat, selbst wenn viele Preise gleichartig sein sollten und sich Geburtsdaten an manchen Tagen häufen mögen.

Vermeidung umfangreicher Tabellen („wer soll das alles eingeben?“)

Viele Anwender scheuen den Einsatz von Tabellen, die zwar eigentlich nötig wären, aber viele Datensätze umfassen würden - „wer soll das alles eingeben?“. Natürlich gibt niemand gern Tausende von Zeilen manuell ein. Das ist aber oft auch gar nicht nötig! Ein wenig Programmierung kann dafür sorgen, dass Sätze, die schematisch aufgebaut sind, auf Knopfdruck von Access erzeugt werden können. Solch ein Generator kann Ihnen z.B. eine Kalendertabelle mit den Tagen eines Jahres füllen, ohne dass Sie auch nur eine Tageszeile selbst tippen müssen. Sie geben lediglich die Parameter vor, hier z.B. das zu erzeugende Jahr, und der Generator legt für Sie die 365/366 Tagessätze an – schnell, fehlerfrei und bequem! Solch ein Generator wird Ihnen in Hilfeforen oft kostenlos und binnen kurzer Zeit erstellt, wenn Ihre Kenntnisse da noch nicht ausreichen. Lange Tabellen sollten Sie also nicht schrecken – ggf. lassen Sie Access tippen!

Untauglicher Einsatz von Primärschlüsseln

Ein Primärschlüssel ist ein datenbanktechnisches Erfordernis. Er sollte nicht missbraucht werden, um fachliche Geschäftsregeln durchzusetzen. Sollen z.B. im Feld „Urkundennummer“ Duplikate ausgeschlossen sein, muss dieses Feld dennoch nicht der Primärschlüssel sein; Sie können es auch durch einen sog. eindeutigen Index überwachen lassen. Ein Primärschlüssel sollte aus nur einem Feld bestehen, das kurze Werte enthält, numerisch ist und möglichst keine inhaltliche Bedeutung (=keinen Realitätsbezug) hat – idealerweise also ein Autowert. Ihr Primärschlüssel sollte zudem mögllichst ein Feld sein, an dessen Werten sich aller Voraussicht nach niemals (!) Änderungen ergeben werden. Bei einem Autowert ist das implizit so, denn er lässt keine Eingaben zu, so dass Autowerte immer einen guten Primärschlüssel abgeben. Als Primärschlüssel kann aber auch ein anderes Feld dienen, sofern es über Zeit stabil sind, z.B. das Datum in einer Kalendertabelle: der 05.01.2012 wird voraussichtlich nie zum 23.02.2012 werden..."

Speichern von berechneten oder abgeleiteten Informationen

Speichern Sie keine Summen, Anzahlen, Altersangaben und ähnliche berechnete Werte. Alles, was sich berechnen oder ableiten lässt, sollten Sie bei Bedarf durch Berechnungen in Abfragen oder (ab Access 2010) in einem berechneten Feld der Tabelle ermitteln lassen. Hier droht sonst Inkonsistenz. Beispiel Alter: Mitglied Meier ist laut Geburtsdatum heute 50 Jahre alt, aber im Feld Alter steht noch 48 – wurden da zwei Geburtstage verschlafen? Wie alt ist Meier denn nun?! Auch Felder wie Lagerbestand oder Kundenumsatz sind keine festen Größen, sondern Berechnungen, die sich laufend ändern können! Schaffen Sie keine Fakten, die keine sind!

„Nummernkreise“ und sprechende Felder

Hüten Sie sich vor Werten, die „sprechen“, d.h. denen Sie etwas ansehen können, so etwa:

  • „Wenn die erste Stelle der Kontonummer eine 1 ist, ist es ein Girokonto“
  • „Gerade Nummern stehen für Männer, ungerade für Frauen“
  • „Tennisergebnisse haben Kennziffer 100-199, Fußballergebnisse 200-299“
  • „Wenn die ersten 3 Stellen 103 sind, ist es ein Nahrungsmittel (1), ohne Kühlung (0), Gemüse (3). 501 wäre hingegen Kleidung (5), Herren (0), Jeans (1).“

Was immer Sie aus diesen Werten herauslesen: es gehört in eigene Felder; Kontoart, Geschlecht/Anrede, Sportart, Warengruppe. Und für all diese Werte gibt es dann auch einen Vorrat, auf den sie sich beziehen sollten. Nummernkreise und sprechende Schlüssel neigen zum „Überlaufen“ und zur Bildung von Artefakten: Sie haben im 1. Beispiel nur 10 Möglichkeiten für die Kontoart (0-9) – was passiert, wenn das nicht mehr ausreicht? Sie haben im 2. Beispiel nur die Anreden Herr (gerade) und Frau (ungerade) – wie bringen Sie da eine Firma unter?

Laufende Nummern

Oft werden laufende Nummern verlangt, d.h. Nummern, die immer um +1 hochgezählt werden, wenn z.B. ein neuer Beleg erfasst wird. Dies soll Lückenlosigkeit und damit eine Vollständigkeitskontrolle erlauben, analog zum vorgedruckten Nummernblock, von dem z.B. Gewinnlose oder numerierte Urkunden abgelöst werden. Ein solcher Fortlauf ist aber auch beim Papier-Nummernblock schon nur innerhalb eines Blocks durchzuhalten! Die Existenz eines zweiten Blocks, z.B. für einen Kollegen oder eine andere Filiale, kann den Fortlauf also auch in der Papierwelt schon zerstören oder Unvollständigkeit vertuschen. In der Datenbankwelt, wo eine Tabelle einem solchen Nummernblock entspräche, kann ein Fortlauf ebenfalls durch Mehrbenutzerbetrieb und andere Vorfälle durchbrochen werden und zöge dann umfangreiche Neunumerierungen der verbliebenen Sätze nach sich! Selbst das Finanzamt legt bei Belegen keinen Wert mehr auf Fortlauf, sondern nur noch auf Eindeutigkeit – das ist etwas anderes und viel leichter durchzuhalten. Auch ein Autowertfeld sichert keinen Fortlauf, da es durch Löschungen oder einen gewillkürten Startwert Lücken aufweisen kann. Kurz: Fortlauf ist ein Relikt aus der Daten-Steinzeit – bürokratisch, nutzlos, instabil. Unbedingt meiden! (Hinweis: Laufende Nummern im Sinne von Zeilennummern auf Rechnungen o.ä. sind ok, da sie nicht gespeichert werden, sondern lediglich eine Zählhilfe auf dem Ausdruck geben).

Trennung gleicher Informationen in mehrere Tabellen („Umsatz_2010, Umsatz_2011“)

Gleichartige Daten sollten in der gleichen Tabelle landen. Meiden Sie das künstliche Aufspalten von Tabellen in Teile, z.B. in Jahrestabellen („Umsatz 2010“ mit den Umsätzen aus 2010, „Umsatz 2011“ mit denen aus 2011 etc). Umsätze sind Umsätze, und anhand des Umsatzdatums lassen sie sich leicht gliedern! So werden auch jahresübergreifende Auswertungen möglich, was bei Jahrestabellen nicht so leicht ist. Das Merkmal, das Ihre Tabellen im Namen unterscheidet, sollte besser ein Feld der Tabelle werden: statt „Umsatz_JJJJ“ lieber nur eine Umsatztabelle mit Umsatzdatum, und statt den Paralleltabellen „Inaktive Kunden/Aktive Kunden“ ein J/N-Feld „Kunde inaktiv“ in der Kundentabelle.

Mangelnde Kenntnis des realen Sachverhalts

Eine Datenbank soll einen Teil der realen Welt datentechnisch abbilden. Dazu ist erforderlich, dass Sie die für Ihren Sachverhalt die reale Welt kennen. Das klingt zwar selbstverständlich, aber oft wird dabei unzulässig vereinfacht. Gerade im Finanz- und Geschäftsleben gibt es „unmögliche“ und außergewöhnliche Dinge: halbe Kinder(-freibeträge), mehrere MwSt-Sätze je Artikel (je nach Art oder Land des Abnehmers), negative Zinssätze und Mengen (Stornos!), vielleicht auch Fremdwährungen etc. Denken Sie auch über „selbstverständliche“ Annahmen lieber zweimal nach.

History-Bedarf und interne Dokumentationspflichten

Genügt es Ihnen, wenn die Datenbank nur den Datenstand von heute umfasst, oder wollen Sie auch wissen, wie die Lage gestern war – also bevor Sie die Preise verändert, das Sortiment bereinigt und den Umzug von Kunde Meier erfasst haben?

  • Wenn Sie einen Wert verändern oder löschen, ist der vorige Zustand verloren. Wenn der alte Wert für Recherche/Dokumentation erhalten bleiben soll, brauchen Sie eine Historisierung, d.h. neue Tabellen, die den Altzustand aufnehmen oder herleiten.
  • Eine Referenz ist „zeitlos“. Wenn Sie z.B. in den Nordwind-Bestelldetails auf eine Artikelnummer verweisen, zeigt dieser Verweis immer auf den Artikel, wie er heute aussieht. Ist die Bestellung aber Jahre alt, kann der Artikel damals z.B. einen anderen Preis gehabt haben. Sie sollten den „Preis am Umsatztag“ also speichern, damit Sie diese historische Information nicht verlieren. Der Preis „heute“ ist für einen Umsatz „gestern“ ohne Belang! Wehe, wenn Sie annehmen, der damalige Preis stünde beim Artikel: der aktuelle durchaus, aber der historische nicht! Ebenso wehe, wenn Sie die Bedeutung einer Artikelnummer ändern: wenn Artikel 14 damals eine Tube Senf war und bestellt wurde, sollten Sie Artikel 14 auch später nicht zum Würstchen umtaufen, denn der damalige Senf bleibt Senf… Die Vergangenheit ist nicht zu ändern!

Auswirkungen von externen Vorschriften

Zur Wirklichkeit, die eine Datenbank abbilden soll, gehören auch externe Vorschriften, die einzuhalten sind. So verbieten z.B. die Grundsätze ordnungsgemäßer Buchungssysteme (GoBS) ein Überschreiben und Löschen vorhandener Werte in Buchungen und fordern stattdessen Storno/Neu-Mechanismen. Manche Regelung verlangt ein 4-Augen-Prinzip, so dass Sätze nur nach Freigabe durch einen Kollegen wirksam werden können, oder ein Protokoll aller Änderungen. Ihre Datenbank sollte diese Vorgaben berücksichtigen.

Ansatz der aktuellen Lage für die Zukunft

Wenn Sie eine Datenbank aufbauen, bilden Sie den heutigen Stand Ihrer Wirklichkeit ab. Das bedeutet auch, dass z.B. heutige Gesetze, Vorschriften, Abläufe und Gewohnheiten einfließen. Die können sich in Zukunft ändern. Das kann zwar niemand voraussehen, aber Sie sollten niemals annehmen, dass der Status Quo ewig gilt:

  • Viele Datenbanken aus D-Mark-Zeiten hatten Schwierigkeiten, als der Euro kam und zeitweise parallel zur D-Mark umlief. Ein Währungsfeld hätte das vermieden und wäre in Mehrwährungssystemen ohnehin schon immer nötig gewesen: hat nicht jeder Umsatz eine Währung (die sicher oft gleich ist, aber eben wechseln kann)?
  • Das alte Lastschriftverfahren, seit Jahrzehnten vertraut, stirbt voraussichtlich 2014 den SEPA-Tod – BLZ und Kontonummer haben dann ausgedient, dafür kommen neue Felder in Sicht: IBAN, BIC, Mandatskennung.
  • Glauben Sie, dass die Mehrwertsteuersätze dauerhaft so bleiben wie bisher? Nein? Dann ist vielleicht der konstante Ansatz von „festen“ 19% ein vermeidbarer Fehler…
  • Vor ein paar Jahren waren Mobilfunk und E-Mail noch exklusiv, heute sind sie Alltag. Dafür sind Telex und Fax fast schon vergessen. Alles fließt!

Eine Datenbank lässt sich zwar immer weiterentwickeln, aber man sollte mögliche Baustellen immer schon im Auge haben – soweit Sie sehen können.

Normalformen

Die Normalformen sind ein paar kurze Regeln, die Sie als „Abnahmetest“ beim Aufbau Ihrer Tabellen anwenden können. Alle Ihre Tabellen sollten die ersten 3 Normalformen erfüllen, sonst ist etwas faul.

  • 1.Normalform: Primärschlüssel setzen; nur atomare Daten; feste Tabellenbreite!

Fügen Sie einen Primärschlüssel ein, am besten einen Autowert. Zerlegen Sie die Daten so weit, wie es sinnvoll ist. Ein Adressfeld lässt sich z.B. in die Felder Straße, PLZ, Ort und ggf. Hausnummer, Land und Region zerlegen. Achten Sie auch darauf, dass Ihre Sätze atomar sind: ein Kundensatz „Eheleute Hilde und Jürgen Boskopp“ ist in zwei Sätze aufzuteilen, denn beim Vornamen und beim Geburtsdatum erhalten Sie sonst Mehrfachwerte oder Artefakte. Achten Sie auf Felder, die die Tabellenbreite beeinflussen, so z.B. „durchnumerierte“ Felder („Kind1, Kind2“) oder Feldnamen, die aus Werten bestehen („rot, gelb, grün“ oder „deutsch, englisch, französisch, spanisch“).

  • 2. Normalform: Alle Felder, die nicht den Primärschlüssel bilden, hängen von diesem ab

Diese Regel ist automatisch erfüllt, wenn Ihre Tabelle einen Ein-Feld-Primärschlüssel hat. Dazu habe ich Sie ja erzogen . Wenn Ihre Tabelle aber einen zusammengesetzten Primärschlüssel hat, dürfen die Felder, die nicht zum Primärschlüssel gehören, nur vom ganzen Primärschlüssel abhängen, nicht schon von einem Teil des Primärschlüssels.

  • 3. Normalform: Die Nicht-Primärschlüsselfelder dürfen beliebig kombiniert werden

Es darf keine Regeln geben, wonach die Nicht-Primärschlüsselfelder einander beeinflussen. Sobald ein Feld, das am Primärschlüssel nicht beteiligt ist, ein anderes Feld beeinflusst, das ebenfalls am Primärschlüssel nicht beteiligt ist, ist diese Regel verletzt.

  • Merkspruch zu Normalform 1-3:

„Der Schlüssel, der ganze Schlüssel, und nichts als der Schlüssel – so wahr mir Codd helfe.“ (Edgar Frank Codd, 1923-2003, hat die theoretischen Grundlagen zu Datenbanken erforscht.)

Wenn Sie unsicher sind, fragen Sie einen Fachmann (in Internetforen, in IT-Unternehmen, ...), bevor Sie Ihre Datenbank in Betrieb nehmen! Datenrettung aus missratenen Datenbanken ist mehr Arbeit, als ein gutes Design vorab erfordert!