LV Programmierung 3.doc Version 07.11.00 22:40 Seite 1 von 47 ...

home.wtal.de

LV Programmierung 3.doc Version 07.11.00 22:40 Seite 1 von 47 ...

LV Programmierung 3.doc Version 07.11.00 22:40 Seite 1 von 47

LV Programmierung 3, Prof. Haas, WS 2000/2001, Stand 14.10.2000 17:20 Folie 1

Programmierung 3 SQL, PL/SQL und Oracle-Developer

Prof. P. Haas, FH Dortmund

Folienabzüge zur Lehrveranstaltung Teil 1 – DB-Design und SQL WiSem 2000

Gesamtübersicht

1. Einführung

2. Relationales Modell und SQL - Standard Query Language / ORACLE

3. Integritätsaspekte und deren Implementierung

4. Ausgewählte Problemstellungen

5. Anhang

Übersicht: Programmierung 3

1. Einführung

1.1 Datenbanken – kurze Einführung

1.2 Aspekte des Datenbankentwurfs

1.2.1 Abstraktionsebenen, 3-Ebenen-Modell

1.2.2 Systemanalyse/Vorgehen und Analyseraster

1.2.3 Semantische Modellierung mittels ER-Modell

1.2.4 Tool-Unterstützung: S-Designor als Modellierungswerkzeug

1.2.5 Modell-Diskussionen zum FH-Modell und Filmstudio

2. Relationales Modell und SQL

2.1 Warum Schwerpunkt „relationale Systeme“?

2.2 Grundlagen des relationalen Modells

2.3 Einschub SQL: Anlegen von Tabellen, Manipulation von Inhalten

24 Das Problem der Schlüsselwahl

2.5 Vom ERM/Klassenmodell zur relationalen DB

2.6 Spezielle Konstrukte und semantische Bedeutung von Tabellen

2.7 Relationale Algebra und Operationen und entsprechende SQL-Befehle

2.8 Nullwertbehandlung

2.9 Normalisierung

2.10 Tabellenarten, semantische Bedeutung von Tabellen

3. Integritätsaspekte und deren Implementierung

4.1 Objekt-Integrität

4.2 Refrentielle Integrität

4.3 Semantische Integrität

4.3.1 Einführung und Beispiele

4.3.2 Deklarative Mechanismen

4.3.3 Domain-Tabellen

4.4 Trigger zur Integritätssicherung

4.5 Ablaufintegrität und Transaktionsmanagement

2.7.5.1 Problemstellung und Fehlerfälle

2.7.5.2 Transaktionsverwaltung

2.7.5.3 Implementierung am Beispiel Oracle

4. Ausgewählte Problemstellungen

4.1 Datenschutz

4.1.1 Rechtliche Rahmenbedingungen

4.1.2 Zugangsebenen und Schutzmechnismen

4.1.3 SQL-Berechtigungkonzept

... am Bsp. Oracle

4.1.5 Digitale Signatur / Bsp. Oracle 8

4.1.6 Vorgehen zur Entwicklung eines DS-Konzeptes

4.2 Datensicherheit

4.3 Parametrierbarkeit/Adaptibilität

4.4 Mandantenfähigkeit

5. Anhang

5.1 Fallstudie Filmstudio

5.2 Literatur


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 2 von 47

LV und ergänzende Know-How-Komponenten

Dokumentationslehre

Algorithmen &

Datenstrukturen

Datenbanken

Anwendungswissen

Datenmodellierung

Systemanalyse

Anwendungsentwicklung

Projektmanagement


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 3 von 47

Nachteile der konventionellen Organisation

Unflexibel, meist nur ein Zugriffsschlüssel oder Verwaltung komplexer

Sekundärschlüsselstrukturen

Beschränkung bei Mehrfachzugriffen und -änderungen

Mehraufwand bzw. -kosten für Speicherplatz

Verarbeitung

Programmierung

Datenschutz und Datensicherheit

Redundanz und Probleme der Integrität

physische und logische Datenabhängigkeit

Programmierer für Datenorganisation verantwortlich

Schritte des DBMS (vereinfacht)

Befehl von “extern” entgegennehmen, bestimmte Daten bereitzustellen

Definitionen aus externem Schema des Programms besorgen

Besorgen des zugehörigen Teiles des internen Schemas und Feststellen, welche Entities und

Beziehungen sprich Tabellen gebraucht werden

Prüfung auf Berechtigung für die angeforderten Operationen/Objekte

Feststellen der benötigten Teile des physischen Schemas, d.h. welche Sätze ggf. unter

Nutzung welcher Pfade zu lesen sind

Umsetzung der Leseoperationen und Inauftraggabe an BS-Komponenten

Entgegennehmen und Konvertieren gemäß Auftrag

Übergabe an das rufende Programm bzw. in den Puffer bzw. Speicherbereich


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 4 von 47


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 5 von 47

Befehlsabarbeitung am Beispiel

SELECT Titel FROM Buch WHERE Erstautor = ‘Date‘;

v Überprüfung Syntax

Feststellen ob Tabelle in der DB

Feststellen ob der fragende Benutzer Operation ausführen darf

Feststellen welche internen Operationen zur Durchführung auszuführen sind

Erstellung eines möglichst effizienten Programms zur Berechnung der Antwort

Holen der Operanden aus der DB

Aufbereiten zum Zweck der Ausgabe

Sicherstellen der Mehrbenutzersynchronisation

Welche Hauptfunktionen / Bestandteile

Datenhaltung / DB-Kern

Verwaltung von Meta-Daten / Daten-Diktionär

Daten-Zugriffs-Optimierung / Datenspeicherung und Indizierungs-/ Zugriffsstrukturen auch bei

sehr großen Datenbeständen

Synchronisationsmechanismen / Transaktionsmechanismen

Datensicherheit gewährleisten / Sicherungsmechanismen Logging, Backup-Tools etc.

Datenschutz gewährleisten / Datenschutzsystem

Integrität sicherstellen / Integritätsmechanismen auf verschiedenen Ebenen

Abfragen (relativ einfach) ermöglichen) / Query-Komponenten bzw. Abfragesprache

Benutzerspezifische Sichten ermöglichen

Unterstützung verteilter Systeme

Unterstützung komplexer Dokumente (Informationsobjekte)

Vorteile bei Verwendung eines DBMS

Speicherung und (optimiertes) Wiederauffinden unabhängig vom Verwendungszweck

physische und logische Datenunabhängigkeit

Redundanzarme Abspeicherung (bzw. kontrollierte Redundanz)

Einheitliche u. zentrale Kontrolle von Operationen auf den Daten

Management konkurrierender Anforderungen

automatische, einheitliche Datensicherung, Wiederanlaufverfahren

umfangreiche Datenschutzmechanismen

Austauschbarkeit (bedingt)

physische Datenverteilung


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 6 von 47

DBMS im Berufsalltag des Informatikers

Endbenutzerbetreuung

Anwendungsbetreuung

Datenbankbetreuung

Datenbankadministrator

Entwicklungs-Projektleiter --> DB-Enterprise-Manager

Anwendungs-Programmierung

Datenbank-Programmierung, System-Programmierung

Warum Schwerpunkt relationale Systeme ?

Heute State-of-the-Art in der Praxis

Diebold-Analystem meinen:

1997 entfielen rund 78 % des weltweiten DB-Gesamtumsatzes von 5 Milliarden Dollar auf

relationale Systeme. Der relationale DB-Markt wird auch weiterhin stark wachsen, mit

Wachstumsraten von jährlich ca. 16 %. (Comp. Zeitung 7 /12.2.98)

ORACLE-Aktie in letzen 5 Monaten verfünffacht

OO-DBMS erst in Erprobungs-/Marketeinführungsphase

Stabile und erprobte Verteilungskonzepte bei relationalen DBs

über 70 % aller kommerziellen MI-SW-Produkte für Krankenhäuser haben ORACLE als Basis,

Tendenz steigend

ORACLE bietet mit ORACLE 8 objektrelationale Perspektive und mit 8i INTERNET-

Umgebung

Konzeptionelles Datenmodell

= DBMS-unabhängige Gesamtsicht auf den interessierenden Realitätsausschnitt mittels

Darstellung der Objekttypen (Klassen)deren charakterisierenden Attribute und deren

Beziehungen untereinander.

Konzeptionelles Modell determiniert den Leistungsumfang des Anwendungssystems !!


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 7 von 47

Vorgehensschritte nach Ortner/Söllner (Reihenfolge modifiziert)

1. Schritt: Feststellung gültiger (relevanter) Aussagen über Sachzusammenhänge aus dem

Anwendungsbereich

2. Schritt: Klärung und Rekonstruktion der Fachbegriffe für die Informationsobjekte

3. Schritt: Analyse der Beziehungen zwischen den Begriffen (Objekttypen)

4. Schritt: Ergänzung der Objekttypen um charakterisierende Attribute

5. Schritt: Abbildung der Objekttypenbeziehungen auf Attributebene

6. Schritt: Integration der rekonstruierten Fachbegriffe (Objekttypen) mit ihren Beziehungen in

das bereits existierende konzeptionelle Schema

7. Schritt: Erweiterung (Vervollständigung) des Schemaentwurfes um (weitere)

Integritätsbedingungen

Zur Wiederholung

Klassen, Entity-Typen

Domains

Beziehungen und Kardinalitäten

Beziehungsklassen

Abstrakte Klasse / individuelle Klasse

Spezialisierung („IS-A“-Beziehung)


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 8 von 47

Abstraktionskonzepte zum erweiterten ERM

Klassifikation --> Menge gleicher oder ähnlicher Entities zusammenfassen

Generalisierung/Spezialisierung --> Überdeckungen bei charakterisierenden Attributen

Komposition durch

Konnexion (meist als Aggregation bezeichnet) --> verschiedene Entity-Typen zu einem

komplexen Typ assemblieren (IS-PART-OF) Bsp. Segelschiff aus Rumpf, Mast, Segel, Motor

Aggregation --> gleiche Entities zu komplexen Typ assemblieren Bsp.: Fußballmannschaft,

Schiffskonvoi etc.

Abstrakte Klasse / individuelle Klasse


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 9 von 47

Tool-Unterstützung z.B. mit S-Designor oder Rational Rose

= Hilfe beim Zeichnen und Umzeichnen der Modelle

= Strukturierte Verwaltung der Klassen und deren Attribute

Automatische Verfügbarkeit eines Diktionärs

= weitegehend automatische Ableitung des internen DB-Modells

= einfache Definition und Pflege des physischen Modells

einfache Verwaltung der benötigten Trigger

Generierung des internen Modells und nachfolgend des SQL-Codes (S-Designor: für ca. 50

Datenbanken)

je nach Zielsystem Direktgenerierung des DBMS

Relationale Systeme

E.F. Codd, 1970 "A Relational Model of Data for Large Shared Data

Banks"

Erste (gedankliche) Entwicklung des relationalen Modells

Grundlage für Innovationssprung in der DB-Entwicklung

Erste "Sprachversuche" Structured English Querg Language (SEQUEL) 1974,

IBM

Historie relationaler Systeme

Univ. of Berkeley ca. 1974 Prototyp "Interactive Graphics and Retrieval System" (INGRES)

Prototyp von IBM 1977 (System R)

In BRD Ende 70-er Jahre ADABAS durch Software AG

1979 Codd, "Extending the Database Relational Model to Capture more Meaning"

1982 SQL/DS und 1983 DB2 (IBM)

1980-1990 ganze Reihe neuer Systeme (u.a. Oracle)

1986 American National Standards Institut (ANS I) führt SQL als Standard ein [SQL86],

es folgen [SQL92] und [SQL96]

objektrelationale Systeme ab 1997

Relationaler Ansatz - Grundidee

Einfaches konzeptionelles Modell (Tabellen bzw. Relationen)

Anwendung fundierter mathematischer Theorie (Mengenenalgebra)

Mächtige Sprache für Datenmanagement (von der Satz- zur Mengenbearbeitung, nicht

prozedural!)

konzeptionelles und internes Modell übereinstimmend (nur wenn zur konzeptionellen

Modellierung das Relationenmodell genutzt wird)

Tabelle im relationalen Modell

Besteht aus Zeilen und Spalten

Jede Zeile (=Tupel) repräsentiert ein Entity

Spalten repräsentieren Attribute

Summe aller Tupel repräsentiert Entity-Set

Strukturelle Aspekte:

Tabellen - keine doppelten Tupel

- Zeilen- und Spaltenreihenfolge ist unerheblich

- alle Zelleneinträge sind atomar

Keine zwei Zeilen haben identische Candidate-Schlüsselwerte; falls ein Attribut des K-

Schlüssels gelöscht wird, geht die Eindeutigkeit verloren


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 10 von 47


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 11 von 47


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 12 von 47


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 13 von 47


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 14 von 47


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 15 von 47

Die Definition eines Schemas

Zusammenfassung mehrerer Creates und Zugriffserteilungen zu einer Transaktion

Einschränkung: Innerhalb nur Standard-SQL-Befehle

Zeitliche Reihenfolge des Anlegens bezgl. Der Abhängigkeiten spielt keine Rolle mehr


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 16 von 47


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 17 von 47

Relationales Modell – Die Wahl des Primary Keys

--> Frage: Was identifiziert den Kunden eindeutig?

Wie wählen wir den Primärschlüssel?

Schlüsseltypen im relationalen Modell

Superschlüssel --> eindeutig identifizierende Attributkombination

Candidate-Schlüssel --> minimale eindeutig identifizierende Attributkombination

Primärschlüssel --> gewählte identifizierende Attributkombination

Sekundärschlüssel --> Indizierungen für schnellen Zugriff, Index

Fremdschlüssel --> Referenzierung anderer Entities zur Realisierung von

Assoziationen

Relationale Systeme: INSERT / DELETE /UPDATE – Rules

... resultieren aus Integritätsbedingungen

Entity-Integrität Refrentielle Integrität

= keine Null-Werte im = Fremdschlüssel muß Null

Primärschlüssel bzw. sein oder passender Eintrag

dessen Attribute in der verbundenen Tabelle

Konsequenz aus Entity-Integrität

Schlüsseldiskussion

was identifiziert eindeutig?

wie „Änderungs-stabil“ ist der gewählte Schlüssel

Semantischer Schlüssel vs. Surrogat-Key d.h. nichtsemantischer Schlüssel

Probleme bei Primärschlüsseln

Problematik der semantischen Schlüssel

Werteänderungen in Schlüsselattributen

Komplexität zusammengesetzter Schlüssel z.B. bei Tabellen die abhängige Entity-Typen oder

Assoziationen repräsentieren (s. FH-Beispiel)

Problematik bei nicht-semantischen Schlüsseln

Surrogat-Key stellt in DB Eindeutigkeit sicher

Funktion des Primary Keys zur Sicherstellung der Entity-Integrität geht verloren !!

Notwendigkeit entsprechender Mechanismen zur Sicherstellung der Entity-Integrität, wenn

semantische Eindeutigkeit notwendig ist


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 18 von 47

Entscheidungskriterien für Schlüsselwahl

Nicht-semantisch bevorzugen

jedoch „Handling“ bei Abfragen und Joins kann umständlicher werden (s. Tafelbeispiel)

Semantisch wenn

einfache Domain-Tabelle (Bsp. PLZ-Tabelle --> wenig Sinn jeder PLZ eine eigene Objekt-ID

zu geben oder den Filmtypen etc.)

einfacher semantischer Schlüssel bei dem seine Unveränderlichkeit absolut sichergestellt ist

Perfomance-Überlegungen (Beispiel „Maßnahme“ und „Patientenmaßnahme“ im Krankenhaus-Modell)

Von der Umwelt zum OOA-Modell zum Datenmodell für ein RDBMS

Aus statischem und dynamischen Modell Entwurf des internen

relationalen Modells sowohl strukturell (Tabellen und Beziehungen,

Constraints) als auch dynamisch (Trigger) statisches Modell


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 19 von 47

Überführung ERM -> relationales Modell

Je Entity-Typ eine Tabelle

Attribute werden zu Tabellenspalten (Normalisierungsregeln beachten !!)

Tabellenzeilen (=Ausprägungen) repräsentieren die Entities

Identifizierender Schlüssel wird zu Primary Key

Je M:N-Beziehungstyp eine Tabelle für den Beziehungstyp mit zusammengesetztem

Schlüssel

Bei 1:N-Beziehungen Mitaufnehmen des Fremdschlüssels in die entsprechende Tabelle

Beachtung der notwendigen Weitergabe von Löschungen, Änderungen etc. in Abhängigkeit

der Beziehungsart (s. bei Kaskadierungen)

3 Varianten für Realisierung der Generalisierungs/ Speziali-sierungsstruktur,

Entwurfsentscheidung in Abhängigkeit der Unterschiede bei Struktur (Attribute und

Beziehungen)

Konnexion Bei M:N-Konstruktion eine Tabelle für den Konnexions-Entity-Typ und eine

Tabelle für die “Beziehungen” mit komplexen Schlüsseln, bei 1:N ggf. Primary Key des

Fremdschlüssels der Konnexions-Entity- Typ-Tabelle in die einzelnen Tabellen der beteiligten

Entity-Typen,

Aggregation Je nach Komplexität der Zusammensetzung Aufnahme der

Primärschlüssel der beteiligten Entity-Typen als Fremdschlüssel in die Tabelle des aus der

Aggregation entstandenen Entity-Typs

Sonderfall: Rekursive Strukturen (z.B. Hierarchie, Betriebs-Organisation)

Prinzipielle Tabellenarten

Basis-Tabelle (Basis-Relation)

Alle Attribute sind prinzipiell vorhanden bzw. originär

Abgeleitete Tabelle

Tabelle wird vollständig von vorhandenen Tabellen abgeleitet

z.B. mittels eines Views, ist also virtuell

z.B. mittels Snapshot oder Trigger, Kopie ist also persitent

Semi-Abgeleitete Tabelle

Einige Attribute sind originär, einige abgeleitet bzw. berechnet (z.B. über Trigger)

--> Performance- und Praktikabilitätsüberlegungen wesentlich

Semantische Bedeutung von Tabellen

Tabelle repräsentiert ....

Entity-Typ

Spezialisierung eines Entity-Typs

Beziehungstyp

Spezialisierung eines Beziehungstyps

Aggregation/Konnexion

Domain für ein Attribut

Historisierung einer Assoziation (1:N wird durch Historisierung zu N:M aber je Zeitpunkt nur

eine „aktive“ Assoziation gültig)

Historisierung eines Attributes bzw. Attributänderungen


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 20 von 47

Relationale Algebra

Spezielle Operationen zur Manipulation n-wertiger Relationen

THETA - SELECT

PROJEKTION

THETA - JOIN

NATURAL - JOIN

DIVIDE

Kartesisches Produkt als Sonderform des Join

Operationen gemäß Mengenalgebra

UNION

INTERSECTION

SET-DIFFERENCE

Theta-SELECT

Selektion von einzelnen Zeilen einer Tabelle

Selektionsbedingung beliebig komplex

Theta-SELECT

Kunde [Geburtsdatum < 1.1.60]

Kunde :

Theta-SELECT

Kunde [Geschlecht = m]

Kunde :

PROJEKTION

Nur gewisse Spalten herausgreifen, einblenden

Projektion

Kunde [Name, Vorname]


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 21 von 47

Selektieren von Daten, Abfragen

Vereinfachte Darstellung:

SELECT FROM WHERE AND / OR

Definiert die Definiert die

Gewünschte Definiert die gewünschte

Projektion beteiligten Selektion

bzw. bei Angabe Tabellen /Views oder

von * Join-Beingung

keine Projektion


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 22 von 47


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 23 von 47


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 24 von 47


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 25 von 47

Weitere Select-Statement-Operatoren:

(+) Hinter einer Spaltenbezeichnung bedeutet dies, daß die Spalte eine OUTER-JOIN-

Spalte ist

* Wildcard bei Spaltenangabe, es werden alle Spalten ausgewählt

PRIOR Bei hierarchischen Abfragen wird hiermit eine Eltern-Kind-Beziehung zwischen Knoten

definiert

ALL Auch doppelte Zeilen werden ausgegeben

DISTINCT Eliminieren von doppelten Zeilen

Theta-Join

Verbinden von 2 Tabellen über eine Spalte

sinnvollerweise Join-Spalte über gleiches Attribut bzw. gleiche Domain

Kunde [Sex=Sex_Code]Geschlecht

Relationale Algebra: Join-Arten

Natural Join ( Gleichheit und Entfernen doppelter Join-Spalte)

Equi-Join ( Join-Bedingung mit Gleicheit )

Non-Equi-Join ( Ungleichheit bei Join-Bedingung )

Semi-Join ( Nur Spalten der erste Tabelle ausgeben )

Restricted Join ( weitere Nachselektion der Join-Menge)

Multiple Join ( Join mit mehreren Bedingungen über 3 und mehr Tabellen hinweg )

Auto-Join ( Joinen einer Tabelle mit sich selbst)

Bulk-Join (Kartesisches Produkt, d.h. Join ohne Join-Bedingung)

Outer-Join (mit Nullwert-Behandlung)

!! !!keine !! OR-Verbindung bei Outer-Joins !!


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 26 von 47

Relationale Algebra: DIVIDE

„Dividieren“ von Mengen

d.h. Werte der Tabelle 1 müssen über „DIVIDE-Spalte“ mit allen entsprechenden Werten der

Tabelle 2 assoziiert sein

Bsp.: Welcher Mitarbeiter arbeitet in allen Projekten mit?

Relationale Algebra: Kartesisches Produkt

Alle möglichen Kombinationen von Zeilen

Relationale Algebra: UNION

Vereinigungsoperation

nur für Vereinigungsfähige Mengen möglich, d.h. Spaltentypen müssen übereinstimmern

(syntaktische Bedingung) und Mengen müssen gleichartig sein (logische Bedingung) d.h.

Attribute haben gleiche Domain


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 27 von 47

Relationale Algebra: INTERSECTION

Durchschnitt von 2 Mengen

Einschränkungen wie bei UNION, nur „vergleichbare Mengen“

Relationale Algebra: SET DIFFERENCE

Differenz aus 2 Mengen

d.h. Abziehen einer Menge von einer anderen Menge, Einschränkungen wie bei UNION

Mengen-Operatoren in Oracle

UNION Vereinigt zwei Anfragen und gibt alle Zeilen die zu beiden Abfragen gehören zurück,

wobei doppelte Zeilen entfernt werden

UNION ALL Wie UNION jedoch auch doppelte Zeilen erscheinen

INTERSECT Gibt alle Zeilen zurück, die in beiden Ergebnis-mengen enthalten sind.

MINUS Gibt alle Zeilen zurück die in der 1. Anfrage enthalten sind aber nicht auch in der 2.

Anfrage


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 28 von 47

Spezielle Operationen mit Nullwertbehandlung

Beispiel Tabelle Lagerbestand mit Nullwerten

Anfrage: Alle Lagerteile mit Bestand > 10

--> Wie gehen wir mit den Teile-Nummern 3 und 6 um ?

--> siehe auch Tafelbeispiel: Patienten und Aufnahmediagnosen


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 29 von 47


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 30 von 47

Normalisierung, Normalformen

Durch Normalisierung sollen alle Redundanzen und ggf. Abhängigkeiten entfernt werden.

1. Normalform: Alle Schlüsselattribute sind definiert. Alle Attribute sind atomar (keine Gruppen

und keine mehrwertigen mehr!!) Es gibt keine Wiederholgruppen in der Tabelle. Alle Attribute

hängen vom Primärschlüssel ab

2. Normalform: Tabelle ist in 1. NF und enthält keine partiellen Abhängigkeiten d.h. kein

Attribut hängt nur von Teilen des Schlüssels ab

3. Normalform: Tabelle ist in 2. NF und enthält keine transitiven Abhängigkeiten (gutes ER-

Modell führt zumeist zu normalisiertem Tabellen-Entwurf)

--> siehe Tafelbeispiel „Projektmanagement“

Der Einsatz von Views

Verringerung der Datenbankstruktur-Komplexität

Verbesserung des Datenschutzes

Datenpräsentation und semantische Bennung aus verschiedenen Blickwinkeln

Befehlsvereinfachung z.B. durch automatische versteckte “Durchführung” von Join-

Operationen durch den View

Komplexe Abfragen mit komplexen Berechnungen speicherbar, Durchführung nur, wenn die

view abgefragt wird

Einschränkungen bei Views

Für DELETE/UPDATE/INSERT gilt:

nicht über Join-Views möglich

für alle Muß-Felder der zugrundeliegenden Basistabelle müssen Default-Werte definiert sein

es dürfen keine berechneten Felder enthalten sein

es dürfen keine Joins und group by enthalten sein

die einzufügenden, zu ändernden oder zu löschenden Zeilen müssen den im view definierten

Selektionskriterien genügen

Integritätssicherung mittels DBMS

Integrität, Konstitenz:

Der Datenbestand muß in sich widerspruchsfrei sein, Entities und deren Attributausprägungen

dürfen nur aus den definierten Domains stammen und alle aus dem betrieblichen Betrachtungsbereich

heraus formulierten Einschränkungen und Bedingungen müssen sichergestellt

sein

Entitäts- bzw. Objektintegrität

Refrentielle Integrität

Semantische Integrität

Ablaufintegrität


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 31 von 47

Entity-/Objekt-Integrität

Grundlagen s. Kapitel 2.3.1

Schlüsselwahl von hoher Bedeutung

nichtsemantische Schlüssel in Oracle:

° Anlegen einer SEQUENCE (je Tabelle oder generell)

° BEFORE INSERT OR UPDATE - Trigger anlegen zum Vergeben der Objekt-ID und

Sicherung ihrer Unveränderbarkeit

° Sicherstellung der „logischen“ Objekt-Integrität

- über die Definition eines UNIQUE-INDEX über die eindeutig identifizierenden

Attribute

- mittels Trigger-Algorithmus vor INSERT und UPDATE

siehe auch Beispiele und Diksussion bei Fallstudio „Filmstudio“

Refrentielle Integrität

Grundlagen siehe Kapitel 2.3.1

Hohe Bedeutung der korrekten Modellierung der Kardinalitäten und Muß-/Kann-Eigenschaft

bei den Assoziationen

Sicherstellung durch entsprechende Kaskadierungsdefinitionen bei Tabellendefinition

oder mittels Trigger

Vorsicht bei Nutzung einer Domain für Attribute mehrerer Tabellen hinsichtlich Kaskadierung


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 32 von 47

Semantische Integritätsbedingungen

„Absolut“ Statische Integritätsbedingungen z.B.:

Geschlecht kann nur männlich, weiblich oder unbekannt sein

nur volljährige Personen können Mitglieder werden d.h. Alter >= 18

Statische - aber sich kundenbezogen oder im Zeitverlauf ändernde - Bedingungen/Domains

z.B.:

° es gibt definierte Filmtypen

° es gibt definierte Unternehmenstypen

° Parametrierbarkeit der Domain bzw. Adaptivität des Informationssystems an sich

ändernde Bedingungen, Sicherstellung über Domain-Tabellen oder Trigger oder

auf Parametereinträgen basierende Trigger

Dynamische Integritätsbedingungen, sind abhängig von Zuständen, also kontextsensitiv, zB.:

° nur Schauspieler können Rollenverpflichtung haben

° wer in mehr als 5 Filmen mitgespielt hat ist VIP

° Terminierung einer Drehszene nur möglich, wenn für alle darin vorkommenden

Rollen ein Schauspieler verpflichtet wurde

° es kann auch die Bedingung selbst dynamisch sein z.B.:

° Berechnungsvorschrift des Rollenstundenkontingentes mit Faktor

1,2 soll veränderbar sein oder Faktor ist abhängig von der

Komplexität der

Rolle usw.

Beliebige Komplexität und Einflüsse denkbar

Sicherstellung jeweils mit

° Mechanismen in den Anwendungsprogrammen oder

° Mechanismen des DBMS wie

° DEFAULT-Clause bei Tabellendefinition

° parametrierbare „Domainisierung“ von Attributen (= Domain

Tabellen)

° UNIQUE-Sekundärschlüssel

° ereignisbezogene Trigger in der DB

Deklaration von Constraints beim CREATE TABLE

Vorteile:

Einfache Definition direkt beim Anlegen der Tabellen

Dokumentation implizit im Create-Skript

Performante Abarbeitung

Nachteile

Änderung der Bedingung führt zu DB-Schema-Änderung bzw. ALTER TABLE

wenig Transparenz der implementierten Constraints

Domain-Tabellen

Explizite Definition von Domains in eigenen Tabellen

+ Transparenz der gültigen Domains

+ Leichtes Ändern und Fortschreiben

+ Kundenbezogene Anpassung

+ Mehrfachnutzung für Attribute verschiedener Tabellen

+ Integritätssicherstellung über Foreign-Key-Bedingung oder

bei komplexer kontextsensitiver Nutzung über Trigger

+ mögliche Mehrspaltigkeit der Domain

- Anwachsen der Zahl der zu verwaltenden Tabellen

- Pflege und Fortschreibung der Domaintabellen

- ggf. Unnötigkeit der Tabellen aus Sicht des einzelnen Kunden


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 33 von 47


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 34 von 47


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 35 von 47

Trigger

In der DB gespeichertes Programm

Aktivierung zu definierten Zeitpunkten sprich Ereignissen

Trigger-Nutzung für ...

Holen und Einsetzen der Objekt-ID über SEQUENCE

Ggf. Sicherstellung der „logischen“ Entity-Integrität bei Nutzung eines nichtsemantischen

Schlüssels

Überprüfung einfacher bis komplexer semantischer Integritätsbedingungen

Anwendung zeitlich oder inhaltlich selektiver Constraints

Überprüfung komplexer refrentieller Integritätsbedingungen

Implementierung von kaskadierendem Ändern und Löschen

Steuerung der Fortschreibung des Entity-Status bei Nutzung von Objekt-Lebenszyklen

über den System-LOG hinausgehende Protokollierung

Implementierung von Datenschutzmechansimen

Satz- oder Befehlsbezogene DML-Folgeaktionen wie

..... für berechnete Felder Werte erzeugen oder Teilkopien anlegen

Trigger-Nutzung: Zur Beachtung

Namensrichtlinien

Dokumentation sowohl des Triggers selbst als auch seiner Wirkung innerhalb des

Datenmodelles

Kaskadierendes Aufrufen möglichst vermeiden

Widersprüche analysieren (Trigger vs. Andere implementierte Integritätsbedingungen)

Rekursionen vermeiden (A feuert B, B feuert C, C feuert wieder A usw.)

Behutsam und qualifiziert nutzen


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 36 von 47


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 37 von 47

Trigger verwalten

Anlegen mit CREATE TRIGGER

Modifizieren mit CREATE OR REPLACE TRIGGER

Deaktivieren mit ALTER TRIGGER DISABLE

Deaktivieren aller Trigger einer Tabelle mit ALTER TABLE DISABLE ALL TRIGGERS

Aktivieren eines einzelnen Triggers mit ALTER TRIGGER ENABLE

Aktivieren aller trigger einer Tabelle mit ALTER TABLE ENABLE ALL TRIGGERS

Löschen eines Triggers mit DROP Trigger

--> Beachte: Triggerbedingungen gelten ab Zeitunkt der Aktivierung,

es können also widersprechende Records in der DB sein, die vor der Aktivierung

eingefügt wurden

Transaktionmanagement

Eine Transaktion ...

... ist eine logische Arbeitseinheit, die insgesamt korrekt abgearbeitet oder abgebrochen

werden muß

zum Beispiel ein SELECT oder eine Reihe von UPDATE-Operationen

... erzeugt eine Reihe von DB-Requests die wiederum mit einer Reihe von I/O-Operationen

einhergehen

Beispiele sind

Mehrfache Datenmanipulationen in einer Tabelle

Bsp.: Rechnungsgenerierung und setzen des Status „abgerechnet“ bei allen betroffenen

Einzelposten

Datenmanipulationen über einen Join-View

Bsp.: Da INSERT nicht über Join-View möglich ist, müssen die Updates in den einzelnen Tabellen

einzeln erfolgen. Trotzdem hänge Sie zusammen z.B. INSERT in Verpflichtung und Rolle bei

Eintrag der Verpflichtung eines Schauspielers für eine Rolle

Datenmanipulation in mehreren Tabellen

Bsp.: Buchungen und Gegenbuchungen im Rechnungswesen

Massendaten-Updates

Bsp.: Alle Gehälter um 5 % erhöhen

Sicherstellung der Sicherstellung der

Ablaufintegrität Konsistenz bei Fehlerfällen

--> Mehrbenutzer-Synchronisation jeglicher Art

Ablaufintegrität

Konkurrierende Nutzung der Datenbanktabellen durch mehrere Nutzer,

Synchronisationsnotwendigkeit

Abzusichern vom DBMS sind folgende Probleme:

Lost Update

Änderungen konkurrierender Benutzer gehen verloren

Uncommited Data

Falsche Daten werden benutzt die nach dem Lesen vom konkurrierenden

Benutzer wieder zurückgesetzt wurden

Inconsistent Retrieval

Bezogen auf den Start einer Anfrage werden in Folge von Änderungen durch

konkurrierende Benutzer zeitlich verschiedene Stände von Records gelesen


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 38 von 47

Beispiel:

Lost Update

Beispiel:

Uncommitted Data

Beispiel:

Inconsistent Retrieval


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 39 von 47

Ablaufintegrität/Transaktionsmanagement

Lösung der Konkurrenzprobleme

durch geschickte Anwendungsprogrammierung (nur rudimentär möglich)

durch Datenbankmechanismen

durch Befehlskonstrukte zum Sperren durch die Anwendung

Sperrmechanismen können

auf Datenbankebene

auf Tabellenebene

auf Datenbank-Block-Ebene

auf Datensatzebene

eingesetzt werden.

Probleme:

Deadlock, Eskalation, unvollständige Transaktionen


Eigenschaften von Transaktionen

Atomarität

Transaktion ist kleinste nicht mehr zerlegbare Einheit (Alles oder Nichts wird festgeschrieben)

Konsitenz

Transaktion hinterläßt konsitente Datenbasis, bei Fehlern einzelner Aktionen wird

insgesamt zurückgesetzt, Zwischenzustände können inkonstitent sein, sind aber für

keinen Benutzer sichtbar

Isolation

Transaktionen dürfen sich nicht gegenseitig beeinflussen d.h. paralelle Transaktionen

dürfen nicht sichtbar sein

Dauerhaftigkeit

Nach Abschluß ist die Wirkung persitent, kann durch DBMS nicht rückgängig gemacht

werden

SQL-Befehle bei Oracle

COMMIT WORK

Transaktion erfolgreich beendet, alle Änderungen sind durch Schreiben in den REDO-LOG

permanent gemacht, alle von der Transaktion gesperrten Ressourcen werden freigegeben

ROLLBACK (TO SAVEPOINT )

Eine Transaktion wird erfolglos beendet, alle bereits geänderten Daten werden zurückgesetzt, alle

gesperrten Resourcen werden freigegeben

SAVEPOINT

(nicht Standard) kann in Ergänzung zum Rollback-Mechanismus genutzt werden, Roll-Back erfolgt

nur bis zum angegebenen SAVEPOINT

Beginn einer Transaktion durch neue Befehle bzw. Befehle nach COMMIT


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 40 von 47

Locking

LOCK TABLE IN MODE (NOWAIT)

ROW SHARE (RS)

ROW EXCLUSIVE (RX)

SHARE UPDATE (Synonym für ROW SHARE)

SHARE (S)

SHARE ROW EXCLUSIVE (SRX)

EXCLUSIVE (X)

!! nur benutzen wenn DBMS-Funktionalität nicht ausreicht; sparsamer Umgang mit eigenen LOCKs !!

EXCLUSIVE

Tabelle ist exklusiv gesperrt. Andere Prozesse können lesen

SHARE

Tabelle ist im Read-Only-Modus gesperrt, andere können ebenfalls im SHARE-Mode

sperren und lesen, jedoch kann kein anderer Prozeß Änderungsoperationen durchführen

ROW SHARE

Andere können lesen, auch RS- und RX-Locks absetzen aber nicht die ganze Tabelle

sperren. Bei der konkreten Update-Durchführung wird ROW SHARE zu ROW EXCLUSIV

ROW EXCLUSIV

wie ROW SHARE jedoch schützen auch vor SHARE-Locks

SHARE ROW EXCLUSIVE

andere können lesen und RS-Sperren aber weder die gesamte Tabelle noch einzelne

ROWS sperren und somit auch keine Updates durchführen

Sperrverträglichkeiten

Transaktions-Log-Datei

hält alle Datenmanipulationen fest mit before und after - image

garantiert Wiederherstellbarkeit

garantiert Synchronisationsmechanismen


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 41 von 47

Allgemeine Fehlerfälle:

Lokaler Fehler in einer offenen Transaktion

Fehler im Anwendungsprogramm, z.B. Integrität verletzt

expliziter Abbruch (Abort) durch Benutzer

systemgesteuerter Abbruch z.B. um Deadlock zu beheben

Fehler mit Hauptspeicherverlust

Stromausfall

Systemfehler

Fehler mit Hintergrundspeicherverlust

Headcrash

Feuer, Wasser, Erdbeben etc.

Fehler in Betriebssystem oder Systemprogrammen

Transaktionen und Fehler

Organisatorische Maßnahmen

Regelmäßige Datensicherung

Kopien getrennt halten, Saves, „Bergstollen“ etc.

Logging aller Transaktionen und Speichern des Log-Files

implizite DBMS-Funktionalität mit Wiederanlauf-Utilities

anwendungsimplementiertes Logging (problematisch!!)

Verteilung von Tabellen auf verschiedene Platten

hardware-technische Spiegelung von Platten

software-technische Spiegelung von Platten

gesamt

teilweise

Datensicherung

„Naives Kopieren“ der DBMS-Files

Problematisierung, Teilsicherungen

Backup-Utility um eine gesamte DB zu sichern

Runterfahren der DB

während dem Systembetrieb (unterbrechungsfrei)

RESTORE-Utility um gesamte DB zu laden

Sicherungsstrategie für LOG-File(s)


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 42 von 47

Datenschutz - Pflichten aus dem Gesetz

Umfangreiche Regelungswerke in BDSG und LDSG sowie

branchen-spezifische Vorschriften z.B. ärztl. Standesrecht,

Krankenhausgesetzgebung etc.

Sicherstellung durch Systemrealisierung von:

Zugangskontrolle

Abgangskontrolle

Speicherkontrolle

Benutzerkontrolle

Zugriffskontrolle

Übermittlungskontrolle

Eingabekontrolle

Auftragskontrolle

(Transportkontrolle)

(Organisationskontrolle)

Schutzmaßnahmen im Überblick

Überprüfbare Zugriffskontrolle

Verschlüsselte Datenspeicherung

elektronische Unterschrift / digitale Signatur

verschlüsselte Datenübermittlung

Firewall und andere Netzsicherheitstechniken

zentrale Zertifikationsinstanz

Chipkarten als persönlicher Ausweis und Schlüsselspeicher

organisatorische Verpflichtungen

Datenschutz - Aspekte für DBMS-Mechanismen

Zugangsbezogene Aspekte

Datenstrukturbezogene Aspekte

Datenausprägungsbezogene Aspekte

Resourcenbezogene Aspekte

Speicherungs- und Übertragungsbezogene Aspekte

Anwendung

SQL

Datenbank

Betriebssystem

Pre-Compiler-

Programm


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 43 von 47

Datenschutz: Rechte in ORACLE

Systemberechtigungen

Recht, eine bestimmte Aktion mit oder innerhalb der Datenbank

auszuführen oder auf einem bestimmten Objekttyp

auszuführen, ca. 80 einzelne Berechtigungen

Objektberechtigungen

Recht, bestimmte Aktionen auf bzw. mit bestimmten Objekten

(also Tabelle, Trigger etc.) auszuführen

Unterscheidung zwischen

User = Person die DB benutzt und Rechte haben kann

Rollen = Zusammenstellung bestimmter Rechte

Profilen = Systemressourcenbezogene Limits für User

Rollen können Usern oder anderen Rollen zugewiesen werden

Anlegen von Benutzern

Erteilen von Systemberechtigungen

Erteilen von Objektberechtigungen


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 44 von 47

Oracle-Systemberechtigungen (Überblick)

Oracle-Objektberechtigungen


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 45 von 47

Objektberechtigungen und Objekte

Berechtigungsprofile in Form von Rollen

Reduzierter Verwaltungsaufwand

Dynamische Verwaltung von Berechtigungen

Selektive Verfügbarkeit von Berechtigungsprofilen

Berechtigungsbewußte Anwendungen

Anwendungsspezifische Sicherheit

Rolle kann Rechte von anderer Rolle bekommen

Mehrere Rollen können je Benutzer aktiv sein

Vorgehensschritte für ein benutzerbezogenes Datenschutz-Konzept mittels DBMS

1. Feststellen aller in Frage kommenden Benutzer

2. Bildung von sinnvollen Benutzergruppen

3. Ggf. Festlegung von “herausragenden” Benutzern in den Gruppen (z.B. Gruppenadministrator)

4. Datenstrukturbezogene Aspekte und Zugriffsrechte definieren (ggf. spezielle views bilden),

Definition der Rollen

5. Datenausprägungsbezogene Aspekte definieren (ggf. views bilden)

6. Allgemeine Resourcengrenzen definieren

7. Spezielle Ressourcengrenzen ggf. ermitteln und definieren

8. Implementierung der zeit- und ggf. hardwarebezogenen Aspekte

--> siehe auch Tafelbeispiel sowie Fallstudie


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 46 von 47

Operationen mit Rollen


LV Programmierung 3.doc Version 07.11.00 22:40 Seite 47 von 47

Ressourcenbezogene Beschränkungen: Profile

CREATE PROFILE testprofil LIMIT

SESSIONS_PER_USER 2

CPU_PER_SESSION unlimited

CPU_PER_CALL 6000

LOGICAL_READS_PER_SESSION unlimited

LOGICAL_READS_PER_CALL 100

IDLE_TIME 30

CONNECT_TIME 480

PRIVATE_SGA_PER_SESSION unlimited;

-> Zuweisung durch die Angabe des Profils beim CREATE USER - Befehl

Datenbankadministrator - Aufgaben

Planung und Durchführung der (Erst-)Installation des DBMS

Planen/Einrichten der einzelnen Datenbanken

Hoch- / Runterfahren des DBMS und Mounten der DBs

Verwalten der Datenbank-Prozesse inkl. der Systemeinstellungen

Planung und Realisierung eines Sicherheitskonzeptes

Planung und Realisierung der Datenschutzstrategie

Verwalten des Datenbankspeichers

Überwachung der DBMS-Aktivitäten – Auditing

Tuning und Effizienzverbesserungen

Datenbankwiederherstellung im Fehlerfall

Planung und Realisierung einer Verteilungsstrategie, Skalierung

Beratung von Programmierern und Benutzern

Einspielen neuer Versionen, Migration

Erstellung des (logischen und) physischen Designs

Kontakte und Verhandlungen mit Herstellern

LV Programmierung 3, Prof. Haas, WS 2000/2001, Stand 14.10.2000

Literatur

Atkins et.al.: Oracle Designer Generation, Osborne/McGraw-Hill - Oracle Press, 1999

Codd E.F.: Extending the Database relational Model to Capture More Meaning, ACM

Transactions on Database Systems, Vol. 4, Dec. 1979

Balzert H.: Methoden der objektorientierten Systemanalyse, BI Wissenschaftsverlag 1995

Froese, Jürgen et.al.: Effiziente Systementwicklung mit ORACLE 7, Addison-Wesley1994

Kemper A., Eickler A.: Datenbanksysteme - Eine Einführung, Oldenbourg Verlag 1996

Martin J., Odell J.: Object Oriented Methods A Foundation, Prentice Hall Inc. New Jersey,

ISBN 0-13-630856-2

Oracle - Handbücher: SQL Language Reference Manual, SQL Quick Reference, DBA-Handbuch

Ortner E., Söllner B.: Semantische Datenmodellierung nach der Objekttypenmethode; in:

Informatik Spektrum (1989) 12:31-42

Urmann: Oracle PL/SQL-Programmierung, Hanser Verlag 2000

Rob P. Coronel C.: Database Systems - Design, Implementation and Management, Wadsworth

Publishing Company, Belmont California (u.a. ausführliche Darstellung ERM und Ableitung

Relationen mit Beispielen)

Roeing, Frank: ORACLE 7 Datenbanken erfolgreich realisieren, Vieweg 1996

Scheer A.-W.: Wirtschaftsinformatik, Referenzmodelle für industrielle Geschäftsprozesse, 5.

Auflage, Springer Verlag 1995

Stein W.: Objektorientierte Analysemethoden - Vergleich, Bewertung, Auswahl, Spektrum Verlag

1995

Stürner Günther: ORACLE 7, dbms-Publishing 1993

Vetter M.: Strategie der Anwendungssoftware-Entwicklung, Teubner 1988

Vossen, Gottfried: Datenmodelle, Datenbanksprachen und Datenbank-Management- Systeme,

Addison-Wesley 1994

Weitere Magazine dieses Users
Ähnliche Magazine