zusammenfassungen/Writerside/topics/04/Datenbanken/01_semantischeDatenmodellierungUndRelationenmodell.md

Semantische Datenmodellierung und Relationenmodell

Lifecycle von Informationssystemen

1. Planungsphase

• Informationsbedarf der zu untersuchenden Organisation ermitteln
• Informationsstrategie erarbeiten

Beispiel: CRUD-Matrix (Create - Read - Update - Delete)

• Ergebnis: Informationsprojekte
  • Zusammenfassung von Funktionen, die gleiche Informationsobjekte verwenden
  • Funktionsbereiche sind definiert
    • strukturieren Organisationsbereich
• 

2. Analysephase

• Informationsprojekte aus Planung weiter detaillieren
  • Daten- und Prozesssicht
• durchgehende Konsistenz zwischen Daten- und Prozessmodell!
• Ergebnis: Datenmodell (UML) und Prozessmodell (Analysesicht)

3. Designphase

• Berücksichtigung des Datenbankmodells, Implementierungsplattform (DBMS)
  • Implementierung von Beziehungen
    • Definition von Referenzen
  • Festlegung der Datentypen (DBMS-spezifisch)
• CASE-Tools (computer aided software engineering)
  • generieren Datenmodelle für 3. aus Datenmodellen aus 2.
  • umgekehrt: Round-Trip-Engineering
• Ergebnis:
  • Datenmodell
    • z.B. Relationenmodell, ergänzt um Datentypen des Ziel-DBMS beim Einsatz von RDBMS
  • Prozessmodell der Designsicht

4. Implementierungsphase

• Güte von Analyse und Design zeigen sich in relativ problemloser Implementierung
• RDBMS: Implementierung DB-Schema durch deklarative Sprachkomponente von SQL (SQL DDL)
• CASE-Tools: SQL-Skript direkt aus Relationenmodell generieren

Beispiel Phasen des DB-Entwurfs

Relationenmodell

• Grundlage des von E. F. Codd vorgestellten RDB-Modells bildet der Relationenbegriff aus Mathe
  • eine n-stellige (n-äre) Relation in einer Menge M ist eine Beziehung, die zwischen je n Elementen aus M besteht oder nicht
    • vorstellbar als Menge von Tupeln gleicher Länge n
      • auch n-Tupel genannt
  • 
    • Spalten - Attribute
    • einzelne Zeilen - Tupel / Datensätze

Definitionen Relationenmodell

• Eine n-stellige Relation R ist definiert als Untermenge des kartesischen Produkts der Wertebereiche der zugehörigen Attribute A_1, A_2, ..., A_n
  • R(A_1, A_2, ..., A_n) ⊆ W(A_1) x ... x W(A_n)
  • Beispiel: Student (MatrNr, Name, Geb.) ⊆ integer x string x date
• Ein Element der Menge R wird als Tupel bezeichnet → t ∈ R
  • Beispiel: t= (123456, 'Schmidt', 30.01.2014)
• Ist der Wert eines Attributs in einem Tupel unbekannt/nicht vorhanden
  • NULL-Wert
  • kann für jedes Attribut festgelegt werden, ob erlaubt ist oder nicht
• Schlüssel p minimale Menge von Attributen
  • Werte identifizieren Tupel eindeutig
  • Wert von p bestimmt die Attributwerte aller anderen Attribute des Tupels eindeutig
    • Man kann (im zusammengesetzten Fall) kein Attribut aus p entfernen, ohne dass das verletzt wird
• 

Schlüssel

Primärschlüssel (primary key)

• Wird aus Liste der Schlüsselkandidaten ausgewählt
• Graphische Notation: in Attributliste unterstreichen

Synthetische vs. semantische Schlüssel

	Synthetisch	Semantisch
Definition	einzelnes Schlüsselattribut, Wert hat ggf. keine Bedeutung	Menge von Attributen, deren Wert eine Bedeutung hat
Beispiel	autoincrement-Datentyp	ISBN-Nummer

Fremdschlüssel (foreign key)

• für jeden Wert vom FK in R_1 muss ein gleicher Wert des PK in einer anderen Relation R_2 oder eines Tupels in R_1
• können NULL sein (falls nicht Teil des PK)

Grundregeln Relationenmodell

1. Jede Zeile (Tupel) ist eindeutig und beschreibt Objekt
2. Reihenfolge der Zeilen ist ohne Bedeutung
3. Reihenfolge der Spalten ist ohne Bedeutung
   • Tragen eindeutigen Namen
4. Jeder Datenwert einer Relation ist ein atomares Datenelement (vgl. 1.NF)
5. Alle bedeutungsvollen Informationen sind ausschließlich durch Datenwerte ausgedrückt
6. Es existiert ein Primärschlüssel (und ggf. weitere Schlüsselkandidaten)

Integritätsbedingungen

• Abhängigkeiten zwischen Attributen
  • innerhalb und zwischen Relation(en)
• Abhängigkeit innerhalb nennt man funktionale Abhängigkeit
  • Spezialfall: Primärschlüssel
• Abhängigkeit zwischen Relationen: Fremdschlüssel

Referentielle Integrität

• Zu jedem Zeitpunkt Referenz eines PK durch Wert einer FK-Spalte gewährleistet ist
• Verletzung:
  • 

Transformation UML Klassendiagramm → Relationenmodell

Wiederholung UML Klassendiagramme

Unterschiede zum Relationenmodell

• Datentypen des UML-Klassendiagramms werden auf den ähnlichsten Datentyp im RM abgebildet
  • oft vom konkreten DBMS abhängig
• Richtung von Assoziationen bleibt unberücksichtigt
• Multiplizitäten werden nicht vollständig abgebildet
  • Man spricht von Kardinalitäten
  • Angabe wird vereinfacht
    • 0..1 , 1..1, 1 → 1
    • 0..*, 1..* → n oder m
    • * auf beiden Seiten → n:m

Abbildung von Klassen und Attributen

• Klassen → Tabellen (Relationen)
• Attribute → Spalten
• system-spezifische Datentypen für Spalten werden ergänzt
• Beispiel:
  • 
  • 
• Primärschlüssel
  • sind im UML nicht vorhanden
  • müssen definiert / hinzugefügt werden
• Fremdschlüssel
  • referenzieren Tupel über Relationen hinweg
  • UML zeigt direkt auf andere Objekte
    • geht mit RM nicht :(

Aggregation

Komposition

1:n-Assoziation

1:1 Assoziation

1. FK bei R1
2. FK bei R2
3. FK bei R1, R2
4. Bildung von R3 mit FK auf R1, R2
   • macht Sinn, wenn 0..1:1..0 wenn beide Relationen groß, aber dünn verbunden sind

Minimalkardinalität 1 → "Richtung 1"

    ABTEILUNGSNR INT4 not null,
    constraint FK_MA_ZUGEH_ABT foreign key (ABTEILUNGSNR)
                 references ABTEILUNG (ABTEILUNGSNR)
                 ON delete restrict on update restrict

Minimalkardinalität 0 → "Richtung 1"

• nahezu identisch zu 1...1
• hier möglichkeit für Abteilungsnr = null

    ABTEILUNGSNR INT4 null,
    constraint FK_MA_ZUGEH_ABT foreign key (ABTEILUNGSNR)
                 references ABTEILUNG (ABTEILUNGSNR)
                 ON delete restrict on update restrict

Minimalkardinalität 0 bzw. 1 → Vielfalt

• 1. NF erlaubt es nicht, da Collection-Datentypen nicht erlaubt sind
  • vor allem für Fremdschlüsselspalten
• wenn 0/1..* → allein über constraints nicht implementierbar
  • kann man dann über Trigger machen (Kapitel 6)

→ Umwandeln in n:m Assoziation

Umwandlungsregel n:m Assoziation

1..:1.. Assoziation

• Einfügen einer neuen Tabelle, welche aus den anderen beiden Tabellen jeweils einen Fremdschlüssel hat
  • Primärschlüssel jeweils als concatenated key einfügen
    • dann muss er immer mit drin sein
  • dadurch kann jede Zeile aus beiden Tabellen auf mehrere aus der anderen verlinken
• geht dann auch mit >2 Tabellen

0..:0.. Assoziation

• Vier Alternativen
  1. FK bei R1
  2. FK bei R2
  3. FK bei R1 und R2
  4. m:n Relation einfügen wie hier
• Hauptnavigationsrichtung der Anwendung entscheidet

Assoziation mit sich selbst (Stückliste)

Selbstreferenzierende n:m Assoziation

Beispiel Stückliste Fahrrad

• man verfährt wie bei der n:m Beziehung durch Einfügen einer Assoziationsklasse
• 
• um Fahrradstückliste zu implementieren sind also 2 Tabellen notwendig:

  • Teileliste	Stückliste

Abbildung Vererbungshierarchien

Subtyp erbt mindestens PK des Supertyps

Variante 1: Nur Spezialisierungen als Tabellen

Variante 2: Super- und Subtypen als Tabellen

Variante 3: Super- und Subtypen als Tabellen mit Redundanz

Variante 4: Supertyp als Tabelle mit Typ-Attribut

Nicht-Atomare Attribute

• Arrays auslagern
  • neue Klasse
  • Zeile duplizieren

Normalisierung

1. NF

• Alle Attribute sind atomar
  • keine Arrays, Listen, Objekte

Anomalien

Einfügeanomalie

• Einfügen eines neuen Tupels ist nicht möglich, da kein Wert für ein Attribut vorhanden

Änderungsanomalie

• Änderung eines Wertes in einem Tupel erfordert Änderung in mehreren Tupeln
  • Gefahr der Inkonsistenz

Löschanomalie

• Löschen eines Tupels führt zum Verlust von Informationen, die nicht gelöscht werden sollten
  • z.B. wenn nur ein Attribut gelöscht wird, aber andere Attribute noch vorhanden sind

2. ΝF

• ist in 1. NF
• Jedes Nicht-Schlüsselattribut ist voll funktional abhängig vom Primärschlüssel
  • d.h. es gibt keine partiellen Abhängigkeiten
  • bspw:
    • Schüler, Klasse, Klassenlehrer (Klassenlehrer schlecht, da er nur von Klasse abhängt)

3. NF

• ist in 2. NF
• Jedes Nicht-Schlüsselattribut ist transitiv abhängig vom Primärschlüssel
  • d.h. es gibt keine transitiven Abhängigkeiten
    • A→B B→C :(

Denormalisierung

• Normalisierung führt zu vielen Tabellen
  • kann Performance beeinträchtigen
    • Nur, falls das tatsächlich ein Problem ist denormalisieren