Zum Hauptinhalt springen

Namenskonventionen

Einheitliche Namen sind keine Nebensache. Sie entscheiden mit darüber, ob Flows, Datensätze, Layer und Konfigurationen später wiedergefunden, verstanden und sauber weiterentwickelt werden können. Gerade in der Plattform arbeiten häufig mehrere Personen, Fachbereiche und Komponenten zusammen. Wenn jede Quelle, jeder Flow oder jedes Dashboard anders benannt ist, entstehen schnell Suchaufwand, Missverständnisse und unnötige Doppelstrukturen.

Für die Praxis heißt das: Namen sollten nicht nur technisch eindeutig sein, sondern auch fachlich verständlich. Ein guter Name hilft sofort dabei zu erkennen, was gemeint ist, woher etwas kommt und wofür es genutzt wird.

Grundregeln​

  • Namen sollten fachlich verständlich sein und nicht nur aus internen Abkürzungen bestehen.
  • Ein Name sollte möglichst nur eine Sache ausdrücken und nicht mehrere Themen vermischen.
  • Die gleiche Logik sollte in allen Bereichen wiederkehren, also zum Beispiel bei Flows, Tabellen, Layern und Datensätzen.
  • Umlaute, Leerzeichen und Sonderzeichen sollten in technischen Bezeichnern möglichst vermieden werden.
  • Für Anzeigenamen darf es verständlicher und lesbarer sein als für technische IDs.
  • Wenn mit Präfixen gearbeitet wird, sollten diese im ganzen Projekt gleich verwendet werden.

Was sich in Namen idealerweise wiederfindet​

Je nach Objekt ist es hilfreich, wenn ein Name mehrere dieser Aspekte erkennbar macht:

  • Fachthema
  • Datenquelle oder zuständiger Bereich
  • Inhalt oder Objekttyp
  • Ort oder Geltungsbereich
  • Zweck der Nutzung
  • Version oder Status, falls wirklich nötig

Nicht jeder Name muss alles enthalten. Wichtig ist vor allem, dass die gewählte Logik im Projekt konsistent bleibt.

Empfohlene Schreibweise​

Für technische Namen ist eine einfache, robuste Schreibweise sinnvoll:

  • Kleinbuchstaben
  • Wörter mit - oder _ trennen
  • keine Umlaute
  • keine wechselnden Kurzformen für denselben Begriff

Beispiele:

  • gut: verkehr-parkplaetze-belegung
  • gut: umwelt-luftqualitaet-messstationen
  • gut: geo-gruenflaechen
  • ungünstig: ParkplätzeNeuFinal
  • ungünstig: daten_fuer_dashboard_neu2
  • ungünstig: testflow_michael

Node-RED-Flows​

Bei Flows sollte direkt erkennbar sein, welche Quelle angebunden wird und welches Zielsystem gemeint ist.

Sinnvoll ist oft ein Aufbau wie:

[quelle]-[inhalt]-[ziel]

Beispiele:

  • mqtt-pegel-kontextbroker
  • api-wetter-datenbank
  • datei-poi-datenbank
  • wfs-gruenflaechen-geoserver

Hilfreich ist zusätzlich:

  • Test- oder Entwurfsflows klar als solche kennzeichnen
  • keine Personennamen im regulären Flownamen
  • produktive und experimentelle Flows nicht gleich benennen

Datenquellen und Schnittstellen​

Bei Datenquellen sollte sichtbar werden, aus welchem fachlichen Kontext sie kommen.

Beispiele:

  • dwd-wettervorhersage
  • osm-points-of-interest
  • stadtwerke-zaehlerdaten
  • verkehr-detektoren-innenstadt

Wichtig ist hier vor allem:

  • gleiche Quelle immer gleich benennen
  • Fachsystemnamen nicht jedes Mal anders abkürzen
  • interne und öffentliche Bezeichnungen nicht vermischen

Datenbanken, Tabellen und Views​

Bei Tabellen und Views sollte sofort erkennbar sein, ob es sich um Rohdaten, aufbereitete Daten oder anwendungsspezifische Sichten handelt.

Sinnvoll können zum Beispiel solche Muster sein:

  • raw_... für eingehende Rohdaten
  • staging_... für Zwischenschritte
  • app_... für anwendungsnahe Tabellen
  • view_... oder sprechende View-Namen für Abfragesichten

Beispiele:

  • raw_umwelt_messwerte
  • staging_parken_belegung
  • app_standorte_ladesaeulen
  • view_dashboard_verkehr

Kontextbroker, Entitäten und Attribute​

Im Kontextbroker ist Konsistenz besonders wichtig, weil dort mehrere Quellen auf gemeinsame Objektstrukturen treffen können.

Empfehlungen:

  • vorhandene Smart Data Models als Ausgangspunkt nutzen
  • gleiche Objekttypen nicht pro Projekt neu benennen
  • Attribute nicht einmal deutsch und einmal englisch benennen
  • fachliche Kürzel nur verwenden, wenn sie im Projekt wirklich etabliert sind

Ungünstig ist zum Beispiel:

  • ein Projekt nutzt parkingSpot
  • das nächste nutzt parkplatz
  • ein drittes nutzt parking_space_status

Besser ist:

  • ein Modell festlegen
  • dieses im Projekt konsequent durchhalten
  • Abweichungen dokumentieren

GeoServer-Layer und Geodaten​

Bei Layern und Geodiensten hilft eine Benennung, die Fachthema und Darstellungszweck gut voneinander trennt.

Beispiele:

  • verkehr_parkhaeuser
  • umwelt_luftqualitaet_stationen
  • planung_bebauungsplaene

Für die Praxis wichtig:

  • Layernamen sollten fachlich verständlich sein
  • kryptische technische Zwischennamen sollten nicht bis in die Nutzung durchgereicht werden
  • wenn Rohdaten und veröffentlichte Layer unterschiedlich heißen, sollte die Zuordnung dokumentiert sein

Dashboards und Visualisierungen​

Dashboard-Namen sollten eher nutzerorientiert als technisch benannt sein. Fachbereiche suchen meist nach Themen, nicht nach Datenquellen.

Beispiele:

  • gut: Parkraum Innenstadt
  • gut: Luftqualität Stadtgebiet
  • gut: Energieverbrauch Verwaltungsgebäude
  • ungünstig: grafana_board_12
  • ungünstig: postgres_monitoring_v2

Datenkatalog und Open Data​

Bei Datensätzen im Datenkatalog zählen vor allem Verständlichkeit und Wiederauffindbarkeit.

Ein guter Datensatzname sollte:

  • fachlich lesbar sein
  • nicht nur aus internen Kürzeln bestehen
  • möglichst dem Titel entsprechen, unter dem andere ihn später suchen würden

Beispiele:

  • Baumstandorte im Stadtgebiet
  • Parkhäuser und Auslastung
  • Ladesäulenstandorte

Was vermieden werden sollte​

  • neu, final, final2, test, tmp als dauerhafte Namensbestandteile
  • Personennamen in produktiven Strukturen
  • wechselnde Abkürzungen für denselben Begriff
  • technische IDs als sichtbare Anzeigenamen
  • fachlich gleiche Dinge mit unterschiedlichen Begriffen benennen