Daten- und Ablaufmodellierung
Umsetzung eines Modells mit einer relationalen Datenbank
Stundenvorschlag A
1. Tabellenentwurf zu einer Aufgabe entwickeln und analysieren
1.1 Aufgabe
Die Verwaltung der Stadt Lichtenfels möchte ein Informationssystem für ihre Kleinstadt und die umliegenden Ortschaften aufbauen, das Hilfsangebote von Nachbarn für Nachbarn enthält. Das Angebot an Hilfsdiensten, die Kosten dafür und Informationen über den Anbieter (Adresse, Alter usw.) sollen dabei in einer Datenbankanwendung gespeichert werden. Die Kosten für die Hilfsdienste werden von der Stadtverwaltung festgelegt, weil soziale und nicht kommerzielle Gesichtspunkte im Vordergrund stehen sollen. Die Datenbankanwendung soll den Mitarbeitern der Stadtverwaltung die Vermittlung von Hilfsleistungen an Hilfesuchende erleichtern.
1.2 Tabellenentwurf
Die Schüler überlegen sich ähnlich wie im Punkt 8.3 des Informatiklehrplans, welche Objekte (hier: Anbieter und Dienst) und welche Attribute (Eigenschaften) für diese Aufgabenstellung relevant sind und fassen die Attribute in einer Tabelle zusammen.

Name der Tabelle: Anbieter
Datenfeldnamen: Name, Adresse, Telefon, Alter, Dienstname, Preis pro Std.
Kurzschreibweise für die Tabelle:
Anbieter (Name, Adresse, Telefon, Alter, Dienstname, Preis pro Stunde)
1.3   Analyse des Tabellenentwurfs
Mit Hilfe von Fallbeispielen wird der Tabellenentwurfs analysiert. Die Schüler erkennen so die Schwächen ihres Entwurfs:
  
a)  Es ist für die Mitarbeiter der Stadtverwaltung sehr schwer eine Liste der Anbieter, die z. B. in Lichtenfels wohnen, auszugeben, da im Datenfeld Adresse sowohl die Straße als auch der Ort abgespeichert wird. 
b) Schwierigkeiten entstehen auch, wenn ein Mitarbeiter der Stadtverwaltung die Liste der Anbieter alphabetisch sortieren möchte, da im Datenfeld Name der Vor- und Nachname (in beliebiger Reihenfolge) abgespeichert ist. Im Fall a) und b) ergeben sich mit dem derzeitigen Tabellenentwurf Probleme bei den Abfragen und bei der Handhabung des Datenbestands.
c) Das Datenfeld Alter muss jedes Jahr aktualisiert werden. Dies ist sehr zeitaufwendig und evtl. schleichen sich dabei Fehler ein. In solch einem Fall spricht man von Inkonsistenz (Unkorrektheit) der Daten nach Änderung des Datensatzes. Es ist deshalb besser statt des Alters das Geburtsdatum abzuspeichern. 
d) Wenn Susi Huber neben Kinderbetreuung noch Nachhilfe in Englisch anbieten möchte, müssten im Datenfeld Dienstname beide Angebote und im Feld Preis pro Std. beide Preisangaben abgespeichert werden. Dadurch würden sich aber große Probleme bei den Suchabfragen ergeben. Sucht man nach einem Anbieter für „Kinderbetreuung“, erhält man Susis Datensatz nicht als Treffer, da der Inhalt des Datenfelds Dienstname „Kinderbetreuung, Nachhilfe in Englisch“ lautet.
Würde man in der Tabelle die zwei weiteren Datenfelder Dienstname2 und Preis pro Std.2 einfügen, treten erneut Probleme auf, sobald für einen Anbieter drei Angebote abgespeichert werden sollen. Zudem bedeuten diese Datenfelder Dienstname2  und Preis pro Std.2 eine Verschwendung von Speicherplatz, da bei den meisten Anbietern dieses Felder leer bleiben werden. 
e) Wenn Susi Huber neben Kinderbetreuung noch Nachhilfe in Englisch anbieten möchte, könnte als weitere Möglichkeit Susis gesamter Datensatz mit ihrer Adresse nochmals gespeichert werden. Dadurch würde aber eine große Datenmenge (die Adressdaten) überflüssigerweise mehrfach gespeichert werden. Man spricht dann von Redundanz (überflüssige Mehrfachspeicherung von Daten). Wenn Susi Huber umzieht, müsste ihre Adresse auch in den beiden Datensätzen geändert werden. Das ist umständlich und anfällig für Tippfehler. Zudem wird die zweite Änderung gern vergessen. Die Adressdaten von Susi Huber wären dadurch evtl. in einem Datensatz falsch abgespeichert. Es käme zu einer Inkonsistenz (Unkorrektheit) der Daten nach Änderung des Datensatzes.
f) In der Tabelle Anbieter kommen zwei Datensätze mit dem Namen „Alfons Meier“ vor. Sind die beiden Vater und Sohn, die den gleichen Namen tragen oder hat sich eine Angestellte der Stadtverwaltung bei der Eingabe des Alters vertippt? Die Datensätze sind also nicht eindeutig identifizierbar.
g) Für Rasenmähen wird sowohl 7 € als auch 8 € berechnet. Die Mitarbeiter der Stadtverwaltung möchten einheitliche Preise. Wenn 20 Personen Rasenmähen anbieten, müsste der Preis 20 mal kontrolliert werden. (Inkonsistenz durch Redundanz)
h) Der Preis für die Dienstleistung „Haushaltshilfe“ wird von den Mitarbeitern der Stadtverwaltung auf 10 € festgelegt. Solange kein Anbieter dafür gefunden wurde, kann der Preis gar nicht in der Tabelle abgespeichert werden. So ergeben sich Probleme beim Einfügen von Daten. 
i) Der Preis für die Kinderbetreuung würde verloren gehen, wenn die einzige Anbieterin, Susi Huber, ihren Dienst einstellt und ihr Datensatz aus der Tabelle gelöscht wird. (Datenverlust bei Löschung von Daten) 
 

Die Schüler haben erkannt, dass eine falsche Struktur der Tabelle zu Redundanzen führt. Die Folge ist, dass beim Ändern oder Einfügen von Datensätzen sachlich falsche oder widersprüchliche Daten (Inkonsistenz) bzw. beim Löschen von Datensätzen Datenverlust entstehen. Ziel wird es sein, den Tabellenentwurf so zu verändern, dass er die Qualitätsmerkmale eines gut durchdachten Datenbankentwurfs erfüllt.
2. Qualitätsmerkmale eines Datenbankentwurfs
Durch die „Schwächen“ des ersten Tabellenentwurfs erkennen die Schüler die Qualitätsmerkmale eines Datenbankentwurfs.
2.1 Geringe Datenredundanz
Unter Redundanz bei der Datenspeicherung versteht man, dass gleiche Fakten (z. B. die Adresse) mehrfach abgespeichert sind.
Verminderung der Redundanz bedeutet, dass jedes Datum nur sooft gespeichert wird, wie es unbedingt erforderlich ist. Dadurch kann Speicherplatz gespart werden.
2.2  Konsistenz (Widerspruchsfreiheit) der Daten
Eine Folge von Redundanz (Mehrfachspeicherung) ist, dass beim Ändern oder Einfügen von Datensätzen sachlich falsche oder inhaltlich widersprüchliche Daten (Inkonsistenz) entstehen bzw. beim Löschen von Datensätzen Daten verloren gehen.
Durch die Verminderung der Redundanz wird die Konsistenz der Daten, d. h. die Widerspruchsfreiheit und Korrektheit der Daten gewährleistet.
Arbeitsblatt zum Thema
AB_DB.pdf
3. Beseitigung der Redundanzen (Normalisierungsregeln 1 – 3)
E. F. Codd, der das relationale Datenbankmodell entwickelt hat, entwickelte zur Beseitigung der Redundanzen sogenannte Normalformen (NF). Mit Hilfe dieser Normalformen wird eine Tabelle, die Redundanzen enthält, in ein System von mehreren Tabellen zerlegt, die über gemeinsame Datenfelder in Beziehung zueinander stehen. Die Normalformen bauen aufeinander auf, d. h. die Anwendung der 2. NF setzt voraus, dass sich die Tabellen in der 1. NF befinden! Tabellen in der dritten Normalform sind weitgehend redundanzfrei, d. h. kein Teil des Datenbestandes kann weggelassen werden, ohne dass dies zu Informationsverlusten führt.
3.1 Erste Normalform (1NF)
Eine Relation (Tabelle) ist in der ersten Normalform, wenn alle Datenfelder mit zusammengesetzten Inhalten in ihre einzelnen Bestandteile zerlegt sind.
So ist z. B. das Datenfeld Adresse, das die Postleitzahl, den Ort, die Straße und die Hausnummer enthält, ein Datenfeld mit zusammengesetzten Inhalten. Alle Teile des Datenfeldinhalts, die getrennt verarbeitet werden sollen, müssen in eigene Datenfelder abgespeichert werden. So entstehen aus dem Datenfeld Adresse die Felder Postleitzahl, Ort und Straße (mit Hausnummer) (vgl. Punkt 1.3, Fallbeispiel a). 
Aus dem Datenfeld Name entstehen die Felder Nachname und Vorname, damit die Liste der Anbieter z. B. alphabetisch geordnet werden kann (vgl. Punkt 1.3, Fallbeispiel b).
Ein Datenfeld Geburtsdatum setzt sich zwar aus den Teilen Tag, Monat und Jahr zusammen, muss aber nicht zerlegt werden, wenn das Geburtsdatum stets als Ganzes verarbeitet wird (vgl. Punkt 1.3, Fallbeispiel c)..

Zuletzt müssen noch die Datenfelder Dienstname und Preis pro Std. bearbeitet werden. Es könnten zwar für einen Anbieter mehrere Angebote in diesem Datenfeld abgespeichert werden (vgl. Punkt 1.3, Fallbeispiel d). Datenfelder mit zusammengesetzten Inhalten verstoßen aber gegen die 1. Normalform. Das Anlegen weiterer Datenfelder Dienstname2, Preis pro Std.2 usw. oder Datensätze für diesen Anbieter löst das Problem ebenfalls nicht (vgl. Punkt 1.3, Fallbeispiel d und e). Wir gehen bei der Lösung dieses Problems folgendermaßen vor:
Datenfelder, die in einem Datensatz mehrfach auftreten (sogenannte Wiederholungsfelder; hier: Dienstname, Dienstname2, Preis pro Std. usw.) werden aus der Tabelle entfernt und gemeinsam mit einem Schlüsselfeld (Primärschlüssel) in einer eigenen Tabelle angelegt.
Ein Primärschlüssel ist ein spezielles Datenfeld, dessen Inhalt bei jedem Datensatz unterschiedlich sein muss. Definiere ein Schlüsselfeld (Primärschlüssel) für jede Tabelle, welches die Datensätze eindeutig voneinander unterscheidet (vgl. auch Punkt 1.3, Fallbeispiel f).
In der Kurzschreibweise der Tabellen werden Datenfelder, die Primärschlüssel sind, mit einer Unterstreichung gekennzeichnet. 

Es entstehen die Tabelle Anbieter und die Tabelle Angebot:
Anbieter  (Anbieter-Nr, Nachname, Vorname, PLZ, Ort, Straße, Telefon, Geburtsdatum),
Angebot (Angebot-Nr, Anbieter-Nr, Dienst-Nr, Dienstname, Preis pro Std)
Bemerkung
Das Einfügen des Schlüsselfeldes Angebot-Nr ist nicht unbedingt notwendig, erleichtert aber die Handhabung in MS-ACCESS, wenn die Tabelle Angebot ein eigenes Feld als Primärschlüssel besitzt.

Damit aus den Tabellen abgelesen werden kann, wer welche Angebote anbietet, müssen die beiden Tabellen Anbieter und Angebot zueinander in Beziehung gebracht werden über ein gemeinsames Schlüsselfeld. Die Tabellen Anbieter und Angebot besitzen noch kein gemeinsames Schlüsselfeld. Um die beiden Tabellen miteinander zu verbinden, wird in der Tabelle Angebot der Primärschlüssel der Tabelle Anbieter (Anbieter-Nr) als zusätzliches Datenfeld eingefügt. Den eingefügten Schlüssel bezeichnet man in der Tabelle Angebot als Sekundärschlüssel (Fremdschlüssel).
Die Tabellen Anbieter und Angebot in der 1. NF
In diese Tabellenstruktur kann nun auch das zweite Angebot von Susi Huber, Nachhilfe in Englisch eingetragen werden.
 
3.2 Zweite Normalform (2NF)
Eine Relation (Tabelle) ist in der zweiten Normalform, wenn alle Nichtschlüsselfelder einer Tabelle vom gesamten Kombinationsschlüssel abhängen.
Eine Tabelle besitzt einen Kombinationsschlüssel, wenn sich der Primärschlüssel aus mehreren Datenfeldern zusammensetzt bzw. eine Tabelle einen Primär- und einen Sekundärschlüssel enthält. 
Hängt ein Datenfeld nicht vom gesamten Kombinationsschlüssel ab, wird dieses Datenfeld aus der Tabelle entfernt und gemeinsam mit dem Teil des Schlüssels, von dem es abhängt, in einer neuen Tabelle gespeichert. 

Die Tabelle Angebot besitzt einen Kombinationsschlüssel (Angebot-Nr, Anbieter-Nr, Dienst-Nr). Die Datenfelder Dienstname und Preis pro Std. sind nur vom Schlüsselfeld Dienst-Nr abhängig nicht jedoch vom Schlüsselfeld Anbieter-Nr. Denn die Preise für die Dienste werden nicht vom Anbieter, sondern von der Stadtverwaltung festgelegt. Deshalb werden die Felder zusammen mit dem Schlüsselfeld Dienst-Nr in die Tabelle Dienste ausgelagert. Damit lösen sich auch die Probleme, die in den Fallbeispielen g) bis i) unter Punkt 1.3 aufgetreten waren. 
Die Tabellen Anbieter, Angebot und Dienste in der 2. NF
 
3.3 Dritte Normalform (3NF)
Eine Relation (Tabelle) ist in der dritten Normalform, wenn alle Datenfelder, die nicht Teil des Schlüssels sind, untereinander in keiner Abhängigkeit stehen. 
Das abhängige Datenfeld wird aus der Tabelle gelöscht, sofern sich die Inhalte dieses Datenfelds aus anderen Datenfeldinhalten berechnen oder bestimmen lassen (vgl. 2. Beispielaufgabe für die Anwendung der 3. NF).
Kann der Inhalt des Datenfelds nicht berechnet werden, wird das abhängige Datenfeld aus der Tabelle entfernt und gemeinsam mit dem Datenfeld, von dem es abhängt, in einer neuen Tabelle abgespeichert. Das Datenelement, von dem es abhängig ist, kann nun als Schlüsselfeld zur Verbindung der beiden Tabellen dienen oder es wird ein neues Schlüsselfeld eingefügt (vgl. 1. und 3. Beispielaufgabe für die Anwendung der 3. NF).

In unserem Beispiel gibt es keine Nicht-Schlüssel-Felder, die voneinander abhängig sind. Somit müssen unsere Tabellen nicht weiter verändert werden. In den folgenden Beispielaufgaben sind jedoch Fälle aufbereitet, in denen die 3. NF zum Einsatz kommt.
3.4 Beispielaufgaben für die Anwendung der 3. NF
a) Datenbankentwurf für eine Nachbarschaftshilfe (mit Preiskategorien)
Bei diesem Datenbankentwurf für eine Nachbarschaftshilfe ist in der Tabelle Dienste zusätzlich das Datenfeld Preiskategorie enthalten. Die Stadtverwaltung gibt 5 Preiskategorien vor, nach denen die Dienste bezahlt werden. 
Die Tabellen Anbieter, Angebot und Dienste in der 2. NF
In der 2. NF befinden sich beide Felder noch in der Tabelle Dienste. 
Der Preis für eine Dienstleistung ist jedoch abhängig davon, in welche Preiskategorie dieser Dienst eingeteilt wurde. Das Datenfeld Preis pro Std ist also abhängig vom Datenfeld Preiskategorie und das Datenfeld Preiskategorie ist kein Teil des Schlüsselfelds. Deshalb werden beide Felder in die Tabelle Preis ausgelagert. Dort werden alle angebotenen Preiskategorien und ihre zugehörigen Preise einmalig abgespeichert. Die Tabellen Dienste und Preis werden über das Datenfeld (=Schlüsselfeld) Preiskategorie verbunden. In der Tabelle Dienste wird nur noch die Preiskategorie des Dienstes abgespeichert. Wenn die Gebühren einzelner Preiskategorien geändert werden, muss dies nur noch einmalig in der Tabelle Preis geschehen. Die Preiskategorie bleibt stets gleich.

Tabellen in der 3. NF
b) Datenbankentwurf für die Bearbeitung von Projekten in einer Firma
Tabellen in der 2. NF
Die Projektdauer ist vom Projektbeginn und vom Projektende abhängig. Denn ändert sich der Projektbeginn oder das Projektende, ändert sich auch die Projektdauer. Die Datenfelder Projektbeginn und Projektende sind aber keine Schlüsselfelder. Somit liegt ein Verstoß gegen die 3. NF vor.
Felder, die aus anderen Feldern bestimmt oder berechnet werden, werden nicht ausgelagert in eine eigene Tabelle, sondern gelöscht.
Das Datenfeld Projektdauer kann aus den Datenfeldern Projektende und Projektbeginn berechnet werden (Projektdauer =  Projektende - Projektanfang) und wird deshalb gelöscht.

Tabellen in der 3. NF
c) Db.entwurf für gebührenpflichtige Ausleihvorgänge in einer Bibliothek

Tabellen in der 2. NF
Die Gebühr für die Ausleihe in einer Bücherei ist abhängig davon, zu welcher Benutzergruppe man gehört (Schüler, Studenten, Rentner, usw.). Das Datenfeld Gebühr ist also abhängig vom Datenfeld Gruppe und das Datenfeld Gruppe ist kein Teil des Schlüsselfeldes. Deshalb werden beide Felder in die Tabelle Gruppen ausgelagert. Dort werden alle angebotenen Benutzergruppen und ihre zugehörigen Bibliotheksgebühren einmalig abgespeichert. Beide Tabellen Leser und Gruppen werden über das neu eingefügte Schlüsselfeld Gruppen-Nr. verbunden. In der Tabelle Leser wird nur noch die Gruppen-Nr. des Lesers abgespeichert. Wenn die Gebühren für einzelne Gruppen geändert werden, muss dies nur noch einmal in der Tabelle Gruppen geschehen. Die Gruppen-Nr. bleibt stets gleich.

Tabellen in der 3. NF
4. Die Tabellen in einem Datenbanksystem anlegen
Für die Realisierung des Datenbankentwurfs kann jedes gewünschte Datenbanksystem verwendet werden. Für die Erarbeitung der Punkte 8.3, 10.1 und 10.3 des Informatiklehrplans wurde MS-ACCESS verwendet. Man sollte bei der Arbeit an einer Datenbank nicht mit verschiedenen Versionen von MS ACCESS arbeiten. Denn eine mit MS-ACCESS erzeugte Datenbanken lässt sich meist nicht mehr mit einer niedrigeren Version von MS-ACCESS bearbeiten bzw. erst nach der Konvertierung in einer höheren Version verwenden. Ein Nachteil von MS-ACCESS ist zudem, dass die Datenbank in einer (sehr großen) Datei angelegt wird, die nicht gegen Veränderungen durch Benutzer geschützt ist. Erst nach Erwerb einer zusätzlichen Software kann eine geschützte und unabhängige Datenbankanwendung erzeugt werden. 

Die Schüler haben bereits in Punkt 8.3 des Informatiklehrplans gelernt wie Tabellen in MS-ACCESS angelegt werden. Für die Schlüsselfelder Anbieter-Nr und Dienst-Nr kann als Datenfeldtyp ‚Autowert’ oder ‚Zahl’ (integer) bzw. ‚Text’ gewählt werden. Beim Datentyp ‚Autowert’ vergibt MS-ACCESS automatisch eine fortlaufende Nummer. Der Datenfeldinhalt der Schlüsselfelder kann vom Anwender nicht mehr geändert werden. Beim Datentyp ‚Zahl’ vergibt der Anwender die Nummern und muss selbst darauf achten, dass keine Nummer unbeabsichtigt zweimal vergeben wird. Der Datentyp ‚Text’ empfiehlt sich, wenn die Schlüsselfeldinhalte aus Buchstaben und Nummern bestehen sollen (z. B. A01, A02 usw. für die Anbieter-Nr bzw. D01, D02, usw. für die Dienst-Nr)

Nach dem Anlegen der drei Tabellen Anbieter, Angebot und Dienste sollten die Schüler mindestens 20 Datensätze je Tabelle eingeben und abspeichern.
 
Download-Bereich
Datenbank nachbar.mdb (180 KB)
(Tabellen mit Datensätzen)		 nachbar.mdb