WinFuture-Forum.de: Datenbankentwurf - Wie angehen? - WinFuture-Forum.de

Zum Inhalt wechseln

Hinweis

Alle neuen Themen werden vor der Veröffentlichung durch einen Moderator geprüft und sind deshalb nicht sofort sichtbar.
Seite 1 von 1

Datenbankentwurf - Wie angehen?

#1 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 7.718
  • Beigetreten: 20. Juli 07
  • Reputation: 851

geschrieben 18. Mai 2015 - 18:31

Dies soll nur ein kleiner Umriß sein, wie man eine Datenbank erstellen *kann* (aber nicht muß). Abgesehen von grundlegenden Strukturen ist der Datenbankentwurf auch immer ein kleines bißchen Kunst.

Tatsache ist aber: Eine Datenbank lebt von ihrer Integrität. Ist diese verloren, kann man sie genausogut wegwerfen. Redundanz hat in einer Datenbank nichts zu suchen, denn wo Redundanz herrscht, schleichen sich Inkonsistenzen ein und wo Inkonsistenzen sind, kann man der bereitgestellten Information nicht vertrauen.

Ein jeder Datenbankentwurf muß daher dafür sorgen, daß solche Redundanzen vermieden werden und sich auch nicht einschleichen können - und gleichzeitig darauf achten, daß nicht jede "scheinbare" Redundanz auch wirklich eine Redundanz ist.

Versuchen wir uns wieder an einem Beispiel. Wir haben eine Excel-Tabelle, oder einfach nur eine Textdatei, mit Adressdaten:

1|Dominic Mustermann, Musterstraße 1, 12345 Musterstadt.
2|Dominique Mustermann, Musterstr 1, 12345 Musterstadt.
3|Dominique Mustermann, Musterstraße 1, 23456 Musterstadt.
4|Dominique Mustermann, Musterstrasse 01, D-12345 Musterstatt.
5|Hans Wurst, Emmentaler Ring 21b, 23456 Kuhnest.




Schritt 1: Analyse der Datensätze

Wir sehen, daß unsere Adressdaten aus "Vorname Name", "Straße Hausnummer", "PLZ Ort" zusammengesetzt sind.
Wir sehen aber auch, daß diese Adressdaten nicht unbedingt zuverlässig sind: Ist (1) und (2) dieselbe Person? (4) ist zumindest für uns Menschen offensichtlich ein Duplikat von mindestens (2) und (3) müssen wir zumindest nochmal nachprüfen, ob das eine eigenständige Person ist oder ob sich einfach nur bei der PLZ vertan wurde.
- Nach eingehender Prüfung stellen wir fest: Dominic(1) ist mit Dominique(2) verheiratet - die fanden das wohl lustig. (3) ist wirklich eine andere Musterstadt und da dort ebenfalls eine Person namens Dominique Mustermann in der dortigen Musterstraße wohnt, läßt sich recht leicht prüfen, ob diese Person auch gemeint war oder nicht. (Sie war.) (4) kann als Kopie von (2) eliminiert werden und (5) ist mehr oder weniger eindeutig.

Schritt 2: Planung der Strukturen - dem "Relational" in "relationale Datenbank"

Schauen wir uns die Datensätze ein bißchen genauer an: Was soll uns ein einzelner Satz eigentlich mitteilen?
Eine Antwort wäre: jeder Datensatz, so wie er da oben steht, ist eine Zuordnung einer PERSON zu seiner WOHNUNG, dargestellt durch deren ADRESSE.

Nun ist das aber keine eineindeutige Zuordnung. Es läßt sich sicherlich von "Person" auf "Adresse" schließen, aber wir wissen nicht wie (Eine Person an Adresse X? Mehrere?), und die Umkehrung fällt noch schwerer.

Also: Was kommt wohin?

Schritt 3: Zuordnung der Daten

Ein jeder Datensatz läßt sich am besten als "Objekt" ("Entität") veranschaulichen, wobei jede dieser Entitäten eine Identität bekommt. So ist beispielsweise ein Personalausweis eine Identität für den Durchschnittsdeutschen: er beschreibt *eindeutig* die ihm zugeordnete Person.

Wir müssen also für unsere Adressen und auch für unsere Personen eine solche Identität suchen, die jeweils der *eindeutigen* Beschreibung gilt.

== Personen. Da wir außer den Namen keine weiteren Informationen aus den ursprünglichen Datensätzen herauslesen können, müssen wir ganz streng genommen "extern" sicherstellen, daß jeder Dominic und jede Dominique ihre eigene Person ist (Stichwort Redundanz). Es ist auch offensichtlich, daß die vorhandenen Informationen für eine eindeutige Identifizierbarkeit *nicht* ausreichen (es gibt ja mehrere Personen namens "Dominique Mustermann"). Daher erhalten wir drei Tabellenspalten:

** Person_ID, eine willkürlich vergebene Identifikationsmöglichkeit für jede Person. Normalerweise einfach eine fortlaufende Nummer.
** Name, lies: der NACHname einer jeden Person.
** Vorname.

Weitere Attribute können jeder Person natürlich ebenfalls zugewiesen werden, so das gewünscht oder erforderlich ist: Mobiltelefonnummer. Schuhgröße. Was auch immer. Halt alles, was einer jeden Person *spezifisch* zuzuordnen ist.

== Adressen. Hier kann man sich streiten, was die "Identität", also den Primärschlüssel für Adressinformationen angeht. Es läßt sich recht leicht argumentieren, daß "das Haus in Straße X Hausnummer Y in Stadt Z mit PLZ W" eindeutig genug sein sollte. Das wäre dann ein vierteiliger Primärschlüssel. Man kann aber genausogut wieder eine arbiträre Identität zuweisen und dann dafür sorgen, daß (straße, hausnummer, plz, ort) eindeutig bleiben.

In jedem Fall brauchen wir zumindest diese vier Spalten:

** Straße
** Hausnr
** PLZ
** Ort

plus, analog zu den Personen oben, optionale, adress-spezifische Zusatzinformationen (Grundstück bebaut?, Art der Bebauung, Festnetzanschluß, sonstwas - Mobilfunkanschluß aber nicht, der ist personenspezifisch).

Jetzt haben wir eine Relation für "Personen" und wir haben auch eine Relation für "Adressen", wo die Personen wohnen können. Nur: Wie kriegen wir jetzt "Personen" und "Adressen" miteinander verbunden?

Schritt 4: Zuordnung der Tabellen untereinander

Dieser Teil ist derjenige, wo "Kunst", "Können" und "Wollen" sowie "Sollen" aufeinandertreffen.

Die Frage an dieser Stelle muß lauten: Was zur Hölle will ich überhaupt erreichen?!

Eine Datenbank soll die Realität möglichst genau widerspiegeln. Was ist also "die Realität"? Und "wieviel Realität" benötige ich?

Es stehen uns drei grundlegende Verknüpfungsoptionen zur Verfügung:

-1- Eine Eins-zu-Eins Beziehung (1:1).
Hier wird genau EINE Person genau EINER Adresse zugeordnet. Das bedeutet praktisch: Jede Person hat ganz genau EINE Adresse und an jeder Adresse findet sich ganz genau EINE Person.

-2- Eine Eins-zu-Viele Beziehung (1:n).
Hier gibt es zwei Möglichkeiten: entweder
>a> wir ordnen EINER Person VIELE Adressen zu; oder
>b> wir ordnen EINER Adresse VIELE Personen zu.

Option (b) scheint auf jeden Fall sinnvoller zu sein als Option (a), denn Option (a) läßt insbesondere "viele Personen an einer Adresse" *nicht* zu.
Aber andererseits kann man (a) auch nicht komplett bedenkenlos zu den Akten legen. Irgendwer könnte ja durchaus noch ein Wochenendgrundstück besitzen... oder gleich eine ganze Wohnsiedlung. Weiß man ja nicht.

Für sowas gibt es

-3- Eine Viele-zu-Viele Beziehung (m:n).
Hiermit lassen sich vielen Personen viele Adressen zuordnen. Es ist also eine Union aus (a) und (b) der 1:n-Beziehung weiter oben.


Wir müssen uns also im Hinblick auf unsere Daten fragen: Welche Option davon brauche ich? (1:1) wird vermutlich nicht ausreichen - es sei denn, das sind alles Singles und werden garantiert auch immer Singles bleiben. Unwahrscheinlich? Egal - eine 1:1-Beziehung kann nichts anderes darstellen.

Die Entscheidung zwischen (1:n) und (m:n) fällt da schon schwieriger. Das muß jeder für sich beurteilen, ob die *Möglichkeit* für "viele-Personen-an-vielen-Adressen" eingeräumt werden soll(oder muß) oder nicht. Tatsache ist: eine 1:n Beziehung läßt viele Personen an vielen Adressen nicht zu, andersherum hingegen schon.



... Sieht es so aus, also ob "m:n" das Non-Plus-Ultra wäre?

... Ist es nicht. :)

Zum Ersten besteht immer die Möglichkeit, daß man eben solche viele-zu-viele Beziehungen ausschließen will. Dann verwendet man natürlich auch keine m:n-fähigen Beziehungen.
Und zum Zweiten sind m:n Beziehungen aufwendiger in der Implementierung:


Erstellung der Verknüpfungen

-a- Die 1:1 Beziehung
Wir sorgen dafür, daß die Identität der Personen und der Adressen (person_id und address_id) dahingehend identisch ist, daß person_id als Schlüssel für Adressen verwendet werden kann (und umgekehrt). Beide Tabellen sind so lediglich eine Erweiterung der anderen und könnten formal in eine einzige Tabelle gesteckt werden. Das war's auch schon.

-b- Die 1:n Beziehung
Wir schauen uns an, welche Seite die "1" in "1:n" bekommen soll. In diesem Fall: 1 Adresse, n Personen".
Für die Implementation fügen wir also der Relation "Person" eine weitere Spalte hinzu und nennen diese "adresse". Hier rein kommt der Primärschlüssel der zugehörigen Adresse (spätestens hier würde der oben erwähnte vierteilige Primärschlüssel problematisch werden). Damit ordnen wir einer jeden Person genau EINE Adresse zu, aber OHNE Anspruch darauf zu erheben, daß diese Zuordnung eineindeutig ist. So können verschiedene Personen an eine Adresse gesetzt werden.

-c- Die m:n Beziehung

bekommen wir weder in "Adressen" noch "Personen" unter. Viele-Personen-an-vielen-Adressen ist bereits dreidimensional (Person, Adresse, Zuordnung); wir brauchen daher eine "Hilfstabelle", die diese Zuordnung beschreibt. Viel muß da nicht hinein:

** Person_ID, der Primärschlüssel der Person
** Adress_ID, der Primärschlüssel der Adresse

Außerdem gibt es noch einen Primärschlüssel für die Zuordnung selber: das ist (person_id, adress_id). Das sorgt dafür, daß jede *Zuordnung* eindeutig ist. Will heißen: Person 1 darf an Addresse 1 und auch an Adresse 2 erreichbar sein, ABER wenn Person 1 an Adresse 1 erreichbar *ist*, dann ist das *eindeutig* und wir brauchen keine weiteren (redundanten) Verknüpfungen, die dasselbe beschreiben.
Auch diese Tabelle kann natürlich weitere Spalten erhalten, die dann *für die Zuordnung* spezifisch ist. "Hauptwohnsitz" oder "Nebenwohnsitz" wäre ein Beispiel für eine Eigenschaft der Zuordnung (das hat weder mit "Adresse" noch mit "Person" was zu tun).


Wenn wir das alles haben, sind wir endlich fertig mit unserem (kleinen) Entwurf für unsere neue Datenbank. Jetzt müssen wir unsere Daten nur noch mit passenden SELECTs und JOINs wieder herausfischen.
Aber dafür lassen sich nun eine ganze Menge Dinge aus den Daten herauslesen, was vorher nicht möglich war: Wer ist an den meisten Adressen wohnhaft? Wieviele Adressen werden im Durchschnitt besessen? Und so weiter.

Außerdem: Sobald die Datenbank steht und erfolgreich mit Daten gefüttert wurde, kann jede kompatible Anwendung darauf zugreifen. Schluß mit dem ständigen Hin- und Herkopieren; Schluß mit fünf verschiedenen Versionen derselben Exceltabelle, wo fünf Mann mehr oder weniger dasselbe hineinfüttern, Schluß vor allem auch mit fünf verschiedenen Varianten ein- und desselben Eintrags mit verschiedenen Schreibweisen.

Aber es ist halt auch zu bedenken: Datenbanksysteme sind keine eierlegenden Wollmilchsäue. Wie wir gesehen haben, kann man nicht "mal so eben losfangen"; es gehört ein gut Teil Planung und Überlegung dazu und wenn dann noch mehrere Personen drauf zugreifen wollen, wird die ganze Sache erst richtig interessant (zugegeben: mit Excel geht DAS gar nicht).
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
1

Anzeige

Thema verteilen:


Seite 1 von 1

1 Besucher lesen dieses Thema
Mitglieder: 0, Gäste: 1, unsichtbare Mitglieder: 0