ibm db2 - s.k. consulting und p… · db2 – logisches design: die ressource „information“...

1 Juni 2012

DB2 DB2 –– DatenDaten--Design und PerformanceDesign und Performance

IBM IBM DB2DB2

(*)

(*) ist eingetragenes Warenzeichen der IBM International Business Machines Inc.

2 Juni 2012

DB2 DB2 –– DB2 Design und PerformanceDB2 Design und Performance

Kapitelinhalt

Der logische Designprozess Der logische Designprozess und und PerformancePerformance

• Voraussetzungen für Datenbank-Performance

• Leistungsbeeinflussende Faktoren

• Analyse und logisches Datendesign

• Vorgehensweise & Einbetten in ein Methodenkonzept

• Tips zur Steigerung der Performance

• Do‘s & Dont‘s

Der physische Designprozess und PerformanceDer physische Designprozess und Performance

• Voraussetzungen für (DB2)-Performance

• Überführen des LDM in ein effizientes PDM

• Datentypen

• Denormalisierungsmuster

• Indexdesign und Performance

Physisches Design bei DB2Physisches Design bei DB2

• TS Typen bei DB2

• Table-Typen bei DB2

• Indextypen bei DB2

Und wie geht es weiter ?Und wie geht es weiter ?

3 Juni 2012

Intro - Performance

1. Es ist bekannt, dass Tuning- und Performance-Massnahmen auch bei

relationalen Systemen bis auf die Applikationsentwicklung wirken.

2. Es gilt auch hier, dass die ineffiziente Nutzung von Systemressourcen durch ein

Anwendungsprogramm über systemtechnische Einstellungen nicht korrigiert werden kann.

3. Entwickler müssen deshalb:

Verständnis für die Internas der DB2-Umgebung besitzen

ein tiefes Wissen über DB2-Tuning-Ansätze und Optimizer-

Verhalten haben

Trotzdem gilt:

Das Fundament für gute Performance kann nur über entsprechende

Maßnahmen beim System-Design in Daten- und Funktionsentwurf erreicht

werden


4 Juni 2012

1. Methodeneinsatz und Modellierung

2. Technologie-Einsatz(HW & Systemsoftware)

Hoher Komfort verlangt nach hohem Ressourceneinsatz. Dennoch sollen die Ressourcen

angemessen sein. Übergrosse Schuhe behindern beim Laufen ebenso wie zu kleine....

Dabei ist es entscheidend, dass auf keiner der unterschiedlichen Ressourcen- und Technologieebenen

Engpässe auftreten.


3. DB2- Systemtechnische Massnahmen

• Optimierung der Generierungsparameter für DB2 (BP, DBM- und DB-PARMS etc.)

• Festlegung der Optionen für physische DB2-Objekte (TS-Typen, Tabellentypen, IX…)

• Re- bzw. Umorganisation der physischen Datenspeicherung (Partitionieren, „clustern“….)

• Beeinflussung des DB2-Zugriffspfades durch Manipulation von Katalog-Statistik-Spalten.

• Permanente Überwachung des Systemverhaltens, Starten von Utilities, wie z.B. RUNSTATS

• Durchführung gezielter BIND/REBIND-Maßnahmen.

4. anwendungsbezogene Massnahmen

• logische und physische Datenmodellierung mit Festlegung der Benutzer-DB2-Objekte (auch

Denormalisierung, falls erforderlich).

• SQL und Einsatzentscheidungen für:Tabellen, Views, Synonyme und Aliase.

• Veränderungen der Datenablage mit Auswirkung auf die logische Ebene (z.B. Aufteilen langer Zeilen,

Kompression, Änderung von Datentypen).

• Festlegung von Prozeduren, UDF‘s, „stored procedures“ und Triggern.

5 Juni 2012


Die Erreichung der Tuningziele bei DB2 verlangt nach komplexen

und aufeinander abgestimmten Maßnahmen

1

2

3

4

3 = 3 = log./physlog./phys..

DBDB--Design Design

(20%)(20%)

2 = DB2 2 = DB2

System System

(10%)(10%)

1 = OS 1 = OS

System System

(10%)(10%)

4 = Anwendung 4 = Anwendung

(60%)(60%)

3 = 3 = log./physlog./phys..

DBDB--Design Design

(20%)(20%)

2 = DB2 2 = DB2

System System

(10%)(10%)

1 = OS 1 = OS

System System

(10%)(10%)

4 = Anwendung 4 = Anwendung

(60%)(60%)

6 Juni 2012

DB2 DB2 –– DB2 logisches Design (Methode)DB2 logisches Design (Methode)

Kapitelinhalt











• Datentypen








7 Juni 2012

DB2 DB2 –– logisches Design: Die Ressource „Information“logisches Design: Die Ressource „Information“

Information als Ressource: Der INFORMATIONSFLUSS im Unternehmen

8 Juni 2012


Information als Ressource: Der INFORMATIONSFLUSS im Unternehmen

Beispiel:

• Strategische

• Dispositive

• Operative

Ziel der Informationsanalyse ist das Sicherstellen des Informationsflusses → vertikal

→ horizontal

→ innerhalb des Unternehmens

→ mit der Außenwelt

Unternehmens-

funktionen

9 Juni 2012


Ziel der Informationsanalyse: Neue Anforderungen an die Datenhaltung

Unterstützung traditioneller DV-Verfahren d.h. standardisierte (zunehmend dialogisierte) Verfahren, die die

operative "Grundlast "des Unternehmens repräsentieren

Forderungen an die Informationsverarbeitung

aus Sicht des Anwenders

• gleichzeitiger Zugriff auf gemeinsame Datenbestände über zahlreiche

Verfahren und Anwendungen

• Vermeiden von Abstimmungs- und Anpassungsprozessen

• aktuelle Informationen für alle Applikationen

• Vermeiden von Widersprüchen und Fehlern in den Daten

aus Sicht der IV-Abteilung

• Rationalisierung von Software-Entwicklung und -Wartung

• Trennung logischer und physischer Datenhaltung

• anwendungsneutrale Datenstrukturen, die für alle Applikationen

gleichermaßen geeignet sind

• “Trennung von Programm und Daten” ( -> Problem "alter" DBMS )

• Verwaltung der Daten und Informationen in einem Datenkatalog

( → “Datadictionary” / "Repository" ... )

• Änderungen der Datenstruktur ohne Auswirkung auf bestehende

Anwendungssysteme

vom Endbenutzer zur Unterstützung der unternehmensweiten IT

• Überblick über die Unternehmensdaten

• Zugang zu aktuellen Unternehmensdaten

• flexible und “ad hoc” Auswertungen über vorhandene Informationen

• Verdichtung und Zusammenführung von “verstreuten” Unternehmensdaten

• Individuelle Datenverarbeitung und „data warehousing“

10 Juni 2012


Anforderungen an unternehmensweite Informationssysteme

aus Sicht des Endbenutzers

einfacher Zugriff

hohe Flexibilität

Arbeitsweise: spontan - kreativ

aus Sicht der traditionellen Anwender betriebswirtschaftlicher

Standardverfahren

hohe Belastbarkeit

kurze Antwortzeiten

Arbeitsweise: geführt - reaktiv

Ziel: ... alle Aufgaben gleichermassen lösen können

11 Juni 2012


Strategie der Informationsplanung

Unternehmensweites Informationsmodell

Informationsverarbeitung

Organisation

Information

Datenbank System

Funktion(BP)

physisch

logisch

12 Juni 2012


Grundelemente der Informationsbe- und verarbeitung

Informationen

Funktionen(BP)

Voraussetzung für eine erfolgreiche

Informationswirtschaft ist:

alle INFORMATIONEN in einem

geordneten "Lager„

Auf das die (Business-) Prozesse

gezielt zugreifen können

Programme, Skripte,

Funktionen

Datenbanken,

Files, etc. ♦ KUNDE

♦ VERKÄUFER

♦ AUFTRAG

♦ RECHNUNG

♦ ZAHLUNG

♦ ARTIKEL

♦ LIEFERANT

♦ LAGER

o Auftrag annehmen

o Bestellung schreiben

o Rechnung erstellen

o Zahlungseingang überwachen

o Artikellager kontrollieren

o Artikel bestelle/produzieren

o Lieferung zusammenstellen

o Provision abrechnen

13 Juni 2012


Anforderungen an Information und Informationsstruktur

Eigenschaften der Ressource INFORMATION

genau und vollständig

bedeutungsvoll und entsprechend (dem Benutzerbedürfnis)

aktuell und verlässlich

verständlich

kurz und zutreffend

zugänglich

Eigenschaften einer Konzeptionellen Datenstruktur

umfassend

vollständig (realitätsgemäß)

widerspruchsfrei

anwendungsneutral

systemneutral

stabil

flexibel

14 Juni 2012


Informationen und betriebliche Prozesse(Funktionen) müssen bedarfsorientiert verfügbar sein….

(1) Schritt: Analyse der Informationen

welche Informationen gibt es ?

welche Bedeutung haben sie ?

ZIEL: Schaffen einer EINDEUTIGEN, KLAREN Begriffswelt für die gesamte

betriebliche Informationsumgebung

(2) Schritt: Analyse der Funktionen

welche Funktionen gibt es ?

wie laufen sie ab: Informationsflüsse / Steuerflüsse ?

welche Informationen verwenden/erzeugen sie ?

ZIEL: Eine bedarfsorientierte Ablauforganisation für alle betrieblich relevanten

Funktionen

15 Juni 2012


Redundanzfreiheit, Zuverlässigkeit und Aktualität verlangen nach Datenintegration…

.... klare eindeutig definierte

Informationsbegriffe und

Informationszusammenhänge

16 Juni 2012


Datenintegration…

(Daten-)Integration heißt

Prüfung

Abstimmung und

Einarbeiten neuer Daten und Datenstrukturen in ein (bereits bestehendes)

"gemeinsames" Informationsmodell

Datenintegration verlangt ein GEMEINSAMES Verfahren bei der

Festlegung der Bedeutung der Daten in ihrem betrieblichen Kontext

Strukturierung der Daten

Beschreibung der Daten

Festlegung der Anforderungen an die IV-bezogene

Implementierung der Daten

… nur so können auch neue Anforderungen an eine moderne

Informationsumgebung (hier: DWH)erfüllt werden

http://www.iwi.uni-hannover.de/lv/seminar_ws03_04/www/Sandner/webseite/grafiken/3d-matrix.gif

17 Juni 2012

DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM

WIE entsteht ein konzeptionelles Datenmodell ?

Schritt 1: Abgrenzung einer “Mini”-Welt

→ auf der Basis: Anforderungskatalog

Schritt 2: Informationsanalyse = statisches Modell der “Mini”-Welt

(Welche Informationen gibt es und wie stehen sie in Beziehung zueinander ?)

Beispiel: → Ein KUNDE hat eine LIEFERADRESSE,

→ ein KURSTEILNEHMER hat einen NAMEN, eine TEILNAHMEABSICHT, eine BUCHUNGSNUMMER

...

DAMIT einher geht

Schritt 3: Funktionenanalyse / Prozessanalyse = dynamisches Abbild der “Mini”-Welt

(Welche Anwender führen welche Funktionen/Prozesse aus ? - Welche Anwendungen/Funktionen benötigen welche

Informationen in welcher Zusammensetzung ? )

Schritt 4: Qualitätssicherung = Abstimmung der Ergebnisse aus Informations- und Funktionenanalyse

Zweck: Prüfung auf VOLLSTÄNDIGKEIT und WIDERSPRUCHSFREIHEIT

Schritt 5: Dokumentation und Visualisierung von INFORMATIONSSTRUKTUR (IS) und FUNKTIONS-

STRUKTUREN (F-S, KOM-S, KON-S)

Zweck: Eine für alle Beteiligten einheitliche und allgemein verständliche Kommunikationsbasis

18 Juni 2012


Das Sichtenmodell der Systementwicklung

d.h. Integration von

Wissen

Methode und

Toolunterstützung

19 Juni 2012


…. Manche Informationen sind GOLD wert….

20 Juni 2012


Das Problem: INFORMATION ist in ihren Vorkommenstypen SUBJEKTIV !

... deshalb:

... kann es eine

GENERELLE (allgemeine) LÖSUNG

der Informationsverarbeitung für alle

Unternehmen NIEMALS geben !?

21 Juni 2012



Das eigentliche Problem der SE-Analyse-Methoden besteht darin, theoretische Ansätze in

praxisgerechte Lösungen umzusetzen.

Ein Problem, das im Bereich der Informationstechnologie durch das Entwicklungstempo der

Märkte und der Technik und somit der Unternehmensorganisationen weiter verschärft wurde

und immer noch wird ...

Ziel: INNOVATIONEN verfügbar machen !

22 Juni 2012



niemand interessiert ALLES ...

jedes Unternehmen bildet nur SEINEN

relevanten Ausschnitt der realen Welt ab....

23 Juni 2012



23

Beispiel

Kunden

Kredite

????

Spareinlagen

Bank

Weinhandlung

Winzer

Kunden

?????

Weine

Anbaugebiete

24 Juni 2012


Theoretische Ansätze zur Informationsanalyse…

Relationen-Modell "entity-relationship"-Modell

Historie

Zielsetzung

Definitionen und Darstellungsformen

Top Down:

Erkennen von Objekttypen,

Bilden von Beziehungen, Erkennen von

Elementarattributen

Historie

Zielsetzung

Definitionen und Darstellungsformen

Bottom Up:

Sammlung von Einzelattributen,

Erkennen von potentiellen Schlüsseln,

Gruppieren zu Objekttypen,

Bilden von Beziehungen (Sonderform: Kanonische

Synthese)

25 Juni 2012


Das Relationenmodell….

Dr. E. F. Codd beschrieb das Relationenmodell erstmalig

1970 im Auftrag des IBM-Laboratory San José

seither zahlreiche theoretische Untersuchungen und praktische

Implementierungsversuche ( z. B. SYSTEM / R )

seit 1984 SQL/DS

seit 1986 DB2 von IBM

26 Juni 2012



Zielsetzung:

Beschreibung der Informationsstrukturen in Form eines mathematischen Modells

Anwendung mathematischer Operationen zur Manipulation definierter und sauber

strukturierter Informationen

Konzept für die technische (physische) Implementierung

Was ist eine RELATION

Annahme:

Seien M1, M2, .... , Mn die Datenelemente (-typen) einer Datenbank (Attributmengen)

Definition:

Jede Teilmenge des kartesischen Produkts M1 x M2 x .... x Mn = {(a1, a2, ... an) ! ai c Mi ) }

stellt eine Teilmenge R c M1 x M2 x .... x Mn dar und heißt n-stellige RELATION über den

Mengen

M1 , M2 , .... , Mn.

Dabei ist n der Grad der Relation R.

27 Juni 2012



II. Zielsetzungen und Absicht des RM II. Zielsetzungen und Absicht des RM

Unabhängigkeit des Datenmodells von Aspekten der Implementierung und der physischen

Realisierung

gemeinsame , einfach strukturierte Benutzerschnittstelle für die unterschiedlichsten (End-)

Benutzer

einfache Datenstrukturdarstellung in Form von TABELLEN (® Relationen / "relations" )

keine Unterscheidung von Objekt und Beziehung

Mächtige Datenmanipulation (mengenorientiert)

MITARBEITER (PERSNR, NAME, PLZ, WOHNORT)

MITARBEITER PERSNR NAME PLZ WOHNORT

4711 Meyer 80231 München

5011 Huber 80122 Ottobrunn

6122 Kraus 89013 Augsburg

Eine RELATION wird dargestellt in Form einer 2-dimensionalen TABELLE

III. Darstellung von Relationen III. Darstellung von Relationen

28 Juni 2012



IV. Beziehungen zwischen Relationen IV. Beziehungen zwischen Relationen

Beziehungen zwischen Relationen werden ebenfalls als RELATION dargestellt

Beispiel: “Ein MITARBEITER kann in einem oder mehreren PROJEKT EN mitarbeiten”

MITARBEITER ( PERSNR, NAME, PLZ, WOHNORT )

PROJEKT ( PRJNR, PROJEKT-BEZ, P-LEITER, ... )

PROJ-MITARB ( PRJNR, PERSNR, STUNDEN )

PROJ-MITARB PRJNR PERSNR STUNDEN

110 4711 10

210 4800 8

180 4711 2

340 5011 6

Attribut einer Beziehung

29 Juni 2012



V. Daten sind als 2-dimensionale Tabellen organisiert V. Daten sind als 2-dimensionale Tabellen organisiert

Eigenschaften von Tabellen (“flat file”):

Spaltenhomogenität alle Einträge einer Spalte haben dieselbe Bedeutung

Eindeutigkeit der Zeilen alle Zeilen sind voneinander unterscheidbar

interpretationsfreie keine internen Strukturen (positionsabhängige Bedeutungen)

Strukturen multiple Felder

Garantierte Zugriffe eindeutige Identifikation der Zeilen über Primärschlüssel und Rückgabe der

gewünschten Informationsmenge ohne Rücksicht auf die physische

Strukturierung der Daten Indizes usw.

Daten (mindestens) in 3. Normalform

RELATION : TABELLE, TABLE, Datenmenge

TUPEL : ZEILE, ROW, Datensatz

ATTRIBUT : SPALTE, COLUMN, Datenattribut

Analoge Begriffe:

30 Juni 2012



VI. Adressierung der Daten aufgrund ihres Inhalts VI. Adressierung der Daten aufgrund ihres Inhalts





SELECT NAME, PLZ, WOHNORT

FROM MITARBEITER

WHERE PLZ BETWEEN 8000 AND 8999

OR WOHNORT = "Salzburg"

Die Reihenfolge der Zeilen ist bedeutungslos keine

positionsabhängige Bedeutung

Zugriff aufgrund der Dateninhalte feldweise Adressierung

Verknüpfte Zugriffsbedingungen

Ergebnis: immer eine DATENMENGE !

31 Juni 2012



VII. Keine Strukturinformationen in den Daten VII. Keine Strukturinformationen in den Daten

Logische Beziehungen zwischen den Daten und Tabellen werden aufgrund korrespondierender

Inhalte dynamisch dargestellt (PK – FK Beziehungen).





PROJ-MITARB PRJNR PERSNR STUNDEN

110 4711 10

210 4800 7

180 4711 2

340 5011 6

Operation : (natural) JOIN

32 Juni 2012



VIII Vorteile des relationalen Modells

leicht zu verstehen (Tabellenstruktur)

“schnell” zu konzipieren und zu implementieren

verlangt eine “saubere” Datenstruktur

einfache, mächtige DML

standardisierte Sprachumgebung (SQL - ANSI-Standard)

vorhersagbare Ergebnisse aus jedem System, das diesem Standard folgt (SQL)

alle Informationen werden über Inhalte dargestellt und verwaltet

hohes Maß an Datenunabhängigkeit

Performance bei Mengenverarbeitung

33 Juni 2012



IX NORMALISIERUNG - der Weg zur "sauberen" Datenstruktur im Relationenmodell

unnormalisierte & normalisierte Relationen

1NF Relationen

2NF Relationen

3NF Relationen

BCNF Relationen

4NF Relationen

5NF Relationen

34 Juni 2012



IX NORMALISIERUNG – Die unnormalisierte Form von Daten (UNF)

.

AUF_NR ADAT KNR K_NAME K_PLZ K_ORT P_NR P_NAME ME PREIS

4711 1.1.91 1001 Meyer 7500 Karlsruhe 1200 Teil A 5 345,--

4711 1.1.91 1001 Meyer 7500 Karlsruhe 1500 Teil C 2 299,--

4711 1.1.91 1001 Meyer 7500 Karlsruhe 1420 Teil X 8 123,--

4800 2.3.91 1551 Müller 6800 Mannheim 1800 Teil Z 7 154,--

4800 2.3.91 1551 Müller 6800 Mannheim 1700 Teil Y 3 154,--

2814 9.9.91 2999 Klein 6800 Mannheim 1000 Teil M 6 189,--

2814 9.9.91 2999 Klein 6800 Mannheim 1000 Teil M 9 192,--

2816 8.8.91 2999 Klein 6800 Mannheim 1200 Teil A 3 345,--

3210 7.7.91 0111 Ludwig 8000 München 1200 Teil A 9 345,--

Was kennzeichnet also eine UNNORMALISIERTE RELATION ?

In einer UNF-Relation sind Mengen als Attributwerte zulässig. Das bedeutet,

daß unter Umständen für einen TUPEL in einem ATTRIBUT mehrere Werte-

ausprägungen existieren können.

35 Juni 2012



IX NORMALISIERUNG – Die unnormalisierte Form von Daten (UNF)

. Unnormalisierte Form (UNF nicht NF2)

Nachteile:

1. Handhabung von UNF-Tabellen ist umständlich

- die Anzahl der Attributelemente variiert von Zeile zu Zeile...

- DML-Funktionen können einfacher implementiert werden, wenn sichergestellt ist, daß die

Anzahl der Elemente für alle Tupel einer Relation identisch ist

2. UNF-Tabellen weisen Datenredundanz auf

- weil ein KUNDE mehr als EINEN AUFTRAG vergibt

- die Feststellung, daß ein KUNDE nur EINEN Namen hat, führt dazu, bei der entspr. KNR

immer denselben Namen mitaufzuführen

3. Datenredundanz besitzt unangenehme Eigenschaften

- höhere Speicherbelegung ( ohne qualitative Informationsverbesserung )

- Anomalien in den Modifikationsoperationen bei der Informationsmanipulation

- die Gefahr von Dateninkonsistenzen

36 Juni 2012



IX NORMALISIERUNG – Die 1. Normalform (NF1)

Die 1NF ist erreicht, wenn jedes Attribut der RELATION nur EINFACHE (keine mengenmäßigen)

Attributwerte mehr hat, d.h. jedes Attribut besitzt genau einen zugehörigen Attributwert

AUFTRAG

AUFNR KNR ADAT KNAME K_PLZ K_ORT

4711 1001 1.1.91 Meyer 7500 Karlsruhe

4800 1551 2.3.91 Müller 6800 Mannheim

4801 2814 9.9.91 Klein 6800 Mannheim

3210 0111 7.7.91 Ludwig 8000 München

5100 1001 ..... ..... ..... .....

A_POSITION

AUFNR P_NR P_NAME ME P_PREIS

4711 1200 Teil A 5 345,--

4711 1500 Teil C 2 299,--

4711 1420 Teil X 8 123,--

4800 1800 Teil Z 7 154,--

2814 1000 Teil M 6 189,--

2814 1000 Teil M 9 192,--

2816 1200 Teil A 3 345,--

3210 1200 Teil A 9 345,--

37 Juni 2012




Die 2NF ist erreicht, wenn

die 1. Normalform erreicht ist

jedes Attribut vom gesamten "Schlüsselwert„ abhängt

nicht aber von Schlüsselteilen ( = funktionale Abhängigkeit )

A_POSITION

AUFNR P_NR ME P_PREIS

4711 1200 5 345,--

4711 1500 2 299,--

4711 1420 8 123,--

4800 1800 7 154,--

2814 1000 6 189,--

2814 1000 9 192,--

2816 1200 3 345,--

3210 1200 9 345,--

PRODUKT

P_NR P_NAME E_PREIS

1000 Teil M 109,--

1200 Teil A 245,--

1500 Teil C 199,--

1420 Teil X 83,--

1700 Teil Y 104,--

1800 Teil Z 104,--

38 Juni 2012






jedes Attribut nur und ausschließlich vom "Primärschlüsselattribut„ abhängt

( = keine transitive Abhängigkeit )

A_POSITION

AUFNR POS_NR P_NR ME P_PREIS

1001 1 1200 5 13,50

1001 2 1500 2 22,80

2333 1 1420 8 18,22

4328 1 1800 7 45,90

4444 1 1700 3 88,90

1002 1 1000 6 17,90

1400 1 1000 6 17,90

1400 2 1200 3 13,50

1345 1 1200 9 13,50

KUNDE

KNR K_NAME K_PLZ K_ORT

0111 Ludwig 8000 München

1001 Meyer 7500 Karlsruhe

1551 Müller 6800 Mannheim

2999 Klein 6800 Mannheim

AUFTRAG

AUF_NR ADAT

4711 1.1.91

4800 2.3.91

2816 8.8.91

3210 7.7.91

2814 9.9.91

?

39 Juni 2012






die Relation keine mehrwertigen Abhängigkeiten mehr aufweist

( = keine unabhängige komplexe Assoziationen )

PRODUZIERT ( KNR, PNR ) GIBT_RABATT ( KNR, RABATT )

KUNDE PRODUKT

RABATT gibt

produziert

K_PR_RABATT

KNR P_NR RABATT

4711 1200 10

4711 1500 10

4711 1200 12 < natürlicher JOIN >

4711 1500 12

4800 1420 12

4800 1420 15

4800 1800 12

4800 1800 15

40 Juni 2012






die Relation unter KEINEN Umständen durch Verschmelzung EINFACHERER Relationen mit

unterschiedlichen Schlüsseln (re-)konstruierbar ist

K_PR_RABATT

KNR P_NR RABATT

4711 1200 10

4711 1500 10

4711 1200 12

4711 1500 12

4800 1420 12

4800 1420 15

4800 1800 12

4800 1800 15

Die Zerlegung in GIBT_RABATT ( KNR, RABATT )

PRODUZIERT ( KNR, PNR )

lässt die ursprüngliche Relation nicht mehr sauber rekonstruieren. Es sei denn man

würde noch zusätzlich die Relation

PROD_RABATT ( PNR, RABATT )

einführen.

Da diese Binär-Relationen unterschiedliche Schlüssel aufweisen verletzt die

Relation KD_PR_RABATT die 5NF.

Die Relation KUNDE ( KNR, K_NAME, K_ORT, K_AUFNR )

kann in R1 ( KNR, K_NAME)

R2 ( KNR, K_ORT )

R3 ( KNR, K_AUFNR )

ohne Informationsverlust zerlegt werden !

41 Juni 2012



X Datenmanipulation im Relationenmodell

Bildung von Teil- /Untermengen

Bilden von Schnittmengen

Bilden von Vereinigungsmengen

Bilden von

Ausschlußmengen/Komplementäre

42 Juni 2012



X Datenmanipulation im Relationenmodell

Die Grundelemente der relationalen Datenmanipulation sind algebraische Mengenfunktionen zur

Qualifizierung einer Ergebnisdatenmenge(n)

PROJEKTION Auswahl von Spalten

SELEKTION Auswahl von Zeilen in Tabelle(n)

aufgrund ihrer Dateninhalte (mit verknüpften Suchkriterien)

JOIN Zusammenführung von Daten aus mehreren Tabellen

Voraussetzung : Daten in 3NF! (mindestens)

43 Juni 2012



X Datenmanipulation im Relationenmodell: SELEKTION

Auswahl bestimmter Zeilen

" Alle KUNDEN, die mehr als € 20.000,-- im Monat durchschnittliches Auftragsvolumen vergeben"

KUNDE KNR K_NAME PLZ ORT A-VOLUMEN

4711 Meyer 7500 Karlsruhe 800.000 €

4800 Müller 6800 Mannheim 750.000 €

2814 Klein 6800 Mannheim 90.000 €

3210 Ludwig 8000 München 660.000 €

5000 Huber 8011 Zorneding 50.000 €

SELECT * FROM KUNDE

WHERE A_VOLUMEN / 12 > 20000

Ergebnis: KNR NAME PLZ ORT A_VOLUMEN



3210 Ludwig 8000 München 660.000 €

44 Juni 2012



X Datenmanipulation im Relationenmodell: PROJEKTION

Auswahl bestimmter Spalten

" Alle KUNDEN mit Namen und ihrem durchschnittliches monatlichen Auftragsvolumen"

KUNDE KNR K_NAME PLZ ORT A-VOLUMEN



2814 Klein 6800 Mannheim 90.000 €

3210 Ludwig 8000 München 660.000 €

5000 Huber 8011 Zorneding 50.000 €

SELECT K_NAME, A_Volumen / 12 FROM KUNDE

Ergebnis: NAME ??????????

Meyer 66.666,67

Müller 62.500,00

Klein 7.500,00

Ludwig 55.000,00

Huber 4.166,67

45 Juni 2012



X Datenmanipulation im Relationenmodell: JOIN

Verbinden von Tabelleninhalten (kart. Produkt ?)

"Alle Aufträge mit Datum und die Auftragspositionen mit Produktbezeichnung"

AUFTRAG KNR AUFNR A_DAT A_WERT A_TYP

4711 1001 1.1.91 2,00 A

4711 2333 3.5.91 5,30 C

4800 4328 2.3.91 1,80 A

4800 4444 2.3.91 3,10 B

2814 1002 9.9.91 1,00 C

2814 1400 8.8.91 4,30 E

3210 1345 7.7.91 2,00 C

SELECT AUFNR, A_DAT, P_NAME FROM AUFTRAG A inner join A_POS AP

on A.AUFNR = AP.AUFNR inner join PRODUKT P

on P.P_NR = AP.P_NR

A_POS AUFNR P_NR ME

1001 1200 5

1001 1500 2

2333 1420

1345 1200 9 PRODUKT P_NR P_PREIS P_NAME P_LAGERORT

1200 13,50 G_Platine 07 München

1500 22,80 Steuerboard X München

1420 18,22 Kabelbaum A Frankfurt

1800 45,90 G_Platine 01 Hamburg

1700 88,90 CD-Steuerung München

1000 17,90 A_Platine 03 Frankfurt

46 Juni 2012



X Datenmanipulation im Relationenmodell: outer JOIN Probleme

Design-Fehler können bei der JOIN-Operation zu “outer-join”-Problematiken führen !!!!!!!!





PROJEKT PRJNR BEZ P-LEITER

110 RZ-ORG 4711

180 AUFT-VW 4220

210 KK ——

340 SIP 6122

Frage: Alle Projekte und ihre Projektleiter mit Namen ( P-LEITER kann NULL sein ??? )

SELECT PERSNR, NAME, PRJNR, BEZ

FROM PROJEKT P,

MITARBEITER M

WHERE P.P-LEITER = M.PERSNR

?

47 Juni 2012



XI Zusammenfassung

Auf einen Blick:

1. Das Relationenmodell von Codd sagt nichts über

“Physische DB-Organisation und Implemenrierungstechniken”

2. Das Codd´sche Modell beschreibt lediglich die

“Organisation und Behandlung von Daten als Mengen”

3. Die unterschiedliche Implementierung der Codd´schen Vorgaben führt bei den verschiedenen

relational orientierten DBMS zu unterschiedlichen Leistungen (!)

4. Zum Relationenmodell gehören

a) eine bestimmte Terminologie ( RELATION, ATTRIBUT, TUPEL...)

b) Regeln zur Normalisierung

c) Regeln für die Konsistenz und Integrität von Daten

d) Beschreibung der Tabellenoperationen

48 Juni 2012


Das „entity relationship“-Modell (ERM)….

Professor Dr. Peter Chen ist der “Erfinder” und Haupt-

Verfechter der ENTITY-RELATIONSHIPModells

1977 entwickelt, P. Chen war damals Professor des M.I.T.

Sloan School of Management

beschrieben wurde die methode im Buch “The Entity-

Relationship Approach to Logical Database Design“

49 Juni 2012



Zielsetzung:

Abbildung der realen Welt in einem Datenmodell

Zusammenfassung positiver Eigenschaften anderer Modelle

Einfache Methode zum Entwurf von Informationsstrukturen

Verständliche Kommunikationsgrundlage

Chen: “Das E-R-Modell stellt die grundlegende

Datenmodellierungsmethode für eine neue

Generation von DBMS´s dar”

50 Juni 2012



Was ist ein ENTITY

ENTITY ist ein Ding, das in der

realen Welt eindeutig

erkennbar und abgrenzbar

ist (auch „Entität“ )

Entities besitzen

ATTRIBUTEs und

RELATIONSHIPS

ENTITY TYPE ist eine Zusammen-

fassung von “entities”

nach bestimmten

Wesensarten (auch

„Entitätsmenge“ genannt)

51 Juni 2012



ENTITY

Eine ENTITÄT ("entity") muss in seiner betrachteten Realität EINDEUTIG IDENTIFIZIERBAR sein. - Jedes

ENTITY besitzt einen ENTITÄTSSCHLÜSSEL

Beispiel:

Kunde Meyer KG ist für seine Bank DUCK & Co eine ENTITÄT.

Alle Kunden der Bank DUCK & Co bilden die ENTITÄTSMENGE ("entity type") "KUNDE".

Alle Kunden, die ihre Konten überzogen haben gehören bei DUCK & Co zur ENTITÄTSMENGE

"KREDITNEHMER"

Aufgaben:

1. Geben Sie jeder ein Beispiel einer beliebigen ENTITÄTSMENGE ...

2. Wie sind Ihre Entitätsmengen EINDEUTIG IDENTIFIZIERT ?

52 Juni 2012



Was ist ein ATTRIBUTE

ATTRIBUTE sind eine Eigenschaft oder

(TYPE) ein Merkmal von

Entity(types) und/oder

Relationship(types)

( auch „Attribut“ )

IDENTIFIZIERENDE ATTRIBUTE

sind einzelne oder mehrere

ATTRIBUTE, die zusammen-

gefaßt den ENTITÄTS-

SCHLÜSSEL bilden. Er

muss eine ENTITÄT

EINDEUTIG identifizieren

53 Juni 2012



ATTRIBUTE(S)

ALSO: ENTITY-TYPES haben ATTRIBUTE-TYPES

ENTITIES haben ATTRIBUTES

oder

ENTITÄTSMENGEN haben ATTRIBUTE

ENTITÄTEN haben ATTRIBUTWERTE

Beispiel:

Attribute der Entitätsmenge KUNDE: Kundennummer

• Kundenname

• Postleitzahl

• Adresse

• Bonität

• .....

Die Menge aller ZULÄSSIGEN WERTE eines ATTRIBUTS heißt: DOMÄNE oder WERTEBEREICH

z.B.: Die Menge aller zulässigen Werte im Attribut GESCHLECHT der Entitätsmenge PERSON ist

"männlich"/"weiblich"

54 Juni 2012



Was ist eine RELATIONSHIP

R ELATIONSHIP Beziehung zwischen beliebig

vielen “entities”

RELATIONSHIP-TYPE Zusammenfassung von

Beziehungen nach

bestimmten Wesensarten

55 Juni 2012



Strukturelemente eines ER-Modells

1:1 Relationship

Aussage: Ein Kunde unterhält genau ein Konto ...

1:n Relationship

Aussage: Ein Kunde vergibt einen/keinen oder mehrere Aufträge ....

n:m Relationship

Aussage: Ein Artikel wird von 0-n Lieferanten geliefert

Ein Lieferant liefert 0-n Artikel

56 Juni 2012


Das „entity relationship“-Modell (ERM)…. Zusammenfassung

Auf einen Blick:

Vorteile des E-R-Modells

Die Grafische Darstellung vereinfacht die Kommunikation (über die dargestellte

Realität) mit allen Beteiligten

mehrere Beziehungen zwischen zwei Entity-Typen sind möglich und darstellbar

Nachteile des E-R-Modells

Normalisierungskriterien sind nicht direkt im Modell enthalten

Behandlung der Attribute bleibt problematisch ( wegen der erforderlichen

Typisierung )

Frage: Gibt es eine methodische Möglichkeit ER Modell und RM zu kombinieren ???

57 Juni 2012


Die Methoden – ERM & relationaler Ansatz

Der Informationsdesigner kann heute in der Regel auf zwei etablierte methodische Grundsätze zurückgreifen:

• das "entity-relationship"-Modell (ERM) von P. Chen nebst einer Reihe daraus abgeleiteter Varianten und die sogenannte

• relationale Datenmodellierung, die auf grundlegenden Arbeiten von Codd zu einer detaillierten Design-Technik ausgearbeitet

wurde.

Beide Methoden beruhen auf analogen gedanklichen Grundkonstrukten ("entity"-Typ, Beziehungstyp, Attribut), gehen aber in der

Analyse- und Darstellungsmethode verschiedene Wege und finden daher, je nach Anwendertyp und Anwendungsbereich

unterschiedliche Akzeptanz.

Die Charakteristika beider Ansätze bezüglich der Ergebnisdarstellung im konzeptionellen Schema seien hier kurz gegenübergestellt.

ERM- Methoden

• grafische Beschreibungssprache mit Symbolen für "entity" (Box), Beziehungstypen (Raute, Pfeil, "crow foot"),

Attribute (Oval)

• zusätzliche Sprachmittel zur Detailbeschreibung von Beziehungstypen (Kompexitätsgrad, Kann-/Muß-

Bedingung)

• strikte Visualisierung aller Entwurfsergebnisse

• Überblick über umfassende Strukturzusammenhänge sind direkt möglich

• Analyseweg ist "top-down" orientiert (Strukturen innerhalb von "entity"-Typen werden in der Regel nicht

beachtet, Ausnahme: Sub-"entity"-Strukturen)

• Unklarheiten bezüglich der Behandlung gewisser Beziehungstypen

58 Juni 2012



Relationale Datenmodellierung

• Beschreibungssprache ist der relationale Formalismus (Relationen mit ihren Attributen, tabellarische

Darstellungen, Beziehungstypen über Fremdschlüssel),

• Darstellung komplexer Beziehungstypen (m : N etc.) über kombinierte Primärschlüssel,

• Visualisierung ist nicht konstruktiver Bestandteil der Methode (entsprechende Diagramme sind jedoch aus

den Relationenstrukturen ableitbar),

• umfassende, d.h. mehrere Relationen übergreifende Strukturzusammenhänge müssen schrittweise

rekonstruiert werden,

• Analyseweg bottom-up-orientiert (Bildung von Elementarrelationen mit maximal 2-3 Attributen, Aggregation,

Normalisierung), also eigentlich: “Syntheseweg”,

• Normalisierungsregeln zur Erzeugung von formal korrekten (i.S. von rdundanzfreien) Datenstrukturen,

• direkte Implementierung der Entwurfsergebnisse auf einem relationalen Datenbanksystem ist möglich (sofern

Gesichtspunkte der Performance und Effizienz außer Betracht bleiben).

59 Juni 2012



Vereinigung der Vorteile aus den theoretischen Modellen

• strukturiert darstellbar

• eindeutig beschreibar

• methodisch nachvollziehbar

• übersichtliche, leicht verständliche Kommunikationsbasis

d.h. Realisierung des Sichtenmodells in der methodischen Vorgehensweise

Management Spezialisten

• Konkrete Ausgangsbasis

• Integration vorhandener

Details

• Grundlage zur genauen

Betrachtungsweise

• Zwang zur frühen Ab-

straktion

• Konzentration auf das

Wesentliche

• Überblick über die

Zusammenhänge

60 Juni 2012


Die Methoden – Entwurfstrategien

TOP DOWN kontra BOTTOM UP

TOP DOWN BOTTOM UP

Vorgehen Sukzessive Verfeinerung durch

vollständiges Zerlegen der

Komponenten in Teilkomponenten

Sukzessiver Aufbau durch

Zusammensetzen von

Einzelkomponenten

Vorteile • Gewährleistet Vollständigkeit

• Systematisch

• Überschaubar

• Gewährleistet Genauigkeit

• Beschränkung auf das Notwendige

Nachteile • Notwendiger Detaillierungsgrad

schwer zu erkennen

• Eventuell wird mehr beschrieben als

notwendig

• Probleme und Entscheidungen

werden u.U. aufgeschoben

• Überschwemmung mit Details

• Zusammenfügen kann schwierig

werden, wenn die Komponenten nicht

genau zueinander passen

• Übergeordnete Strukturen werden

schwer erkannt

Verwendung Neukonzeption Modifikation vorhandener Systeme

Integration im Datenanalyseverfahren

61 Juni 2012


Die Methoden – Integration der Entwurfsverfahren

Zielsetzungen für das Informations- und Datenmodell

Vollständigkeit und Konsistenz

Genauigkeit

Änderbarkeit

Verständlichkeit und Benutzerfreundlichkeit

Anwendungs- und Technologieunabhängigkeit

umfassende, d.h. mehrere Relationen übergreifende Strukturzusammenhänge müssen schrittweise

rekonstruierbar sein

der Analyseweg ist TOP-DOWN orientiert (vom Groben zum Detail !)

der QS-Weg ist BOTTOM-UP gekennzeichnet (Bilden von Elementarrelationen mit wenigen Attributen,

Aggregation und Normalisierung) also eigentlich: "Synthese" !

die direkte Implementierung der Entwurfsergebnisse in einem relationalen DBMS muß möglich sein

62 Juni 2012


Die Methoden – das vollständige Analyseverfahren(DM und BPM)

Funk-

tions-

Analyse

Informa-

tions-

Analyse

Funk-

tions-

Modell

Informa-

tions-

Modell

Elem.-

Funktion

Datensichten

und "dataflow"-

Modell

Kano-

nische

Synthese

Phys.

DB-Design

abgestimmtes

Informations-

Modell

Abst

imm

ung

63 Juni 2012


Die Methoden – das vollständige Analyseverfahren(DM und BPM)

Auf einen Blick:

... auch und gerade Methoden, wie Datenmodellierung und Design sollte im

Hintergrund immer Triebfedern wie

Rentabilität

Nutzenaspekte und

Effizienzüberlegungen

haben...

... Last but not least - erwarten

Sie ungeahnte Erfolge in der

Datenmodellierung ....

64 Juni 2012


Die Methode IA – der Weg und das Ergebnis

Das PROBLEM:

(1) in den Fachbereichen gibt es selten eine eindeutig definierte Begriffswelt

(2) über Bereiche hinweg ist diese gemeinsame Begriffswelt fast nie existent

Beispiel:

KUNDE - INTERESSENT - KÄUFER

MATERIAL - ARTIKEL - PRODUKT

ZIEL: "EINE" Klare , eindeutige Begriffswelt zu Beginn jeder Entwicklung von

Informationssystemen zu schaffen….

65 Juni 2012



am Anfang einer Systementwicklung

Überblick über alle RELEVANTEN

Informationen und ihre Zusammenhänge FARBE KUNDE

Kundennr

Bestellung PREIS Kd-Nr

Menge VERTRAG

AUFTRAG

Bestellung RECHHNUNG

bis zum Abschluß des Fachkonzepts

strukturierte Beschreibung aller für den

Untersuchungsbereich relevanten

Informationen und ihrer Beziehungen

langfristig

Darstellung eines unternehmensweiten

Informationsmodells

66 Juni 2012



Funk-

tions-

Analyse

Informa-

tions-

Analyse

Funk-

tions-

Modell

Informa-

tions-

Modell

Elem.-

Funktion

Datensichten

und "dataflow"-

Modell

Kano-

nische

Synthese

Phys.

DB-Design

abgestimmtes

Informations-

Modell

Abst

imm

ung

67 Juni 2012


Die Methode IA – der Weg und das Ergebnis (TOP Modell)

Die grafische Gesamtdarstellung

der Entitäten und ihrer

Beziehungen nennt man

Informationsmodell

68 Juni 2012


Die Methode IA – der Weg und das Ergebnis (Vorgehen)

I. Systemübersicht erarbeiten

II. Begriffe sammeln

III. Begriffe in Methodenelemente einteilen

IV. Informationsmodell grafisch visualisieren

V. Methodenelemente beschreiben

VI. Abgleich mit der Funktions-(TOP-)Struktur

VII. Abstimmen und dokumentieren

69 Juni 2012


Die Methode IA – der Weg und das Ergebnis (Das Kontext-Diagramm)

Die Systemübersicht / Kontextdiagramm grenzt den Untersuchungsbereich ab. Folgende

Schritte sind erforderlich:

(1) Benennen/Eingrenzen des Untersuchungsbereichs

(2) Bestimmen der "externen Partner"

(3) Bestimmen der "externen Mitteilungen"

(4) Grafische Darstellung

Beispiel:

70 Juni 2012



Mit dem Ziel der Erstellung qualitativ guter Datenmodelle

werden zusätzliche Konstruktionsoperatoren wie

• Klassifizierung,

• Aggregation und

• Generalisierung/Spezialisierung (auch Vererbung

bzw. Inheritance)

benutzt

Ziel der Verfeinerung von Informationsstrukturen ist die

stufenweise Detaillierung der Begriffswelt für den

betreffenden Untersuchungsbereich des Unternehmens.

Hierbei müssen die betrieblichen Funktionen (Abläufe)

beachtet werden, um alle relevanten Begriffe zu finden.

71 Juni 2012


Die Methode IA –das Ergebnis: logisches DM

1. Alle N : M BEZIEHUNGEN sind aufgelöst

2. Jedes Entity hat IDENTIFIZIERENDE Attribute

3. Die Identifizierenden und alle beschreibenden Attribute sind VOLLSTÄNDIG

4. Die ENTWURFSREGELN sind eingehalten

5. Der angestrebte DETAILLIERUNGSGRAD ist erreicht

6. Die TOP-Struktur und der letzte VERFEINERUNGSSCHRITT sind vollständig

DOKUMENTIERT

7. Die TOP-Struktur und der letzte VERFEINERUNGSSCHRITT sind mit den beteiligten

Fachabteilungen /Projekten ABGESTIMMT

8. Das Informationsmodell ist mit den erforderlichen, fachlich relevanten FUNKTIONEN

ABGESTIMMT…

72 Juni 2012

DB2 DB2 –– DB2 logisches DesignDB2 logisches Design

Vorgehen beim Entwurf

1. Begriffe sammeln

2. Begriffe in Methodenelemente einteilen (Objekt, Attribut, Beziehung)

3. Grafik erstellen/entsteht

4. Methodenelemente beschreiben/Definieren

5. Dokumentieren und Abstimmen der TOP-Struktur

6. Verfeinerung des Informationsmodells

• Auflösen der N:M Beziehungen

• Klassifizierung der Enities

• Bildung der Sub-/Supertypen von Entities

• Zerlegung von Entitäten

7. Überprüfen der Normalformen

8. Dokumentieren und Abstimmen der Ergebnisse

Vorgehen - Zusammenfassung

73 Juni 2012


Kapitelinhalt











• Datentypen








74 Juni 2012

DB2 DB2 –– physischer physischer Designprozess&PerformanceDesignprozess&Performance

Auf dem Markt gibt und gab es eine Vielzahl von Datenbankmanagementsystemen,

die sich zwar leicht in Gruppen , wie

Relational

CODASYL

Hierarchisch

Objektorientiert (?)

einteilen lassen, sich aber in vielen Leistungsmerkmalen deutlich voneinander

unterscheiden.

Ziel des systemspezifischen DB-Design

Ausgehend vom konzeptionellen Informationsmodell werden systematische

Überführungsschritte in das Ziel-DBMS festgelegt. Insbesondere werden die Stärken

des Zielsystems berücksichtigt.

Die Problemstellung

75 Juni 2012


Wo sind wir im Design-Prozess???

Entity Relatonship

modelling

(problemorientiert) Normalisierung

(datenorientiert)

conceptual

modelling

(logisch orientert)

Composite logical

modelling

(optimiert)

Physical modelling

(DBMS- /

zugriffsorientert)

Funk-

tions-

Analyse

Informa-

tions-

Analyse

Funk-

tions-

Modell

Informa-

tions-

Modell

Elem.-

Funktion

Datensichten

und "dataflow"-

Modell

Kano-

nische

Synthese

Phys.

DB-Design

abgestimmtes

Informations-

Modell

Abst

imm

ung

76 Juni 2012


PDB – Vorgehen allgemein

Konzeptionelles Informationsmodell Funktionsmodell

Grafik

Dokumente

("business rules")

Abhängigkeiten...

Grafik

(Ablauf-) Beschreibung

(Mengen)

(Häufigkeiten)

(Zugriffsarten) ...

77 Juni 2012


PDB – Vorgehen allgemein

1. Überführung der "entities"

Übernahme von Satztypen

Trennen von Satztypen

Zusammenlegen von Satztypen

2. Überführen der Beziehungen

Behandlung von 1 : 1 "relationships"

Behandlung von 1 : n Beziehungen

Implementieren von Beziehungsregeln ( RI, „constraints“ )

Planen der PK/FK „constraints“

3. Einrichten der Zugriffspfade

Behandlung der Einstiegspunkte

Auswahl der physischen Zugriffspfade

4. Festlegen der DBMS-spezifischen Parameter

Blockgröße / Satzgröße

Speicherplatzgröße / Speicherplatzorganisation

physische Speicherungsfolge

Beachten organisatorischer Einflüsse (DBA) usw.

5. Integration in das bestehende PDM

78 Juni 2012


PDB – Vorgehen allgemein: Übernahme der „entities“

1. Satztypen zusammenlegen

Bei einer 1:1 - Beziehung kann eine Zusammenlegung günstig sein, falls beide

Satztypen in wichtigen Benutzersichten gemeinsam verwendet werden ( kein "join"

erforderlich )

Beispiel:

ACHTUNG: Berücksichtigen Sie die Einstiegspunkte !!

79 Juni 2012



1. Satztypen zusammenlegen

Bei einer 1:n - Beziehung ist eine

Zusammenlegung von Satztypen nur

sinvoll, wenn der n-Satztyp ISOLIERT

im Informationsmodell steht !

Beispiel:

80 Juni 2012



2. Denormalisierung

Denormalisierte Strukturen helfen insbesondere bei relationalen DBMS JOIN-Operationen zu

minimieren und so die Performance in bestimmten Bereichen (beim LESEN) zu steigern.

ACHTUNG:

Bei jeder Denormalisierung entstehen Redundanzen, die GEPFLEGT werden müssen, um die DB-Inhalte

KONSISTENT zu halten !

Beispiel:

KUNDE ( KD-NR, KD-Name, KD-PLZ, KD-ORT, KD-Strasse, )

normalisiert:

KUNDE ( KD-NR, KD-Name, KD-OKZ, KD-Strasse.... )

ORTE ( OKZ, O-PLZ, O-ORT ... )

Voraussetzung für den Einsatz denormalisierter Strukturen:

Änderungsaufwand der Redundanzen ist überschaubar

Änderungshäufigkeit ist möglichst gering !!

81 Juni 2012



3. Satztypen trennen

Die Trennung von Satztypen kann dann sinnvoll sein, wenn die Daten einer Entität von vollständig

unterschiedlichen Organisationseinheiten genutzt und bearbeitet werden sollen, vorgangsorientierte Daten

verarbeitet und zur Verfügung gestellt werden sollen.

Beispiel:

Im o.g. Beispiel besteht das Problem darin, dass Anforderungen wie "...alle genehmigungspflichtigen Transaktionen... " oder "

... alle zur Überweisung freigegebenen Transaktionen ..." aber insbesondere " ... alle nicht bearbeiteten Transaktionen ...„ bei

DB2 zu einem "tablespace-scan", d.h. zum sequentiellen Lesen von 10 Millionen

Datensätzen führen würde, da eine Indizierung über Spalten mit zu wenigen Ausprägungen keine DB2-adäquate Selektivität

aufweisen könnte.

82 Juni 2012



4. Schaffung zusätzlicher Tabellen

In vielen Fällen kann die Schaffung zusätzlicher Spalten/Tabellen aus Performance- Gründen

nützlich sein. Dies ist der Fall bei

Ergebnis- und Summendaten

Unterstützung von Aggregatsfunktionen im Rahmen von Auswertungen

Historischen Daten

Beispiel:

Problematisch kann dies bei referentieller Integrität sein !

83 Juni 2012



5. Ergänzen zusätzlicher Felder im physischen Datenmodell

Zusätzliche Felder sind Felder, die Zugriffe beschleunigen können, Updates sicherer machen, Joins

verhindern helfen usw. aber aufgrund der konzeptionellen Datenmodellierung

nicht erforderlich wären.

Beispiel: Abgeleitete Daten z.B. Brutto-Betrag, Summenfelder

Kennzeichen, ob in abhängigen Tabellen weitere Informationen vorliegen oder nicht; z.B.

Zweit-/Dritt-Adressen

optionale Lieferadressen, Rechnungsadressen usw. deren Existenz in der jeweiligen

„Haupttabelle“ mit „Y“ oder „N“ angezeigt wird:

SELECT <columns>

FROM account a LEFT OUTER JOIN billing b

ON a.accnt# = b.accnt#

AND a.optionalBill = ‘Y’

LEFT OUTER JOIN address c

ON a.accnt# = c.accnt#

AND a.optionalAdress = ‘Y’

…….

WHERE a.accnt# = 1

Für zusätzliche Zugriffsmöglichkeiten z.B. Matchcode, phonetisierte Schreibweise, Großschrift

Als Protokollierungs- und Steuerungsinformation z.B. Datum letzte Änderung, Langfrist-

Sperrkennzeichen

Für Zugriffsschutz z.B. Code für Benutzerberechtigung

Gültigkeitsinformationen

Technische Informationen z.B. Visualisierungsinformationen (CRT, 3270 ... )

Weiterverarbeitungsinformationen z.B. für Datawarehousing, Reporting, Aggregationen ...

84 Juni 2012


PDB – Vorgehen allgemein: Überführung der „relationships“

Beziehungen werden über Schlüsselredundanzen realisiert: "primary key" → "foreign key"

Es ist dabei wichtig zu wissen, ob nur eine oder BEIDE Richtungen der Beziehungen

benötigt werden.

85 Juni 2012


PDB – Vorgehen allgemein: Festlegen der Zugriffspfade und der Datenorganisation(Beispiel: DB2)

Grundsätzlich stehen zwei Zugriffsmethoden bei DB2 zur Verfügung:

"index based"

"tablespace scan"

Ziel wird es sein, indexbasierte Zugriffe zu ermöglichen.

Das hängt allerdings nicht nur vom DB-Design, sondern unter anderem auch von der Formulierung der

"query" ab.

Allerdings muss man pro "Tabelle" mindestens einen Index zur Verfügung stellen(siehe RDM - Definitionen:

"primary key index"

evtl. "cluster index„ (nicht automatisch = PK)

evtl. „partitioning index“

Ausgangspunkt sind dabei die Einstiegspunkte der konzeptionellen Datenstruktur!

Beachte:

Bei konkurrierenden Einstiegspunkten sollte der Index gewählt werden, der möglichst "hochwertig" ist:

1. "cluster index"

2. "primary key" oder "unique index"

3. "normaler" Index („duplicates“)

Wird der Datenbestand sehr häufig erweitert (INSERT ) oder verringert (DELETE), so sollten im Sinne der

Performance möglichst SELEKTIVE , aber WENIGE Indizes auf den Tabellen liegen.

86 Juni 2012


PDB – Vorgehen allgemein: Festlegen der phys. Parameter der Datenorganisation(Beispiel: DB2)

1. Berechnen der TS-Größe

"primary space" / "secondary space„ Bestimmung

Bestimmen zusammengehöriger Tabellen für EINEN TS(?)

Bestimmen des TS-Typs (MDC-TS, PTS, normaler TS, STS…)

Festlegen des Füllgrades der Pages (PCTFREE, FREEPAGE) etc.

2. Bestimmen der LOCKING und ISOLATION - Parameter

LOCKSIZE

ISOLATION Level RR / CS

Zuordnung zu STOGROUPS/LUNs

3. Festlegen der (DB2-)Datentypen in den Tabellen

wenige NULL-Felder eher NOT NULL WITH DEFAULT

keine Tabellen-PROCs ( VALIDPROC, EDITPROC,FIELDPROC ... )

keine LONGVARCHAR / VARCHAR / LOB - Felder

Anordnung der Spalten in der Tabelle (VARCHAR und NULL-Felder ans Ende der Tabelle, usw.)

Definition der RI-Bedingungen ( falls nötig )

Festlegen der "views„ / ALIASE / SYNOMYMs / MQTs etc.

4. Definition der DB2-Datenbanken

nach organisatorisch / administrativen Gesichtspunkten

nach Datenverfügbarkeitsanforderungen ( mit Hilfe der Datenbankadministration ! )

Testdatenbanken sind NIE oder nur SELTEN gleich der PROD-Datenbank !!

87 Juni 2012


PDB – Bauen Sie ihre Informationsumgebung nach NUTZENGESICHTSPUNKTEN auf ....

88 Juni 2012


Kapitelinhalt











• Datentypen








89 Juni 2012

DB2 DB2 –– physisches Designphysisches Design

PDB – DB2 Empfehlungen….

Funk-

tions-

Analyse

Informa-

tions-

Analyse

Funk-

tions-

Modell

Informa-

tions-

Modell

Elem.-

Funktion

Datensichten

und "dataflow"-

Modell

Kano-

nische

Synthese

Phys.

DB-Design

abgestimmtes

Informations-

Modell

Abst

imm

ung

Wir sind immer noch da…

90 Juni 2012


PDB – DB2 Empfehlungen zur DDL….

1. Katalog und Dictionary zur Kontrolle der DB2-Umgebung.

2. Tabellennamen: Die Namen der „embedded“ SQL-Member sollten die Namen der jeweiligen

Tabellen beinhalten (gilt auch für “views” / MQTs).

3. Synonyme: <authid> . <objname> sollte EINDEUTIG in der DB2-Umgebung sein. Außerdem

sollte es pro <authid> nie mehr als EIN Synonym für dasselbe “Basisobjekt” geben.

4. LUN – und „storagepaths“: Benutzen Sie unterschiedliche “storage paths” für jede (Test-

)Umgebung und evtl. bestimmte Anwendungen.

5. Grundsätzlich gilt: Speicherplatzersparnis ist nicht so wichtig wie weniger Tabellen.

6. Zum Thema Komprimierung vorab folgende Information:

Der Einsatz von Komprimierungsfunktionen macht viele Speicherplatzüberlegungen annähernd

überflüssig. Die heute möglichen Kompressionsraten und die damit verbundenen

Platzersparnisse erfordern nur marginal höhere Aufwände bei CPU- und Laufzeiten der

Prozesse:

• mögliche Kompressionsrate bei kommerziellen Daten 40 - 70 %

• Erhöhung der CPU-Zeit ca. 15 %*

• Verringerung der Laufzeit serieller Prozesse ca. 10 %* (stark schwankend in

Einzelfällen!!)

91 Juni 2012


PDB – DB2 Empfehlungen zum physischen (systemspezifische) Design für DB2 ….

(1) Der physische Design-Prozess unter

• Technischen Aspekten

• Performance-Gesichtspunkten

(2) STORAGE Parameter („automatic“, „on demand“,

„SMS, DMS….)

• Größen, Typen

• Bufferpools

• „storage layout“

(3) DB2 Objekte

• DATABASE(S)

• TABLESPACES

• TABLES

• INDEXES

• “VIEWS” / MQTs / andere Objekte

(4) DDL und Implementierung

Entity Relatonship

modelling

(problemorientiert) Normalisierung

(datenorientiert)

conceptual

modelling

(logisch orientert)

Composite logical

modelling

(optimiert)

Physical modelling

(DBMS- /

zugriffsorientert)

92 Juni 2012



Siehe WS „DB2 LUW – Performance&Tuning (Grundlagen)“

• Tabellen-Design

• Index-Design

Dennoch einige ergänzende Tips zu DB2-Objekten:

1. Tips zum Erzeugen von „databases“

• Nutzen Sie DB2-Datenbanken/-instanzen als Einheiten für die Verfügbarkeit von Tabellen und Indizes

(START/STOP).

• DB2-"security"-Mechanismen können auch auf "database"-Ebene vergeben werden.

• Vermeiden Sie Verweilzeiten im DB2-Katalog. Geben Sie JEDEM Entwickler SEINE (private)

"database".

• Es kann sinnvoll sein, nur EINE TS pro DATABASE zu erlauben, besonders, wenn die Tabelle(n) sehr

groß sind

• generell gilt die Regel, dass nicht mehr als 10 bis 20 TS für eine “database” angelegt werden sollten

• Die maximale Anzahl von „database“.-Objekten, die in einer DB2-Instanz/Subsystem verwaltet

werden können, liegt derzeit bei 65279.

93 Juni 2012



2. Empfehlungen zu "tablespaces"

• TS sind Objekte für

a) LOCKING

b) UTILITIES

• "Partitions" können auf unterschiedlich physische "devices" verteilt sein (aus

Performancegründen).

• Ein PTS bietet auch Flexibilität für die Ausführung bestimmter DB2-"utilities„ (REORG, IC/BACKUP,

LOAD, RECOVER, RUNSTATS, usw. …)

Anmerkung: Eine sinnvolle Partitionierung kann sich auch aus dem logischen Informationsmodell

ergeben.

• Einzelne "Partitions" sollten weder gelöscht noch neu verteilt werden, wenn sie EINMAL definiert

sind.

• Der Index(CIX) auf einen PTS wirkt wie eine Integritätsprüfung bei der Einspeicherung von "rows".

• Mehrere Tabellen in EINER TS sind nicht immer die "klügste" Entscheidung: "Locking" auf TS-Ebene sperrt ALLE Tabellen im TS (!)

TS-Scans durchsuchen alle Tabellen im TS

RECOVER / REORG verursachen ein Sperren des TS – außer man verwendet das „feature“ des Online-REORG;

Wiederverwendung von freigewordenem Speicherplatz findet oft nicht statt bis zum REORG

94 Juni 2012



3 Empfehlungen zu Tabellen

• Pro Tablespace sind mehrere Tabellen anzulegen.

• Für spezielle Tabellen ist auch ein separater TS möglich

• Für jede Tabelle ist ein Kommentar anzulegen (Comment)

• Ein Cluster-Index(bzw. MDC-Clustering) ist bei grossen Tabellen zwingend vorzusehen (muß nicht

„Unique“ sein)

• Eine PK-Definition muss angegeben werden (muß unique sein)

• Indizes sind nach Möglichkeit „unique“ zu definieren

• Mindestens 1 Unique-Index pro Tabelle muß vorhanden sein.

Man sollte folgende Methoden und Aspekte beachten, wenn man die Datentypen festlegt:

• Verwenden Sie immer einen “numeric” Datentyp VOR einen “ character datatype”, unter folgender

Überlegung:

- Beim Anlegen einer Spalte mit einem “bool’schen” Inhalt – z.B. “YES” oder “NO”, sollte man einen “decimal (1,0)”

oder einen ähnlichen Datentyp wählen. = und 1 als Werte für diese Spalte erfüllen ihren Zweck genauso, wie “N”

oder “Y”.

Nutzen Sie INTEGERs bei der Darstellung von sogen. „Codes“

Sind weniger als 10 Code-Werte für eine bestimmte Spalte vorhanden, so ist der Datentyp “decimal (1,0)“

angemessen. Sind mehr als 9 “code values” zu definieren, nutzen Sie “smallint”.

95 Juni 2012



3 Empfehlungen zu Tabellen(cntn‘d)

• Speichern Sie die Definitionen als „domain“ Werte in einem „data modeling“ Werkzeug, z.B. Rational

Data Architect. Dort können diese Werte einem größeren Team über das „metadata reporting“ mitgeteilt

werden.

• Speichern Sie die Definitionen als Werte in eine Tabelle einer „database”, wo die

Definitionen“gejoined” und mit einem Kontext angereichert werden können – als „Textname” oder

“Beschreibung”.

• Lassen Sie die Finger von ineffizienten Datentypen wie:

GRAPHIC - Länge zwischen 2 und 20(???);

VARGRAPHIC – Länge zwischen 13 und 500(!); z.B. der UPDATE_USER mit Länge 20

„Variable-length column” (VARCHAR oder VARGRAPHIC) erlauben die Definition jeder beliebigen Anzahl von Spalten in

einer Tabelle auf variabler Länge. Nutzt man VARCHAR bzw. VARGRAPHIC kann sich die Größe einer Tabelle dramatisch

reduzieren, aber nur dann, wenn die Einsparungen durch die variablen Datentypen in großem Umfang möglich sind; z.B. bei einer

großen Anzahl von Sätzen in der Tabelle und die VAR-Spalte ist wegen weniger Datenwerte sehr groß (10%), die restlichen

Datenwerte sind aber nur sehr kurz:

Beispiel: 1.000.000 Sätze max. Wert = 1024 Bytes, 90% der „rows“ sind nur 20 Byte lang

Das ergäbe bei einem Verhältnis von 90/10 eine Ersparnis von ca. 90.000 Byte = 90 MB

VARGRAPHIC ist kein Ersatz für UTF-8 UNICODE Datenbanken. Hier wäre es besser, alle Datenbanken –

falls noch nicht geschehen – auf UNICODE umzustellen und mit VARCHAR-Feldern zu arbeiten.

96 Juni 2012



4 Felder/“columns“

• NULL ist nur zu verwenden, wenn explizit zwischen „nicht vorhandensein“ eines Wertes und einem Default-Wert

unterschieden werden muß . Ist das Feld Kandidat für einen Index oder für WHERE-Abfragen, ist es sinnvoller NULL-

Werte nicht zuzulassen, da dies die Indexnutzung erschweren kann (z.B. WHERE <FELD> NOT NULL OR <FELD> >=

‚2008-01-01’)

• Felder, die auch in anderen Tabellen gespeichert sind, müssen in jeder Tabelle denselben Namen (außer Prefix/Schema-Teil)

und dasselbe Format (Typ+Länge) haben.

• Alle Felder, die ein Datum beinhalten, müssen mit dem Typ DATE definiert werden.

• Alle Felder, die eine Uhrzeit beinhalten, müssen mit dem Typ TIME definiert werden.

• Zahlen sind über numerische Typen (DEC, INT, SMALLINT, FLOAT, REAL, DOUBLE) zu definieren - nicht mit CHAR!

• Für alphanumerische Felder mit einer Länge von mehr als 30 Zeichen ist die Verwendung von VARCHAR zulässig. Dies

vor allem dann, wenn zu erwarten ist, dass durchschnittlich weniger als 80% des Feldes gefüllt sein wird. Allerdings

sollten VARCHAR-Felder möglichst nicht für Indizes benötigt werden!

• Auch die Reihenfolge der Felder kann die Performance beeinträchtigen. Die Felder sollten möglichst nach folgender

Reihenfolge angelegt werden:

o Primary-Key-Felder

o Häufig gelesen Felder

o Seltener gelesene Felder

o Seltener geänderte Felder

o Variabel lange Felder

o Häufiger geänderte Felder

97 Juni 2012




Reihenfolge der Spalten zur Minimierung der LOG-Aktivitäten

• Spalten, die häufig aktualisiert werden, sollten zusammengruppiert und näher zum Ende bzw. am Ende der Tabellendefinition

definiert werden. Dies

o verbessert die Leistung,

o verringert die Anzahl der zu protokollierenden Byte

o senkt die Anzahl der zu schreibenden Protokollseiten

o vermindert den Speicherplatzbedarf für „active transaction Logs“

• Der Datenbankmanager nimmt nicht automatisch an, dass Spalten, die in der SET-Klausel einer UPDATE-Anweisung

angegeben sind, im Wert geändert werden sollen. Zur Begrenzung des Aufwands der Indexpflege und des zu

protokollierenden Umfangs der Zeile vergleicht DB2 den neuen Spaltenwert mit dem alten Spaltenwert, um zu entscheiden,

ob die Spalte geändert wird. Ausnahmen von diesem UPDATE-Verhalten ergeben sich für Spalten, bei denen die Daten

außerhalb der Datenzeile gespeichert werden (Spaltentypen LONG, LOB, ADT und XML), oder für Spalten mit fester Länge,

wenn die Registrierdatenbankvariable DB2ASSUMEUPDATE aktiviert ist. In diesen Fällen wird angenommen, dass sich der

Spaltenwert ändert, sodass kein Vergleich zwischen dem neuen und dem alten Spaltenwert angestellt wird.

• Es gibt vier unterschiedliche Typen von UPDATE-Logs:

o Vollständige Protokollierung der Before- und After-Images. Dies ist der einzige Typ von Protokollierung, der für

Tabellen mit Option DATA CAPTURE CHANGES ausgeführt wird, und logged die höchste Anzahl von Bytes.

o Protokollierung des vollständigen Before-Image. Dabei werden das Before-Image und das Minimum an zusätzlichen

Daten protokolliert.

.

98 Juni 2012




Reihenfolge der Spalten zur Minimierung der LOG-Aktivitäten

• Es gibt vier unterschiedliche Typen von UPDATE-Logs (cntn‘d):

o Vollständige XOR-Protokollierung. Die XOR-Unterschiede zwischen dem Before-Image und dem After-Image der

Zeile, angefangen vom ersten Byte, das sich ändert, sowie alle restlichen Byte in der Zeile, werden protokolliert.

o Partielle XOR-Protokollierung. Die XOR-Unterschiede zwischen dem Before-Image und dem After-Image der Zeile,

angefangen vom ersten geänderten Byte, bis zum letzten geänderten Byte, werden protokolliert. Bei diesem Verfahren

wird die geringste Anzahl von Byte protokolliert und der effizienteste Protokollsatztyp generiert.

Wenn für die ersten beiden oben aufgeführten Typen von UPDATE-Protokollsätzen die Option DATA CAPTURE CHANGES

nicht aktiviert ist, hängt der Umfang der Daten, die protokolliert werden, von folgenden Faktoren ab:

o Die Nähe der aktualisierten Spalten (COLNO)

o Ob die aktualisierten Spalten eine feste oder variable Länge haben

o Ob die Zeilenkomprimierung (COMPRESS YES) aktiviert ist

Wenn sich die Gesamtlänge der Zeile auch bei aktivierter Zeilenkomprimierung nicht ändert, berechnet und schreibt der

Datenbankmanager den optimalen partiellen XOR-Protokollsatz.

Wenn sich die Gesamtlänge der Zeile ändert, was bei der Aktualisierung von Spalten mit variabler Länge und bei aktivierter

Zeilenkomprimierung der Regelfall ist, stellt der Datenbankmanager fest, welches Byte sich als erstes geändert hat und schreibt

einen vollständigen XOR-Protokollsatz.

99 Juni 2012



4 Felder/“columns“ (contn‘d)

• Bei DEC-Feldern ist die Genauigkeit mit einem ungeraden Wert anzugeben (um effizientes Speichern

zu ermöglichen – wegen Vorzeichen-Halbbyte)

• Ganze Zahlen sind als SMALLINT, INTEGER oder BIGINT zu definieren.

• Fingerabdruck(„footprint“):

o jede Tabelle sollte einen INSert-Fingerabdruck besitzen

o jede Tabelle mit Updates sollte auch einen AENDerungs-Fingerabdruck besitzen

o Der Fingerabdruck sollte aus folgenden 4 Feldern bestehen (pppp=Feld-Prefix):

<pppp>TSINS /TSAEND TIMESTAMP ... Timestamp Insert/Update(automatisch mit CURRENT ….)

<pppp>USERINS/USERAEND CHAR(8) ... User Insert/Update

USERINS/USERAEND: in diesem Feld sollte der User festgehalten werden, der die Speicherung veranlasst hat: M2-

User/ROK-User/3270-User.

Eine nachträgliche Unterscheidung ist aufgrund des Formates erkennbar.

TSINS/TSAEND: in diesem Feld sollten Änderungen festgehalten werden – egal woher sie kommen (also müssen sie als

„constraints“ definiert sein)

• Journalisierung:

o Sollte es erforderlich sein, die einzelnen Schritte, in denen eine Tabelle verändert wurde aufzuzeichnen, so ist

„Journalschreibung“ auf Tabellenebene (alle oder einzelne Felder) eine Lösung

100 Juni 2012



5 Constraints

5.1 Referenzielle Constraints

Sind bei der NORD/LB prinzipiell nicht zu verwenden, da derartige Konstrukte im Rahmen der Administrationsaufgaben zu

großen Aufwänden führen können (Backup-Restore von zusammenhängenden Tabellen/Systemen)

Referenzielle Constraints definieren die Beziehung zwischen 2 Tabellen.

OFFEN: Seit Version 8 stehen auch „Informational Referential Constraints“ zur Verfügung. Diese rein informativen, jedoch

nicht bindenden Beziehungsdarstellungen könnten in einer weiteren Überarbeitung dieser Dokumentation in Betracht gezogen

werden.

5.2 Check Constraints

Sind bei der NORD/LB prinzipiell nicht zu verwenden, da sie die Performance wesentlich verschlechtern können. Checks werden

grundsätzlich dediziert in den Programmen durchgeführt!

5.3 Unique Constraints

Sind bei der NORD/LB prinzipiell nicht zu verwenden, da sie die Performance (wesentlich) verschlechtern können. Denselben

Effekt kann man mit entsprechenden Unique-Indizes erreichen.

Usw. usw. usw. – im Rahmen von Design-Richtlinien sollten alle Eckwerte festgeschrieben

werden…………

101 Juni 2012


Kapitelinhalt











• Datentypen








102 Juni 2012

DB2 DB2 –– DB2 Programmdesign & PerformanceDB2 Programmdesign & Performance

„Application Code“ und SQL

• Die meisten Tuningexperten von relationalen Systemen sind

sich einig, dass die Mehrzahl von Performance-Problemen

bei Applikationen, die relationale DBMS zugreifen von Schlecht geschriebenen Programmen oder

Unpassend kodiertem SQL… ( 70% bis 80%)

herrühren

• Einfacher ist besser, aber komplexe SQL können effizienter sein

• Generell gilt: SQL sollte die Arbeit machen, nicht das Programm

• Fordern Sie das absolute Minimum an “rows” aus der DB an

• Fordern Sie nur die benötigten Spalten an – niemals mehr…

• Setzen Sie immer “join predicates” (i.e. nie ein “kartesisches Produkt”)

• Favorisieren Sie Stage 1- und “Indexable” Prädikate Datentypen der Host variablen sollten in Type und Länge zu den “columns” passen

• Vermeiden Sie “tablespace scans” auf grossen Tabellen (normalerweise)

• Vermeiden Sie SORTs wenn möglich: Indexe für ORDER BY und GROUP BY

Gewissenhafter Umgang mit DISTINCT

UNION ALL vs UNION (wenn möglich)

103 Juni 2012

Die „stages“

Stage-2

Stage-1

4

Buffermanager

Request Request Response Response

Phys . I/O

Indizierte

Prädikate

Weitere IX- Key - Prädikate werden wirksam

Alle übrigen Stage1- Alle übrigen Stage1- Prädikate werden Prädikate werden wirksam wirksam

Alle Stage2- Prä - dikate werden wirksam

CPU ! CPU !

IX-

Zugriff

Zugriff auf

Datenpage 3 2 1

(Relational) Data Manager (DM)(Relational) Data Manager (DM)

Relational Data Services (RDS)Relational Data Services (RDS)

BufferBuffer ManagerManager

Physical I/O Physical I/O

(PIO)(PIO)

STAGE 2 – evaluiert nach

„data retrieval“ (non-sargable)

via RDS (Relational Data

Services) – damit teurer als

der DataManager.

STAGE 1 - – evaluiert zum

Zeitpunkit des Lesens der

Daten-“rows” (sargable). Ein

Performance-Vorteil von Stage

1 Prädikaten ist die Tatsache,

dass weniger „rows“ vom

Data Manager an Stage 2

übergeben werden müssen


104 Juni 2012

„application tuning“ & Optimization


105 Juni 2012

„application tuning“ : Explain Analyse


• Hint used?

• Index used?

− Single, Multiple

• Matching column(s)?

• Index only?

• TS scan (page range)

• Type of Join?

− Nested Loop

− Merge Scan

− Hybrid

• Prefetch?

− Sequential

− List

− „dynamic“

• Parallelism used?

− I/O, CPU, Sysplex

− Degree

• Sort required?

− Join, Unique, Group By,

Order By

• Locking

• SQL Text

• Table & Index

Information

− DDL

− Stats

• Cardinality

• Other Stuff

− Triggers

− RI

− Constraints

106 Juni 2012

„application tuning“ : Locking


• Planen und implementieren Sie eine “COMMIT Strategie”

− oder gehen Sie mit TIMEOUTs und DEADLOCKs entsprechend um

• Vermeiden Sie “deadlocks” durch Kodieren von Modifikationen in derselben Sequenz

ohne Rücksicht auf das Programm

• Setzen Sie SQL, das Daten modifiziert, so nah, wie möglich ans Ende einer UOW

− je später in der UOW ein “update” erfolgt, desto kürzer ist die Dauer einer Sperre

• Focussieren Sie auf „Lock Avoidance“

− ISOLATION(CS) / CURRENTDATA(NO)

− ist vor allem wirksam für “read only” Cursors

• Nutzen Sie LOCK TABLE sehr gewissenhaft (oder NIE)

• ISOLATION(UR) kann “locking” vermeiden helfen

• Vermeiden Sie das „Bachelor Programming Syndrome“

107 Juni 2012

„application tuning“ : Programm


• Schreiben Sie NIE effizientes SQL in ineffizienter Programm-Logik

− Klassisch: feingetuntes, effizientes SQL in einem Programm, wo eine Schleife damit

3,510,627 mal läuft!

• Lassen Sie SQL die Arbeit verrichten –wenn möglich

− z.B. Kodieren Sie keine “program joins“

• Anzeichen für Ärger: SQL gefolgt von einer Menge von IF...ELSE bzw. CASE Statements

• Will man nur eine einzige “row” als Ergebnis: Kodieren Sie einen “singleton SELECT”

(usually)

Online vs. Batch

• Wenn Sie “online transactions” designen, limitieren Sie die Menge an Daten, die

zurückgegeben werden auf einen realistischen Wert

− Kein Mensch liest 1000de Pages/”screens” online!

• Limitieren Sie “online” SORTs und Joins (angemessen)

• Verwenden Sie OPTIMIZE FOR 1 ROW, um den List Prefetch auszuschalten

− Beim LP liest DB2 eine Liste von RIDs aus einem “matching “ IX, sortiert diese und greift

auf die Daten über diese “RID list” zu

− kann sehr ineffizient sein bei “multiple page transactions”

108 Juni 2012


Database Object Tuning

109 Juni 2012


Database Organisation

• Seien sie sicher, dass RUNSTATS läuft

− wenn sich das Datenvolumen ändert, neue Datenstrukturen hinzugefügt werden

− gefolgt von PREP , (RE)BIND mit EXPLAIN bei ”static” SQL

mit EXPLAIN auf das Package/Programm bei ”dynamic” SQL

• Prüfen Sie die “statistics”, um zu entscheiden, ob ein REORG sinnvoll ist

− NEARINDREF und FARINDREF

− LEAFDIST, PERCDROP

− bei „clustering indexes“

NEAROFFPOSF und FAROFFPOSF

CLUSTERRATIOF

– Analysieren Sie das Zugriffsprofil vor dem REORG

Random vs. „sequential“

Denken Sie über eine

Automatisierung nach

110 Juni 2012

DB2 DB2 –– Design & Tuning (zusammenfassend)Design & Tuning (zusammenfassend)

Database Design & Tuning

• Applikation

• Database

• DB2 Subsystem

• Environment

• Eins nach dem anderen und

• YES, you can tune DB2!

111 Juni 2012

DB2 DB2 –– Design & Tuning Design & Tuning -- ÜbungenÜbungen

1. Sie haben Ihre DB um einige Tabellen erweitert. Was müssen Sie tun, um auf diese

neuen Tabellen optimales Zugriffsverhalten bei DB2 zu ermöglichen. – SQL-

Optimierung ist nicht gemeint !!!

2. Formulieren Sie folgende Queries nach den eben gehörten Empfehlungen in

effiziente Queries um:

a) SELECT PERS_NR

, NACHNAME

, VORNAME

FROM V_MITARBEITER M

WHERE PERS_NR IN ( SELECT PERS_NR

FROM V_M_PROJ_AKT

WHERE PERS_NR IS NOT NULL

)

ORDER BY 2

b) SELECT ABT_NR

, AVG(GEHALT)

FROM V_MITARBEITER

WHERE ABT_NR IS NOT NULL

GROUP BY ABT_NR

HAVING AVG(GEHALT) <= ALL ( SELECT AVG(GEHALT)

FROM V_MITARBEITER

WHERE ABT_NR IS NOT NULL

)

112 Juni 2012

DB2 DB2 –– Design & Tuning Design & Tuning -- ÜbungenÜbungen

c) SELECT A.ABT_NR

, A.ABT_NAME

, M.NACHNAME

FROM V_MITARBEITER M

, V_ABTEILUNG A

WHERE A.ABT_LTNR = M.PERS_NR

UNION

SELECT A.ABT_NR

, A.ABT_NAME

, '** UNBEKANNT **'

FROM V_ABTEILUNG A

WHERE NOT EXISTS ( SELECT *

FROM V_MITARBEITER

WHERE PERS_NR = A.ABT_LTNR

)

ORDER BY 2

3. Welche Informationen brauchen Sie, um effiziente Queries erkennen zu

können? – Welche Arten von Queries sind am effizientesten ?

113 Juni 2012

DB2 DB2 –– Design & Tuning Design & Tuning –– „„ThanksThanks““

ibm db2 - s.k. consulting und p… · db2 – logisches design: die ressource „information“...

Documents