---
title: Datenmanagement
description: View the slide with "Slide Mode".
---
<style>
.reveal {
font-size: 28px;
}
</style>

## LV-Ziele

* Verschiedenen Datenbankarchitekturen und Funktionsprinzipien.
* Entity-Relationship(ER)-Modelle und von relationalen Datenmodelle und deren Sprachelemente.
* Erstellung eines ER-Modells auf der Basis eines Teilausschnitts der
unternehmerischen Realität ein dementsprechendes ER-Modell erstellen.
* Überführung in ein relationales Datenmodell und Implementation mit SQL-Befehlen.

----

## LV-Ziele 2

* Normalisierung ein gegebenes relationales Datenmodell bis zur 3. Stufe.
* Datenaustauschformate inklusive deren Notations- und Speicherform sowie deren
Einsatzbereich und Datenübertragungsprotokolle in verteilten Systemen.
* Beschreibung von Softwarekompenenten und -architekturen
sowie deren Einsatzbereich sowie Funktionalität erläutern.

---

# Datenbanken

Referenz: UTB3_Datenanken_02_Ueberblick

---

## Grundlegende Begriffe

1. Datenbank (DB): geordnete, selbstbeschreibende Sammlung von Daten, die in Beziehung stehen.
2. Datenbanksystem (DBS): DB + Datenbank Managemensystem (DBMS) + Kommunikationsschnittstelle.

----

<!-- .slide: style="font-size: 24px;" -->
## <span style="font-size: var(--r-heading2-size);">Grundlegende Begriffe 2</span>

| Tabelle | Relationale Datenbank | Entity-RelationshipModell (ERM) | Unified Modeling Language (UML) |
| ----------------------------- |:--------------------------------------------:| ------------------------------- |:-------------------------------- |
| Wertebereich (Domäne, Domain) | --""-- | --""-- | --""-- |
| Kopfzeile | Relationstyp Relationsformat Relationsschema | Entitätstyp | Klasse |
| Spaltenüberschrift | Attribut | Attribut | Attribut |
| Inhalt | Relation | Entitätsmenge | Objektmenge Instanzmenge |
| -- | Fremdschlüsselbeziehung | Beziehung | ASsoziation |
| Zeile | Tuple | Entität | Objekt, Instanz |
| Zeile | Attributswert | Attributswert | Attributswert |

---

## "Arten" von Datenbanken

1. relationale DB: Daten liegt in Tabellen
* Pro: schnell
* Contra: komplexe Objektstrukturen nicht intuitiv darstellbar (z.B. Eltern-Kind, Student-Jahrgang, ...)
3. objektorienteierte DB: Daten in form von Objekten
* Pro: Objektsturkturen intuitiv darstelbar
* Contra: langsam
3. objketrelationale DBMS: verbindung der Vorteile von relationalen und objektorientierten DBs

---

## Anforderungen einer Datenbank

1. Persistenz: Daten langfristig speichern
2. CRUD (Create, Read, Update, Delete): meist mit Schwerpunkt auf Read
3. Verwaltung des Datenschemas (Kontext/Relationen) der Daten

---

## Datenbankdesign

1. Konzeptionelle Modelle => Logische Struktur => Entity-Relationship-Modell => Welche Daten will ich darstellen/speichern.
2. Implemantative Modelle => Speicherstruktur => relationales Datenbankmodell => Wie will ich die Daten darstellen/speichern.

Beide Modelle sind meistens Notwendig und Sinnvoll!

---

# Datenbankentwurf

*Referenz: UTB3Datenanken03Entwurf*

Datenbankentwurf ist ein Teil der Wirklichkeit, welche für die betriebliche Informationsverbarbeitung wichitg ist, zu beschreiben:
> A database represents some aspect of the real world, sometimes
> called the miniworld or the universe of discourse (UoD).

----

### Früher

siehe ANSI SPARC

### Heute (semantische Modellierung)


----

### Unterschiede

Das **Was** ist abstahiert und aus Managementsicht entscheidened.
Das **Wie** besser Experten zu überlassen ist.

Bei ANSI SPARC ist dies nicht gut getrennt --> in der semantischen Modellierung gut getrennt (Was: ER-Modell, Wie: relationales Schema).

--> das sematische Modell erleichtert Kommunikation zwischen Management und IT (für Laien lesbar und für IT eindeutig)

---

## Gutes vs Schlechtes Datenbankkonzept

Bei einem guten Datenbankkonzept geht es nicht um Entities, Tabellen, etc. sondern um reale Objekte, Informationen, Zusammenhänge, etc.
**Nicht zu technisch Denken!** und auch inhaltich abklären welche Daten zu erfassen sind.
#### User werden kreativ wenn sie:
1. Daten nich angeben können obwohl sie wollen (Extrainformationen)
2. Daten nicht erforderlich sind (zuviel Information notwendig)
3. Daten fehlerhaft, doppel sind (unsinnige Informationen)

----

## Wie erstellt man ein sematisches Modell?

Entity-Relationship-Modelle nicht standardisiert --> zum Teil in gleicher Firma unterschiedliche "Dialekte"
--> Unified Modeling Language (UML) Diagramme als stndardisierte Lösung
* Klassendiagramme
* Objektdiagramme

---

## sematische Modellierung vorgehen

1. Daten auf klar idenifizierbare und unterscheidbare **Objekte** (sowohl der realität als auch des Denkens) durchsuchen --> Entities/Objekte
2. Untersuchung der **Beziehungen** zwischen diesen Objekten --> Relationship/Association
* Kann eine Zahl sein z.B. ein Kurs hat mindestens 5 und maximal 12 Teilneihmer (Kardinalität)
* aber auch ob eine Beziehung vorhanden ist z.B. ein Student kann muss aber keinen Abschluss haben (Optionalität)
3. Untersuchung der **Eigenschaften** dieser Objeken
* **identifizierende** Eigenschaften vs sonsitige Eigenschaften
* Art der Eigenschaft (Typ --> z.B. Text, Zahl)
* Wertebereich der Eigenschaft (z.B. Noten nur zwischen 1-5)

----

## sematische Modellierung vorgehen 2

* zwei Betrachtungsebenen
* einzelne Objekte (Exemplar)
* Gruppe von Objekten (Typen, Klassen)
* Entity Typen sind eine Sammlung von Entties mit den selben Attributen
* Alle Entities eines Types haben zwar die gleichen Attribute aber besitzen ihre eigene Werte (z.B. Alter)

----

## sematische Modellierung vorgehen 3


----

## sematische Modellierung vorgehen 4


---

## ER-Modellierung

* Entity Typen werden zu Tabellen
* Entities werden zu Zeilen (bzw. deren Werte werden zeilenweise eingetragen)

----

## ER-Modellierung 2


----

## ER-Modellierung 3

1.  sind Entities (Objekte)
2.  sind Relationen (Beziehungstypen)
3.  sind Attribute (Eigenschaften)
4.  sind Kardinalitäten (Beziehungen)
5.  Generalisierung / Spezialisierung

----

## ER-Modellierung 4 / Kardinalitäten

1. Chen: Wieviele Objekte sind einem Objekt höchstens zugeordnet
Eine Bestellung entöhlt viele (n) Bestellposten.<br>
Ein Bestellposten ist einer Bestellung zugeordnet.
1. 1:1 => Ein Objekt is einem anderem zugeordnet
2. 1:n => Mehrere Objekte sind einem Objekt zugeordnet
4. n:1 => Ein Objekt ist mehreren Objekten zugeordnet
5. n:m => Mehrere Objekte sind mehreren Objeketen zugeordnet
2. Schlageter-Stucky: Mit wieviel Objeketen steht ein Objekt in Beziehung
Ähnlich wie Chen nur Leserichtung "umgedreht"<br>
Erlaubt Auflösung von komplexeren Beziehungen
| Kürzel | Bedeutung | Beispiel |
| -------- | -------- | -------- |
| k | k-mal | 5 |
| [n,m] | mindesten n, maximal m | [2,6] |
| * | 0 oder mehr | 8 |
| + | 1 oder mehr | 1 |
| c | 0 oder 1 | 0 |

3. ISO: Mit wie vielen OBjekten steht ein Objekt minmal und maximal in Beziehung
4. Modified-Chen (MC): wie Chen nur mit extras :smiley:
1. c => 0 oder 1
2. m => mulitple

Der unterschied ist, dass 1 in MC bedeutet mindestens 1<br>
| Chen | Modified-Chen |
| --- | --- |
| 1:1 | c:c |
| 1:N | c:mc|
| 1:N + total participation| 1:mc|
| M:N | mc:mc|
| total part. + 1:1 | c:1|
| total part. + 1:1 + total part.| 1:1|
|total part. 1:N + total part. | 1:m|
|total part. + M:N | mc:m |
|total part. + M:N + total part.| m:m|
5. Chen mit Min-Max Kennzeichnung (für Vorlesung)
Mischung aus Chen und ISO + '0' für keins oder mehrere und '1' für eins oder mehr
Eine Bestellung enthält mehrere Bestellposten (1:n) und ein Bestellposten ist in einer Bestellung enthalten (1:1). Eine Bestellung enthält mindestens 1 Bestellposten und ein Bestellposten ohne Bestellung gibt es auch nicht!
Ein Student kann Bücher ausleihen muss aber nicht (0:n) und ein Buch kann von einem Studenten ausgeliehen sein muss aber nicht (0:1).
6. Crow's Foot / Martin Notation: grafische Darstellung einer Notation

---

## Unified Modeling Language (UML)

Standardisierte Diagramme um Kommunikation zu vereinfachen.

---

# Datenbankschema

Beschreibt die Struktur und Art der Daten einer Datenbank.

1. Welche Tabellen gibt?
2. Für jede Tabelle: Welche Spalten gibt es?
3. Für jede Spalte:
4. Welcher Datentyp?
5. Nullable?
6. Defaultwert?
7. Constraints (Einschrenkung des Wertebereichs)
5. Primärschlüssel?
6. Fremdschlüssel?
7. Indizes?

---

## Architektur eines DBMS


----

## Architektur eines DBMS - Einschichtig

* Alles auf einem PC (z.B. SqlLite)
* Im Unternhemensumfeld oft nicht sinnvoll (z.B. wegen Wartung, Skalierbarkeit, ...)

----

## Architektur eines DBMS - Zweischichtig

Unterscheidung zwischen Intelegentem Server oder Client

----

### Architektur eines DBMS - Zweischichtig - Intelligenter Client


* Daten müssen nur einmal Übertragen werden, Bearbeitung kann selbständig erfolgen
* Client benötigt entsprechende Resourcen (Rechenleistung) um komplexe Verbeitungen durchzuführen

----

### Architektur eines DBMS - Zweischichtig - Intelligenter Server


* Clients benötigen nicht viel Rechenleistungs selbst für komplexe Verarbeitungen
* Server muss basierend auf den Usern Skaliert sein (oft Engpass)

----

### Architektur eines DBMS - Zweischichtig - Hybride Lösung

Server und Client teilen sich die Verarbeitung basierend auf den Anforderungen <br> so können rechenintensive Auswertungen z.B. Täglich in der Nacht auf dem Server durchgeführt und dann gecached dem Client übergeben werden <br> kleiner Auswertungen aber direkt vom Client beim Verwenden erstellt werden+

----

## Architektur eines DBMS - n-schichtig

Auftrennung der Layer zum teil mit extra Redundanz.

---

# Normalisierung_Transkation

---

## ACID

1. Atomicity: bei Teilfehler schläft gesamte Transaktion fehl
3. Consitency: die Datenbank ist/kann jederzeit zu einem konsitenten Zustand überführt werden
4. Isolation: Änderungen sind erst nach Abschluss der Transaktion (für andere) sichtbar
5. Durability: Daten können selbst bei fehlern nicht verloren gehen

----

## Probleme ohne ACID

1. Lost Update
2. Dirty read
4. Non-Repeatable read

----

## Transaktionszustädne

* Active: Anfangszustand, Transaktion bleibt in diesem Zustand solange sie ausgeführt wird
* Partially commited: nach letzter Anweisung
* Commited: bei erfolgreicher Durchführung
* Terminated/Aborted: Abschluss der Transaktion

---

# SQL

Abfragesprache für Datenbanken
Basis ist relationale Algebra
Grundoperationen:
* Vereinigungen (Union)
* Differenz
* Auswahl
* Projektion
* Kreuzprodukt

Operationen im rel. Algebra erzeugen immer selbst Relationen --> einfach verschachtelbar.

----

## SQL Grundoperationen


----

## Views

* Views sind virtuelle Tabellen ereugt aus `SELECT`-Statements. <br>
* Erleichtern Rechtevergabe, da z.B. ein User nur zugriff auf einen View haben kann.
* Könenn Dynmisch (bei Abfrage dynamisch erzeugt) als auch Statisch (vorbereitet und Abgespeichert) sein basierend nach dem Aufwand
* Datenänderungen über Views können problematisch sein (nur wenn DBMS von View die Transformation zurück zu den Tabellen erstellen kann)
*

----

## Stored Procedure

* Unterprogramme die in einer DMBS laufen
* Programmiersprache ist Abhängig vom DBMS Hersteller (z.B. T-SQL/.NET bei Microsoft, PL/SQL oder Java bei Oracle)
* Pro:
* Ausführung direkt auf dem DB-Server (Netzwerkvolumen niedrig)
* selbst komplizierte Prozeduren können mit einem `CALL`-Befehl ausgeführt werden
* Zugriffskontrolle
* Zugriff auf API des RDBMS
* detailierte Eingriffe in Verarbeitungsprozesse möglich

---

# SQL

---

# Big Data