<\/p>\n
André Minhorst, Duisburg<\/b><\/p>\n
Grundlage für die Entwicklung einer professionellen Datenbankanwendung ist eine entsprechende Modellierung des Datenmodells. Die Musterlösungen und Beispieldatenbanken von Access im Unternehmen versuchen, dieser Voraussetzung zu entsprechen. Im vorliegenden Beitrag erfahren Sie nicht nur, welche Grundlagen hinter der Datenmodellierung professioneller Datenbanken stehen, sondern lernen auch die wichtigsten Begriffe im Zusammenhang mit relationalen Datenbanken, referentieller Integrität und Beziehungen zwischen Tabellen kennen.<\/b><\/p>\n
Eifrige Leser von Access im Unternehmen haben die vorgestellten Musterlösungen und Beispiele nicht kommentarlos hingenommen, sondern auch den dazugehörenden Beitrag gelesen und nachvollzogen.<\/p>\n
Da die theoretischen Hintergründe für die jeweilige Gestaltung des zugrunde liegenden Datenmodells nicht in jedem Beitrag komplett aufgeführt werden können, sollen die Grundlagen für professionelle Datenmodellierung an dieser Stelle einmal umfassend vorgestellt werden.<\/p>\n
Im vorliegenden Beitrag lernen Sie die ersten drei Normalformen kennen, die dem ersten, provisorischen Entwurf eines Datenmodells den richtigen Kick geben, und Sie erfahren die Grundlagen für die unterschiedlichen Beziehungstypen und finden eine Erklärung der wichtigsten Begriffe der Datenmodellierung wie Master- und Detailtabelle oder Primär- und Fremdschlüssel.<\/p>\n
Die Nordwind-Datenbank, die zu jeder der hier besprochenen Access-Versionen gehört und standardmäßig installiert wird, bietet Beispiele für alle gebräuchlichen Arten von Beziehungen. Daher gelten die Beispiele des vorliegenden Beitrags für das Datenmodell – also die Tabellen und Beziehungen – dieser Datenbank.<\/p>\n
Falls Sie nicht wissen, wo Sie die Nordwind-Datenbank finden sollen, lassen Sie sich vom Windows Explorer helfen und suchen Sie im Office-Ordner nach der Datei Nordwind.mdb.<\/p>\n
„Warum gibt überhaupt Beziehungen“ Das fragt sichso mancher Anwender, der alle für seine Arbeit wichtigen Daten in einer einzigen Tabelle speichert. Alles auf einen Blick – was will man denn noch mehr<\/p>\n
Die folgenden Kapitel beschreiben die theoretischen Grundlagen für den Entwurf des Datenmodells einer relationalen Datenbank. Deren Umsetzung setzt voraus, dass Sie sich bereits mit dem Erstellen von Tabellen sowie der Definition von Beziehungen auskennen. <\/p>\n
Davon abgesehen, dass sich Datenmodelle komplexer Anwendungen bestimmt nicht übersichtlich in einer einzigen Tabelle darstellen lassen, führt die oft praktizierte Unart, völlig unterschiedliche Daten in einer einzigen Tabelle unterzubringen, zu Redundanzen und in deren Folge zu Inkonsistenzen.<\/p>\n
Um dies zu vermeiden, basieren die Datenmodelle der meisten relationalen Datenbanken auf den 1972 von Edgar F. Codd im Artikel „Further normalization of the data base relational model“ veröffentlichten Normalformen. Die Zusammenfassung ersten drei, für relationale Datenbanken besonders wichtigen Normalformen finden Sie in den folgenden Abschnitten.<\/p>\n
Tabellen beinhalten oft Felder, die nicht nur eine, sondern mehrere Informationen speichern. Viele Anwender bringen beispielsweise gerne Vor- und Nachnamen in einem einzigen Feld unter (wie z. B. beim Feld Kontaktperson der Tabelle Kunden in der Nordwind-Datenbank). Probleme sind vorprogrammiert – schon die getrennte Sortierung nach Vor- oder Nachname ist nicht ohne Weiteres möglich.<\/p>\n
Ein weiteres Beispiel ist das Speichern von mehreren Informationen gleicher Art in einem einzigen Feld – z. B. das Speichern aller Untergebenen eines Mitarbeiters.<\/p>\n
Nicht-Profis umgehen mit solchen Methoden gerne die Erstellung weiterer Beziehungen und Tabellen (und damit vermeintliche Mehrarbeit), verursachen damit aber letztlich erheblichen Mehraufwand.<\/p>\n
![](\"..\/fileadmin\/_temp_\/{AA84A517-5D50-4900-B700-91073AFBB02B}\/pic001.png\")
<\/p>\n
<\/b><\/p>\n
Bild 1: Aufsplittung eines Feldes in seine elementaren Informationen<\/span><\/b><\/p>\n Die erste Normalform fordert daher, jede relevante Information auch in einzelnen Feldern zu speichern (siehe Bild 1).<\/p>\n Außerdem soll eine Tabelle nicht mehrere gleichartige Daten in unterschiedlichen Feldern enthalten – also in einer Kunden-Tabelle z. B. nicht mehrere Felder für unterschiedliche Kontaktpersonen bereitstellen, sondern die Kontaktpersonen in eine Tabelle auslagern und die Tabellen entsprechend verknüpfen.<\/p>\n Eine weitere Forderung der ersten Normalform ist, dass die Felder einer Tabelle sich lediglich auf die Beschreibung eines einzigen Objekts beziehen – also z. B. auf einen Artikel, einen Kunden, einen Lieferanten oder ähnliche reale Objekte.<\/p>\n Die letzte Forderung ist, auch sich wiederholende Feldinhalte in verknüpfte Tabellen auszulagern. Dies ist sinnvoll, wenn der Inhalt des Feldes aus einer überschaubaren Anzahl von Werten besteht – z. B. den unterschiedlichen Anredeformen für Personen wie Herr, Frau usw. Bei nicht überschaubaren Mengen von möglichen Werten wie z. B. Städtenamen in Adresstabellen ist die Anwendung der ersten Normalform allerdings nicht uneingeschränkt sinnvoll.<\/p>\n Die Nordwind-Datenbank bietet z. B. die Möglichkeit, die Einträge des Feldes Position in der Tabelle Personal in eine weitere Tabelle namens Positionen auszulagern (siehe Bild 2).<\/p>\n Die zweite Normalform setzt das Bestehen der ersten Normalform voraus und besagt weiterhin, dass jede Tabelle einen Primärschlüssel haben muss und dass alle weiteren Felder nur von diesem einen Primärschlüssel funktionell abhängig sind.<\/p>\n Der Primärschlüssel ist ein Feld oder eine Kombination von mehreren Feldern. Er darf genau einmal in einer Tabelle vorkommen.<\/p>\n Die Bedeutung funktionaler Abhängigkeit lässt sich leicht am Beispiel eines Artikels erläutern: Eine Artikeltabelle enthält einen eindeutigen Index – in der Regel die Artikelnummer – und einige weitere Informationen wie die Bezeichnung des Artikels, den Preis, den aktuellen Bestand usw. Alle diese Informationen beziehen sich genau auf den Artikel mit der jeweiligen Artikelnummer – und sind damit von dem Primärschlüssel Artikel-Nr abhängig.<\/p>\n <\/b><\/p>\n Bild 2: Auslagerung der Position in eine verknüpfte Tabelle<\/span><\/b><\/p>\n <\/b><\/p>\n Bild 3: Auslagern von nicht-transitiven Abhängigkeiten<\/span><\/b><\/p>\n In der Praxis verhindern Sie auf diese Weise, dass sich mehrere völlig gleiche Datensätze in derselben Tabelle befinden.<\/p>\n Die dritte Normalform setzt das Bestehen der zweiten Normalform voraus und verlangt außerdem die Beseitigung sämtlicher nicht-transitiver Abhängigkeiten.<\/p>\n Nicht-transitive Abhängigkeiten sind funktionale Abhängigkeiten zwischen Feldern der Tabelle, von denen keines der Primärschlüssel dieser Tabelle ist. Das folgende Beispiel verdeutlicht den Zusammenhang:<\/p>\n Möglicherweise enthält die Tabelle aus dem vorherigen Beispiel auch Informationen über den Lieferanten des Artikels in Form der Lieferanten-ID, des Lieferantennamens und einigen weiteren Informationen wie z. B. Adressdaten des Lieferanten (siehe Bild 3).<\/p>\n <\/p>\n Wenn Sie sich die Lieferanten-ID als Primärschlüssel für die Lieferantendaten vorstellen, dann sind alle weiteren Lieferantendaten funktional abhängig von der Lieferanten-ID – nicht aber vom eigentlichen Primärschlüssel der Artikeltabelle.<\/p>\n Zur Durchsetzung der dritten Normalform müssten Sie also die Lieferantendaten komplett in eine weitere Tabelle ausgliedern (wie es in der Nordwind-Datenbank der Fall ist) und nur den Primärschlüssel der Lieferantentabelle, also die Lieferanten-ID, als Fremdschlüssel in die Artikeltabelle aufnehmen.<\/p>\n Die nachfolgende Auflistung enthält einige wichtige Vorteile der Normalisierung des Datenmodells:<\/p>\n Die drei wesentlichen Vorteile lassen sich am bereits genannten Beispiel beschreiben, bei dem aus einer Artikeltabelle inklusive detaillierter Lieferantendaten zwei Tabellen mit getrennten Artikel- und Lieferantendaten entstehen.<\/p>\n Die Artikeltabelle besteht nur noch aus Feldern, die direkt der Beschreibung des Artikels dienen. Dazu gehört auch ein Feld mit dem Kürzel des Lieferanten als Fremdschlüsselfeld. Dieses Feld beinhaltet einen der in der Lieferantentabelle verwendeten Primärschlüssel und dient damit der Zuordnung des Lieferanten zu dem Artikel. Sie können also jeden eingegebenen Lieferantendatensatz beliebig vielen Artikeldatensätzen zuordnen, ohne die Daten für jeden Artikel neu eingeben zu müssen.<\/p>\n Wenn Sie die Artikeltabelle vor der Abspaltung der Lieferantendaten ansehen, können Sie sich sicher vorstellen, dass einige Lieferanten mehrere Artikel liefern. Die Tabelle enthält dann die gleichen Daten direkt mehrfach – ein typischer Fall einer Redundanz. Durch die Abspaltung solcher Daten verhindern Sie solche Redundanzen.<\/p>\n Tabellen mit redundanten Daten bergen immer das Risiko der Entstehung von Inkonsistenzen. Eine Inkonsistenz liegt beispielsweise vor, wenn einer von zwei Datensätzen mit redundanten – also eigentlich gleichen – Daten so geändert wird, dass die redundanten Daten nicht mehr gleich sind. Wenn keine redundanten Daten vorkommen, droht die Gefahr der Bildung von Inkonsistenzen erst gar nicht.<\/p>\n Die Wahrung referentieller Integrität bedeutet die Einhaltung einer einzigen Regel: Jeder Fremdschlüsselwert eines Datensatzes einer Tabelle muss einem Primärschlüsselwert eines Datensatzes der verknüpften Tabelle entsprechen.<\/p>\n Um diese Regel mit Leben zu füllen, lernen Sie zunächst die beiden Schlüsselarten Primärschlüssel und Fremdschlüssel kennen und erfahren anschließend, wie sich die Anwendung dieser Regel im praktischen Einsatz einer Datenbank auswirkt.<\/p>\n Im Rahmen des relationalen Datenmodells verwenden Sie zwei unterschiedliche Schlüsselarten, um Beziehungen zu realisieren. Dabei handelt es sich um Primär- und Fremdschlüssel.<\/p>\n Primärschlüssel dienen unter anderem der eindeutigen Definition eines Datensatzes. Sicher gibt es Tabellen, deren Feldzusammensetzung ein Auftauchen zweier identischer Datensätze nahezu ausschließt.<\/p>\n Dennoch wäre es schwierig, auf einfache Weise auf einen bestimmten Datensatz Bezug zu nehmen. Daher sollte jede Tabelle ein Feld mit eindeutigem Inhalt als Primärindex bereitstellen.<\/p>\n Fremdschlüssel dienen der Verknüpfung von Datensätzen unterschiedlicher Tabellen. Dabei enthält das Fremdschlüsselfeld der einen Tabelle den Wert des Primärschlüsselfeldes des gewünschten Datensatzes der anderen Tabelle. Im Beispiel der Artikel- und der Lieferantentabelle enthält die Artikeltabelle ein Fremdschlüsselfeld namens Lieferanten-Nr, das den Inhalt des Feldes Lieferanten-Nr des verknüpften Datensatzes der Lieferantentabelle enthält.<\/p>\n Eine relationale Beziehung basiert in der Regel auf dem Vorhandensein von zwei Tabellen. Durch die Natur ihrer unterschiedlichen Funktionen besitzen diese beiden Tabellenarten auch verschiedene Bezeichnungen: Sie werden z. B. Master- und Detailtabelle, Parent- und Childtabelle oder Vater- und Kindtabelle genannt.<\/p>\n Dabei ist die Master-, Parent- bzw. Vatertabelle immer diejenige Tabelle, deren Primärschlüsselfeld an der Beziehung beteiligt ist. Die Detail-, Child- bzw. Kindtabelle besitzt ein Fremdschlüsselfeld, das mit dem jeweiligen Inhalt des Primärschlüsselfeldes des Datensatzes der Master-, Parent- bzw. Vatertabelle gefüllt ist.<\/p>\n Im Folgenden soll – um die Begriffsvielfalt ein wenig einzuschränken – nur noch von Master- und Detailtabelle die Rede sein. <\/p>\n Das Datenbankmanagementsystem selbst – also z. B. Microsoft Access – sorgt für die Durchsetzung der zu Beginn des Kapitels genannten Regel, sofern Sie dies für eine Beziehung festgelegt haben.<\/p>\n Die Kontrolle über die referentielle Integrität tritt in vier Fällen in Aktion:<\/p>\n Falls einer der genannten Fälle für eine Beziehung mit definierter referentieller Integrität eintritt, führt Access eine Aktion entsprechend den für die referentielle Integrität festgelegten Eigenschaften aus.<\/p>\n In der Grundeinstellung erscheint lediglich eine entsprechende Fehlermeldung, die mit dem Abbruch der gewünschten Datenoperation endet. Sie können allerdings auch festlegen, dass Access beispielsweise beim Löschen eines Datensatzes der Mastertabelle alle mit diesem Datensatz verknüpften Datensätze der Detailtabelle automatisch mitlöscht (Löschweitergabe). Das ist beispielsweise beim Löschen von Bestellungen und den entsprechenden Detaildaten sinnvoll.<\/p>\n Mit einer weiteren Einstellung können Sie festlegen, dass Access bei einer änderung des Wertes des Primärschlüsselfeldes eines Datensatzes der Mastertabelle direkt den Inhalt des entsprechenden Fremdschlüsselfeldes der Detailtabelle aktualisiert (Aktualisierungsweitergabe).<\/p>\n Die im Rahmen der Normalisierung eines Datenmodells durchgeführten Maßnahmen führen in der Regel zu einem Datenmodell, dessen Tabellen sehr elementare Informationen zu den jeweilig beschriebenen Objekten beinhalten.<\/p>\n Dafür enthält das Datenmodell mit wachsender Anzahl von Tabellen eine entsprechend wachsende Anzahl von Beziehungen zwischen diesen Tabellen, die unterschiedliche Ausprägungen aufweisen können. In den folgenden Abschnitten erhalten Sie Informationen über die einzelnen Beziehungsarten.<\/p>\n 1:1-Beziehungen verknüpfen die Primärschlüsselfelder zweier Tabellen miteinander. Diese Beziehungsart wird praktisch nie verwendet.<\/p>\n Einer der wenigen Gründe für den Einsatz einer solchen Beziehung – und damit der Aufteilung einer Tabelle in zwei per 1:1-Beziehung verknüpfte Tabellen – ist die Verwendung von mehr als 256 Feldern.<\/p>\n Dies ist unter Access nicht möglich, lässt aber auch mit hoher Wahrscheinlichkeit auf Fehler bei der Datenmodellierung schließen.<\/p>\n Ein weiterer Grund sind Felder mit großen Inhalten – z. B. Felder, die mit Bilddateien gefüllt werden sollen. Wenn Sie solche Felder aus der eigentlichen Tabelle in eine per 1:1-Beziehung verknüpfte Tabelle auslagern, muss das Datenbanksystem keinen unnötigen Platz für Felder reservieren, die möglicherweise gar keine Daten enthalten. Für Access-Datenbanken ist dieser Fall allerdings nicht relevant, da hier ohnehin für keinen Datentyp Speicherplatz reserviert wird. Anders ist es beispielsweise beim Microsoft SQL Server.<\/p>\n Es gibt noch eine weitere Anwendung für 1:1-Beziehungen. Welche das ist und wie Sie mit solchen Beziehungen umgehen, erfahren Sie im Beitrag 1:1-Beziehungen in der Praxis der kommenden Ausgabe von Access im Unternehmen. <\/p>\n 1:n-Beziehungen beschreiben Verknüpfungen zwischen zwei Tabellen, die über das Primärschlüsselfeld der einen und ein Fremdschlüsselfeld der zweiten Tabelle miteinander verknüpft sind.<\/p>\n Beispiele für diese Beziehungsart sind die bereits erwähnte Beziehung zwischen Artikel und Lieferant (siehe Bild 4), Projekt und Kunde usw.<\/p>\n Wichtiges Merkmal dieser Beziehungsart ist, dass beide beteiligten Tabellen eigene Objekte repräsentieren. Dies unterscheidet die 1:n-Beziehung von der nachfolgend beschriebenen n:1-Beziehung.<\/p>\n <\/b><\/p>\n Bild 4: 1:n-Beziehung zwischen Artikeln und Lieferanten<\/span><\/b><\/p>\n <\/b><\/p>\n Bild 5: Beispiele für n:1-Beziehungen<\/span><\/b><\/p>\n n:1-Beziehungen sind formal wie 1:n-Beziehungen zu behandeln. Dabei dient der Inhalt der Mastertabelle jedoch nicht der Beschreibung eines realen Objektes.<\/p>\n Die Tabelle ist vielmehr das Produkt der Auslagerung von sich wiederholenden Feldinhalten wie z. B. Anredeformen (Herr, Frau usw.) oder anderen objektspezifischen Eigenschaften und enthält neben dem Primärindexfeld lediglich den eigentlichen Inhalt. Andere Beispiele sind Zahlungsart, Tätigkeitsart etc. (siehe Bild 5).<\/p>\n m:n-Beziehungen verknüpfen wie die 1:1-Beziehung die Primärschlüsselfelder zweier Tabellen miteinander – allerdings nicht direkt, sondern über eine Verknüpfungstabelle.<\/p>\n Die Verknüpfungstabelle besteht aus zwei Fremdschlüsselfeldern, die als Werte die Primärschlüsselwerte der zu verknüpfenden Datensätze der beiden Tabellen enthalten.<\/p>\n Wenn Sie bei den beiden Begriffen Primärschlüssel und Fremdschlüssel hellhörig werden, haben Sie offensichtlich sorgfältig gelesen: In der Tat besteht die m:n-Beziehung aus zwei 1:n-Beziehungen, die eine gemeinsame Detailtabelle haben.<\/p>\n Um in dieser Detailtabelle Redundanzen zu vermeiden, legen Sie einen zusammengesetzten, aus den beiden Fremdschlüsselfeldern der Tabelle bestehenden eindeutigen Schlüssel fest (s. Abb. 6).<\/p>\n <\/b><\/p>\n Bild 6: Beispiel einer m:n-Beziehung<\/span><\/b><\/p>\n m:n-Beziehungen müssen allerdings nicht zwangsläufig über eine einzige Verknüpfungstabelle realisiert werden.<\/p>\n Zwischen den betroffenen Tabellen können sich auch mehrere statt einer einzigen Tabelle befinden, die ihrerseits per 1:n-Beziehung miteinander verknüpft sind.<\/p>\n <\/b><\/p>\n Bild 7: Beispiel einer reflexiven Beziehung<\/span><\/b><\/p>\n Reflexive Beziehungen sind prinzipiell 1:n-Beziehungen – mit dem Unterschied, dass Master- und Detailtabelle identisch sind und dass die Festlegung referentieller Integrität nicht möglich ist – zumindest nicht, wenn Sie eine logische reflexive Beziehung aufbauen möchten.<\/p>\n Ein Beispiel ist die Tabelle Personal der Nordwind-Datenbank (siehe Bild 7). Das Fremdschlüsselfeld Vorgesetzte® enthält entweder keinen Wert – was darauf hindeutet, dass der entsprechende Mitarbeiter keinen Vorgesetzten hat – oder es enthält den Inhalt des Primärschlüsselfeldes eines der Datensätze der Tabelle Personal – womit der jeweilige Vorgesetzte festgelegt ist.<\/p>\n Die referentielle Integrität kommt hier allerdings mit der Logik in Konflikt, da zumindest ein Mitarbeiter keinen Vorgesetzten haben kann. Sie können in diesem Fall also keine referentielle Integrität festlegen.<\/p>\n Das bedeutet, dass Sie die Eingabevalidierung durch geeignete Maßnahmen durchführen müssen – zum Beispiel bei der Eingabe der Daten über ein Formular.<\/p>\n Es gibt noch weitere Beziehungsarten, die in der Praxis allerdings wenig Beachtung finden bzw. Ableitungen von den genannten Beziehungsarten sind.<\/p>\n Genau genommen haben Sie mit der m:n-Beziehung ja bereits einen Spezialfall der 1:n-Beziehung kennen gelernt.<\/p>\n Ein weiterer Spezialfall der 1:n-Beziehung ist die n:0-Beziehung – die allerdings aus einem schlechten Datenbankmodell resultiert. Eine n:0-Beziehung tritt auf, wenn ein Feld der Detailtabelle als Wert den Primärschlüssel der Mastertabelle erwartet – z. B. für die Auswahl einer Anrede – und kein Wert der Tabelle ausgewählt wird, der Inhalt des Feldes also Null ist. Dies kann allerdings in den meisten Fällen durch das Anlegen eines Wertes wie z. B. Sonstige in der verknüpften Mastertabelle umgangen werden.<\/p>\n","protected":false},"excerpt":{"rendered":" Grundlage für die Entwicklung einer professionellen Datenbankanwendung ist eine entsprechende Modellierung des Datenmodells. Die Musterlösungen und Beispieldatenbanken von Access im Unternehmen versuchen, dieser Voraussetzung zu entsprechen. Im vorliegenden Beitrag erfahren Sie nicht nur, welche Grundlagen hinter der Datenmodellierung professioneller Datenbanken stehen, sondern lernen auch die wichtigsten Begriffe im Zusammenhang mit relationalen Datenbanken, referentieller Integrität und Beziehungen zwischen Tabellen kennen.<\/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":[66012003,662003,44000021],"tags":[],"class_list":["post-55000097","post","type-post","status-publish","format-standard","hentry","category-66012003","category-662003","category-Tabellen_und_Datenmodellierung"],"yoast_head":"\nDie zweite Normalform<\/h2>\n
![](\"..\/fileadmin\/_temp_\/{AA84A517-5D50-4900-B700-91073AFBB02B}\/pic002.png\")
<\/p>\n![](\"..\/fileadmin\/_temp_\/{AA84A517-5D50-4900-B700-91073AFBB02B}\/pic003.png\")
<\/p>\nDie dritte Normalform<\/h2>\n
Vorteile der Normalisierung des Datenmodells<\/h2>\n
Einmalige Eingabe von Daten<\/h3>\n
Vermeidung von Redundanzen<\/h3>\n
Vermeidung von Inkonsistenzen<\/h3>\n
Schlüsselarten<\/h2>\n
Primärschlüssel<\/h3>\n
Fremdschlüssel<\/h3>\n
Bezeichnungen verknüpfter Tabellen<\/h3>\n
Hinweis<\/h3>\n
Referentielle Integrität in der Praxis<\/h2>\n
1:1-Beziehungen<\/h2>\n
Hinweis<\/h3>\n
1:n-Beziehungen<\/h2>\n
![](\"..\/fileadmin\/_temp_\/{AA84A517-5D50-4900-B700-91073AFBB02B}\/pic004.png\")
<\/p>\n![](\"..\/fileadmin\/_temp_\/{AA84A517-5D50-4900-B700-91073AFBB02B}\/pic005.png\")
<\/p>\nn:1-Beziehungen<\/h2>\n
m:n-Beziehungen<\/h2>\n
![](\"..\/fileadmin\/_temp_\/{AA84A517-5D50-4900-B700-91073AFBB02B}\/pic006.png\")
<\/p>\n![](\"..\/fileadmin\/_temp_\/{AA84A517-5D50-4900-B700-91073AFBB02B}\/pic007.png\")
<\/p>\nReflexive Beziehungen<\/h2>\n
Weitere Beziehungsarten<\/h2>\n