Braindump Sommersemester 2012
Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
SQL Anwendung, Relationenmapping
Guten Abend!
Ich habe eine Frage bezüglich der SQL Aufgabe auf dem Braindump vom Sommersemester’12 (https://fsi.informatik.uni-erlangen.de/dw/_media/pruefungen/bachelor/braindump_ss12.pdf?id=pruefungen%3Abachelor%3Aindex&cache=cache).
Direkt die 5.1
Verstehe ich die Auswertung richtig, wenn ich davon ausgehe, dass m1 die linke Spalte der Matrix ist und m2 die rechte (Also m1 Quasi in der Tabelle bei Spalte immer 1 stehen hat und m2 immer 2).
Denn ungefähr so habe ich meine Auswertung aufgebaut, was mir dann am Ende (Nach meiner Logik zumindest) eine Tabelle mit Zeile und Wert gibt, die so aussieht:
Zeile Wert
1 1,5
1 2,5
2 3,5
2 4,5
3 5,5
3 7,5
Hab ich das richtig verstanden oder komplett verhauen?
Außerdem habe ich noch eine Frage zum Relationenmapping (3).
Ich konnte in den Folien von KonzMod nichts eindeutiges finden und daher dachte ich stelle ich mal meinen Lösungsvorschlag vor.
Ich bin mir sicher, dass das falsch ist, da ich mit der Angabe wenig anfangen konnte. Vor allem Punkte wie “aKey[A]” - Wofür steht das in den eckigen Klammern z.B.?
Möchte sich jemand erbarmen und mir die Syntax erklären oder einen Link wo ich mehr darüber erfahren kann geben? Das wäre schön.
Viele Grüße und schon mal danke!!
Zeile a b
1 1,5 2,5
2 3,5 4,5
3 5,5 7,5
sollte da meiner Meinung nach rauskommen. Du kannst dich aber auch einfach zu einem db server verbinden und das testen.
Zum ER-Diagramm das in eckigen Klammern soll ein Fremdschlüssel sein ansonsten enthalte ich mich da mal 
Hallo,
ich habe mich mit diesem Braindump ebenfalls bereits beschäftigt, ich versuche mal zu antworten,
aber alle Angaben sind wie immer ohne Gewähr=)
Beim Relationenmapping habe ich das ganze wie folgt aufgefasst:
A ist ein Entity-Typ. Das heißt man muss das in ein RECHTECK zeichnen ( und nicht in einen Kreis…).
A hat den Schlüssel akey. Also zeichnet man in ein OVAL das Attribut akey und unterstreicht es.
dann hat es noch ein ganz normales ATtribut aAtt, das schreibe ich einfach nur in ein OVAL OHNE es zu unterstreichen,
beide Atrribute verbinde ich natürlich mit dem Rechteck von A.
Das gleiche gilt dann analog für B und C.
D scheint mir ein Beziehungstyp zu sein, ich zeichen es also in eine RAUTE.
In der Angabe scheint mir zwischen ckey[C] und dAtt ein Komma zu fehlen.
dAtt ist wohl ein Attribut von diesem Beziehungstyp, also zeichne ich dAtt in ein OVAL und verbinde es mit der Raute.
Was man jetzt mit
genau anfängt, kann ich grad auch nicht sagen.
Da im Primärschlüssel von D nur aKey und bKey vorkommen, könnte es sein, dass das irgendwas mit ner funktionellen Abhängigkeit zu tun hat.
Also, für ein Kombination aus A und B scheint C schon einwandfrei bestimmt zu sein, da würde ich bei C mal als funktionelle Abhängigkeit ne 1 hin schreiben.
Was heißt eigentlich
?
Heißt das, dass sowhol akey als auch ckey eindeutig sind, oder nur die KOMBINATION aus beiden?
Wenn die Kombination aus A und C eindeutig ist, könnte es heißen, dass man auch bei B als funktionale Abhängigkeit
ne 1 hin schreiben kann, oder?
Denn durch die Kombination aus A und C ist ja dann das Tupel eindeutig bestimmt, B ist Not Null, damit ist dann auch B bestimmt, denke ich.
Was ich zu diesem Braindump noch anmerken wollte:
Bei der 5.2 c) heißt es
Wenn ich da hinschaue sind für mich nicht nur drei sondern alle Werte gleich…
Und bei der 7.1:
Müsste da nicht irgendwas von A B C oder D unterstrichen sein, als Schlüssel?
So weit von mir.
beste Grüße
s)
Kombination. Rest der Frage ka hab ich nicht angeschaut 
5.2 c) Ist nur beispielhaft und ändert nichts an dem SQL-Befehl den du schreiben sollst.
7.1 Bin ich mir nicht ganz sicher, aber ich denke es soll einfach nur heißen, dass die darunterstehenden Relationen (also ABD → C,C …) vollständig sind.
Ich bin mir ebenfalls nicht ganz sicher, aber das was da unten steht sind dachte ich keine Relationen
sondern funktionale Abhängigkeiten. So weit ich weiß, braucht man zur Bestimmung der Normalform
immer den Primärschlüssel.
NACHTRAG: Wie man die letzte Aufgabe zu UML mit den Traces bearbeiten soll, ist mir ein völliges Rätsel, ich bin für jegliche Tipps dankbar!
Braucht man da nicht nur irgendwelche Schlüsselkandidaten?
Bei der Aufgabe 3 sieht mir die Beschreibung der Relation D ziemlich nach einem ternären 1-1-N-Beziehungstyp aus. Die N steht vermutlich bei a, die 1 bei b und c. Dann würde ich noch über NOT NULL und PRIMARY KEY die totale Teilnahme auslesen und dann muss man nur noch über UNIQUE und PRIMARY KEY die Kardinalitäten ergänzen.
Kann außerdem bitte jemand meine Lösung zur 7.1 kontrollieren?
- Normalform müsste bei den Beispielen eigentlich immer erfüllt sein, denn man kann ohne konkrete Tabellen immer annehmen, dass die Eigenschaften der 1. NF nach Skript 6 Folie 19 erfüllt sind.
Bei den Abhängigkeiten ABD => C, C => D bin ich mir nicht sicher, was da passiert, BCNF ist es sicherlich nicht (von C hängen A und B nicht ab) und auch die 3. NF ist es nicht (D hängt von ABD transitiv ab). Ich tipp mal auf 2. NF, auf Anhieb sehe ich da keine Verletzung.
Bei den Abhängigkeiten AB=>C, AB=>D, B=>D ist unter der Annahme, dass keine weiteren Attribute existieren, jedes Attribut bis auf A und B von AB funktional abhängig. Also kann AB als Superschlüssel definiert werden. Die Abhängigkeit B=>D verletzt somit die 2. NF (analog zu Skript 6 Folie 22).
Bei AB=>C, AB=>D, C=>D ist D ist AB analog ein Schlüsselkandidat. Die 2. NF ist auch erfüllt, da weder C noch D von A oder B abhängen, ohne, dass sie von AB abhängen. D ist aber transitiv abhängig von C, also fällt die 3. NF weg (siehe Skript 6 Folie 24). Die 3. NF ist also nicht erfüllt.
Ich bitte darum, dass mir jemand bei der Aufgabe 6 auf die Sprünge hilft.
Ich habe bislang:
Region( RegionID , Straße, PLZ)
Alter (AllterID, Monat, Jahr)
Bevölkerung (Zeitraum [Zeitraum], Alter [Alter], Region [Region], Anzahl)
Zeitraum ( ZeitID , ???)
Ist das einigermaßen richtig oder völlig falsch??
Und wie ich beim Zeitraum mit den verschiedenen Konsolidierungspfaden umgehen soll, ist mir völlig schleierhaft!
Ich bin für jegliche Tipps dankbar!
Kann man das Ganze vllt. so modellieren?
Region (RegionID, Straße, PLZ)
Alter (AlterID, Monat, Jahr)
Zeit (ZeitID, 5-Jahres-Raum-ID [5-Jahres-Raum])
Bevölkerung (ZeitID [Zeit], AlterID [Alter], RegionID [Region], Anzahl)
5-JahresRaum (5-Jahres-Raum-ID, 10-Jahres-Raum, 25-Jahres-Raum)
Oder doch eher so?
Region (RegionID, Straße, PLZ)
Alter (AlterID, Monat, Jahr)
Zeit (ZeitID, 5-Jahres-Raum, 10-Jahres-Raum, 25-Jahres-Raum)
Bevölkerung (ZeitID [Zeit], AlterID [Alter], RegionID [Region], Anzahl)
Vermute eher Letzteres.
Kannst Du mir mal erklären, wie man da die totale Teilnahme auslesen kann?
Ich begreife es nicht.
Denn NOT NULL und PRIMARY KEY beziehen sich ja auf eine TABELLE. Selbst wenn dort not null
gilt, heißt es ja noch lange nicht, dass auch ALLE Instanzen eines Entity-Typs dort eingetragen werden…
In der Zwischenzeit mache ich mich über Chayyams Vorschläge zur 7.1=)
NACHTRAG: Ich konnte dort nichts falsches entdecken, außer
Moment, wenn ich doch AB kenne, kann ich doch daraus einwandfrei A und B bestimmen=)
Somit sind doch, auch wenn es komisch klingt, A und B von AB funktional abhängig, oder?
Sonst konnte ich keine Fehler entdecken.
Und ich denke ihr habt Recht, es muss tatsächlich kein Primärschlüssel angegeben sein.
Stimmt, das mit totaler Teilnahme ist Blödsinn. Die Lösung steht in fast derselben Form im Skript zu Mapping auf Folie 30.
Ich wünsche mir nach wie vor, dass mal jemand schreibt,
wie man die letzte Aufgabe mit UML und den Traces lösen soll,
ist mir nämlich schleierhaft.
Soll man da ne gestrichelte Linie einzeichnen und dann bestimmen ob es sequentiell
oder parallel ist ? Oder bin ich hier komplett auf dem Holzweg?
Bei allen gültigen Schritten kommt nach x direkt ein y. Insofern wäre ein strict über x und y eine Methode, um den Trace b->x->a->y zu blockieren. Dann treten bei allen gültigen Schritten x und y später als b auf. Wir sollen also verhindern, dass y vor b auftaucht. Dass kann z. B. mit einem seq über b, x und y gewährleistet werden. Dann wird auch der Trace a->x->y->b blockiert.