Informationssyteme

Hinweis: Diese Wiki-Version des Textes ist noch nicht ganz fertiggestellt

Information ist im Informationszeitalter von ganz zentraler Bedeutung, ihre Bedeutung wird oft ver­glichen mit der der Industrie im Industriezeitalter. Information muss daher in geeigneten Systemen ge­speichert werden und jederzeit und einfach verfügbar sein. Den dafür zuständigen Informationssyst­emen, meist Datenbanken, fällt daher eine wichtige Aufgabe zu.

Der Bereich Datenbanken/Datenbanksysteme gehört zu den Kern-Inhalten der Informatik. In diesem Bereich gibt es auch umfangreiche Theoriegebäude, die deutlich machen, dass Informatik eine Wis­senschaft ist und wesentlich mehr umfasst, als nur Programmierung.

Diese Bedeutung wird auch dadurch unterstrichen, dass dieses Thema verpflichtend ist für den Unter­richt in der Vorstufe der gymnasialen Oberstufe.

Der vorliegende Text gliedert sich in folgende Teile:

I. Datenschutz

II. Projektmanagement

III. Modellbildung

IV. PHP

V. MySQL

VI. Einbindung von MySQL in PHP

VII. Erweiterte Möglichkeiten in MySQL

VIII. Beispielaufgaben

IX. Anhang

I. Datenschutz

In den folgenden Abschnitten werden wir uns mit der Verarbeitung von Daten, auch personenbezoge­nen Daten auseinander setzen. Deshalb ist es wichtig, vorweg ein paar Gedanken auf das Thema Da­tenschutz zu richten.

Dabei gibt es mehrere sehr unterschiedliche Aspekte:

• Schutz der Daten vor
  • Diebstahl
  • Veränderung
  • Löschung
• Schutz des Einzelnen vor
  • Speicherung unnötiger Daten
  • Speicherung falscher Informationen
  • Verknüpfung von Datenbeständen

1. Datensicherheit/Technischer Datenschutz

Relativ einfach wirkt, zumindest auf den ersten Blick, ist der technische Datenschutz, also der Schutz der Daten. Hier ist mit klassischen Techniken wie abschließbaren Räumen, Zugangskontrollen und Si­cherungskopien leicht ein gewisser Standard erreichbar. Obwohl hier auch die zunehmende Vernet­zung der Rechner neue Probleme schafft, was nützt das beste Schloss, wenn der Einbrecher über die Datenleitungen eindringt. Ein gro­ßer Teil dieser Einbrüche bleibt vermutlich unentdeckt. Ein gro­ßes Problem für die Datensicherheit stellen die aktuellen Viren und Würmer dar.

2. Datenschutz

Hier soll es hauptsächlich um den Datenschutz im grundrechtlichen Sinne gehen. Grundlage für das Datenschutz-Recht in Deutschland ist ein Urteil des Verfassungsgerichts vom 1967, in dem es heißt:

„Der Staat darf durch keine Maßnahmen, auch nicht durch ein Gesetz, die Würde des Menschen ver­letzen oder sonst über die in Art. 2 Abs. 1 GG gezogenen Schranken hinaus die Freiheit der Per­son in ihrem Wesensgehalt antasten. Mit der Menschenwürde wäre nicht zu vereinbaren, wenn der Staat das Recht für sich in Anspruch nehmen könnte, den Menschen zwangsweise in seiner ganzen Persönlich­keit zu registrieren und zu katalogisieren, sei es auch nur in der Anonymität einer statis­tischen Erhe­bung, und ihn damit wie eine Sache zu behandeln, die einer Bestandsaufnahme in jeder Bezie­hung zu­gänglich ist."

Datenschutz gehört damit zu den Persönlichkeitsrechten, Grundrecht auf informationelle Selbstbe­stimmung.

In diesem Urteil geht es primär um das Verhältnis zwischen Staat und Bürger. Das Verfassungsge­richt wollte mit seinem Urteil den Bürger vor der Sammelwut des Staates schützen. Staatliche Stellen sind inzwischen auch nicht mehr das größte Problem für den Datenschutz, sondern die Vielzahl von Datenbanken bei nichtstaatlichen Stellen.

Durch die technische Entwicklung ist es möglich geworden eine Unmenge von Daten über jeden ein­zelnen Bürger zu erfassen und in Sekundenschnelle zusammenzufassen und auszuwerten. Damit be­steht die Gefahr, dass wir alle zu gläsernen Bürgern werden, über uns also Persönlichkeitsprofile an­gelegt werden können.

Die einzelnen Daten, welche Bücher liest er, wie viel Alkohol trinkt er, wie oft fehlt er dann Mon­tags, welche politischen Magazine sieht er im Fernsehen..... werden und wurden schon immer in irgendei­ner Form erfasst.

Problematisch wird es immer dann, wenn all diese Daten zusammengeführt werden. Dies ist tech­nisch sehr leicht durchzuführen, da fast alle Rechner, auf denen die Daten vorliegen, miteinander ver­netzt sind. Da hier also technisch die Möglichkeit des Missbrauchs besteht, ist es Aufgabe der Schule für diese Gefahr zu sensibilisieren und Aufgabe des Gesetzgebers den juris­tischen Rahmen für den Schutz der personenbezogenen Daten zu liefern.

3. Gesetzliche Regelungen zum Datenschutz

Zum Datenschutz gibt es auf mehreren Ebenen Gesetze. Auf europäischer Ebene existiert seit 1995 eine Datenschutzrichtlinie die 2002 erneuert wurde (http://register.consilium.eu.int/pdf/de/01/st15/15396d1.pdf). National wäre hier das Bundesdatenschutzgesetz (BDSG) zu nennen, das 1978 in Kraft trat. Daneben gibt es dann noch in den einzelnen Bundesländern jeweils regionale Datenschutzgesetze. Das Hamburgische Datenschutzgesetz (HmbDSG) trat 1981 in Kraft. Beide Gesetze sind in der Zwischenzeit mehrfach überarbeitet worden. Alle drei Texte finden sich unter http://www.daten‑schutz-hamburg.de/. Weiterhin gibt es in vielen sonstigen Gesetzen Regelungen zum Datenschutz. Gern übersehen wurde z.B. der §98 des Hamburgischen Schulgesetzes: „(4) Eine Vernetzung von Datenverarbeitungsgeräten, auf denen Daten von Schülerinnen und Schülern und Erziehungsberechtigten verarbeitet werden, mit Datenverarbeitungsgeräten, die für Unterrichtszwecke verwendet werden, ist unzulässig. Lehrerinnen und Lehrer, die sich schriftlich zur Beachtung der datenschutzrechtlichen Vorschriften verpflichtet haben, dürfen zur Erfüllung ih­rer Aufgaben private Datenverarbeitungsgeräte zur Verarbeitung personenbezogener Daten von Schülerinnen und Schülern verwenden; sie unterliegen insoweit der Überwachung durch den Hamburgischen Datenschutzbeauftragten. Sie haben sicherzustellen, dass diese Daten vor dem Zu­griff Dritter geschützt sind und spätestens nach dem Ende des jeweils nächsten Schuljahres ge­löscht werden.“ Interessanterweise ist dieser Abschnitt bei der letzten Überarbeitung des Schulgesetzes weggefallen.

Worum es beim Datenschutz geht erläutert §4 des HmbDSG folgendermaßen: (1)Personenbezogene Daten sind Einzelangaben über persönliche oder sachliche Verhältnisse be­stimmter oder bestimmbarer natürlicher Personen (Betroffene, betroffene Personen). (2)Datenverarbeitung ist das Erheben, Speichern, Verändern, Übermitteln, Sperren, Löschen und Nutzen personenbezogener Daten. Im Einzelnen ist 1.Erheben das Beschaffen von Daten über Betroffene, 2.Speichern das Erfassen, Aufnehmen oder Aufbewahren von Daten auf einem Datenträger zum Zwecke ihrer weiteren Verarbeitung, 3.Verändern das inhaltliche Umgestalten von Daten, 4.Übermitteln das Bekanntgeben von Daten an Dritte in der Weise, dass die Daten weitergege­ben, zur Einsicht bereitgehalten oder veröffentlicht werden oder dass Dritte in einem automati­sierten Verfahren bereitgehaltene Daten abrufen, 5.Sperren das Verhindern weiterer Verarbeitung von Daten, 6.Löschen das Unkenntlichmachen von Daten oder das Vernichten des Datenträgers, 7.Nutzen jede sonstige Verwendung von Daten ungeachtet der dabei angewendeten Verfahren.

Grundsätzlich gehen die Datenschutzgesetze von folgender Grundidee aus: Die Verarbeitung personenbezogener Daten ist nur zulässig, soweit sie erforderlich ist, d.h. sie ist un­zulässig, wenn der angestrebte Zweck auch ohne sie erreicht werden kann.

Das Datenschutzgesetz unterscheidet drei Bereiche:

• Im öffentlichen Bereich (Schule, Arbeitsamt, Kreiswehrersatzamt,...) ist die Verarbeitung zuläs­sig, wenn sie zur rechtmäßigen Erfüllung der Aufgaben dieser Stellen erforderlich ist.
• Im nicht-öffentlichen Bereich ist die Verarbeitung für eigene Zwecke zulässig, wenn sie sich aus einem Vertrag oder einem vertragsähnlichen Verhältnis ergibt (Kundendateien, Personalinformati­onssysteme, ..), es sonstige berechtigte Interessen erfordern, und soweit keine schutzwürdi­gen Be­lange der Betroffenen beeinträchtigt werden.
• Im nicht-öffentlichen Bereich ist die Verarbeitung für fremde Zwecke (z.B. Adressverlage, De­tekteien, Meinungsforschungsunternehmen, ..) erlaubt, wenn kein Grund zur Annahme besteht, dass dadurch schutzwürdige Belange der Betroffenen beeinträchtigt werden.

Auch hier sieht man wieder, alles ist relativ. Von besonderer Bedeutung ist also eine Sensibilisierung der Bevölkerung. Solange die Ansicht „sol­len sie doch, ich hab' doch nichts zu verbergen“ noch weit verbreitet ist, hat der Datenschutz es schwer, da dann auch bei den „Tätern“ das Unrechtsbewusstsein fehlt. Und ohne entsprechendes Be­wusstsein nützt auch das beste Gesetz wenig.

4. Rechte des einzelnen Bürgers

Aus den Datenschutzregelungen ergeben sich für den einzelnen Bürger die folgenden Rechte:

1. Einwilligungs- und Benachrichtigungsrecht
   §4 des BDSG legt fest, dass der Bürger der Verarbeitung seiner Daten zustimmen muss, sofern nicht ein Gesetz die Verarbeitung erlaubt. Der §33 verpflichtet die speichernde Stelle sogar über die Speicherung von Daten zu informieren.
2. Auskunftsrecht
   Der §19 gibt jedem Bürger das Recht Auskunft über seine gespeicherten Daten und deren Her­kunft zu verlangen.
3. Berichtigungsrecht
   Über §20 und §35 ist geregelt, dass ein Anspruch auf die Berichtigung von fehlerhaften Daten be­steht.
4. Recht auf Sperrung
   Ist die Richtigkeit von Daten strittig, so müssen sie gesperrt werden, auch dies ist in §20 und §35 geregelt.
5. Recht auf Löschung
   Sind Daten fehlerhaft oder ihre Speicherung unzulässig, so müssen sie nach den Regelungen von §20 und §35 gelöscht werden.

5. Fehlerhafte Daten

Leider ist im Zusammenhang mit dem Datenschutz die Einstellung „Ich habe doch nichts zu verber­gen“ weit verbreitet. Selbst wenn man dies akzeptiert, so bleibt doch das Risiko von fehlerhaften Da­ten. Eine Studie (ftp://ftp.freenet.at/privacy/ds-at/dsstudie-ad-1999.pdf) im Auftrag des Bundesmi­nisteriums für Wissenschaft und Verkehr der Republik Österreich hat hier einmal Risikoabschätzun­gen vorgenommen:

Das Doppelgängerproblem Die Gefahr, Daten von Doppelgängern zu vertauschen und irrtümlich zu verknüpfen, wird allgemein unterschätzt. Eine Abschätzung für ganz Österreich (8,08 Millionen Einwohner) ergibt folgende Grö­ßenordnungen: mindestens 2,9 Millionen Personen haben einen Doppelgänger mit gleichem Familiennamen und gleichem Vornamen, mindestens 131.000 Personen haben einen Doppelgänger mit gleichem Familiennamen und glei­chem Geburtsdatum, rund 1.600 Personen haben einen Doppelgänger mit gleichem Familiennamen, gleichem Vorna­men und gleichem Geburtsdatum. Nicht berücksichtigt wurden dabei Namensähnlichkeiten oder Schreibvarianten. Einen Doppelgänger zu haben, ist daher ein relativ wahrscheinliches Ereignis und führt bei vielen nur oberflächlich geführten Datenverarbeitungen zu fehlerhaften Verknüpfungen von Daten verschieden­er Personen.“

Sonstige Fehler in Datenverarbeitungen Versucht man auf der Basis eines durchschnittlichen Prozentsatzes von 5% fehlerhafter Datensätze eine Abschätzung zu machen, ergibt sich folgende Größenordnung an Fehlern: Derzeit sind rund 81.000 Datenverarbeiter mit insgesamt 293.000 Verarbeitungen offiziell registriert. Wenn als untere Grenze von durchschnittlich 10.000 Betroffenen pro Datenverarbeitung ausgegangen wird, ergibt dies rund 145.000.000 fehlerhafte personenbezogene Datensätze.“

Die Einwohnerzahl in Deutschland liegt mit 80Mio etwa um das Zehnfache über der von Österreich, damit lassen sich die Zahlen relativ einfach hochrechnen.

6. Datenschutzbeauftragte

Die Datenschutzbeauftragten überwachen die Einhaltung der Normen und dienen auch als Ansprech­partner für Bürger, die ihre Rechte verletzt sehen. Dazu gibt es einen Bundes-Datenschutzbeauftrag­ten und in jedem Bundesland einen Landes-Datenschutzbeauftragten. In vielen Betrieben, vermutlich auch der Schulbehörde, gibt es auch interne Beauftragte für den Datenschutz.

Web-Adressen

• http://www.swisseduc.ch/informatik/material/glaesmensch/ Der gläserne Mensch, sehr ausführliche Präsentation der Gruppe um Werner Hartmann.
• http://www.datenschutz-hamburg.de/ Der Hamburgische Datenschutzbeauftragte.
• http://www.datenschutz.de Virtuelles Datenschutzbüro
• http://mediawiki.lern-server.de/index.php/18.912_SS_2008 Linksammlung

7. Beispiele

Hier folgen einige Meldungen aus den Medien im Zusammenhang mit dem Datenschutz. Weitere Beispiele finden sich im Anhang.

Beispiel1: Wie sein Handy den Täter überführte (HA vom 9.9.03)

Beispiel 2: Funketiketten für japanische Schulkinder (Heise News 11.7.04)

Beispiel3: Der Ausweis im Oberarm für Mexikos Strafverfolger (Heise News 15.7.04)

II. Projektmanagement

Um eine komplexere Datenbankanwendung erstellen zu können, muss man, bevor man sich über die Theorie von Datenbanken Gedanken machen kann, mit dem Prinzip des Projektmanagements be­schäftigen. Der folgende Text beschäftigt sich nur mit dem informatischen Projektbegriff, aus pädagogischer Sicht gibt es deutliche Unterschiede.

1. Grundlagen

Zum Thema Projekte findet sich in dem Buch „Die Kunst DV-Projekte zum Erfolg zu führen“ von Hedwig Kellner eine interessante Einleitung.

„Um mich herum saßen sechs gestandene Projektleiter, die mich unterstützen wollten, das Seminar für sie selbst und für ihre Kollegen zu entwickeln.

„Was passiert eigentlich in Ihrem Unternehmen, wenn ein Projekt gescheitert ist?“

Lächeln aus sechs Gesichtern.

Der humorigste der Herren kratzte sich schließlich spielerisch am Kopf, zwinkerte über den Brillen­rand und sagte: „Bei uns scheitern keine Projekte.“

Gelächter von allen.

„Optimal! Wenn alle ihre Projekte erfolgreich sind, dann brauchen Sie kein Seminar, dann reicht eine Party mit Sekt und Kaviar.“

Nein, so war es auch nicht.

Wie denn?“

Danach folgt dann eine Beschreibung, was mit Projekten passieren kann, ohne dass man sich das Scheitern eingesteht:

• Ein Projekt dümpelt: es läuft solange ohne Ergebnisse zu liefern, bis es von einem neuen Projekt oder einer Entscheidung von oben abgelöst wird.
• Ein Projekt verdunstet: es wird anfangs mit Mitarbeitern und Projektleitung ausgestattet. Im Laufe der Zeit werden dann aber immer mehr Mitarbeiter und auch der Projektleiter mit anderen Aufga­ben und Projekten betraut bzw. von diesem Projekt abgezogen.
• Ein Projekt verwest: In dem Projekt krachen Charaktere so aufeinander, dass produktive Arbeit nicht möglich ist. Man stiehlt sich gegenseitig Mitarbeiter und Ressourcen und verzettelt sich in Kämpfen.

Interessant sind in dem genannten Buch auch die aufgeführten Merkmale von Projekten

• es ist ein einmaliges Vorhaben,
• es ist zeitlich begrenzt durch Start- und Endtermine,
• es hat ein klares Ziel,
• es ist ein komplexes Vorhaben mit verschiedenen Techniken und Methoden,
• es macht die Zusammenarbeit von Menschen aus unterschiedlichen Fachgebieten und mit unter­schiedlichen Kenntnissen und unterschiedlichen Sprech- und Denkgewohnheiten erforderlich,
• es sind neuartige und unbekannte Probleme zu lösen,
• es stehen unter besonderem Risiko,
• es verfügt über ein eigenes Budget,
• er verfügt über ein klares Ergebnis.

Wenn man sich an diesen Merkmalen orientiert, dann wird deutlich, wie inflationär der Projekt-Be­griff heutzutage benutzt wird.

2. Phasen eines Projektes

Die Durchführung eines Projektes in der Informatik lässt sich prinzipiell in fünf Hauptphasen einteilen:

1. Projektumriss

In dieser ersten Phase geht es darum, den Problembereich zu umschreiben und abzugrenzen (Problemanalyse). Es muss geklärt werden, welche Anforderungen und Wünsche der Auftrag­geber bzw. der zukünftige Anwender an das zu erstellende Programm haben. In dieser Phase ist eine enge Zusammenarbeit zwischen Anwender und Entwickler sehr wichtig. Es sind fol­gende Dokumente zu erstellen: Ist-Zustandsbeschreibung: Wie wird die Arbeit, die von dem Programm übernommen wer­den soll, zur Zeit erledigt. Welche Arbeitsvorgänge gibt es. Pflichtenheft: Welche Eingaben bzw. Eingabedaten tauchen auf, welche Ausgaben werden benötigt. Das Pflichtenheft soll die Leistungsmerkmale des zu erstellenden Programms möglichst vollständig beschreiben. Es ist hinterher Richtschnur für die Realisierung des Programms. Arbeitsplan/Zeitplan: Hier wird versucht den Realisierungsaufwand und damit den Perso­nal- und Zeitbedarf abzuschätzen. Für den Zeitrahmen sollte man hier auch Meilensteine setzen, Zeitvorgaben für bestimmte Entwicklungsschritte.

2. Konzept

Auf der Basis des Pflichtenheftes erfolgt ein Grobentwurf von Lösungsvarianten. Dabei sind folgende Grundvarianten möglich: Übernahme einer vorhandenen Lösung: Sollte das Projekt an anderer Stelle schon einmal bearbeitet worden sein, so kann man versuchen die dortige Lösung zu kaufen. Einsatz eines Hilfssystems: Eine weitere Variante besteht darin, auf einem System wie z.B. Access aufzusetzen und ausgehend von diesem Datenbanksystem eine eigene Anwen­dung zu schreiben. Eigene Anwendungsentwicklung: Natürlich gibt es auch die Möglichkeit alles selbst zu ent­wickeln und auf den Zukauf fremder Software zu verzichten. Bei den Lösungsvarianten spielt nicht nur die technische Lösbarkeit eine Rolle, sondern auch wirtschaftliche Aspekte müssen mit einbezogen werden. Die einzelnen Varianten müssen so beschrieben und verglichen werden, so dass auf der Grundlage dieser Beschreibungen vom Auftraggeber eine Entscheidung getroffen werden kann, welche Variante realisiert werden soll.

3. Detailspezifikation

Nachdem entschieden ist, welche Variante realisiert werden soll, geht es darum, den Entwurf zu verfeinern. Das Gesamtproblem muss in handlichere funktionale Einheiten untergliedert werden. Diese Einheiten können dann durch verschiedene Module realisiert werden. Für diese Untergliederung ist es wichtig die Datenstrukturen und die Schnittstellen zwischen den einzelnen Einheiten verbindlich zu beschreiben, so dass hier arbeitsteilig realisiert wer­den kann. Es kommt hier also zu einer schrittweisen Verfeinerung (stepwise refinement) des Konzepts.

4. Programmierung

Erst wenn die Datenstrukturen und die Schnittstellen festgelegt sind, kann mit der eigentli­chen Programmierung begonnen werden. Hierbei werden eventuell weitere Verfeinerungen der Sys­temstrukturierung notwendig. Es ist wichtig, alle erstellten Programmteile so früh wie möglich auf Fehler zu testen, damit später nur fehlerfreie (kann es das geben?) Programmtei­le zusam­mengefügt werden.

Für sinnvolle Fehlertests ist es wichtig schon sehr früh Daten bereitzustellen, an denen die Programme getestet werden sollen, bzw. die für den späteren Betrieb benötigt werden. Einige Ansätze der Programmierung sind wesentlich konsequenter und führen dazu erst Test bzw. Testklassen zu definieren, bevor man mit der eigentlichen Programmierung beginnt. Das Arbeiten mit Tests und Testklassen wird z.B. von Java-Entwicklungsumgebungen wie Eclipse und BlueJ gut unterstützt.

5. Systemtest

Das fertig erstellte System, bzw. schon all seine einzelnen Einheiten müssen systematisch und umfassend getestet werden. Hierbei bietet es sich an, im Bottom-up-Verfahren schrittwei­se zu testen und zusammenzubauen. Je später ein Fehler entdeckt wird, desto mehr Aufwand kostet seine Beseitigung. Für den Systemtest bietet sich eine klare (auch personelle) Trennung zwischen Programmie­rer und Programmprüfer an. Ein großes Problem ist die Bereitstellung geeigneter Testdaten. Einerseits sollen die Daten ei­nen Bezug zu den realen Anforderungen bieten, andererseits müssen auch die Grenzen des Programms ausgetestet werden.

6. Systemeinführung

Der letzte Schritt des Projekts ist die Einführung des Systems beim Anwender. Hier wird dann das vollständig fertiggestellte und getestete System in seine betriebliche Umgebung einge­führt. Die Schulung der Anwender muss schon vor der Einführung durchgeführt worden sein, um eine problemlose Umstellung zu erlauben. In diesem Zusammenhang wird auch eine ausführliche Dokumentation und Bedienungsanlei­tung wichtig. Falls sich hier noch Fehler finden, wird der Aufwand zu ihrer Beseitigung groß, da nun mit­ten im laufenden Betrieb nachgebessert werden muss.

Spätestens bei der Systemeinführung stellt sich dann auch heraus, ob das Produkt den Vorstellungen des Auftraggebers entspricht oder nicht. Für Streitfälle lässt sich nun das Pflichtenheft Punkt für Punkt abhaken oder eben nicht.

Neben dem hier beschriebenen Wasserfall-Modell gibt es auch andere, z.T. modernere Modelle für das Projektmanagement. Weit verbreitet ist das eXtreme Programming (XP), welches in den OOSE-Seminaren der Universität Hamburg genutzt wird.

XP berücksichtig sowohl den Kunden und seine Änderungswünsche als auch die Möglichkeiten der Entwickler berücksichtigt. Vor allem die hohe Bedeutung der Änderungswünsche macht XP zu einem leichtgewichtigen und flexiblen Prozess. Natürlich müssen auch hier einige Regeln eingehalten werden, damit die Anwendung am Ende die gewünschte Qualität aufweist und alle Kundenwünsche umsetzt.

XP folgt laut (http://www.jeckstein.com/papers/basProXP.pdf) bestimmten Grundprinzipien.

1.Develop for today

Man konzentriert sich auf die Probleme, die heute anstehen, ohne Probleme vorwegzunehmen, die später auftreten könnten. Das hätte ja nur dann Nutzen, wenn wir bereits heute wüssten, welche Änderungen in Zukunft eintreffen werden. Sollten diese Änderungen später nicht eintreffen, hätten wir weiterhin den architektonischen Ballast in unserem Design. Entwicklung auf XP-Art bedeutet deshalb, sich ausschließlich auf die aktuellen Probleme zu konzentrieren. Es wird davon ausgegangen, dass eine Änderung jederzeit und mit vertretbarem Aufwand eingearbeitet werden kann. Das ist jedoch nur dann möglich, wenn die zweite Forderung berücksichtigt wird:

2.Do the simplest thing that could possibly work

Das bedeutet, dass immer das einfachste Design (Simple Design) verwendet wird, um ein Problem zu lösen. Simple Design enthält verschiedene Aspekte: Erfüllung der Anforderungen. Das Design muss der Aufgabe gerecht werden, wie sie zu diesem bestimmten Zeitpunkt verstanden wird.

Redundanzfreiheit: Jede Information darf nur einmal gehalten werden.

Refactoring: Das Design besteht aus der geringst möglichen Anzahl an Klassen, Attributen und Methoden. Das erfordert natürlich, dass sich das Design ständig im Fluss befindet. Wann immer das Design zu komplex wird, sollte es unter Beachtung der oben angeführten Aspekte vereinfacht werden.

3. Qualitätssicherung

Ein großes Problem beim Erstellen umfangreicherer Software ist und bleibt die Qualitätssicherung. Ein paar Schlagworte sollen umreißen, was man unter der Qualität von Software-Produkten verste­hen kann:

• Vollständigkeit der Funktionen
• Zuverlässigkeit
• Fehlertoleranz
• Benutzerfreundlichkeit
• Flexibilität
• Modularität
• Einfachheit
• Ausbaufähigkeit
• Wartbarkeit
• Ergonomie
• ...

Es gibt zwei Techniken, die für die Sicherung der Qualität wichtig sind:

• die Modularisierung durch schrittweise Verfeinerung und
• das sorgfältige Testen aller Module.

III. Modellbildung

Beim Entwickeln einer Datenbank (Datenbank-Design) bildet man einen Teil der Welt, der für eine bestimmte Aufgabenstellung relevant ist, auf eine Datenverarbeitungsanlage ab. Hier handelt es sich also um einen Modellbildungs-Prozess, wie er in allen Wissenschaften in irgendeiner Form üblich ist.

1. Der Modellbegriff

Die Wirklichkeit ist heute in so vielen Bereichen so komplex geworden, dass der menschliche Denk­apparat nicht mehr ausreicht, um die Systeme, deren Teil wir selber sind, fehlerfrei zu begreifen. Die einzige Möglichkeit hier überhaupt einen Ansatz zum Begreifen zu finden, besteht darin, sich ein Modell zu entwerfen.

Ein Modell ist eine beziehungserhaltende Darstellung oder Beschreibung eines Ausschnittes der Wirklichkeit mit den Mitteln einer natürlichen oder künstlichen Sprache. Bei der Modellbildung kommt es zur Abstraktion, Idealisierung und vor allem Komplexitätsreduzie­rung.

Die Definition lässt sehr unterschiedliche Klassen von Modellen zu, z.B. physikalische, hierzu gehö­ren Schiffsmodelle, elektrische Eisenbahnen oder formale Modelle, hierzu gehören Modelle der Ma­thematik und Informatik.

Bei der Beurteilung von Modellen gibt es eigentlich weniger ein Richtig oder ein Falsch, als eher ein Brauchbar oder Unbrauchbar. Die Frage der Brauchbarkeit eines Modells ist immer auch von der Fra­gestellung abhängig. So ist z.B. das Bohr'sche Atommodell nicht falscher als das wellenmechani­sche Atommodell. Für die Probleme der organischen Chemie ist aber das Bohr'sche Atommodell we­niger brauchbar.

In vielen Bereichen, auch der Mathematik, ist es geradezu sinnlos nach der Richtigkeit eines Modells zu fragen. Was man normalerweise nur fordert, ist die Widerspruchsfreiheit, und oft auch die Brauch­barkeit. Gerade der Modellbegriff wird in der Schule leider viel zu selten hinterfragt, da er vor allem die exakten Naturwissenschaften relativiert.

2. Modellbildung bei Datenbanken, das Entity Relationship Modell (ERM)

Das 1976 von Peter Chen vorgestellte Entity Relationship Modell ist heutzutage meist der erste Modellbildungsschritt bei der Entwicklung eines Datenbanksystems.

Den bei der Modellbildung dargestellten Teil der Wirklichkeit bezeichnet man als System oder Mini­welt. Innerhalb dieser Miniwelt lassen sich Objekte identifizieren:

3. Charakterisierung von Objekten

Ein Objekt (Entity, Entität) ist ein eindeutig identifizierbares Element der Miniwelt.

Ein Objekt kann sein:

• eine natürliche oder juristische Person (Karl Meier, Bundesbahn ..)
• ein Gegenstand (Kinderfahrrad der Marke Puky, Computer AMD K7 ..)
• immaterielle Dinge und Sachverhalte (Nichtversetzung von Karl ..)

Der erste Schritt bei der Datenbankentwicklung ist die Festlegung der Elemente der Miniwelt, die als Objekte gewählt werden sollen.

Alle gleichartigen Objekte der Miniwelt können unter einem gemeinsamen Oberbegriff, dem Objekt­typ (Entitytyp, Entitätstyp) zusammengefasst werden.

Im Rahmen der Schule (als Miniwelt) wird man z.B. die Objekttypen Schüler und Lehrer identifizie­ren können. Karl Meier ist dann eine konkrete Ausprägung des Objekttyps Schüler.

Bei der Auswahl der Objekttypen ist es wichtig darauf zu achten, dass diese nicht zu allgemein ge­fasst werden. So wäre es denkbar Schüler und Lehrer unter dem gemeinsamen Objekttyp Mensch zu­sammenzufassen. Doch für die Charakterisierung eines Lehrers sind in dieser Miniwelt andere Eigen­schaften wichtig, als bei einem Schüler. Bei einem Lehrer wäre z.B. die Wochenarbeitszeit bzw. die Unter­richtsfächer eine wichtige Eigenschaft, für einen Schüler aber eher das Eintrittsdatum in die Oberstufe oder dergleichen. Eine derartige Zusammenfassung wäre hier also nicht sinnvoll.

4. Definition von Attributen

Über jedes Objekt der Miniwelt lassen sich Aussagen machen. Jeder Schüler hat z.B. einen Namen und einen Vornamen.

Derartige Eigenschaften nennt man Attribute, die bei einem bestimmten Objekt auftretenden Werte Attributwerte.

Mit den Attributen und ihren Werten kann man

• ein bestimmtes Objekt durch Festhalten seiner Eigenschaften beschreiben (charakterisieren)
• ein bestimmtes Objekt von anderen Objekten unterscheiden (identifizieren).

Nun kann man auch den Begriff Objekttyp sinnvoll definieren:

Ein Objekttyp ist der Oberbegriff für eine Menge von Objekten der Miniwelt, die die gleichen Attribut­e besitzen. Jeder Objekttyp erhält einen für das Datenmodell eindeutigen Namen.

• Ein Attribut kann für jedes Objekt höchstens einen Wert besitzen, der der zugehörigen Objektei­genschaft entspricht. Der Wert der Attributes Vorname beim Objekt Karl Meier kann nicht gleich­zeitig 'Karl' und 'Heinz' sein. Natürlich könnte der Wert des Attributs Vorname bei einem Objekt 'Karl-Heinz' sein.
• Ein Wert ergibt nur zusammen mit seinem Attribut eine eindeutige Aussage über eine Objektei­genschaft. 'Martin' kann der Wert des Attributs Vorname von Martin Müller sein, aber auch der Wert des Attributs Nachname bei Michael Martin.
• Ein Attribut kann für ein Objekt zu einem bestimmten Zeitpunkt keinen Wert besitzen, z.B. weil er im Augenblick nicht bekannt ist.

Zuerst werden für jedes Objekt der Miniwelt die relevanten Eigenschaften gesammelt und erfasst. Was 'relevant' ist, entscheidet der Anwender aufgrund seiner Informationsanforderungen. Objekte mit gleichen bzw. weitgehend gleichen Eigenschaften werden im Datenmodell zu einem Objekttyp abs­trahiert. Die Schuhgröße wird man bei Objekten vom Typ Schüler sicherlich nicht benötigen, sie gehört da­mit nicht zur Miniwelt. Jeder Eigenschaft muss innerhalb des Objekttyps ein eindeutiger Name zugeord­net werden, z.B. Adresse für die Anschrift eines Schülers. Die gefundenen Attribute müssen auf Zerlegbarkeit und Ersatz eines einzelnen Attributs durch meh­rere Attribute überprüft werden. Das Attribut Adresse könnte man zerlegen in die Attribute

• Postleitzahl
• Ort
• Straße
• Hausnummer

Die Zerlegung des Attributs Adresse ist willkürlich und hängt von den Erfordernissen des Anwen­ders ab. Wer z.B. Massendrucksachen an 'seine Objekte' versenden will, der benötigt die Trennung von Ort und Postleitzahl um das Porto zu senken. In diesem Zusammenhang kann es sogar sinnvoll sein, das Attribut Postleitzahl weiter zu zerlegen.

5. Identifizierung von Objekten

Einzelne Objekte der Miniwelt sind in aller Regel voneinander eindeutig unterscheidbar. Diese Unter­scheidbarkeit (Identifizierbarkeit) der Objekte ist über deren Attribute und Attributwerte mög­lich.

Die minimale Kombination aller Attribute, durch deren Wert ein bestimmtes Objekt eindeutig identifiz­iert wird, heißt Primärschlüssel. Ein Primärschlüssel, der sich aus mehreren Attributen zusammensetzt, wird zusammengesetzter Pri­märschlüssel genannt. Ein Attribut eines zusammengesetzten Primärschlüssels wird als Teil­schlüssel bezeichnet.

Oft gibt es keine Kombination von Attributen, die sich als Primärschlüssel eignet. Beim Objekttyp Schüler würden die Attribute 'Name', 'Vorname' und 'Geburtsdatum' zusammen immer noch nicht aus­reichen, um mehrdeutige Werte auszuschließen. In solchen Fällen muss man ein neues Attribut als künstlichen Primärschlüssel einführen. Das Attribut Schüler# (# steht für Nummer) wäre ein sol­cher künstlicher Schlüssel.

Künstliche Primärschlüssel sollten so kurz wie möglich gewählt werden, um die Handhabbarkeit und Übersichtlichkeit zu erhöhen. Klassifizierende Primärschlüssel, z.B. erster Buchstabe des Nachna­mens+erster Buchstabe des Vornamens+Geburtsjahr sind zu vermeiden, da ein korrekt definiertes At­tribut nicht weiter unterteilbar sein soll.

6. Beziehungen (Relationen)

In der Miniwelt gibt es nicht nur Objekte, sondern diese Objekte stehen auch in vielfältigen Abhän­gigkeiten und Beziehungen zueinander.

In klassischen ER-Modell werden Entitäts-Typen durch Rechtecke, Attribute durch Kreise/Ellipsen und Beziehungen durch Rauten dargestellt. Hervorzuheben ist, dass auch eine Beziehung Attribute be­sitzen kann (s.u.).

Bei diesen Beziehungen kann man vereinfacht drei Typen unterscheiden:

1:1 Beziehungen

Hier steht ein Objekt mit genau einem Objekt in Beziehung. Ein typisches Beispiel hierfür wäre die Beziehung 'verheiratet'. Hier steht ein Element des Typs Mensch mit einem Objekt des Typs Mensch in Beziehung.

1:N Beziehung

Ein Beispiel für eine derartige Beziehung wäre „Tutor“. Ein Element des Typs Lehrer kann mehrere Elemente des Typs Schüler als Tutand haben. Aber ein Schüler kann nur einen Tutor haben.

M:N Beziehung

Ein Schüler wird von mehreren (M) Lehrern unterrichtet. Ein Lehrer unterrichtet aber auch mehrere (N) Schüler. Die Beziehung 'unterrichtet' ist also eine M:N Beziehung.

Beschreiben wir unsere Miniwelt als eine Menge von Objekten, zwischen denen beliebige Beziehun­gen bestehen, dann erhalten wir ein Netzwerk, in dem die Objekte durch unterschiedliche Beziehun­gen miteinander verknüpft sind. Kennt eine Datenbeschreibungssprache Objekte (Entities) und belie­bige Beziehungen (SETS), dann können solche Netzwerke mit ihr beschrieben werden. Sie führt zu Netzwerkdatenbanken:

Lässt man zur Beschreibung eines Systems nur hierarchische (1:N) Beziehungen neben den Objekten zu, dann kommt man zu einer hierarchischen Datenbank:

Auf dem theoretischen Sektor recht aktuell ist das objektorientierte Datenmodell. Hier wird versucht, die Elemente über eine Klassenstruktur objektorientiert zu modellieren. Bisher befinden sich derarti­ge Systeme noch weitgehend im Entwicklungs- bzw. Erprobungsstadium, besitzen also noch keine prak­tische Bedeutung.

Natürlich kann man auch Beziehungen als Objekte betrachten. Bei diesem Ansatz spricht man dann allgemeiner von Relationen statt von Objekttypen bzw. Beziehungstypen. Ein solches Daten­modell besteht dann aus einer Reihe von Tabellen (oder Relationen). Auf diese Art kommt man zu einer rela­tionalen Datenbank.

Relationale Datenbanken sind aber nur dann einsetzbar, wenn auf die Speichermedien ein wahlfreier Zugriff möglich ist. Bei der Nutzung von Magnetbändern als Speichermedium ist der Einsatz relationaler Datenbanken kaum denkbar, hier sind hierarchische Datenbanken deutlich passender.

Im weiteren Text soll nur noch von diesen relationalen Datenbanken die Rede sein.

7. Das relationale Datenmodell

Der Übergang vom ER-Model zum relationalen Datenbankmodell (RDM) ist ein erneuter Modellie­rungsschritt, bei dem aber die Komplexität anwächst, da für die konkrete Implementierung der Daten­bank weitere Informationen notwendig sind.

Im relationalen Datenmodell werden alle Informationen (Objekte und Beziehungen) in Form von zwei­dimensionalen Tabellen (Relationen) niedergelegt. Jede Relation besitzt folgende grundlegende Merkmale:

• Die Tabelle ist zweidimensional
• Die Spalten der Tabelle entsprechen den Attributen. Die Anordnung der Spalten innerhalb der Ta­belle ist beliebig.
• Die Zeilen der Tabelle entsprechen den Objekten. Die Anordnung der Zeilen in innerhalb der Ta­belle ist beliebig.

8. Normalformen

Ein wichtiger Schritt beim Entwurf einer Datenbank ist die Normalisierung der Datenstrukturen. Hier­bei werden Redundanzen und Anomalien verhindert und unerwünschte Eigenschaften erkannt. Hierzu gleich ein Beispiel: Gegeben ist die Relation

Dozent-un(Dozenten#, D-Name, Schul#, S-Adresse, Hörer#, H-Name, Kurs, K-Tage)

Diese Relation soll das Fortbildungssystem einer multinationalen Firma beschreiben, die Fortbil­dungszentren in verschiedenen Städten besitzt. Die zugehörige Tabelle könnte folgendermaßen ausse­hen:

Dozent-un

Dozenten#	D-Name	Schul#	S-Adresse	Hörer#	H-Name	Kurs	K-Tage
4711	Meier	001	München	8001	Huber	Cobol	10
4750	Schmidt	003	Wien	8001 8432	Huber Müller	APL Basic	15 5
5000	Adam	003	Wien	8432	Müller	Cobol	10
6000	Wang	003	Berlin	8001 8432	Max Moritz	Cobol APL	10 10
...	...	...	...	...	...	...	...

Diese Tabelle besitzt eine Reihe von Problemen mit sich (sie ist nicht normalisiert): Redundanz, der Name Huber z.B. tritt mehrfach auf, neben seiner Hörernummer. An den Kreuzungspunkten der Zeilen und Spalten stehen teilweise mehrere Werte (z.B. Max und Moritz). Fehlende Konsistenz der Daten, zur Schulnummer 003 taucht mal der Schul-Ort Wien, mal Berlin auf. Entsprechend Hörernummer 8001 hat mal den Namen Huber, mal Max. Wird Herr Huber aus dem Cobol-Kurs abgemeldet, so verschwinden auch alle Angaben über den zugehörigen Dozenten. Dies wird als Löschungsanomalie bezeichnet.

Um diese Probleme möglichst weit zu vermeiden, wird die Relation über Zwischenschritte in die drit­te Normalform gebracht.

Erste Normalform (1NF)

Eine Relation befindet sich dann in der ersten Normalform, wenn jeder Kreuzungspunkt von Zeile und Spalte nur maximal einen Wert besitzt.

Diese Regel ist eigentlich recht naheliegend, trotzdem gibt es Datenbanksysteme, mit denen man ge­gen sie verstoßen kann. Ein Beispiel dafür ist das Produkt Filemaker, das ursprünglich aus der Mac-Welt stammt, aber auch für Windows verfügbar ist. Auch MS-Access lässt entsprechende Verstöße zu.

Diese Forderung ist im vorliegenden Fall recht einfach zu erreichen:

Dozent-1NF

Dozenten#	D-Name	Schul#	S-Adresse	Hörer#	H-Name	Kurs	K-Tage
4711	Meier	001	München	8001	Huber	Cobol	10
4750	Schmidt	003	Wien	8001	Huber	APL	15
4750	Schmidt	003	Wien	8432	Müller	Basic	5
5000	Adam	003	Wien	8432	Müller	Cobol	10
6000	Wang	003	Berlin	8001	Max	Cobol	10
6000	Wang	003	Berlin	8432	Moritz	APL	10
...	...	...	...	...	...	...	...

Die restlichen Probleme dieser Relation sind geblieben. Neu ist, dass nun die Hörer# mit in den Primärschlüssel einbezogen werden muss, da die Dozenten# alleine nicht mehr ausreicht.

Zweite Normalform (2NF)

Eine Relation befindet sich dann in zweiter Normalform, wenn sie sich in 1NF befindet und jedes nicht dem Schlüssel angehörende Attribut vom Gesamtschlüssel, aber nicht von Teilschlüsseln funk­tional abhängig ist.

Hier steckt ein Begriff drin, der erst einmal erläutert werden muss:

Ein Attribut B ist von einem Attribut A dann funktional abhängig, wenn von jedem Attributwert A di­rekt auf den Attributwert B geschlossen werden kann.

In unserem Fall ist das z.B. das Attribut D-Name von der Dozenten# funktional abhängig und Dozen­ten# ist ein Teilschlüssel.

Entsprechend ist das Attribut H-Name vom Attribut Hörer# funktional abhängig. Um diese Abhängigkeiten zu beseitigen, muss die Tabelle aufgespalten werden in drei neue Tabellen:

Hörer

Hörer#	H-Name
8001	Huber
8432	Müller
...	...

Dozent-2NF

Dozenten#	D-Name	Schul#	S-Adresse
4711	Meier	001	München
4750	Schmidt	003	Wien
5000	Adam	003	Wien
6000	Wang	003	Berlin
...	...	...	...

Hörer-Dozent

Dozenten#	Hörer#	Kurs	K-Tage
4711	8001	Cobol	10
4750	8001	APL	15
4750	8432	Basic	5
5000	8432	Cobol	10
6000	8001	Cobol	10
6000	8432	APL	10
...	...	...	...

Ein Teil der Probleme unserer Relation ist durch den Normalisierungsprozess bereits beseitigt: da Dozenten# ein Primärschlüssel ist, kann es nicht zwei Dozenten mit der gleichen Dozenten# geben analog für Hörer und Hörer#

Einige Anomalien bleiben trotzdem möglich: es ist immer noch möglich Inkonsistenzen bezüglich Schul# und S-Adresse zu erzeugen auch bei Kurs und K-Tage sind widersprüchliche Eingabe möglich.

Wir müssen unsere Relation noch weiter normalisieren (zerlegen).

Die dritte Normalform (3NF)

Eine Relation ist dann in dritter Normalform, wenn diese sich in zweiter Normalform befindet und nicht dem Schlüssel angehörende Attribute voneinander nicht funktional abhängig sind.

In unserem Beispiel ist die S-Adresse von der Schul# funktional abhängig. Ebenso ist K-Tage von Kurs funktional abhängig.

Wir spalten also noch einmal auf und erhalten folgende Relationen:

Hörer

Hörer#	H-Name
8001	Huber
8432	Müller
...	...

Dozent-3NF

Dozenten#	D-Name	Schul#
4711	Meier	001
4750	Schmidt	003
5000	Adam	003
6000	Wang	003
...	...	...

Schule

Schul#	S-Adresse
001	München
003	Wien
...	...

Hörer-Dozent

Dozenten#	Hörer#	Kurs
4711	8001	Cobol
4750	8001	APL
4750	8432	Basic
5000	8432	Cobol
6000	8001	Cobol
6000	8432	APL
...	...	...

Kurs

Kurs	K-Tage
Cobol	10
APL	15
Basic	5
...	...

Zusammenfassung Durch diese Zerlegungen sind nun alle erwähnten Speicheranomalien beseitigt. Insgesamt ist die Ab­bildung der Miniwelt beim Zerlegungsprozess sogar verbessert worden, da es nun möglich ist, einen Kurs einzugeben, ohne das gleichzeitig ein Hörer da sein muss.

Zusammenfassen kann man sagen, Normalisieren bedeutet:

• Erkennen und Beseitigen von Redundanzen
• Zerlegen von Relationen in mehrere Relationen
• Minimieren von Speicher-, Lösch- und Änderungs-Anomalien
• Realitätsgetreue Abbildungsmöglichkeit der Miniwelt schaffen
• Erhöhen der Transparenz des Datenmodells.

Für spezielle Anwendungen existieren noch weitere Normalisierungsregeln, die aber in unserem Zu­sammenhang keine Rolle spielen.

9. Datenbanken und Datenbankmanagementsysteme

Nach dem Abschluss der Modellbildung kommt in einem weiteren Schritt die Übertragung des Mo­dells in eine konkrete Datenbank. Dabei muss erst einmal geklärt werden, was eine Datenbank über­haupt ist. Dazu findet man sehr unterschiedliche Definitionen:

„Eine Datenbank ist eine strukturierte Sammlung von Daten“ (Heinz-Gerd Raymans, MySQL im Ein­satz, München 2001).

Oder „Eine Datenbank ist eine einheitlich beschriebene Darstellung eines Weltausschnittes mittels diskreter Daten auf persistenten Speichermedien“ (Günter Leitenbauer, Datenbankmodellierung, Poing 2003).

Wenn man Menschen fragt, welche Datenbanken sie kennen, dann fallen sicher Namen wie Access, MySQL, ORACLE und ähnliche. Dabei sind dies keine Datenbanken, sondern Datenbankmanage­mentsysteme (DBMS). Ein DBMS ist ein System, welches dazu da ist Datenbanken zu verwalten. Es legt sich zwischen die Anwendung und die jeweiligen Datenbanken.

Die Anwendung selber erhält keinen direkten Zugriff auf die Datenbank, dafür können aber mehrere Anwendungen auf die gleiche Datenbank zugreifen. Die Nutzung eines DBMS bietet eine Reihe von Vorteilen:

1. Plattformunabhängigkeit

Es spielt keine Rolle, auf welcher Plattform bzw. welchem Betriebssystem das DBMS läuft. Es ste­hen für verschiedene Umgebungen die gleichen Funktionen und Schnittstellen zur Verfügung. Wichtig ist nur, dass das DBMS für das System, auf dem das Anwendungsprogramm läuft, eine Clientsoftware anbietet. Mit der Art und Weise, wie die Daten auf dem Datenträger gespeichert werden, hat die Anwendung nichts zu tun.

2. Integrierte Konsistzenprüfung

In ein DBMS sind normalerweise Tools zur Konsistenzprüfung integriert, die müssen dann im An­wendungsprogramm nicht vorhanden sein. Wenn z.B. ein Datenfeld (Attribut) als Unique defi­niert wurde, dann lehnt das DBMS die Einfügung eines zweiten Datensatzes mit dem gleichen Wert in diesem Datenfeld ab.

3. Skalierbarkeit

Ein modernes DBMS ist unempfindlich gegen stark wachsende Datenmengen. Zum Teil ist auch die Verteilung der Datenbanken über mehrere Server möglich, was die Skalierbarkeit deutlich er­leichtert.

4. Standardisierte Zugriffsmethoden

Eigentlich jedes DBMS bietet eine SQL-Schnittstelle an, über die nahezu alle Aufgaben erledigt werden können. Damit lassen sich Anwendungen auch zwischen unterschiedlichen DBMS portie­ren, zumindest prinzipiell.

5. Sperrmechanismen

Ein DBMS kann sich darum kümmern, dass keine konkurrierenden Zugriffe auf die gleichen Da­tensätze erfolgen. Das geht so weit, dass teilweise sogar mehrere Vorgänge zu einer Transaktion zusammengefasst und auch wieder als Ganzes rückgängig gemacht werden können.