Datenbanken Entwurf und Design.

Slides:



Advertisements
Ähnliche Präsentationen
Algorithmen und Datenstrukturen
Advertisements

Überblick über die Datenbankproblematik
ER-Datenmodell und Abfragen in SQL
Datenbankdesign mit ACCESS.
Zur Rolle der Sprache bei der Modellierung von Datenbanken
Datenbanken Einführung.
Folien 2-5, 7-8 © Prof. Dr. Manfred Rössle (FH Aalen)
spezielle Nutzersichten formale Ebene (deskriptive Regeln)
Datenmodellierung Externe Phase Informationsstruktur
Objekt – Relationales – Modell Tomasz Makowski IN
MS Office-Paket: Access
Das Entity-Relationship-Modell
Systemüberblick Beispiele: Microsoft Access Oracle Ingres Informix
Kapitel 3: Das Relationenmodell
Franziska Schmidt Sarah Ahlheit
Colibi Bibliothekssystem der Computerlinguistik. Einführung Motivation Was braucht Colibi? Software Datenbankdesign.
Anfragesprachen – Dipl. Ing. Ulrich Borchert / FH Merseburg1/7 Datenbanken werden als Anhäufung von Werten eines Wertebereiches aufgefasst und Datenbankabfragen.
Themenschwerpunkte Übung 3:
Algorithmentheorie 04 –Hashing
Daten bank St. Wiedemann.
Datenbankentwurf mit Hilfe des ER-Modells entwickeln
IS: Datenbanken, © Till Hänisch 2000 CREATE TABLE Syntax: CREATE TABLE name ( coldef [, coldef] [, tableconstraints] ) coldef := name type [länge], [[NOT]NULL],
Datenbanken Einführung Merkmale dateiorientierte Datenverwaltung
SQL 2 Order by null Aggregatfunktionen group by Join subselect.
Datenintegrität Referentielle Integrität create table
Einführung Dateisystem <-> Datenbanksystem
Datenmodellierung - Aufbau einer Datenbank -
Buch S73ff (Informatik I, Oldenbourg-Verlag)
Abfragen – Tipps und Tricks Buch S102ff (Informatik I, Oldenbourg-Verlag) Nach einer Vorlage von Dieter Bergmann.
20:00.
Die Grundterminologie
Datenbank.
Betrieb von Datenbanken Marco Skulschus & Marcus Wiederstein Datenmanipulation Lehrbuch, Kapitel 4.
Überblick über die Datenbankproblematik
Vorlesung #2 Datenbankentwurf
SS 2010 – IBB4C Datenmanagement Fr 15:15 – 16:45 R Vorlesung #2 Datenbankentwurf.
WS 2011/12 Datenbanksysteme Mi 15:15 – 16:45 R Vorlesung #9 Physische Datenorganisation.
Vorlesung #4 Überführung des ER-Modells in das relationale Modell
WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R Vorlesung #7 SQL (Teil 4)
WS 2013/14 Datenbanksysteme D0 15:15 – 16:45 R Vorlesung #5 SQL (Teil 2)
Vorlesung #4 Überführung des ER-Modells in das relationale Modell
Allgemeines zu Datenbanken
HORIZONT 1 XINFO ® Das IT - Informationssystem PL/1 Scanner HORIZONT Software für Rechenzentren Garmischer Str. 8 D München Tel ++49(0)89 / 540.
(D.h. „Hallo MausFans!“ auf Japanisch).
Datenbanksysteme für hörer anderer Fachrichtungen
Einführung in Datenbankmodellierung und SQL
Freiwillige Feuerwehr der Stadt Perg
Symmetrische Blockchiffren DES – der Data Encryption Standard
Vorlesung #10 Physische Datenorganisation
verstehen planen bearbeiten
Normalisierungsprozess
SQL - Structured Query Language AIFB SS (1/9) Join-Operationen in SQL-92(1/9) Syntax einer Join-Operation: join-op := CROSS JOIN | [NATURAL]
Relationale Datenbanken
1 (C)2006, Hermann Knoll, HTW Chur, FHO Quadratische Reste Definitionen: Quadratischer Rest Quadratwurzel Anwendungen.
ADAT©2004 Dipl. - Ing. Walter SabinSeite: 19 Version 1.0a Programme - Zusatzsoftware Oracle: –Forms –Reports –Designer –Jdeveloper –APEX (Application Express)
Schutzvermerk nach DIN 34 beachten 20/05/14 Seite 1 Grundlagen XSoft Lösung :Logische Grundschaltung IEC-Grundlagen und logische Verknüpfungen.
SS 2014 – IBB4C Datenmanagement Do 17:00 – 18:30 R Vorlesung #2 Datenbankentwurf.
Einführung Dateisystem <-> Datenbanksystem
WS 2014/15 Datenbanksysteme D0 15:15 – 16:45 R Vorlesung #6 SQL (Teil 3)
SS 2014 – IBB4B Datenmanagement Do 17:00 – 18:30 R Vorlesung #4 Überführung des ER-Modells in das relationale Modell.
Gerhard Röhner September 2012
WS 2014/15 Datenbanksysteme Do 17:00 – 18:30 R Vorlesung #9 SQL Zusammenfassung.
SS 2015 – IBB4C Datenmanagement Fr 17:00 – 18:30 R Vorlesung #4 Überführung des ER-Modells in das relationale Modell.
Vom Konzept zur Datenbank
BHAK/BHAS 1 Salzburg KIDM 2ASBS Schuljahr 2004/05
SQL Basics Schulung –
DOAG SID Data Warehouse
Kapitel 6: Datenbanksysteme
Administrieren und Arbeiten mit Datenbanken und SQL
(Structured Query Language)
 Präsentation transkript:

Datenbanken Entwurf und Design

Inhaltsübersicht Vorbemerkungen Datenspeicherung Bewertung der Datenorganisation Logische Datenorganisation Datenbankarchitektur Datenmodellierung Entity-Relationship-Modell (ERM) Vorgehensweise Das relationale Datenmodell ERM - RDM Daten normalisieren Daten integrieren Relationenalgebra Standard Query Language (SQL) JOIN Systemarchitektur Join-Design Sort-Merge-Join Transaktionssteuerung Speicher- und Zugriffssteuerung ORACLE 7.1 Datenbankstruktur Speicheroptimierung Dynamische Datenbanksystemstruktur

Grundlagen

Datenspeicherung Datenspeicher Datenspeicher mit Direktzugriff sequentieller Datenspeicher Datenspeicher mit Direktzugriff Magnetbänder Magnetkassetten Magnetplatten Disketten optische Speicher Halbleiterspeicher Spur 0 Sektor Zylinder Datenblock Anlaufzone Bremszone Spur Bandsprosse

Logische Datenorganisation Baumstruktur Netzstruktur

Welche Anforderungen sollte ein Datenbankmanagementsystem erfüllen? Redundanzfreiheit Kein Datenelement soll in der Datenbank mehrfach gepeichert sein; der Speicherplatz ist optimal auszunutzen. Vielfachverwendbarkeit (Anwendungsunabhängigkeit) Die Datenbank soll so aufgebaut sein, daß sie möglichtst viele Funktionsbereiche bedienen kann. Jeder Benutzer, für den die gespeicherten Daten von Bedeutung sind, soll mit der Datenbank arbeiten können. Benutzerfreundlichkeit Der Umgang mit der Datenbank soll leicht erlernbar sein. Mit möglichst geringem Aufwand sollen möglichst viele Funktionen des Datenbanksystems eingesetzt werden können Flexibilität Es muß möglich sein, die Struktur der Datenbank, unabhängig von den bestehenden Anwendungen, zu ändern. Es sollten Backups im laufendem Betrieb möglich sein.

Welche Anforderungen sollte ein Datenbankmanagementsystem erfüllen? Unabhängigkeit von Betriebssystemen Die Datenbank sollte ein offenes System sein, d.h. das Wechseln von Hard- und/oder Software sollte keine Anpassungsschwierigkeiten mit sich bringen. Wirtschaftlichkeit Das System sollte möglichst geringe Betriebskosten verursachen. Abfragen und Datenmanipulationen sollten mit möglichst wenig Plattenzugriffen erfolgen. Datenintegrität Datenschutz, Datensicherheit und Datenkonsistenz sollten vom System weitgehend unterstützt werden. (Beispiele: Wiederanfahrhilfen, Transaktionserkennung, Passcodeverwaltung, Rollback, Logbuch usw.)

Logische Datenorganisation - Tabelle FNR FNAME FSEM DAUER TAG ZEIT_VON ZEIT_BIS ZAHL 1 Grundlagen der Betriebswirtschaftslehre 2 B 90 08.07.1993 830 1000 320 2 Finanz- und Investitionswirtschaft 4 B 90 15.07.1993 830 1000 200 3 Marketing 4 B 90 14.07.1993 1130 1300 250 4 Material- und Fertigungswirtschaft 4 B 90 09.07.1993 1100 1230 200 5 Personalführung 4 B 90 08.07.1993 1400 1530 160 6 Buchführung und Bilanzierung 2 B 90 09.07.1993 830 1000 380 7 Kosten- und Leistungsrechnung 4 B 90 13.07.1993 1330 1500 200 8 Wirtschaftsmathematik 2 B 90 12.07.1993 830 1000 320 9 Betriebsstatistik 2 B 90 14.07.1993 830 1000 360 10 Grundlagen der Volkswirtschaftslehre 2 B 90 13.07.1993 830 1000 320 11 Wirtschaftsprivatrecht 4 B 90 12.07.1993 1130 1300 180 12 Englisch 1 2 B 60 24.06.1993 830 930 290 12 Französisch 1 2 B 60 24.06.1993 1330 1430 40 Sichten Anwender Informatik Datenverarbeitung Mathematik Tabelle Datenobjekt Datei Relation Tabellenzeile Entität Datensatz Tupel Tabellenspalte Wertebereich Datenfeld Domäne Tabellenelement Attributswert Datenelement Wert Tabellenüberschrift Attribute Datenfeldbezeichnung Spaltenbezeichnung Attribut (Eigenschaft) Datenfeld Attribut

Entitätstyp - Entität Die Entität (Entity) ist das konkrete, individuell identifizierbare Objekt bzw. Exemplar von Dingen, Personen oder Begriffen der realen oder der Vorstellungswelt, für das (auf einem Datenträger) Sachverhalte festzuhalten sind. Beispiele: Individuen: Mitarbeiterin Brech, Schüler Weber... Reale Objekte: Maschine 2, Raum 7, Artikel 4711... Ereignisse:Zahlung,Buchung, Mahnung,Start,Landung... Abstraktes: Unterricht, Dienstleistung, Verarbeitungsart, Zahlungsart... Die Entität ist Mitglied einer Gruppe (Klasse), dem Entitätstyp. Der Kunde Müller ist ein konkretes individuell identifizierbares Objekt, über den Informationen abgespeichert werden müssen. Er gehört zur Gruppe der Kunden. Man kann auch sagen, er ist vom Entitätstyp Kunden. Alle Informationen, die über Kunden abgespeichert werden, sind von der Struktur her gleich.

Attribute Ein Attribut ist jede Einzelheit, die dazu dient, eine Entity zu qualifizieren, zu identifizieren, zu klassifizieren, zu quantifizieren oder ihren Status auszudrücken. "Welche Informationen müssen Sie über das Objekt (Entity) haben oder speichern?" Das Attribut muß die Entity beschreiben, unter der es aufgeführt ist. Jede Entity muß eindeutig identifizierbar sein und mindestens zwei Attribute besitzen.

Attribut Attribute beschreiben die Entitäten. Beispiel: Kunde(KdNr, KName, KAdresse,......) Man unterscheidet zwischen identifizierenden Attributen (z.B.: KdNr, FirmenNr, PersNr....) beschreibenden Attributen (z.B.: KName, MitarbeiterName, ArtikelBez, .....

Beziehungstyp - konkrete Beziehung Zwischen den Entitätstypen Firma und AZUBI besteht ein Beziehungstyp „ist beschäftigt bei”. Wenn es einen solchen Beziehungstyp gibt, so kann (muß) eine konkrete Beziehung zwischen einem Paar der dazu gehörenden Entitäten bestehen: Beziehungsattribute sind die beschreibenden interessierenden Merkmale der Beziehung. Beispiel zwischen Schüler und Fächern: „belegt“

Nützliche Beziehungsendnamen arbeiten unter, Nützliche Beziehungsendnamen arbeiten unter, Chef sein von, auslösen, ausgelöst werden von, belegt, wird belegt, bestellen, bestellt werden in, betrieben werden von, Betreiber sein von, empfangen, gehen an, erhält, ist für, erteilen, erteilt werden von, erteilt, wird erteilt von, erteilt von, Auftraggeber von, erteilt werden, verantwortlich sein für, führt zu, entstehen aus, für, Gegenstand von, gehören zu, umfassen, gekauft werden von, Lieferant sein von, ist in, umfasst, Teil sein von, zusammengesetzt sein aus, Teil von, bestehen aus, Teilnehmer sein von, sein für, unterbreitet für, wird unterbreitet, unterrichtet, wird unterrichtet, wird bestellt in, wird erteilt für ...

Datenbankarchitektur Externes Schema Raumbe- legung Prüfungs- liste Prüfungs- aushang Aufsichten- einteilung ERM konzeptionelles Schema Prüfung Aufsicht Prüfungsfach Dozent internes Schema Basistabellen Basistabellen DBMS

Entity-Relationship-Modell (ERM) Beziehungsarten 1 : 1 identifizierende Beziehung z.B. Student hat Matrikelnummer charakterisierende und klassifizierende Beziehung z.B. Semestergruppe hat Student 1 : n nicht eindeutige Beziehung, sie muß im Rahmen der Datennormalisierung aufgelöst werden. Beispiel: Student besucht Vorlesung n : m

erweitertes Entity-Relationship-Modell (eERM) 1. Optionale Beziehungen Eine Beziehung ist optional, wenn sie auch den Wert "NULL" haben kann : 1 : c Student Note Student hat Note c : c Student Parkplatz Student belegt Parkplatz c : n Fachbereich Parkplatz Fachbereich hat Parkplätze in der Tiefgarage 1 : cn Fachbereich Student Fachbereich hat Studenten (Ausnahme FB13) c : cn Student Buch Student hat Buch ausgeliehen n : cm Student Vorlesung Student besucht Vorlesung cn : cm Bauteil Bauteil Bauteil enthält Bauteil (Stückliste)

erweitertes Entity-Relationship-Modell (eERM) 2. Min-Max-Notation Relation Entitäts- menge A (a,b) (c,d) menge B 1. Ein Element der Entitätsmenge A steht in Relation mit mindestens c Elementen der Entitätsmenge B höchstens d Elementen der Entitätsmenge B 2. Ein Element der Entitätsmenge B steht in Relation mit mindestens a Elementen der Entitätsmenge A höchstens b Elementen der Entitätsmenge A 3. Gilt b > 1 und d > 1 so erweitert sich die Relation zu einer Beziehungsentität 4. Die Beziehungsentität enthält die Schlüsselattribute der verknüpften Entitätsmengen als Kombinationsschlüssel Relation Entitäts- menge A 1 : m n : 1 menge B

Vorgehensweise 1. Schritt : Sammeln der Datenelemente Datenliste PS Datenfeld Typ Länge NULL Entität Alias Beschreibung PS : Primärschlüssel [Ja / Nein] Datenfeld : Bezeichnung des Datenfeldes, wie es gespeichert werden soll Typ : Datentyp (z.B. Integer, Währung, Text, ext.) Länge : maximale Zahl der Zeichen pro Wert NULL : leeres Datenfeld zulässig? [Ja / Nein] Entität : Welcher Entitätsmenge wird das Datenfeld zugeordnet Alias : Alternative Bezeichnungen für das Datenfeld Beschreib. : Weiter Angaben zum Datenfeld (z.B. zulässige Werte etc.)

Vorgehensweise 2. Schritt : Datenobjekte (Entitäten) finden Auftrag Datenliste PS Datenfeld Typ Länge NULL Entität Alias Beschreibung J AUFNR INT 10 N Auftragsnummer DATUM DAT 8 N Auftragsdatum ARTNR INT 10 N Artikelnummer ARTIKEL TXT 80 J Artikelbezeichnung KNR INT 10 N Kundennummer Auftrag KNAME TXT 50 J Kundenname Artikel Kunde

Vorgehensweise 3. Schritt : Beziehungen zwischen den Entitätsmengen beschreiben und n:m-Beziehungen auflösen (->Verbindungsentität) Kunde erteilt einen oder mehrere Aufträge Ein Auftrag ist eindeutig einem Kunden zugeordnet Ein Auftrag enthält einen oder mehrere Artikel Ein Artikel ist in keinem, einem oder mehreren Aufträgen enthalten Kunde (1,1) erteilt (1,n) (0,n) (1,n) enthält Auftrag Artikel (1,1) (1,1) (1,n) (1,n) enthält Auftrags- position enthält

Vorgehensweise 4. Schritt : Schlüssel- und Datenfelder den Entitätsmengen zuordnen und die Entitätsmengen in die Datenliste eintragen Über die Schlüsselfelder werden die Entitätsmengen miteinander verknüpft. Die Kundennummer (KNR) erscheint in der Entitätsmenge Auftrag als Fremdschlüssel und stellt die Verbindung zur Entitätsmenge Kunde her. Kunde ert (1,1) Auftrag Artikel Auftrags- position enthält (1,n) KNR KNAME KADRESSE AUFNR DATUM ARTNR ARTIKEL PREIS MENGE

Vorgehensweise 5. Schritt : Konsistenz- und Integritätsbedingungen beschreiben Konsistenz Die gespeicherten Daten müssen in sich und zur Realität widerspruchsfrei sein. Integrität Die gespeicherten Daten müssen vollständig und korrekt sein. Datentypkonsistenz z.B.: Ein Schlüsselfeld muß stets vom gleichen Datentypusein. Schlüsselkonsistenz [eindeutiger Wert, nicht NULL] Wertebereichkonsistenz Ist der zulässige Wertebereich kleiner als die dem Datentyp entsprechende Wertemenge, so muß der Wertebereich festgelegt und dem System für die Eingabekontrolle mitgeteilt werden. Beziehungsintegrität Welche Werte darf ein Fremdschlüssel annehmen? [nur Werte eines PS, auch NULL, jeden Wert] Wie ist im Falle einer Löschung bzw. Änderung zu verfahren? Die Löschung/Änderung des Primärschlüssels führt zur Löschung der Datensätze in denen der Schlüssel enthalten ist löscht/ändert den Schlüsselwert wird nur durchgeführt, wenn kein Datensatz mit dem Schlüsselwert existiert. rechnerische Konsistenz z.B. sind die systembedingten Rundungen von Dezimalzahlen akzeptabel Logik des Geschäftsvorfalls Wann dürfen welche Daten eingegeben werden? Die Ausführung eines Auftrags erfolgt erst nach Eingang der Zahlung.

Das relationale Datenmodell Entity-Relationship-Modell relationales Datenmodell Entität = Datenobjekt Relationship = Beziehung Relation = zweidimensionale Tabelle Student Student ( Mtnr, Name, SemGr, Adresse) Mtnr Name Entität Schlüsselattribut SemGr. Relation mit einem identifizierenden Schlüsselattribut Adresse

ERM - RDM Student ( Mtnr, Name, SemGr, Adresse) belegt Vorlesung Mtnr Name SemGr Adresse Vorlnr Fach Semester Raum Zeit Student ( Mtnr, Name, SemGr, Adresse) Fach ( Vorlnr, Fach, Semester, Raum, Zeit) Belegung (Mtnr, Vorlnr)

Daten normalisieren 1. Normalform Eine Relation ist in der 1. Normalform, wenn kein Attribut enthalten ist, zu dem es pro Datensatz mehrere Attributswerte geben kann, d.h. wenn in jeder Zeile und Spalte nur atomare, nicht weiter zerlegbare Werte gespeichert werden. Auftrag (Aufnr, Artikelnr, Artikelbezeichnung, Menge, Preis, Kundennr, Kundenname, Adresse, Datum) Auftrag (Aufnr, Kundennr, Kundenname, Adresse, Datum) Bestellartikel (Aufnr, Artikelnr, Artikelbezeichnung, Menge, Preis) Primärschlüssel Zusammengesetzter Schlüssel

Daten normalisieren 1. Normalform Als Beispiel sollen die Tourendaten verwendet werden. Die Tabelle Tourendaten genügt nicht der 1. NF, da die dritte Spalte noch weiter aufgeteilt werden könnte. Die geteilten Tabellen und entsprechende Beziehung zueinander erfüllt die 1. NF Tourendaten (TourendatenNr, Bezeichnung, Länge, Termine) TourenZiele (TourenNummer, Tour, Kurzbeschreibung,Länge, Grad, Start, Ziel) TourenTermine (TourTerminNr, TourenNummer, Beginn, Ende , MaxTeilnehmer) Primärschlüssel Zusammengesetzter Schlüssel

Daten normalisieren Gilt nur bei zusammengesetztem Primärschlüssel! 2. Normalform Eine Relation ist in der 2. Normalform, wenn sie in der 1. Normalform ist und keine Attribute enthält, die in einer 1:1 Beziehung zum Primärschlüssel oder Teilen des Primärschlüssels stehen, d.h. jede Spalte die nicht zum Primärschlüssel gehört, ist vom kompletten PS abhängig. Auftrag (Aufnr, Kundennr, Kundenname, Adresse, Datum) Bestellartikel (Aufnr, Artikelnr, Artikelbezeichnung, Menge, Preis) Auftrag (Aufnr, Kundennr, Kundenname, Adresse, Datum) Bestellartikel (Aufnr, Artikelnr, Menge) Artikel (Artikelnr, Artikelbezeichnung) Preis (Artikelnr, Preis)

Daten normalisieren 3. Normalform Eine Relation ist in der 3. Normalform, wenn sie in der 2. Normalform ist und keine Attribute enthält, die untereinander abhängig sind. Auftrag (Aufnr, Kundennr, Kundenname, Adresse, Datum) Bestellartikel (Aufnr, Artikelnr, Menge) Artikel (Artikelnr, Artikelbezeichnung) Preis (Artikelnr, Preis) Auftrag (Aufnr, Kundennr, Datum) Kunde (Kundennr, Kundenname) Anschrift (Kundennr, Adresse) Bestellartikel (Aufnr, Artikelnr, Menge) Artikel (Artikelnr, Artikelbezeichnung) Preis (Artikelnr, Preis)

Daten integrieren Auftrag 1 : n Kunde Auftrag (Aufnr, Kundennr, Datum) Kunde (Kundennr, Kundenname) Anschrift (Kundennr, Adresse) Bestellartikel (Aufnr, Artikelnr, Menge) Artikel (Artikelnr, Artikelbezeichnung) Preis (Artikelnr, Preis) 1 : n 1 : 1 Anschrift Bestellartikel n : 1 1 : 1 Artikel Preis Auftrag (Aufnr, Kundennr, Datum) Kunde (Kundennr, Kundenname, Adresse) Bestellartikel (Aufnr, Artikelnr, Menge) Artikel (Artikelnr, Artikelbezeichnung, Preis)

Datenbankdesign 1 An der RBS soll ein Schulverwaltungsprogramm erstellt werden. In dieser Datenbank sind Informationen zu Lehrfächern, Schüler, Lehrer und Klassen festzuhalten. Folgende Fragen sollen beantwortet werden können: Bei welchem Lehrer hat ein Schüler Unterricht? Aus welcher Klasse kommt ein Schüler? Welche Fächer belegt ein Schüler? Welche Fächer gibt ein Lehrer? In welchen Klassen unterrichtet ein Lehrer? Welche Noten hat ein Schüler in seinen belegten Fächern? . Entwerfen Sie zu diesem Problem ein Entity-Relationship-Diagramm. Bestimmen Sie die Relationen (Tabellen) und die dazugehörigen Attribute. Kennzeichnen Sie die Primär- und Fremdschlüssel

Anwendungsentwicklung und Datenbankadministration

Beispiele UNION : Aus den Tabellen "Kunde" und "Vorgang" wird eine Tabelle erzeugt. INTERSECTION : Aus den Tabellen "Kunde" und "Vorgang" werden alle Kundennummern mit einem offenen Vorgang in eine Tabelle gestellt. DIFFERENCE : Aus den Tabellen "Kunde" und "Vorgang" werden alle Kunden selektiert, die keinen offenen Vorgang aufweisen. CARTESIAN PRODUCT : Aus den Tabellen "Vorgang" und "Fahrzeug" wird eine Tabelle erzeugt. PROJECTION : Alle Kundennamen aus der Kundentabelle. SELECTION : Aus der Kundentabelle alle Daten des Kunden mit K# = 4711. JOIN : Alle Kunden mit Adresse aus den Tabellen "Kunde" und "Adresse". DIVISION : Alle Fahrzeuge, die in allen Angeboten enthalten sind.

Structured Query Language (SQL) Funktionen Datendefinition [DDL] CREATE ALTER DROP CREATE TABLE Student Mtknr, char(8), Name, char(30), SemGr, char(6); Datenmanipulation [DML] SELECT UPDATE INSERT DELETE SELECT Name FROM Student WHERE SemGr= "10BW4A"; Kontrolle und Steuerung GRANT LOCK COMMITT ROLLBACK GRANT USER Regier IDENTIFIED BY "Dozent" ;

JOIN SELECT <merkmal> [,<merkmal>, ...] FROM tabelle [, tabelle, ...] WHERE <selektionsprädikat> [AND <selektionsprädikat>] ; Bulk-Join => ohne WHERE-Klausel (kartesisches Produkt) Teta-Join => mit WHERE-Klausel Natural-Join => identische Spalten werden nur einmal angezeigt. Semi-Join => Nur Spalten einer Tabelle (senkt das Kommunikationsvolumen bei verteilter Datenhaltung Multiple-Join => Join mit mehr als zwei Tabellen Outer-Join => Datensätze der ersten Tabelle, denen keine Datensätze der zweiten Tabelle zugeordnet werden können, werden mit einem leeren Datensatz verknüpft. Restricted-Join => Durch AND werden weitere Bedingungen eingefügt Equi-Join => Bedingung enthält nur Gleichheitszeichen Auto-Join => Join einer Tabelle auf sich selbst Vergleichende Bewertung Inner schneller als Outer Equi schneller als Non-Equi Restricted schneller als NO-Restricted

Systemprozeß Ad Hoc Abfrage Anwendungsprogramm Systemnutzung (Job-Design) Optimierung durch eine zweckmäßige Reihenfolge der Operationen (algebraische Optimierung) Optimierung der JOIN-Operationen Übersetzung und Optimierung Systemadministration Datensicherheit Vermeidung von Dateninkonsistenz Vermeidung von Blockaden bei der Nutzung verteilter Systeme Transaktionen- und Cursorverwaltung Speicher- und Zugriffsverwaltung Systemkonfiguration Optimierung der Zugriffszeiten durch Systemauswahl und Konfiguration Systemtabellen Benutzertabellen Datenbankdesign Optimierung der Datenbankstruktur (ERM / RDM) optimale Größe der Tablespaces und Extens

Parsing SQL-Befehle werden als Text an das Datenbankmanagementsystem übermittelt. Dieses muß den Text lesen und interpretieren (Parsing). Parsing benötigt etwa die Hälfte der Antwortzeit. Bekannte SQL-Befehle werden (von den meisten DBMS) wiedererkannt und müssen nicht erneut das Parsing durchlaufen (Shared SQL) Allerdings müssen die Befehle absolut identisch sein! Für SQL-Befehle wird ein Hash-Wert errechnet und im Library Cache gespeichert. Nutzung durch Bind Variables, die anstelle von Werten im SQL-Text verwendet werden, verhindert ein erneutes Übersetzen. lexikalische Analyse Tabellensuche Spaltenattributsuche Typ- und Constraint-Ver- gleich für die Spaltenattribute Sperrung (Parse Lock) Berechtigungsprüfung Ausführungsplanung

Optimierung Für die Ausführung der übersetzten SQL-Befehle erstellt das DBMS einen Ausführungsplan, wobei vom DBMS Optimierungsregeln eingesetzt werden. Regelbasierte Optimierung Die SQL-Befehle werden nach festen Regeln analysiert und die Reihen-folge der Operationen danach fest-gelegt. (siehe folgende Seite) Aufwandbezogene Optimierung Hierbei werden internen Statistiken und Strukturmerkmale der Daten-bank (z.B. Indizes) analysiert um den schnellsten Weg zu den gesuchten Daten zu finden. Oracle ab Version 7 Manuelle Optimierung Durch einen Kommentar im SELECT Befehl kann ein Ausführungshinweis an den Optimierer gegeben werden. SELECT /* FULL */ name, . FROM.. Über den Befehl EXPLAIN PLAN sind bei Oracle (nicht leicht zu lesende) Informationen über das tatsächlich gewählte Optimierungsverfahren zu erhalten.

ALTER TABLE <tabellenname> CACHE; Tabellengröße Bei kleinen Tabellen ist ein vollständiges Lesen der Tabelle schneller als eine Selektion. Häufig benötigte kleine Tabellen können im Cache gepuffert werden: ALTER TABLE <tabellenname> CACHE; Bei großen Tabellen spielen Indizes eine herausragende Rolle. Index-Selektivität Ein eindeutiger Schlüssel (Primärschlüssel) liefert die höchste Selektivität mit dem Wert 1. Je größer der Wert, um so mehr Datensätze werden im Fall eines SELECT Befehls gelesen. Bei Oracle heißt der Wert "badness". Er kann für jedes Attribut errechnet werden, um festzustellen, ob es als Indexfeld geeignet ist.

Cache least recently used (LRU) SQL-Statements Triggers Library Cache Functions Stored Procedures Im Library Cache werden aufgerufene Befehle gespeichert, um bei einem wiederholten Aufruf des gleichen Befehls eine schnellere Ausführung zu erreichen. Dies gelingt jedoch nur dann, wenn der Anwendungsentwickler gebunden Variablen verwendet, so daß die SQL-Statements, Functions etc. identisch sind. Datenbankadministrator und Anwendungsentwickler müssen bei der Optimierung der Datenbankanwendungen zusammenarbeiten!

Join-Design Datum Name = "Müller" (Name = "Müller" SELECT Datum FROM Kunde, Auftrag WHERE = Kunde.KNR = Auftrag.KNR AND Name = "Müller" Datum Name = "Müller" Tabelle := Datum (Name = "Müller" (Kunde |X| Kunde.KNR = Auftrag.KNR , Auftrag )) |X| Kunde.KNR = Auftrag.KNR Tabelle := Datum (Auftrag.KNR, Datum (Auftrag) (|X| Kunde.KNR = Auftrag.KNR ) Kunde.KNR (Name = "Müller"(Kunde))))) Kundentabelle Auftragstabelle Im Rahmen des Join-Design wird bei einer Datenabfrage darauf geachtet, daß der zu untersuchende Datenbestand möglichst klein gehalten wird. SELECT Datum FROM (SELECT KNR, Datum FROM Auftrag WHERE AUFTRAG.KNR = (SELECT KNR FROM Kunde WHERE Name = "Müller")))

Fakten- und Dimensionstabellen Faktentabellen enthalten die betriebswirtschaftlich relevanten numerischen Meßgrößen wie Umsatz, Kosten, Leistung. Dimensionstabellen liefern Angaben zu den Dimensionen (z.B. Zeit, Kunde, Mitarbeiter, Artikel) auf die sich die Faktentabellen via Schlüsselattribute beziehen. Join ist die Verbindung zwischen zwei Tabellen wobei häufig eine Faktentabelle mit einer Dimensionstabelle verbunden wird (z.B. Kunde -Auftrag). Ein Join ist grundsätzlich nur zwischen zwei Tabellen möglich. Zur Verknüpfung mehrere Tabellen bestehen zwei alternative Verfahren: Paarweise Join Star-Abfrage

Paarweise Join versus Star-Abfrage Faktentabelle Auftrag Dimensionstabelle Kunde Dimensions- tabelle Kunde Dimensions- tabelle Artikel Dimensions- tabelle Lieferant JOIN Zwischenergebnis 1 Auftrag & Kunde Dimensionstabelle Artikel Kartesisches Produkt Kunde & Artikel & Lieferant Faktentabelle Auftrag JOIN Zwischenergebnis 2 Auftrag & Kunde & Artikel Dimensionstabelle Lieferant JOIN Abfrageergebnis Auftrag & Kunde & Artikel & Lieferant JOIN Abfrageergebnis Auftrag & Kunde & Artikel & Lieferant Eigenschaften: - viele Operationen - kleine Zwischentabellen Eigenschaften: - wenige Operationen - große Zwischentabelle Effizient bei großen Datenmengen Effizient bei kleinen Datenmengen

Sort-Merge-Join n x m Operationen KNR Name Adresse 4711 Müller 81243 München 5612 Maier 71324 Stuttgart 3254´ Huber 12312 Berlin AUFNR Datum KNR 2137 12.10.97 4711 2231 13.10.97 3254 2178 15.10.97 4711 2337 12.10.97 5511 n x m Operationen KNR AUFNR 4711 2137 2231 2178 2337 5612 2137 .......... Vorsortierung beider Tabellen nach dem Vergleichsattribut KNR Name Adresse 3254 Huber 12312 Berlin 4711 Müller 81243 München 5612 Maier 71324 Stuttgart AUFNR Datum KNR 2231 13.10.97 3254 2137 12.10.97 4711 2178 15.10.97 4711 2337 12.10.97 5511 max: n + m Operationen

Speicher- und Zugriffssteuerung (1) Mehrwegbaum (B*-Tree)  05  10  15  01 02 03 04 06 07 08 09 11 12 13 14 16 17 18 19 RID physische Zeilenadresse [ROW ID] (oder Liste mit Zeilenadressen) Die Indexdatei ist hierarchisch unterteilt. Beim Suchen nach dem Datenfeld mit dem Wert 12 sind statt 12 nur 4 Vergleichsoperationen erforderlich. Eigenschaften: Gute Performanz bei hoher Kardinalität, d.h. das Suchkriterium weist eine hohe Zahl unterschiedlicher Wertausprägungen im Verhältnis zu den Tabellenzeilen auf. Schlechte Performanz bei der Suche nach nicht indizierten Datenfeldern mit geringer Kardinalität.

Speicher- und Zugriffssteuerung (2) Bitmap-Indizierung Für jede Ausprägung einer zu indizierenden Tabellenspalte wird eine Bitfolge angelegt, die kennzeichnet, ob in der entsprechenden Zeile der Tabelle der Wert anzutreffen ist (1) oder nicht (0). Geschäftskunde 1 0 0 0 1 0 0 0 1 1 1 1 1 0 1 0 1 .... Privatkunde 0 1 1 1 0 1 1 0 0 0 0 0 0 1 0 1 0 .... Sonstige 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 .... Merkmalsausprägung Bitmap-Index Eigenschaften: extrem platzsparend bei geringer Merkmalszahl Bei 1.000.000 Kundensätzen werden 3 Mio. Bit = 375 KB benötigt. Im Vergleich dazu benötigt das B*-Tree Verfahren dazu 4MB. Allerdings benötigt jede weitere Ausprägung 125 KB. Bei Häufigkeitszählungen entfällt der Zugriff auf die Tabelle. Schnell bei kombinierten Abfragen Bei T Tupeln braucht jede einzelne Bitliste T/8 Bytes. Bei W verschiedenen Attributwerten sind das insgesamt W*(T/8) Bytes. Für Trefferlisten basierend auf Tupel-Identifikatoren - wie in B+ - Bäumen werden (bei einwertigen Attributen) T*4 Bytes benötigt (4 Bytes pro Tupel-Id.). Bei mehrwertigen Attributen ändert sich der Aufwand für Bitlisten nicht, bei Tupel-Id.-Listen erhöht er sich auf f*T*4, wobei f die durchschnittliche Anzahl von Werten pro Tupel ist (f > 1). Der Speicherbedarf für Bitlisten ist also günstiger, wenn W*(T/8) < 4*f*T, d.h. W < 32*f. Bei Anfragen mit vielen konjunktiven Termen der Art (A1=C1) and (A2=C2) and (A3=C3) and ... müssen die meisten Attribute geringe Selektivität haben, wenn eine nennenswerte Resultatmenge entstehen soll. Beispiel: Sei T=10 , die Zahl der Terme 4, und die Größe der Ergebnismenge 10 . Dann muß (bei statistischer Unabhängigkeit) jeder Term eine mittlere Selektivität von 10 haben, d.h. jedes Attribut hat W=10 Werte. (Für derartige Selektivitäten würde kein B-Baum-Index eingerichtet, d.h. die Anfrage müßte durch sequentielles Lesen bearbeitet werden.) Bei einer Tupellänge von 1KB muß 1GB sequentiell verarbeitet werden. Da die Tupelschnittstelle einen typischen Durchsatz 0.5 MB/s hat, dauert die Anfrage 2000 sec. Für eine Bitliste können wir ca. 10 Seiten ansetzen, d.h. es müssen 40 Seiten wahlfrei gelesen werden; das dauert 1 sec. Die und-Verknüpfung der Bitlisten kann vollständig im Hauptspeicher durchgeführt werden; der Zeitbedarf ist vernachlässigbar. Danach müssen 100 Tupeln wahlfrei gelesen werden; das dauert 2.5 sec. Zusammen mit evtl. indirekten Schreiboperationen im Puffer liegt der Zeitbedarf bei ca. 4 sec. - eine Verbesserung um den Faktor 500.

Komprimierung von Bitmaps (1) 0100 1011 0101 1000 0110 1110 1100 1011 1010 0110 111000001100000000000000000010110000000000000000000010100110 Rekonstruierte Bitliste Darstellung erfordert 10 4-Bit-Blöcke für insgesamt 256 4-Bit-Blöcke

Komprimierung von Bitmaps (2) 1 k ......... Bitmuster oder Nullfolge Kenn- Bit Ist das Kenn-Bit gleich 1, werden die folgenden k-1 Bits als unkompri- mierte Bitfolge interpretiert. Ist das Kenn-Bit gleich 0, so wird der Inhalt der folgenden k-1 als binäre Ganzzahl interpretiert, die angibt, wieviele aufeinander folgende 0-en auf diese Weise komprimiert dargestellt werden. Je weniger 1en in der Bitfolge eines Wertes auftreten, desto wirksamer ist die Komprimierung. Noch effizientere Verfahren resultieren aus der Verwendung mehrerer Kennbits.

Auswertung komplexer Verbundoperationen Dimensions- Relationen Kunde Produkt Filiale Branche Produkt- Gruppe Region Detail - Relation Bestell-Nr. Kunden-Nr. Artikel-Nr. Filial-Nr. Menge Datum SELECT SUM(Menge) FROM Bestellung, Kunde, Produkt, Filiale WHERE Bestellung.Kunden-Nr. = Kunde.Kunden-Nr. AND Bestellung.Artikel-Nr. = Produkt.Artikel-Nr. AND Bestellung.Filial-Nr. = Filiale.Filial-Nr. AND Kunde.Branche = ‘Elektronik’ AND Produkt.Produktgruppe = ‘Telefon’ AND Filiale.Region = ‘Nord’; Bitlisten-Indizes für die Relation Bestellung können z.B. über folgenden Attributen eingerichtet werden: Kunde.Branche Produkt.Produkt-Gruppe Filiale.Region Der Optimierer kann für die vorliegende Anfrage einen Ausführungsplan generieren, der nur die Indizes benutzt. Ohne diese Indizes ist ein 3-Wege-Join notwendig. Informix XPS bietet z.B. einen solchen Index. Performance-Vergleich Betrachtet wurden drei Anfragen (Relation R hat 500,000 Tupeln): Q1: Select count(*) from R where A1=C1; (Ergebnis: 240,000) Q2: Select count(*) from R where A1=C1 and A2=C2; (Ergebnis: 480) Q3: Select count(*) from R where A3>C3; (Ergebnis: 1,200) DSS- Anfrage

Grundformen verteilter Datenbanken Verteilung kompletter Tabellen auf verschieden Server mit der Folge, daß bei einem Join auf zwei Server zugegriffen werden muß. Dieses Verfahren beherrschen die meisten DBMS, wobei die verteilten Datenbanken auf unterschiedlichen Plattformen laufen können. Verteilung einer Tabelle auf verschiedene Server ist bei sehr großen Tabellen erforderlich, wobei sowohl eine horizontale als auch eine vertikale Teilung möglich ist. Tabelle 1 Tabelle 2 Tabelle 2 horizontal Die vertikale Teilung einer Tabelle kommt der im Rahmen der Normaliserung durchgeführten Teilung nahe, entspricht also dem Fall 1. Problem ist allerdings, daß bei einem Zeilenweisen Zugriff auf die Tabelle mehrere Zugriffe erforderlich sind. Besser ist deshalb die horizontale Teilung. Sie unterstützt auch die betriebswirtschaftliche Bedeutung der Daten. Z.B. lassen sich die Kundendaten in den zuständigen Filialen speichern. Diese ideale Form der Datenverteilung bei großen Dateien wird allerdings von keinem der Datenbankmanagementsysteme beherrscht. Lokal verwendet man das "Partionieren" um eine Tabelle auf mehrere Festplatten zu verteilen. Bei verteilten Systemen bedient man sich eine Datenbankspiegelung (Verwendung identischer Datenbanken). Es liegt also kein verteiltes System vor, sonder eine Verbindung von Datenbanken. Das zwingt den Entwickler, den Zugriff auf die Datenbanken durch geeignete Zugriffsmechanismen selbst zu regeln. vertikal

Lösungen für die Speicherung großer Tabellen Array-Speicher Speichermedien sind miteinander verkettet; Fassungsvermögen mehrere Terabytes; Problem: Datensicherung Raid-Array Plattenkombinationen mit redundanter Datenspeicherung. Vorteil: Ausfallschutz; Plattenteile können bei laufendem Betrieb ausgewechselt werden. Nachteil: Langsame Verarbeitung; Schutz bezieht sich aber nur auf physische Fehler. Logische Fehler wirken sich hingegen redundant und ggf. irreparabel aus. 64-Bit-Technologie Mit ihr lassen sich bis zu 2 Gigabyte im Hauptspeicher bearbeiten, beschleunigt folglich die Prozesse ohne jedoch das Problem der Massendatenspeicherung zu lösen. Mehrprozessorsysteme Hierzu fehlen bislang entsprechende Betriebs- und Datenbankmanagementsysteme, die dieses Leistungspotential ausschöpfen. Objektorientierte Datenbanken Vom Denkansatz versprechen sie eine zweckmäßige Lösung über die Instanzenbildung. Aktuelle OODBMS leisten dies jedoch noch nicht.

Datensicherung Zweck Verfahren Technik Organisation Zweck der Datensicherung ist die Wiederherstellung eines konsistenten Datenbestandes nach einem Störfall. Verfahren Komplettsicherung Es werden immer alle Daten gesichert. Differenzsicherung Es werden nur die Änderungen zur vorhergehenden Datensicherung gespeichert. Technik Die von den Betriebssystemen UNIX und Windows angebotenen Sicherungssysteme sind für eine professionelle Sicherung großer Datenbestände nicht geeignet. Von Anbietern für Großraumspeicher werden entsprechende Managementsysteme angeboten. Organisation Datensicherungsplan Es ist in einem Plan festzuschreiben, wie die Datensicherung durchzuführen ist. Notfallplan Der Notfallplan beschreibt das Vorgehen bei der Rekonstruktion der Datenbestände nach einem Störfall.

Richtlinien zur Verwaltung der Speicherressourcen Trenne Data Dictionary- und Benutzerdaten. Trenne die Daten unterschiedlicher Anwendungen. Speichere Tablespaces auf verschiedenen Platten um I/O-Konflikte auszuschließen. Trenne Rollbacksegmente von Datensegmenten, um den Verlust von Daten durch Plattenabsturz zu verhindern. Halte individuelle Tablespaces offline. Schränke die Datenbanknutzung für einen Tablespace ein auf high update performance read only activity temporary segment storage Mache Backups von individuellen Tablespaces Lege Default-Speicherparameter für Objekte fest, die in einer Tablespace angelegt werden sollen. Lege Default-Speicherparameter für eine Tablespace zur Verwaltung spezieller Objekte fest. Vergib Tablespace-Anteile an die Anwender. Oracle-Avices

Kostenfaktoren bei Datenbanksystemen Lizenz 2% Beratung 8% Entwicklung 20% Administration 60% Wartung Schulung Computerzeitung 7/98 Im Durchschnitt entfallen 60 % der Kosten eines Datenbanksystems auf die Systemadministration.

Datenbankadministration Datenadministration Benutzer- und Sicherheitsadministration Systemadministration Installation Datensicherung und -wiederherstellung Datenarchivierung Datenreorganisation Datenverifikation Laufzeitkontrolle Performance-Analyse und Tuning Auditing Massendatentransfer Datenadministration logischer und physischer Datenbankentwurf und Datenpflege Datenverifikation Sicherung der Datenkonsistenz soweit die nicht vom System übernommen wird. Auditing Nachträgliches Ermitteln, welcher Anwender welche Änderungen durchgeführt hat. Massendatentransfer Datenoperationen, die nicht mit einer DML (z.B. SQL) durchgeführt werden. Z.B Einspielen von Daten aus einer Nicht-Datenbank-Datei. Quelle: H. Schöning "Datenbankadministration" in Datenbank Rundbrief 17.5.1996 S. 77-81

Entity Relationship Modell