3.1Vorgehen bei Entwurf und Realisierung einer Datenbank

Transkript

1 1 Erstellung (): 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. 3.1Vorgehen bei 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 2

2 Anwendung -1 Anwendungn Schichtenmodell einer Datenbank 3 externe Modelle E/K-Abbildung E/K-Abbildung konzeptionelles Modell K/I-Abbildung Datenverwaltung Datei-1 Datei- m internes Modell Vorgehensmodell bei einem Datenbankprojekt Parallel: Anwendungen erstellen und Transaktionen festlegen 4 1a) Anforderungsanalyse 1b) Fachlicher Entwurf 2) Implementierungsentw. (technischer Entwurf) 3) Realisierung 4) Einsatz Teil des Anforderungs katalogs Teil der Leistungsbeschreibung Informationsanalyse Funktionsanalyse Konzeptionelles Modell (1) (unabh. v. Datenbanktyp) 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 Zugriff auf die Datenbank

3 3.2. Anforderungsanalyse und fachlicher Entwurf 5 Abstraktion reale Welt Miniwelt Informationsanalyse (datenbezogen statisch) Funktionsanalyse (ablaufbezogen dynamisch) Konzeptionelles Schema (1) 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 6 Konzeptionelles Schema (1) mit ERD

4 3.2.2 Entwurfsdarstellung: ERD Mögliche Beziehungen zwischen Objekttypen 7 KdNr Name AufNr Aufdat Summe 1:n Beziehung Kunde 1 n <0,*> erteilt <1,1> Auftrag Hierarchie n 1 1:n Eigenbeziehung Angestellte AngNr Abteilung 8 MNr... Funktion... PNr... n:m Beziehung Mitarbeiter m n Projekt <0,3> <1,10> Zuordnung StellenNr Funktion Gehalt MaNr Name Eintrittsdat Stelle 1 1 <0,1> hat <1,1> Mitarbeiter 1:1 Beziehung

5 Starke und schwache Entitytypen 9 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. Gebäude 1 n Raum Bsp: Raum: nur sinnvoll mit Bezug zum Gebäude. oder Entleiher Ausleihe - Buch : Ausleihe: nur sinnvoll mit d. anderen Entitytypen u. Beziehungen Beispiel: fachlicher Entwurf zu einer Auftragsbestätigung Herrn Meier Fa. Comtech Maulstr Karlsruhe Auftragsnummer: A Kundenbetreuer: Erwin Kunz Tel. 0721/ Sehr geehrter Herr Meier, hiermit bestätigen wir Ihren Auftrag vom Pos.Nr. Artikel Artikelnr Anzahl Einzelpreis Preis 1 Laptop Dell, LT PentiumII,128MB 2 Laserdrucker / Laserjet III LD Tintenstrahldrucker DT HP Deskjet Maus / Intellimouse MA Auftragssumme % Rabatt Gesamtsumme

6 Mehrwertige Beziehungen MANr Vertriebs_MA MAName 11 KdNr Name 1 <0,*> AufNr Aufdat Summe MNr... Mitarbeiter Kunde m <0,3> 1 <0,*> Auftrags <1,1> erteilung Funktion 1... Auftragserteilung n <1,10> n... Auftrag PNr Projekt Auftraggeber AGNr Standardentwurf (ERD) (bisher besprochen) Nur einfache Attribute Nur allg. Beziehungen (Assoziationen) 12 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

7 13 Andere Arten der grafischen Entwurfsdarstellung Entitiy Relationship Diagramme sind die klassischen Diagramme für den twurf. 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

8 1 3.3 Technischer Entwurf (Implementierungsentwurf) 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 2 a) 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

9 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 3 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

10 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. 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)

11 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) 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. 8 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 R1-1 (MA-Nr, Name, AbtNr, AbtName, Gehalt) (1. und) 2.NF R1-2 (projnr, PrTitel, Funktion, PrBeginn, MA-Nr) 1.NF, nicht 2.NF

12 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) (1. und) 2.NF R1-2 (projnr, PrTitel, Funktion, PrBeginn, MA-Nr) 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) 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)

13 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) 3.4 Realisierung der Datenbank 12 Anforderungsanalyse Fachlicher Entwurf Implementierungsentwurf (technischer Entwurf) Realisierung (Implementierung) Einsatz Teil des Anforderungs katalogs Teil der Leistungsbeschreibung Informationsanalyse Funktionsanalyse Konzeptionelles Modell (1) (unabh. v. Datenbanktyp) 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 Zugriff auf die Datenbank

14 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 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 14

15 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 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

16 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. 18 Erstellung (): 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