Woche 04, Datenbanken und Modellierung

Wir haben schon festgestellt, das Informationssysteme Daten unter anderem sammeln, speichern und verarbeiten. Dazu müssen brauchen sie allerdings eine Komponente, die es ihnen ermöglicht Daten so zu speichern, das sie möglichst wenig Platz einnehmen und gleichzeitig einen schnellen und effizienten Zugriff ermöglicht.

Datenbanken

• Datenbank (DB): Eine Datenbank ist eine möglichst redundanzfreie und struktirierte Sammlung von Daten, die es erlaubt, dass sie von mehreren Benutzern und Anwendungen gleichzeitig und effizient genutzt werden können.
• Datenbankmanagementsystem (DBMS): Sammlung von Programmen zum Erstellen und Verwalten einer Datenbank, die es mehreren Anwedungen gleichzeitig ermöglicht Daten zu speichern, extrahieren und zu manipulieren.

Redundante Daten bezeichnen hier unnötig oft gespeicherte Daten: der Name einer Person braucht nur in einer Tabelle gespeichert werden, andere Tabellen können diese dann einfach referenzieren.

Sicherheitskopien und Backups zählen innerhalb einer Datenbank NICHT als redundant!

Relationale Datenmodelle

• (DB) Tabellen: werden als Relationen bezeichnet, deren Spalten die Attribute einer Entität bestimmen. Zeilen werden als Tupel bezeichnet und stellen Datensätze dar, die die konkrete Entität beschreiben,

• Entität: repräsentieren eindeutig unterscheidbare Objekte, über die Daten gespeichert werden sollen,

• Entitätstyp: bezeichnet gleichartige Entitäten (Bsp.: (Schüler, Studenten, Lehrer, Dozenten) => Personen),

• Attribut: ist eine Eigenschaft, die eine Entität bestimmt. Der Wert dieser Eigenschaft muss atomar/unteilbar sein (Beispiel > Probleme in der Datenbank ).

• Primärschlüssel: (primary key) ist ein Attibut/-kombination, welche/s jeden Datensatz einer Relation eindeutig identifiziert.

• Fremdschlüssel: (foreign key) sind Attribut-/kombinationen, welche auf einen Primärschlüssel einer anderen Relation verweisen und so mehrere Relationen verbinden.

Entity Relationship Model (ERM)

Die Kardinalität lesen wir so: Ein Auftrag besteht aus m Artikeln, wärend jeder Artikel zu genau einem Auftrag gehört. (m ist dabei eine beliebige natürliche Zahl). Sind beide Enden beliebig, so sprechen wir von einer m:n Kardinalität.

Die Variablen können beliebig oft verwendet werden.

Normalformen von Tabellen

1. Normalform

Eine Relation ist in der ersten Normalform, falls es zu jedem Attribut nur genau einen Attributwert geben kann (aka. atomare Attribute).

Die gegebene Relation wäre zum Beispiel nicht in erster Normalform:

| _BestellID_ | Kunde            | Artikel          | Lieferdatum | Lieferant | Lieferadresse           |
| ----------- | ---------------- | ---------------- | ----------- | --------- | ----------------------- |
| 201         | Max Mustermensch | Google Pixel 10, | 2026-10-15  | Prime     | Berlin, Bahnhofstraße 1 |
|             |                  | Pixelbuds        |             |           |                         |

Denn: die Datenbank erfasst die bestellten Artikel nicht atomar. Dazu müssen wir jedem Artikel eine eigene Zeile geben:

| _BestellID_ | Kunde            | Artikel          | Lieferdatum | Lieferant | Lieferadresse           |
| ----------- | ---------------- | ---------------- | ----------- | --------- | ----------------------- |
| 201         | Max Mustermensch | Google Pixel 10, | 2026-10-15  | Prime     | Berlin, Bahnhofstraße 1 |
| 202         | Max Mustermensch | Pixelbuds        | 2026-10-15  | Prime     | Berlin, Bahnhofstraße 1 |

2. Normalform

Eine Relation befindet sich in der zweiten Normalform, falls alle Attribute des Primärschlüssels nötig sind um die Nichtschlüsselattribute zu beschreiben.

Die gegebene Relation wäre zum Beispiel nicht in zweiter Normalform:

| _BestellID_ | Kunde            | Artikel          | Lieferant | Lieferadresse           |
| ----------- | ---------------- | ---------------- | --------- | ----------------------- |
| 201         | Max Mustermensch | Google Pixel 10, | Prime     | Berlin, Bahnhofstraße 1 |
| 202         | Max Mustermensch | Pixelbuds        | Prime     | Berlin, Bahnhofstraße 1 |

Denn: Artikel und Lieferant könnten unter Umständen nachträglich bearbeitet werden müssen. Das funktioniert effizienter, wenn nur ein Eintrag geändert werden muss und der Rest durch einen Foreign Key auf den neuen Wert linkt.

| _BestellID_ | Kunde | Artikel | Lieferant |
| ----------- | ----- | ------- | --------- |
| 201         | 1     | 1       | 1         |
| 202         | 1     | 2       | 1         |

| _KundenID_ | Kunde            | Adresse                 |
| ---------- | ---------------- | ----------------------- |
| 1          | Max Mustermensch | Berlin, Bahnhofstraße 1 |

| _ArtikelID_ | Name                              |
| ----------- | --------------------------------- |
| 1           | Google Pixel 10                   |
| 2           | Pixelbuds Berlin, Bahnhofstraße 1 |

| _LieferantID_ | Name  |
| ------------- | ----- |
| 1             | Prime |

3. Normalform

Eine Relation befindet sich in der dritter Normalform, falls alle Nichtschlüsselattribute unabhängig voneinander sind.

Die gegebene Relation wäre zum Beispiel nicht in dritter Normalform:

| MitarbeiterID | Name   | AbteilungsID | AbteilungsName | Abteilungsleiter |
| ------------- | ------ | ------------ | -------------- | ---------------- |
| 1             | Müller | 10           | Entwicklung    | Schmidt          |
| 2             | Müller | 10           | Entwicklung    | Schmidt          |
| 3             | Weber  | 20           | Vertrieb       | Fischer          |

Denn: AbteilungsName und AbteilungsLeiter hängen von AbteilungsID ab, nicht direkt vom Primärschlüssel MitarbeiterID. Die Lösimg ist auch hier wieder das aufteilen der Relation in eine Mitarbeiter- und eine Abteilungsrelation.

SQL