Gesucht sind Photos vom Mars mit maximalem Zoom. Jedoch mit dem maximalen Zoom in der Menge der Photos vom Mars, nicht der Menge aller Photos (wie hier). Ich hätte die Frage zu mindest so verstanden. Daher hätte ich statt ner Subquery ein GROUP BY Zoom HAVING Zoom=MAX(Zoom) benutzt.
Wenn du GOUP BY nimmst, wird dir nur ein Photo mit dem maximalen Zoom angezeigt oder? ich denke , dass AND Zoom = MAX(Zoom) ausreichend ist statt eine weiter SELECT Anfrage zu verwenden.
Ich glaube Alfons hat recht, jedoch ohne Group by geht es auch ( weiß nicht ob sein Ansatz stimmt). In der verschachtelten Abfrage nutzt man ein join zwischen Photos und Plantes und selektiert die Einträge mit WHERE Name= Mars aus. Somit Sucht man das max nur noch von Mars Einträgen.
soll man hier nicht Rabatt als primärschlüssel mit dem schwarze Punkt markieren?
Ja glaube ich auch wegen dem Wort "charakterisiert"
Bestehensgrenze war 20 Punkte
View 2 more comments
Wie schwer ist Datenbanksysteme? und lohnt es sich Vorlesungen zu besuchen? Danke im Voraus
Datenbanksysteme ist nicht furchtbar schwierig. Die Vorlesung muss man nicht zwingend besuchen. Die Folien der Übung sind ganz interessante (ob sich dort Anwesenheit lohnt weiß ich nicht). Bei der Klausur muss man beachten, dass man nur eine Stunde Zeit hat. Man sollte sich also nicht unnötig lange mit einer Aufgabe beschäftigen. Eine Strategie ist es z.B. den SQL-Teil auszulassen. Dieser ist recht zeitintensiv und wird wohl sehr streng bewertet. Ebenfalls ist es nützlich, wenn man bestimmte Aufgabenstellungen, die häufig auftauchen nicht nur bearbeiten kann, sondern sie auch möglichst zügig bearbeiten kann (oft üben, gutes Schema/Konzept überlegen) Ebenfalls kommt es (gefühlt) immer mal wieder dazu, dass Teile der Klausuraufgaben unabsichtlich schwer werden. Hier wird dann aber glaube ich oft der Notenschlüssel angepasst oder weniger streng korrigiert. Es kann sich also lohnen Aufgaben eben so gut es geht zu bearbeiten.
Hier ist mein Versuch der b)
View 1 more comment
SELECT basePrice FROM (SELECT basePrice FROM product GROUP BY basePrice ORDER BY basePrice DESC LIMIT 3) ORDER BY basePrice ASC LIMIT 1 so ist es richtig
@Belg 1453 👍🏻 wobei man statt dem "GROUP BY" auch "DISTINCT" nutzen könnte, um die doppelten Einträge zu eliminieren)
Korrektur: Relation befindet sich nicht in BCNF, da bei D->E bspw. gilt, dass D kein Superschlüssel ist.
Was ist Superschlüssel? Kommt es Vorlesung dran? Übrigens finde ich wegen gab es transitiven Abhängigkeit zwischen primattribüte
Superschlüssel ist ein Schlüssel der alle anderen Attribute bestimmt
Hier konfligieren w4(y) und w3(y) miteinander, oder? Auch wenn sie aus verschiedenen Transaktionen stammen, operieren sie dennoch auf dem selben Objekt.
in der tat alles außer 2 read operationen konfligiert doch wenn es aus verschiedenen Transaktionen kommt
Darf eine History eigentlich zweimal w1[A] haben? So wie ich das verstanden gibt es für jede Transaktion nur ein write oder read für das selbe Datenobjekt.
Sie Transaktionen können beliebig oft auf das selbe Datenobjetzt schreibend oder lesend zugreifen. Sonst gäbe es sowas wie "Non-repestable read" ja gar nicht.
ich hätte gesagt: Schlüsselkandidat = Attribut, das als Schlüssel in Frage kommt. nach der Def. von Schlüssel war ja nicht gefragt
Das ist auch falsch. Es muss eine mehrfach Spezialisierung sein. Das hier ist eine Partionierung.
Das sehe ich auch so!
außerdem sollte man glaub ich auch die Attribute übernehmen, denn hier im EER ist die Schlüssel-Kennzeichnung anders: mit dem Punkt, statt Unterstreichen
Ich hätte eher zwei völlig separate Beziehungen gemacht, eine für Verkäufer und eine für Käufer. Und, ich bin mir nicht 100% sicher, aber ich glaube, dass die IST Beziehung hier Schlüssel ist, also unterstrichen
Stimme dir zu 👍🏻
Das war mein Vorschlag zur (i)
View 3 more comments
Sollten nicht die Kardinalitäten [0,*] sein, da ein bestimmter Akteur nicht unbedingt an der Beziehung teilnehmen muss. so war es ja vorher. Dass zwei Akteure beteiligt sind wird schon durch die zwei Kanten von Akteur zu verkauft dargestellt.
Nein [0,*] reicht nicht aus, selbst wenn es zwei Kanten sind. Eine Kante führt nicht automatisch zu einer Teilnahme an der Relation. Theoretisch könnte man auf die Kante auch [0,0] schreiben und es würde dem entsprechen, einfach keine Kante zu malen. Und da man bei [0,*] auch den 0-Fall wählen darf, könnte hier der Fall eintreten, dass nur ein Akteur, oder sogar keiner am Verkauf teilnimmt.
Hier fehlen noch einige Fremdschlüssel-Pfeile, oder nicht? Ich würde folgende hinzufügen: - bietetan.Anschrift -> Autohaus.Anschrift - bietetan.Bezeichnung -> Autotyp.Bezeichnung - Auto.Bezeichnung -> Autotyp.Bezeichnung - verkauft.FahrgestellNr -> Auto.FahrgestellNr - verkauft.PersoNr_Käufer -> Käufer.PersoNr - verkauft.PersoNr_Verkäufer -> Verkäufer.PersoNr
Warum wurde r3(z) doch nicht mehr markiert ? auch wenn r3(z) und w3(z) zu den gleichen Transaktionen gehören, konfligieren sie ja trotzdem.
ja, da stimme ich dir zu
Weiß jemand was das ist?
View 2 more comments
lt. der Vorlesungsaufzeichung wird das dann über eine M:N beziehung mit "besitzt" abgebildet wobei man das auch anders nennen kann
Tobias, das wär ja bloß eine andere darstellungsart im ER Modell. Ins relationalen Modell überführen macht man dann so: die Telefonnummer aus der Relation für Dozent herausziehen und in eine neue Relation packen, wo zusätzlich die Schlüsselattribute von Dozent reinkommen und beides zusammen Schlüssel wird. Man hat dann Dozent(_Name_) und Telefon(_Name_ , _Telefonnummer_)
Es sind Rücksetzbarkeitklassen gefragt, also RC,ACA, oder ST.
View 7 more comments
Der Abort von der gelesenen Transaktion kommt vor dem Commit von der lesenden Transaktion, aber was bringt das? Die lesende Transaktion merkt davon ja nichts. Wirklich ausschließen kann man einen Dirty Read nur, wenn die gelesene Transaktion committet hat bevor die andere liest, und das ist eben ACA.
also Dirty read : RC lost update: strictness
Soll COUNT(Spieler.id) oder sonst wenn keine Spieler in einem Team wird trotzdem 1 ausgeben
Create view Heimsieg AS select M1.name,M2.name, (tore_heim -tore_gast ) AS Differenz From Spiel Join ( Select * From Mannschaft As M1,Manschaft As M2 ) ON spiel.heim=M1.id AND spiel.gast = M2.id WHERE tore_heim > tore_gast Order By Differenz ASC
Müsste [1,1] sein, da 1 in Standardkardinalität [0,1] bedeutet.
und hier Transaktionen die aborten werden nicht mehr betrachtet? also z.B bei H1 : nach a2 haben wir kein Konfliktpaare mehr mit T2? wir betrachten dann nur T1 und T3?
doch konfliktpaare sind sie trotzdem. Aber es wäre dann kein overwrite oder reads-from mehr, wenn die Transaktion abortet bevor die andere liest/überschreibt
also das konfliktpaar wird dann trotzdem notiert, aber da dann kein reads-from vorliegt, braucht man auch kein RC oder ACA mehr prüfen
Sollte auch stimmen, oder? SELECT e.id, e.description, sum(l.amount), e.year FROM events e INNER JOIN losses l On e.id = l.event_id WHERE l.description NOT LIKE "%laptop%" AND e.description NOT LIKE "%laptop%" GROUP BY e.description
ich würde nicht nach e.description gruppieren, weil das sicher kein Schlüssel sein wird. Die id macht da wohl mehr Sinn. Aber sonst sollte das auch passen, ja
Hier ist das "losses." nicht notwendig, aber auch nicht falsch. Denn "event_id" ist eindeutig der Relation "losses" zuordenbar
Gab es hier nicht eine Methode zur "grafischen Lösung"?
View 1 more comment
hier ist die Lösung: nein nein ja ja?
ja :)
Müsste man hier nicht mit substrings arbeiten? In der einen Relation sind es F1,F2,.., und in der anderen E1,E2,...
Stimmt! Ich glaube fast, dass das ein Fehler in der Tabelle ist, das würde sonst echt unnötig viel Zeit in Anspruch nehmen :/
in der Aufgabenstellung steht ja, dass es exemplarische Daten sind. Also kann es ja schon sein, dass es die evetns.unit_id "F1" auch als unit.id gibt. Ist vermutlich ein Tippfehler in der Aufgabe, macht aber trotzdem noch Sinn. --> ich glaube diese Lösung stimmt so
Hier sollte [1,N] stehen. Denn "N" in Std.kard. steht für "[0,N]" in Teiln.kard.
Hier sollte jeweils [1,1] stehen. Denn die "1" in Standardkardinalität steht für "[0,1]" in Teilnehmerkardinalität.
Muss hier nicht [1,*] hin, da N ja für [0,*] steht?
View 3 more comments
Kap 4&5, Folie 23: "Recap: Ist keine untere Grenze gegeben, gilt: [0,1] - Optionale Beziehung [bei Standardkardinalität]"
Auch in Standardkardinalität kann man Intervall-Schreibweise nutzen, wenn man Grenzen angeben will
Hier versteckt sich glaube ich eine Falle. Wenn eine Transaktion einen Wert selbst zuletzt geschrieben hat, dann ist es keine Reads-From-Beziehung. In diesem Fall hat man also nur w9y und r8y, sodass nur c8 vor c9 für RC gelten muss.
Aber r7y auch read from w9y
Danke für den Hinweis. Das hatte ich übersehen.
Weiß jemand wie die Graphen aussehen sollen? Laut der Diskussion hier https://www.studydrive.net/kurse/karlsruher-institut-fuer-technologie/datenbanksysteme/klausuren/loesungsskizze-ss2018/vorschau/691488 sollen nur committed Transaktionen im Graph auftauchen, das verwirrt mich hier ein bisschen
View 6 more comments
T2 darfst du im Graph für H4 nicht drin haben, denn T2 comitted ja nicht, sondern abortet
und auch in H4: wegen w3[x]w1[x] gleich am Anfang hast du übrigens eine Kante von 3 nach 1 und somit einen Zyklus.
Kann auch einfacher gelöst werden mit: SELECT id, location, COUNT(*) FROM units JOIN events on units.id=unit_id WHERE year=2018 GROUP BY id, location HAVING COUNT(*) > 2;
Alternativ geht's auch mit dem WHERE-Ausdruck im HAVING-Ausdruck mit drin
glaube muss Units.id anstatt id und Group by einfach mit Units.id oder Location ?
Weiß jemand, wie man allgemein ternäre oder quaternäre Beziehungen ins Relationenschemata übersetzt, bzw. in Standardkardinalitäten umwandelt?
View 2 more comments
also habe es so wie anOnymAus, aber dann kann man doch eigentlich Getriebe, Motor und Rahmen komplett in die Relation verschraubt verschmelzen oder nicht ? Sie müssen ja immer ein Teil der Beziehung verschraubt sein. Könnte mir aber vorstellen, dass das dann zufiele Redundanzen wären.
ich glaube brauch nicht verschmelzen sonst die allgemeine Informationen verloren gegangen ist
Muss man hier zweimal überprüfen? in d) schon geschrieben jedes wortpaar nur einmal in der Sicht enthalten
In meinen Augen entsteht überhaupt kein Deadlock in der Aufgabe, es müsste r6[x] und w6[z] sein damit dann die angegeben Lösung stimmt. Oder liege ich falsch?
das funktioniert schon so wie es hier steht
i) R Durchschnitt S ii) Q vereinigt S iii) richtig
i) Durchschnitt R und S geht schon mal überhaupt nicht, weil R und S unterschiedliche Attribute haben. ii) Durschnitt und Vereinigung sind nicht äquivalent. iii) Könnte richtig sein, aber da bin ich mir nicht sicher. Hier mal meine Lösung für i) und ii)
Nein es gibt kein F in Teilrelation R1 Ja keine partiellabhängigkeit zwischen Schlüsselkandidaten und nicht-primattribut Nein kein G Nein z.b. Keine Beziehung BC—>F
View 1 more comment
glaube BC ist nicht Schlüssel mehr oder da F steht nicht in R1
also wenn BC nicht Teil des Schlüssels in R1 ist, wie komme ich auf BC?
Muss das nicht anders herum sein? Partitionierung oben, damit es auch Wohnhäuser geben kann, die weder Massiv- noch Fachwerkhaus sind und Generalisierung unten, damit es keine Wohnhäuser geben kann, die weder Einfamilien- noch Mehrfamilienhaus sind
View 3 more comments
Warum wäre denn nicht totale Partitionierung gegangen? Ich meine es kann ja nur das eine ODER das andere sein und nicht keines von beiden
Unten ist total Partitionierung richtig (hatte versehentlich Partitionierung geschrieben)
Weiß jemand nun wie man ternäre Beziehungen verschmelzen kann? Gefühlt kommt das ja in jedem Jahr dran aber in den Unterlagen findet man dazu nichts Danke!
Wo steht das? Habe dazu nichts gefunden
Ich glaube hier sind nicht-binäre Beziehungen gemeint.
Hat jemand die Klausur vom SS19? :)
View 1 more comment
Wenn du sie hast könntest du sie hier bitte hochladen? wäre echt lieb :)
habe ich schon :)
Outlier und Clustering sind dieses Mal klausurirrelevant oder?
nein
Weiß einer warum Informationswirte die Datenbank veranstalltung vom AIFB nicht besuchen können ? Ich würde vermuten das es etwas entspannter ist als dieser Spaß hier
Bestehensgrenze lag im SS 19 bei 18 Punkten :-)
War die so viel unterschiedlich im vgl zu den Altklausuren oder woran lag es?
im SS 17 lag die Grenze bei 18,5 von 60 Punkten. Also war die letzte Grenze völlig normal!
Kann mir jemand bei den SQL Online Übungen helfen ? komme bei Aufgabe 9 und 10 leider nicht weiter ...
View 1 more comment
Ich schaffe es auch nicht Aufgabe 9 und 10 zu lösen. Ich habe ehrlich gesagt schon darüber nachgedacht, ob die Prüfung etwas falsches prüft...
Hab meinen Fehler entdeckt. Ich bin beim Vergleich von zwei Date-Objekten davon ausgegangen, dass z.B. return_date > Date '2005-01-01' erst ab '2005-01-02' wahr wird, aber es kann halt auch schon bei '2005-01-01' wahr werden, wenn das Objekt z.B. eigentlich den Wert '2005-01-01 12:00:00' hat. Vielleicht hat ja jemand den gleichen Fehler gemacht :)
Ist das nicht schon dritte Normalform? Die zweite Normalform wäre hier doch in der Form: R1(_A_,D,E,I,J) R2(_B_,F,G,H) R3(_A_,_B_,C)
View 7 more comments
laut Übung: R1: (_A_,_B_,C) R2: (_A_, D, E, I, J) R3: (_B_, F, G, H)
Natürlich kann man in der Einsicht darum streiten, weil die es nicht hinbekommen, sich vernünftig zu formulieren. Sie wollen zwar, dass man es in der 2NF, aber nicht in der 3NF, lößt, aber da die 3NF auch in der 2NF ist, ist die 3NF somit auch in der nächsthöheren Normalform zur 1NF. Um genau zu sein: "die in der nächst höheren Normalform als R liegt" Die Menge der 3NF einer Relation R ist Teilmenge der Menge der 2NF von R. -> Eine 3NF ist eine valide Lösung im Sinne der Aufgabenstellung. Wie schon gesagt, keine Lösung, die sie haben wollen, aber eine Lösung, die sie akzeptieren müssen. Generell muss der Böhm mal hinbekommen, sich besser zu formulieren und auch mal daran denken lösbare Aufgaben zu stellen (ER-Diagramm kapazitätserhaltend in das relationale Modell überführen).
Hier wurde vergessen, dass für den Serialisierbarkeitsgraphen nur die commited projections betrachtet werden dürfen. Anbei die korrekte Lösung.
View 1 more comment
Nein, das war ein Fehler auf den Folien. Siehe Folie 13 von Übung 5.
genau, es dürfen nur vollständig committete und nicht abortete Transaktionen beachtet werden!
Da es keine konflikte der Namen der Attribute gibt wäre auch ein NATURAL JOIN möglich
Da diese 3 Relationen immer zusammen an einer 1:1 beziehung teilnehmen würde ich sie einfach zusammenfassen in eine Relation.
Korrektur: Bei Monteur dürfte kein Kreuz sein, da er immer mit einer Werkzeug Entität in Beziehung stehen muss
View 7 more comments
Ah sorry, da war ein Missverständnis schon in meiner 2. Antwort. So wie ich Teilnehmerkardinalitäten verstehe muss im geg. Modell Monteur garnicht an der Beziehung teilnehmen ([0,*]). Werkzeug dagegen muss teilnehmen. D.h. wenn es ein Werkzeug gibt, muss es nach deiner Argumentation auch ein Monteur geben.
Anderst rum. das [0,*} steht bei Werkzeug, also nimmt ein Werkzeug nur optional an der Beziehung teil (Nicht alle Werkzeuge müssen benutzt werden). Dahingegen Monteur nimmt zwingend mit ( [1,*] ).
Hätte da eher alle nein gesagt außer das zweite: Es gilt C->B, B->A also auch C->A. Das heißt C bestimmt B und A. Das Tupel (0,0,0) existiert bereits also für C=0 gilt A = 0 und B=0 und für B = 0 gilt C=0. (1,0,1) kommt geht nicht, da für B = 0, C=0 gelten muss. (0,1,1) C = 1 und B = 1 wurde nicht verwendet also in Ordnung- (0,2,0) C = 0 also müssen alle anderen auch 0 sein. Geht nicht. (0,1,0) C = 0 gleiches Spiel wie (0,2,0)
Macht Sinn, danke.
Warum setzt du am Anfang voraus dass wenn B=0 dann auch C=0 gelten muss? Meinst du nicht B=0 dann A=0? Genau so bei (1,0,1) da müsste es doch deshalb nicht gehen weil für B=0 A=0 gelten muss
Die Daten sind möglicherweise fehlerhaft. D.h. die Namen in "halt" könnten mehrmals vorkommen. Der Verbund sollte erst nachdem Filtern von "prop" gemacht werden.
Wobei... min(p_value) != max(p_value) löst das dieses Problem schon.
Load more