datenbanksysteme1 datenbanksysteme i vorlesung ss 2006 paul manthey
TRANSCRIPT
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