1.4 Datenbanksysteme u. ihre Eigenschaften und Terminologie im

1.4 Datenbanksysteme u. ihre Eigenschaften und Terminologie im Überblick
1.4.1 Datenbank/Datenbanksystem/Datenbank-Verwaltungssystem
(DBVS, DBMS)
Begriffliche Abgrenzung und Einordnung
Benutzer
Client
DBVS  DBMS
DatenbankVerwaltungssystem
(DBVS)
liegt üblicherweise auf
separatem
DB-Server
BS
Datenbanksystem
Dateiverwaltung
Datenbank
ClientServer
Bemerkung dazu:
• DBVS* (auch Database Management System (DBMS) genannt) verwaltet den
Datenbestand; alle Zugriffe zum Datenbestand (anlegen, lesen, einfügen, ändern,
löschen) gehen ausschließlich über das DBVS, d.h. DBVS übt vollständig Kontrolle
über Datenbestand aus
* in seltenen Fällen auch Datenbank-Betriebssystem genannt
Datenbanksysteme 1
32
• Datenbank = strukturierte Sammlung von „Datensätzen“, i.d.R. auf
Magnetplatte gespeichert. Ablage entweder in vom Betriebssystem
verwalteten Dateien (üblicherweise) oder auch – unter Umgehung des
Dateisystems – auf sog. „raw devices“. (Wir gehen im folgenden von
der Ablage in Dateien aus.)
Neben den Primärdaten enthält die Datenbank
– je nach Entwicklungsstand der Technologie! –
noch weitere Informationen (hier nur kurz angedeutet):
- Indexe (Zugriffspfade)
- Beschreibungsinformation zu den Daten ( Metadaten,
Datenbankkatalog (, Data Dictionary)): Feldlängen, -namen, typen, Datensatz(typ)namen, Informationen über Zugriffsberechtigungen usw. usf.
 Datenbankinhalt somit weitgehend selbstbeschreibend, DBVS
interpretiert Datenbankinhalt mittels des Datenbankkatalogs,
Benutzer darf ebenfalls (zumindest bei relationalen Datenbanksystemen) auf den Katalog zugreifen und diesen lesen
Datenbanksysteme 1
33
- Integritätsbedingungen, die für die Daten erfüllt sein sollen und deren
Einhaltung vom DBVS überwacht werden soll
(„system enforced integrity“)
Beispiele:
• Das Feld Personalnr im Personalstammsatz muss stets einen Wert
besitzen, darf also nicht undefiniert/unbekannt („null“) sein
• Das Feld Gehalt muss stets  6000 sein
• Für jede Abteilungsnr im Personalstammsatz muss es stets (genau)
einen Abteilungsstammsatz mit gleicher Nummer geben
Abteilungsstammsatz
(Typ)
1:n-Beziehung
Vater-Sohn-Beziehung
Personalstammsatz
(Typ)
• Das Durchschnittsgehalt aller Mitarbeiter einer jeden Abteilung muss
stets  5000 sein
• usw. usf.
Datenbanksysteme 1
34
• „Aktive Elemente“ (Aktionen), die es ermöglichen, automatisch
(Folge-)Änderungen auf der Datenbank durchzuführen in Abhängigkeit
von bestimmten, definierten, eingetretenen Ereignissen: passives
Datenbanksystem entwickelt sich weiter zu aktivem Datenbanksystem (erst in jüngerer Zeit anzutreffen)
Beispiele:
- Immer wenn ein Abteilungsstammsatz gelöscht wird, sollen auch
automatisch die Personalstammsätze der zugehörigen Mitarbeiter
gelöscht werden (ohne dass der Benutzer dies explizit veranlassen
muss, sondern Folgeänderungen automatisch/implizit)
- Immer wenn eine Änderung an Personalstammsätzen (durch den
Benutzer) geschieht, soll automatisch ein Protokollsatz erstellt
und geschrieben werden ( zu Revisionszwecken)
- Immer wenn eine Gehaltsänderung (durch den Benutzer) geschieht
im Personalstammsatz oder ein neuer Personalstammsatz hinzukommt oder einer gelöscht wird, soll das Feld DurchschnittsgehaltAbteilung im Abteilungsstammsatz automatisch aktualisiert
werden
Datenbanksysteme 1
35
• Programme, gespeicherte Prozeduren („stored procedures“),
die in der Datenbank hinterlegt sind und bei Aufruf auf der Datenbank
ablaufen  wird später detaillierter erklärt
konkrete Datenbank + DBVS = Datenbanksystem
Wir werden versuchen, in der Vorlesung diese Begriffsbildung
„einigermaßen konsequent“ beizubehalten; in der Literatur / im
umgangssprachlichen Gebrauch wird´s nicht immer so genau
unterschieden, vor allem Datenbanksystem und DBVS oftmals
synonym verwendet (gerade noch akzeptabel).
Nicht mehr akzeptabel:
richtig
- „Welche Datenbank setzen Sie ein?“ 
... welches Datenbank-Verwaltungssystem/Datenbanksystem
- „Wir haben letzte Woche die Oracle-Datenbank bei uns im
richtig
Unternehmen implementiert.“ 
... das DBVS Oracle installiert
Datenbanksysteme 1
36
1.5 Architekturen im DB-Umfeld
Wozu Architekturen?
• „Strukturierung des Chaos“ (beispielsweise eines konkreten, komplexen
Softwaresystems)
• Unterscheidung zwischen verschiedenen Sichtweisen eines Systems
(Benutzersicht, Administratorsicht ...), Festlegung einer Systemstruktur,
bestehend aus Komponenten, Ebenen, Schnittstellen . . .
• (Speziell bei Datenbanksystemen) zusätzlich:
Architekturen als ein Mittel zur Realisierung eines möglichst hohen
Grades an Datenunabhängigkeit durch Separierung verschiedener
Ebenen/Komponenten
1.5.1 ANSI/SPARC-Architektur
• Entstanden in den 1970er Jahren
• Unterscheidung zwischen drei Ebenen:
- externes Schema
- konzeptuelles Schema
- internes Schema
Datenbanksysteme 1
37
Bildlich dargestellt:
Externe
Sichten
Anw./Benutzer
Anw./Benutzer
externes
Schema 1
externes
Schema n
...
Externe
Ebene
Konzeptuelle
Sicht
konzeptuelles
Schema
Konzeptuelle
Ebene
Interne
Sicht
internes
Schema
Interne
Ebene
Erläuterungen:
• Internes Schema: Wie? gespeichert
Beschreibt (systemspezifisch (DBVS)) die interne, physische Darstellung der Daten: wie und wo genau abgelegt, internes Satzformat,
Zugriffspfade, ggf. Verweisstrukturen etc. für die gesamte Datenbank
• Konzeptuelles Schema: Was?
Gesamtdarstellung des Datenmodells auf logischer, (möglichst) systemunabhängiger und anwendungsunabhängiger Ebene, beispielsweise in
relationaler Darstellung (Tabellen, Attribute, Beziehungen) oder noch
höherer Abstraktionsebene (Entity-Relationship)
Datenbanksysteme 1
38
• externe Schemata: Wie dem Benutzer präsentiert?
(Teil-)Sichten auf den Datenbestand, wie von Anwendungen/Benutzern benötigt (Bsp.: Personalabteilung benötigt andere Sicht /
anderen Detaillierungsgrad als etwa Top-Management oder der
einzelne Mitarbeiter), im Fall eines relationalen Datenbanksystems
über Views realisierbar
Wer muss was kennen?
Benutzer
„Anwendungsadministrator“
Datenbankadministrator
• Datenbankadministrator: Legt zusammen mit Anwendungsadministratoren konzeptuelles Schema fest, legt internes Schema fest,
kennt nicht unbedingt externe Schemata
• Anwendungsadministrator: Legt zusammen mit Datenbankadministrator konzeptuelles Schema fest, legt externe Schemata fest,
kennt internes Schema nicht
• Benutzer: („Endbenutzer“) kennt „sein“ externes Schema, stellt
Datenbankanfragen ´gegen´ dieses Schema, kennt sonst nichts weiter
Datenbanksysteme 1
39
Inwiefern Datenunabhängigkeit?
virtuelles Attribut
• Änderungen am internen Schema einer Datenbank (neue Platzierung
der Daten, andere Speichermedien, neue Zugriffspfade oder
Änderungen der Z. (Hash  Baum als ein Beispiel)) haben keine
Auswirkungen auf konzeptuelles/externe Schemata; vor allem die
Anwendungen (Programme, in denen auf das externe Schema Bezug
genommen wird) bleiben unbeeinflusst!
• Änderungen am konzeptuellen Schema (z.B. Definition neuer Tabellen, zusätzlicher Attribute, neuer Beziehungen) können gegenüber
externen Schemata verborgen werden, auch Neuzuordnungen von
Attributen zu Tabellen (im relationalen Fall)  lediglich die Sicht(View-)Definition muss vom Anwendungsadministrator angepasst
werden
 u.U. kann sogar das Wegfallen eines Attributs nach oben „maskiert
werden“ (Bsp.: Attribut DurchschnittsGehalt/Abteilung in Abteilungstabelle entfällt, wird statt dessen aus Daten der Personaltabelle jeweils
berechnet)
 hat aber, wie man sieht, Grenzen
Datenbanksysteme 1
40
Datenbanksystemunabhängigkeit
Ziel: Gar keine / möglichst wenig Änderungen für ein Unternehmen beim
Übergang von DBVS-Produkt x zu DBVS-Produkt y
Betrachtung hier für den relationalen Fall
• internes Schema (Zugriffspfad definieren, Festlegung des Ortes der
Datenabspeicherung etc.) muss angepasst werden, da Systemspezifika nicht genügend von der SQL-Norm erfasst werden (können)
• konzeptuelles Schema kann – falls ´normkonform´ entwickelt –
unverändert bleiben
• externe Schemata ebenso
N.B.: „Normkonformität“ heißt Verzicht auf die Benutzung herstellerspezifischer SQL-Erweiterungen und –Spezialitäten
 erfordert Programmier-/Entwicklungsrichtlinien im Unternehmen
(bzw. man kann teils dem DBVS auch sagen, dass bei der Übersetzung
von Programmen mit eingebetteten SQL-Anweisungen der (SQL-)Compiler nur normkonforme SQL-Anweisungen akzeptieren soll)
Datenbanksysteme 1
41
Beispiel zu den Beziehungen zwischen der ANSI/SPARC-Architektur und
Gegebenheiten relationaler Datenbanksysteme
1. Konzeptuelles Schema = relationales DB-Schema
Informationen über Autoren und Bücher
BUCH
BuchId
4242
3745
...
AUTOR
Datenbanksysteme 1
Titel
Jahr
ADAxx
1956
Hundezucht 1995
...
...
BuchId
Nr
4242
3745
3745
...
1
1
2
...
Name
Winkler
Küspert
Beckstein
...
ISBN
3-452-12
1-424-11
...
Basistabellen
Unterstrichen
 Schlüssel
=
42
2. (Ein) externes Schema = relationale Sicht (View)
Name
Nr
Winkler
Küspert
Beckstein
...
1
1
2
...
TITEL
CREATE
SELECT
FROM
WHERE
Titel
ADAxx
Hundezucht
Hundezucht
...
Jahr
1956
1995
1995
...
ISBN
3-452-12
1-424-11
1-424-11
...
„Virtuelle
Tabelle“
VIEW TITEL AS
Name, Nr, Titel, Jahr, ISBN
BUCH, AUTOR
BUCH.BuchID = AUTOR.BuchID
Datenbanksysteme 1
43
hoher Grad an
Datenunabhängigkeit
• Benutzer kann mit Sicht (View) TITEL arbeiten, ohne zu kennen,
wie diese (aus den Basistabellen BUCH und AUTOR) entstanden
ist; er muss nicht einmal die Basistabellen und deren
Namen/Schemata kennen bzw. die Tatsache, dass er mit einer
Sicht und nicht mit einer Basistabelle arbeitet, kann ihm sogar
verborgen bleiben / egal sein
• Basistabellen können sich strukturell ändern, ohne dass Sicht –
und damit Benutzer – betroffen ist  lediglich Sichtdefinition
(CREATE VIEW ...) muss ggf. (vom Anwendungsadministrator)
angepasst werden
• Problematisch wird´s allerdings u.U. bei Änderungen der in
Sichten enthaltenen Daten (kurz: „bei Änderungen auf Sichten“)
 Semantik bzw. Rückabbildung auf Basistabellen z.T. unklar
bzw. unmöglich
View-Update-Problem
(kommt natürlich später
noch mal in „Ruhe“)
Datenbanksysteme 1
44
3. Internes Schema = physische Realisierung
Spalte
Schneller wahlfreier und auch sortierter Zugriff auf AUTOR über Attribut
Name erforderlich:
Zugriffspfad
Index
B*-Baum
Beckstein
4242
1
Küspert
Winkler
3745
Winkler
3745
1
2
Beckstein
Küspert
CREATE
INDEX Beppo
ON AUTOR (Name)
Schneller wahlfreier Zugriff auf BUCH über ISBN erforderlich
1. Ich brauche
schnellen Zugriff ...
CREATE UNIQUE INDEX Hugo
2. ISBNs auf BUCH
ON BUCH(ISBN)
eindeutig
Hier könnte – falls vom DBVS angeboten – auch eine Hashtabelle
angelegt werden, da lediglich wahlfreier Zugriff gefordert
Datenbanksysteme 1
45
Änderungen am internen Schema haben keinen Einfluss auf
konzeptuelles Schema, externe Schemata oder gar Benutzer  „lediglich“
Performance-Unterschied
Last-Charakterista bestimmen internes Schema (Workload!)
Abschlussbemerkung zur ANSI/SPARC-Architektur: Sie zielt darauf ab,
zwischen verschiedenen Betrachtungsweisen/-ebenen einer Datenbank
zu unterscheiden (für die es auch Äquivalente im Datenbanksprachbereich (siehe SQL oben) gibt), nicht aber auf die Strukturierung/
Ebenenunterteilung eines DBVS!
Datenbanksysteme 1
!
46
1.5.2 DIAM-Modell und Weiterentwicklungen
• DIAM = Data Independent Accessing Model
• Michael Senko, IBM San Jose, Cal., 1973 (später erweitert, s.u.)
• Ursprünglicher Ansatz (4 Ebenen)
Originalbegriff
entity set model
„string model“
encoding model
physical device model
Umschreibung
logische, anw.neutrale Datenstrukturen
logische Zugriffspfade (Indexe)
Speicherungsstrukturen, phys. Zug.
Speicherzuordnungsstrukturen
• Erläuterungen dazu:
1. Entity (Entität): ´Ding´/Objekt der realen Welt, das es in der
Datenbank darzustellen/zu verwalten gilt, zu modellierende
Informationseinheit
Auf der obersten Ebene unseres 4-Schichten-Modells werden also
„Objektmengen“ (Entitätsmengen) dargestellt und vom DBVS
verwaltet
Datenbanksysteme 1
47
2. String Model (nicht so arg „treffender Begriff“):
DBVS kennt hier logische Zugriffspfade, z.B.: es gibt einen Index
auf Attribut PNR; die Datensätze sind intern nach ANR sortiert
abgelegt etc. Realisierung der Zugriffspfade/exakte Datensatzformate dagegen hierbei uninteressant
3. Encoding Model: Art, wie die Daten „kodiert“ sind, d.h. im
Speicher physisch dargestellt, z.B.: Index auf PNR ist B*-Baum mit
fest langen Einträgen zu jeweils 4 Bytes; die Felder eines
Datensatzes sind fortlaufend („dicht“) gespeichert, variabel langen
Feldern geht jeweils ein 2-Byte-Längenfeld voran etc.
4. Physical Device Model: Datenzuordnung zum
Dateisystem/Magnetplatte, z.B.: Tabelle Personal steht in Datei xyz
auf Platte D001, Index Personal PNR ebenso etc.
Datenbanksysteme 1
48
SELECT . . .
FROM . . . WHERE
Datensystem
deskriptive, mengenorientierte Schnittstelle
(z.B. SQL)
Anfrageübersetzung/-optimierung
Query Optimizer
Zugriffspfadauswahl
Zugriffskontrolle/Integritätskontrolle
WIE
prozedural
FINDE nächsten Satz
SPEICHERE Satz (log.)
Zugriffssystem
satzorientierte
Schnittstelle (log.)
Katalogverwaltung
Sortierkomponente
Sperrverwaltung
Speichersystem
SPEICHERE internen Satz
FÜGE Eintrag im B*-Baum ein
interne Satzschnittstelle (phys.)
Record Manager
Zugriffspfadverwaltung
Logging/Recovery (Fehlerbeh.komp.)
Pufferverwaltung
BEREITSTELLEN Seite j
FREIGEBEN Seite j
Systempufferschnittstelle
Systempufferverwaltung (Buffer Manager)
Betriebssystem/
Dateiverwaltung
Dateischnittstelle
LIES Block k
SCHREIBE Block k
Externspeicherverwaltung/Dateiverwaltung
Härder/Rahm 2001
Datenbanksysteme 1
DB
Anwendung
Anwendungsprogramme/Benutzer
deskriptiv
WAS
Betriebssystem/
Datenbank-Verwaltungssystem (DBVS)
Dateisystem
Weiterentwicklung von DIAM
aufgezeigt am Beispiel
eines relationalen
Datenbanksystems
49
Erläuterungen zur 5-Schichten-Architektur
• Datensystem: „Übersetzung“ (Kompilation oder Interpretation) der
deskriptiven, mengenorientierten Datenbankanweisung in einen
prozedural abzuarbeitenden Ablaufplan; Bestimmung des optimalen
Ablaufplans (Gesamtkosten = f (CPU-Zeit-Bedarf + E/A-Aufwand)
unter Einbeziehung von Zugriffspfaden; Zugriffs- und Integritätskontrolle (soweit ohne Datenzugriff machbar)
• Zugriffssystem + Speichersystem: Verwaltung des
Datenbankkatalogs ( Metadaten); Ausführung von Sortiervorgängen (falls in Anfrage spezifiziert oder falls aus internen Gründen
Sortieren (aus Kostengründen) empfehlenswert); Verwaltung von
Datensätzen mit Abbildung in „Container“ (DB-Seiten genannt) sowie
von Zugriffspfaden (B*-Bäume, Hashtabellen), ebenfalls mit Abbildung in DB-Seiten;
Kontrolle des Mehrbenutzerbetriebs (Sperrverwaltung, „concurrency
control“); Treffen von Vorkehrungen für den Fehlerfall / Ermöglichen
des Wiederanlaufs unter Konsistenzgesichtspunkten (Logging/Recovery)
Datenbanksysteme 1
50
• Systempufferverwaltung: Realisierung eines Datenpuffers (Systempuffer, Cache) im Speicher des Verarbeitungsrechners mit dem Ziel,
Plattenzugriffe möglichst zu vermeiden (Zeit für Plattenzugriffe liegt
im ms-Bereich  4-5 Zehnerpotenzen teurer als Datenzugriffe im
internen Speicher); Schreiben von Daten auf die Platte (via Dateisystem) veranlassen
• Externspeicherverwaltung/Dateiverwaltung: Teil des Betriebssystems, Funktionalität bekannt
Die vorgenannte Architektur ist eine mögliche Architektur für (relationale)
Datenbanksysteme; so oder in ähnlicher Form in den meisten Produkten
anzutreffen („erfunden“ worden im System R Projekt); auch hierarchische und Netzwerk-Datenbanksysteme entsprechen in großen Teilen
(bis auf Datensystem) dieser Architektur
Datenbanksysteme 1
51
Zusammenfassung / ´Hilites´ zu Kap. 1
• Datenhaltungsfragestellungen allgegenwärtig in betriebswirtschaftlichen
Anwendungen sowie in ´Non-Standard-Anwendungen´ (Büro, Technik,
Wissenschaft)
• DBMS-Technologie soll wesentliche Anforderungen erfüllen in bezug auf (u.a.)
Datenunabhängigkeit, Flexibilität/Einfachheit/Mächtigkeit des Datenzugriffs,
Datenverfügbarkeit, Sicherheit vor Datenverlust, Datenintegrität, Zugriffskontrolle,
Mehrbenutzerbetrieb ...
• Dateisysteme (allein) können diese Anforderungen nicht oder nur in Teilen
erfüllen
(N.B.: Dennoch darf DBMS-Technologie natürlich Dateiverwaltung „nach unten“
benutzen.)
• Viele Probleme treten erst bei großen Datenbeständen / vielen parallelen
Benutzern / bei hohen Verfügbarkeitsanforderungen massiv in Erscheinung
 Fälle der Praxis!
• Begriffe:DBMS(=DBVS), DB, DBS in Rolle und Zusammenspiel
• Architekturen wesentlich zum Verständnis/Einordnung:
- 3-Schichten-Architektur ANSI/SPARC
- DIAM 4-Schichten-Architektur
- Erweiterte/verfeinerte DIAM-Architektur
Datenbanksysteme 1
52