Mo's db_Designer II Version 1.00

Das Handbuch

Copyrights by Mo & friends  1991, 1992, 1993

Bevor es losgeht

Das obligatorische Vorwort

Wie benutzen Sie die Hilfe

Warum einen db_Designer II?

Eine Einführung

Etwas über die Theorie der Datenbank-Modelle

Eine Datenbank "Quick and dirty"

Die Menues

Das Projekt-Menue

Das Datenbank-Menue

Die Dialoge

Die Buttons

Ein neues Projekt

Eine neue Datenbank

Ein Projekt oder eine Datenbank öffnen

Die Felder eines Datensatzes definieren

Eine Beschreibung erstellen

Der db_Compiler

Die Quick-Hilfe

Eine Meldung, was dann?

About db_Designer II (Information zum db_Designer II)

Wer ist Mo?

Das Beenden des db_Designer II

Tips und Tricks

Das Glossar

Stichworte

Definitionen

Vergleichstabelle der Datentypen

Die Meldungen

Allgemeine Meldungen

Die Katastrophen-Meldungen

Der Support

Die Telefon-Hotline

Das Bulletin Board System

Einige wichtige Adressen

Die Literatur

Etwas zum entspannen

Hoch Wissenschaftliches

Zum Schluß

Das Wort zum Schluß


Das obligatorische Vorwort

Zitat: entn. J. Graf, Murphys Computergesetze

Die allgemeine Ausrede:

''Das stand nicht im Handbuch!''

Die erweitere allgemeine Ausrede:

''Jemand hat sich mein Handbuch ausgeliehen!'' "

Hallo lieber Anwender des db_Designer II...

Unser Handbuch ist Absicht?!

Wir liefern zu Mo's db_Designer II absichtlich kein dickes Handbuch.

Diese Überlegung beruht auf zwei unserer Meinung wichtigen Gründen:

Grund eins

Wir wollen unsere gemeinsame Umwelt nicht durch noch mehr "Regalleichen", die später im Altpapier oder im Hausmüll begraben werden, belasten.

Grund zwei

Wir meinen, daß Sie als Anwender das Recht haben immer die aktuelle Ausgabe eines Handbuch zur Unterstützung Ihrer Arbeit zu benutzen. Sie sollen während Ihrer Arbeit mit Mo's db_Designer II jederzeit online von einem aussagekräftigen Text mit entsprechenden Illustrationen und Grafiken unterstützt werden.

Sie können die Hilfe jederzeit mit der Taste F1 aktivieren. Wir haben Mo's db_Designer II zusätzlich eine Quick-Hilfe mitgegeben. In diesem Quick-Hilfe System haben Sie als Anwender die Möglichkeit die Hilfetexte zu verändern und sich somit Ihre eigene Hilfe zu gestalten. Das ist insbesondere dann nützlich, wenn Sie den Umgang mit Mo's db_Designer II lernen; dann nämlich können Sie Ihre Erkenntnisse und Erfahrungen auf einfache Art und Weise dokumentieren.

Sie können die neueste Version des Handbuchs jederzeit bei unserem Support bestellen.

Wir wünschen Ihnen bei der Arbeit mit dem db_Designer II und diesem Handbuch viel Spaß.

Ihr Team von

Mo & friends


Warum einen db_Designer?

Stellen Sie sich vor, ein Architekt geht her, bestellt sich Baumaterial wie Backsteine, Zement und Sand auf seine Baustelle, und beginnt sodann hochmotiviert mit dem Bau eines Einfamilienhauses. Und das alles ohne eine Planung mit entsprechenden Zeichnungen. Sie werden sagen, den Architekten gibt es nicht! Warum aber soll der Entwickler einer Datenbank nun analog zu unserem fiktiven Architeken genauso "planlos" vorgehen?

Für den Entwurf einer Datenbank werden heute oftmals noch die Einträge in das Data Dictiorary per Hand editiert. Es gibt auch schon Hilfen, die meist aber mehr Aufwand erfordern als eigentlich notwendig wäre. Außerdem muß der Entwickler der Datenbank seine geschaffene Struktur auf einem Handzettel oder im Kopf skizzieren.

Dort wo vor einigen Jahren die CAD-Systeme bei den Architekten Einzug hielten, und dem Anwender ein profitables Werkzeug zur zeichnerischen Umsetzung seiner Ideen an die Hand gegeben wurde, ist man weitgehend zufrieden mit den Ergebnissen. Im Bereich des Entwurfs von Datenbanken wurden bereits in den '70ern die ersten grafischen Entwurfsverfahren entwickelt. Auf Basis dieser Verfahren, wie z.B. das Entity-Relationship-Diagramm oder das Bachman-Diagramm, sind zur Zeit nur wenige gute Werkzeuge am Markt zu finden. Und wenn diese noch Code zur Definition der benutzten Zieldatenbank generieren können, dann bekommen die Entwickler leuchtende Augen. Der db_Designer wurde als ein Werkzeug entwickelt, das eben dieses alles kann. Sie als Entwickler modellieren Ihre Datenbank, ähnlich wie ein Architekt seinen Bauplan zeichnet, an einem voll grafisch orientierten System und werfen danach den entsprechenden Definitions-Code Ihrer Zieldatenbank aus.

Mo's db_Designer II erleichtert Ihnen in diesem Moment wesentlich die Arbeit bei der Modellierung eines Datenbank-Entwurfs. Sie können jederzeit Ihren Entwurf verändern und neu generieren.

Wir wünschen Ihnen fortan viel Spaß beim "planvollen Bauen" einer Datenbank.

(Zum Glück können CAD-Programme noch keine kompletten Eigenheime generieren!? Anm. d. Autors)


Wie benutzen Sie die Hilfe

Das Handbuch soll Ihnen als neuem Anwender einerseits den Einstieg in die Installation des db_Designers und eine kurze Einführung in die Modellierung von Daten bietet, andererseits einen tiefergehenden Einblick in die Methodik der Datenmodelierung bietet. Sie sollten sich dabei immer vor Augen führen, daß Sie es bei diesem Handbuch nicht mit einem spannenden Roman zu tun haben. Das bedeutet für Sie, daß Sie dieses Handbuch nicht von vorne bis hinten durchlesen sollten. Es ist trotz seiner einfachen und lockeren Sprache tödlich langweilend. Kaufen Sie sich für so einen Marathon-Read lieber die vierteilige Trilogie "Per Anhalter durch die Galaxis" von Douglas Adams. Die legen Sie dann tatsächlich nicht vorher aus der Hand, bis Sie die letzten Zeilen des vierten Bandes gelesen haben. Hier zwei kurzes und für Sie nicht uninteressantes Zitate aus dem zweiten Band:

"Es gibt eine Theorie, die besagt, wenn jemals irgendwer genau rausfindet, wozu das Universum da ist und warum es da ist, dann verschwindet es auf der Stelle und wird durch etwas noch Bizarreres und Unbegreiflicheres ersetzt.

....

Es gibt eine andere Theorie, nach der das schon passiert ist."

Und hier das zweite Zitat, als Vorgeschmack auf den Roman:

"...So hatte sich zum Beispiel ein Volk hyperintelligenter, pandimensionaler Wesen einst einen riesenhaften Supercomputer namens Deep Thought, der ein für allemal die Antwort auf die Frage nach dem Leben, dem Universum und allem übrigen herausfinden sollte. Siebeneinhalb Millionen Jahre lang überlegte und rechnete Deep Thought, und schließlich verkündete er, die Antwort lautet schlicht und einfach Zweiundvierzig (42!) - und so mußte ein neuer, noch größerer Computer gebaut werden, der rausfinden sollte, wie den nun die Frage eigentlich laute. Und dieser Computer, der Die Erde hieß, war so groß, daß er oft fälschlich für einen Planeten gehalten wurde - besonders von den merkwürdigen affenartigen Wesen, die auf seiner Oberfläche herumrasten und absolut keinen Schimmer davon hatten, daß sie lediglich der Bestandteil eines gigantischen Computerprogrammes waren.  ..."

Diese Worte sprechen kommentarlos für sich!

Für die saubere Installation lesen Sie bitte nur das Kapitel 3. Für eine kurze Einführung in die Arbeit mit dem db_Designer II arbeiten Sie das Beispiel durch; aber bitte mit dem Programm und nicht als Gute-Nacht-Lektüre im Trocken-Übungs--Stil. Eine genaue Einführung in die Modellierung von Daten, die Normalisierung von Relationen und über verschiedene Verfahren des Datenbank-Entwurfs lesen Sie in Kapitel 5 dieses Handbuchs. Aber Vorsicht, dort sind harte Theorie und einige Tips zum besseren Datenbank-Entwurf abgedruckt. (Das Kapitel 5 "Theorie zum Entwurf von Datenbanken! -Daten-WirrWarr leicht gemacht-" wird im Handbuch für das PreRelease des db_Designers nicht abgedruckt!!! RS)


Etwas über die Theorie der Datenbank-Modelle

Die Theorie ist Grundlage allen praktischen Handelns. Aus diesem Grund möchten wir nicht darauf verzichten Ihnen einige Geheimnisse zum Thema Datenbank-Entwurf zu verraten. Diese grundlegende Einführung in den Datenbank-Entwurf soll Ihnen eine wertvolle Hilfe sein, um Daten in effizenter Art und Weise zu organisieren. Wir haben versucht dieses staubtrockene Thema interessant und visuell ansprechend zu behandeln. (Bitte verzeihen Sie die ein oder andere Einlage des Autors)

Folgende Themen sollen dazu behandelt werden:

Wortspiele mit Begriffen aus der Datenbankwelt

Das Entity-Relationship-Modell

Das Normalisieren von Datenstrukturen

Genauere Beschreibung von verschiedenen Verfahren des Entwurfs von Datenbanken entnehmen Sie der entsprechenden Literatur. Dort werden die oben vorgestellten Verfahren differenzierter beschrieben.


Das Start-Menue
Das Projekt-Menue

Dies ist der Hilfetext für Das Start-Menue, Kontext-String: MNU_START.

Im Moment sind keine weiteren Informationen verfügbar.


Das volle Menue
Das Datenbank-Menue

Dies ist der Hilfetext für Das volle Menue, Kontext-String: MNU_FULL.

Im Moment sind keine weiteren Informationen verfügbar.


Die Buttons

Dies ist der Hilfetext für Die Buttons, Kontext-String: DLG_BUTTONS.

Im Moment sind keine weiteren Informationen verfügbar.


Ein neues Projekt

Dies ist der Hilfetext für Ein neues Projekt, Kontext-String: DLG_NEWPROJ.

Im Moment sind keine weiteren Informationen verfügbar.


Eine neue Datenbank

Dies ist der Hilfetext für Eine neue Datenbank, Kontext-String: DLG_NEWDATABASE.

Im Moment sind keine weiteren Informationen verfügbar.


Ein Projekt oder eine Datenbank öffnen

Dies ist der Hilfetext für Ein Projekt oder eine Datenbank öffnen, Kontext-String: DLG_OPEN.

Im Moment sind keine weiteren Informationen verfügbar.


Die Attribute definieren
Die Felder eines Datensatzes definieren

Dies ist der Hilfetext für Die Attribute definieren, Kontext-String: DLG_ATTRIB.

Im Moment sind keine weiteren Informationen verfügbar.


Eine Beschreibung erstellen

Dies ist der Hilfetext für Eine Beschreibung erstellen, Kontext-String: DLG_DESCRIPT.

Im Moment sind keine weiteren Informationen verfügbar.


Der db_Compiler

Dies ist der Hilfetext für Der db_Compiler, Kontext-String: DB_COMP.

Im Moment sind keine weiteren Informationen verfügbar.


Die Quick-Hilfe

Dies ist der Hilfetext für Die Quick-Hilfe, Kontext-String: DLG_QUICKHELP.

Im Moment sind keine weiteren Informationen verfügbar.


A message for you...
Eine Meldung, was dann?

Dies ist der Hilfetext für A message for you..., Kontext-String: DLG_MESSAGE.

Im Moment sind keine weiteren Informationen verfügbar.


About db_Designer II (Information zum db_Designer II)

Dies ist der Hilfetext für About db_Designer II (Information zum db_Designer II), Kontext-String: DLG_INFO.

Im Moment sind keine weiteren Informationen verfügbar.


Wer ist Mo?

Dies ist der Hilfetext für Wer ist Mo?, Kontext-String: DLG_MO.

Im Moment sind keine weiteren Informationen verfügbar.


Das Beenden des db_Designer II
Das Beenden von Mo's db_Designer II

Dies ist der Hilfetext für Das Beenden des db_Designer II, Kontext-String: DLG_END.

Im Moment sind keine weiteren Informationen verfügbar.


Die Telefon-Hotline

Haben Sie Probleme? Können wir Ihnen helfen?

Dafür bieten wir Ihnen einen kostenlosen Hotline-Support an. Dort können Sie sich in der Zeit von

14.00 bis 17.00 Uhr

kompetente Auskunft und Lösungen zu Ihren Problemen holen. Die Telefonnummer des Hotline-Supports ist:

0 66 1 / 7 94 97

Wir haben eine Bitte an Sie. Bereiten Sie sich auf das Telefongespräch vor. Das heißt wir benötigen die Versionsnummer sowie die Registriernummer Ihres db_Designers II. Beschreiben Sie bitte vorab Ihr Problem genau auf einem Blatt Papier. Außerdem, bitte sein Sie nicht bösse, wenn es beim ersten Anruf nicht klappt.

Wenn Sie ein Fax besitzen, können Sie uns die vorbereiteten Notizen vorab übertragen. Hier unsere Fax-Nummer:

06 11 / 7 69 65

Sie haben außerdem die Möglichkeit Informationen über unsere


Das Bulletin Board System

Dies ist der Hilfetext für Das Bulletin Board System, Kontext-String: BBS_SUPPORT.

Im Moment sind keine weiteren Informationen verfügbar.


Einige wichtige Adressen

Dies ist der Hilfetext für Einige wichtige Adressen, Kontext-String: SUPPORTADRESSE.

Im Moment sind keine weiteren Informationen verfügbar.


Mo & friends

Wer ist Mo? Wer sind seine Freunde?

Mo & friends ist ein Pseudonym für ein Team von Entwicklern, die für Ralf Siebert InformationsSysteme exorbitante Software produzieren. Mo selber ist ein kleiner grüner Elefant mit einer eigenen Geschichte . Wie Mo aussieht sehen Sie unten. Außerdem ist eine Galerie alle Entwickler, Beteiligten und Freunde von Mo & friends abgebildet.

Das ist Mo!

Mo ist das Psydonym für eine Reihe von Entwicklern, die sich zur Aufgabe gemacht haben, Werkzeuge für Entwickluer so zu gestalten, daß diese in der Funktionalität der Arbeits-Methodik eines Entwicklers entsprechen und nicht irgendwelche wissenschaftliche Methoden versuchen umzusetzen.


Stichworte

Dies ist der Hilfetext für Stichworte, Kontext-String: STICHWORT.

Im Moment sind keine weiteren Informationen verfügbar.


Definitionen

Dies ist der Hilfetext für Definitionen, Kontext-String: DEFINES.

Im Moment sind keine weiteren Informationen verfügbar.


Vergleichstabelle der Datentypen

Die folgende Tabelle binhaltet eine Übersicht der Datentypen einzelner DBMS. Außerdem zeigt sie die Übereinstimmung einzelner Datentypen mit denen aus anderen Systemen. Der db_Compiler unterstützt die Konvertierung automatisch:

Allgemein	ANSI/ISO-SQL	db_VISTA III	CDB For xxx /C /C++	xBASE	DB2/Ocelot SQL	ORACLE SQL V5.1	Informix
Alphanumerische	CHARACTER (len)	char[len]	char[len]	ZEICHEN (len)	CHARACTER (len)	CHAR (len)	CHAR (len)
	CHAR (len)	char[len]	char[len]	ZEICHEN (len)	CHAR (len)	CHAR (len)	CHAR (len)
	CHAR (len)	char[len]	char[len]	ZEICHEN (len)	VARCHAR (len)	VARCHAR (len)	VARCHAR (len)
	CHAR (len)	char[len]	char[len]	ZEICHEN (len)	GRAPHIC (len)	VARCHAR (len)	VARCHAR (len)
Numerische	NUMERIC (len,dec)	float, double	float, double	NUMERISCH (len, dec)	NUMERIC (len, dec)	NUMBER (len, dec)	NUMERIC (len, dec)
	INTEGER	float, double	float, double	NUMERISCH	INTEGER	NUMBER	INTEGER
	NUMERIC (len)	float, double	float, double	NUMERISCH (len)	NUMERIC (len)	NUMBER (len)	NUMERIC (len)
	INTEGER	float, double	float, double	NUMERISCH (len)	INTEGER	NUMBER (*)	INTEGER
	DECIMAL (len,dec)	float, double	float, double	NUMERISCH (len, dec)	DECIMAL (len, dec)	DECIMAL (len, dec)	DECIMAL (len, dec)
	DEC (len,dec)	float, double	float, double	NUMERISCH (len, dec)	DEC (len, dec)	DECIMAL (len, dec)	DECIMAL (len, dec)
	INTEGER	(u)int, long	(u)int, long	NUMERISCH (len, dec)	INTEGER	INTEGER	INTEGER
	INT	(u)int, long	(u)int, long	NUMERISCH (len, dec)	INT	INTEGER	INTEGER
	SMALLINT	(u)short	(u)short	NUMERISCH (len, dec)	SMALLINT	SMALLINT	SMALLINT
	NUMERIC (len)	long	long	NUMERISCH (len)	NUMERIC (len)	LONG	NUMERIC (len)
	FLOAT (len)	float	float	NUMERISCH (len, dec)	FLOAT (len)	FLOAT	FLOAT
	FLOAT (len)	float	float	NUMERISCH (len, dec)	FLOAT (len)	FLOAT	SMALLFLOAT
	REAL	flaot	float	NUMERISCH (len, dec)	REAL	FLOAT	REAL
	DOUBLE PRECISION	double	double	NUMERISCH (len, dec)	DOUBLE PRECISION	FLOAT	DOUBLE PRECISION
	CHAR (len)	(u)char[len]	(u)char[len]	ZEICHEN (240)	CHAR (240)	RAW (size)	CHAR (240)
	CHAR (len)	(u)char[len]	(u)char[len]	ZEICHEN (240)	CHAR (240)	LONG RAW	CHAR (240)
Spezielle	nicht konvertierbar	db_addr	(u)long	nicht konvertierbar	nicht konvertierbar	LONG	nicht konvertierbar
	SMALLINT	(u)short	(u)short	LOGISCH	SMALLINT	SMALLINT	SMALLINT
	CHARACTER (len)	(u)long, char[len]	(u)long, char[len]	DATUM	DATE	DATE	DATE
	NUMERIC (len)	(u)long	(u)long	NUMERISCH (len)	NUMERIC (len)	LONG	DATETIME
	CHARACTER (len)	char[len]	char[len]	ZEICHEN (len)	TIME	CHAR (len)	DATETIME
	NUMERIC (len)	(u)long	(u)long	NUMERISCH (len)	NUMERIC (len)	LONG	INTERVAL
	DECIMAL (11, 2)	double	double	NUMERISCH (11, 2)	MONEY	DECIMAL (11, 2)	DECIMAL (11, 2)
	NUMERIC (len)	(u)long	(u)long	NUMERISCH (len)	NUMERIC (len)	LONG	SERIAL
	CHAR (len) Filename	char[len] Filename	char[len] Filename	MEMO	CHAR (len) Filename	CHAR (len) Filename	BLOB TEXT
	CHAR (len) Filename	char[len] Filename	char[len] Filename	ZEICHEN (len) Filename	CHAR (len) Filename	CHAR (len) Filename	BLOB BYTE


Allgemeine Meldungen

Dies ist der Hilfetext für Allgemeine Meldungen, Kontext-String: MELDUNGEN.

Im Moment sind keine weiteren Informationen verfügbar.


Die Katastrophen-Meldungen

Dies ist der Hilfetext für Die Katastrophen-Meldungen, Kontext-String: KATASTROPHE.

Im Moment sind keine weiteren Informationen verfügbar.


Etwas zum Entspannen

Adams, Douglas

Per Anhalter durch die Galaxis

Das Restaurant am Ende des Universums

Das Leben, das Universum, und der ganze Rest

Macht's gut, und danke für den Fisch

Alle vier Bände sind eine wichtige philosophische Ergänzung zum einer gut sortierte Fachbuch-Bibliothek eines Software-und Datenbank-Entwicklers. Um bedingte Pflichtlektüre für das tägliche Leben und Überleben mit einem Computer

Ullstein Verlag, alle ca. 7,80 DM

Graf, Joachim

Murphys Computergesetze

Gedankensammlung zum Thema "Der Computer, das Leben und ich". Dort sind viele Gedanken niedergeschrieben, die jeder Anwender eines Rechners bereits gedacht hat, aber nie schriftlich niedergelegt hat.

Mark & Technik-Verlag, ca. 9,90 DM


Hoch Wissenschaftliches

Chen, Peter

DATABASE MANAGEMENT Series

The Entity-Relationship Approach to logical database design

Die wohl einzige Abhandlung über das semantische Entwurf-Modell von Peter Chen. Sie enthält eine durchgängige Beschreibung, wie Datenbank mit Hilfe von E/R-Diagramme entworfen werden können. Auf theoretische Beweise wurde weitgehend verzichtet. Außerdem werden viele bildliche Darstellungen und Beispiele im Stil eines Studienskripts von eine Hochschule gebracht. Es ist empfehlenswert, da der db_Designer in seine Grundkonzeption und der Verarbeitung der Basisdaten im Data Dictionary auf dem E/R-Modell basiert.

QED Information Sciences Inc., U.S.A., ca. 70,-- DM

Vossen, Gottfried

Datenmodelle, Datenbanksprachen und Datenbank-Managmentsysteme

Gute zum Teil theoretisch-mathematische Einführung, die etwas tiefgründiger ist, in die Modellierung und die Anwendung verschiedene Zielsysteme. Wer die Theorie und mathematischen Beweise von Relationen und hauptsächlich relationalen Systeme nicht scheut, der hat hier ein gutes Handbuch für alle Fälle des Designs von Datenbank vorliegen.

Addison-Wesley Verlag, ca. 58,-- DM

Wiborny, Werner

Datenmodellierung, CASE, Datenmanagment

Dieses Buch gibt wie das vorgenannte von G. Vossen einen Einblick in die professionelle Modellierung von Datenbanken. Die Theorie wird hier durch übersichtliche Skizzen ersetzt. Nichts desto trotz wird die fachliche Qualität nicht vernachlässigt. Herausragend ist die Darstellung der Datenmoddelierung innerhalb unternehmensweiter Projekte. Es wird ein Datenmodellierungs-Modell aufgezeigt, daß nicht nur auf der grafischen Datesellung bassiert. Es läßt sich in einfacher Weise durch seine textuelle Darstellung auf einem Großrechner implementieren.

Addison-Wesley Verlag, ca. 89,-- DM

Date, C. J.

Database Systems Vol. I & II

Die Bibel des Datenbank-Entwicklers. In diesem Buch finden Sie alles über Datenbanken. Vom Entwurf über relationale Algebra bis hin zu Datenbank-Maschinen finden Sie alle Informationen zum Thema Datenbanken. Das Buch ansich ist aufgebaut wie ein Lehrbuch. Die Kapitel werden jeweils durch einen Aufgabenteil abgeschlossen.

Addiso-Wesley Publishing Company,

Vol. I ca. 68,-- DM Vol. II ca. 82,-- DM

Dutka, Allan F. & Hanson, Howard H.

Data Normalization

Die reale Welt stellt sich in einer Ummenge an Einzeldaten dar. Diese Daten müssen als erstes durch eine Analyse selektiert werden. Aus diesem Datenwust müssen Sie als Entwickler jetzt eine möglichst redundanzfreie Datenbank entwerfen. Dieser Vorgange der Normalisierung wird genauestens mit Beispielen in diesem Buch beschrieben. Sie lesen über erste bis vierte sowie Boyce-Codd'sche Normalform, sowie die Umsetzung in die Struktur eines DBMS.

Addison-Wesley Publishing Company, ca. 58,-- DM


Das Wort zum Schluß

Hat sich der Fehlerteufel ein geschlichen? Ist Ihnen etwas unklar!?

Dann dürfen Sie meckern. Aber bitte positiv! Wir freuen uns über jede konstruktive Kritik. Und wir werden Ihre Anmerkungen sammeln, um sie in der nächsten Version des Handbuch und natürlich der Software einzubauen. Wir hoffen, nein wir wissen, das Ihnen der Umgang mit der Software und dem Handbuch sicherlich viel Freude machen wird. Trotzdem, helfen Sie uns Mo's db_Designer II noch besser und noch leistungsfähiger zu gestalten.

Wir hören von Ihnen......


Die Geschichte von Mo

Angefangen hat alles mit dem Einzug in die neuen Geschäftsräume und dem Klo !

Ja auf dem Klo. Die Wandfarbe dieses Ortes ist ein leichtes violett. Einer der ehemaligen Freunde Mo's kommentierte dieses Outfit mit den Worten: "Jetzt fehlen nur noch kleine grüne Elefanten!". Also, war Mo geboren. Zum Leben erwachte er durch den Federstrich von Heike Kretschmann. Er soll in die ernste Sache der Informatik Witz und Humor bringen. Er symbolisiert die Kraft und das Einfühlungsvermögen eines guten Teams in die Lösung einer gestellten Aufgabe. Mo's db_Designer II ist das Produkt viele Stunden Arbeit und vieler Menschen, die Ihre Ideen aus Spaß an der Sache beigesteuert haben.


Klo

Ist die ordinäre, volkstümliche Bezeichnung des Aborts. K. auch Toilette genannt, ist ein stiller Ort, wo selbst der Kaiser zu Fuß hin geht, um seine ganz persönlichen Geschäfte zu erledigen. Bitte nicht stören!


DBMS

Abk. für database managment system, Ein Datenbank-Verwaltungssystem ist ein Systemprogramm, mit desen Hilfe ein Datenbanksystem betrieben werden kann. Im wesentlichen bezieht sich ein DBMS auf drei wesentlichen Aspekte, wie Daten einer Datenbank gesehen werden können (Drei-Schichten-Schema):

- externe Sicht des Benutzers

- konzeptualle, logische Sicht des Datenbankmodells

- interne Sicht der physikalischen Speicherung der gesammelten Daten


Eine Datenbank "Quick and dirty"

In der Einführung dieses Handbuchs konnten Sie etwas über das sogenannte "Papier und Bleistift"-Prinzip lesen. Demnach werden vom vielen Datenbank-Entwicklern zum Entwurf einer Datenbank das Aufzeichnen einer Datenbank-Struktur und das Notieren der entsprechenden Eigenschaftsbeschreibung auf Papier bevorzugt.

Mo's db_Designer II bedient sich dieser Art und Weise eine Datenbank zu entwerfen. In einem kurzen Beispiel sollen Sie an die Arbeit mit Mo's db_Designer II herangeführt werden. Dazu sind keine Kenntnisse über wissenschaftliche Entwurfsmethoden notwendig. Sie sollten sich zur Vertiefung jedoch mit dem Kapitel So werden Datenbanken entworfen beschäftigen. Dort können Sie einiges Wissenswertes zum systematischen Entwurf von Datenbanken lesen.

Sie sollen eine Datenbank für die Verwaltung von Aufträgen entwickeln. Diese Datenbank steht im Zusammenhang mit einem Projekt zur Entwicklung eines Warenwirtschaftssystems. In der Auftragsdatenbank sollen Kunden-, Lieferanten-, Artikel- und Bestelldaten verwalten. Wie Sie sehen handelt es sich hier um ein einfaches Beispiel. Sie sollten sich die Zeit zum Durcharbeiten dieses Beispiels nehmen.

Den Anfang in Mo's db_Designer II machten Sie mit der Definition eines neuen Projekts. Dazu wählen Sie aus dem Menue Desktop den Menuepunkt Projekt... aus. Das Menue Desktop beinhaltet alle wichtigen Funktionen die in logische Zusammenhang mit der Oberfläche von Mo's db_Designer II stehen.

Grafik!

Sie können diese Funktion auch über einen Hotkey bedienen. Dazu drücken Sie lediglich die Tastenkombination [Strg]+[P]. Der Buchstabe [P] steht in diesem Fall für Projekt. Sie erhalten nach Auswahl des entsprechenden Menuepunktes den Dialog zur Definition eines neuen Projektes bzw. zum Öffnen eines bereits bestehenden Projektes.

Grafik!

Um ein neues Projekt zu definieren klicken Sie den Button Neu an. Der Cursor wird danach in das Editierfeld Dateiname gesetzt. Dort geben Sie bitte den Dateiname WAREN ein. Sie können aber auch einen eigenen Dateinamen wählen. Dieser muß lediglich den Konventionen des DOS-Betriebssystems entsprechen. D.h., daß Sie einen möglichst sinnvollen und höchstens acht Zeichen langen Dateinamen wählen sollten. Durch Klicken des Buttons OK wird das Projekt mit Namen WAREN angelegt.

Der Projektname wird auf Ihrem Bildschirm in der Titelzeile des Fensters von Mo's db_Designer II angezeigt. In dem Fenster lassen sich mehrere Datenbanken pro Projekt auf einmal verwalten und bearbeiten. Um eine neue Datenbank anzulegen, wählen Sie bitte in dem Menue Desktop den Menuepunkt Datenbank-Design öffnen aus.

Grafik!

Sie sehen ein Untermenue, in dem bei einem neuen Projekt nur der Menuepunkt neu enthalten ist. Klicken Sie diesen Menuepunkt an, dann wird ein neues Design-Fenster auf dem Bildschirm geöffnet. Außerdem wird der Name der Datenbank, bei Neuanlage ein vorgegebener Name, in das Untermenue eingetragen. Somit haben Sie jederzeit eine Übersicht, welche Datenbanken in Ihrem Projekt implementiert sind. Sie können eine neue Datenbank auch hier über einen Hotkey anlegen. Dazu drücken Sie die Tastenkombination [Strg]+[D], wobei [D] für Datenbank steht.

Grafik!

Nach dem neu Anlegen der Datenbank als Datenbank-Blatt sollten Sie den Namen der Datenbank definieren. Dazu haben Sie jetzt einen neuen zusätzlichen Punkt Datenbank im Menue Ihres Fensters erhalten. Um den vorgegeben Namen der Datenbank zu ändern wählen Sie aus dem Menue Datenbank den Menuepunkt definieren... aus.

Grafik!

Sie erhalten einen Dialog, in dem Sie einen neuen Namen für die Datenbank eingeben können sowie Informationen zum späteren Drucken der Datenbank angeben können.

Grafik!

Bitte geben Sie in dem Editierfeld Name den Datenbanknamen Auftrag ein. Der Alias der Datenbank wird automatisch mitgeschrieben. Er wird zum Beispiel für die Generierung eines Datenbank-Kataloges für das Datenverwaltungssystems dBASE IV verwendet. der Alias ist nicht länger als acht Zeichen und sollte den Konventionen für Dateinamen des DOS-Betriebssystems entsprechen. Sie können zu Ihrer Datenbank eine kurze Beschreibung eingeben, sowie den db_Compiler initialisieren. Auf diese beiden Funktionen wird im Handbuch später genauer eingegangen.

Sie sollten jedoch bereits hier die Druckgröße des Datenbank-Diagramms festlegen. dazu haben Sie vier vorgegebene sowie eine benutzerdefinierte Größen zur Verfügung. Sie können diese durch Klicken des entsprechenden Radio-Buttons einstellen. Wenn Sie Ihre Definitionen in Bezug auf die Datenbank eingegeben haben, können Sie die Eingaben durch Klicken des Buttons OK bestätigen.

Das "Papier und Bleistift"-Prinzip zeichnet sich insbesondere dadurch aus, daß Sie eine Datenbank mit Hilfe einfacher Symbole grafisch gestalten können. dabei werden die Beziehungen der Daten bzw. Datenblöcke grafisch und übersichtlich dargestellt. Ähnlich einem Bauplan für den Bau eines Hauses. In dieser Beispiel-Datenbank sollen Sie einen Entwurf für das Datenbanksystem RAIMA DATA MANAGER (ehem. db_VISTA III) erstellen. Dort ist die Rede von sogenannten RECORDs und SETs. Näheres dazu lesen Sie in dem Kapitel Wortspiele aus der Welt der Datenbanken. Kurz gesagt beinhalten RECORDs die Definition der Datenfelder und SETs sind die Beziehung (Relation) zwischen RECORDs, also Daten.

Auf dem Datenbank-Blatt in Mo's db_Designer II können Sie ein RECORD durch einen einfaches Anklicken der Stelle, an der später das RECORD-Symbol gezeichnet werden. Sie haben nach Erscheinen des Symbols den Namen in einem Editierfeld unterhalb des Symbols einzugeben.

Grafik!

Definieren Sie sich wie oben erläutert die RECORDs Kunde, Lieferant, Bestellung, Artikel und Adressen. Falls Sie den Namen eines Symbols ändern möchten, klicken Sie den Namen des Symbols einfach an und geben einen entsprechenden Namen in dem erscheinenden Editierfeld ein.

Die Beziehungen, also die SETs, können Sie sehr einfach anzeigen. Sie wollen zum Beispiel die Beziehung, daß ein Kunde eine Bestellung hat darstellen. Dazu klicken Sie das Symbol Kunde einfach an und halten die linke Taste der Maus gedrückt. Bewegen Sie nun die Pfeilspitze auf das Symbol Bestellung und lassen die linke Taste der Maus wieder los. Auf dem Datenbank-Blatt sehen Sie eine Raute, die die beiden Symbole des Kunde und Bestellung mit einem Richtungspfeil verbindet.

Grafik!

Die fertige Datenbank-Struktur zeigt Ihnen eine kleine Datenbank zur Verwaltung von Auftragsdaten. Sie können diese Strukturdefinition gerne erweitern oder anderweitig Ihren Wünschen anpassen.

Grafik!

Die einzelnen Symbole lassen sich auf dem Datenbank-Blatt beliebig anordnen. Dazu klicken Sie das entsprechende Symbol einfach an. Das Aussehen des Symbols ändert sich.

Grafik!

Die so aktivierten Symbole können auf zwei verschiedene Arten auf den Datenbank-Blatt bewegt werden. Die erste Möglichkeit ist, daß Sie das aktive Symbol einfach anklicken und die linke Taste der Maus festhalten. Nach einem kurzen Moment erscheint ein neues Cursor-Symbol, das ein kleines Männchen mit einem entsprechenden Symbol sowie einem Kreuz zeigt. Bewegen Sie den Cursor an die Stelle, an der das Symbol ab sofort erscheinen soll. Lassen Sie die linke Taste der Maus wieder los und das Datenbank-Diagramm wird neu gezeichnet.

Die zweite Möglichkeit wird mit Hilfe der Tastatur durchgeführt. Ein aktives Symbol kann jederzeit mit der Cursor-Steuerung in jede Richtung bewegt werden. Das gibt Ihnen die Möglichkeit Ihren Datenbank-Entwurf visuell optimal und übersichtlich zu gestalten.

Nachdem Sie die relationalen Zusammenhänge der Daten zueinander gestaltet haben, müssen die RECORDs mit Leben erfüllt werden. D. h., daß Sie zu den einzelnen RECORDs bestimmte Eigenschaften (Attribute) definieren. Beispielsweise könnte ein Artikel eine Nummer, Bezeichnung, einen Einkaufspreis (EK), Verkaufspreis (VK) und eine Lagermenge als Attribut haben. Jedes einzelne Attribut hat einen eigenen Datentyp und dessen spezifischen Eigenschaften.

Um diese Definitionen anzugeben klicken Sie das RECORD-Symbol Artikel auf Ihren Datenbank-Blatt doppelt an. Daraufhin sehen Sie einen Dialog zur Eingabe dieser Informationen.

Grafik!

Der Dialog gliedert sich in drei Bereiche. Im linken Abschnitt haben Sie eine Übersicht der bereits implementierten Felder (Attribute; Eigenschaften eines RECORDs. Der mittlere Teil dient zur Eingabe bzw. Änderung der Informationen zu einem Feld. Im rechten Teil können Sie bestimmte Funktionen mittels Symbol-Button aktivieren.

Exemplarisch sollen Sie jetzt das Feld für die Artikelnummer neu anlegen. Dazu klicken Sie den Button Neu an. Im mittleren Teil wird ein Vorgabefeld angelegt und der Cursor in das Editierfeld Name gesetzt. Bitte geben Sie als Feldnamen ArtNummer ein. Sie können den Cursor mit der Tabulator-Taste zum nächsten Eingabeelement bewegen.

Das ist eine Liste mit den Datentypen des Datenbanksystems RAIMA DATA MANAGER (db_VISTA III). Wählen Sie in der Liste den Datentyp int aus. Abhängig von Datentyp können Sie dann die Editierfelder Länge bzw. Dezimale benutzen. Im Fall des Datentyp int können Sie keine Länge bzw. Dezimale angeben. Der Datentyp int repräsentiert einen ganzzahligen Wert, der zum Beispiel fortlaufend von einem Anwendungsprogramm vergeben werden kann.

Die letzte Eingabe machen Sie in der Liste Schlüssel. Auch hier werden Ihnen die entsprechenden Begriffe der Schlüssel zum Datenbanksystem RAIMA DATA MANAGER (db_VISTA III) angeboten. Bitte wählen Sie als Schlüssel den unique key aus. Das bedeutet, daß die Artikelnummer als Schlüsselwert eindeutig, also nur einmal, vergeben werden darf.

Haben Sie alle Eingaben erledigt, können Sie das Feld Artikelnummer mit dem Button PutInList in der Feldliste aufnehmen. Den Vorgang wiederholen Sie solange, bis Sie alle notwendigen Felder zu einem RECORD angegeben haben. Um den Dialog zu schließen klicken Sie einfach den Button Schließen an.

Bitte definieren Sie die Felder der anderen RECORDs nach Ihrer Idee oder entnehmen Sie die notwendigen Informationen dem unten stehenden DLL-Code. Die Datenbank ist dann von Ihrer Struktur sowie der inhaltliche Aussage her gestaltet. Der letzte Schritt ist dann die Generierung des DLL-Codes für RAIMA DATA MANAGER (db_VISTA III).

Dafür klicken Sie in dem Menue db_Compiler den Menuepunkt generieren an. Der Menuepunkt generieren aktiviert den db_Compiler immer mit dem Generator für das voreingestellte Datenbanksystem. Sie können aber auch über den Menuepunkt generieren nach ein neues Ziel-Datenbanksystem aus einem entsprechenden Untermenue auswählen.

Grafik!

Der db_Compiler generiert nun den DLL-Code für RAIMA DATA MANAGER (db_VISTA III) in eine ASCII-Datei.

Grafik!

Sie können den Compiler-Lauf in einem eigene Applikations-Fenster beobachten. Dort sehen Sie Informationen über die kompilierte Zeilenanzahl sowie Statusmeldungen zu Fehlern bzw. Warnungen. Wenn Sie ein anderes als das voreingestellte Datenbanksystem für die Generierung verwenden, dann kann es sein, daß bestimmte Datentype oder Schlüsselbegriffe konvertiert werden sowie eine entsprechende Warnung erzeugen.

Wurde die Kompilierung (Generierung) erfolgreich abgeschlossen, dann können Sie den DLL-Code als Text editieren. Aktivieren Sie dazu im Menue Datenbank den Menuepunkt als Text.

Grafik!

Sie können in dem Notiz-Editor von MS Windows den ASCII-Code individuell verändern und anpassen. Bitte beachten Sie aber, daß diese Änderungen nicht in den Entwurf in Mo's db_Designer II direkt übernommen werden. Sie können jedoch den veränderten Code mit den db_Compiler analysieren und haben dann die veränderte Datenbank in Mo's db_Designer II zur Verfügung.

Grafik!

Denn vollständigen generierten DLL-Code für RAIMA DATA MANAGER (db_VISTA III) sehen Sie nachfolgend.

database Auftrag[512]{

record Kunde{

unique key int KndNummer;

key char KndFirma[35];

key char KndName[35];

char Telefon[15];

char Telefax[15];

}

set {

order ascending;

owner Kunde;

member Bestellung;

}

set {

order ascending;

owner Kunde;

member Adressen;

}

record Bestellung{

unique key int BestellNummer;

char BestellDat[10];

char LieferDat[10];

double GesamtBetrag;

double UmsStSatz;

}

set {

order ascending;

owner Bestellung;

member Artikel;

}

record Artikel{

double EK_Preis;

double VK_Preis;

double LagerMenge;

key char ArtBezeichn[40];

unique key int ArtNummer;

}

set {

order ascending;

owner Artikel;

member Bestellung;

}

set {

order ascending;

owner Artikel;

member Lieferant;

}

record Lieferant{

unique key int LiefNummer;

key char LiefFirma[35];

key char LiefName[35];

char Telefon[15];

char Telefax[15];

double RabattSatz;

int Lieferzeit;

}

set {

order ascending;

owner Lieferant;

member Artikel;

}

set {

order ascending;

owner Lieferant;

member Adressen;

}

record Adressen{

char Strasse[25];

char Land[3];

char PostBereich[1];

int Postleitzahl;

char Ort[25];

}

}

Dieses kurze Beispiel soll Ihnen dazu dienen einen ersten Einstieg in die Arbeit mit Mo's db_Designer II zu finden. Wenn Sie die kleine Auftragsverwaltung mit Mo's db_Designer II entwickelt haben, sollten Sie ein Gefühl dafür haben, daß nicht unbedingt wissenschaftliche Methoden für einen guten Datenbank-Entwurf notwendig sind, sondern einfach nur Papier, Bleistift und die Intuition Daten in einer Datenbank effizient unterzubringen. Genau bei dieser Vorgehensweise soll Mo's db_Designer II für Sie ein unentbehrliche Werkzeug sein.


Wortspiele mit Begriffen aus der Welt der Datenbanken

Jedes Datenbanksystem für sich hat seine eigene Terminologie, seine eigene Sprache. Diese sprachlichen bzw. begrifflichen Gegebenheiten sollten Sie kennen, spätestens zu dem Zeitpunkt, wenn Sie von einem Datenbanksystem in ein anderes eine Struktur portieren wollen. Sie sollen die Sprache von den Datenbanksystemen kennenlernen, die Mo's db_Designer II unterstützt. Die Datenbanksysteme lassen sich in drei Gruppen einteilen:

 Datenbanken nach dem Netzwerk-Modell (CODASYL-Modell)

 xBASE-Datenbanken

 SQL-Datenbanken

Diese drei Gruppen haben für sich Ihre eigene Begriffswelt und Methode, Daten für den Benutzer bzw. Entwickler logisch darzustellen.

Allgemeine Begriffe und Methoden bei Datenbanken

Beginnen wir aber vorab mit einigen allgemeinen Begriffen, die im nachfolgenden Text des öfteren auftreten. Datenbanksysteme wurden entwickelt, um dem Anwender bzw. Entwickler die physikalische Speicherung und den damit verbundenen Aufwand der Programmierung weitgehend abzunehmen. Den Aufbau eines Datenbanksystems können Sie in drei Ebenen des Zugriffs auf die Daten beschreiben. Die drei Ebenen sind dann

 externe

 konzeptionelle

und

 interne

Ebene.

Die unterste Ebene eines Datenbanksystems ist die interne Ebene. In ihr sind alle physikalischen Zugriffe auf die gespeicherten Datenbestände implementiert. Diese Ebene sorgt für Sie als Entwickler bzw. Anwender eines Datenbanksystems dafür, daß die richtigen Daten und deren Zusammenhänge mit anderen Daten erkannt und bearbeitet werden. Die Funktionen dieser Ebene speichern die Daten in den richtigen Dateien ab bzw. gewinnen die Daten aus diesen.

Aufbauend auf den Funktionen für die physikalische Speicherung der Daten ist für Sie als Entwickler die konzeptionelle Ebene von Belang. Hier soll Sie Mo's db_Designer II in Ihrer Arbeit und bei der Sammlung Ihrer Ideen unterstützen. Auf der konzeptionellen Ebene legen Sie fest, welche Struktur Ihre Datenbank haben wird, welche Zusammenhänge bzw. Beziehungen zwischen den Daten bestehen sollen. Sie müssen sich in diesem Teil des Datenbank-Entwurfs keine Gedanken über die physikalische Speicherung Ihrer Daten machen. Die Überlegungen in welcher Datei welche Daten gespeichert werden, wird wie oben gezeigt durch die Funktionen der internen Ebene für Sie übernommen.

Wenn Sie die Struktur Ihrer Datenbank festgelegt haben, werden Sie für den "Normal-Anwender" eine einfach bedienbare Applikation nach dessen Wünschen implementieren. Diese für den Anwender sichtbare Ebene, also die Applikation mit ihren Funktionen, nennen wir die externe Ebene eines Datenbanksystems. In den meisten Datenbanksystemen kann diese Ebene durch eine Programmiersprache der vierten Generation (4GL) realisiert werden. Der Anwender bekommt eine ansprechende Oberfläche auf dem Bildschirm präsentiert, über die er seine Daten aus der Datenbank einfach und schnell abfragen kann. Der Anwender der Applikation kommt mit den Definitionen der Struktur einer Datenbank nicht in Berührung. Er kennt sie nicht einmal bewußt.

Für Sie als Entwickler ist wie vorher erwähnt die zweite Ebene, die konzeptionelle Ebene, wichtig. Auf dieser Ebene legen Sie die Struktur Ihrer Datenbank fest. Diese Struktur besteht aus zwei wesentlichen Komponenten:

 Datensätze

 Beziehungen zwischen Datensätzen

Was ist ein Datensatz? Das Lexikon sagt darüber folgendes: "Auch logischer Satz, formatierter oder strukturierter Satz. Der D. ist eine Dateneinheit, die durch ihren zusammengehörigen Inhalt zur Einheit wird." Machen wir diese Aussage an einem kleinen Beispiel fest: Hans Müller, Otto Klamauk, Elfriede Rumpel und viele andere mehr arbeiten in der Firma XYZ GmbH. Die Firma setzt eine Datenbank ein, um die Daten ihrer Mitarbeiter zu sammeln.

PERSONAL

NAME	VORNAME	ALTER	STRASSE	WOHNORT	GEHALT
Müller	Hans	18	Ottostraße 18	6000 Frankfurt/M.	1200,00
Klamauke	Otto	22	Lindenstraße 1	8000 München 12	2000,00
Rumpel	Elfriede	34	Sturmweg 23	7000 Stuttgart	2300,00
......	......	......	......	......	......
......	......	......	......	......	......

Eine Zeile der Tabelle entspricht einem Datensatz. Jeder Datensatz hat den gleichen strukturellen Aufbau. Dieser Aufbau wird in einem Datenbanksystem durch den Entwickler fest vorgegeben. Dazu ist es notwendig, daß Sie als Entwickler sich über die Art der Daten eines Datensatzes im klaren sind. Das heißt, Sie müssen wissen, ob ein Datenfeld einen Text oder eine Zahl enthalten soll.

Datensatz PERSONAL

{

NAME = Text;

VORNAME = Text;

ALTER = Zahl;

STRASSE = Text;

WOHNORT = Text;

GEHALT = Zahl;

}

Sie legen in einer für Ihr verwendetes Datenbanksystem spezifischen Art und Weise den Aufbau des Datensatzes fest. Diese Struktur besteht im allgemeinen aus dem Namen des Datensatzes und den Namen der Datenfelder mit ihren Datentypen. Das zweite wichtige Strukturelement der konzeptionellen Ebene eines Datenbanksystems sind die Beziehungen, auch Relationen genannt, zwischen zwei Datensätzen. Was sind Relationen (Beziehungen) zwischen Daten?

Die Beziehung zwischen Daten läßt sich am besten mit einem einfachen Beispiel erläutern: Herr und Frau Müller sind Angestellte eines großen Unternehmens. Sie besitzen in X-Stadt ein schönes Haus, das ihnen als ihr Erstwohnsitz dient. Im Bayrischen Wald haben die Müllers ein Feriendomizil. Es ist ein kleines Ferienhaus in schöner Lage.

Sie als Entwickler bekommen eine solche Situation dargestellt. Wie Sie unschwer erkennen können, läßt sich aus diesem Beispiel folgender Datensatz ableiten:

Datensatz PERSON

{

NAME = Text;

VORNAME = Text;

ALTER = Zahl;

STRASSE = Text;

POSTLEITZAHL = Zahl;

WOHNORT = Text;

}

Wenn Sie die Daten in die erstellte Datenbank eintragen, haben Sie folgendes Bild:

PERSON

NAME	VORNAME	ALTER	STRASSE	PLZ	WOHNORT
Müller	Otto	52	Otto-Str. 15	6000	Frankfurt/Main
Müller	Elfriede	50	Otto-Str. 15	6000	Frankfurt/Main
Müller	Otto	52	Brunnen Weg 5	8834	Bayerndorf
Müller	Elfriede	50	Brunnen Weg 5	8834	Bayerndorf

Wenn Sie sich die Daten in der Tabelle genauer betrachten, werden Sie feststellen, daß die Adressdaten jeweils doppelt auftreten. Eine solche Mehrfachspeicherung wird beim Datenbank-Entwurf eine Redundanz genannt. Das bedeutet, daß Sie den Datensatz in zwei unterschiedliche Datensätze aufteilen müssen, um die Redundanz zu eliminieren. Die Datensatz-Strukturen haben dann das folgende Aussehen:

Datensatz PERSON

{

NAME = Text;

VORNAME = Text;

ALTER = Zahl;

ADRESSNUMMER = Zahl;

}

Datensatz ADRESSE

{

ADRESSNUMMER = Zahl;

STRASSE = Text;

POSTLEITZAHL = Zahl;

WOHNORT = Text;

}

Um die beiden Datensätze durch das Datenbanksystem in Verbindung bringen zu können, müssen Sie in beiden Datensätzen einen sogenannten Schlüssel einfügen. Den Begriff des Schlüssels werden wir etwas später genauer erklären. Tragen Sie jetzt die Daten in die neuen Datensätze ein, dann haben Sie die folgenden Tabellen:

PERSON

NAME	VORNAME	ALTER	ADRESSNUMMER
Müller	Otto	52	1001
Müller	Elfriede	50	1001
Müller	Otto	52	1002
Müller	Elfriede	50	1002
ADRESSE

ADRESSNUMMER	STRASSE	PLZ	WOHNORT
1001	Otto-Str. 15	6000	Frankfurt/Main
1002	Brunnen Weg 5	8834	Bayerndorf

Wie Sie aus den obigen Tabellen ersehen können, werden die Adressen jeweils nur einmal abgespeichert. Das Datenbanksystem kann mit Hilfe des Schlüsselwertes ADRESSNUMMER eine Beziehung zwischen dem Datensatz PERSON und dem Datensatz ADRESSEN herstellen. Eine solche Beziehung ist eine Relation, die meistens durch Überprüfung der Gleichheit von festgelegten Schlüsselwert entsteht. Durch diesen im Datenbanksystem implementierten Mechanismus entsteht wieder die anfangs entwickelte Datenstruktur als logisches Abbild der beiden Basistabellen.

Der Vorteil mit Relationen zu arbeiten ist klar ersichtlich die Ersparnis an Speicherkapazität auf einem Datenträger. Die oben gezeigte Relation ist gleichbedeutend mit der Aussage "Herr Müller wohnt in der Otto Str. 15 in 6000 Frankfurt/Main", allgemeiner trifft die Aussage "Eine PERSON wohnt in(an) einer ADRESSE" zu. Somit sehen Sie deutlich das eine Beziehung, eben eine Relation, zwischen PERSON und ADRESSE besteht, und daß die Logik dem menschlichen Denken ähnlich ist.

Für die Realisierung einer Relation ist bei den meisten Datenbanksystemen ein Schlüssel notwendig. Sie können zwei grundsätzliche Gruppen von Schlüsseln unterscheiden

 Primär-Schlüssel

 Fremd-Schlüssel.

In einigen Datenbanksystemen finden Sie auch andere Arten von Schlüsseln, die sich letztlich in den beiden oben genannten Gruppen eingliedern lassen oder für die Arbeit mit Relationen sekundär von Belang sind. Der Primär- und der Fremd-Schlüssel bilden im Bezug auf Relationen eine gemeinsame Koexistenz.

Der Primär-Schlüssel wird auch als eindeutiger Schlüssel bezeichnet. Davon können Sie seine Bedeutung innerhalb eines Datensatzes ableiten, er dient zur eindeutigen Identifizierung eines bestimmten Datensatzes. Der Wert des Primär-Schlüssels sollte möglichst numerisch-ganzzahliger Natur sein, da dadurch ein schneller relationaler Zugriff auf Daten gewährleistet werden kann. Außerdem ist der Primär-Schlüssel als Wert innerhalb einer Datenspalte in einem Datensatz immer einmalig, deshalb also eindeutig.

Um von einem Datensatz A aus eine Relation zu einem Datensatz B bilden zu können, muß in Datensatz A ein Fremd-Schlüssel angegeben werden. Dieser Fremd-Schlüssel wird in einigen Datenbanksystemen auch als Verweis-Schlüssel bezeichnet. Er zeigt bei einer Auswertung der Relation welche Datensätze A mit welchen Datensätzen B verknüpft werden können.

Im oberen Abschnitt haben Sie ein kurzes Beispiel für Schlüssel bereits kennengelernt. Dieses sollen Sie sich ins Gedächtnis rufen:

Datensatz PERSON

{

NAME = Text;

VORNAME = Text;

ALTER = Zahl;

ADRESSNUMMER = Zahl   FREMDSCHLÜSSEL;

}

Datensatz ADRESSE

{

ADRESSNUMMER = Zahl   PRIMÄRSCHLÜSSEL;

STRASSE = Text;

POSTLEITZAHL = Zahl;

WOHNORT = Text;

}

PERSON

NAME	VORNAME	ALTER	ADRESS-NUMMER
Müller	Otto	52	1001
Müller	Elfriede	50	1001
Müller	Otto	52	1002
Müller	Elfriede	50	1002
ADRESSE

ADRESS-NUMMER	STRASSE	PLZ	WOHNORT
1001	Otto-Str. 15	6000	Frankfurt/Main
1002	Brunnen Weg 5	8834	Bayerndorf

In den obigen Tabellen wurden die Namen der Schlüssel entsprechend markiert. Sie sollten einen Primär-Schlüssel durch eine doppelte und einen Fremd-Schlüssel durch eine einfache Unterstreichung markieren.

Leider werden in unserem Beispiel die Daten der PERSON immer noch redundant abgespeichert. Die Datensätze der beiden Müllers werden für jeden Wohnsitz geführt. Diese Notwendigkeit kann durch einen dritten Datensatz beseitigt werden.

Datensatz PERSON

{

PERSONNUMMER = Zahl   PRIMÄRSCHLÜSSEL;

NAME = Text;

VORNAME = Text;

ALTER = Zahl;

}

Datensatz PERSON

{

PERSONNUMMER = Zahl   FREMDSCHLÜSSEL;

ADRESSNUMMER = Zahl   FREMDSCHLÜSSEL;

}

Datensatz ADRESSE

{

ADRESSNUMMER = Zahl   PRIMÄRSCHLÜSSEL;

STRASSE = Text;

POSTLEITZAHL = Zahl;

WOHNORT = Text;

}

PERSON

PERSON-NUMMER	NAME	VORNAME	ALTER
P1001	Müller	Otto	52
P1002	Müller	Elfriede	50
PERSADRESS

PERSON-NUMMER	ADRESS-NUMMER
P1001	A1001
P1001	A1002
P1002	A1001
P1002	A1002
ADRESSE

ADRESS-NUMMER	STRASSE	PLZ	WOHNORT
A1001	Otto-Str. 15	6000	Frankfurt/Main
A1002	Brunnen Weg 5	8834	Bayerndorf

In der obigen Variante des Beispiels wird ein dritter Datensatz eingeführt, der lediglich die Werte der Primär-Schlüssel vom Datensatz PERSON und dem Datensatz ADRESSE beinhaltet. In den beiden Datensätzen PERSON und ADRESSE wurden Primär-Schlüssel definiert. Im Datensatz PERSADRESS wurden die PERSONNUMMER und die ADRESSNUMMER als Fremdschlüssel definiert. Dadurch können die Werte des Schlüssels doppelt vorkommen. Wenn Sie die Relation, die zwischen den drei Datensätzen besteht, auswerten erhalten Sie die folgende Datentabelle:

PERSON-NUMMER	NAME	VORNAME	ALTER	PERSON-NUMMER	ADRESS-NUMMER	ADRESS-NUMMER	STRASSE	PLZ	WOHNORT
P1001	Müller	Otto	52	P1001	A1001	A1001	Otto-Str. 15	6000	Frankfurt/Main
P1001	Müller	Otto	52	P1001	A1002	A1002	Brunnen Weg 5	8834	Bayerndorf
P1002	Müller	Elfriede	50	P1002	A1001	A1001	Otto-Str. 15	6000	Frankfurt/Main
P1002	Müller	Elfriede	50	P1002	A1002	A1002	Brunnen Weg 5	8834	Bayerndorf

Datensätze stehen nicht nur in Relation zueinander, sondern die Relationen drücken zumeist ein bestimmtes Verhältnis aus. Bezogen auf das oben beschriebene Beispiel mit den Müllers kann das Verhältnis verbal wie folgt ausgedrückt werden: "Herr Müller wohnt an zwei Orten!" oder "Frau Müller wohnt an zwei Orten!". Aus der Sicht der Orte sieht das Verhältnis so aus: "An einem Ort wohnen zwei Müllers!". Wenn Sie diese Verhältnisse im Allgemeinen betrachten, bekommen Sie folgende Aussage: "Eine Person kann an mehreren Orten wohnen!" und "An einem Ort wohnen mehrere Personen!". Diese Verhältnisse in Bezug auf Relationen werden als Kardinalität bezeichnet. Die Kardinalität wird sogar noch etwas kürzer ausgedrückt. Hier einige Beispiele:

Verbale Aussage	Kardinalität
"Eine Person kann an mehreren Orten wohnen!"	1:N
"An einem Ort wohnen mehrere Personen!"	1:N
"Mehrere Personen können an mehreren Orten wohnen!"	N:M

Als Entwickler sollten Sie sich immer Gedanken über die Kardinalität, das Verhältnis in Bezug auf die Menge der zu speichernden Daten, machen. Dadurch erreichen Sie einen weitgehend optimalen Entwurf der Relationen in Ihrer Datenbank. Wir werden den Begriff der Kardinalität mit ihren Feinheiten später genauer kennenlernen.

Nachdem Sie jetzt die grundlegenden Begriffe und Methoden im Umgang mit Daten innerhalb von Datenbanken kennen, wollen wir uns mit den oben genannten drei Gruppen von Datenbanksystemen auseinandersetzen. Nach einer kurzen Einleitung in die einzelnen Gruppen werden Sie die spezielle Terminologie der einzelnen Datenbanksysteme kennenlernen, die von Mo's db_Designer II unterstützt werden. Im Anhang wird die Syntax der einzelnen Datenbanken zusätzlich aufgeführt.

Datenbanken nach dem Netzwerk-Modell (CODASYL-Modell)

Im Jahre 1971 wurde erstmals in einer Konferenz und in verschiedenen Entwicklungsgruppen CODASYL (Conference on Data Systems Languages) genannt detaillierte Vorschläge zu einer Netzwerk-Datenbank entwickelt. Auf der dort erarbeiteten Spezifikation für Netzwerk-Datenbanken beruhen weitgehend alle am Markt erhältlichen Datenbanksysteme nach dem Netzwerk-Modell.

Zwei wesentliche Begriffe der Netzwerk-Datenbanken sind zum einen

 RECORD

zum anderen

 SET.

Im vorherigen Text haben Sie den Begriff des Datensatzes kennengelernt. Ein Datensatz ist bei einer Netzwerk-Datenbank ein RECORD. Der RECORD definiert für das Datenbanksystem die logische Struktur der zu speichernden Daten. Ein RECORD muß nicht der physikalischen Struktur der Datei entsprechen, in der die Daten später gesichert werden. Ein SET ist die Relation zwischen zwei RECORDs. Die beiden RECORDs, die durch ein SET miteinander verknüpft sind, werden OWNER und MEMBER genannt.

In vielen Handbüchern zu Netzwerk-Datenbanken werden RECORDs als Rechteck und SETs als gerichteter Pfeil dargestellt. RECORDs besitzen grundsätzlich einen eindeutigen Namen. SETs hingegen werden in einigen Datenbanksystemen ohne Namen geführt. Wie Sie aus der Grafik leicht ersehen können, ist ein MEMBER über das SET immer abhängig von einem OWNER. Die Kardinalität wird durch die Pfeilspitze festgelegt bzw. dargestellt. In einer Netzwerk-Datenbank ist die Kardinalität immer 1:N. Das heißt, daß ein OWNER mehrere MEMBERs haben kann, aber ein MEMBER immer nur einen OWNER hat. Wenn Sie eine N:M-Kardinalität darstellen wollen müssen Sie dies über einen dritte RECORD implementieren. Dieser RECORD ist dann immer der MEMBER der beiden Daten-RECORDs.

Der zusätzliche RECORD wird bei vielen Netzwerk-Datenbanken als INTERSECT-RECORD bezeichnet. Er ist meistens ein leerer RECORD. Gegenüber anderen Datenbanksystemen haben Netzwerk-Datenbanken einen wesentlichen Unterschied, der zu einer Minimierung der Zugriffszeit führt. In Netzwerk-Datenbanken müssen Sie keine Primär- bzw. Fremd-Schlüssel definieren. Die Gewinnung der Daten erfolgt über ein SET. Ein SET ist demnach eine feste Verbindung zwischen zwei RECORDs, die zur Zeit des Zugriffs bekannt sein muß. Schlüsselwerte werden nur dort festgelegt, wo ein direkter und schneller Zugriff auf die Daten eines RECORDs erforderlich ist.

Mo's db_Designer II unterstützt zwei Datenbanksysteme nach dem Netzwerk(CODASYL)-Modell. Beide Systeme sind portabel auf die Betriebssystem-Umgebungen MS-DOS, UNIX System V und MS Windows. Sie werden die wichtigsten Merkmale in Bezug auf den Entwurf einer Datenbank von den Datenbank-Systemen

 RAIMA DATA MANAGER (ehemals db_VISTA III)

und

 CDB For Windows/DOS/UNIX

kennenlernen. Wir werden genau auf den Aufbau der Data Definition Language (DDL) der beiden Datenbanksysteme eingehen und das Design dieser behandeln. Eine allgemeine Einführung in das Design und die entsprechenden Methoden lesen Sie bitte im Kapitel Das Entity-Relationship-Modell. Der beschriebene DDL-Code ist das Ergebnis der Generierung einer gezeichneten Datenbank-Struktur von Mo's db_Designer II. Sie sollten trotzdem die wichtigsten Merkmale der DDL kennenlernen, um ein besseres Verständnis in Bezug auf die grafische Darstellung zu haben.

Für die weiteren Erklärungen soll uns ein einfaches Beispiel nützlich sein: Sie sollen ein kleines Warenwirtschaftssystem mit einer eigenen Datenbank für einen Kunden entwickeln. Grafisch aufbereitet könnte dabei die folgende Struktur entstehen.

Wir wissen, daß ein Warenwirtschaftssystem im Regelfall komplexer ist als das hier dargestellte. Die Struktur enthält allerdings alle in einem Entwurf möglichen Varianten von RECORDs und SETs. Die einzelnen RECORDs haben den folgenden Aufbau:

RECORD-Name	Feldname (Field)	Datentyp
Kunde	KundenNummer	ganze Zahl
	Firma	Text
	Name	Text
	Vorname	Text
	Aufnahme	ganze Zahl
	Rabattsatz	Zahl
	AktUmsatz	Zahl
	VorjUmsatz	Zahl
Lieferant	LieferNummer	ganze Zahl
	Firma	Text
	Name	Text
	Vorname	Text
	Aufnahme	ganze Zahl
	LetzteBest	ganze Zahl
	Rabattsatz	Zahl
Adresse	Strasse	Text
	Postleitzahl	ganze Zahl
	Postbereich	Buchstabe
	Ort	Text
	Telefon	Text
	Telefax	Text
	Land	Text
	AdressArt	Text
Auftrag	AuftragsNummer	Struktur
	Sachbearbeiter	Text
	BestellDat	ganze Zahl
	LieferDat	ganze Zahl
	NettoBetrag	Zahl
	Umsatzsteuer	Zahl
	BruttoBetrag	Zahl
	ZusatzText	Text
Artikel	ArtikelNummer	Text
	ArtBezeichn	Text
	EK_Preis	Zahl
	VK_Preis	Zahl
	LagerMenge	Zahl
	BestellMenge	Zahl

 RAIMA DATA MANAGER (db_VISTA III)

RAIMA DATA MANAGER (db_VISTA III) ist eine Netzwerk-Datenbank für den Einsatz in der Programmierung von C/C++ -Anwendungen. Sie zeichnet sich durch ihre hohe Performance insbesondere bei großen Datenmengen aus. Als Entwickler greifen Sie über verschiedene C-Funktionen auf die entworfene Datenbank zu. Das Design einer Datenbank wird bei db_VISTA III in einer eigene DDL abgebildet.

Die Definition eines RECORDs im RAIMA DATA MANAGER (db_VISTA III) hat Ähnlichkeit mit der Definition einer Struktur in der Programmiersprache C/C++. Die Datentypen können entsprechend der C/C++ -Spezifikation verwendet werden. Danach hat ein RECORD den folgenden Aufbau:

record Artikel {

unique key char ArtikelNummer[12];

char ArtikelBez[40];

double EK_Preis;

double VK_Preis;

double LagerMenge;

double BestellMenge;

}

Außer den üblichen Datentyp-Definitionen kann die RECORD-Definition zusätzliche Angaben über einfache und zusammengesetzte Schlüssel enthalten. Die entsprechenden syntaktischen Spezifikationen entnehmen Sie bitte aus den Handbüchern zu RAIMA DATA MANAGER (db_VISTA III).

Im RAIMA DATA MANAGER (db_VISTA III) werden SETs namentlich definiert. Dadurch besteht die Möglichkeit, zwischen einem OWNER und mehreren MEMBERs eine Relation zu erstellen. Das folgende Code-Fragment zeigt die Definition eines SETs zwischen den RECORDs Kunde und Adresse:

set Kunde_Hat_Adresse {

order ascending;

owner Kunde;

member Adresse;

}

Die Definition eines SETs beinhaltet neben den Angaben zum OWNER und MEMBER auch Informationen zur Sortier-Reihenfolge bei Speicherung der Daten.

Mo's db_Designer II generiert den entsprechenden DLL-Code für den RAIMA DATA MANAGER (db_VISTA III), trotzdem sollten Sie die Handbücher zu RAIMA DATA MANAGER (db_VISTA III) ausführlich studieren.

 CDB For Windows/DOS/UNIX

CDB For Windows/DOS/UNIX ist ähnlich wie der RAIMA DATA MANAGER (db_VISTA III) ein Netzwerk-Datenbanksystem für die Programmierung in C/C++. Es enthält alle notwendigen Funktionen zur Kontrolle der erstellten Datenbank. CDB For Windows/DOS/UNIX verfügt über eine DDL, die stark an die Definition von Strukturen in der Programmiersprache C/C++ erinnert. In CDB For Windows/DOS/UNIX wird die Definition eines RECORDs und dessen Verknüpfung mit anderen RECORDs in demselben Ausdruck definiert. Dies sieht dann folgendermaßen aus:

struct Kunde {

connect Adresse key AdressNummer;

key char ArtikelNummer[12];

char ArtikelBez[40];

double EK_Preis;

double VK_Preis;

double LagerMenge;

double BestellMenge;

}

Bei CDB For Windows/DOS/UNIX wird ein SET durch die connect-Anweisung definiert. Namentliche SETs sind in CDB For Windows/DOS/UNIX nicht möglich.

Datenbanken nach dem xBASE-Standard

Mit der Markteinführung des Datenverwaltungssystems dBASE II durch Ashton Tate im Jahre 1981 wurde der Pseudo-Standard des xBASE geboren. An diesem Standard orientieren sich mittlerweile einige populäre Datenverwaltungssysteme wie Clipper, Paradox und FoxBase. Der Vorteil dieser Systeme ist der, daß sie dem Anwender eine einfache Möglichkeit der Datenmanipulation zur Verfügung stellen. Außerdem verfügen die einzelnen Systeme über eine eigene Kommando-Sprache, die auch komplexere Anwendungen mit entsprechenden komfortablen Dialogen und Reports zuläßt.

Bei xBASE-Systemen werden, anders als bei DBMS, vom Anwender direkt physikalische Dateien erzeugt. Diese Dateien werden dann als Datenbank bezeichnet. Das heißt also, es besteht kein System, das die Kontrollen über die einzelnen Dateien gemäß dem oben vorgestellten Drei-Schicht-Modell ausführt und dadurch die einzelnen Dateien als eine Datenbank abbildet. Der Anwender muß durch seine Applikation mit Hilfe der entsprechenden Kommandos dafür sorgen, daß die richtigen Dateien zur richtigen Zeit geöffnet werden und entsprechende Verknüpfungen von Daten vorgenommen werden.

Viele Anwender verzichten leider auf die Möglichkeiten der Datenverknüpfung in xBASE-Systemen. Sie versuchen ihre Daten in einer Datenbank unterzubringen. Das hat den Nachteil, daß meistens große Mengen an Daten redundant gespeichert werden.

Mo's db_Designer II unterstützt alle Datenverwaltungssysteme, die die Möglichkeit des Lesens und Schreibens von xBASE-Dateien zulassen. Vier der wichtigsten Systeme sollen dazu näher betrachtet werden:

 dBASE III+ und dBASE IV,

 Clipper 5.0,

 FoxBASE 2.0

sowie

 PARADOX 4.0

Es soll dabei nicht unbedingt auf die programmiertechnischen Details eingegangen werden, vielmehr soll Ihnen ein Eindruck vermittelt werden, wie Sie in den einzelnen Systemen durch Verwendung von Relationen eine Anwendung flexibler gestalten können.

Mo's db_Designer II generiert die entsprechenden Datenbank-Dateien sowie eine Datei, in der alle entworfenen Relationen als Code-Fragment für die Programmierung in der entsprechenden Kommando-Sprache für eines der vier Systeme zur Verfügung steht.

 dBASE III+ und dBASE IV

 Clipper 5.0

 FoxPRO 2.0

Im dBASE III+-Standard existieren zwei verschiedene Möglichkeiten eine Relation zu verwirklichen. Der dBASE II+-Standard bietet ausschließlich die Möglichkeit, Relationen innerhalb des Programm-Codes eines dBASE-Programmes aufzubauen. Ergänzend ist dazu zu bemerken, daß in dBASE immer nur zwei Dateien miteinander in Relation gesetzt werden können. Im folgenden soll anhand kurzer Code-Fragmente die Technik der Programmierung erläutert werden.

1. Möglichkeit:

Relationen können durch den Befehl JOIN aufgebaut werden, der folgende Syntax besitzt:

JOIN WITH Alias TO Dateiname FOR Ausdruck

oder

JOIN WITH Alias TO Dateiname FOR Bedingung FIELDS Feldliste

Gehen wir in unserem Beispiel von den folgenden Datenbank-Strukturen aus:

Datenbank GEBAEUDE

Feld	Feldname	Typ	Länge	Dez
1	BEZEICHN	Zeichen	15
2	PREIS	Numerisch	9	2
3	ABSCHR	Numerisch	9	2
4	BUCHWERT	Numerisch	9	2

Datenbank GRUNDST

Feld	Feldname	Typ	Länge	Dez
1	BEZEICHN	Zeichen	15
2	KAUFPREIS	Numerisch	9	2
4	WERTZUW	Numerisch	9	2
5	ZEITWERT	Numerisch	9	2

Diese beiden Datenbanken können wir folgendermaßen mit dem Befehl JOIN in Relation setzen:

SELECT A

USE GEBAEUDE

SELECT B

USE GRUNDST

JOIN WITH GEBAEUDE TO KOMBI FOR BEZEICHN = GEBAEUDE->BEZEICHN

Durch dieses Code-Fragment werden die folgenden Aktionen ausgelöst:

a) Selektieren eines Arbeitsbereiches mit Bezeichnung A

b) Öffnen der Datenbank GEBAEUDE

c) Selektieren eines Arbeitsbereiches mit Bezeichnung B

d) Öffnen der Datenbank GRUNDST

e) Der Befehl JOIN kombiniert über den Vergleich der Inhalte von BEZEICHN die Daten der beiden Dateien zu einer neuen Datei Namens KOMBI.

Die Daten lassen sich nun durch Verwendung der neuen Datei einfach auslesen:

USE KOMBI

LIST OFF

Den Befehl JOIN können wir auch in folgender Art und Weise anwenden:

SELECT A

USE GEBAEUDE

SELECT B

USE GRUNDST

JOIN WITH GEBAEUDE TO KOMBI FOR BEZEICHN = GEBAEUDE->BEZEICHN

FIELDS BEZEICHN, ZEITWERT, BUCHWERT

Dadurch werden nur die Felder in die neue Datei eingetragen, die in der Liste hinter dem Schlüsselwort FIELDS genannt werden.

2. Möglichkeit

Soll keine neue Datei für eine Relation erzeugt werden, so können wir dies mit einer Art des Befehls SET erreichen. Im folgenden soll diese Technik durch ein kurzes Code-Fragment gezeigt werden. Die Datenbank des vorhergehenden Beispiels soll hier weiter verwendet werden. Unterschiedlich ist bei dieser Art der Relation lediglich, daß das Feld BEZEICHN indiziert sein muß:

SELECT A

USE GEBAEUDE

SELECT B

USE GRUNDST INDEX BEZEICHN

SELECT HAUS

SET RELATION TO BEZEICHN INTO GRUNDST

Durch dieses Code-Fragment werden die folgenden Aktionen ausgelöst:

a) Selektieren eines Arbeitsbereiches mit Bezeichnung A

b) Öffnen der Datenbank GEBAEUDE

c) Selektieren eines Arbeitsbereiches mit Bezeichnung B

d) Öffnen der Datenbank GRUNDST mit der Erzeugung eines Indexes auf das Feld BEZEICHN

e) Selektieren eines eigenen Arbeitsbereiches für die Relation mit Namen HAUS

f) Erzeugen der Relation auf Basis des Indexes BEZEICHN

Die zweite Möglichkeit ist etwas zeitintensiver je größer die Dateien sind. Die Datenbanksysteme FoxPRO 2.0 sowie Clipper 5.0 arbeiten mit den selben Anweisungen. Somit sind keine Änderungen des Codes notwendig.

 PARADOX 4.0

Für das Datebanksystem PARADOX 4.0 generiert Mo's db_Designer II lediglich die entsprechenden Datendateien. Die Abfragen müssen Sie individuelle in Bezug auf die Dateien im Dialog mit dem Datenbanksystem PARADOX 4.0 anlegen. Bitte lesen Sie dazu die entsprechenden Abschnitte in den Handbüchern zu PARADOX 4.0.

Relationale Datenbanksysteme mit Structured Query Language (SQL)

Die Welt der Datenbanken wird immer größer. Datenbanken werden auf den verschiedensten Rechnertypen eingesetzt. Ob Mainframe, Workstation oder PC, relationale Datenbanken haben sich als Basis-Modell von Datenbanken durchgesetzt. Unbewußt haben Sie relationale Datenbanksysteme kennengelernt. Wenn Sie einige Seiten zurückblättern, können Sie lesen, daß Sie durch Zerlegung (Normalisierung) überflüssige Datenspeicherung (Redundanz) umgehen können. Die zerlegten Datensätze lassen sich dann durch Schlüssel-Referenzen wieder miteinander verknüpfen. Diese Methoden ergeben sich aus der Relationenlehre.

Die Structured Query Language, abgekürzt SQL, ermöglicht ein einfaches und effizientes Arbeiten mit einem relationalen Datenbanksystem. SQL wurde vom ANSI (American National Standards Institute) definiert und wird derzeit auch von der ISO (International Standards Organization) anerkannt. Die meisten kommerziellen Datenbanksysteme, wie ORACLE, Informix oder DB2, bauen auf dem Standard von SQL auf, erweitern diese Syntax aber durch eigene sprachliche Elemente.

Sie sollen außer dem ANSI/ISO SQL einige Dialekte und deren Besonderheiten verschiedener DBMS (Database Management System) kennenlernen. Außerdem sollen Ihnen nur Syntaxelemente der DDL (Data Definition Language) gezeigt werden. Wie Sie später auf die Daten mittels der DML (Data Manipulation Language) zugreifen können, lesen Sie in der einschlägigen Literatur oder in den Handbüchern der einzelnen Systeme.

Im Abschnitt Allgemeine Begriffe und Methoden bei Datenbanken war unter anderem die Rede von Datensätzen und Beziehungen zwischen Datensätzen. Diese Begriffe sollen zunächst, bezogen auf SQL, genauer erläutert werden. SQL kennt den Begriff der Tabelle (TABLE). Dieser repräsentiert den Datensatz im klassischen Sinne.

PERSON

PERSON-NUMMER	NAME	VORNAME	ALTER
P1001	Müller	Otto	52
P1002	Müller	Elfriede	50
PERSADRESS

PERSON-NUMMER	ADRESS-NUMMER
P1001	A1001
P1001	A1002
P1002	A1001
P1002	A1002
ADRESSE

ADRESS-NUMMER	STRASSE	PLZ	WOHNORT
A1001	Otto-Str. 15	6000	Frankfurt/Main
A1002	Brunnen Weg 5	8834	Bayerndorf

Der Begriff der Tabelle (TABLE) wird dadurch geprägt, weil die Daten in tabellarischen Listen gespeichert werden. Die Relationen werden mittels Schlüsseln hergestellt. In SQL werden Primär-Schlüssel als PRIMARY KEYs und Fremd-Schlüssel als FOREIGN KEYs bezeichnet. Die oben gezeigten TABLEs sehen nach einer Verknüpfung über ihre Schlüssel wie folgt aus:

PERSON-NUMMER	NAME	VORNAME	ALTER	PERSON-NUMMER	ADRESS-NUMMER	ADRESS-NUMMER	STRASSE	PLZ	WOHNORT
P1001	Müller	Otto	52	P1001	A1001	A1001	Otto-Str. 15	6000	Frankfurt/Main
P1001	Müller	Otto	52	P1001	A1002	A1002	Brunnen Weg 5	8834	Bayerndorf
P1002	Müller	Elfriede	50	P1002	A1001	A1001	Otto-Str. 15	6000	Frankfurt/Main
P1002	Müller	Elfriede	50	P1002	A1002	A1002	Brunnen Weg 5	8834	Bayerndorf

Für die grafische Darstellung von Tabellen und Relationen wird bei relationalen Datenbanken häufig das Entity-Relationship-Diagramm herangezogen. Ein Entity, dargestellt durch ein Rechteck, zeigt die Sache, also zum Beispiel eine Person. Die Relationship, repräsentiert durch eine Raute, soll die Beziehung (Relation) zwischen zwei Sachen zeigen, zum Beispiel eine Person hat eine bzw. mehrere Adressen.

Die Zahlen an den Schnittpunkten der Verbindungslinien und der Entitys zeigen die Kardinalität in der Beispiel-Grafik 0 zu N an. Das Entity-Relationship-Modell bzw. -Diagramm wird im weiteren Text genauer vorgestellt werden. Mo's db_Designer II unterstützt nicht direkt das etwas wissenschaftlich anmutende Diagramm. Es wird durch eine vereinfachte Darstellungsform ersetzt, die eine relationale Datenbank genauso effizient beschreibt wie das Original. Versteckt im Hintergrund wird jeder Entwurf mit Mo's db_Designer II als Entity-Relationship-Modell abgebildet. Dadurch erst wird es möglich, daß Mo's db_Designer II Datenbanken unterschiedlicher Modelle auf einfache Art und Weise portieren kann.

Um in SQL eine Tabelle (TABLE) zu erzeugen, wird der SQL-Befehl: CREATE TABLE (...); verwendet. Dieser SQL-Befehl hat im allgemeinen in jeder kommerziellen SQL-Datenbank den gleichen Aufbau.

Für das bessere Verständnis der einzelnen Code-Fragmente soll Ihnen ein einfaches und vielleicht bereits bekanntes Beispiel dienen. Im Abschnitt Datenbanken nach dem Netzwerk-Modell (CODASYL-Modell) wurde ein einfaches Warenwirtschaftssystem dargestellt. Als Entity-Relationship-Diagramm könnte dieses Warenwirschaftssystem wie folgt aussehen:

 ANSI/ISO SQL

Wie Sie bereits wissen, entstand ANSI/ISO SQL als grundlegender Standard für die DBMS (Database Management System) verschiedener Hersteller. Gemäß dem ANSI/ISO SQL könnten Sie die Tabelle Artikel folgendermaßen definieren:

CREATE TABLE Artikel

( ArtikelNummer	CHAR (12)	NOT NULL UNIQUE,

  ArtikelBez	CHAR (40)	NOT NULL,

  EK_Preis	NUMERIC (10, 2),

  VK_Preis	NUMERIC (10, 2),

  LagerMenge	NUMERIC (10, 2),

  BestellMenge	NUMERIC (10, 2) );

Diese SQL-Anweisung legt auf einfache und beschreibende Weise den Aufbau der Tabelle (TABLE) Artikel fest. Sie können in ANSI/ISO SQL auch direkt primäre sowie Fremd-Schlüssel festlegen.

CREATE TABLE Kunde

( KundeNummer	INTEGER	NOT NULL PRIMARY KEY,

  Firma	CHAR (40),

  Name	CHAR (20),

  Vorname	CHAR (20),

  Aufnahme	INTEGER,

  Rabattsatz	NUMERIC (10, 2),

  AktUmsatz	NUMERIC (10, 2),

  VorjUmsatz	NUMERIC (10, 2),

.. AdressNummer	INTEGER,

  FOREIGN KEY (AdressNummer) REFERENCES Adresse (AdressNummer) );

CREATE TABLE Adresse

( AdressNummer	INTEGER	NOT NULL PRIMARY KEY,

  Strasse	CHAR (25),

  Postleitzahl	NUMERIC (4),

  Postbereich	CHAR (1),

  Ort	CHAR (25),

  Telefon	CHAR (15),

  Telefax	CHAR (15),

  Land	CHAR (3),

  AdressArt	CHAR (1) );

Oft kommt es vor, daß ein Feld in einer Tabelle (TABLE) auf einen gültigen Eingabewert hin überprüft werden. Beispiele dafür sind, daß eine Postleitzahl zwischen 1000 und 8999 liegen muß oder der Postbereich in W für West und O für Ost aufgeteilt ist.

CREATE TABLE Adresse

( AdressNummer	INTEGER	NOT NULL PRIMARY KEY,

  Strasse	CHAR (25),

  Postleitzahl	NUMERIC (4)

CHECK (Postleitzahl BETWEEN 1000 AND 8999),

  Postbereich	CHAR (1)

CHECK (Postbereich IN ('O', 'o', 'W', 'w')),

  Ort	CHAR (25),

  Telefon	CHAR (15),

  Telefax	CHAR (15),

  Land	CHAR (3),

  AdressArt	CHAR (1) );

Die Möglichkeiten der CHECK-Anweisung zur Überprüfung der eingegebenen Daten ist vielfältig. Wenn Sie eine solche Anweisung einsetzen, sollten Sie sich im Klaren darüber sein ob, sich die zu prüfenden Daten nicht ständig ändern.

Mo's db_Designer II unterstützt alle Möglichkeiten und syntaktischen Eigenschaften von ANSI/ISO SQL. Genauere Informationen zu ANSI/ISO SQL erhalten Sie aus einschlägiger Literatur, die Sie im "dicken" Handbuch zu Mo's db_Designer II finden.


Das Entity-Relationship-Modell

In diesem Abschnitt sollen Sie einige Ideen zum Entwurf von Datenbanken kennenlernen. Diese Überlegungen beruhen auf dem Entwurfsverfahren des Entity-Relationship-Modells. Dieses Modell wurde im Jahre 1977 zum erstenmal von Peter Chen veröffentlicht. Es beruht auf der Überlegung, die drei orginären Modelle, das relationale, das Netzwerk- und das hierarchische Modell, zu einem übergreifenden semantischen Modell zusammenzufassen.

Dabei wird davon ausgegangen, daß die Objekte eines Unternehmens aus der realen Welt in einem Datenbanksystem abgebildet werden sollen. Wollen Sie diese Darstellung eines Unternehmens in einer relationalen Datenbank implementieren, so müssen Sie eine andere Methode des Entwurfs verwenden, als bei einer Datenbank des Netzwerk-Modells.

Das Entity-Relationship-Modell steht ist eine Zwischenstufe. Das Entity-Relationship-Modell bildet mit einfachen Symbolen die Unternehmensstruktur von der einen Seite her ab und ist ein für jedes Datenbankmodell interpretierbaren Bauplan einer UnternehmensDatenbank auf der anderen Seite. Mo's db_Designer II setzt diese Technik ein. Dadurch ist es mit Mo's db_Designer II möglich, daß Beschreibungsprachen für verschiedene Datenbanksysteme generiert bzw. analysiert werden können.

Die Symbolik des Entity-Relationship-Modells ist sehr einfach. Sie besteht im wesentlichen aus zwei Symbolen. Dem Rechteck, das eine Entity darstellt und der Raute, die einer Relationship (Relation) entspricht. Die Entity ist eine Sache, ein Ding, das sich greifen läßt. Die Relationship ist eine Beziehung zwischen Dingen.

Ein typisches Beispiel ist, daß eine Person ein Kind haben kann.

Wie Sie wissen, ist die Existenz eines Kindes nur dann gegeben, wenn es Eltern also Personen gibt. Dieser besondere Umstand kann ebenfalls durch das Entity-Relationship-Modell dargestellt werden. Dazu gibt es besondere Symbole. Ein Rechteck mit doppeltem Rahmen bezeichnet ein Weak Entity, zu deutsch ein "schwaches" Entity. Dieses Weak Entity ist existenzabhängig. Die Relationship, die ein Entity mit einem Weak Entity verknüpft, bekommt zusätzlich zur Raute das Initial E. Dadurch wird die existentielle Abhängigkeit des Weak Entity vom Entity angezeigt. Ein Richtungspfeil soll zusätzlich die Richtung der Abhängigkeit anzeigen.

Die folgende Grafik zeigt die erweiterte Darstellung der PERSON-KIND Beziehung.

Das Zusammensetzen der einzelnen Symbole kann aus verbalen Fragestellungen hergeleitet werden. So könnte die Frage für die PERSON-KIND Beziehung folgendermaßen gestellt werden: "Eine Person kann mehrere Kinder haben, aber ein Kind kann nur dann existieren (in der Datenbank aufgenommen werden), wenn es mindestens einen Elternteil hat?!".

Ihre Aufgaben als Datenbank-Entwickler besteht demnach darin, möglichst die komplexen Zusammenhänge eines Unternehmens auf die wesentlichen Zusammenhänge zu reduzieren. Das heißt, Sie gehen am besten davon aus, welche Informationen Sie später aus dem Datenbanksystem gewinnen wollen und welche Basisdaten dazu notwendig sind. Die Beziehung der Objekte, zu denen die Basisdaten gehören, können Sie mit der allgemeinen Fragestellung: "Was hat das Objekt A mit dem Objekt B zu tun?" am einfachsten ermitteln.

Wenn Sie ein unternehmensweites Datenbanksystem entwerfen sollen, dann können Sie in zwei Schritten vorgehen:

1. Schritt

Sie analysieren die Organisationsstruktur des Unternehmens. Bilden Sie entsprechenden Abteilungen in einem Organisationsplan. Beschreiben Sie die Schnittstellen zwischen den einzelnen Abteilungen.

2. Schritt

Sie gehen in die einzelnen Abteilungen, die aus dem vorhergehenden ersten Schritt hervorgegangen sind. Beobachten Sie die Arbeitsweisen und den Papier- und Formularfluß innerhalb der Abteilung sowie in bzw. aus anderen Abteilungen.

Durch das Verfolgen des Formularflußes und Analysieren der einzelnen Formulare können Sie die notwendigen Basisdaten für Ihren späteren Datenbank-Entwurf ermitteln. Versuchen Sie, aus den einzelnen Vorgängen Objekte zu bilden und aus den dazugehörigen Bewegungen die Beziehung der Objekte zueinander heraus zu filtern.

Dabei können Sie sich Notizen machen, die bereits die ersten Züge der späteren Datenbanken als Entity-Relationship-Diagramm haben. Mo's db_Designer II unterstützt Sie bei diesen Notierungen. Die ermittelten Basisdaten werden im Entity-Relationship-Modell als Attribute bezeichnet. Attribute sind die Eigenschaften der Entity. Das heißt, daß eine Person als Eigenschaft einen Namen, einen Vornamen, eine Adresse usw. hat. Im Entity-Relationship-Diagramm werden die Attribute als Ovale dargestellt. Die meisten Datenbank-Entwickler lassen dieses Symbol zugunsten der Übersichtlichkeit weg und notieren sich die Attribute zu einer Entity auf einem separaten Blatt Papier.

Attribute sollten immer eine atomare Eigenschaft eines Entitys darstellen. Das heißt, daß verschiedene Attribute sich in weitere Attribute zerlegen lassen. Sollte das möglich sein, dann können Sie oft ein eigenes Entity definieren. Im oben gezeigten Beispiel können Sie das Attribut Adresse zerlegen. Eine Adresse hat dann eine Straße, eine Postleitzahl, einen Postbereich, eine Landeskennung und einen Ort.

Wie Sie selber sehen können, ist es besser, die Attribute auf einem gesonderten Blatt zu notieren. In Mo's db_Designer II können Sie diese Notizen in einem Attribute- bzw. Feld-Dialog vornehmen.

Bei Ihrer Analyse ermitteln Sie nicht nur die Existenz von Attributen, sondern Sie lernen auch die Werte dieser Attribute kennen. So könnte zum Beispiel das Attribut Nachname den Wert Müller haben oder das Attribut Postleitzahl den Wert 6400. Die Kenntnis über die Werte der Attribute ist später notwendig, um den Datentyp der Attribute, zum Beispiel Text oder Zahl, festlegen zu können.

Wie Ihnen in den Grafiken sicher aufgefallen sein wird, wurden an den Schnittstellen der Verbindungslinien und der Entitys eine Zahl bzw. ein Buchstabe aufgeschrieben. Diese kennzeichnen die Kardinalität, also das mengenmäßige Verhältnis der Entitys zueinander. Im Abschnitt Allgemeine Begriffe und Methoden bei Datenbanken haben Sie den Begriff der Kardinalität bereits kennengelernt. Dort konnten Sie folgende Aussagen lesen, die wir nachfolgend genauer betrachten wollen:

Verbale Aussage	Kardinalität
"Eine Person kann an mehreren Orten wohnen!"	1:N
"An einem Ort wohnen mehrere Personen!"	1:N
"Mehrere Personen können an mehreren Orten wohnen!"	N:M

Die Kardinalität wird durch bestimmte Zahlen bzw. Buchstaben beschrieben. Dafür lassen sich synonyme verbale Aussagen nennen:

Verbale Aussage	Kardinalitätsziffer
Ein Objekt	1
Mehrere Objekte	N oder M
Es kann ein Objekt sein	0

Die fettgedruckten Schlüsselworte können in Ihren Fragestellungen auftauchen. So läßt eben die Aussage: "Eine Person kann an mehreren Orten wohnen!" den Schluß auf die Kardinalität 1:N zu.

Sie sollten sich zu Ihrem Entwurf jeweils Gedanken machen, welche Mengen an Daten in der späteren Datenbank in Bezug auf die Relationen gespeichert werden sollen. Daraus und aus der entsprechenden verbalen Formulierung einer Aussagen können Sie die Kardinalität ableiten.

Ein kleiner Tip soll Ihnen weiterhelfen. Die Kardinalität N:M ist in vielen Datenbanksystemen ohne Umwege nicht bzw. nur schwierig zu implementieren. Deshalb sollten Sie eine solche Kardinalität zerlegen. Dazu ein kleines Beispiel:

Diese Darstellung sagt aus, daß ein Auftrag mehrere Artikel haben kann, aber daß auch ein Artikel in mehreren Aufträgen vorkommen kann. Diese N:M-Relation können Sie in einfachere 1:N-Relationen zerlegen. Der grafische Aufwand ist zwar größer, aber die Implementierung ist vom verwendeten Datenbanksystem weitgehend unabhängig.

Das temporäre Entity AUFTR_ART beinhaltet lediglich zwei Fremdschlüssel, die als Verweis auf das Entity AUFTRAG bzw. ARTIKEL dienen.

Wenn Sie mehr zum Entity-Relationship-Modell wissen möchten, können Sie einiges in den Büchern nachlesen, die im "dicken" Handbuch unter Wissenschaftliche Literatur genannt werden.


Die Normalisierung von Datenstrukturen

Im vorhergehenden Abschnitt war des öfteren der Begriff Zerlegung zu lesen. Näher eingegangen wurde auf diese Zerlegung allerdings nicht. Diese Zerlegung von Objekten wird als Normalisierung bezeichnet. Die Daten-Normalisierung ist eine Menge an Regel und Methoden, die Ihnen helfen sollen

 Relationen zwischen Attributenfestzustellen,

 Attribute zu Relationen zu formen

und

 Relationen zu einer Datenbank zusammen zu führen.

Ein Attribut ist synonym mit dem Begriff bzw. der Bedeutung eines Datenfeldes. Der Begriff Relation steht bei der Normalisierung für eine Gruppe von Attributen. Er ist synonym mit den Begriffen Datensatz, Record, Tabelle bzw. Entity.

Die Normalisierung soll Sie dabei unterstützen, Anomalien in einem Datenbank-Entwurf zu entfernen. Anomalien sind Zustände, die andere Datenbestände negativ beeinflussen können. Anomalien können auftreten, wenn Sie in der erstellten Datenbank Daten einfügen, löschen oder ändern wollen.

KUNDE_NAME

KUNDE_NUMMER

KUNDE_ADRESSE

PRODUKT_NUMMER

PRODUKT_BESCHREIBUNG

PRODUKT_PREIS

Die oben aufgeführten Attribute beschreiben eine einfache Datenbank, in der Daten von Kunden und Produkten im selben Datensatz gespeichert werden können. Dies hat zur Folge, daß beim neu anlegen eines Kunden jeweils immer ein "leeres" Produkt mitangelegt werden muß. Beim Löschen eines Produktes wird gleichzeitig immer der im Datensatz vorhandene Kunde mitgelöscht. Diese Zustände, eben Anomalien, sind für einen sauberen Datenbank-Betrieb nicht akzeptabel. Sehen Sie sich ein weiteres Beispiel zum Thema Fußball an.

F_SPIELER_NUMMER

MANNSCHAFTS_NAME

TRAINER_NAME

VEREINSNAME

Was passiert wenn die Mannschaft einen neuen Trainer bekommt? Alle Datensätze dieser Datenbank müssen nach dem alten Trainer durchsucht werden, und der Name entsprechend geändert werden. Vom zeitlichen Aufwand abgesehen, kann diese Aufgabe Fehler verursachen. Wenn Sie den Datensatz normalisieren, können Sie diese Änderungs-Anomalie ausschließen.

Datensatz_A	Datensatz_B
F_SPIELER_NUMMER MANNSCHAFTS_NAME	MANNSCHAFTS_NAME TRAINER_NAME VEREINSNAME

Wenn Sie jetzt den einen neuen Trainer für Ihre Fußballmannschaft einstellen wollen, können Sie mit der Änderung des Datensatz_B die Datenbank auf den neuesten Stand bringen.

Die Normalisierung ist eine gute Methode, Datenbanken effizient zu gestalten. Vorab wollen wir einige Begriffe erläutern, die zum Verständnis der Normalisierung und deren Methoden notwendig sind.

Die funktionale Abhängigkeit

Sehen Sie sich das folgende Beispiel an. Es stellt die Umsatztabelle über einen Zeitraum von 18 Jahren eines Handelsunternehmens dar.

Jahr	Umsatz (in Mio. DM)	Jahr	Umsatz (in Mio. DM)
1	2,0	10	2,0
2	1,7	11	2,4
3	1,4	12	2,6
4	1,2	13	3,0
5	1,1	14	3,1
6	1,1	15	3,2
7	1,1	16	3,0
8	0,9	17	2,9
9	1,9	18	3,3

Die Daten in dieser Tabelle sind in einer relationalen Form. Jede Datenzeile baut auf zwei Attributen, Jahr und Umsatz, auf. Der primäre Schlüssel der Relation ist das Attribut Jahr. Jede Datenzeile ist durch das Attribut Jahr eindeutig identifizierbar. In der Normalisierung wird eine solche Relation folgendermaßen notiert:

UMSATZDATEN (Jahr, Umsatz)

Die Relation erhält einen Namen. Diesen können Sie in einem späteren Entwurf in Mo's db_Designer II als Bezeichnung eines RECORDs, einer Tabelle (TABLE), einer Datenbank bzw. eines Datensatzes verwenden. Der primäre Schlüssel einer Relation wird hier unterstrichen dargestellt.

Was bedeutet in Bezug auf das oben gezeigt Beispiel die funktionale Abhängigkeit? Die Mathematik definiert eine funktionale Abhängigkeit wie folgt:

Ein Attribut bzw. eine Attributs-Kombination B ist funktional abhängig von einem Attribut bzw. Attribut-Kombination A derselben Relation R, wenn zu einer bestimmten Ausprägung von A höchstens eine Ausprägung von B möglich ist.

In dem oben gezeigten Beispiel ist klar erkennbar, daß zu jedem Jahr nur ein Umsatzwert gehört. Das heißt, daß zum 15. Jahr eine Ausprägung des Umsatzes, hier 3,2 Mio. DM, zugeordnet werden kann. Das Attribut Umsatz ist funktional abhängig vom Attribut Jahr, da für jedes Jahr nur eine Ausprägung (ein Wert) verzeichnet wurde.

Umgekehrt tauchen des öfteren in der Umsatztabelle die gleichen Umsatzbeträge auf, so zum Beispiel wurde der Umsatz von 3,0 Mio. DM im 13. und 16. Jahr verzeichnet. Es sind mehr als eine Ausprägung in Bezug auf den Umsatz aufgetaucht. Somit ist das Attribut Jahr nicht funktional abhängig vom Attribut Umsatz.

Vereinfacht ausgedrückt ist die funktionale Abhängigkeit von einem Wert A dann gegeben, wenn ein Wert B höchstens einmal in Bezug auf den Wert A auftritt.

Die Normalformen von Relationen

Auslöser für die Übernahme bestimmter mathematischer Regel aus Mengenlehre in die Datenverarbeitung waren Anfang der 70er Jahre die steigenden Kosten im Bereich der Prozessoren, Datenträger und des Zugriffs auf diese. Dies nahm E. F. Codd 1970 zum Anlaß, entsprechende Arbeitenzu veröffentlichen. Durch die Normalisierung soll eine möglichst redundanzfreie Datenspeicherung erreicht werden. Die Normalisierung wird in mehreren Stufen durchgeführt. Sie werden die erste bis dritte Normalform kennenlernen.

Zuvor sollen Sie noch zwei Begriffe kennenlernen. Zum einen den Begriff des Schlüsselkandidatens und des Primärschlüssels. Den Primärschlüssel haben Sie bereits in anderem Zusammenhang im Abschnitt Allgemeine Begriffe und Methoden bei Datenbanken kennengelernt. Hier soll der Begriff etwas genauer betrachtet werden.

 Schlüsselkandidat

Der Schlüsselkandidat ist ein Attribut bzw. eine kleine Gruppe von Attributen, die einen Datensatz einer Relation identifizieren können und solange wertmäßig konstant bleiben, wie der Datensatz existiert. Als Beispiel soll Ihnen die Relation für die Anmeldung zu einem EDV-Kurs dienen.

ANMELDUNG (KURS, LFD_NR, TEILNEHMER, ANMELDE_DAT)

Als Tabelle mit entsprechenden Daten sieht die Ralation folgendermaßen aus:

KURS	LFD_NR	TEILNEHMER	ANMELDE_DAT
Textverarbeitung	01	Otto Meier	05.05.1992
Textverarbeitung	02	Elfriede Müller	02.10.1992
Textverarbeitung	03	Egon Schmidt	05.05.1992
Datenbanken	04	Otto Meier	05.05.1992
Datenbanken	05	Traudel Koslowski	12.06.1992
Datenbanken	06	Hans Stubenhocker	13.06.1992

In der Tabelle können Sie jede einzelne Datenzeile durch die Attributkombinationen KURS+LDF_NR oder durch KURS+TEILNEHMER identifizieren. Es kann also sein, daß es zwei oder mehrere Schlüsselkandidaten geben kann.

 Primärschlüssel

Der Primärschlüssel ist das Attribut bzw. sind die Attribute-Gruppe, die als Schlüsselkandidat lokalisiert wurden und die Zeile einer Datentabelle eindeutig identifizieren kann. Der Primärschlüssel wird entsprechend durch eine Unterstreichung gekennzeichnet.

ANMELDUNG (KURS, LFD_NR, TEILNEHMER, ANMELDE_DAT)

 Die erste Normalform (1NF

Die erste Normalform ist dann gegeben, wenn keines der Attribute innerhalb einer Relation Werte aufweist, die sich aus mehreren Werten zusammensetzen. Sehen Sie dazu eine Beispiel-Relation an:

MITARBEITER (MITARB_NR, MITARB_NAME; KINDER_NAMEN)

Diese Relation sagt aus, daß die Daten eines Mitarbeiters gespeichert werden sollen. Zu diesen gehören unter anderem auch die Daten, z.B. die Namen der Kinder des Mitarbeiters. Ein Mitarbeiter kann allerdings mehrere Kinder haben. Das hat zur Folge, daß in dem Attribut KINDER_NAMEN mehrere Namen gespeichert werden. Die Relation ist dann nicht in der ersten Normalform. Zerlegen Sie diese Relation nun, dann entstehen zwei neue Relationen:

MITARBEITER (MITARB_NR, MITARB_NAME)

MITARB_KIND (MITARB_NR, KIND_NAME)

Jetzt können Sie die Daten der Kinder jeweils für ein Kind in einer eigenen Relation speichern. Die Daten des Mitarbeiters werden mittels der MITARB_NR bei einer Auswertung zusammengeführt.

Ein zweites Beispiel soll Ihnen zeigen, daß bestimmte Attribute nicht atomar, im Sinne von nicht weiter zerlegbar, sind.

MITARBEITER (MITARB_NR, MITARB_NAME, ADRESSE)

Was ist, wenn Sie die Relation MITARBEITER bezüglich eines bestimmten Postleitzahlgebietes auswerten wollen? Sie werden diese Informationen nur schwerlich gewinnen. Das Attribut ADRESSE, das diese Information beinhaltet, könnte also entsprechend zerlegt werden. Die Relation MITARBEITER ist in dem Fall nicht in der ersten Normalform. Normalisiert hat die Relation dann folgendes Aussehen:

MITARBEITER (MITARB_NR, MITARB_NAME, STRASSE, POSTLEITZAHL, ORT)

 Die zweite Normalform (2NF

Die zweite Normalform ist dann gegeben, wenn eine Relation in der ersten Normalform ist und jedes Nicht-Primärattribut von jedem Schlüsselkandidaten der Relation voll abhängig ist. Ein NichtPrimärattribut wird ein Attribut dann bezeichnet, wenn es keinem der festgelegten Schlüsselkandidaten angehört.

Die folgende Relation ist nicht in der zweiten Normalform:

TEILNEHMER (MITARB_NR, KURS_NR, STOFF_BEURTEIL, MITARB_NAME)

In dieser Relation ist der Schlüsselkandidat gleichzeitig der Primärschlüssel. Das Attribut STOFF_BEURTEIL ist voll funktional vom Primärschlüssel abhängig. Das Attribut MITARB_NAME hingegen ist auch abhängig vom Attribut MITARB_NR. Sie müssen diese Relation zerlegen:

TEILNEHMER (MITARB_NR, KURS_NR, STOFF_BEURTEIL)

MITARBEITER (MITARB_NR, MITARB_NAME, STRASSE, POSTLEITZAHL, ORT)

Durch diese Normalisierung können Sie Speicherplatz auf Ihrem Datenträger sparen und die Änderung von Mitarbeiterdaten, besonders dem Namen, sind einfach durchzuführen.

 Die dritte Normalform (3NF

Aus Erfahrung ist zu sagen, daß die dritte Normalform bei den meisten Datenbank-Entwürfen selten angewandt wird. Ein Grund dafür ist, daß eine Unternehmensstruktur der realen Welt zu sehr zergliedert werden würde. Die Zusammenführung der Daten in einem Datenbanksystem nimmt viel Rechenzeit in Anspruch. Sie sollten sich deshalb überlegen, ob die Anwendung dritte Normalform für die entworfene Datenbank sinnvoll ist.

Die dritte Normalform ist dann gegeben, wenn sich eine Relation in der zweiten Normalform befindet und wenn kein Nicht-Primärattribut transitiv von einem Schlüsselkandidaten abhängig ist. Transitive Abhängigkeit bedeutet, daß das Nicht-Primärattribut nicht nur vom eigentlichen Schlüsselkandidaten, sondern auch von einem anderen Nicht-Primärattribut abhängig ist.

Ein Beispiel soll diesen Zustand verdeutlichen:

KURS (KURS_NR, TRAINER_NR, TRAINER_NAME)

Hier in dieser Relation ist das Attribut TRAINER_NAME funktional abhängig vom Schlüssel-Attribut KURS_NR. Es besteht allerdings auch eine funktionale Abhängigkeit in Bezug auf das Attribut TRAINER_NR. Die Relation ist nicht in der dritten Normalform. Zerlegen Sie die Relation, dann erhalten Sie die folgenden zwei normalisierten Relationen:

KURS (KURS_NR, TRAINER_NR)

TRAINER (TRAINER_NR, TRAINER_NAME)

Die Normalisierung ansich ist eine Sache der Erfahrung. Sie haben einige Methoden dazu theoretisch kennengelernt. Sie sollten allerdings vermeiden, diese Regel auf Biegen und Brechen einzusetzen. Normalisierung hat auch einiges mit Gefühl für die Zusammenhänge der Daten zu tun. Die Normalisierung ist keine technische und automatisierbare Arbeitsweise, sondern erfordert viel Fingerspitzengefühl. Sie sollten immer darauf achten, daß sich Ersparnis bei der Speicherung der Daten und die Performance der Datenbank nicht im Wege stehen. Weitere tiefergehende Informationen bietet Ihnen die im "dicken" Handbuch aufgeführte Literatur.