3.1Vorgehen bei Entwurf und Realisierung einer Datenbank

Datenbanken
•
•
•
•
•
•
•
•
Entwurf und Realisierung
1
Erstellung (Entwurf und Realisierung): Kapitelinhalt
Wie geht man generell vor bei einem Datenbankprojekt.
Wie werden Anforderungen erhoben und ein erster (fachlicher) Entwurf
erstellt.
Welche Möglichkeiten der Entwurfsdarstellung gibt es.
Kann es zwischen Datenbankobjekten unterschiedliche Arten von Beziehungen
geben und wie stellt man das geg.falls dar.
Wie dokumentiert man betriebliche Anforderungen, die im Entwurf nicht so
ohne weiteres aufgenommen werden können.
Weshalb wird zwischen einem fachlichen und einem technischen Entwurf
unterschieden, worin besteht der Unterschied und wie kommt man vom einen
zum anderen.
Was ist und wozu dient die „Normalisierung von Tabellen“. Wie geht man dabei
vor.
Welche Schritte müssen noch unternommen werden, um vom technischen
Entwurf zu einer funktionsfähigen Datenbank zu kommen.
Prof.Dr.Kühn /Fak. W
Datenbanken
2007
IMB1-K3-Erstellung.doc
Entwurf und Realisierung
2
3.1Vorgehen bei Entwurf und Realisierung einer Datenbank
• Vereinfachende Sichtweise: Schichtenmodell einer Datenbank
• Vorgehensmodell
= Anforderungskatalog und Fachlicher Entwurf
- Informationsanalyse
- Funktionsanalse
= Leistungsbeschreibung (Lastenheft) und technischer Entwurf
- Einschränkungen durch das gegebene DBMS
- Normalisierung
= Realisierung
- Tabellen
- Zugriffshilfen
- externe Modelle (Views)
- Aussagen bzgl. betrieblicher Zusatzbedingungen
- Aussagen bzgl. Zugriffsbeschränkungen
• Parallele Erstellung der Anwendungen
Prof.Dr.Kühn /Fak. W
2007
IMB1-K3-Erstellung.doc
Datenbanken
Entwurf und Realisierung
Anwendung
-1
Anwendungn
3
Schichtenmodell einer
Datenbank
externe
Modelle
E/K-Abbildung
E/K-Abbildung
konzeptionelles
Modell
K/I-Abbildung
Datenverwaltung
Datei-1
internes
Modell
Datei- m
Prof.Dr.Kühn /Fak. W
2007
Datenbanken
IMB1-K3-Erstellung.doc
Entwurf und Realisierung
4
Vorgehensmodell bei einem Datenbankprojekt
Parallel: Anwendungen erstellen und Transaktionen festlegen
Informationsanalyse
Funktionsanalyse
1a) Anforderungsanalyse
1b) Fachlicher Entwurf
Teil des
Anforderungs
katalogs
Konzeptionelles Modell (1)
(unabh. v. Datenbanktyp)
2) Implementierungsentw.
(technischer Entwurf)
Teil der
Leistungsbeschreibung
Konzeptionelles Modell (2)
(bezogen auf einen
bestimmten DB-Typ / ein
bestimmtes DB-System)
Erstellen der DB-Struktur
Optimieren der Speicherung
Benutzerrechte vergeben
Erst-Laden der Datenbank
3) Realisierung
4) Einsatz
Prof.Dr.Kühn /Fak. W
Zugriff auf die Datenbank
2007
IMB1-K3-Erstellung.doc
Datenbanken
Entwurf und Realisierung
5
3.2. Anforderungsanalyse und fachlicher Entwurf
reale Welt
Abstraktion
Miniwelt
Informationsanalyse
(datenbezogen
statisch)
Funktionsanalyse
(ablaufbezogen
dynamisch)
Konzeptionelles
Schema (1)
Prof.Dr.Kühn /Fak. W
2007
Datenbanken
IMB1-K3-Erstellung.doc
Entwurf und Realisierung
6
zu: Anforderungsanalyse und fachlicher Entwurf
• Anforderungen jeweils aufgabenbezogen / gruppenweise erheben
Methoden?
• Informationensanalyse:
wo werden welche Informationen derzeit gespeichert/ verwendet / gepflegt
Objekte/Objekttypen identifizieren; erwartete Datenmenge?
Attribute sammeln und zuordnen;
identifizierende Attribute, Datentypen und Wertebereiche klären;
Beziehungen festlegen und Kardinalitäten klären
• Funktionsanalyse
Welche Auswertungen werden bzgl. der Daten derzeit durchgeführt;
welche sind gewünscht
wie oft erfolgt eine bestimmte Auswertung; welche Informationen benötigt sie
welche Geschäftsregeln gibt es
• Jeweils aufgabenbezogener fachlicher Entwurf
• Entwürfe zusammenführen
geg.falls entitytypen, Beziehungen, Namensgebung, Datentypen angleichen
Konzeptionelles Schema (1) mit ERD
Prof.Dr.Kühn /Fak. W
2007
IMB1-K3-Erstellung.doc
Datenbanken
Entwurf und Realisierung
7
3.2.2 Entwurfsdarstellung: ERD
Mögliche Beziehungen zwischen Objekttypen
KdNr
Name
AufNr
1
Summe
n
Kunde
1:n Beziehung
Aufdat
Auftrag
<0,*>
erteilt
<1,1>
Hierarchie
n
1
1:n Eigenbeziehung
Angestellte
AngNr
Prof.Dr.Kühn /Fak. W
Abteilung
2007
Datenbanken
IMB1-K3-Erstellung.doc
Entwurf und Realisierung
MNr
8
...
Funktion
Projekt
Mitarbeiter
<0,3>
StellenNr
Funktion
...
n
m
n:m Beziehung
PNr
...
Gehalt
Zuordnung
<1,10>
MaNr
1
Name
Eintrittsdat
1
Stelle
Mitarbeiter
<0,1>
hat
<1,1>
1:1 Beziehung
Prof.Dr.Kühn /Fak. W
2007
IMB1-K3-Erstellung.doc
Datenbanken
Entwurf und Realisierung
9
„Starke“ und „schwache“ Entitytypen
¾ Starke Entitytypen können unabhängig von Anderen und unabhängig
von Beziehungen existieren.
Beispiel: Gebäude, Vorlesung („Stammdaten“)
¾ Schwache Entitytypen existieren nur aufgrund ihrer Beziehungen zu
anderen Entitytypen. Schwache Entitytypen werden im ERD manchmal
durch doppelte Umrahmung dargestellt. Der PK des starken Entitytyps ist
häufig Teil des PK des schwachen Entitytyps.
1
n
Gebäude
Raum
Bsp: Raum: nur sinnvoll mit Bezug zum Gebäude.
oder
Entleiher – Ausleihe - Buch :
Ausleihe: nur sinnvoll mit d. anderen Entitytypen u. Beziehungen
Prof.Dr.Kühn /Fak. W
Datenbanken
2007
IMB1-K3-Erstellung.doc
Entwurf und Realisierung
10
Beispiel: fachlicher Entwurf zu einer Auftragsbestätigung
Herrn Meier
Fa. Comtech
Maulstr.7
76666 Karlsruhe
1.7.05
Auftragsnummer: A7020456
Kundenbetreuer: Erwin Kunz Tel. 0721/283949
Sehr geehrter Herr Meier,
hiermit bestätigen wir Ihren Auftrag vom 25.6.05
Pos.Nr.
Artikel
1
Laptop Dell,
PentiumII,128MB
Artikelnr
LT1789
Anzahl
5
Einzelpreis
1990.-
Preis
9950.-
2
Laserdrucker / Laserjet III
LD0245
10
360.-
3600.-
3
Tintenstrahldrucker
HP Deskjet 720
DT0303
15
190.-
2850.-
4
Maus / Intellimouse
MA0501
10
29.95
299.50
Auftragssumme
3% Rabatt
Gesamtsumme
Prof.Dr.Kühn /Fak. W
2007
16699.50
500.98
------------------------------16198.52
IMB1-K3-Erstellung.doc
Datenbanken
Entwurf und Realisierung
11
Mehrwertige Beziehungen
MANr
MAName
Vertriebs_MA
KdNr
1
Name
<0,*>
AufNr
1
Auftrag
<0,*>
Auftrags
erteilung
<1,1>
...
...
...
Funktion
PNr
Auftragserteilung
m
n
Mitarbeiter
Projekt
<0,3>
<1,10>
1
Auftraggeber
Prof.Dr.Kühn /Fak. W
Datenbanken
Summe
n
Kunde
MNr
Aufdat
AGNr
2007
IMB1-K3-Erstellung.doc
Entwurf und Realisierung
12
Standardentwurf (ERD) (bisher besprochen)
¾ Nur einfache Attribute
¾ Nur „allg. Beziehungen“ (Assoziationen)
Æ direkt in eine (rein) relationale DB umsetzbar
Erweiterter Entwurf (EERD)
¾ Zusätzliche Datentypen
¾ Zusätzliche Beziehungstypen
Æ nur auf „Umwegen“ in eine relationale DB umsetzbar
Æ teilweise in eine objekt-relationale DB
oder eine objektorientierte DB umsetzbar
Prof.Dr.Kühn /Fak. W
2007
IMB1-K3-Erstellung.doc
Datenbanken
Entwurf und Realisierung
13
Andere Arten der grafischen Entwurfsdarstellung
• Entitiy Relationship Diagramme sind die „klassischen“
Diagramme für den Datenbankentwurf.
• Es sind aber noch andere Darstellungsweisen gebräuchlich:
•
(Abgewandelte) UML-Klassendiagramme (s. nächste Seite)
•
Diagramme mit „Krähenfuß“-Notation (s. Access)
In dieser Vorlesung werden weiterhin Entitiy Relationship
Diagramme verwendet
Prof.Dr.Kühn /Fak. W
2007
IMB1-K3-Erstellung.doc
Datenbanken
technischer Entwurf und Reakisierung
1
3.3 Technischer Entwurf (Implementierungsentwurf)
3.3.1 Prinzipielles Vorgehen
a) Attribute überprüfen
b) Beziehungen überprüfen
c) Normalform der Tabellen prüfen / Tabellen normalisieren
(Tabellen teilen)
überarbeitetes Entity Relationship Diagramm erstellen
Prof.Dr.Kühn /Fak. W
Datenbanken
a)
2007
IMB2-K3-Erstellung.doc
technischer Entwurf und Reakisierung
2
Attribute überprüfen
was kann im verwendeten DBMS dargestellt werden
- welche Datentypen stehen zur Verfügung
- gibt es zusammengesetzte Attribute
- wie sollen Wiederholungsgruppen behandelt werden
Prof.Dr.Kühn /Fak. W
2007
IMB2-K3-Erstellung.doc
Datenbanken
technischer Entwurf und Reakisierung
3
b) Beziehungen überprüfen:
Zweierbeziehungen vom Typ 1:n
a) Standard: Mitführen des Fremdschlüsselattributs
b) evt. eine zusätzliche Relation einführen,
wenn viele Nullwerte/wenige Teffer in einer großen Basismenge
Zweierbeziehungen vom Typ n:m
stets in zwei 1:n-Beziehungen auflösen (mit Verbindungsrelation)
Zweierbeziehungen vom Typ 1:1
- entweder als getrennte Relationen
- bei häufigem Join und Muss-Beziehung auch als eine Relation
Eigenbeziehungen (1:1 oder 1:n)
Kann-Beziehung: meist als eigene Relation (Einwohner,verheiratet mit ...)
Muß-Beziehung: meist Mitführen des Schlüssels i.d. Ausgangstabelle als
zusätzliches („Fremdschlüssel-“) Attribut
Mehrwertige Beziehungen
Werden in entsprechend viele zweiwertige 1:n-Beziehungen plus
Verbindungsrelation aufgelöst
Prof.Dr.Kühn /Fak. W
Datenbanken
2007
IMB2-K3-Erstellung.doc
technischer Entwurf und Reakisierung
4
c) Normalform der Tabellen prüfen: Normalisierung
Ziele der Normalisierung:
•
•
•
•
•
•
•
•
Keine zusammengesetzten Attribute
Keine Relationen mit variabler (sondern nur fester) Breite
Möglichst keine Redundanz in Nicht-Schlüsselattributen
In jede Tabelle nur das, was logisch / inhaltlich
zusammengehört.
Damit Vermeiden von
Aktualisierungsanomalien
Einfügeanomalien
Löschanomalien
Prof.Dr.Kühn /Fak. W
2007
IMB2-K3-Erstellung.doc
Datenbanken
technischer Entwurf und Reakisierung
5
Beispiel-1:
Aufträge (AufNr, Aufdat, AufBetrag,KNr,KName,KAdresse)
• Einfügeanomalie:
Neuer Kunde kann nur bei gleichzeitiger Auftragserteilung aufgenommen
werden
• Löschanomalie
Kundeninfo verschwindet wenn letzter Auftrag gelöscht wird
Beispiel-2:
Vorlesung (VorNr, VorBez, VorRaum, ProfName, ProfRaum, ProfSprechstd)
• Aktualisierungsanomalie:
Wenn die Sprechstunde eines Professors sich ändert, so muss sie in allen seinen
Vorlesungsdatensätzen geändert werden.
• Einfügeanomalie
Ein Professor wird berufen. Dann können seine persönlichen Daten nicht
aufgenommen werden solangeVorNr noch nicht bekannt ist.
• Löschanomalie
Wenn die „letzte“ Vorlesung eines Professors gelöscht wird, dann geht auch die
Information bzgl. Sprechstunde und Raum verloren.
Prof.Dr.Kühn /Fak. W
Datenbanken
2007
IMB2-K3-Erstellung.doc
technischer Entwurf und Reakisierung
6
Einschub: Abhängigkeiten zwischen Attributen
1.Funktionale Abhängigkeit:
• Ein Attribut B ist von einem Attribut A "funktional abhängig",
wenn aus einem bestimmten Wert von A genau ein bestimmter
Wert von B folgt.
• Wenn A eine Attributkombination ist und zur eindeutigen
Bestimmung von B alle Attribute von A benötigt werden, so ist B
"voll funktional abhängig" von A.
Beispiel:
BUCH (BuchNr, Titel, Autor, Verlag, Preis)
AUSLEIHE (BuchNr, EntlNr, Rdat, MahnKennz)
Aber: AUSLEIHE2 (BuchNr, EntlNr, EntlName, Rdat, MahnKennz)
Prof.Dr.Kühn /Fak. W
2007
IMB2-K3-Erstellung.doc
Datenbanken
technischer Entwurf und Reakisierung
7
2. Transitive Abhängigkeit:
(Gegensatz: Direkte Abhängigkeit)
•
Gegeben: 3 Attribute A, B und C.
B sei von A (direkt) funktional abhängig.
Wenn C funktional von B abhängt, d.h.bereits durch den Inhalt
von B eindeutig festgelegt ist, so ist C indirekt (=transitiv= über B)
abhängig von A.
Beispiel:
KUNDE (KdNr,Name,VertrNr,VBezirk)
Prof.Dr.Kühn /Fak. W
Datenbanken
2007
IMB2-K3-Erstellung.doc
technischer Entwurf und Reakisierung
8
Normalisierung
¾ Erste Normalform:
Eine Relation ist in "erster Normalform", wenn sie eine feste Breite hat
(keine Wiederholungsgruppen enthält) und nur aus einfachen (nicht
zusammengesetzten) Attributen besteht.
¾ Zweite Normalform
Eine Relation ist in "zweiter Normalform", wenn sie in erster Normalform
ist und jedes Attribut vom Primärschlüssel voll funktional abhängig ist.
Wenn der Primärschlüssel nur aus einem Attribut besteht, so ist eine Relation, die sich in
1.Normalform befindet, automatisch auch in 2.Normalform.
Beispiel:
R1 (MA-Nr, Name, {projNr, PrTitel, Funktion, PrBeginn}, AbtNr,
AbtName, Gehalt)
Aufteilen:
keine NF
(1. und) 2.NF
R1-1 (MA-Nr, Name, AbtNr, AbtName, Gehalt)
R1-2 (projNr, PrTitel, Funktion, PrBeginn, MA-Nr)
1.NF, nicht 2.NF
Prof.Dr.Kühn /Fak. W
2007
IMB2-K3-Erstellung.doc
Datenbanken
technischer Entwurf und Reakisierung
9
¾ Dritte Normalform
Eine Relation ist in "dritter Normalform", wenn sie zweiter Normalform ist
und wenn jedes Attribut nur direkt (und nicht transitiv) vom Primärschlüssel
abhängt.
R1-1 (MA-Nr, Name, AbtNr, AbtName, Gehalt)
R1-2 (projNr, PrTitel, Funktion, PrBeginn, MA-Nr)
(1. und) 2.NF
1.NF, nicht 2.NF
R1-1-1 (MA-Nr, Name, AbtNr, Gehalt)
R1-1-2 (AbtNr, AbtName )
R1-2-1 (projNr, PrTitel, PrBeginn)
R1-2-2 (projNr, MA-Nr, Funktion)
(1., 2.und) 3.NF
3.NF
3.NF
3.NF
(Unterstrichen: Primärschlüssel; kursiv: Fremdschlüsselattribut)
Prof.Dr.Kühn /Fak. W
Datenbanken
2007
IMB2-K3-Erstellung.doc
technischer Entwurf und Reakisierung
10
Wdh: Vorgehen bei der Normalisierung
VERKAUF (KdNr, KdName, KdAdresse, RNr, RDat, RBetrag, ZahlDat, Mahnkz)
KONTAKTE (KdNr, KdName, VertrNr, Datum, Kontakt, VertrNr, Datum, Kontakt,...)
1. zusammengesetzte Attribute auflösen:
Verkauf --> V1
V1 (KdNr, KdName, KdStrasse, KdPLZ, KdOrt, RNr, RDat, RBetrag, ZahlDat, Mahnkz)
2. Wenn Wiederholungsgruppen vorhanden sind:
Jede Wiederholungsgruppe in eine eigene Tabelle auslagern;
dabei den ursprünglichen PK jeweils als zusätzliches Feld mitnehmen, um
den Zusammenhang zu wahren.
KONTAKTE --> K1, K2
K1 (VertrNr, Datum, Kontakt, KDNr); K2(KD-Nr, KD-Name)
In der neuen Tab. den PK festlegen (wird meist aus mehr als 1 Feld bestehen
oder als zusätzliches künstliches Attribut festgelegt)
Prof.Dr.Kühn /Fak. W
2007
IMB2-K3-Erstellung.doc
Datenbanken
technischer Entwurf und Reakisierung
11
3. Tabellen mit einem PK, der aus mehr als 1 Feld besteht:
Gibt es Attribute, die bereits durch e. Teil des PK bestimmt sind: --> in
eigene Tabelle auslagern. Das bestimmende Attribut (Teil des ursprüngl.
PK) als zusätzliches Feld mitnehmen. Wird PK der neuen Tab.
AUFTRAG (AufNr, ArtNr, KNr, Dat, GesBetrag , ArtBez, Anzahl, EPreis) -->A1, A2, A3
A1(AufNr, KNr, Dat, GesBetrag);
A2(ArtNr, ArtBez, EPreis);
A3(AufNr, ArtNr, Anzahl)
4. Alle Tabellen
Gibt es Attribute, die nur indirekt vom PK abhängen: --> in eigene Tabelle
auslagern. Das bestimmende Attribut als zusätzliches Feld mitnehmen. Wird
PK der neuen Tabelle. V1 --> V2,V3
V1 (KdNr, KdName, KdStrasse, KdPLZ, KdOrt, RNr, RDat, RBetrag, ZahlDat, Mahnkz)
V2(KdNr, KdName, KdStrasse, KdPLZ, KdOrt),
V3(KdNr, RNr, RDat, RBetrag, ZahlDat, Mahnkz)
Prof.Dr.Kühn /Fak. W
2007
Datenbanken
IMB2-K3-Erstellung.doc
technischer Entwurf und Reakisierung
12
3.4 Realisierung der Datenbank
Informationsanalyse
Funktionsanalyse
Anforderungsanalyse
Fachlicher Entwurf
Teil des
Anforderungs
katalogs
Konzeptionelles Modell (1)
(unabh. v. Datenbanktyp)
Implementierungsentwurf
(technischer Entwurf)
Teil der
Leistungsbeschreibung
Konzeptionelles Modell (2)
(bezogen auf einen
bestimmten DB-Typ / ein
bestimmtes DB-System)
Erstellen der DB-Struktur
Optimieren der Speicherung
Benutzerrechte vergeben
Erst-Laden der Datenbank
Realisierung
(Implementierung)
Einsatz
Prof.Dr.Kühn /Fak. W
Zugriff auf die Datenbank
2007
IMB2-K3-Erstellung.doc
Datenbanken
technischer Entwurf und Reakisierung
13
Realisierung der Datenbank
a) Erstellen der Datenbankstruktur
b) Optimieren der Speicherung
c) Festlegen von (zusätzlichen) Benutzersichten und
Zugriffsrechten
d) Erstladen der Datenbank
e) Erstellen der Anwendungsprogramme
Prof.Dr.Kühn /Fak. W
Datenbanken
2007
IMB2-K3-Erstellung.doc
technischer Entwurf und Reakisierung
14
Zu a): Datenbankstruktur erzeugen
¾Objekttypen mit SQL-Befehlen in Tabellen umsetzen (create ...):
• Jeder Entitätstyp Æ Relation; Attribute aus ERD
•
•
•
•
Auf PRIMARY KEY und Fremdschlüsselattribute achten
evt. gezielte Denormalisierung
Umsetzung von Zweierbeziehungen vom Typ 1:n
a) Standard: Mitführen des Schlüsselattributs der übergeordneten
Relation (references-Klausel?)
b) evt. als eigene Relation, wenn sonst sehr viele Nullwerte
(Entleiher, Buch; Entleiher, Buch, Entleihsatz)
Umsetzung von Zweierbeziehungen vom Typ 1:1
- entweder als getrennte Relationen
- bei häufigem Join auch als eine Relation
- auch abhängig davon, ob Muss- oder Kann-Beziehung
Umsetzung von Eigenbeziehungen (1:1 oder 1:n)
Kann-Beziehung: meist als eigene Relation (Einwohner,verheiratet mit ...)
Muß-Beziehung: meist Mitführen des Schlüssels i.d. Ausgangstabelle als
zusätzliches („Fremdschlüssel-“) Attribut
Prof.Dr.Kühn /Fak. W
2007
IMB2-K3-Erstellung.doc
Datenbanken
technischer Entwurf und Reakisierung
15
¾ Constraints: überprüfen, ergänzen
soweit möglich fachliche Randbedingungen berücksichtigen
• Muss- und Kann-Felder
• CHECK constraint
• DEFAULT Werte für Attribute
• Soweit die SQL-Syntax nicht ausreicht, muss über Prüfprogramme
(Trigger) nachgedacht werden
¾ ist Unterstützung von min/max Aussagen möglich?
evt. muss über Prüfprogramme (Trigger) nachgedacht werden
¾ Zugriffsunterstützung:
• Bei großen Datenmengen und häufigem Zugriff entsprechende
Indextabellen definieren
Prof.Dr.Kühn /Fak. W
Datenbanken
2007
IMB2-K3-Erstellung.doc
technischer Entwurf und Reakisierung
16
Zu b): Speicherung der Daten:
• Jedes DBMS hat Standardeinstellungen bzgl.der Speicherung der
Benutzerdaten.
• Bei Bedarf kann der Datenbankverwalter abweichende Einstellungen
vornehmen
Zu c): Benutzerrechte:
•
•
Die Möglichkeiten, Benutzern Rechte für unterschiedliche Ausschnitte
der Datenbank und für unterschiedliche Aktionen zuzuweisen, sind für
verschiedene DBMS sehr unterschiedlich ausgeprägt.
Oracle:
CREATE VIEW
CREATE USER, CREATE ROLE
GRANT-Befehle
Prof.Dr.Kühn /Fak. W
2007
IMB2-K3-Erstellung.doc
Datenbanken
technischer Entwurf und Reakisierung
17
Zu d): Erst-Laden der Datenbank
• Dies kann ein zeitaufwendiger Prozess sein, für es von den meisten
Herstellern unterstützende Tools gibt. Unabhängig davon sollte jedoch
vorher die Korrektheit der zu ladenden Daten überprüft werden!
Zu e): Anwendungsprogramme
• Die wichtigsten Anwendungen wurden bereits beim Entwurf der
Datenbank berücksichtigt (s. Funktionsanalyse) und geg.falls parallel zur
Datenbank erstellt.
• Operative Anwendungen erhalten meist Bedienoberflächen mit
Formularen und Menüs, für deren Erstellung alle Datenbankanbieter
Entwicklungsprogramme (Tools, Assistenten,...) anbieten.
Prof.Dr.Kühn /Fak. W
Datenbanken
•
•
•
•
•
•
2007
IMB2-K3-Erstellung.doc
technischer Entwurf und Reakisierung
18
Erstellung (Entwurf und Realisierung): Zusammenfassung
Datenbankprojekte werden wie andere SW-Entwicklungsprojekte nach einem
Vorgehensmodell durchgeführt. Meist werden parallel zur Datenbank auch die wichtigsten
Anwendungsprogramme entwickelt.
Die betrieblichen Anforderungen führen zu einem fachlichen Entwurf, der zumindest teilweise
mittels Diagrammen beschrieben wird. Es gibt dafür verschiedene grafische
Darstellungsformen, die sich (weitgehend) ineinander überführen lassen.
Im fachlichen Entwurf werden die Anforderungen dokumentiert, ohne auf die Möglichkeiten
eines bestimmten DBMS-Typs (oder gar die eines bestimmten DBMS) Rücksicht zu nehmen.
Außerdem werden evt. zusätzliche betriebliche Bedingungen als Text formuliert.
Der technische Entwurf muss den Bedingungen eines bestimmten, meist relationalen DBMS
genügen. Dafür sind oft Anpassungen und Umformungen (Normalisierung) von Tabellen
nötig.
Bei der Realisierung der Datenbank können zusätzlich Indextabellen zur Beschleunigung
bestimmter Abfragen, und SQL-constraints zur Realisierung mancher (nicht aller)
betrieblichen Zusatzbedingungen eingeführt werden. Ausserdem werden Benutzersichten
Views) formuliert, um Zugriffe bequemer zu gestalten oder den Benutzerzugriff auf bestimmte
Daten zu begrenzen.
Abschließend müssen (mit entsprechenden Insert-Befehlen oder mittels Hilfsprogrammen) die
Daten in die Datenbank geladen werden
Prof.Dr.Kühn /Fak. W
2007
IMB2-K3-Erstellung.doc