Nachdem beim letzten Mal das Erstellen des
Entity-Relationship-Modells Thema war, widmen wir uns in der
neunundvierzigsten Episode des Anwendungsentwickler-Podcasts den
Schritten bei der Erstellung eines Tabellenmodells. TL;DR Ich zeige
dir, wie du ein ER-Modell in ein relationales Tabellenmodell
überträgst: Entitätstypen werden zu Tabellen, deren Spalten einen
Datentyp erhalten und festlegen, ob NULL erlaubt ist. Bei
1:n-Beziehungen gehört der Fremdschlüssel auf die n-Seite; für
m:n-Beziehungen legst du eine Zuordnungstabelle an. Für deine
Prüfung gehören klar gekennzeichnete Schlüssel und die dritte
Normalform dazu, während du bei zusammengesetzten Schlüsseln prüfen
musst, ob sie jeden Datensatz eindeutig bestimmen. Kapitelmarken
[00:00:01] Einstieg ins Tabellenmodell [00:00:31] Relationale
Datenbanken in Geschäftsanwendungen [00:02:02] Tabellen, Relationen
und Beziehungen [00:03:36] Fremdschlüssel und Kardinalitäten
[00:04:54] Primärschlüssel und Fremdschlüssel kennzeichnen
[00:05:40] Spalten und Datentypen [00:06:55] Datentypen für die
Prüfung [00:08:24] NULL und Pflichtfelder [00:09:48]
Tabellenmodelle zeichnen [00:11:07] Vom ER-Modell zum
Tabellenmodell [00:12:14] Entitätstypen als Tabellen übernehmen
[00:14:11] 1:1-Beziehungen abbilden [00:16:29] Fremdschlüssel bei
1:n-Beziehungen [00:18:26] Zuordnungstabellen für m:n-Beziehungen
[00:19:51] Fachliche Namen für Zuordnungstabellen [00:21:40]
Zusammengesetzte Primärschlüssel [00:22:18] Beziehungsattribute und
wiederholte Zuordnungen [00:24:05] Anonyme IDs als Primärschlüssel
[00:26:15] Schritte beim Übertragen im Überblick [00:27:15]
Zusätzliche Angaben in Prüfungsdiagrammen [00:30:23] Dritte
Normalform in der Prüfung [00:31:28] Bewusst denormalisieren für
schnellere Abfragen [00:32:24] Prüfungsfrage zu Beziehungen und
Normalformen [00:33:32] Literatur und Übungsaufgaben [00:35:26]
Seven Databases in Seven Weeks [00:36:23] Einzelprojekt und
Teilprojekt beim Abschlussprojekt [00:37:08] Erfahrungen aus der
Spieleentwicklung [00:37:55] Kontakt und Newsletter [00:38:51]
Ausblick auf Fehler im Projektantrag Inhalt Modellierung mit
Tabellenmodellen Welche Bestandteile hat ein Tabellenmodell?
Tabellen (Relationen) mit Name, Spalten, Datentypen; Beziehungen
mit Kardinalitäten; Primär- und Fremdschlüssel werden
gekennzeichnet (z.B. mit PK und FK). Wie kommt man vom ER-Modell
zum Tabellenmodell? Jeder Entitätstyp wird zu einer Tabelle.
Attribute werden zu Spalten dieser Tabellen. Datentypen der Spalten
bestimmen. m:n-Beziehungen durch Fremdschlüssel in Zwischentabellen
auflösen. Ggfs. Attribute der Beziehung als Spalten ergänzen. 1:n-
und 1:1-Beziehungen durch Fremdschlüssel auflösen. Bei 1:1 ist die
Position des Fremdschlüssels egal, bei 1:n muss er in die
n-Tabelle. Tipps zur Prüfung und Praxis Immer alle Informationen
einzeichnen, auch wenn sie nicht explizit gefragt sind. Drei
Datentypen reichen: VARCHAR, NUMBER und DATE. Wenn eine Tabelle
einen zusammengesetzten Schlüssel mit mehr als 2 Attributen hat,
führe einen anonymen Primärschlüssel ein. Achte auf ein
normalisiertes Modell in dritter Normalform (die weiteren
Normalformen sind irrelevant). Du solltest trotzdem erklären
können, wann man von der Normalisierung abweichen kann/sollte. Die
1:n-Beziehungen werden in der 3. Normalform aufgelöst, die
m:n-Beziehungen in der 2. Literaturempfehlungen Einsteigern ins
Thema Datenmodellierung empfehle ich die Artikelreihe von Dr.
Veikko Krypczyk im Entwickler Magazin. Der erste Artikel ist frei
verfügbar: Datenbanken: Grundlagen und Entwurf - entwickler.de. Im
Handbuch für Fachinformatiker ist das komplette Kapitel 13 dem
Thema Datenbanken gewidmet. *(direkt beim Rheinwerk-Verlag
bestellen*) Am besten übst du die Datenbankmodellierung mit
Prüfungsaufgaben der IHK. Dazu empfehle ich die Prüfungstrainer für
die Abschlussprüfung*. * Ein tolles Buch, um einmal über den
Tellerrand der relationalen Datenbanken hinweg zu schauen, ist
Seven Databases in Seven Weeks*. Eine relationale Datenbank
(PostgreSQL) wird vorgestellt, aber der Rest des Buches behandelt
die unterschiedlichsten Typen von (NoSQL-)Datenbanken und ihre
Besonderheiten - gerade auch ber der Datenmodellierung. Absolut
lesenswert für jeden Softwareentwickler. * Links Permalink zu
dieser Podcast-Episode RSS-Feed des Podcasts Relationale
Datenbanken - Häufige Fragen im Fachgespräch -
Anwendungsentwickler-Podcast #17 Normalisierung - Häufige Fragen im
Fachgespräch - Anwendungsentwickler-Podcast #18 SQL - Häufige
Fragen im Fachgespräch - Anwendungsentwickler-Podcast #19
Zusammenfassung Tabellen und ihre Beziehungen Als
Fachinformatiker:in für Anwendungsentwicklung arbeitest du häufig
an Geschäftsanwendungen, deren Daten in relationalen Datenbanken
liegen. Beispiele aus dem Unternehmensumfeld sind Oracle und
Microsoft SQL Server. Auch DB2 gehört dazu. Eine Relation
bezeichnet im Tabellenmodell eine Tabelle. Darin stehen
zusammengehörige Daten, etwa die Attribute einer Person.
Beziehungen zwischen Tabellen zeichnest du als Verbindungslinien
ein und versiehst sie mit Kardinalitäten. Im Tabellenmodell bilden
Fremdschlüssel diese Beziehungen ab. Zu jeder Spalte gehört
außerdem ein Datentyp, damit sich aus dem Modell eine lauffähige
Datenbank erstellen lässt. Was du in eine Tabelle einträgst Eine
Tabelle zeichnest du als Rechteck mit einem Namen. Für ihre Spalten
hältst du folgende Angaben fest: Spaltenname: Er ergibt sich aus
dem jeweiligen Attribut. Datentyp: Er legt fest, welche Werte die
Spalte aufnehmen kann. NULL erlaubt: Du kennzeichnest, ob ein Wert
fehlen darf. Pflichtfelder erhalten NOT NULL. Schlüssel: Mit PK für
Primary Key markierst du den Primärschlüssel. FK steht für Foreign
Key, also Fremdschlüssel. Die Kürzel kannst du vor oder hinter die
betreffende Spalte schreiben, solange eindeutig erkennbar bleibt,
worauf sie sich beziehen. Für die Zeichnung reicht eine
Verbindungslinie zwischen den Tabellen. Über die gekennzeichneten
Schlüssel lässt sich zuordnen, welche Spalten zusammengehören. Um
eine Kardinalität einzutragen, formulierst du die Beziehung in
beide Richtungen. Bei der Aussage "Eine Artikelgruppe enthält
mehrere Artikel" steht das n an der Tabelle Artikel. Datentypen für
deine Prüfung Da Datenbanksysteme unterschiedliche Typen anbieten,
empfehle ich dir für Prüfungsaufgaben einfache Bezeichnungen, die
dein:e Prüfer:in zuordnen kann: VARCHAR für Zeichenketten, etwa
einen Namen. NUMBER für Zahlen, wobei du bei Bedarf
Nachkommastellen angibst. DATE für Datumswerte. Damit lassen sich
auch Datumsoperationen ausführen, beispielsweise ein Jahr abziehen.
Wahrheitswerte kannst du bei fehlendem Boolean-Typ durch eine Zahl
mit den Werten 0 und 1 abbilden. Bietet das Datenbanksystem einen
passenden Boolean-Typ, kannst du diesen verwenden. Vom ER-Modell
zum Tabellenmodell Entitätstypen übernehmen Für jeden Entitätstyp
legst du eine Tabelle an und überträgst dessen Attribute als
Spalten. Den im ER-Modell unterstrichenen Primärschlüssel
kennzeichnest du mit PK. Anschließend vergibst du für jede Spalte
einen Datentyp und entscheidest, ob NULL erlaubt ist. Ein
Geburtsdatum erhält beispielsweise DATE; für einen Namen passt
VARCHAR. Dieser Schritt lässt sich direkt aus dem ER-Modell
ableiten und bringt dir bei einer entsprechenden Prüfungsaufgabe
bereits Punkte. 1:1-Beziehungen abbilden Bei einer 1:1-Beziehung
kannst du den Fremdschlüssel in einer der beiden Tabellen
unterbringen. Im Beispiel gehört zu einem Benutzerkonto genau ein
Login, das wiederum genau diesem Konto zugeordnet ist. Du kannst
deshalb eine Login-ID in der Tabelle User hinterlegen oder eine
User-ID in Login. Ich wähle den Ort danach, wie die Daten fachlich
zusammengehören. Wenn das Benutzerkonto die Haupttabelle bildet und
das Login ergänzende Daten enthält, lege ich die User-ID als
Fremdschlüssel in Login ab. 1:n-Beziehungen abbilden Bei einer
1:n-Beziehung kommt der Fremdschlüssel in die Tabelle auf der
n-Seite. Jeder Artikel gehört im Beispiel zu genau einer
Artikelgruppe, während eine Gruppe mehrere Artikel enthält. Die
Tabelle Artikel erhält daher eine Artikelgruppen-ID als
Fremdschlüssel. So enthält jede Zelle einen atomaren Wert. Mehrere
Artikel können über dieselbe Gruppen-ID derselben Artikelgruppe
zugeordnet sein. m:n-Beziehungen abbilden Für eine m:n-Beziehung
legst du eine zusätzliche Zuordnungstabelle an. Sie enthält die
Schlüssel der beiden beteiligten Tabellen als Fremdschlüssel.
Daraus entstehen zwei 1:n-Beziehungen. Eine Rechnung kann
beispielsweise mehrere Artikel enthalten, und ein Artikel kann auf
mehreren Rechnungen vorkommen. Die Zuordnungstabelle erhält deshalb
eine Rechnungs-ID sowie eine Artikel-ID. Diese beiden Spalten
bilden üblicherweise gemeinsam den Primärschlüssel. Ich empfehle
dir einen fachlich passenden Namen wie Rechnungsposition. In der
Prüfung wird auch ein zusammengesetzter Tabellenname wie
Artikel_Rechnung akzeptiert. Attribute an Beziehungen und
zusammengesetzte Schlüssel Wenn eine Beziehung eigene Attribute
besitzt, überträgst du diese in die Zuordnungstabelle. Bei einer
Rechnungsposition gehören beispielsweise Preis und Menge dazu.
Prüfe dann, ob die beiden Fremdschlüssel gemeinsam jeden Datensatz
eindeutig bestimmen. Wenn du wiederholte Käufe eines Artikels durch
dieselbe Person abbilden möchtest, reicht die Kombination aus
Kunden-ID und Artikel-ID für eine Historie allein nicht aus. Mit
einem zusätzlichen Datum im Schlüssel lassen sich Käufe zu
unterschiedlichen Zeitpunkten unterscheiden. Für meine Praxis
empfehle ich bei Schlüsseln mit mehr als zwei Spalten eine
zusätzliche anonyme ID als Primärschlüssel. Dadurch lassen sich
Beziehungen in SQL-Abfragen einfacher formulieren. Bei einem
zusammengesetzten Schlüssel müssen die zugehörigen Spalten in einem
Join vollständig berücksichtigt werden; ein vergessener Bestandteil
kann zu falschen Ergebnissen führen. In Prüfungsaufgaben empfehle
ich dir, zusammengesetzte Schlüssel zu modellieren,...
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.