Datenbankmodellierungen

[MichiLee]

Hallo Forum,

es gibt ja für Datenbanken die Relationenschreibweise in Form von:
Entitiy_1(Spalte_1(PK), Spalte_2, Spalte_3)
Entity_2(Spalte_1(PK(FK), Spalte_2)

Dann ER-Modellierung, bei der man zum Beispiel Entity, Relation und Kardinalität aufzeichnen kann:
http://de.wikipedia.org/wiki/Entity-Relationship-Modell#ER-Diagramme

Was mir nun nicht einfällt, wie man die Schreibweise bzw. Modellierung nennt, in der man die Tabellen als Kästchen zeichnet, und drunter dann die einzelnen Spalten, die in der jeweiligen Tabelle beinhaltet sind. Unser Lehrer hatte da etwas genannt, habe es aber vergessen zu notieren. (Er hatte auf jedenfall zwischen zwei Modellierungen unterschieden)

Grüße

[MichiLee]

Mir fällt leider noch eine klitzekleine Frage auf, sollte auch die letzte diesbezüglich sein.

Wenn ich eine Zwischentabelle habe, um eine N zu M Beziehung aufzulösen und dort die Fremdschlüssel der beiden Tabellen eintrage, dann wäre das ja:

Zwischentabelle(Spalte_DB1(FK), Spalte_DB2(FK)

Warum macht unser Lehrer daraus noch ein (PK)
Zwischentabelle(Spalte_DB1(PK)(FK), Spalte_DB2(PK)(FK)

Normal ist das ja garnicht notwendig ne?

Grüße

[Hopsel]

Hi MichiLee!

Wenn ich eine Zwischentabelle habe, um eine N zu M Beziehung aufzulösen und dort die Fremdschlüssel der beiden Tabellen eintrage, dann wäre das ja:

Zwischentabelle(Spalte_DB1(FK), Spalte_DB2(FK)

Warum macht unser Lehrer daraus noch ein (PK)
Zwischentabelle(Spalte_DB1(PK)(FK), Spalte_DB2(PK)(FK)

Normal ist das ja garnicht notwendig ne?

Doch. Laut Definition wird bei n:m-Beziehungen der Primärschlüssel über beide Fremdschlüssel gebildet.

MfG H☼psel

[MichiLee]

Hi Hopsel,
danke für die Antwort. Ich glaube, dass er evtl. UML gemeint hat, das wäre dann aber beim ERM ja nur eine Notation. Wie auch immer. Ich nehme das mal so hin. Bzgl. der Schlüssel:

Wenn ich eine Zwischentabelle habe, um eine N zu M Beziehung aufzulösen und dort die Fremdschlüssel der beiden Tabellen eintrage, dann wäre das ja:

Zwischentabelle(Spalte_DB1(FK), Spalte_DB2(FK)

Warum macht unser Lehrer daraus noch ein (PK)
Zwischentabelle(Spalte_DB1(PK)(FK), Spalte_DB2(PK)(FK)

Normal ist das ja garnicht notwendig ne?

Doch. Laut Definition wird bei n:m-Beziehungen der Primärschlüssel über beide Fremdschlüssel gebildet.

Ich hätte das so geschrieben:
Zwischentabelle(Zwsichen_ID(PK), Spalte_DB1(FK), Spalte_DB2(FK))

Wusste nicht, dass man einen Schlüssel, sowohl als Primär, als auch als Fremd definieren könnte :-)

Grüße

[Hopsel]

Hi MichiLee!

Ich hätte das so geschrieben:
Zwischentabelle(Zwsichen_ID(PK), Spalte_DB1(FK), Spalte_DB2(FK))

Das kann man natürlich machen. Aber es wird nicht benötigt, da du sowieso ein Wertepaar aus Spalte_DB1 und Spalte_DB2 sowieso eindeutig sein muss.
Ich bin mir auch gerade nicht sicher, ob diese Relation dann noch der 3. Normalform entspräche.

Wusste nicht, dass man einen Schlüssel, sowohl als Primär, als auch als Fremd definieren könnte :-)

So ist es ja auch nicht. Die Fremdschlüsselbeziehung besagt ja nur, dass der Wert einer Tabelle einen Wert einer anderen referenzieren muss, dass also die Tabelle (bzw. die Spalte), auf die der Fremdschlüssel verweist, einen solchen Wert enthalten muss.

Der Primärschlüssel definiert hingegen eine Attributmenge (also eine gewisse Anzahl von Spalten) einer Relation (Tabelle), die jeden einzelnen Datensatz der Relation eindeutig identifizieren können muss.

In diesem Zusammenhang ist ein zusammengesetzter Schlüssel(-kandidat) einfach nur die logische Konsequenz, die aus der Definition einer n:m-Beziehung folgt.

Ein Attribut, das gleichzeitg Fremd- und Primärschlüssel ist, wäre auch widersinnig, da alle Informationen der Relation auch in der Relation, auf die der Fremdschlüssel zeigt, gespeichert werden können.
Ausnahme könnte hier allenfalls die Erweiterung eines bestehenden Datenbankdesigns bilden (z. B. ein Plugin für ein Programm, das einfach (de-)installiert werden und weitere Informationen zu schon vorhanden Datensätzen speichern können soll).

MfG H☼psel

[MichiLee]

Hi,

Ich hätte das so geschrieben:
Zwischentabelle(Zwsichen_ID(PK), Spalte_DB1(FK), Spalte_DB2(FK))
Das kann man natürlich machen. Aber es wird nicht benötigt, da du sowieso ein Wertepaar aus Spalte_DB1 und Spalte_DB2 sowieso eindeutig sein muss.
Ich bin mir auch gerade nicht sicher, ob diese Relation dann noch der 3. Normalform entspräche.

Sollte eigentlich schon.

Wusste nicht, dass man einen Schlüssel, sowohl als Primär, als auch als Fremd definieren könnte :-)
So ist es ja auch nicht. Die Fremdschlüsselbeziehung besagt ja nur, dass der Wert einer Tabelle einen Wert einer anderen referenzieren muss, dass also die Tabelle (bzw. die Spalte), auf die der Fremdschlüssel verweist, einen solchen Wert enthalten muss.

Der Primärschlüssel definiert hingegen eine Attributmenge (also eine gewisse Anzahl von Spalten) einer Relation (Tabelle), die jeden einzelnen Datensatz der Relation eindeutig identifizieren können muss.

In diesem Zusammenhang ist ein zusammengesetzter Schlüssel(-kandidat) einfach nur die logische Konsequenz, die aus der Definition einer n:m-Beziehung folgt.

Jetzt verstehe ich was man damit meint, wenn man das (PK) dazsuchreibt.
Praktisch so etwas in der Art:
Zwischentabelle(Spalte_DB1(FK), Spalte_DB2(FK) -> UNIQUE(Spalte_DB1, Spalte_DB2))

Grüße

[Hopsel]

Hi MichiLee!

Zwischentabelle(Zwsichen_ID(PK), Spalte_DB1(FK), Spalte_DB2(FK))
Das kann man natürlich machen. Aber es wird nicht benötigt, da du sowieso ein Wertepaar aus Spalte_DB1 und Spalte_DB2 sowieso eindeutig sein muss.
Ich bin mir auch gerade nicht sicher, ob diese Relation dann noch der 3. Normalform entspräche.
Sollte eigentlich schon.

Da bin ich mir nicht so sicher.

Tabelle: ID | FK_1 | FK_2

Aus ID → (FK_1, FK_2) und (FK_1, FK_2) → FK_1 ergibt sich eine transitive Abhängigkeit von FK_1 zu ID. Dass die Abhängkeit dabei über einen Schlüsselkandidaten und eine Attributmenge erfolgt, dürfte beides nicht ausschlaggebend sein.
Aber dazu müsste mal einer der Experten hier im Forum Stellung nehmen.

Jetzt verstehe ich was man damit meint, wenn man das (PK) dazsuchreibt.
Praktisch so etwas in der Art:
Zwischentabelle(Spalte_DB1(FK), Spalte_DB2(FK) -> UNIQUE(Spalte_DB1, Spalte_DB2))

Ein Primärschlüssel ist immer UNIQUE. Und da es pro Relation auch nur einen gibt, kann man das PK getrost zu jedem Attribut schreiben, dass daran beteiligt ist. Daraus wird klar, dass diese Attribute einen zusammengesetzten Schlüssel bilden.

MfG H☼psel

[Michilee]

Hi Hospel,

Zwischentabelle(Zwsichen_ID(PK), Spalte_DB1(FK), Spalte_DB2(FK))
Das kann man natürlich machen. Aber es wird nicht benötigt, da du sowieso ein Wertepaar aus Spalte_DB1 und Spalte_DB2 sowieso eindeutig sein muss.
Ich bin mir auch gerade nicht sicher, ob diese Relation dann noch der 3. Normalform entspräche.
Sollte eigentlich schon.

Da bin ich mir nicht so sicher.

Tabelle: ID | FK_1 | FK_2

Aus ID → (FK_1, FK_2) und (FK_1, FK_2) → FK_1 ergibt sich eine transitive Abhängigkeit von FK_1 zu ID. Dass die Abhängkeit dabei über einen Schlüsselkandidaten und eine Attributmenge erfolgt, dürfte beides nicht ausschlaggebend sein.
Aber dazu müsste mal einer der Experten hier im Forum Stellung nehmen.

Habe etwas über die dritte Normalform herumgelesen. wie es aussieht, wäre das mit der ID dann NF2.

Jetzt verstehe ich was man damit meint, wenn man das (PK) dazsuchreibt.
Praktisch so etwas in der Art:
Zwischentabelle(Spalte_DB1(FK), Spalte_DB2(FK) -> UNIQUE(Spalte_DB1, Spalte_DB2))

Ein Primärschlüssel ist immer UNIQUE. Und da es pro Relation auch nur einen gibt, kann man das PK getrost zu jedem Attribut schreiben, dass daran beteiligt ist. Daraus wird klar, dass diese Attribute einen zusammengesetzten Schlüssel bilden.

vielen dank, dann ist das mir klar, wenn es eindeutig ist, dass die Schreibweise einen zusammengesetzten Schlüssel bildet.

Grüße

[Vinzenz Mai]

Hallo,

Zwischentabelle(Zwsichen_ID(PK), Spalte_DB1(FK), Spalte_DB2(FK))
Das kann man natürlich machen. Aber es wird nicht benötigt, da du sowieso ein Wertepaar aus Spalte_DB1 und Spalte_DB2 sowieso eindeutig sein muss.

Das ist ein Irrtum!

Es könnte selbstverständlich noch eine weitere Spalte für die Eindeutigkeit erforderlich sein :-)

das gleiche Element aus Tabelle A kann dem gleichen Element aus Tabelle B mehrfach zugeordnet sein, wobei ein weiteres Attribut der Zwischentabelle zwischen den einzelnen Zuordnungen unterscheidet.

Es ist völlig selbstverständlich und normal, dass die Zwischentabelle selbst weitere Attribute besitzt, die zur Zuordnung gehören.

Beispiel:

Eine Maschine besteht aus mehreren Einzelteilen.
Einzelteile können in verschiedenen Maschinen verbaut sein.
Das gleiche Einzelteil (nicht das selbe) kann in der gleichen Maschine mehrfach (an verschiedenen Stellen) verbaut sein.

Ja, das ist ein Fall, den ich in sehr relevanter Praxis erlebt habe.
Also: Das Wertepaar aus Spalte_DB1 und Spalte_DB2 *muss nicht* eindeutig sein.

Freundliche Grüße

Vinzenz

[Hopsel]

Hi Vinzenz!

Es ist völlig selbstverständlich und normal, dass die Zwischentabelle selbst weitere Attribute besitzt, die zur Zuordnung gehören.

Richtig. Das Beispiel, was du aber nennst, ist für mich ein Paradebeispiel dafür, wie ein Attribut eine Beziehung näher beschreibt. Die Eigenschaft "Anzahl der verbauten Elemente in einer Maschine" gehört somit als zusätzliche Spalte zu Assoziationstabelle, wobei der Primärschlüssel über die beiden Fremdschlüssel vollkommen ausreicht.
Das hat dann auch beim Auslesen Vorteile.

MfG H☼psel

[MichiLee]

Hi Vinzenz,

Beispiel:

Eine Maschine besteht aus mehreren Einzelteilen.
Einzelteile können in verschiedenen Maschinen verbaut sein.
Das gleiche Einzelteil (nicht das selbe) kann in der gleichen Maschine mehrfach (an verschiedenen Stellen) verbaut sein.

Ja, das ist ein Fall, den ich in sehr relevanter Praxis erlebt habe.
Also: Das Wertepaar aus Spalte_DB1 und Spalte_DB2 *muss nicht* eindeutig sein.

Wäre das dann auch in der dritten Normalform, sobald die Zwischentabelle einen Primär- bzw Identifikatiosschlüssel nach deinem Beispiel besitzt?

(Ich schaue mir heute die transitiven Abhängigkeiten mal an. Bisher habe ich es immer soweit versucht herunterzubrechen, bis keine Daten mehr redundant vorkommen)

Grüße

[Hopsel]

Hi MichiLee!

Was mir nun nicht einfällt, wie man die Schreibweise bzw. Modellierung nennt, in der man die Tabellen als Kästchen zeichnet, und drunter dann die einzelnen Spalten, die in der jeweiligen Tabelle beinhaltet sind. Unser Lehrer hatte da etwas genannt, habe es aber vergessen zu notieren. (Er hatte auf jedenfall zwischen zwei Modellierungen unterschieden)

Ich weiß nicht, ob du vielleicht auf die UML hinaus möchtest. Mit der UML kann man Datenbanken ebenso entwerfen wie mit einem ERD.

Programm wie z. B. MySQL Workbench verwenden für die grafische Darstellung eine Mischung, wie du sie wahrscheinlich meinst. Um die Übersichtlichkeit zu gewähren werden die Attribute der Entitätstypen UML-like dargestellt, also in Tabellenform innerhalb der Entitätstypen selbst.

In der UML würde man solch ein Diagramm als "Klassendiagramm" bezeichnen.

MfG H☼psel

[MichiLee]

Hi Hopsel,

Ich weiß nicht, ob du vielleicht auf die UML hinaus möchtest. Mit der UML kann man Datenbanken ebenso entwerfen wie mit einem ERD.

ich konnte gestern den Lehrer fragen, da ich ihn gesehen habe. Er unterscheidet unter 3 verschiedenen Dingern:

1. Relationenmodel
2. ER-Model
3. Relationenschreibweise

Wobei für mich 1 und 2 eigentlich dasselbe ist, außer dass man dort verschiedene Notationen anwenden kann. Er hat es aber dadurch begründet, dass das ein logisches und das andere ein physisches Model sei :-)

Grüße

[Ilja]

Wobei für mich 1 und 2 eigentlich dasselbe ist, außer dass man dort verschiedene Notationen anwenden kann. Er hat es aber dadurch begründet, dass das ein logisches und das andere ein physisches Model sei :-)

das ist mit nichten das gleiche, wie dein lehrer bereits sagte, ist das eine das logische modell und das andere das physikalische modell (streng genommen ist das physikalische auch nicht physikalisch, sondern logisch, aber aus einer anderen ebene heraus betrachtet). das physikalische ist abhängig davon, welche technik und auch welches produkt zum einsatz kommt. das E/R, also das logische, ist davon ganzz unabhängig. nicht immer wurden für das physikalische rdbms benutzt, es gab auch zeiten anderer datenbanksysteme....

Ilja

[Ilja]

moin,

Was mir nun nicht einfällt, wie man die Schreibweise bzw. Modellierung nennt, in der man die Tabellen als Kästchen zeichnet, und drunter dann die einzelnen Spalten, die in der jeweiligen Tabelle beinhaltet sind. Unser Lehrer hatte da etwas genannt, habe es aber vergessen zu notieren. (Er hatte auf jedenfall zwischen zwei Modellierungen unterschieden)

• Chen-Notation
• IDEF1X
• Bachman-Notation
• Krähenfuß-Notation
• (min, max)-Notation

oder  nachzulesen unter: http://de.wikipedia.org/wiki/Entity-Relationship-Modell. es gibt immer wieder abwandelungen davon oder mischungen.

Ilja