Studiengang BWL FHDW Vorlesung: Betriebliche Informationssysteme II

Präsentation zum Thema: "Studiengang BWL FHDW Vorlesung: Betriebliche Informationssysteme II"—  Präsentation transkript:

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

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

3 Aufbau von Datenbankmanagement-Systemen
Datenbanken I

4 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

5 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

6 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

7 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

8 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

9 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

10 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

11 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

12 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

13 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

14 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

15 Beispiel Hierarchisches Modell
Datenbanken I

16 Ausprägung Hierarchisches Modell
Datenbanken I

17 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

18 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

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

20 Relationale Datenbanksysteme
Datenbanken I

21 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

22 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

23 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

24 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

25 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

26 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

27 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

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

29 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

30 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

31 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

32 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

33 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

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

35 Normalisierung Datenbanken I

36 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 27 Buchführung SS Susi Sorglos 68723 51 Englisch II 78 Excel MM Martin Schulze 256254 Löschanomalie Einfügeanomalie Änderungsanomalie Datenbanken I

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

38 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

39 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

40 Normalformen beinhalten einander
Datenbanken I

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

42 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

43 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

44 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

45 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

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

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

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

49 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

50 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

51 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

52 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

53 Beispiel Studentenbelegung Schlüsselkandiaten: {MatrNr, VorlNr}
MatrNr VorlNr Name Semester Fichte 10 Schopenhauer 6 Schopenhauer 6 Carnap 3 Carnap 3 Carnap 3 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

54 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

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

56 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

57 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

58 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

59 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

60 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

61 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

62 Normalisierung-Beispiel
Datenbanken I

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

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

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

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

67 ENDE Fragen?

68 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

69 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 G. Hellberg, Vorlesungsskripte Netzwerke, FHDW G. Hellberg, Vorlesungsskripte Technische Grundlagen, FHDW Microsoft Whitepapers Diverse Quellen Internet (Wikipedia)