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.
Klausur
Hallo zusammen.
Da ich letztes Mal (u.a.) nicht in der Klausur war, würde ich gerne wissen, wie diese 1. aufgebaut ist und 2. was alles dran kommt bzw. ob was ausgeschlossen wurde. Und wenn es sonst noch was zu wissen geben sollte, wäre das auch sehr hilfreich.
Danke dafür
Gruß
Berschi
Die Klausur wird sich vorrangig an den Übungen orientieren, allerdings werden auch einzelne Definitionen aus der Vorlesung drankommen. Die einzelnen Themen werden ca. so wie in der Übung gewichtet, d.h. was in der Übung ausführlich gemacht wurde wird wohl auch einen großen Teil der Klausur einnehmen.
Stofflich ist alles relevant bis einschließlich Kapitel 12 (UML).
Hier gibts nen Braindump von letztem Jahr
https://fsi.informatik.uni-erlangen.de/dw/pruefungen/bachelor/index
Es werden auf jeden Fall die Themen drankommen, für die in den Übungen 2 Stunden spendiert wurden. Und diese werden (fast) zum bestehen ausreichen. (sinngemäß zitiert)
D.h. übersetzt: SQL und E/R werden etwa 50% ausmachen…
Außerdem ist die Klausur gedrittelt zwischen Wissen, Transfer und “Aufgabenlösung” (=praktische Aufgaben)
90 min Klausur mit etwa 90 Punkten (= 1 Punkt <-> 1 Min)
Ist das sicher? Im braindump wars ja ne 120% überhangklausur, mit 108 erreichbaren punkten.
wird auch sehr wahrscheinlich (was ich gehört habe) eine Überhangsklausur, aber 90 Pkt = 1,0, wird gesamt denk ich so 99 oder 108 pkte geben
Da ich so ziemlich keine Ahnung von der “Multidimensionalen Modellierung” habe, werd ich da mal auf gut Glück lernen und es auslassen 
die Oracle-Datenbank funktioniert leider nicht im CIP-Pool…
hat jemand eine etwas größere, ungefähr den Beispielen in Konzmod angelegte MySQL-Datenbank, die er hier bereitstellen könnte?
wäre hilfreich 
bei der oracle datenbank musst du bei den produkten im preis die kommata durch nen punkt ersetzen dann geht das. musst auch nicht alle umschreiben
wir haben gestern ein paar gemacht, findest du http://wwwcip.informatik.uni-erlangen.de/~spchsclu/PRODUKT.sql hier
Mal eine Frage zum Stoff:
Wann braucht man im E/R Modell schwache Entities genau? Die Beziehung “kann nicht ohne existieren” wird doch bei einer 1:N Beziehung mit totale Teilnahme bei N doch schon zu genüge ausgedrückt oder?
Ist der einzige Grund tatsächlich, dass man sich einen eventuellen künstlichen Schlüssel spart?
Im Prinzip schon, aber eine solche Entität hätte immer noch ihren eigenen eindeutigen Primärschlüssel und damit (rein ideell) eine eigenständige Existenz. Das Besondere an einer schwachen Entität ist gerade, dass ihr Schlüsselattribut (Partialschlüssel) nur in Verbindung mit dem Primärschlüssel der Entität, von der sie abhängig ist, eindeutig ist.
ich weiß es nicht sicher, aber eine 1:N beziehung drückt ja keine „kann nicht ohne existieren“ verbindung aus, 1:n bedeutet ja nur dass jede entity eine beziehung eingehen muss, der entitiy typ hingehen ist ja alleine identifizierbar.
ich seh das so: (s.Vorlesung) wenn du den Verwandten eines Angestellten mit SVN speichern würdest (wobei die ja selten bekannt sein dürfte) dann wäre der Verwandte eine Strong Entity mit Totaler Teilnahme an „ist verwandt mit“, wenn du hingegen nur den namen speicherst dann wird der verwandte ja erst mit dem Angestellten und dessen PK eindeutig bestimmt.
puh, bitte korregiert mich wenn ich mist schreib, bin mir jetzt selbst nicht mehr sicher…
[quote=BastiW]Wann braucht man im E/R Modell schwache Entities genau? Die Beziehung “kann nicht ohne existieren” wird doch bei einer 1:N Beziehung mit totale Teilnahme bei N doch schon zu genüge ausgedrückt oder?[/quote]Jein. Du müsstest dann noch ON DELETE CASCADE hinzufügen und du verlierst die semantische Information, dass Daten von schwachen Entity-Typen ohne deren starken Gegenüber parktisch nutzlos sind (was sich darin ausdrückt, dass der Foreign Key von schwacher Entity auf die starke Entity zum Primary Key der Tabellenabbildung der schwachen Entität gehört).
[quote=sotsoguk]puh, bitte korregiert mich wenn ich mist schreib, bin mir jetzt selbst nicht mehr sicher…[/quote]Stimmt.
Edit: OK, 3 Antworten sollten genügen 
Wenn ich jetzt habe [Krankenhaus] 1- <beschäftigt> =N [Arzt] und ich lösch eine Instanz von Krankenhaus, dann wären ja einige Ärzte ohne ein Krankenhaus, was laut Szenariobeschreibung nicht sein darf. Deswegen werden sie gelöscht nehm ich an. Also hat man damit das gleiche ausgedrückt wie wenn ich Arzt als schwache Entität von Krankenhaus modellieren würde.
Auf die gleiche Weise kann ich andersrum mit dem Beispiel von den Mitarbeiter und Verwandten argumentieren.
Warum macht man es trotzdem so und nicht anders? Ich hab diesen anscheinend feinen Unterschied immer noch nicht ganz begriffen 
[quote=BastiW]Wenn ich jetzt habe [Krankenhaus] 1- <beschäftigt> =N [Arzt] und ich lösch eine Instanz von Krankenhaus, dann wären ja einige Ärzte ohne ein Krankenhaus, was laut Szenariobeschreibung nicht sein darf. Deswegen werden sie gelöscht nehm ich an.[/quote]Nein, das müsstest du gesondert spezifizieren - es wäre auch möglich, dass ON DELETE RESTRICT gilt - dann könntest du das Krankenhaus nicht löschen, solange es noch Ärzte hat. Da schwache Entitäten nicht alleine existieren können ist ON DELETE CASCADE implizit, bei anderen Beziehungstypen nicht.
Ein schwaches Entity kann übrigens, wie von Airhardt oben angesprochen, nicht direkt angesprochen werden (im Beispiel Angestellter - Angehöriger: es könnte mehrere Angehörige mit dem gleichen Namen geben, die sich nur durch den zugehörigen Angestellten unterscheiden lassen), weil der partielle Schlüssel die Entities nicht eindeutig identifiziert.
Letztendlich ist es ja deine eigene Entwurfsentscheidung, ob du ein Entity stark oder schwach modellierst. Es kommt ja auch immer auf den Kontext an.
N=:-1 Beziehungen können später prinzipiell wie schwache Entities gemappt werden (eben wie eine M:N-Beziehung).
Schwache Entities drücken aber die Existenzabhängigkeit einfach besser aus als N=:-1 Beziehungen, weil von der Existenz einer Relationship die Existenz eines Entity nicht abhängig ist,
- Ein Arzt existiert als eigenständige Entität, d. h. er ist eindeutig identifizierbar auch ohne das Krankenhaus zu kennen, in dem er angestellt ist. Auch könnte er problemlos seinen Arbeitsplatz wechseln und in einem anderen Hospital anfangen.
- In der Praxis wird man sich überlegen, ob man bei totaler Partizipation die Aktion beim Löschen wirklich auf CASCADE setzt, oder ob man doch lieber den Constraint aufweicht, indem man SET NULL wählt. Die dadurch entstandenen Inkonsistenzen (ein Arzt kann temporär NULL als Arbeitsplatz haben) könnte man dann per Hand auflösen. Das zugrunde liegende ER-Schema ist meiner Meinung nach nichts Heiliges und Unantastbares, das man beim relationalen Mapping unbedingt strikt wörtlich befolgen muss, auch wenn Details sich als unpraktikabel herausstellen sollten.
das ist bullshit, auch schwache entities können relationships zu anderen entities haben… Eine schwache entity würd ich für klausurzwecke nur modellieren, wenn kein Schlüsselattribut angegeben ist, schliesslich soll man nichts dazuerfinden, in diesem Fall einen nötigen Surrogatschlüssel zur eindeutigkeit.
Und vor allem wenn du den Arzt als schwcahe entity modellierst obwohl er ein eindeutiges Schlüsselattribut hast, dann schränkst du die gegebene modellierungsvorschrift ja ein. Denn schwache entity bedeutet, sie ist nur in kombination mit dem Key des Ownertyps identifizierbar. Der Arzt ist aber alleine eindeutig identifizierbar.
ups, stimmt, fail meinerseits.
hab da gerade an komplexe attribute gedacht (zu denen man eine schwache entity umbauen kann)