1:1-Beziehungen können für eine ganze Reihe von Anwendungzwecken sinnvoll sein. Sie können damit beispielsweise die Liefer- und\/oder die Rechnungsanschrift für einen Kundendatensatz in eigenen Tabellen speichern, um so verschiedene Ziele zu erreichen: beispielsweise die Anzahl der Felder je Tabelle zu verringern, verschiedene Teile der Daten mit unterschiedlichen Berechtigungen versehen und so weiter. In diesem Artikel schauen wir uns an, wie Sie eine 1:1-Beziehung herstellen und welche Stolpersteine es zu beachten gibt.<\/p>\n
Beispieldatenbank<\/h2>\n
Die Beispiele dieses Artikels finden Sie in der Datenbank 1806_11Beziehung.accdb<\/b>.<\/p>\n
Aufbau von 1:1-Beziehungen<\/h2>\n
Eine 1:1-Beziehung besteht aus zwei Tabellen und ist im Prinzip eine eingeschränkte 1:n-Beziehung. Bei der 1:n-Beziehung können Sie dem Datensatz der Tabelle mit dem Primärschlüsselfeld der Beziehung, also etwa tblKunden<\/b>, keinen, einen oder mehrere Datensätze der Tabelle mit dem Fremdschlüsselfeld der Beziehung zuweisen, also etwa tblBestellungen<\/b>. In diesem Fall realisieren wir das über ein Fremdschlüsselfeld, das durch die Definition der Beziehung so angelegt wird, dass dieses Feld nur die Werte des Primärschlüsselfeldes der verknüpften Tabelle annehmen kann.<\/p>\n
Bei der 1:1-Beziehung ist das prinzipiell genau das Gleiche, mit einem entscheidenden Unterschied: Das Fremdschlüsselfeld der Beziehung wird so ausgelegt, dass es jeden Wert nur einmal annehmen kann, es erhält also einen eindeutigen Index. Das würde im obigen Beispiel der Kunden und Bestellungen bedeuten, dass wir das Fremdschlüsselfeld KundeID <\/b>der Tabelle tblBestellungen <\/b>mit einem eindeutigen Index versehen.<\/p>\n
Dann könnten Sie jedem Kunden allerdings nur eine Bestellung zuweisen, was definitiv keinen Sinn ergibt. In anderen Fällen jedoch schon: Wenn Sie etwa die Adresse des Kunden in einer eigenen Tabelle verwalten wollen (zum Beispiel namens tblKundenLieferadresse<\/b>), würde ein mit einem eindeutigen Index versehenes Feld etwa namens KundeID <\/b>als Fremdschlüsselfeld durchaus sinnvoll sein. Auf diese Weise ist sichergestellt, dass es für jeden Kunden nur eine Lieferadresse gibt. Was übrigens in den meisten Anwendungsfällen ausreicht – außer, Sie programmieren eine Datenbank für ein Shopsystem wie Amazon, wo ein Kunde auch Bestellungen an andere Empfänger schicken lassen kann.<\/p>\n
Auf die gleiche Weise könnte man dann auch noch eine zweite Tabelle per 1:1-Beziehung mit der Tabelle tblKunden <\/b>verknüpfen, zum Beispiel namens tblKundenRechnungsadressen<\/b>, um zu jedem Kunden auch noch eine Rechnungsadresse speichern zu können. Auch hier würden wir das Fremdschlüsselfeld mit einem eindeutigen Index versehen.<\/p>\n
Sinn von 1:1-Beziehungen<\/h2>\n
Welchen Sinn und Zweck haben solche 1:1-Beziehungen nun Der erste ist, dass man eine Tabelle auf diese Weise ein wenig entschlacken kann. Das ist insbesondere wichtig, wenn es der Anwendungsfall tatsächlich erfordert, dass die Tabelle mehr als 255 Felder enthält (was in der Realität nicht oft vorkommen sollte – meist lassen sich dann ähnliche Felder in eine m:n-Tabelle auslagern). Sollte also eine Tabelle tatsächlich mehr als 255 Felder benötigen, legen Sie eine zweite Tabelle an, die per Fremdschlüsselfeld mit eindeutigem Index mit der ersten Tabelle verknüpft wird.<\/p>\n
Ein weiterer Anwendungszweck sind Berechtigungen. Wenn Sie zum Beispiel Mitarbeiter in einer Datenbank verwalten, könnte die Tabelle mit den Mitarbeitern auch sensible Daten wie etwa das Gehalt enthalten. Die Mitarbeiterdaten benötigen Sie aber auch für andere Zwecke wir etwa das Zuweisen von Aufgaben. Damit beispielsweise Projektleiter dies tun können, ohne Einblick in die Gehälter der Mitarbeiter nehmen zu können, müssten Sie die Tabellen mit entsprechenden Berechtigungen versehen. Wenn Sie das nicht auf Feldebene tun wollen, können Sie die Tabelle aufteilen und per 1:1-Beziehung verknüpfen und den Teil der Tabelle mit den sensiblen Daten entsprechend schützen.<\/p>\n
Zugegeben: Das Thema ist nicht relevant, wenn Sie mit einer reinen Access-Datenbank arbeiten, da diese keine Möglichkeiten zur Vergabe von Berechtigungen bietet. Aber wenn Sie etwa mit dem SQL Server arbeiten, ist dies durchaus einen Alternative. Wenngleich Sie dort natürlich auch auf anderer Ebene sicherstellen können, dass Benutzer nur die für sie relevanten Daten sehen – etwa indem Sie per gespeicherter Prozedur nur solche Daten liefern, die der Benutzer benötigt.<\/p>\n
Eine andere Variante, die sich ebenfalls die Verwaltung von Kunden anschneidet, ist die, bei der Personen in eine allgemeine Tabelle geschrieben werden und deren Informationen bezüglich ihrer Rolle, also etwa als Kunde, Mitarbeiter oder Lieferant in separaten Tabellen gespeichert werden. Die Tabelle tblPersonen <\/b>würde dann nur Informationen wie die Anrede, Vorname, Nachname, Geburtsdatum und andere allgemeine Daten aufnehmen. In weiteren Tabellen wie tblKunden<\/b>, tblMitarbeiter <\/b>oder tblLieferanten <\/b>fügen Sie dann die rollenspezifischen Daten hinzu. Auf diese Weise ist es dann auch einfach, einer Person mehrere Rollen zuzuweisen. Warum sollte ein Mitarbeiter nicht gleichzeitig auch Kunde sein<\/p>\n
1:1-Beziehung erstellen<\/h2>\n
Wir wir eine 1:1-Beziehung erstellen, schauen wir uns am Beispiel von Kunden und Lieferadressen an. Die Tabelle tblKunden <\/b>soll allgemeine Daten enthalten, wie sie etwa in einem Shopsystem Verwendung finden wie E-Mail-Adresse, das Kennwort oder das Datum der Aufnahme dieses Kunden in die Datenbank (siehe Bild 1).<\/p>\n
![\"Entwurf](\"..\/tl_files\/images\/pic_427_001.png\")
<\/a><\/p>\n