Zum Hauptinhalt springen

Smart Data Models

Diese Seite beschreibt nicht noch einmal die Grundlagen von Smart Data Models, sondern den praktischen Umgang damit im Projektalltag.

Für die inhaltliche Einführung, Beispiele, Begriffserklärung und die Rolle von @context siehe:

Was ist hier die wichtigste Regel?​

Für die Praxis reicht meist diese einfache Reihenfolge:

  1. Zuerst prüfen, ob es bereits ein passendes Smart Data Model gibt.
  2. Wenn es fast passt, das bestehende Modell als Grundlage nehmen und nur gezielt erweitern.
  3. Nur wenn es wirklich kein sinnvolles passendes Modell gibt, über ein neues Modell nachdenken.

Wichtig ist dabei: Erst übernehmen, dann erweitern, und nur im Ausnahmefall neu bauen.

Was ist dabei Best Practice?​

  • vorhandene Modelle möglichst konsequent nutzen
  • ähnliche Objekte im Projekt immer gleich modellieren
  • Erweiterungen nur bewusst und dokumentiert ergänzen
  • Mapping-Logik klar und wiederverwendbar aufbauen
  • neue Typen und Attribute nicht zufällig in einzelnen Flows entstehen lassen

Ein bestehendes Modell spart nicht nur Zeit, sondern sorgt auch dafür, dass ähnliche Daten nicht in jedem Projekt wieder anders beschrieben werden.

Was in der Praxis oft schiefläuft​

Typische Probleme sind:

  • ähnliche Objekte werden in jedem Projekt anders benannt
  • Attribute werden einmal deutsch, einmal englisch geführt
  • Quellen schreiben fachlich ähnliche Inhalte in unterschiedliche Strukturen
  • lokale Sonderfelder verdrängen die eigentliche Standardstruktur
  • bestehende Modelle werden nur teilweise übernommen und dann stark verbogen

Das Ergebnis ist dann oft: formal gibt es ein Modell, praktisch aber trotzdem keine einheitliche Datengrundlage.

Wie dokumentiert man Abweichungen sinnvoll?​

Abweichungen sollten nicht stillschweigend in Flows oder Mapping-Logik verschwinden. Sinnvoll ist eine kurze, nachvollziehbare Dokumentation:

  • welches Modell als Basis genutzt wird
  • welche Felder direkt übernommen wurden
  • welche Felder ergänzt wurden
  • warum die Ergänzung nötig war
  • wie Quellen auf dieses Modell gemappt werden

Das muss keine große Spezifikation sein. Schon eine verständliche Projektnotiz oder eine kleine Doku-Seite hilft oft deutlich weiter.

Rolle von Node-RED beim Mapping​

In vielen Projekten entstehen Smart Data Models nicht direkt in der Quelle, sondern erst im Mapping. Genau dort spielt Node-RED häufig eine zentrale Rolle.

Für die Praxis ist wichtig:

  • Das Modell sollte nicht erst ganz am Ende mit Einzel-Fixes zusammengesetzt werden.
  • Besser ist ein klarer, nachvollziehbarer Mapping-Schritt.
  • Wenn mehrere Quellen dasselbe Modell bedienen, sollte die Mapping-Logik möglichst gleichartig aufgebaut sein.
  • Wiederkehrende Mapping-Muster sollten nicht in jedem Flow neu erfunden werden.

Umgang mit eigenen Erweiterungen​

Eigene Erweiterungen sind nicht grundsätzlich falsch. Sie sollten aber bewusst und kontrolliert erfolgen.

Best Practice ist:

  • bestehende Attribute und Typen bevorzugen
  • neue Begriffe nur ergänzen, wenn sie fachlich wirklich nötig sind
  • Erweiterungen zentral dokumentieren
  • zentrale Kontextdefinitionen nachziehen, wenn die Erweiterung dauerhaft relevant bleibt

Wenn ein zentraler Kontext nicht direkt mitgepflegt werden kann, ist das kein Blocker. Wichtig ist dann vor allem, dass die Erweiterung wenigstens an einer verlässlichen Stelle im Projekt festgehalten wird.

Hilfreiche Einstiege​