Deutsch|English

 

Normalisierung der Daten

Ein Buchführungssystem ist so gut wie das zugrunde liegende Datenmodell. Ein gute Datenorganisation vereinfacht nicht nur die Eingabe, sondern erhöht die Flexibilität und Aussagekraft der Berichte. Es ist deshalb erstaunlich, wie wenig die Datenmodellierung als Innovationsmöglichkeit auch in der Finanzbuchhaltung aufgegriffen worden ist.

Die nach mathematischen Kriterien optimierte Organisation der Daten ist eine Grundvoraussetzung für den effizienten Einsatz von relationalen Datenbanken und wird als Normalisierung bezeichnet. Die grundlegenden
Konzepte wurden von Edgar F. Codd formuliert (E.F.Codd, „A Relational Model of Data for Large Shared Data Banks“, Comm.ACM 13 (6), June 1970, pp. 377-387). In der Arbeit mit grossen Datenbanken entwickelte er seine Normalisierungsregeln, die bis heute breite Akzeptanz finden.

Codd, E.F. (1970). "A Relational Model of Data for Large Shared Data Banks". Communications of the ACM 13 (6): 377–387

 

Codd erkannte früh, dass sich durch die Normalisierung der Daten eine universelle Datenbanksprache entwickeln liesse. Die Anwendung konnte so eine maximale Unabhängigkeit von den Daten erreichen. Ferner wurde die Redundanz weitgehend eliminiert. So konnten Mehrfacheinträge, die wiederum komplizierte Verwaltungsprogramme nach sich ziehen würden, vermieden werden.

In der Praxis wird die maximale Eliminierung von Redundanz allerdings nicht konsequent umgesetzt. Ein wichtiger Grund ist der Zeitfaktor. Bei einer Faktur zum Beispiel ist es wichtig, die in der Rechnung verwendet Anschrift des Kunden vollumfänglich dokumentiert zu haben. Es wäre datentechnisch nicht richtig, wenn sich eine Adressänderung noch auf bereits verschickte Rechnungen auswirken würde.

Ein weiterer einschränkender Faktor ist der Applikationsaufwand. Konsequent normalisierte Daten führen zu sehr vielen kleinen Tabellen, die für die Anwendungen über sog. „Views“ (Sichten) zusammengefasst werden. Der Einsatz von Views verlangt aber wiederum eine entsprechende technische Grundlage bei der eingesetzten Datenbank und ist relativ kompliziert in der Realisierung.

Als drittes Element ist ferner festzuhalten, dass Codd’s Überlegungen sich vor allem auf die Auslagerung der Stammdaten beziehen, die optimalerweise aus einem Index und beschreibenden Daten bestehen (zum Beispiel Adress-Nr. und Adressdaten). Die im Kontext der doppelseitigen Buchung wichtige Frage nach der Handhabung mehrfacher Indexe in derselben Transaktionsdatei bleibt hier offen.

Folgt man der Argumentation von Codd, bietet sich eine weitere Normalisierung der doppelseitigen Buchungen in einseitige Buchungen an. Bereits Codd’s erste Normalisierungsstufe verlangt, dass Wiederholungen gleichartiger Daten in der Datenstruktur zu vermeiden sind:

Statt einer Liste mit der Struktur A:

- Beleg, Konto1, Konto2, Betrag


Erstellt man besser eine Liste mit Struktur B:

- Beleg, Konto, Betrag


Bei der Buchhaltung ist dies besonders nahe liegend, da die Buchungen einem Beleg zugeordnet sind. Folgt man der Liste mit Struktur A, ergeben sich sofort Probleme beim Aufruf von Druckprogrammen. Wie soll man mit einer solchen Datenstruktur einen Bericht mit Bilanz oder Erfolgsrechnung, oder auch nur einen einfachen Kontoauszug erstellen? Bei jeder Abfrage muss überprüft werden, ob Konto1 oder Konto2 dem Ablagekonto entsprechen, und zudem im ersten Fall der positive Betrag und im zweiten der negative Betrag für die Berechnung des Totals eingesetzt werden.

 

Dieser Aspekt der Datenmodellierung ist aus der Programmierung von Stücklisten, sog. „Bills of Material“ gut bekannt. Der Datensatz einer Stückliste enthält typischerweise zwei Produkte-Nummern, eine für das übergeordnete Produkt und eine für das untergeordnete. Dies ist nötig, da jedes Produkt mehrfach einem anderen Produkt untergeordnet werden kann (vgl. zu diesem Thema auch: Carl August Zehnder,  Informationssysteme und Datenbanken, B.G.Teubner, Stuttgart 1989, insb. Seiten 60 f.

Wird diese sogenannte „Many-to-Many“-Verbindung vollständig normalisiert, muss in Ergänzung zu den Verbindungselementen ein übergeordnetes Sammelgefäss für die Verbindungseinheit in der Datenbank erfasst werden. Dies ermöglicht dann die Erfassung einseitiger Verbindungen zu den Produkten. Erst durch diese vollständige Normalisierung kann auch die Produktion von verschiedenen Varianten korrekt dargestellt werden. Für die Verbindung zwischen Master und Detail stehen dann verschiedene Verbindungseinheiten beziehungsweise –möglichkeiten zur Verfügung. In der Praxis wird vielfach versucht, diesen etwas aufwändigen Stil zu umgehen, da er nicht geeignet ist für Anwendungen mit der Computermaus, bei der zum Beispiel Detailprodukte einfach über ein Masterprodukt „gezogen“ werden können. Man kann also die Anwendung vereinfachen, erhält dann aber einen Mehraufwand bei den Auswertungen (hier zum Beispiel der Berechnung der Lagerbewegungen).

In Anbetracht der heutigen technischen Möglichkeiten hat man in der Buchhaltung aber wenig Interesse, den „Beleg“ wegzulassen. Im Gegenteil, für die Revision und das Verständnis des Verbuchens ist es äusserst wertvoll, eine Anzahl Buchungen einem Buchungsbeleg zuzuordnen. Dies entspricht auch der Darstellungspraxis auf Papier. Dabei ist nicht wesentlich, ob dem Beleg einseitige oder zweiseitige Buchungszeilen zugeordnet werden. Es gilt lediglich sicherzustellen, dass die Summe der übergebenen Buchungen ein Total von null ergibt. Bei zweiseitigen Buchungen ist diese Anforderung prinzipiell immer erfüllt, bei einseitigen Buchungen kann man den Beleg erst abschicken, wenn dieses Kriterium erfüllt ist.

Besonders interessant ist auch die Analyse der Kontierung unter dem Gesichtspunkt der Normalisierung. Tatsächlich beinhalten fast allen Kontenpläne mehrere Dimensionen, die zu einem schwierig zu handhabenden Register zusammengefasst werden. Ein Kontenplan enthält vielfach verschiedene Elemente der internen Organisation, der Geschäftstätigkeit und der Vertragspartner. Dadurch wird die Buchführung jedoch schnell unübersichtlich und es muss viel Aufwand betrieben werden, um die Kontenvielfalt in der Erstellung der Berichte wieder geeignet zusammenfassen zu können.

Die Komplexität der Kontenpläne ist schon in den Ausführungen Paciolis ersichtlich. War die ursprüngliche Idee des Kontos die einer Kundenabrechnung (also der vertraglichen Beziehung zum Schuldner oder Gläubiger), so werden alsbald virtuelle Schuldner/Gläubiger für Warenbeschaffungen, Warenlager, bald aber auch allgemeiner Betriebsaufwand und Gewinne/Verluste eingeführt.

Es ist deshalb wesentlich effizienter, auch in der Finanzbuchhaltung ein kohärentes Datenmodell einzusetzen. Damit kann der Kontenplan schlank gehalten und auf das finanzielle Berichtwesen ausgerichtet werden. Details zu Vertragspartnern, Geschäftsfeldern oder Organisationseinheiten können dann je nach Bedarf ergänzend abgefragt werden.