Datenbanksysteme I Vorlesung SS 2006 Paul Manthey Datenbanksysteme

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

Inhalte von Datenbanken Eine fiktive Rechnung Datenbanksysteme

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

Beispiel: Daten in Tabellenform Datenbanksysteme

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

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

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

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

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

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

Codd‘sche Regeln Integration: einheitliche, nichtredundante Datenverwaltung Operationen: Speichern, Suchen, Ändern Katalog: Zugriffe auf Datenbankbeschreibungen im Data Dictionary Benutzersichten Integritätssicherung: Korrektheit des Datenbankinhalts Datenschutz: Ausschluss unauthorisierter Zugriffe Transaktionen: mehrere DB-Operationen als Funktionseinheit Synchronisation: parallele Transaktionen koordinieren Datensicherung: Wiederherstellung von Daten nach Systemfehlern Datenbanksysteme

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

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

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

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 Datenbanksysteme

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 Datenbanksysteme

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

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) Datenbanksysteme

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

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

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

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

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

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 ... statische Eigenschaften Objekte und Beziehungen inklusive der Standard-Datentypen, die Daten über die Beziehungen und Objekte darstellen können, dynamische Eigenschaften wie Operationen Beziehungen zwischen Operationen, Integritätsbedingungen an Objekte Datenbanksysteme

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 Datenbanksysteme

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

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 × 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 Datenbanksysteme

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

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. Datenbanksysteme

ER-Diagramme: Beispiel Konzeptionelles Schema einer Universität Datenbanksysteme

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

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. Datenbanksysteme

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

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

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

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

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

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

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

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

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 Datenbanksysteme

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

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

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

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

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

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

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 Datenbanksysteme

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

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

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

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) Datenbanksysteme

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

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

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

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

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

Übersicht über die Transformationen Datenbanksysteme

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

Beispiel: Prod_Herst-Relation mit Redundanzen Datenbanksysteme

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

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

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 Datenbanksysteme

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

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

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

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 Datenbanksysteme

Eliminierung partieller Abhängigkeiten Datenbanksysteme

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

Eliminierung transitiver Abhängigkeiten Datenbanksysteme

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

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

Schemaeigenschaften Datenbanksysteme