*** ER_Diagramm Nur sehr fragmentarische Abdeckung der Aufgabenstellung Kardinalitäten an den Beziehungen auf der falschen Seite -1 Fremdschlüssel gibt es im ER-Modell keine, die sind ja in den Beziehungen! Marke (installationen, geschulte Mitarbeiter) fehlt komplett -4P Verbindung Installation-Marke fehlt -1.5 Verbindung Mitarbeiter-Marke fehlt -1.5 Installation.marke nicht als Attribut, sondern als Beziehung -1 Kardinalität Marke-Mitarbeiter <0,*> (am Anfang nichts) -1/2 Kardinalität Marke-Mitarbeiter fehlt -1/2 Kardinalität Mitarbeiter-Marke <0,*> -1/2 Kardinalität Installation-Marke <1,1> -1/2 Kardinalität Marke-Installation <0,*> (am Anfang nichts) -1/2 Marke.mname nicht als Attr -> Bez zu Mitarbeiter -1 Marke.id muss key sein -1/2 Marke.name Attr fehlt und müsste key sein -1 Marke als Installation.marke und Mitarbeiter..marke kann man so machen. Entitätstyp und Beziehungen wäre besser gewesen. (der Teil, dass zu jeder Marke eine Kontakt-Telefonnummer gespeichert sein sollte, fehlte im Text, hatte ich aber beim Durchlesen gesagt) Auftrag.nr muss key sein -1/2 Kardinalität Auftrag-Standort <1,1> -1/2 Kardinalität Standort-Auftrag <0,*> -1/2 Kardinalität Auftrag-Mitarbeiter <0,*> -1/2 Kardinalität Mitarbeiter-Auftrag <0,*> -1/2 Auftrag Attribute _nr_, datum, zeit und key fehlen -2 Auftrag.datum fehlt -1/2 Kardinalität Auftrag-Arbeit <0,*> (am Anfang nichts) -1/2 Kardinalität Arbeit-Auftrag <1,1> -1/2 Kardinalität Installation-Arbeit <0,*> -1/2 Auftrag.Standort nicht als Attr -> Bez zu Standort -1 Auftrag->Kunde nicht als Beziehung, ist via ->Standort->Kunde -1/2 Auftrag.knr nicht als Attr, ist via ->Standort->Kunde -1/2 Kardinalität Arbeit-Installation fehlt -1/2 Kardinalität Arbeit-Installation <1,1> -1/2 Kardinalität Arbeit-Mitarbeiter <0,1> (ggf nicht sofort zugeordnet) -1/2 Kardinalität Arbeit-Mitarbeiter <0,1> (es sollte nur der verantwortliche Mitarbeiter dazu gespeichert sein) -1/2 (mit <0,*> wenn man alle an der Arbeit Mitwirkenden speichert, ist es dann korrekt und notwendig, std und personalkosten an anzulegen; entsprechend sind es dann auch in Aufgabe 2 zwei Tabellen - ok) Kardinalität Mitarbeiter-Arbeit <0,*> (Azubis nicht verantwortlich zugeordnet) -1/2 Beziehung Arbeit->Mitarbeiter fehlt -1.5 Arbeit.mitarbeiter nicht als Attr -> Bez zu Mitarbeiter -1 Arbeit.installation nicht als Attr, ist in der -<>-Beziehung zu Installation -1/2 Arbeit.installation nicht als Attr, ist Beziehung -1 Arbeit.auftragsnr nicht als Attr, ist Beziehung -1 Arbeit.auftragsnr nicht nochmal als Attr, ist in der -<>-Beziehung zu Auftrag -1/2 dann müsste [[Arbeit]] <> sein -1/2 Arbeit Attribute datum, beschreibung std, matK, persK von Arbeit fehlen -2.5 Arbeit.datum fehlt -1/2 Arbeit.std fehlt -1/2 Arbeit.beschreibung fehlt -1/2 Arbeit.personalkosten fehlt -1/2 Arbeit.personalkosten kein mehrwertiges Attribut (ist "abgeleitetes Attr" gemeint?) Arbeit.materialkosten fehlt -1/2 (Arbeit.anr als künstlicher key geht) (Arbeit ohne key geht) Arbeit weak -> müsste eine <>-Beziehung (zu Auftrag) und im Allgemeinen einen local key haben -1 Arbeit mit <>Beziehung/en -> müsste [[weak]] sein -1/2 Arbeit weak und <>-Beziehung -> müsste einen local key haben -1/2 Wenn Arbeit.nr nur innerhalb des Auftrags eindeutig, müsste es weak zu Auftrag sein -1/2 Wenn Arbeit dann in der Tabelle auch _AuftragNr_ als Teil des PK hat, müsste es weak zu Auftrag sein -1/2 Wenn Arbeit.id, sollte es auch key sein -1/2 Arbeit.datum als key reicht nicht aus -1/2 Wenn Arbeit als schwacher Entitätstyp, reichen (Auftrag+Datum) als key nicht aus -1/2 Wenn Arbeit als schwacher Entitätstyp, reichen (Auftrag,Inst,Mitarb,datum) als key nicht aus - ein Mitarbeiter macht ja ggf mehrere Arbeiten an einer Installation (Wartung, Ausgleichgefäß tauschen, Emissionsmessung) -1/2 Wenn Arbeit als schwacher Entitätstyp, reichen (Auftrag+Beschreibung) als key nicht aus - ein Mitarbeiter macht ja ggf dieselbe Arbeiten (Wartung) an mehreren Installationen -1/2 Wenn Arbeit als schwacher Entitätstyp, reichen (Auftrag,Inst,Mitarb) als key nicht aus -1/2 (Arbeit als dreistellige Beziehung kann man machen) Nicht weak zu Mitarbeiter, der kann bei der Planung NULL sein FF Datum nicht Teil des keys, kann bei der Planung NULL sein -1/2 (Arbeit als schwacher Entitätstyp mit Auftrag+Installation+Beschreibung/Tätigkeit kann man machen, ist aber etwas riskant, wenn Dinge zweimal gemacht werden (Emissionsmessung, nochwas tauschen, nochmal Emissionsmessung), oder zwei gleiche Teile verbaut werden) ** Antwort bei Frage 2 Das ist kein ER-Diagramm, sondern sehr vereinzelte Stücke davon. Bei so einfachen Teilen kann man das machen - ein ganzes Diagramm würde sehr unübersichtlich. *** Relationales Modell ****************************************************** Antwort bei Aufgabe 4 Bewertung siehe Aufgabe 3 Nur sehr fragmentarische Abdeckung der Aufgabenstellung Beispieltupel fehlen -1P Tabelle Marke fehlt -1 Marke PK fehlt -1/2 Tabelle Schulungen fehlt -1.5 Schulung PK fehlt -1/2 Schulung FK Ziele fehlen -1/2 Arbeit.datum, std, material, personalkosten fehlt (FF, Abzug bei Aufg 5 bei den Beispieltupeln) PK und FK under/overlined, aber die Referenzen, wohin die FKs gehen, fehlen (zu 5 angegebenen FKs -> -5/4P) Auftrag.Standort auf PK Standort.ID -1/2 Auftrag: Standort nicht Teil des PK -1/2 Arbeit: PK FF Arbeit: Personalkosten fehlt -1/2 Wenn Arbeit als schwacher Entitätstyp, dann kann nicht Auftrag+Datum alleine Key sein) FF Arbeit: (Auftrag,Inst,Mitarb,datum) reichen als key nicht aus - ein Mitarbeiter macht ja ggf mehrere Arbeiten an einer Installation (Wartung, Ausgleichgefäß tauschen, Emissionsmessung) -1/2 (Arbeit: (Auftrag,Arbeit) als key etwas kritisch, wenn an mehreren Installationen dieslebe Arbeit ("Wartung") durchgeführt wird) Mitarbeiter, Datum nicht key, da bei der Planung evtl. noch NULL -1/2 Da fehlt die Spalte Arbeit.Mitarbeiter, oder (Kard <1,*> bei Ihnen) die separate Tabelle, wer was bearbeitet (PK, FK) -1 (Tabelle "arbeitet" separat ok) (Tabelle "eingeteilt" wird nicht benötigt, ergibt sich aus Arbeiten) ******** Beispieltupel ****** Auftrag.Standort fehlt -1/2 Standort.ID anstatt "Alte Strasse 32" (muss ja FK sein) -1/2 Stunden und Kosten kann man vorher noch nicht eintragen. -1/2 (das soll ja in Aufgabe 15 gemacht werden) Was wurde da hochgeladen? Ilias zeigt nichts brauchbares an (Programmcode-Text-Aufgabe) *************** CREATE TABLE *************** Spaltentypen fehlen bis auf datum -1 Datum fehlt -1/2 Arbeitsstunden und Personalkosten fehlen -1 AuftragNr REF fehlt -1/2 Spalte Installation fehlt -1 Beschreibung NOT NULL -1/2 Mitarbeiter (FF?) und Datum sollte zur Arbeitsplanung NULL sein können -1/2 (Datum sollte für die Planung auch in der Zukunft liegen dürfen, erzwingt sonst NULL für die Planung) Stunden/Pers-/Materialkosten dürfen auch null sein (insbesondere weil ja zuerst die Arbeit eingetragen wird, und evtl erst nach Ausführung klar ist, wieviel Material/Kosten notwendig sind) -1/2 Stunden, Materialkosten, Personalkosten CHECK >= 0 -1P (Datum, Arbeitsstunden und Personalkosten nicht dabei weil separate Tabelle ok) Primary key FF, Syntax ok Mitarbeiter in separater Tabelle ok *************** Queries *************** Algebra als Upload in Aufgabe 14 Baum zu Anfragen (4) (Wartung) Bäume zu Anfragen (1), Anfragen (4) (Wartung), Anfragen (6) (Div) nicht zielführend 0P jeweils -1/2P wenn Tabellenname/Spaltenname mit dem eigenen Schema in Aufgabe 3 nicht übereinstimmen Anfragen (1) DISTINCT fehlt -1/2 Mitarbeiter muss drangejoint werden, da a.mitarbeiter nur den Code ausgibt -1 Inneres SELECT: und dieselbe Installation -1/2 a_neuinstallation.datum < a_anderes.datum (oder auftr.nr verschieden) -1/2 Vereinfachung: 1 join weniger notwendig wegen Mitarbeitername als FK anstatt ID -1/2 Das würde auch Mitarbeiter ausgeben, die gleichzeitig zur Neuinstallation durch einen anderen eine Arbeit ausführen. -1/2 (wenn man ganz exakt ist, muss man Stunden is NOT NULL und Datum <= SYSDATE prüfen) Algebra: Upload in Aufgabe 14 vor dem unteren join alle störenden Attrs wegprojizieren, sonst wird über die auch =-gejoint -1/2 vor dem join mit Mitarbeiter renamen -> id -1/2 Aliasing gibt es in der Algebra nicht -> Attribute einzeln umbenennen datum->d1 usw Vereinfachung -1 oberes Join: links ist a.mitarbeiter_Id und b.mitarbeiter_id - welche wird mit mitarbeiter.id von rechts gejoint? -> vorher Projektion -1/2 Join mit Bedingung gibt es in der relationalen Algebra nicht -> renaming, natural join -1/2 pi: datum von a1 oder a2 ausgeben? -1/2 Anfragen (2) SUM (Kundenname? ... war nicht explizit gefragt ... im Text vergessen) kname bzw knr auch ausgeben -1/2 and year=2025 -1/2 SUM (personalkosten) -1/2 Auftrag hat keine Kundennummer -> Standort reinjoinen -1 GROUP BY fehlt -1 GROUP BY knr,kname - zwei Kunden könnten denselben Namen haben -1/2 (wenn man ganz exakt ist, muss man das outer join verwenden für Kunden die in dem Jahr Kosten=0 hatten) Anfragen (3) NEG Batterie hier war der Kundenname gefragt -1/2 (GROUP BY mit s.id anstatt Adresse. Mehrere Standorte könnten dieselbe Adresse haben (Wohnungs-Gasthermen in Mehrfamilienhäusern)) ORDER by knr oder Telnr anstatt name - zwei Kunden könnten denselben Namen haben -1/2 ORDER BY fehlt -1 Nicht GROUP BY, sondern ORDER BY -1/2 Anfragen (4) NEG Batterie Algebra kein Batteriespeicher -1/2 Join mit Bedingung gibt es in der relationalen Algebra nicht -> renaming, natural join -1/2 Unter dem Minus passendes Renaming auf ID -1/2 Standort.ID <-> Installation.Standort passend renamen -1/2 Join zwischen Kunde und Standort würde die beiden Adressen equijoinen -1/2 Ausgabe Adresse: Kunde und Standort haben Adresse -> welche? -1/2 NOT EXISTS gibt es in der relationalen Algebra nicht -> Minus verwenden -2 Unter dem Minus müssen beide Seiten dieselbe Signatur haben -> Installationen minus, dann die Restdaten wieder dranjoinen, also der ganze Baum ziemlich anders -2 Anfragen (5) DIV Mitarb mitarbeiter.bis is NULL -1/2 Standort nach ganz innen -1 Mitarbeiter.bis IS NULL muss in die mittlere Ebene -1 Wenn man die COUNT-Lösung nimmt: GROUP by knr,kname - zwei Kunden könnten denselben Namen haben -1/2 Anfrage (6) DIV Mitarb Dass es eine Division ist, ist richtig, mitarbeiter.bis is NULL -1/2 (wenn man ganz exakt ist, müsste man OR m.bis>SYSDATE falls gekündigt oder befristet machen) (wenn man ganz exakt ist, muss man std NOT NULL oder Datum < SYSDATE auch prüfen) Division andersrum links <-> rechts -1/2 Join mit Bedingung gibt es in der relationalen Algebra nicht -> renaming, natural join -1/2 Join-Attribute passend umbenennen -1/2 Auftrag.standortID zu Standort.id passend renamen -1/2 Mitarbeiter.ID <-> Arbeit.mitarbeiter vor Division passend renamen -1/2 Join zwischen Auftrag und Arbeit ohne Projektion würde auch datum equijoinen -1/2 (check: wenn beide Attrs "datum" heissen) Renaming notwendig, damit die beiden Seiten der DIV zusammenpassen -1/2 Auf der linken Seite muss vorher auf (kunde,mitarbeiter) projiziert werden, da sonst nur diejenigen Kunden ausgegeben werden, wo es eine Installation gibt, an der schon alle Mitarbeiter gearbeitet haben -1/2 Division: knr verwenden, zwei Kunden könnten denselben Namen haben; name muss nachher wieder drangejoint werden -1 Anfragen (7) erste Wärmepumpe DISTINCT - falls jemand an dem Tag zwei Wärmepumpen bekommen hat -1/2 inneres Select: hier auch nur Wärmepumpen-Neuinstallationen betrachten -2 äußeres Select: AND Beschreibung="Neuinstallation" -1/2 inneres Select: AND Beschreibung="Neuinstallation" -1/2 inneres Select: AND Beschreibung="Neuinstallation" -1/2 inneres Select: AND Tätigkeit="Neuinstallation" -1/2 i.Installationsdatum gibts nicht (könnte man aber an sich machen, wäre an sich nicht schlecht)-> "Neuinstallation" aus "Arbeit" -2 Arbeit.datum anstatt Auftrag.von nehmen (Installation kann ja am 2. Tag des Auftrages stattfinden) -1/2 ### UPDATE: Das Auftrag-Tupel ist schon da (siehe Aufgabe 5) -1/2 Das Auftrag-Tupel muss schon da sein (siehe Aufgabe 5) -1/2 Die neue Installation sollte auch INSERTed werden -1 Zeile 1: das "Arbeit"-Tupel für den Abbau ist schon da (siehe Aufgabe 5), muss also ein UPDATE sein -1 UPDATE das Tupel mit der Arbeit "Abbau": Stunden eintragen -2 INSERT Tupel mit Material+Personalkosten für die Neuinstallation+Anschluss fehlt -1 Personalkosten für die (ggf. an dem Tag) neu eingetragenen Arbeiten -3 Entwurf 1: ER-M? Nur PK angegeben PK soll minimal sein, also wenn man Marke+Modell reinnimmt, braucht man Art nicht -1/2 1: und was wird als lokaler Schlüssel dazugenommen? Standortwechsel eines Gerätes wäre eine Neuinstallation (eine Heizung/Solaranlage schraubt man nicht einfach irgendwo neu rein) Problem: wenn an einem Standort zwei gleiche Geräte (z.B. 2x Batteriespeicher BYD LVS 24) stehen -1 Semantik: Besitzerwechsel, dann muss man alles überall nachziehen -1P Selbes Problem aber bei Auftrag/Standort - Arbeit/installation (wird nicht überprüft, ob sie an diesem Standort ist - was der zusammengesetzte Schlüssel in der vorigen Aufgabe im ersten Punkt lösen würde)) 1: Die einfachen ID-FKs sind ja da. Das kann also nicht passieren. Ob die MA noch eingestellt sind, kann man mit FK nicht prüfen (Status ist ja nicht Teil des PK) 2: die Frage ist, was man machen kann, wenn das wie in (1) beschrieben nicht ausreicht. ################