1. Einführung: 1.2 Typen von DBMS
Auswertung der Praxis Dieselbe DB auf 3 verschiedenen DBMS Bis auf kleinere Unterschiede (z.b. Literale) egal, womit man arbeitet Äquivalent: Gleiches Datenmodell (Relationale Datenbanken) Ist das Datenunabhängigkeit? Sogar auf höherer Stufe... Dank SQL-Normung sogar unabhängig vom DBMS In der Praxis werden Prototypen oft mit einem einfachen (kostenlosen) DBMS entwickelt und dann auf das Produktions- DBMS migriert. Datenunabhängigkeit setzt früher an: Unabhängigkeit der Anwendung von der logischen und physischen Datenstruktur und umgekehrt. schmiedecke 06 DB2 DBMS-Typen 2
Datenhaltung in Dateien Anwendung Datenbestand Daten in der Anwendung Anw. 1 1 Datum 1 1-5 Logische Datenstruktur im Anwendungsprogramm "verdrahtet" Anw. 2 2 3 Datum 2 Datum 3 Physische Abbildung auf Dateiformat im Anwendungsprogramm "verdrahtet" Anw. 3 4 5 P.Sauer Änderung im Programm Änderung der Dateistruktur Gegenseitige Gefährdung der Anwendungen schmiedecke 06 DB2 DBMS-Typen 3
Datenhaltung in Gemeinsamer Datenbasis Vereinbarte Datenstruktur evtl. gemeinsame externe Spezifikationsdatei Anw. 1 Anw. 2 Anw. 3 Datenbasis Vereinbartes Speicherund Dateiformat evtl. Abstraktion durch Lese-Schreib-Werkzeug I/O Anw. n Spez. Durch Auslagerung von Datenstrukturbeschreibung und Dateizugriff wächst die Datenunabhängigkeit schmiedecke 06 DB2 DBMS-Typen 4
DBMS Anw. 1 Anw. 2 Anw. 3 Anw. n DBMS Datenbasis DD. Gemeinsamer Zugriff auf änderbare formale Beschreibung der logischen Datenstruktur (DD) in genormten Datenmodell ("logisches Schema") Zugriff auf die physischen Daten nur über die abstrakte logische Struktur Programme sind unabhängig von der logischen und physischen Strukturierung der Daten schmiedecke 06 DB2 DBMS-Typen 5
Datenunabhängigkeit Datenunabhängigkeit bedeutet Entkopplung von Datenhaltung und Datennutzung Logische Datenunabhängigkeit: - Anwendungsprogramme müssen nicht die komplette logische Realisierung der Datenstruktur kennen, um mit den Daten arbeiten zu können. Physische Datenunabhängigkeit: - Anwendungsprogramme müssen die interne Datenorganisation (Speicher, Datei) und die Zugriffsmöglichkeiten nicht kennen, um mit den Daten arbeiten zu können. Was müssen Anwendungprogramme kennen? - abstrakte logische Struktur und ein Zugriffskalkül d.h. Datenmodell und DB-Sprache Entkopplungsbeispiel Milch: - Max muss nicht wissen, wie viel die Kuh frisst, von der die Milch stammt, damit ihm die Cornflakes schmecken. - Der Landwirt produziert und liefert Milch, ohne je von Max gehört zu haben. Beide kooperieren über den Handel und über Geld. schmiedecke 06 DB2 DBMS-Typen 6
Was ist ein Datenmodell? Kalkül zur Strukturierung von Informationen (Daten) Bietet Konzepte zur Datenabstraktion (Benennung von Teilmengen) Datensuche (Navigation, Retrieval) Datenmanipulation Beispiel Binäre Baumstruktur: Benennung von Knoten und Teilbäumen Traversierungsalgorithmen, Suchstrategien Baumoperationen zum Einhängen und Restrukturieren (Balancieren) Konzepte sind unabhängig von der Implementierung (Verkettete Listen, Indextabellen,...) schmiedecke 06 DB2 DBMS-Typen 7
Verschiedene Abstraktionsstufen: Datenmodelle Mengen, Objekte, Wissensräume,... ohne Bezug zur Implementierung (oder Implementierbarkeit) semantische Datenmodelle (oder abstrakte Datenmodelle) ERM, EERM, UML-Klassenmodell Listen, Bäume, Netze, Tabellen,... Implementierungs-Referenzmodell liegt zugrunde (Implementierbarkeit gesichert) logische Datenmodelle (oder konkrete Datenmodelle) HDM, NDM, RDM, ORDM, OODM Zeigerstrukturen, Indexdateien, Hashtabellen, Datenblöcke... Implementierung, Abbildung auf Speichermedien physische Datenmodelle (oder interne Datenmodelle) schmiedecke 06 DB2 DBMS-Typen 8
Logische Datenmodelle sind die Basis der Arbeit mit einer Datenbank stellen einen Mittelweg zwischen Realweltabbildung und Implementierung dar zur "technisch" für den Entwurf komplexer Datenbanken zu "abstrakt" für eine unmittelbare Abbildung auf Speichermedien. schmiedecke 06 DB2 DBMS-Typen 9
Kunden: Name Strasse PLZ, Ort Konto Marktstände: Markt Produkte Bestellungen Umsatz Erlös Datenbestand Keramische Werkstatt Buchhaltung Märkte: Ort Veranstalter Termin Bestellungen: Datum Name Strasse PLZ, Ort Produktbez. Preis Anzahl Lagerposten: Produkt Charge Anzahl Lagerverwaltung Produkte Bezeichnung Größe Glasur Dekor Preis Rohstoffe: Bezeichnung Lieferant Preis Materialeinkauf Werbung schmiedecke 06 DB2 DBMS-Typen 10
Hierarchisches Datenmodell Datenstruktur Betrieb Ort Leitung Name Anschrift Status Typ Dekor Glasur Re-Nr Status Gesamtpreis Nr Artikel Preis Anzahl Nr Artikel Glasur Dekor Einzelpreis schmiedecke 06 DB2 DBMS-Typen 11
Hierarchisches Datenmodell Beispiel-Datensätze Keram.Werkstatt Lindau Schmidt Max Mayr Max Großhändler 30 grau ohne Hansen Hanne Privatkunde 31 grau Fisch Joseph Jürgens Galerist 3016 Teller 6,15 3017 Schale 12,10 217 Bestellung 164,40 3025 Teekanne 50,75 2 3125 Teekanne grau Fisch 53,70 6 3016 Teller grau ohne 6,15 6 3117 Schale grau Fisch 12,30 206 Kauf 361,80 60 2816 Teller blau Möve 6,30 schmiedecke 06 DB2 DBMS-Typen 12
Hierarchisches Datenmodelle Diskussion Charakteristika: historisch erstes Modell(1969 IMS) Datenstrukturen als Bäume Navigation entlang des Baumes zum Zugriff Realisierung der Zusammenhänge durch Zeiger (typischerweise) Vorteile: günstig für 1:N-Beziehungen (z.b. Stücklisten, Personaldateien,...) Abfragen, die den Baumstrukturen folgen, sehr effizient und schnell einfache Speicherstrukturen (sequentiell) Nachteile: Redundanz M:N-Beziehungen direkt nicht darstellbar -> Auflösung in 2x 1:N- Beziehungen Änderungen sehr aufwendig Quer -abfragen nicht unmittelbar möglich schmiedecke 06 DB2 DBMS-Typen 13
Netzwerkdatenmodell Datenstruktur Betrieb Ort Leitung Name Anschrift Status Typ Dekor Glasur Re-Nr Status Gesamtpreis Nr Artikel Preis Anzahl schmiedecke 06 DB2 DBMS-Typen 14
Netzwerk-Datenmodell Beispiel-Datensätze Keram.Werkstatt Lindau Schmidt Max Mayr Max Großhändler 30 grau ohne Hansen Hanne Privatkunde 31 grau Fisch Joseph Jürgens Galerist 3016 Teller 6,15 3017 Schale 12,10 217 Bestellung 164,40 3025 Teekanne 50,75 2 6 6 3116 3117 3125 Teller Schale Teekanne 6,30 12,80 53,60 206 Kauf 361,80 20 schmiedecke 06 DB2 DBMS-Typen 15
Netzwerk-Datenmodell Diskussion Charakteristika: Datenstrukturen in Form von Netzwerken (n Wurzeln, n Vorgänger) Navigation über definierte Zugriffspfade alle Beziehungen darstellbar (zusätzliche Zeiger) Vorteile: redundanzfrei auch M:N-Beziehungen effizient darstellbar Nachteile: Komplexität, Handhabbarkeit schwer überschaubar, schwer änderbar nur vorgedachte Abfragen schnell realisierbar -> Navigationspfad schmiedecke 06 DB2 DBMS-Typen 16
Geschäftspartner Das Relationale Datenmodell Struktur und Beispiel-Datensätze Märkte $ $) * +, - #+ ', &#() ' -. + / ) 0&1! "#$ % # &!'!& '#() *& ')+ % % Wird angeboten auf (! '#() '#() Struktur Produkte '#() ')+ Daten! " # $ # $ % # $ schmiedecke 06 DB2 DBMS-Typen 17
Das Relationale Datenmodell Diskussion Charakteristika: Datenstrukturen als zweidimensionale Tabellen Objekte / Entitäten Zeilen Attribute Spalten Verknüpfung von Tabellen über Attributübernahme Vorteile: Einfachheit, alle Beziehungen darstellbar redundanzarme Datenspeicherung (kontrollierte Redundanz) einfach erweiter-, änder-, abfragbar keine Zugriffspfade, sondern frei definierbare Abfragen Relationenalgebra, Integritätsbedingungen, NFL, SQL Nachteile: Probleme bei komplexen Datenstrukturen Performance bei Abfragen über viele Tabellen schmiedecke 06 DB2 DBMS-Typen 18
Das objektorientierte Datenmodell Struktur Betrieb -Name -Ort -Geschäftsführung : Geschäftspartner * 1 1 1..* Geschäftspartner -Name -Anschrift -Status +StatusÄndern() 1 Produkt -Artikelnr -Bezeichnung -Preis +preisändern() +aussortimententfernen() 0..* 1 Serie -Typ -Dekor -Glasur 0..* 1..* 1 Auftrag -Datum -Status -Gesamtpreis +PositionHinzufügen() +StatusÄndern() 1 1..* Auftragsposition -Anzahl schmiedecke 06 DB2 DBMS-Typen 19
Das objektorientierte Datenmodell Beispieldatenstruktur MaxMayr : Geschäftspartner Name = Max Mayr Anschrift = Dorfkern7 Lindau Status = Großhändler HanneHansen : Geschäftspartner Name = Hanne Hansen Anschrift = ImWald 9 Serrau Status = Privatkunde JosephJürgens : Geschäftspartner Name = Joseph Jürgens Anschrift = Markt22 Karmen Status = Galerist KeramischeWerkstatt : Betrieb Name = KeramWerkstatt Ort = Lindau Geschäftsführung : Geschäftspartner 107720 : Auftrag Datum = 10-08-06 Status = gekauft Gesamtpreis = 381,80 118833 : Auftrag Datum = 02-09-06 Status = bestellt Gesamtpreis = 164,40 Pos1 : Auftragsposition Anzahl = 20 Teller : Produkt Artikelnr Bezeichnung Preis KlSchale : Produkt Artikelnr Bezeichnung Preis Schale : Produkt Artikelnr = 3117 Bezeichnung = Schale gr. Preis = 13,09 Serie30 : Serie Typ = 30 Dekor = ohne Glasur = grau Seria31 : Serie Typ = 31 Dekor = Fisch Glasur = grau schmiedecke 06 DB2 DBMS-Typen 20
Das objektorientierte Datenmodell Diskussion Charakteristika: Sachverhalte der Realsphäre natürlich abbilden (ohne Zerlegung wie bei klassischen DM) Abbildung komplex zusammengesetzter Daten möglich Speicherung der Zugriffsoperationen auf den Daten gemeinsam mit Daten 2 Wege zur OODB: Ergänzung objektorientierter Programmiersprachen um Konzepte zur dauerhaften Datenhaltung in DBS (Persistenz, Transaktionen, Sperrmechanismen, etc.), keine Ad-hoc-Anfragen OODM Erweiterung Relationaler DBMS um objektorientierte Konzepte ORDM (SQL-1999) Vorteile: alle Beziehungen darstellbar effizienter Zugriff (Laufzeitsysteme, DB-Systeme) einfache Änder-, Erweiterbarkeit Nachteile: Standard (ODMG 97), aber Klasse von Modellen mit großen Unterschieden Handhabung zwar kompliziert, aber zunehmend etabliert Frameworks. schmiedecke 06 DB2 DBMS-Typen 21
Beispiel für direkte OODB-Anbindung durch Persistenz-Framework public persistent class Produkt { public persistent int Artikelnr; public persistent String Bezeichnung; public persistent double Preis; public static double MwSt; //... public atomic void PreisAendern(double Preis) {... } //... } schmiedecke 06 DB2 DBMS-Typen 22
Physische Datenmodelle Regeln die Abbildung der logischen Struktur auf Speichermedien Implementierbarkeit durch Referenzmodelle gesichert in Anwendungsfall oft Optimierungsbedarf Kriterien: Zugriffs- und Platzeffizienz Datenschutz und Datensicherheit Immer mehrere Ebenen: Abbildung im Speicher Ablage auf externen Medien (Platte, früher auch Band) Oft Gesamtredundanz (RAID-Systeme) Konzepte zur Datensicherung/Archivierung/Versionierung Konzepte zur Transaktionssicherung schmiedecke 06 DB2 DBMS-Typen 23
Administration und Tuning Administrator kann das physische Modell beeinflussen: Beispiele aus Relationalen Datenbanken: Wahl zwischen Implementierungsmodellen (z.b. MySQL: ISAM, MyISAM, MERGE, HEAP, BerkeleyDB, InnoDB) Caching-Verhalten (HEAP!) Initial- und Standardgröße von Dateien, Datenblöcken, Pages Datei-Organisation: index-sequentiell, Hash, Tree Dateiformat: - CSV, binär, XML, proprietär... Tabellen-Indexe zur Zugriffsbeschleunigung Die Verwaltung von Rechten und Transaktionen erfolgt auf dieser Abstraktionsebene: Zugriffe auf Dateien (nicht auf Tabelle und Attribute) schmiedecke 06 DB2 DBMS-Typen 24
Weiter mit SQL... INNER und OUTER JOIN Aggregatfunktionen GROUP und ORDER
Abfragen über mehrer Tabellen (Joins) SELECT [DISTINCT] Auswahlliste FROM Quelle1, Quelle2, Quelle3,... WHERE Where-Verbundklausel AND Where-Klausel ; JOIN nach SQL-86 Intuitive Formulierung nach SQL-86:! " # " $ % & ' ( schmiedecke 06 DB2 DBMS-Typen 26
Abfragen über mehrer Tabellen (Inner Joins) SELECT [DISTINCT] Auswahlliste FROM Quelle1 JOIN Quelle2 ON Where-Verbundklausel AND Where-Klausel ; JOIN nach SQL-92 Benutzung des JOIN-Operators: ) * " # " $ % & ' ( Vereinfachungen bei gleichen Spaltennamen und evtl. Eindeutigkeit ) * + *,! % & ' ( + ) *! % & ' ( schmiedecke 06 DB2 DBMS-Typen 27
Abfragen über mehrer Tabellen (Outer Joins) SELECT [DISTINCT] Auswahlliste FROM Quelle1 OUTER JOIN Quelle2 ON Where-Verbundklausel AND Where-Klausel ; JOIN nach SQL-92 OUTER JOIN bedeutet, dass auch Zeilen gelistet werden, für die die Verknüpfung nicht gilt ggf. mit NULL-Wert für die fehlenden Attribute: + ) * -.. / 0 " # " (-1 2 3 4 5.6 7 0 + ) * -.. " 0 " # " ( schmiedecke 06 DB2 DBMS-Typen 28
Aggregatfunktionen Funktionen, die eine Spalte zu einem Wert aggregieren: 2 ( 2.*" 2 (/ 2 2 " SELECT-Anweisungen mit Aggregatfunktionen aggregieren eine Tabelle zu einer Zeile meistens nur eine Spalte selektiert skalares Ergebnis schmiedecke 06 DB2 DBMS-Typen 29
Aggregatfunktionen SELECT Funktion1(Spalte1), Funktion2(Spalte2),... FROM Quelle WHERE Where-Klausel ; SELECT Funktion (Spalte) FROM Quelle WHERE Where-Klausel ; Zeilenwertiges Select Skalares Select 8, 9, : ;."! 5 7 ; 8, 9* 7.: ;."* 7.; 8, 9 : ;." ;!. <= <( *9 :!. <= <( 01 0 0 2 3 % schmiedecke 06 DB2 DBMS-Typen 30
Aggregatfunktionen + 9 : ; 5 > ; ( 4 + 9?: ; 5 > ; ( + 9?: ; 7.. ;! $ # ;.;( schmiedecke 06 DB2 DBMS-Typen 31
Gruppieren SELECT Funktion1(Spalte1), Funktion2(Spalte2),... FROM Quelle WHERE Where-Klausel GROUP BY Spalte ; SELECT Funktion1(Spalte1), Funktion2(Spalte2),... FROM Quelle WHERE Where-Klausel GROUP BY Spalte HAVING Bedingung; $ 8, 9 : ;." ;, + @ $ ( Gruppiertes Aggregat Gruppiertes Teil-Aggregat 0 $ $ 8, 9 : ;." ;, + @ $! 8 *,,.. ;= = ;(! schmiedecke 06 DB2 DBMS-Typen 32 0 $
Sortieren SELECT Spalten FROM Quelle WHERE Where-Klausel GROUP BY Spalte [DESC ASC]; oder: ORDER BY Spalte [DESC ASC] GROUP BY sortiert ORDER BY sortiert SELECT Funktion1(Spalte1), Funktion2(Spalte2),... FROM Quelle WHERE Where-Klausel GROUP BY Spalte-n HAVING Bedingung ORDER BY Spalte-m; $,. 8, 9 : ;." ;, + @ $ $ @ ;." ;$ ( Gruppiert, aggregiert und sortiert dann um. 0 $! " schmiedecke 06 DB2 DBMS-Typen 33