ERM in mySQL Workbench

[Dickus]

Hallo Leute,
habe mir heute die Workbench heruntergeladen, um eine DB
zu entwerfen. Dabei bin ich aber auf ein mittelschweres Problem
gestossen.
Das war dann der Grund, dass ich mir noch schnell eine Trial
vom Sybase PowerDesigner herunterlud, um dort mit Erschrecken
das gleiche Problem festzustellen.

Nun frage ich mich, weil die Programme ja auch von Profis genutzt
werden, ob ich in meiner Denkweise einen Fehler habe.

Nun wird's konkreter. ;-)
Wenn ich eine DB entwerfe (bisher immer nur auf Papier) dann nutze
ich nicht nur die Chen-Notation (1:n, n:1, 1:1, m:n), sondern auch die
Min-/Max-Notation, da diese ja viel detaillierter ist.
In der Chen-Notation beim Fall 1:1 gibt es schliesslich drei verschiedene
Möglichkeiten die Tabellen korrekt zu erstellen. Was genau gemacht werden
muss, sagt mir dann allerdings erst die Min-/Max-Notation.

1:1 mit nur einer Tabelle:
Trifft zu, wenn beide Seiten (ERM) obligatorisch sind. Der Logik und
Übersichtlichkeit wegen teilt man es meist eh in zwei Tabellen auf, wobei
dann egal ist welcher PK als FK in die andere Tabelle wandert.
Z.B.: Autos und Fahrer. Jeder Fahrer fährt genau ein Auto und jedes Auto
wird von genau einem Fahrer gefahren.

1:1 mit zwei Tabellen:
Trifft zu, wenn eine Seite nicht-obligatorisch ist und die andere obligatorisch.
Z.B.: Autos und Fahrer. Ein Fahrer wird keinem Auto zugeordnet. Alle anderen
fahren wieder nur genau ein Fahrzeug. Es ist quasi ein Fahrer übrig.
Hier wäre die Seite der Fahrer nicht-obligatorisch, da beim Minimum die
Möglichkeit einer 0 besteht.
Somit muss der PK der nicht-obligatorischen Seite als FK zur obligatorischen
Seite wandern.
Anders herum wäre es nicht korrekt, weil dann Leerfelder in der Tabelle
entstehen würden.

1:1 mit drei Tabellen:
Trifft zu, wenn beide Seiten im ERM nicht-obligatorisch sind. Zwei Tabellen reichen
hier nicht aus, da egal wie man es dreht und wendet, immer Leerfelder in den
Tabellen entstehen.
Also wandert der PK der einen Seite und der PK der anderen Seite jeweils als
FK in eine 'ZwischenTabelle'.

So...also es gibt für 1:1 drei Möglichkeiten der Tabellenbildung.
Welche Software kann das abbilden?
Wo kann man mit der Min-/Max-Notation arbeiten?
Die Chen-Notation ist ja hier keinesfalls ausreichend

...oder?

Danke
Dickus

[Christian Marquardt]

Deine Beschreibung bezeichnet man als Uni- oder Bidirektionale Beziehung.
Allerding ist mit nicht klar, warum man soviele Tabellen benötigt. Sicherlich ist 0 als Key möglich, aber eben auch NULL.

Somit würde ich max. 2 Tabellen für erforderlich halten

[Dickus]

Hallo Christian,
dass es den Eintrag NULL gibt ist natürlich richtig. ;-)
Aber diese Felder mit 'nichts' drin, habe ich immer zu verhindern
versucht, da diese ja auch Speicherplatz belegen.

Sagen wir mal, ich habe die Tabelle 'Mitarbeiter':

|m_id|zuname|vorname|
|----+------+-------|
|1234|hans  |mueller|
|5678|klaus |meier  |
|9876|eva   |schulze|

Bis hier ist alles klar. Was aber wenn die Mitarbeiter eine E-Mail
Adresse bekommen, aber so, dass eben nicht jeder eine bekommt?

|m_id(PK)|zuname|vorname|mail           |
|--------+------+-------+---------------|
|1234    |hans  |mueller|[email protected]|
|5678    |klaus |meier  |NULL           |
|9876    |eva   |schulze|[email protected]   |

Um das Leerfeld zu vermeiden arbeite ich mit einer zweiten Tabelle,
wobei der PK der nicht-obligatorischen Seite als FK zur obligatorischen Seite wandert.

ERD:

              [0,1]                  [1,1]
                          /\
+-------------+          /  \            +-------+
| Mitarbeiter |---------- hat -----------| EMail |
+-------------+          \  /            +-------+
                          \/
                         1:1

|m_id(PK)|zuname|vorname|          |mail           |m_id(FK)|
|--------+------+-------|          |---------------+--------|
|1234    |hans  |mueller|          |[email protected]|1234    |
|5678    |klaus |meier  |          |[email protected]   |9876    |
|9876    |eva   |schulze|

Somit habe ich das Problem der Leerfelder umgangen.
Wenn nun beide Seiten nicht-obligatorisch sind, dann nehme ich halt
drei Tabellen und alles wird gut. ;-)

Auch hier mal ein kleines Beispiel:

ERD:

              [0,1]                  [0,1]
                          /\
+-------------+          /  \            +-------+
| Fahrer      |---------- hat -----------| PKW   |
+-------------+          \  /            +-------+
                          \/
                         1:1

     hans ------------------------------- Opel
     klaus                                Honda
     eva  ------------------------------- VW

Das soll bedeuten, dass wenn denn jemand ein Auto fährt, es auch genau
ein Auto ist. Sofern ein Auto gefahren wird, dann auch nur von genau
einem Fahrer.
Dennoch besteht auf beiden Seiten die Option, dass kein Auto gefahren
wird bzw. kein Fahrer ein Auto fährt.
Die drei Tabellen sehen dann wie folgt aus:

|f_id(PK)|zuname|vorname|     |f_id(FK)|PKW(FK)|     |PKW(PK)|
|--------+------+-------|     |--------+-------|     |-------|
|1234    |hans  |mueller|     |1234    |Opel   |     |Opel   |
|5678    |klaus |meier  |     |9876    |VW     |     |Honda  |
|9876    |eva   |schulze|                            |VW     |

Die Tabelle in der Mitte stellt die Zuordnung her.

Denke ich da zu umständlich ?

Danke
Dickus

[Christian Marquardt]

Aber diese Felder mit 'nichts' drin, habe ich immer zu verhindern
versucht, da diese ja auch Speicherplatz belegen.

???Das verstehe ich jetzt nicht, stattdessen Tabellen anlegen? Gott sei Dank belegen diese kein Speicherplatz?

Denke ich da zu umständlich ?

Aus meiner Sicht -> Ja

Des Weiteren müsste die 3. Tabelle ebenfalls mit Keys arbeiten...

[Dickus]

Moinsen,
dass mit den PK's in der dritten Tabelle stimmt.
Die hatte ich vergessen. ;-)

Ab einer gewissen Menge an Leerfeldern lohnt sich
auf jeden Fall eine weitere Tabelle.

Bei 500 Mitarbeitern, bei denen nur eine handvoll
bestimmte Eigenschaften haben (wie z.B. eine E-Mail Adresse)
würde ich grundsätzlich mit einer weiteren Tabelle arbeiten.

Auch lassen sich doch so eleganter die E-Mail Adressen bei
Bedarf löschen, ohne dass gleich der Mitarbeiter gelöscht wird.

Die referentielle Integrität ist auch gewahrt.

Ich für meinen Teil finde es nicht zu umständlich. ;-)

Nun ja, die Hersteller der Tools (Workbench, PowerDesinger etc.)
sehen das wohl auch n bissel anders.

Hmmm...ich frage mich, ob sich eine SW-Entwicklung in diese
Richtung lohnt. Oder bin ich der einzige, der diese Gedanken hat ? *staun*

Dickus

[Christian Marquardt]

Auch lassen sich doch so eleganter die E-Mail Adressen bei
Bedarf löschen, ohne dass gleich der Mitarbeiter gelöscht wird.

Nunja, was an einem löschen eines Feldes aus einem DS nciht elegant ist.....

Oder bin ich der einzige, der diese Gedanken hat ? *staun*

Da ORM Tools wie Hibernate, Toplink ebenfalls anders arbeiten, würde mir das zu denken geben

[Dickus]

Moin,
habe noch einmal das Internet bemüht und musste feststellen, dass
es regelrechte Abhandlungen zu dem Thema NULL bzw. Leerfelder gibt.
So wie es aussieht gibt es da mal wieder geteilte Meinungen.
Die Regeln zur Überführung eines ERD in ein relationales Modell besagen
jedenfalls, das NULL-Felder nach Möglichkeit zu verhindern sind und
dass eben deswegen auch schonmal drei Tabellen Sinn machen.

Wie dem auch sei, ich werde dann mal weiter nach einem geeigneten
Tool suchen und bis dahin meinen bisherigen Werkzeugen Papier und
Stift treu bleiben.

Wenn die Zeit es hergibt, steht vielleicht mal eine Eigenentwicklung an.

Dickus