html5-img
1 / 69

Studiengang BWL FHDW

Vorlesung: Betriebliche Informationssysteme II Datenbanken Teil 2 BI-U2 2. Quartal 2012. Studiengang BWL FHDW. Datenbanken I. Aufbau von Datenbankmanagementsystemen Relationale Datenbanksysteme Normalisierung Entity-Relationship-Diagramme Praxis: Datenbanksystem MySQL

Télécharger la présentation

Studiengang BWL FHDW

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

  3. Datenbanken I Aufbau von Datenbankmanagement-Systemen

  4. 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

  5. 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

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

  7. 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.

  8. 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

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

  10. 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

  11. 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)

  12. 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

  13. Datenbanken I Datenmodelle • Hierarchisches DatenmodellIMS (Information Management System) IBM • NetzwerkmodellUDS von Siemens • Relationales DatenmodelldBase, MySQL, Access, SQL-Server, ... • Objektorientiertes Datenmodellteilw. Oracle, O2 von O2 Technology

  14. 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)

  15. Datenbanken I Beispiel Hierarchisches Modell

  16. Datenbanken I Ausprägung Hierarchisches Modell

  17. 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

  18. Datenbanken I 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.

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

  20. Datenbanken I Relationale Datenbanksysteme

  21. Datenbanken I 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

  22. 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 interne Ebene Abbildung auf Dateisystem

  23. 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 Schemasbei Änderungen des konzeptionellen Schemas

  24. Datenbanken I Codds 12 Regeln für relationale DBS • 1. InformationsregelDaten in Tabellen • ZugriffsgarantieJedes Feld eindeutig adressierbar • NULL-Werteunabh. vom Datentyp existiert Wert f. nichtvorh. Daten • MetadatenMetadaten in Tabellen • 5. Allumfassende Sprachefür alle User einheitlich, z. B. DML, DDL, DCL, TCL • 6. Datenänderung in Views • 7. Mengenorientierte ÄnderungsoperationenMengenoperationen nicht nur für Abfragen

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

  26. 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

  27. 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.

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

  29. 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.

  30. 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.

  31. 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.

  32. 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.

  33. 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.

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

  35. Datenbanken I Normalisierung

  36. Datenbanken I Anomalien Löschanomalie Einfügeanomalie Änderungsanomalie

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

  38. 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.

  39. 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

  40. Datenbanken I Normalformen beinhalten einander

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

  42. 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...)

  43. Datenbanken I Erste Normalform • 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. Eine Relation ist dann in der ersten Normal-form, wenn alle ihre Attribute atomar sind.

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

  45. 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)

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

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

  48. Datenbanken I Ableitung von funkt. Abhängigkeiten

  49. Datenbanken I volle funktionale Abhängigkeit • ist voll funktional abhängig von ( =>), falls gilt     A   :  – {A}   • Ein Attribut  istvollfunktionalabhängig von einerAttributmenge  falls •  funktionalabhängigist von  • und  nichtfunktionalabhängigist von einerechtenTeilmenge von . • Bsp: Kunde(KundenID, Nachname, PLZ, Ort)KundenID, Nachname  PLZ, OrtaberKundenID, Nachname ≠> PLZ, Ort , daKundenID PLZ, Ort

  50. Datenbanken I Schlüssel KundenIDVorname, Nachname, PLZ, Ortes 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

More Related