Documentation
Understand the configuration data model: classes, fields, relation types
What the configuration data model defines, where to view and change it, and how classes, fields, required data and relation types work together.
6 min read · September 2026
Das Datenmodell bestimmt, welche Arten von Technik Sie in der Konfigurationsverwaltung führen, welche Angaben zu jeder Art gehören und wie die Objekte zusammenhängen. Sie ändern es ohne Programmierung, direkt in den Einstellungen. Regeln, die Sie dort festlegen, gelten sofort beim Erfassen.
Rechte
Das Datenmodell sehen alle mit Leserecht für die Konfigurationsverwaltung. Zum Ändern brauchen Sie das Recht CMDB-Administration.
Wo Sie das Datenmodell finden
Öffnen Sie Einstellungen, dann CMDB, dann Modell & Standorte. Die Seite hat vier Reiter:
- Klassen und Felder: die Klassen mit ihren Feldern, Pflichtangaben und Pflichtbeziehungen,
- Beziehungsarten: wie Objekte zusammenhängen können,
- Standorte: der Standortbaum,
- Modelländerungen: der Verlauf aller Änderungen am Modell.
Klassen: die Arten von Technik
Eine Klasse beschreibt eine Art von Technik, zum Beispiel Server, Speichersystem oder Endgerät. Knooing liefert Standardklassen mit. Jede trägt ein Etikett mit ihrer Elementart nach ArchiMate 3.2 (The Open Group, Technologie-Ebene), etwa ArchiMate 3.2: Device / Node bei Server. Eigene Klassen ergänzen Sie selbst: ohne Vorlage oder abgeleitet von einer vorhandenen Klasse.
Anwendungen, Leistungen und Geschäftsprozesse sind keine Klassen des Datenmodells. Sie haben ihre eigene Verwaltung. Das Datenmodell beschreibt nur die Technik darunter.
Was jede Klasse mitbringt: die Stammfelder
Jedes Konfigurationselement hat dieselben Stammfelder, gleich welche Klasse es hat: Name, CI-Kennung, Beschreibung, Lebenszyklus, Umgebung, Standort, Verantwortlich, Organisationseinheit, Hersteller, Kritikalität und Schutzbedarf. Der Name ist immer Pflicht, Lebenszyklus und Umgebung sind immer gesetzt. Verantwortlich und Kritikalität machen Sie je Klasse zur Pflicht, alles andere ist freiwillig.
Felder: was zu einer Klasse zusätzlich gehört
Zusätzlich hat jede Klasse eigene Felder, bei Server zum Beispiel Rechnername (FQDN), Bauart und Seriennummer. Je Feld legen Sie fest:
- den Datentyp: Text, Langtext, Ganzzahl, Dezimalzahl, Datum, Datum und Uhrzeit, Ja/Nein, Auswahl, Mehrfachauswahl, Link (URL), IP-Adresse, Geldbetrag sowie Verweise auf Person, Abteilung, Lieferbeziehung, Standort, CI, Anwendung und Service,
- ob das Feld Pflicht ist, auch nur unter einer Bedingung, etwa „Seriennummer ist Pflicht, wenn Bauart = physisch“,
- das Schreibrecht: von Hand, nur Quellsystem (etwa für Werte, die ein Inventarwerkzeug liefert) oder Quelle, überschreibbar,
- wann das Feld sichtbar ist.
Warum so genau? Was ein Objekt verbindlich tragen muss, entscheidet sich am Anfang, beim Erfassen. Was dort fehlt, fehlt später in jeder Auswertung, in der Ausfallbewertung und bei jeder Prüfung.
Pflichtbeziehungen: was an einem Objekt hängen muss
Eine Pflichtbeziehung legt fest, was an einem Objekt der Klasse hängen muss, damit es eingeordnet ist. Fehlt sie, entsteht ein Klärfall. Speichern lässt sich das Objekt trotzdem, denn ein neu erfasstes Objekt kann noch keine Beziehung haben.
Beziehungsarten: wie Objekte zusammenhängen
Eine Beziehungsart benennt eine Verbindung in beide Leserichtungen, zum Beispiel läuft auf und betreibt. Sie legt fest, welche Klassen am Anfang und am Ziel stehen dürfen und ob ein Ausfall des Ziels den Ausgangspunkt mitbetrifft. Diese Wirkung übernimmt jede Beziehung beim Anlegen von ihrer Art. Sieben Arten sind mitgeliefert, eigene ergänzen Sie selbst.
Änderungen nachvollziehen
Jede Änderung am Modell landet im Reiter Modelländerungen, mit Zeitpunkt, Person und der Zahl der betroffenen Objekte. Der Verlauf lässt sich nicht bearbeiten.