ER-Modell

[benschi]

Hallo!

Im Anhang befindet sich ein ER-Modell zu einer Musik-CD-Sammlung.

Am Montag ist Abgabetermin für dieses ER-Modell. Dieses Modell wird dann benotet.

Da ich mir nicht sicher bin, ob

-Die Beziehungen zueinander passen

-Dieses ER-Modell sich in der 3. Normalform befindet

-Wichtige Angaben noch fehlen

möchte ich eure Meinung, bzw. Verbesserungsvorschläge dazu hören???

Bin über jeden Beitrag sehr dankbar!

MfG

Benny

[benschi]

Hallo!

Hab mein ER-Modell etwas abgeändert - siehe Anhang!

Dann hoffe ich mal auf eine Antwort von euch!

Schönen Abend noch!

MfG Benny

[Chefe]

Passt auf den ersten Blick.

[dr.dimitri]

Hmm naja aber auch nur auf einen sehr flüchtigen ersten Blick.

Das DB Modell ist meiner Meinung nach total übernormalisiert bzw. auch falsch designed.

- Die Beziehung Lied - Format passt nicht. Ein Lied hat genau ein Format. Ist das gleiche Lied in mehreren Formaten in deiner Sammlung, dann muss es auch mehrmals aufgeführt werden. Stell dir z.B. eine Erweitung vor, mit der Du einen Playlist abbilden möchtest. Dann hättest Du keine Möglichkeit festzustellen ob die mp3 oder die flac version in einer bestimmten PL ist. Damit kann das Format als Tabelle entfallen und wird als Attribut der Tabelle Lied eingeführt.

- Das Problem, das ein Künstler sowohl eine einzelne Person als auch eine Band sein kann, würd ich so lösen: Du führst eine Zuordnungstabelle INTERPRET ein. Dort gibt es eine Spalte TYP, anhand derer Du festmachst, ob der Interpret eine Band oder eine natürliche Person ist. Ist ersteres der Fall, kannst Du direkt eine Verbindung zur Künstertabelle machen, andernfalls joinst Du zuerst mit einer neuen Tabelle BAND, in der die gewünschten Daten zur Band liegen (Gründungsjahr etc etc). Zwischen BAND und KÜNSTLER gibt es dann wiederum eine n:m Auflösungstabelle BANDMITGLIED, die einen Künstler mit einer Band verbindet. Falls gewünscht, kannst dann in BANDMITGLIEDER auch noch die Information ablegen (bzw. den Schlüssel dazu) welche Funktion diese Person in dieser Band hatte (Sänger, Schlagzeuger, Kaffeekocher etc etc.)

- Die Verbindung Album - Lied ist viel zu umständlich. Ich würde die Verknüpfung so machen:

Album Lieder 1:n

Album Interpret n:1

Album CD 1:n (evtl. hast ja ein Album doppelt, falls das nicht vorgesehen sein soll kanns CD auch weglassen)

- Die Tabelle GESCHLECHT weglassen. Das ist ein Attribut von KÜNSTLER

- Wofür ist die Tabelle LÄNDER gut? Ausserdem sollte man immer den Singular für den Tabellennamen verwenden

- Wofür ist die Tabelle ALBUMTYP?

- Die Musikrichtung würde ich an's Album hängen.

Das ist mir mal so auf den zweiten Blick aufgefallen.

Die Kunst ein gutes ER Modell zu erstellen liegt nicht darin, alles Mögliche und Unmögliche in Entitäten aufzusplitten und die Normalisierung auf die Spitze zu treiben, sondern darin, die richtige Balance zwischen Wartbarkeit, Performance und Flexibilität herzustellen.

Jede Tabelle in einem ER Modell muss später mittels Programmcode befüllt werden. Bei Änderungen an den Daten müssen entsprechende Sperren und Lockingmechanismen implementiert werden (zumindest in einer Multiuserumgebung). Damit steigt der Aufwand natürlich überproportional zur Anzahl der Tabellen - aber das wirst Du merken, wenn Du beginnst das Programm zu deinem ER-Modell zu schreiben

Dim

[benschi]

Hallo!

Also vielen Dank für die Hilfe.

Hab mein ER-Modell gestern noch etwas abgeändert bzw. verkürzt.

Stimmen die Beziehungen jetzt zueinander bzw. befindet es sich in der 3. Normalform.

Gruß Benny

[dr.dimitri]

Hmm welche meiner Anmerkungen hast Du jetzt konkret umgesetzt? Die wichtigsten Punkte sind immer noch so.

Dim

[benschi]

Hallo!

Erstmal danke für die vielen Tipps.

Scheinst dich ja wirklich gut auszukennen :-)

Hab mir jetzt deine Anmerkungen nochmals gründlich angeschaut.

Ich habe deshalb das Format aufgesplittet in einen seperaten Entitätstyp, da sonst bei der Tabelle Lied z.B. 100 mal mp3 steht. Wenn ich dann später den Formatstyp ändern möchte, muss ich das 100 mal tun, ansonsten nur einmal.

Ausserdem denke ich dass es so wie ich es habe in der 3. Normalform ist, wenn es als Attribut bei Lieder steht, denke ich nicht mehr in der 3.

Sorry, aber folgende Zeilen habe ich nicht so ganz verstanden. Habe im Anhang folgenden Text aufgezeichnet. Hoffe ich habe ihn richtig verstanden????

Dies ist der Text:

- Das Problem, das ein Künstler sowohl eine einzelne Person als auch eine Band sein kann, würd ich so lösen: Du führst eine Zuordnungstabelle INTERPRET ein. Dort gibt es eine Spalte TYP, anhand derer Du festmachst, ob der Interpret eine Band oder eine natürliche Person ist. Ist ersteres der Fall, kannst Du direkt eine Verbindung zur Künstertabelle machen, andernfalls joinst Du zuerst mit einer neuen Tabelle BAND, in der die gewünschten Daten zur Band liegen (Gründungsjahr etc etc). Zwischen BAND und KÜNSTLER gibt es dann wiederum eine n:m Auflösungstabelle BANDMITGLIED, die einen Künstler mit einer Band verbindet. Falls gewünscht, kannst dann in BANDMITGLIEDER auch noch die Information ablegen (bzw. den Schlüssel dazu) welche Funktion diese Person in dieser Band hatte (Sänger, Schlagzeuger, Kaffeekocher etc etc.)

- Die Verbindung Album - Lied ist jetzt weg.

- Die Tabelle GESCHLECHT ist weg.

- Die Tabelle Länder ist dazu gut, um zu wissen, wo sich die Labels befinden.

-Albumtyp ist jetzt auch weg

Danke für deine große Hilfe nochmals.

Schönen Abend noch!

MfG Benny

[dr.dimitri]

Ich habe deshalb das Format aufgesplittet in einen seperaten Entitätstyp, da sonst bei der Tabelle Lied z.B. 100 mal mp3 steht. Wenn ich dann später den Formatstyp ändern möchte, muss ich das 100 mal tun, ansonsten nur einmal.

Mal angenommen, Du hast 10000 Lieder. 2000 davon sind im flac und 8000 davon im mp3 Format. Wenn Du jetzt von den flacs 500 nach mp3 umkodierst, dann änderst Du doch nicht die Lookuptabelle, da ansonsten auch die restlichen 1500 flac Dateien als mp3 gelten würden.

Ausserdem ist es absolut kein Problem 100 oder 10000 Datensätze mit einem SQL zu ändern. Du brauchst in Deinem Programm eben eine entsprechende Möglichkeit das Format batchmäßig zu ändern.

Hoffe ich habe ihn richtig verstanden????

Ja hast Du. Über die Tabelle INTERPRET verzweigt dein Programm anhand des Typs links oder rechts rum und geht entweder direkt zur natürlichen Person oder erstmal zur Band, die eine Klammer um eine Gruppe von Personen bildet.

Dim

[benschi]

Ok, mir kommt das ganze auf der Zeichnung nur etwas komisch vor.

Zum einen ist eine Verbindung zwischen Künstler und Band mit einer eindeutigen Beziehung dazwischen. (Das kapier ich ja noch und ist echt gut)

Zum anderen ist zwischen Künstler und Band wieder eine Entität mit Interpret Art.

Kann es sein, dass da noch etwas fehlt???

Also wie ich das gelernt habe, muß doch zwischen Künstler und Interpretart bzw. zwischen Band und Interpretart doch eine Beziehung (Route) rein, oder bin ich jetzt total auf dem Schlauch?

Oder muss ich aus dem Rechteck Interpretart eine Route machen, so dass dies eine Zuordnungstabelle darstellt?

Aber wenn ich das wiederum mache, gibt es ja 2 Zuordnungsmöglichkeiten.

Sorry für meine lästigen Fragen, aber bin absoluter Neuling in dem Gebiet und auch kein Informatik-Student.

Dieses Modell basiert auch nicht auf SQL, sondern als Relationen Modell für Access.

Danke und Gruß

MfG Benny

[dr.dimitri]

Zum anderen ist zwischen Künstler und Band wieder eine Entität mit Interpret Art.

Nein das musst Du anders lesen.

- Ein Album hat einen Interpreten (ein Interpret kann ein oder mehrere Alben haben)

- Ein Interpret kann ein Künstler (natürliche Person) oder eine Band sein

- Eine Band besteht aus Bandmitgliedern

Mit diesem Modell kannst Du z.B. auch herausfinden, welcher Künstler in welchen Bands war (oder ob er überhaupt jemals in einer war):

Interessanter ist allerdings die Frage, ob Dein Lehrer soviel Praxiserfahrung hat, um die Flexibilität einer solchen Struktur zu erkennen.

Ach ja, da es um eine Benotung geht (hab ich glatt verdrängt) solltest Du das Musikformat vielleicht doch in eine eigene Entität verlagern, auch wenn man das in der Praxis wohl nicht so machen würde...

Dim

[benschi]

Hallo!

So, habe jetzt das ER-Modell etwas verbessert, hoffe ich :-)

Ist es so ok, oder gibt es noch Verbesserungsvorschläge?

Vielen Dank!!!

MfG Benny

[dr.dimitri]

oder gibt es noch Verbesserungsvorschläge?

Ja schon. Band und Künsler sollen weder eine direkte Verbindung zu Lied noch zu CD haben. Genau dafür ist ja die Tabelle INTERPRET da.

Wenn ich wissen will, wer ein Lied geschrieben hat, dann muss ich über INTERPRET gehen. Wenn ich wissen will, welche Künstler oder Bands auf meiner Compilation sind, muss ich ebenso über INTERPRET gehen.

Momentan verteilst deine Künstler und Band IDs auf alle möglichen Tabellen.

Der zentrale Punkt ist das Lied. Am Lied hängt die CD und der Interpret. Über den Interpret bekomme ich den Künstler bzw. die Band heraus.

Dim

[benschi]

Hab es jetzt abgeändert.

Ist es jetzt ok?

Danke!

MfG

[dr.dimitri]

Fast.

In INTERPRET gehört noch die LiedID (dafür die ART_ID aus LIED heraus).

Des weiteren produziert ein Interpret keine CD. Die Entität Produzent fehlt bei dir komplett.

Eine Produzent wäre z.B. Dieter Bohlen, der "Künstler" Marc Mattlock und das Label EMI (keine Ahnung ob das Stimmt nur mal als Beispiel).

Möchtest Du z.B. wissen, welche Band welche Lieder hat, dann kannst Du mit der bandID und dem passenden typ in der Tabelle INTERPRET selektieren und bekommst deine LiedIDs. Damit kanns wiederum in LIEB weiterselektieren und bekommst die CDs auf denen die Lieder sind. Über die CD wiederum das Label etc.

Das sind die Wege die du mit diesem ER Modell dann gehen musst um die gewünschte Information zu bekommen.

[benschi]

Hallo!

Meinst du es in etwa so? (siehe Anhang)

Gruß Benny

[dr.dimitri]

Fast. Ein Interpret produziert keine Produzenten oder? Ein Produzent produziert eine CD.

Dim

[benschi]

Stimmt hast recht :-)

Da hab ich wohl vor lauter Änderungen das wichtigste übersehen...

Ok, dann dürfte es ja so passen.

Nur eines kommt mir noch seltsam vor:

als Beispiel, zur Interpret-Art:

wenn bei dem Entitätstyp Interpret-Art bei den Attributen Art-ID, Lied-ID und Typ etwas drin steht.

z.B.

Art-ID (Primary-Key) = Laufende Nummerierung von 1 - 99999........

bei Typ steht z.B. Einzelkünstler, danach Band, danach Einzelkünstler, Band usw.

bei Lied-ID steht in der gleichen Reihenfolge die Lied-IDs zu den Liednamen

Also ich meine das gibt doch mehrfacheinträge ohne Ende und die 3 Attribute machen doch irgendwie keinen Sinn, oder?

also siehe Beispiel oben als Tabelle:

Art-ID Typ Lied-ID

1 Band 5

2 Einzelkünstler 9

3 Band 7

4 Band 5

also irgendwie kapier ich den Sinn nicht bzw. verstehe ich auch nicht wie das Fremdschlüsselfeld Lied-ID bei Interpret-Art die Beziehung herstellt.

Ausserdem kapier ich auch nicht woher die Interpretart die Beziehung zu Künstler bzw. Band herstellt, ohne Fremdschlüsselfeld von denen?

Warscheinlich ist es ganz einfach zu erklären, hoffe ich.

Ja dann vielen Dank für alles.

MfG Benny

Befindet sich jetzt eigentlich dieses Modell noch in der 3. Normalform?

[dr.dimitri]

Da hab ich wohl vor lauter Änderungen das wichtigste übersehen...

Jetzt hast aber eine neue Beziehung eingefügt. Die ist rein fachlich natürlich richtig, macht das ganze aber wieder komplexer. Ein Interpret kann mehrere Produzenten haben, und ein Produzent hat sicherlich auch mehrere Interpreten. Sprich das ganze ist eine n:m Beziehung, die durch eine Zwischentabelle aufgelöst werden muss. Entweder Du läßt die Verbindung weg, oder Du löst die n:m Beziehung auf.

Also ich meine das gibt doch mehrfacheinträge ohne Ende und die 3 Attribute machen doch irgendwie keinen Sinn, oder?

Für jedes Lied hast Du mindestens 1 Eintrag in der INTERPRET_ART (falls es ein Duett ist auch zwei - muss ja deshalb noch keine Band sein). Das ist absolut ok und widerspricht auch nicht der 3 NF.

also irgendwie kapier ich den Sinn nicht bzw. verstehe ich auch nicht wie das Fremdschlüsselfeld Lied-ID bei Interpret-Art die Beziehung herstellt.

Stell dir eine Aufgabenstellung vor, die verlangt alle Lieder zu ermitteln die eine Band gemacht hat. Du würdet mit der Band_ID und den TYP=Band auf die INTERPRET_ID selektieren und bekommst dann eine Menge X von LIED_ID. Diese kannst dann mit der Tabelle LIED verknüpfen und erhältst die Lieder dieser Band. Das ganze geht in einem einzigen SQL und nennt sich dann JOIN.

Ausserdem kapier ich auch nicht woher die Interpretart die Beziehung zu Künstler bzw. Band herstellt, ohne Fremdschlüsselfeld von denen?

Punkt für dich, das Feld hab ich glatt vergessen . Das müsstest Du noch aufnehmen. Abhängig vom Wert des Feldes TYP weiß man dann, ob man in der Tabelle Künstler oder in der Tabelle Band suchen muss.

Befindet sich jetzt eigentlich dieses Modell noch in der 3. Normalform?

Ich würd mal behaupten ja. Keine Redundanten Einträge, keine Werte, die nicht vom PK abhängen, alle Spalten enthalten atomare Werte. Außer ich hab hier was übersehen.

In der Praxis würde man natürlich spätestens jetzt beginnen dein Modell zu Denormalisieren. Sprich gezielt gegen die 3 NF zu verstoßen und Redundanzen einzuführen. Eine ER Modell in der 3 NF kann zum einen sehr komplex werden (siehst ja wieviele Tabellen eine einfache Plattenverwaltung braucht) und zum anderen ist es auch recht langsam wenn man sich durch viele Tabellen durchjoinen muss.

Dim