Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
fragen zum skript
hi,
beim sysprog-lernen sind uns einige fragen aufgestossen, die ich hier mal zusammengefasst stelle:
-
seite 56: zum konstruktor des blockfile: bedeutet der dritte parameter blocksize, dass man die blocksize fuer jede neue datei separat angeben kann? das macht doch keinen sinn, sowas wird doch dateisystemweit bestimmt, oder?
-
seite 82: beim system dbtt: da steht bei der zuordnungstabelle, sie waere nur “fuer satztyp y”. was ist damit gemeint, was fuer andere satztypen kann es noch geben?
-
seite 116: warum wird binaere suche erschwert durch variabel lange eintraege? das hat doch nichts mit der laenge der eintraege zu tun, oder?
-
seite 225: meiner meinung nach repraesentiert die sql-abfrage nicht die geforderte anfrage. sieht das jemand auch so?
-
seite 421: was sind genau diese six-sperren? wann brauche ich die und kann jemand ein beispiel dazu bringen? wir haben uns einige gedanken darueber gemacht, die allesamt zu nichts gefuehrt haben :[…
-
seite 431: physisches und logisches protokollieren ist klar, aber was ist dann bitteschoen physiologisches protokollieren?
-
seite 433: was ist der unterschied der strategien steal und noforce? die beschreibungen sind sogar fast identisch…
auch antworten auf nur einen teil der fragen sind erwuenscht! danke!
Also sämtliche Fragen, die du gestellt hast, waren auch mir nicht so ganz klar (zudem aber auch noch einige andere).
Ich glaube schon, dass die sql-Anfrage auf 225 dem entspricht, was oben ausformuliert steht. Allerdings ist auch mir diese ausformulierte Anfrage ein wenig komisch im Verständnis - womöglich habe ich sie ja auch falsch verstanden und Du liegst mit Deiner Vermutung richtig:
Auswertungsreihenfolge ist ja where → group by → having → select. Also müsste doch erstmal eine Tabelle entstehen in der alle Gehälter derjenigen Angestellten drinstehen, die mehr verdienen als ihr Vorgesetzter, sowie die ANr und die Abteilungsbezeichnung. Dann wird nach der Bezeichnung gruppiert und schließlich der Maximalwert für das Gehalt selektiert. Übrig bleibt also eine Zeile, in welcher der gewünschte Maximalwert steht.
Könnte jemand die Anfrage zu 224 posten (vielleicht steht sie ja schon irgendwo, dann sagt mir doch bitte wo) ?
Seite 251: da steht “select *” wäre keine gute Idee. Weshalb? Was ist daran so schlimm 
?
Verzeiht, wenn diese Frage blöd ist, aber: ist der Unterschied zwischen “UNIQUE” und “UNIQUE NOT NULL” einfach nur der (1,1) <-> (0,1) ?
weitere Fragen folgen…
to be continued 
Gruß
Marco
Unique heißt, das das Element Schlüsselkandidat ist, d.h. es darf kein Wert doppelt vorkommen, NOT NULL ist dann zusätzlich noch, das es keinen NULL-Eintrag haben darf, also wenn du z.B. eine TAbelle hast mit Gehalt, Mitarbeiternr. und Namen, dann ist die Nr der Primärschlüssel, muss also UNIQUE NOT NULL sein, da sie einzigartig sein muss in der Relation und es darf keinen NULL-Eintrag geben(sonst wäre der entsprechende Mitarbeiter nicht mehr eindeutig identifizeirbar) wenn du etz noch willst das jeder Mitarbeiter auf alle Fälle ein Gehalt bekommen soll, dann sagst du dass das NOT NULL sein solll.
Hoffe, das war die Antwort die du wolltest, ein bisschen viel geschwafelt…
Ob das in den Wertigkeiten dann enthalten ist, weiß ich nich…
Das mit dem “kein Gehalt” liest sich etwas schwammig, denn kein Gehalt kann man auch als Gehalt == 0 auffassen. Man bedenke, dass NULL != 0.
Ich weiss, nix spektakuläres, nur um vorzusorgen, dass sich da keiner vertut
Ich hab auch noch ne Frage zu DBTT:
Da steht ja:
Verwaltung eines Feldes, das zu jeder Satznummer Blocknummer und Byte-Position enthaelt.
Meiner Meinung nach stimmt das Bild damit aber nicht ueberein, da dort ja im Feld nur der Block steht und die Byte-Position in Block gespeichert ist.
Seht ihr das auch so?
Vielleicht ist der Satztyp ein Feature, das die Anwendung nutzen kann um Saetze zu differenzieren, damit die Suche im Feld nach dem passenden Block/Offset beschleunigt werden kann.
Ist aber natuerlich nur geraten…
zum DBTT: da hast du IMO recht. denn es wird ja ausdruecklich von einem feld gesprochen, die grafik deutet aber anderes an. das verwirrt eigentlich total, denn im TID konzept wird die idee, die eigentlichen bytegenauen positionen im block selber zu speichern, gross hervorgehoben, obwohl die grafik dasselbe schon fuer DBTT vermuten laesst.
IMO: naja im TID konzept hatten wir ja die 3 bits, die direkten, indirekten und fragmentierten satz unterschieden. hier wirds halt ueber verschiedene tabellen gemacht.
zu s. 56: hmm. ich glaube, die blockgroesse die dasteht hat nix mit der blockgroesse auf einer platte zu tun. andererseits ist es schon komisch, dass ich jeder datei eine andere blockgroesse geben kann; geht doch sonst nur fs-wide?! (man mkfs.ext2 und konsorten …)
Also, ich stell mir das so vor:
Ich möchte in einer Tabelle auf alle Tupel lesend zugreifen, aber auch ein paar verändern. Also brauch ich ein S auf die Tabelle, aber auch ein IX, auf Tupel-Ebene hab ich dann noch das eigentliche X auf ein paar Tupeln. Wenn das S und das IX von zwei unterschiedlichen Transaktionen kommen würde, würde es nicht zusammenpassen. Aber für eine Transaktion gleichzeitig ist es erlaubt, derjenige der die Transaktion programmiert muss dann halt aufpassen dass alles konsistent bleibt.
Ich könnte natürlich auch gleich ein X auf die Tabelle machen, dann geht’s auch. Allerdings können dann die anderen Transaktionen nicht mehr lesend zugreifen (bei SIX können sie es, natürlich bis auf die einzelnen Tupel die noch extra mit X gelockt sind).
@leonidas: danke! super erklaerung, klingt jetzt richtig logisch.
ich muss mir das nochmal an ein paar beispielen klar machen.
zu Seite 116:
Bei der binären Suche versucht man ja immer die Mitte seiner Liste zu finden und sein aktuelles Element damit zu vergleichen. Durch die variable Länge der Einträge kann man die Position der Mitte nicht berechnen, sondern muss entweder von vorne abzählen und dann kann man gleich sequenziell suchen, oder man baut eben ne weitere Indirektion ein…
Ich habe das Konzept zur Überlaufbehandlung auf Seite 100 nicht verstanden. Kann mir jemand sagen was diese Binärwerte bedeuten und woher sie kommen?
Außerdem verstehe ich noch nicht, wie man in B*-Bäumen einfügt. Leonidas hatte ja schon einmal gefragt, wenn also jetzt jemand eine Antwort weiß… Was ist nun richtig: Seite 142 oder 143? Soll nun der Splitt beim B*-Baum durchgeführt werden oder neu gemischt werden?
Es werden immer wieder die “inhärenten Konsistenzregeln” erwähnt - eine genaue Definition kann ich aber nirgendfinden(S. 189 etc.). Oder wo steht das im Skript ?
Und noch eine letzte Frage zu S. 385: Was heißt “Verbundpartner müsste sich unter dieser Adresse befinden” ? Kapiere das Schema nicht.
Vielen Dank
Gruß, marco
und noch ne frage: was soll das mit dem 2-Phasen-Sperrprotokoll? erwaehnt ist das bei den Sperren auf der letzten folie, aber auch nur da. Hat er das vielleicht ausm stoff genomm?
hatten wir in einem anderen thread… irgendwas mit bekommen und weggeben oder so
das ist bloss die hash-berechnung fuer den schluessel k02. das ganze laeuft nach extended binary coded decimal interchange code. dann xoren und mod nehmen und es kommt der bucket 3 raus.
inhaerent = referenzielle integritaet (fremdschluessel vorhanden) + einzigartigkeit von primaerschluesseln
das muss das db-system garantieren.
das verbundattribut ist ja z. b. r.a = s.b; jetzt wird relation r nach a gehasht und eine tabelle aufgebaut. dann wird relation s nach b gehasht, wenn ein verbundpartner mit der obigen bedingung exisitiert, muss er sich ja im selben bucket befinden. muss er aber nicht, weil vielleicht gibt es ja kein passendes tupel.
Wo wir grad beim Hashen sind:
Was sind diese “Bereiche” [Treffer und Rest]? Sind das Teile des Wertebereichs des Verknuepfungsattributs?
das ist bloss die hash-berechnung fuer den schluessel k02. das ganze laeuft nach extended binary coded decimal interchange code. dann xoren und mod nehmen und es kommt der bucket 3 raus.
Ja aber woher kommen diese Zahlen? da steht: nimm EBCDIC-Darst. jedes Zeichens und… Von welchen Zeichen ist da die Rede?
was, wie und vor allem - wo?
von den zeichen des attributs, nach dem gehasht wird, also ueber welches z. b. ein index angelegt wird. wenn z. b. ein index in einer personenrelation ueber „nachname“ angelegt wird, liefert „meyer-wegener“ eine entsprechende summe in ebcdic-darstellung, die dann gehasht wird. got it?
uebrigens ist das voellig unwichtig, nur so am rande…
ok, danke trotz der unwichtigkeit dessen!
Die meinen ein Satz aus einer Tabelle. Jede Tabelle hat ne andere Struktur und damit sehen auch die Sätze anders aus.
Mein Gott, wegen einem kleinen Wort irgendwo ganz unten auf eine unbedeutenden Folie… 
Sagen wir es bedeuted beides zusammen… 
Hoffentlich nicht zu spät… bin grade erst fertig geworden.
Alle Angaben sind in diesem Fall ausdrücklich ohne Gewähr…