Dipl.-Oek. Patrick Bartels

Datenorganisation
Februar bis Mai 2007
Dipl.-Oek. Patrick Bartels
Institut für Wirtschaftsinformatik
Universität Hannover
Telefon:
+49 (0) 511 762 - 4979
+49 (0) 170 342 84 95
Email: [email protected]
Internet: www.iwi.uni-hannover.de
Datenorganisation | Veranstaltung 6
4. Datenintegrität
2
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
Literatur
ƒ Schwarze, J.
ƒ Kemper, A. ; Eickler, A., S. 133-141
ƒ Schicker, E., S. 73-82, 212-220
ƒ Vossen, G., S. 147-152, 171-177
3
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4. Datenintegrität
„Datenintegrität umfasst Widerspruchsfreiheit (Konsistenz) der
Daten, die Sicherung der Daten gegen Verlust und Verfälschung
sowie die Einhaltung von Datenschutzvorschriften.“
Quelle: Schwarze
4
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4. Datenintegrität
Datenintegrität umfasst:
ƒ Datensicherheit: Sicherung der Daten
vor Zerstörung, Verfälschung und unberechtigtem Zugriff
ƒ Datenschutz: Einhaltung rechtlicher Richtlinien, insbesondere
Schutz personenbezogener Daten
ƒ Datenkonsistenz: Sicherstellung der Widerspruchsfreiheit der
Daten
5
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4.1. Datensicherheit
6
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4.1. Datensicherheit
„Als Datensicherheit bezeichnet man den Schutz vor Zugriffen von
unberechtigten Personen und den Schutz gegen zufälliges oder
absichtliches Verändern oder Zerstören der Daten.“
Quelle: Schwarze
7
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4.1. Datensicherheit
Schutz der Daten vor folgenden Gefahren:
ƒ Zerstörung von Daten durch Feuer, Diebstahl, Festplattendefekt,
...
ƒ Computerviren
ƒ Datenmissbrauch, d. h. Verhinderung, dass ein unberechtigter
Benutzer auf die Daten zugreift
8
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4.1. Datensicherheit
Maßnahmen zum Schutz der Daten:
ƒ Zugriffsschutz, z. B. Zugangskontrolle über Benutzername und
Passwort
ƒ Schutz vor Zerstörung (z. B. Brandschutz, USV, Virenscanner)
ƒ Räumliche Zugangssperren
ƒ Regelmäßige Datensicherungen (Backup, Recovery)
9
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4.1. Datensicherheit
Sicherheitsprozess
10
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4.1. Datensicherheit
Sicherheitskosten
11
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4.1. Datensicherheit
Sicherheitskosten
12
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4.2. Datenschutz
13
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4.2. Datenschutz
„Datenschutz bezieht sich auf die rechtliche Seite des unbefugten
Zugriffs und der unbefugten Weitergabe personenbezogener
Daten.“ Geregelt im Bundesdatenschutzgesetz usw.
Quelle: Schwarze
14
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4.2. Datenschutz
Maßnahmen zur Gewährleistung von Datenschutz:
ƒ Zugriffsschutz (Benutzername und Passwort)
ƒ Sichten, Zugriffsrechte auf Feldebene
ƒ Verschlüsselung (Kryptographie)
ƒ Schriftliche Einwilligung der Datenverarbeitung durch Kunden
(Data Mining)
15
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4.3. Datenkonsistenz
16
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4.3. Datenkonsistenz
Sicherstellung von Datenkonsistenz (Widerspruchsfreiheit) durch:
ƒ Jede einzelne Anwendung (fehleranfällig!)
ƒ DBMS (nur an einer Stelle)
17
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4.3. Datenkonsistenz
Arten von Integritätsbedingungen:
ƒ Statische Bedingungen: müssen von jedem Zustand einer
Datenbank erfüllt werden
ƒ Transitionale und dynamische Bedingungen:
Zustandsübergänge,
z. B. ledig → verheiratet → (geschieden oder verwitwet)
18
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4.3. Datenkonsistenz
Statische Integritätsbedingungen:
ƒ Auf Feldebene: z. B. Einschränkung des Wertebereichs
(Ober-/Untergrenze), Eingabeformate, Festlegung bestimmter
Werte, Not-Null
ƒ Auf Datensatzebene: [RDAT]>=[LDAT]
ƒ Auf Tabellenebene: z. B. Primärschlüssel
ƒ Referentielle Bedingungen: Beziehungen
19
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4.3.1. Referentielle Integrität
Referentielle Integrität:
ƒ Unter referentieller Integrität versteht man die Durchsetzung der
definierten Beziehungen zwischen Relationen
ƒ Jede Relation hat einen Primärschlüssel
ƒ Die Verknüpfung von zwei Relationen geschieht durch
Schlüsselvererbung: Der Primärschlüssel der einen Relation wird
als Fremdschlüssel an die andere Relation vererbt
20
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4.3.1. Referentielle Integrität
ƒ 1-Seite: Haupt- oder Mastertabelle
ƒ n-Seite: Detailtabelle (enthält Primärschlüssel der Haupttabelle
als Fremdschlüssel)
ƒ Der Fremdschlüssel (n-Seite) kann nur gültige Werte des
vererbenden Primärschlüssels (1-Seite)
ƒ Beispiel: Kunde — Rechnung
21
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4.3.1. Referentielle Integrität
ƒ Jeder Fremdschlüsselwert in der Detailtabelle muss als
Primärschlüsselwert in der Haupttabelle existieren
ƒ Verweist ein Fremdschlüsselwert auf
einen Primärschlüsselwert, kann der Primärschlüsselwert nicht
geändert werden
22
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4.3.1. Referentielle Integrität
Änderung des Primärschlüssels:
ƒ on update no action
ƒ on update cascade (Aktualisierungsweitergabe)
ƒ on update set null
23
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4.3.1. Referentielle Integrität
Löschen eines Datensatzes:
ƒ on delete no action
ƒ on delete cascade (Löschweitergabe)
ƒ on delete set null
24
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4.3.1. Referentielle Integrität
Referentielle Integrität bei 1:n-Beziehungen:
ƒ Aktualisierungsweitergabe: Eine Änderung des Primärschlüssels in
der Haupttabelle führt zu einer Anpassung der Fremdschlüssel der
zugehörigen Detaildatensätze (on update cascade)
ƒ Löschweitergabe: Eine Löschung eines Datensatzes in der
Haupttabelle führt zur Löschung aller zugehörigen Datensätze
in der Detailtabelle (on delete cascade)
25
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4.3.1. Referentielle Integrität
Kaskadierendes Löschen :
ƒ Mehrfaches „on delete cascade“
ƒ Vorsicht: eventuell werden Datensätze gelöscht, die gar nicht
gelöscht werden sollten
26
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4.3.2. Trigger
Die Integritätsüberwachung kann transaktionsorientiert oder
ereignisorientiert erfolgen.
Transaktionsorientiert: Nach Durchführung einer
Datenbankoperation wird überprüft, ob die Integrität verletzt
wurde. Wenn ja, wird die Operation rückgängig gemacht.
Ereignisorientiert: Bei Vorliegen eines Ereignisses wird eine
Bedingung geprüft. Ist die Bedingung erfüllt, wird eine Aktion
ausgeführt.
27
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4.3.2. Trigger
Ein Trigger (engl. „Auslöser“) stellt eine aktive Komponente eines
DBMS dar, da ein Trigger eine Aktion eigenständig ausführen
kann.
28
ƒ
Ereignis: Datenbankoperation (Löschen, Einfügen, Ändern von
Datensätzen)
ƒ
Bedingung (kann hohen Komplexitätsgrad aufweisen)
ƒ
Aktion (z. B. benutzerdefinierte Prozedur)
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4.3.2. Trigger
trigger on { INSERT | DELETE | UPDATE } if Bedingung then do
Aktion
trigger on { INSERT | DELETE | UPDATE } if not Bedingung then
undo Aktion
29
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4.3.2. Trigger
Vereinfachtes Beispiel:
create trigger auftrag_tr
after update on auftrag
insert into auftragshistorie(auftrnr, datum, zeit, user, summe)
values(auftrag.auftrnr, date(), time(), user,auftrag.auftr_summe);
30
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
4.3.2. Trigger
In Access:
Ereignisorientierte Programmierung, z. B. beim Verlassen eines
Formularfeldes wird eine Prozedur aufgerufen. Die Ausführung der
Prozedur ist jedoch nicht abhängig von einer Bedingung.
31
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5. Datenmanipulation
32
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
Literatur
ƒ Schwarze, J.
ƒ Kemper, A. ; Eickler, A., S. 72-90, 205-207, 241-247
ƒ Schicker, E., S. 60-62, 82-87, 237-238
ƒ Vossen, G., S. 435-469, 499-508
33
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5. Datenmanipulation
„Unter einer Datenmanipulation versteht man eine beliebige
Operation auf einer Datenbank.“
Man unterscheidet drei Zugriffsarten:
ƒ Abfrage: lesender Zugriff auf die Daten
ƒ Mutation: Ändern, Löschen, Einfügen
ƒ Transaktion: konsistenzerhaltende Operationen
Quelle: Schwarze
34
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5. Datenmanipulation
Abfragearten:
ƒ Freie Abfrage, z. B. SQL oder QBE
ƒ Strukturierte Abfrage: menügesteuert
QBE: Query by Example: fensterorientierte, visuelle
Abfragesprache, einfach zu erlernen, interaktiv
35
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.1. Transaktionsverwaltung
36
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.1. Transaktionsverwaltung
„Eine Transaktion ist eine konsistenzerhaltende Operation auf
einer Datenbank. Eine Operation besteht aus einer beliebigen
Anzahl von Abfragen und Mutationen.“
„Konsistenz heißt die Freiheit von Widersprüchen innerhalb einer
Datenbank.“
„Eine Transaktion muss .. immer entweder komplett oder gar
nicht ausgeführt werden. Eine Transaktion ist demnach ein
atomarer Zugriff!“
Quelle: Schicker
37
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.1. Transaktionsverwaltung
Konten-Beispiel:
ƒ Abbuchen von Betrag x von Konto 1
ƒ Zugang von Betrag x auf Konto 2
Erst nach Abschluss beider Buchungen ist die Datenbank wieder in
einem konsistenten Zustand.
38
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.1. Transaktionsverwaltung
Transaktionen sind wichtig für:
ƒ das Recovery (Fehlerbehandlung)
ƒ die Mehrbenutzersynchronisation (parallel ablaufende
Transaktionen)
39
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.1. Transaktionsverwaltung
Elemente einer Transaktion:
ƒ begin of transaction (BOT)
ƒ Befehle 1, 2, ..., n (Lesen, Schreiben)
ƒ commit (Beendigung einer Transaktion)
ƒ abort (Abbruch einer Transaktion, "rollback")
40
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.1. Transaktionsverwaltung
Erfolgreiche Transaktion:
BOT
Befehl 1
Befehl 2
...
Befehl n
commit
41
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.1. Transaktionsverwaltung
Abbruch einer Transaktion:
BOT
Befehl 1
Befehl 2
...
Befehl n
abort
42
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.1. Transaktionsverwaltung
Fehler während einer Transaktion:
BOT
Befehl 1
Befehl 2
...
Befehl n
Fehler (Stromausfall, Hard-/Software, Verletzung von
Konsistenzbedingungen usw.)
43
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.1. Transaktionsverwaltung
Eigenschaften von Transaktionen (ACID):
Atomicity: Eine Transaktion stellt die kleinste, nicht weiter
zerlegbare Einheit dar. Sie wird entweder vollständig abgearbeitet
oder vollständig zurückgesetzt.
Consistency: Eine Transaktion überführt den Datenbestand von
einem konsistenten Zustand in einen (anderen) konsistenten
Zustand.
Isolation: Gleichzeitig ausgeführte Transaktionen dürfen sich nicht
gegenseitig beeinflussen.
Durability (Dauerhaftigkeit): Eine erfolgreich abgeschlossene
Transaktion muss permanent (auch nach einem Fehler) in der
Datenbank erhalten bleiben.
44
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.1. Transaktionsverwaltung
Transaktionsverwaltung in SQL:
ƒ Transaktionen werden implizit begonnen (kein BOT)
ƒ Abschluss einer Transaktion mit commit work
ƒ Abbruch einer Transaktion mit rollback work
45
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.1. Transaktionsverwaltung
Transaktionsverwaltung in Access:
ƒ Transaktionen werden explizit begonnen (mit begin transaction)
ƒ Abschluss einer Transaktion mit commit [work | transaction]
ƒ Abbruch einer Transaktion mit rollback [work | transaction]
ƒ Können verschachtelt sein (5 Ebenen)
46
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.2. Abfragesprachen
47
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.2. Abfragesprachen
Für die Abfrageformulierung in relationalen Datenbanken gibt es die
folgenden zwei formalen Abfragesprachen:
1. Relationale Algebra (Relationenalgebra)
2. Relationenkalkül
Sie bilden die theoretische Basis für SQL und QBE.
48
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.2.1. Relationenalgebra
Relationenalgebra:
Es gibt acht Operatoren, mit denen die Zugriffe auf die Relationen
einer Datenbank formuliert werden können.
Ein Ausdruck der Relationenalgebra wird aus diesen Operatoren
zusammengesetzt.
49
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.2.1. Relationenalgebra
Die acht Operatoren der Relationenalgebra:
ƒ Selektion (R WHERE Bedingung)
ƒ Projektion (R [Attributauswahl])
ƒ Vereinigung (R1 UNION R2)
ƒ Mengendifferenz (R1 MINUS R2)
ƒ Kartesisches Produkt (R1 TIMES R2)
ƒ Verbindung/Join (R1 JOIN R2)
ƒ Mengendurchschnitt (R1 INTERSECT R2)
ƒ Division (R1 DIVIDE BY R2)
50
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.2.1. Relationenalgebra
Selektion (R WHERE Bedingung):
Die neue Relation enthält alle Datensätze, die der Bedingung
entsprechen.
ƒ σF(R)
ƒ SigmaFormel(Relation)
ƒ Attribute, Konstanten
ƒ =,<,>,≤,≥,≠,∧(und),∨(oder),¬(nicht)
ƒ σOrt='Hannover'(Kunden)
51
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.2.1. Relationenalgebra
Projektion (R [Attributauswahl]):
Die neue Relation enthält alle Datensätze, aber nur die angegebenen
Attribute.
ƒ ΠA(R)
ƒ ΠAttributliste(Relation)
ƒ ΠKDNr,NName,Ort(Kunden)
52
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.2.1. Relationenalgebra
Vereinigung (R1 UNION R2):
Die neue Relation enthält alle Datensätze, die in mindestens einer
der beiden Relationen enthalten ist.
ƒ R1 ∪ R2 (müssen das
gleiche Schema haben)
ƒ ΠA(R1) ∪ ΠA(R2)
ƒ ΠCDNr(CD) ∪ ΠVINr(Video)
53
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.2.1. Relationenalgebra
Mengendifferenz (R1 MINUS R2):
Die neue Relation enthält diejenigen Datensätze, die in R1, aber
nicht in R2 enthalten sind.
ƒ R1 — R2 (gleiches Schema)
ƒ ΠA(R1) — ΠA(R2)
ƒ ΠCDNr(CD) — ΠCDNr(Leihe)
54
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.2.1. Relationenalgebra
Kartesisches Produkt (R1 TIMES R2):
Die neue Relation enthält alle Kombinationen der in R1 und R2
enthaltenen Datensätze.
ƒ R1 x R2
a
b
ƒ Kunde x Leihe
ƒ Evtl. qualifizierte Attributnamen,
z. B. Kunde.KDNr, Leihe.KDNr
55
19. März 2007
Dipl.-Ök. Patrick Bartels
x
y
z
a
a
a
b
b
b
x
y
z
x
y
z
Datenorganisation | Veranstaltung 6
5.2.1. Relationenalgebra
Die ersten fünf Operatoren sind notwendig, die folgenden drei
Operatoren lassen sich jedoch durch Kombination aus den ersten
fünf Operatoren ausdrücken.
56
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.2.1. Relationenalgebra
Verbindung/Join (R1 JOIN R2):
Die neue Relation enthält Kombinationen von Datensätzen der
Relationen R1 und R2, die über ein gemeinsames Attribut verknüpft
wurden.
ƒ R1
R2 (natural Join)
ƒ ΠA1,...,B,C1,...(σR1.B=R2.B(R1xR2))
ƒ Kunden
Leihe
x1 y1
x2 y2
x3 y2
y1 z1
y2 z2
y3 z1
x1 y1 z1
x2 y2 z2
x3 y2 z2
57
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.2.1. Relationenalgebra
Allgemeiner (innerer) Join:
Beim allgemeinen Join (Theta-Join) handelt es sich um einen Join, bei
dem die Verknüpfungsattribute nicht gleichbenannt sein müssen.
ƒ R1
θ
R2
ƒ σθ(R1 x R2)
ƒ σR1.A=R2.B(R1 x R2) (Equi-Join)
x1 y1
x2 y2
x3 y2
y1 z1
y2 z2
y3 z1
x1 y1 y1 z1
x2 y2 y2 z2
x3 y2 y2 z2
58
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.2.1. Relationenalgebra
Äußerer Join:
ƒ Left outer join (alle Tupel der linken Relation bleiben erhalten:
R1
R2
ƒ Right outer join (alle Tupel der rechten Relation bleiben erhalten:
R1
R2
ƒ Full outer join (alle Tupel der linken und der rechten Relation
bleiben erhalten:
R1
R2
59
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.2.1. Relationenalgebra
Mengendurchschnitt (R1 INTERSECT R2):
Die neue Relation enthält nur die Datensätze, die in beiden
Relationen enthalten sind.
ƒ R1 ∩ R2 = R1 — (R1 — R2)
ƒ R1 und R2 müssen das
gleiche Schema haben
ƒ ΠA(R1) ∩ ΠA(R2)
ƒ ΠCDNr(CD) ∩ ΠCDNr(Leihe)
60
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.2.1. Relationenalgebra
Division (R1 DIVIDE BY R2):
R2 ist in R1 enthalten. Die neue Relation enthält die Attribute, die
nicht in R2 enthalten sind, und die Datensätze aus R1, bei denen eine
Übereinstimmung zu den Werten in R2 existiert.
ƒ R1 : R2
ƒ Π(R1-R2)(R1) — Π(R1-R2)((Π(R1-R2)(R1) x R2) — R1)
61
19. März 2007
Dipl.-Ök. Patrick Bartels
a
a
a
b
c
x
y
z
x
y
x
y
a
Datenorganisation | Veranstaltung 6
5.2.1. Relationenalgebra
Operatorbaum-Darstellung:
Bei komplexen Anfragen ist die Darstellung über einen Operatorbaum
übersichtlicher:
∏
CDNr, CDTitel, Interpret
CD.CDNr=Leihe.CDNr
σ
CDNr=CD00000001
Leihe
CD
62
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.2.2. Relationenkalkül
Relationenkalkül:
Der Relationenkalkül ist eher deklarativ,
d. h. die gesuchten Datensätze werden beschrieben, ohne
anzugeben, wie das Ergebnis bestimmt werden soll.
Es gibt zwei Ausprägungen des Relationenkalküls:
ƒ Der relationale Tupelkalkül
ƒ Der relationale Domänenkalkül
63
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.2.2. Relationenkalkül
Der relationale Tupelkalkül:
ƒ {t | Bedingung}
ƒ t heißt Tupelvariable
ƒ {p | p ∈ CD ∧ p.Interpret='Joe Cocker'}
ƒ Der Relationenkalkül lässt sich ohne Verluste in die
Relationenalgebra umformen. Beide Anfragesprachen sind
"relational vollständig".
64
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.2.3. Anfrageoptimierung
Anfrageoptimierung:
ƒ Das DBMS muss entscheiden, wie eine Anfrage optimal
abgearbeitet wird, da es unter Umständen sehr viele
Ausführungsmöglichkeiten gibt, die sich in ihrer
Ausführungsdauer stark unterscheiden können.
ƒ select ... from ... where
Projektion(Selektion(Kreuzprodukt))
65
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
5.2.3. Anfrageoptimierung
Projektion(Selektion(Kreuzprodukt))
∏ CDNr, CDTitel, Interpret
σ
CDNr='CD00000001'
∧
∏ CDNr, CDTitel, Interpret
σ
CD.CDNr=Leihe.CDNr
CD.CDNr=Leihe.CDNr
x
x
σ
CDNr='CD00000001'
CD
66
19. März 2007
Leihe
CD
Dipl.-Ök. Patrick Bartels
Leihe
Datenorganisation | Veranstaltung 6
6. Recovery
67
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
Literatur
ƒ Kemper, A. ; Eickler, A., S. 249-269
ƒ Schicker, E., S. 173-187
ƒ Vossen, G., S. 583-595
68
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
6. Recovery
Unter Recovery versteht man die Wiederherstellung einer
Datenbank nach aufgetretenen Fehlern. Dabei muss die
Konsistenz der Daten sichergestellt werden.
Das Recovery hängt eng mit dem Begriff der Transaktionen
zusammen.
69
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
6. Recovery
Fehlerarten:
ƒ Hardwarefehler: Stromzufuhr, Hardwaredefekt durch Brand,
Netzwerkausfall usw.
ƒ Softwarefehler: Fehler im Anwendungsprogramm (z. B. Division
durch 0), in der Datenübertragungssoftware usw.
ƒ Benutzerfehler: Benutzer führt eine Transaktion nicht vollständig
aus.
70
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
6. Recovery
Transaktion:
ƒ Konsistenzerhaltender Datenbankzugriff
ƒ Besteht meistens aus mehreren Einzelzugriffen
ƒ Commit Work oder Rollback Work
ƒ Alle Änderungen an den Daten werden in einer Logdatei
protokolliert, damit ein Commit oder Rollback auch im Fehlerfall
durchgeführt werden kann
71
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
6. Recovery
Maßnahmen des Recovery:
ƒ Wöchentliche Komplettsicherung der Datenbank
ƒ Tägliche Differenzsicherung (nur Änderungen werden gesichert)
ƒ Führen einer Protokolldatei (Logdatei)
72
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
6.1. Logdatei
73
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
6.1. Logdatei
ƒ Protokolldatei: alle Veränderungen an den Daten werden in der
Datenbank und in der Logdatei gespeichert
ƒ Auf einem nichtflüchtigen Speicher
ƒ Auf einem anderen Medium (nicht die gleiche physische
Festplatte) als die Datenbank
74
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
6.1. Logdatei
Ablauf:
ƒ Laden der Daten in den DB-Puffer
ƒ Before Image: zu verändernde Daten werden in Logdatei
gespeichert
ƒ Ändern der Daten im Datenbankpuffer
ƒ After Image: geänderte Daten werden in Logdatei gespeichert
ƒ Wiederholung für jeden Einzelschritt einer Transaktion
ƒ Commit (Transaktionsende in Logdatei speichern) oder Rollback
(Rückgriff auf Before Image, Rücksetzen aller Änderungen)
ƒ Asymmetrische Speicherung der geänderten Daten in die
Datenbank
75
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
6.1. Logdatei
Informationen in der Logdatei:
ƒ Redo-Infos: wie können die Änderungen nachträglich vollzogen
werden (After Image)
ƒ Undo-Infos: wie können die Änderungen rückgängig gemacht
werden (Before Image)
ƒ Fortlaufende Nummer des Log-Eintrags
ƒ Nummer der Transaktion
ƒ Nummer der Datenbank-Seite
ƒ Zeiger auf vorherigen Log-Eintrag der TA
76
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
6.1. Logdatei
ƒ Umfang des Datentransfers in die Logdatei ist sehr gering
ƒ Verzögertes Schreiben der Änderungen in Logdatei, kurz bevor
die Änderungen in die Datenbank geschrieben werden (zum
Transaktionsende), reicht aus (Logpuffer)
ƒ In die Logdatei wird sequentiell geschrieben
ƒ Normale Logdatei (auf Festplatte) und Logarchiv (auf Band)
77
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
6.2. Fehlerarten
78
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
6.2. Fehlerarten
ƒ Lokaler Fehler (einzelne Transaktion, noch kein Commit)
ƒ Ausfall des Arbeitsspeichers (des Datenbankpuffers!)
ƒ Hardwareausfall (z. B. Defekt einer Festplatte)
79
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
6.2. Fehlerarten
Lokaler Fehler (einzelne Transaktion):
ƒ Lokales Undo: Alle Änderungen an den Daten, die von der
aktiven Transaktion ausgelöst wurden, werden rückgängig
gemacht
ƒ Die Logdatei wird für die betroffene Transaktion von hinten nach
vorne durchgearbeitet
ƒ Relativ häufig
ƒ Im Millisekundenbereich
80
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
6.2. Fehlerarten
Ausfall des Arbeitsspeichers (DB-Puffers):
ƒ Vor dem Ausfall gespeicherte Transaktionen (kein
Handlungsbedarf)
ƒ Globales Redo: nicht gespeicherte, aber abgeschlossene
Transaktionen, müssen in die DB gespeichert werden (Winner)
ƒ Globales Undo: gespeicherte, nicht abgeschlossene
Transaktionen werden rückgängig gemacht (Looser)
81
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
6.2. Fehlerarten
Hardwareausfall:
ƒ Rücksicherung der Archivkopie der Datenbank
ƒ Konsistenz herstellen über Log-Archiv (beinhaltet alle seit
Anlegen der Archivkopie gespeicherten Änderungen, wird
aufgrund seiner Größe meist auf Magnetband gespeichert)
82
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
6.3. Checkpoints
83
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
6.3. Checkpoints
Checkpoints = Sicherungspunkte
ƒ Markierung einer Position in der Logdatei, ab der die
Wiederherstellung erfolgen soll
ƒ Ältere Log-Einträge sind ohne Bedeutung
84
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
6.3. Checkpoints
Transaktionskonsistente Checkpoints:
ƒ Alle Transaktionen werden zu Ende geführt, keine neuen
begonnen
ƒ Es werden alle veränderten Datenbankseiten vom
Datenbankpuffer in die Datenbank übertragen
ƒ Es werden also nur abgeschlossene Transaktionen
abgespeichert
ƒ Beeinträchtigt stark den Datenbankablauf
85
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
6.3. Checkpoints
Aktionskonsistente Checkpoints:
ƒ Alle elementaren Änderungsoperationen werden zu Ende
geführt, keine neuen begonnen
ƒ Es werden alle veränderten Datenbankseiten vom
Datenbankpuffer in die Datenbank übertragen
ƒ Es werden auch nicht abgeschlossene Transaktionen
abgespeichert
ƒ Beeinträchtigt den DB-betrieb weniger
86
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
6.3. Checkpoints
ƒ Checkpoints reduzieren den Aufwand eines Recovery (Redo ab
Checkpoint)
ƒ Zu häufige Checkpoints: häufiges Abspeichern in Datenbank
erhöht den Datenverkehr
ƒ Zu seltene Checkpoints: hohe Stoßbelastung während eines
Checkpoints
87
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
6.3. Checkpoints
Ausfall des Arbeitsspeichers (DB-Puffers):
ƒ Aktualisierung der Datenbank ab dem letzten Checkpoint
ƒ Vor dem Checkpoint abgeschlossene Transaktionen (sind in DB
gespeichert)
ƒ Nach dem Checkpoint abgeschlossene Transaktionen (evtl.
Redo)
ƒ Nach dem Checkpoint nicht abgeschlossene Transaktionen
(Undo)
88
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
7. Concurrency
89
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
Literatur
ƒ Kemper, A. ; Eickler, A., S. 273-307
ƒ Schicker, E., S. 187-202
ƒ Vossen, G., S. 551-567
90
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
7. Concurrency
Transaktionen laufen im sog. Mehrbenutzerbetrieb häufig
gleichzeitig, d. h. parallel ab. Die Konsistenz der Datenbank darf
dadurch nicht beeinträchtigt werden.
Jede Transaktion muss vom DBMS so abgearbeitet werden, als
wäre sie die einzige Transaktion im System.
91
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
7. Concurrency
Probleme des konkurrierenden Zugriffs:
ƒ Problem der verloren gegangenen Änderung (lost update)
ƒ Abhängigkeit von nicht abgeschlossenen Transaktionen (dirty
read)
ƒ Problem der Inkonsistenz
ƒ Phantomproblem
92
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
7. Concurrency
Verlorengegangene Änderung:
ƒ Zwei Transaktionen wollen die gleichen Daten lesen und ändern
ƒ TA1 schreibt seine Änderungen in die DB
ƒ TA2 überschreibt anschließend die Änderungen von TA1
TA1
TA2
select R
...
select R
update R
...
update R
93
19. März 2007
Das Update von TA1 geht verloren !
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
7. Concurrency
Nicht abgeschlossene Transaktionen:
ƒ
ƒ
ƒ
ƒ
94
Transaktion 2 ändert Daten
Transaktion 1 liest die geänderten Daten
Transaktion 2 macht seine Änderungen rückgängig
T1 hat also ungültige Daten gelesen
19. März 2007
TA1
TA2
...
update R
select R
...
...
Rollback
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
7. Concurrency
Problem der Inkonsistenz:
TA1
TA2
select Konto1 (500)
select Konto2 (200)
...
select Konto3 (800)
update Konto3 (800-500=300)
select Konto1 (500)
update Konto1 (500+500=1.000)
Commit Work
select Konto3 (300)
Summe=1.000
Commit Work
Korrekte Summe wäre 1.500 gewesen!
95
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
7. Concurrency
Phantomproblem:
ƒ Die Select-Anweisung gibt innerhalb einer Transaktion zwei
unterschiedliche Ergebnisse zurück
TA1
TA2
select ... from R
insert into R ...
...
select ... from R
96
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
7. Concurrency
Verfahren:
ƒ Optimistische Strategie: Änderungen in der Datenbank dürfen
vorgenommen werden. Vor einem Commit wird überprüft, ob es
Konflikte mit anderen Transaktionen gibt. Wenn ja, wird ein
Rollback durchgeführt und die Transaktion neu gestartet
ƒ Pessimistische Strategie: Man geht von Konflikten aus und lässt
ein gemeinsames Ändern von Daten nicht zu
97
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
7. Concurrency
Pessimistische Verfahren:
ƒ Sperrbasierte Synchronisation (mit Abstand wichtigstes
Verfahren)
ƒ Zeitstempelbasierte Synchronisation
98
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
7.1. Sperrmechanismen
99
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
7.1. Sperrmechanismen
ƒ Eine Sperre ist anzufordern, bevor Daten gelesen oder
geschrieben werden sollen
— Vom DBMS automatisch
— Vom DB-Programmierer vor jedem Zugriff
ƒ Eine Sperre wird nach Transaktionsende automatisch freigegeben
(beim Commit oder Rollback)
100
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
7.1. Sperrmechanismen
Sperrmodi:
ƒ Share-Lock, read lock, Lesesperre:
für Lesezugriffe, kann von mehreren Transaktionen angefordert
werden
ƒ Exclusive-Lock, write lock, Schreibsperre: für Schreibzugriffe,
kann nur von einer Transaktion angefordert werden
ƒ Wird ein Exclusive-Lock angefordert, obwohl es bereits einen
Share-Lock gibt, muss die Transaktion auf Freigabe warten
101
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
7.1. Sperrmechanismen
Sperr-Granulate:
ƒ Datenbank-Lock
ƒ Tabellen-Lock
ƒ Seiten-Lock
ƒ Tupel-Lock
ƒ Eintrags-Lock
Multiple-granularity locking (MGL): flexible Auswahl der benötigten
Sperrgranulate je Transaktion
102
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
7.2. Deadlocks
103
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
7.2. Deadlocks
Verlorengegangene Änderung:
ƒ Anfordern Share-Lock
ƒ Anfordern Exclusive-Lock
ƒ Warten auf Freigabe des Share-Lock
T A 1
T A 2
S -L o c k a n fo rd e rn
s e le c t R
...
S -L o c k a n fo rd e rn
s e le c t R
X -L o c k a n fo rd e rn
w a rte n
...
104
19. März 2007
...
X -L o c k a n fo rd e rn
w a rte n
...
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
7.2. Deadlocks
Nicht abgeschlossene Transaktionen:
TA1
TA2
S -L o c k a n fo rd e rn
w a rte n
X -L o c k a n fo rd e r n
u p d a te R
...
...
R o llb a c k
s e le c t R
ƒ Serialisierung konkurrierender Zugriffe
ƒ Transaktionen laufen nacheinander ab
105
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
7.2. Deadlocks
Problem der Inkonsistenz:
ƒ Warten auf Freigabe der Sperren
TA1
TA2
S-Lock zu Konto3 anfordern
select Konto3 (800)
S-Lock zu Kont1 anfordern
select Konto1 (500)
S-Lock zu Konto2 anfordern
select Konto2 (200)
S-Lock zu Konto3 anfordern
warten
106
19. März 2007
X-Lock zu Konto3 anfordern
update Konto3 (800-500=300)
S-Lock zu Konto 1 anfordern
select Konto1 (500)
X-Lock zu Konto1 anfordern
warten
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
7.2. Deadlocks
Deadlock:
ƒ Ein Deadlock ist eine Verklemmung von Transaktionen. Zwei
oder mehr Transaktionen warten auf die Freigabe von Sperren
(Share- oder Exclusive-Locks)
ƒ Es gibt verschiedene Strategien zur Deadlockvermeidung und
Deadlockauflösung
107
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
7.2. Deadlocks
Deadlockerkennung durch Wartegraphen:
ƒ TA1 wartet auf Freigabe einer Sperre, die von TA2 gehalten
wird, TA2 wartet auf Freigabe einer Sperre, die von TA3
gehalten wird, TA3 wartet auf Freigabe einer Sperre, die von
TA1 gehalten wird
ƒ Es ist ein Zyklus entstanden: Deadlock
TA1
TA3
108
19. März 2007
TA2
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
7.2. Deadlocks
Deadlockauflösung:
ƒ Bei Vorliegen eines Deadlocks muss eine der betroffenen
Transaktionen abgebrochen werden
ƒ Alle von dieser Transaktion gehaltenen Sperren werden damit
freigegeben
ƒ Die abgebrochene Transaktion muss von neuem gestartet
werden
109
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8. Moderne Datenbankarchitekturen
110
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
Literatur
ƒ Schwarze, J.
ƒ Kemper, A. ; Eickler, A., S. 403-438
ƒ Schicker, E., S. 185-187, 268-278
ƒ Vossen, G., S. 39-62, 177-179
111
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.1. Client-Server-Datenbanken
112
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.1. Client-Server-Datenbanken
"Beim Client-Server-Konzept einer Datenbank geht es ... um die
Verteilung von Prozessen, d. h. von Aufgaben innerhalb der
Datenverwaltung, auf mehrere vernetzte Rechner.„
Quelle: Schwarze
113
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.1. Client-Server-Datenbanken
Grundprinzip einer Client-Server-Interaktion:
ƒ Client-Prozess: sendet eine Anfrage
ƒ Server-Prozess: antwortet auf die Anfrage
ƒ Ein Computer kann sowohl die Rolle eines Clients als auch die
eines Servers einnehmen (bei unterschiedlichen Prozessen)
Client
Anfrage
Antwort
Quelle: Schwarze
114
19. März 2007
Dipl.-Ök. Patrick Bartels
Server
Datenorganisation | Veranstaltung 6
8.1. Client-Server-Datenbanken
Aufteilung der Datenbankaufgaben
115
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.1. Client-Server-Datenbanken
Mögliche Vorteile:
ƒ Verteilung der Last auf verschiedene Computer (Entlastung des
Servers)
ƒ Verbesserung des Antwortzeitverhaltens Datenbankbasierter
Anwendungen
ƒ Bessere Skalierbarkeit der Hardware
Mögliche Nachteile:
ƒ Koordinationsaufwand
ƒ Bei Anfrageverarbeitung durch Client: Es müssen zunächst alle
betroffenen Tabellen über das Netzwerk auf den Client
übertragen werden (hohe Netzbelastung)
116
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.1. Client-Server-Datenbanken
Konkrete Architekturen:
ƒ Client enthält API (z. B. ODBC-Treiber)
ƒ Client enthält API und Teile der Abfrageverwaltung
ƒ Client enthält API und die gesamte Abfrageverwaltung
ƒ usw.
Konkrete Verteilung der Aufgaben auf zwei oder mehr Computer!
117
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.2. Verteilte Datenbanken
118
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.2. Verteilte Datenbanken
Werden die logisch zusammengehörenden Daten einer Datenbank
auf miteinander vernetzten Computern (Knoten, Sites) an
unterschiedlichen Orten gespeichert, handelt es sich um eine
verteilte Datenbank.
Die zugehörigen Datenbankmanagementsysteme bezeichnet man
als verteilte Datenbankmanagementsysteme (VDBMS).
119
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.2. Verteilte Datenbanken
Strategien der Datenverteilung:
ƒ Replikation: Daten werden in mind. zwei Knoten redundant
gespeichert
ƒ Horizontale Partitionierung: Daten werden satzweise auf Knoten
verteilt
ƒ Vertikale Partitionierung: Daten werden attributweise auf
Knoten verteilt
ƒ Kombinationen der drei Strategien
120
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.2. Verteilte Datenbanken
Aufgabe des VDBMS:
ƒ Koordination des Zugriffs zu den verteilt gespeicherten Daten
ƒ Globale Anfrageoptimierung
ƒ Globales Recovery
ƒ Globales Concurrency
ƒ Globales Sicherheitsmanagement
121
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.2. Verteilte Datenbanken
Grundprinzip eines VDBMS:
Die verteilte Datenbank soll sich für den Anwender und
Programmierer so verhalten, als ob sie physisch an einem Ort
(nichtverteilt) abgespeichert ist (Fragmentierungstransparenz).
122
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.2. Verteilte Datenbanken
Anforderungen an ein VDBMS:
ƒ Transparenz der Speicherstelle
ƒ Replikationstransparenz
ƒ Fehlertransparenz
ƒ Transparenz des gleichzeitigen Zugriffs
ƒ Anfrageoptimierung
(Date stellt insgesamt 12 Forderungen auf)
123
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.2. Verteilte Datenbanken
Anforderungen an ein VDBMS:
ƒ Transparenz der Speicherstelle: dem Anwender bzw.
Programmierer soll die physische Speicherstruktur verborgen
bleiben
ƒ Replikationstransparenz: Daten werden behandelt, als ob sie in
einem einzigen Knoten gespeichert wären
ƒ Fehlertransparenz: globales Recovery
ƒ Transparenz des gleichzeitigen Zugriffs: globales Concurrency
ƒ Anfrageoptimierung: sehr komplexe Aufgabe! Auf welchem
Computer soll welche Verarbeitung stattfinden (Umfang der
Netzbelastung, Reihenfolge der relationalen Operatoren wie
Selektion, Join,...)
124
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.2. Verteilte Datenbanken
Repository eines VDBMS:
ƒ Enthält Schemainformationen für alle beteiligten Datenbanken
ƒ Ergibt die logische Struktur der Gesamtdatenbank
125
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.2. Verteilte Datenbanken
Vorteile:
ƒ Verbesserung der Antwortzeiten und höhere Integrität der
Daten (Speicherung und Administration der Daten am Ort der
Entstehung bzw. des Bedarfs)
ƒ Ausfallsicherheit: höhere Zuverlässigkeit des Gesamtsystems
ƒ Höhere Skalierbarkeit des Gesamtsystems
ƒ Höhere Effizienz (paralleles Arbeiten)
ƒ Senkung der Kommunikationskosten
126
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.2. Verteilte Datenbanken
Nachteile:
ƒ Ein VDBMS ist sehr komplex
ƒ Hoher Aufwand für die Koordination (Recovery, Concurrency
usw.)
ƒ Belastung des Netzwerks
ƒ Niedrige Übertragungsgeschwindigkeit des Netzwerks
ƒ Bestimmung einer optimalen Verteilungsstrategie schwierig
ƒ Anfrageoptimierung schwierig
127
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.2. Verteilte Datenbanken
Beispiel Recovery:
ƒ Datenbankübergreifende Transaktionen
ƒ Die globale Transaktion darf erst dann abgeschlossen sein,
wenn alle lokalen Einzeloperationen der Transaktion beendet
sind
ƒ Zwei-Phasen-Commit
128
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.2. Verteilte Datenbanken
Zwei-Phasen-Commit:
1.
2.
3.
4.
129
Lokales Abarbeiten einer Transaktion
Melden des Transaktionsendes
(Ende Phase 1)
Globales Transaktionsende
Endgültiges lokales Transaktionsende
(Ende Phase 2)
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.2. Verteilte Datenbanken
1. Lokales Abarbeiten einer Transaktion:
ƒ Die Einzelschritte der Transaktion werden lokal abgearbeitet und
in der lokalen Logdatei protokolliert
ƒ Es erfolgt ein lokales Commit Work
130
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.2. Verteilte Datenbanken
2. Melden des lokalen Transaktionsendes:
ƒ Nach erfolgreich durchgeführter Transaktion, wird eine Meldung
an den Koordinator (i. d. R. einer der beteiligten Knoten)
gesendet
ƒ Ist die lokale Transaktion missglückt, erfolgt eine entsprechende
Fehlermeldung
131
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.2. Verteilte Datenbanken
3. Globales Transaktionsende:
ƒ Der Koordinator sammelt alle Meldungen der Knoten (lokale
Transaktionen)
ƒ Sind alle Meldungen positiv, wird ein globales Commit Work
protokolliert
ƒ Ist auch nur eine Rückmeldung negativ, so ist ein globales
Rollback die Folge
132
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.2. Verteilte Datenbanken
4. Endgültiges lokales Transaktionsende:
ƒ Der Koordinator teilt den Knoten das Ergebnis der globalen
Transaktion mit
ƒ Die Knoten übernehmen das globale Ergebnis: endgültiges
Commit oder Rollback
ƒ Die globale Transaktion ist abgeschlossen
133
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.2. Verteilte Datenbanken
Probleme des Zwei-Phasen-Commit:
ƒ Extrem zeitintensiv (Antwortzeiten können sich erheblich
verschlechtern)
ƒ Es ist ein Koordinator notwendig (widerspricht einer der
Forderungen an verteilte Datenbanken)
ƒ Dauert eine lokale Transaktion zu lange, wird sie als gescheitert
angenommen (Zeitüberschreitung)
134
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.3. Aktive Datenbanken
135
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.3. Aktive Datenbanken
Klassische Datenbank:
ƒ Das DBMS hat die Aufgabe, Daten bereitzustellen, es wartet
also passiv auf Anfragen
ƒ Anwendungsprogramme greifen auf die Daten zu, sie führen
also aktiv Operationen auf der Datenbank aus
136
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.3. Aktive Datenbanken
Trigger:
ƒ ECA-Prinzip: Event-Condition-Action
ƒ Ein Ereignis löst die Überprüfung einer Bedingung aus; ist die
Bedingung erfüllt, wird eine bestimmte Aktion ausgelöst
(z. B. Rollback oder Starten eines kleinen Programms)
137
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.3. Aktive Datenbanken
Problem:
ƒ Die Überprüfung der Bedingung nach Eintritt eines Ereignisses
ist für manche Anwendungen zu langsam
ƒ Beispiele: Datenbank zur Überwachung von Kernkraftanlagen,
Aktienhandel (Kauf/Verkauf bei Überschreiten eines bestimmten
Schwellenwertes)
ƒ Lösung: Permanente Überwachung der Ereignisse und
Bedingungen
138
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.3. Aktive Datenbanken
Aktive Datenbank:
ƒ Verallgemeinerung des Konzepts der Trigger
ƒ Beliebige Ereignisse (nicht nur Updates)
ƒ Tritt das Ereignis ein, ist dem DBMS meist bereits bekannt, ob
die Bedingung erfüllt ist
ƒ Reaktion bereits innerhalb einer Transaktion möglich (Immediate
Firing)
139
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.4. Föderierte Datenbanken
140
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.4. Föderierte Datenbanken
Ausgangslage:
ƒ Vielzahl bereichsbezogener (unterschiedlicher) Datenbanken
ƒ Bestimmte Datenobjekte existieren in verschiedenen (logischen)
Datenbanken (z. B. Adressdaten)
ƒ Den Datenbanken liegen häufig verschiedene Datenmodelle
zugrunde (z. B. hierarchische, relationale, multidimensionale
Datenmodelle)
141
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.4. Föderierte Datenbanken
Konzept der Föderierten Datenbanken:
ƒ Erweiterung der Drei-Ebenen-Architektur um eine weitere Schicht
(sog. Föderierungsschicht), die die Integration der verschiedenen
DBMS ermöglicht
ƒ Föderieren: sich verbünden
ƒ Vier-Ebenen-Architektur
ƒ Die beteiligten DBMS behalten ihre Selbständigkeit
142
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.4. Föderierte Datenbanken
Konzept der Föderierten Datenbanken:
ƒ Ein Benutzer kann (ähnlich wie in VDBMS) auf alle Datenbanken
zugreifen oder bekommt zumindest einen Überblick über die im
Unternehmen verfügbaren Daten
ƒ Realisierung z. B. über geeignete Middleware
ƒ Eine aktive Komponente übernimmt die Aktualisierung von Daten
(z. B. Änderung von Kundenstammdaten in einer Datenbank,
entsprechende Aktualisierung der Daten auch in den anderen
Datenbanken, in denen sie gespeichert sind)
ƒ Dabei sind z. B. Schemaanpassungen notwendig
143
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.4. Föderierte Datenbanken
Aufbau der Föderierter Datenbanken:
144
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.4. Föderierte Datenbanken
Aufbau der Föderierter Datenbanken:
145
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.5. Data Warehouse
- Operative Systeme arbeiten mit zweckmäßig auf die Erfüllung
konkreter Aufgabenstellungen ausgerichteten Daten. Diese sind
weitestgehend durch die Unternehmensmodellierung erfasst und
werden durch System-Kataloge erfasst (Data Dictionary).
- Operative Systeme sind i. d. R. nicht zur Informationsbeschaffung
geeignet, da wünschenswerte Informationen erst durch
Verbindung vieler Einzeldaten entstehen. Zudem liegen
Insellösungen in den Anwendungen vor.
- Lösung durch Kombination der Vor- und Nachteile:
Data-Warehouse.
146
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.5. Data Warehouse
Eigenschaft
147
Transaktionssysteme
Analysesysteme
Anzahl gleichzeitiger Benutzer
bis zu mehreren Tausend
zweistelliger Bereich
Antwortzeiten
Millisekunden
Sekunden bis Minuten
Zugriffsfrequenz
hoch
niedrig bis mittel
Datenvolumen pro Zugriff
niedrig
hoch
Änderungen des
Datenbestandes
laufend
durch definierte Updates
Aktualität der Daten
hoch
durch Updateintervall bestimmt
Datenstrukturierung
detailliert
verdichtet
Kritische Faktoren
Performance,
Antwortzeitverhalten,
Ausfallssicherheit
Datenbankgröße, strukturelle
Änderungen, Datenqualität
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.5. Data Warehouse
ƒ Ziel: Effiziente Bereitstellung (aktueller) qualitativ hochwertiger
Daten.
ƒ Verbesserung von Informationen und Datenqualität
ƒ Steigerung der Endbenutzerproduktivität (bspw. im Vertrieb)
148
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.5. Data Warehouse
149
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.5. Data Warehouse Ö Anforderungen
ƒ Themenorientiert
ƒ Integriert
Daten werden in normierter Form angelegt.
ƒ Zeitabbildend
Daten können über die verschiedensten Zeitpunkte abgerufen
werden. Bspw. kann heute (2.12.2003) der Zustand der Daten
am 13.7.1999 abgerufen werden.
ƒ Archivfunktion
Daten werden über einen längeren Zeitraum gespeichert (5-10
Jahre).
150
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.5. Data Warehouse - Datenarten
ƒ Detaillierte Daten (Aus dem operativen System mit Time Stamp
(Zeitstempel) übernommen)
ƒ Aggregierte Daten, die direkt aus dem operativen System
abgeleitet werden.
ƒ Externe Daten
ƒ Historische Daten aus zurückliegenden Zeiträumen
ƒ Operative Daten (per Definition nicht enthalten, aber es macht
bei einigen Daten keinen Sinn, diese mir einem Time Stamp zu
übernehmen Æ Kundenstammdaten bspw.)
151
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.5. Data Warehouse - Datenarten
ƒ Beispiel für interne Daten:
— Kundenstammdaten
— Materialflussdaten
— Transaktionsdaten
ƒ Beispiel für externe Daten:
— Konkurrenzdaten (Produkte, Service, Preise)
— Wirtschaftsdaten (Bspw. Devisenkurse)
— Industriedaten (Handelsinformationen)
— Kreditdaten (aktuelle Zinssätze)
— Warendaten (Rohstoffpreise)
— Meteorologische Daten (Wetterbedingungen wie
Temperaturen oder Winde)
152
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.5. Data Warehouse - Data Warehouse Ansätze
ƒ virtuelles DW
ƒ zentrales DW
ƒ Data Mart
153
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.5. Data Warehouse - Data Warehouse Ansätze
ƒ virtuelles DW
— Keine eigene redundante Datenhaltung
— Direkter Zugriff auf operativen Datenbestand
— Middleware muss alle Meta-Daten kennen
— Vorteile:
• Schnelle Realisierbarkeit.
• Aktualität.
— Nachteile:
•
•
•
•
•
•
•
•
154
Schlechte Performance.
Keine Optimierung der Abfragen möglich.
Beeinflussen des operativen Betriebs.
Hohe Komplexität der Metadaten.
Weiterentwicklung schwierig.
Keine Zwischenspeicherung der aggregierten Daten möglich.
Keine Aufzeichnung der historischen Daten möglich.
externe Daten sind schwer zugänglich!.
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.5. Data Warehouse - Data Warehouse Ansätze
ƒ virtuelles DW
ƒ zentrales DW
— redundante Datenbasis (vom operativen System entkoppelt)
— zentrales Data Warehouse Management System
— Data Warehouse heute in der Regel Zwischenschicht
zwischen operativen Datenbanken und Endbenutzer.
155
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.5. Data Warehouse - Data Warehouse Ansätze
ƒ virtuelles DW
ƒ zentrales DW
— Vorteile:
•
•
•
•
•
Performance-Gewinn
einheitliche Meta-Daten
einheitliches Sichtenmanagement
Aufzeichnung historischer und aggregierter Daten
Integration externer Daten
— Nachteil:
• aufwendige Einführung (Kosten)
• Probleme der Konsolidierung der Daten
156
19. März 2007
Dipl.-Ök. Patrick Bartels
Datenorganisation | Veranstaltung 6
8.5. Data Warehouse - Data Warehouse Ansätze
ƒ virtuelles DW
ƒ zentrales DW
ƒ Data Mart
— Sind eine Art „Mini-Data Warehouse“
157
19. März 2007
Dipl.-Ök. Patrick Bartels