MS SQL Server Einstieg in relationale Datenbanken und SQL Marco Skulschus Marcus Wiederstein

www.comelio-medien.com MS SQL Server Einstieg in relationale Datenbanken und SQL Marco Skulschus Marcus Wiederstein

MS SQL Server Einstieg in relationale Datenbanken und SQL Marco Skulschus Marcus Wiederstein Webseite zum Buch: Comelio Medien 2011

Alle Rechte vorbehalten. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jeder Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für die Vervielfältigung, Übersetzung, Mikroverfilmung und die Einspeicherung und Verbreitung in elektronischen Systemen. Comelio GmbH Comelio GmbH Goethestr. 34 D-13086 Berlin Fon: +49 (0) 30-8 14 56 22-00 Fax: +49 (0) 30-8 14 56 22-10 www.comelio-medien.com info@comelio.com Umschlaggestaltung, Comelio-Grafiken, Layout & Satz: Nadine Kilian ISBN 978-3-939701-52-1

Inhaltsverzeichnis Inhaltsverzeichnis 1. Grundlagen 11 1. 1. Beispiel-System MS SQL Server 11 1. 1. 1. Installation 11 1. 1. 2. Management Studio 14 1. 1. 3. Abfragen direkt ausführen 16 1. 2. Beispieldatenbank AdventureWorks 17 1. 2. 1. Personaldaten 17 1. 2. 2. Produktdaten 18 1. 2. 3. Verkaufsdaten 19 1. 3. Das relationale Modell 19 1. 3. 1. Grundbegriffe des relationalen Modells 19 1. 3. 2. Semantisches Modell 20 1. 3. 3. Eigenschaften von Daten 21 1. 3. 4. Klassifikation von Datentypen 23 1. 3. 5. Beziehungen zwischen Daten 24 1. 3. 6. Entity-Relationship-Modell 27 1. 3. 7. Normalisierung mit Normalformen 29 1. 3. 8. DB-Anomalien 34 1. 4. Das relationale Datenbank-System 35 1. 4. 1. Zentrale Begriffe 35 1. 4. 2. Sichten auf ein relationales Datenbanksystem 37 1. 4. 3. Anforderungen an ein DBMS 38 1. 4. 4. Bestandteile einer Tabelle 38 1. 4. 5. Inhalte einer relationalen Datenbank 39 1. 4. 6. Architektur-Muster beim Einsatz relationaler Datenbanken 40 1. 5. SQL Structured Query Language 42 1. 5. 1. Sprachbestandteile 43 1. 5. 2. Ursprung: Relationale Algebra 43 2. Einfache Abfragen 47 2. 1. Grundstruktur von SELECT 47 2. 1. 1. Spaltenauswahl 48 2. 1. 2. Aliasnamen 48 2. 1. 3. Qualifizierte Spaltennamen 49 2. 2. Bedingungen 50 2. 2. 1. Einfache Bedingungen und Operatoren 50 2. 2. 2. Boolesche Operatoren 52 2. 2. 3. Mathematische Operatoren 55 2. 2. 4. Mengen-Operatoren 57 2. 3. Ergebnisse aufbereiten 60 2. 3. 1. Duplikate ein-/ausblenden 60 2. 3. 2. Ergebnisse sortieren 61 2. 3. 3. Standard-Aggregate 62 2. 3. 4. Gruppieren 64 3

Inhaltsverzeichnis 3. Komplexe Abfragen 68 3. 1. Verknüpfungen 68 3. 1. 1. Manuelle Verknüpfungen 68 3. 1. 2. ANSI-SQL-Verknüpfungen 71 3. 2. Unterabfragen 77 3. 2. 1. Einfache Unterabfragen 77 3. 2. 2. Spaltenunterabfragen 79 3. 2. 3. Abgeleitete Tabellen 80 3. 2. 4. Korrelierte Unterabfragen 83 3. 2. 5. Operatoren für Unterabfragen 85 3. 3. Verzweigungen 87 3. 3. 1. CASE mit Selektor 87 3. 3. 2. Selektorlose CASE-Anweisung 89 4. Datenmanipulation 92 4. 1. Datenstrukturen anlegen 92 4. 1. 1. Tabellen grafisch anlegen 92 4. 1. 2. Tabellen mit SQL erstellen 97 4. 1. 3. Tabellen und ihre Eigenschaften ändern 102 4. 1. 4. Sichten 104 4. 1. 5. Datentypen 107 4. 1. 6. Indizes 109 4. 2. Daten bearbeiten 109 4. 2. 1. Vorbereitung 109 4. 2. 2. Einfügen 111 4. 2. 3. Aktualisieren 113 4. 2. 4. Löschen 115 4. 3. Objekte verwalten 117 4. 3. 1. Katalogsichten für Objekte 117 4. 3. 2. Funktionen 119 5. Grundlagen T-SQL 123 5. 1. T-SQL Blöcke 123 5. 1. 1. SQL als Programmiersprache 123 5. 1. 2. Variablen und Anweisungen 123 5. 2. Kontrollanweisungen 125 5. 2. 1. Fallunterscheidungen 125 5. 2. 2. Schleifen 126 5. 3. Fehlerbehandlung 127 5. 3. 1. Ausnahmen 127 5. 3. 2. Traditionelle Fehlerbehandlung 129 5. 4. Cursor 130 5. 4. 1. Deklaration 130 5. 4. 2. Verwendung 131 5. 4. 3. Beispiele 133 5. 5. Transaktionen 136 5. 5. 1. Einfache Transaktionen 136 5. 5. 2. Sicherungspunkte 139 5. 5. 3. Erweiterte Transaktionssteuerung 139 6. Programm-Module in der DB 142 6. 1. Prozeduren 142 4

Inhaltsverzeichnis 6. 1. 1. Einführung 142 6. 1. 2. Prozedurarten 145 6. 1. 3. Parameter und Aufruf 147 6. 2. Funktionen 150 6. 2. 1. Skalare Funktionen 151 6. 2. 2. Tabellenwertfunktion 152 6. 3. Trigger 156 6. 3. 1. Grundlagen 156 6. 3. 2. DML-Trigger 157 6. 3. 3. DDL-Trigger 161 6. 3. 4. Weitere Optionen 164 7. Administration 166 7. 1. Sicherheit 166 7. 1. 1. Allgemeine Überlegungen zur Sicherheit 166 7. 1. 2. Datensicherheit 168 7. 1. 3. Zugriffskontrolle 168 7. 1. 4. Rollen 171 7. 1. 5. Benutzer verwalten 171 7. 1. 6. Rechte verwalten 173 7. 1. 7. Rechte kaskadierend weitergeben 174 7. 1. 8. Sicherheit von Prozeduren, Funktionen und Trigger 176 7. 2. Sicherung und Wiederherstellung 179 7. 2. 1. Datensicherung 179 7. 2. 2. Wiederherstellung von Datenbanken 181 7. 2. 3. DB-Zustand 182 5

Vorwort

Vorwort Vorwort Herzlich willkommen zu einem Fachbuch von Comelio Medien, einem Unternehmensbereich der Comelio GmbH. Wir hoffen sehr, dass Sie mit der Darstellung und Aufbereitung dieses Einstiegs in SQL und relationale Datenbanken am Beispiel von MS SQL Server zufrieden sind und die für Ihren Berufsalltag wesentlichen Themen finden. Zu dieser Reihe Dieses Buch gehört zu einer Gruppe von verschiedenen Büchern bei Comelio Medien im Bereich relationale Datenbanken und Microsoft SQL Server. Sie umfasst Themen, welche bei der Verwendung als Programmierer und Administrator wichtig sind. Die Reihe enthält folgende Themen: Abfragen von relationalen Datenbanken mit T-SQLund PL/SQL und Programmierung von Prozeduren, Funktionen und Triggern MS SQL Server: T-SQL-Programmierung und Abfragen, ISBN 978-3-939701-02-6, http:// www.comelio-medien.com/buch-katalog/ms_sql_server/t-sql Oracle PL/SQL, ISBN 978-3-939701-40-8 http://www.comelio-medien.com/buch-katalog/oracle/oracle_pl_sql Oracle SQL, ISBN 978-3-939701-41-5, http://www.comelio-medien.com/buch-katalog/ oracle/oracle_sql Erzeugen von XML aus Oracle- und MS SQL Server-Daten sowie deren Verarbeitung MS SQL Server: XML und SOAP Webservices - ISBN 978-3-939701-03-3, http://www.comelio-medien.com/buch-katalog/ms_sql_server/xml Oracle, PL/SQL und XML, ISBN 978-3-939701-10-1, http://www.comelio-medien.com/ buch-katalog/oracle/oracle_und_xml Autoren Die beiden Autoren Marco Skulschus und Marcus Wiederstein blicken bereits auf zahlreiche Bücher zu Themen rund um Programmierung und auch Datenbanken zurück. Bei der Comelio GmbH sind sie im Bereich Softwareentwicklung als Projektleiter und auch als Dozenten tätig und stellen mit Hilfe der Veröffentlichungen ihre Erfahrungen im Bereich der Softwareentwicklung einem breiteren Publikum zur Verfügung. Dies geschieht auch im Bereich Weiterbildung, der von der Comelio GmbH im gesamten deutschsprachigen Raum angeboten wird. Marco Skulschus (Jahrgang 1978) studierte Ökonomie in Wuppertal und Paris. Er setzt C# und den MS SQL Server für Kundenprojekte ein. Nichtsdestoweniger ist er auch in anderen Themenbereichen wie 7

Vorwort Oracle/Java aktiv. Insbesondere der Themenbereich Datenbanken, Datenmodellierung und XML steht an erster Stelle. Seine Spezialthemen sind Ontologien auf Basis von OWL (Web Ontology Language). Marcus Wiederstein (Jahrgang 1971) studierte Elektrotechnik in Bochum und Dortmund. Er beschäftigt sich nicht nur mit Softwareentwicklung auf Basis von Microsoft-Technologien, sondern auch mit der Administration von Microsoft-Servern. Seine speziellen Interessengebiete sind die Sicherheit und die Planung von sicheren Anwendungsstrukturen. Marco Skulschus und Marcus Wiederstein haben zusammen bereits viele Bücher zu XML sowie zu Datenbanken herausgebracht. Darüber hinaus haben sie unterschiedliche Zertifizierungen von Microsoft und Oracle erworben. Aufbau des Buchs 1. Das erste Kapitel beschreibt zunächst Grundlagen zur Arbeitsumgebung. Es beschreibt bspw. kurz die Installation der Datenbank, den Umgang mit dem grafischen Werkzeug Management Studio sowie die Beispieldatenbank AdventureWorks. In der zweiten Hälfte des Kapitels lernen Sie die wesentlichen Prinzipien von relationalen Datenbanken kennen. Diese umfassen die Themen der Datenmodellierung mithilfe des Entity-Relationship-Modells, den Prozess der Normalisierung, den Aufbau von relationalen Datenbanksystemen und eine allgemeine Einführung in das relationale Modell. 2. Das zweite Kapitel stellt Standard-SQL am Beispiel vom MS SQL Server und vor allen Dingen der AdventureWorks-Datenbank vor. Dabei beginnt es mit einfachen Standardabfragen und arbeitet sich dann durch die typischen Bereiche wie Filtern, Sortieren und Gruppieren, die nicht nur mit dem MS SQL Server, sondern mit jeder Datenbank möglich sind. Es stellt anschließend die verschiedenen Standard-SQL-Funktionen für Aggregate und damit für Datengruppierungen vor. 3. Das dritte Kapitel konzentriert sich auf die Darstellung von so genannten komplexen Abfragen. Dies bedeutet zunächst, dass man die Daten nicht nur aus einer einzigen Tabelle abruft, sondern mehrere Tabellen miteinander über ihre Primärschlüssel-Fremdschlüssel-Verknüpfung verbinden muss. Hier stellt das Kapitel die traditionelle Variante den neuen, so genannten ANSI-SQL-Verknüpfungen gegenüber. Eine zweite Stufe hinsichtlich der Verwendung von komplexen Abfragen ist dann der Einsatz von Unterabfragen. Hier folgt eine Darstellung von einfachen Unterabfragen, Spaltenunterabfragen, abgeleiteten Tabellen und korrelierten Unterabfragen. Die verschiedenen Techniken sind in vielen Datenbanken gleich oder wenigstens ähnlich nutzbar. Schließlich folgt noch die Darstellung, wie man Fallunterscheidungen über die CASE-Anweisung in SQL realisiert und wie zusätzliche Aggregate errechnet werden können. Darunter sind Rangfolgen, Untersummen und Würfel zu verstehen. 4. Das vierte Kapitel arbeitet die Bereiche der Einrichtung von Datenstrukturen und der Datenmanipulation durch. In einem ersten Teil erstellt man über SQL die Datenstrukturen für Tabellen und Sichten. In einem zweiten, umfangreicheren Teil werden dann für verschiedene vereinfachte Tabellen der Beispieldatebank die typischen Bearbeitungsszenarien von Datenerfassung, -bearbeitung, -aktualisierung und -löschung vorgestellt. 5. Das fünfte Kapitel bietet schließlich eine übersichtliche Einführung in die SQL-Erweiterung von MS SQL Server mit dem Namen Transact SQL (T-SQL). Zwar gibt es in einigen vorherigen Kapiteln bereits verschiedene Beispiele, die mit einfachen Mitteln von T-SQL operieren, doch die Erstellung von Variablen, die Verwendung und die Auswahl von geeigneten Datentypen, die Erstellung und Nutzung von Cursorn sowie schließlich auch die Erstellung von Prozeduren und Funktionen ist den 8

Vorwort einzelnen Abschnitten dieses fünften Kapitels vorbehalten. T-SQL steht hier als Beispiel für andere SQL-Erweiterungen wie sie in Oracle oder IBM DB2 zu finden sind. 6. Das sechste Kapitel erweitert die Möglichkeiten der Programmierung in der Datenbank und zeigt, wie man für einfache Administration oder die Anwendungsentwicklung Module in der Datenbank erstellt. Jeweils werden Funktionen, Prozeduren und Trigger theoretisch und mit praktischen Beispielen vorgestellt. 7. Das siebte Kapitel schließt das Buch dann mit einigen administrativen Themen ab. Hier sollen nicht MS SQL Server-spezifische Themen behandelt werden, sondern Bereiche wie Benutzer, Rollen und Rechte sollen stattdessen anhand von allgemeinen Beispielen präsentiert werden. Neben dem Thema Sicherheit enthält dieses Kapitel auch Erläuterungen und entsprechende SQL-Skripte für Daten-Sicherung und Wiederherstellung. Beispieldateien Das Beispiel-Datenbank-System ist MS SQL Server, von der auch eine Test-Version und eine kostenlose so genannte Express-Version vorliegen. Als Beispiel-Datenbank dient die sehr umfangreiche Datenbank AdventureWorks, welche im ersten Kapitel kurz eingeführt und vorgestellt wird. Die Datenbank kann sehr leicht zusätzlich installiert und kostenlos aus dem Internet herunter geladen werden. Die verschiedenen Abfragen und Programmdateien, welche in diesem Buch erstellt und diskutiert werden, liegen ebenfalls im Internet zum Download bereit. Die einzelnen Quelltexte sind vollständig dokumentiert und enthalten neben dem eigentlichen Quelltext auch in einem Kommentarbereich die Ergebnisse. Dies ermöglicht es, die Dateien auch ohne Testen vollständig zu verwenden. Die Beispiel-Skripte und auch Seminar-Folien für den Unterrichtseinsatz oder das Selbststudium finden Sie unter. Kontakt zu den Autoren Sie erreichen das Sekretariat der Autoren unter der E-Mail-Adresse info@comelio.com. Von dort werden Ihre Emails dann weitergeleitet. Die Webseite des Verlags finden Sie unter der Adresse http:// www.comelio-medien.com, während Sie auf der Unternehmenswebseite folgende weitere Informationen finden: SQL-Artikel: http://www.comelio-medien.com/comelio-blog Kurzreferenzen: http://www.comelio-medien.com/leserservice/kurz-referenzen Auch in der realen Welt ist der Verlag zu erreichen. Die Hauptzentrale befindet sich in Berlin, Deutschland. Comelio GmbH, Goethestr. 34, D-13086 Berlin 9

Grundlagen

1. Grundlagen 1. Grundlagen Dieses Kapitel führt im ersten Teil in die Arbeitsumgebung und kurz in das Beispiel-System sowie die Beispiel-Datenbank ein. Im zweiten Teil präsentiert es die wesentlichen Prinzipien und Aspekte der relationalen Modellierung und die Theorie von relationalen Datenbanken. 1. 1. Beispiel-System MS SQL Server Für dieses Buch setzen wir als Beispiel-System den Microsoft SQL Server ein. Er zählt zu den am häufigsten eingesetzten Datenbanksystemen der Welt. Grundsätzlich ist die Installation des MS SQL Servers recht einfach, solange nur Testzwecke oder reine Anwendungsentwicklung betroffen ist und nicht etwa der Aufbau eines realistischen Systems. Der MS SQL Server ist in unterschiedlichen Varianten erhältlich. Im Normalfall interessiert man sich am Anfang für die Testversion, die 180 Tage gültig ist oder die Developer Edition, da beide Versionen den vollen Umfang der Datenbank bieten. Zusätzlich ist auch noch eine MS SQL Server Express Edition verfügbar, welche die Datenbankgröße auf 4 Gigabyte und maximal eine CPU sowie bis zu 1 GB Arbeitsspeicher unterstützt. Sie ist für die kostenlose Weiterverteilung und Einbettung in Anwendungen gedacht. Für die Beispiele verwenden wir die Developer-Version, wobei Sie bei einem Test zuhause oder in der Firma auf die angesprochene 180-Tage-Testversion zurückgreifen können. 1. 1. 1. Installation Folgende Schritte sind für eine Standardinstallation notwendig: 11

1. Grundlagen Abbildung 1.1: Installation (1) 12

1. Grundlagen Abbildung 1.2: Installation (2) 13

1. Grundlagen Abbildung 1.3: Installation (3) 1. 1. 2. Management Studio Die Steuerung des Systems erfolgt über die Sprache SQL, die Sie in diesem Buch kennen lernen werden, und die Desktop-Anwendung SQL Server Management Studio vorgestellt wird. 14

1. Grundlagen Abbildung 1.4: Management Studio Starten Das Management Studio ist die zentrale Anlaufstelle für die Arbeit mit dem MS SQL Server. Starten Sie das Programm, indem Sie unter Start / Programme / Microsoft SQL Server / SQL Server Management Studio auswählen. Auf der linken Seite des sich öffnenden Fensters befindet sich der so genannte Objekt-Explorer, der die Objekte des Servers anzeigt. Dies sind zunächst die Datenbanken selbst, gefolgt von weiteren Bereichen wie Sicherheit, Verwaltung, unterschiedliche Dienste und Datensicherung. Abbildung 1.5: Objekt-Explorer einer Datenbank 15

1. Grundlagen 1. 1. 3. Abfragen direkt ausführen Das Management Studio bietet die Möglichkeit, über einen einfachen Texteditor Abfragen an die Datenbank zu senden. Selbstverständlich gibt es dazu auch eine große Anzahl an grafischen Werkzeugen für die Erstellung von Abfragen, Manipulation von Daten oder Verwaltung von DB-Objekten. Mehr über die Beispieldatenbank und wo Sie sie beziehen, erfahren Sie im nächsten Abschnitt. 1. Um eine Abfrage oder allgemein eine DB-Anweisung auszuführen, wählen Sie die Schaltfläche Neue Abfrage. 2. In der Auswahlliste, welche die verschiedenen Datenbanken enthält, die gerade innerhalb des Datenbankservers enthalten sind, wählen Sie die AdventureWorks-Datenbank aus, da die Anweisung in dieser DB ausgeführt werden soll. 3. Tragen Sie dann Ihre SQL-Anweisungen wie bspw. SELECT * FROM Production.Product in das sich öffnende Textfenster ein. 4. Wählen Sie die Ausführen-Schaltfläche oder drücken Sie die F5-Taste. 5. Das Ergebnis erscheint standardmäßig in der so genannten Raster-Ansicht (engl. Grid View) im Bereich Ergebnisse. Zusätzliche Meldungen oder natürlich Fehlermeldungen erscheinen dagegen im Bereich Meldungen. Um eine Folge von SQL-Anweisungen wie bspw. eine Abfrage, die Sie später noch einmal ausführen wollen, als Textdatei zu speichern, wählen Sie Datei / SQL1Query.sql speichern oder Datei / SQL1Query.sql speichern als... aus. Die Endung der Datei ist für die Funktionstüchtigkeit der Datei bedeutungslos, d.h. die Endung.txt wäre genauso sinnvoll. Allerdings können Sie die.sql-endung mit dem Management Studio verknüpfen und sie ist die gebräuchliche Endung für Datenbankanweisungen. Eine solchermaßen gespeicherte Datei lässt sich dann über Datei / Öffnen wieder laden und zur Ausführung bringen. Abbildung 1.6: Ausführen einer Abfrage 16

1. Grundlagen 1. 2. Beispieldatenbank AdventureWorks Die Beispiel-Datenbank ist in unterschiedliche Schemata (Bereiche) eingestellt, die mit ihren wesentlichen Tabellen im nachfolgenden kurz vorgestellt werden. Es werden in diesem Buch aus Gründen der Übersichtlichkeit nicht alle Tabellen genutzt. Der Umfang der gesamten Datenbank wäre dafür ein wenig zu groß. Das Thema der Datenbank ist die fiktive Firma AdventureWorks, welche Fahrräder produziert und weltweit per Internet oder lokale Läden vertreibt. Die Datenbank erhalten Sie in verschiedenen Versionen unter http://msftdbprodsamples.codeplex. com/. Der Installationsprozess ist einfach und richtet die Datenbanken auch sofort ein. 1. 2. 1. Personaldaten Innerhalb der Personaldaten werden die Angestellten in einer Employee-Tabelle gespeichert. Sie arbeiten in einer Abteilung, die in einer Department-Tabelle dargestellt ist. Da ein Angestellter nicht notwendigerweise permanent in der gleichen Abteilung arbeitet, sondern von Zeit zu Zeit auch wechselt, ist keine direkte Beziehung zwischen Department und Employee vorhanden, sondern stattdessen eine Beziehungstabelle EmployeeDepartmentHistory eingefügt, welche insbesondere den Eintritt in eine neue Abteilung und den möglichen Austritt enthält. Darüber hinaus arbeiten die Mitarbeiter in Schichten, wobei die Schichteinteilung in der Shift-Tabelle angegeben ist. Betreten Sie eine Abteilung werden sie ebenfalls zu einer Schicht zugeordnet, sodass in der erwähnten EmployeeDepartmentHistory-Tabelle auch eine Verknüpfung zu dieser Shift-Tabelle existiert. Abbildung 1.7: Schema HumanResources Die Kontaktdaten aller Objekte des modellierten Weltausschnitts, die Kontaktdaten aufweisen können, sind zentral in zwei Tabellen gespeichert. Die Contact-Tabelle enthält die allgemeinen persönlichen Daten wie Vorname, Nachname etc. Die Address-Tabelle dagegen enthält Adressinformationen mit Straße, Stadt und PLZ. Für beide Tabellen existieren dann auch noch jeweils zwei Type-Tabellen, d.h. eine Tabelle namens ContactType und eine AddressType-Tabelle, durch die die jeweiligen Datensätze kategorisiert werden können. Länder und allgemeine geografische Bereiche, die außerhalb von konkreten Adressen liegen bzw. die wie Wertelisten angesehen werden können, sind dann in verschiedenen weiteren Tabellen untergebracht. Dies sind solche Tabellen wie CountryRegion oder State- Province. 17

1. Grundlagen Abbildung 1.8: Schema Person 1. 2. 2. Produktdaten Die Produkte werden im Schema Production in eine Vielzahl von Tabellen eingeteilt. Davon werden in den Beispielen in diesem Buch nicht alle verwendet, da die Gesamtzahl der Informationen nicht für alle Beispiele didaktisch wertvoll ist, sofern man nicht gerade ein Beispiel benötigt, um zehn Tabellen zu verknüpfen. Die zentrale Tabelle ist Product, in der die wesentlichen Informationen eines Produkts wie Nummer, Bezeichnung, Farbe, Sicherheitsbestand im Lager, Standardkosten und Listenpreis enthalten sind. Für die beiden Attribute Größe und Verkaufseinheit gibt es ausgelagerte Tabellen mit Wertelisten. Kunden bewerten die Produkte in einer ProductReview-Tabelle. Fotos zu den Produkten speichert die Tabelle ProductPhoto in Form eines Pfads. Die historischen Preise werden in einer ProductListPriceHistory gespeichert. Die Kategorien schließlich, die wieder für verschiedene Beispiele sehr hilfreich sind, um Produkte zu kategorisieren und über diese Kategorien Aggregate abzubilden, sind in zwei Tabellen gespeichert. Man unterscheidet zwei Kategorieebenen: zum eine die ProductSubcategory und zum anderen die ProductCategory, wobei die Product-Tabelle zunächst die Unterkategorie verknüpft und diese Unterkategorie wiederum die Oberkategorien. Abbildung 1.9: Schema Production 18

1. Grundlagen 1. 2. 3. Verkaufsdaten Die Verkaufsinformationen befinden sich im Schema Sales, wobei aus den sehr vielen Tabellen in den Beispielen im Wesentlichen nur die SalesOrderHeader-Tabelle benutzt wird, da sie die zusammenfassenden Informationen für einen Verkauf (Kopfdaten) enthält. Sie referenziert in sehr vielen Fremdschlüsselspalten eine große Menge an anderen Tabellen, da sie als typische Buchungstabelle die Geschäftsaktivitäten der Firma abbildet. Zu den Kopfdaten eines Auftrags gehören solche Informationen wie drei verschiedene Zeiten (Bestell-, Auslieferungs-, Fälligkeitsdatum), Preise (Netto, Steuer, Total, Fracht) und die erwähnten Referenzen wie Adressen (Liefer-, Rechnungsadresse), Kunden- und Kontaktinformationen sowie Verkaufsgebiet. Abbildung 1.10: Schema Sales Neben diesen Kopfdaten, die ja bereits umfangreich genug sind, wenn man nur die ganzen Referenzen auflöst, gibt es noch weitere Tabellen in diesem Schema. Jede Bestellung enthält natürlich auch einzelne Positionen, die in SalesOrderDetail gespeichert werden, welche insbesondere eine Referenz zur Product-Tabelle enthält. Die Bestelldetails werden in fast allen Beispielen außer Acht gelassen. Ähnliches gilt auch für die verschiedenen Währungen, die man eigentlich für die Bildung von Umsatzaggregaten mit Wechselkursen berücksichtigen müsste. Dazu gibt es die Tabellen CurrencyRate-Tabelle mit den zeitbezogenen Wechselkursdaten und die Currency-Tabelle mit dem Währungsnamen als Werteliste. Die ermittelten Umsatzzahlen, die in den verschiedenen Aggregatbeispielen genutzt werden, müssten also eigentlich noch jeweils in eine gemeinsame Währung umgerechnet werden, was jedoch zu nebensächlichem Zusatzquelltext führt, der das eigentliche Beispiel nur vernebelt. 1. 3. Das relationale Modell Dieser Abschnitt beschreibt einige wesentliche Begriffe des relationalen Modells, auf dem die relationalen Datenbanken, welche später noch genauer beschrieben werden, aufbauen. 1. 3. 1. Grundbegriffe des relationalen Modells Beim relationalen Modell handelt sich um ein mathematisches Modell, dessen grundlegende Einheit die so genannte Relation ist, welche in einer Datenbank schließlich zu einer Tabelle wird. Eine solche Relation wiederum wird als eine Menge von n-tupeln bezeichnet. Ein Tupel ist in einer Datenbankta- 19

1. Grundlagen belle eine einzelne Zeile bzw. ein Datensatz. Die Menge aller Zeilen bildet dann die gesamte Tabelle, während die Menge aller Tupel die Relation bildet. Operationen, die man auf einer solchen Relation ausführen kann, werden als relationale Algebra bezeichnet. Sie baut auf der Mengenlehre auf. Ihre Ausprägung in einer Datenbank ist dann die SQL-Sprache, mit der diese Operationen formuliert werden können. Grundlegende Züge der Mengen-Theorie und ihrer Operationen sind auch in SQL gut zu erkennen und bereits ein grundlegendes und allgemeines Verständnis dieser Operationen bzw. der Mengenlehre hilft sehr beim Erlernen von SQL und Formulieren von komplexen Abfragen. Die nachfolgende Tabelle enthält einen Vergleich zwischen Begriffen des relationalen Modells und einer relationalen Datenbank: Relationales Modell Relation n-tupel mit n Attributen Attribut Relationale Algebra Relationale Datenbank Tabelle Datensatz mit n-feldern Feld, Spalte, Attribut SQL (Structured Query Language) 1. 3. 2. Semantisches Modell Ein semantisches Modell versucht, die Objekte der Realität möglichst genau zu erfassen und so eine Basis für die endgültig zu erstellende Datenbank zu liefern. Im Idealfall entsteht ein Text, der bereits alle Objekte, Beziehungen und Attribute nennt. Die Entwicklung des semantischen Modells stellt die erste analytische Phase dar. Dieses Thema berührt sehr viele verschiedene angrenzende Bereiche der Analyse und beschreibenden Darstellung zum Zwecke der Anwendungsentwicklung. Dazu zählen die folgenden groben Themen: Beschreibung von Abläufen und Prozessen mit ihren Eigenschaften, die an verschiedenen Stationen wertmäßig erfasst werden, und den Einschränkungen und Bedingungen, die für Abläufe und die Auswahl von bedingten Prozessschritten notwendig sind. Identifikation und Beschreibung von Objekten und Entitäten mit ihren Eigenschaften sowie den Beziehungen zwischen ihnen und Einschränkungen und Validierungsregeln für Eigenschaftswerte. Nahezu alle Mittel zur Analyse und Präsentation ihrer Ergebnisse lassen sich denken. Dazu zählen daher die folgenden: Texte und schriftliche Beschreibungen von Abläufen und Objekten mit den üblichen Techniken wie durchgehender Fließtext, Listen und Tabellen. Es empfiehlt sich hier, Techniken des strukturierten Schreibens zu verwenden. Bspw. gehört dazu, einfache und klar geliederte Aussagen zu formulieren und dabei klare Hauptwörter, Sinn tragende Verben und nur die notwendigsten Adjektive zu verwenden. Es ist auch empfehlenswert, Aussagen durch Formelsprache zur Abbildung von Einschränkungen und Bedingungen zu verkürzen. Zeichnungen und Abbildungen von Abläufen sowie den Objekten und ihren jeweiligen Beziehungen. 20

1. Grundlagen Einsatz von Darstellungs- und Analysetechniken, die für die Abbildung von Strukturen (Objekte mit ihren Eigenschaften und Beziehungen) sowie Abläufen entwickelt worden sind. Dazu zählen vor allen Dingen das Entity-Relationship-Diagramm (ER-Diagramm). Eine fortgeschrittene Technik ist dabei die UML (Unified Modeling Language). Ältere Techniken sind alle Arten von Flussdiagrammen, welche teilweise als Vorläufer der UML gesehen werden können. Sehr moderne und fortgeschrittene Techniken für Datenstrukturen und Beziehungen zwischen Daten sind Ontologien und ontologische Datenmodelle. Die Technik dieser Art Modellierung und Beschreibung ist schon sehr alt, aber im Bereich Softwaretechnik recht neu. 1. 3. 3. Eigenschaften von Daten Die kleinsten Einheiten in einem Datenbanksystem (DBS) sind zweifellos die Daten, die in einem sinnvollen Zusammenhang stehen und von Programmen unterschiedlicher Art für Zwecke der Kontrolle (Finanzsituation), des Marketing (personalisierte Kundenprofile) oder der Verwaltung (Stammdaten) verarbeitet werden. Dieser sinnvolle Zusammenhang ist in der Abbildung illustriert: Interessant sind nicht alle möglichen Namen und Adressen, die in den Telefonbüchern der Welt stehen (Grundgesamtheit), sondern nur die Namen und Adressen von Menschen, die wenigstens einmal ein Zimmer einer Hotelkette gebucht haben. Abbildung 1.11: Daten und ihre Erfassung und Nutzung Diese Daten und noch wesentlich mehr werden in die Datenbank aufgenommen, sobald ein Gast über ein Hotelreservierungssystem als Benutzerschnittstelle ein Zimmer bucht. Damit trägt er seinen Namen sowie weitere Informationen wie Beginn und Ende seines Aufenthalts und natürlich den Hotelnamen in ein Formular ein. Entweder wird dieses Formular direkt im Internet entgegengenommen 21

1. Grundlagen oder wandert erst über eine zentrale Stelle wie z.b. das Fremdenverkehrsamt. Im letzteren Fall würden die Daten vermutlich zusätzlich für Kontroll- und Werbezwecke gespeichert, die nicht das Hotel, aber die Stadt als solche betreffen. In einer ersten Phase benötigt das Hotel die Daten lediglich, um die Zimmerbelegung und die Rechnungserstellung zu automatisieren. In einer zweiten Phase könnte man dann diesen Gast in den regelmäßigen Verteiler des Hotelwerbematerials aufnehmen, sodass er für mindestens drei Jahre jährlich eine Broschüre über die weltweit zu buchenden Hotels der Kette erhält. Je mehr Daten vorhanden sind, desto genauer könnte diese personalisierte Marketingstrategie ausgeführt werden: Kennt man den Beruf und weiß man zusätzlich, dass der Grund für den Aufenthalt ein Messebesuch war, so könnte man in einem regelmäßig ablaufenden Programm die Messetermine mit den Aufenthaltsgründen abgleichen und zielgenau die vorjährigen Messebesucher anschreiben, um das Hotel in Erinnerung zu rufen. Mithilfe von drei Kategorien kann man die Eigenschaften von Daten beschreiben. Insbesondere bei der Neu- oder Weiterentwicklung einer Datenbank ist es wichtig, diese drei Eigenschaftsräume mit Leben zu füllen. Dass dies natürlich dann in ihrer Verarbeitung auch für die Programme gilt, in denen sie z.b. als Variablen auftreten, wird Ihnen schon bekannt sein. Der Datentyp dürfte die bekannteste Achse sein, mit der Daten beschrieben werden können. Er ordnet Informationen in bestimmte Kategorien, für die jeweils unterschiedliche Verarbeitungsmöglichkeiten bestehen. Der Name des Hotelgastes kann sinnvollerweise nur vom Datentyp Text sein, damit entsprechende Programmfunktionen und SQL selbst eine Spalte nach dem Alphabet sortieren oder eine Zeichenkette in ihre Bestandteile zerlegen kann. Die kleinste Einheit dieses Datentyps wiederum ist der einzelne Buchstabe. Anreise und Abreise dagegen könnten als Zahl oder Text gespeichert werden, wobei aber zusätzlich für diesen speziellen Typ auch noch ein Typ Datum existiert. Mit Zahlen lässt sich natürlich rechnen. Verwenden Sie den Typ Datum, können Sie später über entsprechende Funktionen auch Rechenoperationen durchführen und somit zum Beispiel die Anzahl der Übernachtungen automatisch berechnen lassen. Erst über diese Definition kann man mit Hilfe entsprechender Programmfunktionen die Dauer des Aufenthalts berechnen. Bei der Verwendung des Datentyps Text sind solche mathematischen Berechnungen dagegen gar nicht erst möglich. Die Eigenschaft Datenformat stellt oftmals kleine Hürden bei ersten Programmierarbeiten dar, wenn z.b. ein amerikanisches Datum in ein europäisches überführt werden soll oder Währungsbeträge nicht mit beliebig vielen Dezimalstellen (Benzin natürlich wieder ausgenommen), sondern mit genau zwei Dezimalstellen ausgegeben werden sollen. Das Problem tritt sicherlich öfter auf und muss manchmal an einer ganz anderen Baustelle gelöst werden. Das Format lässt sich mit SQL in einigen Fällen von vorne herein vorgeben, in anderen dagegen müssen die Ergebnisdaten eigens in das benötigte Format überführt werden. Damit gehört diese Eigenschaft eher zur externen Problemsicht der Abfrage und wird prinzipiell von SQL nicht weiter berücksichtigt. In einer Programmiersprache Ihrer Wahl können Sie mit den entsprechenden Funktionen sicherlich das Format nach Ihren Wünschen anpassen. Das wohl häufigste Beispiel für die Vorgabe eines Wertebereichs (Domäne) im Internet dürfte die Verwendung der möglichen Werte Herr und Frau für die Spalte Anrede oder Geschlecht sein. Menschen werden typischerweise mit diesen beiden Werten katalogisiert, um z.b. eine korrekte Anrede zu ermöglichen. Gerade bei Auswahl über Optionsfelder lässt sich nichts anderes in die Datenbank eintragen. Möchte man diesen Punkt sehr genau betrachten, so kann man diese Eigenschaft weiter differenzieren: Während der natürliche Wertebereich der in der Realität vorkommende Wertebereich ist (die 22

1. Grundlagen Zahl Pi besitzt schlicht und einfach unendlich viele Nachkommastellen), muss dieser Wertebereich oft für die Verwendung in einem Rechner eingeschränkt werden (ein Rechner verarbeitet sehr lange Zahlen, aber letztlich doch nur endlich lange). Der Wertebereich letztendlich, der wirklich Eingang in die Datenbank findet, ist noch einmal kleiner, denn neben der rechnerbedingten Endlichkeit und damit Begrenzung von Zahlen oder auch anderen Daten, gibt es Daten, die nur in einer bestimmten Größe (Postleitzahlen haben in Deutschland fünf Stellen, in der Schweiz und in Österreich dagegen vier) oder einem bestimmten Muster (Kreditkartennummern, Telefonnummern, ISBN-Nummern) auftreten. Dieser Eigenbereich kann bereits von der Datenbank mit entsprechenden SQL-Befehlen auf Korrektheit überprüft werden. Das Format wird dabei überprüft und mit einem Musterformat verglichen. 1. 3. 4. Klassifikation von Datentypen Wie immer könnte man feinere Verästelungen der Klassifikation von Daten verwenden, doch sollen diese Informationen Ihnen lediglich die wesentlichen Grundlagen vermitteln. Eine einfache Bildung von Unterkategorien im Eigenschaftsraum Datentypen ist die Unterscheidung zwischen elementaren und zusammengesetzten Datentypen. Sie konzentriert sich auf die Elemente der Wertemenge und damit auf die Struktur der Objekte. Typischerweise bewegt man sich bei der Entwicklung von Attributen bzw. Feldnamen von komplexen Begriffen zu elementaren. Dies werden Sie insbesondere bei der Normalisierung von Datenmodellen kennen lernen. Elementare Datentypen sind die Datentypen, die mit SQL für ein Feld vergeben werden und die bereits oben angesprochen wurden. Relationale Datenbanksysteme verwenden u.a. solche elementare Datentypen wie ganze Zahlen im Gegensatz zu reellen Zahlen, wobei die reellen Zahlen Nachkommastellen aufweisen können und damit genauer sind, wenn z.b. Rechenoperationen auf die einzelnen Daten angewandt werden. Zwei als ganze Zahlen definierte Daten ergeben bei einer nicht ganzzahligen Division keine Nachkommastellen, womit zwangsläufig Ungenauigkeiten auftreten, die man entweder wie bei der Modulo-Rechnung in Algorithmen einsetzen kann oder die man lieber vermieden hätte. Weitere Datentypen wie logische Daten, deren Wertebereich gleichzeitig auf WAHR und FALSCH beschränkt ist, können ebenfalls in Programmierabläufen eingesetzt werden. Zusammengesetzte Datentypen ergeben sich aus den Oberbegriffen zu Objekten, die in einem Datenmodell eingearbeitet werden sollen. Innerhalb einer Datenbank für eine Hotelkette werden neben den Gastinformationen natürlich auch Informationen zum Aufenthalt gespeichert. Die Aufenthaltsinformationen sind zunächst für die gegenwärtige Abrechnung wichtig. Da aber der Datensatz des Gastes nicht aus der DB entfernt wird, können die Gastinformationen für die oben erwähnten Marketing-Aktivitäten genutzt werden. Bei dieser Überlegung, die auf den Einsatzmöglichkeiten der Daten beruht, trennt man automatisch beide Bereiche voneinander ab. So wird zum Beispiel der Name atomisiert und in Vorname und Nachname aufgeteilt. Der Datentyp Name ist dann also zusammengesetzt aus Vorname und Nachname. Weitere Oberbegriffe wären dann im Rahmen der Gastinformationen die Adresse, wobei diese ebenfalls jeweils in zusätzliche Feldnamen aufgespaltet werden kann. Hier ist es wichtig zu erwähnen, dass unterschiedliche elementare Datentypen das komplexe Objekt Adresse bilden. Während die Postleitzahl eine Ganzzahl ist, sind Straßen- und Stadtnamen vom Typ Text. Die Hausnummer dagegen ist ebenfalls vom Typ Text, da ja Kombinationen aus Zahlen und Buchstaben (Bahnhofstr. 3a) möglich sind. 23

1. Grundlagen Abbildung 1.12: Verschieden strukturierte Daten 1. 3. 5. Beziehungen zwischen Daten Eine wichtige Eigenschaft von Daten innerhalb eines Datenmodells ist die Beziehungsstruktur. Sie ist zunächst in der Realität vorhanden und wird durch die Abbildung im Datenmodell für die DB bedeutsam. In der Datenbank werden sie vor allen Dingen durch die so genannte Primärschlüssel-Fremdschlüssel-Beziehung abgebildet. Zwei hierarchische Ebenen müssen unterschieden werden: Beziehungen innerhalb eines Objekts: Die Beziehungen, die in den Attributen für den Hotelgast existieren, sind nur für ihn als Individuum bzw. sofern sie wie bei Messebesuchen bei einer Gruppe von Individuen auftreten als kleine Unterkategorie des Objekts Hotelgast interessant. Geht aus irgendeinem Grund die Information verloren, dass er wegen eines Messebesuchs im März im Hotel ein Zimmer gebucht hat, verschwindet in diesem kleinen Beispiel auch die Möglichkeit, ihn personalisiert zu bewerben. Es ist gerade diese Information bzw. ihre Beziehung zu den Attributen Namen und Adresse, die ihn ein wenig heraushebt und besser beschreibt. Beziehungen zwischen Objekten: Zwischen verschiedenen Objekten mit weitestgehend unterschiedlichen Attributen, also Daten, die pro Objekt erfasst werden, sind Beziehungen besonders bedeutsam, da sie die Grundkonzeption relationaler DBS bilden. Erst über spezielle Beziehungen, wie sie bspw. über das Schlüsselkonzept gebildet werden, können Netze von Objekten entstehen 24

1. Grundlagen und Vorteile wie z.b. Redundanzfreiheit genutzt werden. In diesem Zusammenhang sei nur kurz darauf verwiesen, dass ein Hotel, das sich durch günstigen Online-Anschluss im Hotelzimmer, lange Abendessenszeit und Transferdienst auf Messebesucher spezialisiert hat, die Messen ebenfalls als eigenes Objekt in der DB erfassen könnte. So könnten über die Verwendung eines eindeutigen Messenamens (oder typischerweise eine Nummer / einen Schlüssel) im Objekt Messebesucher genauere Messeinformationen mit den Hotelgästen kombiniert werden. Beziehungstyp Eineindeutig 1:1 Funktional 1:n Komplex n:m ÎÎ Die 1:1 (eineindeutige) Beziehung Definition Jedem Objekt vom Typ A ist genau ein Objekt vom Typ B zugeordnet. Jedes Objekt vom Typ A steht mit beliebig vielen Objekten vom Typ B in Beziehung. Dagegen steht ein Objekt vom Typ B höchstens mit einem Objekt vom Typ A in Beziehung. Beliebig viele Objekte vom Typ A stehen mit beliebigen Objekten vom Typ B in Beziehung und umgekehrt. In einem Ehepaarkreis mit vier Ehepaaren kann man die beiden Objekte Ehemänner und Ehefrauen unterscheiden. Da die Objektanzahl begrenzt ist, ist auch der Wertebereich für das Attribut Vorname auf insgesamt acht Werte beschränkt. Jeweils vier davon lassen sich auf eine der Gruppen verteilen. Kein Vorname taucht doppelt auf, sodass unterschiedliche Personen auch unterschiedliche Vornamen besitzen. In einer eineindeutigen Beziehung zwischen zwei Wertebereichen gehört zu jedem Wert des einen Wertebereichs ein Wert des anderen Wertebereichs. In diesem Fall ist Ralf mit Susanne, Reinhard mit Birte, Tom mit Tina und Nils mit Anja verheiratet. Wie das bei deutschen Ehepaaren so üblich ist, hat jeder nur einen einzigen Ehepartner. Abbildung 1.13: Eineindeutige Beziehung ÎÎ Die 1:n (funktionale) Beziehung Sobald man Kinder mit zur Familie zählt, wird alles bunter, und der Organisationsaufwand nimmt zu. So ist es natürlich auch bei der Bestimmung der Beziehungen. Susanne und Tina sind bereits Mütter, während Birte und Anja noch keine Kinder haben. Eine funktionale Beziehung zeichnet sich dadurch aus, dass zu den Werten des einen Wertebereichs null, einer oder mehrere Werte des anderen Wertebereichs gehören. Die funktionale Beziehung bedeutet also: Jeweils ein Kind hat genau eine Mutter. Umgekehrt kann aber eine Mutter mehrere Kinder haben. Daher auch die Beziehung 1:n. 25

1. Grundlagen So kann also Susanne zwei Kinder haben, Tina eines und die anderen Mütter keine. Bei der funktionalen Beziehung ist also nur erlaubt, dass ein Wertebereich uneindeutige Werte hat, sodass es wie in der Realität ausgeschlossen ist, dass ein Kind zwei Mütter hätte. Abbildung 1.14: Funktionale Beziehung ÎÎ Die n:m (komplexe) Beziehung Eine komplexe Beziehung liegt vor, wenn keine Einschränkungen wie bei der funktionalen Beziehung gemacht werden können. Ein solcher Fall stellt sich, wenn weitere Verwandten das Bild betreten. Eine Tante kann sowohl einen als auch mehrere Neffen oder Nichten haben. Umgekehrt ist es auch möglich, dass ein Kind mehrere Tanten besitzt. So ist Birte sowohl von Stefan als auch von Kristina die Tante, während Holger als Tanten Tina und Anja nennen kann. Eine komplexe Beziehung liegt vor, wenn es zu jedem Wert eines Wertebereichs null, einen oder mehrere Werte eines anderen Wertebereichs gibt und umgekehrt. Damit sind die Beschränkungen der funktionalen Beziehung aufgehoben. Abbildung 1.15: Komplexe Beziehung ÎÎZusammenfassung Abbildung 1.16: Zusammenfassung der Beziehungen 26

1. Grundlagen 1. 3. 6. Entity-Relationship-Modell Bevor man sich daranmacht, für ein Datenbankprojekt sofort Tabellen und Feldnamen mit SQL zu tippen, kann man mithilfe eines grafischen Modells versuchen, die zu modellierenden Objekte zu finden und sich einen Überblick über die Beziehungen zu verschaffen. Seit 1976 wird das von P. P. Chen vorgeschlagene Entity-Relationship-Modell (ER-Modell oder ERM) für eine erste Annäherung verwendet, dessen Vorteile in der grafischen Darstellung und der mathematischen Verständlichkeit liegen. Es besteht aus den Elementen Entity, Entity-Typ, Relationship und Attribut. Element Bedeutung Zeichen Entity zu modellierendes Objekt Rechteck Entity-Typ Objekte mit ähnlichen Eigenschaften Rechteck Relationship Beziehung zwischen Objekten Raute Attribut Eigenschaft eines Objekts Oval Das RDM (relationale Datenmodell) beruht auf der Überführung der einzelnen Objekte im ER-Modell in Tabellen, die über die Primärschlüssel, die in der anderen Tabelle Sekundärschlüssel sind, in Beziehung stehen. Dieses Datenmodell wurde von E.F.Codd 1970 entwickelt und bildet die Grundlage für relationale Datenbanksysteme. In diesem Zusammenhang wird ein Datenmodell mit nur einer einzigen Tabelle und sämtlichen Informationen als Universal Relation bezeichnet. Folgende Schritte sind dabei zu berücksichtigen: 1. Entwickeln Sie ein semantisches Modell. 2. Leiten Sie aus dem semantischen Modell die benötigten Objekte ab. 3. Es ist nachher nicht weiter schwierig, sich mehr und mehr Attribute auszudenken, sodass man sich zunächst auf die wichtigsten beschränken sollte. Normalerweise findet man die benötigten Attribute über eine Tätigkeitsanalyse oder eine Objektanalyse. In einer solchen Tätigkeits- oder Prozessanalyse durchläuft man die gesamten Tätigkeiten, die ein Objekt ausführt. Sie verlaufen teilweise auch parallel zu den Tätigkeiten anderer Objekte, die entweder schon von Anfang an bestehen oder sich erst im Prozessverlauf herausbilden. Die Objektanalyse fokussiert mehr die Beschreibung von Objekten, die real vorhanden sind. 4. Erstellen Sie das Entity-Relationship-Diagramm. Dabei werden die einzelnen gefundenen Objekte zueinander in Beziehung gesetzt und in ein Diagramm gezeichnet. Es kann bei vielen Objekten oder Attributen oder komplexen Beziehungsstrukturen beträchtliche Größen erreichen. Wahlweise wird auch ein Name für die Beziehung vergeben. 5. Transformieren Sie das ER-Modell in das relationale Daten-Modell: Ein Objekt bildet eine eigene Tabelle. Die Datensätze sind die einzelnen Zeilen einer solchen Tabelle. 27

1. Grundlagen Die Attribute stellen die Spalten (Feldnamen) dar. Ein Schlüssel ist ein spezielles Attribut, das einen Datensatz eindeutig identifiziert. Oft können die übrig bleibenden Attribute bei Entfernung eines Attributes einen Datensatz nicht mehr korrekt oder eindeutig identifizieren. Der Wertebereich einer Spalte entspricht der Domäne, die dem Attribut zugeordnet wurde. Eine Beziehung wird entweder über Fremdschlüssel oder über eine eigene Beziehungstabelle ausgedrückt. 6. Spalten Sie die Beziehungen in Primärschlüssel-Fremdschlüssel (1:1 und 1:n) oder Beziehungstabellen (n:m) auf. 7. Verhindern Sie Dateninkonsistenzen. Hierbei müssen entsprechende Konventionen aus realen Gegebenheiten abgeleitet werden, um die Daten konsistent zu machen. Nur so können Sie garantieren, dass Abfragen auch tatsächlich korrekt ablaufen. Zwei typische Konzepte helfen bei diesem Ziel: Wertebereiche oder Domänen und Namensdefinitionen. 8. Testen Sie das Datenmodell durch beispielhafte Einträge. Es empfiehlt sich zusätzlich, lieber mit schlechten als mit guten Daten einen Testlauf zu machen, damit evtl. Fehler noch früh genug gefunden werden können. Schlechte Daten in diesem Zusammenhang sind vom DB-Entwickler aus der Prozessanalyse gewonnene Beispieldaten oder solche, die der Auftraggeber/Benutzer ihm als typische übermittelt hat. In jedem Fall sind es nicht die guten Daten, die nachher im normalen Arbeitsprozess, wenn alles funktionieren sollte, eingegeben werden. Mögliche Fehler, die insbesondere durch unerfasste Ausnahmeregelungen entstehen können, können Sie mit Testeinträgen versuchen zu entdecken. Abbildung 1.17: Entity-Relationship-Diagramm für den Komplex Buch-Autor-Verlag 28

1. Grundlagen 1. 3. 7. Normalisierung mit Normalformen Ein in einer Universal-Relation (nicht normalisierte Struktur/Tabelle) vorliegendes Datenmodell kann über Normalisierungen in ein korrektes relationales Schema überführt werden. Dabei werden für die 1NF (erste Normalform) alle Attribute atomisiert, für die 2NF die funktionalen Abhängigkeiten zwischen Primärschlüssel und anderen Attributen elementar gemacht und in der 3NF die funktionalen Abhängigkeiten der Attribute untereinander direkt gemacht. Auf dem Weg von einem semantischen Modell b bis hin zu einem funktionsfähigen relationalen Datenmodell werden normalerweise die wichtigsten Strukturen erkannt und auch korrekt modelliert. Die Feinheiten allerdings bleiben erwartungsgemäß auf der Strecke. Nun soll noch einmal unter dem Blickwinkel des korrekten Tabellenaufbaus der Algorithmus der Normalisierung vorgestellt werden. Die in diesem Algorithmus ablaufenden Regeln und die ihn begründenden Gesetze haben folgende Ziele: Der Aufwand für die Weiterentwicklung der Anwendungsprogramme soll gesenkt werden. Die einzelnen Datenstrukturen sind logisch so weit wie möglich entflochten, sodass die Daten möglichst flexibel verwaltet werden können und Änderungen sowohl bei einzelnen Objekten als auch in der Anwendungssoftware leicht durchführbar bleiben. Eine fast redundanzfreie Speicherung von Daten verkleinert den Speicherplatz und nutzt Rechenzeit besser aus. Dies sind die Definitionen der ersten drei Normalformen: Eine Tabelle ist in der 1. Normalform, wenn sie einen Schlüssel besitzt und alle Attribute atomisiert sind. Atomisiert sind Attribute genau dann, wenn sie nicht weiter aufgeteilt werden können. Eine Tabelle ist in 2. Normalform, wenn sie in der 1. Normalform ist und die funktionalen Abhängigkeiten zwischen Schlüssel und den anderen Attributen elementar ist. Eine Tabelle ist in der 3. Normalform, wenn sie in der 2. Normalform ist und die Eigenschaft und die funktionalen Abhängigkeiten zwischen dem Schlüssel und den anderen Attributen direkt sind. Folgendes Anti-Beispiel erfüllt kein einziges der der oben genannten Merkmale, sodass es mit den folgenden Abschnitten als durchgehendes Beispiel schrittweise in ein geeignetes Datenmodell überführt werden kann. In einer Firma, die sich mit der Lösung von E-Commerce-Problemen beschäftigt, sind verschiedene Mitarbeiter abteilungsübergreifend in Projekten eingesetzt. Jeder Mitarbeiter hat eine Personalnummer (PersNr), einen Namen (Name) und ein Einstiegsjahr (Jahr). Die Mitarbeiter arbeiten in Abteilungen, die eine Abteilungsnummer (AbtNr), einen Abteilungsnamen (AbtName), eine Mitarbeiterzahl (MaZahl) und einen Abteilungsleiter (AbtLeit) besitzen. Die Projekte haben verschiedene Nummern (ProjNr) und einen Projektleiter (LeitNr). Die Mitarbeiter beschäftigen sich unterschiedlich intensiv (Zeit) mit den aktuellen Projekten. Eine solche nicht-normalisierte Tabelle nennt man Universalrelation. PersNr ProjNr LeitNr Zeit Name Jahr AbtNr AbtName MaZahl AbtLeit 1020 C13 1020 15% Ralf 1995 2 Medien 4 1020 Tauzieh 1020 B12 1042 30% Ralf Tauzieh 1992 2 Medien 4 1020 29

1. Grundlagen PersNr ProjNr LeitNr Zeit Name Jahr AbtNr AbtName MaZahl AbtLeit 1035 C13 1020 50% Jana 2001 3 FiBu 2 1035 Grün 1042 B12 1042 25% Tom 1993 1 Seminare 3 1042 Schnell 1042 D10 1049 30% Tom 1990 1 Seminare 3 1042 Schnell 1048 D10 1049 15% Fritz 1999 4 Programmierung 5 1048 Bachler 1049 C13 1020 40% Tanja Sieben 1996 4 Programmierung 5 1048 Zwischen Daten können unterschiedliche Abhängigkeiten bestehen. Mit ihrer Hilfe können Daten in eine vernünftige relationale Form gebracht werden, wenn man die Daten entsprechend analysiert. Die funktionale Abhängigkeit ist diejenige, welche bei der Normalisierung insbesondere interessiert. Für die funktionale Abhängigkeit gilt, dass zwei Attribute eines Objekts dann funktional voneinander abhängen, wenn zu jedem Wert von A nur ein Wert von B gehört. In obiger Tabelle besteht also bspw. eine solche Abhängigkeit zwischen PersNr und Name, da über die Personalnummer (1020) sofort auf den zugehörigen Namen (Ralf Tauzieh) geschlossen werden kann. In diesem Fall sagt man, dass der Name funktional abhängig ist von der Personalnummer. Wenn Sie mit so häufigen Namen wie Ralf Müller oder Ralf Schmidt den gleichen Test machen, könnte es sein, dass auch noch ein Anderer im Betrieb den gleichen Namen hat und deswegen die Personalnummer nicht vom Namen abhängt. 1. Analysieren Sie die vorliegende Datenstruktur. 2. Richten Sie die Tabelle MITARBEITER ein. Ganz deutlich fällt auf, dass ein besonders einfach zu modellierendes Objekt der einzelne Mitarbeiter ist. Er wird in der Übersichtstabelle hauptsächlich durch seine PersNr, seinen Namen und sein Eintrittsjahr gekennzeichnet. Die Aufnahme der anderen Attribute verbietet sich deswegen schon, weil sie u.a. die Datenredundanz hervorgerufen haben. Sobald ja ein Mitarbeiter an zwei Projekten teilnimmt, taucht er mit zwei Datensätzen und seinen gesamten anderen Daten in der Übersichtstabelle auf. PersNr Name Jahr 1020 Ralf Tauzieh 1995 1035 Jana Grün 2001 1042 Tom Schnell 1990 1048 Fritz Bachler 1999 1049 Tanja Sieben 1996 3. Bringen Sie die Tabelle MITARBEITER in die 1. Normalform. Für die 1. Normalform gilt, dass sie einen Schlüssel besitzt und alle Attribute atomisiert sind. Ein Schlüssel ist durch die Personalnummer vorhanden. Die Atomisierung muss noch umgesetzt werden, da im Attribut Name sowohl der Vorname als auch der Nachname eingetragen sind. Atomisiert sind Attribute also dann, wenn sie nicht weiter aufgeteilt werden können. PersNr Vorname Name Jahr 1020 Ralf Tauzieh 1995 1035 Jana Grün 2001 30