2 Datenbanksysteme. 2.1 Grundlegende Begriffe. Datenbank Management System. Schemata und Instanzen

Transkript

1 2 Datenbanksysteme Im Folgenden werden wir einige grundlegende Eigenschaften von Datenbanksystemen kennen lernen Datenbanken sind Bestandteil vieler Anwendungssysteme; sie stellen die dort benötigten Daten bereit Aufbau des Abschnitts Definition grundlegender Begriffe Datenmodelle Relationale Datenmodelle Entwurf einer Datenbank Business Computing and Operations Research Grundlegende Begriffe Eine Datenbank ist eine Ansammlung verwandter Fakten, die Bedeutung haben und gespeichert werden können; dies sind die Daten Die Daten sind zusammenhängend und haben anhaltend Bedeutung Die Daten werden angelegt, gepflegt und in einer speziellen Struktur gehalten Die Daten dienen bestimmten Anwendungen und besitzen so eine Gruppe von gezielten Benutzern Dies ist allerdings keine eindeutige Definition sondern lediglich eine charakterisierende Beschreibung von bestimmten Eigenschaften Business Computing and Operations Research 42 Schemata und Instanzen Unter einem Schema (oder auch Meta Daten) einer Datenbank versteht man die Beschreibung der Struktur der dort zu speichernden Daten Unter den Ausprägungen dieser Datenbank versteht man die konkreten Datenbestände, die in der Datenbank gespeichert sind Die konkreten Datenbestände werden auch Zustand einer Datenbank genannt Somit führen offensichtlich Veränderungen dieser Datenbestände zu neuen Zuständen der Datenbank Datenbank Management System Sammlung von Programmen, die es ermöglichen eine Datenbank zu erstellen und aufrecht zu erhalten DB Sprache für Operationen auf Datenbeständen Universell und anwendungsunabhängig Sichert Konsistenz der Daten Sichert Synchronisation Bietet standardisierte Schnittstelle Dabei wird unterstützt Definition der Datenbank Festlegung der Datenstrukturen und Bedingungen der Datenspeicherung Manipulation der Datenbank Auslesen und Veränderung der Datenbestände Konstruktion der Datenbank Abspeicherung der Datenbestände Allgemein dienliche und einsetzbare Software Sie ist nicht erforderlich, um eine Datenbank zu verwalten, sondern man kann auch eigen entwickelte Software benutzen Business Computing and Operations Research 43 Business Computing and Operations Research 44

2 Datenbank Die Datenbank besteht aus Datenausprägungen (den eigentlichen Daten) und Datenbeschreibungen (den Meta Daten, d.h. dem Datenbank Schema) Sie stellt den integrierten Datenbestand anhand eines einheitlichen Datenmodells geordnet dar Das heißt man unterscheidet Die Datenbank Definition und die dort gespeicherten eigentlichen Daten Datenbanksystem Besteht aus einem Datenbankmanagementsystem und der Datenbank Schematisch Datenbanksystem Benutzer / Programmierer Programme / Anfragen DBMS Verwaltet Programme und Anfragen und greift auf Daten zu Dazu unterscheidet man Software zur Anfragebearbeitung und zum eigentlichen Zugriff auf die Daten Datenbank Daten und Meta Daten Business Computing and Operations Research 45 Business Computing and Operations Research 46 Warum gibt es Datenbanksysteme? Für die Beantwortung dieser wichtigen zentralen Frage wollen wir im Folgenden einen kurzen Einblick in die Entwicklungsgeschichte von Datenbanksystemen erarbeiten Hieraus wird schnell deutlich, welche Vorteile Datenbanksysteme dem Nutzer bereitstellen und welche Nachteile vorangegangener Systeme zu ihrer Entwicklung geführt haben Entwicklungsgeschichte I Stufe 1: Elementare Dateien Datenhaltung um 1960 Anwendungen halten eigene Daten in Dateiform mit individueller Struktur Anwendungssysteme führen den Datenzugriff bis ins kleinste Detail selbst durch (Schwacher) Vorteil Schnelle Speziallösungen sind möglich Nachteile Inkonsistenz der Datenbestände kann durch unterschiedliche Dateien und ihrer Modifikation entstehen Redundanz Geräteabhängigkeit der Anwendungssysteme Extreme Expertenmacht kann entstehen Business Computing and Operations Research 47 Business Computing and Operations Research 48

3 Entwicklungsgeschichte II Stufe 2: Dateiverwaltungssysteme Datenhaltung um 1965 Anwendungen halten auch hier eigene Daten in Dateien mit individueller Struktur Anwendungssysteme führen den Datenzugriff einheitlich mit Hilfe bestehender Betriebssystemroutinen durch Erreichter Vorteil Geräteunabhängigkeit wird nun erreicht Nachteile Abhängigkeit von den Speicherstrukturen Betriebssystem liefert lediglich unspezifizierte Sätze zurück Genaue Formatierung der Sätze muss das Anwendungssystem, d.h. der Anwender/Programmierer übernehmen Inkonsistenz der Datenbestände kann durch unterschiedliche Dateien und ihrer Modifikation entstehen Redundanz Alle Update Operationen muss das Anwendungssystem in ihrem Funktionsumfang und zeitlichen Verhalten selbst individuell festlegen Bei Strukturanpassungen sind diese Operationen mit zu ändern Business Computing and Operations Research 49 Entwicklungsgeschichte III Stufe 3: Datenbanksysteme Datenhaltung ab 1975 Anwendungssysteme führen den Datenzugriff über Datenbanksysteme durch Dabei entsteht eine einheitliche Benutzungsschnittstelle zwischen Anwendung und dem Datenbankmanagementsystem Erreichter Vorteil Keine oder nur gewollte Redundanz Zentrale Kontrolle der Benutzung und Art der Veränderung Anwendung arbeitet Datenunabhängigkeit, d.h. es erfolgt kein direkter Zugriff mehr auf untere Schichten (direkt auf die Daten und ihre Strukturen) Nachteile Durch zentrale Datenhaltung rückt das Thema Datenschutz als neues Problem in den Mittelpunkt der Betrachtung Durch zentrale Datenhaltung sind spezielle Probleme bei erforderlichen Zugriffsgeschwindigkeiten zu berücksichtigen Business Computing and Operations Research 50 Leistungen von Datenbanksystemen Integration der Datenbestände Alle Daten werden zentral an einer Stelle einheitlich abgelegt und verwaltet Angebot an vordefinierten standardisierten Operationen zur Datenvisualisierung und -verarbeitung Beschreibung von Datenbeständen (Definition der Datenbestände sind ebenfalls veränderbar) Benutzersichten Jeder Benutzer kann eine eigene Sicht auf Daten erhalten D.h. er erhält als Mitglied einer Gruppe Zugriff auf bestimmte Teile der gesamten Datenbank Konsistenz und Integritätsüberwachung Korrekte Datenbank Inhalte und Veränderungen werden ermöglicht Keine Überprüfung durch Anwendungen notwendig Business Computing and Operations Research 51 Leistungen von Datenbanksystemen Datenschutz durch die Verwaltung von Zugriffsrechten Transaktionsmanagement Zusammenfassung von zusammengehörigen Aktionen zu einer unteilbaren Einheit Ermöglicht eindeutige Ergebnisse von Update Operationen Synchronisation Koordination von konkurrierenden Zugriffen D.h. Verwaltung gleichzeitiger Transaktionen mehrerer Benutzer auf die vorhandenen Datenbestände Datensicherung Laufende Datensicherung Wiederherstellung der Datenbestände nach Systemfehlern Unabhängigkeit zwischen Daten und Programmen (Bei OO Datenbanken zudem Programm und Methoden) Business Computing and Operations Research 52

4 2.1.2 Datenbankbenutzer Datenbank Administrator (DBA) Verantwortlich für Entwurf, Überwachung und Anpassung eines Datenbanksystems Damit ergeben sich die grundlegenden Aufgaben Definition der konzeptionellen / externen / internen Schemata (siehe unten) Datenschutz Leistungsüberwachung (ggf. Änderungen des internen Schemas) Überwachung der Anforderungen (ggf. Änderungen des externen Schemas) Betreuung/Verwaltung von Benutzern Datenbank Designer (DBD) Sammelt bei der Entwicklung der erforderlichen Schemata Informationen Unterstützt den Datenbank Administrator Datenbankbenutzer Fortsetzung System Analyst Analyse von Anforderungen der Anwendungsseite Bereitet Spezifikation für Anwendungsprogramme vor Anwendungsprogrammierer Entwickeln Anwendungsprogramme mit Datenbank Zugriffen Nutzt Spezifikation der System Analysten Hardware/Software Spezialisten Sorgen für lauffähige Gesamtsysteme Haben aber keine direkten Datenbankaufgaben End Benutzer Gehobene Datenbank Anfragen auf der Basis prozeduraler Sprachen Ggf. mit Sonderrechten Einfache Benutzer Tätigen meist Standardanfragen Nutzen ggf. als valide eingestufte Standardprogramme Business Computing and Operations Research 53 Business Computing and Operations Research Drei Schemata Architektur Gesamtaufbau Ziel: Strikte Trennung der Anforderungen und Anwendungen der Benutzer von der physikalischen Datenbank Endbenutzer Externes Level Benutzergruppe 1 Externe Sicht 1 Benutzergruppe n Externe Sicht n Daher finden sich Schemata auf insgesamt drei verschiedenen Ebenen Man unterscheidet Das interne Level (mit dem internen Schema) Das konzeptionelle Level (mit dem konzeptionellen Schema) Konzeptionelles Level Internes Level Bei Anfragen erfolgt durch das DBMS eine schrittweise Umsetzung in das jeweils tiefere Schema Konzeptionelles Schema Internes Schema Bei Antworten erfolgt durch das DBMS eine schrittweise Umsetzung in das jeweils höhere Schema Das externe Level (mit den externen Schemata (auch externe Sichten Views genannt)) Physische Hardwareebene Datenbank Business Computing and Operations Research 55 Business Computing and Operations Research 56

5 Datenunabhängigkeit Datenbank Sprachen Prinzip besteht darin, jeden Benutzer bei Veränderungen nur minimale Auswirkungen spüren zu lassen, d.h., Auswirkungen tieferer Ebenen, die ihn/sie im Prinzip auch betreffen würden, sollen nicht weitergegeben werden Wir unterscheiden im Folgenden Physische Datenunabhängigkeit Stabilität der konzeptionellen Ebene gegenüber Änderungen der Dateiorganisation oder der angewendeten Zugriffsverfahren D.h. eine Veränderung im internen Schema hat keine Auswirkungen auf die konzeptionelle Ebene Logische Datenunabhängigkeit Stabilität der Benutzungsschnittstelle gegenüber Veränderungen der Datenstrukturen auf der konzeptionellen Ebene D.h. eine Veränderung im konzeptionellen Schema hat keine Auswirkungen auf die externen Sichten Ausnahme können allerdings hier z.b. Löschungen sein Idealerweise werden aber diese fälschlichen Zugriffe ebenfalls abgefangen D.h. z.b. der Zugriff auf nicht mehr vorhandene Attribute wird nicht mehr durchgeführt und löst lediglich eine entsprechende Meldung aus DDL=Data Definition Language Konzeptionelles Schema wird hierdurch festgelegt Schnittstellen zum Internen Level SDL=Storage Definition Language Definiert internes Level VDL=View Definition Language Definiert externe Sichten für bestimmte Benutzergruppen Schnittstellen zum konzeptionellen Level DML=Data Manipulation Language Dient zur Formulierung von Benutzeranfragen Man unterscheidet Low level prozedural Diese Sprachen greifen nur einzeln auf Einträge in der Datenbank zu (record at a time) Müssen für aufwändigere Operationen in Hochsprachen eingebunden werden High level prozedural Können bereits komplexere Auswertungen (set at a time) (z.b. SQL) Brauchen nicht eingebunden zu werden Business Computing and Operations Research 57 Business Computing and Operations Research 58 Folgerung Datenbank Administratoren nutzen spezielle Arten von DDL SDL VDL End Benutzer nutzen spezielle Arten von DML Design Prozess der Datenbank Phase 1 Anforderungsanalyse Hieraus entstehen Anforderungen an die Daten und ihren Aufbau Anforderungen hinsichtlich der Zugriffe Phase 2 Entwicklung des konzeptionellen Designs mit Hilfe eines Meta Datenmodells Dieses ist DBMS unabhängig Zudem gilt, dass das konzeptionelle Design ungleich dem konzeptionellen Schema ist DBMS unabhängige Beschreibung der Zugriffe der Anwendungsprogramme Phase 3 Wahl des Datenbanksystems (DBMS+DB) D.h. Datenbanktyp (Relational, OO, ), Wahl der Query Language, Wahl der zusätzlichen Software Beachte: Alle bisherigen Schritte (1-3) waren DBMS unabhängig Business Computing and Operations Research 59 Business Computing and Operations Research 60

6 DBMS abhängige Phasen Phase 4 Entwicklung des logischen Designs Bestimmung des konzeptionellen und des externen Schemas Phase 5 Festlegung des physikalischen Designs Ermittlung des internen Schemas Phase 6 Implementierung des Systems SDL+VDL+DDL Statements für die Festlegung des konzeptionellen, des externen und des internen Schemas Für die Anwendungssysteme werden zur Ausgestaltung der Anfrageroutinen Hilfsprogramme in DML + Host Language implementiert Phase 7 Laufender Betrieb Überwachung & Anpassung Performancemessungen & Befragungen von Mitarbeitern Diese Schritte sind nun abhängig von einem gewählten Datenbanksystem 2.2 Datenmodelle Ein Datenmodell dient zur Beschreibung von Daten und ihrer Strukturen Sie bestimmen Die Syntax (d.h. den Aufbau) und Die Semantik (d.h. die Interpretation) von Datenbank Schemata Wir vereinbaren μ: Menge aller möglichen Objekte und Wertebereiche, die die im Schema angegebenen Objekte und Datentypen annehmen können Σ: Menge von passenden DB Zuständen (d.h. gültigen Ausprägungen) σ Σ ist ein passender DB Zustand Business Computing and Operations Research 61 Business Computing and Operations Research Ein Meta Modell: Das ER Modell Das ER heißt Entity Relationship Model Modellierungskonzepte Entitäten Das ER Modell geht von Entitäten aus, die die Basis des Modells darstellen Entitäten besitzen Eigenschaften (Attribute), die es beschreiben Attribute Eigenschaften die Entitäten beschreiben Eine einzelne Entität hat eine bestimmte Ausprägung für alle diese Attribute Man unterscheidet Einfache/zusammengesetzte Attribute Einwertige/mehrwertige Attribute Gespeicherte/ableitbare Attribute Business Computing and Operations Research 63 Objekttypen Ist ein Schema für Entitäten, d.h. es legt die Struktur von einer Gruppe von Entitäten fest D.h. die Entitäten haben dann eine bestimmte Struktur in Form von identischen Attributen (d.h. natürlich nicht, dass die Werte identisch sind) Für einen Objekttyp E gilt dann allgemein μ(e): Menge aller möglichen Objekte vom Typ E σ(e): Menge der aktuellen Objekte vom Typ E im Zustand σ (d.h. σ(e) μ(e)) Falls also e ein Objekt vom Typ E im Zustand σ ist, dann gilt e ist Element von σ(e) Ein Objekttyp E kann ein Schlüsselattribut besitzen, welches einen unterschiedlichen Wert für alle Entitäten vom Typ E besitzt und somit das einzelne Objekt eindeutig identifiziert Es können auch mehrere Schlüsselattribute sein Business Computing and Operations Research 64

7 Attributstypen Ein Attributstyp A ist eine Abbildung von einem dazugehörigen Entitätstyp E in einen dazugehörigen Datentyp D (bei mehrwertigen in die Potenzmenge von D) Beispiel: Entitätstyp: Angestellter Attributstyp: Name Abbildung für jede zugehörige Entität in den Datentyp D Wertebereich ist damit der Datentyp String Statt A 1 :E D 1,, A n :E D n schreiben wir einfach E(A 1,,A n ) Die Datentypen D 1,,D n sind dabei entweder Mengen Potenzmengen oder Kartesische Produkte von Mengen und/oder Potenzmengen n stelliger Beziehungstyp Ein n stelliger Beziehungstyp R von n Objekttypen E 1,,E n ist eine Relation über E 1,,E n Es gilt somit R( E 1,...,En) E1 E 2... En d.h. für einen konkreten Zustand σ σ R σ E σ E... σ E ( ) ( ) ( ) ( ) 1 2 Gibt es innerhalb eines Beziehungstyps Entitäten, die mehrfach vorkommen, nennt man diesen Beziehungstyp rekursiv Die Kardinalität eines Objekttyps innerhalb eines Beziehungstyps ist die Anzahl von Beziehungen dieses Beziehungstyps in der ein Objekt des betrachteten Objekttyps stehen kann Man unterscheidet 1: Kann nur in einer Beziehung dieses Typs stehen N: Kann in mehreren Beziehungen dieses Typs stehen n Business Computing and Operations Research 65 Business Computing and Operations Research 66 Beispiel Miniwelt: Schule Objekttyp 1: Schulklasse Objekttyp 2: Schüler Beziehungstyp B: Ist_in_Klasse Offensichtlich gilt Objekttyp 2 (Schüler) hat beim Beziehungstyp B die Kardinalität 1 Dies wird daraus deutlich, dass ein Schüler jeweils eindeutig einer Klasse zugeordnet ist Damit gilt, dass für den Beziehungstyp Ist_in_Klasse jedes Element des Objekttyps 2 in maximal einem Element des Beziehungstyps B steht Visualisierung ist in Schüler Klasse 1 N Name Adresse Bezeichnung Raum Ort Straße Business Computing and Operations Research 67 Business Computing and Operations Research 68

8 Darstellung der Kardinalität Die Kardinalität wird jeweils an den Linien zum Beziehungstyp direkt angegeben Dabei gibt es nur die Werte 1 oder N bzw. M 1 steht dafür, dass jedes einzelne Element nur in maximal einer Beziehung des Beziehungstyps auftauchen kann N bzw. M stehen dafür, dass jedes einzelne Element in beliebig vielen Beziehungen des Beziehungstyps auftauchen kann Die Kardinalität regelt also die Maximalzahl des Vorkommens eines Elementes in einem Beziehungstyp Allerdings ist darauf hinzuweisen, dass es unterschiedliche Konventionen der Darstellung in verschiedenen Lehrbüchern gibt. Es gibt also nicht die richtige oder falsche sondern es richtet sich nach der Zweckmäßigkeit Darstellung der Totalität Die Totalität definiert die Minimalzahl des Vorkommens eines Elementes in einem Beziehungstyp Deshalb steht eine totale 1 er Kardinalität für genau ein Vorkommen So im Beispiel: Es gibt keinen Schüler, der nicht in einer Klasse ist Streng genommen gibt es aber Klassen ohne Schüler Wenn man das ausschließen möchte, muss man die Darstellung wie folgt abändern: ist in Schüler 1 N Klasse Name Ort Adresse Straße Bezeichnung Raum Business Computing and Operations Research 69 Business Computing and Operations Research 70 Weitere Vereinbarungen Darstellungen Sei B Beziehungstyp über die Objekttypen E 1,,E n Dann heißt die Partizipation von E i in B total, falls alle Objekte vom Typ E i in B auftauchen, sonst partial Schwache Entitätstypen Sind Objekttypen ohne Schlüsselattribut Sie sind somit nicht identifizierbar Es existiert eine totale Partizipation dieses Objekttyps über einen anderen Entitätstyp Dieser andere Entitätstyp wird als Besitzer charakterisiert Zwei nicht unterscheidbare Objekte des schwachen Objekttyps können nicht dem gleichen Entitätstyp zugeordnet werden Hier gibt es eine 1:X Beziehung 1:N Entitätstyp Schwacher Entitätstyp Relationstyp Identifizierender Relationstyp Attribut Schlüsselattribut Mehrwertiges Attribut Zusammengesetztes Attribut Totalität Kardinalität Business Computing and Operations Research 71 Business Computing and Operations Research 72

9 Am Beispiel besitzt Person PKW N 1 Name Adresse Seriennummer Typ Leistung Ort Straße Das Relationale Modell Ist ein klassisches Datenmodell, das direkt in Datenbank Schemata eingegangen ist Besitzt eine sehr einfache Struktur Das Instrument der Relation stellt die Grundlage dieses Modells dar Eine Domäne ist eine Menge von atomaren Werten d.h. unteilbar in der Datenbankwelt Man definiert sie mit Datentypen und Formatierungsvorschriften Beispiel Telefonnummern in den USA (Staaten Code) Zulässige Durchwahl (ddd) ddd dddd, mit d (digit aus {0,1,2,3,4,5,6,7,8,9}) Business Computing and Operations Research 73 Business Computing and Operations Research 74 Relationales Schema Ein relationales Schema R, geschrieben als R(A 1,,A n ) (mit R Relationsname und den Attributen A 1,,A n ) beschreibt die Relation R Jedes Attribut A i besitzt eine Domäne dom(a i ), die den möglichen Wertebereich festlegt Damit kann der Fall eintreten, dass zwei Domänen identisch sind, d.h. es gilt dom(a i )=dom(a j ) Beispiel hierfür wären Telefonnummer Büro und Telefonnummer privat Eine Relation r als Instanz eines Relationsschema R(A 1,,A n ) (auch geschrieben als r(r)) ist eine Menge von n-tupeln Damit gilt ( ) = {( 1,..., n) { 1,..., }: i ( i) i = } r R t t i n t dom A t NULL ( ) ( )... ( )... ( ) r R dom A dom A dom A 1 i n Folgerungen Somit gilt für einen aktuellen Relationszustand σ ( R) μ( R) = dom( A1 )... dom( Ai)... dom( An) Offensichtlich beinhaltet σ nur zulässige n-tupel der Relation Im Gegensatz dazu umfasst μ alle theoretisch möglichen n- Tupel, die über den Domänen der betrachteten Relation gebildet werden können Offensichtlich gibt es für die einzelnen Tupel einer Relation keine Ordnung, d.h. die Reihenfolge ist per Definition unbestimmt Informationstechnisch ist das natürlich nicht der Fall, da die Daten immer in einer bestimmten Reihenfolge abgelegt sind Business Computing and Operations Research 75 Business Computing and Operations Research 76

10 Wichtige Eigenschaften Demgegenüber gibt es in jedem Tupel eine Ordnung der einzelnen Attribute, d.h. in jeder Instanz eine Ordnung der Werte Man könnte dies offensichtlich umgehen, indem man ein relationales Schema nicht als Tupel sondern als Menge von Attributen festlegt Wichtig In Relationen tauchen nur atomare (d.h. unteilbare) Werte auf Dies muss durch die jeweiligen Domänen gewährleistet werden Dies bedeutet insbesondere, dass es keine mehrwertigen oder zusammengesetzten Attribute in Relationen gibt Somit können wir nicht eine Attributsdomäne als eine Menge von Domänen definieren Das Relationale Modell gilt daher als flach Formale Schreibweisen Wir vereinbaren ( 1 n ) ( ) = 1. R A,..., A : Relationales Schema der Stelligkeit (des Grades) n 2. t r R, t v,..., v, v gehört zu Attribut A. Dabei lassen sich die 1 n i i [ ] einzelnen Komponenten durch t A ansprechen. Ein Sub-Tupel kann [ ] durch t A,..., A angesprochen werden v z i 3. QRS,, sind Relationennamen 4. qrs,, sind Zustände von Relationen 5. tuv,, sind Tupel von Relationen 6. Der Relationenname R alleine bezieht sich auf den aktuellen Zustand der ( A ) Relation während R A,..., das relationale Schema bezeichnet 1 n 7. Attribute (also ihre Domäne) sind ansprechbar über RA. i Business Computing and Operations Research 77 Business Computing and Operations Research 78 Regeln für das Relationale Modell Domänen Regel Domänen sind ausschließlich über atomare Typen zu definieren Siehe dazu die Regeln für SQL Datentypen Schlüssel Regel Eine Relation ist eine Menge von paarweise unterschiedlichen Tupeln Dazu gilt Zwei Tupel t1, t2 mit t1 = t1,1 t1, t2 = t2,1 t2, dom A1 dom A dom A heißen identisch i 1,..., n : t = t (,..., n), (,..., n) ( )... ( i)... ( n) { } 1, i 2, i Des weiteren gilt Nicht identische Tupel ( n) ( n) { k k } Falls gilt für t = t,..., t, t = t,..., t und S = A,..., A, { } { k,..., k }: 1, d 2, d 1 ( 1,1,..., 1, n) und 2 ( 2,1,..., 2, n) 1 1 1,1 1, 2 2,1 2, mit l n und j 1,..., l : k n: d S = A A t t t = t t t = t t sind nicht identisch l Man schreibt in diesem Fall kurz: t S t S j [ ] [ ] l Business Computing and Operations Research 79 Business Computing and Operations Research 80

11 Superschlüssel (Super Key) Eine Menge von Attributen S heißt für ein relationales Schema R(A 1,,A n ) Superschlüssel oder Super Key, genau dann wenn S Teilmenge von {A 1,,A n } ist und es gilt zudem (,..., n) : (,..., n) : [ ] [ ] t = t t R t = t t R t S t S 1 1,1 1, 2 2,1 2, 1 2 Ein Schlüssel S eines relationalen Schemas R(A 1,,A n ) ist ein Superschlüssel mit der folgenden zusätzlichen Eigenschaft ( Super Key) { k k } { } { k } Falls S = A,..., A : c 1,..., l : S / A ist kein Superschlüssel 1 l c Konsequenz Jedes relationale Schema R(A 1,,A n ) hat einen Superschlüssel und einen Schlüssel Dies ist im Extremfall die gesamte Menge der vorhandenen Attribute {A 1,,A n } Jeder Schlüssel ist ein Kandidat als Identifikator (Identifier) eingesetzt zu werden Der gewählte Primärschlüssel ist im relationalen Schema zu unterstreichen und somit als solcher kenntlich zu machen Business Computing and Operations Research 81 Business Computing and Operations Research 82 Integritätsregeln Entitätsintegrität Hier wird gefordert, dass niemals in einer Relation ein Tupel existiert, das den Wert NULL in dem Attribut hat, welches den Primärschlüssel darstellt Nur so bleibt die Primärschlüsseleigenschaft erhalten Schlüsselintegrität Alle Tupel sind unterschiedlich bezüglich eines angegebenen Schlüssels Referentielle Integrität Wir betrachten zwei Relationen R 1 und R 2 Es sei FK eine Attributsmenge der Relation R 1 und PK sei der Primärschlüssel von R 2 Für alle diese Fälle verlangt die referentielle Integrität, dass gilt (,..., n) : (,..., n) : [ ] [ ] [ ] t = t t R t = t t R 1 1,1 1, 1 2 2,1 2, 2 t FK = t PK t FK = NULL Interpretation Was bedeutet somit referentielle Integrität? Man stellt über eine Menge von Attributen in einer Relation eine Verbindung zu einer anderen Relation her Dies geschieht durch einen Primärschlüssel PK, der eindeutig jedes Tupel in der anderen Relation identifiziert Somit muss ein Verweis auf diese zusätzlichen Stammdaten möglich sein Dies gelingt allerdings nur über die referentielle Integritätsbedingung FK wird daher auch als Fremdschlüssel (Foreign Key) in der Relation R 1 bezeichnet Ein Fremdschlüssel ist somit eine Menge von Attributen in einer Relation, die zusammen einen Primärschlüssel einer anderen Relation definieren Business Computing and Operations Research 83 Business Computing and Operations Research 84

12 Relation 1 (Schulklasse) Bezeichnung (Teil des PK) Beispiel Schulklasse Relation 2 (Einwohner der Stadt XX) Name Vorname Geburtsdatum 10a 4711 Rech Kurt a 4711 Kranich Helga Einwohner der Stadt XX Name (PK) Vorname (PK) Geburtsdatum (PK) Adresse Rech Kurt Willistraße 12 Kranich Helga Auf der Howe 23 Beachte Diese Integritätsbedingungen werden direkt im Datenbankschema festgehalten Auf diese Weise wird das System ihre Einhaltung in allen Instanzen sicherstellen Dies wird innerhalb der DDL festgelegt Zudem kann es auch semantische Integritätsbedingungen geben z.b. Gehälter von Auszubildenden sind immer geringer als von Ausgelernten Business Computing and Operations Research 85 Business Computing and Operations Research 86 Konsequenz für Updates Die Operation Insert kann verletzen Schlüsselintegrität Bereichsintegrität Referenzielle Integrität Die Operation Delete kann verletzen Referenzielle Integrität Die Operation Modify kann verletzen Schlüsselintegrität Bereichsintegrität Referenzielle Integrität Das System muss auf auftretende Verletzungen reagieren. Zum Beispiel durch Zurückweisen mit Erklärungen Anpassungsvorschlägen ohne deren Annahme die Transaktion nicht zu Ende durchgeführt wird Damit bestimmt die DDL Die Relationen der Datenbank Deren Namen und Attribute Die Domänen der Attribute und deren Datentypen Die Schlüssel, d.h. Die Primärschlüssel Die Fremdschlüssel Business Computing and Operations Research 87 Business Computing and Operations Research 88

13 Konvertierungen in das relationale Modell Meist liegt zunächst ein Datenbankentwurf in einem leistungsfähigen Meta Modell vor Dies kann zum Beispiel ein ER Modell oder ein EER Modell sein Offensichtlich entspricht dies noch nicht den Standards, die in einem relationalen Modell gelten müssen Daher muss falls eine relationale Datenbank zum Einsatz kommen soll eine betrachtete Instanz dieses Modells noch in ein relationales Schema umgesetzt werden Wir betrachten zunächst den Konvertierungsprozess vom ER Modell in das relationale Modell Business Computing and Operations Research 89 Vom ER Modell zum Relationalen Modell Schritt 1 Für jeden echten (d.h. nicht schwachen) Entitätstypen wird eine eigene Relation konstruiert Dabei werden die einfachen eindeutigen Attribute (auch die der zusammengesetzten eindeutigen Attribute) eingetragen Schritt 2 Für jeden schwachen Entitätstypen W mit besitzendem Entitätstyp E bilde Relation R mit allen einfachen eindeutigen Attributen von W und dem Schlüssel von E Schritt 3 Für jede 1:1 Beziehung, nehme falls vorhanden die totale Seite und füge die andere als Sekundärschlüssel in deren Relation ein Falls keine totale Seite vorhanden, nehme eine beliebige von beiden und füge die andere als Sekundärschlüssel in die Relation ein Business Computing and Operations Research 90 Vom ER Modell zum Relationalen Modell Am obigen Beispiel Schritt 4 Für jede 1:N Beziehung, nehme die nicht eindeutige Seite (N:) mit dem Primärschlüssel und trage diesen als Sekundärschlüssel in die andere Relation ein Schritt 5 Für jede M:N Beziehung bilde eine neue Relation R Bilde einen neuen Primärschlüssel aus den beiden Primärschlüsseln Dasselbe geschieht auch für alle Beziehungstypen mit mehr als zwei beteiligten Entitätstypen Schritt 6 Sei A ein mehrwertiges Attribut von Entitätstyp E Dann bilde eine neue Relation mit dem Primärschlüssel von E als Fremdschlüssel und den einfachen Attributen Hieraus entsteht ein neuer Primärschlüssel besitzt Person PKW N 1 Name Adresse Seriennummer Typ Leistung Ort Straße Business Computing and Operations Research 91 Business Computing and Operations Research 92

14 Transformation ins relationale Modell Wir legen für beide Entitätstypen eine neue Relation mit allen einfachen Attributen an Trage für die 1:N Beziehung bei PKW den PK von Person als FK ein Person Name Ort Straße PKW Seriennummer Typ Leistung Besitzer Name (FK) Business Computing and Operations Research 93