Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Datenbanksysteme1 Datenbanksysteme I Vorlesung SS 2006 Paul Manthey.

Ähnliche Präsentationen


Präsentation zum Thema: "Datenbanksysteme1 Datenbanksysteme I Vorlesung SS 2006 Paul Manthey."—  Präsentation transkript:

1 Datenbanksysteme1 Datenbanksysteme I Vorlesung SS 2006 Paul Manthey

2 Datenbanksysteme2 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)

3 Datenbanksysteme3 Inhalte von Datenbanken Eine fiktive Rechnung

4 Datenbanksysteme4 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

5 Datenbanksysteme5 Beispiel: Daten in Tabellenform

6 Datenbanksysteme6 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

7 Datenbanksysteme7 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

8 Datenbanksysteme8 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

9 Datenbanksysteme9 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 LOC (PL/1, PL/S, Assembler), ca. 1,2 MB Codegröße, Anfragesprache SEQUEL erste Installation : University of California at Berkeley (UCB)  Ingres Anfragesprache QUEL, Vorgänger von Postgres, Sybase, : Oracle Version 2

10 Datenbanksysteme10 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

11 Datenbanksysteme11 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)

12 Datenbanksysteme12 Codd‘sche Regeln 1.Integration: einheitliche, nichtredundante Datenverwaltung 2.Operationen: Speichern, Suchen, Ändern 3.Katalog: Zugriffe auf Datenbankbeschreibungen im Data Dictionary 4.Benutzersichten 5.Integritätssicherung: Korrektheit des Datenbankinhalts 6.Datenschutz: Ausschluss unauthorisierter Zugriffe 7.Transaktionen: mehrere DB-Operationen als Funktionseinheit 8.Synchronisation: parallele Transaktionen koordinieren 9.Datensicherung: Wiederherstellung von Daten nach Systemfehlern

13 Datenbanksysteme13 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

14 Datenbanksysteme14 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

15 Datenbanksysteme15 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

16 Datenbanksysteme16 Datenmodelle Ein 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

17 Datenbanksysteme17 DB-Sprachen Datendefinitionssprache (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

18 Datenbanksysteme18 Phasen des Datenbankentwurfs Datenorientierter Ansatz Welche Daten müssen im System verwaltet werden? Wie werden die Daten im System verändert? Datenbankentwurfsschritte

19 Datenbanksysteme19 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, Datenvolumen Zentrales 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)

20 Datenbanksysteme20 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

21 Datenbanksysteme21 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)

22 Datenbanksysteme22 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

23 Datenbanksysteme23 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)

24 Datenbanksysteme24 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

25 Datenbanksysteme25 Datenbankmodell Definition Ein 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

26 Datenbanksysteme26 Das Entity Relationship DM Allgemeines 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

27 Datenbanksysteme27 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

28 Datenbanksysteme28 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 E 1, E 2,..., E n als Relation, d.h., R ⊆ E 1 × E 2 ×... × E n, n Grad der Beziehung R hört_Vorlesung ⊆ Studenten × Vorlesungen hä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

29 Datenbanksysteme29 Funktionalitäten von binären Beziehungstypen 1:1-Beziehung (one-to-one relationship): falls für einen binären Beziehungstyp R(E 1, E 2 ) jede Entität aus E 1 mit höchstens einer Entität aus E 2 in Beziehung steht und umgekehrt 1:m-Beziehung (one-to-many relationship): falls für einen binären Beziehungstyp R(E 1, E 2 ) jede Entität aus E 1 mit beliebig vielen (also mehreren oder auch gar keinen) Entitäten aus E 2 in Beziehung steht, aber jede Entität aus E 2 mit höchstens einer Entität aus E 1 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(E 1, E 2 ) jede Entität aus E 1 mit beliebig vielen Entitäten aus E 2 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

30 Datenbanksysteme30 ER-Diagramme graphische Repräsentation der Entity-Typen, Beziehungstypen und ihrer Attribute mittels eines Graphen Notation 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.

31 Datenbanksysteme31 ER-Diagramme: Beispiel Konzeptionelles Schema einer Universität

32 Datenbanksysteme32 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 E 1 ist mit einem (starken) Entity-Typ E 2 mittels eines identifizierenden Beziehungstyps verbunden, falls der Schlüssel von E 1 den Schlüssel von E 2 umfasst und einen oder mehrere zusätzliche Attribute von E 1 enthält. Beziehung zum übergeordneten Entity-Typ hat in der Regel eine 1:m- und seltener eine 1:1-Funktionalität

33 Datenbanksysteme33 ER-Diagramme: Erweiterungen (2) Beispiel: Vollkommene Teilnahme einer Entity-Menge an einer Beziehung Alle Entities eines Entity-Typs E 1 stehen in einer Beziehung R zu einem anderen Entity-Typ E 2. Beispiel:

34 Datenbanksysteme34 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

35 Datenbanksysteme35 ER-Diagramme: Erweiterungen - Beispiel Konzeptuelles Schema einer Universität mit (min, max)-Angaben

36 Datenbanksysteme36 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

37 Datenbanksysteme37 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

38 Datenbanksysteme38 Das Relationale DM E.F. Codd. A Relational Model of Data for Large Shared Data Banks. Communications of the ACM 13(6): (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

39 Datenbanksysteme39 Das Relationale DM - Grundlegende Struktur Gegeben seien n Wertebereiche (Domänen, engl. domains) D 1, D 2,..., D n Beispiele Wertebereiche: Datentyp Integer, string, real, bool, date,... Wertebereiche müssen nicht verschieden sein, D i = D j ist zulässig für i ≠ j Wertebereiche dürfen nur atomare Werte enthalten, also nicht strukturiert sein eine Relation(eninstanz) r R ist definiert als eine Teilmenge des kartesischen Produkts (Kreuzprodukts) der n Wertebereiche: r R ⊆ D 1 × D 2 ×... × D n (r R endlich, n Grad der Relation) r R 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: D 1 = {a, b, c}, D 2 = {0, 1} Kartesisches Produkt: D 1 × D 2 = {(a, 0), (a, 1), (b, 0), (b, 1), (c, 0), (c, 1)} Beispiele für Instanzen: r 1 = {(a, 0), (b, 0), (c, 0), (c, 1)}, r 2 = {(a, 0)}, r 3 = Ø

40 Datenbanksysteme40 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(A 1, A 2,..., A n ), besteht aus dem Relationennamen R und einer Liste von Attributen A 1, A 2,..., A n. Jedes Attribut A i ist der Name einer Rolle, die der Wertebereich D i im Relationenschema R spielt. D i ist also der Wertebereich (Typ) von A i Notation: D i = dom(A i ) Für das Schema R(A 1, A 2,..., A n ) gilt: r R ⊆ dom(A 1 ) × dom(A 2 ) ×... × dom(A n ). Man schreibt das Schema von R auch in der Form R(A 1 : D 1, A 2 : D 2,..., A n : D n ). 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.

41 Datenbanksysteme41 Schemadefinition (2) Darstellung einer Relation als Tabelle mit Zeilen (Tupel) und Spalten Beispiel: Relation Studenten(MatrNr : string, Name : string, Alter : integer,...)

42 Datenbanksysteme42 Merkmale von Relationen Ordnung 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

43 Datenbanksysteme43 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(A 1, A 2,..., A n ) gegeben, und sei X ⊆ {A 1, A 2,..., A n }. X heißt Schlüssel, wenn folgende Bedingungen erfüllt sind: Eindeutigkeit: für alle (real möglichen) Relationeninstanzen r R von R gilt: ∀ t 1, t 2 ∈ r R : t 1 [X] = t 2 [X] ⇒ t 1 = t 2 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

44 Datenbanksysteme44 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

45 Datenbanksysteme45 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.

46 Datenbanksysteme46 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.

47 Datenbanksysteme47 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

48 Datenbanksysteme48 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

49 Datenbanksysteme49 m:n-Beziehungen Umsetzung Bestellung (Bestell#, Datum) Produkt (Produkt#, Bezeichnung, Preis) Umfasst (Bestell#  Bestellung, Produkt#  Produkt, Anzahl) Attribute Bestell# und Produkt# sind gemeinsam Schlüssel

50 Datenbanksysteme50 1:n-Beziehungen Umsetzung (zunächst) Produkt (Produkt#, Bezeichnung, Preis) Hersteller (HerstId, Name, Adresse) GeliefertVon(Produkt#, HerstId)

51 Datenbanksysteme51 Abhängige Entity-Typen Umsetzung Bestellposition(PosNr, BestNr  Bestellung, Menge, Produkt) Bestellung(BestNr, Datum)

52 Datenbanksysteme52 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

53 Datenbanksysteme53 Verschmelzung bei 1:n-Beziehung da Produkt von einem Hersteller geliefert werden muss (zwingende Beziehung), können Relationenschemata Produkt und Geliefert_Von verschmolzen werden Umsetzung Produkt (Produkt#, Bezeichnung, Preis, HerstId  Hersteller) Hersteller (HerstId, Name, Adresse)

54 Datenbanksysteme54 1:1-Beziehung Standardumsetzung (ohne Verschmelzung): Drachen (Produkt#, Spannweite, Leinen) Prospekt (Prospekt#, Eignung, Einsatz, Foto) Beschrieben_In (Produkt#  Drachen, Prospekt#  Prospekt)

55 Datenbanksysteme55 Umsetzung der 1:1-Beziehung Umsetzung mit Verschmelzung: Effekt bei „unechter“ 1:1-Beziehung:

56 Datenbanksysteme56 Ist-Beziehung Umsetzung Produkt (Produkt#, Bezeichnung, Preis) Drachen (Produkt#  Produkt, Spannweite, Leinen) Windspiel (Produkt#  Produkt, Art)

57 Datenbanksysteme57 Rekursive Beziehungen Umsetzung Produkt (Produkt#, Bezeichnung, Preis) Ist_Zubehör_Für (Basisprodukt  Produkt, Zubehör  Produkt)

58 Datenbanksysteme58 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

59 Datenbanksysteme59 Übersicht über die Transformationen

60 Datenbanksysteme60 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

61 Datenbanksysteme61 Beispiel: Prod_Herst-Relation mit Redundanzen

62 Datenbanksysteme62 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

63 Datenbanksysteme63 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“

64 Datenbanksysteme64 Funktionale Abhängigkeiten Definition 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

65 Datenbanksysteme65 Schemaeigenschaften und Normalformen Relationenschemata, Schlüssel und Fremdschlüssel so wählen, dass 1.alle Anwendungsdaten aus den Basisrelationen hergeleitet werden können, 2.nur semantisch sinnvolle und konsistente Anwendungsdaten dargestellt werden können und 3.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

66 Datenbanksysteme66 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

67 Datenbanksysteme67 1. Normalform (2) Nachher: In 1NF

68 Datenbanksysteme68 2. Normalform Partielle Abhängigkeit liegt vor, wenn ein Attribut funktional schon von einem Teil des Schlüssels abhängt BestNr  Datum und BestNr, ProdId  BestNr, ProdId, Datum, KNr, VersandId Zweite Normalform eliminiert derartige partielle Abhängigkeiten bei Nichtschlüsselattributen

69 Datenbanksysteme69 Eliminierung partieller Abhängigkeiten

70 Datenbanksysteme70 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

71 Datenbanksysteme71 Eliminierung transitiver Abhängigkeiten

72 Datenbanksysteme72 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

73 Datenbanksysteme73 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‘

74 Datenbanksysteme74 Schemaeigenschaften


Herunterladen ppt "Datenbanksysteme1 Datenbanksysteme I Vorlesung SS 2006 Paul Manthey."

Ähnliche Präsentationen


Google-Anzeigen