1
PrologProlog
Kapitel 2:
Dienstfunktionalität und Dienstmerkmale
2
Kapitel 2.1
Dienste in verteilten Systemen
3
Informatik-prozess 1
Ressourcen-Verwalter 1
Prozessschritt 1
Leistungsprozesse und Ressourcen (1)
Ressourcen-Verwalter 2
Ressourcen-Verwalter 3
Ressourcen-Verwalter 4
Prozessschritt 2 Prozessschritt 3 Prozessschritt 4
Prozessschritt 4Prozessschritt 3Prozessschritt 2Prozessschritt 1 Prozessschritt 5
Informatik-prozess 2
Dienst
Dienstnehmer
Dienst-geber
Dienst: Nach Form und Inhalt wohl definiertes Leistungsangebot eines Ressourcen-Verwalters, das Gegenstand einer Dienstleistungsvereinbarung ist.
Leistungs-prozess
4
Informatik-prozess 1
Ressourcen-Verwalter 1
Prozessschritt 1
Leistungsprozesse und Ressourcen (2)
Ressourcen-Verwalter 2
Ressourcen-Verwalter 3
Ressourcen-Verwalter 4
Prozessschritt 2 Prozessschritt 3 Prozessschritt 4
Prozessschritt 4Prozessschritt 3Prozessschritt 2Prozessschritt 1 Prozessschritt 5
Informatik-prozess 2
Dienstnehmer-Dienstgeber-Verhältnis
Dienstnehmer-Dienstnehmer-Verhältnis
Dienstgeber-Dienstgeber-Verhältnis
Diese Vorlesung!
Nur Vorkehrungen des Dienstnehmers!
5
Dienstfunktionalität und Dienstmerkmale (1)
Algorithmen und Datenstrukturen
Dienst
DienstmerkmaleBedeutungstreueDauerhaftigkeitAllgegenwartLeistungSkalierbarkeitRobustheitSicherheit
Ressourcen-Verwalter
Dienstfunktionalität
Sammlung von Funktionen, die in einem erkennbarenZusammenhang stehen, abereinzeln abgerufen werden können
Von der Dienstfunktionalität in ihrer Gesamtheit zu beachtende Randbedingungen
6
Dienstfunktionalität und Dienstmerkmale (2)
Algorithmen und Datenstrukturen
Dienst
DienstmerkmaleBedeutungstreue
Dauerhaftigkeit
Allgegenwart
Leistung
Skalierbarkeit
Robustheit
Sicherheit
Ressourcen-Verwalter
Dienstfunktionalität
Gemeinsames Verständnis der Datenbei allen am Austausch beteiligten Partnern
Zugriff auf Daten nach ihrer Entstehung zu jeder Zeit in der Zukunft
Datenzugriff zu jeder Zeit von jedem Ort
•Effizienz: Minimaler Verbrauch innerer Ressourcen•Verfügbarkeit: Rechtzeitiger Zugang zu den Ressourcen
Stetes Wachstum ohne Einbußen bei Funktionalität und Leistung
Zuverlässiges Erbringen der Dienste unter Störungen und Fehlern
Keine Verluste, Störungen, Ausfälle durch unbedachte oder böswillige Eingriffe
X
X
7
Kapitel 2.2
Datenbankfunktionalität
8
Dienstfunktionalität der Datenverwaltung
Dienstfunktionen für dasEntgegennehmen,Abspeichern,Ändern,Löschen,Auswählen,Bereitstellenvon Daten.
Dienstfunktionen besitzen domänenneutralen Charakter Wirtschaftlichkeitsgründe diktieren „breitbandige“
Einsatzfähigkeit Generisches Vorgehen.
Algorithmen und Datenstrukturen
Dienst
Dienstfunktionalität
9
Datenmodell
Aspekte der Dienstfunktionalität Beschreibung der zulässigen Datenbasiszustände
Generisch: Mittel zur domänenneutralen Strukturierung der Datenbasis
Beschreibung der zulässigen Zustandsübergänge, im wesentlichen in Form der anwendbaren Operatoren
Generische Operatoren
=: Datenmodell
10
Zustände einer Datenbasis (1)
Grundgedanke: Datentyp = Menge zulässiger Zustände Typ: Menge von Objekten gleicher mathematischer Struktur. Ausprägung (Instanz): Element eines Typs. Polymorphes Typsystem: Menge von Typen, i.d.R.
beschrieben durch: die Festlegung gewisser atomarer Typen, z.B.
» int = Menge der ganzen Zahlen,» bool = {true, false},» date = Menge der Daten des Gregorianischen Kalenders;
die Angabe von Typkonstruktoren, mit denen Typen zu neuen Typen kombiniert werden können, z.B.
» record(t1,t2,...,tn): Menge der Tupel mit Komponenten aus t1,t2,...,tn,» set(t) = Menge der Mengen mit Elementen aus t,» list(t) = Menge der Listen mit Elementen aus t;
und Vorschriften zu deren Verwendung: Polymorphe Typen.
11Zustände einer Datenbasis (2)
Polymorphe Typen: Regeln, nach denen neue Zustände aus vorhandenen zusammengestellt werden können. Diese Regeln legen zu Grunde
Typkonstruktoren einschränkende generische Bedingungen: Polymorphe
Konsistenzbedingung
12Zustände einer Datenbasis (3)
Um die Skalierbarkeit zu erfassen, bauen die polymorphen Typsysteme von Datenbanksystemen grundsätzlich auf Mengen von Datensätzen auf:
Atomare Typen int, float, string, time
PolymorpheTypendatensatz ::= [sel:atomarerTyp, ..., sel:atomarerTyp]
menge ::= {datensatz}Typvariable
record-Typkonstruktor
set-Typkonstruktor
Selektor (Feldname)
Konsistenzbedingung: Jeder datensatz in einer menge besitzt einen Schlüssel, d.h. einen Wert, der ihn eindeutig unter allen Datensätzen der Menge identifiziert. Also existiert Funktion key: menge atomarerTyp datensatz
13
Zustandsübergänge mittels Operatoren
Operatoren: mathematische Funktionen, die auf Elemente von Typen angewendet werden können, z.B. Gleichheitstest (x y): anwendbar auf beliebige Typen Anordnung (x y): anwendbar auf Zahlen, Daten,
Zeichenketten,... arithmetische Operationen (, , , ): anwendbar auf Zahlen logische Operationen (and, or, not): anwendbar auf
boolesche Werte Mengenoperationen (, , ): anwendbar auf Typen, die
durch Anwendung des set-Typkonstruktors entstanden sind Monomorphe Operatoren können nur auf Elemente eines
Typs angewendet werden (z.B. not). Polymorphe Operatoren können auf Elemente
unterschiedlicher (wenn auch nicht immer aller) Typen angewendet werden (z.B. , oder ).
14Zustandsübergänge einer Datenbasis
Ein polymorphes Typsystem hat zwingend polymorphe Operatoren Forderung nach generischen Operatoren ist erfüllt.
Zustandsübergänge: Abspeichern, Löschen von Ausprägungen von Typen in Ausprägungen von Mengentypen.
Auswählen und Bereitstellen von Elementen der Datenbasis lässt sich als der identische Zustandsübergang erfassen.
Erweiterung unseres Beispiels:
Polymorphe Operatoren union: menge menge mengeintersect: menge menge mengeinsert: menge datensatz mengedeleteByKey: menge atomarerTyp mengefindByKey: menge atomarerTyp datensatz
15
Kapitel 2.3
Zustandsbezogene Dienstmerkmale in Datenbanksystemen
16
Bedeutungstreue (1)
Daten müssen interpretierbar sein (Information) Daten müssen bei allen am Austausch beteiligten
Partnern dieselbe Information besitzen Interpretation muss über die Zeit dieselbe bleiben Konventionen zur Interpretation begleiten die Daten
Aufgabe des Datenverwaltungssystems
Algorithmen und Datenstrukturen
Dienst
DienstmerkmaleBedeutungstreueDauerhaftigkeitAllgegenwartLeistungSkalierbarkeitRobustheitSicherheit
Dienstfunktionalität
17Bedeutungstreue (2)
Interpretation erfolgt in einer auf bestimmte Aspekte beschränkten Realwelt, der Miniwelt.
Informationen sind somit gedankliche Abstraktionen (Modelle) der Miniwelt.
Daten sind daher Repräsentationen von Modellen.
Eine Datenbasis ist bedeutungstreu, wenn ihre Elemente Modelle einer gegebenen Miniwelt repräsentieren (Datenbasiskonsistenz).
Datenbasis beschreibt Zustand der Miniwelt durch mathematische Strukturen (Mengen, Tupel, Funktionen, ...).
Datenbasis ist damit formales Modell der Miniwelt.
18Datenbasisschema (1)
Vorgehen: Einsetzen konkreter (aus dem Modell der Miniwelt gewonnener) Typen und Bezeichner für die Typvariablen bzw. Selektoren in den polymorphen Typen, polymorphen Operatoren und polymorphen Konsistenzbedingungen.
Das polymorphe Typsystem wird zu einem monomorphen Typsystem instantiiert.
Erst jetzt ist die Datenbasis interpretierbar. Datenbasistyp: Ergebnis der Konkretisierung. Datenbasisschema (kurz: Schema): Beschreibung eines
Datenbasistyps Folge: Durchgesetzt werden als legitim alle Zustände, die
durch Ausführen der Operatoren unter Interpretation des Schemas erreicht werden können: Schemakonsistenz.
Insbesondere: Erst jetzt kann eine Datenbasis erzeugt werden.
19
Beispiel Realwelt: Lagerverwaltung
Reale, anfassbare Gegenstände: Lagereinheiten mit Identnummer, Lagereinheitart, Art und
Stückzahl der verpackten Artikel, Gewicht, Aufdruck, Preis, Aufstellung;
Lagerhilfsmittel mit Identnummer, Art, Gewicht, Lagerort, Beschaffungsdatum, Beschaffungspreis;
Gedankliche, in ihren Auswirkungen beobachtbare Phänomene: Artikelart mit Identnummer, Name, Lieferdatum, Menge,
Gewicht, Lieferant;
20
Miniwelt Lagerverwaltung
Reale, anfassbare Gegenstände: Lagereinheiten mit Identnummer, Lagereinheitart, Art und
Stückzahl der verpackten Artikel, Gewicht, Aufdruck, Preis, Aufstellung;
Lagerhilfsmittel mit Identnummer, Art , Gewicht, Lagerort, Beschaffungsdatum, Beschaffungspreis;
Gedankliche, in ihren Auswirkungen beobachtbare Phänomene: Artikelart mit Identnummer, Name, Lieferdatum, Menge,
Gewicht, Lieferant;
21Beispiel für Datenbasisschema
Datenbasistyp Lagerverwaltungsdatenbasis
Typ ArtikelArt ::= datensatz [ANr: string, AName: string, Menge: int,Lieferant: string, Gewicht: float ]
Typ Lagereinheit ::= datensatz [LeNr: string, LeaNr: string, ANr: string, Stückzahl: int, Gewicht: float, LhNr: string ]
Typ Lagerhilfsmittel ::= datensatz [LhNr: string, LhaNr: string, Gewicht: float, LoNr: string ]
Typ ArtikelArten ::= menge {ArtikelArt} key ANrTyp Lagereinheiten ::= menge {Lagereinheit} key
LeNrTyp DieLagerhilfsmittel ::= menge
{Lagerhilfsmittel} key LhNr
Zugrundeliegender polymorpher Typ
(Schablone for monomorphe Typen)
monomorphe Konsistenzbedingung mit polymorpher Grundlage
Monomorpher Typ
22Weitere denkbare Konsistenzbedingungen
Datenbasistyp Lagerverwaltungsdatenbasis
Typ ArtikelArt ::= datensatz [ANr: string, AName: string, Menge: int,Lieferant: string, Gewicht: float ]
Typ Lagereinheit ::= datensatz [LeNr: string, LeaNr: string, ANr: string, Stückzahl: int, Gewicht: float, LhNr: string ]
Typ Lagerhilfsmittel ::= datensatz [LhNr: string, LhaNr: string, Gewicht: float, LoNr: string ]
Typ ArtikelArten ::= menge {ArtikelArt} key ANrTyp Lagereinheiten ::= menge {Lagereinheit} key
LeNrTyp DieLagerhilfsmittel ::= menge
{Lagerhilfsmittel} key LhNr
ANr AName
0 < Gewicht < 2000
ANr-Wert unter Lagereinheit kommt als
Wert in ArtikelArt vor
Gewicht = Σ Gewichte der aufgestellten LagereinheitenBedürfen ebenfalls einer polymorphen Grundlage!
23
Beispiel: Lagerverwaltung-Datenbasis
ArtikelArt ANr AName Menge Lieferant Gewicht A-001 Anlasser 1 Bosch 2.00 A-002 Kolben 1 Mahle 0.05 A-003 Kolbenringe 50 Mahle 0.10 A-004 Kurbelwelle 1 Mahle 1.00 A-005 Nockenwelle 1 Mahle 0.50 A-006 Ölwanne 1 Erzberg 1.50 A-007 Pleuel 1 Mahle 0.10 A-008 Ventile 20 Mahle 0.40 A-009 Ventile 20 Bosch 0.40 A-010 Ventilfedern 50 Pohlmann 0.50 A-011 Zündkerzen 20 Bosch 1.00 A-012 Zündkerzen 20 Osram 1.00 A-013 Zündkerzenkabel 10 Siemens 0.80 A-014 Zündkerzenstecker 10 Siemens 0.80 A-015 Zündspule 5 Siemens 2.50 A-016 Zündverteiler 5 Bosch 0.50 A-017 Zylinderdichtung 10 Erzberg 1.00 A-018 Zylinderdichtung 10 Pohlmann 1.00 A-019 Zylinderkopf 1 Mahle 3.00 A-020 Zylinderkurbelgehäuse 1 Erzberg 6.00
24Datenbasisschema (2)
Vor dem Anlegen einer Datenbasis muss dem Verwaltungssystem noch mitgeteilt werden, welche Zustandsräume unter eigenem Namen angelegt und wie sie benannt werden sollen.
Wie in einer Programmiersprache: Definieren von Variablen, nachdem zuvor die benötigten Typen deklariert wurden.
Für eine Datenbasis: Definieren von Wurzelobjekten, die man als persistente Variablen auffassen kann.
Root alleArtikelArten : ArtikelArten
Root alleLagereinheiten : Lagereinheiten
Root alleLagerhilfsmittel : DieLagerhilfsmittel
25
Konsistente Zustände (1)
Zusammenfassung: Voraussetzung für den Betrieb: Vorliegen eines Schemas,
da nur so die Wirkung der Operatoren (= Dienstfunktionen) definiert ist.
Ein Datenverwaltungssystem gewährleistet (Schema-) Konsistenz, wenn seine Dienstfunktionen stets einen (schema-)konsistenten Zustand seiner Datenbasis wieder in einen (schema-)konsistenten Zustand überführen. Gehorcht die Datenbasis einer wie immer gearteten
Schemakonsistenz vor Ausführen einer Dienstfunktion, so gehorcht sie ihr auch zum Abschluss der Ausführung.
26
Konsistente Zustände (2)
Idealfall: volle, aktuelle Übereinstimmung von Datenbasis und MiniweltDatenbasiskonsistenz
min 100%
Legitime Zustände durch Ausführen der Operatoren mit Interpretation des SchemasSchemakonsistenz
Bedeutungstreue
Datenmodell legt Regeln fest, nach denen Zustandsräume konstruiert werden können.Schema legt bestimmten Zustandsraum fest.
Monomorphe Konsistenz-bedingungen
27
Konsistente Zustände (3)
Idealfall: volle, aktuelle Übereinstimmung von Datenbasis und MiniweltDatenbasiskonsistenz
min 100%
Legitime Zustände durch Ausführen der Operatoren mit Interpretation des SchemasSchemakonsistenz
Bedeutungstreue
Datenmodell legt Regeln fest, nach denen Zustandsräume konstruiert werden können.Schema legt bestimmten Zustandsraum fest.
Monomorphe Konsistenz-bedingungen
Ausführung von Transaktionsprozeduren
Transaktionsprozedur: Dienstprozedur als frei definierte Abfolge von Operationen, die Zustandsübergänge einschränkt: Prozedurale Kontrolle der Konsistenz
28
Transaktionsprozeduren (1)
Die Operatoren bleiben polymorph, entwickeln aber monomorphe Wirkung durch Interpretation des Schemas.
Monomorph definieren sie die schemakonsistenten Zustandsübergänge.
Erwünscht: Weitere Einschränkung von Zustandsübergängen in Richtung Datenbasiskonsistenz. Dies ist nur möglich, indem man erst Abfolgen von Operationen für konsistent erklärt.
Transaktionsprozedur: Dienfunktion als frei definierte Abfolge von Operationen mit konsistentem Ergebnis.
29
Beispiel: Wird eine ArtikelArt nicht mehr geführt, so ist deren
Datensatz mit der entsprechenden ANr aus der Menge der Artikelarten zu entfernen, gleichzeitig sind alle Lagereinheit-Datensätze, die sich auf diese ANr beziehen, zu entfernen (in der Realwelt sind die Artikel abzustoßen).
Beachte: Die Bedeutungstreue ist erst zu Ende der Prozedur sichergestellt ist, während der Ausführung, also am Ende einzelner Operationen, muss sie nicht zutreffen.
Transaktionsprozeduren (2)
30
Zustandsübergänge
Folgerung: Um zu verhindern, dass Operatoren unter Missachtung
ihres Kontextes ausgeführt werden und damit zu wenig Konsistenz erreicht wird: Als Dienstfunktionen sind ausschließlich Transaktionsprozeduren zulässig. Die Bedeutungstreue ist an das Ende der Prozedur gebunden,
während der Ausführung, also am Ende einzelner Operationen, muss sie nicht zutreffen.
Daher dürfen Konsistenzbedingungen erst am Ende durchgesetzt werden, die Operatoren sind von deren Durchsetzung frei zu halten.
Transaktionsprozeduren können vorab oder spontan definiert werden.
Konsistenz: Grad an Bedeutungstreue einer Datenbasis
31
Bedeutungstreue: Zusammenfassung
ElementareZustandsräume
Konstruktoren fürZustandsräume
Operatoren
Datenmodell
KonkreterZustandsraum
Konkrete Konsistenz-bedingungen
DB-Schema
Konkrete Zustände(schemaverträglich )
Transaktionsproze-duren (einzelne oder Folge von Operatn.)
Datenbasis
GrundsätzlicheOrganisation des
DBMS
Organisation der DBfür eine bestimmte
Miniwelt
Beschreibung einesbestimmten Zustands
der Miniwelt
DB-Entwurf DB-Betrieb
32Dienstnehmer-Dienstgeber-Protokolle
1. Datendefinitionssprache (DDL; engl.: data definition language) zur Schemaformulierung.
2. Datenmanipulationssprache (DML; engl.: data manipulation language), bestimmt durch die Operatoren des Datenmodells zum nachfolgenden Umgang mit der Datenbasis:- Eigenständige Anfragesprachen (engl.: query languages) für den Dialog von Teilnehmer und Datenhaltungssystem.- In Programmiersprache (Wirtssprache, engl.: host language) eingebettete Anfragesprache für die Weiterverarbeitung der ausgewählten Daten durch Anwendungsprogramme. - Datenbankprogrammiersprachen für die vollständige Integration des Datenmodells einschließlich DDL in eine Programmiersprache.
3. Regeln zur sprachlichen Formulierung von Transaktionsprozeduren: Beginn und Abschluss der Ausführung, Rückkehr zum Zustand zu Beginn der Ausführung.
33
Dauerhaftigkeit (1)
Verbringen der Daten auf nichtflüchtiges Speichermedium genügt nicht.
Dauerhafte Daten müssen zudem konsistent sein. Das sind sie, wenn sie von einer erfolgreich ausgeführten
Transaktionsprozedur stammen.
Dauerhaftigkeit ist die andauernde Nichtflüchtigkeit gewisser, in jedem Fall konsistenter Datenbasiszustände (Unverletzlichkeit der Datenbasis).
Algorithmen und Datenstrukturen
Dienst
DienstmerkmaleBedeutungstreueDauerhaftigkeitAllgegenwartLeistungSkalierbarkeitRobustheitSicherheit
Dienstfunktionalität
34Dauerhaftigkeit (2)
Unbegrenzt lange Speicherung der Daten verschärft die Forderung nach Konsistenz, denn es steigt die Wahrscheinlichkeit, dass durch Störungen oder Fehler die Daten in ihrem Inhaltsbezug korrumpiert werden.
Beispiele: Ausfall von Hintergrundspeichern, Datenträgern oder dem Rechner; externe Ereignisse wie Feuer, Wasser, Klima, Alterung mit physischer Vernichtung der Datenbasis.
35
Kapitel 2.4
Zustandsübergangsbezogene Dienstmerkmale in Datenbanksystemen
36
Durchsetzen von Konsistenz
Informatik-prozess 1
Ressourcen-Verwalter 1
Prozessschritt 1
Ressourcen-Verwalter 2
Ressourcen-Verwalter 3
Ressourcen-Verwalter 4
Prozessschritt 2 Prozessschritt 3 Prozessschritt 4
Prozessschritt 4Prozessschritt 3Prozessschritt 2Prozessschritt 1 Prozessschritt 5
Informatik-prozess 2
Datenbasis-transaktion
Anwendungstransaktion
Ausführung einer Transaktionsprozedur
Konsistente Ausführung eines LeistungsprozessesAusführung einer
Transaktionsprozedur
37
Robustheit 1: Persistenz
Erreichen eines konsistenten nichtflüchtigen Zustands: Persistenz
Algorithmen und Datenstrukturen
Dienst
DienstmerkmaleBedeutungstreueDauerhaftigkeitAllgegenwartLeistungSkalierbarkeitRobustheitSicherheit
Dienstfunktionalität
38
Persistenz
Folgerung: Eine Transaktion strebt stets einen persistenten Zustand an.
Da eine Transaktion ein persistentes Ergebnis bewirkt, ist der Abschluss einer Transaktion ein Persistenz-Ereignis.
Die Transaktionsprozedur ist so zu entwerfen, dass man sie für beendet erklärt genau dann, wenn ihre Ergebnisse nicht mehr verloren gehen dürfen.
» Wann ein persistenter Zustand vorliegt, muss also ausdrücklich dem Datenverwaltungssystem bekannt gemacht werden.
Somit: Transaktionsabschluss bewirkt Eintritt in die Dauerhaftigkeit.
Garantie: Effekte von abgeschlossenen Zustandsübergängen gehen nicht mehr durch Störungen verloren.
39
Robustheit 2: Resistenz
Wahrung von Persistenz (und damit auch Konsistenz) auch unter dem Einfluss von Störungen: Resistenz
Störung des Dienstnehmer-Dienstgeber-Verhältnisses: Fehler-Resistenz.
Störung des Dienstnehmer-Dienstnehmer-Verhältnisses: Konflikt-Resistenz.
Algorithmen und Datenstrukturen
Dienst
DienstmerkmaleBedeutungstreueDauerhaftigkeitAllgegenwartLeistungSkalierbarkeitRobustheitSicherheit
Dienstfunktionalität
40
Fehler-Resistenz (1)
Fehler-Resistenz: Angeforderter Zustandsübergang wird entweder wie verlangt durchgeführt
So lange es zu keinen Störungen kommt, wird die Datenbasis einfach fortentwickelt.
oder wenn Zustandsübergang wegen Störung nicht abgeschlossen werden kann, strebt Datenbasis einen anderen persistenten (und somit konsistenten) Zustand an.
Beispiel: In einer Transaktion wird ein insert-Operator gezwungen, gegen die Schlüsselbedingung zu verstoßen.
Verbreitet: Kommt eine Transaktion nicht zum Abschluss, so ist der jüngste persistente Zustand der Zustand unmittelbar vor Ausführung der Transaktion. Man wird daher diesen Zustand wieder herstellen.
Alternativ: Korrekturaktion.
41Fehler-Resistenz (2)
Beispiele für Störungen: Fehlerhafte Eingaben; Programmierfehler;
unbeabsichtigte Wechselwirkung von Dienstleistungen für unterschiedliche Dienstnehmer; Programmfehler in der Datenverwaltungssoftware; Ausfall von Hintergrundspeichern, Datenträgern oder dem Rechner.
42
Beispiel-Transaktion
Gewünschter Zustandsübergang: Ausmusterung eines Artikels.
Transaktionsprozedur: Entferne zugehörigen Datensatz aus Tabelle ArtikelArt. Ersetze in Tabelle Lagereinheit alle Vorkommen der alten ANr durch
ANr des Ersatzartikels.
Beachte: Datenbasis-Zustand ist zwischen Schritt 1 und 2 inkonsistent, davor und danach konsistent.
Resistenz garantiert, dass bei Störung entweder Zustand vor Schritt 1 oder nach Schritt 2 erreicht wird.
Persistenz garantiert, dass nach Abschluss von Schritt 2 Ergebnis nicht mehr verloren gehen kann.
43
Leistungs-prozess 1
Ressourcen-Verwalter 1
Prozessschritt 1
Resistentes Dienstnehmer-Dienstnehmer-Verhältnis
Ressourcen-Verwalter 2
Ressourcen-Verwalter 3
Ressourcen-Verwalter 4
Prozessschritt 2 Prozessschritt 3 Prozessschritt 4
Prozessschritt 4Prozessschritt 3Prozessschritt 2Prozessschritt 1 Prozessschritt 5
Leistungs-prozess 2
Dienst
Dienstnehmer
Dienst-geber
DienstfunktionalitätKonsistenzPersistenzFehler-Resistenz
Störfaktor für die Konsistenz: Bemühen sich mehrere Dienstnehmer-Transaktionen zur selben Zeit um dieselbe Ressource, so kann es zu einer unerwünschten Wechselwirkung zwischen ihnen kommen (Konflikt).
Konkurrenz
44Konflikt-Resistenz
Konfliktverhalten von Transaktionen durch Konkurrenz um gemeinsame Daten (engl.: concurrency für Nebenläufigkeit).
Gefordert: Resistenz gegen Konflikte: Konflikt-Resistenz. Benötigt: Protokoll, das Konflikte zwischen nebenläufigen
Dienstnehmer-Transaktionen eines Datenverwaltungssystems unterbindet (Synchronisations-Protokoll).
Korrektheitskriterium: Wahrung der Konsistenz durch: Konkurrierende Datenbasistransaktionen sind dann korrekt synchronisiert, wenn jede so abläuft als ob sie ohne Konkurrenz wäre, insbesondere also dem Dienstnehmer keinen inkonsistenten Datenbasiszustand präsentiert und bei Abschluss einen persistenten Datenbasiszustand erreicht.
45
Transaktionen
Transaktionsbegriff fasst Konsistenz, Persistenz und Resistenz zusammen:
Transaktion: resistente Ausführung eines konsistenten Zustandsübergangs (Operator oder Transaktionsprozedur) mit Persistenz des Endzustands.
46
Skalierbarkeit und Leistung (1)
Enge Wechselwirkung zwischen Skalierbarkeit und Leistung
Daher gemeinsame Betrachtung: Performanz
Algorithmen und Datenstrukturen
Dienst
DienstmerkmaleBedeutungstreueDauerhaftigkeitAllgegenwartLeistungSkalierbarkeitRobustheitSicherheit
Dienstfunktionalität
47
Skalierbarkeit und Leistung (2)
Aspekte der Leistung: Effizienz: Möglichst geringer Ressourcenverbrauch durch die
Dienste. Verfügbarkeit: Bedarfsaktueller Zugang zu den Ressourcen.
Aspekte der Skalierbarkeit: Wachstum der Datenbasis Wachstum der Transaktionslast
Effizienz
Verfügbarkeit
Skalierbarkeit
48
Kapitel 2.5
Datenbanksysteme
49
Typsystem +polymorphe Operatoren
DienstfunktionalitätDatenmodell
Dauerhaftigkeit erfolgreicher Zustandsübergänge
Mengenkonstrukt im Typsystem,effiziente Datenstrukturen und Operator-Algorithmen, Verteilung
Dienstfunktionalität und Dienstmerkmale
Algorithmen und Datenstrukturen
DienstDienstmerkmaleBedeutungstreue KonsistenzDauerhaftigkeitLeistung |PerformanzSkalierbarkeit |Robustheit Persistenz/Resistenz
Schema = konkrete Typen + Konsistenzbedingungen,Datenbasis = konkrete Typausprägungen durch Transaktionen
Wechselwirkungsfreie Ganz-oder-gar-nicht-Abwicklung von Zustandsübergängen
50Standardisierte Datenmodelle
Feststellung: Ein Datenverwaltungssystem realisiert ein einziges Datenmodell.
Wirtschaftlichkeitsaspekte: DBMS sind für Anbieter und Anwender extrem hohe
Investitionen. Zudem müssen die Datenbestände jederzeit
wiederverwendbar und austauschbar sein.
Folgerung: Einführung standardisierter Datenmodelle. Anwendung muss sich für eines dieser Datenmodelle
entscheiden.
51Bewertungskriterien für Datenmodelle (1)
Strukturelle Mächtigkeit Maß für die Anzahl unterschiedlicher polymorpher Typen
und damit für die Vielfalt der Strukturierungsmöglichkeiten. Z.B. Mengenmodell: Es gibt Datensätze und Mengen als
die zwei polymorphen Typen.
Strukturelle Orthogonalität Maß für die Freizügigkeit, mit der sich die polymorphen
Typen kombinieren lassen. Z.B. Mengenmodell: Bescheidene Orthogonalität, denn
man kann lediglich atomare Werte zu Datensätzen und Datensätze zu Mengen kombinieren, aber beispielsweise Mengen nicht selbst wieder zu Untermengen von Mengen machen.
52Bewertungskriterien für Datenmodelle (2)
Operationelle Verknüpfbarkeit Maß für die Freizügigkeit, mit der sich die aus den
Typausdrücken hervorgegangenen Datenstrukturen durch Operatoren ineinander überführen lassen.
Z.B. Mengenmodell: Geringe Verknüpfbarkeit, denn die Operatoren sind nur auf Mengen definiert und Mengen können nur ineinander überführt werden.
Operationelle Generizität Position der Operatoren im Spektrum zwischen Polymorphie und
Monomorphie. Ein polymorpher Operator ist ausschließlich an einen
polymorphen Typ gebunden, also gleichermaßen auf alle daraus gewonnenen Typen anwendbar. Daher besitzt er weite Einsatzbreite, kann aber auf keine semantischen Feinheiten eingehen.
Dies kann umgekehrt ein typgebundener (monomorpher) Operator.
53Bewertungskriterien für Datenmodelle (3)
Graphische Darstellungen für Mächtigkeit und Orthogonalität
Charakteristika: Polymorphe Typen sind Knoten. X Y bedeutet, dass X Argument des Konstruktors von Y ist.
Menge Datensatz atomarer Wert
Graphische Darstellung für Verknüpfbarkeit
Charakteristika: Polymorphe Typen sind Knoten. Ein von X und Y ausgehender, zusammengeführter Pfeil nach Z besagt, dass
sich Z aus X und Y berechnet. Die Benennung der Operation steht neben dem Pfeil. Anmerkung: Illustration an einem veränderten Mengenmodell!
Menge Datensatz atomarer Wert
insert,delete
read
create
54
Kapitel 2.6
Diese Vorlesung
55
Datenverwaltungssystem
Datenbasis-Verwaltungssystem(Ressourcen-Verwalter)
Dienstnehmer
Datenverwaltungs-Schnittstelle(Dienstfunktionalität)
Dienstgeber
Datenbasis(Ressource)
DienstmerkmaleDiese Vorlesung
56
DienstfunktionalitätDatenmodell
Dienstfunktionalität und Dienstmerkmale
Algorithmen und Datenstrukturen
DienstDienstmerkmaleBedeutungstreue KonsistenzDauerhaftigkeitLeistung |PerformanzSkalierbarkeit |Robustheit Persistenz/Resistenz
Datenbank-einsatz
Datenbank-implementierung
Transaktions-verwaltung
57
Gliederung (1)
ElementareZustandsräume
Konstruktoren fürZustandsräume
Operatoren
Datenmodell
KonkreterZustandsraum
Konkrete Konsistenz-bedingungen
DB-Schema
Konkrete Zustände(schemaverträglich )
Transaktionsproze-duren (einzelne oder Folge von Operatn.)
Datenbasis
GrundsätzlicheOrganisation des
DBMS
Organisation der DBfür eine bestimmte
Miniwelt
Beschreibung einesbestimmten Zustands
der Miniwelt
DB-Entwurf DB-Betrieb
Teil I Teil II an Beispielen
Datenmodell Datenbasisschema Datenbasis
58
Gliederung (2)
Teil I: Datenmodelle Das relationale Modell Relationale Sprachen Objektorientierte Modelle Objektorientierte Sprachen Semistrukturierte Daten: XML Objektrelationale Modelle Transformation und Sichten Transaktionen
Teil II: Datenbankentwurf Struktur des Entwurfsprozesses Objektorientierter Entwurf (UML) Übersetzung auf logische Datenmodelle Relationentheorie und Normalisierung Sichtenerstellung und Konsolidierung