Datenbanksysteme Teil 1. Dozent: Stefan Maihack Dipl. Ing. (FH)

Transkript

1 Datenbanksysteme Teil 1 Dozent: Stefan Maihack Dipl. Ing. (FH)

2 Inhaltsverzeichnis 1/2 Einführung Das Konzept des Datenbanksystems Datenbanksysteme und traditionelle Datenverwaltung Architektur eines Datenbanksystems Drei Datenebenen Das konzeptuelle Datenmodell Das interne Modell Das externe Modell Das Datenbankmanagementsystem Weitere Komponenten des DBS Datenunabhängigkeit Ein Datenmodell für die konzeptionelle Ebene Datenbankentwurfsprozess Das Entity-Relationship-Modell Symbole Entities Beziehungen Attribute Schlüssel Kardinalitäten Schwache Entity Typen Erweiterungen des ER-Modells

3 Inhaltsverzeichnis 2/2 Datendefinition und Datenselektion Schlüssel Nullwerte Einfache Datenbankoperationen mit SQL Relationale Abfragen (SQL-Abfragen über mehrere Tabellen) Selektion Projektion Kartesisches Produkt Join (Verbund) Aggregatfunktionen und Gruppierungen Aggregatfunktionen Gruppierungen Normalisierung

4 Das Konzept des Datenbanksystems Eine Datenbank ist eine integrierte Ansammlung von Daten, die allen Benutzern eines Anwendungsbereiches als gemeinsame Basis aktueller Informationen dient. Anwendungen greifen nicht direkt auf die Datenbank zu. Die gesamte Kontrolle der Datenbank liegt beim Datenbankmanagementsystem (DBMS) Datenbank und Datenbanksoftware bilden zusammen das Datenbanksystem (DBS) Datenbankmanagementsysteme besitzen eine Abfragesprache (SQL).

5 Das Konzept des Datenbanksystems DB S1 S2 DBMS S3 Anwendungsprogramm

6 Datenbanksysteme und traditionelle Datenverwaltung Jedes gängige Betriebssystem unterstützt ein oder weniger komfortables Dateisystem. COBOL, eine Sprache die primär auf die Verarbeitung von Dateien ausgerichtet ist. Prog A Datei D1 Prog.B Datei D2 Prog.C Datei D3

7 Datenbanksysteme und traditionelle Datenverwaltung Probleme traditioneller Dateiverwaltung: Redundanz: Die gleichen Daten liegen oft mehrfach vor. Inkonsistenz: Gleiche Daten müssen bei Änderungen berücksichtigt werden. Daten-Programm-Abhängigkeit: Daten sind an ein Programm gebunden. Inflexibilität: Daten werden nur anwendungsbezogen gesehen, Neu-Anwendungen zu realisieren ist oft kompliziert. Keine Point-in-Time Recoverymöglichkeit

8 Datenbanksysteme und traditionelle Datenverwaltung Geschichtlicher Überblick: 1. Generation: Filesystem (50 60er Jahre) 2. Generation: Prerelationale Systeme; Erste Trennung zwischen Daten und Programm. 3. Generation: Relationale Datenbanken (80er Jahre) Schwerpunkt dieses Kurses)! 4. Generation: Objektorientierte und objektrelationale Datenbanken. Entwicklung in den 90er Jahren, Einsatz in Produktivumgebungen ist im kommen.

9 Datenbanksysteme und traditionelle Datenverwaltung Vorteile der Datenbank-Philosophie: Eine gemeinsame Basis für alle Anwendungen Redundanz entfällt; wo Redundanz nützlich ist, ist sie durch das DBMS kontrolliert. Konsistenzprobleme entfallen (falsche Daten). Anwendungsprogrammierer müssen nur die Eigenschaften der Daten kennen, nicht deren spezielle Organisation auf den Speicher. Die Abhängigkeit zwischen Daten und Programm wird reduziert. Das DBS kann zentral die Korrektheit der Daten überprüfen (Integrität). Transaktionsorientiert: Eine Transaktion ist eine Folge von Befehlen (oder Operationen), die eine Datenbank von einem konsistenten Zustand in einem anderen überführt. Eine Transaktion muss entweder vollständig durchgeführt oder, bei einem Abbruch, vollständig zurückgesetzt werden können. Das DBS kann zentral Mechanismen zur Wiederherstellung bereitstellen (Recovery).

10 Das Transaktionskonzept Aus logischer Sicht ist eine Transaktion ein Arbeitspaket so klein wie möglich So gross wie nötig, um alle Integritätsbedingungen einhalten zu können. Aus technischer Sicht ist eine Transaktion eine Folge von Lese- Änderungsoperationen in der Datenbank, mit einem definierten Beginn und einem definierten Abschluss. Die Transaktionsverwaltung ist eine der Kernaufgaben eines Datenbanksystems. Das Datenbanksystem garantiert für eine Transaktion folgende Eigenschaften: A = Atomarität; C = Konsistenz, I = Isolation, D = Dauerhaftigkeit. Diese Eigenschaften werden als ACID-Regel bezeichnet

11 Das Transaktionskonzept Atomarität Eine Transaktion kann alle gewünschten Operationen erfolgreich durchführen, oder sie hat gar keine Auswirkkungen auf den Zustand der Datenbank. Alles oder Nichts -Prinzip In Fehlersituationen kann eine Transaktion durch das Anwendungsprogramm oder durch das DBMS abgebrochen werden. Das DBMS ist dafür verantwortlich, dass alle Änderungen am Datenbestand seit Beginn der Transaktion rückgängig gemacht werden (Undo-Recovery) Beispiel Überweisung: Hebe Geld vom Konto ab und schreibe das Geld einem anderen Konto zu.

12 Das Transaktionskonzept Konsistenz Bei Abschluss einer Transaktion muss ein konsistenter Datenbankzustand vorliegen. Jede im DBMS enthaltene Integritätsregel muss spätestens beim Abschluss der Transaktion erfüllt sein. An einer umfassenden Konsistenzerhaltung ist natürlich auch die Anwendung beteiligt, weil es praktisch unmöglich ist, alle Anforderungen in Form von vorab festgelegten Nebenbedingungen der Datenbank zu realisieren.

13 Das Transaktionskonzept Isolation Die Datenbank muss so erscheinen, wie wenn sie jedem Benutzer dediziert zur Verfügung stehen würde. Laufen mehrere Transaktionen gleichzeitig ab, so müssen diese so gesteuert werden, dass sie die Anfrageergebnisse durch eine sequentielle Abarbeitung erzielt werden können. Formal wird dies erreicht, in dem die Operationen serialisierbar sind, als ein seriell ausgeführtes Analogon haben. Hierzu werden Sperrverfahren eingesetzt: 1-Phasen-Sperren: Sperren gehen den Freigaben voraus.

14 Das Transaktionskonzept Dauerhaftigkeit Nach Abschluss einer Transaktion sind die von ihr ausgeführten Änderungen nachhaltig. Hierzu müssen die Daten gegen alle Arten von Ausfällen gesichert werden. Auch Prozessabstürze und Plattenfehler dürfen nicht zu Datenverlust führen. Beispielfragen: Was passiert, wenn das RZ abbrennt (o.ä.)?

15 Das Transaktionskonzept Die Ablaufsteuerung in einem DBMS Das DBMS empfängt die Benutzeranfragen und kontrolliert deren Ausführung. Jede Manipulation durchläuft zum Ende der Transaktion die im DBMS verankerten Konsistenzregeln: Wertebereich (Kontostand > 0) Nebenbedingungen (Gehalt eines Mitarbeiters muss unter dem des Managers liegen) Das DBMS nutzt die Kenntnis aller Operationen einer Transaktion zur Implementierung von Sperrverfahren. Diese ermöglichen die Isolation nebenläufiger Transaktionen.

16 Drei Dateiebenen Die Daten eines Anwendungsbereiches werden auf unterschiedlicher Weise gesehen (Benutzer, Systemprogrammierer, ) Drei unterscheidbare Dateiebenen Die konzeptionelle Gesamtsicht (konzeptuelles Modell). Alle Daten müssen auf logischer Ebene in Form von Informationseinheiten und deren Beziehungen untereinander beschrieben werden, unabhängig von EDV- Gesichtspunkten (Sicht des Datenbankdesigner). Die Interne Sicht (Organisation der Daten auf dem Speicher); (Sicht des Systemadministrators). Die externe Sicht: Jeder Nutzer sieht den Ausschnitt der Datenbank, der für ihn von Bedeutung ist. (Sicht des einzelnen Benutzers). Jede Ebene modelliert die Daten auf einem anderen Abstraktionsniveau. Die Beschreibung einer solchen Ebene heißt Schema.

17 Die drei Datenebenen A1 A1 A1 A1 A1 A1 Ext. Schema Ext. Schema Ext. Schema Externes Modell Logische Datenunabh. Konzeptuelles Schema Konzeptuelles Modell Physische Datenunabh. Internes Schema Internes Modell HW

18 Logische Datenunabhängigkeit Die logische Datenunabhängigkeit besagt, dass ein Datenbestand und seine Zusammenhänge für verschiedene Anwendungen aus unterschiedlichen Perspektiven interpretiert werden können. Jedes auf der Datenbank arbeitende Programm hat eine eigene, spezifische Sicht auf die Datenbank. So können beispielsweise die im Programm angezeigten Tabellen von den tatsächlichen Tabellen abweichen /z.b. weniger Attribute haben oder mehrere Tabellen sind zu einer verschmolzen). Die logische Speicherung der Daten kann somit geändert werden (neue Attribute hinzufügen, Attribute löschen..) ohne dass die auf den Daten arbeitenden Programme geändert werden müssen (allenfalls das Löschen kann kritisch sein).

19 Physikalische Datenunabhängigkeit Physikalische Datenunabhängigkeit bezieht sich darauf, dass Anwenderprogramme sich nicht um die interne Speicherung und Verwaltung der Daten kümmern müssen. So sollten Datenbanktuning oder Erweiterung von Speicherstrukturen keine Auswirkungen auf Anwendungsprogramme haben. Die phyisikalische Organisation der Daten bleibt für die auf der Datenbank arbeitenden Programme verborgen. Die Programme brauchen sich also nicht um Dinge wie Zugriffspfade oder Speicherstrukturen zu kümmern. Die physikalische Speicherung der Daten kann somit geändert werden, ohne dass die auf den Daten arbeitenden Programme geändert werden müssen.

20 Das konzeptionelle Modell Das konzeptionelle Modell beschreibt die Gesamtheit der Daten des Anwendungsbereiches einer Datenbank, die verwaltet werden sollen. Alle wesentlichen Daten und deren Beziehungen zueinander werden beschrieben, in denen sie in der Realität existieren. Beschreibung der Integritätsbedingungen (Bedingungen, die immer gelten) und Dokumentation der Zugriffsrechte. Beschreibung von Operationen, die mit Daten ausgeführt werden.

21 Das konzeptionelle Modell Das konzeptuelle Modell wird mit einer Datenbeschreibungssprache (DDL = Data Definition Language) beschrieben. Änderungen der Daten werden mit einer Datenmanipulationssprache (DML = Data Manipulation Language) erreicht. Datenbanksysteme bieten üblicherweise generische Operationen an (Löschen, speichern, lesen, neu, ). Achtung: Datenbanksysteme vs. Informationssysteme: Informationssysteme: Gesamtheit aller Instanzen und Prozesse, die für den Anwendungsbereich wichtige Informationen von außen aufnehmen, verarbeiten und wieder nach außen abgeben. Datenbanksysteme: Teil von Informationssystemen.

22 Das konzeptionelle Modell Vorteile des konzeptionellen Modells: Das konzeptionelle Modell stellt einen stabilen Bezugspunkt für alle Anwendungen dar. Es ändert sich nur, wenn sich die Vorstellung über den Anwendungsbereich ändert. Das konzeptionelle Modell stellt eine einheitliche Dokumentation wesentlicher Aspekte des Anwendungsbereichs dar. Das konzeptuelle Modell bietet die Möglichkeit, den Gebrauch der Daten an zentraler Stelle zu kontrollieren. Das konzeptuelle Modell schafft die wesentliche Vorraussetzung für die Datenunabhängigkeit der Anwendungsprogramme.

23 Das konzeptionelle Modell der TERRA-Datenbank Die verschiedenen Objekttypen: Land, Berg, Tal, Ebene, Fluss, Institution, und deren Eigenschaften: Name, Größe, Die Beziehungen: Hat_sitz_in, geht_über, ist_benachbart;

24 Das interne Modell Der Datenbankadministrator entwickelt eine physikalische Datenorganisation, so dass die im konzeptionellen Modell beschriebenen Begriffe ableitbar sind. Statistische Informationen sind nötig über die Häufigkeit von Zugriffen auf Objekte, Zeitbeschränkungen für Anwendungen, Verteilen von Werten für Attribute, Das interne Schema umfasst Festlegungen zu folgenden Punkten: Repräsentation von Attributwerten Aufbau gespeicherter Sätze Zugriffsmethoden auf Sätze und Indexstrukturen Das interne Modell bestimmt maßgeblich das Leistungsverhalten des gesamten Datenbanksystems. Weder das externe noch das konzeptuelle Modell sind von Änderungen des internen Schemas betroffen (physische Datenunabhängigkeit).

25 Das interne Modell In kommerziellen System sind eine Reihe von Entwurfsentscheidungen vorweggenommen. Es stehen für Beziehungen und Zugriffspfade nur eingeschränkte Möglichkeiten zur Verfügung. In den Transformationsregeln konzeptuelles/internes Schema wird die Beziehung zwischen den physischen abgespeicherten Feldern und den Objekten des konzeptuellen Schemas angegeben. Muss zur Verbesserung des Systemverhaltens die physische Datenorganisation verändert werden, so müssen die Transformationsregeln ebenso geändert werden. Das konzeptuelle Modell bleibt aber unberührt. (z.b. Anordnen von Datafiles eines Tablesspaces auf eine andere Platte, aufgrund von Performance).

26 Das externe Modell Die integrierte Modellierung der Anwendungsdaten im konzeptionellen Modell bedeutet nicht, dass jeder Benutzer mit der Gesamtheit der Daten arbeiten muss oder darf. Jeder Benutzer bekommt nur die für ihn relevanten Daten (Sicht View). (z.b. GIS oder Telefonbuch) Die Beschreibung des externen Modells erfolgt in den externen Schemata. In den Transformationsregeln externes/konzeptuelles Schema muss angegeben werden auf welche Weise Entities und Beziehungen aus den Objekten des konzeptuellen Modells zusammengesetzt werden.

27 Das externe Modell Sprachemittel für den Zugriff auf die Datenbank DML und DDL Eigenständige Abfrage Sprachen (Query Language) SQL Nicht-eigenständige Übliche Programmiersprachen mit DML-Befehlen COBOL PL/1 Eigenständige Abfragesprachen können meist in üblichen Programmiersprachen eingebettet sin. rs.open SELECT * FROM Projekt WHERE PR_Nr= &piid

28 Aufgaben eines Datenbanksystems Realisierung von Methoden zur interaktiven Verwaltung und Bereitstellung der Daten. Implementierung der Datenmodelle und deren Zugriffsstrukturen mittels formalisierter Sprache. Gezieltes Ausliefern von Daten an Anwendungen auf der Basis von Anfragen. Diese werden interpretiert und optimiert! Sammeln statistischer Daten zwecks Optimierung. Redundanzfreie Datenhaltung des gesamten Datenbestandes. Konsistenzsicherung Daten werden gegenüber zuvor definierten Eigenschaften überwacht. (z.b. durch Daten Dictionary; enthält Beschreibungen der Daten zusammen mit etwaigen Konsistenzregeln) Nur konsistente Änderungen sind möglich.

29 Aufgaben eines Datenbanksystems Mehrbenutzerbetrieb Skalierbarkeit des Systems. Spezielle Zugriffsstrategien sollen einen schnellen Zugriff auf die Daten ermöglichen. Z.B. durch die Optimierung von Benutzeranfragen. Sicherstellen der Nebenläufigkeit von Anfragen. (gleichzeitige Änderung von Datensätzen) Unterstützung von großen Datenbeständen. Datenschutz und Datensicherheit Authentifizierung von Benutzern Erweiterte Zugriffskontrolle (z.b. Digitale Signaturen) Ausgefeilte Sicherungs- und Recovery-Möglichkeiten (z.b. Point in Time Sicherungen; Schattendatenbanken etc.) Auch bei Systemabstürzen bleibt ein konsistenter Datenbankzustand erhalten.

30 Weitere Komponenten des DBS Tools Abfragesysteme Report Writer Tools für den Datenbankentwurf CASE Tools Utilities Laderoutinen Fehleranalyseroutinen Routinen zur Datenreorganisation Archivierungsroutinen DC-Systeme (Data Communication Center) Terminals

31 Beispiel: Tools eines DBS

32 Datenunabhängigkeit Die dreischichtige Architektur ist der Schlüssel zur Datenunabhängigkeit. Physikalische Datenunabhängigkeit: Änderungen der physikalischen Datenorganisation lassen sich durch Modifikationen der Transformationsregeln abfangen. Logische Datenunabhängigkeit bedeutet Isolierung der Anwendungsprogramme vor Änderungen des konzeptuellen Modells (Hinzufügen von Attributen, ) Statische und dynamische Datenunabhängigkeit Heutige DBMS bieten unterschiedliche Grade von Datenunabhängigkeit an.

33 Ein Datenmodell für die konzeptionelle Ebene Die Beschreibung der Datenwelt eines Anwendungsfalles erfolgt in den Begriffen eines Datenmodells. Das Datenmodell muss mächtig genug sein, um alle wichtigen Aspekte der Realwelt beschreiben zu können. (z.b. ERP) Es gibt derzeit kein kommerzielles DBS, das ein befriedigendes Datenmodell bzw. eine DML anbietet, die mächtig genug ist um alle Aspekte der Realwelt zu erfassen. Man unterscheidet daher ein semantisches Modell (Realwelt) vom konzeptuellen Modell in DBMS-Begriffen.