#### Modellierung:

Modellierung: Krankhaus - liegtIn - Kreis fehlt komplett (-2)
Modellierung: gestorben an Corona unabhängig von Krankenhäusern fehlt, so können nur Fälle in Krankenhäusern gezählt werden (s. Beispiel Fritz Müller) (-1)
Modellierung: gestorben an Corona fehlt komplett (-1.5)
Modellierung: CoronaTodesfälle an Krankenhaus+Person: okay.
Modellierung: Es kann nicht unterschieden werden, ob jemand im Krankenhaus gestorben ist oder am selben Tag zuhause. (-0.5)
Modellierung: Zusammenfassen von Tests und Sterbefällen führt dazu, dass man nicht mehr an einem anderen Datum sterben kann als getestet wurde oder umgekehrt. (-1)

Kardinalitäten:

Kardinalität: Testergebnis-getestet muss <1,1> sein. Ein Testergebnis kann nur für eine Person verwendet werden und wird nicht ohne zu testende Person erstellt (-0,5)
Kardinalität: Person-getestet kann mehrere oder überhaupt keine Tests gemacht haben, deshalb <0,*> (-0.5)
Kardinalität: gestorbenAn - CoronaTodesfall hat die Kardinalität <1,1>, jeder Todesfall bezieht sich genau auf eine Person. (-0,5)
Kardinalität: Person - GestorbeAn muss eine Kardinalität von <0,1> haben. Glücklicherweise sind nicht alle Personen in der Datenbank schon tot, aber mehrfach stirbt auch keiner. (-0.5)
Kardinalität: Krankenhaus - liegtIn muss <1,1> sein, irgendwo muss es ja sein, aber auch nur an einem Ort. (-0,5)
Kardinalität: Ein Kreis- liegt in kann beliebig viele Krankenhäuser (auch gar keines) haben also <0,*> für Kreis - liegtIn (-0.5)
Kardinalität: “Person - behandelt” muss <0,*> sein. Eine Person kann mehr als einmal oder gar nicht (wie die meisten Coronafälle) ins Krankenhaus kommen, s.Beispiel Karl Napf (-0.5)
Kardinalität: behandelt - Krankenhaus muss <0,*> sein, jedes Krankenhaus kann beliebig viele Coronapatienten haben (auch überhaupt keine) (-0.5)

Attribute:

Attribut: behandelt-Sterbedatum fehlt, damit klar wird ob die Person im Krankenhaus und nur am selben Tag verstarb (-0,5)
Attribut: "Tage in der Intensivstation" fehlt (-0.5)
Attribute: Entlassungsdatum fehlt (-0.5)
Attribute: Alle fehlen (8*-0.5)
Attribut: Krankenhaus-Kreis wird nicht als Attribut aufgeführt, da es schon durch liegtIn modelliert ist und somit doppelt vorhanden (-0.5).
Attribut: CoronaTote - Datum wird benötigt, damit festgestellt werden kann wann jemand gestorben ist, wenn er nicht im Krankenhaus war. Das führt zwingend zu einer Redundanz bei Krankenhaus aufenthalten. (-0.5)

Relationen

Relation: Test und Einlieferung haben keine Relation, stattdessen jeweils über Person. Eine Einlieferung erfordert nicht zwingend einen Test. (-1)

Relation: Test <-> Gestorben redundant, da die Person schon Tests macht. (-0,5)

Relation: CoronaTod - Aufenthalt dürfen keine Beziehung haben. Daraus würde folgen, das ein Aufenthalt im Krankenhaus zwangsläufig zum Tode führt. Die Kardinalität von <0,1> heißt nicht “optional” sondern für jeden Todestag gibt es keinen oder einen Krankenhaus aufenthalt. (-1)

Relation: Schlüsselbeziehung zwischen Person und Todesfall fehlt (-2)
Relation: Verstorben - Test haben keine direkte Beziehung, die Person verstirbt, nicht der Test (-1)

Weak Entities & Schlüsselrelationen:

Weak Entity: Krankenhaus ist durch seinen Namen eindeutig und deshalb keine Schwache Entität oder liegt in muss eine Schlüsselrealtion sein. (-0.5)

Weak Entity: Testergebnisse sind durch den Fremdschlüssel zu Person zu identifizieren und sind deshalb schwache Entitäten und entsprechend ist die getestet Relation eine Schlüsselrelation. (-1)

Schlüsselrelation: Die Corona Todesfälle sind eine schwache Entität, also muss es eine identifizierende Beziehung zu ihnen geben. (-0.5)

Schlüssel

Primärschlüssel: Krankenhaus-name muss Teil des Primärschlüssels sein, ansonsten könnten nicht mehr als ein Krankenhaus pro Kreis gespeichert werden. (-0.5)
Primärschlüssel: Aufnahme in eingeliefert muss Schlüssel sein, damit Personen mehrfach im selben Krankenhaus sein können, wie z.B. Karl Napf (-0.5)
Fremdschlüssel: Sterbedatum ist kein Fremdschlüssel, ist in keiner anderen Tabelle und nicht für die Identifikation verwendbar. (-0.5)
Primärschlüssel: Verstorben-Datum ist nicht notwendig für den Schüssel, jede Person stirbt ja nur einmal und durchaus mehr als eine pro Tag. (-0.5)
Primärschlüssel: Test-Ergebnis ist nicht notwendig für den Schüssel. (-0.5)
Primärschlüssel: Test-Datum muss Primärschlüssel sein (zusammen mit Person), damit eine Person mehr als einen Test machen kann. (-0.5)
Schlüssel: Test hat keine Primär- oder Fremdschlüssel, d.h. kann nicht einer Person zugeordnet werden. Müsste Datum als Primärschlüssel zusammen mit Person als Fremdschlüssel haben, damit jeder Test eine Person und ein Datum hat. Außerdem müsste Test dann eine Weak Entity sein und getestet eine Schlüsselrelation (-2)
Primärschlüssel: Test-ID unnötig, damit ist eigentlich der Fremdschlüssel Person-ID gemeint der durch die schwache Entität bereits vorhanden ist. (-0.5)

Einzigartige Fehler

Modellierung: Gestorben ist so abgespeichert, das nicht festgestellt werden kann, ob die Person an Corona gestorben ist. (Es kann lediglich festgestellt werden, dass sie positiv getestet wurde) (-1)

Modellierung: In dieser Modellierung, kann jedes Krankenhaus nur einmal einen Patienten aufnehmen, entlassen, testen etc. Alle Attribute bis auf Name sind hier falsch. Sie beschreiben ja nicht das Krankenhaus sondern sind Teil der Beziehung zwischen Patient und dem Krankenhaus. (-5.5)

Modellierung: Testergebnisse werden redundant gespeichert (-0.5).

Modellierung: “Krankenhaus - wird behandelt - Station” ist nicht sinnvoll. Dadurch das es eine 1:1 Beziehung ist, könnte die Aufenthaltszeit genauso gut direkt ein Attribut von Krankenhaus sein. Was natürlich auch keinen Sinn macht, weil dies etwas ist, was die Beziehung zwischen Krankenhaus und Patient beschreibt, aber nicht das Krankenhaus selbst. (-1)

### Transformation in das relationale Modell

Primärschlüssel: CoronaTodesF.Person fehlt (-0.5)
Primärschlüssel: Krankenhaus.Name fehlt (-0.5)
Primärschlüssel: Test.Person fehlt (-0.5)
Primärschlüssel: Test.Datum fehlt (-0.5)
Primärschlüssel: Test.Ergebnis ist nicht notwendig, mehr als ein Test am Tag ist nicht vorgesehen und sie sollten auch in der Regel das selbe Ergebnis haben (-0.5)
Primärschlüssel: eingeliefert/behandelt.Person fehlt (-0.5)
Primärschlüssel: eingeliefert/behandelt.von/ab fehlt (-0.5)

Fremdschlüssel: CoronaTodesF.Person fehlt (-0.5)
Fremdschlüssel: CoronaTodesF.Datum ist nicht notwendig, keine Person stirbt mehrfach (und an verschieden Tagen) (-0.5)
Fremdschlüssel: Krankenhaus.Kreis fehlt (-0.5)
Fremdschlüssel: Test.Person fehlt (-0.5)
Fremdschlüssel: Test.Ergebnis ist kein Fremdschlüssel, Datum und Person sind ausreichend (-0.5)
Fremdschlüssel: eingeliefert/behandelt.Person fehlt (-0.5)
Fremdschlüssel: eingeliefert/behandelt.Krankenhaus fehlt (-0.5)
Fremdschlüssel: Sterbedatum - Ist kein PK von Person, kann deshalb auch nicht als FK verwendet werden. (-0.5)
Fremdschlüssel: Aufenthalt ( Todestag ) -> Person ( SterbeDatum ) ist falsch, sie können nur Fremdschlüssel auf Primärschlüssel einer anderen Tabelle legen. Das SterbeDatum einer Person ist aber kein PK, da Lebende dort NULL haben und ein PK implizit den Constraint NOT NULL hat. (-0.5)
Fremdschlüssel Referenzen fehlen komplett (-2.5)

Spalte: X in Y fehlt (-0.5)
Spalte: gestorben fehlt in eingeliefert (-0.5)

Tabelle: Die Tabelle X fehlt komplett (-2)
Die Tabelle für die Corona Todesfälle fehlt komplett. (-2)
Die Tabelle/Spalte für die Corona Todesfälle außerhalb des Krankenhauses fehlt komplett. (-1.5)
Beispieldaten fehlen (-2)

### Create Table

Primärschlüssel fehlt (-1)
Fremdschlüssel fehlen (-1)
Aufnahme/Entlassung/Sterbetag DATE CHECK (Aufnahme/Entlassung/Sterbetag BETWEEN 01.02.2020 AND SYSDATE) (-0.5)
Aufnahme/Entlassung/Sterbetag DATE CHECK (Aufnahme/Entlassung/Sterbetag BETWEEN 01.02.2020 AND SYSDATE) und intensiv NUMBER CHECK (intensiv >= 0) fehlen (-1)
CHECK (Aufnahme< Entlassung) und CHECK (Aufnahme<= Sterbetag ) fehlen (-1)
Sterbedatums Spalte fehlt (-1)
Date: von & bis überprüft nicht ob > 01.02.2020 (-0.5)
intensiv NUMBER CHECK (intensiv >= 0) fehlt (-0.5)
CHECK (von < bis) fehlt (-0.5)
CHECK (von <= gestorben) fehlt (-0.5)
Krankenhaus hat keine Referenz (-0.5)
Krankenhaus hat keine Spalte und Referenz (-1)
CHECK (von < bis) fehlt (-0.5)
CHECK (von <= gestorben) fehlt (-0.5)
“Tage auf Intensivstation” hat keine Spalte und keinen Check (-1)


### Anfrage 1 (geimpft vor 1.1.2021)
nicht zielführend, 0P  
SQL:
distinct fehlt -1/2
noch nicht gestorben -1/2
Join-Bedingungen Kreis-Person und Person-geimpft fehlen -1/2 -1/2
Join-Bedingung Person-geimpft fehlt  -1/2
gebDat > ... egal
(es gibt keine Tabelle wohntIn, das ist bei Person dabei)
Algebra fehlt
Algebra (upload):
rename person.id fehlt -1/2

### Anfrage 2 (COUNT Fälle nach krankenhaus)
Krankenhausname auch ausgeben -1/2
count(*) auch ausgeben -1
count(*) statt sum(*) -1/2
join-Bed zu Krankenhaus fehlt -1/2
Nur geimpfte personen zählen (Join oder subquery)  -1
Einlieferung dez 2021 -1/2
Impfung muss vor Einlieferung gewesen sein -1/2
group by Krankenhaus -1/2
GROUP BY fehlt -1
Der Between-Test  und die anderen Bedingungen muss ins WHERE, da man im HAVING nur Aggregatfkts verwenden darf. -1/2
Impfung < Einlieferung testen. So könnte theoretisch jemand am 1.12. eingeliefert worden sein, aber am 28.12. eine Impfung erhalten haben. -1/2
(Test-Datum ist im allgemeinen nicht das Einlieferungdatum, sondern vorher, aber in der DB sollen sowieso nur Corona-Fälle gespeichert sein)


### Anfrage 3 (nicht geimpft Krankenhaus)
distinct fehlt -1/2
GebDat auch ausgeben -1/2
Person (für gebDat) dranjoinen -1
Join-Bed fehlt -1/2
geimpft is null geht nicht => NOT ...    noch 1P
geimpft nicht im FROM (ist ja in der subquery), und nicht in Zeile 3 vergleichen, die Person soll ja NICHT geimpft sein -1/2
bei dem zweiten bräuchte man den Krankenhausaufenthalt nicht nochmal mit reinnehmen

### Anfrage 4 Algebra (nicht geimpft Krankenhaus)
Baum als Upload

linkes minus: beide Zweige müssen dieselbe Signatur haben, hier (id, gebDat) vs (id) -1/2
Person (für gebDat) nicht unten verwenden, sondern nach dem minus dranjoinen (rename, join, proj) -1
Person (für gebDat) rename, dranjoinen, ausgeben -1.5

minus: beide Zweige müssen dieselbe Anzahl Spalten und dieselben Spaltennamen haben

### Anfrage 5
Person muss noch leben -1/2

Baum zu Aufgabe 6 (Anfragen 1), Punkte siehe oben
Baum zu Aufgabe 9 (Anfragen 4), Punkte siehe oben
Baum zu Aufgabe 11 (Anfragen 6), Punkte siehe oben

### Updates

Beispieltupel ist in Aufgabe 3 angegeben 1P
Tupel OK 1P
insert OK 1P
update OK 2P

Tupel: ok, wenn man es so schreibt, muss man keinen Wert für tage_intensiv angeben, der ist NULL
nicht eines/alle Testergebnisse von MS updaten (was, wenn noch keines da ist?), sondern insert 0P
(AND statt komma, ist eine normale SQL WHERE-Klausel)
Tupel: Reihenfolge der Spalten muss mit der Tabelle bzw mit dem CREATE TABLE übereinstimmen -1/2
heutigen Test von MS eintragen?  -1
Update: welches Tupel muss geupdated werden -> WHERE? -1
Update: and ... dieser Aufenthalt (falls er mehrmals im Krankenhaus war) -1/2

### Interne Auswertungsstrategie

völlig unklar, wo der Bezug zu der SQL-Anfrage aus Aufgabe 7 ist.

Was ist n? Es sind zwei Tabellen beteiligt. 
noch 1P

richtig (Beschreibung von Baumsuche), aber das war nicht die Frage.
Bezug zu der SQL-Anfrage aus Aufgabe 7?
Auswertung der SQL-Anfrage aus Aufgabe 7?

### Anfragen(7) -- die, die berichtigt werden musste

nein, das ist kein Problem
SQL ist case-insensitiv (und so eine dämliche Aufgabe würden wir nicht stellen ;)
die Syntax (HAVING ) OR (HAVING) ist nicht ganz richtig, muss Having (cond1) OR (cond2) sein -1P
Beschreibung warum es falsch ist, fehlt -2P

Die Beschreibung hätte etwas expliziter sein sollen, was dann passiert (1P)
Das max(...) muss dann aber raus (ist ja noch vor dem GROUP BY) -1

das count(*) ist ok

nein, das GROUP BY sorgt dafür, dass für jede person eine Gruppe (=Ergebniszeile) erzeugt wird. 
doch, max(datum) ist dann da maximale in dieser Gruppe
nein, man muss ihn nicht selecten. Oft will man sowas ja nur in der HAVING-Bedingung testen, ohne es auszugeben.
nein, es zählt die  *Zeilen* in der Gruppe.
nein, syntaktisch ist sie richtig (ergibt ein falsches Ergebnis, aber keine Fehlermeldung)


### Aufgabe 16 (Eine etwas kompliziertere SQL-Anfrage)

das kann so nicht reichen, da das count sich nur auf die erkrankten
bezieht, es müssen aber auf jeden Fall erkrankte gezählt werden, die
mindestens drei Impfungen bekommen haben.

syntaktisch fehlt schon ein globales from für das i, und mit dem Ansatz kann es auch nicht gehen.
ja, aber wie weiter?