Ein flexibles Datenmodell als Basis für das PIM-System ist Gold wert

Ein Blick unter die Oberfläche lohnt sich

Informationssysteme setzen eine Datenbank als Basis voraus. So natürlich auch beim Product Information Management (PIM). Man sagt allgemein, dass Datenbanken mindestens ein drei Mal so langes „Leben“ haben als die Software selbst, also Oberfläche und Programme. Die Datenbank ist das Fundament, der Motor, größere Veränderungen sind – wenn sie überhaupt technisch möglich sind – sehr aufwändig. Daraus ergibt sich für den Softwarehersteller, dass man die Datenbank mit sehr viel Sorgfalt entwickeln sollte und für den Anwender, dass sich ein Blick unter die Oberfläche lohnt. In meinen Berufsjahren habe ich mehrfach erlebt, dass Softwareunternehmen aufgegeben haben, u. a. weil sie die Datenbank nicht optimal aufgebaut haben und die Umstellung immense Aufwände nach sich zog.

Der „Datenbankchef“

Als ich das erste Mal in der Praxis mit Datenmodellen konfrontiert wurde, war es mir zugegebenermaßen lästig. Als junger Softwareentwickler wollte ich zügig eine tolle Oberfläche entwickeln, mit reichlich Funktionalität – wurde allerdings zuerst mal von dem Datenbankadmin gebremst. Ich „musste“ alle Datenstrukturen mit ihm durchgehen, Feld für Feld, und natürlich gab es reichlich Rückfragen wieso und warum. Das Ergebnis wurde grafisch aufbereitet („Entity Relationship Diagramm“) und dann musste ich darauf warten bis das Datenmodell in der Datenbank umgesetzt und ausgerollt wurde.

Im Laufe des Projekts habe ich dann verstanden, wie sinnvoll dieses Vorgehen war: Alle anderen Entwickler hatten somit ein vorgegebenes, robustes Modell und konnten einheitlich Daten verwenden, ohne dass es weitere Schleifen benötigte.

Ich habe zwei Erkenntnisse mitgenommen:

1.) Ein zentral verantwortlicher „Chef“ für die Datenbank ist Pflicht, da ging ich schlussendlich mit.

2.) Das langwierige Anlegen der Felder selbst sollte vermieden werden, das wollte ich verbessern und flexibler gestalten.

Das flexible Datenmodell

Was heißt „flexibles Datenmodell“?

Flexibel heißt zuallererst, dass der Anwender Erweiterungen autark durchführen kann. Bildlich gesprochen ohne den „Datenbankchef“. Es ist also eine Art „Metadatenmodell“ zur Erweiterung von Feldern („Attribute“), Strukturen („Tabellen“) und Zusammenhängen („Relationen“) notwendig:

• Felder speichern Inhalte.
  Im Kontext von PIM bspw. Texte und Übersetzungen, Merkmale (bspw. Zahlen), Bilder, Dokumente und Videos. Typische Erweiterungen sind, dass man ein neues Attribut braucht, einen neuen Texttyp oder eine neue Bildkategorie. Das sollte der Anwender in Eigenregie unkompliziert machen können. Und zwar unbeschränkt in Bezug auf die Anzahl neuer Felder. Sobald man ein neues Feld anlegt, soll es überall sofort sichtbar sein: in der Datenpflege, in Schnittstellen, der Printproduktion und Datenbereitstellungen aller Art. Die Grundidee für das flexible Attributmodell hatte ich übrigens mit einem Freund in der Kneipe skizziert und dann in Access getestet (hat flüssig geklappt :-).
• Strukturen werden typischerweise als Baumstruktur dargestellt. Selbstredend müssen diese bezogen auf die Inhalte einfach erweiterbar und (unbeschränkt) anpassbar sein. Im Kontext von PIM sind das zwingend die Pflegestruktur für die Produkte sowie die Ausgabestrukturen für Website, Shop, Portale und Printmedien. Jedoch können auch weitere komplexere Strukturen das PIM sinnvoll ergänzen, bspw. eine Konfigurationsstruktur als Basis für Konfiguratoren. Strukturen für Standardklassifikationen wie ECLASS und ETIM. Strukturen zur Abbildung von XML-Formaten wie BMEcat. Strukturen für die Verwaltung von Schnittdaten für Werkzeuge. Und, und, und. Die Grundidee für unser flexibles Strukturenmodell hatte unser erster Datenbankchef, das von ihm geprägte sogenannte „Strukturobjekt“ ist Dreh- und Angelpunkt. Auf diese Weise können auch kundenspezifische, individuelle Sachverhalte (releasefähig!) abgebildet werden, was unsere Kunden sehr schätzen. Es gilt natürlich das Gleiche wie bereits für Felder oben beschrieben: Neue Strukturen sollen sofort überall sichtbar werden.
• Zusammenhänge werden als Referenzen dargestellt. Das ist eigentlich der Hauptzweck der Datenbank. Dass man Inhalte einmal anlegt und sie häufig wiederverwendet. Das ist ohne Datenbank natürlich auch möglich – aber nur als Kopie, d. h. ohne Bezug zu dem originären Inhalt. Und Kopien entwickeln ihr eigenes Leben, wie wir alle wissen. Zusammenhänge können im einfachsten Fall die Verknüpfung von Bildern, Dokumenten und Texten zu Artikeln, Produktgruppen usw. sein. Oder Verknüpfungen von Zubehör, Ersatzteilen, Stücklisten. Im Falle von Stücklisten spielen auch sog. Referenzattribute eine Rolle, wie Positionsnummer und Menge eine Rolle; und Im Falle von Verpackungen Abmessungen, Gewicht, EAN usw. Ein flexibles Datenmodell sollte in Bezug auf derartige Zusammenhänge frei konfigurierbar sein.

Flexibilität zeigt sich in allen Belangen

Neben den beschriebenen Sachverhalten sollten Sie insgesamt auf ein flexibles PIM-System achten. Ganz besonders auf die Erweiterbarkeit dieser Punkte: Sprachen und Länder, Zahlenformate und Einheiten, Kataloge und Sortimente, Preislisten und Preisattribute, Textformate und Sonderzeichen.
Flexibilität zeigt sich im Übrigen auch in nachgelagerten Programmen: Wie flexibel ist die Datenbereitstellung: Können API-Services und Datenexporte für Shops, Website und anderen Systemen einfach angepasst werden? Wie flexibel ist die Printengine, sprich können Layoutvorlagen für die Verwendung in InDesign einfach angepasst und erweitert werden oder müssen Programmierkenntnisse („Skipting“) notwendig sein?

Die Herausforderung

Ich möchte nicht verschweigen, dass ein derartiges „Metadatenmodell“ sehr anspruchsvoll ist. Denn die Auswertung ist komplexer, da ja zuerst die Metadaten durchlaufen werden müssen. Dieses Dilemma muss natürlich aufgelöst werden, denn ohne Performance ist auch Flexibilität bedeutungslos. Die gute Nachricht: Es ist machbar!

Die Konfiguration des Datenmodells verlangt außerdem eine Oberfläche, die den PIM-Admin führt; durchgeführte Änderungen müssen sofort in allen Programmen sichtbar sein.

Fazit

Prüfen Sie die (unbeschränkte) Erweiterbarkeit des Datenmodells, inhaltlich aber auch strukturell. Es ist ein bisschen wie bei einem Auto der Motor. Schauen Sie ruhig unter die Motorhaube! Sprich unter die Benutzeroberfläche. Denn die Benutzeroberfläche ändert sich laufend, das Datenmodell selbst ist jedoch sehr langlebig. Und nur mit einem flexiblen Datenmodell sind Sie für die Zukunft gut gewappnet. Und abschließend noch eine Empfehlung: Fragen Sie nach wie viele Datenbanken für die gesamte Systemlösung zum Einsatz kommen. Die Antwort sollte sein: Eine einzige Datenbank. Mehr als eine Datenbank schafft nämlich sonst wieder Kopien, Redundanzen, Inkonsistenzen und vor allem unnötige Arbeit.