schmiedecke · © schmiedecke 06 DB2 – DBMS-Typen 2 Auswertung der Praxis Dieselbe DB auf 3 verschiedenen DBMS Bis auf kleinere Unterschiede (z.B. Literale) egal, womit man

1. Einführung:1.2 Typen von DBMS

��

� � ��

© schmiedecke 06 DB2 – DBMS-Typen 2

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.


Datenhaltung in Dateien

• Logische Datenstruktur im Anwendungsprogramm"verdrahtet"

• Physische Abbildung auf Dateiformat im Anwendungs-programm "verdrahtet"

Änderung im Programm � �

Änderung der Dateistruktur

Gegenseitige Gefährdung der Anwendungen

Anwendung Datenbestand Daten inder Anwendung

1 - 5

Anw. 1

Anw. 2

Anw. 3

Datum 1

Datum 2

Datum 3

1

2

3

4

5

© P.Sauer


Datenhaltung in Gemeinsamer Datenbasis• Vereinbarte Datenstruktur• evtl. gemeinsame externe

Spezifikationsdatei

• Vereinbartes Speicher-und Dateiformat

• evtl. Abstraktion durch Lese-Schreib-Werkzeug

Durch Auslagerung von Datenstrukturbeschreibung und Dateizugriff wächst die Datenunabhängigkeit

Anw. 1

Anw. 2

Anw. 3

Anw. n

Daten-basis

Spez.

I/O


DBMS• 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

Anw. 1

Anw. 2

Anw. 3

Anw. n

Daten-basis

DD.

DBMS


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.


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, ...)


Datenmodelle� Verschiedene Abstraktionsstufen:

– 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)


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.


Datenbestand Keramische WerkstattBestellungen:• Datum• Name• Strasse• PLZ, Ort• Produktbez.• Preis• Anzahl

Kunden:• Name• Strasse• PLZ, Ort• Konto

Produkte• Bezeichnung• Größe • Glasur• Dekor• Preis

BuchhaltungLagerverwaltung

Materialeinkauf Werbung

Märkte:• Ort• Veranstalter• Termin

Lagerposten:• Produkt• Charge• Anzahl

Marktstände:• Markt• Produkte• Bestellungen• Umsatz• Erlös

Rohstoffe:•Bezeichnung•Lieferant•Preis


Hierarchisches DatenmodellDatenstruktur

LeitungOrtBetrieb

GlasurDekorTypStatusAnschriftName

PreisArtikelNrGesamtpreisStatusRe-Nr

Nr EinzelpreisDekorGlasurArtikelAnzahl


SchmidtLindauKeram.Werkstatt

GroßhändlerMaxMax Mayr

2 Fisch 53,70grauTeekanne3125

Hierarchisches DatenmodellBeispiel-Datensätze

PrivatkundeHanneHansen

GaleristJürgensJoseph

164,40Bestellung217

ohnegrau 30

361,80Kauf206

6 ohne 6,15grauTeller3016

6 Fisch 12,30grauSchale3117

60 Möve 6,30blauTeller2816

6,15Teller3016

12,10Schale3017

50,75Teekanne3025

Fischgrau 31


Hierarchisches DatenmodelleDiskussion

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


NetzwerkdatenmodellDatenstruktur

LeitungOrtBetrieb

GlasurDekorTypStatusAnschriftName

PreisArtikelNrGesamtpreisStatusRe-Nr

Anzahl


SchmidtLindauKeram.Werkstatt

GroßhändlerMaxMax Mayr

2

Netzwerk-DatenmodellBeispiel-Datensätze

PrivatkundeHanneHansen

GaleristJürgensJoseph

164,40Bestellung217

ohnegrau 30

361,80Kauf206

6

6

20

6,15Teller3016

12,10Schale3017

50,75Teekanne3025

Fischgrau 31

6,30Teller3116

12,80Schale3117

53,60Teekanne3125


Netzwerk-DatenmodellDiskussion

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”


��

� ��

� ��

� ��

�� !�� "� ��

� #�� $��

� #�� $��

% #��

� �� $��

�� !�� "#$� %�� #�� &��!'��

� !��&�� '��#(��)��

� *��&�� '��) + � �%�� %��

(� �!��

� � � '��#(��)��

� � � '��#(��)��

� � � '��#(��)��

� '��) +

�� $�� $)� *�� +�� ,� -�� #��+��

� '�,�� &�#(��)�� '�� -��

� �� . ��+�� / �� ) �� 0&�1

Geschäftspartner

Wird angeboten auf

Märkte

Produkte

Das Relationale DatenmodellStruktur und Beispiel-Datensätze

Struktur

Daten


Das Relationale DatenmodellDiskussion

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


Das objektorientierte DatenmodellStruktur

+preisÄndern()+ausSortimentEntfernen()

-Artikelnr-Bezeichnung-Preis

Produkt-Typ-Dekor-Glasur

Serie

-Name-Ort-Geschäftsführung : Geschäftspartner

Betrieb

+StatusÄndern()

-Name-Anschrift-Status

Geschäftspartner

+PositionHinzufügen()+StatusÄndern()

-Datum-Status-Gesamtpreis

Auftrag

-Anzahl

Auftragsposition

1*1

1..*

0..*

1

1..*1

1

0..*

1 1..*


Name = KeramWerkstattOrt = LindauGeschäftsführung : Geschäftspartner

KeramischeWerkstatt : Betrieb

Name = Max MayrAnschrift = Dorfkern7 LindauStatus = Großhändler

MaxMayr : Geschäftspartner

Name = Hanne HansenAnschrift = ImWald 9 SerrauStatus = Privatkunde

HanneHansen : Geschäftspartner

Name = Joseph JürgensAnschrift = Markt22 KarmenStatus = Galerist

JosephJürgens : GeschäftspartnerDatum = 02-09-06Status = bestelltGesamtpreis = 164,40

118833 : Auftrag

Datum = 10-08-06Status = gekauftGesamtpreis = 381,80

107720 : Auftrag

ArtikelnrBezeichnungPreis

Teller : Produkt

ArtikelnrBezeichnungPreis

KlSchale : Produkt

Artikelnr = 3117Bezeichnung = Schale gr.Preis = 13,09

Schale : Produkt

Typ = 30Dekor = ohneGlasur = grau

Serie30 : Serie

Typ = 31Dekor = FischGlasur = grau

Seria31 : Serie

Anzahl = 20

Pos1 : Auftragsposition

Das objektorientierte DatenmodellBeispieldatenstruktur


Das objektorientierte DatenmodellDiskussion

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.


Beispiel für direkte OODB-Anbindungdurch 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)

{ ... }

// ...

}


Physische Datenmodelle� Regeln die Abbildung der logischen Struktur auf Speichermedien

– Implementierbarkeit durch Referenzmodelle gesichert– in Anwendungsfall oft Optimierungsbedarf

�Kriterien: Zugriffs- und PlatzeffizienzDatenschutz 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


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)

Weiter mit SQL....

� INNER und OUTER JOIN� Aggregatfunktionen�GROUP und ORDER


Abfragen über mehrer Tabellen (Joins)

�Intuitive Formulierung nach SQL-86:

�� ! �� "��# �� "�� $ � �� % �& ' (

SELECT [DISTINCT] AuswahllisteFROM Quelle1, Quelle2, Quelle3, ...WHERE Where-VerbundklauselAND Where-Klausel;

JOIN nach SQL-86


Abfragen über mehrer Tabellen (Inner Joins)

�Benutzung des JOIN-Operators:

�� ) � *� � �� "��# �� "�� $ � �� % �& ' (

�Vereinfachungen bei gleichen Spaltennamen und evtl. Eindeutigkeit

�� ) � *� � �� + �*�, �� ! �� % �& ' (

�� + � � ��) � *� � �� ! �� % �& ' (

SELECT [DISTINCT] AuswahllisteFROM Quelle1 JOIN Quelle2ON Where-VerbundklauselAND Where-Klausel;

JOIN nach SQL-92


Abfragen über mehrer Tabellen (Outer Joins)

�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� � �� "��# �� "��(

SELECT [DISTINCT] AuswahllisteFROM Quelle1 OUTER JOIN Quelle2ON Where-VerbundklauselAND Where-Klausel;

JOIN nach SQL-92


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


Aggregatfunktionen

�� 8 , 9, �� :�� ;� ��."! 5 7 ;�� 8 , 9*� 7 � .�:�� ;� ��."*� 7 � .�;�� 8 , 9 �� :�� ;� ��." �� ;� � � � � �� ! �� .�� <= � � � � <(�

�� *�9 �� :� � � � � �� ! �� .�� <= � � � � <(

SELECT Funktion1(Spalte1), Funktion2(Spalte2),...FROM QuelleWHERE Where-Klausel;

Zeilenwertiges Select

SELECT Funktion (Spalte) FROM QuelleWHERE Where-Klausel;

Skalares Select

��01�� 0�� 0��

�%��

��2��3�

��


Aggregatfunktionen

�� + ��9��:�� ;�� 5 > ;� � � � � �� (

�� + ��9? :�� ;�� 5 > ;� � � � � �� (

�� + ��9? :� � �;� � � � 7 .�� .� �� ;� � � � � �� ! �� $ � � ��# �;� �� .;(�

�� 4��

�

��

�


Gruppieren

��$ � � �� 8 , 9 �� :�� ;� ��." �� ;� � � � � �� , � � + �� @ �$ � � �(

��$ � � �� 8 , 9 �� :�� ;� ��." �� ;� � � � � �� , � � + �� @ �$ � � �! � 8 *�, �, .� � ��.�� ;= � �� = ;(

SELECT Funktion1(Spalte1), Funktion2(Spalte2),...FROM QuelleWHERE Where-KlauselGROUP BY Spalte ;

Gruppiertes Aggregat

SELECT Funktion1(Spalte1), Funktion2(Spalte2),...FROM QuelleWHERE Where-KlauselGROUP BY Spalte HAVING Bedingung;

Gruppiertes Teil-Aggregat

�� 0��

$��

��

� ��

!��

�� 0��

$��

� ��


Sortieren

��$ � � ��, .� � �� 8 , 9 �� :�� ;� ��." �� ;� � � � � �� , � � + �� @ �$ � � �� $ �� @ �;� ��." �� ;�$ ��(

SELECT SpaltenFROM QuelleWHERE Where-KlauselGROUP BY Spalte [DESC | ASC];oder: ORDER BY Spalte [DESC | ASC]

GROUP BY sortiertORDER BY sortiert

SELECT Funktion1(Spalte1), Funktion2(Spalte2),...FROM QuelleWHERE Where-KlauselGROUP BY Spalte-n HAVING BedingungORDER BY Spalte-m;

Gruppiert, aggregiert undsortiert dann um.

�� 0��

$��

��

!�� "� ��

� ��

� ��

��

��

Documents

schmiedecke · © schmiedecke 06 DB2 – DBMS-Typen 2 Auswertung der Praxis Dieselbe DB auf 3 verschiedenen DBMS Bis auf kleinere Unterschiede (z.B. Literale) egal, womit man