Datenbanken und Datenbankmanagementsysteme

Transkript

1 Datenbanken und Datenbankmanagementsysteme Prof. Dr. Katrin Brabender Version: Labor für Angewandte Informatik und Datenbanken Seite 1

2 Inhalte der Vorlesung Einführung in die Theorie der Datenbanken Relationale Datenbanken Phasen des Datenbankentwurfs Das ER-Modell Normalisierung Die Datenbanksprache SQL Datenbank-Techniken Arbeitsweise eines DBMS und Optimierung Die Datenbank im Netz Einige Datenbanken im Vergleich Datawarehouse und Mulitidimensionale Datenbanken Seite 2

3 Einige Literatur aus dem Bereich der Datenbanken Ramez Elmasir, Shamkant B. Navathe: Grundlagen von Datenbanksystemen, Addison-Wesley 3. Auflage 2002 Andreas Heuer, Gunter Saake, Kai-Uwe Sattler: Datenbanken kompakt, mitp 2001 Rene Steiner: Theorie und Praxis relationaler Datenbanken, vieweg 2000 Zum Thema Data-Warehouse Bauer, A.; Günzel, H.: Data-Warehouse-Systeme. Dpunkt.verlag Heidelberg 2001 Inmon, W.H.: Building the Data Warehouse. Second Edition, John Wiley & Sons, New York, Seite 3

4 Einführung in die Theorie der Datenbanken Datenbanken bzw. Datenbanksysteme sind Systeme zur Beschreibung, Speicherung und Wiedergewinnung von umfangreichen Datenmengen, die von mehreren Anwendungsprogrammen benutzt werden. Ein Datenbanksystem besteht aus der Datenbank (Abkürzung DB), d.h. der Datenbasis, in der die Daten abgelegt werden, und dem Datenbankmanagementsystem (Abkürzung DBMS), d.h. den Verwaltungsprogrammen, die die Daten entsprechend den vorgegebenen Beschreibungen abspeichern, auffinden, verändern etc. Seite 4

5 Ein Datenbanksystem hat folgende Eigenschaften Der Nutzer soll Zugriff auf die gespeicherten Daten haben, ohne dass dieser wissen muss, wie die Daten im System organisiert sind. Daten müssen vor ungewollter Manipulation geschützt werden, d.h. ein Benutzer darf auf Daten nur lesend oder schreibend zugreifen, wenn er hierfür eine Zugriffsberechtigung hat. Es darf nicht passieren, dass wegen Fehlmanipulationen des Benutzers Daten zerstört werden können (bis hin zum gesamten Datenbestand). Datenbanken sollten gewährleisten, dass eine Änderung der internen Datenorganisation nicht zu einer Anpassung der Anwendersoftware führen muss. Seite 5

6 Die Daten sollen in strukturierter Form zur Verwendung durch mehr als ein Software-System gespeichert werden. Ein Ziel von Datenbanksystemen ist die Beseitigung von Datenredundanzen. Sie können große Datenmengen effizient verwalten. Dabei bieten sie benutzergerechte Anfragesprachen an, die es dem Anwender ermöglichen auf die Daten zuzugreifen ohne Rücksicht auf die interne Realisierung der Datenspeicherung. Interne Optimierungen ermöglichen einen effizienten Zugriff auf die Daten. Multiuser-Fähigkeit, d.h. viele Nutzer können gleichzeitig auf die Datenbank zugreifen. Ein Transaktionskonzept verhindert unerwünschte Nebeneffekte beim Zugriff auf gemeinsam genutzte Daten. Seite 6

7 Das Problem der Datenredundanz Ohne den Einsatz von Datenbanksystemen tritt das Problem der Datenredundanz (Mehrfachspeicherung) auf. Das Speichern von Daten in Dateien führt zum mehrfachen Speichern der selben Informationen, d.h. Informationen werden mehrfach abgelegt. Man bezeichnet dies als redundante Speicherung. Die redundante Speicherung führt zu einer Verschwendung von Speicherplatz und zur Dateninkonsistenz. Zugriffskontrollen und Datensicherheit sind nicht gewährleistet. Die Datenunabhängigkeit ist nicht gegeben, d.h. die interne Darstellung der Daten ist nicht einheitlich und erschwert so dem Anwendungsprogrammierer das Zugreifen auf diese Daten. Seite 7

8 Sowohl das Problem der fehlenden Datenunabhängigkeit als auch der fehlenden Zugriffskontrolle und Datensicherheit kann mit Hilfe des Einsatzes von Datenbanksystemen gelöst werden. Im Gegensatz zur Datenredundanz spricht man dann von Datenintegration. Das Prinzip der Datenintegration basiert auf folgenden Überlegungen: Die gesamte Basis- und Anwendungssoftware arbeitet auf denselben Daten, die in einer zentralen Datenhaltungskomponente verwaltet werden. Seite 8

9 Die Datenunabhängigkeit Das Konzept der Datenunabhängigkeit hat das Ziel, eine Datenbank von notwendigen Änderungen der Anwendung abzukoppeln. Sie kann in zwei Aspekte aufgeteilt werden: Die Implementierungsunabhängigkeit oder physische Datenunabhängigkeit bedeutet, dass die konzeptionelle Sicht auf einen Datenbestand unabhängig von der für die Speicherung der Daten gewählten Datenstruktur besteht. Die Anwendungsunabhängigkeit oder logische Datenunabhängigkeit koppelt die Datenbank von Änderungen und Erweiterungen der Anwendungsschnittstelle ab. Seite 9

10 Transaktionen Transaktionen sind eine Folge von Datenbankoperationen, die einen konsistenten Datenbestand in einen neuen konsistenten Datenbestand überführen. Die Folge von Datenbankoperationen wird dabei entweder vollständig oder gar nicht ausgeführt. Gerade im Mehrbenutzerbetrieb ist die Unterstützung des Transaktionskonzeptes ein wichtiges Merkmal von Datenbanksystemen. Seite 10

11 Bemerkung Die Datenunabhängigkeit wird durch die sog. Drei-Ebenen- Architektur (s. später) gewährleistet. Zugriffskontrolle, d.h. kein unbefugter Zugriff und Datensicherheit, d.h. kein ungewollter Datenverlust werden vom System gewährleistet. Seite 11

12 Anforderungen an ein Datenbank-Management-System Der Mathematiker Dr. Edgar F. Codd hat die theoretischen Grundlagen für Datenbanken gelegt. Anfang der 70er Jahre hat Codd die Anforderung an ein Datenbank-Management-System in 9 Regeln aufgestellt, die noch heute ihre Gültigkeit haben. Seite 12

13 Die Codd schen Regeln Integration Einheitliche Verwaltung aller von Anwendungen benötigten Daten, d.h. nicht-redundante Datenhaltung. Operationen Auf der Datenbank müssen Operationen möglich sein, die Datenspeicherung, Suchen, Verändern des Datenbestandes ermöglichen. Katalog Der Katalog oder Data dictionary ermöglicht Zugriffe auf die Datenbeschreibungen der Datenbank. Seite 13

14 Benutzersichten Für die unterschiedlichen Anwendungen sind unterschiedliche Sichten auf die Daten notwendig. Konsistenzüberwachung Überprüfung der Dateninhalte und der korrekten Ausführung von Änderungen. Zugriffskontrolle Transaktionen Zusammenfassung von Datenbank-Änderungen zu Funktionseinheiten. Seite 14

15 Synchronisation Konkurrierende Transaktionen mehrer Benutzer müssen koordiniert werden. Datensicherung Das Wiederherstellen von Daten z.b. nach Systemfehlern muss gewährleistet werden. Seite 15

16 Grundmerkmale von modernen Datenbanksystemen sind (abgeleitet aus den Codd schen Regeln) Verwaltung von persistenten (langfristig zu haltende) Daten. Effiziente Verwaltung großer Datenmengen. Datenbank-Management-Systeme definieren ein Datenmodell, mit dessen Konzepten alle Daten einheitlich beschrieben werden. Sie stellen Operationen und Sprachen zur Verfügung. (Bei relationalen Datenbanken ist SQL der Standard). Sie unterstützen das Transaktionskonzept. Sie unterstützen die Einhaltung des Datenschutzes, Datenkonsistenz und Datensicherheit. Seite 16

17 Architektur in drei Ebenen Die heute noch allgemein akzeptierte Methode zur Beschreibung der Architektur eine Datenbank wurde in den 70er Jahren von der ANSI/X3/SPARC Study Group on Database Management Systems entworfen. Es handelt sich um die Drei-Ebenen-Schema Architektur einer Datenbank. Ein Datenbankschema wird in drei aufeinander aufbauenden Ebenen aufgeteilt: Seite 17

18 Datenbankarchitektur Interne Ebene: Die interne Ebene beschreibt die systemspezifische Realisierung der Datenbank, d.h. die Art und Weise, wie die Daten physisch auf der Hardware abgespeichert werden. Die Interne Ebene verwaltet das DBMS. Konzeptionelle Ebene: Sie beinhaltet eine implementierungsunabhängige Modellierung der Datenbank in einem systemunabhängigen Datenmodell. Die Struktur der Datenbank wird vollständig beschrieben. Zuständig für diese Ebene ist der Datenbank-Administrator. Externe Schicht: Sicht der Endanwender auf die Daten. Es kann mehrere Sichten, d.h. mehrere Externe Schemata geben. Seite 18

19 Klassifizierung von Datenbankmanagementsystemen DBMS werden anhand verschiedener Kriterien klassifiziert. Das dem DBMS zugrunde liegende Datenmodell. Man unterscheidet zwischen einem Hierarchischem Modell Netzwerk Modell Relationalem Modell Objektdatenmodell Das Hierarchische und Netzwerk Modell sind veraltete Modelle, bei denen die Datendateien hierarchisch angeordnet sind. Jeder Datensatz einer höheren Hierarchieebene enthält einen Verweis auf die ihm zugeordneten Datensätze der nächst niedrigeren Ebene. Seite 19

20 Bei relationalen Datenbanken werden die Daten nicht hierarchisch in einem File, sondern geordnet nach Themenkreisen (Entitäten) in Form von Tabellen abgelegt. Relationale Datenbanken zeichnen sich durch eine hohe Flexibilität aus. Objektmodelle beinhalten Konzepte der Objektorientierung. Die vom System unterstützte Anzahl an Nutzern, die gleichzeitig auf die Datenbank zugreifen können. Unterschieden wird hier zwischen Single- und Multi-User System. Anzahl der Rechner, auf die sich die Datenbank verteilt. Man spricht von einem zentralen DBMS, wenn die Daten auf einem einzigen Rechner gespeichert werden und von einem dezentralen DBMS, falls die Datenbank auf mehreren Rechnern verteilt ist. Kosten eines DBMS Seite 20

21 Konkrete kommerzielle Datenbank Management Systeme sind z.b. die relationalen Datenbanksysteme Oracle, IBM DB2, Microsoft SQL-Server, Sybase. Diese Systeme haben eine Drei-Ebenen-Architektur nach ANSI-SPARC eine einheitliche Datenbanksprache (SQL) eine Einbettung dieser Sprache in kommerzielle Programmiersprachen verschiedene Werkzeuge für die Definition, Anfrage und Darstellung von Daten kontrollierter Mehrbenutzerbetrieb, Zugriffskontrolle und Datensicherheitsmechanismen. Seite 21

22 Relationale Datenbanken Das relationale Datenmodell wurde von Codd 1970 eingeführt mit seiner Arbeit E. F. Codd: A Relational Model of Data for Large Shared Data Banks, Communications of the ACM Vol 13, June Die Firma Oracle war die erste Firma, die ein geeignetes DBMS auf den Markt brachte. Seite 22

23 Das Konzept einer relationalen Datenbank Die Basis für das Speichern von Daten in einer relationalen Datenbank sind Tabellen. Beispiel: Die Kunden einer Firma sind in einer Tabelle abgelegt: Kunde Name Vorname PLZ Ort Straße Wertigkeit Meier Klaus Bochum Laerheidestr. 26 B Beier Andrea Frankfurt Zeil 5 A Meier Klaus Wuppertal Güntherstr. 11 C Becker Inga Ravensburg Lindenallee 2 A Kohnen Silvia Frankfurt Im Prüfling 2 B Seite 23

24 Die Grundbegriffe des relationalen Datenmodells Entität (Tabellenname): Eine Entität stellt einen Themenkreis dar, der Elemente mit gleichen Merkmalen umfasst, Beispiel Kunde, Student etc. Entitätsmenge (Datensätze): Die Entitätsmenge beinhaltet alle zu den Merkmalen einer Entität gehörenden Werte. D.h. eine Entitätsmenge entspricht allen gespeicherten Datensätzen einer Tabelle. Tabelle: Entität mit zugehöriger Entitätsmenge Tupel (Datensatz): Ein Tupel umfasst alle Merkmale eines Elementes als Bestandteil einer Entitätsmenge. Entspricht also einem vollständigen Datensatz. Attribut (Spaltenname): Beschreibt spezifische Eigenschaft einer Entitätsmenge, Bsp. Name Seite 24

25 Attributwert: Datenwert, der das zugehörige Attribut eines Tupels beschreibt, Beispiel Attribut = Name, Attributwert = Meier. Jedes Tupel einer Entitätsmenge muss eindeutig identifizierbar sein. Dies kann durch ein Attribut oder einer Kombination von Attributen gewährleistet werden. Man bezeichnet dieses Attribut bzw. diese Kombination aus Attributen als Identifikationsschlüssel (Id-Schlüssel). Im Beispiel der Entität Kunde wäre der Identifikationsschlüssel beispielsweise gegeben durch Name, Vorname, PLZ Die Kombination Name, Vorname würde nicht ausreichen. Seite 25

26 Eigenschaften des Identifikationsschlüssels Er ist eindeutig. Jedem neuen Tupel muss sofort der entsprechende Attributwert des Identifikationsschlüssels zugeteilt werden können. Der Identifikationsschlüssel eines Tupels darf sich während dessen Existenz nicht ändern. Der Identifikationsschlüssel und auch kein Bestandteil darf ein NULL- Wert sein. Seite 26

27 Zur Wahrung der Übersichtlichkeit führt man meist künstliche Identifikationsschlüssel ein, z.b. laufende Nummern. Damit sieht die Kundentabelle wie folgt aus Kunde Entität Attribut KNr Name Vorname PLZ Ort Straße Wertigkeit 100 Meier Klaus Bochum Laerheidestr. 26 B 101 Beier Andrea Frankfurt Zeil 5 A 102 Meier Klaus Wuppertal Güntherstr. 11 C 103 Becker Inga Ravensburg Lindenallee 2 A 104 Kohnen Silvia Frankfurt Im Prüfling 2 B Id-Schlüssel Tupel Seite 27

28 Die Daten einer Datenbank werden unterteilt in Stammdaten und sog. Bewegungsdaten. Beispiel: Eine Firma verkauft und versendet Computerartikel. Die Kunden und die angebotenen Artikel wären hier die Stammdaten, die Aufträge die Bewegungsdaten. Ein Auftrag stammt von einem Kunden, ein Auftrag besteht aus einem oder mehreren Artikeln, die bestellt werden. Damit besteht eine Beziehung zwischen den Tabellen Auftrag und Kunde und eine weitere Beziehung zwischen den Tabellen Auftrag und Artikel. Seite 28

29 Eine Beziehung wird durch einen Fremdschlüssel ausgedrückt. Ein Fremdschlüssel in einer Tabelle T2 ist ein Attribut oder eine Attributkombination, welche in einer Tabelle T1 den Identifikationsschlüssel bildet. Auf der folgenden Folie sind die Tabellen mit ihren Beziehungen dargestellt. Das Attribut KNr in der Tabelle Auftrag ist ein Fremdschlüssel. Zwischen der Tabelle Kunde und Auftrag besteht eine 1:n Beziehung, d.h. 1 Kunde kann n Aufträge erteilen, 1 Auftrag stammt aber nur von 1 Kunden. Seite 29

30 Kunde KNr Name Vorname PLZ Ort Straße Wertigkeit 100 Meier Klaus Bochum Laerheidestr. 26 B 101 Beier Andrea Frankfurt Zeil 5 C 102 Meier Klaus Wuppertal Güntherstr. 11 A 103 Becker Inga Ravensburg Lindenallee 2 C 104 Kohnen Silvia Frankfurt Im Prüfling 2 B Auftrag AufNr KNr AufDat LiefDat Artikel ArtNr ArtBez EkPreis VKPreis 1001 CPU Grafikkarte Speicher Monitor Festplatte Position ArtNr AufNr Menge Seite 30

31 Für eine Beziehung kann referentielle Integrität bestimmt werden. Dann kann kein Tupel in der Tabelle Auftrag mit einem Attributwert eines Kunden erzeugt werden, den es nicht in der Kundentabelle gibt kein Kunde aus der Kundentabelle gelöscht werden, der noch Aufträge in der Tabelle Auftrag hat. Seite 31

32 Die Datenbanksprache SQL SQL (Structured Query Language) ist eine weitestgehend standardisierte Sprache für relationale Datenbanken. SQL ist eine deskriptive, d.h. nichtprozedurale Sprache. Es wird damit dem Datenbankmanagementsystem nicht mitgeteilt, wie die Daten gesucht werden sollen, sondern nur was erreicht werden soll. SQL ist mengenorientiert, d.h. das Ergebnis einer Datenbankabfrage kann aus einem oder mehreren Treffern bestehen. Seite 32

33 SQL besteht aus den Bereichen DDL Data Definition Language mit den Befehlen CREATE (Anlegen von Tabellen, Sichten, ) ALTER (Ändern) DROP (Löschen) DML Data Manipulation Language mit den Befehlen INSERT (Einfügen von Zeilen) UPDATE (Ändern) DELETE (Löschen) SELECT (Abfragen) Seite 33

34 DCL Data Control Language mit den Befehlen GRANT (Vergabe von Zugriffsrechten) REVOKE (Zurücknahme von Zugriffsrechten) COMMIT (Abschluss von Transaktionen) ROLLBACK (Abbruch von Tranksaktionen) Seite 34

35 Der Datenbankentwurfsprozess Dem Entwurf einer Datenbank kommt eine sehr große Bedeutung zu. Der Datenbankentwurf kann in mehrere Phasen unterteilt werden: Anforderungsanalyse Sammeln und Analysieren der Anforderungen an die zu realisierende Datenbank Konzeptioneller Entwurf Die Datenbank soll zusammen mit den Anwendungsfunktionen unabhängig von dem später zur Implementierung verwendeten System entworfen werden. Es soll ein Datenbankmodell benutzt werden, das an konzeptionellen Informationsstrukturen und nicht an Implementierungsmöglichkeiten angelehnt ist. Gut geeignet ist das sog. ER-Modell. Seite 35

36 Verteilungsentwurf Die Verteilung der Daten muss entworfen werden, wenn die Datenbankanwendung verteilt realisiert werden soll. Logischer Entwurf In dieser Phase erfolgt der Detail-Entwurf. Das ER-Modell wird z.b. auf ein relationales Schema übertragen. Datendefinition Hier werden die Datentypen, Wertebereiche etc. definiert. Physischer Entwurf Anlegen von Datencontainern auf den Platten des Datenbankcomputers, Wahl von spezifischen Speicherstrukturen und Zugriffspfaden für die Datenbankdateien. Seite 36

37 Externer Datenbankentwurf Definition von Benutzer-Sichten auf die Datenbank, Anlegen von Benutzern und Gruppen, Vergabe von Zugriffsrechten. Realisierung des Entwurf in einem konkreten DBMS Installation, Anlegen der Datenbank, Anlegen der Tabellen. Dies fällt im Normalfall in den Aufgabenbereich des DBA und wird zusammen mit den Datenbankdesignern durchgeführt. Seite 37

38 Der Konzeptuelle Entwurf- Das Entity-Relationship-Modell (ERM) Das Entity-Relationship-Modell wird häufig für den konzeptuellen Entwurf eingesetzt. Der Begriff des Entity-Relationship-Modells geht zurück auf den grundlegenden Artikel von P.P.Chen im Jahre 1976: The Entity-Relationship Model-Toward a Unified View of Data in ACM Transcations on Database Systems, Band 1, Nr. 1 Ein ER-Schema ist eine graphische Repräsentation der konzeptuellen Modellierung der Daten. Das ERM basiert auf den drei Grundkonzepten Entity als zu modellierende Informationseinheit, Relationship zur Modellierung von Beziehungen zwischen den Enities und Attribut als Eigenschaft von einer Entity oder einer Relationship. Seite 38

39 Entity bzw. Entität Objekt der realen Welt, über das Informationen zu speichern sind, z.b. Produkt, Kunde, Bestellungen, Artikel. Relationship Beschreibt eine Beziehung zwischen Entities, z.b. ein Kunde bestellt n Produkte Attribut Repräsentiert eine Eigenschaft einer Entity, z.b. Kunde hat Namen Seite 39

40 Verwendete Symbole im ER-Modell Für die Modellierung gibt es keinen einheitlichen Standard. Es gibt mehrere Darstellungsformen. Wir verwenden die Folgende: Entities bzw. Entitäten werden durch Rechtecke repräsentiert: Student Attribute werden durch Ellipsen repräsentiert: Name Eindeutige Attribute werden unterstrichen. Seite 40

41 Relationship werden durch Rauten repräsentiert: Student besucht Vorlesung Seite 41

42 Beispiel für eine Entwicklung eines ER-Modells Eine Hochschule möchte eine Struktur in ihre Daten bringen. Studenten, Fachbereiche, Mitarbeiter, Studiengänge sollen sinnvoll mit ihren Beziehungen zueinander abgelegt werden. Vorgehensweise 1. Zunächst bildet man eine erste intuitive Entity-Struktur, Entities wären Student, Fachbereich, Mitarbeiter, Studiengang. 2. Untersuchung der wichtigen Beziehungen zwischen diesen Entitäten. Seite 42

43 Folgende Beziehungstypen (Kardinalitäten) sind möglich Beziehungstyp 1:N Dieser Typ liegt vor, wenn zu einem Wert eines Entities A mehrere Werte eines anderen Entities B in Beziehung stehen, umgekehrt aber jeder Wert von B genau zu einem Wert von A in Beziehung steht. 1 N Bsp. Fachbereich hat Studiengang Ein Fachbereich hat mehrere Studiengänge, 1 Studiengang gehört zu einem Fachbereich Seite 43

44 Beziehungstyp N:M Dieser Typ liegt vor, wenn zu einem Wert eines Entities ein oder beliebig viele Werte eines anderen Entities in Beziehung stehen und umgekehrt (many to many). Beispiel Student N hat M Studiengang Ein Student kann für mehrere Studiengänge (M) eingeschrieben sein, ein Studiengang hat mehrere Studenten (N). Seite 44

45 Beziehungstyp 1:1 Dieser Typ liegt vor, wenn jeder Wert eines Entities A genau zu einem Wert eines anderen Entities B eine Beziehung hat und umgekehrt. Beispiel Mitarbeiter 1 1 leitet Fachbereich Ein Mitarbeiter (Dekan) leitet einen Fachbereich, ein Fachbereich wird von einem Mitarbeiter geleitet. Seite 45

46 Kann- oder Muss-Beziehung Es ist außerdem wichtig zu überprüfen, ob eine Beziehung optional (kann- Beziehung) oder obligatorisch (muss-beziehung) ist. Eine kann-beziehung wird symbolisch durch ein Beziehung durch ein ausgedrückt, eine muss- Beispiel Mitarbeiter 1 1 leitet Fachbereich Ein Mitarbeiter kann einen Fachbereich leiten (dies ist der Mitarbeiter Dekan), ein Fachbereich muss von einem Mitarbeiter geleitet werden. Seite 46

47 Fachbereich 1 N hat Mitarbeiter Ein Fachbereich muss N (d.h. mindestens 1) Mitarbeiter haben, ein Mitarbeiter gehört zu genau einem Fachbereich. Seite 47

48 Grad der Beziehung An einer Beziehung können mehrer Entities beteiligt sein. Von einer Binären Beziehung spricht man, wenn genau zwei Entities beteiligt sind. Fachbereich 1 N hat Mitarbeiter Sind drei oder mehr Entities beteiligt, so spricht man von einer Tenären bzw. n-ären Beziehung. Seite 48

49 Beispiel für eine Tenäre Beziehung Projekt N hat M Mitarbeiter P Qualifikation Seite 49

50 Ist nur eine einzige Entity an einer Beziehung beteiligt, so spricht man von einer rekursiv binären Beziehung. Mitarbeiter 1 verheiratet 1 Mitarbeiter Ein Mitarbeiter kann mit einem Mitarbeiter verheiratet sein. Eine andere Darstellungsform für eine rekursiv binäre Beziehung ist 1 Mitarbeiter 1 verheiratet Seite 50

51 Spezialisierung und Aggregation Unter einer Spezialisierung versteht man, wenn eine Teilmenge (Subtyp) weitere Attribute gegenüber der Grundmenge (Supertyp) hat. Die Entity Supertyp ist dann die Generalisierung, die Subtypen- Entities sind die Spezialisierung. Supertyp IS-A Subtyp Seite 51

52 Beispiel für eine Spezialisierung Laborassistent Mitarbeiter IS-A d Sekretär Professor Techniker Das d in der Beziehung gibt an, dass die Mengen disjunkt sind. Seite 52

53 Aggregation Datenbankanwendung PART-OF GUI DBS Dokumentation Von Aggregation spricht man, wenn ein Entity aus mehreren eigenständigen Entities zusammengesetzt ist. Seite 53

54 Redundante Beziehungen Bei der ER-Modellierung muss darauf geachtet werden, dass keine Redundanten Beziehung in dem Modell existieren. Hat man alle Einzelbeziehungen zwischen den Entities untersucht, dann setzt man die Beziehungen zu einem gesamten ER-Modell zusammen. Dort muss jeder geschlossene Kreis auf Redundanzen überprüft werden. Sind Redundanzen vorhanden, müssen diese im Modell bereinigt werden. Seite 54

55 Diese und die nächste Folie zeigen geschlossene Kreis-Beziehungen im Modell. Beim ersten geschlossenen Kreis handelt es sich um eine redundante Beziehung, der zweite Kreis stellt nicht-redundante Beziehungen dar. Kunde 1 erteilt N Auftrag N N bestellt redundante Beziehung enthält M Artikel M Seite 55

56 Kunde 1 erteilt N Auftrag N N bevorzugt nicht-redundante Beziehung enthält M M Artikel Die Beziehung bevorzugt drückt nun etwas anderes aus. Diese Beziehung wäre beispielsweise wichtig um Kundenverhalten zu analysieren. Seite 56

57 Ein ER-Modell (hier sind nicht die Attribute eingezeichnet) für unser Hochschulbeispiel könnte dann wie folgt aussehen: Studiengang N hat 1 Fachbereich M 1 1 hat hat leitet N N 1 1 Student 1 ist 1 Mitarbeiter IS-A 1 verheiratet Laborassistent Sekretär Professor Techniker Seite 57

58 Die Beziehung Student- Studiengang sieht dann mit den Attributen wie folgt aus Studiengang StudGangBez M StudGangNr hat N Student Geburtstag Name MatrNr Seite 58

59 Das Logische Modell - Die Übertragung der Beziehungen in Tabellen Nachdem das Konzeptuelle Modell erstellt ist, folgt die Übertragung auf ein logisches Modell. Wir verwenden ein Relationales DBMS, d.h. die Beziehungen im ER-Modell werden in Tabellen überführt. Für den Aufbau einer Tabelle kann man folgende Kurzschreibweise wählen: Entitätsname(Id-Schlüssel,Attribut 1, Attribut 2,, Attribut n) Der Tabellenname wird fett gedruckt, der Id-Schlüssel wird unterstrichen. Falls der Id-Schlüssel aus zusammengesetzten Attributen besteht, werden alle zur Bildung des Id-Schlüssels erforderlichen Attribute unterstrichen. Seite 59

60 Ein Attribut ohne Attributwert besitzt einen sog. Nullwert. Nullwerte dürfen in Fremdschlüsseln zunächst nicht vorhanden sein, da ein Fremdschlüsselattributwert immer im Wertebereich des entsprechenden Id-Schlüssels liegen muss. (Wir werden später Fälle betrachten, bei denen Nullwerte dennoch sinnvoll sind.) Seite 60

61 Alle Beziehungstypen werden wir anhand eines fiktiven Beispiels mit den Entities Person und Haustier durchführen. Die beiden Tabellen haben den folgenden Aufbau Person (PNr, Name, Vorname) Haustier(TNr, Art, Rasse, Alter) Seite 61

62 Die 1:1- Beziehung Eine Person hat also 1 Haustier, ein Haustier gehört einer Person. a) Beziehungstyp Person 1 1 hat Haustier Eine Person hat genau 1 Haustier, ein Haustier gehört zu genau einer Person. Seite 62

63 Übertragen auf Tabellen: 1. Möglichkeit Es entstehen 2 Tabellen (Person und Haustier). Der Id-Schlüssel der Tabelle Haustier wird zum Fremdschlüssel der Tabelle Person (umgekehrt geht natürlich auch). Kurzschreibweise: Person (PNr, Name, Vorname, TNr) Haustier (TNr, Art, Rasse, Alter) Seite 63

64 Person PNr Name Vorname TNr 1 Meier Kai 2 2 Müller Ute 5 Person 1 1 hat Haustier 3 Becker Inga 4 4 Kohnen Bernd 1 5 Laufer Thomas 3 Haustier zu jedem Tupel in Person gibt es genau ein Tupel in Haustier TNr Art Rasse Alter 1 Vogel Papagei 20 2 Hund Boxer 1 3 Hund Dackel 10 4 Fisch Goldfisch 0,5 5 Katze Siam 7 Seite 64

65 2. Möglichkeit Man fasst beide Entities zu einer Tabelle Haustierbesitzer zusammen Kurzschreibweise: Haustierbesitzer (PNr, Name, Vorname, Art, Rasse, Alter) Dies ist nur erlaubt, wenn die Tabelle Haustiere nicht noch mit anderen Tabellen in Beziehung steht, da es nun keinen Id-Schlüssel TNr mehr gibt. Seite 65

66 Haustierbesitzer PNr Name Vorname Art Rasse Alter 1 Meier Kai Hund Boxer 1 2 Müller Ute Katze Siam 7 3 Becker Inga Fisch Goldfisch 0,5 4 Kohnen Bernd Vogel Papagei 20 5 Laufer Thomas Hund Dackel 10 Seite 66

67 b) Beziehungstyp Person 1 1 hat Haustier Eine Person kann höchstens 1 (kein oder genau ein) Haustier haben, ein Haustier gehört zu genau einer Person. Seite 67

68 Übertragen auf Tabellen: Es entstehen 2 Tabellen (Person und Haustier). 1. Möglichkeit In der Tabelle Haustier wird der Fremdschlüssel PNr eingefügt. Kurzschreibweise: Person (PNr, Name, Vorname) Haustier (TNr, Art, Rasse, Alter, PNr) Seite 68

69 Person PNr Name Vorname 1 Meier Kai 2 Müller Ute Es gibt Tupel in Person, die keinen Bezug zu einem Tupel in Haustier haben 3 Becker Inga 4 Kohnen Bernd 5 Laufer Thomas Person 1 1 hat Haustier Haustier TNr Art Rasse Alter PNr 1 Vogel Papagei Hund Boxer Hund Dackel 10 4 jedes Tupel in Haustier hat genau ein zugehöriges Tupel in Person Seite 69

70 2. Möglichkeit Da der Fremdschlüssel PNr in Haustier nur eindeutige Attributwerte annehmen kann, wird er gleichzeitig Id-Schlüssel für die Tabelle Haustier. Kurzschreibweise: Person (PNr, Name, Vorname) Haustier (PNr, Art, Rasse, Alter) Seite 70

71 Person PNr Name Vorname 1 Meier Kai 2 Müller Ute Es gibt Tupel in Person, die keinen Bezug zu einem Tupel in Haustier haben 3 Becker Inga 4 Kohnen Bernd 5 Laufer Thomas Person 1 1 hat Haustier Haustier Art Rasse Alter PNr Vogel Papagei 20 3 Hund Boxer 1 1 Hund Dackel 10 4 jedes Tupel in Haustier hat genau ein zugehöriges Tupel in Person Seite 71

72 c) Beziehungstyp Person 1 1 hat Haustier Eine Person kann höchstens 1 (kein oder genau ein) Haustier haben, ein Haustier gehört zu höchstens einer Person. Seite 72

73 Übertragen auf zwei Tabellen: In der Tabelle Person wird der Fremdschlüssel TNr, in der Tabelle Haustiere der Fremdschlüssel PNr verwendet. PNr Name Vorname TNr 1 Meier Kai 2 2 Müller Ute 3 Becker Inga 4 4 Kohnen Bernd 1 5 Laufer Thomas TNr Art Rasse Alter PNr 1 Vogel Papagei Hund Boxer Hund Dackel 10 4 Fisch Goldfisch 0,5 3 5 Katze Siam 7 Hier sind Nullwerte in den Fremdschlüsseln, daher Transformation erforderlich. Seite 73

74 Übertragen der Beziehung auf Tabellen ( ohne Nullwerte im Fremdschlüssel): Person 1 1 hat Haustier Es entstehen 3 Tabellen (Person, Haustier, Tierhalter ). In der Tabelle Tierhalter existieren nur diejenigen Tupel, die eine 1:1 (muss) Beziehung zwischen den Tabellen Person und Haustier herstellen. Der Id-Schlüssel der Tabelle Tierhalter wird aus den Fremdschlüsseln PNr und TNr gebildet. Jeder Attributwert der Attribute TNr und PNr darf in Tierhalter nur einmal vorkommen, daher reicht auch einer dieser Attribute als Id-Schlüssel aus. Seite 74

75 Kurzschreibweise: Person (PNr, Name, Vorname) Haustier (TNr, Art, Rasse, Alter) Tierhalter (TNr,PNr) Seite 75

76 Person PNr Name Vorname 1 Meier Kai 2 Müller Ute 3 Becker Inga 4 Kohnen Bernd 5 Laufer Thomas Tierhalter PNr TNr Haustier TNr Art Rasse Alter 1 Vogel Papagei 20 2 Hund Boxer 1 3 Hund Dackel 10 4 Fisch Goldfisch 0,5 5 Katze Siam 7 Person hat Tierhalter 1 Haustier 1 Seite 76

77 Die 1:N- Beziehung Eine Person hat also N Haustiere, ein Haustier gehört einer Person. a) Beziehungstyp Person 1 N hat Haustier Eine Person muss N (d.h. mindestens 1) Haustier haben, ein Haustier gehört zu genau einer Person. Seite 77

78 Übertragen auf Tabellen: Es entstehen 2 Tabellen (Person und Haustier). Der Id-Schlüssel der Tabelle Person wird zum Fremdschlüssel der Tabelle Haustier. Kurzschreibweise: Person (PNr, Name, Vorname) Haustier (TNr, Art, Rasse, Alter, PNr) Seite 78

79 Die Tabellen haben folgende Eigenschaften: Ein Tupel der Tabelle Person hat eine Beziehung mit mehreren Tupeln aus der Tabelle Haustier. Die Tabelle Haustier besitzt mindestens gleich viele Tupel wie die Tabelle Person. Der Fremdschlüssel PNr in der Tabelle Haustier kann den selben Attributwert mehrmals annehmen. Jeder Attributwert des Attributs PNr aus der Tabelle Person muss mindestens einmal als Fremdschlüssel in Haustier vertreten sein. Seite 79

80 Person PNr Name Vorname 1 Meier Kai 2 Müller Ute 3 Becker Inga 4 Kohnen Bernd Person 1 N hat Haustier 5 Laufer Thomas Haustier TNr Art Rasse Alter PNr 1 Vogel Papagei Hund Boxer Hund Dackel Fisch Goldfisch 0,5 2 5 Katze Siam Pferd Araber Reptil Schlange 30 4 Seite 80

81 b) Beziehungstyp Person 1 N hat Haustier Eine Person kann N (d.h. 0, 1 oder mehr) Haustier haben, ein Haustier gehört zu genau einer Person. Seite 81

82 Übertragen auf Tabellen: Es entstehen 2 Tabellen (Person und Haustier). Der Id-Schlüssel der Tabelle Person wird zum Fremdschlüssel der Tabelle Haustier. Kurzschreibweise: Person (PNr, Name, Vorname) Haustier (TNr, Art, Rasse, Alter, PNr) Seite 82

83 Die Tabellen haben folgende Eigenschaften: Der Fremdschlüssel PNr in der Tabelle Haustier kann die gleichen Attributwerte mehrmals verwenden. In der Tabelle Haustier existieren nur Tupel, die einen Bezug zur Tabelle Person aufweisen. In der Tabelle Person können Tupel stehen, deren Id-Schlüsselwert nicht im Fremdschlüssel PNr der Tabelle Haustier vorkommt. Seite 83

84 Person PNr Name Vorname 1 Meier Kai 2 Müller Ute 3 Becker Inga 4 Kohnen Bernd 5 Laufer Thomas Haustier Person 1 N hat Tupel mit PNr 4 besitzt in Haustier keinen Datensatz Haustier TNr Art Rasse Alter PNr 1 Vogel Papagei Hund Boxer Hund Dackel Fisch Goldfisch 0,5 2 5 Katze Siam Pferd Araber Reptil Schlange 30 2 Seite 84

85 c) Beziehungstyp Person 1 N hat Haustier Eine Person muss N (d.h. mindestens 1) Haustier haben, ein Haustier hat höchstens einen (d.h. keinen oder genau einen) Besitzer. Seite 85

86 Übertragen auf Tabellen: Würde man wieder die zwei Tabellen Person und Haustier wählen und die Beziehung abbilden, so ergäbe sich die Eigenschaften wie im Beziehungsfall a) mit der Besonderheit: In der Tabelle Haustier können auch Tupel auftreten, die zu keinem Tupel in der Tabelle Person einen Bezug haben. Das folgende Beispiel zeigt die Übertragung der Beziehung mit Hilfe von zwei Tabellen: Seite 86

87 Person PNr Name Vorname 1 Meier Kai 2 Müller Ute 3 Becker Inga 4 Kohnen Bernd Haustier TNr Art Rasse Alter PNr 1 Vogel Papagei Hund Boxer Hund Dackel 10 4 Fisch Goldfisch 0,5 2 5 Katze Siam Pferd Araber 3 7 Reptil Schlange 30 4 Das Attribut PNr, d.h. der Fremdschlüssel hat Null-Werte. Seite 87

88 Die Abbildung der Beziehung c) mit Hilfe von zwei Tabellen führt zu Nullwerten im Fremdschlüssel PNr. Dies sollte vermieden werden. Daher muss die Beziehung c) transformiert werden: Es wird eine weitere Tabelle Tierhalter angelegt. Seite 88

89 Übertragen der Beziehung auf Tabellen ( ohne Nullwerte im Fremdschlüssel): Person 1 N hat Haustier Es entstehen 3 Tabellen (Person, Haustier, Tierhalter ). Der Id-Schlüssel der Tabelle Person wird zum Fremdschlüssel der Tabelle Tierhalter. Der Id-Schlüssel der Tabelle Haustier ist gleichzeitig Id-Schlüssel der Tabelle Tierhalter. Kurzschreibweise: Person (PNr, Name, Vorname) Haustier (TNr, Art, Rasse, Alter) Tierhalter (TNr,PNr) Seite 89

90 Die drei Tabellen haben folgende Eigenschaften: Zu jedem Tupel in der Tabelle Person muss es mindestens ein Tupel in der Tabelle Tierhalter geben. Ein Haustier muss dagegen keinen Tierhalter haben. Seite 90

91 Person PNr Name Vorname 1 Meier Kai 2 Müller Ute 3 Becker Inga 4 Kohnen Bernd Tierhalter PNr TNr Haustier TNr Art Rasse Alter 1 Vogel Papagei 20 2 Hund Boxer 1 3 Hund Dackel 10 4 Fisch Goldfisch 0,5 5 Katze Siam 7 6 Pferd Araber 3 7 Reptil Schlange 30 Person 1 N 1 N hat Tierhalter 1 Haustier 1 Seite 91

92 d) Beziehungstyp Person 1 N hat Haustier Eine Person kann N (d.h. kein, ein oder mehr) Haustiere haben, ein Haustier hat höchstens einen (d.h. keinen oder genau einen) Besitzer. Seite 92

93 Übertragen auf Tabellen: Würde man wieder die zwei Tabellen Person und Haustier wählen und die Beziehung dort abbilden, so ergäben sich wieder Nullwerte im Fremdschlüssel Das folgende Beispiel zeigt die Übertragung der Beziehung mit Hilfe von zwei Tabellen: Seite 93

94 Person PNr Name Vorname 1 Meier Kai 2 Müller Ute 3 Becker Inga 4 Kohnen Bernd Zu diesem Tupel gibt es kein Haustier Haustier TNr Art Rasse Alter PNr 1 Vogel Papagei Hund Boxer Hund Dackel 10 4 Fisch Goldfisch 0,5 2 5 Katze Siam Pferd Araber 3 7 Reptil Schlange 30 4 Das Attribut PNr, d.h. der Fremdschlüssel hat Null-Werte. Diese Tupel gehören zu keiner Person. Seite 94

95 Übertragen der Beziehung auf Tabellen ( ohne Nullwerte im Fremdschlüssel): Person 1 N hat Haustier Es entstehen 3 Tabellen (Person, Haustier, Tierhalter ). Der Id-Schlüssel der Tabelle Person wird zum Fremdschlüssel der Tabelle Tierhalter. Der Id-Schlüssel der Tabelle Haustier ist gleichzeitig Id-Schlüssel der Tabelle Tierhalter. Kurzschreibweise: Person (PNr, Name, Vorname) Haustier (TNr, Art, Rasse, Alter) Tierhalter (TNr,PNr) Seite 95

96 Die Tabellen haben folgende Eigenschaften: Im Fremdschlüssel TNr der Tabelle Tierhalter darf jeder Attributwert nur einmal vorkommen Im Fremschlüssel PNr der Tabelle Tabelle Tierhalter darf der gleiche Attributwert mehrmals vorkommen Das Attribut TNr bildet den Id-Schlüssel für die Tabelle Tierhalter. Seite 96

97 Person PNr Name Vorname Tierhalter PNr TNr 1 Meier Kai Müller Ute Becker Inga Kohnen Bernd Haustier TNr Art Rasse Alter 1 Vogel Papagei 20 2 Hund Boxer 1 3 Hund Dackel 10 4 Fisch Goldfisch 0,5 5 Katze Siam 7 6 Pferd Araber 3 7 Reptil Schlange 30 Person 1 N 1 N hat Tierhalter 1 Haustier 1 Seite 97

98 Die N:M- Beziehung Eine Person hat M Haustiere, ein Haustier gehört N Personen. a) Beziehungstyp Person N hat M Haustier Eine Person hat mehrere (mindestens ein) Haustier, ein Haustier gehört zu mehreren (mindestens einer) Person. Seite 98

99 Übertragen auf Tabellen: Auch dieser Beziehungstyp muss transformiert werden. Eine Abbildung des Beziehungstyps in 2 Tabellen, würde zu Mehrfacheinträgen in beiden Tabellen führen. Beispiel: Die Personen Kai Meier und Ute Müller sind beide Besitzer des Haustieres Papagei mit Alter 20. Seite 99

100 Person PNr Name Vorname 1 Meier Kai 2 Müller Ute 3 Becker Inga Die Beziehung ist korrekt dargestellt, aber: Doppelte Datensätze gefährden die Datenkonsistenz. Haustier TNr Art Rasse Alter PNr 1 Vogel Papagei Hund Boxer Hund Dackel Fisch Goldfisch 0,5 1 1 Vogel Papagei Fisch Goldfisch 0,5 2 4 Fisch Goldfisch 0,5 3 Seite 100

101 Daher Transformation der Beziehung: Person N hat M Haustier Es entstehen 3 Tabellen (Person, Haustier, Tierhalter ). Der Id-Schlüssel der Tabelle Tierhalter setzt sich zusammen aus dem Attribut PNr und TNr. Kurzschreibweise: Person (PNr, Name, Vorname) Haustier (TNr, Art, Rasse, Alter) Tierhalter (PNr,TNr) Seite 101

102 Person PNr Name Vorname 1 Meier Kai 2 Müller Ute 3 Becker Inga Haustier Tierhalter PNr TNr Nur eine Kombination aus PNr und TNr kann in dieser Tabelle der Id-Schlüssel sein TNr Art Rasse Alter 1 Vogel Papagei 20 2 Hund Boxer 1 3 Hund Dackel 10 4 Fisch Goldfisch 0,5 Person 1 N hat M Haustier 1 Alle Tupel in den Tabellen sind nun verschieden M Tierhalter N Seite 102

103 b) Beziehungstyp Person N hat M Haustier Eine Person kann mehrere (kein, ein oder mehrere) Haustier haben, ein Haustier gehört mehreren (mindestens einer) Personen. Seite 103

104 Übertragung auf Tabellen Die Beziehung ist ähnlich wie die Beziehung vom Typ a). In der Tabelle Person können allerdings auch Tupel existieren, die keinen Bezug zu einem Tupel in Tabelle Haustier besitzen. Person PNr Name Vorname 1 Meier Kai 2 Müller Ute 3 Becker Inga 4 Kohnen Bernd Diese Person besitzt kein Haustier Haustier Der Goldfisch hat mehrere Besitzer TNr Art Rasse Alter PNr 1 Vogel Papagei Hund Boxer Hund Dackel Fisch Goldfisch 0,5 1 1 Vogel Papagei Fisch Goldfisch 0,5 2 4 Fisch Goldfisch 0,5 3 Seite 104

105 Um auch hier Doppelspeicherung zu vermeiden, muss transformiert werden Person N hat M Haustier Es entstehen 3 Tabellen (Person, Haustier, Tierhalter ). Kurzschreibweise: Person (PNr, Name, Vorname) Haustier (TNr, Art, Rasse, Alter) Tierhalter (PNr,TNr) Seite 105

106 Person PNr Name Vorname 1 Meier Kai 2 Müller Ute 3 Becker Inga 4 Kohnen Bernd Haustier TNr Art Rasse Alter 1 Vogel Papagei 20 2 Hund Boxer 1 3 Hund Dackel 10 4 Fisch Goldfisch 0,5 Tierhalter PNr TNr Nur eine Kombination aus PNr und TNr kann in dieser Tabelle der Id-Schlüssel sein N M Person hat Haustier Alle Tupel in den Tabellen sind nun verschieden 1 1 M Tierhalter N Seite 106

107 c) Beziehungstyp Person N hat M Haustier Eine Person kann mehrere (kein, ein oder mehrere) Haustier haben, ein Haustier kann mehreren Personen gehören. Seite 107

108 Übertragung auf Tabellen Die Beziehung ist ähnlich wie die Beziehung vom Typ a) und b). In der Tabelle Haustier können allerdings auch Tupel existieren, die keinen Bezug zu einem Tupel in Tabelle Person besitzen. Person PNr Name Vorname 1 Meier Kai 2 Müller Ute 3 Becker Inga 4 Kohnen Bernd Diese Person besitzt kein Haustier Haustier Der Hund hat keinen Besitzer TNr Art Rasse Alter PNr 1 Vogel Papagei Hund Boxer 1 3 Hund Dackel Fisch Goldfisch 0,5 1 1 Vogel Papagei Fisch Goldfisch 0,5 2 4 Fisch Goldfisch 0,5 3 Seite 108

109 Hier tauchen also zwei Probleme auf: Doppelspeicherung und Nullwerte im Fremdschlüssel. Person N hat M Haustier Also muss transformiert werden: Es entstehen 3 Tabellen (Person, Haustier, Tierhalter ). Kurzschreibweise: Person (PNr, Name, Vorname) Haustier (TNr, Art, Rasse, Alter) Tierhalter (PNr,TNr) Seite 109

110 Person PNr Name Vorname 1 Meier Kai 2 Müller Ute 3 Becker Inga 4 Kohnen Bernd Haustier TNr Art Rasse Alter 1 Vogel Papagei 20 2 Hund Boxer 1 3 Hund Dackel 10 4 Fisch Goldfisch 0,5 Tierhalter PNr TNr Alle Tupel in den Tabellen sind nun verschieden Nur eine Kombination aus PNr und TNr kann in dieser Tabelle der Id-Schlüssel sein N M Person hat Haustier Alle Tupel in den Tabellen sind nun verschieden 1 1 M Tierhalter N Seite 110

111 Rekursiv binäre Beziehung Auf den nächsten Folien wird die Überführung zweier möglicher rekursiver Beziehungen dargestellt: Beispiel 1 1 Mitarbeiter 1 verheiratet Seite 111

112 1. Möglichkeit der Umsetzung in Tabellenform Eine Tabelle der Form Mitarbeiter (MID, Name, Vorname, VID), wobei VID Fremdschlüssel ist, der aus dem Id-Schlüssel MID von Mitarbeiter gebildet wird. Hier entstehen sehr viele NULL-Werte im Fremdschlüssel, da solche Ehen sehr selten sind. Daher sollte diese Variante nicht gewählt werden. Seite 112

113 2. Möglichkeit der Umsetzung in Tabellenform Zwei Tabellen der Form Mitarbeiter (MID, Name, Vorname), MitarbeiterEhe (MID1, MID2, verheiratet_seit), wobei MID1 und MID2 Fremdschlüssel sind, die aus dem Id-Schlüssel MID von Mitarbeiter gebildet werden. Seite 113

114 3. Möglichkeit der Umsetzung in Tabellenform Drei Tabellen der Form Mitarbeiter (MID, Name, Vorname), EheName (EID, Name), MitarbeiterEhe (MID, EID). Bemerkung Bei dieser Variante sind die Namen der Fremdschlüssel stets identisch mit dem Namen des zugehörigen Id-Schlüssels. In der Praxis würde man aber bei diesem Beispiel die Variante 2 vorziehen. Seite 114

115 Beispiel 2 Mitarbeiter 1 N leitet Ein Mitarbeiter wird von genau einem Mitarbeiter (dies ist der Abteilungsleiter) geleitet, ein Mitarbeiter kann N Mitarbeiter leiten. Seite 115

116 1. Möglichkeit der Umsetzung in Tabellenform Eine Tabelle der Form Mitarbeiter (MNr, LNr, Name, Vorname), wobei LNr Fremdschlüssel ist, der aus dem Id-Schlüssel MNr von Mitarbeiter gebildet wird. MNr LNr Name Vorname 1 4 Schmidt Uwe 2 4 Müller Anke 3 3 Meier Bettina 4 3 Dicke Malte 5 3 Becker Ingo 6 3 Fischer Volker 7 4 Bauer Ute Meier, Bettina ist Chefin, d.h. sie wird von sich selbst geleitet Nachteil: Um zu Überprüfen, ob z. B. Volker Fischer Abteilungsleiter ist, müssen alle Attributwert von LNr auf den Eintrag 6 untersucht werden. Seite 116

117 2. Möglichkeit der Umsetzung in Tabellenform Zwei Tabellen der Form Mitarbeiter (MNr, LNr, Name, Vorname), Abteilungsleiter (LNr, MNr). Mitarbeiter MNr LNr Name Vorname 1 2 Schmidt Uwe 2 2 Müller Anke 3 1 Meier Bettina 4 1 Dicke Malte 5 1 Becker Ingo 6 1 Fischer Volker 7 2 Bauer Ute Abteilungsleiter LNr MNr Nachteil: Hier hängt der Id-Schlüssel MNr vom Fremdschlüssel LNr ab und umgekehrt hängt der Id-Schlüssel LNr vom Fremdschlüssel MNr ab. Seite 117

118 3. Möglichkeit der Umsetzung in Tabellenform Drei Tabellen der Form Mitarbeiter (MNr, ANr, Name, Vorname), Abteilung (ANr, Name) Abteilungsleiter (ANr, MNr). Seite 118

119 Abteilung ANr Name 1 Bo1 Operativ Mitarbeiter 2 Bo1P Projekte Abteilungsleiter MNr ANr MNr Anr Name Vorname 1 2 Schmidt Uwe 2 2 Müller Anke 3 1 Meier Bettina 4 1 Dicke Malte 5 1 Becker Ingo 6 1 Fischer Volker 7 2 Bauer Ute Seite 119

120 Tabellendarstellung für Ternäre- Beziehungen bzw. n-äre Beziehungen Als Beispiel betrachten wir die folgende Ternäre-Beziehung Projekt N hat M Mitarbeiter P Qualifikation Um jede Beziehung abzubilden, müssen zusätzlich zu den 3 Entities 3 weitere Beziehungstabellen gebildet werden. Seite 120

121 Mitarbeiter MNr Name Vorname 1 Schmidt Uwe 2 Müller Anke 3 Meier Bettina 4 Dicke Malte 5 Becker Ingo 6 Fischer Volker 7 Bauer Ute ProjektMitarbeiter MNr PNr ProjektQualifikation PNr QNr Beziehungstabellen Projekt PNr Name StDat Laufzeit 1 CostPlus EasyGo MaQualifikation MNr QNr Qualifikation QNr Name 1 C++ 2 Oracle 3 Project Manager 4 GUI-Designer 5 Business Analyst Seite 121

122 Die Tabellen haben die Form Mitarbeiter (MNr, Name, Vorname), Projekt (PNr, Name, StDat,Laufzeit) Qualifikation (QNr, Name), MaQualifikation (MNr, QNr) ProjektQualifikation (PNr, QNr) ProjektMitarbeiter (MNr, PNr) Die Tabellen geben nun z.b. Auskunft über Mitarbeiter, die in keinem Projekt sind Alle Qualifikationen eines Mitarbeiters Die Qualifikationen, die im Projekt benötigt werden Seite 122

123 Auch die Abbildung mit Hilfe einer einzigen Beziehungstabelle ist möglich. Allerdings werden jetzt nicht alle Informationen abgebildet. Informationen, die verloren gehen: Qualifikationen von Mitarbeiter, die in keinem Projekt sind Alle Qualifikationen eines Mitarbeiters Seite 123

124 Mitarbeiter MNr Name Vorname 1 Schmidt Uwe 2 Müller Anke 3 Meier Bettina 4 Dicke Malte 5 Becker Ingo 6 Fischer Volker 7 Bauer Uter Beziehungstabelle Projekt Projektressourcen PNr Name StDat Laufzeit 1 CostPlus EasyGo PNr MNr QNr Qualifikation QNr Name 1 C++ 2 Oracle 3 Project Manager 4 GUI-Designer 5 Business Analyst Seite 124

125 Generalisierung / Spezialisierung (IS-A) Die spezialisierten Tabellen, d.h. die Subtypen (hier Laborassistent, Sekretär etc) haben weitere Attribute gegenüber der Grundmenge, d.h. dem Supertyp (hier Mitarbeiter). Die entstehenden Subtypen können die Grundmenge total oder partiell überdecken sowie disjunkt oder nicht disjunkt sein. Laborassistent Mitarbeiter IS-A d Sekretär Professor Techniker Seite 125

126 Übertragen der Generalisierung auf Tabellen Zusätzlich zur Tabelle für die Grundmenge wird eine weitere Tabelle für jede Teilmenge angelegt, die denselben Id-Schlüssel wie die Grundmenge hat. In unserem Beispiel würden also zusätzlich zur Tabelle Mitarbeiter vier weitere Tabellen angelegt, wobei jede dieser Tabellen denselben Id-Schlüssel wie die Tabelle Mitarbeiter hat. Zusätzlich haben die Subtyp-Tabellen weitere charakteristische Attribute. Beispiel: Mitarbeiter IS-A Laborassistent Mitarbeiter (MaNr, Name, Vorname) Laborassistent(MaNr, Labor) Seite 126

127 Totale Überdeckung der Grundmenge Man spricht von einer totalen Überdeckung der Grundmenge, wenn die Entitätsmenge des Supertyps vollständig aus der Entitätsmenge der Subtypen besteht. D.h. in der Tabelle des Supertyps existieren keine Tupel, deren Id-Schlüssel nicht in einer der Tabellen der Subtypen als Fremdschlüssel vorkommt. Seite 127

128 Partielle Überdeckung der Grundmenge Man spricht von einer partiellen Überdeckung der Grundmenge, wenn die Entitätsmenge des Supertyps nur partiell aus der Entitätsmenge der Subtypen besteht. D.h. in der Tabelle des Supertyps existieren Tupel, deren Id-Schlüssel in keiner der Tabellen der Subtypen als Fremdschlüssel vorkommen. Seite 128

129 Disjunkte Überdeckung der Grundmenge Man spricht von einer disjunkten Überdeckung der Grundmenge, wenn die Entitätsmenge des Supertyps sich nicht überschneiden. D.h. zu einem Id-Schlüssel des Supertypen gibt es nur ein Tupel in einem Subtypen. Seite 129

130 Nicht-Disjunkte Überdeckung der Grundmenge Man spricht von einer nicht-disjunkten Überdeckung der Grundmenge, wenn die Entitätsmenge des Supertyps sich überschneiden. D.h. zu einem Id-Schlüssel des Supertypen kann es in mehreren Subtypen ein entsprechendes Tupel geben. Bemerkung: Handelt es sich um disjunkte Mengen, so kann eindeutig angegeben werden, welches Tupel aus dem Supertypen in welchem Subtypen vorkommt. Daher kann in der Supertyp-Tabelle ein sog. diskriminierendes Attribut eingefügt werden, das die Subtyp-Tabelle angibt. Seite 130

131 Anmerkungen zu Null-Werten im Fremdschlüssel Null-Werte im Fremdschlüssel sollten nur verwendet werden, wenn sie die Ausnahme sind. Unter referentieller Integrität versteht man die Bedingung für Fremdschlüssel, dass diese nur Werte annehmen können, die im Wertebereich des entsprechenden Id-Schlüssels liegen (oder NULL sind). Seite 131

132 Die 10 Beziehungstypen Durch die Transformation der einzelnen Beziehungen, können alle Beziehungstypen durch die folgenden 4 Beziehungen ausgedrückt werden: N 1 N Können von einem Datenbankprogramm nicht direkt auf Datendefinitionsebene unterstützt werden. Für die Realisierung dieser Beziehungen ist der Datenbankentwickler zuständig Seite 132

133 Normalisierung Die Normalisierung ist ein wichtiger Prozess in der Datenmodellierung. Die Normalisierung bezweckt die redundanzfreie Speicherung von Informationen innerhalb der Tabellen der Datenbasis. Redundanzfreie Datenspeicherung: Kein Teil eines Datenbestandes kann weggelassen werden, ohne dass dies zu Informationsverlusten führt. Redundanzfreie Speicherung führt zum einen zu Speicherplatzersparnis, zum anderen verhindert es Dateninkonsistenz und Löschanomalie. Seite 133

134 Beispiel: Tabelle mit Redundanzen Redundanzen Kurs_Nr Kurs_Bez Semester Doz_Kürzel Doz_Name 14 Datenbanken WS 04/05 dm Meier 7 Einführung Programmierung SS 05 dm Meier 16 Betriebssysteme I WS 04/05 ib Bauer 9 Verteilte Systeme SS 05 ib Bauer 11 Data-Warehouse SS 05 ak Kühne Seite 134

135 Abhängigkeiten Vorab müssen die unterschiedlichen Abhängigkeiten von Attributen innerhalb einer Relation definiert werden: Es werden drei Abhängigkeiten unterschieden Funktionale Abhängigkeit Volle Abhängigkeit Transitive Abhängigkeit Seite 135

136 Definition Ein Attribut bzw. eine Attributkombination B ist dann von einem Attribut oder einer Attributkombination A funktional abhängig, wenn zu einem bestimmten Attributwert von A genau ein Attributwert von B gehört. Aus dem Attributwert von A ergibt sich also eindeutig der Attributwert von B. Beispiel: In der Tabelle Mitarbeiter (MNr, Name) ist das Attribut Name funktional abhängig vom Attribut MNr. Seite 136

137 Definition Ein Attribut bzw. eine Attributkombination B ist dann von einer Attributkombination A voll abhängig, wenn B nur von A, nicht jedoch von einem Teil der Attributkombination A funktional abhängig ist. Beispiel: In der Tabelle MitarbeiterQualifikation (MNr,QNr, zertifiziert) ist das Attribut zertifiziert voll abhängig von der Kombination MNr und QNr. Es gibt an, ob ein Mitarbeiter für eine entsprechende Qualifikation zertifiziert ist. Das Attribut zertifiziert ist nur von der Kombination MNr und QNr abhängig. Seite 137

138 Definition Ein Attribut bzw. eine Attributkombination C ist von einem Attribut oder einer Attributkombination A transitiv abhängig, wenn das Attribut B von A und das Attribut C von B funktional abhängig ist, aber A nicht von C funktional abhängig ist. Beispiel: In der Tabelle Mitarbeiter (MNr,AbtNr, Abteilung) ist das Attribut Abteilung vom Attribut MNr transitiv abhängig, da Abteilung von AbtNr und AbtNr von MNr funktional abhängig ist. MNr ist von Abteilung aber nicht abhängig. Aus MNr folgt die AbtNr und aus AbtNr folgt die Abteilung. Also erhält man aus MNr auch die Abteilung. Seite 138

139 Der Normalisierungsprozess verläuft schrittweise über die Bildung von sog. Normalformen. Es werden hier die ersten 4 Normalformen vorgestellt. Im Beispiel sollen die unterschiedlichen Bankverbindungen von Firmen sinnvoll dargestellt werden. Bankverbindung Firmenname Sparkasse Frankfurt ( ) Sparda-Bank Kiel ( ) Bau u. Partner Postbank Bochum ( ) Burkhardt Commerzbank Frankfurt ( ) Deutsche Bank Hamburg ( ) Sparkasse Frankfurt ( ) WohnIdee Diese Tabelle hat keine korrekte Form. Seite 139

140 1. Normalform Eine Tabelle befindet sich in der 1. Normalform, wenn alle Attribute nur einfache Attributwerte aufweisen, wobei auch Nullwerte zulässig sind. Nur atomare Merkmalswerte sind erlaubt. Firmenkonto KontoNr BLZ Geldinstitut FID Firmenname Sparkasse Frankfurt 101 Bau und Partner Sparda-Bank Kiel 101 Bau und Partner Postbank Bochum 102 Burkhardt Postbank Bochum 102 Burkhardt Commerzbank Frankfurt 103 WohnIdee Deutsche Bank Hamburg 103 WohnIdee Sparkasse Frankfurt 103 WohnIdee Firmenkonto(KontoNr, BLZ, Geldinstitut, FID, Firmenname) Seite 140

141 2. Normalform Eine Tabelle befindet sich in der 2. Normalform, wenn sie schon in der 1. Normalform ist und jedes nicht zum Id-Schlüssel gehörende Attribut voll vom Id-Schlüssel abhängig ist. Es können sich also nur Tabellen mit zusammengesetzten Id- Schlüsseln in der 2. Normalform befinden. Seite 141

142 2. Normalform Geldinstitut ist nur von BLZ abhängig KontoNr BLZ Geldinstitut FID Firmenname Sparkasse Frankfurt 101 Bau und Partner Sparda-Bank Kiel 101 Bau und Partner Postbank Bochum 102 Burkhardt Postbank Bochum 102 Burkhardt Commerzbank Frankfurt 103 WohnIdee Deutsche Bank Hamburg 103 WohnIdee Sparkasse Frankfurt 103 WohnIdee Die Tabelle befindet sich also nicht in der 2. Normalform. Seite 142

143 2. Normalform FirmenKonto KontoNr BLZ FID Firmenname Bau und Partner Bau und Partner Burkhardt Burkhardt WohnIdee WohnIdee WohnIdee Bank BLZ Geldinstitut Sparkasse Frankfurt Sparda-Bank Kiel Postbank Bochum Commerzbank Frankfurt Deutsche Bank Hamburg Sparkasse Frankfurt Es entstehen 2 Tabellen FirmenKonto(KontoNr, BLZ, FID, Firmenname) Bank(BLZ, Geldinstitut) Seite 143

144 3. Normalform Eine Tabelle befindet sich in der 3. Normalform, wenn sie schon in der 2. Normalform (bzw. mit einfachem Id-Schlüssel in der 1. Normalform) ist und kein Nichtschlüssel-Attribut vom Id-Schlüssel transitiv abhängig ist. Die Attribute innerhalb einer Tabelle sind also nur vom Id-Schlüssel funktional abhängig. Untereinander existieren keine sonstigen funktionalen Abhängigkeiten. Seite 144

145 3. Normalform Die Tabelle Bank befindet sich also schon in der 3. Normalform. Die Tabelle FirmenKonto nicht, da das Attribut Firmenname vom Id- Schlüssel (KontoNr, BLZ) transitiv abhängig ist. KontoNr BLZ FID Firmenname Bau und Partner Bau und Partner Burkhardt Burkhardt WohnIdee WohnIdee WohnIdee Seite 145

146 3. Normalform: keine Abhängigkeiten über Umwege FirmenKonto KontoNr BLZ FID Nun sind alle Tabellen in der 3. Normalform. Bank BLZ Geldinstitut Sparkasse Frankfurt Sparda-Bank Kiel Postbank Bochum Commerzbank Frankfurt Deutsche Bank Hamburg Sparkasse Frankfurt Firma FID Firmenname 101 Bau und Partner 102 Burkhardt 103 WohnIdee Seite 146

147 Tabellen, die sich in der 3. Normalform befinden, werden als normalisiert bezeichnet. Die darin enthaltenen Informationen sind redundanzfrei. Dies gilt allerdings nur innerhalb der Relation und sagt nichts über die Redundaz-Freiheit in der gesamten Datenbasis aus. Seite 147

148 4. Normalform Eine Datenbasis befindet sich in der 4. Normalform, wenn sich alle Tabellen in der 3. Normalform befinden und nur noch lokale und globale Attribute existieren. Auch dürfen die Tabellen keine aus der Datenbasis abgeleiteten Attribute, z.b. Berechnungen enthalten. Seite 148

149 Bemerkung: Es muss auch untersucht werden, ob sich ein Attribut aus Attributen anderer Tabellen ableiten lässt. Beispiel: In Tabelle Rechnung (RechNr, RechDat, NettoWert, MWST, BruttoWert) kann BruttoWert durch NettoWert und MWST berechnet werden. Tabelle befindet sich nicht in der 4 NF. Lösung: Streichen des Attributes BruttoWert. Seite 149

150 Als lokale Attribute einer Tabelle bezeichnet man alle Attribute, die nur innerhalb einer einzigen Tabelle vorkommen und nicht deren Id-Schlüssel bilden, bzw. Bestandteile des Id-Schlüssels sind. Als globale Attribute bezeichnet man alle Attribute, die mindestens in einer Tabelle im Id-Schlüssel vorkommen bzw. den Id-Schlüssel bilden. Seite 150

151 Zusammenfassung der Normalformen 1. Normalform: Tabelle hat nur Attribute mit einfachen Attributwerten. 2. Normalform: Tabelle ist in 1 NF und jedes nicht zum Id-Schlüssel gehörende Attribut ist voll vom Id-Schlüssel abhängig. 3. Normalform: Tabelle ist in 2 NF (bzw. mit einfachem Id-Schlüssel in der 1. Normalform) und kein Nichtschlüssel-Attribut vom Id- Schlüssel transitiv abhängig ist. 4. Normalform: Alle Tabellen sind in der 3. Normalform und nur noch lokale und globale Attribute existieren. Seite 151

152 Ein weiteres Beispiel: Tabellen vor der Normalisierung Kunde (KuNr, Firma, Ort, AufNr) Auftrag (AufNr, AufDat, LiefDat) Artikel (ArtNr, ArtBez, LagNr, LagOrt, LagStr) Position (ArtNr, AufNr, Menge, Preis) Rechnung ( RechNr, RechDat, Nettowert, MWST, Bruttowert, AufNr) Tabellen nachdem Datenbasis in 4 NF gebracht wurde Kunde (KuNr, Firma, OId) Ort (OId, Ort) Auftrag (AufNr, AufDat, LiefDat,KuNr) Artikel (ArtNr, ArtBez, Preis, LagNr) Position (ArtNr, AufNr, Menge) Rechnung ( RechNr, RechDat, AufNr, MWST) Lager (LagNr, LagOrt, LagStr) Seite 152

153 Einige Bemerkung zur Normalisierung: Durch die Normalisierung wird erreicht, dass die Tabellen redundanzfrei sind. Durch das Überführen der Datenbasis in die 4. Normalform erreicht man die redundanz-freie Speicherung der Daten innerhalb der gesamten Datenbasis. Anwenden der Normalformen ist kein Muss, Voraussetzung ist nur, dass die Tabellen mindestens in der 1NF vorliegen. Mit steigendem Normalisierungsgrad werden immer mehr Tabellen erzeugt, so dass das Datenmodell sehr unübersichtlich wird. Dies kann Auswirkungen auf die Performance bei Datenmanipulationen haben. Die 4. Normalform wird in der Praxis meist nicht angewendet. Seite 153

154 Vorgehen beim Datenbankentwurf Beim Entwurf werden zusammenfassend folgende Aktivitäten durchgeführt (es kann, bzw. muss auch wieder zurückgesprungen werden): 1. Definition der Aufgabenstellung Zunächst wird die zu lösende Aufgabenstellung klar umrissen. Dabei können größerer Vorhaben in mehrere kleine Zwischenschritte aufgeteilt werden. Es ist wichtig, sich die Ziele vom Auftraggeber schriftlich bestätigen zu lassen. 2. Informationsbeschaffung Es werden alle für die Anwendung benötigten Informationen gesammelt. 3. Bestimmung der Entities mit ihren Attributen Es werden intuitiv die für die zu lösende Aufgabenstellung benötigten Entities festgelegt. Dabei werden die Daten der Informationsbeschaffung strukturiert, indem zusammengehörige Daten zusammengefasst und einem Oberbegriff zugeordnet werden. Beispiel Firmenadresse und Firmenname zu Oberbegriff Kunde. Seite 154

155 Bei der Strukturierung ist zu beachten, dass - jedes Attribut eines Entities einen direkten Bezug zu diesem Entity hat - alle benötigten Informationen als Entities bzw. Attribute auftauchen - keine berechneten Attribute existieren Bestimmung des Id-Schlüssels Es wird dasjenige Attribut bestimmt, dessen Wert innerhalb des Entities eindeutig ist. Falls kein solches existiert, werden mehrere geeignete Attribute zum Id-Schlüssel zusammengefasst oder ein künstlicher Schlüssel wird angelegt. Ermittlung der Beziehungen Mit Hilfe des ERM werden die Beziehungen zwischen den bisher definierten Entities festgestellt. Seite 155

156 6. Ableiten der Tabellenstruktur aus dem ERM Aus dem ERM werden die Tabellenstrukturen einschließlich der Fremdschlüssel abgeleitet. 7. Überprüfung des Entwurfs mit Hilfe der globalen Normalisierung (bis 4NF). Damit können logische Fehler bei der ERM-Methode festgestellt werden. 8. Festlegung der Datentypen und Formulierung der Konsistenzbedingungen Formulierung der Bedingungen, die von den gespeicherten Daten eingehalten werden müssen. Damit ist sichergestellt, dass die Datenkonsistenz jederzeit erhalten bleibt. 9. Test des Entwurfs Erstellen der Datenbank als Prototyps. Testen anhand eines Testkonzeptes. 10. Transaktionen definieren 11. Anlegen von Benutzersichten und Zugriffsrechte Seite 156

157 Ein Beispiel: Sitzplatzreservierung auf Flügen Aufgabenstellung Die neu gegründete Airline EasyFlight möchte ihr Sitzplatz- Reservierungssystem über eine Datenbankanwendung abbilden. Für ein konkretes Flugereignis soll erfasst werden, welcher Sitzplatz von welchem Kunden reserviert wurde. Dabei gilt: Ein Flugereignis ist ein konkreter Flug an einem bestimmten Datum. Ein Flug ist eindeutig charakterisiert durch eine Flugnummer und einen Wochentag. Ein Flug besteht aus mehreren Teilstrecken (Legs). Die zu reservierenden Sitzplätze sind unterschieden in die Kategorien First, Business und Economy. Seite 157

158 Bildung der Entitätsmengen mit den Attributen Flugzeug Kennzeichen jedes Flugzeug hat ein eindeutiges Kennzeichen Flugzeugtyp Flotte Max_Kapazität Ein Flugzeug gehört einer bestimmten Flotte an, z.b. A340, B gibt die maximale Kapazität, d.h. Personen+Fracht an Seite 158

159 Flug FlugNr WT DepA_F ArrA_F Eine Flugnummer wird nur einmal pro Tag vergeben und beinhaltet nicht den Hin- und Rückflug Wochentag Abflug-Airport Ankunft-Airport Leg LegNr DepA_L ArrA_L Jedes Teilstück bekommt eine Nummer Abflug-Airport des Legs Ankunft-Airport des Legs Seite 159

160 Flugereignis Datum Flug an einem bestimmten Datum Sitz SitzNr Kategorie Bezeichnung Sitzplatznummer F, C oder M z.b. 7D Seite 160

161 Bestimmung bzw. Bildung der Id-Schlüssel Seite 161

162 Festlegen der Beziehungen 1. Alle möglichen, gegenseitigen Beziehungen zwischen den Entitätsmengen sind festzuhalten. Unklare Beziehungen sind anzuschreiben. 2. Streichen von redundanten Beziehungen. 3. Transformation der Beziehungen => Bildung zusätzlicher Entitäten Seite 162

163 Überführung der Beziehung in Tabellenform Flugzeugtyp ( FTID, Flotte, Max_Kapazität) Flugzeug (FID, Kennzeichen, FTID) Flug (FlugID,FlugNr, WT, DepA_F, ArrA_F, FID) Leg (LegID, DepA_L, ArrA_L) FlugLeg(FlugID, LegID) Airport(AID, 3LC, Bezeichnung) Flugereignis (FEID, Datum, LegID, FlugID) Reservierung (RID, FEID, SitzID, Kundenname) Sitz (SitzID, Kategorie, Bezeichnung, FTID ) Anmerkung: DepA_F, ArrA_F, DepA_L, ArrA_L sind Fremdschlüssel und entsprechen AID. Seite 163

164 Überprüfung des Entwurfs auf Normalisierung Zunächst fällt auf, dass Redundanzen in den Tabellen sind, da der Airport zweimal in Tabelle Flug und zweimal in Tabelle Leg auftaucht. Der Abflug-Airport des 1. Legs eines Fluges muss mit dem Abflug-Airport des Fluges übereinstimmen. Ebenso muss der Ankunft-Airport des letzten Legs mit dem Ankunft-Airport des Fluges übereinstimmen. Daher sind DepA_F, ArrA_F in Flug überflüssig. Zusätzlich muss aber eine Kennung eingefügt werden, die eine Reihenfolge der Legs anzeigt. Auch die Tabelle FlugLeg erweist sich als unnötig. Sie liefert keine neuen Informationen. Sind die Tabellen sonst alle in der 3NF, bzw. befindet sich Datenbasis in 4NF? Seite 164

165 Festlegung der Datentypen und Formulierung der Konsistenzbedingungen Beispiel für Datentypen Tabelle Attribut Wertebereich Airport APID Ganze Zahl 3LC Zeichenkette mit 3 Zeichen Bezeichnung Zeichenkette mit 50 Zeichen Sitz SitzID Ganze Zahl Kategorie Bezeichnung Nur Zeichen C, M, F zugelassen Zeichenkette Seite 165

166 Formulierung der Konsistenzbedingungen Bei diesem Schritt geht es darum, Bedingungen zu formulieren, die von den gespeicherten Daten eingehalten werden müssen. Damit ist sichergestellt, dass die Datenkonsistenz jederzeit erhalten bleibt. Seite 166

167 Transaktionen definieren Einige Transaktionen für unser Flugbeispiel A: Einfügen, Löschen und Korrigieren von Reservierungen in der Tabelle Reservierung. B: Einfügen eines Datensatzes in der Tabelle Flugzeug C: Einfügen, Updaten eines Datensatzes in der Tabelle Airport. D: Einfügen eines Flugereignisses E: Löschen eines Fluges Seite 167

168 Nach dem Entwurf des Datenmodells, müssen die Tabellen physisch angelegt werden, die Beziehungen müssen angelegt werden, die Tabellen müssen mit Daten gefüllt werden, die Daten müssen manipuliert werden etc. Dazu dient die Datenbanksprache SQL. Seite 168

169 Die Datenbanksprache SQL SQL (Structured Query Language) wurde Ende der 70er Jahre von IBM entwickelt und war ursprünglich für DB2 vorgesehen. Mitte der 80er Jahre wurde SQL als ANSI-Standard formuliert. Im Jahre 1992 wurde SQL92 zum Standard, seit 2000 gibt es SQL3. Die meisten Anbieter relationaler DBMS unterstützen ein erweitertes SQL. => es gibt kein einheitliches SQL sondern verschiedene Dialekte. In der Vorlesung gehen wir auf Besonderheiten vom SQL-Server und Oracle ein. Seite 169

170 Namenskonventionen für Tabellen Tabellennamen und Attribute: müssen mit einem Buchstaben beginnen dürfen 1-30 Zeichen enthalten dürfen nur die folgenden Zeichen enthalten: A-Z, a-z, 0-9,_, $, # dürfen nicht den Namen eines anderen Objekts duplizieren, das demselben Benutzer gehört dürfen nicht einem reservierten Wort entsprechen Seite 170

171 Ausschnitt aus den verschiedenen Datentypen in ANSI-SQL CHAR(size) DEC(n,m) INT, FLOAT, REAL DATE (Synonym CHARACTER) Zeichenkette mit der maximalen Länge size. Werte dieses Datentyps müssen von einfachen Hochkommata eingeschlossen sein. (Synonym DECIMAL) Dezimalzahl mit Genauigkeit und Anzahl der Nachkommastellen. Datentypen für Zahlen Felder für Datum und Zeit Seite 171

172 Einige Datentypen von Oracle VARCHAR2(size) Zeichendaten variabler Länge CHAR(size) Zeichendaten fester Länge NUMBER(p,s) Numerische Daten variabler Länge. Gesamtstellenzahl ist p, Anzahl der Nachkommastellen ist s LONG Zeichendaten variabler Länge mit bis zu 2 Gigabyte DATE Datums- und Zeitwerte BLOB Binärdaten bis zu 4 Gigabyte CLOB Zeichendaten bis zu 4 Gigabyte Seite 172

173 Einige Datentypen vom SQL Server VARCHAR(size) CHAR(size) FLOAT[(p)] REAL DECIMAL(g,n) INT DATETIME Zeichendaten variabler Länge Zeichendaten fester Länge Fließkommazahl, wobei p die Genauigkeit festlegt. Fließkommazahl Fließkommazahl in Abhängigkeit von g,n. g kennzeichnet die Anzahl aller Ziffern, p die Anzahl der Ziffern hinter dem Komma. ganzzahliger numerischer Wert, der in 4 Bytes gespeichert wird. Datumswerte, gespeichert als Ganzzahlen in vier Byte. Eingabe im Format MMMM dd yyyy Seite 173

174 Anlegen einer Tabelle: die CREATE TABLE Anweisung Tabellen werden durch die Anweisung CREATE TABLE angelegt. (Die Eckigen Klammern zeigen optionale Ausdrücke an. Alle von SQL reservierten Wörter werden hier zur Identifizierung mit Großbuchstaben geschrieben). CREATE TABLE Tabellenname (Attribut1 Datentyp [DEFAULT deftyp][spalten_constraint], Attribut2 Datentyp,., [table_constraint]); - Für jedes Attribut dieser Tabelle muss Attributname und Datentyp angegeben werden. Seite 174

175 Optional sind DEFAULT-Option Spalten-Constraint Tabellen-Constraint Seite 175

176 Constraints Constraints erzwingen Regeln auf Tabellenebene Die folgenden Constraint-Regeln sind gültig NOT NULL UNIQUE PRIMARY KEY FOREIGN KEY CHECK Seite 176

177 Constraint NOT NULL UNIQUE PRIMARY KEY FOREIGN KEY CHECK Beschreibung Gibt an, dass die Spalte keinen NULL- Wert enthalten darf. Gibt eine Spalte oder Spaltenkombination an, deren Werte in allen Zeilen der Tabelle eindeutig sein müssen. Identifiziert jede Zeile der Tabelle eindeutig. Richtet eine Fremdschlüsselbeziehung zwischen der Spalte und einer Spalte der referenzierten Tabelle ein und setzt diese durch. Gibt eine Bedingung an, die erfüllt sein muss. Seite 177

178 Constraints definieren Constraints werden in der Regel gleichzeitig mit der Tabelle erstellt. Sie können aber auch nach dem Erstellen der Tabelle hinzugefügt werden. Constraints auf Spaltenebene Attribut [CONSTRAINT constraint_name] constraint_type, Constraints auf Tabellenebene Attribut,. [CONSTRAINT constraint_name] constraint_type (Attribut1, ) Seite 178

179 NOT NULL-Constraint Dieses Constraint kann nur auf Spaltenebene definiert werden. Beispiel: Anlegen einer Tabelle Airport CREATE TABLE Airport (APID INT NOT NULL, A3LC CHAR(3) NOT NULL DEFAULT 'aaa', ABEZ COUNTRY ); VARCHAR(100), VARCHAR(100) Constraint wird vom System benannt. Seite 179

180 oder CREATE TABLE Airport (APID INT NOT NULL, A3LC CHAR(3) DEFAULT 'aaa ABEZ COUNTRY VARCHAR(100), VARCHAR(100)); CONSTRAINT A_3LC NOT NULL, Constraint wird vom Nutzer benannt. Seite 180

181 UNIQUE-Constraint Ein UNIQUE-Constraint erfordert, dass jeder Wert eines Attributs oder Attributkombination eindeutig ist. Dieses Constraint wird auf Tabellen- oder Spaltenebene definiert. CREATE TABLE Airport (APID INT NOT NULL, A3LC CHAR(3) NOT NULL UNIQUE, ABEZ VARCHAR(100), COUNTRY VARCHAR(100) ); Seite 181

182 oder CREATE TABLE Airport (APID INT NOT NULL, A3LC CHAR(3) NOT NULL, ABEZ VARCHAR(100), COUNTRY VARCHAR(100), CONSTRAINT A_3LC UNIQUE (A3LC) ); Seite 182

183 PRIMARY KEY-Constraint Ein PRIMARY KEY-Constraint erstellt für die Tabelle einen Id-Schlüssel. Für jede Tabelle kann nur ein Id-Schlüssel erstellt werden. Das PRIMARY KEY-Constraint ist ein Attribut oder eine Attributkombination, die jedes Tupel einer Tabelle eindeutig identifiziert. Seite 183

184 Beispiel CREATE TABLE Airport (APID INT PRIMARY KEY, A3LC CHAR(3) NOT NULL, ABEZ VARCHAR(100), COUNTRY VARCHAR(100) ); Bemerkung: Besteht ein Primary Key aus einer Attributkombination, so muss PRIMARY KEY als Constraint auf Tabellenebene angegeben werden. Seite 184

185 FOREIGN KEY-Constraint Ein FOREIGN KEY-oder referentielle Integritäts-Constraints bestimmten ein Attribut oder eine Attributkombination als Fremdschlüssel und richten eine Beziehung zwischen einem PRIMARY KEY in derselben oder einer anderen Tabelle ein. Ein FOREIGN KEY- Constraint kann auf Spalten- oder Tabellenebene definiert werden. Bemerkung: Ein FOREIGN KEY Constraint wird von MySQL nur unterstützt mit dem Tabellentyp TYPE=INNODB. Seite 185

186 Beispiel CREATE TABLE Abteilung (AbtID NUMBER(6) PRIMARY KEY, Abt_Name VARCHAR2(20) NOT NULL ); CREATE TABLE Mitarbeiter (MID NUMBER(6) PRIMARY KEY, Name VARCHAR2(20) NOT NULL, Vorname VARCHAR2(20), AbtID NUMBER(6) REFERENCES Abteilung (AbtID) ); Seite 186

187 Schüsselwörter von FOREIGN KEY-Constraints FOREIGN KEY: definiert das Attribut der untergeordneten Tabelle auf Tabellen-Constraint-Ebene. REFERENCES: identifiziert die Tabelle und das Attribut in der übergeordneten Tabelle ON DELETE CASCADE: löscht die abhängigen Zeilen aus der untergeordneten Tabelle, wenn eine Zeile in der übergeordneten Tabelle gelöscht wird. ON DELETE SET NULL: konvertiert abhängige Fremdschlüsselwerte in NULL- Werte. Seite 187

188 CHECK-Constraint Ein CHECK-Constraint definiert eine Bedingung, die jede Zeile erfüllen muss. Beispiel: CREATE TABLE Mitarbeiter (. gehalt NUMERIC (8,2) CHECK (gehalt > 0),.) Bemerkung: MySQL unterstützt dieses Constraint nicht. Seite 188

189 Veränderung von bestehenden Tabellen Die Strukturen bestehender Tabellen müssen unter Umständen verändert werden, d.h. Spalten hinzufügen, Spaltendefinition verändern, Spalten entfernen, Constraints verändern. Dies erfolgt mit Hilfe der ALTER TABLE- Anweisung Seite 189

190 ALTER TABLE- Anweisung Spalten hinzufügen: ALTER TABLE Tabellenname ADD Neuer_Attributname Datentyp [DEFAULT deftyp], ; Bestehende Attribute ändern ALTER TABLE Tabellenname MODIFY Bestehendes_Attribut neuer_datentyp [DEFAULT deftyp], ; Attribut löschen ALTER TABLE Tabellenname DROP Bestehendes_Attribut, ; Seite 190

191 Constraints nachträglich hinzufügen Mit der ALTER TABLE Anweisung können auch Constraints nachträglich bearbeitet werden. Ein Constraint kann hinzugefügt oder gelöscht werden aktiviert oder deaktiviert werden Beispiel für die Syntax zum Einfügen einer neuen Spalte ALTER TABLE Tabellenname ADD [CONSTRAINT constraint] type (Attribut); Seite 191

192 Daten in eine Tabelle einfügen mit INSERT Die Syntax für das Einfügen eines Tupels in eine Tabelle lautet INSERT INTO Tabellenname [(Attribut1 [, Attribut2 ])] VALUES (wert1 [,wert2 ]); Seite 192

193 Beispiel Es sollen Tupel in die Tabelle Mitarbeiter(MID,Name, Vorname, Gehalt) eingefügt werden. Es gibt folgende Möglichkeiten INSERT INTO Mitarbeiter VALUES (100,'Beier','Marc',50000); -> dann müssen Werte in Reihenfolge der Tabellendefinition angegeben werden Seite 193

194 Sind NULL-Werte für einzelne Attribute erlaubt, so müssen für diese nicht unbedingt Werte eingegeben werden: INSERT INTO Mitarbeiter(MID,Name) VALUES(103,'Becker'); oder INSERT INTO Mitarbeiter VALUES (104,'Becker',NULL,NULL); Seite 194

195 oder INSERT INTO Mitarbeiter (MID,Name,Vorname, Gehalt) VALUES (101,'Beier','Marc',50000); werden die Attribute hinter dem Tabellennamen angegeben, so kann die Reihenfolge vertauscht werden: INSERT INTO Mitarbeiter(MID, Gehalt, Name, Vorname) VALUES (102,50000,'Marc','Beier ); Seite 195

196 Abfragen von Datensätzen: die SELECT-Anweisung Um Daten aus der Datenbank zu extrahieren, verwendet man die SELECT Anweisung. Mit einer SELECT Anweisung können folgende Aktionen ausgeführt werden: Projektion: Legt fest, welche Spalten einer Tabelle die Abfrage zurückgibt. Es können beliebig viele Spalten der Tabelle gewählt werden. Auswahl: Legt fest, welche Zeilen einer Tabelle die Abfrage zurückgibt. Es können verschiedene Kriterien angegeben werden, um die angezeigten Zeilen einzuschränken. Join: Die in verschiedenen Tabellen gespeicherten Daten können durch Verknüpfung zusammengebracht werden. Seite 196

197 Grundlegende SELECT-Anweisung SELECT * {[DISTINCT] Attribut Ausdruck [alias], } FROM tabellenname; steht für alternativ SELECT bestimmt, welches Attribut FROM bestimmt, welche Tabelle Seite 197

198 Die Tabelle mitarbeiter(mid,name,vorname,abteilung,gehalt) habe 6 Tupel: Alle Spalten auswählen liefert SELECT * FROM mitarbeiter; mid name vorname abteilung gehalt 100 Hoffmann Richard F3/ , Schulte Karin F2/4 Projekte 60450, Becker Malte D13/ , Schmidt Andreas A12/2 Marketing 65000, Schlodder Kim 40000, Hoffmann Richard F3/ ,00 Alternativ können auch statt * alle Attribute angeben werden: SELECT mid, name, vorname, abteilung, gehalt FROM mitarbeiter Seite 198

199 Bestimmte Spalten auswählen SELECT name, vorname FROM mitarbeiter; liefert name Hoffmann Schulte Becker Schmidt Schlodder Hoffmann vorname Richard Karin Malte Andreas Kim Richard Die Reihenfolge der Angabe der Attribute entscheidet über die Reihenfolge der Ausgabe. Seite 199

200 Arithmetische Ausdrücke In der Anzeige können auch Zahlendaten durch arithmetisch verknüpft werden. SELECT name, vorname, gehalt, gehalt/ liefert FROM mitarbeiter; name vorname gehalt gehalt/ Hoffmann Richard 40000, ,3333 Schulte Karin 60450, ,5000 Becker Malte 25230, ,5000 Schmidt Andreas 65000, ,6667 Schlodder Kim 40000, ,3333 Hoffmann Richard 42000, ,0000 Bemerkung: Es wird keine neue Spalte in der Tabelle erzeugt sondern nur in der Anzeige eine weitere Spalte hinzugefügt. Seite 200

201 Attribut-Aliasnamen definieren Ein Attribut-Aliasname benennt ein Attribut in der Ausgabe um kann z.b. nützlich bei nicht-aussagekräftigen Attributsnamen oder bei Berechnungen sein wird direkt hinter dem Attributnamen angegeben. Optional kann zwischen Attribut und Aliasname AS angegeben werden hat der Aliasname Leerzeichen, so muss er in gesetzt werden Bemerkung: in Oracle werden in der Anzeige alle Attribute in Großbuchstaben ausgegeben. Sollen sie auch in Kleinbuchstaben ausgegeben werden, müssen sie ebenfalls in gesetzt werden. Seite 201

202 Attribut-Aliasnamen verwenden SELECT name AS Mitarbeitername,gehalt, gehalt/12 AS Monatsgehalt FROM mitarbeiter; Mitarbeitername gehalt Monatsgehalt Hoffmann 40000, ,3333 Schulte 60450, ,5000 Becker 25230, ,5000 Schmidt 65000, ,6667 Schlodder 40000, ,3333 Hoffmann 42000, ,0000 SELECT name "Mitarbeiter Name", gehalt, gehalt/12 Monatsgehalt FROM mitarbeiter; Mitarbeiter Name gehalt Monatsgehalt Hoffmann 40000, ,3333 Schulte 60450, ,5000 Seite 202

203 Mehrfach vorhandene Zeilen ausblenden mit DISTINCT liefert SELECT name FROM mitarbeiter; name Hoffmann Schulte Becker Schmidt Schlodder Hoffmann SELECT DISTINCT name FROM mitarbeiter liefert dagegen name Hoffmann Schulte Becker Schmidt Schlodder Seite 203

204 Daten einschränken und sortieren die WHERE- Klausel Die zurückgegebenen Zeilen werden mit Hilfe der WHERE-Klausel eingeschränkt. SELECT * {[DISTINCT] Attribut Ausdruck [alias], } FROM tabellenname [WHERE bedingung(s)]; Die WHERE-Klausel besteht aus Spaltenname, Vergleichsoperator, Attribut, Konstante oder Werteliste Seite 204

205 Die WHERE-Klausel SELECT * liefert FROM mitarbeiter WHERE mid = 101; mid name vorname abteilung gehalt 101 Schulte Karin F2/4 Projekte 60450,00 oder SELECT mid, name, vorname, gehalt FROM mitarbeiter WHERE abteilung= 'F3/20'; Zeichenfolgen müssen in Hochkommata gesetzt werden mid name vorname gehalt 100 Hoffmann Richard 40000,00 Seite 205

206 Die folgenden Vergleichsoperatoren sind möglich = > < >= < <= <> (auch!=) SELECT * FROM mitarbeiter WHERE gehalt > mid name vorname abteilung gehalt 101 Schulte Karin F2/4 Projekte 60450, Schmidt Andreas A12/2 Marketing 65000,00 Seite 206

207 Bemerkung In einer WHERE-Klausel darf kein Alias verwendet werden. Andere Vergleichsoperatoren Operator Bedeutung BETWEEN.AND. IN (menge) LIKE IS NULL Zwischen zwei Werten (einschließlich dieser Werte) Entspricht einem Wert aus der Menge Entspricht einem Zeichenmuster ist ein NULL-Wert Seite 207

208 Der Operator BETWEEN SELECT * FROM mitarbeiter WHERE gehalt BETWEEN AND 60450; liefert mid name vorname abteilung gehalt 100 Hoffmann Richard F3/ , Schulte Karin F2/4 Projekte 60450, Schlodder Kim 40000, Hoffmann Richard F3/ ,00 Seite 208

209 Der Operator IN SELECT * FROM mitarbeiter WHERE mid IN (100, 104); liefert mid name vorname abteilung gehalt 100 Hoffmann Richard F3/ , Schlodder Kim 40000,00 Bemerkung: Zeichen- oder Datumswerte müssen in der Liste in Hochkommata ( )gesetzt werden. Seite 209

210 Der Operator LIKE Mit LIKE kann eine Platzhaltersuche durchgeführt werden. Der Platzhalter % steht für kein, ein oder beliebig viele Zeichen Der Platzhalter _ steht für genau ein Zeichen. SELECT * FROM mitarbeiter WHERE name LIKE 'S%' ; mid name vorname abteilung gehalt 101 Schulte Karin F2/4 Projekte 60450, Schmidt Andreas A12/2 Marketing 65000, Schlodder Kim 40000,00 Seite 210

211 Der Operator IS NULL SELECT * FROM mitarbeiter WHERE abteilung IS NULL; liefert mid name vorname abteilung gehalt 104 Schlodder Kim 40000,00 Entsprechen kann auf IS NOT NULL abgefragt werden. Seite 211

212 Logische Operatoren Operator AND OR NOT Bedeutung TRUE, falls beide Komponentenbedingungen wahr sind TRUE, falls eine der beiden Komponentenbedingungen wahr ist. TRUE, falls die Bedingung falsch ist. Mit diesen Operatoren können mehrere Bedingungen in der WHERE- Klausel verknüpft werden. Seite 212

213 SELECT * FROM mitarbeiter WHERE name LIKE 'SCH%' AND gehalt > 50000; liefert mid name vorname abteilung gehalt 101 Schulte Karin F2/4 Projekte 60450, Schmidt Andreas A12/2 Marketing 65000,00 Seite 213

214 Dagegen ergibt die Anweisung SELECT * FROM mitarbeiter WHERE name LIKE 'SCH%' OR gehalt > 50000; mid name vorname abteilung gehalt 101 Schulte Karin F2/4 Projekte 60450, Schmidt Andreas A12/2 Marketing 65000, Schlodder Kim 40000,00 Seite 214

215 Der NOT-Operator kann mit anderen Operatoren wie IN, BETWEEN, LIKE und NULL kombiniert werden. SELECT * FROM mitarbeiter WHERE mid NOT IN (100,104) mid name vorname abteilung gehalt 101 Schulte Karin F2/4 Projekte 60450, Becker Malte D13/ , Schmidt Andreas A12/2 Marketing 65000, Hoffmann Richard F3/ ,00 Seite 215

216 Sortieren mit der ORDER BY-Klausel Die ORDER BY Klausel in Verbindung mit ASC sortiert in aufsteigender Reihenfolge DESC sortiert in absteigender Reihenfolge. Wird hinter ORDER BY weder ASC noch DESC angegeben, so wird aufsteigend sortiert. Syntax SELECT * {[DISTINCT] Attribut Ausdruck [alias], } FROM tabellenname [WHERE bedingung(s)] [ORDER BY {Attribut, Ausdruck,alias} [ASC DESC ]]; Seite 216

217 Absteigend und Aufsteigend sortieren SELECT * FROM mitarbeiter ORDER BY name DESC; liefert mid name vorname abteilung gehalt 101 Schulte Karin F2/4 Projekte 60450, Schmidt Andreas A12/2 Marketing 65000, Schlodder Kim 40000, Hoffmann Richard F3/ , Hoffmann Richard F3/ , Becker Malte D13/ ,00 Seite 217

218 Es kann auch nach Attributen sortiert werden, die nicht in der SELECT Anweisung enthalten sind SELECT name, vorname FROM mitarbeiter ORDER BY gehalt DESC; Seite 218

219 Auch nach mehreren Attributen oder nach alias kann sortiert werden SELECT name, gehalt/12 monatsgehalt FROM mitarbeiter ORDER BY monatsgehalt, name; name monatsgehalt Becker 2102,5 Hoffmann 3333, Schlodder 3333, Hoffmann 3500 Schulte 5037,5 Schmidt 5416, Seite 219

220 SQL-Funktionen Es gibt zwei verschiedene Arten von Funktionen: Single Row-Funktionen Diese Funktionen bearbeiten nur einzelne Zeilen und geben ein Ergebnis pro Zeile zurück. Multiple Row-Funktionen Diese Funktionen können Gruppen von Zeilen bearbeiten, um ein Ergebnis pro Zeilengruppe zurückzugeben (Gruppenfunktionen). Seite 220

221 Single Row-Funktionen bearbeiten Datenelemente bearbeiten jede zurückgegebene Zeile geben ein Ergebnis pro Zeile zuück akzeptieren Spalten oder Ausdrücke als Argumente können verschachtelt sein. Im Folgenden werden einige dieser Funktionen behandelt. Seite 221

222 Zeichenfunktionen haben als Input Zeichendaten, als Output Zeichenwerte oder numerische Werte. es wird unterschieden zwischen Zeichenfunktionen zur Umwandlung von Groß-/Kleinbuchstaben Funktionen zum Bearbeiten von Zeichen Funktion LOWER(attribut ausdruck) UPPER(attribut ausdruck) CONCAT(attribut1 ausdruck1,attribut2 ausdruck2) LENGTH(attribut ausdruck) TRIM(trim_character FROM trim_source) Zweck Konvertiert alphanumerische Zeichenwerte in Kleinbuchstaben Konvertiert alphanumerische Zeichenwerte in Großbuchstaben Verkettung der Attribute bzw. Ausdrücke entfernt am Anfang und Ende das Zeichen oder die Zeichenkette trim_character aus trim_source Seite 222

223 Beispiel für das Verwenden von Zeichenfunktionen SELECT LOWER(name), UPPER(vorname), CONCAT(vorname,' ',name) AS mitarbeitername, LENGTH(name), TRIM('Sch' FROM name) FROM mitarbeiter; LOWER(name) UPPER(vorname) mitarbeitername LENGTH(name TRIM('Sch' FROM name) hoffmann RICHARD Richard Hoffmann 8 Hoffmann schulte KARIN Karin Schulte 7 ulte becker MALTE Malte Becker 6 Becker schmidt ANDREAS Andreas Schmidt 7 midt schlodder KIM Kim Schlodder 9 lodder hoffmann RICHARD Richard Hoffmann 8 Hoffmann Seite 223

224 Numerische Funktionen haben als Input und Output numerische Werte Auszug der Funktionen Funktion ROUND (attribut ausdruck,n) TRUNC (attribut ausdruck,n) bzw. TRUNCATE(attribut ausdruck,n) in MySQL MOD (m,n) SQRT(attribut ausdruck) SIN( ), COS(..), TAN( ) Zweck Rundet die Spalte bzw. den Ausdruck auf n Dezimalstellen. Ist kein Wert angegeben, wird auf einen ganzzahligen Wert gerundet. Schneidet die Spalte bzw. den Ausdruck auf n Dezimalstellen ab. Ist kein Wert für n angegeben, werden die Ziffern hinter dem Dezimalkomma abgeschnitten Gibt den ganzzahligen Rest von m/n zurück. Berechnet die Wurzel Winkelfunktionen Seite 224

225 Beispiel für das Verwenden von Numerischen Funktionen SELECT gehalt, gehalt/12, ROUND(gehalt/12,2), TRUNC (gehalt/12,2), MOD(gehalt, 12) FROM mitarbeiter; gehalt gehalt/12 ROUND(gehalt/12,2) TRUNC(gehalt/12) MOD(gehalt,12) , , , ,5 2102, , ,5 5037, , , , , , , , , ,00 0 Seite 225

226 Datums- und Zeitwerte In SQL2 gibt es die Datentypen DATE und TIME. DATE umfasst 10 Stellen im Format YYYY-MM-DD. TIME hat 8 Stellen im Format HH:MM:SS. Zusätzlich gibt es den Datentyp TIMESTAMP, der DATE- und TIME-Felder und Stellen für Bruchteile von Sekunden beinhaltet. Die Datums- und Zeitwerte sind je nach DBMS unterschiedlich. Seite 226

227 Datums- und Zeitwerte in Oracle Oracle speichert Datumswerte in einem internen numerischen Format: Jahrhundert, Jahr, Monat, Tag, Stunde, Minute, Sekunde Das Default-Format für die Anzeige ist DD-MM-JJ Mit der Funktion TO_CHAR(datum, format ) kann ein datum in einem anderen Format angezeigt werden. SYSDATE Funktion, die das aktuelle Datum und die aktuelle Uhrzeit des Datenbankservers zurückgibt Da Datumswerte als Zahlen gespeichert werden, können mit Hilfe der arithmetischen Operatoren Berechnungen durchgeführt werden. Seite 227

228 Einige Funktionen für Datum in Oracle Funktion MONTH_BETWEEN(date1,date2) ADD_MONTHS(date,n) NEXT_DAY(date, char ) LAST_DAY(date) ROUND TRUNC Bedeutung Anzahl der Monate zwischen zwei Datumswerten Kalendermonat zu einem Datum addieren Datum des nächsten Wochentages Letzter Tag des Monats Datumswert runden Datumswert abschneiden Seite 228

229 Datums- und Zeitwerte beim SQL-Server Der SQL-Server kennt die Datentypen DATETIME und SMALLDATETIME. DATETIME speichert das Datum und die Zeit in Sekundengenauigkeit, SMALLDATETIME in Minutengenauigkeit. GETDATE() Funktion, die das aktuelle Datum und die aktuelle Uhrzeit des Datenbankservers zurückgibt Seite 229

230 Einige Funktionen für Datum beim SQL-Server DATEADD(datumsteil, anzahl, datum): Zu einem gegebenen Datum kann eine bestimmte Anzahl an Intervallen hinzugefügt oder abgezogen werden. Intervalle sind year, month, week, quarter, hour, minute, second(date,n) DATEDIFF(datumsteil, startdatum, enddatum): Liefert Differenz zwischen zwei Datumswerten DATENAME(datumsteil, datum): Liefert den angegebenen Datumsteil DAY(datum), MONTH(datum), YEAR(datum): Liefert den entsprechenden Datumsteil als Zahl. Seite 230

231 Bedingte Ausdrücke Bedingte Ausdrücke stellen die IF-THEN-ELSE Logik innerhalb einer SQL- Anweisung bereit. In SQL werden sie mit Hilfe von CASE ausgeführt. Syntax CASE attribut ausdruck END WHEN vergleichs_ausdruck1 THEN return_ausdruck1 [WHEN vergleichs_ausdruck2 THEN return_ausdruck2 WHEN vergleichs_ausdruck3 THEN return_ausdruck3 ELSE else_ausdruck] Seite 231

232 Beispiel für das Verwenden von CASE SELECT name, vorname, abteilung, gehalt, CASE abteilung WHEN 'A12/2 Marketing' THEN gehalt+100 WHEN 'F3/20' THEN gehalt ELSE gehalt END 'Angepasstes Gehalt' FROM mitarbeiter; name vorname abteilung gehalt Angepasstes Gehalt Hoffmann Richard F3/ , ,00 Schulte Karin F2/4 Projekte 60450, ,00 Becker Malte D13/ , ,00 Schmidt Andreas A12/2 Marketing 65000, ,00 Schlodder Kim 40000, ,00 Hoffmann Richard F3/ , ,00 Seite 232

233 EINSCHUB- Daten in Tabellen ändern und löschen Tupel in einer Tabelle werden in SQL mit Hilfe der UPDATE Anweisung geändert: Syntax UPDATE SET [WHERE tabellenname attribut = wert [, attribut2 = wert, ] bedingung]; Es können ein oder mehrere Tupel pro Tabelle geändert werden. Seite 233

234 Beispiel für das Ändern von Tupeln Die Tabelle airport habe die folgenden Attribute und Datentypen (hier in MySQL): Field APID A3LC ABEZ COUNTRY UPDATE_DAT INSERT_DAT Type int(11) char(3) varchar(100) varchar(100) timestamp(14) timestamp(14) In die Tabelle werden zwei Datensätze eingefügt: INSERT INTO airport VALUES (100,'FRA', 'Frankfurt','Deutschland',NULL,NULL); INSERT INTO airport (APID, A3LC, ABEZ, COUNTRY,INSERT_DAT) VALUES (105,'LAX', 'Los Angeles','USA',NULL); Seite 234

235 Damit hat die Tabelle den Inhalt Frankfurt soll in Frankfurt am Main geändert werden: UPDATE airport SET ABEZ = 'Frankfurt am Main' WHERE APID = 100; Satz wurde geändert Seite 235

236 Löschen von Tupeln Tupel in einer Tabelle werden in SQL mit Hilfe der DELETE Anweisung gelöscht: Syntax DELETE [FROM] [WHERE tabellenname bedingung]; Seite 236

237 Daten aus mehreren Tabellen anzeigen Seite 237

238 mitarbeiter abteilung Das Ergebnis der Abfrage: Seite 238

239 Um Daten aus mehreren Tabellen anzuzeigen, müssen sog. JOIN-Bedingungen benutzt werden. In SQL99 gibt es In Oracle Natural-Join/Inner-Join Equi-Join Left-Outer-Join bzw. Right-Outer-Join Outer-Join Self-Join Self-Join Cross-Join Kartesisches Produkt Seit Oracle9i unterstützt Oracle auch die Standard-Joins. Seite 239

240 Equi-Joins bzw. Inner-Joins mitarbeiter abteilung Fremdschlüssel Id-Schlüssel Um für eine M_ID den Abteilungsname zu erhalten, müssen die Attributwerte aus der Spalte ABT_ID der Tabelle mitarbeiter mit ABT_ID aus der Tabelle abteilung verglichen werden. Die Verknüpfung der beiden Tabellen nennt man Equi-Join oder Inner-Join. Seite 240

241 Datensätze mit Equi-Join abfragen SELECT FROM WHERE mitarbeiter.m_id, mitarbeiter.name, mitarbeiter.vorname, abteilung.abt_name mitarbeiter, abteilung mitarbeiter.abt_id = abteilung.abt_id; JOIN- Bedingung Seite 241

242 Die Attribute aus den unterschiedlichen Tabellen müssen eindeutig sein Die Eindeutigkeit wird gewährleistet, indem Tabellenpräfixe gesetzt werden. Z.B. mitarbeiter.abt_id Tabellenpräfixe verbessern die Performance bei Abfragen über mehrere Tabellen. Seite 242

243 Tabellen-Aliasnamen Die Abfragen sollten über Tabllen-Aliasnamen vereinfacht werden. Durch das Verwenden von Tabellenpräfixen wird die Performance verbessert. Beispiel SELECT FROM WHERE m.m_id, m.name, m.vorname, a.abt_name mitarbeiter m, abteilung a m.abt_id = a.abt_id; Der Tabellen-Aliasname gilt nur für die aktuelle SELECT-Anweisung. Seite 243

244 Zusätzliche Suchkriterien mit AND SELECT FROM WHERE AND m.m_id, m.name, m.vorname, a.abt_name mitarbeiter m, abteilung a m.abt_id = a.abt_id m.name = 'Schutt'; Seite 244

245 Mehrere Tabellen verknüpfen mitarbeiter abteilung standort Seite 245

246 SELECT FROM WHERE AND m.m_id, m.name, m.vorname, a.abt_name,s.stadt mitarbeiter m, abteilung a, standort s m.abt_id = a.abt_id a.abt_sitz = s.abt_sitz Seite 246

247 Alternativ kann auch ein INNER JOIN gesetzt werden SELECT FROM ON m.m_id, m.name, m.vorname, a.abt_name mitarbeiter m INNER JOIN abteilung a m.abt_id = a.abt_id; oder bei Verbindungen von 3 Tabellen SELECT m.m_id, m.name, m.vorname,a.abt_name,s.stadt FROM mitarbeiter m INNER JOIN abteilung a ON m.abt_id = a.abt_id INNER JOIN standort s ON a.abt_sitz = s.abt_sitz; Seite 247

248 Bemerkung Bei den bisherigen JOINS müssen die vergleichenden Attribute nicht gleich heißen. Beispiel: mitarbeiter(m_id, name, vorname, abtid), abteilung (abt_id, abt_name, abt_sitz) dann ist ein INNER JOIN gegeben durch SELECTm.m_id, m.name, m.vorname, a.abt_name FROM ON mitarbeiter m INNER JOIN abteilung a m.abtid = a.abt_id; Seite 248

249 INNER JOIN USING Heißen die zu verbindenden Attribute in den Tabellen gleich, so kann man bei Oracle auch statt des ON ein USING setzen: Beispiel: Statt SELECT FROM ON m.m_id, m.name, m.vorname, a.abt_name mitarbeiter m INNER JOIN abteilung a m.abt_id = a.abt_id; kann SELECT FROM m.m_id, m.name, m.vorname, a.abt_name mitarbeiter m INNER JOIN abteilung a USING (abt_id); die Klammer muss gesetzt werden es darf kein Tabellenpräfix gesetzt werden Seite 249

250 Outer-Joins mitarbeiter abteilung Diese Sätze würden bei einem INNER-JOIN rausfallen Ein OUTER-JOIN zeigt auch Datensätze an, die keinen Bezug zur zweiten Tabelle haben. Seite 250

251 LEFT OUTER JOIN ( RIGHT OUTER JOIN) Eine Verknüpfung zwischen zwei Tabellen, die das Ergebnis des INNER JOINS sowie die Zeilen ohne Übereinstimmung in der linken Tabelle zurückgibt, wird als LEFT-OUTER-JOIN bezeichnet. Eine Verknüpfung zwischen zwei Tabellen, die das Ergebnis des INNER JOINS sowie die Zeilen ohne Übereinstimmung in der rechten Tabelle zurückgibt, wird als RIGHT-OUTER-JOIN bezeichnet. Durch das Vertauschen der Tabellen, ist der RIGHT OUTER JOIN überflüssig. Seite 251

252 Beispiel für einen LEFT OUTER JOIN SELECT FROM m.m_id, m.name, m.vorname, a.abt_id, a.abt_name mitarbeiter m LEFT OUTER JOIN abteilung a ON (m.abt_id = a.abt_id); alle Tupel der linken Tabelle mitarbeiter werden angezeigt Seite 252

253 Beispiel für einen RIGHT OUTER JOIN SELECT FROM m.m_id, m.name, m.vorname, a.abt_id, a.abt_name mitarbeiter m RIGHT OUTER JOIN abteilung a ON (m.abt_id = a.abt_id); alle Tupel der rechten Tabelle abteilung werden angezeigt Seite 253

254 FULL OUTER JOIN Sollen alle Datensätze aus den beteiligten Tabellen angezeigt werden, so spricht man von einem FULL OUTER JOIN. Wo es möglich ist, werden auch hier Verknüpfungen vorgenommen. Beispiel SELECT FROM m.m_id, m.name, m.vorname, a.abt_id, a.abt_name mitarbeiter m FULL OUTER JOIN abteilung a ON (m.abt_id = a.abt_id); Bemerkung: Der FULL OUTER JOIN existiert nicht unter MySQL. Seite 254

255 SELF JOIN Beim SELF JOIN wird eine Tabelle mit sich selbst verknüpft. mitarbeiter Attributwerte vom Fremdschlüssel CHEF_ID entsprechen denen vom Id- Schlüssel M_ID Um CHEF_ID aufzulösen, muss die Tabelle mitarbeiter mit sich selbst verknüpft werden. Seite 255

256 Beispiel für einen SELF JOIN SELECT FROM WHERE m.m_id, m.name, m.vorname, concat(v.vorname,' ', v.name) AS vorgesetzter mitarbeiter m, mitarbeiter v m.chef_id = v.m_id; Seite 256

257 Was ergibt die folgende SELECT-Anweisung? SELECT FROM WHERE m.m_id, m.name, m.vorname, concat(v.vorname,' ', v.name) AS vorgesetzter mitarbeiter m, mitarbeiter v m.m_id = v.chef_id; Seite 257

258 CROSS JOIN Der CROSS JOIN entspricht dem Kartesischen Produkt aus zwei Tabellen. Beispiel SELECT m.name, a.abt_name FROM mitarbeiter m, abteilung a; entspricht SELECT FROM m.name, a.abt_name mitarbeiter m CROSS JOIN abteilung a; Alternativ zu CROSS JOIN kann auch nur JOIN gesetzt werden. Seite 258

259 Der NATURAL JOIN Der NATURAL JOIN entspricht dem INNER JOIN mit einer USING Klausel. Es werden alle Datensätze mit einer Verbindung angezeigt, deren Spalten den selben Namen haben. Beispiel mitarbeiter abteilung standort Seite 259

260 Beispiel für den NATURAL JOIN SELECT m.m_id, m.name, m.vorname,a.abt_name,s.stadt FROM mitarbeiter m NATURAL JOIN abteilung a NATURAL JOIN standort s; Seite 260

261 Beispiel für den NATURAL JOIN Hat aber der Id-Schlüssel der Tabelle standort nicht den Namen abt_sitz sondern ab_sitz, so ergibt die folgende SELECT Anweisung 56 Datensätze SELECT m.m_id, m.name, m.vorname,a.abt_name,s.stadt FROM mitarbeiter m NATURAL JOIN abteilung a NATURAL JOIN standort s; Seite 261

262 Non- Equi- Joins Equi-Joins selektieren nur die Datensätze, die durch = miteinander verbunden werden (z.b. WHERE m.abt_id = a.abt_id). Benutzt man einen anderen Operator als den = Operator, so spricht man von einem Non-Equi-Join. Seite 262

263 Beispiel für eine Non-Equi-Join Die Tabelle mitarbeiter habe noch eine Spalte gehalt. Die Tabelle gehaltstufe gibt die Gehaltsstufen innerhalb der Firma an. Seite 263

264 Non- Equi- Join SELECT m.m_id, m.name, m.vorname, m.gehalt, g.gehalt_stufe FROM mitarbeiter m, gehaltstufe g WHERE m.gehalt BETWEEN g.gehalt_von AND g.gehalt_bis; Seite 264

265 Daten mit Gruppenfunktionen aggregieren Seite 265

266 Gruppenfunktionen Im Gegensatz zu Single-Row Funktionen werden Gruppenfunktionen auf Gruppen von Zeilen angewendet und geben ein Ergebnis pro Gruppe zurück. Gruppenfunktionen sind z.b. COUNT( ) Anzahl der Zeilen. SUM(n) Summe der Werte von n. MIN() Minimum MAX() Maximum AVG() Durchschnitt Seite 266

267 Die Syntax von Gruppenfunktionen SELECT FROM [WHERE [GROUP BY [ORDER BY [attribut,] gruppen_funktion(attribut), tabellenname bedingung] attribut] attribut] Für die Gruppenfunktionen gilt: Alle Funktionen können zusätzlich zum Attribut als Argument ein DISTINCT haben. DISTINCT bewirkt, dass die Funktion keine doppelten Werte berücksichtigt. Alle Gruppenfunktionen ignorieren NULL-Werte. Seite 267

268 Funktionen AVG(), SUM(), MIN() und MAX() SELECT AVG(gehalt), SUM(gehalt)/10, MAX(gehalt), MIN(gehalt), SUM(gehalt) FROM mitarbeiter ; Ergebnis der Abfrage mitarbeiter NULL-Werte werden ignoriert Seite 268

269 Funktionen COUNT() zählt die Datensätze SELECT COUNT(*) FROM mitarbeiter ; ergibt 10 SELECT COUNT(abt_id) FROM mitarbeiter; ergibt 7 SELECT COUNT(DISTINCT abt_id) FROM mitarbeiter; ergibt 4 Seite 269

270 Gruppierungen durchführen mit GROUP BY SELECT FROM GROUP BY abt_id, AVG(gehalt) mitarbeiter abt_id ergibt mitarbeiter gruppieren nach abt_id Seite 270

271 Für Gruppierungen gilt: Ist eine Gruppenfunktion in einer SELECT-Klausel angegeben, können nicht gleichzeitig einzelne Attribute selektiert werden, es sei denn, sie werden in der GROUP BY-Klausel angegeben. Mit der WHERE-Klausel können vorher Zeilen ausgeschlossen werden, bevor die übrigen Zeilen gruppiert werden Es dürfen keine Spalten-Aliasnamen in der GROUP BY-Klausel verwendet werden. Die in der GROUP BY-Klausel angegebene Spalte muss nicht in der SELECT Liste enthalten sein. Seite 271

272 Nach mehreren Spalten gruppieren mitarbeiter Die Gehälter aus der Tabelle mitarbeiter sollen für jede job_id addiert und gruppiert nach abt_id werden SELECT FROM GROUP BY abt_id, job_id, SUM(gehalt) mitarbeiter abt_id, job_id; Seite 272

273 Gruppenergebnisse filtern mit HAVING Die WHERE-Klausel darf nicht verwendet werden um Gruppen einzuschränken, d.h. es darf keine Gruppenfunktionen in der WHERE Klausel benutzt werden. Um Gruppen einzuschränken, benutzt man die HAVING-Klausel. HAVING arbeitet wie folgt: Die Zeilen werden gruppiert Die Gruppenfunktion wird angewandt Gruppen, die der HAVING-Klausel entsprechen, werden angezeigt. Seite 273

274 Gruppenergebnisse filtern mitarbeiter Das maximale Gehalt jeder Abteilung soll ermittelt werden, wenn es größer als 3000 ist SELECT abt_id, MAX(gehalt) FROM mitarbeiter GROUP BY abt_id HAVING MAX(gehalt) > 3000; Seite 274

275 Die Syntax von Gruppenfunktionen lautet zusammenfassend SELECT [attribut,] gruppen_funktion(attribut), FROM tabellenname [WHERE bedingung] [GROUP BY attribut] [HAVING gruppen_bedingung] [ORDER BY attribut] Benutzt man eine Gruppenfunktion zusammen mit einem Attribut in eine SELECT-Klausel, muss das Attribut in der GROUP BY Klausel angegeben werden. Bedingungen für Gruppenfunktionen müssen in der HAVING-Klausel angegeben werden. Seite 275

276 Unterabfragen Hauptabfrage Unterabfrage Unterabfrage gibt Wert an Hauptabfrage zurück Seite 276

277 Die Syntax von Unterabfragen SELECT FROM WHERE selections_liste tabellenname1 ausdruck operator ( SELECT selections_liste FROM tabellenname2); Die Unterabfrage wird einmal vor der Hauptabfrage ausgeführt Die Hauptabfrage verwendet das Ergebnis der Unterabfrage Unterabfragen können z.b. in WHERE Klauseln, HAVING-Klauseln und FROM-Klauseln eingefügt werden. Der operator ist ein Vergleichsoperator. Die Tabellen aus der Haupt-und Unterabfrage können gleich oder verschieden sein. Seite 277

278 Ein Beispiel für eine Unterabfrage mitarbeiter SELECT m_id, name, vorname FROM mitarbeiter WHERE gehalt > (SELECT gehalt FROM mitarbeiter WHERE name = 'Breitinger'); Ergebnis der Unterabfrage Ergebnis der Hauptabfrage Seite 278

279 Für Unterabfragen gilt: Sie müssen in Klammern gesetzt werden Sie stehen auf der rechten Seite des Vergleichoperators Single Row-Operatoren müssen bei Single Row- Unterabfragen verwendet werden Multiple Row-Operatoren müssen bei Multiple Row- Unterabfragen verwendet werden. Seite 279

280 Single Row-Unterabfragen geben nur eine Zeile zurück verwenden Single Row Vergleichsoperatoren, d.h. = > >= < <= <> Seite 280

281 Ein weiteres Beispiel für eine Unterabfrage SELECT name, vorname, gehalt FROM mitarbeiter WHERE job_id = (SELECT job_id FROM mitarbeiter WHERE m_id = 60) AND gehalt > (SELECT gehalt FROM mitarbeiter WHERE m_id = 54); Ergebnis der Hauptabfrage Seite 281

282 Gruppenfunktionen in Unterabfragen SELECT name, vorname FROM mitarbeiter WHERE gehalt = (SELECT FROM MAX(gehalt) mitarbeiter); Ergebnis der Hauptabfrage Seite 282

283 Gruppenfunktionen in Unterabfragen Welche Mitarbeiter liegen mit ihrem Gehalt über dem Durchschnitt aller Gehälter? SELECT name, vorname FROM mitarbeiter WHERE gehalt > (SELECT FROM AVG(gehalt) mitarbeiter); Seite 283

284 Unterabfragen in HAVING-Klauseln SELECT MIN(m.gehalt) "min gehalt", m.abt_id, a.abt_name FROM mitarbeiter m, abteilung a WHERE m.abt_id = a.abt_id GROUP BY m.abt_id, a.abt_name HAVING MIN(m.gehalt) >= (SELECT MIN(m.gehalt) FROM mitarbeiter WHERE m.abt_id = 11); Ergebnis der Hauptabfrage Seite 284

285 Welche Mitarbeiter sind in der höchsten Gehaltstufe? SELECT FROM WHERE BETWEEN m.name, m.vorname, g.gehalt_stufe mitarbeiter m, gehaltstufe g m.gehalt (SELECT MAX(g.gehalt_von) FROM gehaltstufe g) AND (SELECT MAX(g.gehalt_bis) FROM gehaltstufe g) AND m.gehalt BETWEEN g.gehalt_von AND g.gehalt_bis; Seite 285

286 Multiple Row-Unterabfragen geben mehrere Zeile zurück verwenden Multiple Row Vergleichsoperatoren Operator IN Bedeutung Gleich einem Element aus der Liste ANY ALL EXISTS Vergleicht einen Wert mit jedem Wert der Ergebnisliste. Wert wird mit allen von der Unterabfrage zurückgegebenen Werten verglichen Fragt Existenz von Werten ab Seite 286

287 Operator ANY in Multiple Row Unterabfragen SELECT m_id, name, vorname, job_id, gehalt FROM mitarbeiter WHERE gehalt < ANY ( SELECT gehalt FROM mitarbeiter WHERE job_id = 10) AND job_id <> 10; mitarbeiter Seite 287

288 Operator ALL in Multiple Row Unterabfragen SELECT m_id, name, vorname, job_id, gehalt FROM mitarbeiter WHERE gehalt < ALL ( SELECT gehalt FROM mitarbeiter WHERE job_id = 10) AND job_id <> 10; mitarbeiter Seite 288

289 Operator IN und NOT IN in Multiple Row Unterabfragen Welche Mitarbeiter sind keine Chefs? SELECT FROM WHERE m.name, m.vorname mitarbeiter m m.m_id NOT IN (SELECT v.chef_id FROM mitarbeiter v) mitarbeiter Ergebnis Seite 289

290 ACHTUNG bei NULL-WERTEN in einer Unterabfrage Welche Mitarbeiter sind keine Chefs? SELECT FROM WHERE m.name, m.vorname mitarbeiter m m.m_id NOT IN (SELECT v.chef_id FROM mitarbeiter v) mitarbeiter Es wird kein Ergebnis geliefert. Seite 290

291 Beim Operator IN gibt es mit NULL-Werten keine Probleme: Welche Mitarbeiter sind Chefs? SELECT FROM WHERE m.name, m.vorname mitarbeiter m m.m_id IN (SELECT v.chef_id FROM mitarbeiter v) mitarbeiter Ergebnis Seite 291

292 EXISTS and NOT EXISTS SELECT FROM m.name, m.vorname mitarbeiter m WHERE EXISTS (SELECT FROM WHERE 'c' mitarbeiter v v.chef_id = m.m_id) Seite 292

293 Unterabfragen können auch in der FROM-Klausel verwendet werden Welche Mitarbeiter liegen mit ihrem Gehalt über dem Durchschnitt in ihrer Abteilung? SELECT FROM WHERE AND a.abt_id,a.name, a.vorname, a.gehalt, b.durchschnittgehalt mitarbeiter a, (SELECT abt_id, AVG(gehalt) durchschnittgehalt FROM mitarbeiter GROUP BY abt_id) b a.abt_id = b.abt_id a.gehalt > b.durchschnittgehalt Seite 293

294 Mengenoperatoren Mengenoperatoren kombinieren die Ergebnisse von zwei oder mehreren Abfragen Es wird unterschieden zwischen UNION INTERSECT MINUS Gibt alle eindeutigen Zeilen von einer der beiden Abfragen zurück Gibt alle eindeutigen Zeilen zurück, die von beiden Abfragen geliefert werden Gibt alle eindeutigen Zeilen zurück, die von der ersten SELECT-Anweisung, nicht jedoch von der zweiten SELECT-Anweisung geliefert werden. Seite 294

295 Die Anzahl und Datentypen der Spalten müssen in allen von der Abfrage verwendeten SELECT-Anweisungen identisch sein. Die Spaltennamen müssen nicht identisch sein. Für die Syntax gilt SELECT FROM WHERE UNION SELECT FROM WHERE attribut, tabellenname1 bedingung attribut, tabellenname2 bedingung Seite 295

296 Beispiel für UNION mitarbeiter job_historie Ausgabe des aktuellen Jobs und aller vorherigen Jobs eines Mitarbeiters SELECT FROM m_id, job_id mitarbeiter UNION SELECT FROM m_id, job_id job_historie; Seite 296

297 Strategien zur Formulierung von SELECT-Anweisungen Wie soll die Ergebnisliste aussehen Welche Tabellen werden benötigt? Aliasnamen für Tabellen verwenden, sobald mehr als eine Tabelle verwendet werden Welche Attribute sollen angezeigt werden? Welche virtuellen Spalten kommen vor? Welche (Gruppen-) Funktionen kommen vor? Falls man das Ergebnis einer Gruppenfunktion anzeigen will, darf die Ergebnistabelle entweder nur einen Wert haben oder es muss eine GROUP BY Anweisung folgen, in der die übrigen Ergebnisspalten aufgenommen werden. Seite 297

298 Werden mehrere Tabellen verwendet? Damit kein kartesisches Produkt entsteht, muss eine JOIN- Bedingung angegeben werden. Welche Selektionsbedingungen liegen vor? Bezieht sich die Bedingung auf eine einzelne Zeile, so muss die WHERE-Klausel verwendet werden. Bezieht sich die Bedingung auf eine Gruppe von Zeilen, so muss mit GROUP BY die HAVING Klausel verwendet werden. Unterabfragen Liegen Vergleichswerte in einer anderen Tabelle? Besteht der Vergleichswert aus mehr als einer Zeile, wird eine Unterabfrage mit ANY, ALL, IN oder EXISTS formuliert Eine Ordnung wird durch ORDER BY erreicht. Seite 298

299 Views Eine View ist eine virtuelle Tabelle, d.h. sie ist nicht physisch vorhanden. Eine View enthält keine Daten. Eine View basiert auf einer Tabelle oder einer anderen View. Man bezeichnet die Tabellen, auf denen eine View basiert als Basistabellen. Eine View wird im Data Dictionary als SELECT-Anweisung gespeichert. Seite 299

300 Vorteile von Views Der Einsatz von Views dient zur Beschränkung von Datenzugriffen Erleichterung von komplexen Abfragen Erzielung von Datenunabhängigkeit Darstellung von verschiedenen Ansichten derselben Daten Analog zu Tabellen können nicht zwei Views mit dem identischen Namen innerhalb einer Datenbank angelegt werden. Seite 300

301 Das Erstellen von Views Die Syntax für das Erstellen einer View lautet CREATE VIEW viewname [(alias, )] AS SELECT- Anweisung [WITH CHECK OPTION] Seite 301

302 Bemerkung zur Syntax Die SELECT-Anweisung darf kein ORDER BY enthalten Werden keine Attribute angegeben, so werden die in der SELECT- Anweisung angegebenen Spalten für die View-Definition verwendet. CHECK OPTION bedeutet, dass beim Ändern in der VIEW automatisch darauf geachtet wird, dass die View-Definition in der SELECT-Anweisung durch die Änderung nicht verletzt wird. Seite 302

303 Beispiel für das Anlegen einer View Es soll eine View erstellt werden, die nur die Informationen der Mitarbeiter aus den Abteilungen 5 und 11 enthält. CREATE VIEW v_mitarbeiter_abt5_11 AS SELECT m_id, name, vorname, abt_id FROM mitarbeiter WHERE abt_id IN (5,11) SELECT * FROM v_mitarbeiter_abt5_11 ergibt Seite 303

304 Auch durch Änderungen in der View können die Inhalte der Tabelle verändert werden UPDATE v_mitarbeiter_abt5_11 SET name = 'Schuttemann WHERE m_id = 50; SELECT * FROM mitarbeiter WHERE m_id = 50 ergibt Seite 304

305 Klausel WITH CHECK OPTION verwenden Zunächst wird eine View ohne die CHECK OPTION angelegt CREATE VIEW AS SELECT FROM INNER JOIN ON INNER JOIN ON WHERE v_mitarbeiter_abtsitz_muc m.m_id, m.name, m.vorname, m.gehalt, m.abt_id mitarbeiter m abteilung a m.abt_id = a.abt_id standort s a.abt_sitz = s.abt_sitz s.stadt = 'München' SELECT * FROM v_mitarbeiter_abtsitz_muc ergibt Seite 305

306 Ändert man nun einen Datensatz mit Hilfe der View UPDATE v_mitarbeiter_abtsitz_muc SET abt_id = 10 WHERE m_id = 50; der Mitarbeiter m_id = 50 wird nicht mehr angezeigt so ergibt SELECT * FROM v_mitarbeiter_abtsitz_muc ergibt Seite 306

307 Klausel WITH CHECK OPTION verwenden Nun legt man eine identische View mit Hilfe der WITH CHECK OPTION an CREATE VIEW v_mitarbeiter_abtsitz_muc AS SELECT m.m_id, m.name, m.vorname, m.gehalt, m.abt_id FROM mitarbeiter m INNER JOIN abteilung a ON m.abt_id = a.abt_id INNER JOIN standort s ON a.abt_sitz = s.abt_sitz WHERE s.stadt = 'München' WITH CHECK OPTION SELECT * FROM v_mitarbeiter_abtsitz_muc ergibt auch hier Seite 307

308 Ändert man nun einen Datensatz mit Hilfe der View UPDATE v_mitarbeiter_abtsitz_muc SET abt_id = 10 WHERE m_id = 50; so ergibt sich die Fehlermeldung Seite 308

309 Mit der Klausel WITH CHECK OPTION wird sichergestellt, dass auf eine View angewandte DML-Operationen nur innerhalb der Zeilen ausgeführt werden können, die die View selektieren kann. Falls versucht wird, DML-Operation für Zeilen auszuführen, die von der View nicht ausgewählt wurden, wird eine Fehlermeldung erzeugt. Seite 309

310 Mit der Klausel WITH CHECK OPTION können diskrete Werte für Views als zugelassene Werte definiert werden CREATE VIEW aufmwst AS SELECT * FROM auftrag WHERE mwst IN (0,0.07,0.16) WITH CHECK OPTION Seite 310

311 Auch virtuelle Spalten sind zugelassen CREATE VIEW AS SELECT FROM v_leistnet (anr, lnr, ltext, ldatum, netto) anr, lnr, ltext, ldatum, lanz*lsatz leistung Benutzt man Spaltenaliasnamen in der CREATE VIEW Anweisung, so müssen diese in der selben Reihenfolge angegeben werden, wie die Spalten in der Unterabfrage Ein INSERT, UPDATE oder DELETE auf dieser View, die einen Wert des Attributes netto verändert, wird mit einer Fehlermeldung zurückgewiesen, da netto ein berechnetes Feld ist. Seite 311

312 Views mit Gruppierungen CREATE VIEW v_abt_gehalt (abteilungsname, min_gehalt, max_gehalt, avg_gehalt) AS SELECT a.abt_name,min(m.gehalt), MAX(m.gehalt), AVG(m.gehalt) FROM mitarbeiter m INNER JOIN abteilung a ON m.abt_id = a.abt_id GROUP BY abt_name werden Gruppenfunktionen benutzt, so müssen Alias- Spaltennamen verwendet werden SELECT * FROM v_abt_gehalt Seite 312

313 Auch DISTINCT kann verwendet werden CREATE VIEW AS SELECT DISTINCT FROM v_leiter v.name, v.vorname,v.gehalt mitarbeiter m, mitarbeiter v WHERE m.chef_id = v.m_id SELECT * FROM v_leiter Seite 313

314 DML-Operationen für eine View Es können keine DML-Operationen auf Views durchgeführt werden, wenn die View Gruppenfunktionen GROUP BY Klauseln DISTINCT enthält. Dann kann die View auch nicht mit der WITH CHECK OPTION angelegt werden. Auch darf kein UPDATE oder INSERT auf einem abgeleiteten Feldern durchgeführt werden. Seite 314

315 Es können keine Daten über eine View eingefügt werden, wenn es NOT NULL Spalten in den Basistabellen gibt, die nicht für die View ausgewählt wurden. Beispiel: Die View v_mitarbeiter_abt5 sei definiert durch CREATE VIEW v_mitarbeiter_abt5 AS SELECT m_id, name, gehalt FROM mitarbeiter WHERE abt_id = 5; Das Einfügen eines Tupels über die View erfolgt durch INSERT INTO v_mitarbeiter_abt5 VALUES (80,'Birker', 6023) Seite 315

316 Falls das Attribut vorname in mitarbeiter ein NOT NULL Attribut ist, ergibt sich beim INSERT die Fehlermeldung Seite 316

317 View entfernen Views werden mit DROP VIEW viewname gelöscht Eine View wird ungültig, wenn die Basistabelle nicht mehr vorhanden ist. Sobald die Basistabelle wieder vorhanden ist, wird auch die View erneut gültig. Seite 317

318 Indizes Ein Index ist ein Datenbankobjekt Ein Index kann die Geschwindigkeit von Abfragen erheblich beschleunigen. Indizes können auch verwendet werden um für eine Spalte oder eine Gruppe von Spalten Eindeutigkeit zu erzwingen. Seite 318

319 Wie werden die Datensätze bei einer SELECT Anweisung bearbeitet? Beispiel SELECT FROM WHERE name, vorname mitarbeiter name = 'Birker ' Ohne die Verwendung eines Indizes werden alle Datensätze der Tabelle sequentiell durchsucht und es wird überprüft ob der name im Datensatz = 'Birker' ist. Man spricht von einem Full Table Scan. Bei sehr großen Datenmengen in den Tabellen führt dies zu langen Antwortzeiten. Seite 319

320 Um das Suchen der gewünschten Datensätze zu beschleunigen, setzt man Indizes ein. Ein Index ermöglicht den unmittelbaren und schnellen Zugriff auf Zeilen einer Tabelle. Indizes sind unabhängig von der indizierten Tabelle, d.h. sie können jederzeit ohne Auswirkungen auf die zu Grunde liegende Tabelle erstellt oder gelöscht werden. Wird eine Tabelle gelöscht, so werden alle zugehörigen Indizes ebenfalls gelöscht. Seite 320

321 Wie arbeitet ein Index Es gibt unterschiedliche Index-Strategien. In einem relationalen DBMS wird meistens ein B * -Baum Index verwendet. B * - Bäume sind ausbalancierte Baumstrukturen, deren Blattknoten alle den gleichen Abstand zum Wurzelknoten haben. Vorteil von B * - Bäume sind die extrem kurzen Suchpfade von der Wurzel zum Blatt. Ein weiterer wichtiger Index ist der Bitmap Index, der z.b. im DataWarehouse Umfeld eingesetzt wird. Seite 321

322 Welche Spalten müssen/sollten indiziert werden? Indizes werden automatisch erstellt bei Verwendung eines PRIMARY KEY- Constraints UNIQUE- Constraints Eine manuelle Indizierung sollte erfolgen bei Fremdschlüsselspalten (der Index wird nicht automatisch durch Constraint erzeugt) Häufig verwendete Spalten Seite 322

323 Indizes erstellen Ein Index wird durch die folgende Syntax erstellt: CREATE INDEX indexname ON tabellenname(attribut1[,attribut2] ); Beispiel: Ein Index wird für das Attribut name in der Tabelle mitarbeiter angelegt CREATE INDEX mitarbeiter_name_idx ON mitarbeiter (name); Seite 323

324 Zusammengesetzte Indizes Auch mehrere Spalten können zusammen einen Index bilden. Man spricht dann von einem zusammengesetzten Index. Beispiel: Ein Index wird für die Attribute name und gehalt der Tabelle mitarbeiter angelegt CREATE INDEX mitarbeiter_name_gehalt_idx ON mitarbeiter (name, gehalt); Seite 324

325 Bemerkung zur Indizierung Der Einsatz von Indizes sollte gut überlegt sein. Mehrere Indizes auf einer Tabelle führen nicht unbedingt zu schnelleren Abfragen. Bei jeder DML-Operation, die für eine Tabelle mit Indizes ausgeführt wird, müssen die Indizes aktualisiert werden. Je mehr Indizes auf dieser Tabelle sind, umso höher ist der Aktualisierungsaufwand. Seite 325

326 Wann sollte ein Index erstellt werden? In den folgenden Fällen sollte ein Index erstellt werden Eine Spalte enthält eine große Anzahl von Werten Eine Spalte enthält viele NULL-Werte Eine oder mehrere Spalten werden häufig gemeinsam in einer WHERE- Klausel oder Join-Bedingung verwendet Die Tabelle ist sehr groß und die meisten Abfragen rufen wahrscheinlich nicht mehr als 5 % der Zeilen ab. Seite 326

327 Wann sollte kein Index erstellt werden? In den folgenden Fällen sollte kein Index erstellt werden Die Tabelle ist klein Die Spalten werden selten als Bedingung in einer Abfrage verwendet Die meisten Abfragen rufen wahrscheinlich mehr als 5 % der Zeilen ab. Die Tabelle wird häufig aktualisiert Seite 327

328 Transaktionen Seite 328

329 Beispiel für Transaktionen Überweisung von einem Konto auf ein anderes Konto. Konto 100 EUR werden überwiesen Seite 329

330 Um diese Überweisung durchzuführen sind zwei Schritte notwendig: 1. Reduzierung des Kontostandes mit der Kontonummer um 100 UPDATE konto SET kontostand = kontostand -100 WHERE konto_nr = Erhöhung des Kontostandes mit der Kontonummer um 100 UPDATE konto SET kontostand = kontostand +100 WHERE konto_nr = Seite 330

331 Diese UPDATES müssen beide ausgeführt werden. Kann durch einen Fehler nur das erste UPDATE ausgeführt werden, so kommt es zu inkonsistenten Daten in der Datenbank. Fehler können z.b. auftreten durch Programmierfehler in der Anwendung Systemabstürze Fehleingaben des Benutzers Damit solche Inkonsistenzen nicht entstehen können gibt es bei DBMS das Transaktionskonzept. Seite 331

332 Transaktionen sind Arbeitseinheiten, die als Gruppe in einer logischen Reihenfolge, komplett oder gar nicht ausgeführt werden. Eine Transaktion hat einen definierten Anfang und ein definiertes Ende. Erst wenn alle Arbeitseinheiten abgearbeitet sind, wird das Ergebnis in der Datenbank gespeichert. Eine Transaktion überführt einen konsistenten Datenbestand in einen neuen konsistenten Datenbestand. Seite 332

333 Das Erstellen von Transaktionen Die beiden entscheidenden Schlüsselwörter für eine Transaktion sind COMMIT zum Abschließen einer laufenden Transaktion ROLLBACK zum Zurücksetzen einer laufenden Transaktion. Die DBMS, die Tranksaktionen unterstützen, gehen bzgl. der Syntax mit Transaktionen unterschiedlich um. Alle diese DBMS müssen dem System explizit mitteilen können, dass eine Transaktion beginnt. Seite 333

334 Das Erstellen von Transaktionen Transaktionen werden erstellt durch Anweisung zum Beginn der Transaktion Anweisung1 Anweisung2 COMMIT oder ROLLBACK der Transaktion Im SQL-Server wird der Beginn einer Transaktion durch BEGIN TRANSACTION eingeleitet, Oracle benutzt für den Beginn die Anweisung SET TRANSACTION Seite 334

335 Beispiel: SQL-Server Transaktion für die Banküberweisung BEGIN TRANSACTION UPDATE konto SET kontostand = kontostand -100 WHERE konto_nr = UPDATE konto SET kontostand = kontostand +100 WHERE konto_nr = COMMIT TRANSACTION durch das COMMIT wird die Transaktion abgeschlossen und die Werte in die Datenbank geschrieben. Seite 335

336 Beispiel: Zurücksetzen einer laufenden Transaktion Transaktionen können stets bevor sie mit COMMIT bestätigt wurden - mit ROLLBACK zurückgesetzt werden. BEGIN TRANSACTION UPDATE konto SET kontostand = kontostand +100 WHERE konto_nr = UPDATE konto SET kontostand = kontostand -100 WHERE konto_nr = ROLLBACK TRANSACTION durch das ROLLBACK wird die laufende Transaktion zurückgesetzt. Seite 336

337 Sicherungspunkte Durch ein ROLLBACK werden die gesamten Aktionen innerhalb der Transaktion rückgängig gemacht. Einige DBMS (wie Oracle und SQL Server) können für ihre Transaktionen sog. Sicherungspunkte setzen. Eine Transaktion kann dann nur bis zu dem bestimmten Sicherungspunkt rückgängig gemacht werden. Seite 337

338 Beispiel Sicherungspunkte für den SQL Server BEGIN TRANSACTION Anweisung1: Buche Betrag von Konto K1 ab SAVE TRANSACTION t1 Anweisung2: Füge diesen Betrag zu Konto K2 hinzu Ein ROLLBACK TRANSACTION t1 macht Anweisung2 rückgängig, nicht aber Anweisung1. Ein ROLLBACK TRANSACTION macht sowohl Anweisung1 als auch Anweisung2 rückgängig. Seite 338

339 Beispiel Sicherungspunkte für Oracle In Oracle lautet die Syntax SET TRANSACTION; Anweisung1: Buche Betrag von Konto K1 ab; SAVEPOINT t1; Anweisung2: Füge diesen Betrag zu Konto K2 hinzu; Ein ROLLBACK TO SAVEPOINT t1 macht Anweisung2 rückgängig, nicht aber Anweisung1. Ein ROLLBACK macht sowohl Anweisung1 als auch Anweisung2 rückgängig. Seite 339

340 Transaktionen und Sperren Um die Konsistenz der Daten zu gewährleisten, gibt es das Transaktionskonzept. Eine Transaktion ist dabei eine Folge von Datenbankzugriffen mit folgenden Eigenschaften: Atomarität Eine Tranksaktion ist unteilbar. Das DBMS stellt (mittels Logging- Technik) sicher, dass eine Transaktion selbst im Fall eines Systemabsturzes entweder komplett oder gar nicht durchgeführt wird. Seite 340

341 Konsistenzerhaltung Stellt sicher, dass eine Transaktion die Datenbank in einem gültigen Zustand hinterlässt. Die Kriterien, welcher Zustand als gültig zu betrachten sind, sind Anwendungsspezifisch. Isoliertheit Die Transaktion ist von Effekten anderer Transaktionen isoliert, d.h. gleichzeitig ausgeführte Transaktionen haben keinen Einfluss aufeinander. Sie kann ohne Nebeneffekte zurückgesetzt werden. Seite 341

342 Dauerhaftigkeit Nach Beendigung einer Transaktion wird die Dauerhaftigkeit aller Änderungen garantiert (Persistenz). Das Tranksaktionskonzept realisiert damit das ACID Prinzip durch die Eigenschaften Atomicity, Consistency, Isolation, Durability. Seite 342

343 Sperren Beim Arbeiten mit einer Datenbank kann es passieren, dass zwei Benutzer denselben Datenbestand gleichzeitig bearbeiten wollen. Dies kann zu inkonsistenten Daten führen. Zur Vermeidung dieser Inkonsistenzen müssen die Teile der Datenbank, die von solchen Änderungen betroffen sind, vorübergehend gegen den Zugriff anderer Benutzer gesperrt werden. Die DBMS haben die Möglichkeit, Sperren auf Tabellen oder Zeilen zu setzten und wieder freizugeben. Seite 343

344 Das Sperren bei Transaktionen Hat ein User eine Transaktion gestartet, aber noch nicht mit COMMIT bestätigt, so kann er sich den veränderten Datenbestand schon anzeigen lassen. Die Daten sind aber für jeden anderen Nutzer gesperrt. Erst nach der Bestätigung durch ein COMMIT, kann auf dem neuen Datenbestand durch andere Nutzer zugegriffen werden. Durch dieses Sperren wird Dateninkonsistenz vermieden. Seite 344

345 Logging und Recovery Die geforderte Atomarität einer Transaktion wird in DBMS durch Logging realisiert, d.h. Informationen werden in einem LOG-Protokoll aufgezeichnet. Für eine Transaktion gibt es zwei Arten von Logs: UNDO Log REDO Log Seite 345

346 UNDO Log Beim UNDO Log wird der Zustand der Daten vor ihrer Änderung meist zeilenweise aufgezeichnet. Dieses Log wird im Falle eines ROLLBACK herangezogen REDO Log Das REDO-Log enthält den Zustand der Daten nach der Datenänderung. Durch dieses Log kann eine bereits abgeschlossene Transaktion, deren Änderungen noch nicht in der Datenbank realisiert waren, nachgefahren werden. Das REDO-Log wird beim Hochfahren des Datenbankystems nach einem Ausfall herangezogen. Seite 346

347 Recovery Beim Hochfahren des DBS wird automatisch ermittelt, ob das letzte Abschalten des DBS ordnungsgemäß oder aufgrund eines Fehlers erfolgt ist. Lag ein Fehler vor, wird beim Hochfahren ein Recovery durchgeführt. Bei einem Recovery werden die zum Zeitpunkt der Unterbrechung abgeschlossenen Transaktionen erneut zum Abschluß gebracht (REDO) und die offenen Trankaktionen werden zurückgesetzt. Seite 347

348 Sicherheitskonzept Zugriffsrechte Für ein DBMS ist ein gutes Benutzer und Berechtigungskonzept von entscheidender Bedeutung. In einem DBMS gibt es drei Konzepte Benutzerkonzept Rollenkonzept Privilegienkonzept. Seite 348

349 Es müssen Nutzer für die Datenbanken angelegt werden, Berechtigungen zur Ausführung bestimmter SQL-Anweisungen (d.h. Privilegien) vergeben werden, sowie Rollen, d.h. Gruppen von Privilegien angelegt werden, die Benutzern zugeordnet werden können. Der Datenbankadministrator (DBA) ist ein Benutzer auf höchster Ebene, der alle Systemprivilegien und Objektprivilegien hat. Die gesamte Verwaltung von Benutzern, Privilegien und Rollen kann beim SQL-Server über den SQL Server Enterprise Manager bzw. dem SQL Server Management Studio oder über die Kommandozeile erfolgen. Seite 349

350 Das Benutzerkonzept Das Benutzerkonzept wird anhand des DBMS Microsoft SQL Server beschrieben. Datenbankuser müssen auf zwei Ebenen bekannt sein: 1. SQL-Server 2. Auf den entsprechenden Datenbanken. Seite 350

351 Das Benutzerkonzept für den SQL-Server Eine Anmeldung auf dem SQL-Server erfolgt entweder über SQL Server Authentifizierung oder über das System, d.h. die Domäne, zu der der SQL-Server gehört. im Ordner Sicherheit findet man die Benutzernamen des Servers Seite 351

352 Anlegen eines Users über die Kommandozeile User können mittels DDL-Anweisungen oder mittels gespeicherter Prozeduren angelegt werden. Zunächst werden die gespeicherten Prozeduren vorgestellt: 1. SQL Server-Authentifizierung exec sp_addlogin 'name', 'passwort' [, ' standard db '] Beispiel: Anlegen des Users abcd mit Passwort a23&57v1a3 exec sp_addlogin 'abcd', ' a23&57v1a3 '; Wird keine Standard-Datenbank angegeben, wird als default die Datenbank MASTER gesetzt. Seite 352

353 Löschen eines Users über die Kommandozeile exec sp_droplogin 'name' ; Bemerkung: Ist der zu löschende User noch einer Datenbank zugeordnet, so kann er nicht gelöscht werden. Bemerkung: Beide Prozeduren sollen mit der nächsten SQL-Server Version nicht mehr gültig sein. Stattdessen werden die User mit Hilfe der folgenden DDL-Anweisung angelegt: CREATE LOGIN login_name bzw. mit DROP LOGIN login_name gelöscht. Seite 353

354 Ändern des Passworts eines Users exec sp_password ' pw_alt', 'pw_neu' Der Administrator kann das Passwort für einen User jederzeit neu setzen: exec sp_password NULL, ' pw_neu', 'name_user' Ändern der Standard-Datenbank für einen User exec sp_defaultdb ' name_user', 'db' Seite 354

355 Anlegen eines Users über die Kommandozeile Auch hier gibt es die Möglichkeit über DDL-Anweisungen oder über Stored Procedures User anzulegen. Hier die auszuführenden gespeicherten Prozeduren: 2. Anmeldung über die Domäne exec sp_grantlogin 'domäne\name' Entziehung der Berechtigung für einen User auf den SQL-Server zuzugreifen exec sp_revokelogin 'domäne\name' Seite 355

356 Der Nutzer abcd kann nun auf den SQL-Server zugreifen Als Standard Datenbank wurde test festgelegt Seite 356

357 Er kann aber noch nicht auf seine Standarddatenbank zugreifen. Für die einzelnen Datenbanken müssen die User angelegt werden. Seite 357

358 Verwaltung von Datenbankbenutzern Das Hinzufügen eines Nutzers zu einer Datenbank erfolgt entweder mit Hilfe von Transact SQL Anweisungen oder mit Hilfe von gespeicherten Prozeduren. Die folgenden gespeicherten Prozeduren erlauben bzw. entziehen einem User den Zugriff auf eine bestimmte Datenbank. use datenbankname; exec sp_grantdbaccess 'user_name' ; Mit exec sp_revokedbaccess 'user_name' ; wird ein Benutzer aus einer Datenbank entfernt. Seite 358

359 Mit CREATE USER user_name FOR LOGIN lname kann per Transact SQL ein User für eine Datenbank angemeldet werden. Z.B. USE test CREATE USER abcd FOR LOGIN abcd erlaubt dem User abcd das Arbeiten auf der Datenbank test. Bemerkung: Das Bekanntmachen eines Nutzers in einer Datenbank weist diesem Benutzer keine Rechte auf Datenbankobjekte zu. Seite 359

360 Der User abcd wurde für die Datenbank test angemeldet Nun kann der User abcd auf die Datenbank test zugreifen Seite 360

361 Privilegien Es wird unterschieden zwischen System- und Objektprivilegien. Systemprivilegien wirken Systemweit (z.b. Anlegen und Löschen von Usern, Datenbanken erstellen Rechteverwaltung etc.) Objektprivilegien gelten für ein spezielles Datenbankobjekt (z.b. UPDATE, INSERT.) Diese Privilegien werden entweder einzeln oder durch die Verwendung von Rollen verwaltet. Seite 361

362 Der User abcd hat nach dem Anlegen keinerlei Privilegien auf der Datenbank test. Dem Nutzer abcd müssen Privilegien zugewiesen werden. Seite 362

363 Rollen Eine Rolle ist ein Gruppe verwandter Privilegien. Benutzer werden einer oder mehrere Rollen zugewiesen und erhalten die damit verbundenen Privilegien. Ein Benutzer kann verschiedenen Rollen angehören, und dieselbe Rolle kann von mehreren Benutzern wahrgenommen werden. Im SQL Server gibt es fest vorgegebene Rollen, die durch eigene Rollen ergänzt werden können. Seite 363

364 Einige der vorgegebenen Rollen Es wird unterschieden zwischen Server-Rollen und Datenbank-Rollen. Server-Rollen enthalten Rechte, die zur Administration des gesamten Servers benötigt werden, z.b. Anlegen von Benutzern und Datenbanken oder Herunterfahren des Servers. Alle Mitglieder der Rolle sysadmin haben DBA-Rechte und können damit alle Operationen ausführen. User können einer Server-Rolle durch die Prozedur sp_addsrvrolemember 'rollen_name','user_name' zugewiesen werden. Seite 364

365 Mitglieder von Datenbank-Rollen enthalten Rechte auf Datenbankebene. Mitglieder der Rolle db_owner sind Besitzer einer Datenbank und haben damit innerhalb dieser Datenbank alle Rechte. Mitglieder der Datenbankrolle db_datareader haben die Berechtigung SELECT für jede Tabelle oder View ihrer Datenbank. Sie können niemandem Berechtigungen erteilen oder entziehen. Alle Datenbank Benutzer sind automatisch immer der Rolle public zugewiesen. Rechte die der Rolle public zugewiesen werden gelten damit für alle Nutzer. Seite 365

366 Rollen erstellen Eigene Rollen können entweder über die Transact SQL Anweisung CREATE ROLE rollen_name oder über die Prozedur sp_addrole erzeugt werden. Die so erzeugten Rollen beinhalten noch keine Rechte. Beispiel: exec sp_addrole 'rollen_name' bzw. CREATE ROLE rollen_name Dieser oder andere Datenbank-Rollen können durch die Prozedur sp_addrolemember 'rollen_name','user_name' Benutzer zugewiesen werden. Seite 366

367 sp_droprolemember entfernt Benutzer aus einer Rolle. sp_droprole löscht die Rolle. Alternativ kann ALTER ROLE zum Ändern des Rollennames bzw. DROP ROLE zum Löschen der Rolle verwendet werden. Seite 367

368 Zuordnung von Privilegien Privilegien können Benutzern oder Rollen zugewiesen werden. Zu diesem Zweck gibt es drei Kommandos: GRANT, DENY, REVOKE GRANT fügt vorhandene Rechten ein oder mehrere neue Rechte hinzu. DENY verbietet Privilegien, ist dem GRANT übergeordnet REVOKE entfernt mit GRANT oder DENY erteilte Berechtigungen. Seite 368

369 Syntax für GRANT GRANT Privileg, ALL [PRIVILEGES] ON tabellenname, TO benutzername,. rollenname [WITH GRANT OPTION] entfällt für Datenbankprivilegien Falls WITH GRANT OPTION angegeben ist, kann der Rechteempfänger diese Rechte an andere weitergeben. Mit ALL werden alle Privilegien vergeben. Anstelle eines Tabellennames kann auch ein Viewname angegeben werden. Seite 369

370 Syntax für REVOKE REVOKE Privileg, ALL [PRIVLEGES] ON tabellenname, FROM benutzername,. rollenname [CASCADE] entfällt für Datenbankprivilegien Falls CASCADE angegeben ist und der Rechteempfänger Rechte an andere weitergegeben hat, werden auch diese entfernt. Seite 370

371 Syntax für DENY DENY Privileg, ALL [PRIVILEGES] ON tabellenname, TO benutzername,. rollenname [CASCADE] entfällt für Datenbankprivilegien Seite 371

372 Objekt-Privilegien sind dabei z.b. SELECT INSERT UPDATE DELETE Datenbank-Privilegien sind CREATE TABLE VIEW FUNCTION Das Privileg CREATE DATABASE kann nur in der Datenbank MASTER vergeben werden. Seite 372

373 Beispiel GRANT SELECT ON TO mitarbeiter PUBLIC; => jeder Nutzer hat SELECT Rechte auf der Tabelle mitarbeiter; exec sp_addrole 'rolle_test' GRANT SELECT, UPDATE, INSERT ON mitarbeiter TO rolle_test exec sp_addrolemember 'rolle_test', 'abcd' DENY UPDATE ON mitarbeiter TO abcd Seite 373

374 Das Anlegen und Verwalten der User, Privilegien und Rollen über das SQL Server Management Studio 1. Zugriff auf den SQL-Server Seite 374

375 Das Anlegen und Verwalten der User, Privilegien und Rollen über das SQL Server Management Studio 2. Zugriff auf die Datenbanken Über Eigenschaften des SQL-Users in Sicherheit\Anmeldungen können die Zugriffe auf die einzelnen Datenbanken definiert werden. Seite 375

376 Das Anlegen und Verwalten der User, Privilegien und Rollen über das SQL Server Management Studio 3. Rollen definieren Seite 376

377 Das Anlegen und Verwalten der User, Privilegien und Rollen über das SQL Server Management Studio 4. Rechte den Rollen oder Usern zuweisen Seite 377

378 Transact-SQL und PL/SQL Transact-SQL und PL/SQL sind Datenbankprogrammiersprachen des SQL-Servers und Oracle. SQL ist ein Abfragesprache. Dies reicht für eine Datenbankprogrammierung nicht aus. Prozedurale Elemente fehlen. Transact-SQL bzw. PL/SQL sind prozedurale Spracherweiterungen zu SQL. Sie werden unter anderem zur Erstellung von Triggern, Stored Procedures und userdefinierten Funktionen benötigt. Seite 378

379 Der SQL-Server: Transact-SQL Es werden zwei Arten von Variablen unterschieden: Benutzerdefinierte Variablen. Sie werden innerhalb eines Transact-SQL Programms vom Benutzer erzeugt und gelten nur innerhalb dieses Programms. Deklariert werden sie durch das reservierte Wort DECLARE gefolgt vom Variablennamen und dem Datentyp. Der Name der Variablen beginnt mit Globale Variablen. Ihr Inhalt wird durch das System zugewiesen. Geben Informationen z.b. über das System. Der Name beginnt mit Eine Wertzuweisung erfolgt durch eine SET-Anweisung oder durch eine SELECT- Anweisung. Seite 379

380 Kontrollstrukturen in Transact-SQL Wie in jeder höheren Programmiersprache gibt es in Transact-SQL Kontrollstrukturen. Unterschieden werden die zwei Kategorien Auswahlund Schleifenstruktur. Repräsentiert werden die beiden Kategorien durch IF-ELSE und WHILE. Seite 380

381 Oracle: PL/SQL Der Deklarationsteil eines PL/SQL-Blocks beginnt mit dem reservierten Wort declare. Variablen werden deklariert durch die Syntax variablenname datentyp := initialwert; (die Zuweisung eines Initialwertes ist hier optional) Seite 381

382 Der Ausführungsteil in PL/SQL Nach dem Deklarationsblock folgt der Ausführungsteil. Dieser wird durch begin und end eingeschlossen. PL/SQL kennt die Kontrollstrukturen IF THEN ELSIF ENDIF LOOP EXIT WHILE LOOP FOR LOOP GOTO Seite 382

383 Gespeicherte Prozeduren Stored Procedures Seite 383

384 Stored Procedures Gespeicherte Prozeduren sind wichtige Bestandteile im Datenbankbetrieb. Sie können Datenbankverwaltung und wartung vereinfachen und beschleunigen. Sie können große Gruppierungen von SQL Anweisungen, Transact SQL bzw. PL/SQL Anweisungen enthalten. Sie können mit großer Geschwindigkeit ausgeführt werden, weil viele zur Abarbeitung erforderliche Schritte bereits bei der Erzeugung bzw. beim ersten Aufruf durchgeführt werden. Seite 384

385 Die Anweisungen innerhalb einer Stored Procedure laufen alle nacheinander auf dem Datenbank-Server ab. Es erfolgt erst nach Beendigung aller Anweisungen ein Datenaustausch mit dem Client- Rechner. Dies führt zu einer deutlichen Performance-Steigerung. Stored Procedures können Werte zurückgeben und können auf Eingabeparametern beruhen. Sie können beim Start des Datenbank Servers automatisch ausgeführt werden Sie werden explizit aufgerufen. Seite 385

386 Das Erstellen von Stored Procedures Syntax für den MS SQL-Server: CREATE PROCEDURE Prozedurname {;Nummer} Datentyp} [VARYING] [=default][output]] [WITH {RECOMPILE ENCRYPTION }] [FOR REPLICATION] AS SQL-Anweisungen Seite 386

387 Ein Beispiel für eine einfache Stored Porcedure CREATE PROCEDURE sp_mitarbeiterabt_11 AS SELECT name, vorname FROM mitarbeiter WHERE abt_id = 11 ORDER BY name DESC Um die Prozedur auszuführen wird der Befehl EXEC verwendet: EXEC sp_mitarbeiterabt_11 Seite 387

388 Den Quelltext der Stored Procedure erhält man durch Ausführen der Stored Procedure sp_helptext spname Beispiel: EXEC sp_helptext sp_mitarbeiterabt_11 ergibt Seite 388

389 Die Abhängigkeiten der Stored Procedure erhält man durch Ausführen der SP sp_depends spname d.h. EXCEC sp_depends sp_mitarbeiterabt_11 ergibt Seite 389

390 Auch eine Gruppe von gespeicherten Prozeduren kann erstellt werden: CREATE PROCEDURE sp_g_mitarbeiter; 1 AS SELECT name, vorname FROM mitarbeiter WHERE abt_id = 11 GO CREATE PROCEDURE sp_g_mitarbeiter; 2 AS SELECT name,vorname, abt_name FROM mitarbeiter m INNER JOIN abteilung a ON m.abt_id = a.abt_id INNER JOIN standort s ON a.abt_sitz = s.abt_sitz WHERE s.stadt = 'München' GO Seite 390

391 Bemerkung zur Prozedurengruppe Bei einer Prozedurengruppe wird nur eine einzige Prozedur angelegt, die mehrere Prozeduren als Gruppe beinhaltet. Im Beispiel hat die Prozedur den Namen sp_g_mitarbeiter. Die Referenzierung der einzelnen Prozeduren erfolgt über Prozedurengruppenname; Nummer Im Beispiel: EXEC sp_g_mitarbeiter;2 führt die zweite Prozedur innerhalb der Gruppe aus Seite 391

392 Parameter in Stored Procedures Die folgende Zeile ist für SP mit Parametern zuständig: Datentyp} [VARYING] legt den Namen des Parameters innerhalb der Prozedur fest. Innerhalb einer Prozedur können bis zu 1024 Parameter verwendet werden. Hinter dem Parameternamen muss der Datentyp angegeben werden. Mit = default kann für diesen Parameter ein default Wert angegeben werden. Dieser wird gesetzt, wenn beim Ausführen der Prozedur kein Wert hierfür angegeben wird Seite 392

393 OUTPUT bedeutet, dass der Parameter ein Rückgabeparameter darstellen soll. VARYING bezieht sich auf die zurück gelieferte Datenmenge/Cursor. Seite 393

394 Beispiel: Berechnung des Durchschnitts von 3 Zahlen CREATE PROCEDURE real OUTPUT AS = (@param1 Seite 394

395 Um den Wert von myavg zu verwenden, muss zunächst eine Variable deklariert werden. real Danach kann die Prozedur mit den Werten ausgeführt werden: EXEC sp_mydurchschnitt3 10, 14, OUTPUT Jetzt kann das Ergebnis angezeigt werden: SELECT 'Der Durchschnitt ist: Seite 395

396 Bei Verwendung von default-werten sollte die Reihenfolge beachtet werden CREATE PROCEDURE real int = int = int = 0 AS = (@param1 Beim Ausführen der Prozedur müssen nicht alle Paramter angegeben werden. Die Reihenfolge ist entscheidend. Z.B. Wert, default, Wert ist nicht möglich. EXEC OUTPUT, 4 Seite 396

397 Bemerkung Die Werte müssen an die gespeicherte Prozedur in einer festgelegten Reihenfolge übergeben werden. Eine Übergabe als benannte Parameter ist möglich, indem man die Werte in der Form Parametername = Wert übergibt. Damit kann eine beliebige Reihenfolge angegeben werden. real EXEC = = = 0 Seite 397

398 Rückgabe mit RETURN Statt der Verwendung des Schlüsselworte OUTPUT innerhalb der gespeicherten Prozedur und bei der Ausführung der Prozedur kann auch das Schlüsselwort RETURN verwendet werden. CREATE PROCEDURE int AS int = sp_addition 6,9,0 SELECT 'Das Ergebnis Seite 398

399 Die Option WITH RECOMPILE kann in der Anweisung CREATE PROCEDURE oder in der Anweisung EXEC PROCEDURE stehen. Wird die Option in CREATE PROCEDURE eingesetzt, wird der Ausführungsplan für die Prozedur nicht im Prozedurcache gespeichert. Die gesamte Prozedur wird bei jedem Ablauf neu kompiliert. Wird WITH RECOMPILE in der Anweisung EXEC PROCEDURE verwendet, so wird die gespeicherte Prozedur einmal bei der Ausführung kompiliert und der neue Ausführungsplan anschließend für nachfolgende Aufrufe von EXEC PROCEDURE im Prozedurcache gespeichert. Seite 399

400 Die Option WITH ENCRYPTION Die Option WITH ENCRYPTION verschlüsselt die zur Erzeugung der Prozedur eingesetzten SQL-Anweisungen. Beispiel CREATE PROCEDURE sp_kunde WITH ENCRYPTION AS SELECT kname, kvorname FROM kunde versucht man nun den Quelltext anzuzeigen, erhält man die Meldung Seite 400

401 Das Löschen von gespeicherten Prozeduren Wie alle Datenbankobjekt werden auch SP mit dem reservierten Wort DROP gelöscht. DROP PROCEDURE prozedurname; Prozedur-Gruppen können nur komplett gelöscht werden. Um eine einzelne Prozeduren innerhalb der Gruppe zu löschen, muss die gesamte Gruppe gelöscht werden und mit dem veränderten Quelltext erneut angelegt werden. Seite 401

402 Kontrollstrukturen innerhalb einer Stored Procedure Wie in anderen Programmiersprachen gibt es in Transact-SQL und PL/SQL Kontrollstrukturen. Syntax für Transact-SQL IF boolean_ausdruck {Anweisungsblock} [ELSE {Anweisungsblock}] Die Schleife wird durch folgende Syntax abgebildet: WHILE boolean_ausdruck {Anweisungsblock} [BREAK] Seite 402

403 Ein komplexeres Beispiel für eine Stored Procedure artikel gruppe Mit Hilfe einer Stored Procedure sollen Werte in die Tabelle artikel eingefügt werden. Die Werte werden in der Form Artikelbezeichnung, Artikelpreis, Gruppenbezeichnung eingegeben. Zurückgegeben werden soll die Id des eingefügten Datensatzes Seite 403

404 CREATE PROCEDURE varchar(50) AS int SELECT FROM = gruppen_id = gruppen_bez = max(a_id)+1 FROM artikel Seite 404

405 IS NOT NULL INSERT artikel (a_id,a_bez,a_preis,gruppen_id) VALUES ELSE BEGIN int = max(gruppen_id)+1 FROM gruppe INSERT VALUES gruppe INSERT VALUES END artikel Seite 405

406 Einfügen des Datensatzes 'Keyboard-Super', 35.6, 'Tastatur' int = sp_insert_artikel 'Keyboard-Super',35.6,'Tastatur' Einfügen des Datensatzes 'easyklick', 10.,'Maus' int = sp_insert_artikel 'easyklick',10.,'maus' Seite 406

407 Demonstration der Übersetzungszeit für Prozeduren anhand einer mehrfach aufgerufenen Stored Procedure Beispiel Seite 407

408 Anhand der Prozedur sp_messwert wird der Zeitaufwand für einen Übersetzungsprozess simuliert -- Diese Prozedur erzeugt einen neuen Messwert für eine Geräte-ID mit vorgegebenem Zeitstempel CREATE PROCEDURE datetime AS INSERT INTO messungen (mgi,wert,gemessen_am,geprueft_am,prid) NULL, NULL) Seite 408

409 Mehrfacher Aufruf der Testprozedur mit Zeitmessung Seite 409

410 Laufzeit-Ergebnisse Laufzeit mit Prozeduraufruf, aber ohne Recompile Laufzeit mit Prozeduraufruf, aber mit Recompile Seite 410

411 Datenbank-Trigger Seite 411

412 Trigger Trigger sind eine Art gespeicherte Prozeduren, die automatisch gestartet werden, sobald ein vordefiniertes Ereignis und zwar eine Datenmodifikation eintritt. Sie sind direkt einer Tabelle oder View zugeordnet. Trigger reagieren nur auf DML-Kommandos, d.h. auf Insert, Update oder Delete. Trigger können keine Parameter übernehmen und lassen sich nicht explizit aufrufen. Trigger werden standardmäßig nach einer Datenmodifikation ausgelöst oder Ersetzen eine Datenmodifikation. Seite 412

413 Einsatzmöglichkeiten von Triggern Trigger unterstützen die Datenintegrität. Sie können unbefugte oder inkonsistente Datenänderungen verhindern. Trigger sichern die referentielle Integrität Trigger können die Durchsetzung komplexer Unternehmensregeln gewährleisten. Trigger dienen zur Ausführung zusammenhängender Aktionen Seite 413

414 Das Erstellen von Trigger Syntax für den MS SQL-Server: CREATE TRIGGER Triggername ON Tabellenname Viewname [FOR AFTER INSTEAD OF] {INSERT UPDATE DELETE} [WITH ENCRYPTION] AS SQL-Anweisungen Die folgenden Beispiele verwenden diese Syntax. Seite 414

415 Ein einfaches Beispiel für einen Trigger CREATE TRIGGER t_addupmitarbeiter ON mitarbeiter FOR INSERT,UPDATE AS PRINT AS varchar)+ ' Zeilen wurden geändert' Ein Update oder Insert auf die Tabelle mitarbeiter löst den Trigger aus: UPDATE mitarbeiter SET gehalt = gehalt WHERE abt_id = 11 Ergebnis des Triggers Seite 415

416 Die Tabellen inserted und deleted im MS SQL-Server Trigger im SQL-Server benutzen die zwei virtuellen Tabellen inserted und deleted, die vom SQL-Server selber erstellt und verwaltet werden. Diese beiden Tabellen haben die identische Struktur wie die Tabelle, die dem Trigger zugrunde liegt, d.h. wie die Basistabelle. Seite 416

417 AFTER bzw. FOR Trigger Die Tabelle deleted enthält alle Zeilen, die aus der Basistabelle gelöscht wurden. Die Tabelle inserted enthält alle Zeilen, die der Basistabelle zugefügt worden sind oder verändert wurden. INSTEAD OF Trigger Die Tabelle deleted enthält alle Zeilen, die aus der Basistabelle gelöscht werden sollen. Die Basistabelle ist noch unverändert. Die Tabelle inserted enthält alle Zeilen, die der Basistabelle zugefügt bzw. verändert werden sollen. Seite 417

418 Beispiel: Erstellung eines Triggers, der einen Datensatz in die Tabelle bestell einfügt, sobald der Bestand eines Artikels < 10 wird. artikel CREATE TRIGGER tr_bestell ON artikel AFTER UPDATE AS INSERT bestell SELECT artnr FROM inserted WHERE bestand < 10; Seite 418

419 Beispiel: Erstellung eines eigenen Autoincrements CREATE TRIGGER t_autoinc_kunde ON kunde INSTEAD OF INSERT AS int = max(a_id) FROM kunde; IS NOT NULL ELSE = 1 INSERT INTO kunde kname, kwert FROM inserted Seite 419

420 Beispiel: Erstellen eines Lösch-Triggers, der Datensätze nur dann aus der Tabelle kunde löscht, falls der Kunde keine offenen Aufträge mehr hat. CREATE TRIGGER tr_loeschkontrolle ON kunde INSTEAD OF DELETE AS IF < 2) BEGIN IF ((SELECT auftraege FROM deleted) = 0) BEGIN DELETE FROM kunde WHERE kdnr = (SELECT kdnr FROM deleted) END ELSE PRINT 'Fehler! Auftraege ist > 0' END ELSE PRINT 'Dieser Befehl ist nur für einzelne Zeilen zulässig!' Seite 420

421 Auslösen des Triggers DELETE FROM kunde WHERE kdnr = 1 löst die folgende Fehlermeldung aus DELETE FROM kunde WHERE kdnr = 2 löscht den Datensatz Seite 421

422 Beispiel: Erstellen des Triggers, der die Preise der gelöschten Artikel in einer separaten Tabelle aufsummiert. CREATE TRIGGER tr_loeschsumme ON artikel INSTEAD OF DELETE AS IF <2) BEGIN UPDATE loeschsumme SET summe = ( SELECT summe FROM loeschsumme)+ (SELECT preis FROM deleted) DELETE FROM artikel WHERE artnr = (SELECT artnr FROM deleted) END ELSE PRINT 'Dieser Befehl ist nur für einzelne Zeilen zulässig!' Seite 422

423 Trigger können eingesetzt werden um die referentielle Integrität zu gewährleisten. Beispiel: kunde nur dieser Kunde darf gelöscht werden auftrag Ein Trigger soll gewährleisten, dass nur Kunden gelöscht werden dürfen, die keine Aufträge in der Tabelle Auftrag haben. Seite 423

424 CREATE TRIGGER tr_integr ON kunde INSTEAD OF DELETE AS IF < 2) BEGIN IF( 0 = (SELECT COUNT(*) FROM auftrag WHERE kdnr = (SELECT kdnr FROM deleted)) ) DELETE FROM kunde WHERE kdnr = (SELECT kdnr FROM deleted) ELSE PRINT 'Für diesen Kunden sind noch Aufträge vorhanden' END ELSE PRINT 'Dieser Befehl ist nur für einzelne Zeilen zulässig!' Seite 424

425 Ein Löschen des Kunden mit der kdnr = 1 ist nicht möglich DELETE FROM kunde WHERE kdnr = 1 Seite 425

426 Sicherung von Datenbanken Seite 426

427 Die richtige Datensicherung ist ein wichtiger Aspekt für den Datenbankbetrieb. Welche Datensicherung für die entwickelte Datenbankanwendung am besten bzw. am sinnvollsten ist, sollte bereits während der Projektphase entschieden werden. Für die Durchführung der Datenbanksicherungen ist meist der Datenbankadministrator zuständig. Verantwortlich für die Initiierung ist der Leiter oder das IT- Sicherheitsmanagement. Die Art der Datensicherung ist von dem jeweiligen Datenbanksystem abhängig. Fehlende Datensicherung können nach Auffassung der Gerichte juristische Konsequenzen nach sich ziehen. Seite 427

428 Bei der Wahl der Datensicherung spielen die folgenden Kriterien eine Rolle Wie viele Daten beinhaltet die Datenbank Wie wichtig sind die Daten für das Unternehmen Wie wird die Verfügbarkeit der Daten für das Unternehmen eingestuft Wie oft werden die Daten verändert Seite 428

429 Hat man sich für ein Sicherungsverfahren entschieden, müssen folgende Punkte geklärt werden: Welche Medien benutzt man zur Sicherung Wie oft soll gesichert werden Wann soll gesichert werden, d.h. wann ist die geringste Last auf dem Server Wie lange sollen Sicherungskopien aufgehoben werden Wie lange dauert die Wiederherstellung einer Sicherungskopie Seite 429

430 Datensicherung einer Datenbank Auszüge aus dem IT-Grundschutzhandbuch des Bundesamtes für Sicherheit in der Informationstechnik Die Sicherung der Daten eines Datenbanksystems kann in der Regel nicht mit den Datensicherungsprogrammen auf Betriebssystemebene vollständig abgedeckt werden. Zur Sicherung des DBMS und der Daten müssen die jeweiligen Dienstprogramme des DBMS eingesetzt werden. Seite 430

431 Auszüge aus dem IT-Grundschutzhandbuch des Bundesamtes für Sicherheit in der Informationstechnik Möglichkeiten einer Datenbanksicherung Komplettsicherung der Datenbank in heruntergefahrenem Zustand. Dies ist die einfachste und sicherste Methode, die allerdings aus Gründen der Verfügbarkeitsanforderungen an die Datenbank oder aufgrund des zu sichernden Datenvolumens oft nicht durchführbar ist. Online-Sicherung der Datenbank. Die Sicherung erfolgt während des laufenden Betriebs, d.h. Datenbank muss nicht heruntergefahren werden. Nachteile: Inkonsistenzen können nicht explizit ausgeschlossen werden. Zusätzlich muss eine Offline-Komplettsicherung bestehen. Seite 431

432 Partielle Datenbanksicherung Sollte immer dann verwendet werden, wenn das zu sichernde Datenvolumen zu groß ist, um eine vollständige Sicherung durchführen zu können. Seite 432

433 Auszüge aus dem IT-Grundschutzhandbuch des Bundesamtes für Sicherheit in der Informationstechnik Für die Datensicherung eines Datenbanksystems muss ein eigenes Datensicherungskonzept erstellt werden. Einflussfaktoren für ein solches Konzept sind: Verfügbarkeitanforderungen an die Datenbak Wenn beispielsweise eine Datenbank werktags rund um die Uhr zur Verfügung stehen muss, so kann eine Komplettsicherung nur am Wochenende durchgeführt werden, da dies im allgemeinen ein Herunterfahren der Datenbank erfordert. Seite 433

434 Datenvolumen Das gesamte zu sichernde Datenvolumen muss mit den zur Verfügung stehenden Sicherungskapazitäten verglichen werden. Dabei muss festgestellt werden, ob die Sicherungskapazität für das entsprechende Datenvolumen der Datenbank ausreichend dimensioniert ist. Falls dies nicht der Fall ist, muss ein Konzept zur Teilsicherung des Datenvolumens erstellt werden. Maximal verkraftbarer Datenverlust Wiederanlaufzeit Die maximal zulässige Zeitdauer des Wiederherstellens der Datenbank nach einem Absturz muss festgelegt werden, um den Verfügbarkeitsanforderungen zu genügen. Seite 434

435 Datensicherungsmöglichkeiten der Datenbank-Software Im allgemeinen werden von einer Datenbank-Standardsoftware nicht alle denkbaren Datensicherungsmöglichkeiten unterstützt, wie z.b. eine partielle Datenbanksicherung. Dies ist vorab zu prüfen. Seite 435

436 Anhand dieser Informationen kann ein Konzept für die Datensicherung der Datenbank erstellt werden. In diesem Sicherungskonzept wird u.a. festgelegt wer für die ordnungsgemäße Durchführung von Datensicherungen zuständig ist, in welchen Zeitabständen eine Datenbanksicherung durchgeführt wird, in welcher Art und Weise die Datenbanksicherung zu erfolgen hat, zu welchem Zeitpunkt die Datenbanksicherung durchgeführt wird, die Spezifikation des zu sichernden Datenvolumens je Sicherung, wie die Erstellung von Datensicherungen zu dokumentieren ist, wo die Datensicherungsmedien aufbewahrt werden. Seite 436

437 Ergänzende Kontrollfragen: Existiert eine Dokumentation, wie im Falle eines Absturzes der Datenbank diese wiederherzustellen ist? Ist für die Institution ein aktuelles Datensicherungskonzept für den Bereich Datenbanken dokumentiert? Wie werden Mitarbeiter über den sie betreffenden Teil des Konzeptes unterrichtet? Wird die Einhaltung dieses Konzeptes kontrolliert? Wie werden Änderungen der Einflussfaktoren berücksichtigt? Seite 437

438 Technische Verfahren zur Datensicherung - Spiegelung, Duplexing und Striping - Zwei Festplatten bezeichnet man als gespiegelt, wenn sie exakt die gleichen Daten enthalten. Eine Änderung der Daten auf der einen Festplatte, führt auch zu einer Änderung der Daten auf der gespiegelten Platte. Beide Platten werden von einem gemeinsamen Controller angesteuert. Unter Duplexing versteht man eine Spiegelung, wobei aber jede Festplatte einen eigenen Festplattencontroller besitzt. Beim Striping werden die Daten gleichmäßig auf verschiedene Festplatten verteilt. Angesteuert werden die Festplatten von einem gemeinsamen Controller. Seite 438

439 RAID Konzept RAID = Redundant Array of Inexpensive Disk bzw. Redundant Array of Independent Disk Das RAID Konzept ist in der Industrie weit verbreitet. Es gibt mehrere Stufen. Festplatten werden in RAID-Array konfiguriert, um die auf den Festplatten enthaltenen Daten zu schützen und eine hohe Verfügbarkeit zu gewährleisten. Seite 439

440 Die wichtigsten RAID Stufen RAID 0: Festplattenstriping ohne Paritätsinformationen RAID 1: Spiegelung oder Duplexing. RAID 5: Festplattenstriping mit Parität. Paritätsdaten werden auf alle Festplatten verteilt. RAID 10: Festplattenspiegelung mit Striping, wobei ein Festplattenarray auf einen anderen Satz von verteilten Festplatten mit einem separaten Controller gespiegelt wird. Seite 440

441 Die Datenbank im Netz Verteilte Datenbanken, Replikation, ODBC Seite 441

442 Verteilte Datenbanken In einem Netzwerk befinden sich mehrere Datenbanken, die miteinander verknüpft sind. Die einzelnen lokalen Datenbanken werden so zu einer einheitlichen Sicht zusammengefasst, dass sie sich für den Anwender als eine logische Gesamtdatenbank darstellt. Das DBMS sorgt dafür, dass die Anfragen und Änderungen der Anwender auf die richtigen Daten im Netz zugreifen. Verteilte Datenbanken werden im wesentlichen aus zwei Gründen eingesetzt: aus Performancegründen zur dezentralen Datenhaltung (Replikation) Seite 442

443 Verteiltes Datenbanken-Design Das Design einer verteilten Datenbank erfolgt in den folgenden Schritten Zunächst wird das globale Datenmodell entworfen. Dieser Schritt gilt für alle Datenbanken, d.h. er ist unabhängig von einer Verteilung Fragmentierung bzw. Partitionierung. Fragmente können ganze Tabellen oder Teile von Tabellen sein. Zuordnung der Fragmente zu den vorgesehenen Datenbanken. Seite 443

444 Fragmentierung bzw. Partitionierung Unter Fragmentierung versteht man die disjunkte Zerlegung einer Tabelle in Teiltabellen. Diese Partitionen werden auf die einzelnen dezentralen Datenbanken (Knoten) verteilt. Fragmentierung dient zur Performance- und Verfügbarkeits- Optimierung. Seite 444

445 Replikation Unter Replikation versteht man die redundante Speicherung von Tabellen oder Tabellen-Fragmenten auf unterschiedlichen Knoten. Man unterscheidet im wesentlichen drei Arten von Replikation: synchrone Replikation asynchrone Replikation symmetrische Replikation Seite 445

446 Gründe für die Anwendung von Replikation Zugriffsoptimierung: Kopien der Daten werden am Ort der Verarbeitung gespeichert. Dadurch werden Lese-Zugriffe auf entfernte Datenbankknoten vermieden. => Verringerung von Netzwerkzugriffen und Lastverteilung für die Datenbankserver. Verfügbarkeitsoptimierung: Dadurch, dass die Tabellen mehrfach im Verbund vorhanden sind, ergibt sich eine höherer Verfügbarkeit. Seite 446

447 Synchrone Replikation Bei der synchronen Replikation werden Tabellen in einer zentralen Datenbank gehalten. Auf mehreren Knoten werden Kopien dieser Tabelle redundant abgelegt. Diese bezeichnet man als Replikate. Die Replikate zusammen mit der Basistabelle der zentralen Datenbank enthalten zu jedem Zeitpunkt inhaltlich identische Daten. Schreiboperationen auf den Tabellen müssen in allen anderen Replikaten nachvollzogen werden. Hierfür eignet sich der Einsatz von Triggern. Seite 447

448 Eigenschaften der Synchronen Replikation Vorteil: Ein Anwender liest seine Daten stets von der Datenbank, die am nächsten für ihn liegt. Dadurch wird das Netz, sowie die zentrale Datenbank nicht belastet. Nachteil: Eine Datenänderung muss in allen Replikaten nachgeführt werden. Dies geschieht, sobald das Netz verfügbar ist. Synchrone Replikationen eigenen sich, wenn bevorzugt Leseoperationen auf den Tabellen durchgeführt werden. Seite 448

449 Beispiel für den Einsatz von Synchronen Replikationen: Literatur-Datenbank, die Artikel aus Fachzeitschriften enthält. Auf diese Datenbank finden sehr viele Lesezugriffe durch eine Vielzahl von Clients statt. Schreibzugriffe finden in geringerer Zahl beim Zufügen neuer Artikel statt. Seite 449

450 Asynchrone Replikation Bei der asynchronen Replikation gibt es nur einen Knoten, auf dem die Tabellen geändert werden können (Masterknoten). Dieser Masterknoten enthält immer den aktuellen Datenbestand. Die anderen Knoten enthalten Kopien dieses Masters. Die Aktualisierung der Kopien erfolgt nur periodisch. Dies führt dazu, dass die Daten nicht konsistent sind. Die Kopien werden auch als Snapshot bezeichnet. Seite 450

451 Bemerkung zur Asynchrone Replikation Asynchrone Replikation eignet sich nur, wenn es auf die Aktualität der Datenbestände nicht ankommt. Auf Snapshots kann nur lesend zugegriffen werden. Die Datenaktualisierung durch den Master ist unkritisch. Snapshots eigenen sich besonders gut für Tabellen mit Stammdaten. Stammdaten verändern sich mit einer niedrigen Frequenz. Nach jedem Versionswechsel der Stammdaten sollte eine Aktualisierung der Snapshots stattfinden. Seite 451

452 Symmetrische Replikation Asynchrone und Synchrone Replikation sind die beiden Hauptarten der Replikation. Es gibt eine Reihe weiterer Replikationsarten, die eine Mischform oder Erweiterung der beiden Hauptarten darstellt. Die Symmetrische Replikation ist ein Überbegriff dieser Mischformen und Erweiterungen. Seite 452

453 Einige Arten der Symmetrischen Replikation Mehrere Master Kopien der Tabellen werden auf mehrere Knoten verteilt: Jede Kopie kann verändert werden. Transaktionen werden wenn möglich- auf allen Knoten zeitgleich durchgeführt. Falls dies auf einem Knoten nicht möglich ist, werden die Änderungen für diesen Knoten in eine Warteschlage gestellt und erst übertragen, wenn der Knoten wieder zugänglich ist. Aktualisierbare Snapshots Änderungen können auch an einem Snapshot durchgeführt werden. Die Änderungen werden an den Masterknoten übertragen, der dann eine Verteilung an die anderen Knoten vornimmt. Seite 453

454 Gemischtes Verfahren Kombiniert Verfahren der mehreren Master und der aktualisierbaren Snapshots. Bemerkung: Die symmetrische Replikation kann zu Konflikten führen, wenn an zwei verschiedenen Orten auf den gleichen Daten etwas geändert wird. Daher müssen Regeln definiert werden, die das Konfliktfreie Durchführen von Transaktionen sicherstellen. Seite 454

455 Durchführung von verteilten Transaktionen Verteilte Transaktionen sind Transaktionen, für die gilt: Von der Datenmanipulation sind mehrere Datenbanken betroffen Die gesamte Transaktion wird durch ein COMMIT oder ROLLBACK abgeschlossen. Zur Wahrung der Konsistenzerhaltung und Atomarität bei verteilten Transaktionen wird z.b. das sog. Two Phase Commit Protokoll benutzt. Seite 455

456 Jeder der verteilten Datenbankserver hat eine spezielle Softwarekomponente des DBMS, den sog. Transaktionsmanager. Der Transaktionsmanager des Datenbankservers, von wo aus die Transaktion gestartet wurde, kommuniziert mit den anderen an der Transaktion beteiligten Transaktionsmanagern. Seite 456

457 Das Two Phase Commit Protokoll 1. Phase (Prepare Phase) In dieser Vorbereitungsphase schickt der Transaktionsmanager des auszuführenden Servers eine Prepare Aufforderung an alle beteiligten Server, um sie zur Schaffung der Voraussetzung für ein Commit oder Rollback zu veranlassen. Nachdem die Logs geschrieben wurden, schicken die Server eine Antwort auf die Prepare Aufforderung an den Transaktionsmanager. Seite 457

458 2. Phase (Commit Phase) Wenn alle beteiligten Server eine positive Bestätigung geschickt haben, schickt der Transaktionsmanager eine COMMIT Aufforderung an alle Server. Ansonsten verschickt er eine ROLLBACK Aufforderung. Erst dann schließen die Server die Transaktionen ab bzw. machen sie rückgängig. Seite 458

459 ODBC Bei ODBC handelt es sich um eine standardisierte Methode, die den Zugriff auf Datenbanken erlaubt. Hierbei muss nicht berücksichtigt werden, aus welchem Programm auf welche Datenbank zugegriffen werden. ODBC stammt ursprünglich von Microsoft, ist aber inzwischen auch für eine Reihe von anderen Betriebssystemen verfügbar. ODBC steht für Open DataBase Connectivity. Anwendung Anwendung Anwendung ODBC-Schnittstelle DBS DBS DBS Seite 459

460 ODBC ODBC wird dem Bereich Middelware zugerechnet, d.h. einer Softwareschicht, die zwischen Anwendung und Datenhaltungssystem liegt. Mit Hilfe von ODBC greift ein Anwendungsprogramm über eine -auf dem Client installierte- Standardschnittstelle auf das DBMS zu. Mit ODBC wird ein Standard API zur Verfügung gestellt, das eine einheitliche Anwendungsprogrammierung für unterschiedliche DBMSe ermöglicht. ODBC beruht auf einer Spezifikation, die von der SQL-ACCESS Group unter Federführung von Microsoft ins Leben gerufen wurde. ODBC ist ein ISO-Standard. Seite 460

461 Vor- und Nachteile von ODBC Vorteil: ODBC wird eingesetzt um einen Datenbankzugriff unabhängig vom DBMS-Hersteller zu ermöglichen. Reduzierter Aufwand bei der Treiberentwicklung. Nachteil: Performance-Verlust durch zusätzliche Schicht. Es kann nur auf eine Untermenge der verfügbaren Datenbankfunktionen zugegriffen werden. Teilweise problematische Anwendungen durch die unterschiedliche SQL-Syntax der verschiedenen DBMS- Anbieter. Seite 461

462 Alternativen zu ODBC Datenbank bzw. Programmiersprachenspezifische DBMS Schnittstellen z.b. hat PHP Schnittstellen zu über 20 verschiedenen Datenbanken. Vorteile dieser Schnittstellen: Sie können den gesamten Funktionsumfang der Datenbank abdecken Höhere Kommunikations-Geschwindigkeit Nachteile dieser Schnittstellen: Erhöhter Aufwand bei der Treiberentwicklung Erhöhter Aufwand bei der Wartung Erhebliche Flexibilitätseinbußen beim Datenbankwechsel Seite 462

463 ODBC einrichten für einen MS SQL-Server Seite 463

464 Datenquelle hinzufügen Seite 464

465 Es folgen weitere Treiberspezifische Formulare, die hier nicht aufgeführt werden. Diese müssen beim SQL- Server vorerst nicht verändert werden. Seite 465

466 Damit ist die ODBC Vebindung vom Client zur Datenbank hergestellt. Seite 466