Datenbanksysteme

at Karlsruher Institut für Technologie

Join course
357
Discussion
Documents
Flashcards
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.
Hier ist mein Versuch der b)
Sicher, dass das geht? Ich dachte es wird zuerst WHERE, dann ORDER BY und schließlich GROUP BY ausgeführt. Dann würdest du die 3. Zeile auswählen, bevor überhaupt sortiert wurde.
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
No area was marked for this question
Frage zu A4 e) , woher kommt die Gleichung von c?
Abschlag soll größer als der durchschnittliche Abschlag für Werte mit Jahr 2017 sein
Kann man nicht auch die Locks beliebig positionieren, wie bei den Unlocks?
Semantikerhaltend ? Wieso?
Hey, hätte noch paar abschließende Fragen. Hoffe ihr könnt mir weiterhelfen: (1) Muss die Reihenfolge konfligierender Operationen in der GLEICHEN Transaktion festgelegt werden damit das als vollständige Historie zählt ? (2)Muss man bei einer Überprüfung auf konfliktäquivalenz auch nicht commitete Transaktionen/Operationen überprüfen ? (3)Kann beim Sperrprotokoll ein rl(x) auf zwei verschiedene Transaktionen übergeben werden ? (2 Reals konfligieren ja nicht) (4)Muss man bei einer Transaktion nun die Reihenfolge von zwei Schreiboperationen festlegen ? (In der Definition steht nur r < w, w < r)
Würde sagen: (1) Ja (2) Nein (3) Ja (4) Ja, aber nicht 100 Prozent sicher
Wow, danke !!!
No area was marked for this question
Ist das nicht = statt ⊆? Jedes Wohnhaus ist entweder Einfamilienhaus oder Mehrfamilienhaus.
Für Histories ist definiert, dass die Reihenfolge für konfligierende Operationen festgelegt werden muss. Für Transaktionen steht in den Vorlesungsfolien nur, dass zwischen lese und schreib Operationen die Reihenfolge festgelegt werden muss. Muss man also bei Transaktion nicht die Reihenfolge von 2 schreib Operationen auf das gleiche Objekt festlegen?
View 2 more comments
Also auch zwischen w/w ?
Hat er so gesagt, aber steht nicht auf der Folie, also bin ich mir nicht sicher
Diese Antwort sollte richtig sein. Denn Minimalität ist so definiert, dass man keine Regel weglassen kann, ohne dass die Vollständigkeit verloren geht. Ob es ein äquivalentes Kalkül mit weniger Regeln gibt(wie das RAP Kalkül) ist dabei nicht relevant
Laut der dritten Übung SS19 ist der Kalkül richtig
Genau, "Minimal" muss richtig sein
Ist das wirklich ein Zyklus, wenn die Abhängigkeit von verschiedenen Variablen ist?
ja
Das sieht leider nicht komplett korrekt aus. Die korrekte Lösung mit der gleichen Aufgabenstellung wurde im SS 2019 bei Frau Mülle besprochen (s. 5 Screenshots.)
hier haben wir eine zwingende Relation , d.h. wir können die Regel verschmelzen, Jetzt Die Frage welche N Seite wird gewält ?? Meine Meinung nach , einen von Beiden sind richtig . Oder bin ich falsch ??
View 1 more comment
braucht man hier denn 2 Schlüssel? die Auftragsnummer ist doch eigentlich schon eindeutig
`Ich bin der Meinung, dass Auftragsnummer hier als Schlüssel reicht. Jede Auftragnummer kommt einmal vor. D.h. das bestimmt die Kundennr. eindeutig. Die vereinbart ist unnötig. Kundennr. und Firmennr. könnten einfach in der Relation Auftrag stehen.
MAcht das hier wirklich Sinn? T2 committed zwar nicht, aber dafür T3 und T1.. also gibt es ja ein reads-from paar (r3x liest von w1x) , zudem committet c1 vor r3x..dh es müsste doch RC und ACA sein?
ja denke auch
Nicht möglich, da w1[y] und r2[y] fehlen
View 1 more comment
Oh mann, stimmt.
Eine miese Aufgabe! Krass dass du das siehst.
bcd. Denn a fehlt => Letzter Punkt in der Definition der vollständigen Historie verletzt abc? Nein. Dann hätte w4x kein Commit mehr. Damit ist das Ding keine Transaktion und deshalb auch keine Historie. Weder vollständige Historie noch Historie. abd? Da bin ich mir nicht sicher, Da Historie eine partielle Ordnung ist, ist Transitivität impliziert. https://de.wikipedia.org/wiki/Ordnungsrelation#Halbordnung Das heißt, obwohl es keinen direkten Pfeil zwischen den konfligierenden Operationen w3y und r4y gibt, reichen b und d aus. Das heißt, abd ist eine mögliche Antwort für Aufgabe 4.a.ii.1. Stimmt das?
View 3 more comments
Warum? diese zwei reads konfligieren ja nicht, brauchen also keine Ordnung
abcd ist auch eine mögliche Antwort für Teil 2
Locks freigeben vor oder nach Commit bei striktem 2PL?
Ich denke hier müsste [1, N] stehen weil N <=> TeilnehmerKardinalität(N) = [0,N]
View 3 more comments
Ohhh shit du hast recht, ich meinte das ganze Bezogen auf [1,1] -> 1. Ich denke es müsste [1,1] auch in StandardKardinalität sein
ja da hast du recht
Da fehlt doch noch die einführung der neuen FD: ABCDEGH -> Delta?
View 8 more comments
@Mi Hi, ja ich glaube du hast recht. Denk Fehler von meiner Seite. Denke Lösung von Zaheer Lüfter müsste dann passen.
Korrekt ist: {(AG, {AG}), (ABE, {A}), (BCD, {B}), (BGH, {BG}), (HB, {H})} Damit kann man es überprüfen: http://raymondcho.net/RelationalDatabaseTools/RelationalDatabaseTools
So ist A neuer Schlüssel und somit ist F in 2 NF, oder?
View 2 more comments
Ich hatte B -> D. A -> C geht auch.
D-->C geht glaub auch.
BCE ist auch Schlüssel, oder?
Sollte das alles nicht andersrum sein? also laut der Tabelle ist ja gefragt ob es die BCNF verletzt dann müssten hier überall wo ok steht nein stehen und da wo falsch steht ja stehen.
richtig
Fehlt hier nicht noch "gehört zu"? Also: gehört zu (_FahrgestellNr_, Bezeichnung)
View 7 more comments
Naja, es muss ja nicht alles 1 zu 1 in der Vorlesung/im Skript stehen :D Ich würde ,,verkaufen" auch ins Auto verschmelzen. Wenn man das Auto kennt, kennt man auch den Verkäufer und Käufer. Ich sehe kein Argument, warum das nicht gehen sollte.
Ich sehe es so wie Zeynep. @Kreditkarte Klar wäre das logisch aber überleg doch mal, du modelierst mehrere Autohäuser, viele Kunden geben ihr Auto in Zahlung wenn sie sich ein Fahrzeug kaufen und dann könnte das Autohaus das gleiche Fahrzeug wieder verkaufen. Meiner Meinung nach und so steht es auf den Folien müssten die ursprünglichen PrimärSchlüssel wieder PrimärSchlüssel sein. Ich denke hier geht es nicht um nachdenken was logisch ist, sondern einfach nur ums anwenden.
Weshalb sollte man bei a) joinen? Reicht nicht in etwa: SELECT product_id, COUNT(DISTINCT bidder_id) FROM interest GROUP BY product_id; ? =)
Für p7 hat niemand Interesse. Damit p7 auch im Ergebnis erscheint, wäre wohl der Join sinnvoll.
Vollkommen richtig! Mein Fehler
Raum nimmt doch 0..1 mal teil an der hat-büro beziehung. Daraus folgt doch ganz klar, dass ein Professor nicht unbedingt ein Büro haben muss.
View 2 more comments
Aber dennoch ja, wenn ich mir das jetzt genauer anguck, dann hast du Recht, ein Proffessor MUSS immer ein Büro haben, nur muss nicht jeder Raum das Büro eines Professors sein.
Ja da ist es genau so jeder professor muss genau ein raum haben also ein büro aber in einem raum kann auch kein prof ein büro haben
soll nicht nur die Menge der Bieter, also Count(Bidder.id) ausgegeben werden?
Wenn ich das richtig verstanden habe, ist die 1 in der Standardkardinalität eine [0,1]. In der Teilnehmerkardinalität stand da aber eine [1,1]. Ist es korrekt eine [1,1] in eine 1 bei Standardkardinalität umzuformen?
View 3 more comments
@Brief Wobei in der Übung TeilnehmerKardinalität [10,50] zu N wurde, ich finds mehr als verwirrend und verstehe auch den Sinn des Ganzen nichts. Kennt jemand zufällig eine Regel wie ich Teilnehmer- in Standard-Kardinalitäten umwandeln kann, gerade bei Dreistelleigen Relationen?
Bei mehrstelligen Relationen ist es meines Wissens nicht immer möglich eine Umwandlung zu machen. Das war doch ein Argument von Prof. Böhm warum jede dieser Kardinalitätsangaben seine Daseinsberechtigung hat.
Welchen Zweck hat dieses Konstrukt hier?
Müssen hier nicht beide zusammen unterstrichen, weil "P1 U P2 wird Primärschlüssel der Beziehung"?
View 1 more comment
ja kannst du beide mit einem einzigen strich untersteichen so ist es allerdings auch richtig
Die Aufstellung in der Übersicht in Kap 4&5, Folie 39 "Abbildung ER-Schema nach RDM" hat mich da verwirrt. Dort heißt es: 1:1 - P1 und P2 werden Schlüssel der Beziehung, m:n - P1 U P2 wird Primärschlüssel der Beziehung. Da bin ich mir nicht sicher, wie man den Unterschied grafisch zeigt, wenn nicht durch die einmal durchgängige Unterstreichung von P1 und P2 im n:m-Fall und der getrennten Unterstreichung von P1 und P2 im 1:1-Fall. (Oder wie macht man das?)
SELECT stadt, count(*) as gesamtZahl FROM( SELECT DISTINCT abflug as stadt, id FROM Flugstrecken UNION SELECT DISTINCT flugziel as stadt, id FROM Flugstrecken ) JOIN Buchungen b ON b.f_id = id GROUP BY stadt ORDER BY gesamtZahl ASC;
Schlüssel ist {BC , DE} richtig?
Da Kamera und Verschluss in einer 1:1 beziehung sind, könnte man dann nicht die Relationen zusammen nehmen? Sprich eine Relation Kamera(Seriennummer, Preis, Fertigungszeit, Fertigungsstraße, Lebensdauer) mit dem einzigen Schlüssel Seriennummer?
Sollten nicht in Fr2 enthalten sein das hier ist falsch
kann man nicht generell ohne schüssel der relation keine aussage treffen, welche abhänggkeiten in der relation bestehen?
du kannst eine aussage treffen einfach schauen ob alle Attribute links und rechts einer FD in der relation enthalten sind
Kann mir jemand bitte die Logik hinter dieser Gleichung erklären?
Kam das überhaupt in der VL dran? :D
könnte hier nicht sein {K1,K2,K3,K5 } ?
View 1 more comment
Ich habe (K4,K5,K7)
Ich habe k9 k7 k4 k5
Also ich hätte das so gemacht