Datenbankdesign ist eine sehr komplexe und verantwortungsvolle Aufgabe. Schließlich stellen Daten die Grundlage aller Applikationen dar. In der Praxis ist es nicht wichtig, wie eine Rechnung oder eine Lagerbestandsliste erstellt wird, sondern daß es geschieht. Die dazu verwendeten Funktionen und Methoden sind lediglich Mittel zum Zweck. Es geht einzig und allein um die Daten.
In der Praxis sind die Datenbankstrukturen jedoch der wunde Punkt der meisten Applikationen. Es werden nur die grundlegendsten Planungsschritte durchgeführt, oder es wird einfach direkt “ins Blaue” programmiert.
DataBase Design Patterns (zu Deutsch “Datenbank Design Muster”) sollen hier Abhilfe schaffen. Sie sind jedoch keine Allheilmittel sondern nur Vorschläge. Design Patterns sind übrigens nie richtig oder falsch, sondern sie sind nur mehr oder weniger sinnvoll. Die hier vorgestellten Patterns können wahrscheinlich nicht direkt übernommen werden, sondern sie müssen den jeweiligen Bedürfnissen der Applikation oder gar den jeweiligen Bedürfnissen des Kunden angepaßt werden.
Es gibt viele verschiedene Möglichkeiten, Diagramme für Datenbanken zu erstellen. Ich halte mich hier an die CASE*MethodeTM Notation, die von Richard Barker, Ian Palmer, Harry Ellis und anderen für die britische Consulting Firma CACI entwickelt wurde, und unter anderen von Oracle verwendet wird.
Hier sehen Sie ein Beispiel für diese Notation. Es beschreibt eine Bestellung.
Entities sind Dinge, die für die jeweilige Organisation/ Firma/ Problemstellung wichtig sind und über die Daten gesammelt werden sollen. Das können z.B. Artikel, Kunden, Auftragszeilen, usw… sein. Entities werden durch abgerundete Rechtecke dargestellt. Im obigen Beispiel sind dies Artikel, Artikelzeile, Bestellung, Organisation und Person.
Anmerkung: Ich verwende das englische Wort “Entity”, weil es auch unter deutschsprachigen Entwicklern sehr gebräuchlich ist.
Nahezu alle Notationen verwenden Rechtecke, um Entities darzustellen. Die hier verwendete Methode ist jedoch einzigartig, wenn es um die Darstellung von unter- und übergeordneten Entities kommt. Ein untergeordnetes Entity definiert eine mögliche Erscheinung des übergeordneten Entities. In unserem obigen Beispiel kann ein Artikel entweder ein Produkt oder ein Service sein.
Ursprünglich war es vorgesehen, alle möglichen Sub-Entities aufzulisten. Mittlerweile wurde diese Regel jedoch liberalisiert und die Verwendung von Andere als Sub-Entity erlaubt.
Attribute beschreiben Entities. Die Werte dieser Attribute beschreiben Instanzen von Entities. Wenn ein Entity ein Ding von Wichtigkeit ist, über das man Informationen speichern will, dann beschreibt ein Attribut einen oder mehrere Teile dieser Information.
Beispiel: Ein Produkt hat Attribute wie Bezeichnung, Preis, Größe, usw… Für jedes einzelne Produkt würden diese Attribute unterschiedliche Werte haben. Wenn wir z.B. einen Tiger Tennisschuh haben, wäre die Bezeichnung z.B. Tiger Tennisschuh, der Preis wäre 149,00 DM und die Größe 44.
In einem Diagramm scheinen nicht unbedingt alle Attribute auf, die wirklich in einer Datenbank/ Tabelle gespeichert werden. Auch können einzelne Attribute mehrere Felder in einer Tabelle ergeben.
Relationen beschreiben die Beziehungen zwischen Entities. Die hier verwendete Notation hält viele verschiedene Wege bereit, unterschiedliche Relationen darzustellen.
Jede Relation kann in 2 deutschen Sätzen gelesen werden:
Wenn wir uns obiges Diagramm ansehen, könnte das folgendermaßen umgesetzt werden:
Somit kann die hier verwendete Notation einfach in normale deutsche Sätze umgesetzt und gelesen werden.
Dem Diagramm kann auch entnommen werden, wie viele Vorkommnisse der jeweiligen Entities und jeder Seite der Relation existieren können. Eine normale Linie bedeutet, daß es ein Vorkommen gibt. Krähenfüße zeigen, daß es mehrere Vorkommen geben kann. In unserem Beispieldiagramm gibt es also nur 1:n Relationen.
Der Bogen, der sich über die Relationen zwischen Bestellung und Organisation bzw. Bestellung und Person zieht, bedetuet, daß die Relation entweder zur Person oder zur Organisation besteht. Es kann also nicht beide Relationen gleichzeitig geben. Dasselbe hätten wir übrigens auch erreichen können, wenn wir Person und Organisation ein übergeordnetes Entity gegeben hätten.
Die CASE*MethodeTM bietet weit mehr, als hier gezeigt werden kann. Ich stelle jedoch nur jene Notationen vor, die in diesen Unterlagen verwendet werden.
Ganz egal, um welche Art von Geschäft es sich handelt, immer sind Personen, Firmen, Organisationen oder andere Parteien involviert. Dabei kann es sich um Kunden, Lieferanten, Angestellte, Privatpersonen, uvam… handeln. All diese Parteien können in einem Abstrakt zusammengefaßt werden, den wir Party (Partei) nennen. (Auch hier verwende ich den englischen Ausdruck, da dieser durchaus gebräuchlich ist.)
Eine Party hat Attribute wie Name oder Adresse, ganz egal, um welche Art von Party es sich handelt. Wie bereits erwähnt, gibt es verschiedene Arten von Parties, wie z.B. eine Person oder eine Organisation. Diese Entities haben wiederum individuelle Attribute, wie z.B. der Vorname und das Geburtsdatum einer Person. Eine Organisation hingegen hat keinen Vornamen. Hier gibt es jedoch andere Dinge zu beachten. Z.B. hat jede Organisation einen Grund, weshalb es sie überhaupt gibt, bzw. eine Aufgabe. Dies habe ich im obigen Diagramm einfach Beschreibung genannt.
All die bisher beschriebenen Attribute sind generisch. Man kann sie immer wieder verwenden ohne auf die Individualität unterschiedlicher Aufgabenstellungen eingehen zu müssen. Die weiteren anfallenden Attribute werden jedoch individuell hinzugefügt.
Natürlich gibt es verschiedene Arten von Personen. Eine Person kann z.B. ein Angestellter sein, oder eben nicht. Das müssen wir natürlich in unserem Modell beachten:
Auf den ersten Blick sieht das ganz gut aus. Angestellte haben zusätzliche Attribute, wie z.B. die Versicherungsnummer. Ausserdem können wir das Geburtsdatum aus dem Personen-Entity nehmen und statt dessen dem Angestellten geben, da uns das Geburtsdatum bei anderen Personen nicht interessieren dürfte. Das ist natürlich keine allgemein gültige Regel.
Wenn man dieses Konzept im Detail durchdenkt, fällt jedoch auf, daß eine Person sowohl ein Angestellter als auch eine andere Person sein kann, je nachdem, von welchem Standpunkt man die Sache betrachtet. In diesem Fall darf die Person natürlich nicht doppelt erfaßt werden, sondern wir müssen einen anderen Weg finden, diese Möglichkeit zu modellieren:
In diesem Modell kann eine Person einer Organisation zugeordnet werden. Jede Organisation kann eine beliebige Anzahl an Angestellten haben. Eine Person ist somit ein generisches Entity, das sowohl ein Angestellter als auch eine andere Person sein kann. Dennoch hat dieses Modell einige Probleme. Zum einen kann eine Person natürlich für mehr als eine Organisation arbeiten. Ausserdem gibt es spezielle Attribute für jedes Angestelltenverhältnis. Es bietet sich also an, dafür ein eigenes Entity zu erzeugen:
Mit diesem Modell kan eine Person verschiedene Anstellungen bei verschiedenen Organisationen haben. Dies kann sowohl in verschiedenen Zeiträumen, als auch gleichzeitig sein, was unter Umständen jedoch auch nicht erwünscht sein kann. Wir können das jedoch innerhalb dieses Modelles nicht einschränken, sondern müßten die mit Business Rules (Geschäftsregeln) ausserhalb des Modells definieren.
In der Praxis werden Personen jedoch nicht einfach angestellt um irgend eine Arbeit zu verrichten, sondern sie werden bezahlt, um ganz spezielle Positionen auszufüllen. Beispiele für Positionen wären Lehrer, Direktor, Programmierer, usw… Natürlich kann eine Person mehreren Positionen zugeordnet werden. Schließlich könnte jemand gleichzeitig Lehrer und Direktor sein. Ausserdem kann eine Position von mehreren Personen ausgefüllt werden. So könnte eine Organisation z.B. mehrere Lehrer beschäftigen (gleichzeitig) oder - auf längeren Zeitraum gesehen - mehrere Direktoren haben.
Das nächste Diagramm zeigt eine Variation des gerade Besprochenen. Nehmen wir an, Positionen werden firmenweit definiert. In einzelnen Abteilungen werden diese Positionen jedoch anders benannt. Ein Beispiel dafür wäre ein Abteilungsleiter. In der Marketingabteilung könnte er Marketingdirektor heissen, in der Entwicklungsabteilung jedoch Leadprogrammer. Dennoch sind beide in der selben Position.
Eine weitere Variation ist es wieder das zuvor besprochene Positionszuordnungs-Entity zu verwenden:
Das Interessante an diesem Modell ist, daß eine Person eine Position ausfüllen kann, die von einer anderen Firma definiert wurde, als von der für die er arbeitet. Das ermöglicht es, einen Consultant zu definieren, der zwar bei einer Firma angestellt ist, aber für eine andere Firma in einer von dieser zweiten Firma definierten Position arbeitet. Natürlich kann dieses Modell mit dem zuvor beschriebenen kombiniert werden.
Bisher haben wir uns lediglich ein Subentity von Party angesehen, nämlich Person. Nun ist es an der Zeit, die Organisationen genauer zu beleuchten. Eine Organisation hat natürlich auch wieder mehrere Unterteilungen. So gibt es zuerst interne und externe Organisationen. Eine interne Organisation könnte wiederum eine Abteilung sein. Eine externe Organisation könnte eine Firma, eine Regierung oder eine andere Organisation sein.
Natürlich könnte man diese Entities auch wieder weiter unterteilen. Dabei möchte ich auf einen Fehler aufmerksam machen, den man immer wieder sieht: Sehr oft werden Regierungen in fremde und eigene Regierungen unterteilt. Das mag zwar etliches erleichtern, funktioniert jedoch nur dann wenn die jeweilige Applikation in nur einem Land läuft. Dies wird (vor allem im Zeitalter des Internet) jedoch ziemlich unwahrscheinlich.
Parties haben normalerweise eine oder mehrere Adressen. Der einfachste Weg wäre es, Adressen einfach als Attribut von Party zu definieren. Das Problem jedoch ist, daß Parties sehr oft mehr als eine Adresse haben. So könnte es beispielsweise eine Lieferadresse, eine Rechnungsadresse und bei Personen eine Privatadresse geben. Aus diesem Grund sollte Adresse ein eigenes Entity sein.
Dies bringt jedoch ein Problem mit sich. Wir haben nämlich definiert, daß eine Adresse die Lokalität von einer Party ist. In der Praxis kommt es jedoch vor, daß mehrere Parties eine Adresse teilen, z.B. einzelne Personen einer Familie, oder mehrere Büros in einem Geschäftskomplex. Aus diesem Grund führen wir ein weiteres Entity ein, nämlich Lokalität.
Oft ist es interessant zu wissen, in welchem geografischen Bereich sich eine Adresse befindet. Ein geografischer Bereich kann ein Kontinent, ein Land, eine Provinz, eine Stadt, usw… sein. Geografische Bereiche selbst sind hierarchische Strukturen. Das bedeutet, daß sich ein geografischer Bereich aus anderen geografischen Bereichen zusammensetzen kann. Dies wird durch das sogenannte “Schweineohr” im Entity Geografischer Bereich dargestellt. Eine derartige Konstruktion kann natürlich nicht einfach über eine Relation implementiert werden, sondern sie muß in Form von Business Rules codiert werden.
Wenn wir Adressen nur dazu verwenden um Briefe zu versenden, schießt dieses Modell eindeutig über das Ziel hinaus. Für andere Anwendungen hingegen müssen geografische Bereiche weit detaillierter ausgearbeitet werden. Geografische Bereiche können natürlich in verschiedene Unterbereiche aufgeteilt werden. So kann sich ein geografischer Bereich z.B. aus Provinzen, Staaten und Kontinenten zusammensetzen. Die Struktur könnte jedoch auch aus von der Natur gegebenen Bereichen bestehen, wie z.B. aus Seen oder Tälern. Eine derartige Strukturierung ist z.B. für Forstamte wichtig. Normalerweise bleibt man jedoch beim Provinz-/ Land-/ Kontinentmodell.
Das bisher verwendete Modell birgt jedoch einige Probleme. Geografische Bereiche sind nämlich keine wirklich logische Struktur, sondern sie können teilweise ziemlich konfus sein. Nehmen wir z.B. Postleitzahlenbereiche. Normalerweise sind diese einem bestimmten Bundesland zugeordnet. In Österreich ist z.B. der Bereich 5 Salzburg. Es gibt jedoch auch in Oberösterreich einige 5er Postleitzahlen.
Das Ganze wird noch komplexer, da geografische Subbereiche oft zu mehr als einem übergeordneten Bereich gehören können. In Amerika trifft man das öfters bei Indianerreservaten an. Aber auch in Europa gibt es dafür einige Beispiele. In Österreich gehört z.B. der Bereich rund um den Großglockner teils zu Salzburg und teils zu Kärnten. Oder der Bodensee z.B. gehört gar zu 3 verschiedenen Ländern.
Um derartigen Strukturen gerecht zu werden, bringen wir ein weiteres Entity ins Spiel, nämlich das geografische Struktur-Element:
Das bedeutet, daß ein geografischer Bereich aus mehreren geografischen Struktur-Elementen zusammengesetzt sein kann. Salzburg z.B. besteht aus mehreren Gauen und dem Großglocknergebiet. Diese Teile stellen wiederum andere geografische Bereiche dar. Geografische Struktur-Elemente kann es wiederum in mehreren geografischen Bereichen geben. Das Großglocknergebiet könnte es somit in Salzburg und in Kärnten geben.
Kommen wir jedoch wieder zurück zu Organisationen und Personen. Wie wir bereits gesehen haben, können Personen für Organisationen arbeiten. Es gibt jedoch noch viel mehr Arten der Beziehungen zwischen verschiedenen Parties. Eine Organisation kann sich z.B. aus mehreren Organisationen zusammensetzen.
Jede Party hat Dinge, die sie produziert oder verwendet. Das können Produkte sein, die sie verkauft oder herstellt, oder es können Werkzeuge sein, die dazu benötigt werden. Es könnten jedoch auch Services sein, die angeboten werden. In Spezialfällen kann das sehr komplex werden. In einem Kraftwerk wird z.B. Strom hergestellt. Niemand arbeitet jedoch direkt mit Strom, sondern man benutzt Maschinen, um Strom herzustellen und man verwendet Kabel, um den Strom zum Kunden zu bringen.
Sehen wir uns hergestellte bzw. verkaufbare Produkte genauer an. Hier muß man zwischen den Produkttypen und den Produkten selbst unterscheiden. Eine Produkttype wäre z.B. “Pentium 166mHz Computer”. Das dazugehörige Produkt wäre ein Pentium Computer mit der Seriennummer 34642674.
Produkte werden normalerweise in verschiedene Produktgruppen unterteilt. Dabei ist zu beachten, daß ein Produkt in mehrere Produktgruppen gehören kann. Der oben beschriebene Computer würde sowohl in die Produktgruppe “INTEL Computer” als auch in “beige Computer” passen. Dies kann über ein zusätzliches Klassifizierungs-Entity erreicht werden. Wenn Sie sich folgendes Diagramm ansehen, werden Sie feststellen, daß sowohl das Produkt selbst als auch ein Produkttype klassifiziert werden kann. Es kann jedoch nur entweder das Produkt oder die Produkttype klassifiziert werden und nicht beide gleichzeitig.
Firmen arbeiten jedoch nicht nur mit Produkten, sondern mit verschiedensten Artikeln. Daher sollten wir die Bezeichnung Produkt und Produkttype nicht mehr verwenden, sondern den allgemeingültigen Begriff Artikel verwenden. Ein Artikel kann in verschiedene Untergruppen unterteilt werden.
Eine ähnliche Unterteilung kann auch für die einzelnen Artikel gemacht werden. Hierbei liegt das Hauptaugenmerk jedoch auf Artikeln mit Seriennummer oder ähnlichem (individuelle Artikel), und Massenartikel wie z.B. Schrauben (Inventar). Ausserdem gibt es Artikel, die in keine dieser Gruppen passen, wie z.B. Dienstleistungen.
In diesem Modell wird auch die aktuelle Lokalität eines Artikels definiert. Natürlich muß dieses Modell bei vielen Applikationen noch detaillierter ausgearbeitet werden. Ein Inventar kann z.B. aus vielen verschiedenen Untergruppen definiert werden. Ausserdem sollten wir definieren, welche Typen sich auf welche Artikel beziehen.
Einzelne Produkte/Artikel können natürlich aus mehreren anderen Artikeln zusammengesetzt sein. Ein Beispiel dafür wäre z.B. ein Auto, das aus einem Motor, einer Karosserie, Sitzen, usw… besteht. Der Motor wiederum besteht aus weiteren Teilen. Das kann folgendermaßen modelliert werden:
Dieses Modell hat jedoch einige Probleme. Zum einen haben wir eine n:n Relation. Zum anderen wissen wir z.B. nicht, wie viele Artikel in einem anderen enthalten sind. Wir haben z.B. keine Information darüber, wie viele Kolben in einem Motor sind. Daher führen wir auch hier ein weiteres Entity ein.
Kehren wir jedoch nun zu unserem eigentlichen Artikel-Entity zurück. Ein Problem, das wir dort noch haben ist, daß alle Artikel dieselben Attribute haben. Das bedeutet, daß, ganz egal ob wir Bleistifte, Chemikalien oder Weißwürste verkaufen, alle dieselben Attribute teilen. Das ist in der Praxis natürlich nicht sinnvoll. Bleistifte werden nämlich nach Härtegraden verkauft, Chemikalien nach unterschiedlichsten Werten (z.B. pH-Wert) und Weißwürste in Paaren. Dieses Problem können wir mit folgendem Modell lösen:
Jede Artikeltype wird beschrieben durch Werte. Ein Computer hat z.B. eine bestimmte Leistung, gemessen in mHz. Ausserdem hat er einen Hauptspeicher von bestimmter Größe und ebenso eine Festplatte. Andere Artikel werden durch andere Werte beschrieben, eine Chemikalie z.B. durch ihren pH-Wert. MHz-Werte interessieren uns hier hingegen nicht. All diese Werte werden im Attribute-Entity definiert.
Jede Artikeltype ist einer und nur einer Artikelklasse zugeordnet. Diese Artikelklasse könnte z.B. “Computer” oder “Chemikalie” sein. Über das Entity Attributzuordnung werden jeder Klasse Attribute zugeordnet. Jedes Attribut kann in beliebig vielen Klassen zugeordnet werden. Das Attribut “Länge” kann z.B. bei Tischen und bei Betten verwendet werden.
Die Liste der möglichen Modelle würde den Umfang dieser Sessionunterlagen (oder womöglich sogar den Umfang des ganzen Ordners) bei weitem sprengen. Diese Unterlagen können somit nur eine sehr oberflächliche Einführung in diese Materie darstellen. Es soll jedoch auch nicht Sinn dieses Dokumentes sein, möglichst viele Modelle zu präsentieren, sondern ich will Ihnen die Idee der Datenbank Design Patterns näherbringen.
Naheliegende weitere Modelle wären z.B. Verträge. Darunter versteht man z.B. auch mit Kunden abgeschlossene Kaufverträge und die dazugehörigen Rechnungen, Mahnungen, usw. Ziemlich gebräuchlich sind auch Patterns für Buchhaltungen und ähnliches. Weiters gibt es in jeder Firma Aktivitäten und Ereignisse, die koordiniert werden müssen. Daraus resultieren meist Dokumente (im weitesten Sinne). Diese Liste könnte ich noch beliebig erweitern.
Wenn Sie sich für mehr Informationen zu diesem Thema interessieren, können Sie diese z.B. bei diversen Workshops bekommen. Leider gibt es bisher nicht viel Literatur zu diesem Thema. Eines der wenigen Bücher, die ich empfehlen kann, ist “Data Model Patterns” von David C. Hay (ISBN: 0-932633-29-3). Ausserdem können Sie mich natürlich jederzeit über CompuServe oder Internet kontaktieren.