Datenbanksysteme 1

Datenbanksysteme I

Vorlesung SS 2006Paul Manthey

Datenbanksysteme 2

Charakteristika von Datenbanken• Eine Datenbank hat die (langfristige) Aufbewahrung von

Daten zur Aufgabe.• Die Sicherheit vor Verlusten ist eine Hauptmotivation, etwas

„auf die Bank zu bringen“.• Eine Bank bietet Dienstleistungen für mehrere Kunden an, um

effizient arbeiten zu können.• Gespeicherte Werte können „Zinsen“ bringen.• Datenbanken sind Investitionsgüter• Daten haben sehr lange Lebensdauer (Technologiesprünge)

Datenbanksysteme 3

Inhalte von DatenbankenEine fiktive Rechnung

Datenbanksysteme 4

Daten in Tabellenform• Kundentabelle speichert relevante Informationen des Kunden

(Namen, Kontostand, Adresse etc.); Kunde wird über die Kundennummer identifiziert

• Produkttabelle mit Informationen zu Produktnamen, Lagerort (die ersten beiden Angaben auf der Rechnung), Preis, vorhandener Lagerbestand (nicht auf der Rechnung); Identifikation erfolgt durch eine Produktnummer

• weitere Tabelle enthält Rechnungs- und Lieferungsdaten einzelner Rechnungen

• zur Vereinfachung werden Rechnungspositionen in einer separaten Tabelle gespeichert

Datenbanksysteme 5

Beispiel: Daten in Tabellenform

Datenbanksysteme 6

Nachteile ohne Datenbankeinsatz (1)• Datenformat: Basis- oder Anwendungssoftware verwaltet

ihre eigenen Daten in ihren eigenen (Datei-)Formaten• Textverarbeitung: Texte, Artikel und Adressen• Buchhaltung: Artikel, Adressen• Lagerverwaltung: Artikel, Aufträge• Auftragsverwaltung: Aufträge, Artikel, Adressen• CAD-System: Artikel, Technische Bausteine

• Redundanz: Daten sind redundant, d.h. mehrfach gespeichert; Verschwendung von Speicherplatz, „Vergessen“ von Änderungen; keine zentrale, „genormte“ Datenhaltung

• Datenbanksystem (DBS): DBS = DBMS + n * DB

Datenbanksysteme 7

Nachteile ohne Datenbankeinsatz (2)• Kapazität: Andere Software-Systeme können große Mengen

von Daten nicht effizient verarbeiten• Parallelverarbeitung: Mehrere Benutzer oder Anwendungen

können nicht parallel auf den gleichen Daten arbeiten, ohne sich zu stören

• Datenunabhängigkeit: Anwendungsprogrammierer / Benutzer können Anwendungen nicht programmieren / benutzen, ohne

• interne Darstellung der Daten,• Speichermedien oder Rechner

zu kennen (Datenunabhängigkeit nicht gewährleistet)• Sicherheit: Datenschutz und Datensicherheit sind nicht

gewährleistet

Datenbanksysteme 8

Vorteile mit Datenbankeinsatz• Datenintegration: Die gesamte Basis- und

Anwendungssoftware arbeitet auf denselben Daten, z.B. Adressen und Artikel werden nur einmal gespeichert

• Datenbanksysteme können große Datenmengen effizient verwalten (Anfragesprachen, Optimierung, Interne Ebene)

• Benutzer können parallel auf Datenbanken arbeiten (Transaktionskonzept)

• Datenunabhängigkeit durch 3-Ebenen-Konzept• Datenschutz (kein unbefugter Zugriff) und Datensicherheit

(kein ungewollter Datenverlust) werden vom System gewährleistet

Datenbanksysteme 9

Historie• Anfang 60er Jahre: elementare Dateien,

anwendungsspezifische Datenorganisation (geräteabhängig, redundant, inkonsistent)

• Ende 60er Jahre: Dateiverwaltungssysteme (SAM, ISAM) mit Dienst-programmen (geräteunabhängig, aber redundant und inkonsistent)

• 70er Jahre: Datenbanksysteme (Geräte- und Datenunabhängigkeit, redundanzfrei, konsistent)

• 1970: Ted Codd (IBM) Relationenmodell als konzeptionelle Grundlage relationaler DBS

• 1974: System R (IBM) erster Prototyp eines RDBMS• zwei Module: RDS, RSS; ca. 80.000 LOC (PL/1, PL/S,

Assembler), ca. 1,2 MB Codegröße, Anfragesprache SEQUEL

• erste Installation 1977• 1975: University of California at Berkeley (UCB) Ingres

• Anfragesprache QUEL, Vorgänger von Postgres, Sybase, . . .

• 1979: Oracle Version 2

Datenbanksysteme 10

Datenbankbegriff• Datenbank (DB): integrierte und strukturierte Sammlung großer

Bestände persistenter Daten, die allen Benutzern eines Anwendungsbereichs als gemeinsame und verlässliche Basis aktueller Information dient; häufig verwendeter synonymer Begriff: Datenbasis• Datenbank-Managementsystem (DBMS): All-Zweck-Softwaresystem, das den Be-nutzer bei der Definition, Konstruktion und Manipulation von Datenbanken für verschiedene Anwendungen applikati-onsneutral und effizient unterstützt; Menge von Programmen zur Verwaltung und zum Zugriff auf die Daten in der DB; Softwareschicht zwischen physischer Datenbank und dem Benutzer

• Datenbanksystem (DBS): DBS = DBMS + n * DB

Datenbanksysteme 11

Prinzipien• Grundmerkmale von DBMS:

• Verwalten persistente (langfristig zu haltende) Daten• Verwalten große Datenmengen effizient• Datenbankmodell, mit dessen Konzepten alle Daten

einheitlich beschrieben werden (Integration)• Operationen und Sprachen sind deskriptiv• Transaktionskonzept, Concurrency Control: logisch

zusammen-hängende Operationen atomar (unteilbar), Auswirkungen lang-lebig, können parallel durchgeführt werden

• Datenschutz, Datenintegrität (Konsistenz), Datensicherheit• Grundprinzip moderner Datenbanksysteme

• 3-Ebenen-Architektur (physische, logische Datenunabhängigkeit)

• Trennung zwischen Schema (etwa Tabellenstruktur) und Instanz (etwa Tabelleninhalt)

Datenbanksysteme 12

Codd‘sche Regeln1. Integration: einheitliche, nichtredundante

Datenverwaltung2. Operationen: Speichern, Suchen, Ändern3. Katalog: Zugriffe auf Datenbankbeschreibungen im Data

Dictionary4. Benutzersichten5. Integritätssicherung: Korrektheit des Datenbankinhalts6. Datenschutz: Ausschluss unauthorisierter Zugriffe7. Transaktionen: mehrere DB-Operationen als

Funktionseinheit8. Synchronisation: parallele Transaktionen koordinieren9. Datensicherung: Wiederherstellung von Daten nach

Systemfehlern

Datenbanksysteme 13

DBS-Strukturen• Beschreibung der Komponenten eines Datenbanksystems• Standardisierung der Schnittstellen zwischen Komponenten• Architekturvorschläge

• ANSI-SPARC-Architektur Drei-Ebenen-Architektur• Fünf-Schichten-Architektur Beschreibung von

Transforma-tionskomponenten im Detail• ANSI: American National Standards Institute• SPARC: Standards Planning and Requirement Committee• Vorschlag von 1978• Im Wesentlichen Grobarchitektur verfeinert

• Interne Ebene / Betriebssystem verfeinert• Mehr Interaktive und Programmier-Komponenten• Schnittstellen bezeichnet und normiert

Datenbanksysteme 14

Datenabstraktion: 3-Ebenen-Modell (ANSI/SPARC)

DBS besitzt mehrere Abstraktionsstufen

• externe Ebenen beschreiben den Teil der DB, der für Benutzer relevant ist

• konzeptionelle Ebene gibt an, welche Daten und Beziehungen in der DB vorhanden sind

• physische Ebene beschreibt, wie die Daten physisch abgelegt sind

Datenbankschema und -zustand• Schema beschreibt die

Struktur bzw. den Entwurf der DB

• Zustand bezeichnet eine konkrete Instanz einer DB

Datenbanksysteme 15

Klassifizierung der Komponenten• Definitionskomponenten: Datendefinition,

Dateiorganisation, Sichtdefinition• Programmierkomponenten: DB-Programmierung mit

eingebetteten DB-Operationen• Benutzerkomponenten: Anwendungsprogramme, Anfrage

und Update interaktiv• Transformationskomponenten: Optimierer, Auswertung,

Plattenzugriffssteuerung• Data Dictionary (Datenwörterbuch): Aufnahme der Daten

aus Definitionskomponenten, Versorgung der anderen Komponenten

Datenbanksysteme 16

DatenmodelleEin Datenmodell bietet Möglichkeiten

• zur Beschreibung der Datenobjekte• zur Beschreibung der Beziehung zwischen den Daten und• zur Festlegung der anwendbaren Operationen und deren

Wirkung (Semantik)Üblicherweise besitzt ein DBS mindestens zwei Datenmodelle (DM)

• physische DM zur speicher-orientierten Repräsentation der Daten

• logische DM zur benutzer-orientierten Repräsentation der Daten

• objekt-basiert, z.B. Entity Relationship Model (ERM), objekt-orientiertes DM, objekt-relationales DM

• satz-orientiert, z.B. objekt-relationales DM, relationales DM, Netzwerk-DM, hierarchisches DM

Datenbanksysteme 17

DB-SprachenDatendefinitionssprache (engl. data definition language, DDL)

• Sprache zur Manipulation des Datenbankschemas• (Meta-) Daten zur Beschreibung des Schemas

(Systemkatalog, data dictionary)• erlaubt die Spezifikation von Implementierungsdetails

Datenmanipulationssprache (engl. data manipulation language, DML)

• Anfragesprache (engl. query language) zum Suchen nach Datenobjekten in der DB

• „eigentliche“ Datenmanipulationssprache zur Änderung von abgespeicherten Datenobjekten, zum Einfügen von neuen Daten und zum Löschen von gespeicherten Daten

Datensteuerungssprache (engl. data control language, DCL)• Vergabe von Zugriffsrechten an Benutzer und DB-Objekte

Datenbanksysteme 18

Phasen des DatenbankentwurfsDatenorientierter Ansatz

• Welche Daten müssen im System verwaltet werden?• Wie werden die Daten im System verändert?

Datenbankentwurfsschritte

Datenbanksysteme 19

Anforderungsanalyse (1)basiert auf dem Wissen über Informationsstrukturanforderungen des relevanten Ausschnitts der realen Welt, z.B.

• Was sind die relevanten Objekte und deren Attribute?• Wie sehen die Beziehungen zwischen den Objekten aus?

und über Datenverarbeitungsanforderungen, z.B.• Was sind die typischen Operationen?• Bedeutung der Operationen, Laufzeit der Operationen,

DatenvolumenZentrales Problem bei der Anforderungsanalyse:

• Benutzer bzw. Anwendungsspezialist muss Informationen an den Entwickler übermitteln, d.h., Kommunikation zwischen dem Entwickler und dem Benutzer einer Datenbank erforderlich

• kein Patentrezept für eine erfolgreiche Anforderungsanalyse (Softwaretechnik-Problem)

Datenbanksysteme 20

Anforderungsanalyse (2)• Vorgehensweise:

• Sammlung des Informationsbedarfs in den Fachabteilungen

• Ergebnis: • informale Beschreibung (Texte, tabellarische

Aufstellungen, Formblätter, usw.) des Fachproblems• Trennen der Information über Daten (Datenanalyse) von

den Information über Funktionen (Funktionsanalyse)• „Klassischer“ DB-Entwurf:

• nur Datenanalyse und Folgeschritte• Funktionsentwurf:

• Methoden des Software Engineering

Datenbanksysteme 21

Konzeptioneller Entwurf (1)• Beschreibung der Datenstrukturen in einer formalen Sprache

auf der Basis eines konzeptionellen Datenmodells hoher Abstraktion

• bekanntestes konzeptionelles DM ist das Entity Relationship DM (ERM)

• Es werden nur Schemainformationen und keine Instanzen (Daten) betrachtet

⇒ nur DDL, aber keine DML erforderlich• Transformation der Anforderungsspezifikation in einen

konzeptionellen Entwurf ist schwierig:• Benutzer verwenden verschiedene Bezeichner für den

gleichen Objekttyp• Benutzer verwenden den gleichen Bezeichner für

verschiedene Objekttypen• Weglassen irrelevanter Strukturen (Abstraktion der realen

Objekte)

Datenbanksysteme 22

Konzeptioneller Entwurf (2)• Vorgehensweise:

• Modellierung von Sichten z.B. für verschiedene Fachabteilungen

• Analyse der vorliegenden Sichten in Bezug auf Konflikte• Integration der Sichten in ein Gesamtschema

• Ergebnis: konzeptionelles Gesamtschema, z.B. (E)ER-Diagramm

Datenbanksysteme 23

Logischer Entwurf• Abbildung der Datenstrukturen des konzeptionellen Modells in

Datenstrukturen eines logischen (Implementations-) DM, d.h., in konkrete Datenstrukturen der darunter liegenden Datenbank

• Datenstrukturen des logischen Modells abstrahieren von der physischen Repräsentation

• Ziel: einmalige Speicherung von Daten (Vermeidung von Redundanz)

Datenbanksysteme 24

Physischer Entwurf• Abbildung der Datenstrukturen des logischen Entwurfs auf

Dateien (physisches DM)• Berücksichtigung von Datensicherheitsprinzipien (RAID)• Unterstützung von Datensicherungsverfahren• Ausgewogener Einsatz von Indexstrukturen, um Anfragen

effizient zu unterstützen• zu viele Indizes: Updates der Datenbank werden zu teuer• zu wenige Indizes: Suchoperationen werden nicht effizient

unterstützt

Datenbanksysteme 25

DatenbankmodellDefinitionEin Datenbankmodell ist ein System von Konzepten zur Beschreibung von Datenbanken. Es legt Syntax und Semantik von Datenbankbeschreibungen für ein Datenbanksystem fest.Ein Datenbankmodell legt fest ...

1. statische Eigenschaften• Objekte und Beziehungen inklusive der Standard-

Datentypen, die Daten über die Beziehungen und Objekte darstellen können,

2. dynamische Eigenschaften wie• Operationen• Beziehungen zwischen Operationen,

3. Integritätsbedingungen an• Objekte• Operationen

Datenbanksysteme 26

Das Entity Relationship DMAllgemeines

• Peter P. Chen. The Entity-Relationship Model - Toward a Unified View of Data. Transactions on Database Systems 1(1):9-36 (1976)

• konzeptionelles DM mit hohem Abstraktionsniveau, leicht zu verstehen, unabhängig von Organisations- und Verwaltungsaspekten

• Zweiphasige Vorgehensweise beim DB-Entwurf• 1. Anforderungsanalyse und Entwurf des ERM• 2. Transformation des ERM in ein konkretes logisches

Modell• Ziel: Modellierung eines Ausschnitts der „realen Welt“ durch

Abstraktion, so dass Fragen über die reale Welt mit Hilfe des Modells beantwortet werden können

ER-Modell beschreibt die „reale Welt“ durch• Entitäten (Objekte, engl. entities)• Eigenschaften (Attribute, engl. attributes)• Beziehungen (engl. relationships) der Objekte zueinander

Datenbanksysteme 27

Entität (entity)• Entitäten sind wohlunterscheidbare physisch oder gedanklich

existierende Konzepte der zu modellierenden Welt.• Ähnliche Entitäten werden in einem Entity-Typ (einer Entity-

Menge) zusammengefasst, z.B. die Menge aller Bücher, Menge aller Vorlesungen

• Eine Entität wird durch eine Menge von zugehörigen Eigenschaften (Attributen) beschrieben, z.B. jedes Buch besitzt eine ISBN-Nummer, einen Autor, einen Verlag, ...

• Die Werte eines Attributs stammen aus Wertebereichen wie Integer, Real, String, ... z.B. der Name eines Autors ist vom Typ String

• formal: Attribut als Funktion von Entität auf einen Wertebereich

• Eine minimale Menge von Attributen, deren Werte die zugeordnete Entität eindeutig innerhalb aller Entitäten ihres Typs identifiziert, nennt man Schlüssel, z.B. ISBN-Nummer identifiziert ein Buch, eine Artikelnummer einen Artikel

Datenbanksysteme 28

Beziehung (relationship)• Eine Beziehung beschreibt einen Zusammenhang zwischen

Entitäten, z.B. Student Maier hört Vorlesung DBS I, Dozent hält Vorlesung SQL

• Eine homogene Menge von Beziehungen wird in einem Beziehungstyp (einer Beziehungsmenge) zusammengefasst, z.B. die Beziehungs-typen hört_Vorlesung, hält_Vorlesung

• formal: Beziehungstyp R zwischen den Entity-Typen E1, E2, ..., En als Relation, d.h., R ⊆ E1 × E2 × ... × En, n Grad der Beziehung R

hört_Vorlesung ⊆ Studenten × Vorlesungenhält_Vorlesung ⊆ Professoren × Vorlesungen

• Attribute charakterisieren Beziehungen, z.B. Häufigkeitsgrad (Eifer) als Attribut für hört_Vorlesung

• Entity-Typ kann mehrfach in einem Beziehungstyp vorkommen

• Einer binären Beziehung R(E, E), an der nur ein Entity-Typ beteiligt ist, kann Rolle zugeordnet werden, z.B. ist_Voraussetzung_für ⊆ Vorlesungen × Vorlesungen, erste Vorlesung / zweite Vorlesung hat Rolle des Vorgängers / Nachfolgers

Datenbanksysteme 29

Funktionalitäten von binären Beziehungstypen• 1:1-Beziehung (one-to-one relationship): falls für einen

binären Beziehungstyp R(E1, E2) jede Entität aus E1 mit höchstens einer Entität aus E2 in Beziehung steht und umgekehrt

• 1:m-Beziehung (one-to-many relationship): falls für einen binären Beziehungstyp R(E1, E2) jede Entität aus E1 mit beliebig vielen (also mehreren oder auch gar keinen) Entitäten aus E2 in Beziehung steht, aber jede Entität aus E2 mit höchstens einer Entität aus E1 in Beziehung stehen kann

• m:1-Beziehung (many-to-one relationship): analog zu 1:m-Beziehung

• m:n-Beziehung (many-to-many relationship): falls für einen binären Beziehungstyp R(E1, E2) jede Entität aus E1 mit beliebig vielen Entitäten aus E2 in Beziehung stehen kann und umgekehrt

Funktionalitäten als partielle Funktionen, z.B.• für 1:1-Beziehung: Ehemann: Frauen → Männer, Ehefrau:

Männer → Frauen• für 1:m- und m:1-Beziehung: beschäftigen: Personen →

Firmen

Datenbanksysteme 30

ER-Diagrammegraphische Repräsentation der Entity-Typen, Beziehungstypen und ihrer Attribute mittels eines GraphenNotation

• Rechtecke repräsentieren Entity-Typen:• Ellipsen oder Kreise repräsentieren Attribute:

• Sie sind über ungerichtete Kanten mit ihrem Entity-Typ verbunden

• Schlüssel-Attribute werden unterstrichen• ein Beziehungstyp wird durch eine Raute repräsentiert:

• Beziehungstypen werden mit ihren Entity-Typen durch Kanten verbunden

• Kanten tragen Kardinalitätsverhältnis gemäß ihrer Funktionalität (häufig wird auch Pfeilnotation verwendet)

• Eine Rolle eines Beziehungstyps wird an der entsprechenden Kante notiert.

Datenbanksysteme 31

ER-Diagramme: BeispielKonzeptionelles Schema einer Universität

Datenbanksysteme 32

ER-Diagramme: Erweiterungen (1)Existenzabhängige (schwache) Entity-Typen

• Bisher: Entitäten sind autonom und innerhalb ihrer Entity-Menge über Schlüsselattribute eindeutig identifizierbar (starke Entität)

• In der Realität gibt es aber auch schwache Entitäten, bei denen dies nicht gilt. Diese Entitäten sind

• in ihrer Existenz von einer übergeordneten Entität abhängig und

• nur in Kombination mit dem Schlüssel der übergeordneten Entität eindeutig identifizierbar.

Identifizierender Beziehungstyp• Ein (schwacher) Entity-Typ E1 ist mit einem (starken) Entity-

Typ E2 mittels eines identifizierenden Beziehungstyps verbunden, falls der Schlüssel von E1 den Schlüssel von E2 umfasst und einen oder mehrere zusätzliche Attribute von E1 enthält.

• Beziehung zum übergeordneten Entity-Typ hat in der Regel eine 1:m- und seltener eine 1:1-Funktionalität

Datenbanksysteme 33

ER-Diagramme: Erweiterungen (2)• Beispiel:

Vollkommene Teilnahme einer Entity-Menge an einer Beziehung• Alle Entities eines Entity-Typs E1 stehen in einer Beziehung R

zu einem anderen Entity-Typ E2.• Beispiel:

Datenbanksysteme 34

ER-Diagramme: Erweiterungen (3)Präzisere Charakterisierung der Funktionalitäten von Beziehungstypen

• (min, max)-Notation• für jeden an einem Beziehungstyp beteiligten Entity-Typ

bezeichnet• min: jede Entität dieses Typs steht mindestens min-mal in

Beziehung• max: jede Entität dieses Typs steht höchstens max-mal in

Beziehung• Sonderfälle

• min = 0: eine Entität braucht nicht eine Beziehung einzugehen (optional)

• max = *: eine Entität darf beliebig oft an einer Beziehung beteiligt sein

Datenbanksysteme 35

ER-Diagramme: Erweiterungen - BeispielKonzeptuelles Schema einer Universität mit (min, max)-Angaben

Datenbanksysteme 36

ER-Diagramme: Generalisierung• Ziele

• Abstraktion auf Typebene: bessere (d.h. natürlichere und übersichtlichere) Strukturierung der Entity-Typen

• Abstraktion auf Instanzebene: ähnliche Entitäten sollen in der Form eines gemeinsamen Entity-Typs modelliert werden

• „Herausfaktorisieren“ von Eigenschaften (Attribute, Beziehungen) ähnlicher Entity-Typen (Untertypen, Kategorien) zu einem gemeinsamen Obertyp

• Eigenschaften, die nicht „faktorisierbar“ sind, verbleiben beim jeweiligen Untertyp, d.h. der Untertyp ist eine Spezialisierung des Obertyps

• Vererbung als Schlüsselkonzept der Generalisierung: ein Untertyp erbt sämtliche Eigenschaften des Obertyps

• Entitäten eines Untertyps werden implizit als Entitäten des Obertyps betrachtet, daher: is-a in der graphischen Darstellung → Entitymen-ge des Untertyps ist eine Teilmenge der Entity-Menge des Obertyps

Datenbanksysteme 37

ER-Diagramme: Aggregation• Ziel: unterschiedliche Entity-Typen, die in ihrer Gesamtheit

einen strukturierten Obertyp bilden, werden einander zugeordnet

• Eine Aggregation ist ein besonderer Beziehungstyp, der einem übergeordneten Entity-Typ mehrere untergeordnete Entity-Typen zuordnet.

• Teil-von-Beziehung, part-of-Beziehung• Beispiel: Aufbau eines Fahrrads

Datenbanksysteme 38

Das Relationale DM• E.F. Codd. A Relational Model of Data for Large Shared Data

Banks. Communications of the ACM 13(6):377-387 (1970)• kommerzielle DBMS wie z.B. Oracle, Informix, SQL Server,

Sybase, DB/2 basieren auf dem relationalen Modell• Gründe für den Erfolg des relationalen DM

• flache Tabellen (Relationen) als zugrundeliegende Datenstruktur

• keine verschachtelten komplizierten Strukturen• mengenorientierte Verarbeitung der Daten im Gegensatz

zu der bis dahin vorherrschenden satzorientierten Verarbeitung (hierarchisches Modell, Netzwerkmodell)

• einfache Verständlichkeit auch für den unerfahrenen Benutzer

• gute Einsetzbarkeit / Performance für Standard-DB-Anwendungen

• Existenz einer ausgereiften, formalen Theorie (im Gegensatz zu anderen DM), insbesondere hinsichtlich des Entwurfs relationaler DB und der effizienten Verarbeitung von Benutzeranfragen

Datenbanksysteme 39

Das Relationale DM - Grundlegende Struktur• Gegeben seien n Wertebereiche (Domänen, engl. domains) D1,

D2, ..., Dn

• Beispiele Wertebereiche: Datentyp Integer, string, real, bool, date, ...

• Wertebereiche müssen nicht verschieden sein, Di = Dj ist zulässig für i ≠ j

• Wertebereiche dürfen nur atomare Werte enthalten, also nicht strukturiert sein

• eine Relation(eninstanz) rR ist definiert als eine Teilmenge des kartesischen Produkts (Kreuzprodukts) der n Wertebereiche:

• rR ⊆ D1 × D2 × ... × Dn (rR endlich, n Grad der Relation)• rR ist eine Ausprägung (Instanz) eines zugehörigen

Relationenschemas R (analog zum programmiersprachlichen Begriff einer Variablen).

• ein Element der Menge R wird Tupel genannt, Tupel hat Stelligkeit n

• Beispiel: Wertebereiche: D1 = {a, b, c}, D2 = {0, 1}• Kartesisches Produkt: D1 × D2 = {(a, 0), (a, 1), (b, 0), (b, 1), (c, 0), (c,

1)}• Beispiele für Instanzen: r1 = {(a, 0), (b, 0), (c, 0), (c, 1)}, r2 = {(a,

0)}, r3 = Ø

Datenbanksysteme 40

Schemadefinition (1)• Unterscheidung des Schemas einer Relation R, das durch die n

Wertebereiche (Datentypen) gegeben ist, und der aktuellen Ausprägung (Instanz) dieses Relationenschemas, die durch die Teilmenge des Kreuzprodukts gegeben ist

• Schema analog zum programmiersprachlichen Begriff einer Typdefinition

• Ein Relationenschema R, bezeichnet mittels R(A1, A2, ..., An), besteht aus dem Relationennamen R und einer Liste von Attributen A1, A2, ..., An.

• Jedes Attribut Ai ist der Name einer Rolle, die der Wertebereich Di im Relationenschema R spielt.

• Di ist also der Wertebereich (Typ) von Ai

• Notation: Di = dom(Ai)• Für das Schema R(A1, A2, ..., An) gilt: rR ⊆ dom(A1) × dom(A2) × ... ×

dom(An).• Man schreibt das Schema von R auch in der Form R(A1 : D1, A2 : D2, ...,

An : Dn).• Da oft keine klare Unterscheidung zwischen der Metaebene (Schema)

und der Instanzebene (Ausprägung) gemacht wird, bezeichnet man auch Relationenin-stanzen mit dem Buchstaben R.

Datenbanksysteme 41

Schemadefinition (2)• Darstellung einer Relation als Tabelle mit Zeilen (Tupel) und Spalten

• Beispiel: Relation Studenten(MatrNr : string, Name : string, Alter : integer, ...)

Datenbanksysteme 42

Merkmale von RelationenOrdnung auf den Tupeln in einer Relation

• Eine Relation ist definiert als eine Menge von Tupeln, d.h., die Tupel in einer Relation sind nicht geordnet.

• In einer Datei sind die Datensätze physisch geordnet.• Ebenso sind die Zeilen in einer Tabelle geordnet.

Ordnung auf den Werten in einem Tupel • Lt. Definition einer Relation ist ein Tupel eine geordnete Liste von n

Werten.• Aus logischer Sicht ist die Ordnung der Attribute und ihrer Werte

unwichtig, nur die Korrespondenz zwischen Attributen / Werten muss erhalten werden.

Werte in Tupeln• Jeder Wert in einem Tupel ist ein atomarer (unteilbarer) Wert.• keine zusammengesetzten oder mehrwertigen Attribute erlaubt• Werte von Attributen in einem Tupel können unbekannt /

unzutreffend sein• Verwendung eines speziellen Null-Wertes für diesen Fall

Datenbanksysteme 43

Schlüssel• analog zum Schlüsselbegriff des ER-Modells• Wegen der Mengeneigenschaft von Relationen gibt es keine

zwei Tupel, die die gleiche Kombination von Werten für alle ihre Attribute haben.

• Sei R(A1, A2, ..., An) gegeben, und sei X ⊆ {A1, A2, ..., An}. X heißt Schlüssel, wenn folgende Bedingungen erfüllt sind:

• Eindeutigkeit: für alle (real möglichen) Relationeninstanzen rR von R gilt:

∀ t1, t2 ∈ rR : t1[X] = t2[X] ⇒ t1 = t2

• Minimalität: es gibt kein Y ⊂ X, so dass Eindeutigkeit erfüllt ist

• Kandidatenschlüssel: mehrere mögliche Schlüssel, einer ist Primärschlüssel

Datenbanksysteme 44

Integritätsbedingungen• Integritätsbedingungen (engl. integrity constraints) (IBs)

• stellen ein Mittel dar, um sicherzustellen, dass Änderungen der DB durch autorisierte Benutzer zu keinem Verlust der Datenkonsistenz führen.

• dienen zur Einschränkung der DB-Zustände auf diejenigen, die es in der realen Welt tatsächlich gibt.

• sind aus dem erstellten DM semantisch ableitbar und können des-halb bereits bei der Erstellung des Schemas angegeben werden.

• Vorteile• Konsistenzbedingungen werden nur einmal angegeben• Konsistenzbedingungen werden automatisch vom DBMS

überprüft• Anwendungen brauchen sich um eine Überprüfung der

Bedingungen nicht zu kümmern

Datenbanksysteme 45

Referentielle Integrität• Referentielle IBs sind Bedingungen an Relationen, die insbesondere

eine Beziehung modellieren.• Erhalten die Konsistenz zwischen Tupeln zweier Relationen aufrecht.• Eine referentielle IB fordert, dass sich ein Tupel einer Relation, das

sich auf eine andere Relation bezieht, auf ein existierendes Tupel dieser Relation beziehen muss.

• Seien R und S Relationen mit den Schemata R und S. Sei K ⊆ R Primärschlüssel von R. Dann wird F ⊆ S Fremdschlüssel von S genannt, falls für jeden Datensatz s aus der Relation S eine der folgenden Bedingungen gilt:

• Es gilt ∀ A ∈ F : s[A] = null.• Es gibt einen Datensatz r aus R, so daß s[F] = r[K] gilt.

• Beispiel: Relationen Kunde, Ware, Bestellt (m:n-Beziehung zw. Kunde / Ware)

• mögliche Probleme, wenn referentielle Integrität nicht gegeben ist:• Kunde bestellt eine Ware, die es nicht gibt.• Waren können von einem Kunden bestellt werden, der nicht

existiert.

Datenbanksysteme 46

Integritätsbedingungen - Beispiele• Kein Kundenname darf mehrfach in der Relation „Kunden“

vorkommen.• Jeder Kundenname in der Relation „Auftrag“ muss auch in der

Relation „Kunden“ vorkommen.• Kein Kontostand eines Kunden darf unter -100 DM absinken.• Das Konto von Weiß darf überhaupt nicht überzogen werden.• Nur solche Waren dürfen bestellt werden, für die es

mindestens einen Lieferanten gibt.• Der Brotpreis darf nicht erhöht werden.

Datenbanksysteme 47

ER-Abbildung auf Relationen• Entity-Typen und Beziehungstypen: jeweils auf

Relationenschemata• Attribute: Attribute des Relationenschemas, Schlüssel

werden übernommen• Kardinalitäten der Beziehungen: durch Wahl der Schlüssel

bei den zugehörigen Relationenschemata ausgedrückt• in einigen Fällen: Verschmelzen der Relationenschemata

von Entity- und Beziehungstypen• zwischen den verbleibenden Relationenschemata diverse

Fremdschlüsselbedingungen einführen

Datenbanksysteme 48

Abbildung von Beziehungstypen• neues Relationenschema mit allen Attributen des

Beziehungstyps, zusätzlich Übernahme aller Primärschlüssel der beteiligten Entity-Typen

• Festlegung der Schlüssel:• m:n-Beziehung: beide Primärschlüssel zusammen

werden Schlüssel im neuen Relationenschema• 1:n-Beziehung: Primärschlüssel der n-Seite (bei der

funktionalen Notation die Seite ohne Pfeilspitze) wird Schlüssel im neuen Relationenschema

• 1:1-Beziehung: beide Primärschlüssel werden je ein Schlüssel im neuen Relationenschema, der Primärschlüssel wird dann aus diesen Schlüsseln gewählt

Datenbanksysteme 49

m:n-Beziehungen

• UmsetzungBestellung (Bestell#, Datum)

Produkt (Produkt#, Bezeichnung, Preis)

Umfasst (Bestell# Bestellung,

Produkt# Produkt, Anzahl)• Attribute Bestell# und Produkt# sind gemeinsam Schlüssel

Datenbanksysteme 50

1:n-Beziehungen

• Umsetzung (zunächst)Produkt (Produkt#, Bezeichnung, Preis)

Hersteller (HerstId, Name, Adresse)

GeliefertVon(Produkt#, HerstId)

Datenbanksysteme 51

Abhängige Entity-Typen

• UmsetzungBestellposition(PosNr, BestNr Bestellung, Menge, Produkt)

Bestellung(BestNr, Datum)

Datenbanksysteme 52

Mögliche Verschmelzungen• optionale Beziehungen ((0, 1) oder (0, n)) werden nicht ver-

schmolzen• bei Kardinalitäten (1, 1) oder (1, n) (zwingende Beziehungen)

Verschmelzung möglich:• 1:n-Beziehung: das Entity-Relationenschema der n-Seite

kann in das Relationenschema der Beziehung integriert werden

• 1:1-Beziehung: beide Entity-Relationenschemata können in das Relationenschema der Beziehung integriert werden

Datenbanksysteme 53

Verschmelzung bei 1:n-Beziehung

• da Produkt von einem Hersteller geliefert werden muss (zwingende Beziehung), können Relationenschemata Produkt und Geliefert_Von verschmolzen werden

• UmsetzungProdukt (Produkt#, Bezeichnung, Preis, HerstId Hersteller)

Hersteller (HerstId, Name, Adresse)

Datenbanksysteme 54

1:1-Beziehung

• Standardumsetzung (ohne Verschmelzung):•Drachen (Produkt#, Spannweite, Leinen)

•Prospekt (Prospekt#, Eignung, Einsatz, Foto)•Beschrieben_In (Produkt# Drachen, Prospekt# Prospekt)

Datenbanksysteme 55

Umsetzung der 1:1-Beziehung• Umsetzung mit Verschmelzung:

• Effekt bei „unechter“ 1:1-Beziehung:

Datenbanksysteme 56

Ist-Beziehung

• UmsetzungProdukt (Produkt#, Bezeichnung, Preis)

Drachen (Produkt# Produkt, Spannweite, Leinen)

Windspiel (Produkt# Produkt, Art)

Datenbanksysteme 57

Rekursive Beziehungen

• UmsetzungProdukt (Produkt#, Bezeichnung, Preis)

Ist_Zubehör_Für (Basisprodukt Produkt, Zubehör Produkt)

Datenbanksysteme 58

Mehrstellige Beziehungen

• jeder beteiligte Entity-Typ wird nach den obigen Regeln behandelt

• für Beziehung Löst_Aus werden Primärschlüssel der drei beteiligten Entity-Typen in das resultierende Relationenschema aufgenommen

• Beziehung ist allgemeiner Art (k:m:n-Beziehung): alle Primärschlüssel bilden zusammen den Schlüssel

Datenbanksysteme 59

Übersicht über die Transformationen

Datenbanksysteme 60

Relationaler DB-Entwurf• Verfeinern des logischen Entwurfs• Ziel: Vermeidung von Redundanzen durch Aufspalten von

Relationen-schemata, ohne gleichzeitig semantische Informationen zu verlieren

• (Abhängigkeitstreue)• die Möglichkeit zur Rekonstruktion der Relationen zu

verlieren (Verbundtreue)• Redundanzvermeidung durch Normalformen

Datenbanksysteme 61

Beispiel: Prod_Herst-Relation mit Redundanzen

Datenbanksysteme 62

Redundanzen• Redundanzen in Basisrelationen aus mehreren Gründen

unerwünscht:• Redundante Informationen belegen unnötigen Speicherplatz• Änderungsoperationen auf Basisrelationen mit Redundanzen

nur schwer korrekt umsetzbar: wenn eine Information redundant vorkommt, muss eine Änderung diese Information in allen ihren Vorkommen verändern

• mit normalen relationalen Änderungsoperationen und den in relationalen Systemen vorkommenden lokalen Integritätsbedingungen (Schlüsseln) nur schwer realisierbar

Datenbanksysteme 63

Update-Anomalien• Einfügen in die mit Redundanzen behaftete Produkt-

Hersteller-Relation:

• Integritätsbedingung verletzt, die in dieser Relation durch eine Schlüsselbedingung nicht spezifiziert werden kann

• dem Hersteller mit der ID 902 ist eigentlich der Herstellername „Dragon.com“ zugeordnet und nicht der Name „OnTheMove“

Datenbanksysteme 64

Funktionale AbhängigkeitenDefinition

Funktionale Abhängigkeit zwischen Attributmengen X und Y einer Relation herrscht dann, wenn in jedem Tupel der Relation der Attributwert unter den X-Komponenten den Attributwert unter den Y-Komponenten festlegt.

• Unterscheiden sich zwei Tupel in den X-Attributen nicht, so haben sie auch gleiche Werte für alle Y-Attribute

• Notation für funktionale Abhängigkeit (FD, von functional dependency): X Y

Beispiel:ProdID Bezeichnung, HerstID

Datenbanksysteme 65

Schemaeigenschaften und Normalformen• Relationenschemata, Schlüssel und Fremdschlüssel so wählen,

dass1. alle Anwendungsdaten aus den Basisrelationen

hergeleitet werden können,2. nur semantisch sinnvolle und konsistente

Anwendungsdaten dargestellt werden können und3. die Anwendungsdaten möglichst nicht-redundant

dargestellt werden.• Hier: Forderung 3

• Redundanzen innerhalb einer Relation: Normalformen• globale Redundanzen: Minimalität

• Normalformen legen Eigenschaften von Relationenschemata fest

• Normalformen verbieten bestimmte Kombinationen von funktionalen Abhängigkeiten in Relationen

• Normalformen sollen Redundanzen und Anomalien vermeiden

Datenbanksysteme 66

1. Normalform (1)• erlaubt nur atomare Attribute in den Relationenschemata, d.h.

als Attributwerte sind Elemente von Standard-Datentypen wie integer oder string erlaubt, aber keine Konstruktoren wie array oder set

• Vorher: Nicht in 1NF

Datenbanksysteme 67

1. Normalform (2)• Nachher: In 1NF

Datenbanksysteme 68

2. Normalform• Partielle Abhängigkeit liegt vor, wenn ein Attribut funktional

schon von einem Teil des Schlüssels abhängtBestNr Datum

undBestNr, ProdId BestNr, ProdId, Datum, KNr, VersandId

• Zweite Normalform eliminiert derartige partielle Abhängigkeiten bei Nichtschlüsselattributen

Datenbanksysteme 69

Eliminierung partieller Abhängigkeiten

Datenbanksysteme 70

3. Normalform• eliminiert (zusätzlich) transitive Abhängigkeiten• etwa ProdId HerstId und HerstId Name• man beachte: 3NF betrachtet nur Nicht-Schlüsselattribute als

Endpunkt transitiver Abhängigkeiten

Datenbanksysteme 71

Eliminierung transitiver Abhängigkeiten

Datenbanksysteme 72

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

auch zwischen Primattributen• Beispiel

Produkt(Produkt#, Hersteller, Lieferant, Preis)

• FDs:Produkt#, Hersteller Preis

Hersteller Lieferant

Lieferant Hersteller

• Schlüsselkandidaten: Produkt#, Hersteller und Produkt#, Lieferant

• in 3NF, nicht jedoch in BCNF• Schema in BCNF:

Produkt(Produkt#, Hersteller, Preis)

HerstLief(Hersteller, Lieferant)• BCNF kann jedoch Abhängigkeitstreue verletzen, daher oft nur

bis 3NF

Datenbanksysteme 73

Minimalität• Global Redundanzen vermeiden• andere Kriterien (wie Normalformen) mit möglichst wenig

Schemata erreichen• Beispiel: Attributmenge ABC, FD-Menge {A B,B C}• Datenbankschemata in dritter Normalform:

• S = {(AB, {A}), (BC, {B})}• S‘ = {(AB, {A}), (BC, {B}), (AC, {A})}

• Redundanzen in S‘

Datenbanksysteme 74

Schemaeigenschaften