Datenbankbasierte Implementierung Von Informationssystemen

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
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!
Seite24
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
Seite25
Inhalt
Vorbemerkungen
Seite26
3.2*Beispielfirma*LegoTrailer AG
Inhalt
3.2.1
3.2.2
Produkte,2Einzelteile2und2deren2Verwendung
Anforderungen2an2das2ERPZSystem
Seite27
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
Seite28
3.2.1*Beispielfirma*LegoTrailer AG* Produkte*
AAG
(Aufbauanhnger2geschlossen)
AKK
(Kippanhnger2kurz)
AKL
(Kippanhnger2lang)
Diese2Produkte
gibt2es2in2rot (Farbcode =*1)
und2in2blau (Farbcode =*2)
Seite29
3.2.1*Beispielfirma*LegoTrailer AG* Produkte*
CAH
CKK
(Chassis2Aufbauanhnger)
(Chassis2Kippanhnger2kurz)
FG
(Fahrgestell)
CKL
Diese2Produkte
gibt2es2in2rot (Farbcode =*1)
und2in2blau (Farbcode =*2)
(Chassis2Kippanhnger2lang)
Seite210
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)
Seite211
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
Seite212

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
Seite213

FG*(Fahrgestell)
FG
f
f2 {21,222}
4
FA
f
2
K28
0
2
KR24
0
4
P24
0
RF
0
Seite214

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
Seite215

CKK*(Chassis*Kippanhnger* kurz)
CKK
f
1
FG
f
GO25
0
GU25
0
GV25
0
K16
f
1
P616
0
PZ
0
Seite216

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
Seite217
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.
Seite218
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.
Seite219
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.
Seite220
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.
Seite221
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
Seite222
Inhalt
Vorbemerkungen
Seite223
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)
Seite224
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
Seite225
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
Seite226
!
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
Seite227
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.
Seite228
!
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
Seite229
!
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
Seite230
!
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
Seite231
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
Seite232
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
Seite233
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
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
! 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
Seite234
! Alternative*2:**Zusammenfassung* logischer*Relationen
Beobachtung:
1
Auftrag
AuftrNr,2KdNr, AuftrDatum,2Erfassungsdatum,2AuftrStatus,2LgLieferung,
AuftrAnFertigung,2 FertigungBeendet,2 WareAusliefBereit,2AusliefDatum,
Rechnungsstatus,2Rechnungsdatum,2Zahlungseingang
AuftragsPos
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
Relationen2 1,22und23 knnen2als2Spezialisierungen2 eines2gemeinsamen2 (abstrakten)2Supertyps2

aufgefasst2werden\2sie2reprsentieren2unterschiedliche2Zustnde2eines2Auftrags2
mgliche2(physische)2Speicherung2in2einer Relation
Analog:2Relationen2 4,252und26.2Auch2hier2mgliche2Speicherung2in2einer (physischen)2Relation.
Seite235
Einschub:*Abbildung*von*ISAbBeziehungen*
PersNr
Name
Abt
Adresse
Gehalt
Mitarbeiter
UBIst
Verkufer
UBSoll
Ttigkeit7=
"Schreibkraft"
Anschlge
Ttigkeit7=
"Mechaniker"
Fremdspr
Ttigkeit7=
"Verkufer"
Schreibkraft
Zustndig
Mechaniker
Seite236
!
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
Seite237
!
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))
Seite238
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)
Seite239
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
Seite240
3.3.3**Realisiertes*Schema*fr*LegoTrailer AG
Relation*AuftragsDS
Seite241
Seite242
Relation*AuftragsPosDS
Details2siehe
LegoTrailerZSchemaZ*.sql
Seite243
(Forts.)
Seite244
Seite245
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
Seite246
! 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
Seite247
! Ergnzende*Materialien
(integraler*Bestandteil*von*Vorl.*+*b.)
LegoTrailerbSchemab2015bgefllt.sql
Seite248
Inhalt
Vorbemerkungen
Seite249
3.4*Implementierung*von*Anwendungsfunktionen
! Vorbemerkung
! In2Ergnzung2zu2den2bungen2 im2Folgenden2 exemplarische2
Konkretisierung2einiger2Anwendungsfunktionen2 des2ERPZSystems2
der2LegoTrailer AG
! Ziel2ist,2bezglich2Datenbankanfragen2 alternative2Lsungen2zu2
diskutieren2und2den2Anwendungsnutzen2 weiterfhrender2SQLZ
Funktionen2aufzuzeigen
! Die2weitergehenden2 SQLZFunktionen2behandeln2 wir2dann2im2
nchsten2Kapitel
Seite250
! 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
Seite251
! 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
Seite252
! 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)
Seite253
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
Seite254
Problem:*
Naive*Anfrageformulierung
fhrt*zu*einer*komplexen
Anfragebearbeitung*
SQLbAusfhrungsplan* von*
IBM*DB2 fr*obige*Anfrage
Seite255
! 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)
Seite256
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
Seite257
! 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
Seite258
Inhalt
Vorbemerkungen
Seite259
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
Seite260
! 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
Seite261
! 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
Seite262
! DBMSbseitige*aktive*Konsistenzsicherung
! Das2DBMS2verhindert2Inkonsistenzen2dadurch,2dass2es2bei2einer2
nderungsoperation2 auf2einer2Tabelle2selbststndig2die2entsprechenden2
nderungsoperationen2 auf2den2abhngigen2 Tabellen2durchfhrt
! Mittel:*
! CREATE2TABLE22REFERENCES222ON2DELETE2CASCADE
! CREATE2TABLE22REFERENCES22ON2UPDATE2CASCADE
! CREATE2TRIGGER2
! Zusammenfassung
! Konsistenthaltung von2Daten2in2groen2IS2eine2sehr2groe2Herausforderung
! Konsistenzsicherung2alleine2mittels2Anwendungsprogrammen2 ist2fahrlssig
! Wo2immer2mglich,2Konsistenzsicherung2ins2DBMS2integrieren2(passiv2oder2
aktiv)!
Seite263
Inhalt
Vorbemerkungen
Seite264
3.6*Transaktionale*Aspekte*und*Mehrbenutzerbetrieb
Inhalt
! Allgemeines
! Transaktionskonzept
! Serialisierbarkeitsprinzip
! Allgemeines2zur2Synchronisation2(Concurrency Control\2CC)
! Sperrverfahren
! Systempufferwaltung und2Logging
!
Fehlerbehandlung2 (Recovery)
Seite265
! 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
Seite266
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
Seite267
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
Seite268
! Probleme*/*Fragestellungen
! Welche2aller2mglichen2berlappenden2Ausfhrungen2fhren2zu2
einem2korrekten2Resultat?
! Was2heit2berhaupt2korrektes2Resultat2bei2konkurrierenden2
nderungen?
! Wie2erkennt2und2vermeidet2man2unerwnschte2(d.h.2nicht2
korrekte)2Ausfhrungsreihenfolgen?
! Wie2geht2man2mit2nicht2vollstndig2ausgefhrten2nderungen2
(z.B.2wegen2Programmabbruch2oder2Systemcrash)2um?
Seite269
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)
Seite270
AP1
Wert2im
Haupt<
speicher
Wert2auf
Hintergrund<
speicher
AP2
Wert2im
Haupt<
speicher
2 x
AP1:2 AP2:2
lese(x) lese(x)
Zeit
Seite271
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
Seite272
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
Seite273
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
Seite274
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
Seite275
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)
Seite276
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
Seite277
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)
Seite278
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
Seite279
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
Seite280
! 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.
Seite281
! 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)
Seite282
! 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?
Seite283
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.
Seite284
! 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.
Seite285
! 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]
Seite286
! 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
Seite287
! 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
Seite288
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
Seite289
! 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.
Seite290
! 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
Seite291
! 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.
Seite292
! Implementierung
! (Zentrale)2Sperrtabelle2mit2Sperrverwalter2(Lock2Manager)
! Sperrverwalter2/2Sperrtabelle2liegen2in2einem2kritischen2Abschnitt
" exklusiver2Zugriff2fr2die2jeweilige2Tx
! Anfragebearbeitung2 ruft2Sperrverwalter2(lock2manager)2zum2Anfordern2/2
Freigeben2 von2Sperren
! Bei2Nichtgewhrung2 der2Sperre2vorbergehende2 Suspendierung2 der2
Transaktion2durch2den2Sperrverwalter2bzw.2den2Scheduler2des2DBMS
Seite293
! 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.
Seite294
Das*ZweibPhasenbSperrprotokoll* *(Forts.)
Typischer2Verlauf2einer2Transaktion2mit22PLZSynchronisation:
lock2all<Zeitpunkt
#2gesperrte
Objekte
Sperrphase
Freigabephase
Zeit
Seite295
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
Seite296
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).
Seite297
! 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
Seite298
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.
Seite299
Systempufferwaltung und*Logging
DBMSbZugriff*auf*Hintergrundspeicher
Alle2Seitenzugriffe2sowie2die
Verwaltung2des2HintergrundZ
speichers2finden2ber2die2
Systempufferverwaltung2statt
Seite2100
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
Seite2101
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
Seite2102
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
Seite2103
Fehlerbehandlung* (Recovery)
! Aufgaben
Wiederherstellung2eines2konsistenten2DBZZustandes2nach
Transaktionsabbruch
" Transaction2Recovery (Undo)
Systemzusammenbruch2(z.B.2wg.2Stromausfall)22" Crash2Recovery
Hardwarefehlern2auf2Speichermedium
" Media2Recovery
Seite2104
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
Seite2105
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.
Seite2106
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
Seite2107
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.
Seite2108
Inhalt
Vorbemerkungen
Seite2109
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
Seite2110

Informationssysteme
SAP2Business2One Ansicht2eines2Kundenauftrags
Seite2111

Informationssysteme
SAP2Business2One VerkaufsanalyseZDashboard
Seite2112

Informationssysteme
! Frher:2Individualsoftware,2gezielt2fr2ein2Unternehmen2entwickelt
! Heute:2Meist2StandardZSoftware,2die2kundenspezifisch2konfiguriert2wird
! Whrung
! Sprache
! Zeitzone
! Aussehen2von2OnlineZFormularen2und2Masken
! Berechtigungen2 zum2Lesen/ndern2auf2Formularen/Masken2bis2hinunter2zur2
Feldebene
! u.v.a.m.
! Hierdurch2im2Laufe2der2Jahre2sehr2komplexe2Systeme2entstanden,2mit
hoher2interner2Komplexitt
hohem2Konfigurationsaufwand
Seite2113
Inhalt
Vorbemerkungen
Seite2114
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

Datenbankbasierte Implementierung Von Informationssystemen

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Datenbankbasierte Implementierung Von Informationssystemen

Enviado por

Direitos autorais:

Formatos disponíveis

Informationssysteme

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

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

Transaktionale Aspekte und2Mehrbenutzerbetrieb

Weiterfhrende Anforderungen an2betriebliche Informationssysteme

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

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

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

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

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

Transaktionale Aspekte und2Mehrbenutzerbetrieb

Weiterfhrende Anforderungen an2betriebliche Informationssysteme

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

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

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

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

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.2.1*Beispielfirma*LegoTrailer AG* Produkte*

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

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.2.1*Beispielfirma*LegoTrailer AG* Produkte*

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

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.2.1*Beispielfirma*LegoTrailer AG* Einzelteile

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

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.2.1*Beispielfirma*LegoTrailer AG* Gozintographen

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

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.2.1*Beispielfirma*LegoTrailer AG* Gozintographen

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

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.2.1*Beispielfirma*LegoTrailer AG* Gozintographen

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

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.2.1*Beispielfirma*LegoTrailer AG* Gozintographen

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

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.2.1*Beispielfirma*LegoTrailer AG* Gozintographen

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

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

3.2.1*Beispielfirma*LegoTrailer AG* Gozintographen

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

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

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

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

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

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

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

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

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

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

Transaktionale Aspekte und2Mehrbenutzerbetrieb

Weiterfhrende Anforderungen an2betriebliche Informationssysteme

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

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

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

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

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

LegoTrailer verwaltet2zu2jedem2Kunden2eine2Kundennummer2 sowie2den2Namen,2die2Stadt2sowie2

Informationssysteme2|2Kapitel 3:2Datenbankbasierte Implementierung von2Informationssystemen

LegoTrailer liefert2seine2Artikel2im2Allgemeinen2 nach2Preisliste.2Wurden2mit2einem2 Kunden2ein2

LegoTrailer verwaltet2zu2jedem2Lieferanten2 seine2Lieferantennummer2 sowie2den2Namen,2die2Stadt2

3.2.1BeispielfirmaLegoTrailer AG* Produkte*

3.2.1BeispielfirmaLegoTrailer AG* Produkte*

3.2.1BeispielfirmaLegoTrailer AG* Einzelteile

3.2.1BeispielfirmaLegoTrailer AG* Gozintographen

3.2.1BeispielfirmaLegoTrailer AG* Gozintographen

3.2.1BeispielfirmaLegoTrailer AG* Gozintographen

3.2.1BeispielfirmaLegoTrailer AG* Gozintographen

3.2.1BeispielfirmaLegoTrailer AG* Gozintographen

3.2.1BeispielfirmaLegoTrailer AG* Gozintographen

InterneRealisierungsalternativen imklassischen RelationenbModell

InterneRealiserungsalternativen imklassischen* RelationenbModell

WHERE a.AuftrNr =15AND