Stellen Sie sich vor, Sie möchten Ihren Familienstammbaum auf einem einzigen DIN-A4-Blatt darstellen. Großeltern oben, darunter die Eltern, dann die Kinder, vielleicht schon die Enkelkinder. Einfach, solange Ihre Familie überschaubar ist. Aber was, wenn eine Großmutter vier Kinder hat, von denen drei wiederum je drei Kinder haben? Was, wenn ein Onkel adoptiert wurde und offiziell zu zwei Familienzweigen gehört? Irgendwann reicht ein einzelnes Blatt Papier nicht mehr aus — und vor allem: Wenn ein Familienmitglied heiratet oder umzieht, müssen Sie das gesamte Blatt neu zeichnen.

Genau vor diesem Problem stehen viele Unternehmen, wenn sie ihren Katalog produzieren. Nicht mit Menschen, sondern mit Produkten.

Ein Stuhl gibt es in sechs Farben. Jede Farbe ist in drei Größen verfügbar. Manche Größen gibt es nur in bestimmten Farben. Dazu gibt es passendes Zubehör: Kissenbezüge, Gleitschoner, ein separates Fußteil. Und das Ganze existiert sowohl als Einzelprodukt als auch als Teil eines Sets.

Wer das in einem Katalog ohne klare Hierarchie abbilden will, kämpft gegen ein grundlegendes strukturelles Problem — nicht gegen ein Layout-Problem.

Was eine Produkthierarchie ist — und warum sie im Katalog sichtbar wird

Im ERP-System Ihres Unternehmens sind diese Beziehungen längst abgebildet. Es gibt ein Elternprodukt — den Stuhl — und darunter hängen Varianten nach Farbe und Größe. Jede Variante hat eine eigene Artikelnummer, einen eigenen Bestand, vielleicht einen eigenen Preis.

Im Katalog soll das elegant aussehen: Das Elternprodukt wird einmal vorgestellt, die Varianten als Tabelle oder kompakte Liste darunter. Kein Leser soll sechs nahezu identische Produktseiten blättern müssen.

Das Problem ohne strukturierte Lösung: Wenn Sie das manuell aufbauen, müssen Sie bei jeder Katalogaktualisierung prüfen, welche Varianten neu dazugekommen sind, welche weggefallen sind, und ob sich Preise geändert haben. Bei sechs Varianten ist das lästig. Bei sechzig ist es fehleranfällig. Bei sechshundert ist es nicht mehr manuell beherrschbar.

Das Relational-Modul von EasyCatalog löst nicht ein Layout-Problem. Es löst ein Datenstruktur-Problem, das sich im Layout zeigt.

Wie das Relational-Modul funktioniert

Das Relational-Modul erweitert EasyCatalog um die Fähigkeit, nicht nur einzelne Datensätze darzustellen, sondern Beziehungen zwischen Datensätzen zu verstehen und abzubilden.

Konkret: Sie definieren in Ihrer Datenquelle, welches Feld die Eltern-Kind-Beziehung herstellt. Typischerweise ist das ein gemeinsames Attribut — zum Beispiel eine übergeordnete Produktgruppen-ID oder ein Familiencode. EasyCatalog erkennt dann: Diese acht Datensätze gehören zusammen, weil sie alle denselben Familiencode tragen.

Im Template bauen Sie zwei Ebenen: Ein Eltern-Template, das die gemeinsamen Informationen zeigt — Produktname, Beschreibung, Hauptbild — und ein Kind-Template, das für jede Variante einmal wiederholt wird. Die Varianten-Tabelle mit Farbe, Größe und Preis entsteht automatisch, weil EasyCatalog weiß, welche Datensätze zu diesem Elternprodukt gehören.

Wenn im nächsten Katalogzyklus zwei neue Farbvarianten hinzukommen, erscheinen sie beim nächsten Pagination-Lauf automatisch in der Tabelle. Kein manuelles Einfügen, kein Nacharbeiten.

Welche Hierarchien das Modul abbilden kann

Die häufigste Anwendung ist die einstufige Eltern-Kind-Beziehung: Ein Hauptprodukt mit Varianten. Aber das Relational-Modul kann mehr.

• Mehrstufige Hierarchien sind möglich, wenn Ihre Datenstruktur es hergibt. Ein Produktkatalog einer Maschinenbaufirma könnte eine Hauptmaschine zeigen, darunter Baugruppen, und unter jeder Baugruppe die entsprechenden Ersatzteile. Drei Ebenen, vollständig automatisiert.
• Querverlinkungen lassen sich ebenfalls abbilden: „Passend dazu“-Abschnitte, in denen EasyCatalog automatisch Zubehör ausgibt, das in der Datenquelle als zugehörig zu diesem Produkt markiert ist. Kein Redakteur muss mehr entscheiden, was zu welchem Produkt passt — das steht in den Daten, und EasyCatalog bringt es an die richtige Stelle.
• Bundles und Sets funktionieren nach demselben Prinzip: Das Bundle-Produkt ist das Elternelement, die enthaltenen Einzelprodukte sind die Kinder. Änderungen an der Bundle-Zusammensetzung werden automatisch im nächsten Katalogdurchlauf übernommen.

Erfordert das eine aufwendige Datenvorbereitung? Ja — aber es ist eine Investition, die sich bereits beim zweiten Katalog auszahlt.

Was in der Datenquelle stimmen muss

Hier zeigt sich wieder das Grundprinzip aus unserem Posting über Datenqualität: EasyCatalog kann nur abbilden, was in den Daten sauber modelliert ist.

Das bedeutet in der Praxis: Die Beziehungen zwischen Produkten müssen explizit in der Datenquelle vorhanden sein. Ein Feld, das sagt: „Dieses Produkt gehört zur Familie XY.“ Wenn das fehlt, kann kein Modul der Welt die Zusammenhänge automatisch erkennen.

In vielen Projekten ist genau das die Herausforderung. Das ERP weiß natürlich, welche Varianten zusammengehören — aber diese Information ist im Export nicht sauber mitgegeben. Sie steckt implizit in ähnlichen Artikelnummern oder wird nur im System selbst angezeigt, nicht aber als auswertbares Feld exportiert.

Wer das Relational-Modul einsetzen will, sollte deshalb frühzeitig prüfen: Können wir aus unserem ERP oder PIM einen Export erzeugen, der Eltern-Kind-Beziehungen als auswertbares Feld enthält? Falls nicht — kann das ergänzt werden, oder müssen wir eine Zwischentabelle pflegen?

Diese Klärung kostet Zeit. Aber sie ist die einmalige Investition, die alle zukünftigen Katalogzyklen beschleunigt.

Häufige Missverständnisse aus der Projektpraxis

„Wir brauchen das nicht, unsere Produkte sind einfach.“ Das hören wir häufig am Anfang eines Projekts. Dann stellt sich heraus, dass es 40 Farbvarianten gibt, drei Länderversionen und saisonale Sondermodelle. Was im ERP einfach aussieht, hat im Katalog plötzlich eine komplexe Struktur.

„Das können wir auch manuell nachpflegen.“ Das stimmt — einmal. Beim zweiten Mal auch noch. Beim fünften Katalogzyklus mit 20 neuen Produktfamilien und 15 weggefallenen Varianten wird aus der manuellen Nachpflege eine Fehlerquelle.

„Das Relational-Modul ist nur für große Sortimente.“ Falsch. Bereits bei 50 Elternprodukten mit je 5 Varianten sind das 250 Datensätze, die in ihrer Beziehung zueinander korrekt dargestellt werden müssen. Wer das automatisiert, gewinnt Sicherheit und Geschwindigkeit — unabhängig von der Sortimentsgröße.

Fazit

Das Relational-Modul ist kein Nice-to-Have für komplexe Sortimente. Es ist das Werkzeug, das verhindert, dass Produkthierarchien in der Katalogproduktion zur Handarbeit werden — und damit zur Fehlerquelle.

Wer heute in die Frage investiert, wie seine Produkt-Beziehungen in der Datenquelle modelliert sind, schafft die Grundlage für einen Katalogprozess, der mit dem Sortiment mitwächst — statt bei jeder Änderung von vorne anzufangen.

Prüfen Sie Ihren nächsten Datenexport: Enthält er explizit, welche Varianten zusammengehören? Wenn nicht, ist genau das der erste Schritt.