Rekursive Tabellen

Ihr Kumpel, der Gemeinderat, kommt auf die geniale Idee, für alle Bewohner des Dorfes einen Stammbaum anzulegen, und betreut Sie als Programmierer mit der Aufgabe, diese in einer Datenbank anzulegen, um das anschließend zu Papier bringen zu können. Das kann kein so kompliziertes Unterfangen sein, denken Sie, und machen sich frohgemut an die Arbeit. Das Datenmodell ist der erste Schritt, der zu bewältigen ist…

Beispieldatenbank

Die Beispiele dieses Artikels finden Sie in der Datenbank 1509_RekursiveTabellen.accdb

Eltern, Kinder, Enkel im Datenmodell

Es scheint gar nicht schwer zu sein. Es muss einfach eine Tabelle für die Eltern her, die einen Primärschlüssel aufweist. Dann eine für die Kinder, in der die Datensätze über einen Fremdschlüssel ElterID auf die Datensätze der Eltern verweisen. Und schließlich gibt es noch Enkel, deren Tabelle ähnlich aufgebaut ist, wie die der Kinder. Im Ergebnis erhalten Sie das Beziehungslayout aus Bild 1. Die Tabellen sind über Referenzielle Integrität eindeutig miteinander verknüpft, jeweils Indizes auf das Feld ElterID gelegt, und die eigentlichen Einträge der Daten bestehen aus dem Feld Person für den Namen der Bürgers und dem Feld mw, welches sein Geschlecht wiedergeben soll. Flux die Daten aus der Excel-Grundlage in die Tabellen eingepflegt, und schon lässt sich dank der automatischen Unterdatenblätter von Access – ein Feature, welches hier wirklich einmal sinnvoll zum Einsatz kommt – ein Baum ausklappen, wie in Bild 2. Spätestens hier kommen Ihnen Bedenken wegen der etwaigen Urenkel oder gar noch weiterer Abkömmlinge. Sollten noch weitere Tabellen für diese angelegt werden Und wie sieht es später mit der Auswertung dieser Struktur aus Werden die dafür benötigten Abfragen da nicht recht umfangreich und unübersichtlich

Bild 1: Der erste Enwurf des Datenmodells für die Stammbaumdatenbank mit allen Tabellen und deren Beziehungen

Bild 2: Nach dem öffnen der Tabelle tblEltern lassen sich die automatisch generierten Unterdatenblätter mit den Kindern und Enkeln ausklappen

Es geht natürlich auch anders! Sie kommen tatsächlich mit nur einer einzigen Tabelle aus, in der rekursiv eine Beziehung zwischen den Datensätzen für Eltern und Kinder hergestellt wird

Rekursive Tabellen

Das Grundprinzip ist ganz einfach. Eine rekursive Tabelle muss einen Primärschlüssel aufweisen, der jeden Datensatz eindeutig identifiziert. Und zusätzlich ein weiteres indiziertes Feld, welches als Fremdschlüsselverweis für den Primärschlüssel dient. Dazu kommen dann die eigentlichen Inhalte der Tabelle. In Bild 3 ist das für die Tabelle tblElternKind realisiert. Die ID ist als Primärschlüssel vom Typ Autowert. ParentID vom Typ Long enthält dann jeweils einen Wert, der auf einen anderen Datensatz mit dieser ID verweist. Person und mw sind die eigentlichen Inhalte der Tabelle. Ingbert in Datensatz 7 hat die ParentID 60, was besagt, dass sein Elter weiter unten im Datensatz mit eben dieser ID 60 zu finden ist. Das wäre dann, außerhalb des in Bild 3 sichtbaren Bereichs, Günter. Scrollen Sie zu Günter, so kann es sein, dass dieser ebenfalls eine ParentID enthält, mithin also etwa ein Kind von Klara wäre, und somit Ingbert ein Enkel von Klara. Tatsächlich ist aber das Feld ParentID von Günter leer, was besagt, dass in der Datenbank kein Elter von ihm verzeichnet ist. Günter wäre ein Root-Datensatz der rekursiven Tabelle.

Bild 3: Die Eltern-Kind-Tabelle in Datenblattansicht mit dem Verweisfeld ParentID

Mehr gibt es dazu eigentlich nicht zu sagen. Immer dann, wenn Datensätze hierarchisch voneinander abhängen und die Zahl der Kindelemente, also der Unterebenen, nicht bekannt ist, kommt so eine rekursive Struktur infrage.

Sie finden in jeder Access-Datenbank dafür ein Beispiel. Die Systemtabelle MSysObjects enthält rekursive Einträge. Auch sie hat den Primärschlüssel ID und das Verweisfeld ParentID. öffnen Sie sie einmal in der Beispieldatenbank, was voraussetzt, dass in den Optionen des Navigationsbereichs der Eintrag Systemobjekte anzeigen aktiviert ist. Unter der Name Spalte Name suchen Sie die Tabelle tblElternKind. Im Datensatz finden Sie unter ParentID den Wert 251658241.

Nun navigieren Sie zum Datensatz mit dieser ID. Dort steht unter Name Tables. Das ist der Container für alle Tabellen der Datenbank. Er selbst hat die ParentID 251658240, was allerdings zu keinem gültigen Datensatz in der Tabelle führt…

Ein anderes Beispiel wäre die Systemtabelle MSysAccessStorage, welche alle Objekte der Datenbank enthält, außer den Tabellen und Abfragen. Sie ist noch stärker verschachtelt und hat als Root-Datensatz die ID 1 für den bezeichnenden Eintrag MSysAccessStorage_ROOT.

Sie sparen sich mit dieser rekursiven Tabelle also eine Menge Arbeit für die Stammbaumdatenbank ein. Doch wie sieht es nun mit der Darstellung des Baums aus Gab es im ersten Entwurf noch voneinander abhängige Tabellen, die als Unterdatenblätter der Elterntabelle eingeblendet werden konnten, so scheint diese Möglichkeit bei nur einer Tabelle nunmehr auszuscheiden.

Anzeige rekursiver Tabellen

Tatsächlich kommt aber nur Access von sich aus nicht auf die Idee, in einer Tabelle als Unterdatenblatt eben die gleiche Tabelle einzutragen. Doch genau dies ist machbar. Nehmen Sie den Entwurf der Tabelle tblElternKind in Bild 4. Dort ist ein Ausschnitt des Eigenschaftenblatts der Tabelle eingeblendet. Als Unterdatenblatt ist die tblElternKind selbst eingetragen und die Verknüpfung über ParentID und ID gewährleistet. Nachdem Sie diese änderung abgespeichert haben, zeigt das Datenblatt die bekannten Plus-Symbole und klappt zu Eltern tatsächlich die Kinder aus, diese wiederum die Enkel, diese die Urenkel, und so fort. Access erzeugt hier also für jede Unterebene eine neue Instanz der Tabelle und verknüpft diese im Hintergrund mit dem Datensatz der übergeordneten Instanz.

Bild 4: Die Eltern-Kind-Tabelle im Entwurf mit einem Teil des Eigenschaftenblatts

Username or Email

Passwort

Angemeldet bleiben