Grund konzept der datenorientierten Modellierung

Grundkonzepte der datenorientierten
Modellierung
1.1
Ein einführendes Beispiel .......................................... 2
1.2
Konventioneller Ansatz .............................................. 5
1.3
Datenbank-orientierter Ansatz ................................... 16
1.4
Probleme beim Tabellenentwurf ................................ 25
1.5
Die Join-Operation ..................................................... 32
1.6
Architektur eines Datenbanksystems ......................... 40
1.7
Datenmodelle als Beschreibungsmittel ...................... 45
Informationssysteme
1
01.10.2010
01.10.2010
LV Informationssysteme
29.11.2010
1
1.1 Ein einführendes Beispiel
(1|3)
•
•
•
•
Das Unternehmen gliedert sich in mehrere Betriebe an
verschiedenen Standorten
(Aholming, Karben, …),
an jedem Standort jedoch nur ein Betrieb.
Jeder Betrieb ist eindeutig einem
Unternehmensbereich zugeordnet.
Zu jedem Betrieb gehören ein oder mehrere Gebäude.
Abteilungen (F&E, Controlling, …) sind immer in einem
Gebäude untergebracht.
Informationssysteme
•
01.10.2010
Ein Unternehmen möchte ein Informationssystem aufbauen.
• Das Unternehmen gliedert sich in mehrere
Unternehmensbereiche (Elektro, Kfz, …).
29.11.2010
2
DB-Grundkonzepte
1
LV Informationssysteme
01.10.2010
1.1 Ein einführendes Beispiel
(2|3)
01.10.2010
Unternehmen
…
F&E
Vertr
…
F&E
Contr
Rewe
Karben (Kfz)
Informationssysteme
Aholming (Elektro)
29.11.2010
3
1.1 Ein einführendes Beispiel
(3|3)
Einer Informationsbedarfsanalyse zufolge sollen folgende Daten
und Zusammenhänge gespeichert werden:
•
Mitarbeiterinnen und Mitarbeiter:
– Personalnummer,
– an welchem Ort und
– in welchem Unternehmensbereich sie/er arbeitet,
01.10.2010
– Name,
– Abteilung,
– Gebäude, in welchem sich der Arbeitsplatz befindet
Standort eines Betriebs:
– die geographischen Koordinaten (für Tourenplanung),
– Straße/Hausnummer, Ortsname und PLZ,
– den Namen des Betriebsleiters,
Informationssysteme
•
– Gehalt.
– die Höhe des Personalbudgets.
29.11.2010
4
DB-Grundkonzepte
2
01.10.2010
Grundkonzepte der datenorientierten
Modellierung
1.1
Ein einführendes Beispiel ...................................................
2
1.2
Konventioneller Ansatz .......................................................
5
1.2.1 Informationssystem in COBOL mit Dateien ...............
6
1.2.2 Änderung des Dateiaufbaus ......................................
8
1.2.3 Redundanz ................................................................
10
1.2.4 Inkonsistenzen ..........................................................
11
1.2.5 Beurteilung des konventionellen Ansatzes ...............
14
1.3
Datenbank-orientierter Ansatz ............................................
16
1.4
Probleme beim Tabellenentwurf .........................................
25
1.5
Die Join-Operation ..............................................................
32
1.6
Architektur eines Datenbanksystems .................................
40
29.11.2010
1.7
Datenmodelle als Beschreibungsmittel ..............................
45
Informationssysteme
1
01.10.2010
LV Informationssysteme
5
1.2.1 Informationssystem in COBOL mit Dateien
(1/2)
Frits
Frans
Lubbe
Enzian
Truhel
Jöndhard
Frits
17
9133
321
17
54
739
17
Aholming
Aholming
Aholming
München
Karben
Karben
Fürth
Elektro
Elektro
Elektro
Mechanik
Kfz
Kfz
Mechanik
F&E
Contr
Vertr
F&E
F&E
F&E
Contr
11
11
8
2
2
2
4
44.000
88.200
38.000
53.000
43.500
45.300
90.000
Informationssysteme
Datei: „PERSONAL“, feste Satzlänge=80 Bytes
Name
PersNr StOrt
UBereich Abt GebNr Gehalt
Länge: 16
8
16
18
10
4
8
01.10.2010
Um die Aufgabe zu lösen, wird von der zentralen EDV-Abteilung ein
COBOL-Programm erstellt, das die geforderten Daten über
Bildschirmmasken abfragt und in die Dateien PERSONAL bzw.
STANDORT schreibt.
29.11.2010
6
DB-Grundkonzepte
3
LV Informationssysteme
01.10.2010
1.2.1 Informationssystem in COBOL mit Dateien
(2/2)
Datei: „STANDORT“, feste Satzlänge=81 Bytes
Straße
Koord
Länge: 12
5
20
15
Leiter PersBudget
20
9
Aholming
94527 Bärengasse 22 48.47N:12.59E
Beutel
560.000
München
81523 Codd-Weg 9
48.07N:11.38E
Schmitz
900.000
Karben
61184 Nusshof 17
50.32N:08.71E
Dieler
120.000
90763 Maierring 109
49.23N:10.61E
Gabler
389.200
Fürth
01.10.2010
PLZ
Informationssysteme
Standort
Im Laufe der Zeit wurden weitere Programme geschrieben, die
„PERSONAL“ und/oder „STANDORT“ benutzen.
29.11.2010
7
1.2.2 Änderung des Dateiaufbaus
(1/2)
Die Aufteilung eines Satzes in Felder sowie die Länge der
einzelnen Datenfelder sind in jedem COBOL-Programm, das die
Datei benutzen soll, genau zu definieren (und damit auch die
Satzlänge eines Datensatzes).
01.10.2010
„File-Descriptor” (FD)
…
FD STANDORT.
05 STANDORT-NAME
PIC X(12).
05 PLZ
PIC 9(05).
05 STRASSE
PIC X(20).
05 KOORDINATEN
PIC X(15).
05 LEITER-NAME
PIC X(20).
05 PERSBUDGET
PIC 9(09).
Informationssysteme
01 STANDORT-SATZ.
…
29.11.2010
8
DB-Grundkonzepte
4
LV Informationssysteme
01.10.2010
1.2.2 Änderung des Dateiaufbaus
(2/2)
Eine Änderung des Dateiaufbaus wie
•
•
Verlängern oder Verkürzen eines Feldes.
Beispiel: In Deutschland wurden 1993 die Postleitzahlen umgestellt
(von 4 auf 5 Stellen)
Entfernen oder Hinzufügen eines Feldes
Beispiel: In die PERSONAL-Datei soll für jeden Mitarbeiter das
Geburtsdatum aufgenommen werden
01.10.2010
•
Veränderung der Anordnung der Felder
(hat zur Folge)
Neuinstallation aller Programme, die auf diese Datei zugreifen.
Aus versäumten Änderungen können
•
•
Absturz des betreffenden Programms und (schlimmer)
falsche Rechenergebnisse resultieren.
Informationssysteme
Änderung der Dateibeschreibung, damit Änderung und
29.11.2010
9
1.2.3 Redundanz
Er kopiert sich aus der Personaldatei PERSONAL (vgl. 1.2.1 (1/2)) die
Sätze aller „F&E”–Mitarbeiter und erstellt daraus die Datei PERSONAL–
FuE. Diese enthält anstelle des Gehaltes ein zusätzliches Feld „Experte”,
das angibt, worin sich der Mitarbeiter besonders gut auskennt:
Datei: „PERSONAL-FuE“, feste Satzlänge=86 Bytes
Länge: 16
Frits
Enzian
Truhel
Jöndhard
PersNr
8
17
17
54
739
StOrt
16
Aholming
München
Karben
Karben
UBereich
18
Elektro
Mechanik
Kfz
Kfz
Abt
10
F&E
F&E
F&E
F&E
GebNr Experte
4
14
11
2
2
2
VLSI
Quanten
Sicherheit
Motor
Ergebnis: Der überwiegende Teil dieser Daten (alle bis auf „Experte“) ist
nun doppelt im Unternehmen vorhanden.
Informationssysteme
Name
01.10.2010
Der Unternehmensvorstand „Forschung und Entwicklung” möchte
zum einfacheren Versenden von Rundschreiben eine Datei aller „F&E”–
Mitarbeiter haben.
Redundanz
29.11.2010
10
DB-Grundkonzepte
5
LV Informationssysteme
01.10.2010
1.2.4 Inkonsistenzen
(1/3)
Unter Umständen werden auch die modifizierten Kopien selbst
wieder weitergegeben.
So entsteht im Unternehmen mit der Zeit eine große Sammlung
unterschiedlicher Abkömmlinge der PERSONAL-Datei:
PERSONAL
01.10.2010
Andere Stellen im Unternehmen kopieren die PERSONAL-Datei
ebenfalls und modifizieren ihre Kopien nach ihren Bedürfnissen.
Informationssysteme
PERSONAL-FuE
29.11.2010
11
1.2.4 Inkonsistenzen
(2/3)
Datei: „PERSONAL“, feste Satzlänge=80 Bytes
Name
PersNr
StOrt
UBereich
Länge: 16
8
16
18
Frits
17
Aholming
Elektro
Frans
9133
Aholming
Elektro
Lubbe
321
Aholming
Elektro
Enzian
17
München
Mechanik
Truhel
54
Karben
Kfz
Jöndhard
739
Karben
Kfz
Frits
17
Fürth
Mechanik
Abt
10
F&E
Contr
Vertr
F&E
F&E
F&E
Contr
GebNr
4
11
11
8
2
2
2
4
Gehalt
8
44.000
88.200
38.000
53.000
43.500
45.300
90.000
01.10.2010
Änderung im Unternehmen:
Herr Truhel aus F&E wird in den Vertrieb versetzt (bei gleichzeitiger
Gehaltserhöhung).
Die Personalabteilung korrigiert die Datei PERSONAL:
Datei: „PERSONAL“, feste Satzlänge=80 Bytes
Name
PersNr
StOrt
UBereich
Länge: 16
8
16
18
Frits
17
Aholming
Elektro
Frans
9133
Aholming
Elektro
Lubbe
321
Aholming
Elektro
Enzian
17
München
Mechanik
Truhel
54
Karben
Kfz
29.11.2010
Jöndhard
739
Karben
Kfz
Frits
17
Fürth
Mechanik
DB-Grundkonzepte
Abt
10
F&E
Contr
Vertr
F&E
Vertr.
F&E
Contr
GebNr
4
11
11
8
2
8
2
4
Gehalt
8
44.000
88.200
38.000
53.000
44.000
45.300
90.000
Informationssysteme
Änderung durch die Personalabteilung
12
6
LV Informationssysteme
01.10.2010
1.2.4 Inkonsistenzen
(3/3)
Folge: Alle von PERSONAL abgeleiteten Dateien enthalten nun
falsche Angaben über Herrn Truhel
Die Konsistent-Haltung aller Abkömmlinge von PERSONAL über
einen längeren Zeitraum ist in der Realität kaum zu gewährleisten.
Informationssysteme
Beispiel: Der F&E-Vorstand (vgl. 1.2.3) wird wohl auch weiterhin
seine Rundschreiben an Herrn Truhels alten Arbeitsplatz schicken.
01.10.2010
Inkonsistenzen.
29.11.2010
13
1.2.5
Beurteilung des konventionellen Ansatzes
(1/2)
Insel-Lösungen
(2) Dateiaufbau gemäß jeweiliger Aufgabenstellung
(ggf. ein einzelnes Anwendungsprogramm funktioniert gut – im
allgemein das zuerst entwickelte / aber:)
01.10.2010
(1) Definition der vom Betriebssystem zu verwaltenden Dateien im
Anwendungsprogramm
- Entweder Änderung des Dateiaufbaus:
Zusätzliche Felder, andere Feld-Definitionen,
andere Organisationsformen erfordern Änderung im
Anwenderprogramm
- oder zusätzliche Datei:
Kann unerwünschte Redundanz bewirken
29.11.2010 Gefahr der Inkonsistenz des Datenbestandes
Informationssysteme
(3) Nutzung der Datei durch andere Programme erschwert,
wenig Flexibilität / 2 Alternativen:
14
DB-Grundkonzepte
7
LV Informationssysteme
1.2.5
01.10.2010
Beurteilung des konventionellen Ansatzes
(2/2)
Programmierung im konventionellen Stil:
Enge Verflechtung zwischen Programm und Daten,
d.h. Programm-Daten-Abhängigkeit
A
D1
(ANGESTELLTEN–DATEI)
B
D2
(ANGESTELLTEN–DATEI-FuE)
D3
(ANGESTELLTEN–DATEI-Vertrieb)
D4
(STANDORT–DATEI)
C
01.10.2010
Datei (physisch)
Informationssysteme
Programm
große Datenredundanz
29.11.2010
15
1.1
Ein einführendes Beispiel ...............................................
2
1.2
Konventioneller Ansatz ....................................................
5
1.3
Datenbank-orientierter Ansatz ......................................... 16
1.3.1
Das Konzept ...................................................... 17
1.3.2
Beurteilung des Datenbank-Ansatzes ............... 24
1.4
Probleme beim Tabellenentwurf ..................................... 25
1.5
Die Join-Operation ............................................................ 32
1.6
Architektur eines Datenbanksystems ................................ 40
1.7
Datenmodelle als Beschreibungsmittel ............................. 45
01.10.2010
Grundkonzepte der datenorientierten
Modellierung
Informationssysteme
1
29.11.2010
16
DB-Grundkonzepte
8
LV Informationssysteme
01.10.2010
1.3.1 Das Konzept
(1/7)
Konzept des Datenbanksystems:
Integration des Datenbestandes, zentrale Verwaltung der Daten;
Trennung von Programm und physischer Datenorganisation:
Datei (logisch)
...
01.10.2010
Anwendungsprogramm
Datenbankmanagementsystem (DBMS)
Informationssysteme
...
Datenbank
(DB)
Datenunabängigkeit
29.11.2010
17
1.3.1 Das Konzept
(2/7)
Datenbanksystem (DBS)
•
Datenbankmanagementsystem (DBMS):
Verwaltung der Datenbank;
Bereitstellung der Daten in der vom Benutzer gewünschten Form
DBS = DBMS + eine oder mehrere DBs
Anwendungsprogramm
...
29.11.2010
DB-Grundkonzepte
01.10.2010
•
Datenbank (DB): (auch Datenbasis; engl. database)
Gesamtheit aller relevanten Daten;
zentral verwaltet
Datei (logisch)
...
Datenbankmanagementsystem (DBMS)
DBS
Datenbank
(DB)
Informationssysteme
•
18
9
LV Informationssysteme
01.10.2010
1.3.1 Das Konzept
(3/7)
Im Beispiel:
Personal- und Standortdaten sollen künftig in einem Datenbanksystem
gehalten werden.
01.10.2010
z.B. relationales System
„Datei“„ Relation“, „Tabelle“
Frits
Frans
Lubbe
Enzian
Truhel
Jöndhard
Frits
17
9133
321
17
54
739
17
Aholming
Aholming
Aholming
München
Karben
Karben
Fürth
UBereich Abt GebNr Gehalt
Elektro
F&E
Elektro Contr
Elektro
Vertr
Mechanik F&E
Kfz
F&E
Kfz
F&E
Mechanik Contr
11
11
8
2
2
2
4
44.000
88.200
38.000
53.000
43.500
45.300
90.000
Informationssysteme
Tabelle: „PERSONAL“
Name
PersNr
StOrt
29.11.2010
19
(4/7)
Tabelle: „STANDORT“
Standort PLZ
Straße
Aholming
München
Karben
Fürth
94527
81523
61184
90763
Bärengasse 22
Codd-Weg 9
Nusshof 17
Maierring 109
Koord
Leiter
PersBudget
48.47N:12.59E
48.07N:11.38E
50.32N:08.71E
49.23N:10.61E
Beutel
Schmitz
Dieler
Gabler
560.000
900.000
120.000
389.200
DBMS kann die Einhaltung von semantischen Integritätsbedingungen
überwachen
01.10.2010
1.3.1 Das Konzept
•
Innerhalb einer Tabellenzeile:
– Wertebereichsangaben (z.B. PLZ muß zwischsen 01000 und 99999
liegen) (statische Bedingung)
– Gehalt eines Angestellten darf bei Änderungen nie kleiner werden
(dynamische Bedingung)
Informationssysteme
Bsp. (für semantische Integritätsbedingungen):
(vgl. auch Geschäftsregeln in 1.1 (1/3))
29.11.2010
20
DB-Grundkonzepte
10
LV Informationssysteme
01.10.2010
1.3.1 Das Konzept
(5/7)
Bsp. (für semantische Integritätsbedingungen):
•
Innerhalb einer Tabelle:
– Je Standort gehören alle Mitarbeiter demselben Unternehmensbereich an.
Tabelle: „PERSONAL“
Name
PersNr
StOrt
17
9133
321
17
54
739
17
UBereich Abt GebNr Gehalt
Aholming
Aholming
Aholming
München
Karben
Karben
Fürth
Elektro
F&E
Elektro Contr
Elektro
Vertr
Mechanik F&E
Kfz
F&E
Kfz
F&E
Mechanik Contr
11
11
8
2
2
2
4
44.000
88.200
38.000
53.000
43.500
45.300
90.000
Informationssysteme
Frits
Frans
Lubbe
Enzian
Truhel
Jöndhard
Frits
01.10.2010
– Alle Angestellten, die am selben Standort in derselben Abteilung arbeiten,
haben ihren Arbeitsplatz im selben Gebäude
29.11.2010
21
1.3.1 Das Konzept
(6/7)
Bsp. (für semantische Integritätsbedingungen):
•
Tabellenübergreifend:
Frits
Frans
Lubbe
Enzian
Truhel
Jöndhard
Frits
17
9133
321
17
54
739
17
Aholming Elektro
Aholming Elektro
Aholming Elektro
München Mechanik
Karben
Kfz
Karben
Kfz
Fürth
Mechanik
F&E
Contr
Vertr
F&E
F&E
F&E
Contr
GebNr Gehalt
11
11
8
2
2
2
4
44.000
88.200
38.000
53.000
43.500
45.300
90.000
Summe
170.200
Summe
88.800
<
<
Tabelle: „STANDORT“
Standort PLZ
Straße
Aholming
München
Karben
Fürth
29.11.2010
Koord
Leiter PersBudget
94527 Bärengasse 22 48.47N:12.59E Beutel
81523 Codd-Weg 9 48.07N:11.38E Schmitz
61184 Nusshof 17 50.32N:08.71E Dieler
90763 Maierring 109 49.23N:10.61E Gabler
560.000
900.000
120.000
389.200
Informationssysteme
Tabelle: „PERSONAL“
Name PersNr StOrt UBereich Abt
01.10.2010
– Die Summe der Gehälter aller Mitarbeiter an einem Standort darf das
Personalbudget dieses Standorts nicht überschreiten
22
DB-Grundkonzepte
11
LV Informationssysteme
01.10.2010
1.3.1 Das Konzept
(7/7)
Bsp. (für semantische Integritätsbedingungen):
•
Tabellenübergreifend:
Frits
Frans
Lubbe
Enzian
Truhel
Jöndhard
Frits
17
9133
321
17
54
739
17
UBereich
Abt
GebNr
Gehalt
Elektro
Elektro
Elektro
Mechanik
Kfz
Kfz
Mechanik
F&E
Contr
Vertr
F&E
F&E
F&E
Contr
11
11
8
2
2
2
4
44.000
88.200
38.000
53.000
43.500
45.300
90.000
Aholming
Aholming
Aholming
München
Karben
Karben
Fürth
Tabelle: „STANDORT“
Standort PLZ
Straße
Aholming
München
Karben
Fürth
94527
81523
61184
90763
Bärengasse 22
Codd-Weg 9
Nusshof 17
Maierring 109
Koord
Leiter
PersBudget
48.47N:12.59E
48.07N:11.38E
50.32N:08.71E
49.23N:10.61E
Beutel
Schmitz
Dieler
Gabler
560.000
900.000
120.000
389.200
–
Angenommen, das Unternehmen hat den Inhalt des PLZ-Buches als neue Tabelle in
seine Datenbank aufgenommen. Dann muß für jede Zeile der Tabelle STANDORT die
29.11.2010 dort angegebene PLZ dieselbe sein, wie sie sich für dieselbe Standort/ StraßenKombination aus der PLZ-Tabelle ergibt.
1.3.2
Informationssysteme
Tabelle: „PERSONAL“
Name PersNr
StOrt
01.10.2010
– In der PERSONAL-Tabelle dürfen nur solche Standorte auftreten, die in
der Tabelle Standort vorkommen
23
Beurteilung des Datenbank-Ansatzes
1. Vermeidung von Redundanz
– Trennung von Programm und Daten, integrierte Verwaltung der Daten,
damit redundante Datenspeicherung vermeidbar (Duplikate nicht
notwendig).
3. Flexibler Gebrauch von Daten
– Daten werden dem Benutzer vom DBMS in der von ihm gewünschten
Form übergeben.
– Neue Anwendungen sind leichter zu implementieren, da
Datenverwaltung nicht auf einzelne Anwendungen zugeschnitten ist.
– Grad der Flexibilität eines DBS allerdings abhängig vom Datenmodell und
den verwendeten Speichertechniken.
4. Sicherung der Integrität
– Integrität der Datenbank: Korrektheit und Vollständigkeit der gespeicherten
Daten;
– zentrale Kontrollmöglichkeit durch spezielle Programme des DBMS.
Informationssysteme
– Zentrale Verwaltung bewirkt aktuellen und gleichen Stand der Daten für
alle Benutzer.
01.10.2010
2. Sicherstellung der Aktualität für alle
29.11.2010
DB-Grundkonzepte
24
12
LV Informationssysteme
1.1
Ein einführendes Beispiel .................................................
2
1.2
Konventioneller Ansatz .....................................................
5
1.3
Datenbank-orientierter Ansatz ..........................................
16
1.4
Probleme beim Tabellenentwurf .....................................
25
1.4.1 Anomalien
...............................................................
26
1.4.2 Zerlegung von Tabellen .............................................
30
1.5
Die Join-Operation
.........................................................
32
1.6
Architektur eines Datenbanksystems ..............................
40
1.7
Datenmodelle als Beschreibungsmittel .............................
45
01.10.2010
Grundkonzepte der datenorientierten
Modellierung
Informationssysteme
1
01.10.2010
29.11.2010
25
(1/4)
Kann man beim Entwurf von Dateien oder insbesondere von Tabellen
für eine Datenbank Fehler machen?
Lösch-Anomalien (deletion anomaly)
Die Vertriebs-Abteilung des Standorts Aholming besteht nur aus einem
Mitarbeiter, Herrn Lubbe. Sie befindet sich im neuen Gebäude 8 des
Betriebs, in dem (noch) keine anderen Abteilungen untergebracht sind.
Herr Lubbe geht nun in den Ruhestand. Die Personalabteilung löscht
seinen Satz aus der PERSONAL-Tabelle:
Frits
Frans
Lubbe
Enzian
Truhel
Jöndhard
Frits
17
9133
321
17
54
739
17
Aholming
Aholming
Aholming
München
Karben
Karben
Fürth
UBereich
Abt
Elektro
Elektro
Elektro
Mechanik
Kfz
Kfz
Mechanik
F&E
Contr
Vertr
F&E
F&E
F&E
Contr
GebNr Gehalt
11
11
8
2
2
2
4
44.000
88.200
38.000
53.000
43.500
45.300
90.000
alle Informationen über das Gebäude 8 sind verschwunden.
Es ging also mehr Information verloren, als erwünscht war (zu den Angaben über
Herrn
Lubbe auch noch die über Gebäude 8).
29.11.2010
Lösch-Anomalie (deletion anomaly).
DB-Grundkonzepte
Informationssysteme
Tabelle: „PERSONAL“
Name PersNr StOrt
01.10.2010
1.4.1 Anomalien
26
13
LV Informationssysteme
01.10.2010
1.4.1 Anomalien
(2/4)
Änderungs-Anomalien (update anomaly)
Am Standort Karben zieht die expandierende
F & E- Abteilung vom Gebäude 2 in das Gebäude 17 um.
Frits
Frans
Lubbe
Enzian
Truhel
Jöndhard
Frits
PersNr
StOrt
17
9133
321
17
54
739
17
Aholming
Aholming
Aholming
München
Karben
Karben
Fürth
UBereich
Elektro
Elektro
Elektro
Mechanik
Kfz
Kfz
Mechanik
Abt
GebNr
Gehalt
F&E
Contr
Vertr
F&E
F&E
F&E
Contr
11
11
8
2
2 17
2 17
4
44.000
88.200
38.000
53.000
43.500
45.300
90.000
Obwohl sich nur ein Sachverhalt geändert hat, müssen mehrere Zeilen in
PERSONAL korrigiert werden.
Wird die Änderung nicht überall ordnungsgemäß durchgeführt, kommt es zu
Inkonsistenzen in der Datenbank.
Informationssysteme
Name
01.10.2010
Tabelle: „PERSONAL“
Änderungs-Anomalie (update anomaly).
29.11.2010
27
1.4.1 Anomalien
(3/4)
Straße
Bärengasse 22
Codd-Weg 9
Nusshof 17
Maierring 109
Delobel-str 9
Koord
48.47N:12.59E
48.07N:11.38E
50.32N:08.71E
49.23N:10.61E
49.01N:08.16E
Leiter
Beutel
Schmitz
Dieler
Gabler
?
PersBudget
560.000
900.000
120.000
389.200
?
Bemerkung:
Informationssysteme
Tabelle: „STANDORT“,
Standort
PLZ
Aholming
94527
München
81523
Karben
61184
Fürth
90763
Jockgrim
76751
01.10.2010
Einfüge-Anomalien (insertion anomaly)
Das Unternehmen hat die Bauerlaubnis zum Aufbau eines Standorts in
Jockgrim erhalten. Aber es existiert kein Betriebsleiter und kein
Personalbudget.
Der neue Standort kann nicht in die STANDORT-Tabelle
übernommen werden.
Bei realen DBMSen könnte der Datenbankverwalter sogenannte Nullwerte (im Sinne von „Wert
29.11.2010 für die beiden letzten Spalten zulassen. Das ändert aber nichts am offenbar für die
unbekannt”)
Aufgabenstellung unpassenden Entwurf der Unternehmensdatenbank.
28
Obwohl die Informationen über Lage und Adresse des Standorts auch für sich
genommen Sinn machen würden, können sie nicht aufgenommen werden, da andere,
zu diesem Zeitpunkt noch uninteressante Angaben (Leiter/PersBudget) fehlen.
Einfüge-Anomalie (insertion anomaly)
DB-Grundkonzepte
14
LV Informationssysteme
01.10.2010
1.4.1 Anomalien
(4/4)
Kritik am Tabellenentwurf
•
Redundanz
Beispiel:
– An jedem Standort ist genau ein Unternehmensbereich
angesiedelt.
– Es ist daher unnötig, in der Tabelle PERSONAL in jeder Zeile mit
„StOrt” auch „UBereich” abzuspeichern.
01.10.2010
Offenbar weist der Entwurf der Unternehmensdatenbank mit 2 Tabellen
PERSONAL und STANDORT einige Mängel auf:
Alternativen:
•
Informationssysteme
– Extratabelle mit der Zuordnung
“Standort – Unternehmensbereich”.
– Verlagerung der Information “UBereich” in die Tabelle
STANDORT.
Anomalien
Es treten – wie obige Beispiele zeigen – Einfüge-, Lösch- und
29.11.2010
Änderungsanomalien auf.
29
1.4.2 Zerlegung von Tabellen
(1/2)
PLZ
ANSCHRIFT
StOrt PLZ
Straße
Strasse
Koord
Leiter
PersBudget
GEODATEN
StOrt
Koord
LEITUNG
StOrt
Leiter PersBudget
Die Werte der Spalte “StOrt” identifizieren die zugehörigen Zeilen in allen
o.a.Tabellen eindeutig und dienen so als “Bindeglied” zwischen den Tabellen
ANSCHRIFT,
LEITUNG und GEODATEN.
29.11.2010
Informationssysteme
STANDORT
Standort
01.10.2010
Beispiel 1-1:
Um den neuen Standort Jockgrim doch schon in die
Unternehmensdatenbank aufnehmen zu können, schlägt die EDVAbteilung eine Zerlegung der Tabelle STANDORT vor:
30
DB-Grundkonzepte
15
LV Informationssysteme
01.10.2010
1.4.2 Zerlegung von Tabellen
(2/2)
•
Der Standort Jockgrim kann nun in die Tabellen „ANSCHRIFT” und
(unabhängig davon) „GEODATEN” aufgenommen werden.
•
Die Zeile mit den Angaben „Leiter” und „PersBudget” wird in
„LEITUNG” eingetragen, sobald diese Daten vorliegen.
01.10.2010
Resultat:
STANDORT
Standort
PLZ
...
Jockgrim
...
ANSCHRIFT
StOrt
PLZ
...
Jockgrim
...
29.11.2010
...
Delobel-str 9
...
Koord
Leiter
PersBudget
...
49.01N:08.16E
...
...
?
...
...
?
...
GEODATEN
StOrt
Strasse
...
...
76751 Delobel-str 9
...
...
...
Jockgrim
...
LEITUNG
StOrt
...
Leiter
PersBudget
...
...
Koord
...
49.01N:08.16E
...
31
1.1
Ein einführendes Beispiel .................................................
2
1.2
Konventioneller Ansatz .....................................................
5
1.3
Datenbank-orientierter Ansatz ..........................................
16
1.4
Probleme beim Tabellenentwurf .....................................
25
1.5
Die Join-Operation
.........................................................
32
1.6
Architektur eines Datenbanksystems ..............................
40
1.7
Datenmodelle als Beschreibungsmittel .............................
45
01.10.2010
Grundkonzepte der datenorientierten
Modellierung
Informationssysteme
1
Straße
...
76751
...
Informationssysteme
Die Einfüge-Anomalie (vgl. 1.4.1 (3/4)) ist damit beseitigt.
29.11.2010
32
DB-Grundkonzepte
16
LV Informationssysteme
01.10.2010
1.5 Die Join-Operation
(1|7)
In STANDORT war es möglich, zu einem Standort gleich die Adresse und den
Namen des Leiters herauszufinden.
Karben
Jockgrim
München
Aholming
Strasse
61184
Nusshof 17
76751
Delobel-str 9
81523 Maierring 109
94527 Bärengasse 22
LEITUNG
StOrt
Leiter
PersBudget
Aholming
München
Karben
Fürth
Beutel
Schmitz
Dieler
Gabler
560.000
900.000
120.000
389.200
(=Join)
Ergebnistabelle von ANSCHRIFT LEITUNG
StOrt
PLZ
Straße
Aholming
München
Karben
94527
81523
61184
Bärengasse 22
Maierring 109
Nusshof 17
Leiter
PersBudget
Beutel
Schmitz
Dieler
560.000
900.000
120.000
Informationssysteme
ANSCHRIFT
StOrt
PLZ
01.10.2010
Um eine ähnliche Übersicht aus den drei neuen, kleineren Tabellen zu erhalten,
müssen Paare von Zeilen aus ANSCHRIFT und LEITUNG, welche gleiche „StOrt”Werte haben, zusammengeführt werden:
Diese Zusammenführungsoperation der beiden Tabellen entlang einer (oder
mehrerer) Spalte(n) gleichen Namens (hier: „StOrt”) bezeichnet man auch als
(natürlichen)
Join der beiden Tabellen (in Zeichen ).
29.11.2010
33
1.5 Die Join-Operation
(2|7)
Kommen bestimmte Spaltenwerte in einer oder beiden der
zusammenzuführenden Tabellen mehrfach vor, so enthält das Ergebnis der
Join-Operation alle Kombinationen der betreffenden Zeilen.
PERSONAL
Name
PersNr
...
Truhel
Jöndhard
...
...
54
739
...
PERSONAL
Name
...
Truhel
Jöndhard
...
ANSCHRIFT
StOrt
UBereich
...
Karben
Karben
...
...
...
...
...
ANSCHRIFT
PersNr
...
54
739
...
ANSCHRIFT
StOrt
PLZ
Karben
Jockgrim
München
Aholming
Strasse
61184
76751
81523
94527
Nusshof 17
...
...
...
StOrt
UBereich
PLZ
Strasse
...
Karben
Karben
...
...
...
...
...
61184
61184
Nusshof 17
Nusshof 17
Informationssysteme
Lösung: Bilde PERSONAL
01.10.2010
Beispiel 1-2: Ähnlich wie oben soll eine Tabelle erstellt werden mit allen
augenblicklichen Mitarbeitern und deren Firmenadresse.
29.11.2010
34
DB-Grundkonzepte
17
LV Informationssysteme
01.10.2010
1.5 Die Join-Operation
(3|7)
Tabellen ohne gemeinsame Spaltennamen:
Join = kartesisches Produkt
(Alle Zeilen der einen werden mit allen Zeilen der anderer Tabelle
B
C
1
2
1
3
1
3
( =kartesische
Produkt)
Tabelle1 Tabelle 2
A
B
C
1
1
2
2
1
1
3
3
1
1
3
3
Tabelle 2
D
1
2
D
1
2
1
2
1
2
E
1
2
E
1
2
1
2
1
2
Informationssysteme
Tabelle 1
A
01.10.2010
kombiniert)
29.11.2010
Animation
aus Vikar
35
1.5 Die Join-Operation
(4|7)
Informationen wie
Wie ist die Adresse des Werksleiters „Schmitz”
konnten direkt aus der Tabelle STANDORT abgelesen werden.
Frage:
Ist die Zerlegung der Tabelle STANDORT in die drei Tabellen
ANSCHRIFT, GEODATEN und LEITUNG verlustfrei,
das heißt:
Kann man durch „Joinen” (aller drei „kleineren“ Tabellen) die
ursprüngliche Tabelle genau rekonstruieren?
STANDORT
Standort
ANSCHRIFT
StOrt
PLZ
29.11.2010
PLZ
Strasse
Straße
?
LEITUNG
StOrt
Leiter
Koord
Leiter
PersBudget
PersBudget
01.10.2010
•
Welches Personalbudget hat der Standort mit den
Koordinaten 50.32N:08:71E?
Informationssysteme
•
GEODATEN
StOrt
Koord
36
DB-Grundkonzepte
18
LV Informationssysteme
01.10.2010
1.5 Die Join-Operation
(5|7)
1. Schritt: Bilde ANSCHRIFT GEODATEN
Aholming
München
Karben
Fürth
94527
81523
61184
90763
Bärengasse 22
Coddweg 9
Nusshof 17
Maierring 109
Koord
48.47N:12.59E
48.07N:11.38E
50.32N:08.71E
49.23N:10.61E
01.10.2010
Ergebnistabelle von ANSCHRIFT GEODATEN
StOrt
PLZ
Straße
2. Schritt: Bilde (ANSCHRIFT GEODATEN) LEITUNG
Leiter
PersBuget
Beutel
Schmitz
Dieler
Gabler
560.000
900.000
120.000
389.200
Informationssysteme
Ergebnistabelle von (ANSCHRIFT GEODATEN) LEITUNG
StOrt
PLZ
Straße
Koord
Aholming
94527
Bärengasse 22
48.47N:12.59E
München
81523
Coddweg 9
48.07N:11.38E
Karben
61184
Nusshof 17
50.32N:08.71E
Fürth
90763
Maierring 109
49.23N:10.61E
Das Ergebnis stimmt mit der Tabelle STANDORT überein, die Zerlegung
29.11.2010
ist „verlustfrei“.
37
1.5 Die Join-Operation
(6|7)
Neues Problem: Die Personalabteilung soll nun Mitarbeiter auch dann
schon in die Datenbank aufnehmen können, wenn noch nicht bekannt ist,
in welcher Abteilung eines Standorts sie eingesetzt werden sollen.
MITARBEITER
Name PersNr
StOrt
StOrt
UBereich
UBereich
Gehalt
Abt
GebNr
Gehalt
ARBEITSPLATZ
Name
Abt GebNr
Ist dies eine verlustfreie Zerlegung von PERSONAL?
sind also alle Informationen aus PERSONAL im Ergebnis von
MITARBEITER ARBEITSPLATZ enthalten (… und keine anderen)?
Informationssysteme
PERSONAL
Name
PersNr
01.10.2010
Um Einfüge-Anomalien zu vermeiden, wird die Tabelle PERSONAL in
folgender Weise zerlegt:
29.11.2010
38
DB-Grundkonzepte
19
LV Informationssysteme
01.10.2010
1.5 Die Join-Operation
17
9133
321
17
54
739
17
Aholming
Aholming
Aholming
München
Karben
Karben
Fürth
MITARBEITER
Name
PersNr
Frits
Frits
Frans
Lubbe
Enzian
Truhel
Jöndhard
Frits
Frits
17
17
9133
321
17
54
739
17
17
UBereich
Elektro
Elektro
Elektro
Mechanik
Kfz
Kfz
Mechanik
StOrt
Aholming
Aholming
Aholming
Aholming
München
Karben
Karben
Fürth
Fürth
Gehalt
ARBEITSPLATZ
Name
Abt
44.000
88.200
38.000
53.000
43.500
45.300
90.000
Frits
Frans
Lubbe
Enzian
Truhel
Jöndhard
Frits
UBereich
Elektro
Elektro
Elektro
Elektro
Mechanik
Kfz
Kfz
Mechanik
Mechanik
GebNr
F&E
Contr
Vertr
F&E
F&E
F&E
Contr
Gehalt
Abt
44.000
44.000
88.200
38.000
53.000
43.500
45.300
90.000
90.000
F&E
Contr
Contr
Vertr
F&E
F&E
F&E
F&E
Contr
11
11
8
2
2
2
4
01.10.2010
Frits
Frans
Lubbe
Enzian
Truhel
Jöndhard
Frits
StOrt
GebNr
11
4
11
8
2
2
2
11
4
Informationssysteme
MITARBEITER
Name
PersNr
(7|7)
keine verlustfreie Zerlegung von PERSONAL, da hier auf einmal jeweils zwei
Mitarbeiter „Frits” in Aholming und Fürth auftauchen.
29.11.2010
39
1.1 Ein einführendes Beispiel ...............................................
2
1.2 Konventioneller Ansatz ..................................................
5
1.3 Datenbank-orientierter Ansatz .........................................
16
1.4 Probleme beim Tabellenentwurf .....................................
25
1.5 Die Join-Operation ..........................................................
32
1.6 Architektur eines Datenbanksystems ..............................
40
1.6.1 Grundfunktionen eines DBMS ................................
41
1.6.2 Drei-Ebenen-Architektur .........................................
42
1.7 Datenmodelle als Beschreibungsmittel ............................
45
01.10.2010
Grundkonzepte der datenorientierten
Modellierung
Informationssysteme
1
29.11.2010
40
DB-Grundkonzepte
20
LV Informationssysteme
01.10.2010
1.6.1 Grundfunktionen eines DBMS
Grundfunktionen
•
Beschreibung der Daten mittels eines Datenmodells
auf unterschiedlichen Ebenen
zur Erreichung von Datenunabhängigkeit und Datenintegrität.
Benutzerschnittstellen zur flexiblen Auswertbarkeit:
01.10.2010
•
Bereitstellung mächtiger Benutzerschnittstellen,
die auf unterschiedliche Anwender zugeschnitten sind.
•
Transaktionsmanagement
zur Mehrbenutzerverwaltung und als Grundlage für Recovery.
•
Recovery zur Wiederherstellung der Integrität im Fehlerfall.
Informationssysteme
Zusatzfunktionen
– Datenschutz (Zugriffssicherung)
– Data Dictionary
(Kataloge/Inhaltsverzeichnisse u. ä)
– Entwicklungswerkzeuge
29.11.2010
41
1.6.2 Drei-Ebenen-Architektur
(1|3)
Ein DBMS hat Aufgaben auf drei Ebenen zu erfüllen:
(siehe Abb. auf der nächsten Seite)
Konzeptuelle (logische) Ebene
– Es (das DBMS) muß die Zusammenhänge der Daten
darstellen können;
•
Benutzerebene (externe) Ebene
01.10.2010
•
•
Physische (interne) Ebene
– es muß die Daten auf Speichermedien verwalten.
Ziel der Drei-Ebenen-Architektur ist die Datenunabhängigkeit.
Informationssysteme
– es muß die Daten "aufbereitet" dem Benutzer auf
verschiedene Art und Weise präsentieren
(Benutzersichten);
29.11.2010
42
DB-Grundkonzepte
21
LV Informationssysteme
01.10.2010
1.6.2 Drei-Ebenen-Architektur
(2|3)
Bes chreibung der Daten
• auf jeder Ebene
•
•
in einem eigenen Schema
01.10.2010
nach den Regeln eines Datenmodells
Ebenenhierarchie (ANSI/SPARC-Architektur)
externe
Ebene
externe
Sicht
externe
Sicht
...
externe
Sicht
konzeptuelle
Ebene
Informationssysteme
Transformation
konzeptuelles Schema
Transformation
interne
Ebene
29.11.2010
internes Schema
43
1.6.2 Drei-Ebenen-Architektur
•
(3|3)
Konzeptuelles (logisches) Schema
– Beschreibung der Daten des Unternehmens auf logischer Ebene
•
Externe Schemata bzw. Sichten
– Ausschnitt aus konzeptuellem Schema für eine spezielle Anwendung:
Benutzersicht (View)
•
•
•
Internes Schema: Diese Ebene beschäftigt sich mit der rein
physikalischen Struktur der Datenbank (Zugriffspfade/Rechte). Auf die
interne Ebene besteht normalerweise selbst für den Datenbankadministrator kein direkter Zugriff. Sie wird allein vom DBMS verwaltet.
Jeweils dazwischen: Transformationsregeln
Die Schemata sind nur Beschreibungen der Daten;
die eigentlichen Daten existieren nur einmal, nämlich auf der physischen
Ebene.
Informationssysteme
– (Konzeptuelles Schema=) Modell des Unternehmens nach Analyse
aufgrund von Abstraktion und Klassenbildung
01.10.2010
– unabhängig von Gesichtspunkten der Verarbeitung (Zugriffsart,
Verarbeitungsreihenfolge)
29.11.2010
44
DB-Grundkonzepte
22
LV Informationssysteme
Grundkonzepte der datenorientierten
Modellierung
1.1 Ein einführendes Beispiel ....................................................
2
1.2 Konventioneller Ansatz ........................................................
5
1.3 Datenbank-orientierter Ansatz
1.4 Probleme beim Tabellenentwurf
........................................ 16
..................................... 25
1.5 Die Join-Operation ............................................................... 32
01.10.2010
1
01.10.2010
1.6 Architektur eines Datenbanksystems ................................... 40
1.7.1
Realwelt und Modell ........................................... 46
1.7.2
Die klassischen Datenmodelle ........................... 49
1.7.3
Semantische Datenmodelle ................................ 50
Informationssysteme
1.7 Datenmodelle als Beschreibungsmittel ................................ 45
29.11.2010
45
1.7.1 Realwelt und Modell
(1|3)
(1) Informationen über Objekte
•
Objekte
– Personen (Kunden, Mitarbeiter)
– andere Dinge (Artikel, Maschinen)
– ...
•
Objekttyp / Objektmenge
01.10.2010
– Ereignisse
– gleichartige Dinge (Kunden; Angestellte; Artikel; ...)
Bsp.:
Artikel:
Kunde:
Artikel-Nr, Bezeichnung, ...
Kunden-Nr, Name, Anschrift, ...
•
Objekt - Attributwerte
•
Schlüsselattribute
Bsp.:
Spezielle Artikel:
2317, Seife, ...
Informationssysteme
– Beschreibung durch Attribute (Eigenschaften)
– eindeutige Identifizierbarkeit innerhalb des Objekttyps
29.11.2010
46
DB-Grundkonzepte
23
LV Informationssysteme
01.10.2010
1.7.1 Realwelt und Modell
(2|3)
(2) Informationen über Zusammenhänge/ Beziehungen zwischen
Objekten
(gleichen oder verschiedenen Typs)
•
Beziehung
01.10.2010
Bsp.:
– Die Angestellten X,Y gehören zur Abteilung U
– Kunde M hat Artikel A, B bestellt
•
„Typ-Bildung“
Informationssysteme
– Beziehungstyp
– besteht zwischen Objekttypen
29.11.2010
47
1.7.1 Realwelt und Modell
(3|3)
Bemerkung: Folgende Dinge sind möglich:
Attribute von Beziehungen
Bsp.:
Stückliste : Bauteil
Bauteil
(übergeordnet
untergeordnet)
Mehr als 1 Beziehung zwischen denselben Objekttypen
Bsp.:
•
Abteilung
Abteilung
Angestellte (Zugehörigkeit)
Angestellte (Abt.-Leiter)
Beziehungen zwischen mehr als 2 Objekttypen
Bsp.:
Projekt
Bauteil
Lieferant
(3) Information über dynamische Aspekte
•
•
Preis
Menge
Beziehungen zwischen Objekten desselben Typs
Bsp.:
•
Lieferant :
Material :
01.10.2010
•
Teil
Auftrag
Prozesse,
Abläufe
(wichtig, wird aber hier nicht behandelt.)
Informationssysteme
•
29.11.2010
DB-Grundkonzepte
48
24
LV Informationssysteme
01.10.2010
Modell
Hierarchisch:
Netzwerk:
(CODASYL)
29.11.2010
Inverted
Vertreiber
IBM
System 2000
MRI/SAS Institute
IDMS
UDS
DMS 1100
TOTAL
Cullinet
Siemens
Sperry
CINCOM
DB2
IBM
CA-OpenIngres
Computer Associates
ORACLE
ORACLE Corp.
INFORMIX
Informix Software
Rdb/VMS
DEC
SQL-Server
Microsoft
SYBASE
Sybase
ADABAS-D
Software AG
u.v.a.m.
SQL als (standardisierte) Sprache
List:
ADABAS
Software AG
DATACOM/DB
Applier/Data Research
1.7.3 Semantische Datenmodelle
Informationssysteme
Relational:
System
IMS
01.10.2010
1.7.2 Die klassischen Datenmodelle
49
(1|2)
Ziel
möglichst viel Semantik
viele Abstraktionstechniken
einfache Konstrukte
Bsp.:
Entity-Relationship-Modell
(ERM)
Semantisch-Hierarchisches Modell (SHM)
Implementierungen bisher meist nur zu
01.10.2010
•
•
•
– Forschungszwecken oder als
– Entwicklungswerkzeuge in DBMS oder sonstigen CASE-Tools
•
•
zur Modellierung beim Datenbank-Entwurf
als Vergleichsbasis für die klassischen Modelle
Gut geeignet: Entity-Relationship-Modell
Neuere Entwicklung:
•
Datenbanken
29.11.2010
DB-Grundkonzepte
Datenmodell
Informationssysteme
(i.d.R. mit wesentlichen Einschränkungen)
Modelle werden im Allgemeinen verwendet
mit objekt-orientiertem/ objekt-relationalem
50
25
LV Informationssysteme
01.10.2010
1.7.3 Semantische Datenmodelle
Konzeptuelles
Schema
E/R-Modell (o.ä.)
Implementierungsunabhängig;
Ziel: Aufnahme in
existierende
Datenbanksysteme
logisches
Schema
01.10.2010
Reale
Welt
ext.
Schema/Sicht
Physische
Ebene
Implementierungsabhängig;
existierendes DBS
Informationssysteme
Modellierungsprozess
(2|2)
29.11.2010
51
DB-Grundkonzepte
26