Beispielmodell Buchungskreis

Für die "eingebaute Funktionalität" heißt das, dass eine Unterscheidung von Buchungssätzen verschiedener Buchungskreise bei der Nutzung einer relationalen Datenbank in der Regel so modelliert wird, dass jeder Buchungssatz ein Attribut "Buchungskreis" erhält. Häufig hält man derartige, identifizierende Informationen nur in Parameter- oder Systemdateien vor. Beispielsweise kann Buchungskreis "1" etwa die GmbH & Co. KG einer Firma und Buchungskreis "2" die zugehörige Komplementär-GmbH sein. Der Buchungskreis hat keine weitere Eigenschaft als mittels Angabe der Nummer und Text die Trennung der Buchhaltung in zwei Untergruppen zu ermöglichen.

Es erscheint durchaus lohnenswert, einen Schritt weiter zu gehen und im Modell eine übergeordnete Systematik zu entwickeln, die die Buchungskreise verwaltet. Ein Buchungskreis ist dann zum Beispiel ein separates, ordnendes Objekt, das als eine seiner Eigenschaften seine Buchungssätze aktiv verwaltet. Derartige Buchungskreis-Objekte lassen sich auch nachträglich einbauen. Außerdem können mehrere parallel arbeitende Buchungskreise existieren. In einer objektorientierten Datenbank kann jedes Buchungskreis-Objekt direkt eine Liste mit (Referenzen zu) seinen Buchungssätzen halten. Es verhält sich so, als ob jedes Buchungskreis-Objekt eine eigene Tabelle nur seiner Buchungssätze definieren würde. Aber es ginge noch mehr: Jedes Buchungssatzobjekt kann auch mehr als einem Buchungskreisobjekt zugeordnet sein. Dadurch wird also eine Änderung des Anwendungsmodells durch Instanziierung weiterer Objekte erzeugt. Der Umbau des Modells und damit die Erweiterung der Funktionalität werden durch Neuorganisation der Beziehungen der Objekte untereinander erreicht. Die Klassen selbst ändern sich dabei nicht.

Individuell verwaltbare Geschäftsobjekte

Möglicherweise ist es nicht immer empfehlenswert, alle Objekte desselben Typs in einer einzigen großen Tabelle zu verwalten. Das spart nicht nur Attribute zur Unterscheidung oder besseren Zuordnung der Einträge, es hilft auch beim Verständnis des Gesamtmodells.

Die Tabellen relationaler Datenbanken können in einer objektorientierten Datenbank auf derartige, der Geschäftslogik folgenden Verwaltungsobjekte aufgeteilt werden.

Natürlich sind solche Beispiele auch anders darstellbar. Hier geht es jedoch um die Frage, ob die Nutzung einer relationalen Datenbank für ein ERP-System nicht nur zu einer bestimmten technischen Lösung führt, sondern auch zu einem bestimmten Verständnis der geforderten Anwendungslösung und andersherum. Beides scheint sich gegenseitig zu bedingen.

Die Vorstellung von individuell zu verwaltenden Geschäftsobjekten in einer objektorientierten Datenbank integriert die Rolle der Tabellen in die Modellierung. Die in einem relationalen System zu verwaltenden Tabellen gehen in das Modell der objektorientierten Datenbank über. Die objektorientierte Datenbank ist dann - sicherlich nicht nur im Vergleich zu einer relationalen Datenbank - keinesfalls mehr zu kompliziert.