M1 Grundlagen Von DB

2
e
ng t e m
u
rles sys
Vo ns
t io
a
o rm Modul 1
f
In
Grundlagen von
Datenbanken
a.Univ.-Prof. Dr. Werner Retschitzegger
Department of
Einführung Konzeptionelle DM Realisierungs DM DB-Entwurf SQL
Inhalt
n Einführung
l Motivation und Historie
l Architektur
l Existierende Systeme
n Konzeptionelle Datenmodelle
n Realisierungs-Datenmodelle
n Datenbankentwurf
n SQL
Der vorliegende Foliensatz basiert vorwiegend auf:

n Gunter Saake, Kai-Uwe Sattler, Andreas Heuer: Datenbanken – Konzepte und Sprachen,
MITP Verlag, 6. Auflage, 800 Seiten, 2018
COOPERATIVE INFORMATION SYSTEMS, JKU Linz 2/113

Motivation
Ohne Datenbanken ... 1/2
n Basis- oder Anwendungssoftware verwaltet ihre eigenen

Daten in ihren eigenen (Datei-)Formaten
l Textverarbeitung: Texte, Artikel und Adressen
l Buchhaltung: Artikel, Adressen
l Lagerverwaltung: Artikel, Aufträge
l Auftragsverwaltung: Aufträge, Artikel, Adressen
l ...
n Daten sind redundant gespeichert – zahlreiche Probleme:

l Verschwendung von Speicherplatz
l „Vergessen“ von Änderungen (_ Anomalien)
l keine zentrale, „genormte“ Datenhaltung

Motivation
Ohne Datenbanken ... 2/2
n Andere SW-Systeme können große Datenmengen

nicht effizient verarbeiten
n Mehrere Benutzer oder Anwendungen können

nicht parallel auf den gleichen Daten arbeiten
n Anwendungsprogrammierer / Benutzer können Anwendungen

nicht programmieren / benutzen, ohne
l interne Darstellung der Daten
l Speichermedien oder Rechner
zu kennen – Datenunabhängigkeit nicht gewährleistet
n Datenschutz und -Sicherheit sind nicht gewährleistet

Motivation
Mit Datenbanken ... Datenintegration
n Die gesamte Anwendungs-SW arbeitet auf

denselben Daten
l z.B. Adressen und Artikel werden nur einmal gespeichert
n DBS können große Datenmengen effizient verwalten
l Anfragesprachen, Optimierung, Interne Ebene
n Benutzer können parallel auf DB arbeiten
l Transaktionskonzept
n Datenunabhängigkeit
l Drei-Ebenen-Konzept
n Datenschutz
l kein unbefugter Zugriff
n Datensicherheit
l kein ungewollter Datenverlust

Motivation
Historie
n Anfang 60er Jahre

l elementare Dateien, anwendungsspezifische Datenorganisation
l geräteabhängig, redundant, inkonsistent
n Ende 60er Jahre

l Dateiverwaltungssysteme (SAM, ISAM)
mit Dienstprogrammen (Sortieren)
l geräteunabhängig, aber redundant und inkonsistent
n 70er Jahre
l Datenbanksysteme
l Geräte- und Datenunabhängigkeit, redundanzfrei, konsistent

Motivation
Historie von Relationalen DBS
n 1970: Edgar F. Codd (IBM) _ Relationenmodell

als konzeptionelle Grundlage von RDBS E. F. Codd
(Turing Award 1981)
n 1974: System R (IBM) _ erster Prototyp eines RDBS

l Anfragesprache SEQUEL
l erste Installation 1977
n 1975: University of California at Berkeley _ Ingres

l Anfragesprache QUEL
l Vorgänger von Postgres, Sybase, . . .
n 1979: Oracle Version 2

n ...
Codd E.F.: A Relational Model of Data for Large Shared Data Banks.
Communications of the ACM, Volume 13, Issue 6, 377-387, 1970

Architektur
Die Codd'schen Regeln (1985!)
1. Integration
w einheitliche, nichtredundante Datenverwaltung
2. Operationen
w Speichern, Suchen, Ändern, Einfügen
3. Katalog
w Zugriffe auf Datenbankbeschreibungen im Data Dictionary
4. Benutzersichten
w Sichten auf eine Datenbank
5. Integritätssicherung
w Korrektheit des Datenbankinhalts
6. Datenschutz
w Ausschluss unauthorisierter Zugriffe
7. Transaktionen
w mehrere DB-Operationen als Funktionseinheit
8. Synchronisation
w parallele Transaktionen koordinieren
9. Datensicherung
w Wiederherstellung von Daten nach Systemfehlern
w ...

Architektur
Komponenten eines DBS im Überblick
n Besteht aus
l einer oder mehreren Datenbanken (DB)
l einem Data Dictionary (DD)
l und einem Datenbankmanagementsystem (DBMS)
Anwendung 1 Anwendung 2 ... Anwendung n Software für die

Definition, Konstruktion
und Manipulation von
DBMS (Datenbankmanagementsystem) Datenbanken
DD (Data DB 1 DB n
Dictionary (Daten- ...
Gespeicherte mit DB- bank)
Datenbank- Schema)
definition
(Metadaten)
DBS (Datenbanksystem)

Architektur
Komponenten eines DBS im Detail
Anwendungs-
programmierer
Anwendungsprogramme
Gelegentliche
Datenbankadministrator Benutzer
Pre-Compiler
Host Language
DDL-Anweisungen Privilegierte Befehle Interaktive Anfrage
Compiler
Anfrage- DML- Kompilierte

Übersetzer Anweisungen (vorgeplante)
Transaktionen
DDL-Compiler Data DML-Compiler
Dictionary
Laufzeit-
komponente
des Daten-
banksystems
Storage Subsysteme für Nebenläufigkeitskontrolle,

Manager Datensicherung und Wiederverwendung
Datenbank
Architektur
Drei-Schichten-Architektur 1/3
Benutzer
EXTERNE Externes Schema ... Externes Schema

Ebene
Anfragebearbeitung
Datendarstellung
externe/konzeptuelle Abbildung Logische Datenbankunabhängigkeit
KONZEPTUELLE/ Konzeptuelles/logisches Schema

LOGISCHE
Ebene Physische Datenbankunabhängigkeit
konzeptuelle/interne Abbildung
Internes/physisches Schema
INTERNE/
PHYSISCHE
Ebene
Gespeicherte Datenbank
Standardisiert: ANSI/X3/SPARC
Architektur
n Konzeptuelles / logisches Schema

l = Ergebnis der Datenmodellierung/-definition
n Internes / physisches Schema
l = Tabellen mit SQL-Befehlen erzeugen, Dateiorganisation,
Zugriffspfade und Hilfsstrukturen aufbauen
n Externes Schema
l = Ergebnis der Sichtdefinition
auf jeder Ebene
n Trennung Schema – Instanz

l Schema (DB-Struktur, Metadaten) – „Intension“
l Instanz (DB-Inhalt, -zustand bzw. -ausprägung) – „Extension“

Architektur
n Physische Datenunabhängigkeit
“Implementierungsunabhängigkeit“
l Änderungen der Dateiorganisationen und Zugriffspfade
haben keinen Einfluss auf das konzeptuelle Schema
n Logische Datenunabhängigkeit
“Anwendungsunabhängigkeit“
l eventuell externe Schemata betroffen (Ändern von
Attributen)
l eventuell Anwendungsprogramme betroffen –

Rekompilieren der Anwendungsprogramme, eventuell
Änderungen nötig
l nötige Änderungen werden jedoch vom DBMS erkannt und

überwacht

Existierende Systeme
Eigenschaften von RDBS im Überblick
n Drei-Ebenen-Architektur nach ANSI-SPARC nur zum Teil
n SQL als einheitliche Datenbanksprache
n Einbettung von SQL in Programmiersprachen
n Diverse Werkzeuge für Definition, Anfrage, Darstellung von

Daten, Entwurf und Benutzer-Interaktion
n Kontrollierter Mehrbenutzerbetrieb, Zugriffskontrolle und

Datensicherheitsmechanismen
n Verfügbar für die wichtigsten Betriebssystemplattformen

(auch Microsoft SQL Server seit 2017 für Linux verfügbar!)

Entwicklungshistorie von RDBS
n Umfassende Liste von RDBS

http://de.wikipedia.org/wiki/Datenbank_%28Liste%29
Chamberlin, D.D., et al.: A History and Evaluation of the System R,

Communications of the ACM (CACM), 24(10), October 1981

Open Source RDBS – Beispiele
n MySQL (www.mysql.com)
l weit verbreitet (Linux, Solaris, Windows)
l gute SQL-Unterstützung
l keine Stored Procedures- und Trigger-Unterstützung
l eingeschränkte Transaktionsunterstützung
n Firebird (www.firebirdsql.org)
l weit verbreitet (Linux, Solaris, Windows)
l gute SQL-Unterstützung
l kompakt, geringer Speicherbedarf
l unterstützt verteilte Transaktionen
n PostgreSQL (www.postgresql.org)
l umfangreiches Angebot an Erweiterungen durch Dritthersteller,
wie z. B. PostGIS zur Verwaltung von Geo-Daten
l PostgreSQL ist in den meisten Linux-Distributionen enthalten
l Apple liefert PostgreSQL als Standarddatenbank aus

Einsatzgebiete von RDBS
n Klassische Einsatzgebiete
l Große Datenmengen, viele Nutzer
l Wohlstrukturiertes Schema
l Redundanzfreiheit
l Flexibel abfragbar
l Von mehreren Anwendungen gleichzeitig nutzbar, bei hoher
Aktualität der Daten
l Ausfallsicherheit
l ...
n Grenzen
l Flexible Schemata
l Gezielte Redundanzen zur Performanz-Steigerung
l "Unschärfe" bei Abfragen – „similarity search“
l Flexibles Konsistenzmodell
l …

Klassifikation von DBS
n Hierarchische Systeme
l z.B. IMS/IBM
n Netzwerkmodell-basierte Systeme
l z.B. UDS/Siemens
n (Objekt)-Relationale Systeme
l z.B. Oracle, DB2, SQLServer
n Objektorientierte Systeme
l z.B. ObjectStore, Poet, Versant, GemStone
n XML-basierte Systeme
l z.B. TAMINO/Software AG, eXcelon
n NoSQL-Systeme
l z.B. MongoDB, Hbase, Cassandra

Non-Standard Anwendungsbereiche
n Multimedia
l Verwaltung multimedialer Objekte (Bilder, Audio, Video)
n Verteilte Datenhaltung
l Verteilung von Daten auf verschiedene Rechnerknoten
n Föderierte Datenbanken, Multidatenbanken, Mediatoren

l Integration von Daten heterogener Quellen (z.B. Web)
n Mobile Datenbanken
l Datenverwaltung auf Kleinstgeräten (PDA, Handy, . . . )
n Data Warehouses
l Datenverwaltung für Analysezwecke
n …

Inhalt
n Einführung
l Modellbegriff
l Datenmodelle
l Vorgehensmodell für den DB-Entwurf
l ER-Modelle
l Objektorientierte Modelle – UML
n Datenbankentwurf
n SQL
COOPERATIVE INFORMATION SYSTEMS , JKU Linz 20/113

Modellbegriff
Abbildungsmerkmal
n Ein Modell stellt eine Abstraktion eines Realitätsausschnitts

dar
l Um Information verständlicher darzustellen
l Um essentielle Systemaspekte aufzuzeigen
l Zur Kommunikation (Projektmitarbeiter, Kunden)
l Um komplexe Architekturen darstellen zu können
n Ein Diagramm ist die grafische Repräsentation eines
Modells bzw. eines Modell-Ausschnitts
cd A Person
Platz
Sitzplatz
Reihe
EndeZeit=BeginnZeit+Film.Dauer N
Assistent Mitarbeiter
EndeZeit
Kino
1 BeginnZeit
reserviert
besitzt Datum
N 1 ReservierungsNr
1 N 1 N
Saal spieltIn Vorführung gehörtZu Reservierung Verfallsdauer
1 N N N
Realitäts-
Verfallszeit
SaalNr Verfallszeit=
hat macht Vorführung.BeginnZeit -
Modell
Bezeichnung Verfallsdauer
Sicht Sicht
Anz. Reihen 1
1 ID
Anz. Plätze
ausschnitt Modell
Film Person Vorname
entwertenKarten
Code Nachname
giltFür
Titel IS_A IS_A
Dauer
Mitarbeiter Besucher
FreigegebenAb 1
Kartenabreißer SVNr
N IS_A
Platz IS_A Adresse
Eintrittskarten Preis Name
Reihe
IS_A Produkt N verkaufen 1 Verkäufer arbeitetAn Ticketschalter
GNr N N
Gutschein
Diagramme
Gültigkeit
Modell: Konkretes oder gedankliches Abbild eines vorhandenen Gebildes

(~Realitätsausschnitt) oder Vorbild für ein zu schaffendes Gebilde in der
COOPERATIVE INFORMATION
Wahrnehmung SYSTEMS
der beteiligten
, JKU LinzPersonen für einen bestimmten Verwendungszweck. 21/113
Modellbegriff
Verkürzungsmerkmal
n Modelle erfassen meist nicht alle Individuen und Attribute des

Originals
l Bewusste Abstraktion
n Es wird nur das modelliert, was den Modellschaffenden
wichtig/nützlich/notwendig erscheint
l Wahrnehmung, Erfahrung, Erkenntnis der Personen
n Das Modell kann Individuen und Attribute enthalten, die
keine Entsprechung im Original haben
Bsp:
Original Modell

Ein Datenmodell
n Ein Datenmodell ist eine Menge von Konzepten zur

Beschreibung der Syntax und Semantik von Daten
n Es sollten 3 Aspekte spezifiziert werden können:
1. Statische Eigenschaften
a. Objekte
b. Beziehungen
inklusive der Standard-Datentypen, die Daten über die
Beziehungen und Objekte darstellen können
2. Dynamische Eigenschaften
a. Operationen
b. Beziehungen zwischen Operationen
3. Integritätsbedingungen an
a. Objekte
b. Operationen

Arten von Datenmodellen
n Klassische Datenmodelle sind speziell geeignet für

l große Informationsmengen mit relativ starrer Struktur und
l die Darstellung statischer Eigenschaften und
Integritätsbedingungen (also die Bereiche 1(a), 1(b) und 3(a))
n Konzeptionelle (Analyse/Entwurfs-) Modelle

l (E)ER-Modell
l UML
n Realisierungsmodelle
l Relationenmodell
l Objektorientierte Modelle
l Semistrukturierte Modelle

Vorgehensmodell für den DB-Entwurf
Konzeptionelles (Analyse/Entwurfs-) Modell
Phase Modell Ergebnis

ANF 5.4: Eine Rechnung wird durch
Anforderungs- Anforderungs- Pflichtenheft Realitäts- eine fortlaufende RechNr. eindeutig
ausschnitt identifiziert und kann sich auf eine
analyse modell (Use-Cases, ...)
Bestellung beziehen. ...
Konzeptioneller Entity Relationship Konzeptuelles Modell

Entwurf (UML, ...) DB-Schema
relational
(hierarchisch, objekt-
Logischer orientiert, objekt- Logisches Rechnung(RechNr, Datum, ...)
Entwurf relational, semi- DB-Schema Bestellung(BestellNr, Datum, ...)
strukturiert, ...)
CREATE TABLE Rechnung (

Physischer Data Definition Physisches Oracle, DB2, RechNr NUMBER(10) PRIMARY KEY,
Entwurf Language DB-Schema SQLServer,
Datum DATE,
MySql, ...
...
);
Realisierungsmodell

Das ER-Modell
n Das Entity-Relationsship-Modell wurde 1976 in einem
wegweisenden Aufsatz von Peter Chen vorgestellt
Dr. Peter Chen
n Wie der Name schon ausdrückt, modelliert dieses Modell

Gegenstände (Entities) und die Beziehungen
(Relationships) zwischen diesen
n Notation wurde später erweitert ð EER-Modell
n Viele unterschiedliche graphische Notationen – die

Konzepte (Entity, Relationship, Attribut, Schlüssel, Rolle) sind
jedoch überall dieselben
Chen P.: The Entity-Relationship Model - Toward a Unified View of Data.

ACM Transactions on Database Systems, Band 1, Nr. 1, 9-36, 1976
(http://bit.csc.lsu.edu/~chen/pdf/erd.pdf)

Das ER-Modell
Grundkonzepte
n Entity
l Objekt der realen oder der Vorstellungswelt, über das
Informationen zu speichern sind z.B. Produkt, Hersteller oder
Kunde
l aber auch Informationen über Ereignisse, wie z.B. Bestellungen
n Relationship
l beschreibt eine Beziehung zwischen Entities, z.B. ein Kunde
bestellt ein Produkt oder ein Hersteller liefert ein Produkt
n Attribut
l repräsentiert eine Eigenschaft von Entities oder Beziehungen,
z.B. Name eines Kunden, Bezeichnung eines Produktes oder
Datum einer Bestellung

Das ER-Modell
Beispiel
RechNr Datum BestellNr Datum Menge Preis
1 bezieht 1 m n
Rechnung sich Bestellung umfasst Produkt Bezeichnung
n m
ProduktNr
1
Versand bestellt liefert
Name Telefon LieferantenNr

1 n
Kunde Lieferant Name
Adresse
KundenNr Name
Adresse

Das ER-Modell
Einschätzung
n ER-Diagramme sind eine weit verbreitete Art der

konzeptuellen Modellierung
n Die Konzepte sind nicht allzu schwer zu begreifen, d.h.

der Sachverhalt kann auch mit Domain-Experten (die den
Fachbereich kennen) diskutiert werden
n Prinzipiell „mit Papier und Bleistift“ verwendbar, doch auch

von Werkzeugen unterstützt
n Wegen Einschränkungen vermehrt Verdrängung der ER-

Diagramme durch objektorientierte Modelle (UML)

Objektorientierte Datenmodelle
n Seit Beginn der 90er Jahre Booch, Jacobson, Rumbaugh
l Ansätze für OO Analyse und Entwurf
n Ansätze der ersten Generation

l OMT – Object Modeling Technique
(J. Rumbaugh et al.)
¡ Starker Bezug zur Datenmodellierung
(erweiterte ER-Diagramme)
l Booch-Methode (Grady Booch)
¡ Starker Programmiersprachenbezug
(Modellierung von Echtzeitsystemen)
l OOSE – Object-Oriented Software Engineering
(I. Jacobson)
¡ Stark in der Beschreibung von Anforderungen
(Use-Case-orientiert)
n Ab Mitte der 90er Jahre

l Vereinheitlichung zur Unified Modeling Language (UML)
OMG: http://www.omg.org/technology/documents/formal/uml.htm
OMG UML Resource Page: www.uml.ac.at/

Ziele von UML
n Bereitstellung einer ausdrucksstarken

Modellierungssprache
l Zur Formulierung unterschiedlicher Typen
von Modellen
l Zum Austausch von Modellen
l Zur Spezifikation, Konstruktion, Visualisierung und
Dokumentation der Artefakte eines SW-Systems
n Bedeutung des Begriffs »Unified«

l Unterstützung des gesamten Entwicklungsprozesses
l Flexibilität in Bezug auf Vorgehensmodelle
l Unabhängigkeit von Entwicklungswerkzeugen und –plattformen,
sowie Programmiersprachen
l Einsetzbarkeit für verschiedenste Anwendungsbereiche
l Generizität der Sprachkonzepte u. in einem Metamodell definiert

Historische Entwicklung von UML
Konsolidierung
2015 UML 2.5 Öffentliches
Feedback
Fundamentale UML 2
2005 Neuerungen
Erweiterung
Öffentliches
2004 Aktionsmodell Feedback
2003 UML 1.5 Industrialisierung

Komponenten,
2002 Profile,
Kollaboration
2001 UML 1.4 Öffentliches
Feedback
2000 XMI
1999 UML 1.3

OCL
1998 Standardisierung
UML 1.1
durch OMG
1997
UML 1
Öffentliches
1996 UML 0.9 Feedback
1995 Unified Method 0.8 Vereinheitlichung
Diverse Fragmentierung
OOAD OMT OOSE
Methoden

Anwendungsfalldiagramm
UML-Diagrammarten
Diagrammart
Strukturdiagramm Verhaltensdiagramm
Klassen- Paket- Komponenten- Verteilungs- Anwendungsfall- Zustands-

diagramm diagramm diagramm diagramm diagramm diagramm
Objekt- Kompositionsstruktur- Interaktions- Aktivitäts-

diagramm diagramm diagramm diagramm
Sequenz- Kommunikations- Zeit- Interaktionsübersichts-

diagramm diagramm diagramm diagramm
Klassendiagramm
Paketdiagramm
COOPERATIVE INFORMATION SYSTEMS Sequenzdiagramm
, JKU Linz 33/113
Beispiel UML-Klassendiagramm
1 1
CALENDARIUM
verwaltet verwaltet
Personengruppe *
* Eintrag
* nimmtTeil
* Benutzer 1..* * {abstract} Kalender
* 1..*
ergehtAn name /auszeichnung: Farbe gehörtZu istOffen: bool
1..* berechtigung beschreibung: String {ordered} *
* typ: Termintyp
stelltDar
Notifikation 0..3 erinnertAn 1
*
Ansicht
Termin Serie ToDoEintrag
beginn: DatumZeit whDauer fälligPer: Datum
dauer: Zeit whFrequenz 1..*
hyperlink [0..1]: URL 0..1 0..1
* anzahlTermine: Int {ordered}
/kollidiertMit
* 1..* {xor}
{ordered}
vgl.: W. Retschitzegger, E. Kapsammer, M. Hitz, G. Kappel: UML@Work. dpunkt.verlag

Inhalt
n Einführung
l Relationenmodell
l NF2-Datenmodell
l Objektorientierte Modelle
l Semistrukturierte Modelle – XML
n Datenbankentwurf
n SQL

Datenmodelle für die Realisierung
n Klassische Datenmodelle
l Hierarchisches Datenmodell
l Netzwerk-Datenmodell
l Relationenmodell
n Erweiterte relationale Datenmodelle
l NF2-Datenmodell
n Objektorientierte Datenmodelle
n Semistrukturierte Datenmodelle
l eXtensible Markup Language (XML)
Zeichnen sich dadurch aus, dass sie

§ weniger abstrakt und
§ implementierungsnäher sind sowie
§ mit konkreten Anfrage- und Änderungs-
operationen verbunden sind
Relationenmodell
Grundkonzepte 1/3
n E.F. Codd im Jahre 1970 entwickelt (ð Turing Award)
Relationenname Attribut(-namen)
R A1 ... An Relationenschema
... ... ...

Tupel Relation
... ... ...
Attributwerte
Codd E.F.: A Relational Model of Data for Large Shared Data Banks.
Communications of the ACM, Volume 13, Issue 6, 377-387, 1970

Relationenmodell
Grundkonzepte 2/3
n Jede Zeile (Tupel) ist eindeutig und beschreibt ein Objekt

der Realität
n Die Ordnung der Zeilen
l ... ist ohne Bedeutung; durch ihre Reihenfolge wird keine für den
Benutzer relevante Information ausgedrückt
n Die Ordnung der Spalten
l ... ist ohne Bedeutung, da sie einen eindeutigen Namen
(Attributnamen) tragen
n Jeder Datenwert innerhalb einer Relation ist ein
atomares Datenelement
n Alle für den Benutzer bedeutungsvollen Informationen
sind ausschließlich durch Datenwerte ausgedrückt
n Es existiert ein Primärschlüssel

Relationenmodell
Grundkonzepte 3/3
Begriff Informale Bedeutung

Attribut Spalte einer Tabelle
Wertebereich Mögliche Werte eines Attributs (Domäne)
Attributwert Element eines Wertebereichs
Relationenschema Menge von Attributen
Relation Menge von Zeilen einer Tabelle (Ausprägung eines
Relationenschemas)
Tupel Zeile einer Tabelle

Datenbankschema Menge von Relationenschemata
Datenbank Menge von Relationen (Basisrelationen)
Schlüssel Minimale Menge von Attributen, deren Werte ein Tupel
einer Tabelle eindeutig identifizieren
Primärschlüssel Ein beim DB-Entwurf ausgezeichneter Schlüssel

Fremdschlüssel Attributmenge, die in anderer Relation Schlüssel ist
Fremdschlüssel- Alle Attributwerte des Fremdschlüssels erscheinen

bedingung in der anderen Relation als Werte des Schlüssels

Relationenmodell
Schlüssel
n Attribute einer Spalte identifizieren eindeutig gespeicherte

Tupel ð Schlüsseleigenschaft
l etwa KNr für Tabelle Kunde
Kunde
KNr Vorname Name PLZ Ort
101 Karl Maier 4040 Linz
102 Franz Huber 4232 Hagenberg
103 Hans Humer 1010 Wien
n Auch Attributkombinationen können Schlüssel sein

n Schlüssel soll minimal sein
n Kein Schlüsselwert darf NULL sein
Ø Entitätsintegrität!

Relationenmodell
Fremdschlüssel 1/2
n Schlüssel einer Tabelle können in einer anderen (oder

derselben) Tabelle als eindeutige Verweise genutzt
werden ("relationenübergreifende Information")
n Etwa Produkt.HerstNr als Verweis auf Hersteller.HerstNr
n Fremdschlüssel = Schlüssel in einer "fremden" Tabelle
Produkt Fremdschlüssel Hersteller Primärschlüssel

ProduktNr Bezeich Preis Bestand HerstNr HerstNr Name
101 x 99.0 77 10 10 A
102 y 77.6 60 11 11 B
103 z 55.7 2 11 12 C
104 w 66.5 100 12 referenzierte Relation

referenzierende Relation
Primär- und Fremdschlüssel
müssen gleichen Wertebereich
Ø Referenzielle Integrität! haben!

Relationenmodell
Fremdschlüssel 2/2
n Fremdschlüssel können Nullwerte aufweisen

l wenn sie nicht Teil eines Primärschlüssels sind oder
l wenn nicht explizit NOT NULL spezifiziert ist
n Eine Relation kann mehrere Fremdschlüssel besitzen

l welche die gleiche oder verschiedene Relationen
referenzieren
n Fremdschlüssel kann auch die eigene Relation

referenzieren ("self-referencing table")
n Zyklen sind möglich

NF2-Relationenmodell
n Zweck
l Verarbeitung komplexer Attributwerte
l Strukturierte und mengenwertige Attribute
n Merkmale
l Nichtatomare Attributwerte werden zugelassen (1.NF wird nicht
gefordert - Non First Normal Form - NFNF _ NF2)
l Attributwerte können demnach atomar oder wiederum
Relationen sein _ "geschachtelte" Relationen
l Operationen zum Schachteln (Nesting) und Entschachteln von
Relationen notwendig

NF2-Relationenmodell
Beispiel einer NF2-Relation
Lehrpersonal
Studiengang Belegschaft
PersNr Nachname Telefone Eintrittsjahr
Telefon
07236-3888-2020
101 Dobler 1996
0664-3476543
Software Engineering 102 Kurschl 07236-3888-2029

2001
07236-3888-2023
103 Altmann 2005
0669-8765434
0732-594054
07236-3888-2024
104 Hinterholzer 1998
07236-3888-2700
Bioinformatik 144 Pröll 1999
0676-3456789
Attribut Belegschaft enthält

mehrspaltige Untertabelle Attribut Telefone enthält
einspaltige Untertabelle
(Multiple Felder)

n Merkmale
l Objekte
l Objektidentität (unveränderliche OIDs)
l Kapselung
l Typen, Klassen und Beziehungen
l Spezialisierung
n Entwicklungslinien
l Erweiterung objektorientierter Programmiersprachen
(z.B. ObjectStore, Poet)
l komplette Neuentwicklungen (z.B. O2)
l Erweiterung von RDBS
_ Objektrelationale DBS
z.B. Oracle, IBM DB2, SQL Server
Weiterentwicklung von SQL2 zu SQL3 (enthält oo Konzepte!)

B
Semistrukturierte Datenmodelle
XML 1/2
h
n Strukturierung der Daten
l nicht immer sinnvoll, oft nicht bekannt, oft nicht für alle
Dokumente gleich, oft nicht gewünscht, oft zu aufwendig,
wechselt oft, ...
l optionale Teile
l Wiederholungen
l Reihenfolge relevant
n Schema implizit in jedem Dokument enthalten und explizit

über Schemadefinitionssprachen spezifizierbar
l Zwei W3C-Standards für XML (eXtensible Markup Language) –
DTD (Document Type Definition) und XML-Schema
l Grammatiken zur Definition XML-basierter Sprachen –
erlaubte Tag-Namen, mögliche Schachtelung, Datentypen, etc.
n Zugriff auf semistrukturierte Daten pfadorientiert

l W3C-Standard XPath

Semistrukturierte Datenmodelle
XML 2/2
UML Klassendiagramm XML-Dokument

...
HandyKatalog <!DOCTYPE HandyKatalog [
<!ELEMENT HandyKatalog (Hersteller*)>
* <!ELEMENT Hersteller (HerstellerNr, Modell+)>
Hersteller <!ATTLIST Hersteller name CDATA #REQUIRED>
name <!ELEMENT HerstellerNr EMPTY>
<!ATTLIST HerstellerNr nr ID #REQUIRED> Grammatik
<!ELEMENT Modell (Gewicht, Preis+)> (logische Struktur)
1 1..*
<!ATTLIST Modell name CDATA #REQUIRED>
HerstellerNr Modell <!ELEMENT Gewicht (#PCDATA)>
nr name <!ELEMENT Preis (#PCDATA)>
<!ATTLIST Preis vertrag (ja|nein) "nein">
1 1..* ]>
<HandyKatalog>
Gewicht Preis
<!–- NOKIA -->
vertrag <Hersteller name="NOKIA">
<HerstellerNr nr="h1234"/>
<Modell name="7110"> Instanz
<Gewicht>141g</Gewicht> (physische Struktur)
<Preis vertrag="ja">999</Preis>
</Modell>
</Hersteller>
</HandyKatalog>

Inhalt
n Einführung
n Logischer Entwurf
l Zwei Kernaufgaben
l Abbildung ER-RM
l Verbesserung des relationalen Schemas
¡ Redundanzen und Anomalien
¡ Funktionale Abhängigkeiten
¡ Normalformen
¡ Schema-Eigenschaften
¡ Transformationseigenschaften
n SQL

Logischer Entwurf
Zwei Kernaufgaben
(1) Abbildung auf Relationenmodell (RM)

l Vorgehensweisen
¡ Transformation nach Faustregeln manuell
¡ automatische Transformation
l Ziel: „kapazitätserhaltende“ Abbildung
(2) Verbesserung des relationalen Schemas

l anhand von Gütekriterien
¡ Minimierung redundanter Speicherung
(ð Normalisierung)
¡ Effizienzsteigerung beim Zugriff
(ð Zugriffspfade, Denormalisierung, ...)

Abbildung auf RM
Konzeptionelles DM Realisierungs-DM
Verlag
Name Verlag Name Ort Plz
Ort
Plz
1..1
gibtHeraus
1..* Buch ISBN Titel Name
Buch
ISBN
Titel ISBN ID
0..* schreibt
schreibt
1..* ID Vorname Nachname
Autor
Autor
ID
Vorname
Nachname

Abbildung auf RM
Regeln am Beispiel 2/3
n Ternäre Beziehug wird eine Relation

n Die Primärschlüsseln der beteiligten Klassen werden in die
Relation aufgenommen
Lieferant
*
* *
Teil Lieferung Projekt
Verwendung von vier Relationen erforderlich:
Teil (TeilNr, Bezeichnung, ..., Gewicht)

Projekt (ProjektNr, Projektname, ...)
Lieferant (LieferantNr, Lieferantname, ...)
Lieferung (LieferantNr, ProjektNr, TeilNr, Datum, ...)

Abbildung auf RM
Zusammenfassung
n Klassen
l jeweils auf Relationenschemata abbilden
n Attribute
l Attribute des Relationenschemas, Schlüssel werden übernommen
n Kardinalitäten der Beziehungen
l durch Wahl der Schlüssel bei den zugehörigen Relationenschemata
ausdrücken
n Beziehungen
l *:*-Beziehung ist durch eine eigene Relation darzustellen
n Generalisierung/Spezialisierung
l keine direkte Unterstützung im Relationenmodell
l Auswahl einer geeigneten Abbildung hängt von konkreter
Problemstellung ab
l Abwägung von Speichereffizienz und Laufzeiteffizienz
l Relevant bei Abbildung OO ó Relational

Abbildung auf RM
Regeln am Beispiel 3/3
n Vererbungshierarchie
l Jede Klasse wird durch eine Relation abgebildet
l Jede Instanz ist genau einmal und vollständig in ihrer "Basis-
relation" gespeichert
Ø Es wird eine horizontale Partitionierung der Instanzen erreicht
FH-Angehöriger SVNR Name
111 Ernie
SVNR
FH-Angehöriger
Name
Angestellter SVNR Name Vertr.Kat.
IST-EIN
007 Garfield 2L
Angestellter Student
Vertragskategorie
.... Techniker SVNR Name Vertr.kat Erfahrung
IST-EIN
123 Donald 1A Linux
Techniker Wiss-Mitarbeiter
Erfahrung
Diplom Wiss-Mitarbeiter SVNR Name Vertr.kat Diplom Spez.Geb.
Spez-Geb.
777 Grouch 1L BIN C++
333 Daisy 1L SE UML

Verbesserung des Relationalen Schemas

Ziele
n Redundanzen vermeiden
l Belegen unnötigen Speicherplatz (eher unwichtig)
l Änderungsop. bei Redundanzen schwer korrekt umsetzbar
¡ wenn Information redundant vorkommt, muss eine Änderung diese Information
in allen ihren Vorkommen verändern
¡ mit normalen relationalen Änderungsoperationen und lokalen
Integritätsbedingungen (Schlüssel) schwer realisierbar
n Anomalien (sich wiedersprechende Daten) vermeiden
l Änderungsanomalien: Beim Ändern eines Wertes müssen viele Tupel
ebenfalls geändert werden
l Einfügeanomalien: Beim Einfügen eines Tuples können bestimmte
Werte nicht angegeben werden, da sie noch nicht bekannt sind (wenn
Schlüsselwerte fehlen, kann Tupel nicht einmal eingefügt werden)
l Löschanomalien: Beim Löschen eines Tuples geht mehr Information
verloren als beabsichtigt
n OHNE
l semantische Informationen zu verlieren (Abhängigkeitstreue)
l die Möglichkeit zur Rekonstruktion der Relationen zu verlieren
(Verbundtreue)
à Wartung einer DB vereinfachen
Normalformen à Konsistenz gewährleisten

Beispiel für eine Anomalie
n Einfügen in die mit Redundanzen behaftete Produkt-

Hersteller-Relation:
ProduktNr Bezeichnung Preis Bestand HerstellerNr Name
207 A 44 6 100 HerstellerA
210 B 55 88 101 HerstellerB
Einfügen
230 C 77 90 100 HerstellerC
n Dem Hersteller mit der Nummer 100 ist eigentlich der

Herstellername „HerstellerA“ zugeordnet und nicht der
Name „HerstellerC“
n Integritätsbedingung verletzt, die in dieser Relation durch
eine Schlüsselbedingung nicht spezifiziert werden kann


Funktionale Abhängigkeiten 1/2
n Funktionale Abhängigkeit zwischen Attributmengen X

und Y einer Relation gilt,
l wenn in jedem Tupel der Attributwert unter den X-Komponenten
den Attributwert unter den Y-Komponenten festlegt
l unterscheiden sich zwei Tupel in den X-Attributen nicht, so
haben sie auch gleiche Werte für alle Y-Attribute
n Beispiel:
l ProduktNr à Bezeichnung, HerstellerNr


Funktionale Abhängigkeiten 2/2
n Es ist unrealistisch, alle möglichen Tupel einer Relation in

der Praxis zu überprüfen
n Funktionale Abhängigkeiten müssen aus dem
Hintergrundwissen über die Anwendung abgeleitet
werden
n Beispiel:
l ProduktNr à Bezeichnung, HerstellerNr
l HerstellerNr à Name
n Was machen wir jetzt mit diesen funkt. Abhängigkeiten?

n Man kann einen Schlüssel für die Relation identifizieren!


Eigenschaften von Schlüsseln
n Eigenschaften eines Schlüssels X:

1. X ⊆ R
2. X à R (Vollständigkeit)
3. Es gibt kein X' ⊆ X so dass X'à R (Minimalität)
n X wird auch Kandidatenschlüssel genannt

l es kann mehr als ein X geben, das obige Eigenschaften erfüllt
n Ein X wird als Primärschlüssel gewählt


Erste Normalform
n Erlaubt nur atomare Attribute in den Relationenschemata

l d.h. als Attributwerte sind Elemente von Standard-Datentypen
wie integer oder string erlaubt, aber keine Konstruktoren wie
array oder set
n Nicht in 1NF
Bestellung BestellNr Datum KNr VersandNr ProduktNr

207 2.4.95 44 6 100
210 3.4.05 55 88 {101, 102}
n in 1NF
Bestellung BestellNr Datum KNr VersandNr ProduktNr

207 2.4.95 44 6 100
210 3.4.05 55 88 101
210 3.4.05 55 88 102


Zweite Normalform 1/2
n Partielle Abhängigkeit liegt vor, wenn ein Attribut

funktional schon von einem Teil des Schlüssels abhängt
BestellNr à Datum
und
BestellNr, ProduktNr à Datum, KNr, VersandNr
n Verstoß gegen 2NF deutet darauf hin, dass verschiedene

Beziehungen (zwischen Entitätstypen) in einer Relation
gemischt wurden
n Zweite Normalform eliminiert derartige partielle

Abhängigkeiten bei Nichtschlüssel-Attributen (NSA)


Zweite Normalform 2/2
Eliminierung partieller Abhängigkeiten
Schlüssel K
Teil des abhängiges

Schlüssels X Attribut A


Dritte Normalform 1/2
n Eliminiert (zusätzlich) transitive Abhängigkeiten

l bei denen NSA über andere NSA vom Schlüssel abhängen
n Etwa ProduktNr à HerstellerNr und HerstellerNr à Name
n Man beachte: 3NF betrachtet nur NSA (!) als Endpunkt

transitiver Abhängigkeiten


Dritte Normalform 2/2
Eliminierung transitiver Abhängigkeiten
Schlüssel K
Attribut- abhängiges
menge X Attribut A

Boyce-Codd Normalform
n Verschärfung der 3NF: Eliminierung transitiver Abhängigkeiten auch

zwischen primen Attributen
n Beispiel:
Produkt(ProduktNr, Hersteller, Lieferant, Preis)
n Funktionale Abhängigkeiten:
ProduktNr, Hersteller à Preis
Hersteller à Lieferant
Lieferant à Hersteller
n Schlüsselkandidaten: ProduktNr,Hersteller u.
ProduktNr,Lieferant
n à in 3NF, nicht jedoch in BCNF
n Schema in BCNF:
Produkt (ProduktNr, Hersteller, Preis)
HerstLief (Hersteller, Lieferant)
n BCNF kann jedoch die Abhängigkeitstreue verletzen, daher oft
nur bis 3NF


Schema-Eigenschaften – Zusammenfassung
Schema- Kurzcharakteristik
Eigenschaft
1NF nur atomare Attribute
2NF keine partielle Abhängigkeit eines NSA
von einem Schlüssel
3NF keine transitive Abhängigkeit eines NSA
von einem Schlüssel
BCNF keine transitive Abhängigkeit eines

Attributes von einem Schlüssel
Minimalität minimale Anzahl von Relationenschemata,
die die anderen Eigenschaften erfüllt


Transformations-Eigenschaften – Zusammenfassung
n Bei der Zerlegung einer Relation in mehrere Relationen ist

darauf zu achten, dass
l nur semantisch sinnvolle und konsistente Daten dargestellt
(Abhängigkeitstreue) und
l alle Daten aus den Basisrelationen hergeleitet werden können
(Verbundtreue)
Transformations- Kurzcharakteristik
Eigenschaft
Abhängigkeitstreue alle gegebenen funktionalen Abhängigkeiten sind durch
Primär- und Fremdschlüssel repräsentiert
Verbundtreue die Originalrelationen können durch den Verbund der
Basisrelationen wieder gewonnen werden


Einschätzung der Normalisierung
n Normalisierung kann sich negativ auf die Performanz

auswirken, weil Verbunde sehr teuer auszuwerten sind
n Nicht jede funktionale Abhängigkeit berücksichtigen

l Abhängigkeiten zw. Wohnort, Vorwahl, Postleitzahl
n Man kann SQL-Integritätsbedingungen formulieren, um

Anomalien zu vermeiden – z.B. Trigger

Inhalt
n Einführung
n Logischer Entwurf
n SQL
l SQL-Standardisierung
l Ausgewählte DDL-Konzepte
¡ CHECK-Bedingung
¡ DOMAIN-Definition
¡ Referentielle Integrität
l Ausgewählte Anfrage-Konzepte
¡ Outer-Join
¡ Gruppierung durch Rollup- und Cube-Operator
¡ Rekursive Anfragen
l Ausgewählte DML-Konzepte
¡ Merge-Anweisung
¡ Generierung eindeutiger Schlüssel
¡ Materialisierte Sicht
l Prozedurale Erweiterungen
¡ Stored Procedures
¡ Trigger

SQL-Standardisierung
Structured Query Language (SQL)
n SQL ist "de facto"-Standard in der relationalen Welt

l 1986 von ANSI, 1987 von ISO akzeptiert
Lebenszyklus ISO-Standardisierung
n Weiterentwicklung des
Standards in vier Stufen
n Mächtigkeit von SQL

l Auswahlvermögen äquivalent dem Relationen-Kalkül und der
Relationen-Algebra

Historie
DBMS-Produkte
Sprachentwicklung
Chamberlin, D., Boyce, R.F. SEQUEL: A Structured English Query
n SEQUEL (1974, IBM Research Labs San Jose) Language. Proc. ACM SIGFIDET Conf., Ann Arbor, MI, May 1974.
http://www.almaden.ibm.com/cs/people/chamberlin
n SEQUEL2 (1976, IBM Research Labs San Jose)
Codd, E.F.: A Relational Model of Data for Large Shared Data Banks,
n SQL (1982, IBM) Communications of the ACM, Vol. 13, No. 6, June 1970,
n ANSI-SQL (SQL1 oder SQL:86) http://www.acm.org/classics/nov95/toc.html
n ISO-SQL (SQL1 + Integrity Enhancement Feature oder SQL:89)
n (ANSI / ISO) SQL2 (als SQL:92 verabschiedet)
n (ANSI / ISO) SQL3 (als SQL:1999 verabschiedet)
n (ANSI / ISO) SQL:2003 (verabschiedet)
Standards im Historischen Überblick
https://modern-sql.com/de/standard
n SQL:1986 – SQL1
l erste Version der SQL-Norm 1986 veröffentlicht
l DDL, DML, eingebaute Typen, Privilegien für den Zugriff auf Tabellen, ...
n SQL:1989
l Erste Revision von SQL:1986
l Erweiterung um referentielle Integrität
n SQL:1992 – SQL2
l Zusätzliche Datentypen, OuterJoins, Kataloge, Domänen,
Zuweisungen, temporäre Tabellen, referentielle Aktionen, dynamisches SQL, ...
l laufende Revisionen: prozedurale Konstrukte wie Stored Procedures, Schema
Manipulation
n SQL:1999 – SQL3
l Standard wird in fünf Teile gegliedert
l zusätzliche Typen (wie CLOB, BLOB), objekt-relationale Erweiterungen, rekursive
Abfragen, Sicherungspunkte (Savepoints), Rollen, Trigger, ...
n SQL:2003
l neuer Teil: SQL/XML (Verknüpfung von XML und SQL)
l SQL/OLB und SQL/JRT: Verbindung zwischen SQL und Java
l generierte Spalten (berechnen sich aus anderen Spalten)
l MULTISET-Typen (speichern eine beliebige Anzahl von Werten mit Duplikaten)
l Merging (fügt zwei Tabellen zusammen)
l Identitätsspalten (stellen automatisch inkrementierte Werte bereit), ...

Neue Anforderungen an SQL:1999-2007

SQL:2007 – Umfang

Konformität von SQL:2007: Core-SQL vs. SQL/XML
Prof. Dr. Wloka, Entwicklung des SQL-Standards – Vom Hoffnungsträger zum Ideengrab,
Hochschule für Technik und Wirtschaft, Dresden, Vortragsunterlagen, März 2007
SQL:2007
n Struktur und wesentliche „alte Inhalte bleiben gleich

l Geringe Änderungen bei SQL/Schema
l Änderungen bei SQL/Foundation
n Umfangreiche Entwicklungen bei SQL/XML
n Zusätzliche Neue Features (außerhalb von SQL/XML)
l Materialized views
l Ermöglichung von Bulkinserts
l Unterstützung der history (stripped-down temporal)
l Unterstützung von streaming data
l Reguläre Ausdrücke
l BINARY datatype
l FIRST n (LIMIT TO n, TOP n, …)
l IEEE 754 floatingdecimal datatype

SQL:2011
n Temporale DB-Konzepte = hauptsächliche Neuerung

l Viele Daten weisen 2 Zeitdimensionen auf die unterschiedlich
sein können
¡ „Valid (application) time (z.B. Gehaltserhöhungen)
¡ „Transaction (system) time (z.B. Fehlerkorrektur)
l 4 verschiedene Tabellen-Typen u. SQL-DML Erweiterungen
Application-Time Period Table System-Versioned Table
n Weitere neue Features

l Innerhalb eines MERGE nun auch Delete möglich
l Innerhalb SELECT nun auch DML-Ops erlaubt ("Pipelined DML")
l Non-enforced table constraints
l Einige neue DDL-features bei Identitätsspalten
l Erweiterungen von collection types
SQL:2016 – aktuelle Version!
n Delta v.a. in Part 2 des Standards (“SQL Foundation”)

l SQL:2007: 1323 Seiten
l SQL:2011: 1472 Seiten
l SQL:2016: 1732 Seiten (+ 260 Seiten / ~18%)
à 44 neue optionale Funktionen, keine obligatorischen
n Zeilenmustererkennung (“Row Pattern Recognition”)
l durch reguläre Ausdrücke Analyse von Zeitreihen
l z.B. zusammenhängende Ereignisse / Löcher in WebLog erkennen
n JSON-Unterstützung
l JSON-Objekte erzeugen/über Pfadausdrücke auf Element zugreifen
l Umwandlung JSONàSQL und SQLàJSON
n Polymorphe Tabellen-Funktionen
l Liefern eine Tabelle als Ergebnis, deren Ergebnistyp
(Spalten-Namen und -Typen) zur Laufzeit festgelegt werden kann
n Weitere analytische Funktionen
l Trigonometrische | Logarithmische
http://modern-sql.com/de/blog/2017-06/was-ist-neu-in-sql-2016
Ausgewählte DDL-Konzepte
DDL‘s im Überblick
n SQL
l DDL (Data Definition Language)
à Teil der Standardsprache für RDBS
l DDL-Erweiterungen von SQL:1999
à objektrelationale Konzepte
l DDL-Erweiterungen von SQL:2003
à XML-Konzepte
n XML
l DTD (Document Type Declaration)
l XML Schema

CHECK-Bedingung
n Logische Bedingung zugeordnet zu Attributen von Tabellen

n Wird bei DML-Operationen geprüft
l TRUE: DML-Operation erlaubt
l FALSE: DML-Operation zurückgewiesen
CREATE TABLE base-table (base-table-element-list)

base-table-element
::= column-def | base-table-constraint-def
CREATE TABLE Buch_Versionen (
ISBN CHAR(10) PRIMARY KEY
ISBN CHAR(10) NOT NULL UNIQUE,
Auflage SMALLINT CONSTRAINT Check_Auflage
CHECK(Auflage > 0),
Jahr INTEGER CONSTRAINT Check_Jahr
CHECK (Jahr BETWEEN 1800 AND 2020),
Seiten INTEGER DEFAULT 0);

DOMAIN-Definition
n Domänen stellen benutzerdefinierte Wertebereiche dar

n Basieren auf existierenden Datentypen
n Können wie ein herkömmlicher Datentyp für die
Attributdefinition verwendet werden
n Spezifikationsmöglichkeiten
l Optionale Angabe von Default-Werten
l Wertebereichseingrenzung durch CHECK-Bedingung möglich
CREATE DOMAIN domain [AS] data type

[DEFAULT {literal|NULL}
[[CONSTRAINT constraint] CHECK (cond-exp)]
CREATE DOMAIN ALTER AS INT

DEFAULT NULL
CONSTRAINT Altersbegrenzung
CHECK (VALUE=NULL OR (VALUE>18 AND VALUE<70))

Referentielle Integrität 1/4
n RM unterstützt nur wertbasierte Beziehungen

l oo Datenmodelle haben referenzbasierte Beziehungen!
n Fremdschlüssel (FK) und zugehöriger Primärschlüssel (PK)
repräsentieren eine Beziehung
l gleiche Wertebereiche!
n Spezifikationsmöglichkeiten in SQL:
l PK PRIMARY KEY (implizit: UNIQUE + NOT NULL)
l FK [UNIQUE] [NOT NULL]
n Fremdschlüsseldeklaration in KindKTabelle:
Vatertabelle Kind-Tabelle
0..1 0..* FK ...
1..1 0..* FK ... NOT NULL
0..1 0..1 FK ... UNIQUE
1..1 0..1 FK ... UNIQUE NOT NULL
n Referentielle Integritätsbedingung zwischen Primär- und

Fremdschlüssel
Vater-Tabelle: Kind-Tabelle:
CREATE TABLE Verlage ( CREATE TABLE Bücher (
Verlagsname VARCHAR(30), ISBN CHAR(10),
... Titel VARCHAR(200),
CONSTRAINT PK_Verlagsname Verlagsname VARCHAR(30),
PRIMARY KEY CONSTRAINT PK_ISBN
(Verlagsname), PRIMARY KEY (ISBN),
... CONSTRAINT FK_Verlagsname
); FOREIGN KEY (Verlagsname)
REFERENCES Verlage (Verlagsname)
);
n Zu jedem Fremdschlüsselwert der referenzierenden

Kindtabelle (Bücher) muss ein entsprechender Schlüssel-
wert in der referenzierten Vatertabelle (Verlage)
exisiteren
Potentielle Gefährdung der Kind-Tabelle:
n Operationen in der Kind-Tabelle

l Einfügen eines Tupels
l Ändern des FK in einem Tupel
l Löschen eines Tupels
n Welche Maßnahmen sind erforderlich?

l Beim Einfügen erfolgt eine Prüfung, ob in einem Vater-Tupel ein
PK-Wert gleich dem FK-Wert des einzufügenden Tupels existiert
l Beim Ändern eines FK-Wertes erfolgt eine analoge Prüfung
l Löschen eines Tuples ist immer unkritisch!

Potentielle Gefährdung der Vater-Tabelle:

n Operationen in der Vater-Tabelle
l Einfügen eines Tupels
l Ändern des PKs in einem Tupel
l Löschen eines Tupels
n Welche Aktion ist wann möglich/sinnvoll?

l Einfügen eines Tuples ist immer unkritisch!
l Verbiete Ändern/Löschen falls abhängige Tupel oder
l Ändere/Lösche rekursiv Tupel mit zugehörigen FS-Werten
¡ Falls Kind-Tupel erhalten bleiben soll (nicht immer möglich, z.B. bei
Existenzabhängigkeit), setze FK-Wert zu NULL oder Default
l Referentielle Aktionen nur für das Löschen und Ändern von

Vater-Tupeln von Interesse!

Referentielle Aktionen bei ON DELETE / ON UPDATE 1/2
CREATE TABLE Bücher (

n SQL2-Standard führt ISBN CHAR(10),
„referential actions“ ein! Titel VARCHAR(200),
l werden bei DELETE oder Verlagsname VARCHAR(30),
UPDATE der Vatertabelle auf CONSTRAINT PK_ISBN
die Kindtabelle ausgeführt, PRIMARY KEY (ISBN),
um referentielle Integrität CONSTRAINT FK_Verlagsname
zu gewährleisten FOREIGN KEY (Verlagsname)
REFERENCES Verlage
Referentielle Aktion wird auf Bücher-
(Verlagsname)
Tabelle (=Kindtabelle) ausgeführt ON DELETE CASCADE
);
n Spezifiziert bei FS Oracle nur: ON DELETE{CASCADE|SET NULL}

l ON DELETE
{CASCADE|RESTRICT|SET NULL|SET DEFAULT|NO ACTION}
l ON UPDATE
{CASCADE|RESTRICT|SET NULL|SET DEFAULT|NO ACTION}

Referentielle Aktionen bei ON DELETE / ON UPDATE 2/2
n RESTRICT
l Operation nur ausgeführt, wenn keine zugehörigen (FK-Werte)
l entspricht dem Fall, dass die gesamte Klausel weggelassen wird
n CASCADE
l Operation propagiert zu allen zugehörigen Sätzen
n SET NULL
l FK wird in zugehörigen Sätzen auf NULL gesetzt
n SET DEFAULT
l FK wird in den zugehörigen Sätzen auf einen
benutzerdefinierten Default-Wert gesetzt
n NO ACTION
l Für Referenz keine referentielle Aktion
l Durch DB-Op können jedoch mehrere Referenzen (mit
unterschiedlichen Optionen) betroffen sei
l Am Ende aller referentiellen Aktionen wird die Einhaltung der
referentiellen Integrität geprüft
Abarbeitung von Referentiellen Aktionen 1/2
CREATE TABLE T1 (... PRIMARY KEY K1)

T1
ON DELETE ON DELETE
CREATE TABLE T2 (... PRIMARY KEY K2 CASCADE CASCADE
FOREIGN KEY (K1) REFERENCES T1(K1)
ON DELETE CASCADE) T2 T3
CREATE TABLE T3 (... PRIMARY KEY K3 ON DELETE ON DELETE
FOREIGN KEY (K1) REFERENCES T1(K1) CASCADE RESTRICT
ON DELETE CASCADE) T4
CREATE TABLE T4 (... PRIMARY KEY K4

DELETE in T1:
ON DELETE RESTRICT)
FOREIGN KEY (K2) REFERENCES T2(K2) Aktionen von T3 vor T4 vor T2 7
ON DELETE CASCADE) Aktionen von T2 vor T4 vor T3 ü
ð Es können reihenfolgeabhängige Ergebnisse auftreten!

Abarbeitung von Referentiellen Aktionen 2/2
CREATE TABLE T1 (... PRIMARY KEY K1)

T1
ON DELETE ON DELETE
CREATE TABLE T2 (... PRIMARY KEY K2 CASCADE CASCADE
ON DELETE CASCADE) T2 T3
CREATE TABLE T3 (... PRIMARY KEY K3 ON DELETE ON DELETE
FOREIGN KEY (K1) REFERENCES T1(K1) CASCADE NO ACTION
ON DELETE CASCADE) T4
CREATE TABLE T4 (... PRIMARY KEY K4

ON DELETE RESTRICT) NO ACTION
ON DELETE CASCADE)
à Bei NO ACTION wird Test der referenzierenden Relation ans Ende der Op verschoben
à Verletzung der referentiellen Beziehung à ROLLBACK
ð Schema ist immer sicher

Ausgewählte Anfrage-Konzepte
SFW-Block
5n SELECT
l Projektionsliste (= Ergebnisschema)
l arithmetische Operationen und Aggregatfunktionen
Auswertungsreihenfolge
1n FROM
l zu verarbeitende Relationen, evtl. Umbenennungen
2n WHERE
l Selektions-, Verbundbedingungen
l Geschachtelte Anfragen (wieder ein SFW-Block)
3n GROUP BY
l Gruppierung für Aggregatfunktionen
4n HAVING
l Selektionsbedingungen an Gruppen
Äußerer Verbund 1/2
n Zusätzlich zu klassischem Verbund (INNER JOIN)

l seit SQL2 auch äußerer Verbund
l _ Übernahme von Tupel in das Ergebnis, die keine Join-
Partner in der jeweiligen anderen Relation haben und
l _ Auffüllen mit Nullwerten
n OUTER JOIN
l übernimmt alle Tupel beider Operanden
l Langfassung: (NATURAL) FULL OUTER JOIN
n LEFT OUTER JOIN
l übernimmt alle Tupel des linken Operanden
n RIGHT OUTER JOIN
l übernimmt alle Tupel des rechten Operanden

Äußerer Verbund 2/2
LINKS A B RECHTS B C
NATURAL JOIN A B C
1 2 3 4
2 3 4
2 3 4 5
SELECT * FROM LINKS NATURAL JOIN RECHTS;
RIGHT OUTER JOIN FULL OUTER JOIN

A B C A B C SELECT *
2 3 4 1 2 NULL FROM LINKS NATURAL FULL OUTER JOIN
2 3 4
RECHTS;
NULL 4 5
NULL 4 5
LEFT OUTER JOIN

A B C SELECT L.A, L.B, R.C
1 2 NULL FROM LINKS L LEFT OUTER JOIN RECHTS R
2 3 4
ON L.B=R.B;

ROLLUP-Operator
n ROLLUP ist eine Erweiterung der GROUP BY-Klausel

n Mit dem ROLLUP-Operator können kumulative Aggregate,
z.B. Zwischensummen, erstellt werden
SELECT A, B, SUM(D)
FROM REL
WHERE D <= 7
A B SUM(D)
GROUP BY ROLLUP (A, B);
1 2 9
A B C D 1 3 5
1 2 3 4 1 14
1 2 4 5 2 3 4
1 3 4 5 Superaggregate
ROLLUP 2 4
für A (= 1,2,3)
2 3 3 4 3 3 5
3 3 4 5 3 4 7
3 4 6 7 3 12
Gesamtsumme
4 3 6 8 30

CUBE-Operator
n CUBE ist ebenso eine Erweiterung der GROUP BY-Klausel

n Mit dem CUBE-Operator können mit einer einzelnen SELECT-
Anweisung Kreuztabellenwerte erstellt werden
SELECT A, B, SUM(D) A B SUM(D)
FROM REL 30 Gesamtsumme
WHERE D <= 7
2 9
GROUP BY CUBE (A, B); nach B zusammen-
3 14 gefasst
A B C D 4 7
1 2 3 4 1 14 nach A zusammen-
1 2 4 5 gefasst
1 2 9
1 3 4 5 nach A und B
CUBE 1 3 5
zusammengefasst
2 3 3 4 2 4
3 3 4 5 2 3 4
3 4 6 7 3 12
4 3 6 8 3 3 5
3 4 7
Flug:
Ausgewählte Anfrage-Konzepte Flugnr Abflug Ziel Preis
Rekursive Anfrage 1/3

LH131 Frankfurt Sydney 1009
BA170 Zürich London 599
AF691 Paris New York 1299
UA103 Sydney New York 1549
SR163 Zürich Frankfurt 499
n Ermittle alle von Zürich aus direkt erreichbaren TK911 Paris Istanbul 799
Ziele! BA297 London Frankfurt 299
Zürich
SELECT Abflug, Ziel Abflug Ziel
London Frankfurt
FROM Flug Zürich London
WHERE Abflug = 'Zürich'; Zürich Frankfurt Frankfurt Sydney
Sydney New York

n Ermittle alle von Zürich aus indirekt erreichbaren Ziele!
New York
SELECT Abflug, Ziel
Abflug Ziel
FROM Flug
London Frankfurt
WHERE Abflug IN ( SELECT Ziel
Frankfurt Sydney
FROM Flug
WHERE Abflug = 'Zürich');
Abflug Ziel
n Ermittlung aller von Zürich aus erreichbaren Ziele Zürich London
kann mit den vorgestellten Mitteln jedoch in SQL Zürich Frankfurt
nicht formuliert werden. Zürich Sydney

Zürich New York

Rekursive Anfrage – SQL-Standard 2/3
WITH RECURSIVE Erreichbar(Abflug, Ziel) AS

(
SELECT Abflug, Ziel
FROM Flug 1 Abflug Ziel
WHERE Abflug = 'Zürich' Zürich London
UNION ALL Zürich Frankfurt
SELECT e.Abflug, f.Ziel Zürich Sydney
2 FROM Erreichbar e, Flug f
Zürich New York
WHERE e.Ziel = f.Abflug
)
SELECT DISTINCT *
FROM Erreichbar;
Rekursionsinitialisierung berechnet alle direkten

Verbindungen in der Rekursionsrelation Erreichbar
Rekursionsschritt berechnet alle indirekten Verbindungen

basierend auf den bereits berechneten Zielorten

Rekursive Anfrage – Oracle 3/3
n Implementierungen in konkreten Systemen (Oracle, DB2)

schon vor der Standardisierung vorhanden!
n Beispiel in Oracle:
SELECT Abflug, Ziel

FROM Flug
CONNECT BY PRIOR Ziel = Abflug
START WITH Abflug = 'Zürich';
Rekursionsbedingung: gibt die Spalten an, in denen die

PRIOR-Beziehung zwischen Vater- und Kindknoten besteht
Rekursionsinitialisierung: gibt die Anfangsknoten der Hierarchie an

bei denen begonnen werden soll

Ausgewählte DML-Konzepte
MERGE-Anweisung 1/2
n NEU in SQL:2003
n Kombination von mehreren UPDATE- und INSERT-
Anweisungen, die ausgewählte Spaltenwerte bzw. Tupel
aus einer Tabelle in eine andere Tabelle übernimmt
n Bedingungsabhängiges Aktualisieren oder Einfügen:

l UPDATE-Anweisung, wenn Zeile vorhanden ist
l INSERT-Anweisung, wenn neue Zeile NICHT vorhanden ist
n Vorteile:
l Vermeidet separate Aktualisierungen
l Steigert Performanz und Benutzerfreundlichkeit
l Nützlich z.B. für Data Warehousing-Anwendungen

MERGE-Anweisung 2/2
Zieltabelle, deren Daten aktualisiert oder ergänzt werden
MERGE INTO ziel_relation [AS ziel_relation_alias]

USING referenz_relation
Quelle kann Tabelle, Sicht oder Unteranfrage sein
ON verbund_bedingung
WHEN [MATCHED THEN UPDATE SET spalten_zuweisung]
[NOT MATCHED THEN INSERT[(attribute1..n)] VALUES (werte1..n)]
Aktualisiere bestehende Zeile Füge neue Zeile ein
n Je nachdem, ob die Verbundbedingung erfüllt ist oder nicht,

wird die jeweilige Klausel ausgeführt
MERGE INTO Lieferant l
USING Hersteller h
ON (l.LiefId = h.HerstId)
WHEN MATCHED THEN UPDATE SET
l.Name = h.Name
NOT MATCHED THEN INSERT
(LiefId, Name) VALUES (h.HerstId, h.Name);

Generierung Eindeutiger Schlüssel – Sequenzgenerator
n Seit SQL:2003, automatische Generierung von eindeutigen

numerischen Werten
l z.B. zur Vergabe von künstlichen Schlüsselwerten
l Parametrisierung: Startwert, Inkrement, Überlaufbehandlung
CREATE SEQUENCE PersonIDGen AS INT

START WITH 5000 INCREMENT BY 1
MINVALUE 1000 MAXVALUE 99999
CYCLE;
n CYCLE-Klausel bestimmt über den nächsten Schritt, wenn beim

Inkrementieren der Maximalwert (bzw. beim Dekrementieren der
Minimalwert) erreicht wird
l NO CYCLE beendet Generierung mit einer Ausnahmebedingung
l CYCLE setzt die Generierung mit dem Minimalwert fort
n Anwendung:
INSERT INTO MitarbeiterTupeltabelle (MNr, Name)
VALUES (NEXT VALUE FOR PersonIDGen, 'Harry');

Generierung Eindeutiger Schlüssel – Identitätsspalten
n Seit SQL:2003, automatische Generierung von Schlüsseln mit

Hilfe eines impliziten Sequenzgenerators
n Eine Tabelle darf maximal eine Identitätsspalte enthalten
CREATE TABLE Produkt (
ProdId INTEGER GENERATED ALWAYS AS IDENTITY
( START WITH 5000 INCREMENT BY 1
MINVALUE 1000 MAXVALUE 99999
NO CYCLE),
Bezeichnung VARCHAR(20), Preis DECIMAL(9,2), ...
);
INSERT INTO Produkt (Bezeichnung, Preis, ...)
VALUES ( 'Messer', 20,...);
n Wert der generierten Spalte wird automatisch berechnet

l z.B. DB2, SQLServer realisieren Identitätsspalte

Sichten (Views) im Allgemeinen
n Eigenschaften
l "dynamisches Fenster" auf Basistabellen
l Sichten auf Sichten möglich
l prinzipiell wie eine Tabelle behandelbar … ABER:
n Unterschied Sicht – Tabelle

l keine Integritätsbedingungen
l keine Indizes
l keine Trigger
l änderbare und nicht-änderbare Sichten
n Einsatz
l logische Datenunabhängigkeit
l vorformulierte Anfragen
l Sichten als "Zwischentabellen"
l Datenschutz

Materialisierte Sichten – Vorteile & Einsatz
n = Gespeicherte Tabelle
l Daten aus einer/mehreren Basistabellen oder anderen Sichten
l wie Basistabelle verwendbar
¡ SELECT ... FROM MaterializedView WHERE ...
n Vorteile
l Überwiegend lesender Zugriff auf stabiler Datenbasis
¡ geringer Aufwand bei Sicht-Aktualisierung
l Verbesserung der Performanz (Reduktion der Antwortzeit)
¡ DBS kann automatisch Anfrageteile erkennen, deren (Teil-)
Ergebnisse durch materialisierte Sichten zur Verfügung stehen
n Einsatz
l Data-Warehouses
l Replikation in verteilten DBS

Materialisierte Sichten – Auswahl und Wartung
n Auswahl materialisierter Sichten

l Speicherbedarf für redundant gehaltene Daten
l zusätzlicher Verwaltungsaufwand durch Materialisierung
(Materialisierungskonfiguration)
l erwartete Reduktion von Antwortzeiten
n Wartung materialisierter Sichten

l Änderungen in Basistabellen erfordern
¡ Neuberechnung der Sicht (ð Rematerialisierung) oder
¡ Propagierung der Änderungsoperationen zu den Sichten
(ð inkrementelle Aktualisierung)
l Zeitpunkt der Aktualisierung erfolgt
¡ sofort (synchrone)
¡ verzögert Nächste Folie ...
¡ durch Snapshot (asynchron)

Materialisierte Sichten – Aktualisierungszeitpunkt
n Sofortige (synchrone) Aktualisierung

l Sichten immer aktuell
l dafür werden die Modifikationstransaktionen behindert
n Verzögerte Aktualisierung
l Entkoppelung der Aktualisierung von Modifikationstransaktion;
bei Zugriff auf Sicht wird diese aktualisiert
l Sicht beim Lesen immer aktuell
l Lesende Transaktion trägt die Aktualisierungskosten
l Unter Umständen müssen viele Modifikationen nachgezogen
werden, wenn auf die Sicht lange nicht zugegriffen wurde
n Snapshot-Aktualisierung
l asynchron zur Modifikation und zum Lesezugriff nach
anwendungsspezifischen Gesichtspunkten

Materialisierte Sichten in ORACLE
n Automatisiert den Aktualisierungs(Refresh)-Prozess

n CREATE MATERIALIZED VIEW-Recht erforderlich!
Name der materialisierten Sicht
CREATE MATERIALIZED VIEW MGAL

REFRESH FORCE WIE? Aktualisierung erst dann,
Aktualisierungs-
strategie ON COMMIT WANN? wenn Änderungen in Basistabellen
WITH PRIMARY KEY festgeschrieben wurde (= commit)
AS
SELECT Mitarbeiter, Gehalt, MGA.Abteilung, Leiter
FROM MGA, AL
WHERE MGA.Abteilung = AL.Abteilung;
Berechnungsvorschrift, die den Inhalt für
materialisierte Sicht festlegt

Materialisierte Sichten in ORACLE – Aktualisierung
n Wann wird aktualisiert

l ON DEMAND: Nur bei Aufruf von speziellen Funktionen
l ON COMMIT: Beim Abschluss von Transaktionen, die
mindestens eine Basistabelle verändern
l START WITH date NEXT date: Aktualisiert Sicht zunächst
basierend auf START WITH date - mit NEXT date erfolgt
Aktualisierung in Intervallen
n Wie wird aktualisiert

l COMPLETE: Komplette Neuberechnung der Sicht bei
Änderungen an mindestens einer Basistabelle
l FAST: Inkrementelles Nachführen von Änderungen - nur bei
einfachen materialisierten Sichten möglich (= Daten nur aus
einer Basistabelle)
l FORCE: Ausführung von FAST, wenn möglich; sonst COMPLETE

Prozedurale Erweiterungen
Stored Procedures 1/2
n Erweiterung von SQL um prozedurale Konstrukte oder mittels

externer Programmiersprachen wie Java
l SQL/PSM (Persistent Stored Modules) – seit 1992 SQL-Standard!
n Erlauben die Ausführung komplexer DB-orientierter Operationen
innerhalb des DB-Servers
l Kontrolle muss nicht nach jeder SQL-Operation an das
Anwendungsprogramm zurückgegeben werden
l Performanz, Wiederverwendbarkeit, Wartungsfreundlichkeit
CREATE FUNCTION DEPT_SIZE (IN deptno INTEGER)

RETURNS VARCHAR[7]
DECLARE TOT_EMPS INTEGER;
SELECT COUNT (*) INTO TOT_EMPS

FROM SELECT EMPLOYEE WHERE DNO = deptno;
IF TOT_EMPS > 100 THEN RETURN “HUGE”
ELSEIF TOT_EMPS > 50 THEN RETURN “LARGE”
ELSEIF TOT_EMPS > 30 THEN RETURN “MEDIUM”
ELSE RETURN “SMALL”
ENDIF;
COOPERATIVE INFORMATION SYSTEMS 107/113
, JKU Linz
Stored Procedures 2/2
Compound statement BEGIN [ATOMIC] SQL-Anweisungen END;

SQL variable declaration DECLARE Variable Datentyp;
IF statement IF Prädikat THEN SQL-Anweisungen
ELSE SQL-Anweisungen END IF;
CASE statement CASE X WHEN Wert THEN SQL-Anweisungen
ELSE SQL-Anweisungen END CASE;
LOOP statement LOOP SQL-Anweisungen END LOOP;
WHILE statement WHILE Prädikat DO SQL-Anweisungen END WHILE;
REPEAT statement REPEAT SQL-Anweisungen UNTIL Prädikat END REPEAT;
FOR statement FOR Loop-Variable AS Cursor-Spezifikation
DO SQL-Anweisungen END FOR;
RETURN statement RETURN Rückgabewert;
CALL statement CALL Routine(Parameterliste);
Assignment statement SET Variable = Wert;
SIGNAL statement SIGNAL Ausnahme;

Trigger
n Reagiert automatisch auf vordefinierte Ereignisse in der

Datenbank mit entsprechenden Aktionen
l Event/Condition/Action-Rule (ECA-Regel)
l Basieren auf SQL/PSM
l "aktive DB-Konzepte"
n Einsatzgebiete
l Wahrung von Integritätsbedingungen (z.B. onUpdateCascade)
l Zugriffsschutz (z.B. zeitabhängige Zugriffserlaubnis)
l Definition von Geschäftsregeln (z.B. Rabattberechnung)
l Protokollierung (z.B. Tracing von Zugriffen)
n Erst mit SQL:1999 standardisiert

l obwohl kommerzielle Systeme Trigger schon lange unterstützen
l Sybase führte Trigger bereits 1987 ein

Trigger – Bestandteile
n Triggerereignis
l INSERT/DELETE/UPDATE auf Basistabelle
n Triggeraktivierungszeitpunkt
l BEFORE/AFTER Triggerereignis
n Triggergranularität
l FOR EACH ROW/STATEMENT
n Triggerbedingung CREATE TRIGGER OnUpdateCascadeMNr
l SQL-Bedingung AFTER UPDATE OF MNr ON Mitarbeiter
REFERENCING OLD AS AltMit NEW AS NeuMit
l Aktion nur dann FOR EACH ROW
ausgeführt, wenn WHEN(EXISTS(SELECT * FROM Mitarbeiter
Bedingung erfüllt ist WHERE Manager= AltMit.MNr))
n Triggeraktion BEGIN ATOMIC
UPDATE Mitarbeiter
l Sequenz von SET Vorgesetzter=NeuMit.MNr
SQL-Anweisungen WHERE Vorgesetzter=AltMit.MNr;
END;

Trigger – Standard vs. Systemunterstützung
SQL- DB2 ORACLE SQL Postgres-

Standard SERVER SQL
BEFORE-TRIGGER
AFTER-TRIGGER
INSERT-TRIGGER
UPDATE-TRIGGER
DELETE-TRIGGER
INSTEAD-OF-TRIGGER --- ---

Multiple-TRIGGER ?
DDL-TRIGGER --- ---
Rekursive-TRIGGER ? ?
ALTER-TRIGGER ---
DROP-TRIGGER

Literatur
n Philip A. Bernstein, Vassos Hadzilacos, Nathan Goodman: Concurrency control & recovery in DBS, Addison-Wesley (1987)
n Philip A. Bernstein, E. Newcomer: Principles of Transaction Processing, Morgan-Kaufmann, San Francisco, 1997.
n C.J. Date, An Introduction for Database Systems, Pearson Education, 2004
n Ramez Elmasri, Shamkant B. Navathe: Grundlagen von Datenbanksystemen – 7. Auflage, Pearson Studium (2016)
n Hector Garcia-Molina, Jeffrey D. Ullman, Jennifer Widom, Database Systems – The Complete Book, Prentice Hall, 2002
n Jim Gray, Andreas Reuter: Transaction processing: concepts and techniques. San Mateo, Kaufmann, (1994)
n M. Tamer Özsu, Patrick Valduriez: Principles of Distributed Database Systems, Third Edition, Prentice-Hall (2011)
n Erhard Rahm, Theo Härder: Datenbanksysteme - Konzepte und Techniken der Implementierung, Springer-Verlag, (1999)
n Gunter Saake, Andreas Heuer, Kai-Uwe Sattler: Datenbanken-Implementierungstechniken, 3. Auflage, MITP Verlag (2011)
n Gunter Saake, Andreas Heuer: Datenbanken - Konzepte und Sprachen, 6. Auflage, MITP Verlag (2018)
n Gunter Saake, Andreas Heuer: Datenbanken kompakt, MITP Verlag (Neuauflage 2003)
n Dennis Shasha and Phillipe Bonnet: Database Tuning: Principles Experiments and Troubleshooting Techniques, Morgan
Kaufmann Publishers (2002)
n Michael Stonebraker, Dorothy Moore: Object-relational DBMSs: the next great wave, San Francisco, Kaufmann (1996)
n Jeffrey D. Ullman: Principles of database and knowledge-base systems. - Vol. I & II, Computer Science Press (1988)
n Gottfried Vossen: Datenbankmodelle, Datenbanksprachen und Datenbank-Management-Systeme, Oldenbourg (1999)
n Gerhard Weikum, Gottfried Vossen: Transactional Information Systems, Morgan Kaufmann Publishers (2002)

Anhang
n F. Zemke, What‘s new in SQL:2011,

SIGMOD Record, Vol. 41, No. 1, March 2012
n K. Kulkarni et al., Temporal features in SQL:2011,

SIGMOD Record, Vol. 41, No. 3, September 2012
n J. Michels et al., The New and Improved SQL:2016

Standard,
SIGMOD Record, Vol. 47, No. 2, June 2018

Sprache

Willkommen bei Scribd!

M1 Grundlagen Von DB

Hochgeladen von

Dokumentinformationen

Beschreibung:

Datum des Uploads

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Beschreibung:

Copyright:

Verfügbare Formate

M1 Grundlagen Von DB

Hochgeladen von

Beschreibung:

Copyright:

Verfügbare Formate

Verwandte Titel

2

a.Univ.-Prof. Dr. Werner Retschitzegger

Der vorliegende Foliensatz basiert vorwiegend auf:

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 2/113

n Basis- oder Anwendungssoftware verwaltet ihre eigenen

n Daten sind redundant gespeichert – zahlreiche Probleme:

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 3/113

n Andere SW-Systeme können große Datenmengen

n Mehrere Benutzer oder Anwendungen können

n Anwendungsprogrammierer / Benutzer können Anwendungen

n Datenschutz und -Sicherheit sind nicht gewährleistet

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 4/113

n Die gesamte Anwendungs-SW arbeitet auf

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 5/113

n Anfang 60er Jahre

n Ende 60er Jahre

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 6/113

n 1970: Edgar F. Codd (IBM) _ Relationenmodell

n 1974: System R (IBM) _ erster Prototyp eines RDBS

n 1975: University of California at Berkeley _ Ingres

n 1979: Oracle Version 2

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 7/113

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 8/113

Anwendung 1 Anwendung 2 ... Anwendung n Software für die

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 9/113

Anfrage- DML- Kompilierte

Storage Subsysteme für Nebenläufigkeitskontrolle,

EXTERNE Externes Schema ... Externes Schema

KONZEPTUELLE/ Konzeptuelles/logisches Schema

n Konzeptuelles / logisches Schema

auf jeder Ebene

n Trennung Schema – Instanz

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 12/113

l eventuell Anwendungsprogramme betroffen –

l nötige Änderungen werden jedoch vom DBMS erkannt und

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 13/113

n Drei-Ebenen-Architektur nach ANSI-SPARC nur zum Teil

n SQL als einheitliche Datenbanksprache

n Einbettung von SQL in Programmiersprachen

n Diverse Werkzeuge für Definition, Anfrage, Darstellung von

n Kontrollierter Mehrbenutzerbetrieb, Zugriffskontrolle und

n Verfügbar für die wichtigsten Betriebssystemplattformen

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 14/113

n Umfassende Liste von RDBS

Chamberlin, D.D., et al.: A History and Evaluation of the System R,

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 15/113

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 16/113

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 17/113

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 18/113

n Föderierte Datenbanken, Multidatenbanken, Mediatoren

COOPERATIVE INFORMATION SYSTEMS, JKU Linz 19/113

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 20/113

n Ein Modell stellt eine Abstraktion eines Realitätsausschnitts

Modell: Konkretes oder gedankliches Abbild eines vorhandenen Gebildes

n Modelle erfassen meist nicht alle Individuen und Attribute des

COOPERATIVE INFORMATION SYSTEMS , JKU Linz 22/113

n Ein Datenmodell ist eine Menge von Konzepten zur