Tabellenerzeugung aus einem ERM (Regel 3)

[Souli]

Aloha,
und wieder einmal DB und ERM.

"Die Regeln der Ableitung von relationalen Datenmodellen aus dem ERM
sind abhängig sowohl vom Grad als auch von der Ausprägung der
Beziehungen. Es existieren folgende Regeln (vgl. Jackson: Entwurf
relationaler Datenbanken, Carl Hanser Verlag München Wien, 1990)"

So, da ist die Rede von 6 Regeln.
Bei der dritten habe ich schon eine Frage.

Regel Nr. 3 besagt:
---
Ist der Grad der Beziehung 1:1 und die Teilnahme der Ausprägungen
von keiner der beiden Entitäten obligatorisch, werden drei Relationen
benötigt.
Es gibt jeweils eine Relation für beide Entitäten und die Beziehung.
In der Beziehungsrelation müssen beide Entitätenschlüssel als Attribut
(Fremdschlüssel) enthalten sein.
---

Beispiel:
[ externes Bild ]

Alsooo...
Ein Mitarbeiter besitzt entweder keinen (1) oder genau einen (2) Leserausweis.
Ein Leserausweis ist entweder keinem (3) oder genau einem (4) Mitarbeiter zugeordnet.

Ich verstehe das so, dass meine Relationen wie folgt aussehen könnten:
Relation 1: Mitarbeiter (id, zuname, vorname)
Relation 2: Besitz (tab, id, nr)
Relation 3: Leserausweis(nr)

Oder anschaulicher:
[ externes Bild ]

Hierbei sind die Primärschlüssel fett und untersrichen (id, tab und nr)
Die Fremdschlüssel sind fett und kursiv (id und nr)

Ist das so korrekt?

Danke
Souli

[Pyramide]

Eine dritte Tabelle brauchst du normalerweise nur bei M:N Beziehungen. In deinem Fall würde ich beim Ausweis einfach ein Feld "mitarbeiternummer" einfügen.

[PhilippK]

Na ja, an der Stelle beginnt dann so langsam die Freiheit beim Datenbank-Entwurf
Ich sehe jetzt erst mal keinen Grund, wieso das nicht in einer der beiden Tabellen mit als Fremdschlüssel erfasst werden sollte. Das hängt aber ggf. auch stark von dem betrachteten Fall ab.
Nach der Regel wäre das Ergebnis korrekt. Sinnvoll wäre es aber hier, bei den Fremdschlüsseln auf die UNIQUE-Eigenschaft hinzuweisen. Die würde hier nämlich Sinn machen. Ohne die könnten wir auch gleich in der Tabelle Besitz einen zusammengesetzten Primärschlüssel verwenden.

Gruß, Philipp

[Souli]

Moinsen,

ok, mit zwei Tabellen geht das hier anscheinend auch.
Aber...

...
Ohne die könnten wir auch gleich in der Tabelle Besitz einen zusammengesetzten Primärschlüssel verwenden.
...

Da habe ich doch glatt ein paar Thesen zu den Schlüsseln:
1.) Jede Tabelle muss zwingend einen Primärschlüssel (PK) haben.
2.) Der PK kann aus mehreren Attributen zusammengesetzt sein.
3.) Der PK sollte möglichst kurz gehalten werden.
4.) Ist ein PK einer Tabelle aus mehreren Attributen zusammengesetzt, darf keines der Attribute ein FK dieser Tabelle sein.
--> Ein PK kann innerhalb einer Tabelle niemals gleichzeitig PK und FK sein.
5.) Hat man mehrere Tabellen, müssen diese unterschiedliche PKs haben.
--> Ein PK darf niemals doppelt vorkommen.

Stimmen diese Aussagen?

Danke
Souli

[/quote]

[PhilippK]

Mit 1 bis 3 habe ich keine Probleme. Mit 4 und 5 schon.
Zu 4: bei einer n:m-Verknüpfung nimmt man oft einen zusammengesetzten Primärschlüssel, der sich aus den PKs der beiden zu verknüpfenden Tabelle zusammensetzt. In diesem Fall besteht der PK aus zwei FKs
Zu 5: Meistens passt das. Aber es gibt Ausnahmen. Eine 1:1-Verknüpfung (die auch schon eine Ausnahme ist) kann ein Beispiel sein. Oder bei einer Generalisierung/Spezialisierung kann so was vorkommen.

Gruß, Philipp

[Souli]

Alles klar

Dankeschön !

Souli

[Souli]

So...auf zur nächsten Runde...

Hallöle Ihr Datenbankspezialisten.

Habe bei der TU Ilmenau ein interessantes kleines Skript zum Thema
Datenbanken gefunden:
(http://www.tu-ilmenau.de/fakia/fileadmi ... orKap6.pdf)

Bei meiner Suche zu einer Erklärung zu den Normalformen stiess ich darauf.
Hier nun meine Fragen, die ich wieder durch Grafiken unterstütze:

Ausganstabelle:
[ externes Bild ]

So...gehen wir mal von der 1NF aus.
Ich weiss....die Namen sind nicht wirklich in der 1NF, soll hier aber egal sein.

Die 2NF sieht dann so aus:
[ externes Bild ]

Als ERM sehe ich das so: [Kunde (1,*)]----<bucht>----[Flug(1,*)]

An dieser Stelle schiebe ich mal kurz die Regeln zur Überführung des ERMs in ein physisches Datenmodell ein:
Regel 1: Bei 1:1 wo beide Seiten obligatorisch (muss) sind, benötigt man 1 Tabelle.
Regel 2: Bei 1:1 wo eine Seite obligatorisch ist, benötigt man 2 Tabellen.
Regel 3: Bei 1:1 wo beide Seiten nichtobligatorisch (kann) sind, benötigt man 3 Tabellen.
Regel 4: Bei 1:n wo die n-Seite obligatorisch ist, benötigt man 2 Tabellen.
Regel 5: Bei 1:n wo die n-Seite nichtobligatorisch ist, benötigt man 3 Tabellen.
Regel 6: Bei n:m Beziehungen sind die Ausprägungen egal, es werden immer 3 Tabellen benötigt.

Da ich ja schrieb, dass ich das ERM so sehe:
[Kunde (1,*)]----<bucht>----[Flug(1,*)]
tritt hier Regel 6 in Kraft. Es werden also drei Tabellen benötigt.

Wenn die Beziehung so wäre:
[Kunde (0,1)]----<bucht>----[Flug(0,1)]
dann würde Regel 3 greifen.

Der noch nicht untersuchte Fall mit drei Tabellen wäre 1:n mit
nichtobligatorischer n-Seite. Da nur die n-Seite untersucht wird,
wären viele Fälle als ERM möglich:
- [Kunde (0,1)]----<bucht>----[Flug(0,1)]
- [Kunde (0,*)]----<bucht>----[Flug(0,1)]
- [Kunde (1,1)]----<bucht>----[Flug(0,1)]
- [Kunde (1,1)]----<bucht>----[Flug(0,1)]
- [Kunde (0,1)]----<bucht>----[Flug(0,*)]
- [Kunde (0,*)]----<bucht>----[Flug(0,*)]
- [Kunde (1,1)]----<bucht>----[Flug(0,*)]
- [Kunde (1,1)]----<bucht>----[Flug(0,*)]

Wenn ich das alles richtig verstanden habe, sollte das korrekt sein.

So, nun mal eine echte Frage.
Laut Regel 2 darf ich nur zwei Tabellen einsetzen, wenn eine Seite in der
1:1 Beziehung obligatorisch ist.
Wenn mein ERM also so aussehen würde:
[Kunde (1,*)]----<bucht>----[Flug(0,*)]
dann heisst das ja:
Ein Kunde (und zwar mindestens einer) kann entweder gar keinen Flug oder aber (theoretisch) unendlich viele Flüge buchen.
Ein Flug wird entweder von keinem Kunden gebucht oder aber es können auch (theoretisch) unendlich viele Kunden sein.

Macht in der Praxis vielleicht nicht viel Sinn, mit leerem Flugzeug Richtung Süden zu fliegen.

Wie aber würden meine Tabellen aussehen ?

Mein Vorschlag:
[ externes Bild ]

Die Regel besagt nämlich dass der Primärschlüssel der nichtobligatorischen
Seite zugleich der Fremdschlüssel in der Tabelle der obligatorischen
Seite ist. (In der Tabelle Kunden ist Flug der Fremdschlüssel)

Puh...soll erstmal bis hier reichen.

Wenn mir jemand diesen ganzen Gehirnschmalz bestätigen kann,
dass ich also richtig liege und das soweit korrekt verstanden habe,
dann schiebe ich noch etwas mit der 3NF nach.

Vielen Dank für Eure Mühe !
Souli

[Pyramide]

Ignorierst du meine Hinweise eigentlich absichtlich? Große Bilder bitte nur verlinken!

KB:knigge

[Souli]

sorry, schien mir aber in diesem Zusammenhang besser zu sein,
wenn man die Bilder auch im Beitrag sieht und nicht erst ein
anderes Fenster öffnen muss.

Kommt jedenfalls nicht wieder vor.

Souli

[PhilippK]

Zur eigentlichen Frage: sieht erst mal passend aus. Wobei die Regeln in der Praxis durchaus interpretationsfähig sind

Gruß, Philipp