update

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

@@ -67,3 +67,90 @@
     - 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"