DBMS BACKUP

Personen (SV#, Name| SV# = PS)

Dozenten (Spezialgebiet, Gehalt, SV# | SV# = PS, Dozenten.SV# ⊆ Personen.SV#)

Studenten (Matrikel#, SV# | SV# = PS, Studenten.SV# ⊆ Personen.SV#)

• Aus der 1:1 Beziehung wird in der Regel keine eigene Relation.
• Der Fremdschlüssel und die Attribute der Beziehung (AZ) werden an eine der beiden Relationen "angehängt". Es spielt dabei keine Rolle, welche Relation man nimmt. 

• Aus der 1:n Beziehung wird in der Regel keine eigene Relation.
• Der Fremdschlüssel und die Attribute der Beziehung (AZ) werden an die Relation "angehängt", die dem Entity-Typ an der mit n beschrifteten Kante entspricht.

• Aus n:m-Beziehungs-Typen wird eine zusätzliche Relation.
• Diese Relation enthält die Schlüssel der beteiligten Entity-Typen (Pi ) als Attribute und zusätzlich die Attribute des Beziehungs-Typen (AZ).

hören (MatNr, VorlNr | {Matrikelnummer, VorlNr} = PS,

hören.MatNr ⊆ Studenten.MatNr,

hören.VorlNr ⊆ Vorlesungen.VorlNr)

Beziehungs-Typ..Attribut ⊆ referenzierteTabelle.PS

Das Symbol «Teilmenge von» stellt sicher, dass nur Tupel referenziert werden, welche in der referenzierten 
Tabelle existieren. Dies ist später bei Abfragen aus der Datenbank relevant, um Fehler zu vermeiden.

• Fremdschlüssel referenzieren zwischen Tabellen.
• Dabei werden Tabellen durch ihre Primärschlüssel repräsentiert.
• Wird benötigt, um Konstrukte wie Beziehungen, Weak Entities, etc. zu übertragen.

Angestellte (ang-nr, name, gehalt, ort | ang-nr = PS)

Relationale Datenbanken basieren auf Tabellen (= Mengen von Tupeln).

➢ Z.B. innerhalb eines Unternehmens können ERM aufgrund von verschiedenen User Stories entworfen werden (User Story des Verkaufs, User Story der Logistik).

➢ Diese führt zu verschiedenen «Sichten» auf das unternehmensweite ERM.

➢ Es kann nun Sinn machen diese Sichten zu integrieren.

➢ Andererseits kann es auch Sinn machen verschiedene ERM für ein Unternehmen zu erlauben, um die Komplexität einzelner ERM zu reduzieren. 

1. Entitäts-Typen identifizieren.
2. Beziehungs-Typen ergänzen. 
3. Attribute ergänzen; Prüfung auf Sinnhaftigkeit (nur was nötig ist und das so eindeutig wie möglich),
4. Primärschlüssel festlegen (falls notwendig Schlüssel erstellen, z.B. eine ID).
5. Kardinalitäten ergänzen.
6. Nochmals durchgehen und auf Lücken, Dopplungen, Uneindeutigkeiten überprüfen.
7. Neue Grafik erstellen (Version 2); Iterationen sind unvermeidlich und wichtig für die Qualität des ERM.

Zur Vereinfachung können Generalisierung und Spezialisierungen durchgeführt werden.

Generalisierung: Statt bei den Entitäts-Typen Buch und Schuhe jeweils noch die Attribute «Artikel#», «Name» und «Preis» anzufügen kann ein «Über-Entitäts-Typ» «Artikel» erstellt werden. Für Buch und Schuhe werden dann lediglich die weiteren relevanten Attribute hinzugefügt (siehe Bild).

Spezialisierung: Aufteilung eines allgemeineren Typs in verschiedene Untergruppen. Entitätstyp «Artikel» enthält alle Attribute und ist mit den Entitätstypen «Bücher» und «Schuhe» mittels Pfeil verbunden.

➢ Werden im doppeltem Rechteck und doppelter Raute dargestellt (manchmal wird der Schlüssel auch nur gestrichelt dargestellt).

➢ Schwache Entitäten können über die Beziehung zu einer «normalen» Entität eindeutig definiert werden.

➢ Im Beispiel hat der Raum zwar die RaumNr als Schlüssel; diese RaumNr kann aber öfter als einmal vorkommen. Erst durch die Beziehung zu einem Gebäude mit einer eindeutigen GebNr wird auch der Raum eindeutig definiert.

Durch Rollen werden Rekursionen genauer erklärt. 

Beispiel:

➢ Alleine der Entitäts-Typ «Mitarbeiter» und der Beziehungstyp «managed» sagt noch nicht viel aus.

➢ Welcher Mitarbeitet «managed» hier wenn?

➢ Durch die Rollen «Chef» und «Sklave» werden die Beziehungen klarer.

➢ «Mitarbeiter, Chef» «managed» «Mitarbeiter, Sklave». Es werden also Hierarchiestufen abgebildet.

➢ Rollen werden an die Verbindungslinien geschrieben

Zwei Entitäten eines Entitätstypen werden miteinander verbunden.

Chen Notation: 1:1, 1:n, n:1, n:m (immer max. Angaben)

min/max-Notation: (0,1), (0,*), (1,1), (1,*) oder auch (1,5) 

1. Schlüssel: Eine Menge von Attributen (also eines oder mehrere), die eine Entität eindeutig identifiziert.

2. Schlüsselkandidat: Ein möglicher Schlüssel mit minimaler Anzahl Attribute. Also wenn es einen Schlüssel mit 2 Attributen und einen Schlüssel mit drei Attributen gibt, dann ist der Schlüssel mit 2 Attributen der Schlüsselkandidat.

3. Primärschlüssel: Ist ein beliebig ausgewählter Schlüsselkandidat, der zur eindeutigen Identifizierung nun benutzt wird. 

Besteht der Primärschlüssel aus mehreren Attributen (dies ist dann der Fall, wenn ein Attribut zur eindeutigen 
Identifizierung nicht ausreicht), wird er als zusammengesetzter Primärschlüssel bezeichnet.

4. Schlüsselattribut: Ist ein Attribut, das Teil mindestens eines Schlüsselkandidaten ist.

5. Nicht-Schlüsselattribute sind alle anderen. 

➢ Die Entitäten eines Entitäten-Typs müssen eindeutig benannt werden können.

➢ Hierzu dienen «Schlüssel».

➢ Diese bestehen aus einem oder mehreren Attributen.

➢ So kann das Attribut «Name» als Schlüssel genommen werden. «Thomas Müller» muss dann die Entität eindeutig beschreiben. Leider gibt es viele Thomas Müller.

➢ Oft macht es Sinn eine eindeutige ID zu vergeben und diese als Schlüssel zu verwenden

➢ Der Beziehungs-Typ steht grundsätzlich für die Beziehungen zwischen «Mitarbeiter» und «Projekt».

➢ Während eine Beziehung eine spezifische Verbindung zwischen z.B. Thomas Müller und Projekt X ist.

➢ Entitäten sind einzelne «Einheiten», z.B. der Mitarbeiter Thomas Müller.

➢ Entitäts-Typen dagegen stehen für den Typ «Mitarbeiter». 

Ein Attribut sollte Atomar sein, also z.B. das Attribut "Name" würde den Vor- und Nachnamen inkludieren. Darum lieber zwei Attribute erstellen, einer für Vorname und einer für Nachname.

➢ In einem Pflichtenheft werden Funktionalitäten und Absprachen für ein abgegrenztes Projekt festgehalten.

➢ Damit definiert dieses Dokument auch den Umfang eines Projekts für die beteiligten Partner.

➢ Bezogen auf den Bereich Datenbankmanagementsysteme geht es dabei hauptsächlich um die Frage, welche Daten auf welche Weise erfasst und abgelegt werden sollen um bestimmte Prozesse zielführend zu unterstützen.

➢ Änderungen am Pflichtenheft bedürfen der Zustimmung der beteiligten Partner. 

Am Anfang müssen zunächst die Anforderungen definiert werden.

➢ Dies kann durch Interviews, User Stories oder andere Methoden erfolgen.

➢ Wichtige Themen, die zu erfassen sind wären (je nach Gegenstand der Modellierung):

➢ Organisations-Einheiten (z.B. Abteilungen),

➢ Objekte (z.B. Mitarbeiter),

➢ Objektbeschreibung (Attribute),

➢ Beziehungen (zwischen Objekten),

➢ Beziehungsbeschreibung (Attribute),

➢ Prozesse und Use Cases (z.B. ein Buch ausleihen, einen Artikel verkaufen),

➢ Prozessbeschreibung (ausführlichere Beschreibung des Prozesses bzw. Use Cases). 

Ziel sind klare Dokumentationen wie: ein Pflichtenheft, Backlog Item oder ähnliches. 

1. Anforderungsanalyse.

2. Modellierung von Objekten und Verbindungen zwischen Objekten (ERM). Evaluierung des ERM.

3. Übertragung in Relationale Schemata (Von Grafik zu «Textform»)

4. Relationen und Tabellen – zweidimensionale Datenspeicherung. Weitere Optimierung.

5. Erstellung von Datenbank Schemata mit der Hilfe von DBMS und befüllen dieser Schemata mit Daten. 

➢ Beschreibung von Strukturen und Prozessen (z.B. in einem Unternehmen).

➢ Nachhaltige Datenspeicherung.

➢ Nachvollziehbare Datenmodelle für die Ablage der Daten.

➢ Möglichkeit Datenmodelle anzupassen, da wir wissen wie sie angelegt wurden.

➢ Abfragen auf Basis von Daten ausführen.