My Remarks!

Ausgabe 2 heute wieder mit den ältesten Programmierweisheiten aus der Steinzeit.

Titel der heutigen Ausgabe:

"Datenmodell, was ist das?" oder "Der überwältigende Vorteil von Redundanzen und alten Hüten"

Heute möchte ich alles rund um das Thema AS/400, RPG, Datenmodell, SQL und Normalformen diskutieren (und das wird nicht sehr viel sein). Grundsätzlich verhält es sich mit RPG und einer relationalen Datenbank wie mit einer Unterhaltung zwischen einer Kakalake und Albert Einstein: Beide bewohnen zwar den gleichen Planeten können sich aber absolut nicht verstehen. Wenn man alledings noch berücksichtigt, dass sich das ganze in dem deutschen Weltunternehmen - nennen wir es einmal Maschinenfabrik Hans Bauer GmbH⁽¹⁾ - abspielt, stellt sich heraus, dass die Kakalake nicht auf der Erde sondern auf Beteigeuze Sieben lebt. Zunächst möchte ich hier die unterschiedlichen Definitionen der Datenmodellierung ansprechen:

1. Datenmodell (in der Informatik): Modell von Beziehungen und Strukturen um Informationen weitgehend redundanzfrei zu speichern.
2. Datenmodell (bei MHB⁽²⁾): Ansammlung von Dateien, bei denen die Informationen möglichst unstrukturiert, mit hoher Redundanz und frei von Beziehungen gespeichert werden.

Wenn man den Pfad der "schulmäßigen" Informatik verlässt (allerdings muss man denselben sehr stark in Richtung Unterholz verlassen) wird man die enormen Vorteile und Einsparmöglichkeiten des MHB-Modells erkennen. Hier einige Hinweise für den MHB Programmier-Anfänger:

1) Entfernen von Referenz-Informationen: Daten auf die man typischerweise von anderen Dateien zugreifen müsste, werden - um sich einen Zugriff zu sparen - einfach auf die Datei übertragen aus der man zugreifen will. Die so aufgebaute mehrfache Speicherung von Referenzinformation erzeugt enorme Geschwindigkeitsvorteile.

2) um das vorgehen von a) noch zu verbessern, unterlässt man die Speicherung von Fremdschlüsseln sondern man nimmt alle Referenzinformationen auf die oben beschriebene Datei mit auf. Das Einsparpotential bezüglich Speicherplatz wird sich auch sehr positiv auswirken.  Faustregel: Überall wo die Artikel-Nummer gespeichert wird, muss zwangsläufig auch die Artikelbezeichnung stehen. Sollte die Artikelbezeichnung mehrsprachig sein müssen, kann man sich dann mit den Feldern artbez_franz, artbez_engl, artbez_span, etc. behelfen. Durch dieses Prinzip können wir beliebig viele sprachen verwalten! Die hier beschriebene Idealform wäre, alles in einer einzigen Datei mit tausenden verschiedener sog. Satzarten zu verwalten. Das lässt sich aber nicht mehr durchsetzen, da der EDV-Leiter so ein "Junger Wilder" ist, der sein Diplom noch auf der Zuse Z1 gemacht hat.

3) Datensicherheit: Dadurch, dass man alle Informationen doppelt und dreifach auf verschiedenen Dateien gespeichert hat, ist es nicht weiter schlimm, wenn mal irgendwelche Daten verloren gehen. In den meisten Fällen kann man sich aus irgendwelchen anderen Dateien, die Informationen wieder herstellen.

4) Eindeutige Feldnamen über alle Dateien. Bei diesem Paradigma, welches noch aus der Zeit stammt, als sich gerade die ersten unstrukturierten Zellhaufen in der Ursuppe gebildet haben, erhält jeder Feldname noch einen, nach Gusto zu vergebenden, zweistelligen Prä- oder Suffix. Somit weiss jeder, der ein Feld verwenden will gleich, aus welcher Datei es stammt (oder auch nicht). Beispiel gefällig?

Der Mandant heisst in der Datei ADMADRE also MNDAD und in der Datei KBOJRU dann MNDOJ. klar?? Dies führt zu sehr grosser Freude bei den Jung-Programmierern alle unter 60, die mit solch unausgereiften Tools wie SQL, eine dateiübergreifende logische Datei (heute nennt man das VIEW) herstellen wollen. Diesen Kollegen muss dann erst einmal klar gemacht werden, wozu die ganzen Redundanzen auf den Dateien erzeugt wurden. (by the way, what the hell is MANDANT??? (kleiner Insiderjokus))

5) Strikte Unterlassung der Verwendung von Pflichtfeldern. Erst das anwenden dieser Regel ermöglicht es, einen Datensatz nach und nach zu komplettieren. Beispiel:

wieso soll es einem Anwender einer Auftragsabwicklung zugemutet werden, eine Auftragsart auszuwählen? Vielmehr kann man solche Randinformationen später, nach dem 3. oder 4. Fehlversuch einer weiterführenden Verarbeitung, manuell nachpflegen. Diese Tätigkeiten halten die Mitarbeiter bei hoher geistiger Frische.

6) Der Anteil der Felder einer Datei, die zu einem eindeutigen Schlüssel gehören (falls überhaupt vorhanden) sollte mindestens 50% betragen. Der steinzeitliche Projektleiter sieht es besonders gerne, wenn nicht mehr als ein Feld ausserhalb des (ggf vorhandenen) eindeutigen Schlüssels liegt. Nicht verstanden?? Hier ein Beispiel aus dem legendären Dokumentensystem:

Um ein Dokument eindeutig zu identifzieren braucht man folgende Informationen:

Gruppe, Bereich, Mandant, Belegkreis, Servicebereich, Artikel, Auftragsart, Kampagne, Land, Dokumenten-Nr und Dokumenten-Typ.

dafür erhält man dann die Informationen:

Dokumentenbezeichnung und Formulartyp.

überall wo dann ein Brief referenziert wird, werden die oben als Schlüssel genannten Felder mit übernommen. Somit erspart man sich lästiges Referenzlesen von zum Schlüssel gehörenden Feldern, welches man hätte, wenn man solche unausgereiften Methoden wie künstliche Schlüssel (ID's oder Sequences) verwenden würde. Zudem sorgt man für konstanten Auftragseingang bei der Festplattenabteilung von IBM.

7) Als erweiterter Nervenkitzel zu Regel 5 der UNIFUG⁽¹⁾-Knigge, wird hier vollständig auf den Transaktionsmechanismus der relationalen Datenbank verzichtet. Im Unterschied zu der Regel wird zur Betäubung aber Tannenzäpfle statt Weizen verwendet. Die (Aus-)Wirkungen sind aber identisch. Wer braucht heute schon noch Rollback oder Commit? wenn man bedenkt, dass der typische Programmierer auf der AS400 ein stattliches Alter von durchschnittlich 62 Jahren besitzt und hier schon die ersten Alterserscheinungen wie Sehschwäche, Gicht, Alzheimer (die MHB⁽²⁾ Variante gilt als besonders schwer) auftreten, kann man sich leicht ausrechnen wieviel zeit draufgeht bis so ein Informatik-Opa eine Doppelwort-Anweisung wie "Commit" erfolgreich abgesetzt hat. Durch dieses "AutoCommit", kann man pro Mitarbeiter sicher 20-30 Minuten pro Tag ersparen. Dies auf das ganze Jahr hochgerechnet gibt doch einen stattlichen Betrag der die Jahres-End-Prämie sichert!

Seien Sie gespannt auf die nächste der Ausgabe der RPG oldest News. Der Titel stand bei Redaktionsschluss noch nicht fest. Sicher ist allerdings, dass es nichts Neues sein wird!

⁽¹⁾ Name von der Redaktion geändert
⁽²⁾ MHB = Maschinenfabrik Hans Bauer GmbH