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"