1:1 Verbindung in Datenbanken

6 Antworten

greyhead
17.03.2010, 23:15

Theoretisches Szenarium zu 1:

Es gibt eine Tabelle "Abteilungsleiter" und eine "Abteilung". Ein AbtLeit managt genau eine Abteilung und eine Abteilung hat nur einen AbtLeit. Ämterhäufung ist bei diesem Szenario verboten. Sinnvoll ist die Aufteilung auf zwei Tabellen, da es sich einmal um Daten zu einer Person handelt und einmal um Daten zu einem abstrakten Gebilde. Beispiel: die Gebäudebezeichnung in dem die Abteilung untergebracht ist, hat mit dem AbtLeit nichts zu tun und das Geburtsdatum des AbtLeit ist irrelevant für die Abteilung.

Hoffe, das ist sinnvoll genug.
micholee 
Beitragsersteller
 18.03.2010, 14:51

hey greyhead, auf jedenfal, super Beispiel. Vielen Dank

0
wotan38
01.07.2012, 09:53

Zu 1: Wenn ich eine Mitgliederverwaltung habe, wo ein Teil der Mitglieder den Beitrag per Bankeinzug zahlt und der Rest per Überweisung, dann habe ich nur bei ersteren eine Bankverbindung, die ich speichern muss. So kommen z.B. auf 1000 Mitglieder nur 500 Bankverbindungen. Ein Auslagern in getrennte Tabellen ist wegen der unterschiedlichen Mengen sinnvoll. Ich habe aber bei den Einziehern nach wie vor eine 1:1-Beziehung, weil je Mitglied immer nur eine Bankverbindung möglich ist.

raka67
17.03.2010, 09:16

zu 1: Ich denke vorwiegend ist die Beziehung gemeint, wie sie bel1987 bereits genannt hat, weniger die der praktischen Lösung wie sie greyhad anführt.(Obwohl er praktisch gesehen genauso recht hat :-), aber ich denke in Deinem Fall geht es eher um Datenbanktheorie.) Das Hausmeisterbeispiel hinkt aber, sobald eine Firma zwei Hausmeister hat.Stell Dir in vor, Du baust eine Software (um bei bel1987 zu bleiben) die Mitarbeiter verwaltet. Du legst die Mitarbeiter in einer Tabelle ab. Um eine saubere Verwaltung der möglichen Berufe die im Unternehmen vorhanden sind zu haben, packst Du diese ebenfalls in eine Tabelle.Wenn jetzt ein Mitarbeiter (bleiben wir beim Hausmeister) angelegt wird, bekommt er eine Id aus der Beruftabelle.Bei der Berufstabelle hast Du meines erachtens nach KEINE 1:1 Beziehung, da jederzeit ein weiterer HAusmeister angestellt werden könnte. Dann wäre es bereits 2:1 bzw. n:1 (Mitarbeiter:Berufe). Nimm lieber Steuernummern für die Buchhaltung. JEder Mitarbeiter kann nur eine Steuernummer haben. Ich glaube das ist besser.

zu 2: Die alte BDE (Borland Database Engine) war sowas. Hier konnte man wirklich (wenn man bei Standard-Sql blieb) einfach nur einen Parameter ändern und von Oracle auf Firebird, von Firebird auf Access usw. switchen. Klar natürlich nur dann wenn man keine schmutzigen Tricks machte. Dies ist der Grund warum wir heute noch beim Übertragen von DB Typ a nach DB Typ b unheimlich gerne die BDE einsetzen.

Schönen Tach noch.
micholee 
Beitragsersteller
 17.03.2010, 23:09

hi raka67, vielen Dank für die nette Erklärung. Das von greyhead leuchtet mir auch voll und klar ein, die beiden Beispiel die er erwähnt hat. Das was du sagst, hört sich auch gut. Man hätte praktisch für jeden Mitarbeiter eine Tabelle und Steuernummern wären in einer anderen Tabelle. (Wobei hier der Prof. fragen könnte: "Sie könnten ja dann gleich zusammenlegen". Dann könnte ich aber sagen, dass zum Beispiel Tabelle a und b von verschiedenen Leuten evtl. administriert wird oder man eine bestimmte Anzahl von Feldern in der Tabelle haben will, usw. usw. :-)

Zu Frage 2. Oki, BDE kenne ich nicht. Aber wenn das ein Abtraktionslayer ist, könnte ich das mal namentlich nennen. Obwohl man bei JDBC nicht nur einen Parameter ändern und eine andere DB einsetzen kann, ist JDBC dennoch ein Abtraktionslayer ne. (Wenn ich JDBC nicht einsetzen würde, müsste ich praktisch direkt zu Datenbank programmieren. Was wäre für mich hier der Mehraufwand, denn den Vorteil vn JDBC, dass ich kurz auf andere DB's switschen kann, habe ich ja nicht wirklich. Außer, ich nehme JDBC raus in meiner Aplikation und setze dafür eine andere Schnittstelle ein, dann müssten nur meine SQL-statements außerhalb der Schnittstelle noch passen.

Grüße

0
micholee
16.03.2010, 18:30

hi vielen dank.

1 zu 1 Verbindungen könnte man ja aber eigentlich gleich in eine Tabelle einpacken, anstatt zwei deren Beziehung 1 zu 1 ist, dennoch soll es in bestimmten Fällen Sinn machen, was mir nicht einleuchtet.

Grüße
greyhead  16.03.2010, 22:19

Es gibt praktische Szenarien, die dafür sprechen. Eine Tabellenerweiterung um ein Feld kann einen Rattenschwanz an weiterer Wartungsarbeit nach sich ziehen, wenn sehr viele Abfragen/Programme auf diese Tabelle zugreifen: soll/darf bei select * das neue Feld mit hochgebaggert werden? Und Pfusch, der von der Anzahl der Tabellenfelder abhängig ist, funktioniert nicht mehr.

Oder dieser Fall: Tabelle A wird von Firma a administriert und Tabelle B von Firma b. Einig sind sich beide nur beim Aufbau der ID mit der beide Tabellen verknüpft werden sollen...

0
illnin086
15.12.2010, 11:22

Es gibt noch eine Idee für 1:1-Tabellen: Ich erstelle gerade eine Datenbank für einen Bestatter. Dabei hat man oft den Fall, dass zum Beispiel zwar eine verstorbene Person abgeholt werden soll, die Beerdigung mit der Urne aber von einem anderen Bestatter an einem anderen Ort durchgeführt wird. So hat man in diesem Fall immer leere Werte in vielen Spalten. Wenn ich eine 1:1-Tabelle habe, die nur dann genutzt wird, wenn ich sie wirklich brauche, dann habe ich nicht so viele Leerspalten in den Datensätzen - außerdem habe ich mehr Übersicht, wenn statt einer Tabelle mit 150 Spalten z.B. 5 Tabellen mit im Schnitt 30 Spalten habe. Ist zwar dann bei der Programmierung ein kleiner Mehraufwand, macht sich aber mit Sicherheit positiv bemerkbar.

Diese Antwort ist weniger für den Fragesteller als vielmehr für andere Suchende, die Pro- & Contra-Argumente hören möchten.