Marcus Börger. Relationale Datenbanken. Modellierung und SQL

Transkript

1

2

3 Marcus Börger Relationale Datenbanken Modellierung und SQL

4 Relationale Datenbanken, Modellierung und SQL, richtet sich an alle, die sich in das Thema Relationale Datenbanken einarbeiten wollen. Es bietet dazu eine praktisch orientierte Einführung in die Konzepte Relationaler Datenbanken sowie einen Einstieg in die drei verbreiteten Datenbank Managementsysteme MySQL, PostgreSQL und Oracle. Titel Thema Herausgeber Autor Umschlagdesign Relationale Datenbanken Modellierung und SQL Marcus Börger Marcus Börger Martine Windt, Marcus Börger Erstellt am Aktuelle Version

5 Relationale Datenbanken Inhalt Inhalt 1 Einleitung Datenbank Schemata Das Physische Schema Das Konzeptuelle Schema Tabellen Attribute Datentypen Indizes Relationen Keys Referenzielle Integrität Views Aufgaben Modellierung Normalformen Erste Normalform Zweite Normalform Dritte Normalform Vierte Normalform Jenseits der Normalformen Normalform oder Optimierung Namensgebung ER-Diagramme Aufgaben Anwendungsstrukturen tier tier tier Installation MySQL Windows PostgreSQL Windows Initialisierung von Postgres Postgres als Windows Service Oracle Windows Linux Database Configuration Assistant Net8 Assistant DBA Studio SQL*Plus Data Definition Language CREATE DATABASE Verbinden mit der Datenbank Anlegen und Verbinden mit dem Beispiel CREATE TABLE...55 Marcus Börger 5

6 Inhalt Relationale Datenbanken CREATE TABLE für MySQL Spaltendefinitionen Constraints CREATE TABLE SELECT Anlegen der Tabellen der Datenbank Uni CREATE INDEX CREATE VIEW CREATE TRIGGER CREATE RULE CREATE SEQUENCE ALTER TABLE ALTER TABLE und MySQL ALTER TABLE und Oracle ALTER TABLE und PostgreSQL DROP TRUNCATE TABLE Data Manipulation Language INSERT INTO INSERT INTO SELECT Eingabe der Beispieldaten SELECT FROM WHERE Aliasnamen Abfragen über mehrere Tabellen Tabellen mehrmals in einer Abfrage Abfragen mit indirekten Tabellen Aggregation GROUP BY HAVING ORDER BY UNION UNION ALL EXCEPT INTERSECT Subselects SELECT DISTINCT SELECT ohne FROM Top-Level Abfragen UPDATE SELECT FOR UPDATE; UPDATE; REPLACE INTO DELETE Top-Level Delete Löschen doppelter Datensätze Operatoren und Funktionen Mathematische Operatoren Bitweise Operatoren Logische Operatoren Vergleichsoperatoren Bedingungsoperatoren Umgang mit NULL Funktionen für Zeichenketten Online Analytical Processing Transactions Marcus Börger

7 Relationale Datenbanken Inhalt 9 Rechteverwaltung MySQL Die Datenbank mysql Rechte applizieren Verlust des root Paßworts phpmyadmin PostgreSQL Oracle Trigger PostgreSQL und PL/PGSQL Oracle und PL/SQL Microsoft und VBA Zusammenfassung A EBNF B Lösungen C Verzeichnis der Abbildungen und Tabellen D Literaturverzeichnis Marcus Börger 7

8 Einleitung Relationale Datenbanken 1 Einleitung Gegenstand dieses Booklets sind relationale Datenbanken. Relationale Datenbanken arbeiten mit strukturierte Daten, daß heißt sie arbeiten üblicherweise mit großen Mengen von ähnlich strukturierten Daten und können diese in Relation zu einander bringen. Neben diesem Konzept existieren noch andere Ansätze, die mit semistrukturierten Daten arbeiten, Verzeichnisdienste, Objektorientierte Datenbanken und XML 1 [BeMi00], [Boe00], [NWB00]. Verzeichnisdienste 2 wie DAP [HSG98], NDS oder ADS werden oft zur hierarchischen Speicherung von Zugriffsrechten verwendet. Es wäre zwar möglich diese auf relationalen Datenbanken ab zu bilden aber diese eignen sich dafür nur eingeschränkt. Ebensowenig eignen sich relationale Datenbanken zur Speicherung von XML Daten. Zwar erweitern alle großen Datenbankhersteller ihre Datenbanken immer mehr um Fähigkeiten zum Umgang mit XML Daten, jedoch ermöglichen erst native Datenbanken wie Tamino [SAG00] einen effektiven Umgang. Die Reihenfolge der Kapitel entspricht dem Bottom-Up Ansatz. Es werden also zuerst die Grundlagen erarbeitet und am Ende die Anwendungen vorgestellt. Wenn ein grundlegendes Verständnis der einzelnen Kapitel bereits vorhanden ist, so kann jedes Kapitel für sich getrennt unabhängig von der Reihenfolge betrachtet werden. Zunächst sollen im Kapitel 2 Datenbank Schemata die Struktur und die Funktionsweise von relationalen Datenbanken kurz angerissen werden. Dies ist wichtig um die weiteren Abschnitte verstehen zu können. Ein exaktes Verständnis bis ins Detail ist jedoch nicht notwendig. Dieses bleibt dem Selbststudium in der einschlägigen Literatur vorbehalten [HeSa00], [SKS97]. Nachdem grundlegende Strukturen und Begriffe eingeführt sind, erfolgt in Kapitel 3 Modellierung eine Einführung in die Modellierung relationaler Datenbanken. Hierbei handelt es sich um eine verkürzte Einführung, die anhand von Beispielen praktische Modellierungskonzepte vorstellt. Auch hierbei gilt, daß eine exakte wissenschaftliche Einführung der Fachliteratur vorbehalten bleibt. Das Kapitel 4 Anwendungsstrukturen beschäftigt sich mit den Strukturen, in denen Datenbanken eingesetzt werden. Bevor die erstellten Modelle umgesetzt werden können, muß zunächst ein geeignetes Datenbank Managementsystem installiert werden. In Kapitel 5 Installation wird die Installation für einige Systeme vorgestellt. Stark mit der Modellierung verbunden ist das Anlegen der Datenstrukturen. Bei relationalen Datenbanken erfolgt dies meist mit einem Teilsatz der Structured Query Language (SQL). Dieses wird in Kapitel 6 Data Definition Language behandelt. Den zweiten wichtigen Teil von SQL stellt das Kapitel 7 Data Manipulation Language vor. Er dient der Bearbeitung/Abfrage von Daten. Ein Teil des Kapitels ist dem Thema Funktionen und Online Analytical Processing (OLAP) gewidmet. 1 XML: extensible Markup Language 2 Verzeichnisdienste stellen hierarchische Informationen bereit. Diese können erst mit den in SQL-99 definierten rekursiven Anfragen effektiv in relationalen Datenbanken realisiert werden. Beispiele: DAP: Directory Access Protocol und LDAP: Lightweight Directory Access Protocol; NDS: Novell Directory Service, Rechteverwaltung auf Novell Servern; ADS: Advanced Directory Service, von Microsoft mit Windows 2000 eingeführte Rechteverwaltung. 8 Marcus Börger

9 Relationale Datenbanken Einleitung Die Data Maipulation Language bietet lediglich Atomare Befehle. Oft sind aber für Änderungen an einem Datenbestand mehrere Befehle notwendig. In Kapitel 8 Transactions wird die Lösung dazu vorgestellt. Wenn mehrere Personen mit einer Datenbank arbeiten, so ist es meist erforderlich Rechte zu vergeben mit denen man die Möglichkeiten der Datenmanipulation und des Datenzugangs für einzelne Nutzer einschränken zu können. Dieses Thema wird in Kapitel 9 Rechteverwaltung behandelt. Größere Datenbank Management Systeme bieten Methoden zur Automatisierung von Vorgängen in der Datenbank. Lesen Sie hierüber in Kapitel 10 Trigger. Am Ende einiger Kapitel befinden sich Übungen mit denen der jeweilige Stoff vertieft werden kann. Die anfänglichen Übungen bauen auf den Beispielen des Textes auf. Ihnen schließen sich komplexere Aufgaben an. Marcus Börger 9

10 Datenbank Schemata Relationale Datenbanken 2 Datenbank Schemata Wenn man die logische Architektur einer Datenbank betrachtet, dann besteht eine Datenbank aus drei Schemata (Ebenen) [FNA99], [HeSa00], [SKS97]. Das Physische Schema abstrahiert von der Art und Weise, wie die Daten physikalisch abgelegt sind. Das bedeutet, daß es außerhalb des Physischen Schemas keine Rolle spielt, ob die Daten in einer Datei oder mehreren Dateien abgelegt sind, wie die Dateien organisiert sind, wie sie angesprochen werden oder ob überhaupt Dateien zum Einsatz kommen. Weiterhin abstrahiert das Physische Schema von der internen Struktur der abgelegten Daten. Das Konzeptuelle Schema bildet die logische Struktur der Daten ab. Wird eine Datenbank geplant, so werden zunächst die Daten und ihre Zusammenhänge analysiert. Hieraus entsteht das eingesetzte Datenmodell, das frei von Redundanz ist. Im relationalen Datenmodell werden Datensätze gleichen Typs in Tabellen abgelegt. Auf dem konzeptuellen Schema basieren schließlich Views (Sichten). Views sind unabhängig von logischen Änderungen in den unterliegenden Schemata. Views erlauben unterschiedliche Ausschnitte des Datenmodels und verschiedene Sichten darauf für unterschiedliche Anwendungen und Anwender. Sie bringen Sicherheit und Konsistenz in die Datenbank. Views für Studenten Kein Zugriff auf andere Studenten Nur Leseoperationen Views für Dozenten Kein Zugriff auf persönliche Daten anderer Personen Views für Verwaltung Noten nur Lesen, außer Prüfungsamt Gehälter ändern Konzeptuelles Schema Personen (PNr, PTyp [Student, Dozent], Name, Adresse, Login, Gehalt, Datum) Veranstaltungen (VNr, PNr, VName, VZeit, VOrt) besuchen (PNr, VNr, Note) Daten in physischer Form Indizes auf Datensätze Kontrollinformationen, Scripte Physisches Schema Abbildung 2.1: Datenbank Schemata 10 Marcus Börger

11 Relationale Datenbanken Datenbank Schemata 2.1 Das Physische Schema Wie bereits erläutert werden im physischen Schema die Daten gespeichert. Werden etwa Adreßdaten in einer Textdatei abgelegt und entspricht jeder Zeile eine Adresse, so sind dadurch bereits physisches und konzeptuelles Schema bestimmt. Die Suche nach einzelnen Adressen erfordert hier jedoch ein Durchsuchen der gesamten Liste für jede Einzelne. Noch schlimmer wird es, wenn Teile der Adreßdatei weitergegeben werden sollen, die Reihenfolge geändert oder Analysen durchgeführt werden sollen, wie etwa die Berechnung der Personen, die in einer bestimmten Stadt wohnen. Ein weiteres Problem ist auch die Übersichtlichkeit der Adressen innerhalb der Dateien, denn egal wie man seine Adressen innerhalb der Datei formatiert, es finden sich immer Adressen, die nicht in das Format passen. Eine Datenbank kann hier wesentlich mehr leisten, denn die Ausgabe kann immer neu angepaßt werden und es ist dabei nicht zwingend notwendig jedesmal die physikalische Struktur der Daten zu kennen. Ein genaues Verständnis, wie die Daten abgelegt werden, ist nicht notwendig. Jedoch speichern die meisten Datenbanken in Dateien auf Standard Dateisystemen. Bei großen Datenbanken ist es hilfreich die Organisation zu verstehen, da bereits hier eine Optimierung erfolgen kann bzw. die Eigenschaften des Dateisystems Einfluß auf Eigenschaften der Datenbank hat. Während kleinere Datenbanken üblicherweise eine einzige Datei benutzen, legen größere Datenbanken ihre Daten meist in mehreren Dateien ab. Eine erste Aufteilung ergibt sich, wenn die Datenbank für jede Tabelle eine eigene Datei anlegt und Indizes getrennt speichert. Meist benutzen die Datenbanken jedoch sogenannte Extends die unabhängig von den Strukturen im Konzeptuellen Schema sind (Informationstheoretisch wäre eine Vermischung der Schemata ein großer Nachteil). Die Einflußmöglichkeiten des Dateisystems sind weitreichend, werden jedoch meist unterschätzt und zu spät erkannt. Wichtigstes Augenmerk ist hier die Beachtung der maximalen Dateigröße des Dateisystems. Wenn die Datenbankkonfiguration größere Dateien erlaubt als das System sind Fehler vorprogrammiert. Das Wissen um die Einflußmöglichkeiten auf die Speicherorte der Daten kann Kosten und/oder Zugriffszeiten senken. Zum einen können Daten die selten benötigt werden auf langsameren und damit billigeren Medien oder Systemen gespeichert werden. Zum anderen kann man bei großen Datenbanken Informationen nach Teilinformationen getrennt ablegen. Üblicherweise können solche Datenbanken auch mit mehreren Prozessoren gleichzeitig arbeiten, wodurch sich für die Datenbank die Möglichkeit ergibt eine Aufgabe vollkommen parallel auszuführen. Besonders die Kenntnis der Art und Weise, wie eine Datenbank mit verschiedenen Datentypen umgeht, kann zu Optimierungszwecken genutzt werden. Werden im Konzeptuellen Schema beispielsweise viele mathematische Berechnungen mit einem Wert durchgeführt, so empfiehlt es sich ihn von der Datenbank im Physischen Schema als Zahl abspeichern zu lassen. Werden hingegen Textoperationen mit einem Wert ausgeführt sollte man den Wert im Textformat speichern. Ist hingegen die Datenbank ungeeignet ein bestimmtes Format zu speichern, so kann eine andere Lösung sinnvoll sein. Hat eine Datenbank zum Beispiel Probleme mit großen Datenmengen, so werden in der Datenbank einfach Referenzen auf Dateien gespeichert und in diesen Dateien werden dann die Daten abgelegt. Als Referenz kann der Dateiname benutzt werden, so daß das Dateisystem hierbei zur Datenbank wird. So bleiben bei Webanwendungen Bild- und Musikdaten meist auf dem Webserver und in der Datenbank werden nur ihre Dateinamen gespeichert. Marcus Börger 11

12 Datenbank Schemata Relationale Datenbanken 2.2 Das Konzeptuelle Schema Im Konzeptuellen Schema definiert der Datenbank Entwickler das Datenmodell, die wie bereits erwähnt unabhängig von den Strukturen des physischen Schemas sind. Denn alle Datenabfragen und Dateneingaben erfolgen hier im Konzeptuellen Schema. Schon während der Modellierung muß die Anwendung bekannt sein, damit man nicht an der Anwendung vorbei modelliert. Man hat im dann Extremfall zwar ein Datenmodell, daß die Daten speichert, nicht aber die Anfragen der Anwendung effektiv bearbeiten kann. Man muß also während der gesamten Modellierungsphase die Eignung des Datenmodells zur Realisierung der Aufgaben innerhalb der Anwendung prüfen. Bevor eine Datenbank modelliert werden kann, ist also ein genaues Verständnis der Strukturen einer Datenbank sowie ihren Werkzeugen und Funktionsweisen unabdingbar Tabellen Relationale Datenbanken verwenden Tabellen zum Speichern von Daten. Bei der Modellierung der Datenbank ermittelt man in welcher Form Daten vorliegen. Für die unterschiedlichen Formen legt man dann jeweils Tabellen an. Diese bilden eine Ablageschablone für die gefundenen Datenformen. Der allgemeine Datenbanktheoretische Begriff für Tabellen lautet Entity oder zu Deutsch Entität Attribute Die einzelnen Spalten einer Tabelle bezeichnet man als Attribute. Die einzelnen Zellen der Tabelle werden als Felder und die Zeilen der Tabelle als Datensätze bezeichnet. Die Felder nehmen also die einzelnen Werte auf, aus denen ein Datensatz besteht. Dabei wird der Datentyp bereits durch die Spalte bestimmt. Alle Felder einer Spalte haben also den gleichen Datentyp. In Kapitel 3.3 ER-Diagramme wird ein sehr oft benutzter Diagrammtyp vorgestellt. Zur besseren Veranschaulichung wird aber zunächst die folgende Darstellung für Tabellen benutzt: Datensatz Tabellenname Attribut 1 Attribut 2 Attribut 3 Attribut 4 Attribut 5 Feld Datensatz Spalte Abbildung 2.2: Tabellendarstellung Die Spalte Datensatz dient der Numerierung der Datensätze und damit lediglich der Veranschaulichung. Zwar benutzen Datenbanksysteme tatsächlich zusätzliche Verwaltungsinformationen, allerdings sind diese nicht zugänglich vom verwendeten System abhängig und werden damit in der Modellierung und Veranschaulichung auch nicht benötigt. 12 Marcus Börger

13 Relationale Datenbanken Datenbank Schemata Als Beispiel für Datenbanktabellen mit ihren Attributen dienen hier die Tabellen für Personen, Veranstaltungen und die Relationstabelle besuchen. Datensatz PNr Datensatz Personen PTyp Name Adresse Login Gehalt Datum Dozent Ebert, K. ebert Dozent Zucker, G. zucker Student Meier, A NULL Student Kühn, H NULL Student Muster, M NULL Abbildung 2.3: Tabelle Personen Veranstaltungen VNr PNr VName VZeit VOrt Einführung Mo, 10:00 H Modellierung Di, 12:00 H SQL-DDL Mo, 10:00 H SQL-DML Di, 10:00 H1 Abbildung 2.4: Tabelle Veranstaltungen besuchen Datensatz VNr PNr Abbildung 2.5: Tabelle besuchen Datentypen Die einzelnen Attribute einer Tabelle können einwertig, mehrwertig oder zusammengesetzt sein. Einwertige Attribute enthalten Texte oder Zahlen oder Werte aus einer Liste. Eine genaue Auflistung dieser Datentypen findet sich weiter unten. Man kann eine weitere Tabelle mit der Liste aller möglichen Werte für ein Attribut füllen und auf diese Weise den Wertebereich für ein Attribut dynamisch verwalten. Mehrwertige Attribute stellen eine Liste einwertiger Datentypen dar. Dieses wird oft benutzt, um Flags oder benannte Eigenschaften zu speichern. Das Speichern der besuchten oder gelesenen Veranstaltungen ist ein Beispiel hierfür. Mehrwertige Attribute sind in einem Relationalen Datenmodell nicht zulässig. Kommt bei einem mehrwertigem Attribut eine Liste mit bekannter maximaler Länge zum Einsatz, so kann man das mehrwertige Attribut durch den Einsatz entsprechend vieler einwertiger Attribute gleichen Datentyps ersetzen. Ansonsten muß eine weitere Tabelle angelegt werden. Das wird in Kapitel 3.1 Normalformen deutlich. Zusammengesetzte Attribute sind im Prinzip einzelne Attribute die als ganzes betrachtet werden können. Man kann zusammengesetzte Attribute in einer weiteren Tabelle auslagern, wenn immer gleiche Paare auftreten. Anders verhält sich das Beispielsweise bei Namen. Diese können natürlich in einem einzelnen Attribut gespeichert werden, dabei geht jedoch verloren welcher Teil Anrede, Vorname oder Nachname ist. Die einzelnen Attribute von zusammengesetzten Attributen müssen im Gegensatz zu mehrwertigen Attributen nicht vom gleichen Datentyp sein. Auch können Teilinformationen als Referenz auf eine andere Tabelle realisiert werden. Nachteilig ist, daß das Zusammensetzten der Teilinformationen einen zusätzlichem Aufwand darstellt. Marcus Börger 13

14 Datenbank Schemata Relationale Datenbanken Relationale Datenbanken unterscheiden die folgenden einwertigen Datentypen: Integerzahlen; ganzzahlige Werte eignen sich besonders gut als Indizes und für einfache mathematische Berechnungen. Fließkommazahlen; Mathematische Berechnungen jeder Art. Festkommazahlen; Fließkommazahlen mit fester Anzahl der Nachkommastellen für mathematische Berechnungen, besonders für Währungsrechnungen geeignet. Einsatz ist nicht empfehlenswert, wenn Genauigkeit und Darstellung nicht identisch sind, damit keine Eignung für Wirtschaftssysteme. Währung; Festkommazahlen die mit einer Währungskennzeichnung versehen sind. Zeichen ;Einzelne beliebige Zeichen, oft als Flags oder Status genutzt. Zeichenketten; Zeichenfolgen mit fester oder variabler Länge. Boolesche Werte; Speicherung der Zustände JA/NEIN. Zeiten; Zeitangaben mit festgelegter Genauigkeit eignen sich in einfachen Systemen gut für Zeitberechnungen. Datumsangaben; Datumsangeben sind wie Zeitangaben meist Systemabhängig. Kommen mehrere Systeme zum Einsatz, sind andere Lösungen zu prüfen. Binary Large Objects (BLOB); Speicherung beliebiger Informationen. Dabei bieten die meisten RDBMS rein binäre und textorientierte Typen, die Textfunktionen erlauben. Neben diesen Standardtypen existieren in vielen Datenbanken noch spezielle andere Datentypen und oft haben die Datenbanken unterschiedliche Bezeichnungen für obige Datentypen. Bei der Modellierung sollte darauf Acht gegeben werden, daß nicht zu oft zwischen den Datentypen konvertiert werden muß, da jede Konvertierung zusätzliche Zeit beansprucht. Bei den meisten Datentypen können zusätzliche Angaben zur Genauigkeit oder Länge angegeben werden. Die SQL Datentypen werden in SQL Datentypen beschrieben NULL Der Wert NULL ist eigentlich gar kein Wert, denn er repräsentiert die Aussage kein Wert oder Wert nicht bekannt. Alle Spaltenwerte, die nicht explizit oder implizit durch Standardwerte belegt werden haben den Wert NULL. Der Wert NULL ist gänzlich von der Zahl 0, der leeren Zeichenfolge '' sowie der leeren Menge () zu unterscheiden. Alle Vergleiche mit dem NULL ergeben falsch. Für eine Überprüfung auf den Wert NULL benötigen Datenbanken also spezielle Funktionen bzw. Operatoren. SQL benutzt hierzu den Operator IS NULL (siehe IS NULL). Folgende Aussagen veranschaulichen NULL: NULL!= 0 NULL ist ungleich der Zahl 0 NULL!= '' NULL ist ungleich einer leeren Zeichenfolge NULL!= () NULL ist ungleich der leeren Menge (NULL!= NULL) = NULL NULL ist weder gleich noch ungleich NULL (NULL IS NULL) = true NULL wird über den Operator IS NULL erkannt Für nahezu alle Funktionen und Operatoren außer IS NULL gilt, wenn ein Parameter den Wert NULL hat, so ist das Ergebnis NULL. 14 Marcus Börger

15 Relationale Datenbanken Datenbank Schemata Berechnete Spalten Eine Besonderheit bilden berechnete Spalten, die von einigen wenigen Datenbanken unterstützt werden. Solche Spalten repräsentieren das Ergebnis einer Berechnung anderer Spalten des Datensatzes. Damit lassen sich einige Aufgaben vereinfachen. Angenommen in einer Tabelle werden Anzahl und Preis einer Ware gespeichert, dann könnte man den Gesamtpreis als berechnete Spalte Anzahl*Preis definieren. Dieses Konzept hat den Nachteil, daß nun nicht mehr alle Spalten der Tabelle geändert werden können. Denn solche Spalten dürfen logischerweise nur gelesen werden. Eine elegantere Methode stellen Views bereit. Diese bieten zudem die Möglichkeit andere Datensätze auch aus fremden Tabellen mit in die Berechnung einzubeziehen (2.3 Views). Beispiele für berechnete Spalten: (Anzahl * Preis + Porto) * MWSt Vorname ' ' Nachname Indizes Wenn Daten ohne irgendeine Sortierung geliefert werden sollen, so nimmt das DBMS immer einen sogenannten full-table-scan vor. Daß heißt es wir ein Datenzeiger auf den ersten Datensatz in der physikalischen Tabelle positioniert und der Datensatz geliefert. Danach wird der Datensatzzeiger zum nächsten Datensatz verschoben und der dortige Datensatz geliefert. Das wird solange wiederholt, bis alle Datensätze zurückgegeben worden sind. Datensatzzeiger Datensatz hört VNr Abbildung 2.6: full-table-scan Indizes bilden eine Möglichkeit schnell und geordnet auf einzelne Datensätze innerhalb einer Tabelle zu zugreifen. Hierzu speichert ein Index eine bestimmte Sortierfolge der Datensätze einer Tabelle ab und ordnet dieser den Positionen innerhalb der Tabelle zu. Wenn ein Zugriff auf eine Tabelle unter einer Sortierung erfolgt, für die es keinen Index gibt, so wird dieser temporär angelegt und nach dem Zugriff verworfen 3. Da die Berechnung der Reihenfolge der Datensätze für einen Index zeitaufwendig ist, sollten für solche Zugriffe alle notwendigen Indizes vorhanden sein. Das Fehlen eines Index wirkt sich besonders dann dramatisch aus, wenn er häufig benutzt wird. Dies kann der Fall sein, wenn sich der Index in einer Unterabfrage oder einer Funktion fehlt, das Fehlen sich also über eine Nebenaktion auswirkt und nicht offensichtlich ist. Wenn ein Index eindeutig ist, so wird er als unique bezeichnet. Eine besondere Form eindeutiger Indizes wird in Keys vorgestellt. Dort finden sich auch Grafiken, die den Tabellenzugriff über Indizes veranschaulichen (Abbildung 2.18: Primary Key, Abbildung 2.19: Primary Key bei ungeordneter Tabelle und Abbildung 2.20: Primary Key und Index (VZeit, VOrt)). PNr Datensatz 3 Manche Datenbanken ersetzen sortierte Abfragen auch durch full-table-scans. Das Anlegen eines temporären Index hat aber den enormen Vorteil, daß der Datenbank Programmcode mit einer Funktion auskommt. Auch macht es zeitlich oft keinen Unterschied ob ein Index erstellt wird oder ein Sortierkriterium für jeden einzelnen Datensatz geprüft werden muß. Marcus Börger 15

16 Datenbank Schemata Relationale Datenbanken Relationen Relationen stellen die Verbindung mehrerer Tabellen zueinander her. Durch sie können Daten, die sich über mehreren Tabellen verteilen, zusammengefügt werden. Relationen können durch den Einsatz von Constraints und Triggern (6.4.3 Constraints) gesichert werden. Insbesondere ist es damit möglich ein getrenntes Löschen bzw. Anlegen von Teildatensätzen zu verhindern (siehe Referenzielle Integrität) Relationstyp 1 zu 1 Eine Relation der Form 1 zu 1 entsteht, wenn es zu jedem Spaltenwert einer Tabelle genau einen Spaltenwert in einer zweiten Tabelle gibt. Relationen der Form 1 zu 1 sollten in einer relationalen Datenbank niemals vorkommen, da sie in einer Tabelle zusammengefaßt werden können. Sollte sich eine 1 zu 1 Relation durch nachträgliche Modifikation ergeben, so sollte die Relation zumindest gesichert werden, es empfiehlt sich jedoch die Ursprungstabellen zu vereinigen und durch Views abzubilden. Wenn eine neue Tabelle unter einem neuen Namen angelegt wird, so können die alten Tabellen durch Views simuliert werden. Dadurch ist es insbesondere möglich, die Restlich Anwendung ohne weitere Änderung weiter zu nutzen. Besonderen Nutzen der Zusammenfassung erhält man allerdings erst, wenn die Anwendung auf die neue Tabelle umgestellt wird. Mit diesem Hintergrund ergibt sich jedoch umgekehrt, daß eine 1 zu 1 Relation sinnvoll sein kann, wenn sie sich aus anfänglichen Anwendungsanforderungen ergibt, sich in späteren Erweiterungen aber 1 zu n Relationen ergeben. Als Beispiel sei hier die Speicherung von Personen und Adressen angegeben. Anwendungen kommen oft mit nur einer Adresse pro Person aus. Sollen die Personen/Adreßdaten jedoch etwa zu einem Contact Relation Management (CRM) Modul erweitert werden, so ist es erforderlich mehrere Adressen pro Person zu speichern (Privatadresse, Firmenadresse, Lieferadresse). Ein weiterer Grund für die Verwendung von 1 zu 1 Relationen liegt in der Optimierung. Wenn es gelingt den oft benutzen Teil der Datensätze in einer Tabelle aus Spalten fester Länge zu bilden, so erfolgt der Zugriff meist wesentlich schneller. Dies liegt daran, daß sich die Position der Datensätze innerhalb des Speicherortes aus Datensatznummer und Datensatzgröße direkt ergibt. Bei Datensätzen mit variabler Länge muß die Datenbank hingegen ständig Indizes korrigieren oder beim Zugriff die Position jedesmal neu berechnen. Die folgende Abbildung zeigt eine 1 zu 1 Beziehung zwischen einer modifizierten Version von Personen genannt Personen 2, bei der das Feld Adresse fehlt und der neuen Tabelle Adresse, die Adreßangaben auf mehrere Spalten aufteilt. Wäre die Relation über das Feld Adresse definiert hätte man nicht einmal die Tabelle Personen modifizieren müssen. Personen 2 PNr PTyp Name Login Gehalt Datum 1 1 = Adressen PNr Straße Straße2 PLZ Stadt Land Abbildung 2.7: Relationstyp 1 zu 1 16 Marcus Börger

17 Relationale Datenbanken Datenbank Schemata Relationstyp 1 zu 0/1 Optionale Elemente werden oft in getrennten Tabellen gespeichert. Dies hat vor allem bei Optionen, die aus mehreren Feldern bestehen, den Vorteil, daß man Speicherplatz einsparen kann. Im Übrigen sind 1 zu 0/1 Relationen ein Sonderfall von 1 zu 1 Relationen, bei denen es Datensätze gibt, deren einer Teil komplett mit dem Wert NULL belegt ist. Ein Beispiel hiefür sind Studenten und Professoren. Man kann sie in einer Tabelle speichern, wie im Beispiel der Tabelle Personen, da Studenten im Gegensatz zu Professoren jedoch kein Gehalt beziehen, braucht man für sie aber weder Bankverbindungen noch Gehälter speichern. Werden Studenten und Dozenten hingegen in verschiedenen Tabellen gespeichert, so ist es sinnvoll für die gemeinsamen Informationen gleiche Strukturen zu nutzen. Durch den Einsatz entsprechender Techniken (siehe 2.3 Views) kann dann eine Tabelle simuliert werden. Dabei gehen allerdings Key Eigenschaften und gegebenenfalls auch Sortiereigenschaften verloren. Dozenten PNr PTyp Name Adresse Login Gehalt Datum Studenten PNr PTyp Name Adresse Login Studenten & Dozenten" PNr PTyp Name Adresse Login Abbildung 2.8: Relationstyp 1 zu 0/1 vs. Strukturgleichheit Ein weiteres Beispiel ergibt sich aus Abbildung 2.7: Relationstyp 1 zu 1, wenn für Personen, deren Adresse unbekannt ist, keine leeren Datensätze in der Tabelle Adressen erzeugt werden. Zunächst ändert sich an den sichtbaren Strukturen nichts, allerdings ergeben sich aus der Änderung des Relationstyps Konsequenzen bei der Datenorganisation. Werden 1 zu 1 Relationen über Constraints gesichert, so kann ein Löschen eines Datensatzes zur Löschung des entsprechenden Datensatzes genutzt werden. Bei 1 zu 0/1 Relationen geht das nur in einer Richtung. Das Löschen des nicht optionalen Datensatzes führt zum Löschen des optionalen. Personen 2 PNr PTyp Name Login Datum Adressen und Gehalt PNr Straße Straße2 PLZ Stadt Land Gehalt 1 0/1 = Abbildung 2.9: Relationstyp 1 zu 0/1 Die Abbildung 2.9: Relationstyp 1 zu 0/1 zeigt auch, daß Datenmodellierung nicht immer offensichtlich ist. Ausgehend davon, daß Adressen nur für Dozenten gespeichert werden, wurde auch direkt das Gehalt in die Tabelle Adressen und Gehalt verschoben, da auch nur Dozenten ein Gehalt beziehen. Marcus Börger 17

18 Datenbank Schemata Relationale Datenbanken Relationstyp 1 zu n Wenn es zu jedem Datensatz einer Tabelle mehrere zugehörige andere Datensätze einer anderen Tabelle geben kann, spricht man von einer 1 zu n Relation. Die 1 Seite bezeichnet man dann als Master- oder Referenztabelle und die andere als Detailtabelle. Dementsprechend werden die Werte in der Mastertabelle als Referenz- oder Key Werte bezeichnet. Die Werte der Detailtabelle werden Foreign Key Werte genannt. Beispiele hierfür sind Vorlesungen, denn jeder Professor soll mehrere Vorlesungen geben. Werden 1 zu n Relationen aus der anderen Richtung betrachtet, so werden sie zu n zu 1 Relationen. Außer der Bezeichnung und dem Betrachtungswinkel ändert sich jedoch nichts. Auch hierzu kann aus Abbildung 2.7: Relationstyp 1 zu 1 ein Beispiel erzeugt werden, indem man für Professoren sowohl Privatadresse, als auch Lehrstuhladresse angibt. In solchen Fällen empfiehlt es sich dann, die einzelnen Datensätze der n Seite der 1 zu n Relation unterscheiden zu können, am einfachsten durch einfügen einer Typ Spalte. In Abbildung 2.10: Relationstyp 1 zu n gibt es zu jedem Datensatz in Personen 2 beliebig viele Datensätze in Adresse 2. In diesem Beispiel sollte jeder Adreßtyp pro Person maximal einmal existieren, damit aus den Spalten PNr und AdrTyp ein eindeutiger Index für die Tabelle Adresse 2 gebildet werden kann. Personen 2 PNr PTyp Name Login Gehalt Datum 1 n = Adressen 2 PNr AdrTyp Straße PLZ Ort Land Abbildung 2.10: Relationstyp 1 zu n Relationstyp 1 zu c, c klein Manchmal begrenzt man die maximale Anzahl möglicher Relationen zu einem Datensatz, um die Relationen innerhalb der gleichen Tabelle speichern zu können, was die Abfragen wesentlich schneller macht. Häufiges Beispiel hierzu sind Adreßdaten. Oft reicht es vollkommen aus, Privatadresse und Firmenadresse zu speichern (1 zu 2). Dies veranschaulicht Abbildung 2.11: Mehrfache Felder vs. Relation mit der Tabelle Personen 3, die zwei Adreßfelder enthält (Adresse1, Adresse2). Die oben genannten Vorteile werden allerdings durch den Nachteil erkauft, daß man sehr unflexibel wird, was spätere Erweiterungen angeht. Außerdem wird Speicherplatz verschwendet, wenn selten alle Felder benötigt werden. Personen 3 PNr PTyp Name Adresse1 Adresse2 Login Gehalt Abbildung 2.11: Mehrfache Felder vs. Relation Datum Relationsauszeichnung Jede einzelne Beziehung, die aus einem Key Wert und einem Foreign Key Wert gebildet wird, kann ein Label bekommen das genau diese Beziehung beschreibt. Ein Label kann dabei entweder implizit bekannt sein oder es wird explizit abgespeichert. Damit für das Label keine neue Tabelle angelegt werden muß, kann es entweder aus der Zieltabelle hervorgehen, sofern unterschiedliche Referenztabellen möglich sind, oder es wird in der Detailtabelle abgelegt. Ein Beispiel für das getrennte Speichern eines Relationenlabels in der Detailtabelle ist das Feld AdrTyp in Abbildung 2.10: Relationstyp 1 zu n. 18 Marcus Börger

19 Relationale Datenbanken Datenbank Schemata Abbildung 2.12: Relation umgekehrt greift noch mal die Tabelle Personen 3 aus Abbildung 2.11: Mehrfache Felder vs. Relation auf. Hier werden die beiden Adressen allerdings in einer getrennten Tabelle gespeichert. Damit ist möglich, daß eine Adresse mehreren Personen zugeordnet wird. Die Lehrstuhladresse muß daher nicht für jeden Mitarbeiter getrennt abgespeichert werden. Andererseits ist ein implizites Label vorhanden, wenn Adresse1 immer die Privatadresse und Adresse2 immer die Firmenanschrift referenziert. Personen 3 PNr PTyp Name Privat Firma Login Gehalt 1 n = 1 n = Datum Adressen 3 ANr Straße Straße 2 PLZ Stadt Land Abbildung 2.12: Relation umgekehrt Relationen zu verschiedenen Tabellen Eine Tabelle kann von mehreren Tabellen referenziert werden und sie kann Relationen zu verschiedenen anderen Tabellen enthalten. Während der erste Fall unproblematisch ist, muß im zweiten Fall beachtet werden, daß eine Spalte keine Relation zu verschiedenen Tabellen realisieren kann, insbesondere kann dazu auch kein Label benutzt werden 4 (siehe Foreign Keys). Wenn für Privat/Firmenadressen getrennte Tabellen existieren, müssen auch getrennte Spalten für die verschiedenen Relationen benutzt werden. Haben die Zieltabellen die gleiche Struktur, können diese zu einer virtuellen zusammengefaßt werden (siehe 2.3 Views), dabei gehen ggf. Informationen verloren, hier die Unterscheidung zwischen Privat- und Firmenadresse. Sind diese Informationen abhängig vom Modell, wie die hier vorhandene Zuordnung von Adresse1 für Firmenadressen und Adresse2 für Privatadressen, so können sie in der virtuellen Tabelle eingeblendet werden. Personen 3 PNr PTyp Name Adresse1 Adresse2 Login Gehalt 1 n = 1 n = Datum Privatadressen Privat ANr Straße Straße2 PLZ Stadt Land Firmenadressen Firma ANr Straße Straße2 PLZ Stadt Land Alle Adressen AdrTyp ANr Straße Straße2 PLZ Stadt Land Abbildung 2.13: Relationen zu verschiedenen Tabellen 4 Das könnte zwar mit Triggern realisiert werden, das Ergebnis wäre jedoch kein relationales Datenmodell mehr. Marcus Börger 19

20 Datenbank Schemata Relationale Datenbanken Rekursion Es kommt vor, daß sich Tabellen selbst referenzieren. Solchen Relationen bilden also eine Rekursion. Dabei ist das Einfügen des ersten Wertes problematisch, wenn die Relation gesichert wird. Denn eine leere Tabelle enthält noch keinen zulässigen Wert für das Referenz Feld, da keine Werte für das referenzierte Feld vorhanden sind. Der Wert NULL muß für das Referenzfeld explizit erlaubt sein. Wenn ein Datenbank Managementsystem benutzt wird, daß die Relationen am Ende der Transaktion überprüft, kann auf NULL verzichtet werden. Ein Beispiel hierzu zeigt die Abbildung 2.14: Relationstyp 1 zu n mit Rekursion, in der die modifizierte Tabelle Personen 4 das neue Feld Chef enthält. Damit kann man Mitarbeitern einen Abteilungsleiter, Professoren einen Dekan und Studenten einen Mentor zuordnen. Wird ein Datensatz eingefügt, so muß der Wert für das Referenzfeld Chef bereits als Wert für das referenzierte Feld PNR in einem bestehenden Datensatz vorhanden sein. Personen 4 PNr PTyp Name Login Gehalt Datum Chef 1 n = Abbildung 2.14: Relationstyp 1 zu n mit Rekursion Relationstyp n zu m Eine weitere Klasse von Relationen sind die n zu m Relationen. Hierbei stehen jeweils beliebig viele Datensätze einer Tabelle mit beliebig vielen Datensätzen einer anderen Tabelle in Relation. Es wird nicht von n zu n Relationen gesprochen, da die Anzahl der in Relation zu einander stehenden Datensätzen in beiden Tabellen nicht identisch sein müssen. Bei den verschiedenen Modellen für Adressen trat das Problem auf, daß eine Person mehrere Adressen haben kann, aber eine Adresse auch für mehrere Personen gleich ist. Die bisherigen Lösungen konnten diesem Umstand nur Ansatzweise gerecht werden. Den günstigsten Kompromiß stellt Abbildung 2.12: Relation umgekehrt dar. Hier wird möglichst wenig Speicher genutzt, es gibt jedoch maximal zwei Adressen je Person. Ein weiteres Beispiel für n zu m Relationen stellt die Relation Studenten besuchen Vorlesungen dar. Diese Relation ist dadurch gekennzeichnet, daß sowohl eine Vorlesung von mehreren Studenten besucht wird, als auch ein Student mehrere Vorlesungen besucht. Diese Relationen sind nicht direkt in einer relationalen Datenbank darstellbar. Es sind hierzu zwei 1 zu n Relationen und eine weitere Tabelle notwendig. Die zwischengeschaltete Tabelle muß nicht Zwingenderweise auf die beiden Foreign Keys beschränkt sein. Da jeder Datensatz einer solchen Tabelle exakt einer Relation entspricht, kann man diese Relation in weiteren Spalten auszeichnen. Da n zu m Relation über drei Tabellen realisiert werden, ist der Zugriff darauf langsamer als der Zugriff auf zwei Tabellen, wie er bei Relationen der Form 1 zu n gegeben ist. Personen Name PNr besuchen PNr VNr 1 n = Veranstaltungen VNr VName m 1 = "Studenten besuchen Veranstaltungen" Name PNr VNr VName Abbildung 2.15: Relationstyp n zu m 20 Marcus Börger

21 Relationale Datenbanken Datenbank Schemata Das bisher verwendete Beispiel geht davon aus, daß eine Veranstaltung nur von einem Dozenten gelesen wird, es sieht also nicht den Fall vor, daß sich zwei Dozenten im Wechsel eine Veranstaltung teilen. Um das in der Datenbank zu speichern, wird in der Tabelle Veranstaltungen das Feld PNr entfernt. Denn die Lese Beziehung soll ja ersetzt werden. Es gibt hier nun zwei Möglichkeiten. Entweder wird aus der Tabelle besuchen in Abbildung 2.15: Relationstyp n zu m eine Tabelle "lesen und besuchen", indem man die einzelnen Beziehungen mit dem Wert liest oder besucht auszeichnet. Oder man zerlegt die Tabelle in eine Tabelle besuchen und eine Tabelle lesen wie es Abbildung 2.16: Doppelte n zu m Relation zeigt. In diesem Fall kommt man gänzlich ohne direktes Speichern der Information liest/besucht aus, denn diese Information ergibt sich implizit aus der Tabelle. Da man aber zwei Tabellen benutzt, sind natürlich auch alle Hilfsstrukturen wie Indizes und Keys doppelt vorhanden. Daher führt dieses Vorgehen selten zu Speicherersparnissen. Aber es kann einen anderen Gewinn bringen. Zum einen muß kein weiteres Feld ausgewertet werden, um die Art der Beziehung zu kennen. Zum anderen kann man die Zweiteilung nutzen, um den Zugriff auf eine der beiden Tabellen zu Beschleunigen, wenn eine der beiden Tabellen wenige Einträge enthält aber häufig benötigt wird. Größere RDBMS bieten oft Möglichkeiten Einfluß auf die Zugriffsgeschwindigkeit zu nehmen, meist auf Kosten von Speicherplatz. Personenen Name PNr 1 n = besuchen PNr VNr n 1 n = = 1 PNr lesen VNr n 1 = Veranstaltungen VNr VName "Studenten besuchen Veranstaltungen" Name PNr VNr VName "Dozenten lesen Veranstaltungen" Name PNr VNr VName Abbildung 2.16: Doppelte n zu m Relation Eine weitere Alternative ist es, die Tabelle Personen in Studenten und Dozenten aufzuteilen. Hierbei geht im Beispiel dann allerdings die Möglichkeit verloren, daß ein Dozent auch eine Veranstaltung besuchen kann, es sei denn man legt für ihn zwei Datensätze an. Es entstehen auch bei dieser Lösung wieder zwei n zu m Relationen, da es nicht erlaubt ist eine Relation zu zwei verschiedenen Tabellen herzustellen. Insbesondere kann hierzu auch kein Label benutzt werden. Studenten Name PNr 1 n = besuchen PNr VNr n 1 = Veranstaltungen VNr VName 1 n = lesen VNr PNr n 1 = Dozenten PNr Name "Studenten besuchen Veranstaltungen" Name PNr VNr VName Abbildung 2.17: Parallele n zu m Relationen "Dozenten lesen Veranstaltungen" VName VNr PNr Name Marcus Börger 21

22 Datenbank Schemata Relationale Datenbanken Keys Wie bereits in Indizes erwähnt, sind eindeutige Indizes in der Lage Datensätze zu identifizieren, daher nennt man sie auch Datensatzschlüssel oder kurz Schlüssel, im Englischen also Keys. Keys spielen in Relationalen Datenbanken eine wichtige Rolle, da über sie die Relationen definiert werden Primary Keys In relationalen Datenbanken ist jeder Datensatz eindeutig gekennzeichnet. Diese eindeutige Kennzeichnung wird durch den Primary Key realisiert. Man kann ihn entweder als Teil einer Tabelle definieren oder von der Datenbank generieren lassen. Letzteres passiert genaugenommen immer dann, wenn kein Primary Key explizit definiert wird. In fast allen Datenbanken legt der Primary Key zusätzlich fest, daß seine Werte nicht NULL sein dürfen. Ohne diese Festlegung darf NULL als Wert des Primary Keys dann exakt einmal in der Tabelle vorhanden sein. Wird der Primary Key bei der Modellierung hingegen explizit definiert, so kann er über einem oder mehreren Attributen definiert sein. Ein weiterer Index ist für diese Attributkombination nicht mehr notwendig, da der Primary Key immer auch ein Index ist. Es empfiehlt sich den Primary Key möglichst kurz zu definieren, um den Zugriff auf ihn zu beschleunigen. Da alle Tabellenzugriffe über den Primary Key abgewickelt werden, beschleunigt man so alle Zugriffe auf die zugehörige Tabelle. Es gibt verschiedene Möglichkeiten Primary Keys zu erzeugen: Attribute einer Tabelle sind häufig bereits eindeutig (siehe auch Anerkannte Standards). Wenn die einzelnen Werte jetzt noch wenig Platz zur Speicherung benötigen so eignen sie sich besonders. Jedem Datensatz wird eine eindeutige Zahl zugewiesen. Hierzu gibt es von vielen Datenbanken Unterstützung. Einige Datenbanken bieten sogenannte Autoinkrement Werte an, die bei jedem neuen Datensatz um den Wert 1 erhöht werden. Nachteilig ist dabei, daß es einen weiteren eindeutigen Schlüssel geben muß, um den Datensatz nach dem ersten einfügen in der Tabelle finden zu können. Andere Datenbanken bieten sogenannte Sequences, die bei jedem Zugriff eindeutige Werte liefern können. Wird in der gesamten Anwendung nur eine Sequence genutzt, so hat das den Nachteil, daß es das System verlangsamen kann, bei Systemen, die seltener neue Datensätze anlegen, lassen sich so Systemweit eindeutige Primary Keys generieren. Eine besondere Stellung nimmt hier PostgreSQL ein, da hier Autoinkrement Werte durch Sequences realisiert werden, die automatisch angelegt werden. Bei den Verknüpfungstabellen von n zu m Relationen werden beide Foreign Keys zu einem Primary Key zusammengefaßt (siehe auch Relationstyp n zu m und Foreign Keys). Oft finden bei der Erzeugung von Datensätzen Algorithmen Verwendung, die bereits eindeutige Werte generieren, die als Primary Key genutzt werden können. Manche Betriebssysteme/APIs bieten Funktionen, die eindeutige Werte generieren. Diese sind oft weltweit eindeutig, meist jedoch relativ lang. Die Verbindung von Foreign Keys und einem weiteren Typfeld wird ebenfalls häufig als Primary Key genutzt. In Abbildung 2.10: Relationstyp 1 zu n könnten die Spalten PNr und AdrTyp den Primary Key bilden. 22 Marcus Börger

23 Relationale Datenbanken Datenbank Schemata Intern dient der Primary Key wie bereits erwähnt dem Auffinden der Datensätze. Dabei werden im Primary Key die Positionen der einzelnen Datensätze innerhalb der Tabelle gespeichert. Wenn die Länge der Datensätze variabel ist, so wird auch die Länge der einzelnen Datensätze gespeichert. Dadurch ist es möglich eine Tabelle linear in einer Datei abzulegen und außerdem können Lücken innerhalb der Datendatei aufgefunden und ggf. mit neuen Datensätzen aufgefüllt werden. Bei Datensätzen mit konstanter Länge ist das Speichern der Länge der einzelnen Datensätze natürlich nicht erforderlich. Im folgenden werden Systeme betrachtet, die den Primary Key in einer eigenen Datenstruktur Speichern. Die folgende Abbildung 2.18: Primary Key zeigt den Primary Key, dessen Spalte Position auf die jeweiligen Datensätze in der Tabelle Veranstaltungen zeigt. Die Spalte Datensatz dient hier nur der Übersicht und repräsentiert die Reihenfolge in der die Datensätze eingefügt wurden, sie ist in einem realen DBMS nicht erforderlich. Allerdings verwenden Reale DBMS oft zusätzliche Felder in den Datensätzen und den Primary Key Listen, die für interne Tabellenreorganisationen benutzt werden. Im Beispiel sind die Längen der Datensätze nicht angegeben, da sie hier nicht von Interesse sind: Primary Key Datensatz Position Länge???? Abbildung 2.18: Primary Key Die Abbildung 2.18: Primary Key läßt noch nicht ganz den Sinn der Datensatzidentifikation über den Primary Key erkennen, da die Datensätze innerhalb der Tabelle Veranstaltungen nach den Werten VNR, also den Primary Key Werten sortiert sind. In der nächsten Abbildung wurden die Datensätze in einer anderen Reihenfolge eingegeben. Daher stimmt die Reihenfolge in der Tabelle nicht mehr mit der Reihenfolge überein, die sich aus den Primary Key Werten ergibt: Primary Key Datensatz Position Länge???? Abbildung 2.19: Primary Key bei ungeordneter Tabelle Als nächstes folgt die Einbeziehung eines Index. Dieser enthält nun nur noch Verweise auf die Position im Primary Key. Wird etwa der Datensatz Nummer drei im Index VZeit, VOrt benötigt, so wird zunächst die Position im Primary Key gelesen. Nach Lesen der Position aus dem Primary Key kann dann der Datensatz innerhalb der Tabelle gelesen werden. Index D.S. Pos Primary Key Pos. L ???? Abbildung 2.20: Primary Key und Index (VZeit, VOrt) Veranstaltungen PNr VName VZeit Indizes und Keys können in einer Tabelle gespeichert werden, denn sie benutzen Datenstrukturen fester Länge. Die Position einzelner Index/Keywerte läßt sich also mittels der Multiplikation Datensatznummer * Datensatzlänge berechnen. Daher benötigen DBMS keine weitere Organisationsform. Der Zugriff auf einen Datensatz über einen Index bewirkt intern also den Zugriff auf drei Tabellen. VNr VOrt Einführung Mo, 10:00 H Modellierung Di, 12:00 H SQL-DDL Mo, 10:00 H SQL-DML Di, 10:00 H1 VNr Veranstaltungen PNr VName VZeit VOrt Einführung Mo, 10:00 H SQL-DML Di, 10:00 H Modellierung Di, 12:00 H SQL-DDL Mo, 10:00 H3 VNr Veranstaltungen PNr VName VZeit VOrt Einführung Mo, 10:00 H SQL-DML Di, 10:00 H Modellierung Di, 12:00 H SQL-DDL Mo, 10:00 H3 Marcus Börger 23

24 Datenbank Schemata Relationale Datenbanken Foreign Keys Eine sehr wichtige Rolle im Zusammenhang mit Relationen spielen Foreign Keys. Sie legen fest, auf welchen Key in welcher Tabelle sich die Werte einer Spalte beziehen. Man sagt hierzu auch, daß ein Foreign Key einen Key einer anderen Tabelle referenziert (siehe Referenzielle Integrität). Berücksichtigt die Datenbank das Konzept Foreign Key vollständig, so können als Werte für Spalten, die als Foreign Key definiert sind, nur solche benutzt werden, die in der referenzierten Tabelle vorhanden sind oder aber der Wert NULL. In einigen Datenbanken beziehen sich Foreign Keys immer auf den Primary Key der referenzierten Tabelle. Immer jedoch bezieht sich ein Foreign Key aber auf exakt eine Tabelle. Daher werden in Abbildung 2.17: Parallele n zu m Relationen auch die beiden Tabellen lesen bzw. besuchen benötigt. Unterstützt die Datenbank auch Constraints, so ist es möglich dafür zu sorgen, daß Relationen zwischen Datensätzen, die über Foreign Key Beziehungen bestehen gesichert werden. Sicherung bedeutet hierbei, daß die Datenbank die Konsistenz der Daten bezüglich dieser Relation gewährleistet. Hierzu kann beim Erzeugen der zugehörigen Tabellen bereits festlegt werden, wie sich die Datenbank verhalten soll, wenn durch eine Aktion die Konsistenz verletzt wird. Es gibt dabei unter anderen die beiden Möglichkeiten kaskadierendes Löschen und Abbrechen. Wird für einen Foreign Key kaskadierendes Löschen eingestellt, so werden vor dem Löschen eines Key Wertes alle Datensätze gelöscht, die diesen Wert als Foreign Key benutzen Alternate Keys Jeder weitere eindeutige Index wird auch als Alternate Key bezeichnet. Einige Datenbank Management Systeme erlauben es Relationen über Alternate Keys zu definieren. Das macht einige Aufgaben zwar einfacher oder besser verständlich, notwendig ist das jedoch nicht. Denn bei jedem Zugriff über den Primary Key stehen alle Felder beider beteiligten Tabellen zur Verfügung, insbesondere auch die Alternate Key Felder Anerkannte Standards Der Modellierung einer Datenbank sollte immer eine gründliche Analyse der zu speichernden Daten vorausgehen. Wenn hierbei Standards auftauchen, so ist es immer empfehlenswert diese möglichst ohne Änderung zu verwenden. Innerhalb einer Adreßdatenbank wird so zum Beispiel auch das Land zu jeder Adresse gespeichert. Hierzu gibt es die Norm ISO 3166 [ISO3166], die Ländercodes und Ländernamen international eindeutig festlegt. Die vorgenannte Norm ist im Internet als Textdatei verfügbar und läßt sich mittels einfacher Konvertierungen in eine Datenbank einlesen. Danach reicht es zu jeder Adresse den Ländercode zu speichern. Als Ergebnis erhält man weltweit eindeutige und gültige Ländernamen Referenzielle Integrität Bei der referenziellen Integrität geht es um die implizite Kontrolle und Steuerung von Referenzen durch das Datenbank Management System. Sind alle Foreign Key Werte einer Tabelle dereferenzierbar, daß bedeutet es existieren die referenzierten Werte in der referenzierten Tabelle, so gilt die Relation, die durch den Foreign Key bestimmt ist, als integer. Gilt das für alle Relationen einer Datenbank, so ist die referenzielle Integrität der Datenbank gewährleistet, andernfalls ist sie verletzt. Es sei hier nochmals auf Constraints hingewiesen, die eine Methode zur automatischen Überwachung und Gewährleistung der referenziellen Integrität bereitstellen. Sie übernehmen die im folgenden beschriebenen naheliegenden Konzepte. 24 Marcus Börger