Architekturen

Architekturen im DB-Umfeld
ANSI/SPARC und DIAM
Wintersemester 16/17
DBIS
1
Motivation
Wintersemester 16/17
DBIS
2
Ziele von Architekturdefinitionen I
• „Strukturierung des Chaos“
• Komplexe (IT-)Anwendungen und reale Problemstellungen bestehen aus
vielen Einzelteilen.
• Z.B. Schulsystem: Irgendwer muss festlegen, was ein Schüler im Laufe
seiner Schullaufbahn lernen soll. Dann müssen die Inhalte in Fächer
aufgeteilt und festgelegt werden, welche Inhalte wann gelehrt werden
(und wie die Inhalte aufeinander aufbauen). Außerdem muss klar sein,
wer mit welchem Material lehrt und wann und wie Prüfungen stattfinden.
Schulen, Klassen, Stundenpläne,…
• Unterscheidung zwischen verschiedenen Sichtweisen eines Systems.
• Schulleiter braucht andere Informationen zum Schulsystem als der
Schüler / Blickt mit einer anderen „Brille“ auf die Schule.
• Selbes gilt für Systemadministratoren und Benutzer
Wintersemester 16/17
DBIS
3
Ziele von Architekturdefinitionen II
• Festlegung der Systemarchitektur
• Aus welchen Elementen besteht ein (technisches) System und wie sind diese
untereinander „verdrahtet“?
• Komponenten, Ebenen, Schnittstellen
• Oder im Schulbeispiel: Kultusminister  Weisungen (z.B. Lehrpläne in Papierform)
an Schulleiter  Festlegung des entsprechenden Lehrerbedarfs und Aufteilung der
Lehrer auf Klassen  Lehrer bekommt Stundenplan für sich und jeweiligen
Lehrplan pro Jahr pro Klasse  …
• Speziell bei Datenbanksystemen sind Architekturen zusätzlich Mittel zur
Realisierung eines möglichst hohen Grades an Datenunabhängigkeit
• Wie kann erreicht werden, dass die Daten physisch verteilt liegen können?
• Wie können verschiedene Nutzersichten ermöglicht werden (ohne dass die Daten
für jede Sicht eigens gehalten werden)?
• Bedeutende Architekturen: ANSI/SPARC und DIAM
Wintersemester 16/17
DBIS
4
ANSI/SPARC-Architektur I
• Entstanden in den 1970er Jahren
• ANSI = American National Standards Institute
• SPARC = Standards Planning and Requirements Committee
• Legt drei Ebenen fest, die ein DBMS unterscheiden können soll:
• Externes Schema:
• Wie werden die Daten dem Nutzer präsentiert?
• (Teil-)Sichten auf den Datenbestand je nach Anforderung
• Z.B. werden die Lehrpläne der Schule (über alle Fächer und Jahrgänge) in
einem Datenbestand gehalten, der Deutschlehrer bekommt aber nur die
Pläne für Deutsch und ggf. Ausschnitte aus anderen Lehrplänen (wenn die
für seinen Unterricht relevant sind) präsentiert
• In relationalen Datenbanksystemen durch „Views“ realisierbar
Wintersemester 16/17
DBIS
5
ANSI/SPARC-Architektur II
• Konzeptuelles Schema:
•
Welche Daten werden beschrieben?
•
Gesamtdarstellung des Datenmodells auf logischer und möglichst system- und
anwendungsunabhängiger Ebene
•
Z.B. Schulsystem: Alle Informationen, die zu Schulen, Schülern, Klassen, Lehrern, Lehrplänen,
Schulleitern,… vorhanden sein müssen, damit die Benutzer in Ihren Views all die Informationen
erhalten, die sie brauchen. Zusätzlich natürlich auch die Beziehungen zwischen den Einheiten (Schüler
besucht Klasse, Lehrer unterrichtet Klasse)
•
Verschiedene Darstellungsformen (relationale Darstellung, Entity-Relationship-Modell)
• Internes Schema:
•
Wie werden die Daten physisch gehalten?
•
Beschreibt (DBMS-spezifisch) die interne, physische Darstellung der Daten
•
Z.B. Schulsystem: In welchem Format und auf welchem Rechner liegen die Stundenpläne? Welchen
Datentyp hat der Name des Faches und wie ist der Datentyp aufgebaut? Wie kann man alle Fächer
physisch nacheinander erreichen?
Wintersemester 16/17
DBIS
6
ANSI/SPARC-Architektur III
• Fokus auf Unterscheidung
verschiedener
Betrachtungsweisen eines
Datenbestandes
• Kein Mittel zur Strukturierung
eines DBMS
• Für den Übergang zwischen den
Ebenen eigene Sprachen (SQL)
• Daten liegen nur auf der
untersten Ebene
Quelle: Elmasri/Navathe - „Grundlagen von Datenbanksystemen“
Wintersemester 16/17
DBIS
7
ANSI/SPARC-Architektur IV
• Außerdem: Definition verschiedener Rollen/Zuständigkeiten
• Datenbankadministrator:
• Legt konzeptuelles Schema mit Anwendungsadministratoren fest
• Legt internes Schema fest
• Kennt nicht unbedingt externe Schemata
• Anwendungsadministrator
• Legt konzeptuelles Schema mit Datenbankadministrator fest
• Legt externe Schemata fest
• Kennt internes Schema nicht
• Benutzer/Anwendung:
• Kennt nur eigenes externes Schema und stellt Datenbankabfragen „gegen“
dieses Schema
• Kennt sonst nichts weiter
Wintersemester 16/17
DBIS
8
ANSI/SPARC-Architektur V
• Nutzen der Aufteilung in Ebenen:
• Physische Datenunabhängigkeit:
• Änderungen am internen Schema einer Datenbank haben keine Auswirkungen auf
andere Schemata.
• Z.B. neue Platzierung der Daten, andere Speichermedien, neue Zugriffspfade
(Hash vs. Baum) beeinflusst die Anwendungssicht nicht.
• Logische Datenunabhängigkeit:
• Änderungen am konzeptuellen Schema können gegenüber externen Schemata
verborgen werden
• Z.B. Definition neue/wegfallende Tabellen, zusätzliche/wegfallende Attribute,
neue/wegfallende Beziehungen usw. Nur relevant für eine Sicht, wenn diese auf
den Teil des Schemas zurückgreift. Für betroffene Sichten muss auch die Definition
(also der Übergang zur konzeptuellen Sicht) angepasst werden
• Die Transparenz hat aber ihre Grenzen: Wenn z.B. nicht mehr alle Informationen
vorhanden sind, die die Sicht braucht.
Wintersemester 16/17
DBIS
9
ANSI/SPARC-Architektur VI
• Nutzen der Aufteilung in Ebenen:
• Datenbanksystemunabhängigkeit
• Möglichst wenig Änderungen am System beim Übergang zwischen zwei DBMSProdukten
• Internes Schema muss zwar angepasst werden da Systemspezifika nicht
genügend von der Norm erfasst werden können, aber konzeptuelles und externe
Schemata können unverändert bleiben
• (Wie immer) bringt Normkonformität auch Probleme mit sich:
• Verzicht auf herstellerspezifische SQL-Erweiterungen (in System X kann aufgrund
des Systemaufbaus dieses oder jenes performanter gelöst werden, als mit
Standard-SQL)
• Programmier- und Entwicklungsrichtlinien im Unternehmen benötigt (z.B. zu in
Views eingebettete SQL-Anweisungen)
 Die meisten Systeme erfüllen den Standard nicht vollständig
Wintersemester 16/17
DBIS
10
Beziehung zwischen ANSI/SPARC und relationalen DBS I
• In Datenbanken wird die Welt als Tabellenstruktur (mit Zeilen und Spalten)
modelliert. Wie passen das zu den Schemata?
• Konzeptuelles Schema entspricht relationalem DB-Schema
• Z.B. Bücher und Autoren (beides „Dinge der realen Welt“, die z.B. für die Versorgung mit
Schulbüchern erfasst werden müssen)
• Die Beziehung zwischen beiden „Dingen“ wird über den „Schlüssel“ der Tabellen
modelliert (Autor Winkler hat Buch mit dem Schlüssel 4242 geschrieben)
CREATE TABLE buch
(
BuchId int
Titel varchar(50)
…
)
CREATE TABLE autor
(
BuchId int
Nr
int
…
)
Wintersemester 16/17
DBIS
not null identity(1,1),
not null,
not null,
not null,
11
Beziehung zwischen ANSI/SPARC und relationalen DBS II
• Das externe Schema entspricht der relationalen Sicht
• Realisierung über Views („Virtuelle Tabelle“)
• Z.B. Alle vorhandenen Schulbuchtitel mit entsprechenden Autoren
• Die Daten sind im konzeptuellen Schema anders modelliert und
physisch anders abgelegt, trotzdem kann der Nutzer in seinem
Schema die Tabelle so verwenden, als wäre Sie tatsächlich physisch
vorhanden
CREATE VIEW TITEL AS
SELECT Name, Nr, Titel, Jahr, ISBN
FROM BUCH, AUTOR
WHERE BUCH.BuchID = AUTOR.BuchID
Wintersemester 16/17
DBIS
12
Beziehung zwischen ANSI/SPARC und relationalen DBS III
• Benutzer kann mit TITEL arbeiten
• Ohne Kenntnis über deren Entstehung (aus Buch und Autor)
• Ohne Kenntnis der Namen und Schemata der Basistabellen
• Die Tatsache, dass mit einer View gearbeitet wird, kann sogar verbogen bleiben
• Basistabellen können sich strukturell ändern
• Ohne Beeinflussung der Sicht (und damit des Benutzers)
• Lediglich die Definition der Sicht (also der SQL-Code für TITEL) muss ggf. durch den
Anwendungsadministrator angepasst werden
• View-Update-Problem:
• Änderung der in der Sicht enthaltenen Daten durch den Nutzer muss auf die
Basistabellen abgebildet werden
• Rückabbildung teilweise unklar oder sogar unmöglich, etwa bei Änderung berechneter
Attribute
• Z.B. (Durchschnittliche Arbeitszeit pro Lehrer)
Wintersemester 16/17
DBIS
13
Beziehung zwischen ANSI/SPARC und relationalen DBS IV
• Internes Schema entspricht der physischen Realisierung
• Z.B. schneller, wahlfreier und sortierter Zugriff auf AUTOR über
Spalte „Name“ erforderlich?
Realisierung in internem Schema über B*-Baum
CREATE INDEX autor_name
ON AUTOR (Name)
• Fazit:
• Die Ebenen können im relationalen DBS realisiert werden
• SQL bietet entsprechende Sprachelemente
Wintersemester 16/17
DBIS
14
DIAM – Modell I
• DIAM = Data Independent Accessing Model, Entwickelt von Michael Senko (IBM)
1973
• Architektur mit Fokus auf „was muss das DBMS von den Daten wissen, um
funktionieren zu können? Wie muss das DBMS intern aufgebaut sein?“
• Ursprünglich Unterscheidung von 4 Ebenen
• Entity set model: logische anwendungsneutrale Datenstrukturen
• String model: logische zugriffspfade (Indexe)
• Encoding model: Speicherungsstrukturen, physische Zugriffspfade
• Physical device model: Speicherzuordnungsstrukturen
• Entity set model:
• Entität = „Ding der realen Welt“ = Informationseinheit, die die Datenbank verwalten muss
 Auf oberster Ebene werden „Objektmengen“ dargestellt (nicht etwa Dateien oder
Bytefolgen oder einzelne Tabellenzellen)
Wintersemester 16/17
DBIS
15
DIAM – Modell II
• String model
• Logische Zugriffspfade: Welche „Fäden“ halten die Objekte intern und untereinander
zusammen?
• Z.B. Index des Objektes X ist Spalte a, Intern werden die Datensätze nach Spalte b
sortiert abgelegt
• Realisierung der Zugriffspfade und Datenformate nicht von Bedeutung
• Encoding model
• Physische Speicherdarstellung: Wie sind die Daten kodiert und in welchen (Speicher-)
Strukturen sind sie geordnet?
• Z.B. Index des Objektes X ist als B*-Baum realisiert, das Objekt X besteht aus folgenden
Feldern fester Länge,…
• Physical device model
• Datenzuordnung zum Dateisystem/Magnetplatte
• Z.B. Objekt X liegt in Datei 123 auf Platte p789
Wintersemester 16/17
DBIS
16
Erweiterung zur 5-Schichten-Architektur I
Wintersemester 16/17
DBIS
17
Erweiterung zur 5-Schichten-Architektur II
• Diese Architektur ist eine von mehreren möglichen Architekturen für ein
relationales DBS
• So oder in ähnlicher Form in den meisten Produkten anzutreffen
• Grundlegender Aufbau im System R Projekt (IBM, 70er Jahre) entwickelt worden
• Bestandteile:
• Datensystem
•
Übersetzung der deskriptiven, mengenorientierten Datenbankanweisung in einen prozedural
abarbeitbaren Ablaufplan (komplilieren)
•
Bestimmung des optimalen Ablaufplans und der Gesamtkosten unter Einbeziehung von
Zugriffspfaden (in CPU-Zeit und E/A-Aufwand)
•
Zugriffs- und Integritätskontrolle (soweit ohne Datenzugriff machbar)
• Zugriffssystem
•
Verwaltung des Datenbankkatalogs (Metadaten) und Ausführung von Sortiervorgängen (falls
gefordert oder intern empfehlenswert)
•
Kontrolle des Mehrbenutzerbetriebes (Sperren und freigeben)
Wintersemester 16/17
DBIS
18
Erweiterung zur 5-Schichten-Architektur III
• Bestandteile:
• Speichersystem
• Verwaltung von Datensätzen und Containern (Seiten) sowie von
Zugriffspfaden (Bäume, Hashtabellen)
• Treffen von Vorkehrungen für den Fehlerfall und ermöglichen des
Wiederanlaufs unter Konsistenzgesichtspunkten (Logging/Recovery)
• Systempufferverwaltung
• Realisierung eines Datenpuffers im Verarbeitungsrechner um Plattenzugriffe
möglichst zu vermeiden
• Schreiben von Daten auf die Platte via Dateisystem veranlassen
• Externspeicher-/Dateiverwaltung
• Teil des Betriebssystems
• Muss nur geeignet angesprochen werden
Wintersemester 16/17
DBIS
19