Vorlesung DBMS Thema: Datenbanktechnologie

Präsentation zum Thema: "Vorlesung DBMS Thema: Datenbanktechnologie"—  Präsentation transkript:

1 Vorlesung DBMS Thema: Datenbanktechnologie
- Von der Realwelt zur Datenbank - Michael Andriczka Sommersemester 2003 Michael Andriczka DBMS

2 Inhalt Einleitung 1.1 Charakteristika
1.2 Vergleich Datenredundanz vs. Datenintegrität 1.3 Prinzipien 1.4 Eigenschaften aktueller DBS 1.5 Einige konkrete Systeme 1.6 Datenbankgrößen 1.7 Gegenwärtiger Entwicklungsstand Von der Realwelt zum ER-Modell 2.1 Die sogenannte Miniwelt (1) 2.2 Entität 2.3 Attribute 2.4 Schlüssel 2.5 Beziehungen 2.6 Die sogenannte Miniwelt (2) Michael Andriczka DBMS

3 Inhalt 3. Vom Modell zur Datenbank
3.1 Umsetzung des ER-Modells in das relationale Datenbankschema 3.2 Normalisierung 4. Schlussbetrachtung Michael Andriczka DBMS

4 1. Einleitung 1.1 Charakteristika von Datenbanken
Eine Datenbank hat die langfristige Aufbewahrung von Daten als Aufgabe Die Sicherheit vor Verlusten ist eine Hauptmotivation, etwas „auf die Bank zu bringen“. Eine Bank bietet Dienstleistungen für mehrere Kunden an, um effizient arbeiten zu können. Michael Andriczka DBMS

5 1. Einleitung 1.2 Datenredundanz vs. Datenintegration
Ohne Datenbanken: Datenredundanz Basis- oder Anwendungssoftware verwaltet ihre eigenen Daten in ihren (eigenen) Dateiformaten - Textverarbeitung: Texte, Artikel und Adressen - Buchhaltung: Artikel, Adressen - Lagerverwaltung: Artikel, Aufträge - Auftragsverwaltung: Aufträge, Artikel, Adressen - CAD-System: Artikel, Technische Bausteine Daten sind redundant: mehrfach gespeichert; Probleme: Verschwendung von Speicherplatz, „Vergessen“ von Änderungen; keine zentrale, „genormte“ Datenhaltung Michael Andriczka DBMS

6 1. Einleitung Mehrere Benutzer oder Anwendungen können nicht parallel
auf den gleichen Daten arbeiten, ohne sich zu stören Anwendungsprogrammierer/Benutzer können Anwendungen nicht programmieren/benutzen, ohne - interne Darstellung der Daten - Speichermedien oder Rechner zu kennen (Datenunabhängigkeit nicht gewährleistet) Datenschutz und Sicherheit sind nicht gewährleistet Michael Andriczka DBMS

7 1. Einleitung 1.2 Datenredundanz vs. Datenintegration
Mit Datenbanken: Datenintegration Die gesamte Basis- und Anwendungssoftware arbeitet auf den selben Daten, z.B. Adressen und Artikel werden nur einmal gespeichert - Datenbanksysteme können große Mengen an Daten effizient verwalten (Anfragesprachen) - Benutzer können parallel auf Datenbanken arbeiten (Transaktionskonzept) - Datenschutz (kein unbefugter Zugriff) und Datensicherheit (kein ungewollter Datenverlust) werden vom System gewährleistet Michael Andriczka DBMS

8 1. Einleitung 1.3 Prinzipien Datenbank-Management-System
Unter einem Datenbank-Management-System (DBMS) versteht man ein Softwarepaket, welches in der Lage ist, (Anwender-) Daten in einem Computersystem zu verwalten. Spricht man von einem relationalen Datenbank-Management-System, meint man damit, dass dieses DBMS für die Verwaltung der Daten intern eine bestimmte Technologie benutzt und dass es bestimmten Anforderungen genügt. Datenbank-System Unter einem Datenbank-System versteht man ein DBMS mit zusätzlich einer oder mehreren Datenbanken zur Sammlung von nicht redundanten Daten, die von mehreren Applikationen benutzt werden.

9 1. Einleitung DB: Strukturierter, von DBMS verwalteter Datenbestand
DBS: Datenbanksystem (DBMS + Datenbank) DBMS: Datenbank-Management-System Michael Andriczka DBMS

10 1. Einleitung Grundmerkmale von DBMS
- verwalten persistente (langfristig zu haltende) Daten - verwalten große Datenmengen effizient - Datenmodell, mit dessen Konzepten alle Daten einheitlich beschrieben werden (Integration) - Transaktionskonzept - Datenschutz, Datenintegrität (Konsistenz), Datensicherheit Grundprinzip moderner DBS - 3-Ebenen-Architektur - Trennung zwischen Schema (Tabellenstruktur) und Instanz (etwa Tabelleninhalt) Michael Andriczka DBMS

11 1. Einleitung 1.4 Eigenschaften aktueller Datenbanksysteme
3-Ebenen-Architektur nach ANSI-SPARC Externe Ebene (Benutzersichten) Konzeptionelle Ebene (Logische Gesamtsicht) Interne Ebene (Physische Schicht) Einheitliche Datenbankanfragesprache SQL Einbettung dieser Sprache in kommerzielle Programmier- sprachen Diverse Werkzeuge für die Definition, Anfrage und Darstellung von Daten und den Entwurf von Datenbankanwendungsprogrammen und der Benutzer-Interaktion, sowie Kontrollierter Mehrbenutzerbetrieb, Zugriffskontrolle und Datensicherheitsmechanismen Michael Andriczka DBMS

12 1. Einleitung 1.5 Einige konkrete Systeme (Objekt-)Relationale DBMS
- Oracle 9i, DB2 V.8, Microsoft SQL-Server 2000 - MySQL, PostgreSQL, FireBird Pseudo DBMS - MS Access Objektorientierte DBMS - Poet, Versant, ObjectStore XML-DBMS - Tamino, eXcelon Michael Andriczka DBMS

13 1. Einleitung 1.6 Datenbankgrößen Slolan Digital Sky Survey 40 TB
Himmelsdaten (Bilder und Objektinformationen); WalMart Data WareHouse 24 TB Produktinfos (Verkäufe, etc.) von 2900 Märkten; Anfragen pro Wochen US Libary of Congress TB nicht digitalisiert Indexierbares WWW (1999) 6 TB ca. 800 Millionen Dokumente Microsofts TerraServer 3,5 TB unkomprimierte Bilder und Daten (komprimiert: ca. 1 TB) Michael Andriczka DBMS

14 1. Einleitung SAP R/3-Installation der Deutschen Telekom AG (1998)
Financial Accounting: Rechnungen, Lastschriften Zahlungsaufforderung, Mahnungen, etc. 15 SAP R/3-Systeme; jedes - verarbeitet Rechnungen, Mahnungen, Änderungen von Kundendaten pro Tag - bis zu jeweils 1000 Nutzer gleichzeitig Über Datenbanktabellen Michael Andriczka DBMS

15 1. Einleitung 1.7 Gegenwärtiger Entwicklungsstand
Unterstützung für spezielle Anwendungen - Multimedia-Datenbanken: Verwaltung multimedialer Objekte (Bilder, Audio, Video) - XML-Datenbanken: Verwalten semistrukturierter Daten - Verteilte Datenbanken: Verteilung von Daten auf verschiedenen Rechnerknoten - Förderierte Datenbanken: Multimedia-Datenbanken - Mobile Datenbanken: Datenverwaltung auf Kleinstgeräten (PDA, Handy) Michael Andriczka DBMS

16 2. Von der Realwelt zum ER-Modell
2.1 Die sogenannte Miniwelt (1) Um zu einem geeigneten Modell zu gelangen, muss zunächst durch eine Analyse der realen Welt ein zu modellierender Teilausschnitt dieser realen Welt definiert werden. Diesen Teilausschnitt nennt man auch Miniwelt. Beispiel: Die Firma Mustermann handelt mit PCs und Zubehör. Aus dem Produktkatalog der Firma Mustermann können Kunden per Telefon oder per Bestellkarte ein oder mehrere Artikel zur Bestellung aufgeben. Aufgrund der enormen Nachfrage nach PCs und Zubehör kann das Geschäftsaufkommen mittlerweile nicht mehr über Karteikarten abgewickelt werden. Somit entschließt man sich zur Einführung eines relationalen DBS und der dazu gehörigen Anwendungsprogramme. Beim Betrachten dieser Miniwelt erkennt man gewisse Objekte (sog. Entities) wie Artikelnamen, Kundennamen, Bestellungen usw. Zwischen diesen Objekten existieren Beziehungen (sog. Relationships), die bestimmte Abläufe oder Abhängigkeiten in der Miniwelt darstellen. Michael Andriczka DBMS

17 2. Von der Realwelt zum ER-Modell
Um zu einem Datenmodell zu gelangen, fasst man gleichartige Objekte und gleichartige Beziehungen zu Klassen zusammen. Somit ergeben sich: Objekttypen wie Artikel, Bestellung, Kunden und Beziehungstypen wie Bestellposition, welche die Objekte in eine gewisse Beziehung bringen. Jedem Objekttyp oder Beziehungstyp sind gewisse Eigenschaften zu- geordnet, wie z.B. dem Objekttyp Artikel die Eigenschaften Bezeichnung und Preis. Man nennt diese Eigenschaften eines Objekttyps oder Beziehungstyps auch Attribute. Zur Darstellung von Objekten (Entities) und vor allem der Beziehungen zwischen den Objekten dienen die sogenannten ER-Diagramme. Michael Andriczka DBMS

18 2. Von der Realwelt zum ER-Modell
2.2 Entität Ausgangspunkt des ER-Modells ist der Begriff der Entität. Eine Entität ist ein individuelles und identifizierbares Exemplar von Dingen, Personen oder Begriffen der realen oder der Vorstellungswelt. Die Entität wird durch Attribute näher beschrieben. Die Entitätsmenge (auch Entitytyp genannt) wird im ER-Modell durch ein Rechteck dargestellt. In dem Rechteck steht der Name der Entität. Der Name beschreibt die Entitätsmenge und steht im Singular. Die Entität (Entity) ist also das konkrete, individuell identifizierbare Objekt bzw. Exemplar von Dingen, Personen oder Begriffen der realen oder der Vorstellungswelt. KUNDE Michael Andriczka DBMS

19 2. Von der Realwelt zum ER-Modell
Beispiele: Individuen: Mitarbeiterin Brecht, Student Weber, Kunde Meier Reales Objekt: Maschine 2, Raum 7, Artikel Ereignis: Zahlung, Buchung, Mahnung, Start, Landung..... Abstraktes: Unterricht, Dienstleistung, Verarbeitungsart, Zahlungsart.... Der Kunde Meier ist also ein konkretes individuell identifizierbares Objekt, über den Informationen abgespeichert werden müssen. Er gehört zur Gruppe der Kunden. Man kann auch sagen, er ist vom Entitätstyp Kunde. Alle Informationen, die über Kunden abgespeichert werden, sind von der Struktur her gleich. Michael Andriczka DBMS

20 2. Von der Realwelt zum ER-Modell
2.3 Attribute Attribute beschreiben die Entitäten. Beispiel: Kunde (KdNr, KName, KAdresse,...) Man unterscheidet zwischen identifizierenden Attributen, sog. Schlüssel (z.B.: KdNr, FirmenNr, PersNr...) beschreibenden Attributen (z.B.: KName, MitarbeiterName, ArtikelBez, ... ) KdNr KUNDE KName Michael Andriczka DBMS

21 2. Von der Realwelt zum ER-Modell
2.4 Schlüssel: Eine minimale Menge von Attributen, deren Werte das zugeordnete Entity eindeutig innerhalb aller Entities seines Typs identifiziert. Man unterscheidet Primärschlüssel und Fremdschlüssel. 2.4.1 Primärschlüssel: Der Primärschlüssel wird benötigt, um Datensätze eindeutig zu identifizieren, also der Datensatz darf nicht doppelt (z.B. in einer Tabelle) vorkommen. Der Primärschlüssel ist in einem ER-Modell anhand des unterstrichenem Attributes zu erkennen. Die Merkmale eines Feldes mit Primärschlüssel sind: Der Inhalt eines Feldes ist eindeutig In jedem Datensatz müssen Daten stehen Ein Primärschlüssel kann sich auch aus mehreren Feldern zusammensetzen Michael Andriczka DBMS

22 2. Von der Realwelt zum ER-Modell
2.4.2 Fremdschlüssel: Der Fremdschlüssel ist ein Attributwert, der einen Schlüsselwert in einer anderen Tabelle darstellt und somit als eindeutiger Verweis auf einen Datensatz in einer anderen Tabelle zeigt. Dies wird auch als referentielle Integrität benannt. Beispiel Fremdschlüssel: Fremdschlüssel Primärschlüssel Referentielle Integrität KNr PNr Kurs BereichsNr 44 15 D 1 45 G 2 47 6 M 48 I 49 E BereichsNr Bereich 1 Sprache 2 Geisteswissenschaften 6 Naturwissenschaften Michael Andriczka DBMS

23 2. Von der Realwelt zum ER-Modell
2.5 Beziehungen Die Wechselwirkungen und Abhängigkeiten zwischen Entitäten werden durch Beziehungen (relationship) dargestellt. Die Zusammenfassung gleichartiger Beziehungen zwischen Entitäten erfolgt durch Beziehungsmengen. Eine Beziehung wird nach Chen graphisch durch eine Raute dargestellt. In ihr steht der Name der Beziehung. Als Name sollte ein Verb gewählt werden. gibt auf Michael Andriczka DBMS

24 2. Von der Realwelt zum ER-Modell
Die Beziehung wird durch eine Verbindungslinie, zwischen der die Raute steht, dargestellt. Zwischen den Entitätstypen KUNDE und BESTELLUNG besteht ein Beziehungstyp „gibt auf“. Wenn es einen solchen Beziehungstyp gibt, so kann (muss) eine konkrete Beziehung zwischen einem Paar der dazu gehörenden Entitäten bestehen 1 n Man liest: KUNDE gibt auf Bestellungen bzw. Bestellungen werden aufgegeben von Kunde. KUNDE gibt auf BESTELLUNG Michael Andriczka DBMS

25 2. Von der Realwelt zum ER-Modell
2.6 Die sogenannte Miniwelt (2) Drei der wichtigsten Objekttypen aus der Miniwelt der Firma Mustermann werden nun mit den dazugehörigen Attributen als Datenmodell dienen. Es handelt sich hierbei um die Objekte Kunden: alle Kunden, die Bestellungen aufgeben Bestellung: die offenen Bestellungen der Kunden Artikel: alle lieferbaren Artikel Michael Andriczka DBMS

26 2. Von der Realwelt zum ER-Modell
KdNr KUNDE KName 1 gibt auf n BestellNr BESTELLUNG Datum n Bestellposition Menge n Bez ARTIKEL ArtikelNr Preis Michael Andriczka DBMS

27 3. Vom Modell zur Datenbank
3.1 Umsetzung des ER-Modells in das relationale Datenmodell Das ER-Modell besitzt zwei grundlegende Strukturierungskonzepte: Entitytypen und Beziehungstypen Dem steht im relationalen Modell nur ein einziges Strukturierungskonzept – nämlich die Relation – gegenüber. Also werden sowohl Entitytypen als auch Beziehungstypen jeweils auf eine Relation (Tabelle) abgebildet. Zu den Entitytypen als auch zu den Beziehungstypen aus dem vorherigen ER-Modell werden nun Relationen gebildet. Hierbei werden die Spalten als Attribute (Felder) bezeichnet. Die Attribute müssen innerhalb einer Relation eindeutig benannt sein. Die Zeilen der Tabelle entsprechen den Tupeln der Relation. Michael Andriczka DBMS

28 3. Vom Modell zur Datenbank
KUNDE : {KdNr, KName} BESTELLUNG : {BestellNr, Datum, KdNr} BESTELLPOSITION : {BestellNr, ArtikelNr, Menge} ARTIKEL : {ArtikelNr, Bez, Preis} ER-Modell Relationales Modell Entity = Objekt Relation = zweidimensionale Relationship = Beziehung Tabelle Entität Schlüsselattribut Schlüsselattribut Entität KdNr KUNDE KdNr KName 001112 Meier 001535 Schulz KUNDE KName Michael Andriczka DBMS

29 3. Vom Modell zur Datenbank
3.2 Normalisierung Unter Normalisierung versteht man das Aufteilen der Daten in Relationen in der Art und Weise, dass sie am Ende den Normalisierungsregeln entsprechen. Normalisierungsgründe Minimierung redundanter Daten Vermeidung von Änderungsanomalien Reduzierung inkonsistenter Daten Entwerfen von Datenstrukturen, die eine einfache Pflege erlauben Michael Andriczka DBMS

30 3. Vom Modell zur Datenbank
Normalform Die Normalformenlehre von Codd besagt, dass sich eine Relation nur dann in der ersten Normalform befindet, wenn der Wertebereich der Attribute elementar ist. PNr Vorname Name Straße PLZ Wohnort KNr Kurs 15 Hugo Meier Schulstr.1 10124 Berlin 44, 45 D, G 6 Detlef Euler Maiweg 5 54294 Trier 47, 48, 49 M, I, E Michael Andriczka DBMS

31 3. Vom Modell zur Datenbank
Normalform Eine Relation ist in der ersten Normalform, wenn alle Attribute nur atomare Werte beinhalten. Eindeutige Identifikation durch Primärschlüssel Redundanzfreiheit Da hier Anomalien in der 1NF auftreten können, ist es sinnvoll, die Relation in die 2NF zu überführen. PNr Vorname Name Straße PLZ Wohnort KNr Kurs 15 Hugo Meier Schulstr.1 10124 Berlin 44 D 45 G 6 Detlef Euler Maiweg 5 54294 Trier 47 M 48 I 49 E Michael Andriczka DBMS

32 3. Vom Modell zur Datenbank
Normalform Eine Relation ist in der zweiten Normalform, wenn sie sich in der ersten Normalform befindet und jedes Nicht-Schlüssel-Attribut funktional vom Gesamtschlüssel abhängig ist, nicht aber von einzelnen Schlüsselteilen. Vermeidung der Anomalien der 1NF durch Aufteilung der Entitäten in seperate Tabellen. PNr Vorname Name Straße PLZ Wohnort KNr Kurs Bereich 15 Hugo Meier Schulstr.1 10124 Berlin 44 D Sprache 45 G Geisteswissenschaften 6 Detlef Euler Maiweg 5 54294 Trier 47 M Naturwissenschaften 48 I 49 E Michael Andriczka DBMS

33 3. Vom Modell zur Datenbank
Tabelle Lehrer Wie man sieht, entfallen somit die Zeilen mit unterschiedlichen Kursen derselben Lehrer. Die Kurse wurden in eine andere Tabelle ausgelagert, da sie nicht voll funktional von dem Schlüsselattribut PNR abhängen. Tabelle Kurse PNr Vorname Name Straße PLZ Wohnort 15 Hugo Meier Schulstr.1 10124 Berlin 6 Detlef Euler Maiweg 5 54294 Trier KNr Kurs Bereich 44 D Sprache 45 G Geisteswissenschaften 47 M Naturwissenschaften 48 I 49 E Michael Andriczka DBMS

34 3. Vom Modell zur Datenbank
Mit den Tabellen Lehrer und Kurse besitzt man nun zwei Tabellen, die nichts miteinander zu tun haben und somit nicht mehr den Zustand der 1NF genügen. Es muss also eine Tabelle geschaffen werden, die beide Tabellen verbindet, jedoch die Redundanzen der Tabelle in der 1NF vermeidet. PNr wurde zur Herstellung der referentiellen Integrität als Fremdschlüssel in die Tabelle Kurse eingefügt. KNr Kurs Bereich PNr 44 D Sprache 15 45 G Geisteswissenschaften 47 M Naturwissenschaften 6 48 I 49 E Michael Andriczka DBMS

35 3. Vom Modell zur Datenbank
Normalform Beim Betrachten der Tabelle Kurse in der 2NF treten folgende Anomalien auf: Bereichsnummer hat mehrmals den selben Wert, während sich der Wert des Primärschlüssels ändert Bereichsnamen treten mehrfach auf und müssten Änderungen in mehreren Datensätzen geändert werden transitive Abhängigkeit Transitive Abhängigkeit: Abhängigkeit zwischen nicht Schlüsselattributen KNr PNr Kurs Bereich BereichsNr 44 15 D Sprache 1 45 G Geisteswissenschaften 2 47 6 M Naturwissenschaften 48 I 49 E Michael Andriczka DBMS

36 3. Vom Modell zur Datenbank
Codd erkannte das Problem oder möglichen Schwachpunkt der 2NF und entwickelte die 3NF. Eine Relation ist in der dritten Normalform, wenn sie sich in der ersten und in der zweiten Normalform befindet. Ferner sind keine funktionalen Abhängigkeiten zwischen Attributen erlaubt, die nicht als Schlüssel definiert sind. KNr PNr Kurs BereichsNr 44 15 D 1 45 G 2 47 6 M 48 I 49 E BereichsNr Bereich 1 Sprache 2 Geisteswissenschaften 6 Naturwissenschaften Michael Andriczka DBMS

37 3. Vom Modell zur Datenbank
Normalisierte Tabellen: Tabelle Lehrer: Tabelle Kurse: Tabelle Bereich: PNr Vorname Name Straße PLZ Wohnort 15 Hugo Meier Schulstr.1 10124 Berlin 6 Detlef Euler Maiweg 5 54294 Trier KNr PNr Kurs BereichsNr 44 15 D 1 45 G 2 47 6 M 48 I 49 E BereichsNr Bereich 1 Sprache 2 Geisteswissenschaften 6 Naturwissenschaften Michael Andriczka DBMS

38 4. Schlussbetrachtung Jede in der Datenbank gespeicherte Information wird in solchen „einfachen“ Tabellen festgehalten. Eine Tabelle hat immer einen fest strukturierten Aufbau aus Zeilen (Tupeln) und Spalten (Attributen), der einmalig beim Anlegen der Tabelle definiert wird und sich während der gesamten Lebensdauer der Tabelle nur mittels DDL-Befehlen ändern kann. Zur Kommunikation mit dem DBMS wird dem Endbenutzer in der Regel ein Programm zur Verfügung gestellt, welches mit dem DBS kommuniziert. Dieses Anwendungsprogramm bildet die Schnittstelle zwischen dem Benutzer und dem DBMS. Michael Andriczka DBMS