Studiengang BWL FHDW Vorlesung: Betriebliche Informationssysteme II Datenbanken Teil 2 BI-U2 2. Quartal 2012

Datenbanken I Aufbau von Datenbankmanagementsystemen Relationale Datenbanksysteme Normalisierung Entity-Relationship-Diagramme Praxis: Datenbanksystem MySQL SQL-Abfragen mit MySQL Datenbanken I

Aufbau von Datenbankmanagement-Systemen Datenbanken I

Beispiele für datenintensive Anwendungen Auftragsabwicklung in einem Unternehmen, Erfassen von Bestellungen, Angeboten, Warenaussendungen, Lagerhaltung Universitätsverwaltung erfasst Studenten, Lehrkräfte, Räume, Vorlesungen, Angestellte Bibliothek: Verwalten von Büchern, verliehenen Büchern, Nutzern Datenbanken I

Datenbanksystem-Generationen 50er J. Dateisystem auf Band, nur sequentieller Zugriff, Batchbetrieb 60er J. Dateisystem auf Platte, Random Access, Dialogbetrieb, Indexdateien, Dateiverwaltungssystem 70er J. Prärelationale Systeme (Netzwerk-, hierarchische Systeme) 80er J. Relationale Systeme 90er J. objektbasierte Systeme Datenbanken I

primitive Ein-/Ausgabe- Software 1. Generation (50er J.) Anwendung 1 – Dateiorganisation 1 ... Anwendung n – Dateiorganisation n primitive Ein-/Ausgabe- Software Datei 1 ... Datei n anwendungsspezifische Datenorganisation Geräteabhängigkeit der Programme Redundanz, Inkonsistenz der Daten Datenbanken I

50er Jahre: Dateisysteme Daten speichern in einzelne Dateien Dateiorganisation ist anwendungsspezifisch: Öffnen von Dateien zum Lesen und/oder Schreiben Positionieren innerhalb von Dateien auf bestimmte Sätze mit Hilfe von Dateizeigern Lesen von Sätzen aus einer Datei Schreiben von Sätzen in eine Datei Erkennen des Dateiendes Schließen von Dateien. Datenbanken I

Beispiel Dateisystem begin maxgehalt = 0 öffne Datei Personal solange nicht Dateiende lies nächsten Satz falls (Abteilung = 20 und gehalt > maxgehalt) maxgehalt = gehalt schließe Datei Personal gib maxgehalt aus end Datenbanken I

Dateiverwaltungs- system 2. Generation (60er J.) Dateiverwaltungs- system Anwendung 1 ... Anwendung n Datei(en) 1 mit gemeinsamem Zugriff Datei(en) n Programmbibliothek teilw. standardisierte Datenorganisation Dienstprogramme wie z. B. Sortierer Geräteunabhängigkeit jedoch: Abhängigkeit von Speicherstruktur und Zugriffspfaden Datenbanken I

Datenbanksysteme (seit 70er J.) Datenbanksystem (DBS) besteht aus: Datenbankmanagementsystem (DBMS) Software zur Verwaltung von Datenbeständen Schnittstelle zwischen Benutzer und Datenbank, hierzu DB-Sprache, z.B. SQL realisiert Konsistenz und Datenunabhängigkeit Datenbank (DB) integrierter Datenbestand einheitlich gemäß Datenmodell strukturiert Datenbanken I

Aufbau von Datenbanksystemen Anwendungs- programme Benutzer, Administratoren Benutzer-schnittstelle Betriebssystem Hauptspeicher Sekundärspeicher Datenbank- management- system (DBMS) Datenbank- system (DBS) Daten- bank (DB) Datenbanken I

Aufgaben von DBMS Speicherung u. Verwaltung großer Datenbestände Speicherung dauerhaft, frei von Redundanzen, Konsistenzbedingungen genügend Daten vor unberechtigtem Zugriff geschützt Anfragen sowie Aktualisierungen möglich effizienter / schneller Zugriff auf die Daten mehrere Benutzer gleichzeitig aktiv Zugriffe über Netz oder auf mehrere Datenbanken mit Anwendungs-Software koppelbar Datenbanken I

Datenmodelle Hierarchisches Datenmodell IMS (Information Management System) IBM Netzwerkmodell UDS von Siemens Relationales Datenmodell dBase, MySQL, Access, SQL-Server, ... Objektorientiertes Datenmodell teilw. Oracle, O2 von O2 Technology unterscheiden sich im Aufbau der Datenstrukturen Datenbanken I

Hierarchisches Datenmodell 1960 entwickelt Baumstruktur mit einem Ausgangselement (Root) Jedes Element hat maximal einen Vorgänger (Parent) Jedes Element hat beliebig viele Nachfolger (Children) Datenbanken I

Beispiel Hierarchisches Modell Datenbanken I

Ausprägung Hierarchisches Modell Datenbanken I

Hierarchisches Modell heute LDAP (Lightweight Directory Access Protocol) organisiert Verzeichnisdienst Verzeichnis- und Dateistrukturen von Betriebssystemen HTML / XML IMS (Information Management System) von IBM Datenbanken I

Jeder Knoten kann mehrere übergeordnete Knoten haben. Netzwerkmodell Ab etwa 1970 fand das hierarchische Datenmodell seine Erweiterung im Netzwerkmodell, das nun auch Querverbindungen zwischen Baumstrukturen zuließ. Jeder Knoten kann mehrere übergeordnete Knoten haben. Jede Netzwerkstruktur lässt sich durch Einführung redundanter Knoten als hierarchische Baumstruktur darstellen. Datenbanken I

Beispiel Netzwerk-Modell Student SV Vorlesung ss vs Mustermann Wacker Java Stochastik Zahlentheorie Datenbanken I

Relationale Datenbanksysteme Datenbanken I

Ziel: Erfüllung der Codd-Regeln, Trennung DB-Anwendung und Datenbank 3-Ebenen-Architektur Nach ANSI-SPARC Views, Nutzerzugriffsrechte. Zugriff über DB-Anwendung oder Abfragesprache logische Struktur der DB: Tabellen, Integritätsbedingungen, Prozeduren... Wird vom Admin mittels Abfragesprachen verwaltet physikalische Struktur der DB: Dateien, Ablageort. Wird verwaltet vom DBMS, nicht vom Admin. Ziel: Erfüllung der Codd-Regeln, Trennung DB-Anwendung und Datenbank 1975 vom Standards Planning and Requirements Committee (SPARC) veröffentlicht zur Standardisierung der DB-Architektur -> hohes Maß an Datenunabhängigkeit, meiste CODD-Regeln erfüllt -> Zweck: Trennung von Datenbankanwendungen und der Datenbank selbst Datenbanken I

Beispiel 3-Ebenen-Architektur Bundesbahn: externe Ebene Städteverbindungen konzeptionelle Ebene Kursbuch interne Ebene Abbildung auf Dateisystem Personaldatei: externe Ebene Angestellte mit Namen, Wohnorten und Geburtstag konzeptionelle Ebene Geburtstagsliste mit Name, Datum, Alter Datenbanken I

Datenunabhängigkeit Physische Datenunabhängigkeit: keine Änderung des externen Schemas (auf der externen Ebene) bei Änderung des internen Schemas Logische Datenunabhängigkeit: keine Änderung des externen Schemas bei Änderungen des konzeptionellen Schemas Datenbanken I

Codds 12 Regeln für relationale DBS 1. Informationsregel Daten in Tabellen Zugriffsgarantie Jedes Feld eindeutig adressierbar NULL-Werte unabh. vom Datentyp existiert Wert f. nichtvorh. Daten Metadaten Metadaten in Tabellen 5. Allumfassende Sprache für alle User einheitlich, z. B. DML, DDL, DCL, TCL 6. Datenänderung in Views 7. Mengenorientierte Änderungsoperationen Mengenoperationen nicht nur für Abfragen 1.: Alle Daten sind in Tabellen abgelegt Datenbanken I

Codds 12 Regeln für relationale DBS 8. Physische Datenunabhängigkeit Anwendungsprogramme unabh. vom Speicherort Logische Datenunabhängigkeit Anwendungsprogramme logisch unabhängig v. Tabellen, ermöglicht durch Views 10. Deklarative Datenintegrität Für Einhaltung der Integritätsregeln sorgt DBMS, nicht Anwendungsprogramm 11. Verteilungsunabhängigkeit Datenbank kann physikalisch auf mehrere Speicherorte verteilt sein. Für Anwendungsprogramme unabhängig. 12. Unterwanderungsverbot Zugriff auf Daten nur über eine relationale Sprache Datenbanken I

Gemeinsame Merkmale RDBMS Erfüllung der Codd-Regeln 3-Ebenen-Architektur standardisierte Datenbanksprache SQL (structured query language) Einbettung von SQL in kommerzielle Programmiersprachen Werkzeuge für interaktive Definition, Anfrage und Darstellung von Daten, Entwurf von Benutzeroberflächen Datenbanken I

Aufbau relationaler Datenbanken Die grundlegende Struktur einer relationalen Datenbank ist die Tabelle. Eine Tabelle ein Objekt, das Daten in Datensätzen (Zeilen) und Feldern (Spalten) speichert. In der Regel besteht eine relationale Datenbank aus mehreren voneinander unabhängigen Tabellen, die über Relationen verknüpft werden. Datenbanken I

Relationale Datenbanktabelle Zeile Feld Spalte Primärschlüssel Datenbanken I

Schlüssel Schlüssel dienen der Beschleunigung von Zugriffen auf die Daten. Nur mit Hilfe von Schlüsseln ist eine relationale Verknüpfung von Tabellen möglich. Schlüssel ermöglichen eine Überwachung von Integritätsregeln. Datenbanken I

Primärschlüssel Der Primärschlüssel ermöglicht die eindeutige Identifizierung eines Datensatzes dadurch, dass sein Wert in einer Tabelle nur ein einziges Mal vorkommt. Er setzt sich aus einem oder mehreren Datenfeldern zusammen. Jede Tabelle sollte einen Primärschlüssel besitzen. Datenbanken I

Fremdschlüssel Ein oder mehrere Tabellenfelder, das auf das Primärschlüsselfeld in einer anderen Tabelle Bezug nehmen. Ein Fremd-schlüssel gibt an, in welcher Beziehung die Tabellen zueinander stehen; die Daten des Fremdschlüssels müssen mit denen der Primärschlüsselfelder übereinstimmen. Datenbanken I

1:n-Beziehung Eine Beziehung zwischen zwei Tabellen, bei der gilt: 1. Der Primärschlüsselwert jedes Datensatzes in der Mastertabelle („1“) entspricht dem Wert des jeweiligen Feldes bzw. der jeweiligen Felder in einem oder mehreren Datensätzen der Detailtabelle. 2. Der Primärschlüsselwert jedes Datensatzes in der Detailtabelle („n“) entspricht dem Wert des jeweiligen Feldes bzw. der jeweiligen Felder in genau einem Datensatz der Mastertabelle. Datenbanken I

m:n-Beziehung Eine Beziehung zwischen zwei Tabellen, bei der gilt: 1. Der Primärschlüsselwert jedes Datensatzes in der Tabelle M entspricht dem Wert des jeweiligen Feldes bzw. der jeweiligen Felder in einem oder mehreren Datensätzen der Tabelle N. 2. Der Primärschlüsselwert jedes Datensatzes in der Tabelle N entspricht dem Wert des jeweiligen Feldes bzw. der jeweiligen Felder in einem oder mehreren Datensätzen der Tabelle M. Datenbanken I

Relationenmodell Relation ~ Tabelle Tupel ~ Datensatz Attribut ~ Feld Datenbanken I

Normalisierung Datenbanken I

Anomalien Löschanomalie Einfügeanomalie Änderungsanomalie 2 Englisch I KursNr Kurs_Bez Dozent Anrede Vorname Nachname Telefon 2 Englisch I LL Frau Lisa Lustig 563567 15 Algebra HM Herr Hugo Meier 5673456 27 Buchführung SS Susi Sorglos 68723 51 Englisch II 78 Excel MM Martin Schulze 256254 Löschanomalie Einfügeanomalie Änderungsanomalie Datenbanken I

Anomalien vermeiden Normalformen, Entwurfstheorie und Entwurfsregeln Um Anomalien zu vermeiden, wurden Normalformen, Entwurfstheorie und Entwurfsregeln formuliert. Datenbanken I

Normalisierung Normalformen: Regeln des Tabellenentwurfs. Beim Normalisierungsprozess werden die Daten auf mehrere Tabellen verteilt. Ziel ist eine konsistente Datenhaltung ohne Redundanzen ohne Anomalien. Datenbanken I

Normalformen-Historie Ursprünglich wurden 1973 von Edgar F. Codd 3 Normalformen (1NF, 2NF, 3NF) vorgeschlagen. Jede Stufe beinhaltet die vorhergehende 1NF->2NF->3NF 3NF wurde 1974 revidiert -> Boyce-Codd-NF (BCNF) Später weitere (4NF, 5NF) Normalformen, eher weniger bedeutend Weg: Aufspaltung in Relationen Datenbanken I

Normalformen beinhalten einander Datenbanken I

Anforderungen an NF Aufspaltung in Relationen muss verlustfrei geschehen kein Verlust von Informationen keine falschen Informationen kein Verlust an Integritätsbedingungen Datenbanken I

Hinweise zur Normalisierung NF sind Richtlinien für guten DB-Entwurf. Sie sind kein Zwang! Strikte Normalisierung führt zu größerer Anzahl von Relationen Normalisierung nie losgelöst vom konkreten Kontext der DB betreiben! Je weiter normalisiert werden soll, desto größer die Anforderung an das Hintergrundwissen über die Daten Normalisierung nicht immer erforderlich nicht immer machbar (-> Performanz) nicht immer sinnvoll (zu viele Relationen...) Datenbanken I

Erste Normalform Eine Relation ist dann in der ersten Normal-form, wenn alle ihre Attribute atomar sind. atomar: Der Wert eines Attributs lässt sich nicht weiter teilen oder muss (für diesen Anwendungsfall) nicht weiter geteilt werden. Mengenwertige Attribute sind verboten. Spalten mit gleichartigem Inhalt müssen zusammengefasst werden. Datenbanken I

Erste Normalform Beispiel Spalten mit gleichartigem Inhalt eliminieren Verboten sind mengenwertige Attribute: Vater Mutter Kinder Johann Martha {Else, Lucia} Johann Maria {Theo, Josef} Heinz Martha {Cleo} Verlangt werden atomare Attribute: Vater Mutter Kind Johann Martha Else Johann Martha Lucia Johann Maria Theo Johann Maria Josef Heinz Martha Cleo Datenbanken I

Funktionale Abhängigkeiten sind eine Form der Integritätsbedingungen. A und B seien Attribute. B ist von A funktional abhängig ( A -> B), genau dann, wenn für jeden Wert von A genau ein Wert von B existiert. Gleiche A-Werte ergeben somit gleiche B-Werte. Sprechweise: B hängt von A ab. (oder: B ist funktional abhängig von A) Die Schlüsselabhängigkeit ist ein Spezialfall von funktionaler Abhängigkeit. Der Wert von B muss jedoch nicht nur einmal in einer Relation vorkommen. Abkürzung: FD (functional dependency) Datenbanken I

Definition funktionale Abhängigkeit [X] ist der Wert von Attribut X im Tupel  z.B. Datensatz12[Kundennr]=123 Datenbanken I

Beispiel funktionale Abhängigkeit Mitarbeiter(MitarbeiterID, Nachname, Vorname, AbteilungID, Abteilungsleiter, Unternehmen, Unternehmensanschrift, Berufsgruppe, Gehaltsklasse) Datenbanken I

Ableitung von funkt. Abhängigkeiten C a1 b1 c1 a2 a3 b2 a4 Datenbanken I

volle funktionale Abhängigkeit  ist voll funktional abhängig von  ( =>), falls gilt     A   :  – {A}   Ein Attribut  ist voll funktional abhängig von einer Attributmenge  falls  funktional abhängig ist von  und  nicht funktional abhängig ist von einer echten Teilmenge von . Bsp: Kunde(KundenID, Nachname, PLZ, Ort) KundenID, Nachname  PLZ, Ort aber KundenID, Nachname ≠> PLZ, Ort , da KundenID  PLZ, Ort Datenbanken I

Schlüssel KundenID Vorname Nachname PLZ Ort 1 Martha Muster 12345 Norddorf 2 Heinz Huber 45678 Weststadt KundenID Vorname, Nachname, PLZ, Ort es gilt auch KundenID →KundenID, damit ist das gesamte Schema auf rechter Seite der FA Wenn linke Seite minimal: Schlüssel Formal: Eine Attributmenge X ist Schlüssel von R, wenn das Relationenschema R voll funktional abhängig von X ist (X => R) und X minimal ist. Gibt es mehrere mögliche Schlüssel, so heißen diese Schlüsselkandidat. Ziel des Datenbankentwurfs: alle gegebenen funktionalen Abhängigkeiten in Schlüsselabhängigkeiten umformen, ohne dabei semantische Information zu verlieren Datenbanken I

Definition Schlüssel Sei R eine Attributmenge, X  R. X heißt Schlüssel für Tupelmenge r  Rel(R), falls gilt: 1. ( Tupel ,   r) [X] = [X]  = Für alle Tupel der Relation gilt: sind die Schlüsselwerte gleich, so handelt es sich um die gleichen Tupel. 2. für keine echte Teilmenge X‘  X gilt (1) Datenbanken I

Zweite Normalform Ein Attribut heißt Primärattribut, wenn es in mindestens einem Schlüsselkandidaten vorkommt, andernfalls heißt es Nichtprimärattribut. Ein Relationenschema R ist in zweiter Normalform falls gilt: R ist in der ersten Normalform und jedes Nichtprimär-Attribut A  R ist voll funktional abhängig von jedem Schlüsselkandidaten. Datenbanken I

Beispiel Studentenbelegung Schlüsselkandiaten: {MatrNr, VorlNr} MatrNr VorlNr Name Semester 26120 5001 Fichte 10 27550 5001 Schopenhauer 6 27550 4052 Schopenhauer 6 28106 5041 Carnap 3 28106 5052 Carnap 3 28106 5216 Carnap 3 28106 5259 Carnap 3 . . . . . . . . . . . . Studentenbelegung Schlüsselkandiaten: {MatrNr, VorlNr} Nichtprimärattribute: {Name, Semester} Name ist nicht voll funktional abhängig von {MatrNr, VorlNr}  keine 2. Normalform MatrNr VorlNr Name Semester Datenbanken I

Beispiel Hörsaal Schlüsselkandidaten: {Vorlesung, Termin} Vorlesung Dozent Termin Raum Backen ohne Fett Kant Mo, 10:15 32/102 Selber Atmen Sokrates Mo, 14:15 31/449 Selber Atmen Sokrates Di, 14:15 31/449 Schneller Beten Sokrates Fr, 10:15 31/449 Hörsaal Schlüsselkandidaten: {Vorlesung, Termin} {Dozent, Termin} {Raum, Termin} Es gibt keine Nicht-Primärattribute  2. Normalform Datenbanken I

Beispiel Student Student in zweiter Normalform aber MatrNr Name Fachbereich Dekan 29555 Feuerbach 6 Matthies 27550 Schopenhauer 6 Matthies 26120 Fichte 4 Kapphan 25403 Jonas 6 Matthies 28106 Carnap 7 Weingarten Student Student in zweiter Normalform aber Abhängigkeiten zwischen den Nichtprimärattributen: Fachbereich → Dekan Datenbanken I

Transitive Abhängigkeit Gegeben Attributmenge U mit Teilmengen X,Y,Z Z heißt transitiv abhängig von X, falls gilt X  Z =   Y  U : X Y = , Y  Z =  / X  Y  Z, Y  X Beispiel:  MatrNr  Fachbereich  Dekan Datenbanken I

Dritte Normalform Die Relation R ist in dritter Normalform, wenn gilt: R ist in zweiter Normalform Jedes Nichtprimärattribut ist nicht-transitiv abhängig von jedem Schlüsselkandidaten Praktische Anwendung: Attribute, die nicht in unmittelbarer Abhängigkeit zum Primärschlüssel einer Tabelle stehen, müssen in eine eigene Tabelle ausgelagert werden. Datenbanken I

Beispiel 3. Normalform 1 Entwicklung 70 50 2 Assistenz 30 35 3 45 MitarbeiterID ProjektID Aufgabe Anz_Stunden Stundensatz 1 Entwicklung 70 50 2 Assistenz 30 35 3 45 Primärschlüssel ist {MitarbeiterID, ProjektID} 2. Normalform ist erfüllt. Jedoch ist MitarbeiterID → Aufgabe → Stundensatz somit ist die Relation nicht in der 3. Normalform Aufteilung in 2 Tabellen: ProjektMit(MitarbeiterID, ProjektID, AufgabeID, Stunden) Aufgabe(AufgabeID, Bezeichnung, Stundensatz) Datenbanken I

PersNr  {Ort, BLand}  Vorwahl ProfessorenAdr ProfessorenAdr(PersNr, Rang, Name, Straße, PLZ, Ort, Bundesland, Vorwahl, Landesregierung, Raum) PersNr Raum Rang Name Straße Ort BLand Landesregierung Vorwahl PLZ Alle Nichtprimärattribute sind voll funktional abhängig von jedem Schlüsselkandidaten. PersNr  {Ort, BLand}  Vorwahl   nicht in 3. Normalform Datenbanken I

Normalformen (einfach) Jedem Feld einer Tabelle darf höchstens ein Wert zugewiesen werden.  2. Normalform Die Tabelle ist in der 1. Normalform und jedes Nicht-Schlüsselfeld ist durch den Gesamtschlüssel identifizierbar. 3. Normalform Die Tabelle ist in der 2. Normalform und alle Datenfelder sind nur vom gesamten Schlüssel abhängig und haben keine Abhängigkeiten untereinander. Datenbanken I

The key, the whole key, and nothing but the key, so help me Codd. Der Schlüssel, der gesamte Schlüssel, und nichts als der Schlüssel, so wahr mir Codd helfe. Datenbanken I

Normalisierung-Beispiel Datenbanken I

Bsp: vor Normalisierung KundeID Nachname Telefon AuftragID Auftrag-datum Bearbeiter Abteilung 1 Meier 0511-12345, 0179-222222 200 10.1.12 Mirka Einkauf 2 Müller NULL 201 11.1.12 3 Schulze 0211-12345 202 Erik Versand Datenbanken I

Bsp.: erste Normalform Telefon: Kunde: 1 Meier 200 10.1.12 Mirka KundeID Nachname AuftragID Auftrag-datum Bearbeiter Abteilung 1 Meier 200 10.1.12 Mirka Einkauf 2 Müller 201 11.1.12 3 Schulze 202 Erik Versand Telefon: TelefonID KundeID Telefonnr 100 1 0511-12345 101 0179-222222 102 3 0211-12345 Datenbanken I

Bsp.: zweite Normalform Telefon: Kunde: KundeID Nachname 1 Meier 2 Müller 3 Schulze TelefonID KundeID Telefonnr 100 1 0511-12345 101 0179-222222 102 3 0211-12345 Auftrag: AuftragID Auftrag-datum Bearbeiter Abteilung KundeID 200 10.1.12 Mirka Einkauf 1 201 11.1.12 2 202 Erik Versand 3 Datenbanken I

Bsp.: dritte Normalform Telefon: Kunde: KundeID Nachname 1 Meier 2 Müller 3 Schulze TelefonID KundeID Telefonnr 100 1 0511-12345 101 0179-222222 102 3 0211-12345 Auftrag: Bearbeiter: AuftragID Auftrag-datum BearbeiterID KundeID 200 10.1.12 1000 1 201 11.1.12 2 202 1001 3 BearbeiterID Bearbeiter Abteilung 1000 Mirka Einkauf 1001 Erik Versand Datenbanken I

ENDE Fragen?

Literatur Heuer, A.; Saake, G.: Datenbanken: Konzepte und Sprachen. mitp-Verlag Kemper, A., Eickler, A.: Datenbanksysteme. Oldenbourg Vossen, Gottfried: Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme. Oldenbourg Date, Chris J.: An Introduction to Database Systems. Addison Wesley einfachere Einführungen, diese decken den Lehrstoff jedoch nicht vollständig ab: Geisler, Frank: Datenbanken. Grundlagen und Design. mitp Cordts, Sönke: Datenbankkonzepte in der Praxis. Addison Wesley Datenbanken I 68

Quellen Tannenbaum, Andrew, Moderne Betriebssysteme H. Bethge, Vorlesungsskript DB, FHDW R. Walther, Vorlesungsskript BIS, FHDW 2011 G. Hellberg, Vorlesungsskripte BIS, FHDW 2003 G. Hellberg, diverse Vorlesungsskripte Betriebssysteme, FHDW 2000-2011 G. Hellberg, Vorlesungsskripte Netzwerke, FHDW 2000-2011 G. Hellberg, Vorlesungsskripte Technische Grundlagen, FHDW 2007-2011 Microsoft Whitepapers Diverse Quellen Internet (Wikipedia)