3.3. Datenbanken - New Media
Werbung
3.3. Datenbanken Eine wesentliche Funktion eines Computersystems besteht darin, Daten, Texte, Bilder, Sprache, Sounds (oder auch Kombinationen mehrerer Informationsarten) zu speichern, so dass deren bedarfsgerechtes, insbesondere rasches und einfaches Wiederauffinden und Nutzen ermöglicht wird. Für den Benutzer eines Personalcomputers tritt häufig die Situation auf, dass Informationen ausgewertet und weiterbearbeitet werden sollen, die z. B. in mehreren unterschiedlichen Graphiken, Berichten und Spreadsheets enthalten sind. Diese Dokumente sind oft mittels unterschiedlicher Softwarepakete erstellt bzw. in unterschiedlichen Dateiformaten abgespeichert worden. Das Wiederauffinden und vor allem das Nutzen dieser Dokumente erfordert daher Kenntnisse über die jeweils eingesetzten PC-Dateiformate. (Siehe Kap.1.2.2.) In diesem Abschnitt geht es insbesondere darum, wie große Datenmengen dauerhaft und zuverlässig gespeichert und bei Bedarf abgerufen werden können. Dazu ist es erforderlich, die für einen oder mehrere Benutzer relevanten Ausschnitte aus der Realität einzugrenzen, und letztere in konventionellen Dateisystemen oder in Datenbanken abzubilden. Grundlegende Fragen der Datenorganisation und der Planung von Datenbanksystemen sowie verbreitete Werkzeuge zur Nutzung von Datenbanken (insbesondere SQL) sind daher weitere Inhalte dieses Abschnittes. Bei moderneren Implementierungen von Datenbanken wird in die Funktionen: DatenbankClient und Datenbank-Server unterschieden. In letzter Zeit sind auch verteilte Datenbankkonzepte bzw. Schnittstellen zwischen Datenbanken unterschiedlicher Hersteller entwickelt worden. Allmählich finden SQL-Kommandos bzw. Schnittstellen zu SQL-Datenbanken nicht nur bei PC-Datenbanksoftwarepaketen, sondern auch bei sonstigen Werkzeugen der Individuellen Datenverarbeitung (z. B. bei Tabellenkalkulationsprogrammen) Berücksichtigung. Bezüglich der verfügbaren Speichermedien wird auf Kapitel 1.2.7. verwiesen. 3.3.1. Von der Datei zur Datenbank In diesem und in den folgenden Abschnitten geht es um die Abbildung von Teilen der Realität in Dateien und Datenbanken. Es ist dabei stets von einer bedarfsgerechten Abbildung der Wirklichkeit auszugehen. Dateien und Datenbanken enthalten demnach jene Abbildungen der Wirklichkeit (der Produkte, der Lieferanten, der Geschäftsfälle, usw.) die sich für betriebliche und zwischenbetriebliche Informations- und Kommunikationsprozesse als notwendig bzw. brauchbar erweisen. Die Vollständigkeit bzw. Richtigkeit einer Datei oder Datenbank kann nur unter Einbeziehung des realen Umfeldes beurteilt werden. 3.3.1.1. Die Objekte "Datei" und "Satz" Ein Satz (Datensatz, data record, record) bildet ein Objekt der Realität vereinfachend in einem Computersystem ab. Ein solches Objekt (Entität, Entity) kann ein konkreter Gegen- Informationsverarbeitung 1 Stand: August 2006 3.3. Datenbanken 211 stand, ein Ereignis oder auch ein abstrakter Begriff sein. Es wird durch seine Attribute (Merkmale, Eigenschaften) beschrieben. Das Objekt „Lehrbuch“ kann beispielsweise durch die Attribute „Nummer", „Autor“, „Titel", „Preis", „Verlag“, „Auslaufend“ und „Bestand“ beschrieben werden. Die konkreten Inhalte der Attribute eines konkreten Lehrbuches werden Feldern (Datenfelder, fields) zugewiesen. Alle Felder eines konkreten Objektes bilden einen Datensatz. Eine tabellarische Darstellung eignet sich dafür hervorragend. Die Tabelle kann dabei um die Beschreibung weiterer Objekte (im vorliegenden Beispiel Bücher) erweitert werden. Nr Autor Titel 646 Schwab EDV - Projektleitung Preis Verlag Auslaufend Bestand 30,06 mc y 95 Abbildung 3.3/1: tabellarische Darstellung der Attribute Datenfelder bilden die kleinste Einheit von Dateien und Datenbanken. Datenfelder sind mit einem Namen versehen, der sich oftmals mit der Bezeichnung des Attributes deckt und können unterschiedlichen Datentyps sein. Die Felder „Nummer“ und „Bestand“ sind z.B. vom Typ „Ganzzahl“, das Feld „Preis“ vom Typ „Dezimalzahl“. Die Felder „Autor“, „Titel“ und „Verlag“ sind vom Typ „Text“ und das Feld „Auslaufend“ vom Typ „Flag“ (mit den Ausprägungen „y“ oder „n“). Aus gleichartigen Objekten und deren Attributen werden Objektklassen (Objekttypen, Entityklassen) gebildet. Eine Datei (data file, file) bildet eine Objektklasse ab; sie besteht aus einem oder mehreren Datensätzen. Jenes Feld oder jene Felder, mit denen Objekte einer Objektklasse eindeutig identifiziert werden können, werden Schlüssel (Schlüsselfeld/er) genannt. Sind Schlüssel aus mehreren Feldern zusammengesetzt, werden sie als Kombinationsschlüssel bezeichnet. Abb. 3.3/2: Objektklasse Buch - Darstellung als Diagramm. Das Schlüsselfeld ist unterstrichen. Stand: August 2006 Informationsverarbeitung 1 212 Mittendorfer/Pils Ein Primärschlüssel vermag genau einen Satz zu identifizieren (in unserem Beispiel ist dies die pro Objekt (= Buch) vergebene Buchnummer „Nr“). Bisweilen werden auch Sekundärschlüssel definiert, die allerdings dadurch charakterisiert sind, dass sie sich nicht zur Identifizierung genau eines Satzes eignen, sondern Datensätze mit gleichen TeilEigenschaften in eine Klasse zusammenfassen. Im vorliegenden Beispiel ist das Feld „Verlag“ ein Sekundärschlüssel. Welche Objektklassen im konkreten Fall zu bilden sind, welche Eigenschaften und welche Datentypen gewählt werden, hängt insbesondere von den Erfordernissen der zu bewältigenden Aufgaben und von der Sicht des Anwenders ab. In Abhängigkeit von den gestellten Aufgaben ist es zweckmäßig, die konkreten Attribute der Objektklasse "Buch" ev. neu festzulegen oder zu erweitern (z. B. "Erscheinungsjahr", „Rabatte“ und "ISBN" anzufügen), oder auch weitere Objektklassen zu definieren. Die Datei "Buch" besteht nun aus gleichartig strukturierten Sätzen, von denen jeder ein konkretes Buch abbildet. Nachfolgend wird die Datei beispielhaft mittels Tabelle einer Tabellenkalkulations-Anwendung dargestellt. Die erste Zeile enthält die Feldnamen. Das Schlüsselfeld mit der Bezeichnung „Nr“ wurde aus Gründen der Übersichtlichkeit in die erste Spalte gelegt und ist unterstrichen. Die einzelnen Datensätze sind untereinander, zeilenweise angeordnet. Einfache Suchabfragen lassen sich mittels Filter-Funktion durchführen. Abb. 3.3/3: Beispiel für eine konventionelle Datei Derart strukturierte Dateien werden bisweilen auch als flache, klassische oder konventionelle Dateien bezeichnet. Wegen des starken Bezuges zum Aufgabenspektrum einzelner Anwender entsprechen konventionelle Dateien in der Regel nicht der inner- und zwischenbetrieblichen Aufgabenvielfalt. Ein wesentlicher Mangel der Datenorganisation mittels Dateien besteht in auftretenden Redundanzen (überzählige, überflüssige Informationen) und Inkonsistenzen (Widersprüchlichkeiten) innerhalb der Datei und auch zu anderen Dateien, die von anderen Benutzern bzw. Anwendungsprogrammen für andere Aufgabengebiete eines Unternehmens geführt werden. Informationsverarbeitung 1 Stand: August 2006 3.3. Datenbanken 213 Charakteristisch für konventionelle Dateien ist zudem deren starke, gegenseitige Abhängigkeit mit den, auf diese zugreifenden Anwendungsprogrammen. Weiterentwicklungen betrieblicher Abläufe, sowie gesetzliche oder sonstige Änderungen machen häufig Anpassungen in der Struktur der Dateien notwendig. So müssen z.B. neue Felder in eine Datei (oder in mehrere Dateien) eingefügt werden. Im oben dargestellten Beispiel „Lehrbücher“, könnte eine Änderung des Bestell- und Auslieferungsvorganges (der Logistik) die Erweiterung der Datei „Buch“ um das Feld „ISBN“ erfordern. Solche Situationen ziehen auch aufwendige Änderungen in den auf die Dateien zugreifenden Anwendungsprogrammen nach sich. Die Abhängigkeit wirkt jedoch auch umgekehrt: Bei erforderlichen Anpassungen der Anwendungsprogramme müssen häufig auch die dazugehörenden Dateien umgestaltet werden. Datenbanken mit ihren Datenbank-ManagementSystemen bieten Lösungswege aus dieser Problematik. Die Form, in der Dateien (und ihre Sätze) auf Speichermedien physikalisch abgespeichert werden, entspricht nicht der Sichtweise der Benutzer bzw. der Anwendungsprogrammierer. Die Sätze der konventionellen Dateien werden in physische Sätze (Datenblöcke) zusammengefasst und können auf unterschiedlichen Speichermedien abgelegt. Speichermedien unterscheiden sich vor allem durch ihre Zugriffszeit, die Kosten, die Lebensdauer des Mediums, die Schutzmaßnahmen vor Datenverlust. Es ist also davon auszugehen, dass unterschiedliche logische und physikalische Datensichten vorliegen. 3.3.1.2. Nutzung einer konventionellen Datei Anhand der nachfolgend abgebildeten Beispiele sollen einfache Abfragemöglichkeiten in Tabellenkalkulationswerkzeugen erläutert werden. Verwendet wird die Programmfunktion „Spezialfilter“. In den Zeilen 1 und 2 (A1:G2) befindet sich der „Kriterienbereich“ in den Zeilen 4 bis 14 (A4:G14) der Listenbereich, in den Zeilen 15 bis 18 (A15:G18) der Ergebnisbereich. Stand: August 2006 Informationsverarbeitung 1 214 Mittendorfer/Pils Abb. 3.3/4: Beispiel für die Abfrage einer konventionellen Datei Der Eintrag „oev“ im Kriterium „Verlag“ und „>10“ im Kriterium „Bestand“ bewirkt, dass die vorliegende Tabelle nach Büchern des Verlages „oev“ durchsucht wird, deren Bestand größer als „10“ ist. Das Ergebnis ab Zeile 15 zeigt, dass dies auf 3 Bücher zutrifft. Der Vorgang der aus einer Datei jene Datensätze filtert, welche die vorgegebenen Kriterien erfüllen, heißt Selektion. Die Grundlage der Selektion bildet die Anwendung von logischen Operatoren (und, oder, nicht), Vergleichsoperatoren (gleich, ungleich, größer, kleiner. Größer gleich, kleiner gleich) Rechenoperatoren (+, -, *, /) und Spezialoperatoren (enthält, beginnt mit, neben, statt, u.a.m.). Werden hingegen aus der vorliegenden Anzahl der Datenfelder nur bestimmte ausgewählt, so spricht man von Projektion. Selektion und Projektion können auch parallel ausgeführt werden. Informationsverarbeitung 1 Stand: August 2006 3.3. Datenbanken 215 Abb. 3.3/5: Selektion und Projektion Entsprechend der Abbildung 3.3/5 werden Bücher gesucht (C2:D3), die im Titel entweder „Metall“ oder „Werkzeug“ enthalten (Suchkriterien übereinander symbolisieren eine ODERVerknüpfung) UND deren Preis größer 20 ist. Das Ergebnis (A15:D17) zeigt zwei Bücher (Selektion) zu denen der „Preis“, der „Autor“ der „Titel“ und der „Verlag“ ausgegeben wurde (Projektion). 3.3.1.3. DBMS - Datenbank(management)systeme Datenbanksysteme sind dadurch charakterisiert, dass die von mehreren /vielen Benutzern und Programmen verwendete Datenmenge in einem globalen Modell (konzeptionelles Modell) festgelegt wird. Es kommt zu einer Abkoppelung der Probleme der Datenspeicherung und Datenorganisation (diese werden zentral gelöst) von den fachlichen Aufgabenstellungen der Benutzer (vgl. HANSEN 1992, S. 556). Redundanzen werden lediglich aus Gründen der Sicherheit, der Integrität oder der schnelleren Zugriffszeit toleriert (kontrollierte Redundanz). Inkonsistenzen werden soweit wie möglich ausgeschaltet. Datenbanksysteme bestehen aus der Datenbank (data base) und einem DBMS (DatenbankManagement-System, Datenbankverwaltungssystem). Es muss grundsätzlich unterschieden werden, ob das Hierarchische Datenmodell, das Netzwerkmodell oder das am weitesten verbreitete, unten näher erläuterte Relationenmodell zugrunde liegt. Als Relationale DBMS gelten "ORACLE" von Oracle Corporation und "DB2" von IBM. Diese sind für die meisten Rechnerklassen und die verbreitetsten Betriebsysteme verfügbar. In der Windows-Welt spielt darüber hinaus auch das Produkt "SQL Server" von Microsoft eine wichtige Rolle. In der Linux-Welt ist vor allem "mySQL" von Bedeutung. Objektorientierte DBMS (OO-DBMS): Stand: August 2006 Informationsverarbeitung 1 216 Mittendorfer/Pils Objektorientierte Datenbanken haben sich in der kommerziellen Datenverarbeitung nicht durchsetzen können und sind großteils vom Markt wieder verschwunden. Was bleibt sind objektrelationale Erweiterungen der marktführenden RDBMS Systeme, die wesentlich zum Verschwinden der OO-DBMS beigetragen haben. Von einem DBMS zu unterscheiden ist ein Datenbanksystem (DBS). Einem DBS liegt ebenfalls ein bestimmtes Datenmodell für die Strukturierung der Daten zugrunde. Im Unterschied zu einem DBMS fehlen einem DBS aber wesentliche Funktionalitäten (siehe Abb. 3.3.3.2), die für einen (sicheren) Einsatz als Datenbankserver (siehe nächstes Kapitel) erforderlich sind. Typische Beispiele für DBS sind PC-Datenbanksysteme, denen meist das relationale Datenmodell zu Grunde liegt. Das Angebot reicht von lokalen (Einplatz-) Lösungen, über Lösungen mit Multi-User-Betrieb, wobei nur Datenfiles auf einem Server zur Verfügung gestellt werden, bis hin zu PC-Datenbanken, die auf spezielle Datenbankserver oder auf SQL-Server zugreifen können. PC-Datenbank-Softwarepakete können auch danach unterschieden werden, für welche Betriebssystem-Plattformen sie verfügbar sind, und auch danach, ob fremde SQL-Datenbanken angesprochen werden können. Die Datenbanksysteme Filemaker beispielsweise stehen für die Plattformen MS Windows und MacOS mit einer ähnlichen Benutzeroberfläche zur Verfügung. Diese Produkte können zusätzlich auch als Frontend-Systeme für die Nutzung von SQL-Datenbanken (z. B. für eine Oracle-Datenbank) eingesetzt werden (siehe nächstes Kapitel). 3.3.1.3.1. Client-Server-Datenbanklösungen Modernere Datenbanksysteme sind nach der Architektur des Client-Server-Modells konzipiert. Als Client wird ganz allgemein ein Programm verstanden, das die Dienste eines Servers, also eines anderen Programms bzw. eines anderen Rechners mit der dort installierten Software anfordert. Es findet also eine Arbeitsteilung zwischen dem Client und dem Server statt. Bei Client-Server-Datenbanklösungen wird mehreren Benutzern ein Datenbankdienst zur Verfügung gestellt, der auf einem, oder auch auf mehreren verschieden Rechnern installiert sein kann. Aus Sicht des Benutzers werden die Ebenen Frontend und Backend unterschieden. Frontend: Benutzern in den Fachabteilungen unmittelbar zur Verfügung stehende Informations- und Kommunikationstechniken (in der Regel ein Arbeitsplatzrechner (z. B. Personalcomputer) und lokal verfügbare Softwarepakete. Backend : Jene Informations- und Kommunikationstechniken, die dem Benutzer nicht lokal und unmittelbar, sondern über die Verwendung von Netzwerken zur Verfügung stehen. Backend ist also ein Sammelbegriff für das aus Benutzersicht "im Netzwerk Befindliche“. Als Netzwerktechnologie dient in überwiegender Mehrzahl internetkompatible Technik, basierend auf der IP Protokollfamilie. Informationsverarbeitung 1 Stand: August 2006 3.3. Datenbanken 217 Hinweis: Die Begriffe Server und Backend sind nicht generell gleichzusetzen. Bei der Aufteilung des Datenbanksystems in einen benutzernahen Teil (Frontend) und in den Bereich des Servers ist es zweckmäßig, die Ressourcen und die jeweiligen Vorteile der beteiligten Systeme optimal auszunützen. Im Frontend kommen die bekannten, aus modernen Benutzeroberflächen und aus der Vertrautheit des Benutzers mit "seinem" System resultierenden Vorteile zum Tragen. Die häufig am Frontend anzutreffenden Funktionen sind: o Navigation im Netzwerk und Auswahl der vom Benutzer gewünschten Datenbank(en), o Anmelden am SQL-Server (eingeben von Servername, Anmeldekennung und Kennwort), o Auswahl der Relationen und Spalten, Erstellen von Abfragen (z. B. mittels Eingabe von SQL-Befehlen), o Prüfung der Dateneingabe, o Übersetzen von Kommandos, die durch Auswählen, Anklicken von Objekten usw. eines GUI erteilt wurden, in einen SQL-Befehl, o Absenden von SQL-Befehlen an die Datenbank, o Empfangen und Anzeigen des Rechercheergebnisses, o Weiterbearbeiten, in ein Layout bringen, Präsentieren von Recherche- Ergebnissen (z. B. Aufbereiten von Reports), o Übernahme des Ergebnisses in lokale Anwendungsprogramme. Die Stärken der Datenbankserver liegen in den hohen Verarbeitungsgeschwindigkeiten sowie bei den effizienten Möglichkeiten der systematischen und zentralen Datenhaltung und sicherung In der Regel sind daher das DBMS sowie die Datenbank dort installiert. Auch die Zusammenarbeit mit den im LAN zur Verfügung stehenden Kommunikationsdiensten ist für die konkrete Aufteilung der Aufgaben zwischen Client und Server maßgeblich. Bei überlasteten Netzwerken und leistungsfähigen Frontend-Systemen können auch Lösungen mit dezentraler Datenhaltung zweckmäßig sein (vgl. dazu auch den Abschnitt über verteilte Datenbanken). Zielvorstellung ist dabei, zu insgesamt flexiblen, leistungsfähigen und somit wirtschaftlichen Gesamtsystemen zu kommen. Die Anbindung von Datenbanken an Word-Wide-Web-Server gelten als Erweiterung von Datenbankservern um die Funktionalitäten eines WWW-Servers. Datenbankabfragen durch den Benutzer können via World-Wide-Web gestellt werden, es erfolgt eine automatische Generierung der Antwort als HTML-Seite, die über das Internet dem Client mit dem dort installierten WWW-Browser zur Verfügung gestellt wird. Eine weitere Möglichkeit besteht darin, WWW-Browser als Frontends für die Nutzung von Datenbanken im Internet und/oder Intranet (vgl. Abschnitt 4) einzusetzen. Stand: August 2006 Informationsverarbeitung 1 218 Mittendorfer/Pils 3.3.1.3.2. Verteilte Datenbanken In verteilten Datenbanken (distributed data base) sind die logisch zusammengehörenden, gemeinsam verwalteten Daten einer Datenbank physisch auf mehrere, über Netzwerktechnik verbundene Rechner verteilt. Bei entsprechender Leistung der Rechnernetze kann dem Benutzer die Sicht einer zentralen Datenbasis gegeben werden. Erhöhte Zuverlässigkeit, schnellerer Zugriff, flexible Erhöhung der Speicherkapazität sowie Effizienzsteigerung werden als Vorteile verteilter Datenbanken genannt (vgl. HANSEN 2001, S. 603). 3.3.2. Relationale Datenbanksysteme 3.3.2.1. Datenmodellierung Soll eine relationale Datenbank aufgebaut werden, so wird zunächst ein konzeptionelles Modell, das die von den Benutzern bzw. Anwendungsprogrammen benötigten Daten beschreibt, erarbeitet. Eine häufig verwendete Datenmodellierungsmethode ist hierbei das Entity-RelationshipModell (ERM). In einem ER-Diagramm werden die Objektklassen durch Rechtecke, die Beziehungen zwischen den Objekttypen durch Rauten, die Attribute gegebenenfalls durch Ovale gekennzeichnet. Primärschlüssel werden unterstrichen. In Abhängigkeit davon, wie viele Objekte zueinander in Beziehung stehen, gibt es eins-zu-eins-, eins-zu-viele- (1 : n) oder viele-zu-viele- (n : m) Beziehungen. Beziehungen können ebenfalls Attribute aufweisen. Die nachfolgende Abbildung zeigt beispielhaft ein ER-Diagramm für einen Lehrbuchhandel. Die jeweiligen betrieblichen Aufgaben, prägen entscheidend die Struktur des Diagramms. Informationsverarbeitung 1 Stand: August 2006 3.3. Datenbanken 219 Abb. 3.3/6: ER-Diagramm für ein einfaches Buchhandels-Geschäftsmodell Dem Diagramm liegt ein einfaches Geschäftsmodell eines Lehrbuchhandels zugrunde. Die „Kunden“ (Schulen die durch ihre Kustoden vertreten werden) erteilen wiederholt „Aufträge“ an den Lehrbuchhandel. Jeder „Auftrag“ kann mehrere „Bücher“ enthalten, die jeweils in beliebiger Menge geordert werden können. Mehrere „Verlage“ verlegen die „Bücher“, wobei ein „Buch“ mit bestimmter Nummer und Titel nur von einem „Verlag“ stammen kann, ebenso wie ein bestimmter „Auftrag“ genau einem „Kunden“ zugewiesen wird. Das ER-Diagramm ist demnach das Ergebnis der verbalen Beschreibung des Geschäftsmodells, aus dem bei etwas ausführlichen Darstellungen, auch die Attribute der Objektklassen ableitbar sind. Festlegen der Relationen (Tabellen) Die Darstellung der benötigten Objektklassen in einem ER-Diagramm, mit ihren Beziehungen und Attributen führt noch nicht direkt zu den Tabellen (Relationen, tables) einer relationalen Datenbank. Um die entsprechenden Tabellen abzuleiten, sind Baugesetze für die Tabellen zu beachten, die insbesondere in den sogen. Normalformen zusammengefasst sind. Grundsätzlich gilt, dass sämtliche Daten in Form von Tabellen, die aus Zeilen (Reihen, rows) und Spalten (columns) bestehen, zu organisieren sind. Die Spalten entsprechen den Feldern der konventionellen Dateien, weshalb sich der Gebrauch des Begriffes „Feld“ auch in die Datenbanktheorie eingebürgert hat. Eine Zeile enthält genau einen Datensatz. Eine Tabelle Stand: August 2006 Informationsverarbeitung 1 220 Mittendorfer/Pils enthält nur gleich strukturierte Datensätze. Alle Tabellen und deren Felder werden mit Namen angesprochen. Jedes Feld eines Satzes weist nur einen einzigen Wert auf. Duplikate eines Datensatzes in einer Tabelle sind nicht erlaubt. Alle Werte einer Spalte müssen aus einer Domäne aller möglichen und zulässigen Werte stammen. Aus dem ER-Diagramm in Abb. 3.3/6 kann beispielsweise die Objektklasse „Buch“ in eine Tabelle einer relationalen Datenbank ohne Strukturänderung übergeführt werden. Sie entspricht mehr oder minder zufällig der Struktur jener Datei, die in Abb 3.3/3 bereits behandelt wurde. Für die Dokumentation relationaler Datenbanken wird eine abstrakte Form der Abbildung gewählt, die sich auch für die Darstellung komplexer Systeme eignet. Abb. 3.3/7: Tabelle „Buch“ in einem relationalen Datenmodell Diese Tabelle entspricht auch der Schreibweise Buch (Nr, Autor, Titel, Preis, Verlag, Auslaufend, Bestand). Normalisieren der Tabellen Bei der Überführung der Objektklassen in Tabellen sind diese daraufhin zu prüfen, ob sie Abhängigkeiten der Felder untereinander bzw. Redundanzen aufweisen, die meist zu Disintegritäten führen. Normalisiert wird, indem man schrittweise überprüft, ob die gebildeten Tabellen den Bedingungen der Normalformen entsprechen. Im Verlaufe dieses Normalisierungsprozesses kommt zu einer Reduzierung der Redundanzen, parallel dazu jedoch auch zu einer Vermehrung der Anzahl der Tabellen. Immer dann, wenn Redundanzen entdeckt werden, führt dies zur Bildung neuer Tabellen, die über die Schlüsselfelder miteinander verbunden werden. Die Anpassung der Tabellen an die Normalformen, dient auch der mengentheoretische Grundlage von SQL. Die Anwendung von drei Normalformen wird aus Gründen des Antwortzeitverhaltens der Datenbank empfohlen. 1. Normalform: Entfernen von Wiederholgruppen Jedes Feld darf im Datensatz nur einmal vorkommen. Gibt es mehrere Felder vom gleichen Typ, so müssen diese in einer eigenen Relation gespeichert werden. Die Überführung der Objektklasse „Auftrag“ in eine Tabelle (Relation) könnte der verbalen Beschreibung des Geschäftsmodells entsprechend: „ Jeder Auftrag kann mehrere Bücher enthalten, die jeweils in beliebiger Menge geordert werden können“ , bzw. in Anlehnung an das ER-Diagramm folgende Struktur aufweisen: Informationsverarbeitung 1 Stand: August 2006 3.3. Datenbanken 221 Auftrag (Nr, Kundennummer, Datum, Positionsnummer, Buchnummer, Menge, Positionsnummer, Buchnummer, Menge, ...). Da ein Auftrag in der Regel mehrere unterschiedliche Bücher in unterschiedlichen Mengen enthält, kommen die Felder: „Positionsnummer“, „Buchnummer“ und „Menge“ mehrfach vor, was der 1. Normalform widerspricht. Die Konsequenz ist demnach die Auslagerung der Wiederholgruppen in eine eigene Tabelle „Auftragspos“ (abgeleitet von Auftragsposition) und die Verbindung der Tabellen über die Schlüsselfelder. Das Ergebnis sieht folgendermaßen aus: Abb. 3.3/8 Tabelle „Auftrag“ nach der Anwendung der 1. Normalform Das Feld „Nr“ in der Tabelle „Auftrag“ (Auftrag.Nr) ist Schlüsselfeld der Tabelle „Auftrag“ und wird daher mit dem Feld „Auftragspos.Auftragsnummer“ verbunden. Die Namen der beiden Felder unterscheiden sich zwar, aber der Inhalt ist in beiden Fällen ident. Hier zeigt sich eine unvermeidbare Redundanz in relationalen Datenbanken, weshalb man auch von kontrollierter Redundanz und nicht von redundanzfrei spricht. Für die Erfüllung der im (detaillierten) Geschäftsmodell beschriebenen Aufgaben (z.B. Rechnungslegung) sind detaillierte Daten über die Bücher (z.B. der Preis) erforderlich. Wie auch aus dem ER-Diagramm ersichtlich ist, gibt es eine Verbindung zwischen der Tabelle „Auftrag“ und der Tabelle „Buch“ über die neu gebildete Tabelle „Auftragspos“. Die Notwendigkeit zur Neubildung einer Tabelle zwischen „Auftrag“ und „Buch“ ist auch aus ihrer n:m Beziehung ableitbar. Das Datenmodell hat demnach folgende Struktur: Stand: August 2006 Informationsverarbeitung 1 222 Mittendorfer/Pils Abb. 3.3/9 Datenmodell mit normalisierten Tabellen Die „Auftragspos.Nr „ der Tabelle „Auftragspos“ ist als Primärschlüssel nicht zu gebrauchen, sie dient lediglich der Kennzeichnung der einzelnen Auftragspositionen eines Auftrages, z.B. zum Zwecke der Reihung auf Lieferscheinen oder Rechnungen. Der Primärschlüssel der Tabelle „Auftragspos“ setzt sich vielmehr aus den Feldern „Auftragspos.Auftragsnummer“ und „Auftragspos.Buchnummer“ zusammen. Es handelt sich um einen Kombinationsschlüssel. Auch dieses Auftreten von Kombinatonsschlüsseln ist für die Normalformen-gerechte Auflösung von n:m Beziehungen typisch. 2. Normalform: Entfernen von Attributen, die nur von einigen der identifizierenden Attribute abhängen Die Bedingungen der 1. Normalform, zusätzlich: In Relationen mit einem Kombinationsschlüssel muss jedes Feld vom gesamten Kombinationsschlüssel abhängen. Felder, die nur von einem Teil des Schlüssels abhängen, werden mit diesem als Schlüssel in einer eigenen Relation gespeichert. Die Tabelle „Auftragspos“ besitzt einen Kombinationsschlüssel, wie aus 3.3/9 ersichtlich ist. Da aber der Entwurf der vorliegenden Datenbank mit der (korrekten ?) Erstellung eines ER-Diagrammes begonnen hat, befinden sich in dieser Tabelle keine Felder, die der 2. Normalform widersprechen. Es können jedoch in Frage kommende Erweiterungen der gegenständlichen Tabelle als Erläuterung am Beispiel herangezogen werden. Geht man z.B. davon aus, dass nicht alle Positionen eines Auftrags sofort geliefert werden können und sind Teillieferungen geplant, so wäre das Datum der Auslieferung (wohlgemerkt der gesamten bestellten Menge, keine Teilmengen) ein Feld, welches die Bedingung der 2. Normalform erfüllte. Informationsverarbeitung 1 Stand: August 2006 3.3. Datenbanken 223 Für den Fall, dass Preisnachlässe, in Form von Rabatten gewährt werden, könnte ein weiteres Feld mit der Bezeichnung „Rabatt“ angefügt werden. Diese Art der Gewährung von Rabatten bedeutet, dass der Preisnachlass einmalig, und nur für ein bestimmtes Produkt gewährt wird. Ebenso könnte ein Feld „Rabatt“ der Tabelle „Buch“, der Tabelle „Kunde“ oder der Tabelle „Auftrag“ angefügt werden, ohne die Normalformen zu verletzen. Die Bedeutung der alternativen Platzierung ist jedoch sehr unterschiedlich. Das Feld „Rabatt“ in der Tabelle „Kunde“ bewirkt, dass alle Einkäufe des jeweiligen Kunden mit einem Preisnachlass versehen werden, während das besagte Feld in der Tabelle „Buch“ Preisnachlässe für alle Kunden nach sich zieht. Diese Variationsmöglichkeiten zeigen deutlich, dass die formale Korrektheit einer relationalen Datenbank nicht ohne das zu Grunde liegende Geschäftsmodell überprüft werden kann. Das in Abb. 3.3/9 dargestellte Datenmodell entspricht also den Normalformen 1 und 2. 3. Normalform: Vermeidung von transitiven Abhängigkeiten Die Bedingungen der 2. Normalform, zusätzlich: Felder, die nicht Teil des Schlüssels sind, dürfen nicht untereinander abhängig sein; ist dies der Fall, so müssen sie in eigenen Relationen gespeichert werden. Gemäß dem ER-Diagramm in Abb. 3.3/6 fehlen dem Datenmodell noch die entsprechenden Tabellen für die Kunden und Verlage. Beide enthalten Felder für die Adresse, nämlich „Plz“, „Ort“ und „Straße“ (letzteres enthält auch die Hausnummer). Berücksichtigt man die Zustellbezirke der Post, die sich übrigens nicht mit der politischgeografischen Einteilung in Länder, Bezirke, Gemeinden und Katastralgemeinden decken, so kann festgestellt werden, dass jeder Postleitzahl eindeutig ein Zustellbezirk (zur zeitweiligen Verwirrung auch „Ort“ genannt) zugeordnet werden kann. Das Feld „Ort“ hängt demnach vom Feld „Plz“ ab und muss asugelagert werden. Die ohne Berücksichtigung der 3. Normalform, also falsch abgeleitete Tabellen wären: o Verlag (Kurzbezeichnung, Name, Kundennummer, Strasse, Plz, Ort) o Kunde (Nr, Vorname, Nachname, Strasse, Plz, Ort) Sie werden des Feldes „Ort“ entledigt und es entsteht eine neue Tabelle mit der Bezeichnung „PLZ“, die – wie soll es anders sein – über das Schlüsselfeld „Plz“mit ihrer ursprünglichen Heimat verbunden werden. Das endgültige, den Normalformen 1 bis 3 unterworfene Datenmodell zeigt folgende Struktur: Stand: August 2006 Informationsverarbeitung 1 224 Mittendorfer/Pils Abb. 3.3/10: normalisiertes Datenmodell eines Lehrbuchhandels 3.3.2.2. Funktionen eines DBMS Ein Datenbank-Managemt-System unterstützt das Erstellen von Tabellen mit deren Feldern, das Erstellen von Views (künstlichen Tabellen, welche die Sicht der Benutzer abbilden) und Indizes. Indizes beschleunigen vor allem die Zugriffszeit und den Sortierprozess. Eine View könnte z.B. folgendermaßen aussehen: Kundenumsätze (Kunde.Nr, Kunde.Nachname, PLZ.Ort, SUMME(Auftragpos.Menge * Buch.Preis) Ergänzt um Sortierkriterien und zeitlich/regionalen Einschränkungen (Selektion) kann diese „View“ (künstliche Tabelle) unter dem Namen „Kundenumsätze“ abgespeichert und durch Aufruf jederzeit, auch von „Nichtprogrammieren“ aktiviert werden. Weitere Funktionen eines DBMS sind: o Regelungen bei Concurrency (Mehrfachzugriff) o Security (Wer darf welche Operation in welchen Objekten ausführen?) o Integrity (Einschränkungen zur Aufrechterhaltung der Korrektheit der Daten) o Back-up (Datensicherung) o Restart (Neustart nach Fehlern oder Änderungen) o Recovery (Wiederherstellung des fehlerfreien Zustandes) Hierzu kommen die Anwendung von Verwaltungsinstrumenten (Führen des Systemkataloges, insb. der Tabellen, der Tabellennamen, der Eignernamen) sowie Instrumente zur Optimierung der Zugriffszeit. Informationsverarbeitung 1 Stand: August 2006 3.3. Datenbanken 225 Der Prozess der Entwicklung einer Datenbank, z. B. die Datenmodellierung, kann teilweise durch den Einsatz von einschlägigen Softwareentwicklungswerkzeugen (CASE-Tools, Computer Aided Software Engineering-Tools) unterstützt oder automatisiert werden. 3.3.2.3. Sichten auf eine Datenbank Den unterschiedlichen Aufgaben und Sichtweisen im Zusammenhang mit der Planung, Implementierung und dem Betrieb einer Datenbank entsprechend, sind zweckmäßigerweise drei Schichten auseinander zuhalten. Es sind dies das konzeptionelle Schema, die Benutzersichten und das interne Schema. Die globale, logische Datenbankbeschreibung wird als konzeptionelles Schema (logische Datensicht) bezeichnet. Das in Abb. 3.3/10 vorgestellte Modell, ergänzt durch nähre Angaben über die Felder, kann als konzeptionelles Schema angesehen werden. Die einzelnen Benutzer in den unterschiedlichen Fachabteilungen bzw. die Anwendungsprogramme aus den verschiedenen Bereichen eines Unternehmens benötigen jeweils voneinander unterschiedliche Ausschnitte aus der Wirklichkeit und somit auch aus dem konzeptionellen Schema. Diese unterschiedlichen Sichten des Datenmodells werden als Benutzersichten, Subschemata oder externe Schemata bezeichnet. Die in 3.3.2.2. entwickelte View kann als Beispiel für ein Subschema gelten. Nach Festlegung des konzeptionellen Schemas bzw. der externen Schemata werden die physische Anordnung der Daten auf den Speichermedien und die Zugriffspfade gestaltet. Ergebnis ist das interne Schema. Hier geht es insbesondere um die Ausnutzung von Speichern sowie um die Optimierung von Zugriffszeiten. Da die Verbindung des internen Schemas mit den betrieblichen Aufgaben und Geschäftsmodellen kaum mehr auszumachen sind, entzieht es sich jeglicher Darstellung in dieser Dokumentation. 3.3.2.4. SQL Die selbständige Abfrage von relationalen Datenbanken gehört in zunehmendem Maße zum Repertoire qualifizierter Arbeitsplätze, z.B. im Controlling, Marketing und Personalwesen. Die spontane, unmittelbare Nutzung von relationalen Datenbanken durch den Endbenutzer ist für die Vorbereitung einer Vielzahl von betrieblichen Entscheidungen unabdingbar geworden. Diese spontane Nutzung ist die Voraussetzung um aus Daten mit Hilfe von weiteren Analysewerkzeugen (z. B. siehe Kap. 2.3.1.11. Datenanalyse) Entscheidungsgrundlagen zur Unternehmenssteuerung zu schaffen. Zu einer modernen Standardausbildung von Wirtschaftswissenschaftern im Bereich der Informationsverarbeitung zählt daher auch das Beherrschen wichtiger SQL-Befehle und darauf aufbauender Abfragesysteme. SQL (Structured Query Language) ist die Standard-Datensprache für relationale Datenbankverwaltungssysteme (RDBMS) und Desktop-Datenbanken wie z.B. MS Access. SQL ist nicht prozedural und setzt eine einfache und einheitliche normalisierte tabellarische Datenstruktur Stand: August 2006 Informationsverarbeitung 1 226 Mittendorfer/Pils voraus. Die durch das American National Standards Institute (ANSI) normierte Sprachschnittstelle SQL wird von einer Reihe einschlägiger Softwarepakete verwendet. In der nachfolgernden Darstellung wird auf grundlegenden Sprachelemente zurück gegriffen, die auch unter dem Namen "SQL-Core" bekannt geworden sind. SQL hat folgende Teile: o DDL (Data Definition Language) Sprache für die Definition von Objekten. o DML (Data Manipulation Language) Sprache für die Manipulation von Objekten. o DCL (Data Control Language) Sprache für die Kontrolle der Privilegien. o Verwaltungsinstrumente (Führen des Systemkataloges, insb. Tabellen, Tabellennamen, Eignernamen) o Instrumente zur Performance-Optimierung. SQL kann interpretierend oder als embedded-SQL verwendet werden: o Ein SQL-Befehl wird vom Benutzer geladen oder eingegeben und auf Befehl direkt verarbeitet. Das Ergebnis wird z.B als Liste ausgegeben. (interpretierendes SQL). o Die SQL-Befehle sind in einem, mittels Programmiersprache (Wirtssprache, z. B. Java, C++) erstellten Programmes eingebettet (embedded SQL). Die auf dem Markt angebotenen Datenbank-Softwarepakete (SQL-Implementierungen) stellen in der Regel auch Ergänzungen der SQL durch Sprachzusätze (z.B. JDBC) zur Verfügung. o Trotz ANSI- und ISO-Normung ist SQL in einer Reihe von Datenbank-Softwarepaketen im Detail unterschiedlich implementiert. D. h. nicht alle SQL-Anweisungen sind auf alle Datenbank Implementierungen ausführbar. 3.3.2.5. Grundbefehle von SQL Die nachfolgend dargestellten Beispiele orientieren sich an der SQL-Implementierung der Datenbank "mySQL". 3.3.2.5.1. Erstellen, Ändern und Füllen von Tabellen Eine Tabelle wird mit der CREATE TABLE-Anweisung erstellt. Beispiel für die Tabelle “Buch” Informationsverarbeitung 1 Stand: August 2006 3.3. Datenbanken 227 CREATE TABLE Buch (Nr SMALLINT (4) PRIMARY KEY, Autor VARCHAR (20) NOT NULL, Titel VARCHAR (30) NOT NULL, Preis DECIMAL (3,2), NOT NULL, Verlag CHAR (3) NOT NULL, Auslaufen TINYINT Bestand SMALLINT (4) NOT NULL) Moderne RDBMS und Desktop-Datenbanken bieten benutzerfreundliche Werkzeuge zur Erstellung der Tabellen an. Diese generieren die erforderliche CREATE TABLE-Anweisung aus dem Datenmodell (siehe 3.3./10) automatisch. Häufige Datentypen sind: o Zahlen (z.B. SMALLINT, FLOAT, DECIMAL) o Datum und Uhrzeit (z.B. DATE, DATETIME, TIME) o Zeichenketten (z.B. CHAR, VARCHAR, BLOB) NOT NULL bedeutet, dass dem betreffenden Feld einen Wert zugewiesen werden muss (Mussfeld). Fehlt diese Komponente, kann das Feld auch „leer“ bleiben (Kannfeld). Unter der Domäne (Domain) eines Feldes wird der gewählte Datentyp für sowie auch die erlaubten Inhalte verstanden. Die Domäne beschreibt den erlaubten Lösungsraum eines Feldes. Das nachträgliche Hinzufügen einer Spalte wird mit der Anweisung ALTER TABLE bewirkt. ALTER TABLE Buch ADD Rabatt INT (2) NOTNULL fügt der Tabelle „Buch“ die Spalte „Rabatt“ hinzu. Ein neuer Datensatz kann z. B. wie folgt eingegeben werden: INSERT INTO Buch VALUES ( 5145, ´Hofer´, ´Datenbankmodelle´, 21,50, ´obv´ ,´n´,250) Die manuelle Eingabe eignet sich nicht für Massendaten, weshalb DBMS formularorientierte Anwendungen zur direkten Eingabe der Datensätze bieten. Software für betriebliche Anwendungen nutzen die eingebetteten Datenbankschnittstellen. 3.3.2.5.2. Einfache Abfragen auf eine Tabelle Eine SQL-Datenbank kann mit der SELECT-Anweisung abgefragt werden, wenn die entsprechenden Zugriffsrechte vorliegen. Nachfolgende Beispiele beziehen sich auf die Implementierung des in 3.3/10 dargestellten Modells in einem SQL-Trainingsserver, welche als interpretierende Maschine unter http://sql.idv.edu Stand: August 2006 Informationsverarbeitung 1 228 Mittendorfer/Pils erreichbar ist. Die Zugriffsrechte auf die Lehr- und Übungsdatenbank erlauben lediglich die Anwendungen von Abfragen mit der SELECT Anweisung. Um das Antwortzeitverhalten besonders in Prüfungszeiten zu erhöhen, wurde die Ausgabe der Treffer auf 500 Datensätze begrenzt. Selektion aller Datensätze und aller Spalten der Tabelle „Buch“ SELECT * FROM Buch Eine Liste der Bücher mit Nr. Titel, und Preis (Projektion): SELECT Nr, Titel, Preis FROM Buch Die Liste kann auch sortiert ausgegeben werden: SELECT Nr, Titel, Preis FROM Buch ORDER BY Preis DESC Eine Liste aller Autoren, aufsteigend sortiert: SELECT DISTINCT Autor FROM Buch ORDER BY 1 Verwendung von berechneten Werten mit Spaltenüberschriften: SELECT Buch_Nr, Preis* Bestand AS Bestandswert FROM Buch 3.3.2.5.3. Auswahl von Zeilen aus einer Tabelle (Selektion) Um bestimmte Zeilen einer Tabelle auszuwählen, muss angegeben werden, welche Bedingung für diese Zeilen gelten soll. Die Bedingungen werden in der WHERE Komponente definiert. Sie enthalten Operatoren (siehe 3.3.1.2) für die nachfolgende Reihenfolge anzuwenden ist: 1) 2) 3) 4) 5) ( * + = NOT ) / <> > AND OR < Beispiel in Anlehnung an 3.3./4: Liste der Bücher des Verlages „oev“, die einen Bestand von mehr als 10 Einheiten aufweisen. Informationsverarbeitung 1 Stand: August 2006 3.3. Datenbanken 229 SELECT * FROM Buch WHERE Verlag = 'oev' AND Bestand > 10 ORDER BY Nr Wird diese Abfrage auf http://sql.idv.edu ausgeführt, so weicht as Ergebnis von 3.3/4 deshalb ab, weil sich in der Lehrdatenbank wesentlich mehr Datensätze befinden als in der zitierten Tabelle. Dies gilt auch für nachfolgende Abfragen. Beispiel in Anlehnung an 3.3/5: Liste der Bücher, die im Titel „Metall“ oder „Werkzeug“ enthalten und deren Preis mehr als 20 Einheiten beträgt (Selektion). Ausgegeben sollten lediglich die Felder „Preis“, „Autor“, „Titel“ und „Verlag“ werden (Projektion). Das Ergebnis ist nach der Nummer zu sortieren. SELECT Preis, Autor, Titel, Verlag FROM Buch WHERE Titel LIKE '%Metall%' OR Titel LIKE '%Werkzeug%' AND Preis > 10 ORDER BY Nr 3.3.2.5.4. Die Verbindung mehrer Tabellen (Join) Zur Unterstützung zahlreicher Aufgaben aus dem betrieblichen Alltag werden Daten benötigt, die über mehrere Tabellen verteilt sind, Das Zusammenführen von Feldern aus mehreren Tabellen heißt auch Join und wird ebenfalls in der WHERE Komponente definiert. Die Verbindung der benötigten Tabellen erfolgt über die Schlüsselfelder. In der Regel wird ein Primärschlüssel einer Tabelle mit einem Fremdschlüssel einer weiteren Tabelle verbunden. Dazu ist es hilfreich, das normalisierte Datenmodell (siehe Abb. 3.3/10) zu verwenden. Die gerichteten Kanten weisen den Weg der Verbindungen (Joins). Zur formalen Korrektheit einer Adresse gehört mindestens die Angabe über die „Strasse“, die „Plz“ und den „Ort“. Durch Anwendung der 3. Normalform (siehe oben) wurde der „Ort“ aus den Tabellen mit den Kundendaten und Verlagsdaten entfernt und in eine neue Tabelle ausgelagert. Nachfolgende Abfrage erzeugt eine Kundenliste mit vollständiger Adresse. SELECT Kunde.Vorname, Kunde.Nachname, Kunde.Strasse, Kunde.Plz, PLZ.Ort FROM Kunde, PLZ WHERE Kunde.Plz = PLZ.PLZ ORDER By PLZ.Ort Bei Abfragen, die über mehrere Tabellen gehen, ist es ratsam die Feldnamen in Verbindung mit dem Tabellennamen anzuführen. Aus „Vorname“ wird „Kunde.Vorname“. Diese Maßnahme ist dann notwendig, wenn in ein und derselben Abfrage idente Feldbezeichnungen Stand: August 2006 Informationsverarbeitung 1 230 Mittendorfer/Pils auftauchen. Die „Kunde.Nr“ muss z.B. von der „Artikel.Nr“ und diese von der „Buch.Nr“ unterschieden werden können. Selbstverständlich ist neben der Angabe der Verknüpfung in der WHERE Komponente auch die Formulierung von Selektionskriterien möglich: SELECT Kunde.Vorname, Kunde.Nachname, Kunde.Strasse, Kunde.Plz, PLZ.Ort FROM Kunde, PLZ WHERE Kunde.Plz = PLZ.Plz AND PLZ.Region = ‘w’ ORDER BY Kunde.Nachname 3.3.2.5.5. Die Gruppierung Die GROUP-BY Klausel bewirkt, dass die aus einer Abfrage resultierende Tabelle in Gruppen gegliedert wird. Dazu muss in einer so genannten GROUP BY-Klausel angegeben werden, nach welchem Kriterium die Gruppierung erfolgen soll. Dieses Kriterium, der Gruppierungsschlüssel, ist im einfachsten Fall ein Attribut der Ausgangstabelle. Alle Zeilen mit demselben Wert des Gruppierungsschlüssels fallen in dieselbe Gruppe. Eine Gruppe ist also nichts anderes als eine Teiltabelle. Im Ergebnis wird jede Gruppe auf eine einzelne Zeile. durch die Anwendung von Gruppierungsfunktionen zusammengefasst. Als typische Gruppenfunktionen gelten: o COUNT o SUM o AVG o MAX o MIN Die Gruppenfunktionen werden analog zu gängigen Funktionen in Tabellenkalkulationsprogrammen angewandt und notiert. Z.B. SUM (Auftragspos.Menge * Buch.Preis) Im nachfolgenden Beispiel wird aus der Tabelle „PLZ“ (Ausgangstabelle) die Anzahl jener Orte ermittelt, die im Ortsnamen „kirche“ enthalten. Aggregiert (zusammengefasst) werden die Orte nach der „Region“, sortiert wird nach der Häufigkeit, absteigend. SELECT Region, COUNT(*) FROM PLZ WHERE Ort LIKE ‘%kirche%’ GROUP BY Region ORDER BY 2 DESC Wird die ORDER BY Komponente weggelassen, so bezieht sich die Aggregierung auf die gesamte Tabelle. Informationsverarbeitung 1 Stand: August 2006 3.3. Datenbanken 231 SELECT SUM (Preis), COUNT (Buchnummer) FROM Buch Abfragen der täglichen Praxis enthalten Felder aus mehreren Tabellen und Aggregationen. Die in 3.3.2.2 erwähnte View (Sicht eines Benutzers auf die Datenbank) die als „Kundenumsätze“ bezeichnet wurde, kann folgendermaßen als Abfrage formuliert werden: SELECT Kunde.Nr, Kunde.Nachname, PLZ.Ort, SUM(Auftragspos.Menge*Buch.Preis) AS Umsatz FROM PLZ, Kunde, Auftrag, Auftragspos, Buch WHERE PLZ.Plz = Kunde.Plz AND Kunde.Nr = Auftrag.Kundennummer AND Auftrag.Nr = Auftragspos.Auftragsnummer AND Auftragspos.Buchnummer = Buch.Nr GROUP BY Kunde.Nr ORDER BY Kunde.Nachname Das Ergebnis der soeben dargestellten Abfrage stellt eine vollständige Liste aller Kunden dar, die neben der Kundennummer und dem Nachnamen sowie dem Ort des Kunden, auch die Summe seiner Umsätze zeigt. Beispiel: Kundenliste mit Datum des zuletzt vergebenen Auftrages. SELECT Kunde.Nr, Kunde.Vorname, Kunde.Nachname, MAX(Datum) FROM Kunde, Auftrag WHERE Kunde.Nr = Auftrag.Kundennummer GROUP BY Auftrag.Kundennummer Da der Name des Kunden in der Tabelle „Kunde“ enthalten ist, muss zusätzlich ein Join mit dieser Tabelle vor der Gruppierung erfolgen. Anstelle einer einzelnen Spalte ist als Argument einer Gruppenfunktion auch ein Wertausdruck erlaubt. Beispiel: Der Wert aller Aufträge eines Jahres nach Jahren gegliedert: SELECT YEAR(Datum), SUM(Auftragspos.Menge * Buch.Preis) FROM Auftrag, Auftragspos, Buch WHERE Auftrag.Nr = Auftragspos.Auftragsnummer AND Auftragspos.Buchnummer = Buch.Nr GROUP BY YEAR(Datum) Die HAVING-Komponente dient ähnlich der WHERE-Komponente der Selektion, sie erlaubt jedoch die Anwendung von Gruppierungsfunktionen, die in der WHERE-Komponente nicht zugelassen sind. Beispiel: Alle Orte, denen mehr als drei Postleitzahlen zugeordnet sind. Stand: August 2006 Informationsverarbeitung 1 232 Mittendorfer/Pils SELECT Ort FROM PLZ GROUP BY Ort HAVING COUNT(plz) > 3 Obige Abfrage erzeugt eine Liste aller Orte, die in der Tabelle “PLZ” mindestens 4 mal genannt sind. Literatur Finkenzeller, Hermann / Kracke, Ulrich / Unterstein, Michael: Systematischer Einsatz von SQL-ORACLE, Addison-Wesley Publishing Company, Bonn/ Reading/ Menlo Park/ New York/ Wokingham/ Amsterdam/ Sydney/ Singapore/ Tokyo/ Madrid/ San Juan 1989 Hansen, Hans Robert: Wirtschaftsinformatik I, Einführung in die betriebliche Datenverarbeitung, 8. A., Gustav Fischer Verlag Stuttgart / Jena 2001 Kientzle, Tim: Internet File Formats, Scottsdale/Arizona 1995 Lans, Rick F. van der: Das SQL-Lehrbuch, Addison-Wesley Publishing Company, Bonn/ Reading/ Menlo Park/ New York/ Wokingham/ Amsterdam/ Sydney/ Singapore/ Tokyo/ Madrid/ San Juan1988 (Übersetzt von Himmelberg, Wolfgang) Martin, James: Einführung in die Datenbanktechnik, Carl Hanser Verlag München / Wien, 4. unv. Nachdr. 1987 Oracle Corporation: Überblick über Oracle und Einführung in SQL, Ottobrunn 1987 Panny, Taudes: „Einführung in den Sprachkern von SQL-99“, Verlag Springer, Berlin, 2000 Informationsverarbeitung 1 Stand: August 2006
