Sie sind auf Seite 1von 57

Informationssysteme

2Manfred2Reichert,2Peter2Dadam |2SS220152|2Universitt Ulm

Seite22

Kapitel 3:2Datenbankbasierte
Implementierung von2Informationssystemen

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

Inhalt

Vorbemerkungen

Beispielfirma LegoTrailer AG

Entwurf des2Datenbankschemas

Implementierung von2Anwendungsfunktionen

Konsistenthaltungsaspekte

Transaktionale Aspekte und2Mehrbenutzerbetrieb

Weiterfhrende Anforderungen an2betriebliche Informationssysteme

Abschlieende Bemerkungen
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite23

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.1*Vorbemerkungen
Lernziele
! Auffrischung2und2Anwendung2 der2Kenntnisse2bzgl.2SQL2und2Datenbankentwurf
! Vermittlung2von2Einblicken2in2die2Funktionalitt2sowie2Realisierung2betrieblicher2
Informationssysteme
! 2insbesondere2Heranfhren2an2nichtZtriviale2Relationenschemata
! Einblicke2in2Implementierungsvarianten2fr2die2Interaktion2von2AnwendungsZ
funktionen2mit2dem2DBMS2und2deren2VorZ und2Nachteile
! Motivation2und2Anwendungsbeispiele2 fr2weiterfhrende2SQLZFunktionalitten\
! 2insbesondere2Realisierung2nichtZtrivialer,2SQLZbasierter2Anwendungsfunktionen
! Vermittlung2von2Grundkenntnissen2in2Bezug2auf2Synchronisation2und2Recovery
! Und*ganz*wesentlich:*
! Studieren*Sie*sorgfltig*die*Anwendungsbeispiele* und*lernen*Sie*
darausB*sie*sind*integraler*Teil*der*Vorlesung!
! Wenden*Sie*die*erworbenen*Kenntnisse* im*Rahmen*der*bungen* und*
Selbststudium*eigenstndig* praktisch*an.** Es*lohnt*sich!

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite24

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.1*Vorbemerkungen
Studienobjekt
! Zum2Erreichen2dieser2Lernziele2werden2wir2im2Folgenden2 exemplarisch2ein2
(einfaches)2ERPZSystem2fr2die2LegoTrailer AG entwerfen
! Ausgehend2 von2einer2Anforderungsanalyse2werden2wir2die2zu2realisierenden2
Anwendungsfunktionen und2die2Entities fr2den2Datenbankentwurf
identifizieren
! 2und2deren2Realisierungsvarianten2diskutieren
! Abschlieend2werden2wir2die2praktische2Tauglichkeit2der2gewhlten2ERPZ
Realisierung2diskutieren2und2ggf.2nderungsZ bzw.2Erweiterungsvorschlge2
entwickeln
! Die2(auszugsweise)2Realisierung2des2ERPZSystems2sowie2dessen2Erweiterungen2
bzw.2alternative2Implementierungen2 werden2wir2teils2in2der2Vorlesung,2teils2in2den2
bungen2 vornehmen

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite25

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

Inhalt

Vorbemerkungen

Beispielfirma LegoTrailer AG

Entwurf des2Datenbankschemas

Implementierung von2Anwendungsfunktionen

Konsistenthaltungsaspekte

Transaktionale Aspekte und2Mehrbenutzerbetrieb

Weiterfhrende Anforderungen an2betriebliche Informationssysteme

Abschlieende Bemerkungen
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite26

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.2*Beispielfirma*LegoTrailer AG
Inhalt
3.2.1
3.2.2

Produkte,2Einzelteile2und2deren2Verwendung
Anforderungen2an2das2ERPZSystem

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite27

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.2.1**Produkte,*Einzelteile*und*deren*Verwendung
! Die2LegoTrailer AG vertreibt2aus2Legobausteinen2 hergestellte2LkwZ
Anhnger,2 und2zwar2als2Ganzes2sowie2auch2einige2Halbfabrikate
! Die2Produkte gibt2es2in2den2Farben rot und2blau
! Dem2entsprechend2gibt2es2auch2einige2Einzelteile in2rot und2blau,2einige2
jedoch2nur2in2einer2Standardfarbe
! Die2auf2den2nchsten2Folien2unter2Produkte dargestellten2sind2
Endprodukte und2Halbfabrikate,2welche2die2Firma2vertreibt
! Die2anderen,2unter2Einzelteile gelisteten2Artikel2dienen2 nur2zur2
Herstellung2der2Produkte2und2werden2nicht2einzeln2vertrieben
! Fr2die2Produkte gibt2es2eine2Preisliste*(fr2die2anderen2 nicht)
! Fr2alle*Artikel (Endprodukte,2Halbfabrikate2und2Einzelteile)2gibt2es2
kalkulatorische* Kosten,2welche2die2Basis2fr2die2interne2PreisZ und2
Kostenkalkulation2sind,2sowie2einen2definierten2Mindestbestand\2
auerdem knnen2Artikel2fr2in2Bearbeitung2befindliche2Auftrge2
reserviert sein

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite28

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.2.1*Beispielfirma*LegoTrailer AG* Produkte*

AAG

(Aufbauanhnger2geschlossen)

AKK

(Kippanhnger2kurz)

AKL

(Kippanhnger2lang)

Diese2Produkte
gibt2es2in2rot (Farbcode =*1)
und2in2blau (Farbcode =*2)

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite29

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.2.1*Beispielfirma*LegoTrailer AG* Produkte*

CAH

CKK

(Chassis2Aufbauanhnger)

(Chassis2Kippanhnger2kurz)

FG

(Fahrgestell)

CKL

Diese2Produkte
gibt2es2in2rot (Farbcode =*1)
und2in2blau (Farbcode =*2)

(Chassis2Kippanhnger2lang)

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite210

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.2.1*Beispielfirma*LegoTrailer AG* Einzelteile


Diese2Einzelteile2gibt2es2teilweise2nur2in2neutraler2Ausfhrung2(Farbcode2=20),
teilweise2aber2auch2in2rot2(Farbcode2=21)2und2blau2(Farbcode2=22)

RF

(Reifen)

K28

(Klotz222x28)

FA

(Felge2mit2Achse)

K16

(Klotz212x26)

P624

(Platte262x224)

K18

(Klotz212x28)

KR24

GO25

(Klotz222x242fr2Rad)

K14

(Klotz212x24)

P616

GU25

(Gelenkplatte222x252oben)

P24

(Platte222x24)

(Platte262x216)

P18

(Platte212x28)

PZ

(Gelenkplatte222x252unten)

RK11

(Rundklotz212x21)

(Platte2mit2Zapfen)

GV25
(Gelenkverbinder
22x25)

TL134

TR134

(Tre2links
12x232x24)

(Tre2rechts
12x232x24)

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite211

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.2.1*Beispielfirma*LegoTrailer AG* Gozintographen


AAG*(Aufbauanhnger* geschlossen)

AAG
f

f2 {21,222}

K16
f

K14
f

CAH
f

28

P624
0

TL134
f

TR134
f

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite212

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.2.1*Beispielfirma*LegoTrailer AG* Gozintographen


CAH*(Chassis*Aufbauhnger)
CAH
f

f2 {21,222}

1
FG
f

2
K18
f

2
P18
f

1
P624
0

4
PZ
0

RK11
f

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite213

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.2.1*Beispielfirma*LegoTrailer AG* Gozintographen


FG*(Fahrgestell)

FG
f

f2 {21,222}

4
FA
f

2
K28
0

2
KR24
0

4
P24
0

RF
0

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite214

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.2.1*Beispielfirma*LegoTrailer AG* Gozintographen


AKL*(Kippanhnger* lang)

AKK*(Kippanhnger* kurz)

AKK
f
1

CKK
f

K14
f

AKL
f

f2 {21,222}

8
K16
f

CKL
f

K14
f

16
K16
f

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite215

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.2.1*Beispielfirma*LegoTrailer AG* Gozintographen


CKK*(Chassis*Kippanhnger* kurz)

CKK
f

1
FG
f

GO25
0

GU25
0

GV25
0

K16
f

1
P616
0

PZ
0

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite216

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.2.1*Beispielfirma*LegoTrailer AG* Gozintographen


CKL*(Chassis*Kippanhnger* lang)

CKL
f

1
FG
f

GO25
0

2
GU25
0

GV25
0

1
K16
f

2
K18
f

2
P18
f

1
P624
0

4
PZ
0

RK11
f

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite217

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.2.2**Anforderungen*an*das*ERPbSystem*(I)
Nachstehend2eine2allgemeine2Beschreibung2der2Anforderungen2 und2ein2berblick.
Eine2detaillierte2Beschreibung2folgt2im2Zusammenhang2 mit2dem2Datenbankentwurf.2
! Das2ERPZSystem2sollte2alle2Informationen2verwalten,2die2im2Zusammenhang2
stehen2mit2der
! Auftragsabwicklung
! Produktherstellung
! Beschaffung2der2erforderlichen2Einzelteile2
! Auslieferung2der2Ware
! LegoTrailer stellt2grundstzlich2alle2zum2Verkauf2kommenden2 Artikel2selbst2her.2
Die2hierfr2bentigten2Einzelteile2werden2von2externen2Lieferanten2bezogen.
! Auftrge2werden2von2der2LegoTrailer AG2an2die2Kunden2grundstzlich2immer2
komplett2ausgeliefert,2d.h.2es2gibt2keine2Teillieferungen.2Analog2dazu2wurde2mit2
den2Lieferanten2vereinbart,2dass2diese2Bestellungen2der2LegoTrailer AG2
ebenfalls2stets2nur2komplett2ausliefern.

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite218

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.2.2**Anforderungen*an*das*ERPbSystem*(II)
! Die2Auftragsbearbeitung behandelt2einen2eingehenden2 Kundenauftrag
wie2folgt:2
! Sie2prft,2ob2dieser2komplett2aus2dem2verfgbaren2Lagerbestand2
bedient2werden2kann2(" Lagerlieferung)2oder2hierfr2erst2
produziert2werden2muss2(" Fertigungslieferung).
! Bei2einer2Fertigungslieferung werden2evtl.2im2Lager2verfgbare2
Artikel2fr2diesen2Auftrag2reserviert2und2fr2den2Rest2
Fertigungsauftrge2erzeugt.
! Sind2sofort2bzw.2nach2Abschluss2der2Fertigung2alle2Artikel2im2
Lagerbestand2 verfgbar,2wird2ein2Versandauftrag2erstellt2und2damit2
das2Ausfassen2sowie2die2Auslieferung2der2Ware2fr2diesen2
Kundenauftrag2 veranlasst.
! LegoTrailer liefert2seine2Artikel2im2Allgemeinen2 nach2Preisliste.2
Wurde2mit2einem2Kunden2 ein2abweichender2 Preis2vereinbart,2so2wird2
dieser2in2der2jeweiligen2Auftragsposition2vermerkt.

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite219

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.2.2**Anforderungen*an*das*ERPbSystem*(III)
! Die2Fertigungsabteilung behandelt2 eingehende2 Fertigungsauftrge
wie2folgt:
! Sie2ermittelt2fr2jede2Auftragsposition2den2Bedarf2an2Einzelteilen
! Sind2die2(noch)2zu2produzierende2Artikelmenge2einer2
Auftragsposition2bentigten2Einzelteile2vollstndig2im2Lagerbestand2
verfgbar,2dann2wird2die2Fertigung2fr2diesen2Posten2angestoen.2
! Sind2hingegen2 nicht2alle2Einzelteile2fr2eine2Auftragsposition2
vollstndig2im2Lagerbestand2 verfgbar,2dann2wird2der2Gesamtbedarf
an2Einzelteilen2fr2den2zu2produzierenden2 Artikel2an2den2Einkauf2
gemeldet\2und2zwar2unabhngig2 davon,2ob2eine2Teilmenge2 der2
bentigten2 Einzelteile2evtl.2im2Lagerbestand2 verfgbar2wre.22Z Sind2
alle2bestellten2Einzelteile2fr2einen2FertigungsZauftrag2eingetroffen,2
wird2die2Fertigung2angestoen.
! Nach2Erledigung2eines2Fertigungsauftrages2werden2die2Artikel2im2
Lagerbestand2 eingebucht2und2(fr2diese2Auftragsposition)2als2
reserviert2markiert.

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite220

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.2.2**Anforderungen*an*das*ERPbSystem*(IV)
! Die2Einkaufsabteilung erhlt2Bestellanforderungen,2 die2sich2auf2die2
bentigten2 Einzelteile2fr2einzelne2Fertigungsauftrge,2d.h.2auf2einzelne2
Auftragspositionen2von2Kundenauftrgen,2 beziehen.2Sie2verfhrt2mit2
diesen2Bestellanforderungen2 wie2folgt:
! Sie2fasst2gegebenenfalls2 mehrere2Bestellanforderungen,2 die2
dasselbe2Einzelteil2betreffen,2zu2einer Bestellung2zusammen2und2
schickt2diese2an2den2ausgewhlten2Lieferanten.
! Nach2Eingang2 der2Ware2werden2die2Einzelteile2den2
Bestellanforderungen2 (und2damit2auch2den2Auftragspositionen)2
zugeordnet,2d.h.2bei2der2Einbuchung im2Lagerbestand2fr2diese2
reserviert.
! Die2Versandabteilung bearbeitet2einen2Versandauftrag wie2folgt:
! Sie2fasst2die2Ware2physisch2aus2dem2Lager2aus,2stellt2die2Ware2
zusammen2und2organisiert2den2Transport2zum2Kunden.
! Der2Vollzug2der2Auslieferung2wird2von2der2Versandabteilung2 an2die2
Buchhaltung2gemeldet,2die2daraufhin2die2Rechnungsschreibung2
anstt.2
! Damit2ist2die2Auftragsbearbeitung2abgeschlossen.
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite221

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.2.2**Anforderungen*an*das*ERPbSystem*(V)
Der*Ablauf*einer*Auftragsabwicklung* im*berblick

Auftragsbearbeitung:
Verfgbare2Ware2reserZ
vieren2und2fr2Rest
Fertigungsauftrag2
erteilen

0
Auftrag
wurde2erfasst

Fertigung*(nach*Ende):
Bestand2+2Reservierungen
erhhen

Auftrag
abgeschlossen

Auftragsbearbeitung:
Ausbuchung2aus
Bestand2+2ReserZ
nein
Lagerb
vierung und
ware?
Anstoen2der
ja
Auslieferung
Auftragsb
Versandabteilung:
bearbeitung:
Auslieferung
3
4
Ausbuchung2aus2Bestand
und2Anstoen2Auslieferung

Buchhaltung:
RechnungsZ
schreibung

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite222

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

Inhalt

Vorbemerkungen

Beispielfirma LegoTrailer AG

Entwurf des2Datenbankschemas

Implementierung von2Anwendungsfunktionen

Konsistenthaltungsaspekte

Transaktionale Aspekte und2Mehrbenutzerbetrieb

Weiterfhrende Anforderungen an2betriebliche Informationssysteme

Abschlieende Bemerkungen
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite223

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.3*Entwurf*des*Datenbankschemas
Inhalt
3.3.12
3.3.2
3.3.3
3.3.4

Ermittlung2der2Entities
berlegungen2zur2Abbildung2von2Entities auf2Relationen
Realisiertes2Schema2fr2LegoTrailer AG
Arbeiten2mit2Sichten2(Views)

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite224

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.3.1**Ermittlung*der*Entities (fr*relationalen*DBbEntwurf)
Wiederholung:22Wie2identifizieren2wir2potenzielle2Entities in2einem2Text?
Wodurch2unterscheiden2sich2Entities von2Attributen?22
(Potenzielle)*Entities sind*Substantive,*die*durch*weitere*Angaben*nher*
beschrieben* sind.
Substantive*ohne*nhere*Angaben* sind*in*der*Regel*lediglich*Attribute
von*Entities.
Aber2Achtung:
! Auch2im2Text2nicht2nher2umschriebene2Substantive2knnen2dennoch2 fr2
ein2Entity2stehen!22 Auch2auf2die2Bedeutung2 im2Kontext2der2Anwendung2
achten!
! Auf2Synonyme2und2Homonyme2achten!
! Darauf2achten,2ob2der2Begriff2auch2tatschlich2relevant2fr2das2zu2
realisierende2Informationssystem2ist

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite225

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.3.1**Ermittlung*der*Entities (fr*relationalen*DBbEntwurf)
Detaillierte2Beschreibung2der2Anforderungen2 +2Ermittlung2der2Entities:
!

LegoTrailer stellt2grundstzlich2alle2zum2Verkauf2kommenden2Waren2selbst2her,2diese2sind2in2einer2
Preisliste2aufgefhrt.

Einzelteile2stellt2LegoTrailer nicht2her,2sondern2bezieht2diese2von2externen2Lieferanten

LegoTrailer verwaltet2zu2jedem2Kunden2eine2Kundennummer2 sowie2den2Namen,2die2Stadt2sowie2


seine2Bonitt.

Zu2jedem2Kunden2werden2die2Auftrge2mit2Auftragsnummer,2Auftragsdatum,2Erfassungsdatum,2
Bearbeitungsstatus2sowie2den2Auftragspositionen2mit2Teilenummer2 und2Anzahl2verwaltet.

Der2Bearbeitungsstatus2eines2Auftrages2ist2wie2folgt2definiert:
0 = unbearbeitet
1 = verfgbare2Ware2im2Bestand2reserviert2und2Fertigungsauftrag2initiiert
2 = Fertigung2beendet2und2Ware2in2Bestand2und2Reservierung2eingebucht
3 = Ware2wurde2im2Bestand2(und2ggf.2auch2Reservierung)2ausgebucht2und2steht2zur2Auslieferung2bereit2
4 = Ware2wurde2ausgeliefert2und2Erstellung2und2Versand2der2Rechnung2wurde2initiiert
5 = Rechnungsschreibung2ist2erfolgt2/2Auftragsbearbeitung2abgeschlossen

=**Entity*?
=**Entity
=**Attribut
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite226

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.3.1**Ermittlung*der*Entities (fr*relationalen*DBbEntwurf)
!

LegoTrailer liefert2seine2Artikel2im2Allgemeinen2 nach2Preisliste.2Wurden2mit2einem2 Kunden2ein2


abweichender2Preis2vereinbart,2so2wird2dieser2in2der2jeweiligen2 Auftragsposition2vermerkt.

LegoTrailer verwaltet2zu2jedem2Lieferanten2 seine2Lieferantennummer2 sowie2den2Namen,2die2Stadt2


und2seine2Bewertung.

Zu2jedem2Lieferanten2 werden2die2Bestellungen2 mit2Bestellnummer,2 Bestelldatum,2dem2


Bearbeitungsstatus2sowie2den2Bestellpositionen2mit2Teilenummer2 und2Menge2verwaltet.

Der2Bearbeitungsstatus2einer2Bestellung2ist2wie2folgt2definiert:
0 =Bestellung2luft2
1 =Ware2wurde2angeliefert
2 =Ware2wurde2eingelagert2und2im2Bestand2eingebucht

=**Entity*?
=**Entity
=**Attribut

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite227

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.3.1**Ermittlung*der*Entities (fr*relationalen*DBbEntwurf)
Auftrge2werden2von2der2LegoTrailer AG2an2die2Kunden2grundstzlich2immer2komplett2
ausgeliefert,2d.h.2es2gibt2keine2Teillieferungen.
Erhaltene2Auftrge2werden2von2der2Auftragsbearbeitung2 (der2Verkaufsabteilung)2wie2folgt2
bearbeitet:2
! Sind2alle Positionen2eines2Auftrags2in2der2gewnschten2Menge2im2verfgbaren2Lagerbestand2
(=2Bestand2./.2reserviert)2vorhanden,2dann2werden2die2Artikel2dort2ausgebucht2und2die2
Versandabteilung2 erhlt2einen2Auslieferungsauftrag.
! Kann2der2Auftrag2nicht2komplett2aus2dem2verfgbaren2Lagerbestand2bedient2werden,2wird2
wie2folgt2verfahren:

!
!

! Sind2einige2Auftragspositionen2ganz2oder2teilweise2im2verfgbaren2Lagerbestand2
vorhanden,2werden2diese2dort2reserviert.
! Fr2die2restlichen2Artikel2wird2ein2Fertigungsauftrag2an2die2Fertigungsabteilung2
geschickt.
! Die2Fertigungsabteilung2 bucht2die2Artikel2nach2Fertigstellung2im2Bestand2ein2und2
kennzeichnet2diese2als2reserviert.
! Die2Auftragsverwaltung2bucht2den2Auftrag2mit2seinen2Positionen2aus2dem2Bestand2und2
in2der2Reservierung2aus2und2erteilt2der2Versandabteilung2einen2Versandauftrag.
Ein2Fertigungsauftrag2 bezieht2sich2immer2auf2einen2Kundenauftrag2 und2auf2dessen2AuftragsZ
positionen\2diese2geben2darber2Auskunft,2welche2Produkte2in2welcher2Stckzahl2zu2fertigen2sind.

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite228

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.3.1**Ermittlung*der*Entities (fr*relationalen*DBbEntwurf)
!

Die2Fertigungsabteilung2 behandelt2eingehende2 Fertigungsauftrge2 wie2folgt:


! Sie2ermittelt2 fr2jede2Auftragsposition2Menge2den2Bedarf2an2Einzelteilen.
! Sind2alle2Einzelteile2fr2eine2Auftragsposition2vollstndig2im2Lagerbestand2 verfgbar,2
wird2die2Fertigung2hierfr2angestoen2sowie2die2Ware2nach2Fertigstellung2im2Lager2in2
Bestand2eingebucht2und2als2reserviert2gekennzeichnet.
! Sind2nicht2alle2Einzelteile2einer2Auftragsposition2vollstndig2im2Lagerbestand2verfgbar,2
wird2der2Gesamtbedarf2an2Einzelteilen2 in2Form2einer2Bestellanforderung2an2den2Einkauf2
gemeldet.2
(d.h.2fr2Einzelteile2erfolgt2keine2Entnahme2 oder2Reservierung2von2Teilmengen2 im2
Bestand.)
! Nach2Abwicklung2der2Bestellung2bucht2der2Einkauf2die2Teile2in2Bestand2und2markiert2
diese2als2reserviert.
! Sind2alle2Einzelteile2fr2eine2Auftragsposition2vorhanden,2bucht2die2Fertigung2die2
Einzelteile2aus2Bestand2und2der2Reservierung2aus2und2stt2die2Fertigung2an.
! Wenn2die2letzte2Auftragsposition2im2Lager2eingebucht2wurde,2wird2die2
Auftragsbearbeitung2 von2der2Fertigungsabteilung2 hierber2informiert.
Eine2Bestellanforderung2ist2eine2Liste2von2Teilen2mit2der2bentigten2Anzahl,2welche2die2
EinkaufsZabteilung2fr2die2Fertigungsabteilung2 fr2einen2bestimmten2Fertigungsauftrag2
beschaffen2soll.2
=**Entity*?
=**Entity
=**Attribut
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite229

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.3.1**Ermittlung*der*Entities (fr*relationalen*DBbEntwurf)
!

Eine2Bestellanforderung2wird2seitens2der2Einkaufsabteilung2wie2folgt2bearbeitet:
! Sie2prft,2ob2evtl.2dasselbe2Teil2auch2in2anderen,2aktuell2vorliegenden2Bestellanforderungen2
angefordert2wird2und2fasst2diese2fr2die2Bestellung2beim2Lieferanten2evtl.2zusammen.2
(d.h.2eine2Bestellposition2 einer2Bestellung2kann2sich2evtl.2auf2mehrere2Bestellanforderungen2
beziehen.)
! Anschlieend2legt2die2Einkaufsabteilung2fest,2von2welchem2Lieferanten2die2Teile2(und2zu2
welchem2Preis)2bezogen2werden2sollen2und2fasst2diejenigen2 Bestellpositionen,2die2den2
gleichen2Lieferanten2 betreffen,2zu2einer2Bestellung2zusammen.2
! Die2Einkaufsabteilung2 hat2mit2allen2Lieferanten2 vereinbart,2dass2Bestellungen2stets2
komplett2ausgefhrt2werden2(d.h.2es2erfolgen2keine2Teillieferungen).
! Nach2Eingang2der2Ware2bucht2die2Einkaufsabteilung2 die2Ware2im2Lager2in2den2Bestand2
ein\2und2falls2die2Bestellung2aufgrund2einer2Bestellanforderung2 (der2Fertigungsabteilung)2
erfolgte,2so2wird2sie2auch2reserviert.
! Sind2alle2Bestellpositionen2zu2einer2Bestellanforderung2am2Lager,2benachrichtigt2die2
Einkaufsabteilung2die2Fertigungsabteilung2 entsprechend.

Auerdem2prft2die2Einkaufsabteilung2 von2Zeit2zu2Zeit2die2Lagerbestnde2auf2Unterschreitung2
des2Mindestbestands2und2initiiert2 ggf.2dann2auch2von2sich2aus2Bestellungen.2

=**Entity*?
=**Entity
=**Attribut
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite230

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.3.1**Ermittlung*der*Entities (fr*relationalen*DBbEntwurf)
!

Ein2Versandauftrag2bezieht2sich2stets2auf2einen2Kundenauftrag2 und2ist2eine2
Anweisung2der2Auftragsbearbeitung2an2die2Versandabteilung,2 die2im2Kundenauftrag2
aufgefhrten2 Artikel2in2der2angegebenen2 Menge2an2den2Kunden2zu2versenden.

Ein2Versandauftrag2wird2von2der2Versandabteilung2wie2folgt2bearbeitet:
! Die2Versandabteilung2 fasst2nach2Eingang2des2Versandauftrags2die2Ware2
physisch2aus2dem2Lager2aus,2stellt2die2Ware2zusammen2und2organisiert2den2
Transport2zum2Kunden.
(Die2Ausbuchung2aus2dem2Lagerbestand2wurde2bereits2von2der2
Auftragsbearbeitung2 durchgefhrt.)
! Der2Vollzug2der2Auslieferung2wird2von2der2Versandabteilung2 an2die2
Buchhaltung2gemeldet,2 die2daraufhin2die2Rechnungsschreibung2anstt\2

Damit2ist2die2Auftragsbearbeitung2 abgeschlossen.

Noch*zu*klren:

Rechnung : Wird2nicht2in2diesem2ERPZSystem
verwaltet

Preisliste : Muss2noch2ergnzt2werden

=**Entity*?
=**Entity
=**Attribut

Typischerweise2will2man2in2betrieblichen2IS2u.a.2auch2wissen,2zu2welchem2Zeitpunkt2
welche2Aktionen2angestoen2oder2abgeschlossen2wurden.2
Wir2ergnzen2daher2unsere2ermittelten2 Entities noch2um2ein2paar2zustzliche2Attribute
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite231

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.3.1**Ermittlung*der*Entities (fr*relationalen*DBbEntwurf)
Verfeinerung*/*Ergnzung*der*Entities
! Ermittelte2Entities (1.2Entwurf):

Ergnzungen

! Kunde

KdNr,2KdName,2KdStadt,2Bonitt

! Auftrag

AuftrNr,2KdNr, AuftrDatum,2Erfassungsdatum,
AuftrStatus,2LgLieferung,*AuftrAnFertigung,*FertigungBeendet,
WareAusliefBereit,*AusliefDatum,*Rechnungsstatus,*
Rechnungsdatum,*Zahlungseingang

! AuftragsPos

AuftrNr,2AuftrPos,2TeileNr,2Anzahl,2VkPreis,2AnzFrKundeReserviert,
AnzNochZuFertigen

! Lieferant

LiefNr,2LiefName,2 LiefStadt,2Bewertung

! Bestellungen

BestNr,2BestDatum,2Status,2WareErhalten,*LgZugangGebucht

! BestellPos

BestNr,2BestPos,2TeileNr,2Anzahl

! Teile

TeileNr,2Bestand,2reserviert2,2MinBestand,2KalkKosten

! Fertigungsauftrag FaNr,2AuftrNr,2Eingangsdatum,*FertigungBeendet
! FertigungsauftrPos FaNr,2FaPos,2TeileNr,2AnzahlZuFertigen,2 FertigungsStatus,
BestAnfordGestartet,*BestAnfordErledigt,*FertigungGestartet,*
FertigungErledigt
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite232

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.3.1**Ermittlung*der*Entities (fr*relationalen*DBbEntwurf)
Ergnzungen
! Bestellanforderung

BaNr,2FaNr,*BestErledigtDatum

! BestellAnfordPos

BaNr,2BaPos,2TeileNr,2Anzahl2,2BestNr,2BestPos

! Liefert

LiefNr,2TeileNr,2Preis

! Versandauftrag

VaNr,2AuftrNr,2WareAusliefBereit,*AusliefDatum

! VersandauftrPos

VaNr,2VaPos,2TeileNr,2Anzahl

! Preisliste

TeileNr,2Preis

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite233

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.3.2**berlegungen*zur*Abbildung*von*Entities auf*Relationen
! Ergnzte2Entities:
Auftrag

AuftrNr,2KdNr, AuftrDatum,2Erfassungsdatum,2AuftrStatus,2LgLieferung,
AuftrAnFertigung,2 FertigungBeendet,2 WareAusliefBereit,2AusliefDatum,
Rechnungsstatus,2Rechnungsdatum,2Zahlungseingang

AuftragsPos

AuftrNr,2AuftrPos,2TeileNr,2Anzahl,2VkPreis,2AnzFrKundeReserviert,
AnzNochZuFertigen

Fertigungsauftrag FaNr,2AuftrNr,*Eingangsdatum,2FertigungBeendet
FertigungsauftrPos FaNr,2FaPos,2TeileNr,2AnzahlZuFertigen,2 FertigungsStatus,2
BestAnfordGestartet,2BestAnfordErledigt,2FertigungGestartet,2
FertigungErledigt
Versandauftrag

VaNr,2AuftrNr,2WareAusliefBereit,2AusliefDatum

VersandauftrPos

VaNr,2VaPos,2TeileNr,2Anzahl

! Alternative*1:*Direkte*Umsetzung,*d.h.*Implementierung*von*6*Relationen
! Positiv:*Korrespondenz*zwischen*Relationen*und*Entities unmittelbar*sichtbar
! Negativ:*Redundante*Speicherung*von*Information,*aufwendigere*Konsistenthaltung

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite234

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.3.2**berlegungen*zur*Abbildung*von*Entities auf*Relationen
! Alternative*2:**Zusammenfassung* logischer*Relationen
Beobachtung:
1

Auftrag

AuftrNr,2KdNr, AuftrDatum,2Erfassungsdatum,2AuftrStatus,2LgLieferung,
AuftrAnFertigung,2 FertigungBeendet,2 WareAusliefBereit,2AusliefDatum,
Rechnungsstatus,2Rechnungsdatum,2Zahlungseingang

AuftragsPos

AuftrNr,2AuftrPos,2TeileNr,2Anzahl,2VkPreis,2AnzFrKundeReserviert,
AnzNochZuFertigen

Fertigungsauftrag FaNr,2AuftrNr,*Eingangsdatum,2FertigungBeendet

FertigungsauftrPos FaNr,2FaPos,2TeileNr,2AnzahlZuFertigen,2 FertigungsStatus,2


BestAnfordGestartet,2BestAnfordErledigt,2FertigungGestartet,2
FertigungErledigt

5 Versandauftrag

VaNr,2AuftrNr,2WareAusliefBereit,2AusliefDatum

6 VersandauftrPos

VaNr,2VaPos,2TeileNr,2Anzahl

Relationen2 1,22und23 knnen2als2Spezialisierungen2 eines2gemeinsamen2 (abstrakten)2Supertyps2


aufgefasst2werden\2sie2reprsentieren2unterschiedliche2Zustnde2eines2Auftrags2
mgliche2(physische)2Speicherung2in2einer Relation
Analog:2Relationen2 4,252und26.2Auch2hier2mgliche2Speicherung2in2einer (physischen)2Relation.
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite235

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.3.2**berlegungen*zur*Abbildung*von*Entities auf*Relationen
Einschub:*Abbildung*von*ISAbBeziehungen*

PersNr

Name

Abt

Adresse

Gehalt

Mitarbeiter

UBIst

Verkufer

UBSoll

Ttigkeit7=
"Schreibkraft"

Anschlge

Ttigkeit7=
"Mechaniker"

Fremdspr

Ttigkeit7=
"Verkufer"

Schreibkraft

Zustndig

Mechaniker

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite236

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.3.2**berlegungen*zur*Abbildung*von*Entities auf*Relationen
Einschub:*Abbildung*von*ISAbBeziehungen*
!

Interne*Realisierungsalternativen* im*klassischen* RelationenbModell


1. Supertyp und2Subtypen2werden2jeweils2als2eigene2Relationen2modelliert.2
Der2Schlssel2des2Supertyps2wird2als2Fremdschlssel2in2den2Subtypen2verwendet.
Mitarbeiter(PersNr,2Name,2Adresse,2Abt,2Gehalt)
Verkufer(PersNr,2USoll,2UIst)
Schreibkraft(PersNr,2Anschlge,2Fremdspr)
Mechaniker(PersNr,2Zustndig)
Drei2JoinbViews,2um2logische2Relationen2 Verkufer,2Schreibkraft2oder
Mechaniker2zu2realisieren
2. Supertyp und2alle2Subklassen2werden2in2einer2gemeinsamen (groen)2Relation
zusammengefasst\2evtl.2kann2ein2DiskriminatorZAttribut2die2bernommene2 Rolle2
reprsentieren.
Mitarbeiter(PersNr,2Name,2Adresse,2Abt,2Gehalt,2Ttigkeit,2USoll,2UIst,2
Anschlge,2Fremdspr,2Zustndig)
2Vier2ProjectionbViews fr2die2logischen2Relationen2 sowie2Nullwerte fr2die2
jeweils2nicht2belegten2Attribute
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite237

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.3.2**berlegungen*zur*Abbildung*von*Entities auf*Relationen
Einschub:*Abbildung*von*ISAbBeziehungen*
!

Interne*Realiserungsalternativen im*klassischen* RelationenbModell


3. Der2Supertyp wird2nicht2separat2modelliert.2Stattdessen2werden2dessen2Attribute2
jedem2Subtyp2hinzugefgt2(geht2nur2bei2disjunkter2totaler2Zerlegung2 in2Subklassen).
Verkufer(PersNr,2Name,2Adresse,2Abt,2Gehalt,2USoll,2UIst)
Schreibkraft(PersNr,2Name,2Adresse,2Abt,2Gehalt,2Anschlge,2Fremdspr)
Mechaniker(PersNr,2Name,2Adresse,2Abt,2Gehalt,2Zustndig)
2Typ<Zusammenhang2geht2verloren,-eine UNIONbView zur2Realisierung2einer2
Gesamtsicht

Realisierungsalternative* im*objektrelationalen*TypbSystem*von*SQL:

Vererbungshierarchien2direkt2darstellbar2( CREATE*TYPE typname.2UNDER )

CREATE*TABLE relname OF typname 2

ber2interne2Realisierung2(siehe2oben)2entscheidet2der2Hersteller
(fr*Details*siehe*Vorlesung*Datenbanksysteme*(oder*DBSbLehrbcher))
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite238

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.3.3**Realisiertes*Schema*fr*LegoTrailer AG
(1,1)

Rechnung

(0,*)

*Logische* Sicht*

Kunde

(1,1)

(0,*)
(1,1)
(0,1)

(0,1)

Auftrag

(0,*)

Teiletyp
(1,1)
(1,1)
(0,*)

(1,1)

Teil
(0,*)

(0,*)

(1,*)

(1,*)

Versandauftragb
position
(1,1)

(1,1)

(1,1)

(0,*)

Fertigungsb
auftrag

(1,1) Versandb
auftrag

(0,1)

(1,*)

(1,1)

(1,1) Auftragsb
position

(0,1)
(1,1)

Fertigungsb
auftragposition
(0,*)

(0,1)
(1,1)
Lieferant
(0,*)

Bestellb
position*

(1,1)
(1,*)
(1,1)

Bestellung

(1,*)
(0,1)

Bestellb
anforderung

(1,1)
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite239

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

Kunden
(1,1)

Rechnung

(0,*)

*Implementierung*

Kunde

(1,1)

(0,*)
(1,1)
(0,1)

Teiletypen
(0,*)

(0,1)

Auftrag

Teiletyp
(1,1)
(1,1)

Teile
(1,1)

(0,*)

Teil
(0,*)

Lieferanten
Lieferant
(0,*)

(0,*)

Fertigungsb
auftrag
(1,*)

(1,*)

Versandauftragb
position
(1,1)

(1,1)

(1,1)

(0,*)

(1,1)

(1,1) Versandb
auftrag

(0,1)

(1,*)

AuftragsDS

(1,1) Auftragsb
position

(0,1)
(1,1)

Fertigungsb
auftragposition

AuftragsPosDS

(0,1)

(0,*)

(1,1)

(1,1)
(1,*)

Bestellb
position*

(1,1)

BestellPos

(1,*)

Bestellung

(0,1)

(1,1)

Bestellungen

Bestellb
anforderung

BestellAnforderungen

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite240

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.3.3**Realisiertes*Schema*fr*LegoTrailer AG

Relation*AuftragsDS
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite241

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite242

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

Relation*AuftragsPosDS

Details2siehe
LegoTrailerZSchemaZ*.sql
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite243

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

(Forts.)

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite244

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite245

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.3.4**Arbeiten*mit*Sichten*(Views)
! Attribute2der2Relation*AuftragsDS
davon2(mindestens2 )2bentigt
fr2Entity
1

Auftrag

Fertigungsauftrag

Versandauftrag
Die2anderen2Informationen
knnen2bei2Bedarf2durch
Inspektion2der2beiden2anderen
Entities ermittelt2werden

AuftrNr

KdNr

KdAuftrNr

KdAuftrDatum

ErfassungsDatum

LgLieferung

AuftrStatus

AuftrAnFertigung

AuftrPosInArbeit

FertigungBeendet

WareAusliefBereit

AusliefDatum

RechnungsStatus
RechnungsDatum
ZahlungsEingang
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite246

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

! Attribute2der Relation*
AuftragsPosDS
! davon2(mindestens)2bentigt
fr2Entity
1

AuftragsPos

FertigungsauftragsPos

VersandauftragsPos

Interessant:
Einrichten*von*Sichten
(virtuelle*Relationen*fr
Auftragserfassung

AuftrNr

AuftrPos

TeileID

Farbe

VkPreis

AnzVonKundeBestellt

AnzFuerKundeReserviert

AnzNochZuFertigen

BestAnfordErstellt

(*X*)

BestAnfordErledigt

(*X*)

FertigungGestartet

SQL*II*

FertigungBeendet

FertigungsStatus

Auftragsbearbeitung
Fertigungsplanung

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite247

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

! Ergnzende*Materialien
(integraler*Bestandteil*von*Vorl.*+*b.)

LegoTrailerbSchemab2015bgefllt.sql
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite248

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

Inhalt

Vorbemerkungen

Beispielfirma LegoTrailer AG

Entwurf des2Datenbankschemas

Implementierung von2Anwendungsfunktionen

Konsistenthaltungsaspekte

Transaktionale Aspekte und2Mehrbenutzerbetrieb

Weiterfhrende Anforderungen an2betriebliche Informationssysteme

Abschlieende Bemerkungen
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite249

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.4*Implementierung*von*Anwendungsfunktionen
! Vorbemerkung
! In2Ergnzung2zu2den2bungen2 im2Folgenden2 exemplarische2
Konkretisierung2einiger2Anwendungsfunktionen2 des2ERPZSystems2
der2LegoTrailer AG
! Ziel2ist,2bezglich2Datenbankanfragen2 alternative2Lsungen2zu2
diskutieren2und2den2Anwendungsnutzen2 weiterfhrender2SQLZ
Funktionen2aufzuzeigen
! Die2weitergehenden2 SQLZFunktionen2behandeln2 wir2dann2im2
nchsten2Kapitel

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite250

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.4*Implementierung*von*Anwendungsfunktionen
! Auftragserfassung
! Funktionalitt:*Anlegen* Auftrag
! Anzeige2der2vorhandenen2Kunden2zur2Auswahl2der2KdNr
(+2evtl.2Mglichkeit2zur2Neuanlage:2 Funktionalitt:*Anlegen*Kunde)
! Vergabe2AuftrNr ( automatisch)*
! Erfassung2KdAuftrDatum,2KdAuftrNr)

! Funktionalitt:*Erfassen*Auftragspositionen
! Anzeige2der2Produkte2laut2Preisliste2zur2Auswahl2von2TeileID,2Farbe
! Vergabe2AuftrPos ( automatisch)*
! Erfassung2AnzVonKundeBestellt
! Setzen2AuftrStatus =202und2FertigungsStatus =2Z12( jeweils*automatisch)*

! Implementierung:*
! Wie2gewohnt:2Erfassungsmasken2+2INSERT2VALUES2
! Sinnvoll:*DBbseitige*Vergabe*von*fortlaufenden
Nummern*und*DEFAULTbWerten

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite251

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.4*Implementierung*von*Anwendungsfunktionen
! Auftragsbearbeitung
! Funktionalitt:*(Erste)*Bearbeitung*des*erfassten*Auftrags
! Anzeige2der2erfassten2Auftragsdaten2von2Auftrag2Nr.2x2mit2Liste2
der2beauftragten2 Artikel2(TeileID,2Farbe)2und2Menge
! Klassifikation2des2Auftrags2als2Lagerauftrag ( LgLieferung =21)2
oder2Fertigungsauftrag ( LgLieferung =20)22( automatisch)
! Falls2Lagerauftrag:
Ausbuchen2Produkte2aus2Bestand2(fr2alle2Auftragspositionen)22( automatisch)
Initiieren2 Versandauftrag2( AuftrStatus =23)22( automatisch)*
! Falls2kein-Lagerauftrag:2
Reservieren2verfgbare2Produkte2im2Lagerbestand2( automatisch)*
Fr alle2Positionen2des2Auftrags2fr2restliche2Produkte2und2Mengen2einen
gemeinsamen2 Fertigungsauftrag2erzeugen2(+2AuftrStatus =21)2( automatisch)

! Implementierung
: mittels2konventioneller2SQLZAnweisungen
: Alternativen:2Iteratives2ClientZServerZProgramm2(C/SZProgramm)2oder2SQLb
Prozedur

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite252

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.4*Implementierung*von*Anwendungsfunktionen
! SQLbAnweisung* fr
Klassifikation*des*Auftrags*als*Lagerauftrag (LgLieferung =*1)*
oder*Fertigungsauftrag ( LgLieferung =*0) ( automatisch)
!

Ziel:*Bestimmung,*ob*Lagerauftrag*oder*nicht*mit*einer SQLbAbfrage

Umgangssprachliche*Formulierung*der*Aufgabe:
Ein-Auftrag-ist-ein-Lagerauftrag-genau-dann,-wenn-fr-alle-seine-Auftragspositionen-alle-Artikelin-der-gewnschten-Anzahl-im-verfgbaren-Bestand-enthalten- sind.

Erster*(naiver)*Ansatz:
Bestimme-zunchst-alle-Artikelpositionen,-fr-welche-diese-Bedingung-erfllt-ist.SELECT
FROM
WHERE

a.AuftrPos,*a.TeileID,*a.Farbe
AuftragsPosDS AS*a*JOIN*Teile*AS*t
ON*(a.TeileID =*t.TeileID)*AND*(a.Farbe =*t.Farbe)
a.AuftrNr =*15*AND
a.AnzVonKundeBestellt <=*(t.Bestand b t.Reserviert)

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite253

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.4*Implementierung*von*Anwendungsfunktionen
Wie2wissen2wir,2ob2dies2alle
Auftragspositionen2sind?
Wir*mssen* die*so*erhaltene*Menge*mit*der*Menge* aller
AuftragsposbTupel* vergleichen.
Mit2welcher2SQLZOperation2kann2man2prfen,2ob2Menge12 Menge22gilt?

EXCEPT

Komplette2Anfrage:
SELECT AuftrPos,*TeileID,*Farbe
FROM AuftragsPosDS
WHERE AuftrNr =*15
EXCEPT
SELECT*.*(siehe*vorherige*Query)

Bedingung* nicht*fr*alle
Auftragspos.*erfllt
kein*Lagerauftrag

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite254

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

Problem:*
Naive*Anfrageformulierung
fhrt*zu*einer*komplexen
Anfragebearbeitung*

SQLbAusfhrungsplan* von*
IBM*DB2 fr*obige*Anfrage

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite255

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.4*Implementierung*von*Anwendungsfunktionen

! Umgangssprachliche*Formulierung*der*Aufgabe:
Ein-Auftrag-ist-ein-Lagerauftrag-genau-dann,-wenn-fr-alle-seine-Auftragspositionen-alleArtikel-in-der-gewnschten-Anzahl-im-verfgbaren-Bestand-enthalten-sind.
! Alternativer*Ansatz: (2Gegenbeispiel)
Ein-Auftrag-ist-ein-Lagerauftrag-genau-dann,-wenn-
es2keine2Auftragsposition2gibt,2welche2die2Bedingung2nicht2erfllt
Entsprechende2SQLZAnfrage:
Anfrage*1 mit*genderter*WHEREbBedingung:

WHERE a.AuftrNr =*15*AND


a.AnzVonKundeBestellt >**(t.Bestand b t.Reserviert)

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite256

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

Anmerkung:

SQLbAusfhrungsplan* von
IBM*DB2*fr*alternative*Anfrage

DB22(wie2auch2andere2HochleistungsZ
SQLZDBMS)2fhrt2systemseitig2eine2sog.2
Anfrageoptimierung durch,2bei2der2die2
Anfrage2u.U.2in2eine2semantisch2
quivalente,2jedoch2schneller2
ausfhrbare2Anfrage2umformuliert2wird.
Die2Gte2der2Optimierung2ist2abhngig2
davon,2ob2und2in2welchem2Umfang2dem2
DBMS2Statistikdaten2ber2die2
betroffenen2Relationen2zur2Verfgung2
stehen2sowie2welcher2Optimierungslevel2
eingestellt2ist.
Fr2mehr2Informationen2hierzu2siehe2
Lehrbcher2zu2DBMS2sowie2die2
Vorlesungen2Datenbanksysteme2und2
Database2Internals.

Fazit:
Formulierung*der*SQLb
Anfrage*u.U.*nicht*egal
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite257

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.4*Implementierung*von*Anwendungsfunktionen
! Fertigungsvorbereitung
! Funktionalitt:*(Erste)*Bearbeitung*des*erhaltenen*Fertigungsauftrages
! Anzeige2des2erhaltenen2 Fertigungsauftrages2mit2Liste2der
herzustellenden2Produkte2(TeileID,2Farbe,2Anzahl)
! Berechnen2des2Teilebedarfs2fr2jede2Position2des2Fertigungsauftrags
(22StcklistenZAuflsung!)22( automatisch)
! Prfung2fr2jede2Position2des2Fertigungsauftrags,2ob2alle2Einzelteile
(gem2Stcklistenauflsung)2komplett2am2Lager2verfgbar2sind
( automatisch)
! Falls2ja,2Ausfassen2der2Teile2und2Anstoen2der2Fertigung2 fr2diese
Position2( automatisch)

hnliche
SQLZ
Anfrage
wie2vorher

! Falls2nein,2Erzeugung2einer2Bestellanforderung2 fr2diese2Position
( automatisch)

! Implementierung
: mittels2konventioneller2SQLZAnweisungen
: Alternativen:2Iteratives2C/SZProgramm2oder2SQLZProzedur
: Alternativen:2Iteratives2C/SZProgramm,2
SQLZProzedur2mit2iterativer2Stcklistenauflsung2oder2rekursive*SQLbAbfrage

2SQL*II
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite258

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

Inhalt

Vorbemerkungen

Beispielfirma LegoTrailer AG

Entwurf des2Datenbankschemas

Implementierung von2Anwendungsfunktionen

Konsistenthaltungsaspekte

Transaktionale Aspekte und2Mehrbenutzerbetrieb

Weiterfhrende Anforderungen an2betriebliche Informationssysteme

Abschlieende Bemerkungen
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite259

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.5*Konsistenterhaltungsaspekte
! Einfhrung
! Echte2ERPZSysteme2basieren2hufig2auf2tausenden2von2Tabellen2
! Beispiel2SAP2R/3:2
In2der2Standardkonfiguration2 fast2100.0002 Tabellen,2je2nach2Aufbau2und2
Struktur2knnen2es2auch2bis2zu2150.0002Tabellen2 sein
[2Quelle:2Martin2Zander:2Die2Tabellen2in2SAP2R/3,22008,2www.xinxii.com ]

! Zwischen2diesen2Tabellen2bestehen2 vielfltige2Abhngigkeiten
! klassische2Referenzbeziehungen
! redundant2gespeicherte2Information2(z.B.2nichtZaggregiert2+2aggregiert)
! Konfigurationsbeziehungen2 (Wahl2der2Sprache,2der2Whrung,2der2Zeitzone,2)
!

! Frage:2Wie2Konsistenz2gewhrleisten?
! Alternativen:
! Keine2DBMSZseitige2Konsistenzsicherung2
! DBMSZseitige2passive2Konsistenzsicherung
! DBMSZseitige2aktive2Konsistenzsicherung

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite260

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.5*Konsistenterhaltungsaspekte
! Keine*DBMSbseitige*Konsistenzsicherung
! Die2Konsistenzsicherung2ist2allein2Sache2der2AnwendungsZ und2
Systemprogramme
! Beispiele:2
! Wenn2ein2Auftrag2gelscht2wird,2mssen2durch2das2Anwendungsprogramm2(AP)2auch2
alle2zugehrigen2Auftragspositionen2gelscht2werden
! Wenn2ein2SchlsselZAttribut2einer2Relation2gendert2wird,2das2in2anderen2Relationen2
referenziert2wird,2mssen2vom2AP2die2dortigen2Attributwerte2ebenfalls2gendert2werden
! Wenn2ein2Tupel2in2eine2Bestandsrelation2eingefgt2oder2dort2gelscht2wird,2fr2die2in2
einer2anderen2Relation2ein2ZhlerZ oder2Summenfeld2 angelegt2wurde,2so2muss2vom2AP2
der2dortige2Wert2entsprechend2gendert2werden
! Wenn2die2StandardZWhrung2 von2EUR2auf2USD2umgestellt2wird,2dann2mssen2alle2
Werte2in2Whrungsfeldern2vom2AP2entsprechend2gendert2werden

! Erfordert2extrem2hohe2Disziplin2und2Sorgfalt2seitens2der2Implementierer sowie2
eine2sehr2gute2Dokumentation2aller2Abhngigkeitsbeziehungen
! Bei2groen2System2fast2nicht2beherrschbar2(viele2Tabellen,2viele2Implementierer)
! 2insbesondere,2wenn2Anwender2 selbststndig2nderungen2 vornehmen2drfen

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite261

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.5*Konsistenterhaltungsaspekte
! DBMSbseitige*passive*Konsistenzsicherung
! Das2DBMS2prft,2ob2die2Ausfhrung2der2SQLZAnweisung2 die2hinterlegte2
Konsistenzbedingung2 erfllt2
! Bei einem2Versto wird2die2SQLbAnweisung* zurckgewiesen,2 d.h.2von2ihr2
eventuell2durchgefhrte2nderungen2 wieder2zurckgesetzt2und2ein2
SQLZFehlercode2 zurckgegeben2
! Mittel:
! CREATE2TABLE22REFERENCES222[2ON2DELETE2RESTRICT2]
! CREATE2TABLE22REFERENCES22ON2UPDATE2RESTRICT
! CREATE2TABLE22CHECK2(.)
! CREATE2ASSERTION22CHECK2()
! CREATE2VIEW222WITH2CHECK2OPTION
! CREATE2TRIGGER2

der2bei2einem2entdeckten2Versto2eine2Exception wirft

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite262

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.5*Konsistenterhaltungsaspekte
! DBMSbseitige*aktive*Konsistenzsicherung
! Das2DBMS2verhindert2Inkonsistenzen2dadurch,2dass2es2bei2einer2
nderungsoperation2 auf2einer2Tabelle2selbststndig2die2entsprechenden2
nderungsoperationen2 auf2den2abhngigen2 Tabellen2durchfhrt
! Mittel:*
! CREATE2TABLE22REFERENCES222ON2DELETE2CASCADE
! CREATE2TABLE22REFERENCES22ON2UPDATE2CASCADE
! CREATE2TRIGGER2

! Zusammenfassung
! Konsistenthaltung von2Daten2in2groen2IS2eine2sehr2groe2Herausforderung
! Konsistenzsicherung2alleine2mittels2Anwendungsprogrammen2 ist2fahrlssig
! Wo2immer2mglich,2Konsistenzsicherung2ins2DBMS2integrieren2(passiv2oder2
aktiv)!

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite263

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

Inhalt

Vorbemerkungen

Beispielfirma LegoTrailer AG

Entwurf des2Datenbankschemas

Implementierung von2Anwendungsfunktionen

Konsistenthaltungsaspekte

Transaktionale Aspekte und2Mehrbenutzerbetrieb

Weiterfhrende Anforderungen an2betriebliche Informationssysteme

Abschlieende Bemerkungen
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite264

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
Inhalt
! Allgemeines
! Transaktionskonzept
! Serialisierbarkeitsprinzip
! Allgemeines2zur2Synchronisation2(Concurrency Control\2CC)
! Sperrverfahren
! Systempufferwaltung und2Logging
!

Fehlerbehandlung2 (Recovery)

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite265

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
! Allgemeines
! Szenario
! Mehrbenutzerbetrieb
! Verschiedene2Anwendungsprogramme2 (AP)2greifen2(lesend2und2schreibend)2
auf2denselben2Datenbestand2zu
! Jedes2AP2(genauer:2jede2Verbindung2oder2Session)2wird2im2DBMS2als2
eigener2Prozess2oder2Thread2realisiert2und2konkurrierend2(um2dieselben2
Resourcen)2ausgefhrt
! AP2werden2 aus2Performanzgrnden nicht2hintereinander,2 sondern2
berlappend2 ausgefhrt
! d.h.2das2DBMS2muss2einen2Mix2aus2DBZOperationen2verschiedener2AP2
ausfhren

! Nachfolgend2hierzu2ein2Beispiel2

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite266

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

black box
fr2DBMS

Benutzer1 /*AP1

Benutzer2 /*AP2

Benutzern /*APn

SQLbStmt11

SQLbStmt21

SQLbStmtn1

Query*Compiler*/*Interpreter

elementare
DBZAktionen
InputZQueues

w115
r114
w113
r112
r111

[b]
[c]
[a]2
[b]
[a]

w214
r213
r212
w211

[h]
[h]2
[g]
[f]

wn14
rn13
rn12
rn11

[m]
[g]2
[a]
[b]

DBMSbScheduler
w211 [f]2
r111 [a]
rn11 [b]
Legende:
rijk =2kZter ReadZZugriff2von2SQLZStmt j von2Benutzer2i
wijk =2kZter WriteZZugriff2von2SQLZStmt j von2Benutzer2i

Parallele*
Ausfhrung
von*SQLb
Statements
durch*das*DBMS

Datenbank
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite267

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

black box
fr2DBMS

Benutzer1 /*AP1

Benutzer2 /*AP2

Benutzern /*APn

SQLbStmt11

SQLbStmt21

SQLbStmtn1

Query*Compiler*/*Interpreter

elementare
DBZAktionen
InputZQueues

w115
r114
w113
r112

[b]
[c]
[a]2
[b]

w214 [h]
r213 [h]2
r212 [g]

wn14 [m]
rn13 [g]2
rn12 [a]

DBMSbScheduler
w211 [f]2
r111 [a]
rn11 [b]
Legende:
rijk =2kZter ReadZZugriff2von2SQLZStmt j von2Benutzer2i
wijk =2kZter WriteZZugriff2von2SQLZStmt j von2Benutzer2i

Parallele*
Ausfhrung
von*SQLb
Statements
durch*das*DBMS

Datenbank
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite268

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb

! Probleme*/*Fragestellungen
! Welche2aller2mglichen2berlappenden2Ausfhrungen2fhren2zu2
einem2korrekten2Resultat?
! Was2heit2berhaupt2korrektes2Resultat2bei2konkurrierenden2
nderungen?
! Wie2erkennt2und2vermeidet2man2unerwnschte2(d.h.2nicht2
korrekte)2Ausfhrungsreihenfolgen?
! Wie2geht2man2mit2nicht2vollstndig2ausgefhrten2nderungen2
(z.B.2wegen2Programmabbruch2oder2Systemcrash)2um?

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite269

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
Beispiel*1:*Problem*der*verlorengegangenen* nderungen*(lost*updates)

AP1

Wert2im
Haupt<
speicher

Wert2auf
Hintergrund<
speicher

AP2

2 x

Wert2im
Haupt<
speicher

Zeit

AP1:2
lese(x)

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite270

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
Beispiel*1:*Problem*der*verlorengegangenen* nderungen*(lost*updates)

AP1

Wert2im
Haupt<
speicher

Wert2auf
Hintergrund<
speicher

AP2

Wert2im
Haupt<
speicher

2 x

AP1:2 AP2:2
lese(x) lese(x)

Zeit

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite271

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
Beispiel*1:*Problem*der*verlorengegangenen* nderungen*(lost*updates)

AP1

Wert2im
Haupt<
speicher

Wert2auf
Hintergrund<
speicher

AP2

2*+*3**=***5

2
5

Wert2im
Haupt<
speicher

2 x

Zeit

AP1:2
AP1:2 AP2:2
lese(x) lese(x) x2=2x+3

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite272

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
Beispiel*1:*Problem*der*verlorengegangenen* nderungen*(lost*updates)

AP1

Wert2im
Haupt<
speicher

Wert2auf
Hintergrund<
speicher

AP2

Wert2im
Haupt<
speicher

2 x

7
2*+*5**=***7

AP1:2
AP2:2
AP1:2 AP2:2
lese(x) lese(x) x2=2x+3 x2=2x+5

Zeit

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite273

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
Beispiel*1:*Problem*der*verlorengegangenen* nderungen*(lost*updates)

AP1

Wert2im
Haupt<
speicher

Wert2auf
Hintergrund<
speicher

AP2

Wert2im
Haupt<
speicher

5 x

AP1:2
AP1:2
AP2:2
AP1:2 AP2:2
lese(x) lese(x) x2=2x+3 x2=2x+5 schreibe(x)

Zeit

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite274

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
Beispiel*1:*Problem*der*verlorengegangenen* nderungen*(lost*updates)

AP1

Wert2im
Haupt<
speicher

Wert2auf
Hintergrund<
speicher

AP2

Wert2im
Haupt<
speicher

7 x

Ergebnis:
Die*nderung*von*AP1 ist*verlorengegangen.
Es*gibt*keine*sequenzielle*Ausfhrungsreihenfolge
dieser*Programme,*die*zum*selben*Resultat*fhren*wrde.
Einen*solchen*Effekt*bezeichnet*man*als*lost2update.

AP1:2
AP2:2
AP1:2
AP2:2
AP1:2 AP2:2
lese(x) lese(x) x2=2x+3 x2=2x+5 schreibe(x) schreibe(x)

Zeit

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite275

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
Beispiel*2:*Problem*des*schmutzigen*Lesens*(dirty read)

AP1

Wert2im
Haupt<
speicher

Wert2auf
Hintergrund<
speicher

AP2

2 x

Wert2im
Haupt<
speicher

Zeit

AP1:2
lese(x)

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite276

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
Beispiel*2:*Problem*des*schmutzigen*Lesens*(dirty read)

AP1

Wert2im
Haupt<
speicher

Wert2auf
Hintergrund<
speicher

AP2

2*+*3**=***5

2 x

Wert2im
Haupt<
speicher

AP1:2
lese(x)

AP1:2
x2=2x+3

Zeit

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite277

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
Beispiel*2:*Problem*des*schmutzigen*Lesens*(dirty read)

AP1

Wert2im
Haupt<
speicher

Wert2auf
Hintergrund<
speicher

AP2

5 x

Wert2im
Haupt<
speicher

AP1:2
lese(x)

Zeit

AP1:2
AP1:2
x2=2x+3 schreibe(x)

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite278

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
Beispiel*2:*Problem*des*schmutzigen*Lesens*(dirty read)

AP1

Wert2im
Haupt<
speicher

Wert2auf
Hintergrund<
speicher

AP2

Wert2im
Haupt<
speicher

5 x

AP1:2
lese(x)

AP1:2
AP1:2
x2=2x+3 schreibe(x)

AP2:2
lese(x)

Zeit

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite279

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
Beispiel*2:*Problem*des*schmutzigen*Lesens*(dirty read)

AP1

Wert2im
Haupt<
speicher

Wert2auf
Hintergrund<
speicher

AP2

Wert2im
Haupt<
speicher

5 x

AP1:2
lese(x)

Ergebnis:
Durch*den*Abbruch*von*AP1*hat*AP2 inkonsistente
Daten*gelesen.*
Unter*der*Annahme,*dass*AP1 seine*nderungen
bei*Abbruch*wieder*rckgngig*macht,*gibt*es*keine
sequenzielle*Ausfhrung*dieser*Programme,*die*
zum*selben*(Leseb)Ergebnis*fhren*wrde.
Diesen*Effekt*nennt*man*dirty read.

AP1:2
AP1:2
x2=2x+3 schreibe(x)

AP1:
Abbruch!

AP2:2
lese(x)

Zeit

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite280

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
! Transaktionskonzept
! berlegungen:
! Der2Benutzer2sollte2logisch2zusammengehrige2 Operationen2 klammern2
knnen2(2Transaktion).
! Axiom:2

Im2Einbenutzerbetrieb berfhrt2eine2vollstndig2ausgefhrte2
Transaktion2die2Datenbank2von2einem2konsistenten2Zustand2in2
einen2neuen2 konsistenten2Zustand.

! Parallel2ausgefhrte2Transaktionen2sollten2so2gegeneinander2 isoliert2
werden,2dass2sich2das2System2 aus2Sicht2des2Anwenders2 wie2im2
Einbenutzerbetrieb verhlt.
! Das2DBMS2sollte2fr2Transaktionen2ein2AllesZoderZnichtsZPrinzip2
garantieren.
! Die2nderungen2 erfolgreich2abgeschlossener2Transaktionen2in2der2DB2
sollten2auch2durch2einen2eventuellen2spteren2Systemcrash2nicht2verloren2
gehen.
! Die2letztgenannten242Forderungen2 finden2sich2im2sog.2ACID<Paradigma wieder.
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite281

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
! Das2ACID<Paradigma fr2DBZTransaktionen
! Atomicity ..2Realisierung:2Synchronisation2+2Logging/Recovery
! Consistency ..2eine2Prmisse22
! Isolation

..2Realisierung:2Synchronisation

! Durability ..2Realisierung:2Logging/Recovery
! Eine2Transaktion2wird2vom2Benutzer2/2AP2mittels2den2SQLZAnweisungen
! COMMIT abgeschlossen2oder2mittels2
! ROLLBACK*[*WORK*] abgebrochen2 (und2damit2zurckgesetzt)

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite282

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
! Serialisierbarkeitsprinzip
Die2SchreibZ/Leseoperationen2 parallel2laufender2Transaktionen2werden2in2der2Regel2
berlappt2ausgefhrt.

T1:

r1[a]

r1[b]

r1[c]

w1[c]

T2:

r2[a]

r2[b]

r2[c]

w2[c]

Aktionen2Transaktion2T1

w2[d]

Aktionen2Transaktion2T2

Eine*mgliche*Schedule* (=*Ausfhrungsreihenfolge):

r2[a] r1[a] r2[b] r1[b] r1[c] w1[c] r2[c] w2[c] w2[d]

Frage:

Welche*der*vielen*mglichen*Schedules fhren*zu*einem*semantisch
korrekten*Ergebnis?

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite283

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
Definition*3b1:*Serialisierbarkeitsprinzip
Eine2berlappte2 Ausfhrung2der2Transaktionen2T1,2T2,2...,2Tn ist2korrekt2genau2
dann,2wenn2es2mindestens eine serielle2Ausfhrungsreihenfolge2 (serielle2
Schedule)2der2Transaktionen2T1,2T2,2...,2Tn gibt,2die,2angewandt2 auf2denselben2
Ausgangszustand,2zum2selben2Ergebnis2fhrt.

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite284

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
! Beispiel:22Die2Schedule2von2vorher2 ist2sie2serialisierbar?2
r2[a]

r1[a]

r2[b]

r1[b]

r1[c]

w1[c]

r2[c]

w2[c]

w2[d]

Hilfsmittel:2Konstruktion2Transaktions<Abhngigkeitsgraph
! Die2Knoten2des2Graphen2 stellen2die2Transaktionen2dar2und2die2gerichteten2Kanten2
zwischen2Ihnen2beschreiben2eine2gefundene2 VorgngerZNachfolgerZBeziehung.2
! Seien2op1i[x]2und2op2j[x]2Operationen2 zweier2Transaktionen2T1 und2T2 in2einer2
Schedule,2die2beide2auf2Objekt2x2zugreifen.2Falls2mindestens2eine2von2beiden2
schreibend2auf2x2zugreift,2dann2stehen2die2beiden2 Operationen2in2Konflikt zu2
einander.
! Fr2alle2in2Konflikt2stehenden2Operationen2 zweier2Transaktionen2T1 und2T2 unserer2
Schedule2S2fhren2wir2das2Folgende2 durch:2Tritt2op1i[x]2vor2op2j[x]2in2S2auf,2dann2
fgen2wir2dem2Graph2eine2Kante2T1 2T2 hinzu,2ansonsten2eine2Kante2T2 2T1
! Ist2der2Graph2zyklenfrei,2knnen2wir2mittels2der2topologischen2 Knotensortierung
die2quivalente2serielle2Ausfhrungsreihenfolge2 bestimmen.

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite285

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
! Beispiel:22Die2Schedule2von2vorher2 ist2sie2serialisierbar?2
r2[a] r1[a] r2[b] r1[b] r1[c] w1[c] r2[c] w2[c] w2[d]
Wir2analysieren:
r2[a]

kein2Konflikt

r1[a]

kein2Konflikt

r2[b]

kein2Konflikt

r1[b]

kein2Konflikt

r1[c]

in2Konflikt2mit2w2[c] :22T1 2T2

w1[c]

in2Konflikt2mit2r2[c] :22T1 2T2

r2[c]

ab2hier2keine2Konflikte2mehr2mglich,2nur2noch2Operationen2 von2T2

T1

T2

(Kante2bereits2eingetragen)

Ergebnis:
Die2Schedule2ist2serialisierbar,2
quivalente2serielle2Ausfhrungsreihenfolge:2 T1,2T2

T1

T2

Beispiel2fr2eine2nichtbserialisierbare Schedule:2 2r1[a] r2[a] w1[a] w2[a]

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite286

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
! Anmerkungen* zum*Transaktionsabhngigkeitsgraph
! Wenn2der2Transaktionsabhngigkeitsgraph2zyklenfrei ist,2dann2ist2die2
zugrundeliegende2 Schedule2definitiv2serialisierbar.
! Man2kann2allerdings2pathologische2Schedules konstruieren,2bei2denen2wie2oben2
definierte2Abhngigkeitsgraph2 Zyklen2aufweist,2die2Schedule2(nach2der2Definition2
von2Serialisierbarkeit)2jedoch2trotzdem2serialisierbar ist.
Beispiel:22r1[x] r2[x] w1[x] w2[x] w3[x]
Dies2alleine2wre2nicht2serialisierbar
aber2mit2dieser2Aktion2wird
alles2wieder2geheilt

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite287

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
! Allgemeines*zur*Synchronisation*(Concurrency ControlB*CC)
! Ein2Synchronisationsverfahren,2welches2das2Serialisierbarkeitsprinzip strikt2
beachtet,2
! gewhrleistet2den2hchsten2Grad2an2Isolation2der2Transaktionen2
gegeneinander2 (" logischer2Einbenutzerbetrieb)
! ist2jedoch2am2restriktivsten2in2Bezug2auf2die2zugelassenen2Schedules
! und2fhrt2damit2(potenziell)2zu2einem2niedrigen2Grad2an2Parallelitt
! In2der2Praxis2daher2bei2vielen2Synchronisationsverfahren2einstellbar,2welchen2
Grad2an2Isolation2die2Anwendung2 bentigt
! Der2SQLZStandard2 sieht2vor,2dass2man2fr2jede2Transaktion2den2gewnschten2
Isolationsgrad2einstellen2kann

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite288

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
Isolationsgrade* im*SQLbStandard*und*deren*Effekte
Isolationsgrade*&*Zugriffsmodus
Zugriffsmodus Read*Only

Effekte

ReadbWrite

Dirty*Read

Isolationsgrad

Nonrepeatable* Phantomb
Read
zeilen

Read*Uncommitted

Ja

Nein

Ja

Ja

Ja

Read*Committed

Ja

Ja

Nein

Ja

Ja

Repeatable*Read

Ja

Ja

Nein

Nein

Ja

Serializable

Ja

Ja

Nein

Nein

Nein

Erluterung:22(Tx =2transaction)
Read2Uncommitted /
Dirty Read

:22Eine2Tx kann2nderungen2 anderer2Tx sehen,2auch2wenn2diese


noch2kein2COMMIT2gemacht2hat

Repeatable Read

: Ein2erneutes2Lesen2derselben Tupelmenge zeigt2keine2neuen


Werte2fr2diese2Tupel,2es2sei2denn,2die2Tx hat2diese2selbst
gendert

Phantomzeilen

: Ein2nochmaliges2Ausfhren2einer2Leseanweisung2frdert2keine
neuen2Tupel2(Phantome)2zutage
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite289

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
! Beispiel2zum2Phantomproblem:
Annahmen:
Um2repeatable read2zu2gewhrleisten,2sperrt2eine2Tx alle2Tupel,2auf2die2sie2zugreift,2und2hlt2
diese2Sperren2bis2zu2ihrem2TxZEnde.2Die2Tupel2werden2durch2ihre2TID2identifiziert.
Damit2sind2die2von2der2Tx bislang2gelesenen2Tupel2gegen2nderungen2anderer2Tx geschtzt.
Ein2mglicher2Ablauf:22(BOT2=2begin of transaction,2EOT2=2end2of transaction)
{BOT2T1}
SELECT KdNr,2KdName
FROM
Kunden
WHERE KdStadt =*'Ulm'B
{BOT2T2}
<2andere2Verarbeitung2>
INSERT*INTO Kunden
<2evtl.2Updates2einzelner2Tupel2>
VALUES (300,2'Mustermann',2'Max',2'Ulm',20)\
COMMITB**{EOT2T2}
SELECT KdNr,2KdName
FROM
Kunden
Die2beiden2SQLZStatements2fhren2zu2unterschiedlichen2
Ergebnissen,2obwohl2sie2jeweils2innerhalb2einer
WHERE KdStadt =*'Ulm'B
Transaktion2(d.h.2von2T 1)2ausgefhrt2werden.2

Zeit

Grund:2T 1 sperrt2beim2Lesezugriff2die2zu2diesen2Zeitpunkt
existierenden2TIDs,2T 2 erzeugt2fr2das2einzufgende2Tupel2
jedoch2eine2neue.
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite290

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
! Anmerkungen:
! Das2Serialisierbarkeitsprinzip ist2die2formale2Grundlage2(der2Rahmen2bzw.2die2
Messlatte)2fr2die2Realisierung2von2universell2einsetzbaren2
Synchronisationsverfahren.
! Die2verschiedenen2Synchronisationsverfahren2realisieren2dieses2Prinzip2zum2Teil2
auf2sehr2unterschiedliche2Weise.
! Aber2jedes2solche2Verfahren2muss2den2Nachweis2fhren2knnen2(mit2Satz2und2
Beweis),2nach2welchem2Kriterium2man2jede2von2ihm2erzeugbare2Schedule2
quivalent2serialisieren2kann.2
! Der2Transaktionsabhngigkeitsgraph2hingegen2 ist2im2Wesentlichen2eigentlich2nur2
fr2Theoriefragestellungen2 interessant
! Wir2zeigen2die2Realisierung2eines2Synchronisationsverfahrens2am2Beispiel2von2
Sperrverfahren mit2Zwei<Phasen<Sperrprotokoll

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite291

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
! Sperrverfahren*
! Allgemeines
! Lesezugriffe2belegen2das2DBZObjekt2mit2einer2LesebSperre*(shared lock),2
Schreibzugriffe2mit2einer2Schreibsperre*(exclusive lock).
! Die2DBMS2verwalten2i.d.R.2fr2alle2Tx eine2gemeinsame2Sperrtabelle,2in2welche2
die2Sperren2eingetragen2und2aus2der2sie2am2Ende2der2Tx wieder2gelscht2werden.
! Gngige2Sperrgranulate sind2Seiten (page<level2locking) oder2Tupel2(row<level
locking),2bei2Bedarf2wird2auch2auf2hheren2Ebenen,2wie2etwa2Relation2oder2
Tablespace gesperrt.2Man2spricht2dann2auch2von2hierarchischen2Sperren.
Eine2Sperre2auf2Relationsebene2 ist2bei2manchen2Sperrverfahren2z.B.2erforderlich,2
um2im2Isolationsmodus2serializable2das2parallele2 Einfgen2von2Tupeln in2diese2
Relation2durch2andere2Tx zu2verhindern.2
Ein2anderer2Grund2fr2eine2solche2Sperre2knnen2zu2viele2TupelZ oder2
Seitensperren2der2Tx in2einer2Relation2sein.2Durch2den2Erwerb2einer2Sperre2auf2der2
bergeordneten2 Ebene2( Sperr<Eskalation2(lock2escalation) wird2man2diese2
wieder2los.2

! Wird2in2einer2Tx auf2ein2Objekt2zunchst2lesend2und2dann2schreibend2zugegriffen,2
so2wird2(falls2mgl.)2eine2Sperrkonversion shared lock2 exclusive lock2
durchgefhrt\2es2findet2ggf.2aber2immer2nur2ein2Upgrade2einer2Sperre2statt.
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite292

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
! Implementierung
! (Zentrale)2Sperrtabelle2mit2Sperrverwalter2(Lock2Manager)
! Sperrverwalter2/2Sperrtabelle2liegen2in2einem2kritischen2Abschnitt
" exklusiver2Zugriff2fr2die2jeweilige2Tx
! Anfragebearbeitung2 ruft2Sperrverwalter2(lock2manager)2zum2Anfordern2/2
Freigeben2 von2Sperren
! Bei2Nichtgewhrung2 der2Sperre2vorbergehende2 Suspendierung2 der2
Transaktion2durch2den2Sperrverwalter2bzw.2den2Scheduler2des2DBMS

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite293

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
! Das*ZweibPhasenbSperrprotokoll
! Nur2irgendwie2zu2Sperren2reicht2nicht,2um2Serialisierbarkeit zu2
gewhrleisten.
! Hierzu2bentigt2man2ein2Protokoll,2das2regelt,2wann2Sperren2angefordert2
und2wann2sie2wieder2freigegeben2 werden2drfen.
! Ein2sehr2weit2verbreitetes2Protokoll2ist2das2Zwei<Phasen<Sperrprotokoll
(two<phase2locking protocoll,22PL) auf2dem2z.B.2auch2die2in2IBM2DB22
realisierten2Synchronisationsverfahren2basieren.
! Regeln:
1.*Bevor eine*Transaktion*auf*ein*Objekt*zugreift,*muss*sie*dieses*
geeignet* sperren.
2.*Sobald*eine*Transaktion* eine*Sperre*freigegeben* hat,*darf*sie*keine*
weitere*Sperre*mehr*anfordern.

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite294

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
Das*ZweibPhasenbSperrprotokoll* *(Forts.)
Typischer2Verlauf2einer2Transaktion2mit22PLZSynchronisation:

lock2all<Zeitpunkt

#2gesperrte
Objekte

Sperrphase

Freigabephase

Zeit

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite295

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
Das*ZweibPhasenbSperrprotokoll* *(Forts.)
Wie*ergibt*sich*die*quivalente* serielle*Ausfhrungsreihenfolge?
#2gesperrte
Objekte

T3

T1

1.

Antwort

T2

T4

2.

Zeit

3. 4.

Dieser*wird*durch*die*Lock*allbZeitpunkte*der*Tx definiert.
Gleichzeitiger*Lock*allbZeitpunkt*fr*zwei*Transaktionen
kein*Zugriffskonflikt,*serielle*Ausfhrung*relativ*zueinander*beliebig

! Zugriffskonflikte fhren2zur2Blockierung der2Tx und2damit2ggf.2auch2zu2Deadlocks

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite296

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
Verklemmungen* (Deadlocks)
! Durch2das2sukzessive2Anfordern2von2Sperren2sowie2durch2Sperrkonversionen2und2
eskalationen knnen2Verklemmungen (Deadlocks)2auftreten
Objekt*x

Tx*1

hat2gesperrt
Tx*2

Objekt*y

Tx*3

Objekt*z

mchte2zustzlich
sperren

Beispiel*fr*zyklische*WartetbaufbSituation

! Deadlocks2knnen2nur2durch2Abbruch2einer2involvierten2Tx behoben2werden2
mssen,2da2sie2sich2nicht2von2selbst2wieder2auflsen
! Die2DBMS2betreiben2deshalb2entweder2Deadlockerkennung oder2brechen2Tx ab,2
wenn2sie2zu2lange2auf2eine2Sperre2warten2mssen2(Timeout).
! Wobei2ein2einfacher2Abbruch2meist2nicht2gengt.2In2der2Regel2mssen2die2Effekte2
der2Tx in2der2DB2rckgangig gemacht2werden2(2Rollback\2siehe2spter).
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite297

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
! Erkennung* und*Auflsung* von*Verklemmungen* (Deadlocks)
Vorgehensweise:
1. Analyse2der2Sperrtabelle2(welche2Tx wartet2auf2welche2Tx wegen2
Sperrkonflikt?)2und2Erstellung2einer2WartetZaufZMatrix
2. Ermittlung2von2zyklischen2WartetZaufZBeziehungen
3. Aufbrechen2des2Zyklus2durch2Abbruch2einer2der2beteiligten2Transaktionen
4. Suche,2ob2noch2weitere2Zyklen2vorliegen
5. Falls2keine2Zyklen2mehr2vorhanden,2dann2fertig,2ansonsten2weiter2bei2Schritt23

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite298

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
Abschlieende* Bemerkungen* zu*Sperrverfahren
! Aufwand2fr2die2Verwaltung2der2Sperrtabelle2incl.2Zyklensuche recht2erheblich.
! Hocheffiziente2Implementierung2erforderlich,2da2in2Hochleistungssystemen2u.U.2
mehrere2Tausend2Aufrufe2pro2Sekunde2stattfinden.
! Einfachere2DBMS2sparen2sich2deshalb2oftmals2den2Implementierungsaufwand2fr2
die2Zyklussuche2und2brechen2eine2Tx bei2berschreiten2einer2vorgegebenen2
Zeitdauer2(Time2out)2bei2Warten2auf2die2Gewhrung2einer2Sperre2ab.
! Sperrverfahren2erlauben2die2Implementierung2der2eingangs2beschriebenen2
Isolationsstufen.2Wenn2repeatable read2nicht2gefordert2ist,2dann2knnen2z.B.2
reine2LeseZSperren2bereits2vor2dem2COMMIT2wieder2freigegeben2werden\2UpdateZ
Sperren2werden2allerdings2grundstzlich2bis2zum2COMMITZZeitpunkt2gehalten.
! Es2existieren2diverse2Varianten2von2Sperrverfahren,2z.B.2in2Verbindung2mit2
Versionskonzepten.2
Beim2DBMS2Oracle2z.B.2erhalten2Lesetransaktionen2evtl.2eine2frhere2Version2
eines2Tupels,2um2Konflikte2mit2parallel2laufenden2Updatern zu2vermeiden.

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite299

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
Systempufferwaltung und*Logging
DBMSbZugriff*auf*Hintergrundspeicher

Alle2Seitenzugriffe2sowie2die
Verwaltung2des2HintergrundZ
speichers2finden2ber2die2
Systempufferverwaltung2statt

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite2100

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
Systempufferverwaltung
! Zwischenspeicherung2hufig2bentigter2Seiten2im2Hauptspeicher
! Ziel:2Reduzierung2der2Anzahl2von2Plattenzugriffen
! Nur2genderte2Seiten2werden2auf2Platte2zurckgeschrieben
! Typische2SchnittstellenZOperationen:
FIX ( PageNo, Intention, Adress )
UNFIX ( PageNo, Dirty? )
FLUSH ( PageNo )
! Seiten2werden2mit2Zeitstempel2(oder2Zhler)2des2letzten2Zugriffs2versehen
! bliche2Seitenersetzungsstrategie:22LRU2(least2recently used)2bzw.2Varianten2
davon

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite2101

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
Schreiben*von*LogbDatenstzen* (Logging)
!

Aufgaben*der*LoggingbKomponente:*
1. Protokollierung2der2Werte2von2Seiten,2Tupeln oder2TupelZAttributen2vor deren2
nderung2( before image)2durch2die2Tx in2einem Undo<Logfile
2. Protokollierung2der2Werte2von2Seiten,2Tupeln oder2TupelZAttributen2nach2
deren2nderung2(2after2image)2durch2die2Tx in2einem2Redo<Logfile

Aufgaben*der*Systempufferverwaltung:
Sicherstellung,2dass2der2UndoZLogeintrag2einer2Tx stets2vor
dem2Update2der2DBZSeite2ins2Logfile2geschrieben2wird
Sicherstellung,2dass2alle2RedoZLogeintrge2einer2Tx im
RedoZLogfile2stehen,2bevor2der2Tx das2Commit2besttigt2wird

write<ahead
logging
(WAL)

Warum*dieser*Aufwand? Weil2HochleistungsZDBMS
bereits2whrend2der2Ausfhrung2einer2Tx u.U.2bereits2deren2nderungen2in2
DB2schreiben2(andere2Tx sehen2diese2aber2wegen2der2Sperren2noch2nicht)
bei2Commit2kein2erzwungenes2Schreiben2in2die2DB2vornehmen2mchten2und2
deshalb2genderte2Seiten2nach2Commit2u.U.2nur2im2Systempuffer2stehen
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite2102

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
WritebAheadbLogbPrinzip*(WAL2principle)
! Trick:2 Bei2jeder2Seite2im2SP2wird2vermerkt,2in2welcher2Logseite
( LSN,2log2sequence number)2die2letzte2nderung2eingetragen2 wurde
Vor2jeder2Verdrngung2einer2Seite2wird2geprft,2ob2die2Logseite bereits2drauen2ist
! Beispiel:
Die2aktuelle2LogZSeite23812222enthlt2 Updates2der2Seiten25148,24427,223552und27899.
Diese2Seiten2drfen2in2diesem2Fall2erst2dann2aus2dem2SP2verdrngt2werden,2wenn
LSN2>238122gilt,2d.h.2wenn2LogZ
4
Seite238122geschrieben2wurde.
LSN PNo
LSN PNo
3812 7899
3810 1311
Die2Seiten265592u.221222wurden
nicht2verndert2(ihr2LSNZEintrag
2
LSN PNo
LSN PNo
ist2leer)2und2mssen2deshalb2im
3812 4427
6559
Verdrngungsfall2auch2nicht
zurckgeschrieben2werden.
1
LSN PNo
LSN PNo
Die2Seiten213112und27588
3812 5148
3790 7588
wurden2verndert,2ihre2ndeZ
3
LSN PNo
LSN PNo
rungen wurden2aber2auf2bereits
2122
3812
2355
geschriebenen2LogZSeiten
protokolliert.2Damit2knnen2sie
VerwaltungsZ
eigentliche
bei2Platzbedarf2jederzeit2in2die
Information
Datenseite
Systempuffer
DB2zurckgeschrieben2werden.
LSN

3812

1 2

4
Logseiten
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite2103

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
Fehlerbehandlung* (Recovery)
! Aufgaben
Wiederherstellung2eines2konsistenten2DBZZustandes2nach
Transaktionsabbruch

" Transaction2Recovery (Undo)

Systemzusammenbruch2(z.B.2wg.2Stromausfall)22" Crash2Recovery
Hardwarefehlern2auf2Speichermedium

" Media2Recovery

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite2104

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
Crash*Recovery
! Wiederherstellung2eines2konsistenten2Datenbankzustandes,2so2dass2das2Folgende2gilt:
! alle2nderungen2nicht2abgeschlossener2Transaktionen2(ABORT2oder2sonstiger2
Abbruch)2sind2nicht2in2der2Datenbank
! alle2nderungen2abgeschlossener2Transaktionen2(COMMIT2erreicht)2sind2in2der2
Datenbank
! Beispiel2fr2Crash2Recovery

T1

SystemAbsturz

T2
Erforderliche*RecoverybManahmen
nach*dem*Systemabsturz:

T3
T4

UNDO2fr2die2Verlierer:2 T4,2T5
REDO2fr2die2Gewinner:2 T1,2T2,2T3

T5
t

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite2105

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
Aufgaben
1.
2.
3.
4.

Bestimme2den2letzten2geschriebenen2LogZDatensatz22
Bestimme2unvollendete2Transaktionen2(Verlierer):2BOT2in2Logdatei,2 kein2COMMIT
Bestimme2vollendete2Transaktionen2(Gewinner):2COMMIT2in2Logdatei
Lese2Logdatei2 rckwrts,2ermittle2die2UNDOZLogeintrge2der2Verlierer2und2fhre2mit2diesen2ein2
UNDO2durch\2und2zwar2bis2der2Anfang2der2Logdatei2erreicht2ist.
5. Lese2vom2Anfang2der2Logdatei2 her2vorwrts,2ermittle2die2REDO2Logeintrge2 der2Gewinner2und2
fhre2mit22diesen2ein2REDO2durch.
Anmerkung:22Schritte22,23,2und242knnen2beim2Rckwrtslesen2(RWL)2auf2einmal2erledigt2
werden.
Wie?

Ist*der*letzte*Eintrag*einer*Transaktion*in*der*Logdatei
b der*CommitbRecord,*dann*gehrt*sie*zu*den*Gewinnern:*
" Beim*RWL*knnen*alle*ihre*Eintrge*bis*zum*BOTbEintrag*ignoriert*werden.
b ein*anderer*Record (Undob/Redo),*dann*gehrt*sie*zu*den*Verlierern:*
" Beim*RWL*knnen*die*Undos gleich*ausgefhrt*werden.

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite2106

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
Checkpoints* (CPs)
! Recovery bis2zum2Anfang2der2Logdatei2verursacht2natrlich2u.U.2einen2enormen2
Aufwand,2da2dann2fr2sehr2viele2Tx UNDO2bzw.2REDO2durchgefhrt2werden2muss.
! Abhilfe:2Erzeugung2von2CPs2=2Herauszwingen2von2Seiten2aus2dem2Systempuffer
! Zweck:2UNDOZ/REDOZAufwand2im2Recoveryfall begrenzen
! Checkpoint:2 Zeitpunkt,2zu2dem2bestimmte2Annahmen2ber2den2Zustand2der2DB
gemacht2werden2knnen.2
! CPbEintrag*in*die*Logdatei:*
IDs2der2nicht2abgeschlossenen2Tx
Verweis2auf2letzten2Logdatensatz2dieser2Tx
! Verfahrensweisen:
Wenn2keine2Transaktion aktiv2ist2 " transaktionskonsistenter2CP
Wenn2keine2Aktion aktiv2ist22222222222 " aktionskonsistenter2CP

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite2107

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
Beispiel*fr*aktionskonsistenten* CP

Logfile
Sp13
CP13

aktive'T.!
1726! !
1955! !
2101! !

neue'Eintrge

Sp14
CP14

letzte'LSN
10034
11767
10518

aktive'T.'
3814!
4713!
5139!
5277!

!
!
!
!

letzte'LSN
21234
28642
29700
27666

Inwiefern*kann*ein*CP*helfen,*den*Aufwand*fr*Recovery zu*begrenzen?
Redo:

Undo:

Am*CP*werden*alle*genderten*Seiten*in*die*DB*geschrieben.*Somit
muss*nur*ab dem*CP*bis*zum*LogfilebEnde*(bzw.*dem*Commit*der
letzten*GewinnerbTx)*Redo gemacht*werden.
Im2CP2steht2verzeichnet,2welche2Tx zum2CPZZeitpunkt2offen2waren
sowie2der2Zeiger2auf2den2letzten2TxZLogZRecord.2Somit2kann2auf2die
UndoZRecords2der2verbleibenden2Verlierer2gezielt2zugriffen2werden.
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite2108

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

Inhalt

Vorbemerkungen

Beispielfirma LegoTrailer AG

Entwurf des2Datenbankschemas

Implementierung von2Anwendungsfunktionen

Konsistenthaltungsaspekte

Transaktionale Aspekte und2Mehrbenutzerbetrieb

Weiterfhrende Anforderungen an2betriebliche Informationssysteme

Abschlieende Bemerkungen
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite2109

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.7*Weiterfhrende Anforderungen an*betriebliche


Informationssysteme
! Groe2ERPZSysteme2versuchen2alle2betrieblich2relevanten2Daten2und2
Funktionen2in2einem System2anzubieten
!
!
!
!
!
!
!

Materialwirtschaft
Produktion
Buchhaltung2(Debitoren,2Kreditoren,2Anlagen,2Personal,2CashZManagement,2 )
Personalwesen
Gebudeverwaltung
Transportwesen

! Auerdem2Bereitstellung2von2betriebwirtschaftlichen Kennzahlen2und2
Auswertungen2in2unterschiedlichen2Formen

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite2110

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.7*Weiterfhrende Anforderungen an*betriebliche


Informationssysteme

SAP2Business2One Ansicht2eines2Kundenauftrags
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite2111

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.7*Weiterfhrende Anforderungen an*betriebliche


Informationssysteme

SAP2Business2One VerkaufsanalyseZDashboard
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite2112

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.7*Weiterfhrende Anforderungen an*betriebliche


Informationssysteme
! Frher:2Individualsoftware,2gezielt2fr2ein2Unternehmen2entwickelt
! Heute:2Meist2StandardZSoftware,2die2kundenspezifisch2konfiguriert2wird
! Whrung
! Sprache
! Zeitzone
! Aussehen2von2OnlineZFormularen2und2Masken
! Berechtigungen2 zum2Lesen/ndern2auf2Formularen/Masken2bis2hinunter2zur2
Feldebene
! u.v.a.m.

! Hierdurch2im2Laufe2der2Jahre2sehr2komplexe2Systeme2entstanden,2mit
hoher2interner2Komplexitt
hohem2Konfigurationsaufwand

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite2113

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

Inhalt

Vorbemerkungen

Beispielfirma LegoTrailer AG

Entwurf des2Datenbankschemas

Implementierung von2Anwendungsfunktionen

Konsistenthaltungsaspekte

Transaktionale Aspekte und2Mehrbenutzerbetrieb

Weiterfhrende Anforderungen an2betriebliche Informationssysteme

Abschlieende Bemerkungen
2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015

Seite2114

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.8*Abschlieende*Bemerkungen
! ERPZSysteme2sind2aus2dem2heutigen2Wirtschaftsleben2nicht2mehr2weg2zu2denken
! Neben2den2funktionalen2Anforderungen2 sind2Verlsslichkeit,2Robustheit2und2
Fehlertoleranz2wichtige2Kriterien2fr2die2Praxistauglichkeit
! ERPZSysteme2basieren2deshalb2durchweg2auf2(meist2relationaler)2DBMSZTechnologie
! In2groen2Unternehmen2 arbeiten2tglich2hunderte2 bis2tausende2Mitarbeiter2mit2dem2
(zentralen)2ERPZSystem
! Deshalb2effiziente2Realisierung2des2Zusammenspiels2zwischen2ERPZAnwendungsZ
funktionen2und2DBMS2ebenfalls2ein2sehr2wesentlicher2Faktor
! Wie2gesehen,2ist2auch2Konsistenthaltung der2Daten2eine2groe2Herausforderung
! Fr2effizienten2DBMSZEinsatz2im2Mehrbenutzerbetrieb2tiefere2Kenntnisse2ber2DBMSZ
Interna2(Synchronisation,2Logging,2Recovery,2Anfrageoptimierung,2)2erforderlich2
! Die2Kenntnis2bzw.2Nutzung2der2entsprechenden2 DBMSZseitigen2Funktionen2hilft2Fehler2
in2den2Anwendungsfunktionen2 zu2erkennen2und2die2Daten2gegen2 diese2zu2schtzen

2M.2Reichert,2P.2Dadam |2Universitt Ulm2|2SS22015