IBM DB2 - S.K. Consulting und P… · DB2 – logisches Design: Die Ressource „Information“...
Transcript of 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
DB2 DB2 –– DB2 Design und PerformanceDB2 Design und Performance
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.
DB2 DB2 –– DB2 Design und PerformanceDB2 Design und Performance
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
DB2 DB2 –– DB2 Design und PerformanceDB2 Design und Performance
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
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 ?
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
DB2 DB2 –– logisches Design: Die Ressource „Information“logisches Design: Die Ressource „Information“
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
DB2 DB2 –– logisches Design: Die Ressource „Information“logisches Design: Die Ressource „Information“
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
DB2 DB2 –– logisches Design: Die Ressource „Information“logisches Design: Die Ressource „Information“
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
DB2 DB2 –– logisches Design: Die Ressource „Information“logisches Design: Die Ressource „Information“
Strategie der Informationsplanung
Unternehmensweites Informationsmodell
Informationsverarbeitung
Organisation
Information
Datenbank System
Funktion(BP)
physisch
logisch
12 Juni 2012
DB2 DB2 –– logisches Design: Die Ressource „Information“logisches Design: Die Ressource „Information“
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
DB2 DB2 –– logisches Design: Die Ressource „Information“logisches Design: Die Ressource „Information“
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
DB2 DB2 –– logisches Design: Die Ressource „Information“logisches Design: Die Ressource „Information“
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
DB2 DB2 –– logisches Design: Die Ressource „Information“logisches Design: Die Ressource „Information“
Redundanzfreiheit, Zuverlässigkeit und Aktualität verlangen nach Datenintegration…
.... klare eindeutig definierte
Informationsbegriffe und
Informationszusammenhänge
16 Juni 2012
DB2 DB2 –– logisches Design: Die Ressource „Information“logisches Design: Die Ressource „Information“
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
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das Sichtenmodell der Systementwicklung
d.h. Integration von
Wissen
Methode und
Toolunterstützung
19 Juni 2012
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
…. Manche Informationen sind GOLD wert….
20 Juni 2012
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das Problem: INFORMATION ist in ihren Vorkommenstypen SUBJEKTIV !
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das Problem: INFORMATION ist in ihren Vorkommenstypen SUBJEKTIV !
niemand interessiert ALLES ...
jedes Unternehmen bildet nur SEINEN
relevanten Ausschnitt der realen Welt ab....
23 Juni 2012
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das Problem: INFORMATION ist in ihren Vorkommenstypen SUBJEKTIV !
23
Beispiel
Kunden
Kredite
????
Spareinlagen
Bank
Weinhandlung
Winzer
Kunden
?????
Weine
Anbaugebiete
24 Juni 2012
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das Relationenmodell….
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das Relationenmodell….
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das Relationenmodell….
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das Relationenmodell….
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das Relationenmodell….
VI. Adressierung der Daten aufgrund ihres Inhalts VI. Adressierung der Daten aufgrund ihres Inhalts
MITARBEITER PERSNR NAME PLZ WOHNORT
4711 Meyer 85556 München
5011 Huber 80121 Ottobrunn
6122 Kraus 89104 Augsburg
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das Relationenmodell….
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).
MITARBEITER PERSNR NAME PLZ WOHNORT
4711 Meyer 85556 München
5011 Huber 80121 Ottobrunn
6122 Kraus 89104 Augsburg
PROJ-MITARB PRJNR PERSNR STUNDEN
110 4711 10
210 4800 7
180 4711 2
340 5011 6
Operation : (natural) JOIN
32 Juni 2012
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das Relationenmodell….
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das Relationenmodell….
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das Relationenmodell….
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das Relationenmodell….
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das Relationenmodell….
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das Relationenmodell….
IX NORMALISIERUNG – Die 2. Normalform (NF2)
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das Relationenmodell….
IX NORMALISIERUNG – Die 3. Normalform (NF3)
Die 3NF ist erreicht, wenn
die 2. Normalform erreicht ist
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das Relationenmodell….
IX NORMALISIERUNG – Die 4. Normalform (NF4)
Die 4NF ist erreicht, wenn
die 3. Normalform erreicht ist
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das Relationenmodell….
IX NORMALISIERUNG – Die 5. Normalform (NF5)
Die 5NF ist erreicht, wenn
die 4. Normalform erreicht ist
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das Relationenmodell….
X Datenmanipulation im Relationenmodell
Bildung von Teil- /Untermengen
Bilden von Schnittmengen
Bilden von Vereinigungsmengen
Bilden von
Ausschlußmengen/Komplementäre
42 Juni 2012
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das Relationenmodell….
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das Relationenmodell….
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
4711 Meyer 7500 Karlsruhe 800.000 €
4800 Müller 6800 Mannheim 750.000 €
3210 Ludwig 8000 München 660.000 €
44 Juni 2012
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das Relationenmodell….
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
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 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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das Relationenmodell….
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das Relationenmodell….
X Datenmanipulation im Relationenmodell: outer JOIN Probleme
Design-Fehler können bei der JOIN-Operation zu “outer-join”-Problematiken führen !!!!!!!!
MITARBEITER PERSNR NAME PLZ WOHNORT
4711 Meyer 8000 München
5011 Huber 8012 Ottobrunn
6122 Kraus 8900 Augsburg
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das Relationenmodell….
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das „entity relationship“-Modell (ERM)….
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das „entity relationship“-Modell (ERM)….
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das „entity relationship“-Modell (ERM)….
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das „entity relationship“-Modell (ERM)….
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das „entity relationship“-Modell (ERM)….
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das „entity relationship“-Modell (ERM)….
Was ist eine RELATIONSHIP
R ELATIONSHIP Beziehung zwischen beliebig
vielen “entities”
RELATIONSHIP-TYPE Zusammenfassung von
Beziehungen nach
bestimmten Wesensarten
55 Juni 2012
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Das „entity relationship“-Modell (ERM)….
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Die Methoden – ERM & relationaler Ansatz
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Die Methoden – ERM & relationaler Ansatz
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Die Methode IA – der Weg und das Ergebnis
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Die Methode IA – der Weg und das Ergebnis
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
Die Methode IA – der Weg und das Ergebnis
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
DB2 DB2 –– logisches Design: Entwickeln eines DMlogisches Design: Entwickeln eines DM
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
DB2 DB2 –– DB2 logisches Design (Methode)DB2 logisches Design (Methode)
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 ?
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
DB2 DB2 –– physischer physischer Designprozess&PerformanceDesignprozess&Performance
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
DB2 DB2 –– physischer physischer Designprozess&PerformanceDesignprozess&Performance
PDB – Vorgehen allgemein
Konzeptionelles Informationsmodell Funktionsmodell
Grafik
Dokumente
("business rules")
Abhängigkeiten...
Grafik
(Ablauf-) Beschreibung
(Mengen)
(Häufigkeiten)
(Zugriffsarten) ...
77 Juni 2012
DB2 DB2 –– physischer physischer Designprozess&PerformanceDesignprozess&Performance
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
DB2 DB2 –– physischer physischer Designprozess&PerformanceDesignprozess&Performance
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
DB2 DB2 –– physischer physischer Designprozess&PerformanceDesignprozess&Performance
PDB – Vorgehen allgemein: Übernahme der „entities“
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
DB2 DB2 –– physischer physischer Designprozess&PerformanceDesignprozess&Performance
PDB – Vorgehen allgemein: Übernahme der „entities“
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
DB2 DB2 –– physischer physischer Designprozess&PerformanceDesignprozess&Performance
PDB – Vorgehen allgemein: Übernahme der „entities“
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
DB2 DB2 –– physischer physischer Designprozess&PerformanceDesignprozess&Performance
PDB – Vorgehen allgemein: Übernahme der „entities“
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
DB2 DB2 –– physischer physischer Designprozess&PerformanceDesignprozess&Performance
PDB – Vorgehen allgemein: Übernahme der „entities“
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
DB2 DB2 –– physischer physischer Designprozess&PerformanceDesignprozess&Performance
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
DB2 DB2 –– physischer physischer Designprozess&PerformanceDesignprozess&Performance
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
DB2 DB2 –– physischer physischer Designprozess&PerformanceDesignprozess&Performance
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
DB2 DB2 –– physischer physischer Designprozess&PerformanceDesignprozess&Performance
PDB – Bauen Sie ihre Informationsumgebung nach NUTZENGESICHTSPUNKTEN auf ....
88 Juni 2012
DB2 DB2 –– DB2 logisches Design (Methode)DB2 logisches Design (Methode)
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 ?
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
DB2 DB2 –– physisches Designphysisches Design
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
DB2 DB2 –– physisches Designphysisches Design
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
DB2 DB2 –– physisches Designphysisches Design
PDB – DB2 Empfehlungen zum physischen (systemspezifische) Design für DB2 ….
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
DB2 DB2 –– physisches Designphysisches Design
PDB – DB2 Empfehlungen zum physischen (systemspezifische) Design für DB2 ….
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
DB2 DB2 –– physisches Designphysisches Design
PDB – DB2 Empfehlungen zum physischen (systemspezifische) Design für DB2 ….
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
DB2 DB2 –– physisches Designphysisches Design
PDB – DB2 Empfehlungen zum physischen (systemspezifische) Design für DB2 ….
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
DB2 DB2 –– physisches Designphysisches Design
PDB – DB2 Empfehlungen zum physischen (systemspezifische) Design für DB2 ….
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
DB2 DB2 –– physisches Designphysisches Design
PDB – DB2 Empfehlungen zum physischen (systemspezifische) Design für DB2 ….
4 Felder/“columns“
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
DB2 DB2 –– physisches Designphysisches Design
PDB – DB2 Empfehlungen zum physischen (systemspezifische) Design für DB2 ….
4 Felder/“columns“
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
DB2 DB2 –– physisches Designphysisches Design
PDB – DB2 Empfehlungen zum physischen (systemspezifische) Design für DB2 ….
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
DB2 DB2 –– physisches Designphysisches Design
PDB – DB2 Empfehlungen zum physischen (systemspezifische) Design für DB2 ….
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
DB2 DB2 –– DB2 logisches Design (Methode)DB2 logisches Design (Methode)
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 ?
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
DB2 DB2 –– DB2 Programmdesign & PerformanceDB2 Programmdesign & Performance
104 Juni 2012
„application tuning“ & Optimization
DB2 DB2 –– DB2 Programmdesign & PerformanceDB2 Programmdesign & Performance
105 Juni 2012
„application tuning“ : Explain Analyse
DB2 DB2 –– DB2 Programmdesign & PerformanceDB2 Programmdesign & Performance
• 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
DB2 DB2 –– DB2 Programmdesign & PerformanceDB2 Programmdesign & Performance
• 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
DB2 DB2 –– DB2 Programmdesign & PerformanceDB2 Programmdesign & Performance
• 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
DB2 DB2 –– DB2 Programmdesign & PerformanceDB2 Programmdesign & Performance
Database Object Tuning
109 Juni 2012
DB2 DB2 –– DB2 Programmdesign & PerformanceDB2 Programmdesign & Performance
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““