Gedächtnisprotokoll GDB09-1: Unterschied zwischen den Versionen
(23 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
Die GDB-Klausur im WS08/09 fand am 16.02.2009 statt und wurde im Audimax1 geschrieben. Beaufsichtigt wurde die Klausur von Norbert Ritter und Fabian Panse sowie drei weiteren Übungsgruppenleitern. | |||
Zu erreichen waren 120Pkt, wobei 100Pkt als 100% gerechnet wurden, d.h. 20Bonuspunkte für alle. Es waren 120Min. Zeit die Klausur zu bearbeiten, nach etwa einer Stunde hat Herr Ritter nochmal 20Min. extra gegeben, diese waren zu vollständigen Bearbeitung auch nötig. | |||
Bereits am späten Abend des 17.02.09 hingen die vorläufigen Ergebnisse im Ikum aus, der Schnitt lag bei 2.55 und bestanden hatten 89,47%. | |||
== ER-Diagram == | == ER-Diagram == | ||
Krankenhausangestellte (Hilfskräfte und Ärzte) und Patienten. Behandlung, Medikament und Krankheiten. | |||
== ERM nach RM == | == ERM nach RM == | ||
Parteien, Fraktionen, Personen, Abgeordnete und Ausschüsse | Gegeben war ein ER-Diagramm mit Parteien, Fraktionen, Personen, Abgeordnete und Ausschüsse. | ||
Person war eine Generalisierung auf die Abgeordneter zeigte. Abgeordnete konnten Ausschuss angehören.Parteien konnten einer Fraktion angehören usw. . | |||
Dann sollte das relationale Schema erstellt werden. | |||
== Relationenalgebra und SQL == | == Relationenalgebra und SQL == | ||
Relationen: | |||
Person(PNr, Vorname, Nachname, Alter, ?, Werber-->Person.PNr), | |||
Artikel(ANr, Name, Bezeichnung, Verkäufer-->Person.PNr, ?), | |||
?, | |||
Gebot(Bieter-->Person.Nr, Artikel-->Artikel.ANr, Preis, Datum), | |||
== SQL? == | |||
== Sichten == | |||
=== Änderbarkeit von Sichten === | |||
Gegeben waren vier Sichten auf eine Basisrelation Musiker. Dazu gab es 5 Konfigurationen bei denen einige Sichte with CASC gekennzeichnet waren. | |||
Man sollte nun eine Tabelle für die Konfigurationen und 4 Änderungen der Sichten ausfüllen. | |||
=== Änderungsanomalien === | |||
Gegeben waren T_1 und T_2 mit ihren Aktionen zu den Zeitpunkten 1-5. Hier sollte zu Zeitpunkt 3 eine Aktion in T_2 definiert werden, die bei T_1 ein non-repeatable-read auslöst. | |||
Anhand dieses Beispiels sollte man dann auch noch non-repeatable-read erklären. | |||
== Transaktionen == | == Transaktionen == | ||
Gegeben war je der Scheduler von drei Transaktionen. | |||
=== Sind die Transaktion serialisierbar? === | |||
a) Nein, es gab einen Konflikt, da T_1 erst x gelesen hat, dann T_3 x geschrieben und dann wiederum T_1 x gelesen hat. | |||
b) Ja, T_3, T_2, T_1 oder T_2, T_3, T_1 | |||
c) Ja, .... | |||
== Normalisierung == | |||
atomare Attribute: S, T, O, Z, D, N | |||
Funktionale Abhängigkeiten (so ungefähr ;-): | |||
FA1: S -> N | |||
FA2: N -> Z | |||
FA3: S,D -> O,T | |||
FA4 D,N -> O,Z | |||
FA5: Z -> O | |||
F = (FA1, FA2, FA3, FA4, FA5) | |||
Relation R = (S,T,O,Z,D,N) | |||
a) Geben sie die Schlüsselkanditaten von R in Abhängigkeit von F an. | |||
b) Geben sie die Nicht-Schlüsselattribute an. | |||
c) In welcher Normalform wäre eine Relation mit einem Primärschlüssel aus teil a)? Warum genau in dieser? | |||
== Löschen und Einfügen im Baum == | == Löschen und Einfügen im Baum == | ||
=== Einfügen im B-Baum === | |||
Gegeben war ein B-Baum und Werte die eingefügt werden sollten. Nach jedem Split sollte der Baum neu gezeichnet werden und auch die Aktion zum Einfügen sollte angegeben werden(einfach, Mischen, Split). | |||
=== Löschen im B-Baum === | |||
Gegeben war ein B-Baum und Werte die gelöscht werden sollten. Nach jedem Split sollte der Baum neu gezeichnet werden und auch die Aktion zum Einfügen sollte angegeben werden(einfach, Mischen, Ausgleich). | |||
== Berechnungen im Baum == | == Berechnungen im Baum == | ||
Gegeben waren ein maximal gefüllter B-Baum <math>\tau(3,2)</math> und ein minimal gefüllter B*-Baum <math>\tau(2,3,2)</math>. | |||
Wie viel Knoten müssen gelesen werden um alle Daten auszulesen? | |||
Wie viele Knoten müssen maximal gelesen werden um ein zufälliges Datum zu finden? | |||
... | |||
In einer (fiktiven) DB sei die Seitengröße L = 800B. Die Werte für einen B*-Baum (k,k*,h) sind: | |||
<math>l_M = 4B,\quad l_K = 8B, \quad l_D = 160B, \quad l_P = 4B</math> | |||
Wie groß sind k und k*? | |||
== XPath == | == XPath == | ||
Gegeben war eine DTD mit dem Szenario: Liga, Vereine, Spieler, Präsident, Person, Vorstand usw. | |||
=== a) XPath-Anfragen in normale Sprache übersetzen === | |||
Da kamen solche Sachen wie: | |||
* Der Spieler der beim FC St. Pauli auf der gleichen Position spielt wie ein Spieler mit dem Namen "Klose". | |||
* Alle Personen die im Vorstand sitzen, mit dem Präsidenten "Klaus" | |||
* ... | |||
=== b) Sprachliche Anfragen in XPath übersetzen. === | |||
[[Kategorie:Gedaechtnisprotokoll|GDB]] | [[Kategorie:Gedaechtnisprotokoll|GDB]] |
Aktuelle Version vom 18. Februar 2009, 13:25 Uhr
Die GDB-Klausur im WS08/09 fand am 16.02.2009 statt und wurde im Audimax1 geschrieben. Beaufsichtigt wurde die Klausur von Norbert Ritter und Fabian Panse sowie drei weiteren Übungsgruppenleitern. Zu erreichen waren 120Pkt, wobei 100Pkt als 100% gerechnet wurden, d.h. 20Bonuspunkte für alle. Es waren 120Min. Zeit die Klausur zu bearbeiten, nach etwa einer Stunde hat Herr Ritter nochmal 20Min. extra gegeben, diese waren zu vollständigen Bearbeitung auch nötig.
Bereits am späten Abend des 17.02.09 hingen die vorläufigen Ergebnisse im Ikum aus, der Schnitt lag bei 2.55 und bestanden hatten 89,47%.
ER-Diagram[Bearbeiten]
Krankenhausangestellte (Hilfskräfte und Ärzte) und Patienten. Behandlung, Medikament und Krankheiten.
ERM nach RM[Bearbeiten]
Gegeben war ein ER-Diagramm mit Parteien, Fraktionen, Personen, Abgeordnete und Ausschüsse. Person war eine Generalisierung auf die Abgeordneter zeigte. Abgeordnete konnten Ausschuss angehören.Parteien konnten einer Fraktion angehören usw. .
Dann sollte das relationale Schema erstellt werden.
Relationenalgebra und SQL[Bearbeiten]
Relationen:
Person(PNr, Vorname, Nachname, Alter, ?, Werber-->Person.PNr),
Artikel(ANr, Name, Bezeichnung, Verkäufer-->Person.PNr, ?),
?,
Gebot(Bieter-->Person.Nr, Artikel-->Artikel.ANr, Preis, Datum),
SQL?[Bearbeiten]
Sichten[Bearbeiten]
Änderbarkeit von Sichten[Bearbeiten]
Gegeben waren vier Sichten auf eine Basisrelation Musiker. Dazu gab es 5 Konfigurationen bei denen einige Sichte with CASC gekennzeichnet waren. Man sollte nun eine Tabelle für die Konfigurationen und 4 Änderungen der Sichten ausfüllen.
Änderungsanomalien[Bearbeiten]
Gegeben waren T_1 und T_2 mit ihren Aktionen zu den Zeitpunkten 1-5. Hier sollte zu Zeitpunkt 3 eine Aktion in T_2 definiert werden, die bei T_1 ein non-repeatable-read auslöst. Anhand dieses Beispiels sollte man dann auch noch non-repeatable-read erklären.
Transaktionen[Bearbeiten]
Gegeben war je der Scheduler von drei Transaktionen.
Sind die Transaktion serialisierbar?[Bearbeiten]
a) Nein, es gab einen Konflikt, da T_1 erst x gelesen hat, dann T_3 x geschrieben und dann wiederum T_1 x gelesen hat. b) Ja, T_3, T_2, T_1 oder T_2, T_3, T_1 c) Ja, ....
Normalisierung[Bearbeiten]
atomare Attribute: S, T, O, Z, D, N
Funktionale Abhängigkeiten (so ungefähr ;-):
FA1: S -> N
FA2: N -> Z
FA3: S,D -> O,T
FA4 D,N -> O,Z
FA5: Z -> O
F = (FA1, FA2, FA3, FA4, FA5)
Relation R = (S,T,O,Z,D,N)
a) Geben sie die Schlüsselkanditaten von R in Abhängigkeit von F an.
b) Geben sie die Nicht-Schlüsselattribute an.
c) In welcher Normalform wäre eine Relation mit einem Primärschlüssel aus teil a)? Warum genau in dieser?
Löschen und Einfügen im Baum[Bearbeiten]
Einfügen im B-Baum[Bearbeiten]
Gegeben war ein B-Baum und Werte die eingefügt werden sollten. Nach jedem Split sollte der Baum neu gezeichnet werden und auch die Aktion zum Einfügen sollte angegeben werden(einfach, Mischen, Split).
Löschen im B-Baum[Bearbeiten]
Gegeben war ein B-Baum und Werte die gelöscht werden sollten. Nach jedem Split sollte der Baum neu gezeichnet werden und auch die Aktion zum Einfügen sollte angegeben werden(einfach, Mischen, Ausgleich).
Berechnungen im Baum[Bearbeiten]
Gegeben waren ein maximal gefüllter B-Baum <math>\tau(3,2)</math> und ein minimal gefüllter B*-Baum <math>\tau(2,3,2)</math>.
Wie viel Knoten müssen gelesen werden um alle Daten auszulesen? Wie viele Knoten müssen maximal gelesen werden um ein zufälliges Datum zu finden? ...
In einer (fiktiven) DB sei die Seitengröße L = 800B. Die Werte für einen B*-Baum (k,k*,h) sind:
<math>l_M = 4B,\quad l_K = 8B, \quad l_D = 160B, \quad l_P = 4B</math>
Wie groß sind k und k*?
XPath[Bearbeiten]
Gegeben war eine DTD mit dem Szenario: Liga, Vereine, Spieler, Präsident, Person, Vorstand usw.
a) XPath-Anfragen in normale Sprache übersetzen[Bearbeiten]
Da kamen solche Sachen wie:
- Der Spieler der beim FC St. Pauli auf der gleichen Position spielt wie ein Spieler mit dem Namen "Klose".
- Alle Personen die im Vorstand sitzen, mit dem Präsidenten "Klaus"
- ...