Datenmodellierung mit dem Relationenmodell nach Codd

Die „relationale Denke“ von Codd. Codd stellt in seinem Aufsatz von 1970 die relationale Denkweise der in den 70ern üblichen graphenorientierten Denkweise gegenüber. In der graphenorientierten Sichtweise werden Daten als Knoten und Beziehungen zwischen den Daten als Kanten dargestellt. Das führt dann zu den hierarchischen Datenmodellen. Ebenso war es früher üblich, dass die logische Struktur der Daten eng mit der technischen Organisation der Daten auf dem Datenträger verknüpft war. Davon wollte Codd loskommen, insbesondere, weil durch die Verknüpfung eine Fachfrau für Daten auch gleichzeitig eine Fachfrau für Computertechnik sein musste. Die Fachleute sollten sich auf die logische Sicht der Daten konzentrieren können. Im Weiteren lernen Sie nun der Weg von unstrukturierten Daten zu einem relationalen Modell anhand eines lebensweltlichen Beispiels in drei Schritten kennen.

Stand: 22.05.2021

Zum Überblick über die Methoden der Wirtschaftsinformatik

Einordnung des Coddschen Relationenmodells in ARIS

In der Visualisierung des Aris-Rahmenkonzepts, dem „ARIS-Haus“, finden Sie auf der linken Seite die Daten-Perspektive. Das Relationenmodell von Codd ist in der Daten-Perspektive in der Beschreibungsebene „DV-Konzept“ eingeordnet (Abb. 1).

Das Relationenmodell eigeordnet in das ARIS-Rahmenkonzept.

Abb. 1: Einordnung der Datenmodellierung mit Relationen im ARIS-Rahmenkonzept.

Schritt 1: Ausgangspunkt unstrukturierte Daten (Das Problem)

Daten liegen oft in einer Form vor, so dass zwar Menschen mit den Daten arbeiten können, es jedoch schwer bis unmöglich ist, Computerprogramme für die Verarbeitung zu entwickeln.

Als Veranschaulichungs-Beispiel sollen die Dokumentationspflichten eines Hobbyimkers dienen. Ein Hobbyimker soll aufschreiben, was er wann mit seinen Bienen tut. (Das Folgende gilt für alle Wissenssammlungen und Dokumentationen und ist nicht auf das Beispiel des Hobbyimkers beschränkt) Ein solches „Imker-Logbuch“ in einem Notizbuch oder als einfache Textdatei könnte wie folgt aussehen:

Imker-Logbuch 2021
5.5.2021
B1902
Gewicht vor 16,61, nach 14,7
Honigzarge schön ausgebaut noch nicht ganz voll,Neue Honigzarge gegeben
Zwei verdeckte Weiselzellen gefunden
Ableger aus vier Waben (1 Honig, 1 Pollen 2 alt und verdeckte Brut) -> B2103
Fünf Zargen sind unpraktisch
Neuer Ableger B2103
1 Honig, Pollen und 2 alte Brut, 4,8 kg 
01.05.2021
Kontrolle Ableger B2101, B2102
Volk B2101 B2102
Kennzeichen blauer Deckel brauner Deckel
Sensor grün rot
Gewicht 28.04 kg 4,95 4,55
Gewicht 01.05. kg 4,70 4,30
Flug wenig, zielgerichtet wenig, orientierend

Abb. 2: Beispiel unstrukturiertes Imker-Logbuch für die Kontrollen an Bienenstöcken

Schritt 2: Strukturierungsversuch „aufgeräumter aufschreiben“ (Die Verbesserungsidee)

Mit dem unstrukturierten Logbuch ist der wesentliche Schritt getan: Die Daten sind verschriftlicht und damit festgehalten. Allerdings wird der Hobbyimker, wenn er mit vielen Bienenvölkern und über Jahre arbeitet, irgendwann in seinen Aufzeichnungen nichts mehr wiederfinden. Im nächsten Schritt könnte der Hobbyimker seine Notizen etwas aufgeräumter und systematischer anfertigen.

Imker-Logbuch 2021
Datum: 5.5.2021
            Aktivität: Kontrolle
            Volk: B1902
                        Gewicht vor Bearbeitung: 16,61
                        Gewicht nach Bearbeitung: 14,7
                        Honigzarge Ausbau: gut
                        Weiselzellen: 2
                        Änderung: „neue Honigzarge“
                        Änderung: „Ableger neu B2103“
                        Anmerkung: „Fünf Zargen sind unpraktisch“
Datum: 01.05.2021
            Aktivität: „Kontrolle“
            Volk: „B2101“
                        Gewicht vor Bearbeitung: 4,95
                        Flugaktivität: wenig
                        Flugbild: zielgerichtet
            Volk: „B2102
                        Gewicht vor Bearbeitung: 4,55
                        Flugaktivität: wenig
                        Flugbild: zielgerichtet ….

Abb. 3: Beispiel „aufgeräumtes“ Logbuch.

In dem aufgeräumten Logbuch finden sich Menschen bereits gut zurecht, für Computerprogramme sollte es formal noch strukturierter sein.

Schritt 3: Umsetzung in ein einfaches Relationenmodell (Die Lösung)

Zunächst sollte der Hobbyimker analysieren, welche Daten er denn häufig erfassen möchte. Das aufgeräumte Logbuch gibt dazu Hinweise:

1. Datum der Kontrolle
2. Bezeichnung des Volkes als Zeichenkette/Text, z.B. „B2102“
3. Gewicht des Volkes in kg als Fließkommazahl, z.B. 4,55
4. Bewertung der Flugaktivität. Hier entscheidet sich der Imker, Zahlen wie für Schulnoten zu vergeben, z.B. 1 für hohe Aktivität und 5 für gar keine Aktivität.
5. Bewertung des Flugbildes als Zeichenkette/Text, z. B. „zielgerichtet“ oder „suchend“
6. Änderungen sieht der Imker als Zeichenkette vor. Mehr als zwei Änderungen führt er normalerweise nicht durch.
7. Als Anmerkung möchte der Imker noch Bemerkungen in Textform festhalten.
8. Eine laufende Nummer macht es einfacher, eine bestimmte Kontrolle später wiederzufinden.

Abb. 4: Beispiel Analyse der Daten für das Imker-Logbuch

Wir nutzen nun sogleich die von Codd vorgeschlagene Schreibweise für eine Relation. Eine vertiefte Beschreibung, was es mit der Relation auf sich hat, finden Sie in den folgenden Abschnitten.

Aus der Analyse ergibt sich die Relation.

logeintrag ( lfd_nr, datum, volk, gewicht, flugaktiv, flugbild, aenderung1, aenderung2, anmerkung )

Abb. 5 : Beispiel für die Einträge im Imker-Logbuch. Das Relationenschema für das Imker-Logbuch besteht nur aus dieser einen Relation.

Den Kontrollen werden dann konkrete Tupel (= Datensätze) zugeordnet. Es fällt auf, dass es am 01.05. offensichtlich keine Gründe gab, Änderungen oder Anmerkungen festzuhalten.

logeintrag ( 35, 01.05.2021, B2101, 4,95, 4, „zielgerichtet“, , , )

logeintrag ( 36, 01.05.2021, B2102, 4,55, 4, „zielgerichtet“, , , )

Abb. 6: Beispiel zwei Datensätze einer Kontrolle als Relationen formuliert

Es gibt mehrere Möglichkeiten, die Relation praktisch zu implementieren – von einer einfachen handschriftlichen Tabelle auf Papier bis hin zu einer Smartphone-App mit einem relationalen Datenbankmanagementsystem. In den Folgebeispielen sehen Sie, wie man ein Relationenmodell zur Konzeption entwickelt.

Relationen sind fast wie Tabellen

Eine Relation ist die Basis der von Edgar F. Codd (1970) entwickelten relationalen Algebra. Mathematisch ist das anspruchsvoll, für den praktischen Nutzen können wir die Ideen allerdings stark vereinfachen. Wenn immer möglich, werden Sie über Begrifflichkeiten von Tabellenkalkulationsprogrammen wie Microsoft Excel an die relationale Sichtweise herangeführt. Statt Excel wären auch Numbers (Apple) oder das freie System Open Office Calc oder Gnumeric (Linux) als Beispiele geeignet. Eine Relation besteht aus einer Bezeichnung (vgl. Arbeitsblatt-Name in Excel), aus Attributen (vgl. Spaltenüberschriften in Excel-Tabellen) und Tupeln (vgl. Zeilen in einer Excel-Tabelle). Ein Attribut beschreibt den Typ eines möglichen Attributwertes und bezeichnet ihn mit einem Attributnamen. Ein Tupel stellt eine konkrete Kombination von Attributwerten dar (einen Datensatz). Das Relationenmodell beschreibt Daten also in einer Form, die sich gut in Tabellen übersetzen lässt. Stellen Sie sich ein Schraubenlager vor, in dem Sie über Ihre Schrauben Buch führen wollen. Eine Schraube hat dann die Eigenschaften „Typ“ (z.B. „Rundkopf“), einen Durchmesser in mm, eine Länge in mm und eine Materialsorte (z.B. „Messing“). Mit Blick auf die spätere Umsetzung verzichten manche auf Groß-Kleinschreibung und auf Umlaute.

schraube (id, typ, durchmesser, laenge, material)

Abb. 7: Beispiel für ein Relationsschema mit einer Relation für Schrauben in der Schreibweise von Codd

In der Übersicht in Tab.1 sind die Begriffe der Relationentheorie lebensweltlichen Begriffen gegenübergestellt:

RELATIONENTHEORIE KANN VERDEUTLICHTE WERDEN DURCH
Relation Tabelle
Tupel Menge der Zellen in einer Zeile, Datensatz
Attribut Spaltenüberschrift

Tab. 1: Begriffe aus der Relationentheorie im Vergleich zu Tabellen

Die schon verwendeten Begriffe „Schema“ und „Tupel“ sollen nun noch einmal präziser gefasst werden.

Ein Schema, Datenschema oder Relationsschema ist eine formale Beschreibung der Struktur von Daten.

Abb. 8: Begriffsdefinition „Schema“

Ein Tupel ist eine geordnete Wertesammlungen und wird – in der Relationentheorie – als Synonym für einen Datensatz verwendet. Die Werte eines Tupels sind die Attribute (Synonym für Attribut ist ein Datenfeld). Ein „n-Tupel“ oder verkürzt „Tupel“ bezeichnet somit eine Sammlung mit einer beliebigen Anzahl n von Attributen.

Abb. 9: Begriffsdefinition „Tupel“

Was ist eine Relation?

Mathematik: In der Mathematik ist eine Relation die Beziehung zwischen Dingen. Eine Relation R ist eine Menge von Tupeln. Dinge, die zueinander in der Relation R stehen, bilden ein Tupel, das Element von R ist. So gesehen ist eine Relation die Menge aller Kombinationen der möglichen Attributwerte. In der Mathematik sind meist zweiwertige Relationen von Interesse (z.B. mit den Attributen „person“ und „telefonnr“), in der Informatik finden oft mehrwertige Relationen (z.B. die Schrauben mit fünf Attributen). Haben Sie z. B. drei Personen und vier Telefonnummern, so besteht die zweiwertige Relation theoretisch aus maximal person X telefonnr Elementen, also 3*4=12 Tupeln. Praktisch werden Sie aber nur eine Teilmenge davon haben, z.B. 3 Tupel, wenn jede der drei Personen nur eine Telefonnummer hat. Eine Relation ist daher, mathematisch gesprochen, eine Teilmenge des karthesischen Produktes der Attribute. Das kartesische Produkt M×N zweier Mengen M und N ist die Menge aller geordneten Paare mit erster Komponente aus M und zweiter Komponente aus N. Ein geordnetes Paar (x, y) besteht aus zwei Werten x und y, wobei x die erste und y die zweite Komponente ist.

Praktisch: In der Informatik ist eine Relation eine Sammlung von Datensätzen (=Tupeln), die alle jeweils gleich aufgebaut sein müssen: Ein Datensatz besteht aus einer Reihe von 1 bis n Datenfeldern (=Attributen). Die Reihenfolge bzw. Anordnung der Datenfelder ist wesentlich. Die einzelnen Datenfelder haben eine Bezeichnung (Attributnamen). Wenn Sie vorhaben, Ihre Daten technisch in einem relationalen Datenbankmanagementsystem zu organisieren, können Sie eine Relationen durch eine Tabelle beschreiben. Dann sind die Tupel die Zeilen mit den konkreten Datensätzen, die Attributnamen sind die Spaltenbezeichnungen. Die Reihenfolge der Spalten ist wesentlich. Die Reihenfolge der Zeilen ist allerdings beliebig.

Dem Begriff „Relation“ können Sie sich also über die Eigenschaften einer Relation nähern:

1. Es gibt keine zwei völlig identischen Tupel. Das heißt: Zwei Tupel (Zeilen in einer Tabelle, Datensätze) unterscheiden sich in mindestens einem Attribut (Wert).

2. Die Reihenfolge der Tupel ist unwichtig, sie sind nicht geordnet. (Es ändert erst einmal nichts, wenn die Reifenfolge der Zeilen geändert wird.)

3. Die Reihenfolge der Attribute ist wichtig, sie sind geordnet. (Diese Eigenschaft ist in der Historie und der Ableitung von den mathematischen Relationen geschuldet. Praktisch hat es bei klug gewählten Spaltenüberschriften keine Relevanz.)

4. Alle Attribute sind atomar (In jeder Tabellenzelle darf nur ein Eintrag einer Sorte stehen. In ein Tabellenfeld gehört nur ein Wert.). Wenn alle Werte atomar sind, befindet sich das Relationenmodell in der ersten Normalform. Das is mit die wichtigste Eigenschaft.

Abb. 10: Beispiel für die Implementierung einer einfache Relation in eineTabelle am Beispiel Schrauben.

Aus dem vorgenannten lässt sich der Begriff Relation schärfer fassen.

Eine Relation ist eine Menge von Tupeln bzw. Datensätzen. Die Tupel bestehen alle aus der gleichen Anzahl von Datenfeldern oder Attributen. Die Datenfelder oder Attribute sind immer in der gleichen Reihenfolge angeordnet. In jedem Datenfeld steht immer nur ein Wert. In jedem Datenfeld in einer bestimmten Position steht immer die gleiche Art von Wert.

Abb. 11: Begriffsdefinition „Relation“

 

Implementierung von Relationen

Implementierung von Relationen als Tabellen

In den meisten Fällen werden Ihnen Relationen als Tabellen z.B. in relationalen Datenbankmanagementsystemen oder in Excel oder als CSV-Dateien begegnen. Die Umsetzung des Relationenschemas für die Schrauben (Abb. xx) als Tabelle sähe dann wie in Abb. xx aus:

schraube (id, typ, durchmesser, laenge, material)

Abb. 12: Relationenschema mit einer Relation „schraube“

id    typ         laenge      durchmesser material
==================================================
1     Rundkopf    50          4           Messing
2     Rundkopf    30          4           Messing
3     Senkkopf    50          5           vernickelt
4     Senkkopf    30          5           vernickelt
.....

Abb. 13: Umsetzung der Relation „schraube“ in eine Tabelle

Eine CSV-Datei (nach RFC 4180) bildet Tabellen in einem einfachen Textformat nach. In einer CSV-Datei  werden die Zeilen durch einen Zeilenumbruch mit Wagenrücklauf getrennt (in Programiersprachen mit „\r\n“ bezeichnet) die einzelnen Datenfelder werden normalerweise mit einem Komma getrennt, in Deutschland mit einem Semikolon, da das Komma der Dezimaltrenner ist. Die erste Zeile enthält die Attributnamen.

id;typ;durchmesser;laenge;material\r\n
1;Rundkopf;4;50;Messing\r\n
2;Rundkopf;4;30;Messing\r\n
3;Senkkopf;5;50;vernickelt\r\n
4;Senkkopf;5;30;vernickelt\r\n
.....

Abb. 14

Implementierung von Relationen als Schlüssel-Wert-Paare

Ein Relationenschema kann, muss aber nicht als Sammlung von Tabellen implementiert werden. Eine andere Möglichkeit ist die technische Speicherung als Schüssel-Wert-Paare in einer einfachen Textdatei. So wird beispielsweise bei JSON-formatierten Daten (nach RFC 8259) verfahren. Für das Beispiel der Schrauben hieße das:

{
id:1
typ:Rundkopf
durchmesser:4
laenge:50
material:Messing
}
{
id:2
typ:Rundkopf
durchmesser:4
laenge:30
material:Messing
}
....

Abb. 15: Implementierung der Relation „schraube“ als Schlüssel-Wert-Paare.

Implementierung von Relationen in XML

Ein Relationenschema kann auch XML-formatiert (standardisiert vom W3C) implementiert werden. Für das Beispiel der Schrauben sähe eine XML-Darstellung wie in Abb. xx aus.

<schraube>
<id>1</id>
<typ>Rundkopf</typ>
<durchmesser>4</durchmesser>
<laenge>50</laenge>
<material>Messing</material>
</schraube>
<schraube>
<id>2</id>
<typ>Rundkopf</typ>
<durchmesser>4</durchmesser>
<laenge>30</laenge>
<material>Messing</material>
</schraube>
....

Abb. 16: Implementierung der Relation „schraube“ als XML-formatierte Textdatei.

 

Umgang mit komplexeren Beziehungen zwischen Relationen

Allgemeiner Fall, komplexe Struktur am Beispiel einer Telefonliste

Das relationale Modell spielt seine Stärken dann aus, wenn Daten eine komplexere Struktur haben. So kann es im Imker-Logbuch-Beispiel vorkommen, dass es vielleicht mehr als zwei Änderungen bei einem Logbucheintrag gibt. Oder aber Personen haben mehrere Telefonnummern und teilen sich vielleicht in Bürogemeinschaft eine Nummer. Das Telefonnummernbeispiel soll nun dazu dienen, die Beziehung zwischen mehreren Relationen zu erläutern.

Das Problem: Würden Sie den Fall, dass Personen mehrere Telefone haben und sich vielleicht mehrere Personen ein Telefon teilen, durch eine Relation darstellen wollen, müssten Sie für eine Vielzahl von Telefonen, z.B. drei, jeweils Attributnamen vorsehen. In der Implementierung als Tabelle wird das zu einer „löchrigen“ Tabelle mit vielen ungefüllten Feldern führen. Wenn dann die erste Person mit vier Telefonen auftaucht, müssten Sie das Relationenschema ändern und auch die Struktur der gesamten Datenbank.

telefon_von (id, name, telnr1, telnr2, telnr3)

Abb. 17: Beispiel für ein Relationsschema für die Telefonliste in der Schreibweise von Codd

id    name        tel1        tel2        tel3
=====================================================
1     Schmidt     0186-233    -3351       0172 1234567
2     Müller                  -3351       0177 1234567
3     Mayer       0184-223

Abb. 18: Umsetzung der Relation für eine Telefonliste als Tabelle

Die Lösung der o.a.  Probleme (löchrige Tabelle oder ggf. nicht genug Felder in einem Tupel) ist, mit mehreren Relationen zu arbeiten und eine Beziehung zwischen den Relationen über gleiche Attributnamen herzustellen (Abb. xx).

 

person            person_hat_tel    telefonnummer

p_id  name        p_id  t_id        t_id  telefon
=============     ==========       ==================
1     Schmidt     1     1           1     0172 1234567
2     Müller      1     3           2     0177 1234567
3     Mayer       1     3           3     -3351
2     3           4     0186-233
2     2           5     0186-233
3     5

Abb. 19: Beispiel dicht gefüllte Tabellen, die Telefonliste ist auf drei Tabellen aufgeteilt

Mit den drei Tabellen können Sie nun eine Beziehung der möglichen Telefonnummern (Tabelle „telefonnummer“) zu den möglichen Personen (Tabelle „person“) herstellen, in dem Sie zunächst die id der betreffenden Person heraussuchen, dann die Telefon-Ids (t_id) suchen, die in der Tabelle person_hat_tel der jeweiligen Personen-Id (p_id) zugeordnet sind und dann alle Telefonnummern herausschreiben, die Sie mit den Telefon-Ids in der Tabelle „telefonnummer“ finden. Dieser Finde-Algorithmus lässt sich im Übrigen leicht programmieren, so dass sich diese Art der Datenorganisation in relationalen Systemen durchgesetzt hat.

Das Relationenschema zu den drei Tabellen aus Abb. xx besteht aus drei Relationen wie in Abb. xx

person (p_id, name)
telefonnummer (t_id, telefon)
person_hat_tel (p_id, t_id)

Abb. 20: Relationenschema mit drei Relationen für komplexere Datenbeziehungen m-zu-n

Im in Abb. 20 dargestellten Fall handelt es sich im übrigen um eine sogenannte m-zu-n Beziehung, da grundsätzlich jeder Person beliebig viele (n) Telefonnummern zugeordnet werden können, andererseits aber eine Telefonnummer theiretisch auch von beliebig vielen (m) Personen genutzt werden kann.

Die Ids p_id und t_id in den Relationen person und telefonnummer sind Primärschlüssel, Die gleichnamigen Ids in der Relation „person_hat_tel“ sind Fremdschlüssel.

Mit der Aufteilung der Telefonliste auf drei Relationen befindet sich das Relationenschema in der zweiten Normalform, da jedes Attribut in jeder Relation vom Primärschlüssel abhängig ist.

Primärschlüssel und Fremdschlüssel

Der Primärschlüssel wird zur eindeutigen Identifizierung eines Tupels (=Datensatzes) verwendet.

Der Wert eines Primärschlüssels muss einmalig sein, da er jeden Datensatz eindeutig kennzeichnet. Beispiele wären für Menschen die Personalausweis-ID, bei Studentinnen die Matrikel-Nummer oder im Sportverein die Mitgliedsnummer. Der Primärschlüssel einer Relation kann drei Ausprägungen haben und ein eindeutiger, ein zusammengesetzter oder ein künstlicher Primärschlüssel sein. Die hier verwendeten zusätzlichen Ids sind künstliche Primärschlüssel.

Auf künstliche Primärschlüssel kann verzichtet werden, wenn es einen eindeutigen Primärschlüssel oder einen zusammengesetzten Primärschlüssel gibt.

Bei einem eindeutigen Primärschlüssel handelt es sich um ein Attribut, das einen Datensatz eindeutig kennzeichnet. Das liegt nicht immer vor: Der Nachname beispielsweise ist ungeeignet, da es oft mehrere Menschen mit Nachnamen „Schmidt“ gibt.

Ein zusammengesetzter Primärschlüssel besteht aus mehreren Attributen, die zusammen ein Tupel eindeutig kennzeichnen.

Es hat sich in der Praxis bewährt, spätestens bei der Implementierung in ein RDBMS künstliche Primärschlüssel für jede Tabelle zu verwenden.

Ein Fremdschlüssel ist ein Attribut, das auf einen Primärschlüssel in einer anderen Relation verweist und damit die Beziehung zwischen Relationen herstellt.

Sonderfall „ein bisschen komplexe Datenbeziehungen“

Für den etwas einfacheren Fall, dass eine Person zwar mehrere Telefone haben kann, aber es nie vorkommt, dass ein Telefon mehreren Personen zugeordnet ist, vereinfacht sich das relationale Modell auf zwei Relationen. Die notwendige Beziehung zwischen Personen und den Telefonen wird dadurch hergestellt, dass jedem Telefon eine Personen-Id zugeordnet wird. Die Relation „telefon“ erhält dazu ein weiteres Attribut p_id. Das Attribut p_id in der Relation „telefon“ ist ein Fremdschlüssel, in der Relation „person“ ist p_id ein Primärschlüssel und kennzeichnet ein Tupel (einen Datensatz) eindeutig.

person (p_id, name)
telefonnummer (t_id, telefon, p_id)

Abb. 21: Relationenschema für eine weniger komplexe Datenbeziehungen 1-zu-n

Eine solche Form der Beziehung zwischen Relationen heißt 1-zu-n Beziehung.

Sonderfall „ganz einfache Datenbeziehung“

Der ganz einfache Fall, dass zu jeder Person genau eine Telefonnummer gibt, eine sogenannte 1-zu-1 Beziehung, können Sie durch eine einzelne Relation darstellen. Das heißt, Sie fassen die realweltlichen Objekte Person und Telefon zu einer Relation zusammen und haben keine direkte Zuordnung mehr zwischen den Objekten in der Realität und der modellhaften Vorstellung in Form von Relationen.

person (id, name, telefon)

Abb. 22: Relationenschema für ganz einfache Datenbeziehungen 1-zu-1

 

Anwendung der Datenmodellierung mit Relationen auf die Fallstudie der Kaffeemanufaktur

Die Fallstudie für die Kaffeemanufaktur führt zur Datenhaltung aus:

Kaffeemanufaktur „Kleiner Schwarzer“ goes cloud computing – Datenhaltung und User Interface

Daten in Excel

Das Excel-Arbeitsblatt verkauf.xlsx hat sich Frau Malzkanne selber gebaut. Es besteht aus acht Spalten mit Nummern „laufende Nummer“, „Datum“, „Kundenname“, Anzahl Brasil Santos“, „Anzahl Espresso“, „Anzahl Omas Bester“, „Betrag netto“, „Betrag brutto“. Martin Malzkanne soll als Ersatz für das Excel-Arbeitsblatt verkauf.xlsx in eine Internet-Anwendung programmieren, in die Frau Malzkanne dann zukünftig die Verkäufe eintragen kann. Martin Malzkanne zeichnet dazu ein Use-Case-Diagramm, um mit Melitta Malzkanne zu diskutieren, was sie mit der Internet-Anwendung tun können sollte. Ebenso soll Frau Malzkanne das Datenmodell (Relationenmodell oder ERM) für diese Daten zeichnen, damit Martin Malzkanne die Datenbank anlegen kann.

Abb. 23: Auszug aus der Fallstudie

Das Relationenschema, das Frau Malzkanne erstellen soll, ist eines für eine „einfache Datenstruktur“ und besteht aus nur einer Relation. Die Id ist in diesem Fall die laufende Nummer.

verkauf (lfd_nr, datum, kd_name, anz_brasil_santos, anz_espresso, anz_oma_best, netto, brutto)

Abb. 24: Relationenmodell für den Verkaufsprozess in der Fallstudie

Damit ist die Aufgabenstellung zunächst erledigt. Wenn Sie weiter denken, ziehen Sie vielleicht ein Wachstum des Unternehmens in Betracht, und es werden Kaffeesorten hinzukommen. Sie werden dann mit mehreren Relationen arbeiten, in diesem Fall wird das Datenmodell ungleich komplizierter. Für den Start genügt das einfache Modell.

Quellen

Codd, E. (1970): A Relational Model of Data for Large Shared Data Banks” Communications of the ACM, San Jose, CA, USA, 1970. ACM, New York, USA, 1970; S. 377-387.  IBM Research Laboratory, San Jose, California. Online Ressource: https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf

Teile diesen Beitrag.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.