Relationale Datenbanksysteme
Werbung
MultiAugustinum E2A/E3A SQL Relationale Datenbanksysteme Mag. Christian Gürtler 2009 Inhaltsverzeichnis 3 Teil I Allgemeines 5 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 Datei 1 Anwendung 2 Datei 2 Datei 3 Abbildung 1.1: Zugriff auf Dateien Problem der Datenredundanz 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 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 Datei 1 Dateiverwaltungssystem II 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 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 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 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 Weine Tupel Attribute Name La Rose Grand Cru Zinfandel Chardonnay Farbe Rot Rot Weiß Jahrgang 1998 2003 1999 Weingut Creek Helena Müller Relationenschema Relation Tabelle 2.1: Begriffsbildung 11 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 3 Anfrage Antwort Bearbeitung 1 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. 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 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 Benutzerschnittstelle Anwendungslogik DB-Schnittstelle Anwendungslogik DB-Schnittstelle Datenbank Datenbank Abbildung 2.2: Anwendungsarchitekturen 13 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 Müller Produktion Huber Dorfer Meier Vertrieb 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. 3.2 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 3 Arten von Datenbanksystemen Großsrechnern eingesetzt. Der Datenbestand besteht hier aus netzwerkartig verketteten Datensätzen (Records). 3.3 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). 3.4 Relationale Datenbanksysteme Im folgenden wird hauptsächlich dieses Modell mit Tabellen, Entities, Relationen etc. besprochen. 16 Teil II Datenbankdesign 17 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 (SQLDatenbanken), die Beziehungen werden durch Wertevergleich ausgedrückt. Eine Erweiterung dieses Modells ist das Modell der geschachtelteten oder Non-First-Normal-Form (N F 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 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. Zum ER-Modell gehören drei Begriffe: 1. Entity: ein Objekt aus der reellen Welt (Artikel, Kunden, Lieferanten,. . . ). 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 gleichen 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 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: 20 4.2 Grundlagen des Entity-Relationship-Modells (ER-Modell) (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. Preis Nummer Artikel Bezeichnung Abbildung 4.3: Attributnotation eines Entity-Typs Neben Entities können auch Beziehungen Attribute aufweisen. Anteil Wein hergestellt aus Rebsorte Abbildung 4.4: Attributnotation für Beziehungen 21 4 Entity-Relationship-Modell In dieser Abbildung ist die Beziehung zweier Tabellen (Entities) dargestellt, das Attribut Anteil ist weder der Entity Wein noch der Entity Rebsorte zugeordnet. Identifizierung durch Schlüssel 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 ISBNNummer. 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 . 4.3 Eigenschaften von Beziehungen Beziehungen lassen sich durch zwei 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. 4.3.1 Stelligkeit 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 Wein empfiehlt Speise Kritiker (b) Drei binäre Beziehungstypen Kritiker K-S K-W Speise Wein S-W Abbildung 4.5: Beziehungstypen im ER-Modell 22 4.3 Eigenschaften von Beziehungen 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 ). 4.3.2 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. • 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. 23 4 Entity-Relationship-Modell Autor [0, ∗] [1, 1] schreibt Buch (a) [min, max]-Notation bei 1 : N Autor 1 N schreibt Buch (b) Chen-Notation schreibt Autor Buch (c) Krähenfuß-Notation Abbildung 4.6: 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 diese in 1 : N -Beziehungen überführt werden. schreibt Autor Autor 1 N schreibt Buch N 1 Buch Abbildung 4.7: Abbildung M : N -Beziehung 24 4.3 Eigenschaften von Beziehungen 4.3.3 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. (a) schwache Beziehung (b) starke Beziehung Abbildung 4.8: Notation für Stärke der Beziehung 4.3.4 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 Kreis auf der optionalen Seite gekennzeichnet, nicht-optionale durch einen senkrechten Strich. 25 4 Entity-Relationship-Modell Autor schreibt Buch Abbildung 4.9: (Nicht)optionale Beziehung Ein Autor muß nicht unbedingt ein Buch geschrieben haben, aber ein Buch ist ohne Autor nicht denkbar. 4.3.5 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 CO2 , . . . ) 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). 26 4.3 Eigenschaften von Beziehungen Zusammenfassend eine Übersicht der Begriffe: Begriff Bedeutung Entity Objekt der Realität (Zinfandel, Jahrgang 2004, Alkohol 12%) Entity-Typ Gruppierung von Entities mit gleichen Eigenschaften (Weine) Beziehungstyp Gruppierung von Beziehungen zwischen Entities (Produzent erzeugt Wein) Attribut Eigenschaft einer Entity oder Beziehung (Name, Jahrgang, . . . ) Schlüssel identifizierende Eigenschaft (Nummer) Kardinalität wie oft nimmt Entity an Beziehung teil (1 : 1, 1 : N, M : N ) Konnektivität wie viele Entities minimal/maximal beteiligt sind Stärke Entity abhängig (stark)/nicht abhängig (schwach) von anderer Entity Stelligkeit Anzahl der beteiligten Entity-Typen (binär, ternär) abhängige Entities z.B IST-Beziehung Optionalität ein Weinanbaugebiet kann oder muss in einer Region liegen Tabelle 4.1: Begriffe des ER-Modells 27 Teil III SQL-Abfragen 29 Index 1:1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 1:N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 DB2, Informix . . . . . . . . . . . . . . . . . . . . . 12 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Drei-Ebenen-Architektur . . . . . . . . . . . 12 Dreischichtensysteme . . . . . . . . . . . . . . .12 A E ACID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Applikationsserver . . . . . . . . . . . . . . . . . 12 atomar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Attribut . . . . . . . . . . . . . . . . . . . . . . . . 11, 20 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 f. Entity-Typ . . . . . . . . . . . . . . . . . . . . . . . . .20 ER-Diagramm . . . . . . . . . . . . . . . . . . . . . 20 ER-Modell . . . . . . . . . . . . . . . . . . . . . . . . . 19 externe Ebene. . . . . . . . . . . . . . . . . . . . . .11 Symbols H B Baumstruktur . . . . . . . . . . . . . . . . . . . . . . 15 Beziehung 1:1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 1:N . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 M:N . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 schwache . . . . . . . . . . . . . . . . . . . . . . 24 starke . . . . . . . . . . . . . . . . . . . . . . . . . 24 Beziehungstypen . . . . . . . . . . . . . . . . . . . 20 C C ++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 C/C ++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Client-Server . . . . . . . . . . . . . . . . . . . . . . . 12 Hierarchische Datenbanken . . . . . . . . . 15 Hierarchisches Modell . . . . . . . . . . . . . . 15 I Informationen . . . . . . . . . . . . . . . . . . . . . . 19 Inkonsistenz . . . . . . . . . . . . . . . . . . . . . . . . . 7 Instanz . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Integrität . . . . . . . . . . . . . . . . . . . . . . . . . . 19 interne Ebene . . . . . . . . . . . . . . . . . . . . . . 11 ISAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 isoliert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 IST-Beziehung . . . . . . . . . . . . . . . . . . . . . 25 J D Java . . . . . . . . . . . . . . . . . . . . . . . . . . . .12, 16 Data Dictionary . . . . . . . . . . . . . . . . . . . . . 9 Dateiverwaltungssystem . . . . . . . . . . . . . 8 Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Datenbankmanagementsystem . . . 8, 10 Datenbanksystem. . . . . . . . . . . . . . . .8, 10 Datenredundanz . . . . . . . . . . . . . . . . . . . . 7 Datentyp . . . . . . . . . . . . . . . . . . . . . . . . . . 20 char . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 date . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 integer, int . . . . . . . . . . . . . . . . . . . . 20 dauerhaft . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 DB, Datenbank . . . . . . . . . . . . . . . . . . . . 10 K Kandidaten . . . . . . . . . . . . . . . . . . . . . . . . 22 Kardinalität . . . . . . . . . . . . . . . . . . . . . . . 22 Katalog, Data Dictionary . . . . . . . . . . . 9 Konnektivität . . . . . . . . . . . . . . . . . . . . . . 24 konsistent . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Konsistenz . . . . . . . . . . . . . . . . . . . . . . . . . . 9 konzeptuelle Ebene. . . . . . . . . . . . . . . . .11 L LINUX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 31 Index M M:N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Microsoft, SQL SERVER. . . . . . . . . . .12 Middleware . . . . . . . . . . . . . . . . . . . . . . . . 13 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 MySQL Query Browser . . . . . . . . . . . . 12 MySQL, SUN . . . . . . . . . . . . . . . . . . . . . . 12 N Netzwerkmodell . . . . . . . . . . . . . . . . . . . . 15 Non-First-Normal-Form, NF2 . . . . . . 19 SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 SQL Server, Microsoft. . . . . . . . . . . . . .12 Stelligkeit . . . . . . . . . . . . . . . . . . . . . . . . . . 22 T Tabelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Transaktionen . . . . . . . . . . . . . . . . . . . . . . . 9 Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 Tupel . . . . . . . . . . . . . . . . . . . . . . . . . . 11, 20 U UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 O V Objektorientierte DBS . . . . . . . . . . . . . 16 ODBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Open Source . . . . . . . . . . . . . . . . . . . . . . . 12 Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 P PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 PHPMyAdmin . . . . . . . . . . . . . . . . . . . . . 12 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . 12 Primärschlüssel . . . . . . . . . . . . . . . . . . . . 22 Primary Key . . . . . . . . . . . . . . . . . . . . . . . 22 R Rechte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 f. redundant . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 redundant, nicht-redundant . . . . . . . . . 9 referentielle Integrität . . . . . . . . . . . . . . 19 Relation . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Relationale DBS . . . . . . . . . . . . . . . . . . . 16 Relationenmodell . . . . . . . . . . . . 8, 11, 19 Relationenschema . . . . . . . . . . . . . . . . . . 11 Relationship . . . . . . . . . . . . . . . . . . . . . . . 20 S Schlüssel, Schlüsselbedingung . . . . . . 19 Sichten, views . . . . . . . . . . . . . . . . . . . . . . . 9 Smalltalk . . . . . . . . . . . . . . . . . . . . . . . . . . 16 sperren, Sperre . . . . . . . . . . . . . . . . . . . . . . 8 32 Vererbung . . . . . . . . . . . . . . . . . . . . . . . . . 25 Verlustlosigkeit. . . . . . . . . . . . . . . . . . . . .23 Z Zweischichtensystem . . . . . . . . . . . . . . . 12
