2.1 Datenbanken / Einführung 2.1 Datenbanken

2.1 Datenbanken / Einführung
2.1.1 Literatur:
●
2.1 Datenbanken / Einführung
WS 05/06
WS 05/06
2.1.2 Begriffe:
[8] Peter Kleinschmidt, Christian Rank: Relationale
Datenbanksysteme, Eine praktische Einführung,
Springer Verlag, Berlin, 1997
–
Datenbank (der gesamte Datenbestand der zu verwalten ist)
–
Datenbanksystem (genauer: Datenbankverwaltungssystem)
(besteht aus:)
●
●
●
–
Englisch: DBMS (Database Management System)
Datensammlung (Datenbasis, Datenbank)
Sammlung von Programmen zur Erzeugung und Verwaltung der
Daten
Plattform (Art/Typ des Computersystems)
●
PC, Workstation, Mainframe, ...
CSA 83
2.1 Datenbanken / Einführung
CSA 84
2.1 Datenbanken / Einführung
WS 05/06
2.1.3 Software-technische Vorteile, Beispiel:
WS 05/06
2.1.4 Software-technische Vorteile, Übersicht:
[8], S. 2, Fig. 1
Ein Versicherungunternehmen bietet Haftpflicht- und Rechtsschutzversicherungen. Die Realisierung erfolgt durch verschiedene
Anwendungen, die jeweils für sich entwickelt wurden. Damit ergibt
sich eine Datenhaltung in verschiedenen (physischen) Dateien auf
den Massenspeichern (Festplatten) des Computersystems .
Daher der geben sich Probleme:
Inkonsistenzen für Kunden mit Haftpflicht und Rechtschutz
(z.B. erhalten sie Doppelwerbung durch Marketing,
Adresskorrekturen werden versehentlich nur in einem System
ausgeführt oder die Namensschreibweisen in beiden Systemen
weichen geringfügig voneinander ab, ...
)
–
Paraleller / konkurrenter Zugriff auf Daten
–
Konsistenz der Daten (keine "halb fertigen" Änderungen)
–
Transaktion (ohne DBMS: hoher Programmieraufwand für
exklusiven Zugriff )
–
Redundanzen (doppelte Datenhaltung) vermeiden
–
Kapselung der Daten (kein direkter physischer Zugriff,
Zugriff nur durch das DBMS)
–
Meta-Daten (Informationen über die Struktur der Daten)
–
klarere Trennung Programmier- / Datenebene
●
[8], S.3, Fig. 2
Verbesserung durch die Verwendung eines DBMS.
CSA 85S
Datenabstraktion (kein Konzept erforderlich, wie und wo Daten
abgelegt/gespeichert werden)
CSA 86
2.1 Datenbanken / Einführung
2.2 Datenbanken / DBMS Anforderungen
WS 05/06
WS 05/06
2.2.1 Grundlegende Forderungen:
2.1.5 Vereinfachtes Software Modell einer Datenbank Anwendung:
[8], S.4, Fig. 3
–
–
jeder Zugriff auf die eigentlichen (physischen) Daten erfolgt
durch das DBMS
Daten müssen manipulierbar (veränderbar) sein
–
Redundanzfreiheit (evtl. kontrollierbare Redundanz)
–
Universelle Verwendbarkeit (Einsatz für verschiedene
Anwendungsbereiche)
–
Unabhängigkeit vom Programm (Von Programm A erzeugte Daten
DBMS Software:
●
●
–
–
Software zum Ausführen von Programmen / Abfragen
Software zum Zugriff auf die physischen Daten
müssen durch Programm B lesbar sein)
DBMS Daten
●
●
–
Daten, die die Struktur der gespeicherten Daten (Tabellen)
beschreiben (Metadaten)
Datenbereich, der den Dateninhalt der gespeicherten Daten enthält.
Das ist die eigentliche Datenbank)
Konfigurationsunabhängigkeit des DBMS von Hardware,
Software, Netz
CSA 87S
2.2 Datenbanken / DBMS Anforderungen
CSA 88
2.2 Datenbanken / DBMS Anforderungen
WS 05/06
2.2.2 Zusätzliche (Unterscheidungs-) Merkmale für DBMS:
2.2.1 Grundlegende Forderungen:
–
WS 05/06
●
Funktionale Integration: transparente und nutzbare
Darstellung semantischer Datenzusammenhänge
Einfluss auf die Kaufentscheidung haben (u.a.):
–
Nationalsprachenunterstüzung
–
Strukturflexibilität: Struktur muß veränderbar sein (z.B. PLZ
Umstellung, Euro-Umstellung )
–
Verfügbarkeit für verschiedene Plattformen
Mehrbenutzerbetrieb (gleichzeitiger Zugriff,
Berechtigungen, Authentifizierung z.B. durch Passwörter)
–
–
sparsame Ressourcenausnutzung (Rechenzeit, Plattenplatz)
–
Ergänzungstools:
–
Datenintegrität (Daten vollständig, semantisch korrekt)
–
●
●
Datensicherheit: Backup, Datenrekonstruktion (Rollforward,
Transaktions-Log)
CSA 89
●
Berichtserstellung (Reportgenerator)
Unterstützung für die Erstellung graphischer Oberflächen (4GL)
Tools zur Anwendungsentwicklung, Administration, Entwurf
CSA 90
2.3 Datenbanken / Formale Modelle
2.3.1 Relationenmodell
–
–
–
2.3 Datenbanken / Formale Modelle
WS 05/06
WS 05/06
2.3.2 Relationenmodell, Beispiele:
Seien M1, ..., Mn beliebige Mengen (z.B. ganze Zahlen,
reelle Zahlen, Zeichenketten, Datumsangaben)
kartesisches Produkt: die Menge M1 × ... × Mn besteht
aus (n-) Tupeln: (m1, ..., mn), wobei mi ∈ Mi, 1 ≤ i ≤ n.
Relation R: Teilmenge des kartesischen Produktes
R ⊆ M1 × ... × Mn
–
M1 Menge aller Zeichenketten (Strings)
–
M2 = M3 = M4 Menge ganzer Zahlen
–
Relation Mitarbeiter MTAR ⊆ M1 × M2 × M3 × M4
–
Bedeutung der Attribute
●
●
–
Die Indices 1, ..., n heißen die Attribute der Relation und
–
die Menge A = {1, ... n} ist die Attributmenge.
–
mi heißt Attributwert zum Attribut i.
●
●
Attribut (Index) 1
Attribut (Index) 2
Attribut (Index) 3
Attribut (Index) 4
Name
Telefonnummer
Zimmernummer
Personalnummer
CSA 92
CSA 91
2.3 Datenbanken / Formale Modelle
WS 05/06
2.3.3 Namen für Attribute :
–
2.3.4 Tabellendarstellung einer Relation:
hier im Beispiel der vorhergehenden Folie wird aus der
Attributmenge
A = {1,2,3,4}
Attributnamen (Spaltennamen)
die Menge mit den Namen (oder Bezeichnungen) für die Attribute:
A' = { Name, Telefonnummer, Zimmernummer, Personalnummer }.
–
WS 05/06
benannte Attribute zur Verbesserung der Übersicht
●
–
2.3 Datenbanken / Formale Modelle
Relation mit benannten Attributen, Schreibweise:
MTAR(NAME, TELNR, ZINR, PNR)
Bezeichnung für eine Relation mit benannten Attributen:
Relationenschema
Zeilen: [Daten-]Satz
1
NAME
2
3
TELNR ZINR
4
PNR
Schultz
4711
016 803209
Meyer
1147
216 803210
Schmidt
1234
217 803212
Förger
2777
217 803213
Schröder
4321
219 803214
Stoiber
5678
219 803217
Attributwert (Feld eines Datensatzes)
CSA 93
CSA 94
2.3 Datenbanken / Formale Modelle
2.3.5 Funktionale Abhängigkeit zweier Relationenschemata
–
Gegeben sei ein Raltionenschema R(A1, ..., An) mit der
Attributmenge A = {A1, ..., An}.
–
Seien die Attributmengen X,Y Teilmengen der
Attributmenge A der Relation R
X = {X1, ..., Xk} ⊆ A und Y = {Y1, ..., Yj}⊆ A
–
2.3 Datenbanken / Formale Modelle
WS 05/06
WS 05/06
2.3.5 Funktionale Abhängigkeit (Fortsetzung)
–
Definition: Y heißt genau dann voll funktional abhängig
von X, wenn für jede echte Teilmenge Z ⊂ X keine
funktionale Abhängigkeit vorhanden ist.
Schreibweise: X ↳ Y
( und nicht '' )
Definition: Y heißt genau dann funktional abhängig von
X, wenn für zwei Tupel P, Q aus der Relation R, d.h.
P  R und Q  R, P=(pA1, ..., pAn), Q=(qA1, ..., qAn), gilt:
aus pX1 = qX1, ..., pXk = qXk folgt pY1 = qY1, ..., pYj = qYj
Schreibweise: X  Y
CSA 95
2.3 Datenbanken / Formale Modelle
2
NAME
3
TELNR ZINR
4
PNR
Schultz
4711
016 803209
Meyer
1147
216 803210
Schmidt
2777
217 803212
Förger
2777
217 803213
Schröder
4321
219 803214
Stoiber
4321
219 803217
●
WS 05/06
2.3.7 Schlüssel
Beispiel: funktionale Abhängigkeit
{PNR, ZINR}
 {TELNR}
{ZINR}
 {TELNR}
{ZINR}
↳ {TELNR}
–
Es sei die Attributteilmenge X der Attributmenge A der Relation R
mit X = {X1, ..., Xk} ⊆ A gegeben
–
Definition: X heißt Superschlüssel für R, wenn gilt
XA
(funktional abhängig) (d.h. hier gilt: Y=A)
–
Definition: X heißt Schlüssel für R, wenn gilt
X ↳ A (voll funktional abhängig)
Funktionale Abhängigkeiten werden in der Regel nicht durch
eine Analyse der vorhandenen Daten sondern durch die
beabsichtigte Interpretation der Attribute festgelegt.
–
2.3 Datenbanken / Formale Modelle
WS 05/06
2.3.6 Funktionale Abhängigkeit Beispiel
1
CSA 96
Im obigem Beispiel ist aufgrund einer innerbetrieblichen
Organisationsentscheidung festgelegt worden, dass jedes Büro
nur ein Telefon erhält.
CSA 97
–
Jeder Schlüssel ist also auch gleichzeitig Superschlüssel
–
Ein Schlüssel ist also ein minimaler Superschlüssel, dh. kein Attribut
kann aus dem Schlüssel entfernt werden, ohne daß die
Schlüsseleigenschaft verloren geht.
–
Ein Primärschlüssel ist beim Datenbank-Entwurf ausgezeichneter
Schlüssel, z.B. der, der am effizientesten eingesetzt werden kann,
vielleicht mit den wenigsten Attributen (Konvention: Unterstreichen in
Tabellen)
CSA 98
2.3 Datenbanken / Formale Modelle
2.3 Datenbanken / Formale Modelle
WS 05/06
2.3.8 Entity Relationship Model, Beispiel
2.3.9 Entity Relationship Model
[8], S. 11, Fig. 7
Beispiel für Entities und ihre Beziehungen zu einander:
Entity: Personal
Attribute: Pid, Nachname, Vorname, Straße, Ort, Einstellungsdatum,
Gehalt
Entity: Abteilung
Attribute: Aid, Bezeichnung, Ort
Entity:Projekt
Attribute: Projid, Name
Relationen:
"arbeitet in" (n:1):
Personal ↔ Abteilung
"ist Vorgesetzter von" (n:1): Personal ↔ Personal (Vorgesetzter)
"ist zugelteil" (n:m):
Personal ↔ Projekt
–
Entity
●
●
–
●
–
Assoziation (in Beziehung setzten) zweier (mehrerer) Entities nach
bestimmten Gesichtspunkten
Relationship-Typ
●
–
Kollektion von Entities mit gleichen Merkmalen (Objekttyp)
Relationship (Beziehung)
●
–
existierendes Objekt
von anderen Objekten unterscheidbar
Entitytyp
Ojekttyp von Relationship
Komplexität des Relationship-Typs
●
wird über eine Klasseneinteilung festgelegt (nächste Folie)
CSA 99S
2.3 Datenbanken / Formale Modelle
WS 05/06
2.3.9 Entity Relationship Model (Fortsetzung)
–
●
Es seien E1, E2 Entitytypen und R ⊆ E1 × E2 ein Realtionshiptyp
●
Klasseneinteilung
–
–
–
CSA 100
2.3 Datenbanken / Formale Modelle
WS 05/06
2.3.10 Entity Relationship Model, Beispieldaten
Komplexität des Relationship-Typs
–
WS 05/06
[8], S. 12, Fig. 8
Konkretes Beispiel für das auf Folie 197 dargestellte ER-Diagramm
durch Tabellen mit konkreten Attributwerten. vgl. Übungsaufgabe
1:1-Beziehung: Jeder Entity in E1 wird durch R eine Entity in E2 zugeordnet
und umgekehrt (Beispiel für R: "Ist verheiratet mit")
1:n-Beziehung: Jeder Entity in E2 wird durch R eine Entity in E1 zugeordnet
(keine Beschränkung in der anderen Richtung) (z.B. E1=Klasse, E2=Kinder)
n:1 Beziehung: Jeder Entity in E1 wird durch R eine Entity in E2 zugeordnet
(keine Beschränkung in der anderen Richtung)
m:n Beziehung: Beliebige Zuordnung von Entities in E1 zu Entities in E2
möglich (z.B. E1= Studenten, E2= Vorlesungen)
[8], S. 10, Fig. 6
graphische Darstellung in Entity-Relationship-Diagrammen
CSA 101S
CSA 102S
2.3 Datenbanken / Formale Modelle
2.3.11 Entity Relationship Model / Relationen
●
–
Aus dem Beispiel ergeben sich für die Entities die
Relationenschemata
● PERSONAL (Pid, Nachname, Vorname, Straße, Ort,
Einstellung, Gehalt)
● ABTEILUNG (Aid, Bezeichnung, Ort)
● PROJEKT (Projid, Name)
Relationen für die Relationship-Typen im Beispiel:
● ist_vorgesetzter_von (vorges_id, pid)
● arbeitet_in (pid, aid)
● ist_zugeteilt(pid, projid)
–
–
–
–
Auswahl: Select („alle vom Personal, die in Abteilung 5 [Außendienst] sind“)
Projektion: Auswahl bestimmter Spalten (Ort, Aid aus Personal)
Vereinigung: Zusammenfassung zweier Relationen zu
einer („alle Orte, die Wohnorte von Mitarbeitern oder Abteilungsstandorte sind“)
Durchschnitt: Im Ergebnis sind nur Elemente enthalten,
die in beiden Relationen vorhanden sind (Attribute paarweise aus
der selben Grundmenge) ( „Orte aus Abteilung, die auch Wohnorte von Mitarbeitern sind“)
–
Differenz: Nur Datensätze, die in der zweiten Menge
nicht vorhanden sind, bleiben in der ersten erhalten
(Attribute paarweise aus der selben Grundmenge) („Orte aus Abteilung, die nicht Wohnorte
von Mitarbeitern sind“)
–
Kartesisches Produkt
(vgl. Einleitung: Ergebnisrelation enthält jedes Element
der einen Relation mit kombiniert mit jedem Element der der anderen Relation)
CSA 103
2.3 Datenbanken / Formale Modelle
WS 05/06
2.3.11 Operationen für Relationen (Fortsetzung)
–
CSA 104
2.3 Datenbanken / Formale Modelle
●
Ergebnisrelation:
[8], S. 15, Fig. 10
Ergebnistabelle des Equi-Joins
Beispiel: Tabelle Personal mit Tabelle Abteilung:
–
WS 05/06
2.3.11 Operationen für Relationen (Fortsetzung)
Join: Zusammenfassung von Relationen anhand von
Beziehungen vergleichbarer Attribute von jeweils zwei
Relationen
●
WS 05/06
2.3.11 Operationen für Relationen
Zusammenhang: Entity-Relationship-Modell /Relationen
–
2.3 Datenbanken / Formale Modelle
WS 05/06
Attribute Aid müssen übereinstimmen
[8], S. 16, Fig. 9
graphische Darstellung der Konstruktion eines (Equi-) Joins
●
●
●
Diese Art der Verknüpfung wird als Equi-Join bezeichnet
Entfernen doppelter Attribute: Natural Join
Verbindung einer Relation mit sich selbst: Self-Join
–
Beispiel Tabelle Personal, Ergebnis: Nachname Mitarbeiter, Nachname
Vorgesetzter
● Regel: Null Werte niemals gleich
CSA 106S
CSA 105S
2.3 Datenbanken / Formale Modelle
2.3.11 Operationen für Relationen (Fortsetzung)
●
2.3 Datenbanken / Formale Modelle
WS 05/06
2.3.12 Zusatzforderungen für relationale DBMS
Aggregationsoperationen
–
(werden dazu genutzt, um aus einer Gruppe
(Menge) von Datensätzen (Tupeln) aus den Werten vorgegebener Attribute die folgenden Werte
–
zu ermitteln
●
●
●
●
●
WS 05/06
Informationsregel (Informationen nur einheitlich als Attribut gespeichert)
Zugriffsgarantie (erforderliche Zugriffsinformation: Tabellenname, Spaltenname,
Primärschlüssel)
COUNT Zählen von Datensätzen
SUM Summieren von Werten (nur für numerische
Attributwerte)
MINIMUM auch für Zeichenketten (Strings) -> lexikalisch
kleinstes Element
MAXIMUM ebenfalls für Zeichenketten,
AVG (average) Mittelwert
–
Nicht bekannte Information werden einheitlich als NULL gespeichert
–
Datenbankkatalog (auch Beschreibungsinformationen (Metadaten) in Tabellenform,
d.h. die Informationen über Tabellen (Relationen), Attribute und deren Typen werden
ebenfalls als Tabellen (Relationen) gespeichert)
–
Mengenorientierung (Unterdrückung doppelter Sätze)
–
Integritätsunabhängigkeit (Formulierung der Integritätsregeln in
Datenbanksprache (SQL), Speicherung im Datenbankkatalog, z.B. in der Projetzuordnung nur
Personalnummern zulassen, zu denen es auch einen Mitarbeiter in der Personaltabelle gibt.)
CSA 107
2.3 Datenbanken / Formale Modelle
DDL
–
–
–
●
–
–
–
–
–
●
Data Definition Language, Beispiele:
CREATE TABLE ... Tabelle anlegen
ALTER ... Struktur einer Tabelle ändern: z.B. Attribute hinzufügen, löschen,
Typ ändern (beispielsweise bei Zeichenketten die Länge verändern)
DROP TABLE ... Tabelle löschen
●
Wesentlicher Schritt beim Entwurf (engl. Design):
Festlegung der Tabellen-Struktur
–
Frage bei mehreren Alternativen:
Was ist eine gute Form für ein Relationenschema?
–
Kriterien:
DML Data Manipulation Language, Beispiele:
–
SELECT Datensätze auswählen
UPDATE
Attributwerte ändern
INSERT
Neue Datensätze einfügen
DELETE
Datensätze löschen
GRANT
Benutzern Berechtigungen für den Datenzugriff erteilen
REVOKE
Benutzern Berechtigungen entziehen
DCL
–
–
WS 05/06
2.4.1 Entwurfsaufgabenstellung
Datenbanksprache (SQL Structured Query Language)
●
2.4 Datenbanken / Entwurf
WS 05/06
2.3.12 Zusatzforderungen für relationale DBMS
–
CSA 108
●
●
Logische Ebene: Wie leicht fällt die Interpretation
Physikalische Ebene: Wie effizient sind Abrufen, Speichern,
Ändern
Data Control Language, Beispiele:
COMMIT
ROLLBACK
Eine Folge von Änderungen auf einmal anwenden
Eine Folge von Änderungen wieder verwerfen
CSA 109
CSA 110
2.4 Datenbanken / Entwurf
2.4.2 Entwurfsbedingte Anomalien
●
2.4 Datenbanken / Entwurf
WS 05/06
2.4.2 Entwurfsbedingte Anomalien (Fortsetzung)
Beispiel, Relationenschema:
–
Folgerung: Für jeden Kunden nur ein Datensatz (Kunde
ist Schlüssel)
–
Änderungsanomalie
Bestellungen (Kunde, Ort, Vertreter, Menge)
–
Kunde Name des Kunden (eindeutig, Primärschlüssel)
–
Ort Unternehmenssitz des Kunden
–
Vertreter Für den Kunden zuständiger Vertreter,
●
abhängig vom Unternehmenssitz
–
●
Menge Menge des bestellten Artikels der Firma
–
KUNDE
ORT
VERTRETER MENGE
Auer
Passau
1
9
Blank Regensburg
2
20
Christ München
3
3
Dom
Passau
1
5
2.4 Datenbanken / Entwurf
●
–
●
–
CSA 112
2.4 Datenbanken / Entwurf
WS 05/06
Wird ein Kunde gelöscht (z.B. keine Bestellung) =>
Information über den Ort geht verloren
Lösung: Beispiel, Relationenschema:
BestellM (Kunde, Menge)
STANDORT (Kunde, Ort)
Ein neuer Datensatz kann nur eingefügt werden, wenn alle 4
Attribute bekannt sind (das ist eine Forderung des
theoretisches Relationenmodell)
Abschwächung dieser Forderung bei Datenbanken: Alle
Schlüssel müssen bekannt sein
–
Ausgangspunkt: Funktionale Abhänigkeiten
–
Idee: aus funktionalen Abhängigkeiten weitere ableiten
Seien X, Y, Z Teilmengen der Attributmenge eines
Realtionenschemas, dann gelten die folgenden Regeln
(Armstrongs Inferenzregeln):
–
Anomalien reduzieren:
●
WS 05/06
2.4.3 Minimale Abhängigkeitssysteme
Einfügeanomalie:
●
Wird ein Kunde gelöscht (z.B. keine Bestellung) =>
Information über den Ort geht verloren (siehe nächste Folie)
CSA 111
Löschanomalie:
●
Ändert sich der Vertreter (z.B. Passau) => mehrere Sätze
ändern
Lösung: Beispiel, Relationenschema:
Bestell1 (Kunde, Ort, Menge)
ZUST (Ort, Vertreter)
Löschanomalie:
●
2.4.2 Entwurfsbedingte Anomalien (Fortsetzung)
–
WS 05/06
●
Aus Y ⊆ X folgt: X  Y (Reflexivität).
●
Gilt X  Y, so gilt auch X ∪ Z  Y (Argumentierung)
●
Gilt X  Y und Y  Z, so gilt auch X  Z (Transitivität)
Mit diesen Regeln lassen sich aus einem System von
funktionalen Abhängigkeiten alle weiteren Abhängigkeiten
ableiten
Lösung: Normalformen von Relationen
CSA 113
CSA 114
2.4 Datenbanken / Entwurf
2.4.3 Minimale Abhängigkeitssysteme (Fortsetzung)
–
–
–
(1) Für jede Abhängigkeit X  Y gilt, dass Y aus genau einem
Attribut besteht
(2) F enthält keine redundanten Abhängigkeiten, dh. es gibt in F
keine Abhängigkeit, die sich durch Anwendung der Inferenzregeln
ableiten läßt.
(3) Eine Abhängigkeit von X  A in F kann nicht durch durch Y 
A ersetzt werden mit Y ⊆ X und X ≠ Y
F+ heißt Abschluss von F.
Die beiden Systeme ergeben die gleichen Abhängikeiten, wenn
gilt: F+ =G+ .
–
●
In diesem Fall werden F und G als äquivalent bezeichnet
2.4 Datenbanken / Entwurf
–
Forderung 1: Daraus entstehen viele kleine Abhängigkeiten
mit X  Ak1, ..., X  Akn, Zusammenfassung in der
CSA 116
Schreibweise (kompakter, Abkürzung)
X  Ak1 ∪ ... ∪ Akn,
–
Herleitung in der Praxis: Durch Analyse der vorgesehen
Bedeutung der Attribute (Beispiel: Zimmernr. / Telefonnr.)
Umwandlung
zur 1. Normalform
Schlüssel
identifizieren:
WS 05/06
2.4.4 Zweite Normalform
alle Attribute haben atomare Werte
Beispiel nicht in
1. Normalform:
2.4 Datenbanken / Entwurf
WS 05/06
2.4.4 Erste Normalform
–
–
Frage: welches System von funktionalen Abhängigkeiten enthält
keine „überflüssigen“ Informationen und ist somit minimal?
CSA 115
–
Minimale Abhängigkeit, Bedingungen:
Vergleich zweier Systeme F und G von funktionalen
Abhängigkeiten:
●
WS 05/06
2.4.3 Minimale Abhängigkeitssysteme (Fortsetzung)
Für ein System F wird das (vollständige) System aller
funktionaler Abhängigkeiten mit F+ bezeichnet, das sich
durch Anwendung der Inferenzregeln ergibt.
●
2.4 Datenbanken / Entwurf
WS 05/06
[8], S. 74, Fig. 37
Relation mit nicht atomaren Attributen,
Das Attribut Hobbies besteht aus einer Liste,
deren Elemente immer die zwei Werte (Name des
Hobbies und Priorität) enthalten
[8], S. 75, Fig. 38
Überführung der Relation in zwei Relationen
zusätzliche Relation Hobbies hat Attribute
Nr. (für die Person), Hobbie-Name, Priorität
CSA 117S
–
jedes Attribut, das nicht Bestandteil eines Schlüssels (nicht
Superschlüssel) ist, ist voll funktional abhängig von jedem
Schlüssel
–
Folgerung: Sind alle Schlüssel einelementig, so liegt bereits
die zweite Normalform vor
–
Beispiel (Kino):
KINO (PLCODE, SAAL, PLATZ, REIHE, PREIS, GRÖSSE)
●
PLCODE eindeutige Platznummer im ganzen Kino
●
SAAL Nummer des Spielsaals
●
PLATZ Nummer des Platzes im Spielsaal
●
REIHE Reihe des Platzes im Spielsaal
●
PREIS Eintrittspreis für den Platz
●
GRÖSSE Größe des Spielsaals
CSA 118
2.4 Datenbanken / Entwurf
2.4.4 Zweite Normalform
(Fortsetzung)
–
–
a1: {PLCODE} ↳
–
a2: {SAAL, PLATZ} ↳ {PLCODE, SAAL, PLATZ, REIHE,
PREIS, GRÖSSE}
–
a3: {SAAL} ↳ {GRÖSSE}
–
a4: {REIHE} ↳ {PREIS}
–
Verletzung der Regel: GRÖSSE ist vom einer echten
Teilmenge {SAAL} des Schlüssels {SAAL, PLATZ} funktional
CSA 119S
abhängig
[8], S. 77, Fig. 40
Grafische Darstellung der Transformation in die 2. Normalform
–
erste Normalform liegt vor und
–
für jede funktionale Abhängigkeit X  {Ak} gilt:
CSA 120S
2.4 Datenbanken / Entwurf
WS 05/06
2.4.5 Dritte Normalform
WS 05/06
2.4.5 Dritte Normalform (Fortsetzung)
–
X ist Superschlüssel der Relation R oder
Ak ist Bestandteil eines anderen Schlüssels
Normalisierung, dritte Normalform:
[8], S. 77, Fig. 40, wie Folie 199
Grafische Darstellung der Transformation in die 2. Normalform
–
Alternative Formulierung: Analysiere alle Attribute Ak, die
nicht Bestandteil eines Schlüssels sind, falls gilt:
X ↳ {Ak} muss X Schlüssel sein => 3.Normalform liegt vor.
–
Hinweis: ein Relationenschema in dritter Normalform liegt
automatisch auch in zweiter Normalform vor.
–
Normalisierung:
{PLCODE, SAAL, PLATZ, REIHE, PREIS,
GRÖSSE}
2.4 Datenbanken / Entwurf
●
WS 05/06
2.4.4 Zweite Normalform (Fortsetzung)
[8], S. 76, Fig. 39
Grafische Darstellung der unten genannten (funktionalen) Abhängigkeiten
●
2.4 Datenbanken / Entwurf
WS 05/06
Relationen mit nur einem Nichtschlüssel-Attribut sind
automatisch in dritter Normalform
CSA 121
–
nicht in Dritter Normalform:
●
{REIHE} ↳ {PREIS} Weder ist Reihe Superschlüssel noch ist
Preis Bestandteil irgend eines anderen Schlüssels.
CSA 122S
2.4 Datenbanken / Entwurf
2.4 Datenbanken / Entwurf
WS 05/06
2.4.5 Dritte Normalform (Fortsetzung)
–
2.4.6 Andere Normalform
Normalisierung, dritte Normalform, Ergebnis:
[8], S. 78, Fig. 41
Grafische Darstellung der Transformation in die 3. Normalform
–
Für die Praxis von untergeordneter Relevanz
–
vierte Normalform
–
Boyce-Codd-Normalform (BCNF)
–
Domain-Key-Normalform (DKNF)
CSA 123S
2.4 Datenbanken / Entwurf
CSA 124
2.4 Datenbanken / Entwurf
WS 05/06
2.4.6 Bewertung der Normalisierung
●
●
WS 05/06
WS 05/06
2.4.6 Datenbankindex
Normalisierung, Vorteile:
–
Verminderung der Redundanz
–
Weniger Anomalien
–
Mehr Konsistenz
–
Speicherplatzersparnis
[8], S. 90, Fig. 50
Grafische Darstellung der Struktur eines Indexes
Normalisierung, Nachteile:
–
–
●
Unübersichtlichere und schwieriger zu handhabende
Datenbanken
Höhere Antwortzeiten durch Verknüpfung mehrerer
Tabellen
CSA 125
Index (B-Baum)
–
auf eine oder mehrere Spalten
–
mehrere Indices pro Tabelle sind möglich
–
automatisch vom DBMS verwaltet
–
Verbesserung für WHERE, ODER BY
CSA 126S
2.4 Datenbanken / Entwurf
2.4.7 Weitere Aspekte bei Datenbanken
–
Transaktionen (SQL: COMMIT, ROLLBACK)
–
Sperren von Tabellen (SQL: LOCK TABLE ... )
–
Berechtigungen (SQL: GRANT ... , REVOKE ...)
–
VIEWS (SQL: CREATE VIEW ... )
Pseudo-Tabellen deren Daten durch eine SQL
SELECT-Bedingung festgelegt werden
–
2.4 Datenbanken / Entwurf
WS 05/06
2.4.7 Weitere Aspekte bei Datenbanken (Fortsetzung)
–
●
●
●
●
Web basiert (Plattform unabhängig)
–
–
●
●
Server basiert: Java, PHP, Perl, ...
auf dem Client: HTML/Javascript
Client basiert: Java-Applets, JDBC (Java Database Connectivity)
auf dem Server: Datenbank mit JDBC
Proprietäre Lösung versch. Hersteller
3.1 Verschlüsselung / Einführung
–
kein Ersatz für Computersicherheit
–
Warum Verschlüsselung?
●
●
●
●
●
–
PRIMARY KEY
FOREIGN KEY
ein oder mehrere Attribute bilden einen Primärschlüssel
ein oder mehrere Attribute beziehen sich auf einen
Primärschlüssel in einer anderen Datenbanktabelle, d.h. hier stellt das DBMS sicher,
das nur Datensätze mit Werten in die Tabelle aufgenommen werden, zu denen es in
der anderen Tabelle auch einen zugehörigen Eintrag gibt (referentielle Integrität).
CHECK (eingeschränkt)
–
Trigger bei Änderungen in der Datenbank automatisch eine Aktion ausführen
–
Cursor dient zum
geordneten Durchlaufen von Sätzen in der Datenbank. Der Cursor
legt den aktuellen Datensatz fest und durchläuft z.B. nach einander alle Datensätze, die zu
einer Anfrage gehören.
CSA 128
WS 05/06
Literatur:
–
Einführung in die Kryptographie Network Associates
International (NAI) : http://www.nai.com, ebenfalls unter:
http://www.rzbd.haw-hamburg.de/ftp/files/kryptografie.pdf
–
Script von Prof. Völler Fachbereich E+I der HAW:
http://users.informatik.haw-hamburg.de/~voeller/crypto.zip
–
asymmetrisch (public, private Key)
symmetrisch, Problem: sicherer Austausch des Schlüssels
ein oder mehrere Attribute dürfen einen Wert oder eine
Wertekombination nur einmal enthalten.
3.1 Verschlüsselung / Einführung
●
Methoden
Attribut muss vorhanden sein
Stored Procedures (Oracle: PL/SQL = procedural SQL)
WS 05/06
zufällige Betrachtung / Enthüllung sensibler Daten
Systemadministratoren sollen nicht an alle Informationen
herankommen
Angriffe erschweren
NOT NULL
UNIQUE
–
CSA 127
–
Constraint (zusätzliche Bedingungen für Attributwerte)
graphische Benutzeroberflächen
●
WS 05/06
Das Handbuch der freien Software GnuPG
http://www.gnupg.org/gph/de/manual.pdf
Software
●
●
Netzwerkkommunikation: z.B. ssh, scp
E-Mail: z.B. PGP
CSA 129
CSA 130
3.2 Verschlüsselung / Beispiel
●
3.3 Verschlüsselung / Verfahren
WS 05/06
Beispiel für den Einsatz:
3.3.1 Symmetrische Verschlüsselung
–
Alice möchte bei Ihrer Bank eine Überweisung in Auftrag
geben. Zur Übertragung soll das Internet genutzt werden.
–
Probleme
●
●
●
WS 05/06
Vertraulichkeit (nur die Bank soll den Inhalt der Überweisung lesen können)
Authentizität (Die Bank muss sicher sein, daß die Überweisung von Alice stammt)
Integrität (Der Inhalt der Daten ist unverändert, z.B. der Überweisungsbetrag)
–
–
Alice
Überweisung
Integrität ergibt sich automatisch, wenn
● Vertraulichkeit
● Authentizität gewährleistet sind.
Manchmal ist Vertraulichkeit nicht erwünscht (z.B.
öffentliche Bekanntmachungen), dann sind aber Authentizität
(z.B. Reisewarnung stammt wirklich von der
Bundesregierung) und Integrität ( z.B.wurde tatsächlich für
das Land Algerien herausgegeben) wesentliche Forderungen
CSA 131
Quelle der Bilder NAI: http://www.rzbd.haw-hamburg.de/ftp/files/kryptografie.pdf
CSA 132
3.3 Verschlüsselung / Verfahren
3.3 Verschlüsselung / Verfahren
WS 05/06
3.3.1 Symmetrische Verschlüsselung (Fortsetzung)
●
3.3.1 Symmetrische Verschlüsselung (Fortsetzung)
●
In unserem Beispiel:
Alice
Überweisung
Merkmale der konventionellen (klassischen,
symmetrischen) Verschlüsselung
–
Sender und Empfänger verfügen über einen gemeinsamen
Schlüssel, der zum Ver- und Entschlüsseln benutzt werden
kann.
–
Der verschlüsselte Text ist ohne den Schlüssel nicht lesbar
●
Verschlüsselung
WS 05/06
–
Entschlüsselung
d.h. nur mit solchen Aufwand, dass sich der Versuch nicht lohnt
Das Verschlüsselungsverfahren ist allgemein bekannt
(Kerckhoffs Maxime, niederl. Philologe, Buch: La cryptographie militaire)
–
CSA 133
Geheim/vertraulich ist nur der Schlüssel
CSA 134
3.3.1 Symmetrische Verschlüsselung (Fortsetzung)
●
–
–
–
–
–
●
Umgeordnete Alphabete:
–
Es sei
–
Buchstaben verschieben (Cäsar): leicht zu knacken (z.B. Analyse der
Buchstabenhäufigkeiten)
T der zu verschlüsselnde Ausgangstext
C (chiffriert) der verschlüsselte Text
K (Key) der Schlüssel, der geheim zu halten ist
E( K, T ) eine Funktion, deren Berechnungsvorschrift bekannt ist und die
den verschlüsselten Text berechnet (engl. encode): C = E( T, K )
D( K, C ) eine Funktion, deren Berechnungsvorschrift bekannt ist und die
den Ausgangstext berechnet (engl. decode): T = D( K, C )
–
–
weitere ...
Verschlüsselungsmaschinen
–
Dt. Wehrmacht: Enigma
Dann gilt:
T = D( K, E(K, T) )
●
–
–
–
–
–
CSA 136
WS 05/06
3.3.2 Symmetrische Verschlüsselung, Beispiele (Fortsetzung)
DES (Data Encryption Standard)
–
Englisch
3.3 Verschlüsselung / Verfahren
WS 05/06
3.3.2 Symmetrische Verschlüsselung, Beispiele (Fortsetzung)
Deutsch
Bilder: Script Prof. Dr. Völler
CSA 135
3.3 Verschlüsselung / Verfahren
WS 05/06
3.3.2 Symmetrische Verschlüsselung, Beispiele
Mathematische Formulierung
●
3.3 Verschlüsselung / Verfahren
WS 05/06
Buchstabenhäufigkeiten
3.3 Verschlüsselung / Verfahren
–
1977 entwickelt von IBM unter Mitwirkung der NSA
Schlüssellänge 56 Bit (+ 8 Paritätsbits = 64)
Hintertür vorhanden?
● 1991 Shamir: Differntielle Kryptoanalyse => Reduktion des
Analyseaufwandes um 29 (512) auf 247 (1,4 1014)
● Bereits 1977 bekannt, aber nicht publiziert
Blockchiffre 64 Bit (8 Byte) Klartext -> 64 Bit Geheimtext
einfache logische und arithmetische Operationen, leicht in Hardware zu
realisieren
verschiedene Modi:
● ECB Electronic Code Book Mode: alle 64 Bit werden mit gleichem
Schlüssel verschlüsselt.
● CBC Chiper Block Changing Mode: Verschlüsselung des n-ten
Blocks verwendet Ergebnisse der vorangehenden n-1
Verschlüsselungen
CSA 137
DES (Data Encryption Standard)
●
Sicherheit
–
–
–
1978 Untersuchung durch ein US Senatskomitee: kein Hinweis auf
"Hintertüren" der NSA (Berichtsdetails heute noch geheim)
DES eine Gruppe? 1992: Keine Gruppe => mehrfache Verschlüsselung ist
sinnvoll: C = E( K1, E(K2, T) ) => zusätzliche Sicherheit
IDEA (Nachfolger von DES)
●
●
Schlüssellänge: 128 Bits
Triple IDEA: Verbesserung der Sicherheit:
C = E(K1, D(K2, E(K1,T)))
T = D(K1, E(K2, D(K1,T)))
CSA 138
3.3 Verschlüsselung / Verfahren
3.3.3 Symmetrische Verschlüsselung, Problem
–
3.3 Verschlüsselung / Verfahren
WS 05/06
WS 05/06
3.3.4 Asymmetrische Verschlüsselung, Prinzip
Austausch des symmetrischen Schlüssels (über
das Internet: unsicher!)
Empfänger
Empfänger
Übermittlung des
b Schlüssels auf
sicherem Weg
Alice
Überweisung
Verschlüsselung
●
Entschlüsselung
Lösung: asymmetrische Verschlüsselung (nächste Folie)
Quelle der Bilder NAI: http://www.rzbd.haw-hamburg.de/ftp/files/kryptografie.pdfCSA 140
CSA 139
3.3 Verschlüsselung / Verfahren
3.3.5 Hybrides Verfahren
Problem: asymmetrische Verschlüsselung ca. 1000 fach
langsamer als symmetrische Verschlüsselung
–
Lösung: Hybrides Verfahren
●
WS 05/06
3.3.6 Hybrides Verfahren (Fortsetzung)
–
●
3.3 Verschlüsselung / Verfahren
WS 05/06
–
Entschlüsseln beim hybriden Verfahren
Erzeugen eines zufälligen symmetrischen Sitzungsschlüssels
Übermittlung des Sitzungsschlüssels mit Hilfe der asymmetrischen
Verschlüsselung
Quelle der Bilder NAI: http://www.rzbd.haw-hamburg.de/ftp/files/kryptografie.pdf
CSA 141
Quelle der Bilder NAI: http://www.rzbd.haw-hamburg.de/ftp/files/kryptografie.pdfCSA 142
3.3 Verschlüsselung / Verfahren
3.3.7 Sicherheit der asymmetrischen Verschlüsselung
–
–
Schlüssellängenvergleich
–
–
Verifizieren: verschlüsselten Teil mit öffentlichem Schlüssel
entschlüsseln, bei Übereinstimmung: Unterschrift OK
(Authentizität)
Empfänger
RSA (1977, Autoren: Rivest, Shamir, Adlemann)
–
–
wähle große Primzhalen p,q, und wähle e,d mit (e*d)%((p-1)*(q-1)) = 1
öffentlicher Schlüssel: (e, p*q), privater Schlüssel: (d, p*q)
Verschlüsselung einer Zahl t (0 <= t < p*q): c = te %(p*q), t = cd %(p*q)
ElGamal (1985 Taher ElGamal )
●
3.4 Verschlüsselung / Unterschriften
CSA 143
WS 05/06
3.4.2 Anwendbares Verfahren
CSA 144
3.4 Verschlüsselung / Unterschriften
WS 05/06
3.4.2 Anwendbares Verfahren (Fortsetzung)
Nachteile der grundlegenden Idee
●
●
●
Unterschreiben: Originaltext + mit privaten Schlüssel
verschlüsselten Text übertragen
Verfahren der asymmetrischen Verschlüsselung
●
–
–
Empfänger
symmetrischer 80 Bit Schlüssel entspricht 1024 Bit
asymmetrischem Schlüsselpaar
symmetrisch: 128 Bit ≙ asymmetrisch 3000 Bit
●
WS 05/06
3.4.1 Digitale Unterschrift, grundlegende Idee
entscheidend abhängig von der Rechnertechnologie, da der
private Schlüssel grundsätzlich aus dem öffentlichen
Schlüssel berechenbar ist, allerdings nur mit hohem
Berechnungsaufwand
●
3.4 Verschlüsselung / Unterschriften
WS 05/06
große Datenmengen sind zu übertragen (2 x Nachricht)
großer Berechnungsaufwand
Lösung: Hash-Funktion
(berechnet aus einem Text beliebiger Länge: Ausgabe
mit fester Länge, geringfügige Änderungen am Ausgangstext verändern Ergebnis völlig, z.B.
MD5 [RFC1321]: Message digest (engl. Nachrichten Zusammenfassung) Version 5,
128 Bit Länge (Autor: Rivest),
SHA1 [RFC3174]: US Secure Hash Algorithm 1, 160 Bit Länge)
CSA 145
Quelle der Bilder NAI: http://www.rzbd.haw-hamburg.de/ftp/files/kryptografie.pdfCSA 146
3.5 Verschlüsselung / Zertifikate
3.5.1 Grundlegende Idee
–
–
3.5 Verschlüsselung / Zertifikate
WS 05/06
Problem: Angriffe durch gezielte Verfälschung eines
öffentlichen Schlüssels (Man in the middle attack)
3.5.2 Zertifikate als Beispiel: X.509
–
ITU-T X.509 Zertifikate (internationaler Standard)
Lösung: Zertifikate / unterschriebene Schlüssel zur Prüfung der
●
Authentizität eines öffentlichen Schlüssels
●
–
–
●
–
–
●
X.509-Zertifikate
Unterschriebene öffentliche Schlüssel (PGP, Fa. NAI) Web of Trust
(=“Netz des Vertrauens“)
●
●
Inhalt:
–
–
öffentlicher Schlüssel
Zertifikatsdaten zur Identität des Benutzers
eine oder mehrere digitale Unterschriften einer vertrauenswürdigen
Einrichtung
●
●
Liste von vertrauenswürdigen Einrichtungen + deren öffentliche Schlüssel
Certificate Server (Schlüssel/ Zertifikatserver)
IE:
Extras ->
● Abrufen von Schlüsseln / Zertifikaten
Internetoptionen...
<Inhalte>
● Bereitstellen von Schlüsseln/Zertifikaten
>Zertifikate ...<CSA 147
3.5 Verschlüsselung / Zertifikate
●
●
... weitere Zertifiaktstypen z.B. PGP
–
Weitere Möglichkeit zur Prüfung der Gültigkeit:
Fingerabdruck (=Hash des Zertifikates)
3.5 Verschlüsselung / Zertifikate
–
müssen bei einer entsprechende Stelle beantragt werden
ein Name
eine digitale Unterschrift
–
●
CSA 148
WS 05/06
3.5.3 Public Key Infrastructure (PKI)
Eigenschaften der X.509 Zertifikate
●
●
Gültigkeitsdauer (Anfangs- und Ablaufdatum)
Eindeutiger Name des Zertifikatausstellers
Digitale Unterschrift des Ausstellers
Kennung für das Unterschriftsverfahren (Algorithmus =
Berechnungsmethode)
WS 05/06
3.5.2 Zertifikate als Beispiel: X.509 (Fortsetzung)
–
X.509 Versionsnummer
öffentlicher Schlüssel des Zertifikatsinhabers
Seriennummer des Zertifikats
Eindeutige Kennung des Zertifikatsinhabers
CN=Bob Allen, OU=Total Network Security Division, O=Network Associates
C=US
CN: Common Name (bekannter Name), OU: Organization Unit (Firmenabteilung),
O: Organization (Firma) , C: Country (Land)
zur Automatisierung des Ablaufes benötigt man:
–
WS 05/06
Def. PKI: Darunter versteht man alle Einrichtungen,
Werkzeuge und Verfahren, die erforderlich sind, um
Verschlüsselung in einem konkreten Anwendungsfall
fachgerecht einzusetzen.
●
●
●
MD5 Fingerprint=22:55:A4:CF:F3:3D:5E:73:74:E1:5F:73:B3:5A:9F:8B
Ein solcher Fingerabdruck kann beispielsweise auf einer
Visitenkarte stehen, die persönlich (oder per Post) einem
Kommunikationspartner übergeben wird.
Zertifizierungsinstanz (entspricht Behörde, die Ausweise ausstellt)
(Trustcenter)
Zertifikat-Server
Verwaltungsinformationen für Zertifikate
–
●
Zertifizierungskette / -pfad
–
CSA 149
Gültigkeit: Ausgestellt, zurückgenommen, Vertrauenseinstufung
Auf oberster Ebene: Root Zertifikat
CSA 150