K2 Anforderungen und Beschreibungsmodell Flashcards
GDB K2 Anforderungen und Beschreibungsmodell
Was ist ein Dateisystem?
Permanente Datenhaltung innerhalb von Betriebssystem-Dateien
Betriebssystem/Dateisystem bietet Funktionen für
- Erzeugen/Löschen von Dateien
- Zugriffsmöglichkeiten auf Blöcke/Sätze der Datei
- einfache Operationen zum Lesen/Ändern/Einfügen/Löschen von Sätzen
Probleme:
- Datenredundanz und Inkonsistenz
- Inflexibilität
- Mehrbenutzerbetrieb, Fehlerfälligkeit
- Integritätssicherung
- Missbrauch der Daten
- Verantwortlichkeit
GDB K2 Anforderungen und Beschreibungsmodell
Datenbank (DB) als Abbildung einer Miniwelt
- Vorgänge und Sachverhalte werden als gedankliche Abstraktionen (Modelle) der Miniwelt erfasst und als Daten (Repräsentationen von Modellen) in der Datenbank gespeichert
- Daten beziehen sich nur auf solche Aspekte der Miniwelt, die für die Zwecke der Anwendung relevant sind
- Eine DB ist integritätserhaltend (bedeutungstreu), wenn ihre Objekte Modelle einer gegebenen Miniwelt repräsentieren
GDB K2 Anforderungen und Beschreibungsmodell
Was ist ein Datenmodell?
Datenmodell (Typen, Operatoren, Konsistenzbedingungen) legt Regeln fest, nach denen die Objekte von DBs (für die Repräsentation beliebiger Miniwelten) erzeugt und verändert werden (Konstruktionsregeln für die Zustandsräume der Modelle einer Miniwelt)
GDB K2 Anforderungen und Beschreibungsmodell
Was ist ein DB-Schema?
DB-Schema legt die Ausprägungen der Objekte fest, welche die DB für eine bestimmte Miniwelt einnehmen kann (Zustandsraum der Modelle einer Miniwelt)
GDB K2 Anforderungen und Beschreibungsmodell
Was ist eine DB-Instanz?
DB-Instanz entspricht tatsächlicher (schema-konformer) Ausprägung einer Menge von Objekten (konkrete Zustände der Modelle einer Miniwelt)
GDB K2 Anforderungen und Beschreibungsmodell
Beschreibung und Handhabung der Daten
- Daten müssen interpretierbar sein
- sie müssen bei allen am Austausch beteiligten Partnern (Systemen, Komponenten) die Ableitung derselben Information erlauben
- Einsatzspektrum verlangt generische Vorgehensweise:
Beschreibung der zulässigen DB-Zustände
Beschreibung der zulässigen Zustandsübergänge (generische Operatoren)
GDB K2 Anforderungen und Beschreibungsmodell
Was ist ein API?
Anwendungsprogrammier-Schnittstelle (API)
Operatoren zur Definition von Objekttypen (Beschreibung der Objekte)
- DB-Schema: Welche Objekte sollen in der DB gespeichert werden?
Operatoren zum Aufsuchen und Verändern von Daten
- AW-Schnittstelle: Wie erzeugt, aktualisiert und findet man DB-Objekte?
Operatoren zur Definition von Integritätsbedingungen (Constraints)
- Sicherung der Qualität: Was ist ein akzeptabler DB-Zustand?
Operatoren zur Definition von Zugriffskontrollbedingungen
- Maßnahmen zum Datenschutz: Wer darf was?
GDB K2 Anforderungen und Beschreibungsmodell
Was sind die Anforderungen an ein DBS?
- Kontrolle über die operationalen Daten
- Leichte Handhabbarkeit der Daten
- Kontrolle der Datenintegrität
- Leistung und Skalierbarkeit
- Hoher Grad an Daten-Unabhängigkeit
GDB K2 Anforderungen und Beschreibungsmodell
Anforderungen an ein DBS: Kontrolle über die operationalen Daten
Alle Daten können/müssen gemeinsam benutzt werden
- keine verstreuten privaten Dateien
- Querauswertungen aufgrund inhaltlicher Zusammenhänge
- symmetrische Organisationsformen (keine Bevorzugung einer Verarbeitungs- und Auswertungsrichtung)
- Entwicklung neuer Anwendungen auf der existierenden DB
Redundanzfreiheit (aus Sicht der Anwendung)
- keine wiederholte Speicherung in unterschiedlicher Form für verschiedene Anwendungen
- Vermeidung von Inkonsistenzen
- zeitgerechter Änderungsdienst, keine unterschiedlichen Änderungsstände
Datenbankadministrator (DBA): zentrale Verantwortung für die operationalen Daten
GDB K2 Anforderungen und Beschreibungsmodell
Anforderungen an ein DBS: Leichte Handhabbarkeitder Daten
Einfache Datenmodelle
- Beschreibung der logischen Aspekte der Daten
- Benutzung der Daten ohne Bezug auf systemtechnische Realisierung
Logische Sicht der Anwendung
- zugeschnitten auf ihren Bedarf
- lokale Sicht auf die DB
Leicht erlernbare Sprachen
- deskriptive Problemformulierung
- hohe Auswahlmächtigkeit
- Unterstützung der Problemlösung des Anwenders im Dialog
Durchsetzung von Standards
- unterschiedliche DBS bieten einheitliche Schnittstelle
- Portierbarkeit von Anwendungen
- erleichterter Datenaustausch
Geeignete Unterstützung der verschiedenen Benutzerklassen
- Systempersonal
- Anwendungsprogrammierer
- anspruchsvolle Laien
- gelegentliche Benutzer
GDB K2 Anforderungen und Beschreibungsmodell
Anforderungen an ein DBS: Kontrolle der Datenintegrität
Automatisierte Zugriffskontrollen (Datenschutz)
- separat für jedes Datenobjekt
- unterschiedliche Rechte für verschiedene Arten des Zugriffs
Erhaltung der logischen Datenintegrität (system enforced integrity)
- Beschreibung der „Richtigkeit“ von Daten durch Prädikate und Regeln
- „Qualitätskontrollen“ bei Änderungsoperationen durch das DBS
- Ggf. aktive Maßnahmen durch das DBS
Transaktionskonzept (Durchsetzung der ACID-Eigenschaften)
- Schema-Konsistenz (C) aller DB-Daten wird bei Commit erzwungen
- ACID impliziert Robustheit, d. h., DB enthält nur solche Zustände, die explizit durch erfolgreich abgeschlossene TA erzeugt wurden
- *D**auerhaftigkeit (Persistenz): Effekte von abgeschlossenen TA gehen nicht verloren
- *A**tomarität (Resistenz): Zustandsänderungen werden entweder, wie in der TA spezifiziert, vollständig durchgeführt oder überhaupt nicht
- Im Mehrbenutzerbetrieb entsteht durch nebenläufige TA ein Konkurrenzverhalten (concurrency) um gemeinsame Daten, d. h., TA geraten in Konflikt
- *I**solationseigenschaft: TA-Konflikte sind zu verhindern oder aufzulösen
Erhaltung der physischen Datenintegrität
- Periodisches Erstellen von Datenkopien
- Führen von Änderungsprotokollen für den Fehlerfall (Logging)
- Bereitstellen von Wiederherstellungsalgorithmen im Fehlerfall (Recovery)
- *Garantie** nach erfolgreichem Neustart: jüngster transaktionskonsistenter DB-Zustand
Notwendigkeit des kontrollierten Mehrbenutzerbetriebs
- logischer Einbenutzerbetrieb für jeden von n parallelen Benutzern (Leser + Schreiber)
- geeignete Synchronisationsmaßnahmen zur gegenseitigen Isolation
- angepasste Synchronisationseinheiten (z. B. Sperrgranulate) mit abgestuften Zugriffsmöglichkeiten
- *Ziel**: möglichst geringe gegenseitige Behinderung
GDB K2 Anforderungen und Beschreibungsmodell
Kontrolle der Datenintegrität
Zu: Erhaltung der physischen Datenintegrität
DBMS garantiert physische Datenintegrität
- bei jedem Fehler wird eine „korrekte“ Datenbank rekonstruiert
- nach einem (Teil-)Absturz ist immer der jüngste transaktionskonsistente Zustand der DB zu rekonstruieren, in dem alle Änderungen von Transaktionen enthalten sind, die vor dem Zeitpunkt des Fehlers erfolgreich beendet waren (T1 bis T4) und sonst keine
- automatische Wiederherstellung nach Neustart des Systems
Maßnahmen beim Wiederanlauf
- Ermittlung der beim Absturz aktiven Transaktionen (T5, T6, T7)
- Rücksetzen (UNDO) der Änderungen der aktiven Transaktionen in der Datenbank (B‘ → B)
- Wiederholen (REDO) der Änderungen von abgeschlossenen Transaktionen, die vor dem Absturz nicht in die Datenbank zurückgeschriebenwaren (A → A‘)
GDB K2 Anforderungen und Beschreibungsmodell
Kontrolleder Datenintegrität
Zu: Notwendigkeit der Kontrolle des Mehrbenutzerbetriebs
- Beim logischen Einbenutzerbetrieb hat jede der parallel aktiven Transaktionen den ‚Eindruck‘, als liefe sie alleine ab, d. h., logisch bilden alle Transaktionen eine serielle Ablauffolge
- Synchronisationskomponente des DBMS umfasst alle Maßnahmen zur Sicherstellung der Ablaufintegrität (Isolation der parallelen Transaktionen)
- Formale Definition: Eine parallele Ablauffolge von Transaktionen ist genau dann korrekt synchronisiert, wenn es eine zu dieser Ablauffolge äquivalente (bezüglich ihrer Lese- und Schreibabhängigkeiten (r, w)) serielle Ablauffolge gibt, so dass jede Transaktion Ti in der seriellen Reihenfolge dieselben Werte liest und schreibt wie im parallelen Ablauf. (Dabei ist jede Permutation der Ti-Folge gleichermaßen zulässig, siehe Beispiel)
GDB K2 Anforderungen und Beschreibungsmodell
Anforderungen an ein DBS: Leistung und Skalierbarkeit
DBS-Implementierung gewährleistet
- Effizienz der Operatoren (möglichst geringer Ressourcenverbrauch)
- Verfügbarkeit der Daten (Redundanz, Verteilung usw.)
Effizienz des Datenzugriffs
- Zugriffsoptimierung durch das DBS, nicht durch den Anwender
- Anlegen von Zugriffspfaden durch den Datenbankadministrator, Auswahl idealerweise durch das DBS
Maßzahlen für Leistung: Antwortzeit, Durchsatz
Skalierbarkeit: Scaleup, Speedup
GDB K2 Anforderungen und Beschreibungsmodell
Anforderungen an ein DBS: Hoher Grad an Daten-Unabhängigkeit
- *Ziel:** möglichst starke Isolation der Anwendungsprogramme von den Daten
- *sonst:** extremer Wartungsaufwand für die Anwendungsprogramme
Realisierung verschiedener Arten von Daten - Unabhängigkeit:
- Minimalziel: physische Daten-Unabhängigkeit (durch das BS/DBS)
Geräteunabhängigkeit
Speicherungsstruktur-Unabhängigkeit - logische Daten-Unabhängigkeit (vor allem durch das Datenmodell!)
Zugriffspfad-Unabhängigkeit
Datenstruktur-Unabhängigkeit
GDB K2 Anforderungen und Beschreibungsmodell
Schichtenmodell für DBS
Ziel: Architektur eines daten-unabhängigen DBS
Weitere Komponenten in der DBS-Architektur
Entwurfsziel: DBS sollen von ihrem Aufbau und ihrer Einsatzorientierung her in hohem Maße generische Systeme sein. Sie sind so zu entwerfen, dass sie flexibel durch Parameterwahl und ggf. durch Einbindung spezieller Komponenten für eine vorgegebene Anwendungsumgebung konfigurierbar sind.
Metadaten
- Metadaten enthalten Informationen über die zu verwaltenden Daten
- sie beschreiben also diese Daten (Benutzerdaten) näher hinsichtlich Inhalt, Bedeutung, Nutzung, Integritätsbedingungen, Zugriffskontrolle usw.
- die Metadaten lassen sich unabhängig vom DBVS beschreiben (siehe internes, konzeptionelles und externes Schema)
- dadurch erfolgt das „Zuschneidern eines DBS“ auf eine konkrete Einsatzumgebung; die Spezifikation, Verwaltung und Nutzung von Metadaten bildet die Grundlage dafür, dass DBS hochgradig „generische“ Systeme sind
- Metadaten fallen in allen DBS-Schichten an
- Metadatenverwaltung, DB-Katalog, Data-Dictionary-System, DD-System, …
Transaktionsverwaltung
- Realisierung der ACID-Eigenschaften (Synchronisation, Logging/Recovery, Integritätssicherung)
GDB K2 Anforderungen und Beschreibungsmodell
Schema-Architektur
Drei-Schema-Architektur nach ANSI-SPARC
bisher Realisierungssicht (3-Schichtenmodell), nun Benutzungssicht
Konzeptionelles Schema
- (zeitvariante) globale Struktur; neutrale und redundanzfreie Beschreibung in der Sprache eines spezifischen Datenmodells
Externes Schema
- Definition von zugeschnittenen Sichten auf Teile des konzeptionellen Schemas für spezielle Anwendungen (Benutzer)
- Sichtenbildung
Anpassung der Datentypen an die der Wirtssprache (DBS ist „multi-lingual“)
Zugriffsschutz
Reduktion der Komplexität
Internes Schema
- legt physische Struktur der DB fest (Satzformate, Zugriffspfade etc.)
GDB K2 Anforderungen und Beschreibungsmodell
Zusammenfassung
