Relationale Datenbanksysteme

Transkript

1 MultiAugustinum E2A/E3A SQL Relationale Datenbanksysteme Mag. Christian Gürtler 2011

2

3 Inhaltsverzeichnis I. Allgemeines 5 1. Vergleich Datenbankysteme Dateisystem 7 2. Architektur eines DBMS Konkrete Architekturen Arten von Datenbanksystemen Hierarchische Datenbanksysteme Netzwerkmodell Objektorientierte Datenbanksysteme Relationale Datenbanksysteme II. Datenbankdesign Entity-Relationship-Modell Modelle Grundlagen des Entity-Relationship-Modells (ER-Modell) Eigenschaften von Beziehungen Eigenschaften von Eigenschaften Stelligkeit Kardinalität Konnektivität Stärke der Beziehung Optionalität Abhängige Entity-Typen, IST-Beziehung Redundante Beziehungen Beispiel eines ER-Modells

4

5 Teil I. Allgemeines 5

6

7 1 Vergleich Datenbankysteme Dateisystem Bis in die 1960er-Jahre wurden die Daten in einem Dateisystem gespeichert, im schlimmsten Fall verwaltet jedes Anwendungsprogramm seine eigenen Daten und mitunter auch noch in eigenen Dateiformaten (Excel als xls, Access als mdb usw.) Die Buchhaltung speichert Daten über Artikel und Adressen. Die Auftragsverwaltung bearbeitet Daten über Aufträge, Adressen und Kunden Die Kundenbetreuung bearbeitet Daten der Kunden (Adressen,...) Anwendung 1 Anwendung 2 Datei 1 Datei 2 Datei 3 Problem der Datenredundanz Abbildung 1.1.: Zugriff auf Dateien In diesem Szenario sind die Daten mehrfach (redundant) gespeichert, in der Folge kommt es einerseits zu unnötig belegtem Speicherplatz und andererseits (was noch gravierender ist) zu Dateninkonsistenzen: ändert die Kundenbetreuung die Daten eines Kunden zum Beispiel von Herrn Müller, dann müssen auch die Buchhaltung und die Auftragsverwaltung ihre Daten ändern. Geschieht dies nicht, so haben alle Abteilungen unterschiedliche Datensätze, also inkonsistente Daten. Der Müller aus der Kundenbetreuung ist nicht mehr der Kunde Müller aus der Auftragsverwaltung. 7

8 1. Vergleich Datenbankysteme Dateisystem Weitere Problemfelder Um diese Daten zu verwalten, werden in den Betrieben oft zusätzlich spezielle Anwendungsprogramme entwickelt. Die Entwickler solcher Programme müssen jedoch wissen, wie die Daten intern gespeichert werden (um die Daten in einem speziellen Format zu speichern). Dieser Punkt wird als fehlende Datenunabhängigkeit bezeichnet. Ein weiterer Punkt der Speicherung von Daten in einem Dateisystem betrifft fehlende Zugriffskontrolle und Datensicherheit. Meist können in einem Dateisystem die Rechte nur bis auf Dateiebene vergeben werden, nicht jedoch auf einzelne Inhalte einer Datei. Zusätzlich existieren kaum Möglichkeiten, Dateien so zu sperren, dass sich mehrere Benutzer beim Bearbeiten nicht gegenseitig behindern bzw. Daten gegenseitig überschreiben (was zu Datenverlust führen kann). Ende der 1960er-Jahre wurden Dateiverwaltungssysteme eingeführt. Zwischen Datei und Anwendung liegt eine Dateiverwaltungsschicht (z. B ISAM Indexed Sequential Access Method). Anwendung 1 Anwendung 2 Dateiverwaltungssystem I Dateiverwaltungssystem II Datei 1 Datei 2 Datei 3 Abbildung 1.2.: Zugriff auf Dateien Mit der Verwendung von (I)SAM wurde Geräteunabhängigkeit erreicht, die Daten waren aber immer noch redundant gespeichert. Die Lösung dieser Probleme wurden in den 1970er-Jahren durch den Einsatz von Datenbanksystemen erreicht, hier ist insbesonders das von Codd entwickelte Relationenmodell zu nennen. Die Daten sind in einer Datenbank gespeichert, wo die Daten physisch liegen wird vom Datenbankmanagementsystem (DBMS) verwaltet, die Anwender und Programmiererer brauchen sich in der Regel nicht darum zu kümmern. Der Zugriff erfolgt sozusagen gefiltert (abstrahiert) durch das DBMS. 8

9 Anwendung 1 Anwendung 2 DBMS Datenbank Abbildung 1.3.: Zugriff auf Datenbank Zusammengefasst: Datenbanksysteme zeichnen sich durch folgende Prinzipien aus: Die Daten werden zentral und nicht-redundant gespeichert. Mehrere Benutzer können gleichzeitig (parallel) auf die Daten zugreifen. Transaktionen verhindern unerwünschte Nebeneffekte. Konkurrierende Transaktionen müssen synchronisiert werden (greifen mehrere Transaktionen auf einen Datensatz zu, so müssen sie aufeinander abgestimmt werden). 1 Datenunabhängigkeit gewährleistet die Unabhängigkeit der Programme von den Daten und umgekehrt. Wie die Daten organisiert bzw. gespeichert werden spielt für ein Programm keine Rolle; ein bestimmtes Programm oder eine Applikation darf wiederum die Organisation der Daten nicht beeinflussen. Datenbanksysteme gewährleisten feiner abgestimmte Zugriffskontrollen und Rechte. Sichten (eingeschränkte Sicht auf die Daten) und Rechte auf einzelne Datensätze (Zeilen) sind möglich (views). Ein Datenbanksystem bietet Operationen zum Suchen, ändern und Anlegen von Datensätzen. Dazu sind deskriptive Sprachen vorhanden. Ein Katalog, auch Data Dictionary genannt, ermöglicht Zugriffe auf die Beschreibungen (Metadaten) der Daten und Datenbanken (um zum Beispiel zu erfahren, wer einen bestimmten Datensatz angelegt oder geändert hat, oder welche Tabellen eine bestimmte Datenbank besitzt). Das Datenbanksystem gewährleistet die Datenintegrität (Konsistenz). Datensicherung muss die Wiederherstellung von Daten nach Fehlern gewährleisten. 1 Unter einer Transaktion versteht man eine Zusammenfassung von Datenbankprozessen, die als gesamtes (atomar) ausgeführt werden. Nach einer Transaktion befindet sich die Datenbank in einem konsistenten (consistent) Zustand. Mehrere Transaktionen laufen isoliert voneinander ab. Bei Erfolg sind die Daten dauerhaft speichert ACID. 9

10 1. Vergleich Datenbankysteme Dateisystem Im Zusammenhang mit Datenbanken sind verschiedene Begriffe üblich. Folgende Tabelle erläutert die Unterschiede: Kürzel Begriff Erläuterung DB Datenbank Datenbestand DBMS Datenbankmanagementsystem verwaltet Datenbestand DBS Datenbanksystem DB + DBMS Tabelle 1.1.: Begriffe 10

11 2 Architektur eines DBMS Es werden drei Ebenen unterschieden, die den Zugriff auf die Daten gewährleisten: die externe Ebene beschreibt, wie Anwendungen (Masken, Einbettung in Programmiersprachen wie PHP), die Daten sehen. Da dies je nach Anwendung unterschiedlich ist, existiert eine konzeptuelle Ebene, die eine logische Sicht auf die Daten bietet. Eine Stufe tiefer existiert eine interne Ebene, die sich um die physische Speicherung auf Platten- bzw. Betriebssystemebene kümmert. Dieses Schema gewährleistet einen wichtigen Punkt, nämlich den der Datenunabhängigkeit mit ihren zwei Teilaspekten (Implementierungsunabhängigkeit, physische Datenunabhängigkeit wie die Daten gespeichert werden, ist für die Sicht auf die Daten egal und Anwendungsunabhängigkeit, logische Unabhängigkeit Änderungen auf eine Anwendung dürfen sich nicht auf die Daten auswirken). Modell für die konzeptuelle Ebene: Relationenmodell Die Grundlage des Relationenmodells liefert die Relation. Eine Tabelle wird durch ein sog. Relationenschema beschrieben. Dieses Schema gibt an, aus wievielen Spalten die Tabelle besteht und wie die Spalten benannt sind. Die Einträge in der Tabelle werden als Relation zu diesem Schema bezeichnet. Ein Tupel bezeichnet eine Zeile in einer Tabelle. Die Spaltenüberschriften werden als Attribute bezeichnet. Relationenname Attribute Tupel Weine Name Farbe Jahrgang Weingut La Rose Grand Cru Rot 1998 Creek Zinfandel Rot 2003 Helena Chardonnay Weiß 1999 Müller Relationenname Relation Tabelle 2.1: Begriffsbildung 11

12 2. Architektur eines DBMS 2.1. Konkrete Architekturen Die relationalen DBMS sind die Systeme, die den Markt dominieren. Vertreter sind IBM (DB2, Informix), Oracle(Oracle 11g), Microsoft (SQL Server), PostgreSQL, SUN (MySQL). Die beiden letztgenannten sind Open-Source-Systeme. Gemeinsame Merkmale sind die Drei-Ebenen-Architektur einheitliche Sprache (SQL) Einbettung in Programmiersprachen wie C/C ++, PHP, Java kontrollierter Mehrbenutzerbetrieb, Zugriffskontrolle Mit Ausnahme von SQL Server (läuft nur auf Microsoft-Servern) gibt es für die oben genannten Datenbanksysteme Versionen für die gängigsten Betriebssysteme(Windows, UNIX, Linux). Aus der Sicht einer Anwendung ist ein DBMS ein Client-Server-System. Der Client läuft meist auf einem PC (Mysql-Query-Browser, PHPMyAdmin,...), der eine Anfrage an den Server stellt. Dieser nimmt die Anfrage auf, führt eine Bearbeitung durch und gibt die Ergebnisse dem Client zurück. Client Server 1 Anfrage 3 Antwort Bearbeitung 2 Abbildung 2.1.: Client-Server-System Oft sind diese Systeme reine sog. Zwei-Schichtensysteme(reine Client-Server-Systeme), wo sowohl Benutzerschnittstelle als auch die Anwendungslogik im Client integriert sind. Bei manchen Systemen gibt es allerdings drei Schichten, wie beispielsweise Apache/PHP-MySQL-PostgreSQL. Streng genommen kann der Apache mit PHP und der entsprechenden Schnittstelle zur Datenbank als eigener Applikationsserver betrachtet werden. Solche Drei-Schichtensysteme gibt es auch bei Oracle, IBM (WebSphere), RedHat (JBoss), Java Beans... Bei diesen Beispielen ist es oft problematisch, wenn ein Datenbanksystem durch ein anderes ersetzt werden soll (beispielsweise MySQL durch Oracle). Dann müssen in 12

13 2.1. Konkrete Architekturen sämtlichen Anwendungsprogrammen die Schnittstellen geändert werden (Risiko, Zeitaufwand). Um diese Probleme zu umgehen, wurden sog. Middleware-Lösungen wie CORBA oder ODBC entwickelt. Diese zusätzliche Schicht enthält nur die Information (Treiber) über die darunterliegende Datenbank, das Anwendungsprogramm braucht sich darum nicht zu kümmern. änderungen sind daher nur einmal notwendig und nicht in allen Programmen. (a) Zwei-Schichten-System (b) Drei-Schichten-System Benutzerschnittstelle Anwendungslogik DB-Schnittstelle Benutzerschnittstelle Anwendungslogik DB-Schnittstelle Datenbank Datenbank Abbildung 2.2.: Anwendungsarchitekturen 13

14

15 3 Arten von Datenbanksystemen 3.1. Hierarchische Datenbanksysteme In den 1960er-Jahren wurde das sogenannte hierarchische Datenbankmodell entwickelt. Die Daten werden in einer Baumstruktur mit einem Root-Knoten, ästen (vertikal) und Blättern (horizontal) gespeichert. Firma Vorstand Produktion Vertrieb Müller Huber Dorfer Meier Hauser Berger Abbildung 3.1.: Hierarchisches Modell In diesem Modell sind nur 1 : 1 und 1 : N-Beziehungen darstellbar, M : N- Beziehungen sind nur mit zusätzlichem Aufwand (virtuelle Zeiger) darstellbar. Ein ähnliches System existiert in LDAP, einem modernen plattformübergreifenden Userverwaltungssystem Netzwerkmodell In diesem System, das auch als CODASYL-System, bekannt ist, sind auch M : N- Beziehungen darstellbar, allerdings fehlt hier der wesentliche Punkt der Datenunabhängigkeit; als Programmiersprache ist weitgehend COBOL und keine eigene Abfragesprache wie SQL im Einsatz. Diese Datenbanken werden hauptsächlich noch auf 15

16 3. Arten von Datenbanksystemen Großsrechnern eingesetzt. Der Datenbestand besteht hier aus netzwerkartig verketteten Datensätzen (Records) Objektorientierte Datenbanksysteme Diese Systeme entstanden bereits in den 1980er-Jahren und wollen prinzipiell die objektorientierte Ausrichtung von Programmiersprachen wie C ++, Smalltalk oder Java auf Datenbanken abbilden. Erst 1993 bildete sich so etwas wie ein gemeinsamer Standard (Kompromiss) Relationale Datenbanksysteme Im folgenden wird hauptsächlich dieses Modell mit Tabellen, Entities, Relationen etc. besprochen. 16

17 Teil II. Datenbankdesign 17

18

19 4 Entity-Relationship-Modell 4.1. Modelle Modelle dienen zum Erfassen der Daten und nicht der daraus gewonnen Informationen. Daten sind zum Beispiel Schüler mit ihrem Namen, Geburtsdatum und Noten, Informationen werden daraus gewonnen (Notendurchschnitt, Alter). Um ein Modell zu entwickeln, sind Informationen über 1. statische Eigenschaften von Objekten und Beziehungen, 2. dynamische Eigenschaften wie Operationen und Beziehungen zwischen Operationen, 3. Integritätsbedingungen von Objekten und Operationen zu sammeln. Objekte sind zum Beispiel Artikel mit statischen Eigenschaften Bezeichnung, Preis etc. Beziehungen wären beispielsweise: 1 Erzeugern produziert einen Artikel, oder Schüler x geht in die Klasse y. Dynamische Eigenschaften (Operationen) wären die Berechnung des Endpreises mit Skonto. Eine Beziehung zwischen Operationen könnte sein, dass ein Artikel erst dann bestellt werden darf, wenn er produziert wurde, oder ein Schüler erst dann in den Aufbaulehrgang kommen darf, wenn er eine Fachschule absolviert hat. Integritätsbedingungen legen zum Beispiel fest, dass ein Artikel eine eindeutige Nummer aufweisen muss (Schlüsselbedingung) und dass es zu jedem Artikel einen Erzeuger geben muss (referentielle Integrität). Im Relationenmodell sind sie Daten in ungeschachtelten Tabellen gespeichert (SQL- Datenbanken), die Beziehungen werden durch Wertevergleich ausgedrückt. Eine Erweiterung dieses Modells ist das Modell der geschachtelteten oder Non-First-Normal-Form (NF 2 ), in der Attribute Relationen als Werte haben dürfen, sonst dürfen nur einfache Strings (keine Arrays,...) gespeichert werden. Als Vorstufe des Relationenmodells wird das Entity-Relationship-Modell angesehen, das eine abstrakte Sicht auf die Daten liefert und für einen Entwurf einer Datenbank unerläßlich ist. Hier werden die Daten mit ihren Attributen und Beziehungen grafisch dargestellt. 19

20 4. Entity-Relationship-Modell 4.2. Grundlagen des Entity-Relationship-Modells (ER-Modell) Das ER-Modell geht zurück auf eine Arbeit von P. P. Chen im Jahre 1976 und ist heute faktisch Standard bei der Datenbankentwicklung. Zum ER-Modell gehört eine grafische Notation (ER-Diagramm oder ERD, die die Datenbank mit ihren Daten und Beziehungen abstrakt darstellt. Das ER-Modell spiegelt nicht die konkreten Werte wider, sondern zeigt nur die typmäßige Struktur. Zum ER-Modell gehören drei Begriffe: 1. Entity: ein Objekt aus der reellen Welt (Artikel, Kunden, Lieferanten,...). Wichtig ist dabei festzustellen, welche Objekttypen (Entitytypen) vorhanden sind. Ein Objekttyp ist vergleichbar mit einem Karteikasten (Kundenkartei), in dem für jedes einzelne Objekt( Kunde) eine Karteikarte angelegt wird. Der Objekttyp ist sozusagen die Abstraktion. 2. Relationship: gibt die Beziehung zwischen den Entities wider (Lieferant produziert Artikel, Kunde kauft Artikel,...) 3. Attribut: entspricht einer Eigenschaft von Entities oder auch Beziehungen (Farbe eines Weines, Bezeichnung eines Artikels, Name von Kunden,...). Um diese Attribute speichern zu können, sind entsprechende Datentypen notwendig (integer für ganze Zahlen, date für Datumswerte, char für Strings,...) Entity-Typen Entities sind Einheiten, in denen Objekte mit der gleichen Art von Eigenschaften gespeichert werden. Die einzelnen Zeilen (Tupel) werden nicht als eigene Einheit gespeichert, sondern werden beispielsweise alle Artikel, die eine Nummer, eine Bezeichnung und einen Preis aufweisen in einem Entity-Typ Artikel gespeichert. In der grafischen Notation werden diese Entity-Typen als Rechteck (bei Oracle mit gerundeten Ecken) dargestellt und der Name des Typs im Rechteck eingetragen. (a) klassische Darstellung (b) Darstellung Oracle Artikel Artikel Abbildung 4.1.: Grafische Darstellung eines Entity-Typs Beziehungstypen Beziehungen zwischen Entities werden nicht für jede Ausprägung modelliert, sondern zu Beziehungstypen zusammengefasst, also nicht, dass Artikel Feinkristallzucker von 20

21 4.2. Grundlagen des Entity-Relationship-Modells (ER-Modell) der Firma Agrana stammt, sondern dass ein Artikel von einem Produzenten erzeugt wird. Beziehungstypen werden als Raute dargestellt. Die Beziehungen können Zweistellig (binär) oder n-stellig sein: (a) binärer Beziehungstyp Artikel produziert Produzent Kritiker empfiehlt Wein Speise (b) n-stelliger Beziehungstyp Abbildung 4.2.: Grafische Darstellung von Beziehungstypen Attribute modellieren Eigenschaften von Entities oder Beziehungen, alle Entities eines Typs haben die selben Arten von Eigenschaften. Attribute werden als Oval dargestellt und einem Entity-Typ zugeordnet. Wie genau die Attribute zergliedert werden, hängt von den Anforderungen ab. Zum Beispiel kann eine Adresse wie 5581 St. Margarethen Schulgasse 60 als kompletter Satz gespeichert werden soll später aber nach Postleitzahlen oder Orten gesucht werden, empfiehlt sich eine Auftrennung in ein Attribut Postleitzahl, ein Attribut Straße und ein Attribut Ort. Eigenschaften (Attribute) können identifizierend sein (zum Beispiel eine Buchnummer oder Personalnummer) oder beschreibend. Hat ein Objekttyp kein identifizierendes Attribut, so spricht man von einem schwachen Objettyp Preis Nummer Artikel Bezeichnung Abbildung 4.3.: Attributnotation eines Entity-Typs Neben Entities können auch Beziehungen Attribute aufweisen. 21

22 4. Entity-Relationship-Modell Anteil Wein hergestellt aus Rebsorte Abbildung 4.4.: Attributnotation für Beziehungen In dieser Abbildung ist die Beziehung zweier Tabellen (Entities) dargestellt, das Attribut Anteil ist weder der Entity Wein noch der Entity Rebsorte zugeordnet. Beziehungen können auch rekursiv sein, zum Beispiel kann in einem Objekttyp Person ein Objekt mit einem anderen in Beziehung stehen, wenn Herr Meier der Vorgesetzte von Frau Müller ist. Person PersonalNummer Name Identifizierung durch Schlüssel Abbildung 4.5.: rekursive Beziehung Für jede Entity gibt es den Effekt, dass einige Attribute mit ihren Werten für eine eindeutige Identifizierung der Entity sorgen. Ein Wein kann zum Beispiel durch die Kombination aus Namen, Jahrgang und Weingut identifiziert werden, ein Mitarbeiter in einer Firma durch seine Sozialversicherungsnummer oder ein Buch durch seine ISBN- Nummer. Diese Attribute werden Schlüsselattribute genannt. Oft tritt der Fall ein, dass es mehrere Kandidaten gibt ein Wein kann durch die Kombination aus Namen, Jahrgang und Weingut, aber auch durch ein künstliches Merkmal (interne Nummer) eindeutig gekennzeichnet werden. Aus diesen Kandidaten wird einer gewählt, dieser wird dann der sog. Primärschlüssel. Für eine eindeutige Identifizierung gibt es drei Möglichkeiten eine einzige Eigenschaft: unikales Attribut; Beispiele wären Sozialversicherungsnummer, ISBN-Nummer. Diese Attribute werden auch natürliche Schlüssel genannt. 22

23 4.3. Eigenschaften von Beziehungen Kombination von Eigenschaften: hier müssen so wenige Merkmale wie möglich herangezogen werden. Zum Beispiel kann ein Wein durch die Kombination aus Namen, Jahrgang, Weingut identifiziert. Name, Jahrgang wäre wahrscheinlich zu wenig, Name, Jahrgang, Weingut, Restzucker wäre zu viel. künstliche Schlüssel: wenn ein natürlicher Schlüssel nicht vorhanden ist oder eine Kombination zu umständlich ist, werden künstliche Attribute eingeführt. Ein Beispiel wäre in einer Firma die Personalnummer oder in einem Laden die Artikelnummer. Künstliche Schlüssel werden sehr oft eingesetzt, da sie meistens kürzer sind (Vergleich Personalnummer mit Sozialversicherungsnummer) und daher weniger fehleranfällig (gegen vertippen etc.) sind Eigenschaften von Beziehungen Beziehungen gehen immer in zwei Richtungen zum Beispiel: Lehrer unterrichtet Schüler; Schüler wird von Lehrer unterrichtet; wobei die Fragestellung immer von 1 ausgehen muss: 1 Lehrer unterrichtet wie viele Schüler, 1 Schüler wird von wie vielen Lehrern unterrichtet. Falsch wäre: Mehrere Lehrer unterrichten mehrere Schüler, mehrere Schüler werden von mehreren Lehrern unterrichtet. Dies würde nichts über die tatsächliche Beziehung zwischen den einzelnen Objekten (hier Personen) aussagen. Beziehungen lassen sich durch drei Eigenschaften charakterisieren: die Stelligkeit gibt an, wie viele Entities an einer Beziehung beteiligt sind die Kardinalität gibt an, wie viele Instanzen eines Entity-Typs an einer Beziehung beteiligt sind. die Optionalität. Beispiel: 1 Autor kann (muss aber nicht) Bücher schreiben, 1 Buch muss aber unbedingt von einem Autor geschrieben werden. Häufig besteht die Notwendigkeit, eine Beziehung zwischen Objekttypen genauer zu spezifizieren. Zum Beispiel werden in einem Standesamt Informationen gespeichert, welcher Mann mit welcher Frau verheiratet ist und wann das Hochzeitsdatum war. Dieses Hochzeitsdatum gehört als Eigenschaft weder zu Mann noch zu Frau, sie ist eine Eigenschaft der Beziehung. Ein ähnliches Beispiel wäre die Beziehung zwischen Arbeitgeber und Arbeitnehmer. Das Einstellungsdatum ist eine Eigenschaft der Beziehung und nicht des Arbeitgebers oder Arbeitnehmers. 23

24 4. Entity-Relationship-Modell Mann FamName Vorname Ehe Datum Frau FamName Vorname Abbildung 4.6.: Eigenschaft einer Beziehung Eigenschaften von Eigenschaften Angenommen, es werden Informationen über den Fuhrpark einer Firma gespeichert. Ein Auto weist ein eindeutiges Kennzeichen, eine Farbe, eine Marke auf. Nun soll zu dieser Marke ein Mindestpreisreis gespeichert werden. Auto Kennzeichen Marke Farbe Abbildung 4.7.: Objekttyp Auto Was würde passieren, wenn zu dieser Marke der Mindestpreis gespeichert wird? Wenn mehrere Autos zur gleichen Marke gehören, würden Redundanzen auftreten und somit die Fehleranfälligkeit steigen. Daher folgt eine Transformation wie in folgendem Schema. Auto Marke Kennzeichen Marke Farbe MinPreis Abbildung 4.8.: Eigenschaften von Eigenschaften 24

25 Stelligkeit 4.3. Eigenschaften von Beziehungen Sie beschreibt die Anzahl der beteiligten Entities. Die Mehrzahl der Beziehungen ist zweistellig (binär), es gibt aber auch ternäre (dreistellige) und n-stellige Beziehungen. Dazu folgendes Beispiel: (a) ternärer Beziehungstyp (b) Drei binäre Beziehungstypen Wein Kritiker K-S empfiehlt Kritiker K-W Speise Speise Wein S-W Abbildung 4.9.: Beziehungstypen im ER-Modell Es ist aber nicht immer möglich, eine n-stellige Beziehung in mehrere binäre aufzuteilen. Angenommen der Kritiker Huber empfiehlt zur Speise Schnitzel den Wein Grüner Veltliner und zum Henderl einen Eiswein, so entstehen folgende binäre Beziehungen: Huber Schnitzel Huber Henderl Schnitzel Veltliner Henderl Eiswein Es geht aber Information verloren, dass Huber nur zum Schnitzel einen Veltliner empfiehlt (Verlustlosigkeit) Kardinalität Konnektivität Neben der Anzahl der Entitäten ist auch die Anzahl der Instanzen entscheidend. So kann für die hergestellt-aus-beziehung festgelegt werden, dass ein Wein aus mindestens einer Rebsorte hergestellt werden muss, oder auf der Rechnung eines Kunden mehrere Artikel enthalten sein dürfen, oder zu einem Mitarbeiter nur ein Foto gespeichert werden darf. Solche Kriterien werden als Kardinalität bezeichnet. Es gibt 3 Formen: 1 : 1-Beziehung: ein Mitarbeiter hat nur ein Foto, ein bestimmtes Foto gehört nur zu einem Kunden. 25

26 4. Entity-Relationship-Modell 1 : N-Beziehung: eine Mutter kann mehrere Kinder haben, ein Kind hat jedoch nur eine (biologische) Mutter. M : N-Beziehung: ein Autor kann mehrere Bücher schreiben, an einem Buch können mehrere Autoren beteiligt sein. Achtung!! Es kommt auf die richtige Fragestellung an. Eine falsche und für die Sache nicht logische Fragestellung wäre: Mehrere Autoren schreiben mehrere Bücher Denn dieser Satz sagt nichts darüber aus, wie viele Bücher ein einzelner Autor schreibt, bzw. wie viele Autoren an einem bestimmten Buch schreiben. Notationen Für Kardinalitäten gibt es unterschiedliche Methoden der Darstellung. Autor [0, ] [1,1] schreibt Buch Autor (a) [min,max]-notation bei 1 : N 1 N schreibt Buch (b) Chen-Notation Autor schreibt Buch (c) Krähenfuß-Notation Abbildung 4.10.: Notationen für Kardinalitäten Von der Kardinalität wird oft die Konnektivität unterschieden, die die tatsächliche Anzahl der beteiligten Entities angibt. Dies ist im ER-Modell insofern wichtig, da daraus Informationen für Applikationen und Programme gewonnen werden. In einer Datenbank ist es unmöglich, Konnektivität darzustellen, außer es werden sog. Trigger eingesetzt. Beispiele für Konnektivität sind: In einer Firma betreut 1 Berater mindestens 1, maximal aber 3 Kunden, 1 Kunde wird von mindestens 1 Berater, maximal aber von 3 beraten. Die Kardinalität ist hier M : N, die Konnektivität ist (1,5), bzw. (1,3) je nach Seite. üblicherweise wird nur im Chen-Modell die Konnektivität angegeben, und zwar in runden Klammern. M : N-Beziehungen sind in relationalen Datenbanken nicht abbildbar, daher müssen 26

27 4.3. Eigenschaften von Beziehungen diese in 1 : N-Beziehungen überführt werden. Autor schreibt Buch Autor 1 N N 1 schreibt Buch Abbildung 4.11.: Abbildung M : N-Beziehung Stärke der Beziehung Von einer schwachen Beziehung spricht man, wenn zwei Entitäten voneinander unabhängig existieren können. Umgekehrt wird von einer starken Beziehung gesprochen, wenn zwei Entitäten voneinander abhängig sind. Beispiel für eine schwache Beziehung unterstrichene Wörter markieren Primärschlüssel: KUNDENKATEGORIE (KATEG ID, Bez) KUNDE (KUND ID, KATEG ID, NAME, ADRESSE) In der Tabelle KUNDE existiert ein Fremdschlüssel (KATEG ID), dieser ist jedoch nicht Teil des Primärschlüssels, daher ist die Beziehung schwach. Beispiel für eine starke Beziehung unterstrichene Wörter markieren Primärschlüssel: RECHNUNG (RECHNUNG ID, DATUM, KUNDE ID) RECHNUNGPOSTEN (POS ID, RECHNUNG ID, ARTIKEL, ANZAHL, PREIS) In der Tabelle RECHNUNGPOSTEN existiert ein Fremdschlüssel (RECHNUNG ID), der zusätzlich Teil des Primärschlüssels ist. Daher liegt hier eine starke Beziehung vor. Starke Beziehungen werden im Krähenfuß-Diagramm mit durchgezogenen Linien dargestellt, schwache mit strichlierten Linien Optionalität Bei einer optionalen Beziehung ist die minimale Kardinalität 0, bei einer nicht-optionalen mindestens 1. Optionale Beziehungen werden im Krähenfußmodell durch einen kleinen 27

28 4. Entity-Relationship-Modell (a) schwache Beziehung (b) starke Beziehung Abbildung 4.12.: Notation für Stärke der Beziehung Kreis auf der optionalen Seite gekennzeichnet, nicht-optionale durch einen senkrechten Strich. Autor schreibt Buch Abbildung 4.13.: (Nicht)optionale Beziehung Ein Autor muß nicht unbedingt ein Buch geschrieben haben, aber ein Buch ist ohne Autor nicht denkbar Abhängige Entity-Typen, IST-Beziehung Dieser Spezialfall tritt häufig auf, ein Beispiel ist die Beziehung Wein Schaumwein. Jeder Wein weist gewisse Eigenschafen auf (Jahrgang, Restsüße, Farbe), ein Spezialwein wie ein Schaumwein weist zusätzliche Eigenschaften (Art der Erzeugung, Gehalt an CO 2,...) auf, die die übrigen Weine nicht besitzen. Jeder Schaumwein ist ein Wein, aber nicht jeder Wein ist ein Schaumwein Die Attribute von Wein werden aber zusätzlich an Schaumwein vererbt (und nicht umgekehrt) Redundante Beziehungen Redundanzen sollten normalerweise vermieden werden. Gründe dafür sind: 28

29 4.3. Eigenschaften von Beziehungen mehrfache Eingabe der Daten nötig unnötig Speicherplatz Gefahr von Anomalien und inkonsistenten Daten Folgendes Beispiel soll dies demonstrieren. 1 Kunde kann mehrere Aufträge tätigen, 1 Auftrag kann nur von 1 Kunden kommen. 1 Auftrag kann mehrere Artikel beinhalten, 1 Artikel kommt durchaus auf mehreren Aufträgen vor. Artikel Kunde Auftrag Abbildung 4.14.: zyklische Beziehung Wenn die Beziehung zwischen Kunde und Artikel vom Typ bestellt ist, dann ist die Beziehung redundant, da ja die Artikel über einen Auftrag kommen. Ist die Beziehung jedoch vom Typ reklamiert, dann ist die Beziehung nicht redundant, da ja aus der Bestellung nicht unmittelbar eine Stornierung folgt (zumindest nicht bei funktionierenden Firmen). Ob die Beziehung redundant ist, kann also nicht aus dem ER-Modell abgeleitet werden, erst eine Analyse der Daten bringt Klarheit. 29

30 4. Entity-Relationship-Modell Zusammenfassend eine Übersicht der Begriffe: Begriff Bedeutung Entity Entity-Typ Beziehungstyp Attribut Schlüssel Kardinalität Konnektivität Stärke Stelligkeit abhängige Entities z.b IST-Beziehung Optionalität Objekt der Realität (Zinfandel, Jahrgang 2004, Alkohol 12%) Gruppierung von Entities mit gleichen Eigenschaften (Weine) Gruppierung von Beziehungen zwischen Entities (Produzent erzeugt Wein) Eigenschaft einer Entity oder Beziehung (Name, Jahrgang,...) identifizierende Eigenschaft (Nummer) wie oft nimmt Entity an Beziehung teil (1 : 1,1 : N,M : N) wie viele Entities minimal/maximal beteiligt sind Entity abhängig(stark)/nicht abhängig (schwach) von anderer Entity Anzahl der beteiligten Entity-Typen (binär, ternär) ein Weinanbaugebiet kann oder muss in einer Region liegen Tabelle 4.1.: Begriffe des ER-Modells 4.4. Beispiel eines ER-Modells Es soll eine Datenbank für eine Bibliothek erstellt werden. Dabei werden Daten über Bücher erhoben, jedes Buch trägt einen Titel, eine Seitenanzahl, eine Kurzbeschreibung. Manche Bücher weisen eine ISBN auf, ältere nicht, dennoch soll jedes Buch eindeutig identifiziert werden können. Zusätzlich werden Daten über die Schriftsteller (Autoren) erhoben, diese haben einen Vor- und Nachnamen, sowie ein Geburtsjahr. Es werden noch Daten über Kunden gespeichert (Vor- und Nachnamen, sowie eine Adresse). Es gelten folgende Regeln: Ein Autor kann mehrere Bücher schreiben, ein Buch kann 30

31 4.4. Beispiel eines ER-Modells auch von mehreren Autoren geschrieben werden (Beispiel Fachbücher). Ein Buch erscheint bei einem Verlag, ein Verlag kann aber mehrere Bücher herausbringen. Ein Kunde kann mehrere Bücher ausleihen, dazu muss ein Datum vermerkt werden, wann das Buch ausgeliehen wurde, wann es fällig ist und wann es zurückgebracht wurde. Autoren, Verlage, Bücher und Kunden müssen eindeutig identifizierbar sein. Verlag VerlagNr Name Verlag kann ein Buch herausbringen 1 Buch muss unbedingt von 1 Verlag sein 1 Autor kann 1 Buch schreiben 1 Buch muss unbedingt von 1 Autor sein 2 Buch Verleih Kunde BuchNr Titel Seiten ISBN 5 6 ausleihdat retourdat fällig 7 8 KundenNr Name Adresse Verleih muss ein Buch haben 1 Buch kann auf einem Verleih sein Autor AutorNr Name Adresse Kunde kann ein Buch ausleihen 1 Verleih muss einen Kunden haben Abbildung 4.15.: Beispiel ER-Modell Verleih entsteht aus der Beziehung zwischen Buch und Kunde, da die Angaben wie ausleihdat, fällig, retourdat weder Eigenschaften des Buches noch Eigenschaften des Kunden sind. Bei 1 : N-Beziehungen müssen noch in den Tabellen Fremdschlüssel als Attribute eingetragen werden, damit zum Beispiel später festgestellt werden kann, welches Buch von welchem Verlag herausgebracht wird. Nun ist hier die Frage wichtig, bei welcher Tabelle ein Fremdschlüssel eingetragen wird. Das soll am Beispiel der Beziehung Verlag Buch mit Testdaten demonstriert werden. Zuerst wird in der Tabelle verlag ein Fremdschlüssel (verweist auf Tabelle buch) eingetragen. Beide Bücher werden vom selben Verlag herausgebracht. 31

32 4. Entity-Relationship-Modell VerlagNr Name Ort BuchNr BuchNr Titel Seiten ISBN 100 Suhrkamp Stuttgart Fischer Berlin Suhrkamp Stuttgart 2 Tabelle 4.2.: Verlag 1 Gehen Frost Der Prozess Tabelle 4.3.: Buch Da der Verlag Suhrkamp hier zwei Bücher herausgebracht hat, muss für jedes Buch eine Zeile in der Tabelle Verlag eingezogen werden. Sofort ist hier erkennbar, dass einerseits gewisse Werte redundant vorliegen (VerlagNr, Name, Ort) hier rot gekennzeichnet, andererseits wäre auch die Voraussetzung für einen Primärschlüssel(Einmaligkeit) nicht mehr gegeben (VerlagNr 100 wäre doppelt). Redundante Werte führen zu Anomalien. Daher wäre es falsch, in der Tabelle Verlag den Fremdschlüssel einzutragen. Nun der Versuch, in der Tabelle Buch den Fremdschlüssel (Verweis auf Tabelle verlag) einzutragen. VerlagNr Name Ort 100 Suhrkamp Stuttgart 200 Fischer Berlin Tabelle 4.4.: Verlag BuchNr Titel Seiten ISBN VerlagNr 1 Gehen Frost Der Prozess Tabelle 4.5.: Buch Hier sind keine redundanten Werte vorhanden, somit ist das Schema akzeptabel. Bei M : N-Beziehungen müsste man auf einer der beiden Tabellen Fremdschlüssel eintragen, hätte somit auf jeden Fall redundante Werte, daher wird hier ein anderes Schema angewendet es wird eine Zwischentabelle eingezogen. BuchNr Titel Seiten 100 SQL PHP 200 Tabelle 4.6.: Buch BuchNr AutorNr Tabelle 4.7.: Autor Buch AutorNr Name 1 Huber 2 Meier 3 Dorfer Tabelle 4.8.: Autor Dies Zwischentabelle besteht aus mindestens 2 Spalten, sie besitzt einen kombinierten (hier 2-spaltigen) Primärschlüssel sowohl BuchNr alleine als auch AutorNr alleine 32

33 4.4. Beispiel eines ER-Modells wären nicht primärschlüsselfähig. Jede Spalte für sich ist ein Fremdschlüssel auf eine andere Tabelle (BuchNr verweist auf Tabelle Buch und AutorNr verweist auf Tabelle Autor). Verlag VerlagNr Name Buch BuchNr Titel Seiten ISBN VerlagNr Verleih Buch BuchNr FID retourdat Kunde fällig FID fällig ausleihdat KundenNr Autor Buch BuchNr AutorNr Autor AutorNr Name Adresse Kunde KundenNr Name Adresse Abbildung 4.16.: Beispiel fertiges ER-Modell Die beiden Tabellen Verleih Buch und Kunde fällig sind am ehesten aus Dummydaten ersichtlich. Wenn man davon ausgeht, dass ein Kunde mit einer Ausleihaktion mehrere Bücher ausleihen kann und jedes Buch zu einem anderen Zeitpunkt zurückbringen kann, dann ergibt sich zuerst diese Tabelle: 33

34 4. Entity-Relationship-Modell ID KdNr BuchNr ausleihdat fällig retourdat Tabelle 4.9.: Ausleihtabelle Hier fällt auf, dass zum Beispiel bei ID 1 die Spalten ID, KdNr, ausleihdat und fällig redundant vorkommen, daher ergibt sich folgendes Bild unter Aufspaltung der redundanten Werte in eine neue Tabelle. FID KdNr fällig ausleihdat Tabelle 4.10.: Kunde fällig FID BuchNr retourdat Tabelle 4.11.: Verleih Buch Kunde fällig erhält einen einspaltigen Primärschlüssel (FID) und Verleih Dat einen 2-spaltigen, bestehend aus FID und BuchNr. 34

35 Index Symbols 1: :N...24 A ACID...9 Apache Applikationsserver atomar...9 Attribut...11, 20 Attribute B Baumstruktur...15 Beziehung 1: :N...24 Kardinalität...23 M:N...24 Optionalität...23 rekursiv...22 schwache...26 starke...26 Stelligkeit Beziehungstypen...20 C C C/C Client-Server...12 D Data Dictionary...9 Dateiverwaltungssystem...8 Daten...19 Datenbankmanagementsystem... 8, 10 Datenbanksystem...8, 10 Datenredundanz... 7 Datentyp char...20 date...20 integer, int...20 Datenunabhängigkeit...8f., 11, 15 dauerhaft... 9 DB, Datenbank...10 DB2, Informix...12 Design...17 Drei-Ebenen-Architektur...12 Dreischichtensysteme...12 E Entity...20f. Entitytypen...20 Entity-Typ...20 Entity-Typen...20 ER-Diagramm...20 ER-Modell...19 externe Ebene...11 H Hierarchische Datenbanken...15 Hierarchisches Modell...15 I Informationen...19 Inkonsistenz...7 Instanz Integrität...9, 19 interne Ebene...11 ISAM...8 isoliert...9 IST-Beziehung...27 J Java...12, 16 K Kardinalität...23f. Katalog, Data Dictionary

36 Index Konnektivität...24f. konsistent...9 Konsistenz...9 konzeptuelle Ebene...11 L LINUX M M:N...24 Microsoft, SQL SERVER...12 Middleware...13 MySQL...12 MySQL Query Browser MySQL, SUN...12 N Netzwerkmodell...15 Non-First-Normal-Form, NF O Objekt Objekttyp...20 schwacher Objekttyp Objektorientierte DBS...16 ODBC...13 Open Source...12 Optionalität...23, 26 Oracle...12 P PHP...12 PHPMyAdmin...12 PostgreSQL...12 Primärschlüssel...22 Primary Key...22 R referentielle Integrität...19 Relation Relationale DBS...16 Relationenmodell...8, 11, 19 Relationenschema...11 Relationship S Schlüssel...22 künstliche Schlüssel...22 Kandidaten...22 natürliche Schlüssel...22 Primärschlüssel...22 Schlüsselattribute Schlüsselbedingung...19 Sichten, views...9 Smalltalk sperren, Sperre...8 SQL...12 SQL Server, Microsoft...12 Stelligkeit...23 T Tabelle Transaktionen...9 Trigger...25 Tupel... 11, 20 U UNIX...12 V Vererbung Verlustlosigkeit...24 Z Zweischichtensystem Rechte... 8f. redundant...7 redundant, nicht-redundant