1 Warum Datenbanken

1
Warum Datenbanken
Früher alles in Dateien -> Problem große Wechselwirkung zwischen Programmen (Code)
und Daten. Änderungen der Datenstruktur verursachten Änderungen des Codes und
umgekehrt.
Datenbanksystem steht zwischen Programm und Daten. Programm kann nur über
Datenbanksystem auf Daten lesend und schreibend zugreifen. Datenbanksystem besteht
aus DB und DBMS.
2
Datenmodelle
Datenmodellierung: Entwurf eines Datenbankschemas zur Verwaltung der Daten.
Datenmodell: Damit werden alle in der DB abgebildeten Sachverhalte beschrieben.
Konzeptionelle Datenmodelle
Stellen problemnahe Modellierungskonzepte für die ersten Schritte des
Datenbankentwurfs zur Verfügung und dienen zur Kommunikation zwischen
Datenbankentwicklern und Endbenutzern.
Physische Modelle
Stellen maschinennahe Konzepte zur Verfügung und dienen zur Beschreibung der
Organisation von Daten in Dateien, sowie zur Beschreibung von Zugriffsstrukturen, die ein
rasches Einfügen, Suchen, Löschen und Ändern von Daten ermöglichen.
Logische Datenmodelle
Dienen der Überbrückung der Kluft zwischen den konzeptionellen und physischen
Modellen, sie werden auch Implementierungsmodelle genannt.
Schema: Eine konkrete Beschreibung der Daten eines Unternehmen mit den Mitteln eines
bestimmten Datenmodells
2.1
Hierarchisches Modell
Daten gemäß Zugriffspfad angeordnet.
Vorteil: Sehr speichereffizient und schnell
Nachteil: Für neue Abfrage (mit neuem Zugriffspfad) muss Struktur geändert werden ->
unflexibel
2.2
Netzwerk Modell
Datenelemente durch Pointer miteinander verbunden.
Kopfelement verweist auf Detailelement usw. das letzte Detailelement verweist wieder auf
Kopfelement (verkettete Liste).
2.3
Entity Relationship Modell
Welt besteht aus Objekten und Beziehungen zwischen den Objekten.
Objekte, Beziehungen, Attribute, Werte.
2.4
Relationales Modell
●
Ergebnisse der mathematischen Theorie der Relationen in die
Datenbankproblematik übertragen.
●
Tabellarisches Konzept, in dem die Daten und Beziehungen verwaltet werden
Eine Entität ist ein abgegrenzter Begriff der Realwelt, der modelliert werden soll. Es wird
auf „schärfere“ Begriffe wie „Objekt“ oder „Objektart“ bewusst verzichtet, da auch abstrakte
Begriffe modelliert werden müssen
Ein Attribut ist eine einer Entität direkt zuordenbare Eigenschaft (Feld, Spalte).
Tupel: Datensatz
Domäne: Datentyp
Entität moduliert durch Relation: Tabelle
2.5
Objektrelationale Datenbanken
Objektrelationale Datenbanken vereinigen Eigenschaften von Relationalen Datenbanken
mit Elementen der Objektorientierten Programmierung.
Vererbung: Tabellen können aus anderen Tabellen abgeleitet werden und erben deren
Attribute.
Kapselung: „Gespeicherte Prozeduren“ sind untrennbar mit Datensätzen verbunden.
2.6
Objektorientierte Datenbanken
Erweiterung objektorientierter Programmiersprachen
2.7
ISO Modell (3 Schichten)
2.7.1 Externe Schicht
Struktur, die der Applikationsprogrammierer "sieht"; (Objekt~)Relationales Modell:
Sichten, Gespeicherte Prozeduren(aber schlampiger weise auch: Tabellen &
Beziehungen)
2.7.2 Konzeptionelle Schicht
Struktur, die der Datenbankprogrammierer sieht bzw. entwirft: (Objekt~)Relationales
Modell: Tabellen & Beziehungen. Beschreibt die logische Struktur der Daten einer
Datenbank im konzeptionellen Schema. In diesem Schema werden die Daten und ihre
Beziehungen zueinander mit den Mitteln der Datenmodellierung beschrieben. Weiters
enthält das konzeptionelle Schema Integritätsbedingungen, Sicherheitsregeln und die
Definition von Triggern.
2.7.3 Interne Schicht
Dateiformat, für das sich DB-Systemprogrammierer entschieden haben: ISAM, VSAM,
XML,...) Ist der physischen Speicherung am nächsten, entspricht ihr aber nicht ganz.
Beschrieben wird die interne Ebene durch das interne Schema der Daten. Es enthält nicht
nur Art und Aufbau der gespeicherten Datenstrukturen, sondern auch Informationen über
Indizes.
Diese Ebene stellt somit als Schnittstelle zur eigentlichen Datenbank die Abbildung von
logischem in physikalischen Adressraum unter Zuhilfenahme von
Betriebssystemfunktionen zur Verfügung.
3
Schlüssel
●
Schlüsselkandidat: Als Schlüsselkandidaten werden alle Attribute bezeichnet, die
die Eigenschaft der eindeutigen Tupelidentifizierung besitzen.
●
Primärschlüssel: Ein beliebiger schlüsselkandidat (+ not null)
Sekundärschlüssel: Habe zusammengesetzten Primärschlüssel, wenn Teil davon
Fremdschlüssel - ist dieser sek. Schlüssel
Fremdschlüssel: Ist eigentlich kein Schlüssel (in anderer Tabelle Schlüsselkandidat)
●
●
4
Beziehungen
Eine Beziehung zwischen zwei Tabellen A und B bedeutet, dass zu einem Datensatz einer
Tabelle A bestimmte Datensätze der Tabelle B gehören. In der Tabelle B wird dazu in
einem Datensatz ein Verweis auf einen Datensatz in der Tabelle A gespeichert
(Fremdschlüssel). Tabelle A nennen wir in diesem Zusammenhang die Kopf- oder
Mastertabelle, Tabelle B ist in diesem Sinn eine Detailtabelle.
Beziehungen werden implementiert, indem man in der Detailtabelle die Spalte(n) eines
Schlüsselkandidaten einer anderen Tabelle aufnimmt (Fremdschlüssel).
4.1
Arten von Beziehungen
Definition 1:n Beziehung: Jedem Datensatz in einer Kopftabelle (1-Tabelle) entsprechen
0 oder mehr Datensätze in der Detailtabelle (N-Tabelle).
1:n-Beziehungen werden dargestellt, indem in der n-Tabelle ein Schlüssel der Kopftabelle
mit allen Feldern als sog. Fremdschlüssel aufgenommen wird.
Definition 1:1 Beziehung: Jedem Datensatz in einer Kopftabelle entsprechen 0 oder ein
Datensätze in der Detailtabelle.
Definition: m:n Beziehung Jedem Datensatz in einer Tabelle A entsprechen 0 oder mehr
Datensätze in einer Tabelle B und umgekehrt (d.h. jedem Datensatz in der Tabelle B
entsprechen 0 oder mehr Datensätze in der Tabelle A)
In einer Relationalen Datenbank erfordert die Darstellung einer m:n Beziehung eine
Hilfstabelle, die eine Verbindung zwischen den beiden Tabellen herstellt. Die m:n
Beziehung wird somit in 2 Beziehungen 1:m und 1:n aufgelöst. Die “neue” Tabelle
bekommt automatisch die Schlüssel aus den beiden anderen Tabelle als Fremdschlüssel
„vererbt“. Diese Fremdschlüssel können selbst Schlüssel für die neue Tabelle sein. Es ist
aber auch möglich, dass die Kombination der Fremdschlüssel selbst zu schwach ist, um
den Schlüssel zu bilden.
Wichtig: Auch 1:1 hat Richtung (Kopf und Detailtabelle)
5
Subkategorien
Die Kardinalität bestimmt, wie viele Datensätze in einer Detailtabelle zu jedem
Kopfdatensatz vorhanden sein müssen, damit einerseits die definierte Integrität der
Datenbank gewährt ist, andererseits die Übereinstimmung des Modells mit der Realwelt.
Manchmal 1:n zu schwach, brauch genau 1:4 z.b.
Auch 1:1 kann zu schwach sein, brauch genau 1:1 und nicht auch 1:0.
Muss selbst ausprogrammiert werden.
Subkategorien: Eine Kopftabelle steht zu mehreren Detailtabellen in 1:1 Beziehung.
Allerdings gibt es zu jedem Kopfdatensatz in höchstens 1 Detailtabelle einen
Detaildatensatz.
Dabei unterscheiden wir:
Vollständige Subkategorie: Kopftabelle hat in genau 1 Detailtabelle einen
Detaildatensatz.
Unvollständige Subkategorie: Kopftabelle hat in höchstens 1 Detailtabelle einen
Detaildatensatz.
Beispiel: KFZ Tabelle, Detailtabellen: LKW, Baumaschine -> Kann nur in einer einen
Eintrag haben.
Unvollständig wär z.b. wenn kein Eintrag bedeutet PKW.
6
Referenzielle Integrität
Regelsystem in der Datenbank, welches die Gültigkeit von Beziehungen garantiert und
Datensatzanomalien verhindert. Sie gewährleistet, dass...
●
...in ein Fremdschlüsselfeld einer Detailtabelle kein Wert eingegeben werden kann, der nicht
im zugehörigen Schlüsselkandidaten der Mastertabelle vorkommt (weder durch Einfügen
noch durch Ändern eines Datensatzes).
●
...aus einer Kopftabelle kein Wert des entsprechenden Schlüsselkandidaten „verschwinden“
kann (weder durch Löschen noch durch Ändern), wenn übereinstimmende Tupel in einer
Detailtabelle vorhanden sind .
Liegt also vor wenn alle Detailtabellen gültigen FK haben oder Null.
2. Punkt kann gelöst werden mit Kaskaden (Weitergaben) durch:
●
Löschweitergabe: Wird ein Tupel aus einer Kopftabelle gelöscht, werden alle
übereinstimmende Tupel der Detailtabelle gelöscht.
●
Aktualisierungsweitergabe: Wird der Schlüsselwert einer Kopftabelle geändert, werden
alle übereinstimmende Werte der Detailtabellen mit dem geänderten Wert aktualisiert.
Gibt es keine deklarative referenzielle Integrität, kann das alles mit Triggern durchgesetzt werden.
7
Matchregeln
Bei der Verknüpfung zweier Tabellen kann das DBMS grundsätzlich folgendermaßen
vorgehen, sofern der Fremdschlüssel zusammengesetzt ist.
Match Simple
Enthält eine der Fremdschlüsselspalten NULL, wird die RI gar nicht überprüft: die Zeile
wird aufgenommen
Match Partial
Alle Non-NULL-Inhalte in Fremdschlüsselspalten haben eine Entsprechung bei einem
Schlüsselkandidaten in der referenzierten Tabelle (etwas problematisch)
Match Full
Alle Fremdschlüsselspalten haben eine Entsprechung bei einem Schlüsselkandidaten in
der referenzierten Tabelle oder sind NULL.
Match-Regeln steuern also, ob und wie das Datenbanksystem Manipulationen an
Detaildatensätzen als Bruch der RI interporetiert oder nicht.
8
Integritätsarten
●
Domänenintegrität
●
Entitätenintegrität
●
Prozuderale Integrität
●
Referenzielle Integrität
9
Anomalien
Unnormalisierte Relationen führen zu Problemen:
●
Redundanz
●
Update-Anomalien
Redundanz steht in direktem Zusammenhang mit den Update-Anomalien:
Änderungsaufwand
Änderung eines Eintrages muss an mehreren Datensätzen durchgeführt werden
Inkonsistente Attributwerte
verschiedene Werte sind für den 'selben' Eintrag möglich
Löschen mit Informationsverlust
Das Löschen einer Bestellung kann dann zu einem (unerwünschten) Informationsverlust
führen, wenn danach das bestellte Teil nicht mehr in einem Tupel der Relation existiert. Es
gibt dann zu diesem Teil keine Teilebeschreibung mehr.
Unvollständiges Einfügen
Wenn der Primärschlüssel eine Attributkombination ist, müssen für jedes einzufügende
Tupel alle Attribute des Schlüssels "reale" Werte (keine Nullwerte!) sein. In der geänderten
Relation kann man keine Datensätze einfügen, zu der nicht mindestens eine Bestellung
vorliegt. (Wie kann man Teile bestellen, die nicht in der Relation existieren?)
10
Normalformen
Zweck:
●
Verhinderung von “Anomalien”
●
Gewährleistung jeder Erweiterbarkeit
●
Performance verbessern
●
Eliminierung von sog. Funktionalen Abhängigkeiten bedeutet auch die Eliminierung
von Redundanzen.
10.1 1. Normalform
Eine Relation befindet sich in der 1. Normalform, wenn alle Felder atomare (nicht sinnvoll weiter
aufteilbare) Werte enthalten und keine Wiederholungsgruppen (z.b. Telefonnummer öfters)
vorkommen.
10.2 2. Normalform
Eine Relation ist in der 2. Normalform, wenn sie in der 1NF ist und jedes Nicht-Schlüssel-Attribut
vom Gesamtschlüssel voll funktional abhängig ist (also nicht von Teilen des Schlüssels).
Die Zweite Normalform kann also nur verletzt werden, wenn der Schlüssel aus mehreren Feldern
besteht!
funktional abhängig: ein Attribut (Feld) B ist von einem anderen Attribut A funktional abhängig,
wenn zu jedem Wert von A genau ein Wert von B gehört.
(funktional abhängig wie bei einer Funktion i.d. Mathematik)
Beispiel: Attribut PLZ & Attribut Ort
Der Ort ist von der Postleitzahl funktional abhängig - man kann den Ort der PLZ 1090 angeben:
Wien
Die Postleitzahl ist vom Ort nicht funktional abhängig - Wien hat viele Postleitzahlen, man kann
nicht "die Postleitzahl" von Wien angeben
10.3 3. Normalform
Eine Relation ist in der 3. Normalform, wenn sie in der 2NF ist und keine Nicht-SchlüsselAttribute voneinander funktional abhängig sind.
10.4 Boyce Codd Normalform
Eine Relation befindet sich in Boyce Codd Normalform (BCNF), wenn sie in der 3NF ist und jede
Determinante Schlüsselkandidat ist. Verhindert das beim Einfügen eines künstlichen Schlüssels die
NF verletzt wäre.
11
Transaktion
Eine Transaktion ist eine Folge von (Datenbank)operationen, die als eine logische Einheit
ausgeführt werden. Transaktionen fassen mehrere Operationen zu einer Arbeitseinheit zusammen
Sie werden "ganz oder gar nicht" ausgeführt und werden vom Programmierer festgelegt.
Paradebeispiel: Geldtransaktion
11.1 Eigenschaften
Atomic (Unteilbar)
Eine Transaktion wird ganz oder gar nicht ausgeführt, sie ist "unteilbar"
Consistent (Konsistent)
Wenn Daten am Anfang der Transaktion konsistent (widerspruchsfrei) sind, muss das DBMS
sicherstellen, dass sie es auch am Ende sind.
Isolated (Isolierbar)
Parallel laufende Transaktionen dürfen nicht auf dieselben Ressourcen greifen können.
Anm.: Das entspräche der ISO-Isolationsstufe "Serialisable", aus Performance-Gründen muss man
tw. andere Isolationsstufen zulassen (siehe Isolationsstufen).
Durable (Dauerhaft)
Wenn ein DBMS ein Commit fehlerfrei ausgeführt hat, muss sich der Programmierer darauf
verlassen können, dass die Daten verfügbar sind, egal, was mit dem System passiert (Crash, Blue
Screen, Kernel Panic, Stromausfall,...).
11.2 Codierung
●
begin transaction
●
commit
11.3 Rollback
Das Herstellen des Zustandes vor Beginn der Transaktion wird als „Rollback“ („Zurückrollen“)
bezeichnet. Kann man auch manuell veranlassen (rollback).
11.4 Implementierung
Das Transaktionsprotokoll ist eine fortlaufende Aufzeichnung aller Befehle, die zu Änderungen an
den Datenbeständen führen:
●
mit welcher Transaktion wurde die jeweilige Änderung durchgeführt
●
Beginn und Ende der Transaktion
●
Änderungen an den Daten selbst
Mit Hilfe des Transaktionsprotokolls kann das DBMS Transaktionen wiederherstellen, fertig stellen
oder zurück rollen.
Das Transaktionsprotokoll ist ein sog. „Write-Ahead-Log“, d.h. der Eintrag der Information über
eine Änderung wird noch vor der Durchführung der Änderung selbst vorgenommen. Beim
Abarbeiten nachher werden sie im Log „abgehakt“.
Wenn ein Fehler passiert (Stromausfall, Absturz der DB-Software, Absturz des OS o.ä.) wird das
DBMS irgendwann wieder gestartet und analysiert als 1. das Transaktionsprotokoll.
3 Möglichkeiten:
●
Eine Transaktion ist von Begin Tran bis Commit Tran im Protokoll eingetragen und alle
Befehle sind abgehakt: gar nichts ist zu tun ("inaktiver Teil" des Logs)
●
Es befinden sich ein Begin Tran, einige abgehakte Befehle und einige nicht abgehakte
Befehle, aber kein Commit tran im Log: der Fehler trat also auf, während die Transaktion
noch ins Log eingetragen wurde: das DBMS rollt die Transaktion zurück ("Rollback")
●
Es befinden sich ein Begin Tran, einige abgehakte Befehle, einige nicht abgehakte Befehle
und ein nicht abgehaktes Commit Tran im Log: der Fehler trat auf, nachdem die Transaktion
eingetragen wurde aber noch während der Abarbeitung vor Fertigstellung: Die Transaktion
wird fertiggestellt ("vorgerollt", "Roll Forward")
11.5 Verschachtelte Transaktionen
Commit: Wirkt nur auf innerste.
Rollback: Wirkt bis zur äußersten.
11.6 Explizit – Implizit
12
●
Im expliziten Transaktionsmodus ist jedes Statement, das ohne besondere Maßnahmen
(BEGIN TRAN & COMMIT) durchgeführt wird, seine eigene Transaktion.
●
Im Gegensatz dazu kann das DBMS nach jedem COMMIT sofort eine neue Transaktion
beginnen: „impliziter Transaktionsmodus“
Parallelität
Wenn mehrere Transaktionen parallel laufen, die auf die selben Ressourcen
(Tabellen[teile]) zugreifen, kann es im Fehlerfall Probleme geben.
Die Concurreny Control - Einheit eines DBMS ermöglicht mehreren Benutzern, eine DB
gemeinsam zur selben Zeit zu benutzen, ohne ihre Konsistenz zu gefährden. Das
traditionell verwendete Korrektheitskriterium ist dabei die „Serialisierbarkeit“ (besagt, dass
das Ergebnis von parallel ausgeführten Transaktionen dem Ergebnis der hintereinander
ausgeführten Transaktionen entspricht. Um die Serialisierbarkeit von Transaktionen zu
gewährleisten, verwenden DBMSe ein Sperrverfahren.
Benützt man aber „niedrigere“ Isolationsstufen, können bestimmte Parallelitätsfehler
auftreten:
Dirty Read: Wird im vorigen Beispiel die Transaktion A zurückgerollt, nachdem
Transaktion B bereits den Kontostand von Konto A ausgelesen hat, kommt es zu
inkonsistenten Daten.
Anm.: Beim "Zurückrollen" werden nicht die Befehle "verkehrt herum" abgearbeitet,
sondern es wird einfach der Zustand wiederhergestellt, der vor Beginn der
Befehlsausführung bestanden hatte.
Non Repeatable Read: Eine Transaktion liest Daten 2x, wobei die Daten zwischen dem
1. und 2. Mal von einer anderen Transaktion verändert (und committed) wurden -> Die
Transaktion liest 2x unterschiedliche Daten, obwohl derselbe Datensatz gelesen wird.
Phantom Read: Eine Transaktion wiederholt eine Suchabfrage, wobei beim 2. Mal eine
andere Anzahl an Datensätzen zurückgegeben wird als beim ersten Mal.
Datensätze können bei der 2. Abfrage "aufgetaucht" und/oder verschwunden" sein (sog.
"Phantom Records") weil eine parallel laufende Einfüge- oder Löschabfrage die
Ergebnismenge zwischendurch verändert hat.
Achten Sie bei der Auswahl eines Datenbanksystems, dass es außer "Serializable"
wenigstens "Read Committed" oder "Repeatable Read" unterstützt.
Befehl:
SET TRANSACTION ISOLATION LEVEL <LEVEL>
Im allgemeinen liefert "Read Committed" einen guten Kompromiss zwischen
Parallelisierbarkeit (Perfomance) und Stabilität. In Einzelfällen braucht der Programmierer
eine höhere Isolationsstufe.
13
Sperren
Die unterschiedlichen Isolationsstufen werden implementiert durch unterschiedliches
Sperrverhalten ("Locking") der DB.
14
●
Read uncommitted: Sperren werden – soweit möglich – gar nicht beachtet
●
Read committed: Es wird mit dem Lesen gewartet, bis die andere Transaktion
committed hat, d.h. deren Sperren wieder aufgehoben sind.
●
Repeatable Read: Es wird mit dem Lesen gewartet, bis die andere Transaktion
committed hat, dann wird selbst gesperrt (auch nur zum Lesen!), bis die eigene
Transaktion fertig ist, d.h. auch gelesene Ressourcen werden gesperrt.
●
Serializable: Keinerlei gleichzeitige Zugriffe zweier Transaktionen auf dieselben
Resourcen (Datenseiten, Datensätze o.ä.) werden zugelassen: Gelesene
Ressourcen werden genauso wie geänderte gesperrt, dabei werden Einfügungen in
die betroffenen Tabellen ebenfalls verhindert.
Locking
Durch Sperren können sogenannte "Deadlocksituationen auftreten.
Beispiel: Dining Philosophers
5 Philosophen (Informatiker) sitzen vor einem runden Tisch mit 5 Tellern Spagetti.
Zwischen den Tellern jeweils 1 Gabel. Jeder Informatiker bekommt folgende
Arbeitsvorschrift ("Algorithmus") für den Fall, dass er hungrig wird:
Warte bis die Gabel zu Deiner Rechten frei wird
Nimm die Gabel zu Deiner Rechten
Warte, bis die Gabel zu Deiner Linken frei wird
Nimm die Gabel zu Deiner Linken
Iss, bis Du satt bist
Lege beide Gabeln zurück
Das funktioniert solange, bis einmal alle Gabeln auf dem Tisch liegen und alle Informatiker
gleichzeitig hungrig werden: Jeder nimmt die Gabel zu seiner Rechten und wartet...
Einzige Lösung, damit nicht alle Informatiker verhungern: einen Informatiker erschießen
Gute DBMS können Deadlock-Situationen erkennen, und brechen tatsächlich einen
beteiligten Prozess unter Erzeugung einer Fehlermeldung ab ("Deadlock-Victim")
15
Praxis
Normalisieren (Üben), Modellieren (Üben), Abfragen (SQL – Teil3)