Normalform Aufgaben

[Hony%]

2. Zu jeden Bestellung gehört doch eine Kaffeemaschine, da der Hersteller nur diese anbietet. Die Kardinalität vom Zubehör habe ich auf (0,n)/(0,n) geändert, da nicht jede Bestellung Zubehör enthält.

Richtig. Zu jeder Bestellung gehört eine Maschine und ggf. Zubehör. Der Fall einer Bestellung von nur Zubehör wird nicht verlangt. Aber nicht jede Maschine oder jedes Zubehör müssen auch tatsächlich mindestens einmal bestellt worden sein.

Eine brandneue Maschine ist bereits verfügbar aber es gibt noch keine Kunden? Trotz deiner Änderung brauche ich aber eine Bestellung für jede verfügbare Maschine. Daher muss gelten: Kaffemaschine(0,n)/(1,n) Bestellung

3. Kann das durch ein einfaches Attribut Betriebszeit gelöst werden? Ich frage mich gerade ob ich das bei der Wartung mit einbinde, dort kann es ja erst ausgelesen werden.

Die Betriebszeit gehört ganz klar zur Maschine. Viele professionellen Geräte wie Kopierer oder auch Gabelstapler besitzen dafür eine Anzeige. Sogar mein Fernseher kann mir sagen wie viele Betriebsstunden er hat.

Wird die Wartung hingegen zyklisch vorgenommen wie beim TÜV ist der Termin der letzten Prüfung/Wartung relevant und gehört dann auch zur Wartung. Da fragt aber auch niemand danach ob du 5.000 oder 50.000km seit der letzten Prüfung gefahren bist. Meiner Meinung nach also implizit nicht leistungsbezogen.

 

[hhbr89]

Die Betriebszeit gehört ganz klar zur Maschine. Viele professionellen Geräte wie Kopierer oder auch Gabelstapler besitzen dafür eine Anzeige. Sogar mein Fernseher kann mir sagen wie viele Betriebsstunden er hat.

Würde das nicht bedeuten das genau einer Maschine (z.B. mit m_nr) immer nur ein Wert zugeschrieben wird? Müsste man nicht eine Relation aus Bestellung und Maschine herstellen und die Zeit genau einer Maschine aus eben dieser Bestellung zuzuordnen, oder denke ich wieder verkehrt?

Habe noch eine Übung bei der ich mir mit der 3NF nicht ganz sicher bin. Hoffe das kann ich noch in diesen Thread packen.

Erstellen Sie für die Daten, die in einem Notenauszug der UNI enthalten sind, eine normalisierte Relation. Überführen Sie diese Relation schrittweise in die dritte NF.

 

[Hony%]

Würde das nicht bedeuten das genau einer Maschine (z.B. mit m_nr) immer nur ein Wert zugeschrieben wird? Müsste man nicht eine Relation aus Bestellung und Maschine herstellen und die Zeit genau einer Maschine aus eben dieser Bestellung zuzuordnen, oder denke ich wieder verkehrt?

Ich denke dein Hauptproblem ist die ungeschickte Struktur. Du ordnest alles um die Bestellung. Kaufmännisch mag das sinnvoll sein, da hier der Fokus liegt. Allerdings spielt hier die Wartung nur eine untergeordnete Rolle.

Versuch doch einfach die Kaffeemaschine ins Zentrum zu setzen. Über die "Seriennummer" der Maschine lässt sich die Bestellung identifizieren. Und damit das Kaufdatum und die Garantiezeit. Auf diese Art kannst du auch n Maschinen an 1 Bestellung knüpfen.

Gleichzeitig kannst du aber jeder einzelnen Maschine eine Betriebszeit zuordnen die wiederum für die Wartung ausschlaggebend ist.

Erstellen Sie für die Daten, die in einem Notenauszug der UNI enthalten sind, eine normalisierte Relation. Überführen Sie diese Relation schrittweise in die dritte NF.

Wie willst du aus der Note die Prozente wiederherstellen?

 

[hhbr89]

Stimmt, das mit der Maschine im Mittelpunkt klingt nach einer vernünftigen Lösung. Ich habe dummerweise nach der Aufgabenstellung das ERM aufgebaut. Werde das auf jeden Fall nochmal so anordnen.

Ohhh das ist natürlich Blödsinn, ich muss Prozente mit Note in Notenliste vertauschen. Ist dann die 3NF erreicht? War mir bei der 2NF nicht ganz sicher ob die eventuell schon der 3NF entspricht, das mit der transitivität habe ich noch nicht zu 100% verinnerlicht.

 

[Hony%]

Ist dann die 3NF erreicht? War mir bei der 2NF nicht ganz sicher ob die eventuell schon der 3NF entspricht, das mit der transitivität habe ich noch nicht zu 100% verinnerlicht.

R=(_A_,B,C) A->B; B->C

Diese Relation entspricht der 2.NF aber nicht der 3.NF, da C von Schlüssel A transitiv abhängig ist.

R=(_A,B_,C,D) A->B,D; B->C

Hier ist die 2.NF verletzt, da B nur ein Teilschlüssel ist.

Wenn eine Relation einen Einzelschlüssel hat und alle Attribute von diesem einen Schlüssel abhängen ist die 2.NF immer erreicht.

Das Problem mit deinem PDF ist, dass nicht ersichtlich ist welche FA gelten. Daher wäre eine Angabe der Relationenschema sowie der FA am hilfreichsten.

Ist z.B. CrP von Fachbez. abhängig? Dann ist die 3.NF nicht erreicht.

 

[hhbr89]

R=(_A_,B,C) A->B; B->C

Diese Relation entspricht der 2.NF aber nicht der 3.NF, da C von Schlüssel A transitiv abhängig ist.

R=(_A,B_,C,D) A->B,D; B->C

Hier ist die 2.NF verletzt, da B nur ein Teilschlüssel ist.

Wenn eine Relation einen Einzelschlüssel hat und alle Attribute von diesem einen Schlüssel abhängen ist die 2.NF immer erreicht.

Das Problem mit deinem PDF ist, dass nicht ersichtlich ist welche FA gelten. Daher wäre eine Angabe der Relationenschema sowie der FA am hilfreichsten.

Ist z.B. CrP von Fachbez. abhängig? Dann ist die 3.NF nicht erreicht.

Was transitiv bedeutet hatten wir schon in einem Fach davor, mir fällt es nur ab und zu schwer das auch anzuwenden. Aber da Credit Points abhängig vom Fach sind, müsste das ja bedeuten das ich für die 3NF noch eine Tabelle Creditpoints erstellen müsste?

R(Crp_ID, CrP, Fachbez)

Was meinst du mit FA? Fremdattribute, funktionale Abhängigkeit? Da es in der Übung nicht angegeben ist, lasse ich es vorerst mal weg, üben kann ich es danach immer noch.


Anbei nochmal eine Übung (Chen Notation).

 

[Hony%]

Was transitiv bedeutet hatten wir schon in einem Fach davor, mir fällt es nur ab und zu schwer das auch anzuwenden. Aber da Credit Points abhängig vom Fach sind, müsste das ja bedeuten das ich für die 3NF noch eine Tabelle Creditpoints erstellen müsste?

Das ist jetzt ein bisschen "weich". Du hast jedem Fach eine ID zugewiesen. Kannst du über die ID direkt die CrP bestimmen besteht eine FA und die 3.NF ist gegeben.

Frage dazu: Brauchst du die ID oder ist die Fachbez. eindeutig?

Was meinst du mit FA? Fremdattribute, funktionale Abhängigkeit?

FA ist bei mir eine Funktionale Abhängigkeit.

Anbei nochmal eine Übung (Chen Notation).

Zu welchem Problem? Was sind Mitglieder? Verwaltung? PR? Sind die Mitglieder vielleicht sogar schwache Entitäten und von Band abhängig?

 

[hhbr89]

Zu welchem Problem? Was sind Mitglieder? Verwaltung? PR? Sind die Mitglieder vielleicht sogar schwache Entitäten und von Band abhängig?

Ich vermute mal das die Kursbez. eindeutig ist, daher kann ich es als primärschlüssel nutzen und habe keine t. abhängigkeit

Sorry vergessen... :/


Gegeben ist folgender Sachverhalt:Es soll die Zusammensetzung von Musik-Bands sowie ihre Buchung für Events in einer Datenbank abgespeichert werden.Zu jeder Band sind der Name, die Standard Abendgage und die vertretenen Musik Stile (mehrere pro Band möglich) abzuspeichern. Letztere sind als Liste in einer getrennten Tabelle zu speichern und von
den Bands aus zu referenzieren.

Jede Band besteht aus mehreren Musikern, die ebenfalls mit ihrem Namen in einer eigenen Tabelle abzuspeichern sind. Bei der Zugehörigkeit eines Musikers zu einer Band ist das Instrument (bzw. Gesang) abzuspeichern. Es ist zu beachten, dass Musiker auch zu mehr als einer Band gehören können.Sowohl zu Musikern als auch Bands ist jeweils genau ein Manager mit Namen und Anschrift anzugeben, der auch für mehrere Künstler zuständig sein kann.

Die Bands werden für Events gebucht (auch mehrere Bands pro Event), für die jeweils ein Name, der Ort und das Datum anzugeben sind.Zeichnen Sie dazu ein vollständiges ERDiagramm (inkl. aller Attribute und Kardinalitäten. Überflüssige Entitätsmengen sind zu vermeiden.

 

[Hony%]

Anbei nochmal eine Übung (Chen Notation).

Im Diagramm fehlt die Bandzugehörigkeit vollständig.

Warum vergibst du überall eine ID? Gibt es keine anderen, ggf zusammen gesetzte, eindeutige Schlüssel?

 

[hhbr89]

Da hapert es noch manchmal mit den zusammengesetzten Schlüsseln bzw. schon vorhandene Schlüssel.

Bandzugehörigkeit habe ich jetzt mit einem Beziehungstyp gelöst der ein Attribut enthält.

 

[Hony%]

Da hapert es noch manchmal mit den zusammengesetzten Schlüsseln bzw. schon vorhandene Schlüssel.

Manager/Musiker gleichen Namens unter gleicher Anschrift kann ich mir gut vorstellen. Aber mehrere gleichnamige Events am gleichen Tag und Ort?

Ansonsten sehe ich die Aufgabe als erfüllt.

 

[hhbr89]

Darf man im ERM denn mehrere Attribute zu einem Schlüssel zusammen setzen? Sprich bei Event Name + Datum? Habe ich so noch nie in einem ERM gesehen.

 

[Hony%]

Darf man im ERM denn mehrere Attribute zu einem Schlüssel zusammen setzen?

Warum sollte das nicht gehen? Nach der mir geläufigen Definition besteht ein Schlüssel aus einer Menge von Attributen die jede Instanz eindeutig identifizieren.

 

[hhbr89]

Habe einfach noch kein ERM in der Form gesehen. Aber wenn das geht, ist es ja gut. Ich denke mal wenn es mein Prof. in der Klausur ausdrücklich verlangt werde ich es so machen. Andernfalls ist es glaube ich schneller und einfacher eine ID zu hinterlegen. Außer du sagst jetzt das es schlicht und einfach falsch wäre, dann nehme ich mir gerne die Minute

 

[Hony%]

Außer du sagst jetzt das es schlicht und einfach falsch wäre

Dein ERM lässt Events mit gleichem Namen, Ort und Datum zu. In der Aufgabe wurde nicht gefordert, dass ein Event einzigartig sein muss. Daher ist die Aufgabe formal erfüllt.

Im Grunde kann man in dem Fall aber vom Bruch einer physikalischen Funktionalen Abhängigkeit ausgehen. Daher könnte dein Prof die Lösung als falsch werten.

Vielleicht findest du bei OpenHPI noch einige Anregungen: https://openhpi.de/course/sql