Lösung Altklausur WS1718.pdf

Exams
Uploaded by snape 1392 at 2019-07-14
Description:

Überarbeitete Lösung. Bei Zweifeln bitte Kommentare schreiben.

 -1
60
4
Download
genrelle Frage, aber an diesem Beispiel ersichtlich: Bei Überführungsaufgaben steht oft bei den gegebenen Tabellen der Hinweis " mit * gekennzeichnete Attribute sind Pflichtfelder", das gilt z.B. immer für die Primärschlüssel. Im Create-Statement sind diese logischerweise NOT NULL, muss man diese bei der Überführung in Relationen dann auch schon mit einem NOT NULL Constraint belegen? -> wurde hier bspw. nicht gemacht
nein primary keys sind in sql automatisch not null
Teilnehmer würde doch Schüler , Externe , MA diskriminerien eventeull hier mit Galxy Schmea erweitern?
das wären hier alles Bezugsobjekte der Dimension Teilnehmergruppe und ich glaube du meinst eine Erweiterung zu einem Snowflake-Schema, was man hier und eigentlich immer problemlos machen kann
hätte man das so auch machen könne ? Ich dachte Zeitraum wird nur eigener Entitytyp wenn dieser Primärschlüssek eines REALTIONSHIPtypen ist ? ODer irre ich mich daher könnte Zeitraum ja auch Attribut sein , da werden ja nicht wie bei einer Buchung Zeitpunkte erfasst , sondern Klausuren werden ja geplant , aber vllt irre ich mich auch und wieso die 1,1 Bezihung zu Doktor und Prod wenn von MINDestens einem die Rede ist ?
würde Zeit auch nicht als E-Typ modellieren und bei der Doktor- bzw. Professor-Beziehung hast du auch Recht, die müsste (1,n) sein
Müsste Alter nicht eine eigene Dimensionstabelle werden? Auch Kurs hat eine eigene Hierachie mit nachgelagerte Dimensionstabellen womit du zumindest ein Snowflake Schema hättest.
Hab nochmal nachgedacht: Alter als spezifischeres Attribut unter "Trainer" hinzuzufügen, wäre sinnvoll. Dimensionshierarchien können im Star-Schema in einzelnen Dimensionstabellen zusammengefasst werden oder im Snowflake-Schema ausgelagert werden. Beides möglich, beides richtig.