Datenbank Modellierung

[MidnightRun]

Hallo,

ich bin nun im dritten Lehrjahr und wir haben mit Datenbanken begonnen. Mein Ausbilder hat bereits gesagt das er gerne möchte das ich auch ein Projekt in Richtung dieser mache und da ich bis dato keine Erfahrung mit Datenbanken hatte, arbeite ich mich eben ein.

Ich habe noch ein generelles Problem mit der Modellierung sprich, ich habe das Problem und soll nun ein Datenbankdesign dazu konstruieren.

In der Schule haben wir folgende Schritte der Modellierung beigebracht bekommen.

1. Entitäten erkennen

2. Zentrale Entität bestimmen

3. Attribute bestimmen der Zentralen Entität

4. Attribute auf Teilbarkeit prüfen z.B. bei Telefonnummer Ortswahl und Telefonnummer trennen.

5. Weitere Unterentitäten erkennen und wenn anlegen. Z.B man hat eine Personen Tabelle und eine Person kann in mehrern Abteilungen arbeiten. Dann sollte man eine Tabelle Abteilungen anlegen.

6. Attribute der Subentitäten festlegen.

7. Datentypenfestlegen.

8. Beziehungen bestimmen.

Nun habe ich mir ein Buch besorgt und dort sind kleine Übungsaufgaben und leider sind keine Musterlösungen drinne. Deswegen würde ich gerne die Aufgaben hier posten und meine Lösung präsentieren und eure Meinung dazu hören ob es passt oder nicht

Es sind zu Anfang ganz simple ER Diagramme aber dennoch bin ich mir nicht so sicher.

Also Aufgabe 1 :

Ein fiktiver Online Musikshop soll erstellt werden. Eine Bestellung enthält beliebig viele CDs, wird aber von einem einzigen Kunden getätigt. Eine CD kann von mehreren Kunden bestellt werden, d.h. diese CD kann in mehreren Bestellungen enthalten sein. Jede CD ist von einem Künstler. Ein Künstler kann mehrere CDs aufnehmen.

Lösungweg :

Zuerst habe ich mir die Entitäten aufgeschrieben.

Bestellung

Kunde

CD

Künstler

Meine Zentrale Entität ist Bestellung, da es ein Shop ist und es das wichtigste ist.

Mein ERD sieht so aus :

Ein Kunde kann mehrer Bestellung haben, eine Bestellung gehört zu einem Kunden. Ist für mich eine klassische 1:n Beziehung.

Eine Bestellung kann mehrere CDs enthalten, eine CD kann in mehreren Bestellungen sein. n:m.

Bei dieser Zeichnung war ich mir nicht sicher. Eine CD ist von einem Künstler, ein Künstler kann mehr CDs aufnehmen. Habe da eine 1:n Beziehung bin aber von schreibstil beim Künstler gestarten. Ist das richtig so ?

In die RAUTEN Symbole sollen ja auch Verben rein aber ich habe da nie was anständiges hinbekommen.

KUNDE hat BESTELLUNG

BESTELLUNG enthält CD

CD enthält KÜNSTLER

So in etwa ??

Danke für euer Tipps

[kingofbrain]

Ich finde, die Entitäten und ihre Beziehungen sind korrekt. Du hast zwar keine Attribute, aber die sind laut Aufgabenstellung auch nicht gefordert.

Schöne Grüße,

Peter

[MidnightRun]

Ich finde, die Entitäten und ihre Beziehungen sind korrekt. Du hast zwar keine Attribute, aber die sind laut Aufgabenstellung auch nicht gefordert.

Schöne Grüße,

Peter

Danke Peter. Ist das den so korrekt mit der Notation was ich da mit der KÜNSTLER -> CD Beziehung gemacht habe ?

Bin zurzeit am grübeln bei der nächsten Aufgabe die es mehr in sich hat.

Eine Singlebörse soll erstellt werden.Jeder Single kann jeden anderen Single eine Nachricht schicken. Eine Nachricht hat einen Empfänger und einen Sender. Es können mehrere Nachrichten von einem Single an einen anderen Single versendet werden.

Ich würde nun vorab die Entitäten bilden :

SINGLE

NACHRICHT

EMPFÄNGER

SENDER

Da in einer Nachricht öfters der selbe Sender/Empfänger sein könnte würde ich dies auch als Entitäten definieren.

Aber wie die Beziehungen aussehen kann ich mir gerade nicht vorstellen.

SINGLE NACHRICHT wäre für mich eine 1:n. Ein Single kann mehrere Nachrichten schreiben.

Aber Nachricht setzt sich ja auch Sender/Empfänger zusammen und da würde ich ja wieder auf die Single Daten zugreifen, oder :confused:

Bin für jeden Gedankenanstoß zuhaben.

Danke

[kingofbrain]

Ich bin aufgrund der Aufgabenstellung schon auch der Meinung, dass das eine 1:n-Relation ist. 1 Künstler kann n CDs aufnehmen, die CD wird genau von 1 Künstler aufgenommen.

In Deiner zweiten Aufgabe sehe ich nur zwei Entitäten, nämlich Single und Nachricht. In meinen Augen ist das Senden und Empfangen von Nachrichten eine Relation zwischen Single und Nachricht.

Schöne Grüße,

Peter

[MidnightRun]

Ich bin aufgrund der Aufgabenstellung schon auch der Meinung, dass das eine 1:n-Relation ist. 1 Künstler kann n CDs aufnehmen, die CD wird genau von 1 Künstler aufgenommen.

In Deiner zweiten Aufgabe sehe ich nur zwei Entitäten, nämlich Single und Nachricht. In meinen Augen ist das Senden und Empfangen von Nachrichten eine Relation zwischen Single und Nachricht.

Schöne Grüße,

Peter

Danke nochmals für deine Antwort.

Was mich zu den weiteren Entitäten treiben würde ist, dass ich mir schon vorstelle wie die Daten in den Tabellen aussehn würden.

Ich habe eine Single Tabelle mit den Namen der Singles. Dann habe ich eine Nachricht Tabelle dort steht Empfänger - Sender - Nachricht drinne.

Das bedeutet das der Wert Empfänger - Sender öfters als einmal in der Tabelle vorkommen kann. Ist es nicht dann der Punkt an dem man darüber nachdenkt das Attribut auszulagern und eine Entität zuerstellen ?

Es wäre natürlich irgendwie blöd dann Empfänger und Sender auszulagern. Aber irgendwie will der Gedankengang nicht in meinen Kopp

Danke

[kingofbrain]

Den Empfänger und den Sender musst Du natürlich auslagern, aber das ist ja mit der Entität "Single" bereits geschehen. In der Entität "Nachricht" gibt es je einen Fremdschlüssel "SenderId" und "EmpfaengerId". Beide zeigen auf die Entität "Single".

Aber lass uns Deinen Fall einfach weiterdenken: Du hast also je eine Entität "Sender" und "Empfänger". Welche Eigenschaften (außer einer ID -> Primärschlüssel) haben diese Entitäten?

Schöne Grüße,

Peter

[MidnightRun]

Aber lass uns Deinen Fall einfach weiterdenken: Du hast also je eine Entität "Sender" und "Empfänger". Welche Eigenschaften (außer einer ID -> Primärschlüssel) haben diese Entitäten?

Schöne Grüße,

Peter

Hallo Peter,

genau an diesem Punkt (oben fett markiert) geht mein Konstrukt in die Brüche. Den ich denke nur daran das dort Fremdschlüssel enthalten sein können auf die Single Tabelle.

Ich beschäftige mich zurzeit nur mit der Modellierung und über PKs FKs habe ich mir nicht sonderlich viel Gedanken gemacht. Aber durch dein Beispiel wird das schon sehr deutlich.

Danke vielmals

Falls ich wieder Fragen habe werde ich diesen Thread einfach benutzen.

Wünsche dir noch einen tollen Tag

[kingofbrain]

Wenn die Empfänger- und Sender-Entität nur zur Aufnahme von Fremdschlüsseln zum Single ist, dann kann man sie sich sparen. Sie macht Abfragen schwieriger und unperformanter durch die Joins und bringt keinen Mehrwert. Aber wenn Du die Worte "Empfänger" und "Sender" im ER-Diagramm haben willst, dann bennene doch die Relationen entsprechen.

Schöne Grüße,

Peter

[MidnightRun]

Wenn die Empfänger- und Sender-Entität nur zur Aufnahme von Fremdschlüsseln zum Single ist, dann kann man sie sich sparen. Sie macht Abfragen schwieriger und unperformanter durch die Joins und bringt keinen Mehrwert. Aber wenn Du die Worte "Empfänger" und "Sender" im ER-Diagramm haben willst, dann bennene doch die Relationen entsprechen.

Schöne Grüße,

Peter

Morgen Peter,

also das es unnötig ist eine Empfänger sowie Sender Relation zuerstellen ist mir nun klar geworden. Aber was meinst du den mit dem Satz die Relationen entsprechend zu benennen ???

Vielleicht habe ich auch die falsche Begriffe im Kopf aber für mich ist eine Relation eine Tabelle und im ER Modell wird ja jede Relation als Rechteck dargestellt.

Verstehe ich da was grundlegend falsch ?

Danke

[kingofbrain]

Guten Morgen,

ja, die Relation ist einerseits die Tabelle (die ich hier konsequent Entity genannt habe), eine Relation zwischen zwei Dingen ist aber auch ihre Verbindung. Damit meine ich also die Verknüpfung der Entitäten. Man kann die Verbindung zwischen dem Single und der Nachricht benennen.

Schöne Grüße,

Peter