DBMS - Hochschule Trier

Vorlesung DBMS
Thema:
Datenbanktechnologie
- Von der Realwelt zur Datenbank -
Michael Andriczka
Sommersemester 2003
Michael Andriczka
DBMS
1
Inhalt
1. 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
2. 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
2
Inhalt
3. Vom Modell zur Datenbank
3.1
Umsetzung des ER-Modells in das relationale Datenbankschema
3.2
Normalisierung
4.
Schlussbetrachtung
Michael Andriczka
DBMS
3
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
4
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
5
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
6
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
7
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.
1. Einleitung
DB: Strukturierter, von DBMS verwalteter Datenbestand
DBS: Datenbanksystem (DBMS + Datenbank)
DBMS: Datenbank-Management-System
Michael Andriczka
DBMS
9
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
10
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 Programmiersprachen
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
11
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
12
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;
50.000 Anfragen pro Wochen
US Libary of Congress 10-20 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
13
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 200.000 Rechnungen, 12.000 Mahnungen,
10.000 Änderungen von Kundendaten pro Tag
- bis zu jeweils 1000 Nutzer gleichzeitig
Über 13.000 Datenbanktabellen
Michael Andriczka
DBMS
14
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
15
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
16
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 zugeordnet, 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
17
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.
KUNDE
Die Entität (Entity) ist also das konkrete, individuell identifizierbare Objekt
bzw. Exemplar von Dingen, Personen oder Begriffen der realen oder
der Vorstellungswelt.
Michael Andriczka
DBMS
18
2. Von der Realwelt zum ER-Modell
Beispiele:
Individuen:
Reales Objekt:
Ereignis:
Abstraktes:
Mitarbeiterin Brecht, Student Weber, Kunde Meier
Maschine 2, Raum 7, Artikel 4711....
Zahlung, Buchung, Mahnung, Start, Landung.....
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
19
2. Von der Realwelt zum ER-Modell
2.3 Attribute
Attribute beschreiben die Entitäten.
Beispiel: Kunde (KdNr, KName, KAdresse,...)
KdNr
KUNDE
KName
Man unterscheidet zwischen
• identifizierenden Attributen, sog. Schlüssel (z.B.: KdNr, FirmenNr, PersNr...)
• beschreibenden Attributen (z.B.: KName, MitarbeiterName, ArtikelBez, ... )
Michael Andriczka
DBMS
20
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
21
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
KNr
PNr
Kurs
Primärschlüssel
BereichsNr
BereichsNr
Bereich
44
15
D
1
1
Sprache
45
15
G
2
2
Geisteswissenschaften
47
6
M
6
6
Naturwissenschaften
48
6
I
6
49
6
E
1
Michael Andriczka
Referentielle Integrität
DBMS
22
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
23
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
KUNDE
1
gibt auf
n
BESTELLUNG
Man liest: KUNDE gibt auf Bestellungen bzw. Bestellungen werden
aufgegeben von Kunde.
Michael Andriczka
DBMS
24
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:
Bestellung:
Artikel:
Michael Andriczka
alle Kunden, die Bestellungen aufgeben
die offenen Bestellungen der Kunden
alle lieferbaren Artikel
DBMS
25
2. Von der Realwelt zum ER-Modell
ER-Modell:
KdNr
KUNDE
KName
1
gibt auf
n
BestellNr
BESTELLUNG
n
Bestellposition
n
ArtikelNr
Datum
Menge
Bez
ARTIKEL
Preis
Michael Andriczka
DBMS
26
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
27
3. Vom Modell zur Datenbank
KUNDE :
BESTELLUNG :
BESTELLPOSITION :
ARTIKEL :
{KdNr, KName}
{BestellNr, Datum, KdNr}
{BestellNr, ArtikelNr, Menge}
{ArtikelNr, Bez, Preis}
ER-Modell
Entity = Objekt
Relationship = Beziehung
Entität
KUNDE
Relationales Modell
Relation = zweidimensionale
Tabelle
Schlüsselattribut
Entität
KUNDE
KdNr
KdNr
KName
Michael Andriczka
Schlüsselattribut
DBMS
KName
001112
Meier
001535
Schulz
28
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
29
3. Vom Modell zur Datenbank
3.2.1 0.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
15
Hugo
6
Detlef
Michael Andriczka
Name
Straße
PLZ
Wohnort
KNr
Kurs
Meier
Schulstr.1
10124
Berlin
44,
D,
G
Euler
Maiweg 5
54294
Trier
47,
49
M,
I,
E
DBMS
30
3. Vom Modell zur Datenbank
3.2.2 1.Normalform
Eine Relation ist in der ersten Normalform, wenn alle Attribute nur atomare
Werte beinhalten.
PNr
Vorname
15
Hugo
15
Name
Straße
PLZ
Wohnort
KNr
Kurs
Meier
Schulstr.1
10124
Berlin
44
D
Hugo
Meier
Schulstr.1
10124
Berlin
45
G
6
Detlef
Euler
Maiweg 5
54294
Trier
47
M
6
Detlef
Euler
Maiweg 5
54294
Trier
48
I
6
Detlef
Euler
Maiweg 5
54294
Trier
49
E
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.
Michael Andriczka
DBMS
31
3. Vom Modell zur Datenbank
3.2.3 2.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.
PNr
Vorname
Name
Straße
PLZ
Wohnort
KNr
Kurs
15
Hugo
Meier
Schulstr.1
15
Hugo
Meier
6
Detlef
6
6
Bereich
10124
Berlin
44
D
Sprache
Schulstr.1
10124
Berlin
45
G
Geisteswissenschaften
Euler
Maiweg 5
54294
Trier
47
M
Naturwissenschaften
Detlef
Euler
Maiweg 5
54294
Trier
48
I
Naturwissenschaften
Detlef
Euler
Maiweg 5
54294
Trier
49
E
Sprache
Vermeidung der Anomalien der 1NF durch Aufteilung der Entitäten in
seperate Tabellen.
Michael Andriczka
DBMS
32
3. Vom Modell zur Datenbank
Tabelle Lehrer
PNr
Vorname
15
Hugo
6
Detlef
Name
Straße
PLZ
Wohnort
Meier
Schulstr.1
10124
Berlin
Euler
Maiweg 5
54294
Trier
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
KNr
Kurs
Bereich
44
D
Sprache
45
G
Geisteswissenschaften
47
M
Naturwissenschaften
48
I
Naturwissenschaften
49
E
Sprache
Michael Andriczka
DBMS
33
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.
KNr
Kurs
Bereich
PNr
44
D
Sprache
15
45
G
Geisteswissenschaften
15
47
M
Naturwissenschaften
6
48
I
Naturwissenschaften
6
49
E
Sprache
6
PNr wurde zur Herstellung der referentiellen Integrität als Fremdschlüssel
in die Tabelle Kurse eingefügt.
Michael Andriczka
DBMS
34
3. Vom Modell zur Datenbank
3.2.4 3.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
KNr
PNr
Kurs
Bereich
BereichsNr
44
15
D
Sprache
1
45
15
G
Geisteswissenschaften
2
47
6
M
Naturwissenschaften
6
48
6
I
Naturwissenschaften
6
49
6
E
Sprache
1
Transitive Abhängigkeit: Abhängigkeit zwischen nicht Schlüsselattributen
Michael Andriczka
DBMS
35
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
BereichsNr
Bereich
44
15
D
1
1
Sprache
45
15
G
2
2
Geisteswissenschaften
47
6
M
6
6
Naturwissenschaften
48
6
I
6
49
6
E
1
Michael Andriczka
DBMS
36
3. Vom Modell zur Datenbank
3.2.5 Normalisierte Tabellen:
Tabelle Lehrer:
PNr Vorname
Tabelle Kurse:
Tabelle Bereich:
Michael Andriczka
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
15
G
2
47
6
M
6
48
6
I
6
49
6
E
1
BereichsNr
Bereich
1
Sprache
2
Geisteswissenschaften
6
Naturwissenschaften
DBMS
37
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
38