<\/p>\n
Hierarchieartige Strukturen spielen im Datenbankentwurf immer wieder eine große Rolle. Bereits eine schlichte 1:n-Beziehung stellt eine Hierarchie dar. Um in der Dateneingabe einerseits flexibel zu bleiben, aber dennoch Benutzerfehler schon durch den Entwurf zu verhindern, muss man einige Dinge beachten. In diesem Beitrag zeigen wir die Fallstricke beim Entwurf hierarchischer Datenstrukturen auf.<\/b><\/p>\n
Bei diesen Fragen stehen drei Themen im Mittelpunkt:<\/p>\n
In diesem Artikel geht es zunächst um den ersten Teil, die Datenmodellierung.<\/p>\n
Es gibt mehrere Arten von Hierarchien, die sich zunächst in Begriffshierarchien und Objekthierarchien aufteilen:<\/p>\n
Begriffshierarchien oder logische Hierarchien liegen vor, wenn die Objekte, die Sie in Form von Datensätzen verwalten wollen, in einem Teil der zu speichernden Eigenschaften übereinstimmen, sich aber in anderen unterscheiden. Dabei geht es nicht um die Eigenschaftsausprägungen, also die Feldwerte, sondern um die Eigenschaften an sich beziehungsweise die Felddefinitionen.<\/p>\n
Nehmen wir an, Sie haben es in Ihrer Datenbank mit Firmen zu tun, die sich in Kunden und Lieferanten aufteilen. Um Beziehungen mit referentieller Integrität zu anderen Tabellen des Modells umzusetzen (etwa Kunde\/Auftrag, Lieferant\/Bestellung), brauchen Sie eine Lieferantentabelle und eine Kundentabelle. Sie benötigen durchaus unterschiedliche Informationen zu beiden – zu den Lieferanten erfassen Sie etwa Lieferrabatte oder durchschnittliche Lieferzeiten, zu den Kunden erfassen Sie Informationen, die für die Akquise wichtig sind und die Sie in Zusammenhang mit Lieferanten nie brauchten.<\/p>\n
Die Felddefinitionen beider Tabellen sind jedoch zu einem großen Teil identisch: Sowohl Kunden als auch Lieferanten definieren sich über einen Namen, eine Stammadresse und andere Informationen, denn sie gehören der gleichen Grundmenge an: den Firmen.<\/p>\n
Hier haben wir nun eine einstufige Begriffshierarchie: Firma – (Kundenfirma, Lieferantenfirma).<\/p>\n
Es gibt ein Feldbündel, das für Firmen generell gilt, und es gibt je ein Feldbündel, das speziell nur für Kunden oder Lieferanten gilt. So etwas nennt man Generalisierungs-Spezialisierungs-Struktur. In der objektorientierten Programmierung gibt es ähnliches, dort ist dafür die Bezeichnung IsA-Beziehung („Ist-Ein-Beziehung“) üblich. Klassenprogrammierer modellieren so etwas mit Vererbung von Klassen.<\/p>\n
Wie aber modelliert ein Datenbankprogrammierer diese Beziehung in einer Tabellenstruktur Nun, genau hier kommen die oft verkannten 1:1-Beziehungen zum Einsatz. Genauer sind es 1:1\/0-Beziehungen: sie sind also nicht symmetrisch. Es gibt eine Mastertabelle, die 1-Seite, die die Felder für die höhere Generalisierungsstufe aufnimmt (im Beispiel die Firma), und Detailtabellen, die 1\/0-Seite, die die Felder für die stärker spezialisierten Stufen aufnehmen – im Beispiel Kunde und Lieferant.<\/p>\n
Solche Hierarchien können natürlich auch mehrstufig werden. Ein Beispiel ist die biologische Systematik: Reich\/Stamm\/Klasse\/Ordnung\/Familie\/Gattung\/Art<\/b>:<\/p>\n
– Wirbeltiere<\/p>\n
– Fische<\/p>\n
– Reptilien<\/p>\n
– Vögel<\/p>\n
– Säugetiere <\/p>\n
– Paarhufer<\/p>\n
– Unpaarhufer<\/p>\n
– Raubtiere<\/p>\n
– Nagetiere<\/p>\n
Die anzulegenden Tabellen tragen dabei nicht etwa die Namen Klasse<\/b>, Ordnung<\/b>, Familie<\/b>, Gattung<\/b> und Art<\/b>, sondern Sie müssen tatsächlich eine Tabelle Wirbeltiere<\/b> für die Eigenschaften, die allen Wirbeltieren gemeinsam sind, anlegen. Damit nicht genug: Es gibt weitere Spezialtabellen namens Fische<\/b>, Reptilien<\/b>, Vögel <\/b>und Säuger<\/b> und dann in einer weiteren Stufe noch Spezialtabellen zweiter Ordnung wie Huftiere<\/b> und Raubtiere<\/b> oder bei den Reptilien Schlangen<\/b>, Eidechsen<\/b> und Schildkröten<\/b>.<\/p>\n
Umfangreiche Begriffshierarchien erfordern also eine Vielzahl von Tabellen. Zum Glück sind die meisten derartigen Hierarchien in betriebswirtschaftlichen Anwendungen sehr flach, sodass sich die Tabellenzahl in Grenzen hält.<\/p>\n
Der Aufbau der Tabellen ist nicht sonderlich schwer: Auf der obersten Ebene wird ein Schlüsselfeld angelegt (zum Beispiel ein Autowert-Feld) sowie Felder für alle Daten, die allen Individuen gemeinsam sind. Die Tabellen der zweiten Ebene enthalten als Primärschlüssel ein Feld, das die Beziehung zum Primärschlüssel der ersten Ebene aufbaut. Im Falle eines Autowertes auf oberster Ebene verwenden Sie hier eine Long-Integer-Zahl. Diese vererbt sich auf alle nachgeordneten Ebenen. Hinzu kommen die spezifischen Daten dieser Ebene. Die verschiedenen Tabellen auf einer Ebene haben dabei durchaus völlig unterschiedliche Felder, was ja letztlich der Grund für die Aufteilung auf mehrere Tabellen ist. Für die weiteren Ebenen setzt sich dies analog fort.<\/p>\n
Sie könnten nun auf die Idee kommen, einfach eine Tabelle Tiere<\/b> anzulegen, die alle Felder enthält oder, um ein praxisnäheres Beispiel zu verwenden, nur eine Tabelle namens Firmen<\/b>, die Kunden- und Lieferantenfelder mit aufnimmt. Dadurch entstehen jedoch verschiedene Probleme.<\/p>\n
Die Tabelle Tiere <\/b>würde jetzt unter anderem die Felder Fellfarbe <\/b>und Flossenform <\/b>enthalten. Dadurch bleibt bei allen Nichtfischen das Feld mit den Flossen leer und kein Nichtsäuger braucht das Feld zum Eintragen einer Fellfarbe.<\/p>\n
Dadurch wird zunächst die NULL-Wert-Semantik ruiniert, da NULL jetzt nicht mehr wie gefordert für prinzipiell existierende, aber noch nicht bekannte Daten steht, sondern für Daten, die gar nicht existieren können.<\/p>\n
Angenommen keines dieser spezialisierten Felder würde zwingend eine Eingabe erfordern. Dann können Sie, wenn keines dieser Felder ausgefüllt ist, nicht mehr unterscheiden, um welche spezielle Gruppe es sich handelt. Also brauchen Sie ein Typfeld, das diese Information liefert. Der Benutzer kann dann aber problemlos die Kategorie Fisch <\/b>auswählen und dazu die Fellfarbe <\/b>ausfüllen. Ergo: Die Datenbank bietet die strukturelle Möglichkeit, widersprüchliche Informationen einzugeben.<\/p>\n
Wenn nun eines oder mehrere solcher Felder zwingend eine Eingabe erfordern, zum Beispiel die Fellfarbe bei Säugetieren, tritt das erste Problem auf: Sie können das Feld nicht auf Eingabe erforderlich<\/b> stellen, da dieses etwa bei Fischen nicht ausgefüllt werden darf.<\/p>\n
Und schließlich stellt sich noch ein weiteres Problem: Zwischen Teilen dieser zusammengewürfelten Tabelle und anderen Tabellen sollen Beziehungen bestehen. Zum Beispiel wollen Sie eine Beziehung zwischen Kunden und Aufträgen und zwischen Lieferanten und Bestellungen herstellen. Wenn beide zusammen in einer Tabelle namens Firmen<\/b> gespeichert sind, steht diese auf der einen Seite der Beziehung.<\/p>\n
Das Datenbanksystem kann nun aber Fehleingaben wie die Zuordnung eines Lieferanten zu einem Auftrag nicht mehr über referentielle Integrität verhindern. Fehleingaben kann man hier nicht mehr durch die reine Tabellenstruktur, sondern nur noch durch eine entsprechende Programmierung vermeiden.<\/p>\n
Die Variante mit je einer Lieferanten- und Kundentabelle vermeidet diese Probleme, ersetzt sie aber durch neue.<\/p>\n
Eine Liste aller Firmen erhalten Sie beispielsweise nur über eine UNION-Abfrage auf Teile dieser Tabellen. Für Firmen, die gleichzeitig Lieferant und Kunde sind – das kann es ja durchaus geben -, gäbe es direkt zwei Datensätze, je einen in der Lieferanten- und in der Kundentabelle. Dies führt dazu, dass änderungen der Firmendaten an mehreren Stellen notwendig sind. Bei Verwendung von Autowerten hat dieselbe Firma als Kunde und Lieferant verschiedene Primärschlüssel. Durch einen Vertipper im Firmennamen bei der doppelten Eingabe entstehen inkonsistente Daten.<\/p>\n
Somit bleibt nur die Möglichkeit, Begriffshierarchien auch regelgerecht mit 1:1\/0-Beziehungen aufzubauen.<\/p>\n
Es ist natürlich legitim, durch Wahl abstrakterer Begriffe für die Felder die Tabellenanzahl möglichst klein zu halten. Zum Beispiel könnten Sie statt der Felder Fellfarbe<\/b> (Säuger), Schuppenfarbe<\/b> (Fische) oder Federfarbe<\/b> (Vögel) die zwei Felder Farbe <\/b>und Ummantelungsart<\/b> auf der Ebene Tier<\/b> verwenden.<\/p>\nArten von Begriffshierarchien<\/h2>\n
Man kann mehrere Sorten von Spezialisierungen unterscheiden:<\/p>\n
<\/p>\n
Das Tierbeispiel ist disjunkt obligatorisch. Jedes Tier gehört zu je einer Klasse, Ordnung, Familie, Gattung und Art. Sie können zu einem Tier nicht einfach Teile der Hierarchie weglassen. Obendrein gehört jedes Tier zu höchstens einer Klasse, Ordnung, Familie, Gattung und Art. Es darf also nicht mehreren Tabellen auf derselben Ebene zugeordnet sein.<\/p>\n
Das Firmenbeispiel ist adjunkt optional. Eine Firma braucht weder Lieferant noch Kunde zu sein („sonstige Firma“), kann eines davon sein, aber auch beides zugleich.<\/p>\n
Aus den beiden Eigenschaftenpaaren lassen sich also vier Typen kombinieren. Das Festlegen eines davon ist über Trigger möglich. Ohne weitere Trigger hat man den Typ adjunkt optional eingestellt.<\/p>\n
Das Fehlen von Triggern ist natürlich ein schweres Manko von Access, insbesondere da diese per definitionem Bestandteil eines RDBMS sein müssen. Es bleibt hier nur der Notnagel, Trigger in den Eingabeformularen per Ereignisse und VBA-Code nachzustellen und den Zugriff anderer Clients ohne diese Kontrolle auf die Daten zu verhindern.<\/p>\n
Dieses Ungemach ist natürlich jedem Access-Entwickler vertraut, man kann es allenfalls durch einen SQL-Server oder eine vergleichbare Datenbankmaschine als Backend umgehen.<\/p>\n
Durch ein richtiges Modell ergeben sich folgende Vorteile:<\/p>\n
In Bild 1 sehen Sie, wie sich die zahlreichen Datensätze der obersten Ebene auf immer mehr spezialisierte Tabellen verteilen. Die Anzahl Tabellen wird je Ebene immer größer, die Anzahl Datensätze in den Tabellen dabei kleiner. Letztlich zieht sich ein Datensatz einfach über mehrere Tabellen hin; erkennbar an der Graufärbung bei einigen Beispieldatensätzen.<\/p>\n
![\"1.TIF\"](\"..\/fileadmin\/_temp_\/2008_01\/Hierarchien-web-images\/1_opt.jpeg\")
<\/p>\n
Bild 1: Begriffshierarchie<\/span><\/b><\/p>\n Eine Objekthierarchie oder auch materiale Hierarchie wie in Bild 2 liegt vor, wenn die Objekte, die Sie in Form von Datensätzen verwalten wollen, zueinander in einem Über-Unter-Ordnungsverhältnis stehen. Die Eigenschaften der Objekte, die sich als Tabellenfelder niederschlagen, sind dabei zunächst irrelevant; entscheidend ist die mögliche Existenz mehrerer abhängiger Datensätze zu einem Datensatz auf der nächsten Ebene, was analog auch für weitere Ebenen gilt.<\/p>\n Nehmen wir an, Sie haben in Ihrer Datenbank Firmen, deren Angestellte für Sie als Ansprechpartner fungieren, die wiederum mit Ihnen jeweils mehrere Gespräche führen.<\/p>\n Eine Firma regiert also beliebig viele Ansprechpartner, von denen jeder beliebig viele Gespräche regiert. Umgekehrt können Sie jedes Gespräch genau einer Person zuordnen und diese wiederum genau einer Firma.<\/p>\n Im Gegensatz zur Begriffshierarchie zerfasern die Tabellen also nicht beim Durchlaufen der Ebenen, sondern es gibt auf jeder Ebene nur eine Tabelle. Allerdings zerfasern hier die Datensätze, im typischen Fall gehören also zu jedem Datensatz auf der nächsten Ebene mehrere Datensätze. Der Hierarchiecharakter zeigt sich also bei der Begriffshierarchie auf Tabellenebene und hier, bei der Objekthierarchie, auf Datensatzebene.<\/p>\n In der Klassenprogrammierung entspricht dieser Art der Hierarchie die mehrfache Instanzierung, wobei eine Oberklasse über eine Listeneigenschaft verfügt, die mehrere Unterklassen derselben Art referenziert.<\/p>\n Auch bei den Objekthierarchien gibt es mehrere Hierarchietypen:<\/p>\n Bild 3: Reflexive Objekthierarchie<\/span><\/b><\/p>\n Aus diesen beiden Eigenschaftenpaaren lassen sich diesmal nur drei Typen kombinieren. Eine finite Hierarchie kann reflexiv oder irreflexiv sein; eine infinite Hierarchie ist aber nur reflexiv möglich.<\/p>\n Geschlossene irreflexive Hierarchien sind der häufigste Fall in der Datenbankentwicklung. Diese legen Sie einfach in Form aufeinander folgender 1:n-Beziehungen an. Ebene 1 wiederholt den Primärschlüssel von Ebene 0 als Fremdschlüssel; Ebene 2 wiederholt den Primärschlüssel von Ebene 1 als Fremdschlüssel und so weiter.<\/p>\n Jede dieser Tabellen kann von anderer Bedeutung sein und andere Datenfelder enthalten als vorgängige und nachfolgende Ebenen. Die Fremdschlüsselfelder müssen mit Eingabezwang versehen werden, da sonst nicht sichergestellt ist, dass alle Elemente bis auf die gleiche Ausgangsebene („Wurzel“) zurückverfolgt werden können.<\/p>\n In Bild 2 sehen Sie eine dreistufige Hierarchie; das könnte etwa das erwähnte Beispiel mit den Firmen (Ebene 0), Ansprechpartnern (Ebene 1) und Gesprächen (Ebene 2) sein. Die drei Datenbankobjekte weisen logischerweise völlig unterschiedliche Felder auf. Die Tiefe solcher Hierarchien ändert sich nicht, es sei denn, das Vorbild der realen Welt, das Sie modelliert haben, würde sich ändern. Um die Hierarchie daran anzupassen, wäre eine änderung der Tabellenstruktur erforderlich.<\/p>\n Bild 2: Objekthierarchie<\/span><\/b><\/p>\n Die Hierarchieinformationen (die Kaskade der Fremdschlüssel) und die Nutzdaten eines Objekts (Firmenname, Telefon, Gründungsjahr der Firma; Firmenfremdschlüssel, Vor- und Nachname, Durchwahl des Ansprechpartners; Ansprechpartnerfremdschlüssel, Zeit und Inhalt des Gesprächs) befinden sich in jeder Ebene in jeweils derselben Tabelle.<\/p>\n Offene irreflexive Hierarchien sind logisch ausgeschlossen. Jede Ebene würde durch eine eigene Tabelle modelliert, während die Anzahl der Ebenen gleichzeitig nicht feststeht. <\/p>\n Die Datenbank wäre also gezwungen, auf Benutzereingaben gegebenenfalls mit dem Hinzufügen von Tabellen, Erstellen von Beziehungen, respektive Löschen derselben und gleichzeitigem Hinzufügen oder Löschen verbindender Datensätze zu reagieren.<\/p>\n Das ist mit dem Prinzip eines fixen logischen Datenschemas, das dem relationalen Gedanken zu Grunde liegt, nicht vereinbar.<\/p>\n Reflexive geschlossene Hierarchien sind denkbar, kommen aber in der Praxis so gut wie nie vor. Ein Beispiel könnte Folgendes sein:<\/p>\n Sie verwalten einen Verein, in dem es genau drei Ränge gibt, die ganz außerordentlich wichtig sind und laut Statuten niemals geändert werden dürfen. Ein Zenturio ist mehreren Dekurionen vorgesetzt, ein Dekurio mehreren Legionären. Jedes Vereinsmitglied gehört genau einem der drei Ränge an. Der Rang ist eine reine Vorgesetzteninformation, zu der es sonst keine weiteren Daten gibt.<\/p>\n Sie erstellen zunächst drei kaskadierende 1:n-Tabellen Zenturio, Dekurio, Legionär – analog zu Firma, Ansprechpartner, Gespräch – mit allen erforderlichen Daten.<\/p>\n Jetzt sollte Ihnen Zweierlei auffallen. Erstens: Alle drei Tabellen haben genau die gleichen Datenfelder, da ja alle logisch vom Typ Person sind. Zweitens: Wenn ein Mitglied einen neuen Rang bekommt, müsste es mit allen Informationen aus der einen Tabelle gelöscht und gleichzeitig in eine andere eingefügt werden. Beim irreflexiven Beispiel stellte sich dieses Problem nicht, da ein Gespräch nicht irgendwann zur Firma befördert wird.<\/p>\n Idee: Alle Personendaten wie etwa Vorname, Nachname oder Geburtsdatum kommen in eine separate Personen-Tabelle. Die Tabellen Zenturio<\/b>, Dekurio <\/b>und Legionär <\/b>enthalten nur noch je einen Primär- und Fremdschlüssel, der die reine Hierarchie darstellt.<\/p>\n Mit einer Abfrage über alle Legionäre können Sie sich über den Dekurion-Fremdschlüssel der Legionär-Tabelle die zugehörigen Dekurionen anzeigen lassen und durch den Zenturionen-Fremdschlüssel der Dekurionen-Tabelle die denen vorgesetzten Zenturionen. Sie merken sofort: Die Zenturionen-Tabelle brauchen Sie gar nicht: Einem Zenturio ist niemand übergeordnet. Ergo wird die überflüssige Tabelle entsorgt. Das Beziehungsschema sehen Sie in Bild 4.<\/p>\n Bild 4: Reflexive geschlossene Hierarchie<\/span><\/b><\/p>\n Die Beziehungen sind gewöhnliche 1:n-Beziehungen mit Eingabepflicht auf den Fremdschlüsseln fiZ <\/b>und fiD<\/b>, die 1:1\/0-Beziehung ist von Person_1 <\/b>als Master nach Legionär <\/b>als Detail erstellt. Eine n-stufige Hierarchie dieser Art beginnt also oben mit der Datentabelle, an die die 1:n-Kaskade von n-1 reinen Hierarchietabellen anschließt, und wird unten von einer 1:1-Beziehung auf die wiederholte Datentabelle abgeschlossen.<\/p>\n Dieser Hierarchietyp ist der krönende Abschluss. Wie Bild 3 zeigt, gibt es hier nicht mehr mehrere Ebenentabellen, die die hierarchische Ordnung herstellen, sondern nur noch eine Tabelle, welche die diesbezüglichen Informationen für alle Ebenen mit zwei Feldern aufnimmt. Hierarchieebenen erscheinen jetzt also nicht mehr horizontal als nebeneinanderstehende Tabellen, sondern vertikal als untereinanderstehende Datensätze.<\/p>\n Daraus folgt, dass die Hierarchie durch bloße Dateneingabe beliebig erweitert werden kann.<\/p>\n Kein Licht ohne Schatten: Die Nachfahren eines Urelements muss man jetzt mühsam in der Tabelle zusammensuchen:<\/p>\n Das Urelement 1 hat die Kinder 4 und 5. 4 hat die Kinder 9, 10 und 11, die somit die Enkel von 1 sind. 9 wiederum hat die Kinder 21, 22, 23, 24, also die Urenkel von 1.<\/p>\n Da die Hierarchie in ihrem Aufbau einem Baum entspricht, benutzt man hier auch gerne die entsprechende Terminologie.<\/p>\n Die in der Hierarchie angeordneten Elemente heißen daher auch Knoten.<\/p>\n Ein Urelement, also ein Knoten, dem kein Knoten mehr übergeordnet ist, heißt Wurzel oder Root.<\/p>\n Den Weg von Element 1 zu Element 22, also 1\/4\/9\/22, nennt man den Pfad zu 22.<\/p>\n Endknoten, also solche, denen keine Knoten untergeordnet sind, heißen Blätter.<\/p>\n Ein übergeordneter Knoten heißt Elter oder Parent; ein untergeordneter Knoten Kind oder Child.<\/p>\n Die Art der Darstellung heißt Adjazenzliste oder Vater-Zeiger (Parent Pointer).<\/p>\n Vielleicht fällt Ihnen auf, dass man anhand eines Datensatzes gar nicht mehr wie bisher so ohne Weiteres wieß, auf welcher Ebene der Hierarchie man sich befindet.<\/p>\n Insbesondere wieß man auch nicht, wie tief geschachtelte Nachfahren man unter einer Wurzel zu erwarten hat. Damit wieß man auch nicht mehr, wie viele Felder eine Abfrage haben müsste, um auch den längsten Pfad noch in einer Zeile als nebeneinanderstehende Felder darzustellen.<\/p>\n Mit reinen ANSI-SQL ist es auch in der Tat unmöglich, das herauszufinden. Das geht nicht ohne rekursive oder iterative Prozeduren, also entweder eine prozedurale Sprache wie VB(A) oder .Net oder die über den ANSI-Standard hinausgehenden Möglichkeiten, etwa die Sprache T-SQL des Microsoft SQL-Servers.<\/p>\n Damit müssen Sie sich abfinden, da eine offene Hierarchie sich nun mal nicht anders modellieren lässt.<\/p>\n Letzteres ist zugegebenermaßen nicht ganz richtig: Es gibt eine alternative Darstellungsweise in Form einer Teilmengenhierarchie (Nested Sets), die aber die Selbstbezogenheit der Hierarchie auch nicht ignorieren kann.<\/p>\n Einige Dinge sind mit diesem Prinzip erheblich einfacher, insbesondere kommt man ohne Rekursion aus, da die entsprechenden Informationen in der Tabelle gespeichert werden. Anderes ist erheblich schwieriger.<\/p>\n Schlussendlich können Sie weder so noch so die notwendige Arbeit vermeiden. Wir werden diesem Thema zu gegebener Zeit einen eigenen Beitrag widmen. <\/p>\n Entwurf der Tabellen für reflexive offene Hierarchien<\/p>\n Nun sollen Sie noch erfahren, wie Sie die Tabellen für eine reflexive offene Hierarchie entwerfen müssen.<\/p>\n Sie benötigen wie im Vereinsbeispiel eine Tabelle mit Nutzdaten, etwa die Tabelle Person<\/b>. Dazu brauchen Sie jetzt nicht mehrere, sondern nur noch eine Hierarchietabelle, die ausschließlich die Anordnung der Knoten mittels der Schlüssel verwaltet.<\/p>\n Diese Tabelle hat genau zwei Felder: Einen Primärschlüssel (kein AutoWert!) – etwa in Form eines Zahlenfeldes – und ein Fremdschlüsselfeld vom gleichen Typ. Letzteres steht auf Eingabe erforderlich <\/b>und muss Duplikate zulassen.<\/p>\n Das Primärschlüsselfeld steht dabei für den Kindknoten, das Fremdschlüsselfeld für den Elternknoten.<\/p>\n Betrachten Sie noch einmal Abb. 3: 4 <\/b>ist also Kind von 1 <\/b>und Elter von 9<\/b>. Welche Eigenschaften (Name, Gewicht, Datum et cetera) diese Elemente unabhängig von ihrer Stellung in der Hierarchie haben, steht in der Nutzdatentabelle unter dem jeweiligen Schlüssel, der ruhig als AutoWert ausgeführt sein kann.<\/p>\n Sowohl der Kindschlüssel als auch der Elternschlüssel müssen auf diese Nutzdatentabelle bezogen sein. Analog zum Vereinsbeispiel ergibt sich das Schema aus Bild 5: Die Nutzdatentabelle steht als oberstes Glied der Hierarchie in einer 1:n-Beziehung zum Elternschlüssel der Hierarchietabelle. Den Abschluss bildet noch einmal die Nutzdatentabelle, diesmal als Master in einer 1:1-Beziehung zum Kindschlüssel der Hierarchietabelle als Detail.<\/p>\n Bild 5: Reflexive offene Hierarchie<\/span><\/b><\/p>\n Passen Sie auf, dass Sie hierbei nicht in folgende Entwurfsfalle tappen: Sie könnten auf die Idee kommen, die Hierarchiebeziehung ohne eigene Hierarchietabelle direkt von der Nutzdatentabelle auf sich selbst zu erstellen (siehe Bild 6). Das sollten Sie nicht versuchen! Da die Wurzelelemente keine Eltern haben, bliebe hier das Fremdschlüsselfeld leer (siehe Bild 7). Dann kann auf dieses Feld aber nicht mehr wie gewünscht ein Eingabezwang gelegt werden. Die herausgetrennte Hierarchietabelle umgeht dieses Problem. Wurzeln werden beim Abfragen leicht daran erkannt, dass sie im Fremdschlüssel vorkommen, aber nicht im Primärschlüssel.<\/p>\n Bild 6: Falsche Selbstverknüpfung<\/span><\/b><\/p>\n Bild 7: Verbotene Nullwerte bei Selbstverknüpfung<\/span><\/b><\/p>\n Allerdings ist auch der vorgeschlagene Entwurf mit einer eigenständigen Hierarchietabelle nicht völlig problemfrei. Sie können hier zwar erzwingen, dass das Fremdschlüsselfeld in der Hierarchietabelle ausgefüllt wird, aber jeder Datensatz, der in der Nutzdatentabelle erfasst wird, gilt so lange als Wurzelelement, wie ihm in der Hierarchietabelle kein Elter zugeordnet wird.<\/p>\n Sie müssen also den Benutzer in geeigneter Weise zwingen, neue Datensätze einem Elter zuzuordnen oder bewusst zu entscheiden, dass ein neues Wurzelelement vorliegt. Letztlich müsste auch hier wieder ein Datenbanktrigger zum Einsatz kommen, den Sie in Access durch clientseitige Programmierung ersetzen müssen.<\/p>\n Dabei müssen Sie sicherstellen, dass ein neuer Datensatz, wenn er nicht eine Wurzel darstellen soll, mit seinem Primärschlüssel in das Primärschlüsselfeld der Hierarchietabelle übernommen wird. Die Angabe eines Elters erzwingt dann die Eingabepflicht im Fremdschlüsselfeld.<\/p>\n Die reine Struktur-Hierarchie ist ein gelegentlicher Spezialfall der reflexiven Hierarchie. Hier reduzieren sich die Nutzdaten oft gerade mal auf einen Namen. Die Knoten der Hierarchie als solche sind, von ihrer ordnenden Eigenschaft abgesehen, eigentlich völlig uninteressant. Sie dienen nur als eine Art Registratur für die interessierenden Objekte, die 1:n den Endknoten untergeordnet sind und erheblich andere – meist auch mehr – Eigenschaften als die Knoten haben.<\/p>\n Kommt Ihnen dies bekannt vor Ja, die Ordnerhierarchie von Windows. Die Ordner selbst sind ziemlich uninteressant und haben nur den Zweck, die Ablage der eigentlich wichtigen Objekte, der Dateien, zu strukturieren.<\/p>\n Ein anderes Beispiel können Kontenhierarchien sein, die dazu dienen, Budgets von Kostenstellen nach einem bestimmten Begriffsraster zu gruppieren. Es gibt Fälle, da haben solche Konten gerade mal einen Namen und eine dynamisch zu berechnende Knotensumme und dienen ansonsten nur der Bündelung von Kostenstellen.<\/p>\n Die Modellierung dieser Hierarchieart setzt sich aus den zuvor vorgestellten Hierarchiearten zusammen: Einer offenen reflexiven Hierarchie, an die eine geschlossene irreflexive Hierarchie angehängt ist (siehe Bild 8).<\/p>\n Bild 8: Strukturhierarchie<\/span><\/b><\/p>\n Komplexe Hierarchien<\/p>\n Die bisher gezeigten Strukturen können Sie natürlich beliebig kombinieren. Beginnen Sie mit Rechnern, die Festplatten enthalten. Diese wiederum enthalten Partitionen. Sie haben also zunächst eine fixe dreistufige Hierarchie aus unterschiedlichen Objekttypen. Auf den Partitionen haben Sie eine offene Ordnerhierarchie, an die sich noch einmal eine feste Minihierarchie mit Dateien anhängt. Da zwar alle Dateien gemeinsame Eigenschaften haben, aber es auch typspezifische Eigenschaften gibt, kommt an das Ende der allgemeinen Dateitabelle noch einmal ein Bündel Spezialisierungstabellen einer Begriffshierarchie.<\/p>\n Nach dem bisher Gesagten könnte man fast glauben, es sei sowieso alles hierarchisch. Das ist aber keineswegs so. Eine Struktur, die gerne als Beispiel für eine Hierarchie herangezogen wird, die Stückliste, ist gar keine. Da Stücklisten in der Regel auf Objektklassen (zum Beispiel Normteile; es gibt viele Schrauben M8) aufbauen, handelt es sich nicht um eine Baumstruktur, sondern um eine reflexive Netzstruktur. Typischerweise entstehen Stücklisten dann auch aus m:n-Beziehungen und nicht aus 1:n-Beziehungen.<\/p>\n Sie haben nun gesehen, wie Sie die verschiedenen Arten von Hierarchien unterscheiden und modellieren können. Im nächsten Beitrag der Reihe wird es um Abfragetechniken und die erforderliche Programmierung gehen. Danach lernen Sie verschiedene Möglichkeiten kennen, Ihren Benutzern die hierarchischen Daten zu präsentieren.<\/p>\n","protected":false},"excerpt":{"rendered":" Hierarchieartige Strukturen spielen im Datenbankentwurf immer wieder eine große Rolle. Bereits eine schlichte 1:n-Beziehung stellt eine Hierarchie dar. Um in der Dateneingabe einerseits flexibel zu bleiben, aber dennoch Benutzerfehler schon durch den Entwurf zu verhindern, muss man einige Dinge beachten. In diesem Beitrag zeigen wir die Fallstricke beim Entwurf hierarchischer Datenstrukturen auf.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[66012008,662008,44000021],"tags":[],"class_list":["post-55000555","post","type-post","status-publish","format-standard","hentry","category-66012008","category-662008","category-Tabellen_und_Datenmodellierung"],"yoast_head":"\nObjekthierarchien<\/h2>\n
Arten von Objekthierarchien<\/h2>\n
\n
![\"r.TIF\"](\"..\/fileadmin\/_temp_\/2008_01\/Hierarchien-web-images\/r_opt.jpeg\")
<\/p>\nImplementieren der Hierarchiearten<\/h2>\n
![\"n.TIF\"](\"..\/fileadmin\/_temp_\/2008_01\/Hierarchien-web-images\/n_opt.jpeg\")
<\/p>\n![\"H.TIF\"](\"..\/fileadmin\/_temp_\/2008_01\/Hierarchien-web-images\/H_opt.jpeg\")
<\/p>\nReflexive offene Hierarchie<\/h2>\n
![\"r2.tif\"](\"..\/fileadmin\/_temp_\/2008_01\/Hierarchien-web-images\/r2_opt.jpeg\")
<\/p>\n![\"Falsch1.tif\"](\"..\/fileadmin\/_temp_\/2008_01\/Hierarchien-web-images\/Falsch1_opt.jpeg\")
<\/p>\n![\"Falsch2.tif\"](\"..\/fileadmin\/_temp_\/2008_01\/Hierarchien-web-images\/Falsch2_opt.jpeg\")
<\/p>\n![\"r2b.tif\"](\"..\/fileadmin\/_temp_\/2008_01\/Hierarchien-web-images\/r2b_opt.jpeg\")
<\/p>\nKeine Hierarchie<\/h2>\n
Zusammenfassung und Ausblick<\/h2>\n