Logisches Datenbankschema

[Gast Gast85]

Im ER-Modell ist es ja erlaubt eine 1:1 Beziehung z.B. ein Angestellter hat genau eine Personalakte.

Ist die Darstellung einer 1:1 Beziehung in einen logischen Datenbankschema erlaubt?

Ich habe leider keine Beispiele dafür gefunden und frage deswegen hier im Forum nach, weil ich diese Info für mein Abschlussprojekt benötige.

Eine Kundennummer hat genau eine Kundennummer in zwei verschiedenen Tabellen.

 

Vielen Dank für die Hilfe

Gast85

[arlegermi]

Wer soll das verbieten? Wenn du auf Normalisierung hinaus willst, dann gibt es darin nichts, das das verbietet (jedenfalls nicht in den üblichen ersten drei - ob die fünfte oder sechste was dagegen hat, kann ich aus'm Stehgreif nicht sagen).

Und selbst wenn eine der Normalformen das verböte, ist das immer noch kein Gesetz. Es gibt teilweise gute Gründe, gegen die Normalformen zu verstoßen. Genauso wie es zuweilen gute Gründe für 1:1-Beziehungen gibt.

[maestro impostor]

Zitat

In a relational database, a one-to-one relationship exists when one row in a table may be linked with only one row in another table and vice versa. It is important to note that a one-to-one relationship is not a property of the data, but rather of the relationship itself. A list of mothers and their children may happen to describe mothers with only one child, in which case one row of the mothers table will refer to only one row of the children table and vice versa, but the relationship itself is not one-to-one, because mothers may have more than one child, thus forming a one-to-many relationship.

 

[Gast Gast85]

Vielen Dank für eure Antwort.

 

Da es den Kunden eben nur einmal mit dieser Kundennummer gibt. Macht es für mich nur Sinn, wenn zwischen den zwei Tabellen eine 1:1 Beziehung besteht. Mich wundert es nur, das die Darstellung einer 1:1 Beziehung nie als Logisches Datenbankschema gefunden habe. Würde gerne die Gründe wissen, warum man nie Beispiele dazu findet.

Mfg

Gast85

 

 

 

 

[JimTheLion]

vor 14 Minuten schrieb Gast Gast85:

Macht es für mich nur Sinn, wenn zwischen den zwei Tabellen eine 1:1 Beziehung besteht.

Welche 2 Tabellen denn eigentlich?

[Gast Gast85]

Eine Tabelle enthält Kundenstammdaten ( Name, Adresse, Anschrift)  und die andere Tabelle enthält Kundeninformationen ( enthält Zusatzinformationen  zu den Kunden zeweils). Zwischen den beiden Tabellen soll es eine 1:1 Beziehung über die eindeutige Kundennummer beider Tabellen bestehen.

 

 

 

[JimTheLion]

Vielleicht findest du kein Beispiel, weil man die Zusatzinformationen auch in die andere Tabelle mit aufnehmen könnte. Die Partionierung geschieht in deinem Fall wohl aus logistischen Gründen, und nicht weil das Datenmodell danach verlangt.

[Whiz-zarD]

Es gibt da keine Silberkugel beim Design einer relationalen Datenbank. Für jedes Problem muss individuell entschieden werden, was nun die geeignete Form ist. Auch eine Normalisierung ist nicht für jeden Fall geeignet. Es gibt also viele Fälle, wo eine denormalisierte Tabelle mehr Sinn macht, als eine normalisierte.

Eine 1:1 Relation kann also durchaus Sinn machen. Beispiel: Du hast mehrere Gruppen von Personen. Du hast Angestellte, Manager und Kunden. Jede Gruppe besitzt gemeinsame Daten, wie z.B. den Namen aber es gibt unterschiedliche Daten. Ein angestellter oder ein Manager hat ja keine Kundennummer aber ein Kunde schon. Um die Person-Tabelle nicht unnötig breit zu machen, machst du eine Person-, eine Angestellte- und eine Manager-Tabelle. In Person speicherst du die globalen Daten und die Angestellte- und Manager-Tabelle die jeweiligen spezifischen Daten haben dann eine 1:1 Relation zur Person-Tabelle.

Ein anderes Beispiel: Aufgrund von Performance willst du eine Tabelle auf eine SSD oder sogar in den Arbeitsspeicher (In-Memory) schieben aber in dieser Tabelle befindet sich ein BLOB-Feld, was sehr groß sein kann (mehrere GBs). Dieses Feld wird aber nicht immer benötigt bzw. muss nicht schnell geladen werden können. Um die SSD oder den Arbeitsspeicher nicht unnötig zuzumüllen, wird das BLOB-Feld in eine Separate Tabelle ausgelagert, die dann auf einem langsameren Speicher liegt und mit einer 1:1-Relation verbunden. 

Bearbeitet 26. Januar 2018 von Whiz-zarD

[Gast Gast85]

vor 57 Minuten schrieb PVoss:

Vielleicht findest du kein Beispiel, weil man die Zusatzinformationen auch in die andere Tabelle mit aufnehmen könnte. Die Partionierung geschieht in deinem Fall wohl aus logistischen Gründen, und nicht weil das Datenmodell danach verlangt.

Die Tabelle mit den Kundenstammdaten existiert bereits und darf nicht geändert/erweitert werden. Die Tabelle mit den Kundenzusatzinformationen muss erstellt werden. Demnach kann ich die Attribute nicht in eine Tabelle zusammenfassen und muss eine eigene Tabelle dafür erstellen.

 

[JimTheLion]

Jo, macht ja nichts^^'

In solchen Fällen legt man dann eine neue Tabelle an, so wie du es eben vorhast. Ist erlaubt.

[stefan.macke]

Ich  frage mich die ganze Zeit, was denn wohl ein "logisches" Datenbankmodell sein soll. Meinst du vielleicht ein relationales Modell?

Falls ja: Selbstverständlich darfst du 1:1-Beziehungen in einem relationalen Datenbankmodell benutzen. Sie werden exakt so modelliert wie 1:N-Beziehungen, nur dass die Platzierung des Fremdschlüssels frei wählbar ist, während er bei 1:N-Beziehungen immer in der N-Tabelle abgelegt werden muss.

[Gast Gast85]

vor 8 Stunden schrieb stefan.macke:

Ich  frage mich die ganze Zeit, was denn wohl ein "logisches" Datenbankmodell sein soll. Meinst du vielleicht ein relationales Modell?

Falls ja: Selbstverständlich darfst du 1:1-Beziehungen in einem relationalen Datenbankmodell benutzen. Sie werden exakt so modelliert wie 1:N-Beziehungen, nur dass die Platzierung des Fremdschlüssels frei wählbar ist, während er bei 1:N-Beziehungen immer in der N-Tabelle abgelegt werden muss.

Hi Stefean,

ja es handelt sich um das Relationales Datenbankmodell

Logisches Datenbankschema: Das konzeptuelle Datenbankschema wird auf ein logisches Datenbankschema abgebildet. Dabei wird das Modell um datentechnische Angaben erweitert (z. B. Feldformate, identifizierende Suchbegriffe). Das logische Datenbankschema gehorcht den Regeln einer durch das zu verwendende DBMS gegebenen Struktur, z. B. dem relationalen Datenmodell, bei dem alle Daten in Tabellen abgelegt werden.

 

[Gast Gast85]

vor 8 Stunden schrieb stefan.macke:

Ich  frage mich die ganze Zeit, was denn wohl ein "logisches" Datenbankmodell sein soll. Meinst du vielleicht ein relationales Modell?

Falls ja: Selbstverständlich darfst du 1:1-Beziehungen in einem relationalen Datenbankmodell benutzen. Sie werden exakt so modelliert wie 1:N-Beziehungen, nur dass die Platzierung des Fremdschlüssels frei wählbar ist, während er bei 1:N-Beziehungen immer in der N-Tabelle abgelegt werden muss.

Dann wird in im relationellen Datenbankmodel also immer eine 1:n Beziehung  genutzt/dargestellt auch wenn es eine 1:1 Beziehung ist oder hab ich das falsch verstanden (nur das ich mir die Tabelle für den FK aussuchen kann)?

Könntest du da ein Beispiel nennen, damit es verständlicher wird.

Vielen dank

Gast85

[stefan.macke]

Nein, falsch verstanden. Die Kardinalitäten sind semantisch natürlich unterschiedlich! Aber die technische Umsetzung von 1:1 und 1:n ist gleich: Fremdschlüssel in einer Tabelle verweisen auf die zugehörigen Datensätze der anderen Tabelle. Bei m:n wird dafür eine Zwischentabelle benötigt.

Beispiel 1:1: Benutzer / Login. Ob du die LoginID in die Benutzer-Tabelle oder die Benutzer-ID in die Login-Tabelle packst, ist egal und kann frei entschieden werden, da es jeweils nur eine zugeordnete ID geben kann und keine multiplen Werte auftreten können.

Beispiel 1:n: Artikel / Artikelgruppe. Die Artikelgruppe-ID muss hier in die Artikel-Tabelle eingetragen werden, da es ansonsten multiple Werte für die Artikel-ID in der Artikelgruppe-Tabelle gäbe, was gegen die 1. Normalform verstößt.

Beispiel m:n: Artikel / Bestellung. Es ist eine neue Tabelle mit Artikel-ID und Bestellung-ID nötig, in die mehrere Kombinationen eingetragen werden können, da es ansonsten auf beiden Seiten multiple Werte geben könnte.