Einsendearbeit 2 1672

EA 2 (1672)

Bisher habe ich lediglich Aufgabe 3 fertig:

create DATABASE autovermietung;

use autovermietung;

create TABLE Mietwagen (
Kennzeichen VARCHAR(12) NOT NULL PRIMARY KEY,
Marke VARCHAR(30) NOT NULL,
Sprit_Verbrauch FLOAT NOT NULL,
Preis FLOAT NOT NULL
);

create TABLE Mieter (
M_Nr INT(11) NOT NULL AUTO_INCREMENT PRIMARY KEY,
M_Name VARCHAR(50) NOT NULL,
M_Strasse VARCHAR(50) NOT NULL,
M_Stadt VARCHAR (30) NOT NULL
);

create TABLE Filiale (
F_Nr INT(11) NOT NULL AUTO_INCREMENT PRIMARY KEY,
F_Strasse VARCHAR(50) NOT NULL,
F_Stadt VARCHAR (30) NOT NULL,
Leiter VARCHAR (50) NOT NULL
);

create TABLE Reise (
Mieter INT NOT NULL,
Leihdatum DATE NOT NULL,
Abgabedatum DATE NOT NULL,
Leih_Filiale INT NOT NULL,
Abgabe_Filiale INT NOT NULL,
Kfz VARCHAR(12) NOT NULL,
PRIMARY KEY (Mieter, Leihdatum),
CONSTRAINT Mieter_M_Nr_fk FOREIGN KEY (Mieter) REFERENCES Mieter (M_Nr) ON DELETE CASCADE,
CONSTRAINT Filiale_Leih_Filiale_fk FOREIGN KEY (Leih_Filiale) REFERENCES Filiale (F_Nr) ON DELETE CASCADE,
CONSTRAINT Filiale_Abgabe_Filiale_fk FOREIGN KEY (Abgabe_Filiale) REFERENCES Filiale (F_Nr) ON DELETE CASCADE,
CONSTRAINT Mietwagen_Kennzeichen_fk FOREIGN KEY (Kfz) REFERENCES Mietwagen (Kennzeichen) ON DELETE CASCADE
);

Hab's bei mir in MySQL eingepflanzt und mit Testwerten bestückt. Funktioniert alles einwandfrei. Die VARCHAR-Werte sind Geschmackssache, beim Preis könnte man auch DECIMAL anstatt FLOAT verwenden (benötigt aber 1 Byte mehr Speicher ^^). Mal sehen, ob ich noch eine Überprüfung für Leihdatum <= Abgabedatum einbaue, immerhin sollte das Abgabedatum nicht vor dem Leihdatum sein. Ein Workaround ist ein View, das einem alle Fehler diesbezüglich anzeigt:

CREATE VIEW fehler AS SELECT * FROM Reise WHERE Leihdatum > Abgabedatum;

Dann kann man später mit "select * from fehler;" direkt alle Falscheingaben auflisten.
Einige in der Newsgroup verwenden übrigens UNIQUE und PRIMARY KEY zusammen, das ist jedoch verboten und führt zu Fehlern.

Grüße,
Marcel
 
Ich bin noch sehr von Wissensbasierte Systeme eingenommen, darum dauert's bei DBII dieses Mal länger.

Meine Ansätze für Aufgabe 1 und 2:

1a)
siehe S.17 - Bei Systemzusammenbrüchen muss nun nicht mehr das gesamte Log nach offenen Transaktionen durchsucht werden, sondern nur noch jene, die zum Zeitpunkt zwischen Systemzusammenbruch und letztem Checkpoint offen waren. Den Begriff "offen" verwende ich hier sysonym zu "nicht-abgeschlossen" von Seite 15 im Skript.

1b)
Analog zum Algorithums von S.17:
TC = T3
TA = T4
TB = T5
Führe UNDO auf T3, T4 aus.
Führe REDO auf T5 aus.

1c)
Wenn das Herausschreiben der veränderten Daten zum Ende jeder einzelnen Transaktion (EOT) geschieht, dann benötigt man kein REDO mehr für Transaktionen, die vor dem Systemszusammenbruch beendet wurden. Man hätte also eine UNDO/NO-REDO recovery, weshalb keine after-images mehr benötigt werden.


2a)
S. 15

2b)
after-image bei Recoverys mit REDO (= UNDO/REDO und NO-UNDO/REDO)
before-image bei Recovery mit UNDO (=UNDO/REDO und UNDO/NO-REDO)

2c)
after-image: nach erfolgter Transaktion
before-image: zu Beginn einer Transaktion

2d)
after-image: bis zum nächsten Checkpoint
before-image: bis zum Ende der Transaktion (bzw. nach Erzeugung des after-image)

Bei Aufgabe 1 bin ich mir nicht ganz sicher. Aber nach 100 Punkten bei EA 1 kann ich da sehr entspannt bleiben ;)
 
Hallo, wollte mal meine Ergebnisse vergleichen:
1a)
Bei einem "Checkpoint" werden im einfachsten Fall alle aktiven Transaktionen im Log festgehalten. Dies dient dazu, dass bei einem Abbruch nicht das ganze Log nach aktiven Transaktionen durchsucht werden muss, sondern nur bis zum Checkpoint. Außerdem werden beim Checkpoint-schreiben alle After-Images der zu diesem Zeitpunkt abgeschlossenen Transaktionen sowie die Before-Images der abgebrochenen in die Datenbank geschrieben, da nicht zwangsläufig alle Daten im Log bereits in der Datenbank geschrieben wurden.

1b)
Aktive Transaktion beim letzten Checkpoint tc: T3.
Ab hier wird das Log durchsucht, was bedeutet T1 und T2 werden nicht mehr betrachtet, da sie beim Checkpoint bereits COMMIT gemeldet hatten und beim Checkpoint in die Datenbank übernommen wurden.
Im Log werden ungespeicherte Transaktionen gefunden: T4 und T5.
T3 und T4 waren bei Systemzusammenbruch noch aktiv, T5 hat bereits COMMIT gemeldet.
Damit muß ein UNDO für die Transaktionen T3 und T4 ausgeführt werden und ein REDO für Transaktion T5

1c)
Wenn die Daten bei EoT in die Datenbank übernommen werden und erst dann ein COMMIT erfolgt, werden keine REDO-Operationen benötigt, da Transaktionen entweder noch aktiv sind oder bereits in der Datenbank gespeichert wurden.
Deshalb wird dieses Verfahren UNDO/NO-REDO genannt.
Das heißt in obigem Szenario müssen lediglich T3 und T4 zurückgesetzt werden mit UNDO T3 und UNDO T4.
T1 und T2 waren ja schon vor dem Checkpoint abgeschlossen, werden also nicht mehr betrachtet und T5 hat bereits COMMIT gemeldet, ist also in der Datenbank gespeichert.

2a)
Bei einem Before-Image handelt es sich und den Zustand aller von der Transaktion betroffenen Daten vor Ausführung der Transaktion.
Gespeichert wird für jedes Datenobjekt die Identifikation des Objektes,
der Wert vor der Veränderung und die Identifikation der ändernden Transaktion.
Ein After-Image ist wie das Before-Image, jedoch wird hierbei der Wert nach der Veränderung gespeichert, nicht der davor.

2b)
Die UNDO/REDO Recovery benötigt sowohl Before als auch After-Image.
Die UNDO/NO-REDO Recovery benötig nur das Before-Image, da lediglich UNDO-Operationen ausgeführt werden, keine REDO-Operationen.
Die NO-UNDO/REDO Recovery führt lediglich REDO-Operationen durch, womit sie auch nur die After-Images benötigt und keine Before-Images.
Da die NO-UNDO/NO-REDO im Gegensatz zu den Log-Verfahren ein Shadow-Verfahren ist, kann hier auf die Images komplett verzichtet werden, statt dessen wird auf sogenannten Haupt- und Hilfskatalogen gearbeitet.

2c)
Bevor ein geändertes Objekt in die Datenbank geschrieben wird muss mindestens das Bevore-Image im Log gespeichert sein.
Bevor eine Transaktion COMMIT ausführen kann, muss zunächst das After-Image im Log gespeichert sein.

2d)
Diese Logs müssen mindestens bis zum nächsten Checkpoint aufbewahrt werden.

3)
CREATE TABLE Mietwagen (
Kennzeichen VARCHAR(20) NOT NULL PRIMARY KEY,
Marke VARCHAR(100) NOT NULL,
Sprit_Verbrauch FLOAT,
Preis FLOAT NOT NULL
);


CREATE TABLE Mieter (
M_Nr INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY,
M_Name VARCHAR(100) NOT NULL,
M_Strasse VARCHAR(100) NOT NULL,
M_Stadt VARCHAR (100) NOT NULL
);

CREATE TABLE Filiale (
F_Nr INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY,
F_Strasse VARCHAR(100) NOT NULL,
F_Stadt VARCHAR (100) NOT NULL,
Leiter VARCHAR (100) NOT NULL
);

CREATE TABLE Reise (
Mieter INTEGER NOT NULL,
Leihdatum DATE NOT NULL,
Abgabedatum DATE,
Leih_Filiale INTEGER NOT NULL,
Abgabe_Filiale INTEGER,
Kfz VARCHAR(20) NOT NULL,
PRIMARY KEY (Mieter, Leihdatum),
FOREIGN KEY (Mieter) REFERENCES Mieter (M_Nr) ON DELETE CASCADE,
FOREIGN KEY (Leih_Filiale) REFERENCES Filiale (F_Nr) ON DELETE CASCADE,
FOREIGN KEY (Abgabe_Filiale) REFERENCES Filiale (F_Nr) ON DELETE CASCADE,
FOREIGN KEY (Kfz) REFERENCES Mietwagen (Kennzeichen) ON DELETE CASCADE
);

Sind damit ziemlich ähnlich mit den obigen... :cool:
 
Top