Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

TU Dresden - Institut für Bauinformatik Folie-Nr.: 1 Bauinformatik II, Softwareanwendungen 1; 5. Vorlesung Bauinformatik II Softwareanwendungen 1 5. Semester.

Ähnliche Präsentationen


Präsentation zum Thema: "TU Dresden - Institut für Bauinformatik Folie-Nr.: 1 Bauinformatik II, Softwareanwendungen 1; 5. Vorlesung Bauinformatik II Softwareanwendungen 1 5. Semester."—  Präsentation transkript:

1 TU Dresden - Institut für Bauinformatik Folie-Nr.: 1 Bauinformatik II, Softwareanwendungen 1; 5. Vorlesung Bauinformatik II Softwareanwendungen 1 5. Semester 7. Vorlesung Datenbankentwurf- Normalisierung Prof. Dr.-Ing. R. J. Scherer Nürnberger Str. 31a 2. OG, Raum 204 TU Dresden - Institut für Bauinformatik Relationale Datenbanken für Bauingenieurprobleme

2 TU Dresden - Institut für Bauinformatik Folie-Nr.: 2 Bauinformatik II, Softwareanwendungen 1; 5. Vorlesung Normalisierung Ziel: Redundanzfreie Speicherung der Daten und keine Nullwerte Ablauf: in mehreren (Normalisierungs-)Stufen Vorteil: 1. keine Mutationsanomalie, die zu kontrollieren wären 2. geringerer Speicherplatzbedarf (evtl.) 3. erhöhte Schnelligkeit (evtl.) Mutationsanomalie entsteht durch unvollständige Änderung redundanter Daten PNr Name Vorname Baumaschine Typ Anders Berger Lehmann Schulze Sven Paul Andreas Jens Bagger Kipper LKW BG 20 KPx/5 DL 38 A/2 Beispiel: Wenn es keine seperate Relation Baumaschinen gäbe und Relation Bagger-Baggerfahrer gelöscht werden soll, dann wird auch die Person gelöscht. Baufahrzeugfahrer Methode: Buttom Up Datenbankentwurf

3 TU Dresden - Institut für Bauinformatik Folie-Nr.: 3 Bauinformatik II, Softwareanwendungen 1; 5. Vorlesung Buttom-UP Ansatz Der Buttom UP-Ansatz ist eine Entwurfsstrategie für einen Routine-Entwurf, der ausgeht von der Beobachtung. 1.Beobachten und aufschreiben (Analog der Statistik: beob. + zählen) 2.Nach vorgegebenen Regeln um-ordnen und um-strukturieren 3.Ergebnis: allgemeingültiger Erst-Entwurf / Modell 4.Ergänzen auf Grund von Tests in der Praxis Definition: Routine-Entwurf : Der Problemraum ist vollständig bekannt, d. h. mit den vorhandenen Regeln ( = Wissen) sind alle auftrettenden Probleme richtig zu lösen (=Voraussetzung zur Anwendung des Buttom-UP Ansatzes) Der Routine-Entwurf kann sowohl zu einem routine als auch zu einem innovativen Ergebnis führen (innovativ = neuartig, vorher so noch nicht da gewesen) Anwendung: bei komplexen ( schwierigen) Problemen Anmerkung: unter Zeitdruck sind auch schon einfache Probleme komplex.

4 TU Dresden - Institut für Bauinformatik Folie-Nr.: 4 Bauinformatik II, Softwareanwendungen 1; 5. Vorlesung Redundanz Redundanz entsteht durch : 1.Mehrfachspeicherung derselben Entität oder Attribute einer Entität 2.Abhängigkeiten innerhalb einer Entität, d. h. zwischen den Attributen. Zu entscheiden ist zwischen 3 Arten von Abhängigkeiten: 1.Funktionale Abhängigkeit 2.Volle Abhängigkeit 3.Transitive Abhängigkeit

5 TU Dresden - Institut für Bauinformatik Folie-Nr.: 5 Bauinformatik II, Softwareanwendungen 1; 5. Vorlesung Funktionale Abhängigkeit Ein Attribut B ist von einem Attribut A funktional abhängig, wenn zu einem bestimmten Attributwert von A genau ein Attributwert von B gehört. Gleiches gilt für Attribut-Kombinationen von A und B Der Name des Arbeiters ist funktional von der Personal_Nr. abhängig. Alle Attribute einer Entität sind von jedem Schlüsselattribut (-kombination) funktional abhängig. Arbeitskräfte: PNr Name Vorname Müller Büttner Müller Max Felix Peter

6 TU Dresden - Institut für Bauinformatik Folie-Nr.: 6 Bauinformatik II, Softwareanwendungen 1; 5. Vorlesung Volle Abhängigkeit Ein Attribut B ist von einer Attributkombination A voll abhängig, wenn B nur von A, nicht jedoch schon von einem Teil der Attribut- Kombination A funktional abhängig ist. Gleiches gilt für eine Attributkombination von B. Das Kaufdatum ist vom ID-Schlüssel abhängig, jedoch nicht von nur einem der beiden Schlüsselattribute Lieferant, bzw. Material Alle Attribute sind vom ID-Schlüssel voll abhängig. Einkauf von Materialien: Baul.Objekt Adresse Material Bem. Mat.-Nr. Verkäufer Datum Einf.haus Stadtvilla Villa Waldweg 8 Talstr. 19 Bergstr. 5 Feldstr. 12 Fenster Türen Fenster Fenstertüren Türen Alu Holz Alu Holz-Alu Holz Plast Schmidt Müller Meyer Schmidt Bach Schenk

7 TU Dresden - Institut für Bauinformatik Folie-Nr.: 7 Bauinformatik II, Softwareanwendungen 1; 5. Vorlesung Transitive Abhängigkeit Ein Attribut C ist von einem Attribut A transitiv abhängig, wenn das Attribut B von A und das Attribut C von B, aber das Attribut A nicht von C funktional abhängig sind. Das gleiche gilt für Attributkombinationen von A, B, C A B C A Das Attribut Gewerkname ist von der Arbeiter-Nr. transitiv abhängig, weil GNr Gewerkname und ANr GNr, jedoch Gewerkname ANr. ANr GNr Gewerkname Maurer Zimmerer Dachdecker Gerüstbauer Maurer ANr GNr Gw ANr aber transitiv A C aber transitiv ANr C

8 TU Dresden - Institut für Bauinformatik Folie-Nr.: 8 Bauinformatik II, Softwareanwendungen 1; 5. Vorlesung 1. Normalform Eine Tabelle befindet sich in der 1. Normalform, wenn alle Attribute nur noch einfache Attributwerte enthalten. Objekt Adresse Elemente Material SNr. Lieferf-Fa L-Datum Einf.haus Stadtvilla Villa Wallstr. 8 Talstr. 19 Bergstr. 5 Feldstr. 2 Fenster Türen Fenster Fenstertüren Türen Alu Holz Alu Holz-Alu Holz Plast F & T B. Müller Meyer F & T Meyer Bau-Holz ONr Objekt Adresse ENr Elemente Material SNr FNr Liefer-Fa L-Datum Einf.haus Stadtvilla Villa Waldweg 8 Talstr. 19 Bergstr. 5 Feldstr Alu Holz Alu Holz Plast F & T B. Müller Meyer F & T Meyer Bau-Holz Es werden zusätzlich die Attribute 0Nr, ENr, FNr eingefügt, welche die baulichen Objekte, die einzubauenden Artikel (Fenster und Türen) und die Lieferfirmen klar definieren. Fenster Türen Fenster Fenstertüren Türen

9 TU Dresden - Institut für Bauinformatik Folie-Nr.: 9 Bauinformatik II, Softwareanwendungen 1; 5. Vorlesung 2. Normalform Eine Tabelle befindet sich in der 2. Normalform, wenn sie schon in der. 1. Normalform ist und jedes nicht zum ID-Schlüssel gehörende Attribut voll abhängig vom ID-Schlüssel ist. Durch die Aufteilung in 3 Tabellen ist für jede der 3 Tabellen die 2. Normalform erreicht. Aber: eine der Lieferfirmen kann nicht erfasst werden c m Elemente 1 m 1 Lieferung c Objekte FNr L-Fa L-Datum ENr ONr F & T B. Müller Meyer F & T Meyer Bau-Holz

10 TU Dresden - Institut für Bauinformatik Folie-Nr.: 10 Bauinformatik II, Softwareanwendungen 1; 5. Vorlesung 3. Normalform Eine Tabelle befindet sich in der 3. Normalform, wenn sie schon in der. 2. Normalform ist und kein Nichtschlüsselattribut vom ID-Schlüssel transitiv abhängt, d. h. keine Abhängigkeit untereinander außer zum ID. Tabellen in der 3. Normalform werden als normalisiert bezeichnet Ergebnis: 4 Tabellen Redundanzen so aufgeteilt, dass jede Tabelle in sich redundanzfrei ist c m Elemente 1 1 m 1 Lieferung Lieferfirma c mc Objekte ONr ENr L-Datum FNr FNr Lieferfirmen F & T B. Müller Meyer Bau-Holz

11 TU Dresden - Institut für Bauinformatik Folie-Nr.: 11 Bauinformatik II, Softwareanwendungen 1; 5. Vorlesung 4. Normalform (Höhere Normalform, Globale Normalisierung) Eine Tabelle befindet sich in der 4. Normalform, wenn sie schon in der. 3. Normalform ist und nur noch lokale und globale Attribute existieren. Definition: Lokale Attribute: Attribute die nur in einer Tabelle vorkommen und die nicht zum ID gehören Globale Attribute: Attribute, die in mindestens einer Tabelle den ID mit bilden Schwimmkran müsste 2mal aufgenommen werden Transformation: Generalisieren Kran Schwimmfahrzeug Baumaschinen Kran Schwimmfahrzeug

12 TU Dresden - Institut für Bauinformatik Folie-Nr.: 12 Bauinformatik II, Softwareanwendungen 1; 5. Vorlesung Normalisierungsprozess c m Fenster / Türen 1 1 m 1 Lieferung Lieferfirmen c mc Baul. Objekte Buttom-UP Entwurfsstrategie

13 TU Dresden - Institut für Bauinformatik Folie-Nr.: 13 Bauinformatik II, Softwareanwendungen 1; 5. Vorlesung Problem der Normalisierung immer mehr Tabellen 1.Reduziert die Übersichtlichkeit 2.Erhöht den Eingabeaufwand und macht ihn komplexer (viele IDs, die i. d. R. nur Kodenummern sind) 3.Erhöht die Komplexität der Abfragen (die verschachtelte Struktur muss in der Abfrage abgebildet werden, so sind z. B. die Türen eines Geschosses in sehr vielen Spezialtabellen zerstreut Abhilfe: Ontologie) 4.Verringert die Geschwindigkeit

14 TU Dresden - Institut für Bauinformatik Folie-Nr.: 14 Bauinformatik II, Softwareanwendungen 1; 5. Vorlesung Optimale Normalform Eine Mischung zwischen Übersichtlichkeit und Einfachheit und der Redundanzfreiheit Vergleichsweise: 1.Redundanzfreiheit 4. Normalform erfüllt 2.Redundanzkompromisse festlegen, um die Konsequenzen ´ überblicken zu können 1.Konsequenz: alle Redundanzen müssen durch Zusatzprogramme 100prozentig kontrolliert werden, so dass keine Mutationsanomalien entstehen können.

15 TU Dresden - Institut für Bauinformatik Folie-Nr.: 15 Bauinformatik II, Softwareanwendungen 1; 5. Vorlesung Wertebereiche von Attributen Statischer Wertebereich: der Wertebereich ist festgelegt: a) begrenzte vorgegebene Menge von Werten, z. B. Farben b) begrenzte, vorgegebene Elemente, aus denen die Werte gebildet werden können, z. B. Anzahl der Zeichen für die Namen, Anzahl der Bytes für Integerzahlen c) zusätzliche Anschlusskriterien: Plausibilitätsbedingung Dynamischer Wertebereich: ist der Wertebereich für einen Fremdschlüssel. Der Fremdschlüssel wird aus einem ID-Schlüssel gebildet. Der Wertebereich ist durch die Werte, die die ID Schlüsselattribute bisher besitzen, begrenzt. Es können aber neue ID-Schlüssel-Werte eingegeben werden dynamisch

16 TU Dresden - Institut für Bauinformatik Folie-Nr.: 16 Bauinformatik II, Softwareanwendungen 1; 5. Vorlesung Strukturregeln für den Datenbankentwurf 1.Jede Tabelle muss einen ID besitzen 2.Eine Datenbasis muss in der 3. Normalform sein (Ausnahmen) 3.Lokale Attribute müssen statische Wertebereiche verwenden Globale Attribute dürfen nur in 1 Tabelle einen statischen Wertebereich besitzen und sind der ID 4.Rekursive Relationen sind verboten Fremdschlüssel nur von Tabellen (B), die von aktueller Tabelle (A) unabhängig sind 5.Generalisierung / Spezialisierung immer angeben diskreminierendes Attribut muss bei vollständiger Überdeckung angegeben werden. 6.Bei Fremdschlüssel diejenigen Bezugstabellen bezeichnen die größtmögliche Wertebereichsbeschränkungen bringen

17 TU Dresden - Institut für Bauinformatik Folie-Nr.: 17 Bauinformatik II, Softwareanwendungen 1; 5. Vorlesung Vorgehensweise beim Datenbankentwurf Buttom-UP Entwurfsstrategie Start Aufgabe definieren Entitätsmengen bilden Beziehungen festlegen Identifikationsschlüssel Globale Normalisierung Lokalattribute definieren Konsistenzbedingungen Transaktionen formulieren Ende formulieren durchführen definieren

18 TU Dresden - Institut für Bauinformatik Folie-Nr.: 18 Bauinformatik II, Softwareanwendungen 1; 5. Vorlesung. A.) Grobentwurf. 1. WER – WEN - WAS. 2. Beziehungen festlegen alles hinschreiben, auch Widersprüche (um sie anschließend schrittweise auflösen zu können

19 TU Dresden - Institut für Bauinformatik Folie-Nr.: 19 Bauinformatik II, Softwareanwendungen 1; 5. Vorlesung B.) Globale Normalisierung (NF4).schrittweise durchführen 1.rekursive Abhängigkeit entfernen 2.volle Spezialisierung 3.konditionelle und netzwerkförmige Beziehungen 4.NF4 nur noch lokale und globale Attribute auch innerhalb eines Schritt(bereich)es ist schrittweise vorzugehen, da sonst. a) etwas übersehen wird... b) unnötige Entitäten entstehen

20 TU Dresden - Institut für Bauinformatik Folie-Nr.: 20 Bauinformatik II, Softwareanwendungen 1; 5. Vorlesung C.) Jede Tabelle mindestens in 3. NF bringen Ob eine Tabelle als normalisiert betrachtet werden kann, hängt weitgehend von der Aufgabenstellung und den Anforderungen an die Datenkonsistenz ab. D.) Sinnvolle Auslagerungen /Untertabellen für Attribute mit kleinem Wertebereich (= Unterthemen) E.) Wertebereiche festlegen schriftlich in Tabelle dokumentieren

21 TU Dresden - Institut für Bauinformatik Folie-Nr.: 21 Bauinformatik II, Softwareanwendungen 1; 5. Vorlesung F.) Transaktionen definieren. kann aus mehreren Operationsschritten bestehen Alles-oder-Nichts = wenn ein Transaktionsschritt fehlschlägt, ist der Zustand von der Transaktion wieder herzustellen und alle vorherigen Schritte wieder rückgängig zu machen (oder alles wurde zwischengespeichert) Komplexität von Beziehungen vorgeben G.) Dokumentieren Berichte erstellen (s. Transaktionen - Teilbereich davon)

22 TU Dresden - Institut für Bauinformatik Folie-Nr.: 22 Bauinformatik II, Softwareanwendungen 1; 5. Vorlesung Beispiel: Verwaltung der Personen, die auf einer Baustelle tätig sind. 1. Welche Arbeiter sind auf welcher Baustelle zu welcher Arbeit wann eingesetzt und wer war ihr Bauleiter. 2. Die Personaldaten werden von der Personalabteilung, die Bauarbeiten vom Bauleiter und der Baustelleneinsatz von dem Projektleiter verwaltet. 3. Jede Person ist mit P-NR, Name, Vorname, Funktion und Lohnstufe zu erfassen. 4. Bauarbeiten, sind mit BA-Nr, Gewerk, Ort und Art der Arbeit anzugeben.5. Einige Arbeiter können auch Bauleiter sein. Bei diesen internen Bauleitern ist die Berufserfahrung in Jahren anzugeben. Jeder Baustelleneinsatz ist mit Arbeiter, Bauleiter und Einsatzdatum abzuspeichern.

23 TU Dresden - Institut für Bauinformatik Folie-Nr.: 23 Bauinformatik II, Softwareanwendungen 1; 5. Vorlesung Beispiel. 7. Externe Bauleiter sind mit Name, Vorname, Firmenname zu erfassen. Sie werden erst dann abgespeichert, wenn sie auf einer der Baustellen eingesetzt werden.. 8. Es ist weiterhin festzulegen a)Welche Berichte werden benötigt b)wie ist mit dem System zu arbeiten c)wer soll das System wie benutzen dürfen


Herunterladen ppt "TU Dresden - Institut für Bauinformatik Folie-Nr.: 1 Bauinformatik II, Softwareanwendungen 1; 5. Vorlesung Bauinformatik II Softwareanwendungen 1 5. Semester."

Ähnliche Präsentationen


Google-Anzeigen