1 Prolog Kapitel 2: Dienstfunktionalität und Dienstmerkmale.

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)




Prozessschritt 2 Prozessschritt 3 Prozessschritt 4

Prozessschritt 4Prozessschritt 3Prozessschritt 2Prozessschritt 1 Prozessschritt 5


Dienst

Dienstnehmer

Dienst-geber

Dienst: Nach Form und Inhalt wohl definiertes Leistungsangebot eines Ressourcen-Verwalters, das Gegenstand einer Dienstleistungsvereinbarung ist.

Leistungs-prozess

4



Prozessschritt 1

Leistungsprozesse und Ressourcen (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)


Dienst

DienstmerkmaleBedeutungstreue

Dauerhaftigkeit

Allgegenwart

Leistung

Skalierbarkeit

Robustheit

Sicherheit

Ressourcen-Verwalter


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.


Dienst


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


Dienst



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


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


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


Dienst



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



Prozessschritt 1







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


Dienst



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.


Dienst



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


Prozessschritt 1

Resistentes Dienstnehmer-Dienstnehmer-Verhältnis






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


Dienst



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



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.


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.


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



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

1 Prolog Kapitel 2: Dienstfunktionalität und Dienstmerkmale.

Documents

Transcript of 1 Prolog Kapitel 2: Dienstfunktionalität und Dienstmerkmale.