FHTW Berlin Technisches Gebäudemanagement Studienarbeit im Rahmen der Vorlesung Informatik I bei Dozentin Frau Dr. Antonova Thema Datenbanken Modul 3 Datenverarbeitung Modelle Konzepte Abfragesprachen Marktübersicht und Beispiele Ihrer Anwendungen Praktische Aufgabenstellung / Praktisches Beispiel: o Programmieren Sie eine Datenbank, die die Datenbasis für eine Self-Service-Anwendung speichern könnte. o Stellen Sie sicher, dass verschiedene Webanwendungen an die Datenbank andocken könnten und aus diesem Grund das Datenmanagement innerhalb der Datenbank abgewickelt wird. o Erstellen Sie ein ER-Modell der Datenbank. vorgelegt von: Martin Sowinski Matrikel-Nr.: 518833 m.sowinski@addcom.de
Inhaltsverzeichnis INHALTSVERZEICHNIS 1 EINFÜHRUNG 6 2 DAS DBMS / DIE DATENBANKMODELLE 9 2.1 DAS DATENBANKMANAGEMENTSYSTEM - DBMS 10 2.2 EBENEN DER DATENBANKANWENDUNGEN 10 2.2.1 EINSCHICHTIGE ANWENDUNGEN 12 2.2.2 ZWEISCHICHTIGE ANWENDUNGEN 12 2.2.3 N-SCHICHTIGE ANWENDUNGEN 14 2.3 DATENMODELLE 16 2.3.1 HIERARCHISCHE DATENBANKEN 17 2.3.2 NETZWERKDATENBANKEN 19 2.3.3 RELATIONALE DATENBANKEN 21 2.3.4 OBJEKTORIENTIERTE DATENBANKSYSTEME 24 3 DIE DATENBANKSPRACHE SQL 28 3.1 SPRACHKOMPONENTEN VON SQL 29 4 ER-MODELLE 30 5 NORMALISIERUNG 31 5.1 DIE ERSTE NORMALFORM 31 5.2 DIE ZWEITE NORMALFORM 31 5.3 DIE DRITTE NORMALFORM 32 5.4 DIE VIERTE NORMALFORM 32
Inhaltsverzeichnis 5.5 DIE FÜNFTE NORMALFORM 32 5.6 DIE BOYCE-CODD-NORMALFORM 33 6 PRAKTISCHE AUFGABENSTELLUNG 34 6.1 EINFÜHRUNG IN DAS BEISPIEL 34 6.2 FINDUNGEN EINES GESCHÄFTSPROZESSES 35 6.3 DATENBANKENTWURF UND ENTWICKLUNG DES ER-MODELLS 38 6.4 ENTSCHEIDUNGSFINDUNG FÜR DATENBANKFABRIKAT 40 6.5 UMSETZUNG DER PROGRAMMIERUNG 42 6.5.1 VERWENDETE DATENTYPEN 42 6.5.2 VERWENDETER ZEICHENSATZ UND VERWENDET SORTIERORDNUNG 42 6.5.3 ERSTELLEN DER TABELLEN 42 7 ABKÜRZUNGSVERZEICHNIS 48 8 LITERATURVERZEICHNIS 49 Anlagen: Anlage 1: Anlage 2 Anlage 3 CD Präsentation Relationen MySQL-Datenbank 4
Inhaltsverzeichnis 1 Agenda Introduction The DBMS / Types of Databases o The Database Management System (DBMS) o Database Applications o Hierarchical Databases o Network Databases o Relational Databases Entity Relationship Model Normalisation of Databases o Object Relational Databases Programming languages of Databases SQL The Example 5
Einführung 1 Einführung Es gibt viele Gründe sich gerade im technischen Gebäudemanagement mit Datenbanken und ihrer Arbeitsweise auseinanderzusetzen. Ein Grund ist die wachsende Verbreitung von Datenbankanwendungen gerade bei intelligenten Gebäudemanagementsystemen. Ein anderer Grund ist die ständig wachsende Datenmenge, die so gespeichert werden sollte, dass wir als Nutzer dieser Daten sie auch beherrschen. Hierbei gibt es verschiedene Techniken. Fakt ist auch, dass die Menge der zu speichernden Daten in den vergangenen 20 Jahren stark zugenommen hat. Und dass die Perioden, in denen sich das Datenvolumen verdoppelt, immer kürzer werden. Aus diesem Grund wurden geeignete Systeme gesucht, um diese Datenmengen zu beherrschen. Die Entwicklung von leistungsfähigen Datenbanken zur Steuerung dieser Daten bekam eine große Bedeutung. So hat auch das Wissen über Datenbanken stark zugenommen. In Datenbanken wird die Verwaltung der Daten so organisiert, dass die Nutzer schnell und gezielt auf ihre Informationen zugreifen und diese auch auswerten können. Ein weiterer Aspekt ist die Speicherung von Daten aus Programmen. Die hat sich gerade in den letzten 10 Jahren dahingehend verändert, dass früher zum Beispiel Programmprozessdaten in Dateien ausgelagert oder direkt im jeweiligen Programm gespeichert wurden, nun aber die meisten Anwendungsprogramme, die ein großes Volumen an Prozessdaten erzeugen, diese Daten in Datenbanken speichern. Dies hat unter anderem auch den Vorteil, dass Daten programmübergreifend genutzt werden. Durch die Speicherung dieser Daten in einer Datenbank können verschiedene Programme auf die gleichen Informationen zugreifen. Im Technischen Gebäudemanagement wurden Datenbanken mit der Erweiterung von Anlagen der Gebäude-Leit-Technik und der Einführung des CAFM (Computer Aided Facility Management) etabliert. Eine praktische Anwendung, wie Sie bei der Royal BAM Group im Einsatz ist, zeigt die Abbildung 1. Im Zentrum der Anwendungen steht eine Oracle -Datenbank, in der die Daten der zwei Hauptanwendungen SAP und FaMe gespeichert werden. Dabei werden die kaufmännischen Prozesse der Bauunternehmung im SAP und die Prozesse des Gebäudemanagements im FaMe abgebildet. Zusätzlich gibt es noch für verschiedene Projekte ein SelfServicePortal, über das die Nutzer von Gebäuden 6
2 Das DBMS / Die Datenbankmodelle Neben der grundlegenden Trennung von Anwendung und Datenbank gibt es nun mehrere Möglichkeiten der weiteren Verteilung. Ich möchte an dieser Stelle auf zwei eingehen. Zum Einen sind das die Intranetanwendungen und zum Anderen die Webanwendungen. Bei den Intranetanwendungen wird die Präsentationsebene bei den Client-Rechnern angesiedelt, die Geschäftslogik bei den Anwendungsservern hinterlegt und die Datenspeicherung wird von der physischen Ebene sichergestellt. Ein Nachteil dieser Methode ist die dezentrale Speicherung der Client-Software. Als Client-Programme werden häufig keine Standardsoftwareprodukte, wie etwa ein Internetbrowser, genutzt. Hier wird spezielle Clientsoftware verwendet, die auf jedem Client installiert und gewartet werden muss. Das erhöht den administrativen Aufwand bei Release-Wechseln und der Nutzerbetreuung. Abbildung 8 - Schematische Darstellung ein N-schichtigen Webanwendung 9 Eine andere Methode, die seit einigen Jahren einen starken Aufwind erfährt, sind die Internettechnologien. Hier wird die Präsentationsebene auf dem Anwendungsserver dargestellt. Die Präsentation der Daten im eigentlichen Sinne erfolgt aber in einem 9 [3] S.79 15
2 Das DBMS / Die Datenbankmodelle normalen Webbrowser. Gerade diese Verteilung birgt große Vorteile. Zum Einen sind auf den Client-Rechnern nur das Betriebssystem und ein Browser nötig und keine aufwendigen lokalen Installationen. Zum Anderen kann man auch mit firmenfremden Rechnern auf die Systeme von außen zugreifen. Das bringt den Mitarbeitern eine gewisse Unabhängigkeit und es erlaubt Kunden, Geschäftspartnern und Auftragnehmern das System mit zu nutzen, dies natürlich nur in einem begrenzten Rahmen. Der Vorteil den solche Systeme mit sich bringen ist klar. Sie sparen Arbeit, weil zum Beispiel Doppeleingaben vermieden werden. Ein auf den Geschäftsprozess abgestimmter Workflow kann somit für die Vorgangsbearbeitung die Zeit, die für die Verwaltungsaufgaben anfallen, stark minimieren. Gerade die Internetanwendungen werden in den nächsten Jahren weiter an Bedeutung gewinnen. 2.3 Datenmodelle Datenmodelle bezeichnen die Art der Datenstrukturierung. Sie geben den Rahmen für die Organisation der Daten in der Datenbank vor. Datenmodelle kann man sich ähnlich einer Programmiersprache vorstellen. Hier werden die generischen Strukturen und Operatoren definiert, die dann für das Datenmanagement benötigt werden. 10 Für die Definition des Datenmodells betrachtet man zwei Bereiche. Auf der einen Seite muss die Struktur der Daten definiert werden, auf der anderen Seite betrachtet man das Handling der Daten. Das heißt, das Ändern der Daten in der Datenbank und das Auswerten der Informationen. Den ersten Teil bezeichnet man als Datendefinitionssprache und den zweiten Teil als Datenmanipulationssprache. In modernen Datenbanksprachen sind diese beiden Sprachteile zusammengefasst. 11 Das Thema Datenbanksprachen ist so umfangreich, dass es im Rahmen dieser Arbeit nur zu einem geringen Teil Beachtung findet. Ich werde in einem späteren Abschnitt konkret auf die Datenbanksprache SQL und deren Aufteilung der verschiedenen Sprachelemente eingehen. 10 [3] S.20-26 11 [2] S.21-40 und [3] S.20-26 16
2 Das DBMS / Die Datenbankmodelle 2.3.1 Hierarchische Datenbanken Die Entwicklung der Datenbanken begann mit den hierarchischen Datenbanken. Einige der hier verankerten Grundkonzepte werden auch noch bei späteren Evolutionsstufen verwendet. Bei der Entwicklung wollte man reale Einheiten hierarchisch zerteilen und so eine Speicherstruktur für die Datenbankanwendung finden. Deutlich wird das in Abbildung 9. Hier wird die Aufteilung von der Liegenschaft, als größte reale Einheit, zu den Räumen, als kleinste Bestandteile dieser Einheit, vorgenommen. Bei dieser Anordnung werden die einzelnen Verzweigungspunkte als Knoten bezeichnet. Der Wurzelknoten ist die Liegenschaft und alle der Liegenschaft nachgeordneten Knoten werden Kindknoten genannt. Jeder einem Kindknoten vorgeordneter Knoten wird als Elternknoten dieses Kindknotens dargestellt. In der Abbildung 9 wird die Beziehung im Bereich der Freiflächen dargestellt. Hier ist der Knoten Freiflächen der Elternknoten für Natürliche Oberflächen. Die einzelnen Hierarchieebenen werden graduiert, d.h. nach jedem Knotensprung erhält die der aktuellen Ebene folgende Kindebene einen um eins erhöhten Grad. Das revolutionäre an diesen Systemen war unter anderem die Mehrbenutzerfähigkeit. Während Dateien immer nur von einer Person geöffnet und bearbeitet werden konnten, erlaubten die Datenbanken mehreren Benutzern gleichzeitig den Zugriff auf die Datenbasis. Die Daten konnten mit Hilfe von Schnittstellen zwischen den verschiedenen Anwendungsprogrammen zum ersten Mal programmunabhängig gespeichert werden. Die Daten wurden mit Hilfe von Knotenangaben in das System gebracht. Hierin lag jedoch auch ein Nachteil, weil alle in der Datenbank liegenden Knoten nacheinander von der Wurzel und danach von links nach rechts zur Prüfung angefahren wurden. Das machte das System sehr langsam. Ein anderer Schwachpunkt war die strukturelle Abhängigkeit der Anwendungsprogramme von der Datenbank. Die Abgrifftechnik, wie sie schon oben beschrieben wurde, legte nahe, Daten, die besonders häufig angegriffen wurden, links anzuordnen, da diese Seite zuerst bei der Suche nach einer Entsprechung für den Datenpunkt abgegriffen wurde. So kam es, dass man hierarchische Datenbanken zur Performanceoptimierung häufig umstrukturierte. Da die Anwendungsprogramme aber fest auf die Äste dieses Datenbaumes zugriffen, mussten auch sie bei derartigen Änderungen angepasst werden. Das war häufig sehr aufwendig und kostenintensiv. 17
2 Das DBMS / Die Datenbankmodelle Abbildung 9 - Struktur einer hierarchischen Datenbank Auch die baumartige Struktur provozierte Fehler durch die Administratoren. Daten wurden durch falsches Löschen von Knoten vernichtet. Löschte man nämlich einen Elternknoten, so wurden alle ihm nachgeordneten Kinderknoten auch bereinigt. Die beiden nächsten Punkte besiegelten das Schicksal dieser Konstruktion endgültig und waren gleichzeitig für die Konzeption der nachfolgenden Strukturen von entscheidender Bedeutung. In der Phase als die hierarchischen Datenbanken eingesetzt wurden, gab es noch keine Standards für den Datenaustausch. Ein Frabrikationswechsel von einer Datenbank zu einer anderen brachte enorme Schwierigkeiten mit sich, so dass der Aufwand für eine Portierung häufig einer Neuentwicklung glich. Aus diesen Schwierigkeiten lernten die Entwickler und schufen verschiedene Standardschnittstellen für den Datenaustausch zwischen den jeweiligen Datenbanken. Auch aus den letzten Punkten wurde ein großes Potential für weitere Entwicklungen gewonnen. Wenn wir die Entity Relations, die Beziehungen zwischen den Datensätzen betrachten, fällt auf, dass ein Elternknoten zwar beliebig viele Kindkno- 18
2 Das DBMS / Die Datenbankmodelle ten haben darf, aber dass umgekehrt ein Kindknoten nur ein Elternknoten haben darf. Datenbanktechnisch ausgedrückt, kann diese Art von Datenbanken zwar 1:n- Beziehungen darstellen, aber nicht n:m-beziehungen. Das schränkte die Leistungsfähigkeit gegenüber den nachfolgenden Konzepten stark ein. Auf diese Beziehungen werden ich genau im Abschnitt zur ER-Modellierung (Entity Relationship Model) eingehen. Das hierarchische Modell wurde abgelöst von den Netzwerkdatenbanken. 2.3.2 Netzwerkdatenbanken Die Probleme, die aus der Anwendung des hierarchischen Datenbankmodells resultierten, sollten mit der Schaffung der Netzwerkdatenbanken beseitigt werden. Wenn wir auf die hierarchischen Systeme blicken, waren die größten Hindernisse in der Portierungsfähigkeit der Datenbanken und in der mangelnden Fähigkeit der Darstellung von m:n Beziehungen zu sehen. Zur Umsetzung dieser Anliegen gab es einen freiwilligen Zusammenschluss von Computerherstellern, -anwendern und staatlichen Einrichtungen. 12 Dieser Zusammenschluss wurde CODASYL (Conference on Data System Languages) genannt. Die Verbindung entstand bereits im Jahre 1959 in den USA und ein Ergebnis der Arbeit war die Weiterentwicklung der Programmiersprache COBOL. Erst 1973 wurde dann mit dem Bericht CODA73 der Grundstein für die Netzwerkterminologie gelegt. Die beiden elementaren Anforderungen an die Netzwerkdatenbanken wurden erreicht. Die Einführung der Standardsprache COBOL trug dazu bei, dass es bessere Voraussetzungen für die Portierung gab. Außerdem änderte man die Beziehungsfähigkeit der Datensätze. Wenn Sie sich zuerst die Abbildung 9 ansehen und anschließend die Abbildung 10, werden Sie einen fundamentalen Unterschied erkennen. Die Redundanzen aus der Kindebene 6. Grades wurden abgebaut. Die Reinigungsklassen werden nun nur noch ein Mal gespeichert und können beliebig oft anderen Elementen zugeordnet werden. Das sparte für die Zukunft enorme Speicherkapazität durch Verhinderung von Redundanzen 12 [2], S.59-70 19
6 Praktische Aufgabenstellung `wiederholungintagen` INT( 3 ) NULL, `gueltig_von` DATE NOT NULL, `gueltig_bis` DATE NOT NULL, `id_personen` INT( 10 ) NOT NULL, `id_benutzergruppe` INT( 10 ) NOT NULL ) ENGINE = MYISAM CHARACTER SET latin1 COLLATE latin1_german1_ci; Erstellen der Tabelle Benutzergruppe CREATE TABLE `benutzergruppe` ( `id_benutzergruppe` INT( 10 ) NOT NULL AUTO_INCREMENT PRIMARY KEY, `bezeichnung` CHAR( 255 ) NOT NULL, `beschreibung` LONGTEXT NULL ) ENGINE = MYISAM CHARACTER SET latin1 COLLATE latin1_german1_ci; Erstellen der Tabelle Mietvertrag CREATE TABLE `mietvertrag` ( `id _mietvertrag` INT( 10 ) NOT NULL AUTO_INCREMENT PRIMARY KEY, `bezeichnung` CHAR( 255 ) NOT NULL, `beschreibung` LONGTEXT NULL, `datum_beginn` DATE NOT NULL, `datum_ende` DATE NULL, `datum_termin` DATE NULL, `intervall_termin` INT( 3 ) NULL, `kuendigungsfrist` INT( 3 ) NOT NULL, `id_personengruppe_m` INT( 10 ) NOT NULL, `id_personen_m` INT( 10 ) NOT NULL, `id_personengruppe` INT( 10 ) NOT NULL, `id_personen` INT( 10 ) NOT NULL, `id_geltungsbereich` INT( 10 ) NOT NULL ) ENGINE = MYISAM CHARACTER SET latin1 COLLATE latin1_german1_ci; Erstellen der Tabelle REAKTIONSZEIT CREATE TABLE `reaktionszeit` ( `id_reaktionszeit` INT( 10 ) NOT NULL AUTO_INCREMENT PRIMARY KEY, `bezeichnung` CHAR( 255 ) NOT NULL, 45
6 Praktische Aufgabenstellung `beschreibung` LONGTEXT NULL, `frist` INT( 3 ) NOT NULL ) ENGINE = MYISAM CHARACTER SET latin1 COLLATE latin1_german1_ci; Erstellen der Tabelle SERVICEBEREICH CREATE TABLE `servicebereich` ( `id_servicebereich` INT( 10 ) NOT NULL AUTO_INCREMENT PRIMARY KEY, `bezeichnung` CHAR( 255 ) NOT NULL, `beschreibung` LONGTEXT NOT NULL ) ENGINE = MYISAM CHARACTER SET latin1 COLLATE latin1_german1_ci; Erstellen der Tabelle SERVICEDETAIL CREATE TABLE `servicedetail` ( `id_servicedetail` INT( 10 ) NOT NULL AUTO_INCREMENT PRIMARY KEY, `bezeichnung` CHAR( 255 ) NOT NULL, `beschreibung` LONGTEXT NULL, `id_servicebereich` INT( 10 ) NOT NULL, `id_reaktionszeit` INT( 10 ) NOT NULL ) ENGINE = MYISAM CHARACTER SET latin1 COLLATE latin1_german1_ci; Erstellen der Tabelle SERVICE1 CREATE TABLE `service1` ( `id_service1` INT( 10 ) NOT NULL AUTO_INCREMENT, `kurzmeldung` CHAR( 255 ) CHARACTER SET latin1 COLLATE latin1_german1_ci NOT NULL, `meldung` LONGTEXT CHARACTER SET latin1 COLLATE latin1_german1_ci NOT NULL, `eingang` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, `termin` DATETIME NOT NULL, `id_personengruppe_m` INT( 10 ) NOT NULL, `id_personen_m` INT( 10 ) NOT NULL, `id_personengruppe` INT( 10 ) NOT NULL, `id_personen` INT( 10 ) NOT NULL, `id_servicedetail` INT( 10 ) NOT NULL, 46
6 Praktische Aufgabenstellung `id_raum` INT( 10 ) NOT NULL, `id_status` INT( 10 ) NOT NULL ) ENGINE = MYISAM CHARACTER SET latin1 COLLATE latin1_german1_ci; Erstellen der Tabelle STATUS CREATE TABLE `status` ( `id_status` INT( 10 ) NOT NULL AUTO_INCREMENT PRIMARY KEY, `bezeichnung` CHAR( 255 ) NOT NULL, `beschreibung` LONGTEXT NULL ) ENGINE = MYISAM CHARACTER SET latin1 COLLATE latin1_german1_ci; Erstellen der Tabelle AUFTRAG CREATE TABLE `auftrag` ( `id_auftrag` INT( 10 ) NOT NULL AUTO_INCREMENT PRIMARY KEY, `bezeichnung` CHAR( 255 ) NOT NULL, `bemerkung` LONGTEXT NOT NULL, `beschreibung` LONGTEXT NOT NULL, `beginn` DATETIME NOT NULL, `ausfuehrungstermin` DATETIME NOT NULL, `id_personengruppe_m` INT( 10 ) NOT NULL, `id_personengruppe` INT( 10 ) NOT NULL, `id_personengruppe_nu` INT( 10 ) NULL, `id_personen` INT( 10 ) NOT NULL, `id_personen_m` INT( 10 ) NOT NULL, `id_personen_nu` INT( 10 ) NULL, `id_service1` INT( 10 ) NOT NULL ) ENGINE = MYISAM CHARACTER SET latin1 COLLATE latin1_german1_ci; 47
7 Abkürzungsverzeichnis 7 Abkürzungsverzeichnis ANSI BCNF BMA CAFM COBOL CODASYL DB DBMS EMA ER FHTW FM GLT GMS NF OODBMS RDBMS SQL American National Standards Institute Boyce-Codd-Normalform Brandmeldeanlage Computer Aided Facility Management Common Business Oriented Language COnference on DAta SYstems Languages Datenbank Datenbankmanagementsystem Einbruchmeldeanlage Entity Relation Fachhochschule für Technik und Wirtschaft Berlin Facility Management Gebäude-Leit-Technik Gebäudemanagementsystem Normalform Objektorientiertes Datenbankmanagementsystem Relationales Datenbankmanagementsystem Structured Querry Language 48
8 Literaturverzeichnis 8 Literaturverzeichnis [1] VOSSEN, GOTTFRIED: Datenmodelle, Datenbanksprachen und Datenmanagementsysteme Auflagen, Addison-Wesley, 1994 [2] GEISLER, FRANK: Datenbanken, Grundlagen und Design 2. Auflage, Redline, 2006 [3] KEMPER, ALFONS UND EICKLER, ANDRE: Datenbanksysteme 6. Auflage, Oldenbourg Verlag, 2006, ISBN 3-486-57690-9 [4] TRAUTLOF, RAINER UND LINDNER, ULRICH: Datenbanken, Entwurf und Anwendung 1. Auflage, Verlag Technik Berlin, 1991, ISBN 3-341-00861-6 [5] KURBEL, KARL UND STRUNZ, HORST: Handbuch Wirtschaftsinformatik 1. Auflage, C.E. Poeschel Verlag Stuttgart, 1990, ISBN [6] ROLLAND, F.D.: Datenbanksysteme 1. Auflage, Pearson Studium München, 2003, ISBN 3-8273-7066-3 [7] VOSSEN, GOTTFRIED Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme 4. korrigierte und ergänzte Auflage, Oldenbourg Verlag, 2000, ISBN 3-486- 25339-5 49
8 Literaturverzeichnis [8] ELMASRI, RAMEZ UND NAVATHE, SHAMKANT B. Grundlagen von Datenbanksystemen, Ausgabe Grundstudium 3. Auflage, Pearson Studium München, 2005, ISBN 3-8273-7153-8 [9] KUHLMANN, GREGOR UND MÜLLMERSTADT, FRIEDRICH SQL - Der Schlüssel zu relationalen Datenbanken 1. Neuausgabe, Rowohlt Taschenbuch Verlag Hamburg, 2004, ISBN 3-499-61245-3 [10] FRITZE, JÖRG UND MARSCH, JÜRGEN Erfolgreiche Datenbankanwendungen mit SQL3 6. Auflage, Vieweg Wiesbaden, 2002, ISBN 3-528-55210-7 50
Bemerkungen: 51