Datenbanksystemen - Friedrich-Schiller
Werbung
1.6 Datenbanksysteme – Terminologie & Eigenschaften Begriffliche Abgrenzung und Einordnung - Datenbank/Datenbanksystem/Datenbankverwaltungssystem (DBVS) - DBVS = DBMS (Database Management System) - DBVS verwaltet den Datenbestand, alle Zugriffe zum Datenbestand (lesen, einfügen, ändern, löschen) gehen ausschließlich über das DBVS, welches die vollständige Kontrolle über Datenbestand hat Benutzer Client Server liegt üblicherweise auf separatem DB-Server DatenbankVerwaltungssystem (DBVS) BS Datenbanksystem Dateiverwaltung no n o Datenbank Datenbanksysteme Friedrich-Schiller-Universität Jena Seite 27 1.6 Datenbanksysteme – Terminologie & Eigenschaften Datenbank = strukturierte Sammlung von „Datensätzen“ - Üblicherweise auf Magnetplatte gespeichert - Ablage entweder in vom Betriebssystem verwalteten Dateien (Standard) oder auch – unter Umgehung des Dateisystems – auf sog. „raw devices“ - Neben den Primärdaten enthält die Datenbank – abhänging vom Entwicklungsstand der Technologie – noch weitere Informationen (hier nur nur kurz angedeutet) Indexe (Zugriffspfade auf die Daten) Beschreibungsinformation zu den Daten - Metadaten, Datenbankkatalog (Data Dictionary) - Feldlängen, -namen, -typen, Datensatz(typ)namen, Informationen über Zugriffsberechtigungen usw. - Datenbankinhalt somit weitgehend selbstbeschreibend, DBVS interpretiert Datenbankinhalt mittels des Datenbankkatalogs, Benutzer darf ebenfalls (zumindest bei relationalen Datenbank-systemen) auf den Katalog zugreifen und diesen lesen Datenbanksysteme Friedrich-Schiller-Universität Jena Seite 28 1.6 Datenbanksysteme – Terminologie & Eigenschaften Integritätsbedingungen - Definierten Bedingungen, die für die Daten gelten 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. Datenbanksysteme Friedrich-Schiller-Universität Jena Seite 29 1.6 Datenbanksysteme – Terminologie & Eigenschaften "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 Friedrich-Schiller-Universität Jena Seite 30 1.6 Datenbanksysteme – Terminologie & Eigenschaften Programme, gespeicherte Prozeduren („stored procedures“) - Sind in der Datenbank hinterlegt und laufen bei Aufruf auf der Datenbank Datenbanksystem = konkrete Datenbank + DBVS - Begriffe sollten korrekt verwendet werden - In der Literatur / im umgangssprachlichen Gebrauch wird's nicht immer so genau unterschieden, vor allem Datenbanksystem und DBVS oftmals synonym verwendet (gerade noch akzeptabel) - Beispiele: • Falsch: "Welche Datenbank setzen Sie ein?" Richtig: "Welches Datenbank-Verwaltungssystem/Datenbanksystem setzen Sie ein?" • Falsch: "Wir haben letzte Woche die Oracle-Datenbank bei uns im Unternehmen implementiert." Richtig: " Wir haben letzte Woche das DBVS Oracle installiert." Datenbanksysteme Friedrich-Schiller-Universität Jena Seite 31 1.7 Architekturen im DB-Umfeld Wozu Architekturen? - Allgemein zur "Strukturierung des Chaos" (beispielsweise eines konkreten, komplexen Softwaresystems) - Unterscheidung zwischen verschiedenen Sichtweisen eines Systems • Benutzersicht • Administratorsicht, ... - Festlegung einer Systemstruktur • 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 Bedeutende Architekturen - ANSI/SPARC - DIAM Datenbanksysteme Friedrich-Schiller-Universität Jena Seite 32 1.7.1 ANSI/SPARC-Architektur Entstanden in den 1970er Jahren - ANSI = American National Standards Institute - SPARC = Standards Planning and Requirements Committee Unterscheidung zwischen drei Ebenen: - Externes Schema: • Wie werden die Daten dem Benutzer präsentiert? • (Teil-)Sichten auf den Datenbestand je nach Anforderung, in relationalen DBS als View realisierbar (Bsp: Sicht auf Personaldaten für Management / Personalabteilung / Mitarbeiter) - Konzeptuelles Schema: • Welche Daten werden beschrieben? • Gesamtdarstellung des Datenmodells auf logischer, (möglichst) system- und anwendungsunabhängiger Ebene, beispielsweise in relationaler Darstellung oder im Entity-Relationship-Modell - Internes Schema: • Wie werden die Daten persistiert? • Beschreibt (DBVS-spezifisch) die interne, physische Darstellung der Daten: wie und wo genau abgelegt, internes Satzformat, Zugriffspfade Datenbanksysteme Friedrich-Schiller-Universität Jena Seite 33 1.7.1 ANSI/SPARC-Architektur Bildliche Darstellung: 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 Bemerkung zu ANSI/SPARC: - Unterscheidung zwischen verschiedenen Betrachtungsweisen/-ebenen einer Datenbank mit Datenbanksprach-Äquivalenten (SQL) - Kein Mittel zur Strukturierung/Ebenenunterteilung eines DBVS ( DIAM) Datenbanksysteme Friedrich-Schiller-Universität Jena Seite 34 1.7.1 ANSI/SPARC-Architektur 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 "sein/ihr" externes Schema und stellt Datenbankanfragen "gegen" dieses Schema • Kennt sonst nichts weiter Datenbanksysteme Friedrich-Schiller-Universität Jena Seite 35 1.7.1 ANSI/SPARC-Architektur Datenunabhängigkeit - Änderungen am internen Schema einer Datenbank haben keine Auswirkungen auf konzeptuelles/externe Schemata • Beispiel: neue Platzierung der Daten, andere Speichermedien, neue Zugriffspfade (z.B. Hash → Baum) • Vor allem die Anwendungen mit Bezug auf ein externes Schema bleiben unbeeinflusst - Änderungen am konzeptuellen Schema können gegenüber externen Schemata verborgen werden • Beispiel: Definition neuer Tabellen, zusätzliche Attribute, neuer Beziehungen, Neuzuordnungen von Attributen zu Tabellen • Nur Anpassung der Sicht-Definition vom Anwendungsadministrator • Teilweise kann sogar das Wegfallen eines Attributs nach oben "maskiert werden" (Stichwort berechnete/virtuelle Attribute) • Transparenz hat aber Grenzen Datenbanksysteme Friedrich-Schiller-Universität Jena Seite 36 1.7.1 ANSI/SPARC-Architektur Datenbanksystemunabhängigkeit - Ziel: Gar keine / möglichst wenig Änderungen notwendig 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 und externe Schemata können – falls "normkonform" entwickelt – unverändert bleiben - Bemerkung zur "Normkonformität": • heißt Verzicht auf die Benutzung herstellerspezifischer SQLErweiterungen und -Spezialitäten • erfordert Programmier-/Entwicklungsrichtlinien im Unternehmen bzw. Vorgaben an den SQL-Compiler im DBVS für Programme mit eingebetteten SQL-Anweisungen Datenbanksysteme Friedrich-Schiller-Universität Jena Seite 37 1.7.2 Beziehung zwischen ANSI/SPARC und relationalen DBS Beispiel: Informationen über Bücher und Autoren Konzeptuelles Schema = relationales DB-Schema - Basistabellen BUCH und AUTOR - Unterstrichene Attribute sind Schlüssel in der Tabelle - BUCH BuchId 4242 3745 ... Titel Jahr ADAxx 1956 Hundezucht 1995 ... ... ISBN 3-452-12 1-424-11 ... - AUTOR (Schlüssel über BuchID+Nr wegen Co-Autoren) BuchId Nr Name 4242 3745 3745 ... 1 1 2 ... Winkler Küspert Beckstein ... Datenbanksysteme Friedrich-Schiller-Universität Jena Seite 38 1.7.2 Beziehung zwischen ANSI/SPARC und relationalen DBS Externes Schema = relationale Sicht - Realisierung über eine View ("Virtuelle Tabelle") - TITEL Name Nr Winkler Küspert Beckstein ... 1 1 2 ... Titel ADAxx Hundezucht Hundezucht ... Jahr 1956 1995 1995 ... ISBN 3-452-12 1-424-11 1-424-11 ... - SQL-Definition obiger View CREATE VIEW TITEL AS SELECT Name, Nr, Titel, Jahr, ISBN FROM BUCH, AUTOR WHERE BUCH.BuchID = AUTOR.BuchID - Erläuterungen zu Datenunabhängigkeit auf nächster Folie Datenbanksysteme Friedrich-Schiller-Universität Jena Seite 39 1.7.2 Beziehung zwischen ANSI/SPARC und relationalen DBS - Benutzer kann mit Sicht/View TITEL transparent arbeiten • Ohne Kenntnis über deren Entstehung (BUCH + AUTOR) • Ohne Kenntnis über die Namen/Schemata der Basistabellen • 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 Beeinflussung der Sicht und damit des Benutzers • Lediglich Sichtdefinition (CREATE VIEW ...) muss eventuell vom Anwendungsadministrator angepasst werden - Kritisch ist das allerdings das View-Update-Problem • Änderung der in Sichten enthaltenen Daten • Semantik bzw. Rückabbildung auf Basistabellen teilweise unklar oder sogar unmöglich • Beispiel: Änderung berechneter Attribute ("Durchschnittsgehalt") Datenbanksysteme Friedrich-Schiller-Universität Jena Seite 40 1.7.2 Beziehung zwischen ANSI/SPARC und relationalen DBS Internes Schema = physische Realisierung - Schneller wahlfreier und auch sortierter Zugriff auf AUTOR über Spalte/Attribute "Name" erforderlich • Realisierung über B*-Baum • SQL-Anweisung: CREATE INDEX Beppo ON AUTOR (Name) Beckstein 4242 1 Winkler 3745 1 Küspert Küspert Winkler 3745 2 Beckstein - Schneller wahlfreier Zugriff auf BUCH über "ISBN" erforderlich • Realisierung über B*-Baum oder Hashtabelle (nur wahlfrei nötig) • SQL-Anweisung: 1. Ich brauche CREATE UNIQUE INDEX Hugo schnellen Zugriff ... 2. ISBNs auf BUCH ON BUCH(ISBN) eindeutig Datenbanksysteme Friedrich-Schiller-Universität Jena Seite 41 1.7.3 DIAM-Modell DIAM = Data Independent Accessing Model - Entwickelt von Michael Senko, IBM San Jose/Californien, 1973 Ursprünglicher Ansatz umfasst 4 Ebenen (später erweitert): - Entity set model: logische anwendungsneutrale Datenstrukturen - "String model": logische Zugriffspfade (Indexe) - Encoding model: Speicherungsstrukturen, physische Zugriffspfade - Physical device model: Speicherzuordnungsstrukturen Erläuterungen zu den einzelnen Ebenen - Entity set model • Entität ist ein Ding/Objekt der realen Welt, das es in der Datenbank darzustellen/zu verwalten gilt (zu modellierende Informationseinheit) • Auf oberster Ebene des 4-Schichten-Modells werden also "Objektmengen" (Entitätsmengen) dargestellt und vom DBVS verwaltet Datenbanksysteme Friedrich-Schiller-Universität Jena Seite 42 1.7.3 DIAM-Modell - String model (nicht so arg „treffender Begriff“) • DBVS kennt hier logische Zugriffspfade; Bsp: Index auf Attribut PNR, die Datensätze sind intern nach ANR sortiert abgelegt, ... • Realisierung der Zugriffspfade/exakte Datensatzformate dagegen hierbei uninteressant - Encoding model • Art, wie die Daten "kodiert" sind, d.h. physische Speicherdarstellung • Bsp: Index auf PNR ist B*-Baum mit fest langen Einträgen zu jeweils 4 Bytes, die Felder eines Datensatzes sind fortlaufend gespeichert, variabel langen Feldern geht jeweils ein 2-Byte-Längenfeld voran, ... - Physical device model • Datenzuordnung zum Dateisystem/Magnetplatte • Bsp: Tabelle Personal steht in Datei xyz auf Platte D001, Index Personal PNR ebenso, ... Datenbanksysteme Friedrich-Schiller-Universität Jena Seite 43 1.7.4 DIAM-Weiterentwicklung (5-Schichten-Architektur) WIE prozedural Zugriffssystem deskriptive, mengenorientierte Schnittstelle (z.B. SQL) SELECT . . . FROM . . . WHERE Anfrageübersetzung/-optimierung Query Optimizer Zugriffspfadauswahl Zugriffskontrolle/Integritätskontrolle FINDE nächsten Satz SPEICHERE Satz (log.) 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 Härder/Rahm 2001 Datenbanksysteme Dateischnittstelle LIES Block k SCHREIBE Block k Externspeicherverwaltung/Dateiverwaltung DB Friedrich-Schiller-Universität Jena Datenbank-Verwaltungssystem Datensystem Anwendungsprogramme/Benutzer Betriebssystem/ Dateisystem deskriptiv WAS Anwendung Weiterentwicklung von DIAM am Beispiel eines relationalen DBS Seite 44 1.7.4 DIAM-Weiterentwicklung (5-Schichten-Architektur) Die vorgenannte Architektur ist eine mögliche Architektur für rel. DBS - So oder in ähnlicher Form in den meisten Produkten anzutreffen - "Erfunden“ worden im System R Projekt (IBM San Jose, 70er Jahre) Datensystem - "Übersetzung" (Kompilation oder Interpretation) der deskriptiven, mengenorientierten Datenbankanweisung in einen prozedural abzuarbeitenden Ablaufplan - Bestimmung des optimalen Ablaufplans, Gesamtkosten = f (CPU-ZeitBedarf + E/A-Aufwand) unter Einbeziehung von Zugriffspfaden - Zugriffs- und Integritätskontrolle (soweit ohne Datenzugriff machbar) Zugriffssystem - Verwaltung des Datenbankkatalogs (→ Metadaten), Ausführung von Sortiervorgängen (falls in Anfrage gefordert oder intern empfehlenswert) - Kontrolle des Mehrbenutzerbetriebs (Sperrverwaltung, „concurrency control“) Datenbanksysteme Friedrich-Schiller-Universität Jena Seite 45 1.7.4 DIAM-Weiterentwicklung (5-Schichten-Architektur) Speichersystem - Verwaltung von Datensätzen mit Abbildung in "Container" (sogenannte DB-Seiten) sowie von Zugriffspfaden (B*-Bäume, Hashtabellen) ebenfalls mit Abbildung in DB-Seiten - Treffen von Vorkehrungen für den Fehlerfall / Ermöglichen des Wiederanlaufs unter Konsistenzgesichtspunkten (Logging/Recovery) Systempufferverwaltung - Realisierung eines Datenpuffers (Systempuffer, Cache) im Speicher des Verarbeitungsrechner - Ziel: Plattenzugriffe möglichst zu vermeiden (Zeit für Plattenzugriffe liegt im ms-Bereich → 4-5 Zehnerpotenzen teurer/langsamer als Datenzugriffe im internen Speicher) - Schreiben von Daten auf die Platte via Dateisystem veranlassen Externspeicher-/Dateiverwaltung - Teil des Betriebssystems, Funktionalität bekannt Datenbanksysteme Friedrich-Schiller-Universität Jena Seite 46
