Datenbanken II Literatur

Transkript

1 Datenbanken II Literatur C. J. Date: An Introduction to Database Systems; Addison-Wesley Systems Programming Series. 6th ed H. E. Erbs, S. Karczewski und I. Schestag: Datenbanken (Datenmodelle, Objekte, WWW, XML); VDE-Verlag Berlin 2003; 317 pp.; 24 EUR G. Vossen: Datenmodelle, Datenbanksprachen, Datenbankmanagementsysteme; Oldenburg-Verlag 2000; 780 pp. A. Heuer, G. Saake: Datenbanken: Konzepte und Sprachen; mitp Verlag 2000; 670 pp.; 35 EUR Karczewski Datenbanken II 1

2 1. Datenschutz- und sicherheitskonzepte Datenschutz: Ursprünglich: Schutz personenbezogener Daten vor Missbrauch Heute: Schutz des Einzelnen vor Verletzung seines Rechts auf informationelle Selbstbestimmung. Mit der Entwicklung der Computertechnik stetige Zunahme an Bedeutung, weil Datenerfassung, Datenhaltung und Datenanalyse immer einfacher werden. Im Bereich Datenbanken: Schutz der Daten vor unerlaubter Nutzung oder böswilliger Manipulation. Technische Massnahme für Schutz ist Zugriffskontrolle. Karczewski Datenbanken II 2

3 1. Datenschutz- und sicherheitskonzepte Datensicherheit: Eigenschaften von informationsverarbeitenden und -lagernden Systemen, die Verarbeitung, Speicherung und Kommunikation so zu gestalten, dass Vertraulichkeit, Verfügbarkeit und Integrität sichergestellt werden. Schutz des Systems vor unbeabsichtigter oder bösartiger Nutzung (Vertraulichkeit) oder Manipulation (Integrität) von Daten. Massnahmen: Zugriffskontrolle, View-Konzept, Überwachung und Protokollierung von Aktionen auf der Datenbank (Auditing). Karczewski Datenbanken II 3

4 In diesem Abschnitt werden Konzepte vorgestellt, die dazu dienen, jederzeit die Integrität des gesamten Datenbestandes zu gewährleisten, insbesondere bei gleichzeitigem Zugriff mehrerer Anwender auf die selben Daten. Fragen: Was ist Datenintegrität? Wo liegen Probleme bei gleichzeitigem Zugriff? Karczewski Datenbanken II 4

5 Transaktion: Die Transaktion ist eine Folge von Datenbankoperationen, die die Daten von einem konsistenten Zustand in einen neuen konsistenten Zustand überführt und entweder ganz oder gar nicht ausgeführt wird (logische atomare Einheit, Unit of Work (UOW)). Fragen: Warum eine Folge von Operationen? Beispiel aus Ihrem Arbeitsumfeld? Karczewski Datenbanken II 5

6 Beispiel einer Transaktion: Ein Kunde möchte eine Überweisung von seinem Konto auf ein anderes Konto vornehmen. Diese Transaktion besteht aus mehreren Bestandteilen: Reduzierung des eigenen Kontobestandes um den Überweisungsbetrag Erhöhung des anderen Kontobestandes um den Überweisungsbetrag Anpassung von internen Listen (Umsatzvolumina etc.) Erst wenn alle oben genannten Aktionen durchgeführt wurden, war die Transaktion erfolgreich. In jedem Zwischenzustand (z.b. Reduzierung wurde durchgeführt, Erhöhung jedoch nicht) müssen die bis dahin vorgenommenen Änderungen revidierbar sein, um die Forderung ganz oder gar nicht erfüllen zu können. Karczewski Datenbanken II 6

7 ACID-Eigenschaften für Transaktionen: Atomicity Consistency Isolation Durability Transaktionen haben atomaren Charakter (alles oder nichts). Transaktionen bewahren die Konsistenz der Datenbank. Die Datenbank wird von einem konsistenten Zustand in den nächsten überführt. Transaktionen werden untereinander getrennt, d.h. jede Transaktion läuft in einem simulierten Single-User-Betrieb. Datenbank-Updates bleiben nach einem COMMIT dauerhaft erhalten, auch wenn nach diesem COMMIT ein Systemausfall stattgefunden haben sollte. Karczewski Datenbanken II 7

8 Ein DB-System, das das Transaktionskonzept unterstützt, besitzt die Komponente Transaktions-Manager mit üblicherweise folgenden SQL-Befehlen: später BEGIN TRANSACTION COMMIT TRANSACTION ROLLBACK TRANSACTION: Transaktion wird abgebrochen. Alle dazugehörigen Datenbankänderungen werden rückgängig gemacht und auf den letzten konsistenten Zustand des Systems zurückgesetzt (Checkpoints/ Savepoints). Karczewski Datenbanken II 8

9 Beispiel Oracle: Eine Transaktion beginnt immer mit der ersten auszuführenden SQL-Anweisung (implizit). Eine Transaktion wird durch COMMIT erfolgreich beendet. Eine Transaktion kann durch ROLLBACK abgebrochen werden. Innerhalb langer Transaktionen kann man Savepoints setzen, die die Transaktion in kleine, atomare Einheiten unterteilt. Im Fehlerfall kann auf den letzten deklarierten Savepoint zurückgesetzt werden. Karczewski Datenbanken II 9

10 Recovery-Mechanismus: Ein Programm führt i.d.r. mehrere Transaktionen hintereinander aus. Im Fall des Systemausfalls identifiziert das DBMS beim Wiederanlauf (Recovery) nicht vollständig beendete Transaktionen und führt, falls notwendig, die zugehörigen Datenbanksicherungen durch. Der Database-Buffer-Manager verwaltet Puffer für die Daten und die Logs, in denen sämtliche Änderungen der Daten und ihr Status bezüglich aller Transaktionen protokolliert werden. Anhand der gespeicherten Logs kann im Fehlerfall das erforderliche Recovery-Processing durchgeführt werden, um die Daten wieder in ihrem letzten konsistenten Zustand verfügbar zu machen. flüchtige Karczewski Datenbanken II 10

11 Concurrency und Sperrkonzepte: Beim konkurrierenden Zugriff mehrerer Transaktionen auf dieselben Daten können folgende Konflikte auftreten: Lost Update Problem: Zwei Transaktionen ändern ein Tupel der Datenbank an unterschiedlichen Attributen, beide Transaktionen starten jedoch bevor eine der beiden Transaktionen beendet ist. Nur die letzte committete Transaktion wird berücksichtigt: Im Beispiel: Nur DekorID wird verändert, wenn T 2 mit COMMIT abgeschlossen wird. Karczewski Datenbanken II 11

12 Uncommitted Dependency Problem: Einer Transaktion T 2 wird lesender Zugriff auf Daten erlaubt, die von einer Transaktion T 1 verändert werden, aber noch nicht committet wurden. Transaktion T 2 ist somit von Transaktion T 1 abhängig, es erfolgt unter Umständen ein dirty read. Im Beispiel: Die durch T 1 vorgenommene Änderung wird nicht durch ein COMMIT festgeschrieben. Nach einem notwendigen Rollback von T 1 ist das Update des Preises nicht mehr gültig. T 2 liest somit einen dirty Wert. Ähnlich verhält es sich, wenn zwei Transaktionen schreiben, eine anschließend committet und die andere ein Rollback benötigt. Karczewski Datenbanken II 12

13 Inconsistent Analysis Problem: Eine Transaktion T 1 analysiert Daten auf einem Datenbestand, der gerade von einer Transaktion T 2 verändert wird. Obwohl möglicherweise bereits ein COMMIT erfolgt, könnte dabei ein dirty read erfolgen. Im Beispiel: T 1 summiert die Preise der Produktserie , T 2 ändert den Preis von Produkt auf 17.00, nachdem T 1 diesen schon in der Summe berücksichtigt hat. Karczewski Datenbanken II 13

14 Lösung der vorgenannten Probleme: Sperrmechanismen in Datenbanksystemen verhindern die Probleme. Sperren (Locks) dienen dazu, anderen Transaktionen so lange keinen lesenden und/oder schreibenden Zugriff auf die bearbeiteten Tupel einer Transaktion zu ermöglichen, bis diese Transaktion ein COMMIT gegeben hat. S-Locks (= shared-locks, read-locks): Besitzt eine Transaktion T 1 einen S-Lock auf dem Tupel t, so bewirkt dies, dass weitere S-Locks für eine Transaktion T 2 zugelassen werden, also anschließend beide Transaktionen einen S-Lock auf t besitzen. Außerdem werden alle angeforderten X-Locks zurückgewiesen, bis alle S-Locks auf dem Tupel t wieder freigegeben sind. Hierdurch wird gewährleistet, dass die Daten während des lesenden Zugriffs nicht verändert werden können. Karczewski Datenbanken II 14

15 X-Locks (= exclusive locks, write locks): Besitzt eine Transaktion T 1 einen X-Lock auf dem Tupel t, so bewirkt dies, dass alle angeforderten S-Locks anderer Transaktionen zurückgewiesen werden, ebenso wie alle angeforderten X-Locks anderer Transaktionen. S-Locks und X-Locks verhindern die vorgenannten Probleme. Jedoch können dabei Deadlocks entstehen. Deadlocks entstehen dann, wenn zwei Transaktionen Ressourcen gesperrt haben und wechselseitig auf die Ressource der anderen Transaktion warten. Keine der beteiligten Transaktionen kann beendet werden, ohne dass die andere abgebrochen wird. Karczewski Datenbanken II 15

16 Einfaches Beispiel für Deadlock: Drei Autos kommen gleichzeitig an eine Kreuzung, wo als Vorfahrtsregelung Rechts vor Links gilt. Alle wollen links abbiegen, müssen aber auf den jeweiligen Gegenverkehr warten. Wenn sich die Autofahrer nicht anders einigen, warten sie dort ewig. Es entsteht eine Verklemmung (Deadlock). Karczewski Datenbanken II 16

17 Beispiel für ein Deadlock mit zugehörigem Wait-for-Graph: Weiteres Beispiel: Speisende-Philosophen-Problem Karczewski Datenbanken II 17

18 Auflösung von Deadlocks: Ein von einem DBMS erkannter Deadlock wird dadurch aufgelöst, dass eine der beteiligten Transaktionen abgebrochen wird. Für diese Transaktion erfolgt ein ROLLBACK. Ob ein Abbruch zu erfolgen hat wird dadurch erkannt, dass die Wartezeiten zu lange werden (time out). Alternativ kann eine Analyse des Wait-for-Graphen auf Schleifen frühzeitig die Deadlock-Situation aufdecken und das DBMS dann einen Abbruch durchführen. Allgemeines Problem: Zeitaufwand durch das Warten (wait-status), daher ist eine Auflockerung des locking erwünscht. Karczewski Datenbanken II 18

19 Differenzierte Sperren durch Isolation Level: Repeatable read / serializable write: Maximaler Isolation Level. S- und X-Locks werden erworben und bis zum Ende der Transaktion gehalten. Cursor stability: S-Locks werden erworben, bei Lesen eines Datensatzes ohne Update, wird der S-Lock beim Lesen des nächsten Satzes wieder aufgehoben. X-Locks werden bis zum Ende der Transaktion gehalten. Uncommitted read (dirty read): Es werden keine S-Locks gehalten. Die Gefahr, inkonsistente Daten zu lesen, wird eingegangen. X-Locks werden bis zum Ende der Transaktion gehalten. Karczewski Datenbanken II 19

20 Rechteverwaltung: Im relationalen Standard SQL unterstützt die Rechteverwaltung das rollenbasierte Berechtigungskonzept, d.h. Zugriffsrechte können abstrakten Rollen zugewiesen werden. Einzelne Anwender werden diesen Rollen zugeordnet. Alternativ: Einzelne User erhalten direkt Zugriffsrechte. 3 wesentliche Aspekte bei der Rechteverwaltung sind: Wer wird autorisiert (Subjekt)? Für welche Daten wird das Subjekt autorisiert? Für welche Operationen darf der Zugriff auf die Daten erfolgen? Karczewski Datenbanken II 20

21 Vergabe von Rechten: Jeder Erzeuger eines DB-Objekts (z.b. einer Tabelle) erhält automatisch alle Rechte, die für dieses Objekt sinnvoll sind. Er kann diese Rechte (oder einen Teil davon) an andere User(gruppen) weitergeben. Rechte, die auf Tabellen zu vergeben sind: SELECT INSERT UPDATE DELETE REFERENCES (wird bei objektrelationalen Datenbanken relevant) Karczewski Datenbanken II 21

22 Syntax der Rechtevergabe: <Recht>: ALL oder ALL PRIVILEGES bedeutet alle Rechte SELECT bedeutet Leserecht INSERT [(column, )] bedeutet Einfügerecht UPDATE [(column, )] bedeutet Änderungsrecht DELETE bedeutet Löschrecht Karczewski Datenbanken II 22

23 Syntax der Rechtevergabe (Fortsetzung): <Objekt>: Objekt ist i.d.r. eine Tabelle, kann aber auch ein View sein. <User>: Ein User wird identifiziert über seine Benutzerkennung. Das Schlüsselwort PUBLIC kann verwendet werden und meint, dass alle Benutzer für das System Zugriffsrecht haben. [WITH GRANT OPTION]: Diese Option erlaubt den berechtigten Usern die Rechte, die sie erhalten haben, ebenfalls zu erteilen. Karczewski Datenbanken II 23

24 Beispiel: Die CREATE VIEW- Anweisung erzeugt eine Sicht auf genau die Aufträge, in denen der aktuelle Benutzer der Kunde ist. Jeder Benutzer darf seine Aufträge sehen (SELECT) und neue Aufträge einfügen (INSERT), aber nichts löschen oder ändern. Karczewski Datenbanken II 24

25 Rücknahme von Rechten: Erläuterung: Karczewski Datenbanken II 25

26 Rollen und Rechte: Definition der Rolle: Zuordnung eines Users zu einer Rolle: Karczewski Datenbanken II 26

27 Hörsaalübung VIEW-Behandlung Pers: NR NAME ALT Schmidt 30 2 Maier 60 3 Schwarz 90 4 Schulz 50 5 Adam 25 6 Schwarz 65 Vatervon: VATER SOHN CREATE VIEW vv AS SELECT Name, Alt FROM pers WHERE nr IN (SELECT Vater FROM vatervon); SELECT * FROM vv WHERE Alt < 55; Was liefert das SELECT-Statement in Verbindung mit dem VIEW? Was ist inhaltlich gemeint? Karczewski Datenbanken II 27

28 Hörsaalübung VIEW-Behandlung CREATE VIEW vv AS SELECT Name, Alt FROM pers WHERE nr IN (SELECT Vater FROM vatervon); SELECT * FROM vv WHERE Alt < 55; Was liefert das SELECT-Statement in Verbindung mit dem VIEW? NAME ALT Schulz 50 Was ist inhaltlich gemeint? Ausgabe aller Väter, deren Alter kleiner als 55 Jahre ist. Karczewski Datenbanken II 28