Dienstfunktionalität und Dienstmerkmale Prolog Kapitel 2: Dienstfunktionalität und Dienstmerkmale

Dienste in verteilten Systemen Kapitel 2.1 Dienste in verteilten Systemen

Leistungsprozesse und Ressourcen (1) Informatik-prozess 1 Prozessschritt 1 Prozessschritt 2 Prozessschritt 3 Prozessschritt 4 Prozessschritt 5 Dienst Dienst- geber Ressourcen-Verwalter 1 Ressourcen-Verwalter 2 Ressourcen-Verwalter 3 Ressourcen-Verwalter 4 Prozessschritt 1 Prozessschritt 2 Prozessschritt 3 Prozessschritt 4 Informatik-prozess 2 Dienstnehmer Dienst: Nach Form und Inhalt wohl definiertes Leistungsangebot eines Ressourcen-Verwalters, das Gegenstand einer Dienstleistungsvereinbarung ist.

Leistungsprozesse und Ressourcen (2) Informatik-prozess 1 Prozessschritt 1 Prozessschritt 2 Prozessschritt 3 Prozessschritt 4 Prozessschritt 5 Ressourcen-Verwalter 1 Ressourcen-Verwalter 2 Ressourcen-Verwalter 3 Ressourcen-Verwalter 4 Prozessschritt 1 Prozessschritt 2 Prozessschritt 3 Prozessschritt 4 Informatik-prozess 2 Dienstnehmer-Dienstgeber-Verhältnis Diese Vorlesung! Dienstnehmer-Dienstnehmer-Verhältnis Nur Vorkehrungen des Dienstnehmers! Dienstgeber-Dienstgeber-Verhältnis

Dienstfunktionalität und Dienstmerkmale (1) Ressourcen-Verwalter Sammlung von Funktionen, die in einem erkennbaren Zusammenhang stehen, aber einzeln abgerufen werden können Von der Dienstfunktionalität in ihrer Gesamtheit zu beachtende Randbedingungen Dienstfunktionalität Dienstmerkmale Bedeutungstreue Dauerhaftigkeit Allgegenwart Leistung Skalierbarkeit Robustheit Sicherheit Dienst Algorithmen und Datenstrukturen

Dienstfunktionalität und Dienstmerkmale (2) Ressourcen-Verwalter Dienstmerkmale Bedeutungstreue Dauerhaftigkeit Allgegenwart Leistung Skalierbarkeit Robustheit Sicherheit Gemeinsames Verständnis der Daten bei allen am Austausch beteiligten Partnern Dienstfunktionalität Zugriff auf Daten nach ihrer Entstehung zu jeder Zeit in der Zukunft X Dienst Datenzugriff zu jeder Zeit von jedem Ort Algorithmen und Datenstrukturen 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 X Keine Verluste, Störungen, Ausfälle durch unbedachte oder böswillige Eingriffe

Datenbankfunktionalität Kapitel 2.2 Datenbankfunktionalität

Dienstfunktionalität der Datenverwaltung Dienstfunktionen für das Entgegennehmen, Abspeichern, Ändern, Löschen, Auswählen, Bereitstellen von Daten. Dienstfunktionalität Dienst Algorithmen und Datenstrukturen Dienstfunktionen besitzen domänenneutralen Charakter Wirtschaftlichkeitsgründe diktieren „breitbandige“ Einsatzfähigkeit  Generisches Vorgehen.

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

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.

Zustä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

Zustände einer Datenbasis (3) Um die Skalierbarkeit zu erfassen, bauen die polymorphen Typsysteme von Datenbanksystemen grundsätzlich auf Mengen von Datensätzen auf: record-Typkonstruktor Atomare Typen int, float, string, time PolymorpheTypen datensatz ::= [sel:atomarerTyp, ..., sel:atomarerTyp] menge ::= {datensatz} Selektor (Feldname) Typvariable set-Typkonstruktor 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

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 ).

Zustandsü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  menge intersect: menge  menge  menge insert: menge  datensatz  menge deleteByKey: menge  atomarerTyp  menge findByKey: menge  atomarerTyp  datensatz

Zustandsbezogene Dienstmerkmale in Datenbanksystemen Kapitel 2.3 Zustandsbezogene Dienstmerkmale in Datenbanksystemen

Algorithmen und Datenstrukturen Bedeutungstreue (1) Dienstfunktionalität Dienstmerkmale Bedeutungstreue Dauerhaftigkeit Allgegenwart Leistung Skalierbarkeit Robustheit Sicherheit Dienst Algorithmen und Datenstrukturen 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

Bedeutungstreue (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.

Datenbasisschema (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.

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;

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;

Beispiel für Datenbasisschema Zugrundeliegender polymorpher Typ (Schablone for monomorphe Typen) 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 ANr Typ Lagereinheiten ::= menge {Lagereinheit} key LeNr Typ DieLagerhilfsmittel ::= menge {Lagerhilfsmittel} key LhNr Monomorpher Typ monomorphe Konsistenzbedingung mit polymorpher Grundlage

Weitere denkbare Konsistenzbedingungen ANr  AName 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 ANr Typ Lagereinheiten ::= menge {Lagereinheit} key LeNr Typ DieLagerhilfsmittel ::= menge {Lagerhilfsmittel} key LhNr ANr-Wert unter Lagereinheit kommt als Wert in ArtikelArt vor Gewicht = Σ Gewichte der aufgestellten Lagereinheiten 0 < Gewicht < 2000 Bedürfen ebenfalls einer polymorphen Grundlage!

Beispiel: Lagerverwaltung-Datenbasis

Datenbasisschema (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

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.

Konsistente Zustände (2) min 100% Bedeutungstreue Monomorphe Konsistenz-bedingungen Legitime Zustände durch Ausführen der Operatoren mit Interpretation des Schemas Schemakonsistenz Idealfall: volle, aktuelle Übereinstimmung von Datenbasis und Miniwelt Datenbasiskonsistenz Datenmodell legt Regeln fest, nach denen Zustandsräume konstruiert werden können. Schema legt bestimmten Zustandsraum fest.

Konsistente Zustände (3) min 100% Bedeutungstreue Monomorphe Konsistenz-bedingungen Ausführung von Transaktionsprozeduren Legitime Zustände durch Ausführen der Operatoren mit Interpretation des Schemas Schemakonsistenz Idealfall: volle, aktuelle Übereinstimmung von Datenbasis und Miniwelt Datenbasiskonsistenz Transaktionsprozedur: Dienstprozedur als frei definierte Abfolge von Operationen, die Zustandsübergänge einschränkt: Prozedurale Kontrolle der Konsistenz Datenmodell legt Regeln fest, nach denen Zustandsräume konstruiert werden können. Schema legt bestimmten Zustandsraum fest.

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.

Transaktionsprozeduren (2) 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.

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

Bedeutungstreue: Zusammenfassung Elementare Zustandsräume Konstruktoren für Zustandsräume Operatoren Datenmodell Konkreter Zustandsraum Konkrete Konsistenz- bedingungen DB-Schema Datenbasis Konkrete Zustände (schemaverträglich ) Transaktionsproze-duren (einzelne oder Folge von Operatn.) DB-Entwurf DB-Betrieb Grundsätzliche Organisation des DBMS Organisation der DB für eine bestimmte Miniwelt Beschreibung eines bestimmten Zustands der Miniwelt

Dienstnehmer-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.

Algorithmen und Datenstrukturen Dauerhaftigkeit (1) Dienstfunktionalität Dienstmerkmale Bedeutungstreue Dauerhaftigkeit Allgegenwart Leistung Skalierbarkeit Robustheit Sicherheit Dienst Algorithmen und Datenstrukturen 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).

Dauerhaftigkeit (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.

Zustandsübergangsbezogene Dienstmerkmale in Datenbanksystemen Kapitel 2.4 Zustandsübergangsbezogene Dienstmerkmale in Datenbanksystemen

Durchsetzen von Konsistenz Anwendungstransaktion Informatik-prozess 1 Prozessschritt 1 Prozessschritt 2 Prozessschritt 3 Prozessschritt 4 Prozessschritt 5 Datenbasis-transaktion Ressourcen-Verwalter 1 Ressourcen-Verwalter 2 Ressourcen-Verwalter 3 Ressourcen-Verwalter 4 Prozessschritt 1 Prozessschritt 2 Prozessschritt 3 Prozessschritt 4 Informatik-prozess 2 Konsistente Ausführung eines Leistungsprozesses Ausführung einer Transaktionsprozedur Ausführung einer Transaktionsprozedur

Robustheit 1: Persistenz Dienstfunktionalität Dienstmerkmale Bedeutungstreue Dauerhaftigkeit Allgegenwart Leistung Skalierbarkeit Robustheit Sicherheit Dienst Algorithmen und Datenstrukturen Erreichen eines konsistenten nichtflüchtigen Zustands: Persistenz

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.

Robustheit 2: Resistenz Dienstfunktionalität Dienstmerkmale Bedeutungstreue Dauerhaftigkeit Allgegenwart Leistung Skalierbarkeit Robustheit Sicherheit Dienst Algorithmen und Datenstrukturen 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.

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.

Fehler-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.

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.

Resistentes Dienstnehmer-Dienstnehmer-Verhältnis Leistungs-prozess 1 Prozessschritt 1 Prozessschritt 2 Prozessschritt 3 Prozessschritt 4 Prozessschritt 5 Konkurrenz Dienst- geber Ressourcen-Verwalter 1 Ressourcen-Verwalter 2 Ressourcen-Verwalter 3 Ressourcen-Verwalter 4 Dienstfunktionalität Konsistenz Persistenz Fehler-Resistenz Dienst Prozessschritt 1 Prozessschritt 2 Prozessschritt 3 Prozessschritt 4 Leistungs-prozess 2 Dienstnehmer 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).

Konflikt-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.

Transaktionen Transaktionsbegriff fasst Konsistenz, Persistenz und Resistenz zusammen: Transaktion: resistente Ausführung eines konsistenten Zustandsübergangs (Operator oder Transaktionsprozedur) mit Persistenz des Endzustands.

Skalierbarkeit und Leistung (1) Dienstfunktionalität Dienstmerkmale Bedeutungstreue Dauerhaftigkeit Allgegenwart Leistung Skalierbarkeit Robustheit Sicherheit Dienst Algorithmen und Datenstrukturen Enge Wechselwirkung zwischen Skalierbarkeit und Leistung Daher gemeinsame Betrachtung: Performanz

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

Kapitel 2.5 Datenbanksysteme

Dienstfunktionalität und Dienstmerkmale Schema = konkrete Typen + Konsistenzbedingungen, Datenbasis = konkrete Typausprägungen durch Transaktionen Typsystem + polymorphe Operatoren Dauerhaftigkeit erfolgreicher Zustandsübergänge Dienstfunktionalität Datenmodell Dienstmerkmale Bedeutungstreue Konsistenz Dauerhaftigkeit Leistung |Performanz Skalierbarkeit | Robustheit Persistenz/Resistenz Dienst Algorithmen und Datenstrukturen Wechselwirkungsfreie Ganz-oder-gar-nicht-Abwicklung von Zustandsübergängen Mengenkonstrukt im Typsystem, effiziente Datenstrukturen und Operator-Algorithmen, Verteilung

Standardisierte 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.

Bewertungskriterien 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.

Bewertungskriterien 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.

Bewertungskriterien 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

Kapitel 2.6 Diese Vorlesung

Datenverwaltungssystem Dienstnehmer Diese Vorlesung Datenverwaltungs-Schnittstelle (Dienstfunktionalität) Dienstmerkmale Datenbasis-Verwaltungssystem (Ressourcen-Verwalter) Dienstgeber Datenbasis (Ressource)

Dienstfunktionalität und Dienstmerkmale Datenbank-einsatz Dienstfunktionalität Datenmodell Dienstmerkmale Bedeutungstreue Konsistenz Dauerhaftigkeit Leistung |Performanz Skalierbarkeit | Robustheit Persistenz/Resistenz Dienst Transaktions-verwaltung Algorithmen und Datenstrukturen Datenbank-implementierung

Gliederung (1) Datenmodell Datenbasisschema Datenbasis Teil I Teil II Elementare Zustandsräume Konstruktoren für Zustandsräume Operatoren Datenmodell Konkreter Zustandsraum Konkrete Konsistenz- bedingungen DB-Schema Datenbasis Konkrete Zustände (schemaverträglich ) Transaktionsproze-duren (einzelne oder Folge von Operatn.) DB-Entwurf DB-Betrieb Grundsätzliche Organisation des DBMS Organisation der DB für eine bestimmte Miniwelt Beschreibung eines bestimmten Zustands der Miniwelt Datenmodell Datenbasisschema Datenbasis Teil I Teil II an Beispielen

Gliederung (2) Teil I: Datenmodelle Teil II: Datenbankentwurf 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