Alle Vl db Flashcards
(128 cards)
1
Q
Externe Ebene (ANSI-SPARK)
A
benutzerdefinierte Sichten
2
Q
ANSI-SPARK Architektur
A
Externe Ebene, Logische Ebene, Physische Ebene
3
Q
Logische Ebene (ANSI-SPARK)
A
definiert logische Datenbankenstruktur und deren Beziehungen unabhängig von physischer Repräsentation
4
Q
Physische Ebene (ANSI-SPARK)
A
Festlegung physischer Schemata (Art und Weise der Datenspeicherung)
5
Q
Zweck der Schichtenarchitektur
A
Datenunabhängigkeit(logische und physische Abhängigkeit) -> Änderung auf einer Schicht ohne Einfluss auf andere Schichten
Robust gegenüber Änderungen
6
Q
Schlüsselattribute
A
kann Entity eindeutig identifizieren
7
Q
disjoint-constraint
A
disjunkt: Untertypen sind verschieden
overlapping: Untertypen schneiden sich
8
Q
completness-constraint
A
total: jede Entitiy des Obertyps auch Entity eines Untertyps
partiell
9
Q
Datenbankschema
A
Menge der Relationsschemata
10
Q
Datenbank
A
Menge der aktuellen Relationen
11
Q
Kanidatenschlüssel
A
Auswahl für Primärschlüssel
12
Q
Primärschlüssel
A
-minimal
-eindeutige Identifizierung
-zeitlich stabil
13
Q
Fremdschlüssel
A
Attribut (bzw. Kombination) welches auf den Primärschlüssel verweist
minimal
14
Q
Horizontale Partitionierung
A
jede Entity in seperaten Relation mit allen Attributen
15
Q
Vertikale Partitionierung
A
jede Entity in eigener Relation mit Verknüpfung zu der Beziehungsrelation
16
Q
Universalrelation
A
eine Relation
17
Q
Relationale Algebra
A
interne Repräsentation von DB-Anfragen
ausschließlich lesende Operationen
18
Q
Projektion 𝜋
A
Auswahl von Spalten
19
Q
Selektion σ
A
Auswahl von Tupel unter einer Bedingung
20
Q
Kartesisches Produkt
A
Kombination aller Tupel
keine Duplikate
21
Q
Differenz R-S
A
alle Tupel die in R sind und nicht in S
keine Duplikate
22
Q
Vereinigung
A
alle Tupel
bei gleichem Relationsschema
keine Duplikate
23
Q
Durchschnitt
A
alle Tupel die sowohl in R als auch in S sind
keine Duplikate
24
Q
Division
A
alle Tupel von R die alle Tupel aus S als Partner haben
keine Duplikate
24
Natural Join
verbinden von Tupel über gleiche Attribute
25
Theta Join
Natrual Join über andere Vergleichsoperatoren als =
26
Equi Join
Verbinden über Gleichheit von Attributen
27
Left outer Join
Verbund über gleiche Attribute, Ausgabe von R mit verbundspartner in S und Attribute aus R die in S keinen Join Partner haben -> NULL
28
Right Outer Join
Verbund über gleiche Attribute und Ausgabe von allen Attributen von S, die keinen Join Partner in R haben -> NULL
29
Full Outer Join
Left Outer Join + Right Outer Join
30
Semi Join
enthält nur die Tupel von R, die die Join Bedingung mit S erfüllen
31
Referentielle Integrität
-eindeutige Identifikation der Tupel durch Schlüsselattribute
-Datensätze dürfen über Fremdschlüssel nur auf exestierende Daten verweisen
32
Vorteil von datenbanksichten
- erhöht Sicherheit
-steuern Berechtigungen
-vereinfachen SQL-Anfragen
- Unabhängigkeit zwischen Tabellen und Sichten
33
Trigger-Konzepte
Event
Condition
Action
34
Insert Anomalie
-fehlen von Primärschlüsselattributen
-Ursache: Vermischung von Entitätstypen
35
Update Anomalie
-nicht alle Vorkommen eines Attributwert werden geändert
-Ursache: Redundanz
36
Delete Anomalie
-durch löschen eines Datensatzes gehen mehr Informationen als gewünscht verloren
-Ursachen: vermischen von Entitätstypen
37
Funktionale Abhängigkeit
ein Attributwert oder Kombination von Attributwerten bestimmt den Wert eines anderen Attributs bzw. einer anderen Attributmenge
38
Volle funktionale Abhängigkeit
Abhängigkeit ist minimal -> es existiert keine Teilmenge
39
partielle funktionale Abhängigkeit
Abhängigkeit ist NICHT minimal -> es existiert eine Teilmenge
40
Hülle F+
Menge aller funktionalen Abhängigkeit, die aus funktionalen Abhängigkeiten in F ableitbar sind
41
Armstrong Axiome
-Bestimmung der Abhängigkeiten
-reflexiv
-Verstärkung
-transitiv
42
Erweiterte Armstrong Axiome
Vereinigung
Dekomposition
Pseudotransitivität
43
Kriterien für die Zerlegung eines Relationsschemas
-Verlustlosigkeit: Ursprungrelation muss durch einen Natrual Join der Teilrelation rekonstruierbar sein
-Abhängigikeitserhaltung: funktionale Abhängigkeiten müssen übertragbar sein auf Teilrelationen -> hüllengetreue Zerlegung
44
1. Normalform
alle Attribute sind atomar
45
2. Normalform
- 1.NF
-jedes Attribut ist Teil eines Kanditatenschlüssels oder von JEDEM Kanditatenschlüssel voll funktional abhängig
46
3. Normalform
- 2.NF
-keine funktionalen Abhängigkeiten von Nichtschlüsselattributen innerhalb von Relationen -> KEINE transitiven Abhängigkeiten
47
5 Schichten Architektur
Datensystem
Zugriffssystem
Speichersystem
Pufferverwaltung
Betriebssystem
48
Speichersystem Organisation
double linked list
49
Speichersystem Header
information previos and follwing page
number of page (optional)
Type of recors
Information about free space
50
Satzadressierung
Speichersystem
Adressen werden beim Einfügen von Sätzen vergeben und später zum Zugreifen verwendet
51
Satzadressierung Probleme
Speichersystem
Eindeutigkeit -> lebenslange Adressierung
langfristige Speicherung von Datensätzen
Vermeidung von Technologieabhängigkeit
Unterstützung Migration
52
Satzadressierung Ziele
Speichersystem
schneller, direkter Zugriff
Stabilität gegenüber geringfügigen Verschiebungen
Selten/keine Reorganisation
53
TID-Konzept
Speichersystem
Adressierung über Indirektion innerhalb einer Seite
Array mit Byte-Postion der Sätze in der Sätze
TID:Tupel-Identifier (Seitennummer + Index)
54
binäre Suchbäume
Zugriffssystem
maximale Größe der Knoten = Speicherkapazität der Seite
direkter Schlüsselzugriff
sortierter Sequentieller Zugriff
55
binäre Suchbäume
Eigenschaften
Zugriffssystem
Typ(k,h)
h = maximale Länge jeden Pfades
k = minimale # Einträge
2k = maximale # Einträge
-> außer Wurzel
k+1 = min # von Nachfolgern
2k+1 = maximale # von Nachfolgern
mindestens 50% Speicherauslastung
hohe Höhe
keine Redundanz
56
B*-Baum
Eigenschaften
Zugriffssystem
alle Sätze in Blattknoten
innere Knoten nur Verzweigungsinformation
teilweise redundant (Schlüsselwerte)
geringe Höhe
57
Bitmap-Index
Zugriffssystem
Bitliste für jeden Attributwert
jedem Tupel wird ein Bit in Liste zugeordnet
Suche über Submaske (AND)
58
Datensystem
wie werden Daten gefunden
-> Auswertungsstrategie
59
physische Optimierung
Datensystem
diverse Zuordnung der algebraischen Ausdrücke
60
Kostenbasierte Auswahl
Datensystem
-Kostenfunktion -> berechnet Gesamtkosten der Anfrage aus Kostenabschätzung der Einzeloperationen
-Größe der Zwischenergebnisse hat Einfluss
-gesucht werden Kanidaten die schnell Lösungsraum einschränken
61
Prinzip der transaktionalen Verarbeitung
-zusammenfassen aufeinanderfolgender Operationen
-überführen konsistente DB in konsistente DB (möglicherweise zwischendurch inkonsistent)
62
Savepoint
noch aktive Aktionen lässt sich zurücksetzen -> für lange Transaktionen
63
Backup transaction
zurücksetzten auf letzten Sicherungspunkt (oder andere )
64
ACID-Eigenschaften
Atomicity
Consistency
Isolation
Durability
65
Atomicity
-Unteilbarkeit durch Transaktionsdefinition -> gesamte Transaktion wirkungslos, wenn ein Teil wirkungslos
66
Consistency
-erfolgreiche Transaktion garantiert, dass alle Konsistenzbedingungen eingehalten wurden
67
Isolation
mehrere Transaktionen laufen isoliert ab und benutzen keine inkonsistenten Ergebnisse
68
Durability
alle Ergebnisse erfolgreicher Transaktionen müssen, persistent gemacht werden 8
(dauerhaft gespeichert)
69
Transaktionsverwaltung
Synchronisation
Recovery
70
Synchronisation
Ziel: erhalten Transaktionskonsistenz, vermeiden gegenseitiges beeinflussen von Lese- und Schreiboperationen, verhindern Anomalien
71
Arten von Konsistenz
Datenkonsistenz
Transaktionskonsistenz
72
Datenkonsistenz
alle definierte Konsistenzbedingungen sind erfüllt
73
Transaktionskonsistenz
nebenläufiger Ablauf der Transaktionen ist korrekt
-> Gefahr Anomalien
74
Arten von Anomalien
lost update
dirty read
dirty overrride
non-repeatable read
Phantom Problem
75
Serialisierbarkeit
-verhindern Anomalien
-Historie welche zum gleichen Ergebnis wie eine serielle Historie führt
-keine Zyklen im Serialisierbarkeitsgraphen
76
lost update
geschriebene Daten gehen verloren
77
Dirty read
lesen von inkonsistenten Daten
78
Non-repetable read
lesen von unterschiedlichen Daten in einer Transaktion
79
Phantom Problem
Variable wird einmal gelesen und danach gelöschte -> erneutes lesen führt zum Problem
80
Ausführungsplan
Transaktionen können nebeneinander ablaufen -> regelt relative Ausführung zueinander
81
Konfliktoperationen
eine der Operationen ist eine Schreiboperation
82
sequentielle Ausführung
Vorteile, Nachteile
Vorteile: sicher
Nachteile: schlechte Systemauslastung, langsam
83
Datenbank Scheduler
ordnet eingehende Operationen
sorgt für Serialisierbarkeit & Rücksetzbarkeit
84
Strategien Scheduler
pessimistisch
optimistisch
85
Pessimistisch
-verzögern entgegengenommene Operationen
-festlegen geschickte Reihenfolge
-z.B. sperrbasierter Scheduler
86
Optimistisch
-möglichst schnelles Ausführen Operationen
-später eventuelles reparieren von Schaden
-z.B. optimistische Synchronisation, zeitstempelbasierter Scheduler
87
Synchronisation durch Sperren
Pessimistischer Scheduler
logischer Einbenutzerbetrieb -> sperren für exclusiven Zugriff
jedes Datenobjekt zentral eine Sperrtabelle
88
Arten von Sperren
X -> Exclusiv -> Schreibsperre
S/R -> Shared/Read- Sperre -> Lesesperre
89
Statische Sperren
zu Beginn alle Sperren anfordern -> Nachteil: alles sperren was man brauchen KÖNNTE
90
Dynamische Sperren
während Transaktion anfordern nach Bedarf -> Nachteil: Verklemmmung
91
ZweiPhasen-Sperrprotokoll
-Wachstums- und Schrumpfungsphase -> Problem: kaskadierendes Abbrechen
92
Striktes ZweiPhasen-Sperrprotokoll
-Freigabe Lesesperren nach 2PL
-Freigabe Schreibsperren erst am Ende
93
Deadlocks
-Verklemmung
-unvermeidbar bei persimistischen Ansätzen
-Vorraussetzung: paralleler Zugriff, x-Lock, keine vorzeitige Freigabe
94
Behandlungsmöglichkeiten Deadlocks
Deadlockererkennung
Deadlockvermeidung
95
Deadlockererkennung
Wartegraph
prüfen auf periodischen Zyklus
-> zurücksetzen einer Transaktion
96
Deadlockvermeidung
direktes zurücksetzten einer Transaktion
97
Optimistische Synchronisation (OCC)
Lese-Phase
Validierungsphase
Schreibphase
98
Lesephase OCC
eigentliche Transaktionsverarbeitung, Änderungen nur im lokalen Transaktionspuffer
99
Validierungsphase OCC
atomar
Konfliktprüfung
Konflikt -> zurücksetzen
100
Schreibphase
atomar
dauerhafte Speicherung der Änderungen
101
Validierungsstrategien
Backward Oriented
Forward Oriented
102
Backward Oriented BOCC
Validierung gegenüber bereits beendeten Transaktionen
103
Forward Oriented FOCC
Validierung gegenüber laufenden Transaktionen
104
Recovery
wiederherstellen jüngsten transaktionskonsistenten Datenbankenzustand
105
Undo
Recovery
Änderung aller offenen Transaktionen rückgängig machen
106
Redo
Recovery
Änderung aller abgeschlossen Transaktionen gegebenenfalls wiederholen
107
Log-Datei
Recovery
-protokolliert Änderungen
-getrennte Speicherung Sicherungspunkt und Log-Datei
108
Fehlerarten
Recovery
Systemfehler
Gerätefehler
Transaktionsfehler
Katastrophe
109
Recovery-Klassen
Recovery
-R1
-R2
-R3
-R4
110
force
Ausschreibungsstrategien
Recovery
am Ende einer Transaktion werden alle Seiten die verändert wurden auf die Festplatte geschrieben -> langsame Schreiboperationen nötig, garantierte Dauerhaftigkeit
111
no force
Ausschreibungsstrategien
Recovery
Seiten werden nicht auf Festplatte geschrieben, wenn mehrere Transaktion eine Seite verändern, muss sie nicht mehrmals gespeichert werden -> redolock wird benötigt
112
no steal
Ersetzungsstrategien
Recovery
-Solange Transaktion noch aktiv keine Übertragung auf Festplatte
-Veränderungen geschehen im Pufferpool -> Atomarität Transaktionen, Bei Ausfall geht Pufferpool verloren, schnell Kapazität erreicht
113
steal
Ersetzungsstrategien
Recovery
-schreiben von nicht veränderten Transaktionen
-Seiten laufender Transaktionen können auf Festplatte geschrieben werden -> effizientes nutzen Pufferpool, Atomarität gewährleistet
114
Einbringungsstrategie
Recovery
Update-in-Place
-Twin-Block-Verfahren
-Schattenspeicherkonzept
115
Einbringungsstrategie
Update-in-Place
Recovery
-direkte Strategie
-jede Seite hat einen Platz im Hintergrundspeicher -> alter Zustand wird überschrieben
116
Einbringungsstrategie
Twin-Block-Verfahren
Recovery
-indirekte Strategie
-jede Seite werden zwei Seiten zugeordnet
-für letzten und vorletzten Zustand
117
Einbringungsstrategie
Schattenspeicherkonzept
Recovery
-indirekte Strategie
-nur geänderte Seiten werden dupliziert, weniger Redundanz als bei Twin-Block
118
Protokollierungsarten
Recovery
logische Protokollierung
physische Protokollierung
119
Protokollierungsarten
logische Protokollierung
Recovery
-notieren Undo-Operation, um vorherigen Zustand zu erzeugen
-notieren redo-Operation, um Nachfolgezustand zu erzeugen
120
Protokollierungsarten
physische Protokollierung
Recovery
-notiere Before-Image des Objektes
-notiere After-Image des Objektes
121
Protokollierung benötigte Informationen
Recovery
Redo-Informationen
Undo-Informationen
LSN (Log Sequenz Number)
Transaktionskennung
Page ID
PrevLSN
122
Log-Daten
Recovery
Log-Datei: schneller Zugriff, R1,R2,R3-Recovery
Log-Archiv: R4-Recovery
123
Log-Puffer
Recovery
Ringpuffer
kleiner als DB-Puffer
wenn voll-> schreiben Hintergrundspeicher
124
Phasen des Wiederanlaufs
Recovery
-Analyse( Bestimmen Winner und Loser)
-Redo/Wiederholung der Historie
-Undo der Loser
125
Phasen des Wiederanlaufs
Analysephase
Recovery
-Ermittlung gestartet Transaktion durch BOT-Einträge
-Winner -> hat schon commited
Loser -> fehlende commit Einträge
126
Phasen des Wiederanlaufs
Redo-Phase
Recovery
-Logdatei vorwärts durchlaufen
-referenzierte Seite aus Datenbankpuffer holen
-LSN mit LSN Logdatei überprüfen
-LSN (Log) größer (jünger) -> Redo
127
Phasen des Wiederanlaufs
Undo-Phase
Recovery
-Logdatei rückwärts durchlaufen
-alle Log-Einträge der Loser -> holen Seite aus Puffer -> undo
