1.4k likes | 1.6k Views
Themen heute. Rückblick Erweiterung funktionale Beziehungen Relationenmodell Integritätsregeln Übersetzung ERM in Tabellenmodell Übung Grundlegende SQL-Kommandos. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002. Rückblick. E/R-Modell Entity, Entity-Typen, Attribute, Domänen
E N D
Themen heute • Rückblick • Erweiterung funktionale Beziehungen • Relationenmodell • Integritätsregeln • Übersetzung ERM in Tabellenmodell • Übung • Grundlegende SQL-Kommandos Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Rückblick • E/R-Modell • Entity, Entity-Typen, Attribute, Domänen • Relationship-Typ / Beziehungstyp • Funktionale Beziehungen(1:1, 1:n, n:1, n:m) • ISA-Relationship • total / partiell • disjunkt / nicht disjunkt • Schlüsselattribute • Schlüsselkandidat • Primärschlüssel • „Fremdschlüssel“ • Zusammengesetzter Schlüssel Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Attribut A Schlüssel-Attribut A A A Graphische Bausteine des ERM Entity-Typ E E Verbindung zwischen Entity-Typ E und Attribut A A kann undefiniert sein E A R E1 E2 Binäre Relationship zwischen den Entity-Typen E1 und E2 Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
besitzt hört leitet arbeitet-in Abteilungsleiter Angestellter Person Student Vorlesung Haus Abteilung Abteilung Funktionale Beziehungen/ Beispiele 1 1 N 1 1 N N M Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
ISA-Relationship total partiell t p Isa-Beziehung: p: partiell t: total nicht disjunkt disjunkt Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Anzahl PNr BNr KuNr m n 1 n Posten bestellt Produkt Bestellung Kunde n n n n liefert aus bearbeitet liefert beschreibt 1 1 Spediteur Mitarbeiter 1 1 SNr MNr Lieferant Kategorie KaNr LNr
Preis Anzahl BDatum PNr BNr KuNr n 1 n m Posten bestellt Produkt Bestellung Kunde m n n 1 n n n Anzahl LDATUM Preis offeriert LPreis liefert aus bearbeitet liefert OPosten beschreibt 1 n 1 Spediteur Mitarbeiter n Offerte 1 n 1 1 SNr MNr ONr bearbeitet Offerte Lieferant Kategorie KaNr LNr
Sinn der 3 Modellierungssprachen Relationale Modell (Algebra) • mathematische Fundierung, • Semantisch eindeutige Formulierung „Tabellenmodell“ • Implementierung / Realisierung E/R-Modell • Kommunikation, Dokumentation • Übersichtliche Darstellung Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Definition: Datenbankschema Unter einem Datenbankschema versteht man eine Spezifikation der Datenstrukturen einer Datenbank mit den zugehörigen Integritätsbedingungen. D.h.: ein Datenbankschema enthält die Definition der • Tabellen • Attribute • Primärschlüssel • Integritätsbedingungen (Einschränkungen der Wertebereiche der Attribute) Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Grundkonzepte des Relationenmodells • Wertebereich / Domäne Mögliche Werte eines Attributs, Beispiel „string“ • Relation Eine Relation R ist eine Teilmenge des kartesischen Produktes von Domänen Di (1 i n): R D1 x ... x Dn Relationen kann man auch als die Zeilen einer zweidimensionale Tabellen ansehen. • Tupel Tupel sind Elemente von Relationen. In Tabellen entsprechen sie den Zeilen. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Grundkonzepte des Relationenmodells • AttributSpalte einer Tabelle • AttributwertElement eines dem Attribut zugeordneten Wertebereichs • RelationenschemaEin Relationenschema besteht aus einem Relationennamen, gefolgt von der Liste ihrer Attribute und den zugeordneten Domänen: R(A1:D1,...,An:Dn) Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Grundkonzepte des Relationenmodells • Relationales DB-SchemaMenge aller Relationenschema in der Datenbank • Relationale DBDas relationale DB-Schema zusammen mit den momentanen Werten der Relationen Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Integritätsregeln Integritätsbedingungen sind Forderungen an die Zusammenhänge über die in der relationalen DBen enthaltenen Daten. Es gibt zwei verschiedene Typen von Integritätsbedingungen: • Strukturelle Regeln: Sie sind inhärent für das Datenmodell. • Verhaltensregeln: sie sind abhängig von der jeweiligen Anwendung. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Integritätsregeln Eindeutigkeit von Schlüsseln Relationen dürfen als Tupelmengen keine Duplikate enthalten. Eine noch schärfere Einschränkung wird durch den Begriff des Schlüsselkandidaten ermöglicht. Definition: Eine Menge S von Attributen einer Relation R heißt Schlüsselkandidat, wenn gilt: • Keine Instanz von R kann zwei verschiedene Tupel enthalten, die in S übereinstimmen. • Keine echte Teilmenge von S hat Eigenschaft 1. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Integritätsregel 1 - Primärschlüssel Primärschlüssel Jede Relation muß mindestens einen ausgewählten Schlüsselkandidaten besitzen, den sogenannten Primärschlüssel. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Definition: Fremdschlüssel Ein Fremdschlüssel einer Tabelle ist ein Attribut, oder eine Attributs-kombination, das (bzw. die) in einer anderen Tabelle als Primärschlüssel auftritt. Fremdschlüssel stellen die gewünschten Beziehungen zwischen Tabellen her. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Integritätsregel 2 - Fremdschlüssel Fremdschlüssel Der Primärschlüssel eines Relationenschemas R, das einen Relationship-Typ eines E/R-Diagramms modelliert, enthält Fremdschlüssel. Beispiel: In der Relation „liefert(LName,ArtName,Preis)“ ist „Lname“ ein Fremdschlüssel aus „LIEFERANT“, und „ArtName“ ein Fremdschlüssel aus „ARTIKEL“. Eine Relationship kann nur existieren, wenn die beteiligten Entities existieren. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Integritätsregel 2 – Referentielle Integrität Falls ein Relationenschema R einen Fremdschlüssel F = {A1,..., Al} des Relationenschemas S enthält, muß zu jedem Tupel t = (A1 = a1,..., Al = al, ...) aus R ein Tupel t' = (A1 = a1,..., Al = al, ...) in S existieren. Diese Integritätsregel bezeichnet man auch als referentielle Integrität. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Integritätsregel 2 – Referentielle Integrität Bemerkung: • Verletzungen der referentiellen Integrität können auftreten, wenn neue Tupel in R eingefügt oder existierende Tupel aus S gelöscht werden. • Fremdschlüssel sind meist Teil des Primärschlüssels. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Integritätsregel 3 – NULL-Werte Manchmal tritt der Fall auf, daß ein neues Tupel t in die Relation R eingefügt werden soll, ohne daß alle Attributwerte von t bekannt oder relevant sind. Für solche Situationen verwendet man den sogenannten NULL-Wert anstelle unbekannter oder irrelevanter Attributwerte. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Integritätsregel 3 – NULL-Werte Beispiel: Der neue Angestellte Robert Ford wird eingestellt; die Festsetzung seines Gehalts steht aber noch aus. ANGESTELLTER AngName Gehalt 'Robert Ford' NULL Außerdem soll die Zuordnung von Robert Ford zu einer ABTEILUNG erst später getroffen werden. Analog zum Eintrag in ANGESTELLTER ergibt sich daher: arbeitet_in AngName AbtName 'Robert Ford' NULL Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Integritätsregel 3 – NULL-Werte NULL-Werte können nicht auf allen Attributpositionen sinnvoll eingesetzt werden Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Integritätsregel 3 – NULL-Werte Kein Attributwert des Primärschlüssels einer Relation darf NULL sein. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Integritätsregel 3 – NULL-Werte Bemerkung • Dadurch soll die eindeutige Identifikation von Tupeln, die Entities oder Relationships beschreiben, gesichert sein. • Für Fremdschlüssel, die nicht Teil des Primärschlüssels sind, gilt Integritätsregel 3 nicht. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Integritätsregeln - alle Alle drei Integritätsregeln sind strukturelle Integritätsregeln für das relationale Modell. Sie sollten von einem relationalen DBMS automatisch überprüft werden!!! Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Übersetzung E/R-Modell in „Tabellen“-Modell (in Relationales Datenbankschema)
Datenmodellierung im Relationalen Modell • Bei der Erstellung des relationalen Schemadesigns wird folgende Vorgehens-weise nachdrücklich empfohlen: • Erstellung eines E/R-Diagramms. • Konvertierung des E/R-Diagramms in ein relationales DB-Schema. • Grund: Grössere Übersichtlichkeit und grössere semantische Ausdruckskraft des E/R-Modell gegenüber dem Relationen Modell. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Regel 1 Jeder Entity-Typ muss als eigenständige Tabelle mit eindeutigem Primärschlüssel definiert werden. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Konvertierung in Relationales Modell Konvertierungsregel 1: E/R-Modell Relationen Modell Ein Entity-Typ E mit Attributen A1,...,Ak aus den Domänen D1,...,Dk wird abgebildet auf ein k-stelliges Relationenschema E(A1:D1, ..., Ak:Dk). Falls dabei ein Relationship-Typ Eisa F vorliegt, kann man die Attributvererbung (z.B.) durch Hinzunahme aller Schlüsselattribute von F berücksichtigen. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Regel 2 Jede Relationship kann als eigenständige Tabelle definiert werden. Die Primärschlüssel der zugehörigen Entity-Typen treten als Fremd-schlüssel in dieser Tabelle auf. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Konvertierung in Relationales Modell Konvertierungsregel 2: E/R-Modell Relationen Modell Ein Relationship-Typ R zwischen den Entity-Typen E1, ..., En wird dargestellt durch ein Relationenschema R, dessen Attribute aus allen Schlüsselattributen der Ei bestehen. Gleiche Attribute werden dabei durch Umbenennung in R eindeutig gemacht. Falls R eigene Attribute besitzt, nimmt man diese hinzu. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Regel 2 Der Primärschlüssel der Relationship kann sich aus den Fremdschlüsseln zusammensetzen oder ein anderer Schlüsselkandidat sein, z.B. ein neuer künstlich eingeführter Schlüssel. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Beispiel: ERM Regel 1 und 2 Abteilung 1 1 A# Bezeichnung Abteilungs- Leiter Unter- stellung %-Anteil M# P# n Zugehörig- keit Mitarbeiter Projekt 1 m n Inhalt Name Ort Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Alternative Kennzeichnung von Schlüsseln A# := A Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Beispiel: Tabellen Regel 1 Abteilung Projekt Mitarbeiter A# Bezeichnung P# Inhalt M# Name Ort Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Beispiel: Tabellen Regel 2 Abteilungsleiter Unterstellung Zugehörigkeit A# M# M# A# M# P# %-Anteil Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Regel 2 (Beispiel) Da zu jeder Abteilung genau ein Abteilungsleiter gehört, genügt die Abteilungsnummer A# in der Tabelle ABTEILUNGSLEITER als Primärschlüssel. Analoges gilt für M# in der Tabelle UNTERSTELLUNG Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Regel 2 (Beispiel) In der Tabelle ZUGEHÖRIGKEIT müssen die Fremdschlüssel M# und P# zusammen als Primärschlüssel definiert werden. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Regel 3 (n:m-Beziehung) Jede n:m Beziehungsmenge muss als eigenständige Tabelle definiert werden. Die Primärschlüssel der zugehörigen Entity-Typen treten in der Relationship als Fremdschlüssel auf. Der Primärschlüssel der Relationship setzt sich aus den enthaltenen Fremdschlüsseln zusammen oder ist ein anderer Schlüsselkandidat. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Regel 4 (1:n - Relationship) Jede 1:n Relationship kann ohne zusätzlicheeigenständige Tabelle definiert werden. Dazu wird in einer der beiden Tabellen mit Assoziationstyp n ein Fremdschlüssel auf die damit verknüpfte Tabelle geführt. Die Fremdschlüsselbeziehung wird (i.B.) durch ein Attribut gegeben, das sich aus dem entliehenen Primärschlüssel und dem Entity-Namen „Unterstellung“ zusammensetzt. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Beispiel: Regel 4 (1:n) Unter- stellung Mitarbeiter Abteilung n 1 Mitarbeiter Abteilung M# Name Ort A# Bezeichnung A#_Unterstellung Fremdschlüssel-Beziehung Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Regel 5 (1:1- Relationship) Jede 1:1 Relationship kann ohne zusätzlicheeigenständige Tabelle definiert werden. Dazu wird in einer der beiden Tabellen mit Assoziationstyp 1 ein Fremdschlüssel auf die damit verknüpfte Tabelle geführt. Die Fremdschlüsselbeziehung wird (i.B.) durch ein Attribut gegeben, das sich aus dem entliehenen Primärschlüssel und dem Entity-Namen „ Abteilungsleiter“ zusammensetzt. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Beispiel: Regel 5 (1:1) Abteilungs- leiter Mitarbeiter Abteilung 1 1 Mitarbeiter Abteilung M# Name Ort A# Bezeichnung M#_Abteilungsleiter Fremdschlüssel-Beziehung Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Regel 6 Jeder Entitytyp einer Generalisationshierarchie verlangt eine eigenständige Tabelle, wobei der Primärschlüssel der übergeordneten Tabelle auch Primärschlüssel der untergeordneten Tabelle wird. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
Regel 6 Die Nicht-Disjunkt Eigenschaft erfordert keine spezielle Regelung. Die Disjunkt-Eigenschaft erfordert die Einführung eines Attributes „Kategorie“ in der übergeordneten Tabelle. Es enthält die Information zu welcher „Unterklasse“ das Objekt gehört. Bei einer disjunkten und totalen Generalisation muss garantiert werden, dass pro Eintrag in der übergeordneten Tabelle ein Eintrag in einer der Spezialisierungen existiert und umgekehrt. Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002
M# Regel 6 (Beispiel) Name Mitarbeiter Ort Kategorie t Stellung Lehrjahr Führungskraft Fachspezialist Lehrling Know how Mitarbeiter M# Name Ort Kategorie Führungskraft Fachspezialist Lehrling M# Stellung M# Know-how M# Lehrjahr Prof. Dr. Fabian Glasen, Datenbanken, Februar 2002