1926100

Diese Prüfung wird nicht mehr angeboten.
 

Nummer	1926100
Studiengang	Interaktive Medien (IAM 2006)
Modul	Datenmanagement
Lehrveranstaltung	Datenmanagement II
Alternativname	Multimedia-Datenbanken, MMDB
Kürzel	i4.DATA
Prüfer
Zweitprüfer
Prüfung	Diese Prüfung wird nicht mehr angeboten.
Prüfungsart	Onlineklausur
Details	Dauer: 180 Min
Hilfsmittel

Termine

15. März 2017:

Anmeldung zur Teilnahme an der Wiederholungsprüfung über Moodle. Achtung: Zur eigentlichen Prüfung müssen Sie sich außerdem noch zwischen dem 28. 4. und 12. 5. 2017 über den Verwaltungsserver der HS Augsburg anmelden.

30. März 2017:

Abgabe der Anwendungsfälle (Use-Cases) via Repository und Link in Moodle)

6. April 2017:

Abgabe des Datenmodells: ER-Diagramm (als UML-Klassendiagramm) + relationales Schema + SQL-Schema
Modelle und relationales Schema als JPG, PNG oder PDF sowie SQL-Schema (CREATE-TABLE-Befehle) als UTF-8-Text im Repository, Link in Moodle

23. April 2017:

Abgabe der vollständigen Studienarbeit einschließlich einer Erstellungserklärung (via Repository und Link in Moodle)

21. April 2017, 14:00 – 17:00 Uhr:

Prüfungspraktikum

25. und 28. April 2017, J2.10 (die genauen Termine liegen noch nicht fest):

Präsentation der Ergebnisse. Sie müssen Ihre Anwedung erklären und Ihre Anwendung demonstrieren können. Sie brauchen keine Präsentations-Folien vorzubereiten.

Beachten Sie, dass in dem Dokument Erstellungserklärung auch eine Abgabeliste enthalten ist, in der genau aufgelistet wird, was Sie in welcher Form abgeben müssen.

Darüber hinaus müssen Sie im Laufe des Semesters regelmäßig den aktuellen Stand Ihrer Arbeit im SVN-Repository, das Ihnen am Anfang des Semesters zur Verfügung gestellt wurde, zwischenspeichern. Das heißt, vor jeder Zwischenabgabe müssen mindestens 5 Versionen der abzugebenden Dokumente ins Repository eingefügt werden. Von der eigentlichen Implementierung der Studienarbeit müssen vor der Endabgabe jeweils mindestens 20 substanziell verschiedene Versionen von jedem Gruppenmitglied ins Repository eingefügt werden.

Studienarbeit

Als Teilnehmer der Lehrveranstaltung „Datenmanagement II“ („Multimedia-Datenbanken“, MMDB) sollen Sie nachweisen, dass Sie in der Lage sind, für eine (reale oder fiktive) Anwendung eine komplexere Relationale Datenbank zu erstellen.

Sie müssen daher im Rahmen einer Studienarbeit eine Relationale Datenbank gemäß den in der Vorlesung vermittelten Prinzipien modellieren und realisieren. Am Ende des Semesters müssen Sie Ihre Arbeit präsentieren. Sie können sich das Thema (in Absprache mit mir) selbst aussuchen.

Sie können die Studienarbeit auch als Zweier- oder Dreier-Teams realisieren. In diesem Fall muss die Arbeit allerdings aus mehreren eigenständigen Teilen bestehen. Jedes Teammitglied ist für die Modellierung und Realisierung eines dieser Teile verantwortlich. Jedes Teammitglied muss einen angemessenen Teil des Datenmodells erstellen, einen angemessenen Teil der Anwendung implementieren sowie selbstständig (d.h. nicht in Teamarbeit) eine Studienaufgabe bearbeiten.

Beachten Sie, dass Sie im Falle einer Wiederholungsprüfung eine vollkommen neue Arbeit erstellen müssen.

Bewertung der Studienarbeit

In die Bewertung der Studienarbeit fließen ein:

• Inhalt
  • ER-Diagramm in UML-Notation
    • Korrektheit (insbesondere bzgl. Use Cases)
    • die Beschreibung der Klassen und Attribute
  • Relationenschema
    • die Korrektheit bezüglich des ER-Diagramms
  • SQL-Schema (CREATE TABLE)
    • die Korrektheit bezüglich des ER-Diagramms
  • Beispielsdaten (INSERT)
    • alle für die SQL-Anfragen wesentlichen Spezialfälle werden hinreichend im Datenbestand repräsentiert (1=sehr gut, ..., 5=mangelhaft)
  • SQL-Statements der Beispielsanwendung
    • Korrektheit
    • Angemessenheit (d.h., die Anfragen, Insert-, Update- und/oder Delete-Statements sollten für die Implementierung der Use Cases geeignet sein)
• Qualität und Umfang
  • Qualität und Komplexität der Use Cases
  • Qualität und Komplexität des ER-Diagramms (komplexere Beziehungen, Attribute mit Nullwerten, ISA-Vererbung etc.)
  • Qualität und Komplexität der SQL-Implementierung
    • Komplexität: Es müssen Anfragen, die über einfache Equijoin-Anfragen hinausgehen, vorhanden sein. Dabei müssen mindestes fünf unterschiedliche Problemgebiete behandelt werden:
      • Aggregation
      • Gruppierung
      • Subqueries in Select-Statements
      • Insert-/Delete-/Update-Befehle mit Subqueries
      • Outer Joins
      • 3-wertige Logik (Null-Werte)
      • Durchnummerierung von Ergebnissen (Windowing)
      • Es-gibt-ein-/Für-alle-Anfragen
      • komplexe Views
      • Volltextsuche
      • Rekursive View, d.h., View, die sich selbst aufrufen
      • Trigger
      • etc.
    • Umfang (1=angemessen, ..., 5=viel zu wenig)
      • Ein Diagramm mit vier oder fünf Klassen ist, sofern hinreichend komplexe Beziehungen vorhanden sind, vom Umfang her angemessen.
      • Diagramme mit 10 oder mehr Klassen (pro Person) gehen deutlich über die Anforderungen hinaus.
      • Der Umfang der Beispieldaten muss nicht groß sein, es kommt nur auf die Angemessenheit der Daten an.
      • 10 bis 15 SQL-Statements (Select, komplexe Updates, Volltextsuche, Trigger etc.) pro Person (namentlich gekennzeichnet!) reichen vollkommen aus, d.h., es müssen nicht unbedingt alle Use Cases umgesetzt werden. Circa die Hälfte der Statements sollte komplexerer Natur sein (komplexer als Select/Project/Equijoin).
• Prüfungspraktikum
  • Qualität der Lösungen des Prüfungspraktikums (1=sehr gut, ..., 5=mangelhaft)
• Form
  • Lesbarkeit (inbesondere der SQL-Dateien und der Diagramme)
  • Inline-Dokumentation (der komplexen SQL-Statements)

Die Bewertung einer der Hauptkatgorien als mangelhaft führt dazu, dass die gesamte Arbeit als mangelhaft bewertet wird.

Die Bewertung der SQL-Statements als mangelhaft führt dazu, dass die gesamte Arbeit als mangelhaft bewertet wird.

Die gesamte Arbeit wird als mangelhaft bewertet, sobald auch nur ein Plagiat enthalten ist.

Die Arbeit wird als unvollständig und damit als nicht abgegeben gewertet, wenn eine der Zwischenabgaben nicht erfolgt ist.

Die Arbeit wird als unvollständig und damit als nicht abgegeben gewertet, wenn ein wesentlicher Bestandteil fehlt, d.h., wenn in der Abgabeliste im Anschluss an die Erstellungserklärung eine wesentliche Frage mit nein beantwortet wurde oder wenn die Erstellungserklärung samt Abgabeliste fehlt.

Die Arbeit wird als unvollständig und damit als nicht abgegeben gewertet, wenn die grobe Enstehungsgeschichte der Arbeit nicht anhand der Besprechungen im Praktikum oder anhand der Versionen im SVN-Repository nachvollzogen werden kann (entweder regelmäßige Teilnahme am Praktikum oder mindestens 5 einschlägige Updates vor jeder Zwischenabgabe und anschließend mindestens 10 einschlägige Updates vor der Endabgabe).