Prof. Dr.-Ing. Johannes Schildgen
johannes.schildgen@oth-regensburg.de

Datenbanken

Kapitel 5: Mehrbenutzerbetrieb

2020-12-11

In diesem Kapitel...

... definieren wir Sichten,
... lernen, wie man DB-Benutzer und Rollen verwaltet,
... schauen wir uns das Transaktionenkonzept genauer an,
... erfahren wir, wie man Mehrbenutzeranomalien vermeidet
... und wie Recovery-Mechanismen funktionieren.

Datenabstraktion

Externe Ebene (Sichten / Views)

Sicht auf eine Teilmenge des
logischen Schemas für eine
bestimmte Benutzergruppe

Logische Ebene

DB-Gesamt-Schema

Physische Ebene

Internes Schema / Speicherung der Daten

Sicht

log. Schema

int. Schema

Datenabstraktion (Bsp.)

Externe Ebene (View für Webshop-Anwendung)

Produktnr	Bezeichnung	Preis	Bewertung
17	Schokoriegel	0.89	4.5
29	Spülmaschinentabs	3.99	2.0

Logische Ebene

Produktnr	Bezeichnung	Preis
17	Schokoriegel	0.89
29	Spülmaschinentabs	3.99

Kundennr	Produktnr	Bew
5	17	4
8	17	5
5	29	2

Physische Ebene: 0010110000000100101111010101...

Sichten / Views in SQL

94-96

Produktnr	Bezeichnung	Preis	Hersteller	Bewertung
17	Schokoriegel	0.89	Monsterfood	4.5
18	Müsliriegel	1.19	Monsterfood	-
29	Spülmaschinentabs	3.99	Calgonte	2.0

CREATE VIEW produkte_view AS
SELECT P.produktnummer, P.bezeichnung, P.preis, P.hersteller, 
       AVG(B.sterne) AS bewertung
FROM produkte P LEFT JOIN bewertungen B 
     ON P.produktnummer = B.produktnummer
GROUP BY P.produktnummer, P.bezeichnung, P.preis, P.hersteller

SELECT * FROM produkte_view

Views / Sichten in SQL

CREATE VIEW teure_produkte AS SELECT * FROM produkte 
                               WHERE preis > 10;

SELECT * FROM teure_produkte WHERE hersteller = 'Monsterfood'

wird ausgeführt als:

SELECT * FROM (SELECT * FROM produkte WHERE preis > 10)
WHERE hersteller = 'Monsterfood'

SELECT * FROM produkte WHERE preis > 10 AND hersteller = 'Monsterfood'

Liefert etwas komplett anderes
Gibt das gleiche zurück, ist aber schneller
Gibt das gleiche zurück, ist aber langsamer
Gibt das gleiche zurück und ist gleich schnell

https://frage.space

Erfolgt eine Abfrage auf eine View, wird der Name der View durch die Anfrage ersetzt, über die die View definiert ist. Danach erfolgen Optimierungen, sodass die hier dargestellt Anfrage äquivalent ist zu SELECT * FROM produkte WHERE preis > 10 AND hersteller = 'Monsterfood'. Anfragen auf Sichten sind nicht langsamer als die hinter der Sicht stehende Abfrage direkt auszuführen, sie sind aber auch nicht schneller.

Einsatzszenarios von Views

Vereinfachung / Speicherung von Anfragen

CREATE VIEW produkte_view AS ...

Datenunabhängigkeit

Anwendungen greifen über View auf Daten zu; unabhängig, wie die tatsächlichen Tabelle aussehen.

Datenschutz

Benutzern wird nur der Zugriff auf die View gewährt, nicht auf die zugrundeliegenden Tabellen.

CHECK OPTION

106

INSERT, UPDATE und DELETE sind auf simplen Projektion/Selektion-Views erlaubt.

CREATE VIEW teure_produkte AS SELECT * FROM produkte 
                            WHERE preis > 10;

INSERT / UPDATE funktioniert ohne Überprüfung des WHERE-Prädikats.

WITH CHECK OPTION

CREATE VIEW teure_produkte AS SELECT * FROM produkte 
                            WHERE preis > 10 WITH CHECK OPTION;

Das einzufügende oder zu ändernde Tupel muss das WHERE-Prädikat erfüllen.

INSERT INTO teure_produkte (produktnr, bezeichnung, preis) VALUES (123, 'X', 5)

funktioniert nie
funktioniert in den beiden hier gezeigten Sichten nicht
funktioniert in der oberen, aber nicht in der unteren Sicht
funktioniert in der unteren, aber nicht in der oberen Sicht

https://frage.space

Ein INSERT INTO teure_produkte ist hier möglich. Im unteren Fall jedoch nur, wenn das neue Produkt auch einen Preis von mehr als 10 EUR hat. WITH CHECK OPTION ist eine Kurzschreibweise für WITH LOCAL CHECK OPTION. Wenn eine View mit dieser Option eine andere View in der FROM-Klausel hat, wird nicht das Prädikat der anderen View überprüft, außer: Für diese ist ebenfalls eine CHECK OPTION gesetzt, oder wir spezifizieren für die View: WITH CASCADED CHECK OPTION.

Materialisierte Sichten

Views sind nur virtuell, sie speichern nicht wirklich Daten.

Materialisierte Sichten jedoch speichern physisch das Ergebnis der dahinterstehenden Anfrage.

CREATE MATERIALIZED VIEW anz_produkte AS 
SELECT COUNT(*) as anz FROM produkte;

REFRESH MATERIALIZED VIEW

SELECT * FROM anz_produkte; -- zeigt an: 8
INSERT INTO produkte (produktnr, bezeichnung) values (123, 'X'); 
SELECT * FROM anz_produkte; -- zeigt immer noch 8
REFRESH MATERIALIZED VIEW anz_produkte;
SELECT * FROM anz_produkte; -- zeigt nun 9

Beim Erstellen einer materialisierten Sicht, wird diese initial mit dem Anfrageergebnis befüllt. Es gibt Datenbankmanagementsysteme, die ein automatisches Auffrischen unterstützen. Dies erfolgt, wenn sich die Daten in den Basistabellen ändern. In PostgreSQL ist beinhaltet die materialisierte Sich in diesen Fällen veraltete Daten. Mit REFRESH MATERIALIZED VIEW kann ein Auffrischen angestoßen werden.

Benutzer und Rollen

CREATE USER doktor_x WITH PASSWORD 'geheimespasswort1';
CREATE USER schwester_y WITH PASSWORD 'geheimespasswort2';
CREATE USER big_boss WITH PASSWORD 'geheimespasswort3';
CREATE USER ninja WITH PASSWORD 'geheimespasswort4';

Die Data Control Language (DCL) wird genutzt, um Benutzer und Rollen anzulegen. Hier legen wir vier Benutzer an. Diese können sich mit dem angegebenen Nutzernamen und Passwort mit der Datenbank verbinden. In PostgreSQL sind Benutzer und Rollen übrigens das gleiche. CREATE USER ist lediglich ein Alias für CREATE ROLE.

Benutzer und Rollen

CREATE ROLE klinikpersonal;
GRANT klinikpersonal TO doktor_x, schwester_y;
CREATE ROLE mitarbeiter;
GRANT mitarbeiter TO big_boss, klinikpersonal;
CREATE ROLE finanzen;
GRANT finanzen TO big_boss;

GRANT: Berechtigung erteilen

GRANT <Recht> ON <Objekt> TO <Benutzer oder Rolle>

--Mitarbeiter dürfen sich mit der Datenbank verbinden
GRANT CONNECT ON klinik_db TO mitarbeiter;

--Die Finanzabteilung darf die Tabelle Reisekosten lesen
GRANT SELECT ON klinik.reisekosten TO finanzen;

--Doktor X darf alles auf der Patienten-Tabelle machen
GRANT ALL PRIVILEGES ON klinik.patienten TO doktor_x;

--Schwester Y darf Patienten einsehen, erstellen und ändern
GRANT SELECT, INSERT, UPDATE ON klinik.patienten TO schwester_y;

GRANT SELECT ON ALL TABLES IN SCHEMA klinik TO big_boss;

GRANT SELECT ON klinik.raeume TO PUBLIC; -- Das darf jeder

Mit dem GRANT-Befehl wird festgelegt, wer auf welchem Objekt was machen darf. Hinter dem Stichwort ON steht das Objekt. Für das CONNECT-Recht ist dies eine Datenbank. Bei den anderen hier angegeben Privilegien steht hinter dem Stichwort ON eine oder mehrere Tabellen, oder alle Tabellen eines Schemas. In der Rolle PUBLIC sind alle Benutzer.

REVOKE: Berechtigung entziehen

GRANT SELECT ON klinik.raeume TO PUBLIC;

CREATE VIEW klinik.raeume_view AS
SELECT * FROM klinik.raeume WHERE gebaeude IN (10,12,13,15);

REVOKE <Recht> ON <Objekt> FROM <Benutzer oder Rolle>

REVOKE SELECT ON klinik.raeume FROM PUBLIC;

GRANT SELECT ON klinik.raeume_view TO PUBLIC;

Alle Benutzer außer Peter sollen ein SELECT auf T machen dürfen.

GRANT SELECT ON T TO PUBLIC; REVOKE SELECT ON T FROM Peter;
Rolle R erstellen, in der alle außer Peter sind. GRANT SELECT ON T TO R;
Das geht nicht

https://frage.space

GRANT OPTION

Das Privileg, ein Privileg weiterzugeben.

GRANT SELECT ON ALL TABLES IN SCHEMA klinik TO big_boss
WITH GRANT OPTION;

REVOKE GRANT OPTION FOR SELECT ON ALL TABLES IN SCHEMA klinik 
FROM big_boss; -- nur GRANT OPTION entziehen, nicht das Recht

REVOKE ... RESTRICT | CASCADE

REVOKE SELECT ON ALL TABLES IN SCHEMA klinik FROM big_boss 
RESTRICT; -- nur, wenn es nicht weitergegeben wurde

REVOKE SELECT ON ALL TABLES IN SCHEMA klinik FROM big_boss
CASCADE; -- auch allen, denen es weitergegeben wurde

Transaktionen

111

ACID

Atomarität
Konsistenz
Isolation
Dauerhaftigkeit

Commit / Rollback

112-113

Mit einer commit-Operation beendet man eine Transkation.
rollback beendet ebenfalls die Transkation, sie führt jedoch zum Abort, sodass alle Änderungen rückgängig gemacht werden.

Autocommit

DB-Anwendungen setzen Autocommit-Einstellung. Bei SQL-Clients wie dem DBeaver ist Autocommit standardmäßig an.

Autocommit bedeutet, dass ein Commit automatisch wann ausgeführt wird?

nach jeder Transaktion
nach jeder SQL-Anfrage
beim Schließen der DB-Verbindung
alle Paar Sekunden

https://frage.space

Autocommit bedeutet, dass jede SQL-Anfrage automatisch committet wird. Stelle man um auf manuelles Commit, muss man selbst eine commit-Operation ausführen, damit Änderungen wirklich in der Datenbank gespeichert werden. Ist Autocommit aus, kann die laufende Transaktion mittels rollback auch komplett zurückgerollt werden.

Atomarität

Eine TA wird entweder ganz oder gar nicht ausgeführt.

INSERT INTO hersteller VALUES ('Dogdog', 'England');
INSERT INTO produkte VALUES (129, 'Hundefutter', 8.95, 'Dogdog');
COMMIT;

INSERT INTO hersteller VALUES ('Techbob', 'USA');
INSERT INTO produkte VALUES (129, 'Laptop', 999.99, 'Techbob');

SQL-Fehler [23505]: ERROR: duplicate key value violates unique constraint "produkte_pkey" Detail: Key (produktnummer)=(129) already exists.

⇒ Die TA kann komplett zurückgerollt werden, sodass der Hersteller Techbob auch nicht eingefügt wird.

Konsistenz

Eine TA führt die Datenbank von einem konsistenten Zustand in wieder einen konsistenten Zustand.

INSERT INTO produkte VALUES (129, 'Laptop', 999.99, 'Techbob');

SQL-Fehler [23505]: ERROR: duplicate key value violates unique constraint "produkte_pkey" Detail: Key (produktnummer)=(129) already exists.

Alle geltenden Integritätsbedingungen müssen zum Ende einer Transaktion erfüllt sein: Primärschlüssel-, Fremdschlüssel-, UNIQUE-, NOT NULL-, CHECK-Constraints, etc.

Isolation

Parallel laufendende Transaktionen beeinflussen sich nicht.

Mehrbenutzeranomalien

Dirty Read: TA₂ liest noch nicht committete Änderungen von TA₁
Lost Update: TA₁ und TA₂ schreiben gleichzeitig; wer gewinnt?
Non-repeatable Read: TA liest mal veraltete und mal aktualisierte Werte
...

Ziel: Gefühlter Einbenutzerbetrieb!

Dirty Read

TA₁

SELECT preis FROM produkte 
WHERE produktnr = 17; -- 0.89 EUR

UPDATE produkte
SET preis = 0 
WHERE produktnr = 17;



ROLLBACK;

TA₂







SELECT preis FROM produkte
WHERE produktnr = 17; -- 0 EUR
COMMIT;

Was ist hier Dirty?

TA1
TA2
Der Preis von Produkt 17
Rollback

https://frage.space

Lost Update

TA₁

SELECT preis FROM produkte 
WHERE produktnr = 17; -- 0.89 EUR

UPDATE produkte
SET preis = preis + 0.1
WHERE produktnr = 17; -- 0.99 EUR
  
COMMIT;

TA₂

SELECT preis FROM produkte
WHERE produktnr = 17; -- 0.89 EUR

UPDATE produkte
SET preis = preis + 0.1
WHERE produktnr = 17; -- 0.99 EUR

COMMIT;

Non-repeatable Read

TA₁

SELECT preis FROM produkte 
WHERE produktnr = 17; -- 0.89 EUR
    



SELECT preis FROM produkte 
WHERE produktnr = 17; -- 0.99 EUR
  
COMMIT;

Was macht TA2?

INSERT ...;
UPDATE ...;
INSERT ... ; COMMIT;
UPDATE ...; COMMIT;

https://frage.space

TA₂



UPDATE produkte
SET preis = preis + 0.1
WHERE produktnr = 17; -- 0.99 EUR
COMMIT;

Phantomproblem

TA₁

SELECT * FROM produkte 
WHERE hersteller = 'Monsterfood';
-- 2 Produkte werden angezeigt
    



SELECT COUNT(*) FROM produkte 
WHERE hersteller = 'Monsterfood';
-- Ergebnis: 3
  
COMMIT;

TA₂




INSERT INTO produkte
VALUES (..., 'Monsterfood');
COMMIT;

Serialisierbarkeit

Jede Transaktion besteht aus Lese- und Schreibaktionen: $r_1(x), r_1(y), w_1(x), c_1$

Serieller Ablauf

Keine verzahnte Ausführung, z. B. $r_1(x), r_1(y), w_1(x), c_1, r_2(z), r_2(x), c_2, r_3(y), c_3$

Serialisierbarkeit ("Final-State-serialisierbar")

Ablauf ist serialisierbar, wenn Anfragen das gleiche Ergebnis liefern und DB im gleichen Zustand hinterlassen wird, wie bei irgendeinem seriellen Ablauf.

Serialisierbarkeit ("Konflikt-serialisierbar")

Ablauf ist serialisierbar, wenn es keine Zyklen im Serialisierbarkeitsgraphen gibt.

Serialisierbarkeitsgraph

Konfliktoperationen

r → w
w → r
w → w

Von verschiedenen TAs auf gleichem Objekt.

Im Serialisierbarkeitsgraphen sind die TA die Knoten und es gibt eine Kante von einer TA zu einer anderen, wenn Konfliktoperationen zwischen diesen existieren.

Serialisierbarkeitsgraph

Beispiel: $r_1(x), w_1(y), r_2(x), w_1(x), w_3(y), w_3(x), c_1, c_2, c_3$

Konfliktoperationen hier:

$r_1(x) \rightarrow w_3(x)$
$w_1(y) \rightarrow w_3(y)$
$r_2(x) \rightarrow w_1(x)$
$r_2(x) \rightarrow w_3(x)$
$w_1(x) \rightarrow w_3(x)$

TA₁

TA₂

TA₃

Kein Zyklus im Serialisierbarkeitsgraphen ⇒ Der Ablauf ist serialisierbar

Äquivalenter serieller Ablauf: TA₂, TA₁, TA₃

Serialisierbarkeitsgraph

Anderes Beispiel: $r_1(x), w_1(x), r_2(x), w_1(x), w_3(y), w_3(x), c_1, c_2, c_3$

Konfliktoperationen hier:

Welches ist hier eine Konfliktoperation?

r1(x) → w1(x)
r2(x) → w1(x)
r1(x) → w3(y)
r1(x) → r2(x)

https://frage.space

$r_1(x) \rightarrow w_3(x)$
$w_1(x) \rightarrow r_2(x)$
$w_1(x) \rightarrow w_3(x)$
$r_2(x) \rightarrow w_1(x)$
$r_2(x) \rightarrow w_3(x)$
$w_1(x) \rightarrow w_3(x)$

Zyklus im Serialisierbarkeitsgraphen ⇒ Der Ablauf ist nicht serialisierbar

TA₁

TA₂

TA₃

SX-Sperrverfahren

Sperrverfahren werden eingesetzt, um Serialisierbarkeit zu erreichen. Bevor eine TA ein Objekt liest oder schreibt, muss es dies mit einer Sperre versehen.

Sperrmatrix

	S	X
S	✓	-
X	-	-

SX-Sperrverfahren

Beispiel: $r_1(x), r_2(x), c_1, c_2$

TA₁	TA₂	Gesetzte Sperren
$r_1(x)$		$S_1(x)$
	$r_2(x)$	$S_{1,2}(x)$
$c_1$		$S_2(x)$
	$c_2$

SX-Sperrverfahren

Beispiel: $r_1(x), w_1(x), r_2(x), w_1(x), w_3(y), w_3(x), c_1, c_2, c_3$

TA₁	TA₂	TA₃	Gesetzte Sperren
$r_1(x)$			$S_1(x)$
$w_1(x)$			$X_1(x)$
	warten		$X_1(x)$
$w_1(x)$	warten		$X_1(x)$
	warten	$w_3(y)$	$X_1(x), X_3(y)$
	warten	warten	$X_1(x), X_3(y)$
$c_1$	warten	warten	$X_3(y)$
	$r_2(x)$	warten	$S_2(x), X_3(y)$
	$c_2$	warten	$X_3(y)$
		$w_3(x)$	$X_3(x), X_3(y)$
		$c_3$

Was kommt als nächstes?

TA2 liest x
TA2 setzt S-Sperre auf x
TA2 muss warten, bis TA1 x fertig geschrieben hat
TA2 muss warten, bis TA1 committed hat

https://frage.space

Deadlocks

Beispiel: $r_1(x), r_2(y), w_2(x), w_1(y), c_1, c_2$

TA₁	TA₂	Gesetzte Sperren
$r_1(x)$		$S_1(x)$
	$r_2(y)$	$S_1(x), S_2(y)$
	warten	$S_1(x), S_2(y)$
warten	warten	$S_1(x), S_2(y)$

TA₂ wartet auf TA₁ und umgekehrt ⇒ Deadlock

Lösung: Eine der TAs muss vom TMS zurückgesetzt werden.

SQL-Isolationslevels

Read Committed
Read Uncommitted
Repeatable Read
Serializable

	Dirty Read	Non‑Repeatable Read	Phantomproblem
Read Uncommitted	möglich	möglich	möglich
Read Committed	nicht mögl.	möglich	möglich
Repeatable Read	nicht mögl.	nicht mögl.	möglich
Serializable	nicht mögl.	nicht mögl.	nicht mögl.

Lost Updates werden stets verhindert, sie sind in allen Iso'levels nicht möglich.

Was ist der Grund, warum man mal ein lockereres Isolationslevel als Serializable wählen könnte?

Sicherheit
Performanz
Bessere Erfüllung von ACID
Man will alte Werte lesen

https://frage.space

Multi-Version-Concurrency-Control

Ein Objekt (Tabelle, Zeile, Wert, ...) kann in mehreren Versionen existieren.
TA schreibt: $w_1(x)$ ⇒ neue Version $x'$ anlegen
TA liest: $r_2(x)$ ⇒ alte Version $x$ wird gelesen
TA committet: $c_1$ ⇒ neue Version wird gültig und sichtbar für andere TAs

Beispiel (nicht Konflikt-serialisierbar): $r_1(x), w_1(x), r_2(x), w_1(x), c_1, c_2$
↖ TA₂ liest alte Version

Das ist äquivalent zu folgendem und somit doch Konflikt-serialisierbar:
$r_1(x), r_2(x), w_1(x), w_1(x), c_1, c_2$

Recovery-Mechanismen

Transaktionen müssen auch bei TA-, System- und Hardwarefehlern ACID-konform ausgeführt werden (atomar, ..., dauerhaft).

Aus Performance-Gründen schreiben TAs erst einmal Änderungen nur im RAM; von Zeit zu Zeit werden die geänderten Blöcke dann auf die Festplatte ge-flush-t.

Alle Änderungen einer TA werden aber in ein Transaktions-Log eingetragen, welches immer spätestens bei einem Commit auf die Platte geschrieben wird.

LSN	TA	PageID	Undo	Redo	PrevLSN
27	TA₁	x	Undo-Info	Redo-Info	22

Transaktionsfehler

Beispiel: $r_1(x), r_2(y), r_1(z), w_1(x), w_2(y), w_1(z), a_1, c_2$

LSN	TA	PageID	Undo	Redo	PrevLSN
1	TA₁	BOT	-	-	-
2	TA₂	BOT	-	-	-
3	TA₁	x	Undo-Info	Redo-Info	1
4	TA₂	y	Undo-Info	Redo-Info	2
5	TA₁	z	Undo-Info	Redo-Info	3
6	TA₁	Abort	-	-	5
7	TA₂	Commit	-	-	4

Systemfehler

Beispiel: $r_1(x), r_2(y), r_1(z), w_1(x), w_2(y), w_1(z), c_1,$ ↯ Crash!

LSN	TA	PageID	Undo	Redo	PrevLSN
1	TA₁	BOT	-	-	-
2	TA₂	BOT	-	-	-
3	TA₁	x	Undo-Info	Redo-Info	1
4	TA₂	y	Undo-Info	Redo-Info	2
5	-	Flush	-	-	-
6	TA₁	z	Undo-Info	Redo-Info	3
7	TA₁	Commit	-	-	6

Was bedeutet der Flush?

Gepufferte Seiten werden auf die Platte geschrieben
Alle Transaktionen committen
Seiten werden von der Festplatte in den DB-Puffer geladen
Der DB-Puffer wird geleert

https://frage.space

Checkpoints

Regelmäßig legt die Datenbank Sicherungspunkte (Checkpoints) an.

Geänderte DB-Seiten im Puffer werden auf die Platte persistiert (Flush)
Vorteil: Recovery beginnt beim letzten Checkpoint

Varianten:

Transaktionskonsistente Checkpoints
Aktionskonsistente Checkpoints
Unscharfe (Fuzzy) Checkpoints

Transaktionskonsistente Checkpoints

Checkpoint wird angelegt, wenn keine Transaktion läuft.

Anmeldung, dass nun ein Checkpoint angelegt werden soll
Warten, bis alle laufenden TAs abgeschlossen sind
Neu startende TAs müssen warten
Wenn keine TA mehr läuft, gepufferte DB-Seiten persistieren

Aktionskonsistente Checkpoints

Beim Anlegen des Checkpoints werden aktuell laufende TAs pausiert.

Fuzzy Checkpoints

Kein Flush von geänderten Seiten
Checkpoint beinhaltet nur Infos über aktuell laufende TAs und den Puffer-Zustand (welche Seiten sind dirty?)
Recovery beginnt bei Min(DirtyLSN)
Flush von beliebigen Seiten kann asynchron zu beliebiger Zeit erfolgen

MinDirtyPageLSN

Kapitelzusammenfassung

Sichten: CREATE VIEW ... AS
WITH [LOCAL|CASCADED] CHECK OPTION
Materialisierte Sichten / REFRESH
Benutzer und Rollen
GRANT / REVOKE
ACID-Transaktionen
Mehrbenutzeranomalien (Dirty Read, Lost Update, ...)
Serialisierbarkeit / Serialisierbarkeitsgraph
SX-Sperrverfahren
Isolationslevels
MVCC
Recovery / Transaktions-Log
Checkpoint-Recovery

Prof. Dr.-Ing. Johannes Schildgen johannes.schildgen@oth-regensburg.de

Datenbanken

Kapitel 5: Mehrbenutzerbetrieb

2020-12-11

In diesem Kapitel...

Datenabstraktion

Externe Ebene (Sichten / Views)

Logische Ebene

Physische Ebene

Datenabstraktion (Bsp.)

Externe Ebene (View für Webshop-Anwendung)

Logische Ebene

Sichten / Views in SQL

Views / Sichten in SQL

SELECT * FROM produkte WHERE preis > 10 AND hersteller = 'Monsterfood'

https://frage.space

Einsatzszenarios von Views

Vereinfachung / Speicherung von Anfragen

Datenunabhängigkeit

Datenschutz

CHECK OPTION

WITH CHECK OPTION

INSERT INTO teure_produkte (produktnr, bezeichnung, preis) VALUES (123, 'X', 5)

https://frage.space

Materialisierte Sichten

REFRESH MATERIALIZED VIEW

Benutzer und Rollen

Benutzer und Rollen

GRANT: Berechtigung erteilen

REVOKE: Berechtigung entziehen

Alle Benutzer außer Peter sollen ein SELECT auf T machen dürfen.

https://frage.space

GRANT OPTION

REVOKE ... RESTRICT | CASCADE

Transaktionen

ACID

Commit / Rollback

Autocommit

Autocommit bedeutet, dass ein Commit automatisch wann ausgeführt wird?

https://frage.space

Atomarität

Konsistenz

Isolation

Mehrbenutzeranomalien

Dirty Read

Was ist hier Dirty?

https://frage.space

Lost Update

Non-repeatable Read

Was macht TA2?

https://frage.space

Phantomproblem

Serialisierbarkeit

Serieller Ablauf

Serialisierbarkeit ("Final-State-serialisierbar")

Serialisierbarkeit ("Konflikt-serialisierbar")

Serialisierbarkeitsgraph

Konfliktoperationen

Serialisierbarkeitsgraph

Serialisierbarkeitsgraph

Welches ist hier eine Konfliktoperation?

https://frage.space

SX-Sperrverfahren

Sperrmatrix

SX-Sperrverfahren

SX-Sperrverfahren

Was kommt als nächstes?

https://frage.space

Deadlocks

SQL-Isolationslevels

Was ist der Grund, warum man mal ein lockereres Isolationslevel als Serializable wählen könnte?

https://frage.space

Multi-Version-Concurrency-Control

Recovery-Mechanismen

Transaktionsfehler

Systemfehler

Was bedeutet der Flush?

https://frage.space

Checkpoints

Varianten:

Prof. Dr.-Ing. Johannes Schildgen
johannes.schildgen@oth-regensburg.de