IT-Kompaktkurs. Datenbanken Skript zur Folge 8. Prof. Dr. Dieter Rummler Fachhochschule Deggendorf

Transkript

1 IT-Kompaktkurs Skript zur Folge 8 Prof. Dr. Dieter Rummler Fachhochschule Deggendorf

2 SQL (Structured Query Language) Zunächst einige Nachteile von ACCESS: Bei sehr großen Datenmengen (mehrere GB) kann ACCESS nicht mehr eingesetzt werden. Höchstens 255 Anwender können gleichzeitig mit einer ACCESS-Datenbank arbeiten. Nach einem Absturz von ACCESS gibt es keine Wiederherstellungsroutine. Im Netz werden immer alle Daten übertragen ohne Berücksichtigung von WHERE- Kriterien. Das Sicherheitskonzept von ACCESS ist nicht sehr mächtig. Vorteil von ACCESS: Die ACCESS-Oberfläche ist aber sehr bedienerfreundlich, Formulare und Berichte sind sehr einfach (grafisch zu erstellen). ACCESS bietet sich deshalb als Frontend-Tool an mit Zugriff auf die Daten einer Server-Datenbank, z.b. ORACLE, SQL SERVER. Intern wird jede Abfrage in SQL umgesetzt die Notwendigkeit von SQL hat dabei mehrere Gründe: 1. Man kann nicht alle Abfragen grafisch erstellen, z.b. Subselects. 2. SQL ist eine der meistgenutzten Programmiersprachen der Welt, da auf alle relationalen mittels SQL auf Daten zugegriffen wird. (siehe Folie 1) SQL steht für Structured Query Language und ist seit 1987 offizieller Standard des ANSI. Die Mathematische Grundlage bildet dabei die Mengenlehre. SQL ist nicht prozedural, sondern ergebnismengenorientiert. Das Ergebnis ist also wieder eine Menge. (siehe Folie 2) Die Möglichkeiten von SQL: Man kann so ziemlich alles im Zusammenhang mit relationalen machen: Vergeben von Benutzerberechtigungen GRANT Anlegen von Tabellen, Feldern CREATE Manipulation von Daten mit UPDATE, INSERT und DELETE Auswerten von Daten: SELECT-Abfragen (siehe Folie 3) Unterschied zwischen prozedural und Mengenergebnisorientiert: Beispiel Karteikasten: Prozedural Man überlegt sich hier zunächst, wo man im Karteikasten zu lesen anfängt. Am Anfang oder am Ende oder geht man einen der daneben liegenden Zettel durch, auf denen z.b. alle Mitarbeiterdaten nach Namen sortiert sind mit der Angabe der Kartennummer oder sortiert man vielleicht zunächst einmal den ganzen Karteikasten um. Was macht man nun aber, wenn man eine Karte gefunden hat? Hört man dann auf zu suchen, oder sucht man weiter? Man überlegt sich also wie man vorgeht, um die entsprechenden Daten zu finden. Einfacher wäre es natürlich, wenn man sich selber darum gar nicht kümmern müsste, sondern einem Karteikastenexperten sagen könnte, was ich für ein Ergebnis haben möchte. Dieser Experte kennt die Karteikarten ganz genau und weiß deshalb auch viel besser, ob es günstiger ist, über einen der Zettel vorzugehen, oder sequentiell zu suchen. Insbesondere Seite 2

3 wenn Daten aus mehreren Karteikästen zusammengesucht werden sollen, ist es natürlich von entscheidender Bedeutung für die Dauer der Suche, in welcher Reihenfolge man die einzelnen Karteikästen durchsucht. (siehe dazu Folie 4) Oben haben wir unsere Mitarbeitertabelle bereits erwähnt. Angenommen man will aus dieser Tabelle heraus jetzt Strasse und Stadt von allen Personen sehen, die Franz heißen, dann kann man nun ein Programm formulieren, in dem der Zugriff auf die Daten angegeben wird. (siehe Folie 5) Dazu muss man eine Programmierlogik entwickeln, mit Schleifen, Wenn-Abfragen,... - Darin muss auch technisches Wissen enthalten sein, z.b. ob ein Index genutzt wird, wie die Tabelle geöffnet wird, usw. In SQL dagegen gibt man nur an, welches Ergebnis man haben will, nicht den Weg, wie es erreicht werden soll. Damit überläßt man dem Datenbankmanagementsystem die Entscheidung wie zeitlich am schnellsten die Zugriffe erfolgen sollen - dazu verfügt das Datenbankmanagementsystem z.b. über statistische Daten der einzelnen Tabellen, und kann damit erkennen, ob es z.b. besser ist, einen Satz nach dem anderen zu lesen, oder gezielt über einen Index zuzugreifen. Ergebnismengenorientiert: (siehe Folie 6) Gib mir alle Mitarbeiter, die Franz heißen, mit Name, Straße, Ort, wobei sie nach Ort sortiert sein sollen Die vorherige Ausführungen enthielten dabei noch keinen SQL-Code, der wird nun Schritt für Schritt entwickelt. Am besten veranschaulicht man das über die graphische Möglichkeit von ACCESS, Abfragen zu erstellen. Hinter Abfragen steckt im Prinzip immer ein SQL-SELECT. Erstellt man eine neue Abfrage, wählt man zunächst aus den bestehenden Tabellen bzw. Abfragen aus. Dies ergibt SELECT FROM tabelle. Dann kann man die Felder aus den Tabellen mit DRAG and DROP in die Feldzeile ziehen. (Übertragen auf Karteikästen bedeutet dies, dass ich die Karteikästen zusammengestellt habe, aus denen ich Karten entnehmen will.) (siehe Folie 7) Hier z.b.: Name, Straße, Stadt Damit ergibt sich die SELECT - ausgewählte Felder - FROM tabelle. Damit sind die anzuzeigenden Spalten festgelegt (Übertragen auf die Karteikarten bedeutet das, dass nicht alle Daten auf einer Karteikarte interessant sind.) Die anzuzeigenden Zeilen kann man ebenfalls einschränken. Nämlich durch Einträge in der Kriterienzeile unterhalb des jeweiligen Feldes (siehe Folie 8) Hier z.b. Franz bei Namen Dies bewirkt eine WHERE-Angabe im SQL-Befehl (Hinsichtlich der Karteikästen bedeutet dies, dass ich nicht alle, sondern nur bestimmte Karten entnehme.) (siehe Folie 9) Sortieren der Daten: Seite 3

4 (siehe Folie 10) Dazu gibt man in der Sortierungszeile unter dem entsprechenden Feld Aufsteigend oder Absteigend an, dies bewirkt im SELECT-Befehl eine ORDER-BY-Angabe. Die Felder nach denen man sortiert, müssen dabei nicht unbedingt auch angezeigt werden, in der ACCESS-Abfrage entfernt man dazu einfach das Häkchen in der Anzeigen-Zeile. Verarbeiten mehrerer Tabellen gleichzeitig Angenommen man will gleichzeitig Felder aus der Mitarbeitertabelle - nämlich Mitarbeiternummer und Name - und aus der Abteilungstabelle verwenden - nämlich Abteilungsbezeichnung und Budget. (siehe Folie 11) Das Auswählen beider Tabellen geschieht folgendermaßen: Man wählt in der Abfrage die Mitarbeiter- und die Abteilungstabelle aus, wodurch der SELECT-Befehl hinter FROM nun diese beiden Tabellen ausweist. Danach zieht man dann die gewünschten Felder aus den beiden Tabellen nach unten. (siehe Folie 12) Führt man nun den SQL-Befehl aus, erhält man ein entsprechendes Ergebnis. (siehe Folie 13) Zeigt man zusätzlich noch die Daten aus den beiden betroffenen Tabellen an, so bemerkt man, dass man viel zu viele Ergebnissätze erhält. Worin liegt nun der Fehler? Man hat 12 Sätze erhalten, es dürfen aber eigentlich nur 4 Sätze sein. Nämlich einer pro Mitarbeiter. Statt dessen sind für jeden Mitarbeiter 3 Sätze vorhanden. Es wurde jeder Mitarbeiter mit jeder der drei Abteilungen kombiniert. Problem: Woher sollte die Abfrage wissen, wie es die Sätze der beiden Tabellen kombinieren muss? Wenn nichts angegeben ist, wird, wie es das karthesische Produkt zweier Mengen vorschreibt, jeder Satz der einen Tabelle mit jedem Satz der anderen Tabelle verknüpft. Lösung: Wenn man im Datenmodell eine Verknüpfungslinie zwischen den Abteilungsnummern in der Abteilungs- und in der Mitarbeitertabelle gezogen hat erkennt ACCESS, dass jeder Mitarbeiter eine Abteilungsnummer speichert und kann darüber die entsprechende Abteilung verknüpfen. Wenn man dann die beiden Tabellen für die Abfrage auswählt, wird automatisch diese Beziehung in die Abfrage übernommen. (siehe Folie 14) Damit wird dann im SQL-Befehl eine Gleichsetzung der Abteilungsnummer in der Abteilung mit der Abteilungsnummer vom Mitarbeiter erzeugt, man nennt dies auch join-befehl. Führt man dann die Abfrage aus, erhält man wie erwartet die vier Mitarbeiter mit den jeweiligen Abteilungsdaten. (siehe Folie 15) Schauen wir uns noch zwei letzte Aufgabenstellung an, die etwas schwieriger sind: Man will zunächst alle Projekte sehen, denen noch keine Mitarbeiter zugewiesen sind. Das bedeutet, man möchte alle Projekte auswerten, bei denen es eben keine Verknüpfung zu der Mitarbeiterprojekttabelle gibt. Das realisiert man mit einem sogenannten outer join (siehe Folie 16) In der Abfrage macht man dazu einen Doppelklick auf die Beziehung und wählt dann das zweite Optionsfeld; dabei erhält dann die Beziehungslinie oben einen Pfeil nach rechts - nun würde man alle Projekte erhalten, ob sie nun über zugewiesene Mitarbeiter verfügen oder nicht. Seite 4

5 Wenn man nun nur die Projekte ohne Mitarbeiter sehen will, muss man die Ergebnismenge einschränken, indem man NULL als Kriterium beim Primärschlüssel der Mitarbeiterprojekttabelle angibt. (siehe Folie 17) Im SQL-Befehl erkennt man dann das Schlüsselwort LEFT JOIN bei der Verknüpfung von Primär- und Fremdschlüssel. In relationalen ist NULL ein besonderer Eintrag und bedeutet, dass keine Daten für das Feld vorhanden sind. SUBSelect - der schwierigste SQL-Befehl: Man will nun alle Mitarbeiter sehen, die in derselben Abteilung arbeiten, wie eine anzugebende Person. (siehe Folie 15) Wenn Huber eingegeben wird, soll also Huber und Franz ausgegeben werden, da beide in der Abteilung arbeiten, in der Huber arbeitet usw. Man will also alle Kollegen sehen, die ein Mitarbeiter in seiner Abteilung hat. Bei diesen Fragestellungen ist SQL nicht so einfach wie gewohnt, denn hier muss man prozedural vorgehen, insofern man ja zunächst die Abteilung des eingegeben Mitarbeiters suchen muss und dann erst im zweiten Schritt alle Mitarbeiter aus dieser gefundenen Abteilung selektieren kann. Es sind also zwei Schritte notwendig, die durchgeführt werden müssen. Diese werden in Form eines subselects durchgeführt. Grafisch geht man in ACCESS so vor, dass man zunächst eine Abfrage zum Suchen der Abteilung realisiert und diesen SQL- Code dann über die Zwischenablage in die übergeordnete Abfrage als Kriterium übernimmt. (siehe Folie 18) Man wechselt dann in die Abfrage, die die Abteilung (Fremdschlüssel manr-feld) liefert, in der ein Mitarbeiter arbeitet - im Kriterium wurde ein Text in eckigen Klammern angegeben, dies bewirkt eine Eingabemöglichkeit des zu selektierenden Mitarbeiters (siehe Folie 19) Im SELECT ist nun wiederum ein SELECT im Abteilungs-Kriterium angeben. Wenn man nun den SQL-Befehl ausführt, erhält man zunächst eine Eingabeaufforderung und dann die Ergebnismenge, wie man Sie erwartet hat (siehe Folie 20) Seite 5