|
|
> itil > cmdb > datenmodell |
Die ITIL CMDB ist eine Datenbank, daher beschreibt ein Datenmodell
die Struktur ihrer Inhalte.
|
Agilität |
Der Inhalt einer CMDB muss immer aktuell sein. Daher müssen neue Technologien (z.B. Blade, Virtualisierung, IP V6) sofort
in der CMDB abgebildet werden, sobald deren Einsatz geplant und entworfen wird.
Eine Änderung am Datenmodell der CMDB kann nicht bis zum nächsten Software-Release warten ohne dass IT-Prozesse oder Projekte in ihrem Ablauf behindert werden. |
||
Komplexität |
Eine wirklich nützliche CMDB deckt einen großen Umfang von Entitäts-Typen ab —
von Komponenten der technischen Infrastruktur über IT-Services bis hin zu Geschäftsprozessen und Organisationseinheiten.
Die Komplexität des CMDB Modells entspricht in etwa der Summe von IT Komplexität + Business Komplexität. Das CMDB Datenmodell ist auch verwandt mit dem Enterprise Information Model und dem Enterprise Data Dictionary. |
||
Individualität |
Aufgrund der Agilität und der Komplexität jeder nennenswerten CMDB sind auch die Verwaltungskosten für die Dateninhalte deutlich
spürbar.
Jede IT-Organisation wird aus ökonomischen Gründen nur solche Daten in der CMDB pflegen, für die es konkreten (massiven) Informationsbedarf —und somit einen ROI— gibt. Weil der Informationsbedarf in jeder Organisation im Detail anders bewertet wird, entsteht zu Recht in jeder Organisation ein individuelles CMDB Datenmodell. Ansätze zur Standardisierung des gesamten CMDB Modells konnten sich bisher nicht durchsetzen. Allerdings finden sich in jedem CMDB Modell wiederkehrende Muster, die in kleinen Einheiten durchaus wiederverwendet werden können. |
||
Verteilung |
Eine nützliche CMDB muss inhaltlich einen weiten Umfang bieten. Meist stößt man bei der Analyse von benötigter Information
auf andere führende Systeme, deren Daten in die CMDB integriert werden sollen.
Daher ist beim Aufbau einer CMDB meist eine Art von Verteilung, loser Kopplung oder Föderation notwendig. |
||
Normalisierung |
Aufgrund der großen Typenvielfalt in einer CMDB soll das Datenmodell so stark wie möglich normalisiert sein. Im logischen Datenmodell soll jeder CI-Typ (z.B. Server-Hardware, Ethernet-Interface) durch einen entsprechenden Entitätstypen vertreten sein. Relationstypen beschreiben, welche Entitätstypen in welchem Zusammenhang stehen können. | ||
|
|
Im physischen Datenmodell können die logischen Typen aber nicht 1:1 in Tabellen und Schlüssel umgesetzt werden, weil auf diese Weise der Anspruch der Agilität nicht befriedigend erfüllt werden kann. Stattdessen muss das physische Datenmodell im Wesentlichen mit den noch stärker normalisierten Tabellen CI, Relation, CI-Typ und Relations-Typ operieren. | ||
Fazit |
Die CMDB ist "auch nur eine Datenbank".
Involvieren Sie bei einem CMDB Projekt zunächst Ihre internen Spezialisten:
IT Architekt, Software-Designer und Datenbankexperten.
Für die Besonderheiten des CMDB Datenmodells bieten wir unsere Beratung sowie Spezialschulungen an:
|
||
Kleingedrucktes |
(1) Preis pro Teilnehmer zuzüglich MwSt; inklusive Schulungsunterlagen, Mittagessen und Pausenverpflegung; Irrtum vorbehalten |
ITIL CMDB Modellierung