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

# Semantische Datenmodellierung und Relationenmodell
## Lifecycle von Informationssystemen
![image_644.png](image_644.png)

### 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
- ![image_645.png](image_645.png)

### 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](#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
![image_646.png](image_646.png)


## 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
  - ![image_647.png](image_647.png)
    - 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
- ![image_648.png](image_648.png)

### 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](#fremdschl-ssel-foreign-key)

#### Referentielle Integrität
- Zu jedem Zeitpunkt Referenz eines PK durch Wert einer FK-Spalte gewährleistet ist
- Verletzung:
  - ![image_649.png](image_649.png)


## Transformation [UML Klassendiagramm](UMLKlassenDiagramme.md) → Relationenmodell
### Wiederholung UML Klassendiagramme
![image_650.png](image_650.png)

### Unterschiede zum Relationenmodell
- Datentypen des UML-Klassendiagramms werden auf den ähnlichsten Datentyp im RM abgebildet
  - oft vom konkreten [DBMS](00_db_intro.md#datenbank-managementsystem-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:
  - ![image_651.png](image_651.png)
  - ![image_652.png](image_652.png)
- 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
![image_653.png](image_653.png)

#### Komposition
![image_654.png](image_654.png)

#### 1:n-Assoziation
![image_655.png](image_655.png)

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

![image_656.png](image_656.png)

#### Minimalkardinalität 1 → "Richtung 1"
![image_669.png](image_669.png)
![image_670.png](image_670.png)

```sql
    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](#minimalkardinalit-t-1-richtung-1)
- hier möglichkeit für `Abteilungsnr = null`

```sql
    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)

#### Umwandlungsregel n:m Assoziation
##### 1..*:1..* Assoziation {id="1-1-assoziation_1"}
![image_672.png](image_672.png)
- 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](#umwandlungsregel-n-m-assoziation)
- Hauptnavigationsrichtung der Anwendung entscheidet

##### Assoziation mit sich selbst (Stückliste)
> Selbstreferenzierende n:m Assoziation

###### Beispiel Stückliste Fahrrad
![image_673.png](image_673.png)
![image_674.png](image_674.png)
-  man verfährt wie bei der n:m Beziehung durch Einfügen einer Assoziationsklasse
  - ![image_675.png](image_675.png)
- um Fahrradstückliste zu implementieren sind also 2 Tabellen notwendig:
  - | Teileliste                      | Stückliste                      |
    |---------------------------------|---------------------------------|
    | ![image_676.png](image_676.png) | ![image_677.png](image_677.png) |


### Abbildung Vererbungshierarchien
> Subtyp erbt mindestens PK des Supertyps

#### Variante 1: Nur Spezialisierungen als Tabellen
![image_891.png](image_891.png)

#### Variante 2: Super- und Subtypen als Tabellen
![image_892.png](image_892.png)

#### Variante 3: Super- und Subtypen als Tabellen mit Redundanz
![image_893.png](image_893.png)

#### Variante 4: Supertyp als Tabelle mit Typ-Attribut
![image_894.png](image_894.png)

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