Übersicht über die Anpassung des Service Manager Data Warehouse
Wichtig
Diese Version von Service Manager das Ende des Supports erreicht hat, wird empfohlen, ein Upgrade auf Service Manager 2019 durchzuführen.
Nachdem die Service Manager Data Warehouse bereitgestellt wurde und Sie die zugehörigen Berichte angezeigt haben, können Sie die Informationen in den Berichten an Ihre Organisation anpassen. Sie können beispielsweise mithilfe von Service Manager Berichte erneut erstellen, die Sie in der Vergangenheit mit anderen Informationssystemen verwendet haben. Oder Sie können die Berichte für Ihre internen Geschäftsprozesse für Incidents oder für das Change-Management anpassen.
Mithilfe der Informationen in diesem Abschnitt können Sie das Data Warehouse zum Ausführen von gründlichen Analysen erweitern und anpassen.
Dimensionale Data Warehouse-Modellierung mithilfe eines Sternschemas
Das Data Warehouse in Service Manager besteht aus einer Reihe von Datenbanken und Prozessen. Durch die Prozesse werden den Datenbanken automatisch Informationen hinzugefügt. Zweck des Data Warehouse ist das Hinzufügen von Informationen zum Data Mart, wo Sie und andere Benutzer im Rahmen der Führung Ihres Geschäfts Berichte generieren und Analysen durchführen. Service Manager speichert Data Warehouse-Daten aufgrund der Nützlichkeit der Daten für Trend- und Analysedaten länger im Warehouse als in der Service Manager-Datenbank. Data Warehouse-Daten werden zudem oft länger gespeichert als sie für die normale Transaktionsverarbeitung benötigt werden.
Das Data Warehouse ist für die Aggregierung und Analyse großer Datenmengen auf einmal optimiert. Aggregierung und Analyse können auf zahlreiche unterschiedliche, scheinbar unvorhersehbare Art und Weisen ablaufen. Im Unterschied dazu sind Systeme zur Transaktionsverarbeitung für Schreibzugriff auf wenige Datensätze in jeder einzelnen Transaktion optimiert, wodurch das Verhalten der Transaktionen vorhersehbarer werden.
Um das Data Warehouse für Leistung und Benutzerfreundlichkeit zu optimieren, verwendet Service Manager den Ansatz der Dimensionalitätsmodellierung mithilfe des -Konzepts Für die Dimensionsmodellierung. (Weitere Informationen über den Ansatz des PlastischenBalls finden Sie unter Dimensionale Modellierung.) Dies bedeutet, dass die Tabellen in der DWDataMart-Datenbank logisch zu Themenbereichen zusammengefasst sind, die in der Darstellung eines Diagramms einem Stern ähneln. Aus diesem Grund werden diese Gruppierungen häufig „Sternschemas“ genannt. Sie enthalten folgende Elemente:
- Die Mitte des Sterns bildet eine Faktentabelle. Faktentabellen repräsentieren Beziehungen, Maße und Key Performance Indicators (KPIs). Sie sind in der Regel lang und umfassen relativ wenige Spalten, enthalten jedoch eine große Menge Transaktionen.
- Die Faktentabelle ist mit Dimensionstabellen verknüpft, die Klassen, Eigenschaften und Aufzählungen repräsentieren. Dimensionstabellen enthalten wesentlich weniger Zeilen als Faktentabellen. Sie sind jedoch breiter, da sie Attribute enthalten, anhand derer Benutzer die Form von Berichten steuern können. Solche Attribute können Status, Klassifizierungen und Datumsangaben (Erstellungsdatum, Auflösungsdatum etc.) einer Klasse sein.
- Unter einem Outrigger versteht man eine bestimmte Art der Dimensionstabelle, die in puncto Leistung und Nutzbarkeit von einer anderen Dimensionstabelle abhängt.
Das Sternschema kann man gut am Beispiel eines Cafés erklären: Wenn die Transaktionen Kaffeebestellungen darstellen, sind folgende Dimensionen vorstellbar:
- eine Datums-Dimension zur Konsolidierung der Transaktion mit dem gregorianischen und Steuerkalendern
- eine Kunden-Dimension, die angibt, wer den Kaffee bestellt hat
- eine Mitarbeiter-Dimension, die angibt, wer den Kaffee zubereitet hat
- Eine Produkt-Dimension, die den Kaffeetyp (Espresso, Milchkaffe etc.) angibt
- Eine Standort-Dimension
Als Maßangaben in der Faktentabelle sind folgende Elemente vorstellbar:
- Verkaufte Menge
- Preis pro Einheit
- Gesamtumsatz
- Gesamtrabatte
Wenn Sie ein Dimensionsmodell konzipieren, unterscheiden sich die IT-Prozesse nicht grundlegend von dem o. a. Beispiel des Cafés. Es gibt Transaktionen wie etwa die Erstellung, Auflösung und Schließung von Vorfällen, die interessante und nützliche Metriken bieten können, wie zum Beispiel die für die Auflösung gebrauchte Zeit, die Einhaltung von Auflösungszielen, die von Analytikern aufgewendete abrechnungspflichtige Zeit und die Dauer der einzelnen Status.
Überlegen Sie bei der Erweiterung oder Anpassung Ihres Data Warehouse, welche geschäftliche Fragen beantwortet werden sollen, und prüfen Sie, welche nützlichen Informationen und bewährte Praktiken die Dimensionsmodellierung hier bieten kann. Weitere Informationen zur Anpassung des Data Warehouse finden Sie in den anderen Themen dieses Abschnitts.
Faktentabellen im Data Warehouse
In diesem Thema wird beschrieben, wie Beziehungsfakten im Data Warehouse in Service Manager definiert werden. Eine Beziehungsbeziehung im Service Manager Data Warehouse ähnelt einer Beziehung in Service Manager. Mithilfe eines Beziehungsfakts können Abfragen wie folgende beantwortet werden:
- Welche Arbeitselemente sind derzeit dem Benutzer Jens Mander zugewiesen? (Sie möchten den Zustand dieses Arbeitselements ermitteln.)
- Wie lauten alle Computer in der Domäne, auf denen derzeit Windows 10 installiert ist, damit Sie sie auf die neueste Version aktualisieren können?
- Bei welchen Prüfaktivitäten wird Melanie Speckmann als Prüfer aufgelistet? (Sie möchten diese Prüfaktivitäten neu zuweisen, da Frau Speckmann in Urlaub ist.)
In diesen Szenarien gibt es eine Quellinstanz und eine Zielinstanz, die durch eine Beziehung miteinander verbunden sind. Ohne Beziehungsfakt ist es schwierig, die Verknüpfungen zwischen den Instanzen zu ermitteln. Betrachten Sie im folgenden Beispiel die Beziehung „Microsoft.Windows.ComputerHostsOperatingSystem“ im Management Pack „Microsoft.Windows.Library“:
<RelationshipType ID="Microsoft.Windows.ComputerHostsOperatingSystem" Accessibility="Public" Base="System!System.Hosting">
<Source ID="Computer" Type="Microsoft.Windows.Computer" />
<Target ID="OperatingSystem" Type="Microsoft.Windows.OperatingSystem" MaxCardinality="1" />
</RelationshipType>
In einer Service Manager Beziehung werden Quelle und Ziel immer von einer Management Pack-Klasse modelliert. In dieser Beziehung ist die Klasse „Microsoft.Windows.Computer“ die Quelle und die Klasse „Microsoft.Windows.OperatingSystem“ das Ziel. Mit den folgenden Informationen wird der entsprechende Beziehungsfakt (RelationshipFact) basierend auf der Beziehung „Microsoft.Windows.ComputerHostsOperatingSystem“ definiert:
<RelationshipFact ID="ComputerHostsOperatingSystemFact" Accessibility="Public" Domain="Domain.ConfigurationManagement" TimeGrain="Daily" SourceType="Windows!Microsoft.Windows.Computer" SourceDimension="ComputerDim">
<Relationships RelationshipType="Windows!Microsoft.Windows.ComputerHostsOperatingSystem" TargetDimension="OperatingSystemDim" />
</RelationshipFact>
Beachten Sie, wie Quelldimension und Zieldimension vom Beziehungsfakt definiert werden. Die Quellklasse und die Zielklasse der ursprünglichen Beziehung, auf deren Basis der Beziehungsfakt modelliert wurde, sind das Ziel der Quelldimension und der Zieldimension.
Sie können Beziehungsfakte verwenden, indem Sie zwei Dimensionen miteinander verknüpfen. Mithilfe dieser Verknüpfung können wichtige Informationen der einzelnen Dimensionen im Verhältnis zur jeweils anderen Dimension in Berichten angezeigt werden. So können Sie beispielsweise mithilfe der Beziehung „WorkItemAssignedToUser“ Informationen zu Incidents oder zu Änderungsanforderungen für einen bestimmten Benutzer im Bericht anzeigen. Auf diese Weise können Sie die Daten nach Informationen durchsuchen, die für Sie von Interesse sind. Dies ist nur ein Beispiel dafür, wie nützlich Beziehungsfakten beim Erstellen spezieller Ansichten von Daten in Berichten sind.
Die zum Modellieren eines Beziehungsfakts in einem benutzerdefinierten Management Pack erforderlichen Attribute und Unterelement-Tags werden in der folgenden Tabelle für das Tag „<RelationshipFact>“ beschrieben.
| Attribut | Beschreibung |
|---|---|
| id | Dieser eindeutige Bezeichner für das Beziehungsfaktelement ist auch der Tabellenname des Beziehungsfakts im Data Warehouse und Data Mart. |
| Zugriff | Dieses Element muss immer auf „Public“ gesetzt sein, da bei der Bereitstellung vom System abgeleitete Management Packs erstellt werden, die beim Generieren der automatischen Transformationen auf diesen Outrigger verweisen. |
| Domain | Dies ist der Geltungsbereich des Beziehungsfakts. Mögliche Werte sind: Instance Management Activity Management, Incident Management Change Management und Problem Management. Der Wert dieses Attributs muss eine untergeordnete Aufzählung der im Management Pack „Microsoft.SystemCenter.Datawarehouse.Base“ definierten übergeordneten Aufzählung „Domain“ sein. |
| TimeGrain | Dies ist die Detailebene des Beziehungsfakts. Ihr muss einer der folgenden Werte zugeordnet sein: „Hourly“ (Stündlich), „Daily“ (Täglich), „Weekly“ (Wöchentlich) oder „Monthly“ (Monatlich). |
| SourceType | Dies ist die Management Pack-Klasse für die Quelle der Beziehung. |
| SourceDimension | Von dieser Dimension wird die Quellklasse als Ziel verwendet. Dies ist ein optionales Feld. Wenn keine SourceDimension angegeben ist, findet Service Manager automatisch die Dimension, die direkt auf die Quellklasse selbst oder die nächste übergeordnete Klasse der Quellklasse in der Klassenhierarchie ausgerichtet ist. |
In einem Fakt mit mehreren Beziehungen bleibt die Quelldimension immer gleich. Die Zieldimension kann sich jedoch je nach der jeweiligen Beziehung ändern. Jedes Beziehungstypattribut in einem Fakt mit mehreren Beziehungen muss eindeutig sein. Im folgenden Beispiel wird ein Beziehungsfakt im Management Pack „WorkItemAssignedToAndCreatedByUser“ verwendet:
<RelationshipFact ID="WorkItemAssignedToAndCreatedUserFact" Accessibility="Public" Domain="Domain.InstanceManagement" TimeGrain="Daily" SourceType="WorkItem!System.WorkItem" SourceDimension="WorkItemDim">
<Relationships RelationshipType="WorkItem!System.WorkItemAssignedToUser" TargetDimension="UserDim" />
<Relationships RelationshipType="WorkItem!System.WorkItemCreatedByUser" TargetDimension="UserDim" />
</RelationshipFact>
In diesem Beispiel ist die Zieldimension für beide Beziehungen gleich, die Beziehungen selbst sind jedoch eindeutig. Der Beziehungsfakt ist somit gültig. Weitere Beispiele für Outrigger, Dimensionen und Beziehungsfakten finden Sie in den Data Warehouse Management Packs, die in Service Manager enthalten sind. Ein gutes Beispiel ist das Data Warehouse-Basis-Management Pack „Microsoft.SystemCenter.Datawarehouse.Base“.
Outriggers im Data Warehouse
Ein Outrigger im Data Warehouse in Service Manager ist im Wesentlichen eine Liste, die eine Reihe von Werten logisch gruppieren kann. Die beiden folgenden Tabellen enthalten zwei Beispiele einer logischen Gruppierung von Werten unter dem Parameter „Priorität“ und dem Parameter „Betriebssystem“.
| Priorität |
|---|
| Niedrig |
| Medium |
| High |
| Windows-Betriebssystem |
|---|
| Windows 7 |
| Windows 8 |
| Windows 10 |
Outrigger sind in zweierlei Hinsicht hilfreich:
- Sie können diskrete Werte aus einem Outrigger als Dropdownmenü für einen Berichtsparameter verwenden, wenn Sie Berichte in der Service Manager anzeigen.
- Außerdem können Sie Outriggerwerte zum Gruppieren von Daten in Berichten für die erweiterte Analyse verwenden.
Outrigger im Data Warehouse können auf eine oder mehrere Klasseneigenschaften abzielen und zu deren Konsolidierung in einem Einzelsatz diskreter Werte verwendet werden. Dies ist nur bei Eigenschaften des Datentyps „Zeichenfolge“ oder „ManagementPackEnumeration“ möglich. Auf einer Aufzählung basierende Outrigger dienen zudem der Erhaltung der Hierarchie. Service Manager unterstützt keinen Outrigger, der für einen anderen Datentyp als String oder ManagementPackEnumeration definiert ist.
Während der Vorteil der Definition eines Outriggers auf der Basis einer Aufzählung offensichtlich ist, besteht er bei der Definition eines Outriggers auf der Basis einer Zeichenfolgenspalte darin, dass von der Infrastruktur des Data Warehouse die unterschiedlichen Werte einer Eigenschaft aus dem Instanzbereich in einer kleinen Liste zusammengefasst werden. Eine solche Liste kann dann in einem Bericht als benutzerfreundliche Dropdownliste verwendet werden. Ein gutes Beispiel für einen Outrigger auf Zeichenfolgenbasis ist die Eigenschaft Manufacturer für die Klasse Manufacturer , die in der Service Manager-Datenbank als Zeichenfolge modelliert wird. Durch die Definition eines Outriggers auf der Basis dieser Eigenschaft, kann anstelle einer Herstellersuche ein Wert aus einer Dropdownliste ausgewählt werden.
Um ein Beispiel für die Verwendung eines Outriggers in einem Bericht im Parameterheader zu sehen, öffnen Sie die Service Manager Konsole. navigieren Sie zu Berichterstellung, Aktivitätsverwaltung; und führen Sie dann den Bericht Aktivitätsverteilung aus. Überprüfen Sie dann die Liste Status auf die Werte des Outriggers. Im folgenden Beispiel sehen Sie, wie der Outrigger im Management Pack modelliert wurde. Beachten Sie hierfür die Klasse System.WorkItem.Activity, die im Management Pack „System.Workitem.Activity.Library“ definiert wurde:
<ClassType ID="System.WorkItem.Activity" Accessibility="Public" Base="WorkItem!System.WorkItem" Hosted="false" Abstract="true">
< Property ID="SequenceId" Type="int" />
<Property ID="Notes" Type="richtext" MaxLength="4000" />
<Property ID="Status" Type="enum" EnumType="ActivityStatusEnum" />
<Property ID="Priority" Type="enum" EnumType="ActivityPriorityEnum" />
<Property ID="Area" Type="enum" EnumType="ActivityAreaEnum" />
<Property ID="Stage" Type="enum" EnumType="ActivityStageEnum" />
</ClassType>
Sie können beispielsweise auch einen Outrigger auf Basis der Aufzählungseigenschaft Statusdefinieren. Im folgenden Beispiel sehen Sie, wie Sie einen Outrigger in einem Management Pack Ihrer Wahl definieren können:
<Outrigger ID="ActivityStatus" Accessibility="Public">
<Attribute ID="Status" PropertyPath="$Context/Property[Type='CoreActivity!System.WorkItem.Activity']/Status$" />
</Outrigger>
Wie zuvor beschrieben, können Sie als Erautor des Management Packs einen Outrigger für eine oder mehrere Klasseneigenschaften definieren. Jede Klasseneigenschaft wird durch ein entsprechendes Attribut im Outrigger modelliert. Es folgt ein Beispiel der Visualisierung eines Outriggers auf Aufzählungsbasis. In diesem Beispiel basiert „Activity Status“ auf „ActivityStatusEnum“:
<EnumerationTypes>
<EnumerationValue ID="ActivityStatusEnum" Accessibility="Public" />
<EnumerationValue ID="ActivityStatusEnum.Ready" Parent="ActivityStatusEnum" Accessibility="Public" Ordinal="5.0" />
<EnumerationValue ID="ActivityStatusEnum.Active" Parent="ActivityStatusEnum" Accessibility="Public" Ordinal="10.0" />
<EnumerationValue ID="ActivityStatusEnum.OnHold" Parent="ActivityStatusEnum" Accessibility="Public" Ordinal="15.0" />
<EnumerationValue ID="ActivityStatusEnum.Completed" Parent="ActivityStatusEnum" Accessibility="Public" Ordinal="20.0" />
<EnumerationValue ID="ActivityStatusEnum.Failed" Parent="ActivityStatusEnum" Accessibility="Public" Ordinal="25.0" />
<EnumerationValue ID="ActivityStatusEnum.Cancelled" Parent="ActivityStatusEnum" Accessibility="Public" Ordinal="30.0" />
<EnumerationValue ID="ActivityStatusEnum.Rerun" Parent="ActivityStatusEnum" Accessibility="Public" Ordinal="35.0" />
...
</EnumerationTypes>
Jeder der Werte ist im Satz diskreter Werte des Outriggers enthalten. In der folgenden Tabelle sind die Spalten-ID und die Werte für „ActivityStatusValue“ des Outriggers „ActivityStatus“, der sämtliche Aufzählungswerte aus „ActivityStatusEnum“ enthält, aufgeführt.
| id | ActivityStatusValue |
|---|---|
| ActivityStatusEnum.Completed | Abgeschlossen |
| ActivityStatusEnum | Aktivitätsstatus |
| ActivityStatusEnum.Active | Vorgang wird ausgeführt |
| ActivityStatusEnum.OnHold | On Hold |
| ActivityStatusEnum.Rerun | Rerun |
| ActivityStatusEnum.Failed | Fehler |
| ActivityStatusEnum.Ready | Ausstehend |
| ActivityStatusEnum.Cancelled | Abgebrochen |
In der obigen Tabelle werden alle EnumerationValue-IDs des Aufzählungstyps „ActivityStatus“ in der Spalte „ID“ aufgeführt. Die Werte unter „ActivityStatusValue“ sind die benutzerfreundlichen Anzeigenamen, die in den Dropdownmenüs des Berichts erscheinen.
Das folgende Beispiel enthält weitere Einzelheiten zur Erstellung und Modellierung eines Outriggers. Es wird wieder der Outrigger „ActivityStatus“ als Beispiel verwendet:
<Outrigger ID="ActivityStatus" Accessibility="Public">
<Attribute ID="Status" PropertyPath="$Context/Property[Type='CoreActivity!System.WorkItem.Activity']/Status$" />
</Outrigger>
In der folgenden Tabelle werden die Attribute für die Markierung <Outrigger> beschrieben.
| Attribut | Beschreibung |
|---|---|
| id | Eindeutiger Bezeichner für das Outrigger-Element Dies ist auch der Tabellenname des Outriggers im Data Warehouse und im Datamart |
| Zugriff | Dieses Element sollte immer auf „Public“ festgelegt werden. |
Jede übergeordnete Markierung <Outrigger> enthält mindestens eine untergeordnete Markierung <Attribute>. In der folgenden Tabelle werden die Attribute für diese Markierung beschrieben.
| Attribut | Beschreibung |
|---|---|
| id | Eindeutiger Bezeichner für jedes Outriggerattribut |
| PropertyPath | PropertyPath-Syntax, durch die die Klasse und das Attribut, auf die das Outriggerattribut abzielt, eindeutig identifiziert werden müssen. |
Dimensionen im Data Warehouse
Eine Dimension im Service Manager Data Warehouse in Service Manager entspricht in etwa einer Management Pack-Klasse. Jede Management Pack-Klasse verfügt über eine Liste mit Eigenschaften und jede Dimension eine Liste mit Attributen. Jedes Dimensionsattribut entspricht einer Eigenschaft in einer Klasse.
Angenommen, ein Benutzer möchte in Service Manager einen Bericht erstellen, um einige Informationen zu den Attributen der Computer in einer bestimmten Domäne anzuzeigen. Der Benutzer möchte beispielweise die IP-Adressen, die Anzahl der logischen Prozessoren und den DNS-Namen (Domain Name System) der einzelnen Computer ermitteln. Mithilfe von Dimensionen kann der Benutzer die Daten aus Service Manager in das Data Warehouse bringen. Dort können diese Daten für jeden Computer von Berichten abgefragt und angezeigt werden.
Im Service Manager Data Warehouse wird von einer Dimension immer eine einzelne Klasse als Ziel verwendet. Die Dimensionsattribute werden dann den Eigenschaften der Zielklasse zuordnen. In diesem Beispiel gibt es zum Abrufen der Informationen zu den Attributen von einem Computer eine Computerdimension, von der die Klasse „Microsoft.Windows.Computers“ als Ziel verwendet wird.
In bestimmten Fällen, die in diesem Thema ausführlicher beschrieben werden, kann eine Dimension auch den Eigenschaften der Basis- und abgeleiteten Klassen einer Zielklasse zuordnen. Obwohl eine Dimension ungefähr analog zu einer Management Pack-Klasse sein kann, kann sie auch Eigenschaften enthalten, die sich innerhalb der Hierarchie dieser Management Pack-Klasse befinden.
Ein Beispiel für die Verwendung einer Dimension ist im Bericht „Aktivitätsverteilung“ dargestellt. Wenn Sie in dem Bericht unter Betroffenes Konfigurationselement auswählen (optional)auf Hinzufügenklicken, wird das Feld Dimensionsobjekte auswählen geöffnet, und Sie können in der Dimension „ConfigItemDim“ nach Dimensionsinstanzen suchen. Sie können einen Filter für die Eigenschaft Anzeigename verwenden. Wenn Sie Alle Windows-Computer als Dimensionsobjekt auswählen, wird der Berichtskopf mit dem ausgewählten Filterwert aktualisiert. Beim Ausführen des Berichts werden nur Aktivitäten angezeigt, die das ausgewählte Konfigurationselement Alle Windows-Computerbetreffen.
Anhand der im Management Pack „System.Library“ definierten Klassen „System.Entity“ und „System.ConfigItem“ können Sie erkennen, wie die Dimension modelliert wurde:
<ClassType ID="System.Entity" Accessibility="Public" Hosted="false" Abstract="true" Singleton="false">
<Property ID="DisplayName" Type="string" MinLength="0" Key="false" CaseSensitive="false" MaxLength="4000" />
</ClassType>
<ClassType ID="System.ConfigItem" Base="System.Entity" Accessibility="Public" Hosted="false" Abstract="true">
<Property ID="ObjectStatus" Type="enum" EnumType="System.ConfigItem.ObjectStatusEnum" DefaultValue="System.ConfigItem.ObjectStatusEnum.Active" />
<Property ID="AssetStatus" Type="enum" EnumType="System.ConfigItem.AssetStatusEnum" />
<Property ID="Notes" Type="richtext" MaxLength="4000" />
</ClassType>
Wenn Sie die Dimension des Konfigurationselements so ändern möchten, dass von ihr die Eigenschaften „ObjectStatus“ und „AssetStatus“ von „System.ConfigItem“ und die Eigenschaft „DisplayName“ der Basisklasse „System.Library“ als Ziel verwendet werden, können Sie die Dimension mit den folgenden drei Eigenschaften als Attribute definieren:
<Dimension ID="ConfigItemDim" Accessibility="Public" Target="System!System.ConfigItem" InferredDimension="true" HierarchySupport="Exact" Reconcile="true">
<InclusionAttribute ID="DisplayName" PropertyPath="$Context/Property[Type='System!System.Entity']/DisplayName$" SlowlyChangingAttribute="false" />
<InclusionAttribute ID="ObjectStatus" PropertyPath="$Context/Property[Type='System!System.ConfigItem']/ObjectStatus$" SlowlyChangingAttribute="false" />
<InclusionAttribute ID="AssetStatus" PropertyPath="$Context/Property[Type='System!System.ConfigItem']/AssetStatus$" SlowlyChangingAttribute="false" />
</Dimension>
Die folgende Tabelle enthält Details zum Erstellen und Modellieren einer Dimension durch Prüfen der XML-Schemaelemente und -Attribute auf eine <Dimension>.
| Attribut | Beschreibung |
|---|---|
| id | Ein eindeutiger Bezeichner für das Dimensionselement. Dies ist auch der Tabellenname der Dimension im Data Warehouse und Data Mart. |
| Zugriff | Dieses Element sollte immer auf "Public" festgelegt werden. |
| Ziel | Der Name der Management Pack-Klasse, die von der Dimension als Ziel verwendet wird. |
| InferredDimension | Dieser Wert ist immer auf „true“ festgelegt. |
| HierarchySupport | Die Hierarchie der Klassen, mit deren Hilfe die in die Dimension einbezogenen Eigenschaften definiert werden. Es gibt drei mögliche Werte: 1. Genau 2. IncludeExtendedClassProperties 3. IncludeDerivedClassProperties Einzelheiten dieser Werte finden Sie in den nächsten Abschnitten dieses Themas. |
| Extends | Optionales boolesches Kennzeichen, das angibt, ob die Dimension eine Basisdimension oder die Erweiterung einer anderen Dimension ist. Nachdem eine Dimension definiert wurde, können Sie das Service Manager Data Warehouse verwenden, um die Dimension zu "erweitern" und zu einem späteren Zeitpunkt weitere Attribute hinzuzufügen. Wenn das Kennzeichen „Extends“ auf „true“ festgelegt ist, muss „HierarchySupport“ auf „Exact“ festgelegt und alle Erweiterungsattribute müssen aufgeführt werden. Dieses Kennzeichen ist standardmäßig auf „false“ festgelegt. |
| Reconcile | Optionales boolesches Kennzeichen, das angibt, ob zwei Instanzen, die ansonsten identisch sind und sich nur im Hinblick darauf unterscheiden, aus welcher Quelle die Daten stammen, zu einer Datenzeile konsolidiert werden sollen. Dieses Kennzeichen ist standardmäßig auf „false“ festgelegt. Bei Dimensionen, die mit Konfigurationselementen verknüpft sind, ist dieses Flag auf TRUE festgelegt. Bei Dimensionen, die mit Arbeitselementen verknüpft sind, ist dieses Flag auf FALSE festgelegt. |
Mit dem Attribut „HierarchySupport“ wird festgelegt, welche Klassen verarbeitet werden. Zudem werden die Attribute festgelegt, die in die Dimension einbezogen werden. Details zu den einzelnen möglichen Werten werden in den folgenden Abschnitten beschrieben.
Exact
Wenn das Attribut „HierarchySupport“ auf „Exact“ festgelegt ist, müssen Sie jedes Attribut, das in die Dimension einbezogen werden soll, mithilfe des <InclusionAttribute>-Tags manuell definieren. Diese Attribute können entweder aus der Zielklasse oder einer der Basis- und abgeleiteten Klassen der Zielklasse stammen. Jedes Einschließungsattribut entspricht einer Klasseneigenschaft. In der folgenden Tabelle werden die einzelnen Attribute im <InclusionAttribute>-Tag beschrieben.
| Attribut | Beschreibung |
|---|---|
| id | Ein eindeutiger Bezeichner für das Attributelement. |
| PropertyPath | Die Syntax „PropertyPath“, mit der die Klasse und das Attribut eindeutig identifiziert werden muss, die vom Dimensionsattribut als Ziel verwendet werden. |
| SlowlyChangingAttribute | Dieses Attribut muss immer auf „false“ festgelegt werden. |
Im vorherige Beispiel zur Dimension „ConfigItemDim“ ist „HierarchySupport“ auf „Exact“ festgelegt. Daher werden bei der Transformation nur die aufgeführten Einschließungsattribute („DisplayName“, „ObjectStatus“, „AssetStatus“) verarbeitet und in die Dimensionstabelle im Data Warehouse-Repository und Data Mart einbezogen.
Wenn „HierarchySupport“ auf „Exact“ festgelegt wird, müssen Sie jedes Attribut, das in die Dimension einbezogen werden soll, manuell angeben. Möglicherweise möchten Sie jedoch, dass alle Attribute für die Klasse sowie Attribute aus den entsprechenden Basisklassen und abgeleiteten Klassen in die Dimension einbezogen werden. In diesem Fall ist es sehr aufwändig, alle Attribute einzeln aufzulisten. Zur Erleichterung enthält Service Manager zwei weitere „HierarchySupport“-Werte, mit denen diese Fälle automatisiert werden. Diese Werte werden in den folgenden Abschnitten beschrieben.
IncludeExtendedClassProperties
Bei einer Dimension, bei der „HierarchySupport“ auf „IncludeExtendedClassProperties“ festgelegt wurde, werden alle Attribute der Zielklasse und alle entsprechenden Basisklassen in die Dimensionstabelle und die Transformation aufgenommen. In der folgenden Abbildung ist ein Beispiel dargestellt: Von „CarDimension“ wird die Klasse „Car“ als Ziel verwendet und „HierarchySupport“ ist auf „IncludeExtendedClassProperties“ festgelegt.

Da von „CarDimension“ die Klasse „Car“ als Ziel verwendet wird und der „HierarchySupport“-Wert auf „IncludeExtendedClassProperties“ festgelegt ist, wird sowohl die Klasse „Car“ als auch die entsprechende Basisklasse „Vehicle“ verarbeitet. Die resultierende Tabelle und die Transformation enthalten der Attribute in der folgenden Tabelle.
| Attribute vom Typ „CarDimension“ |
|---|
| Color |
| Make |
| Modell |
| NumDoors |
| NumCupHolders |
| PS |
| CargoSpace |
IncludeDerivedClassProperties
Bei einer Dimension, bei der „HierarchySupport“ auf „IncludeDerivedClassProperties“ festgelegt wurde, werden alle Attribute der Zielklasse, die entsprechenden Basisklassen und die entsprechenden abgeleiteten Klassen in die Dimensionstabelle und die entsprechende Transformation aufgenommen.
Wenn wir das vorherige Beispiel leicht verändern, hat „CarDimension“ nun den weiter unten angegebenen „HierarchySupport“-Wert „IncludeDerivedClassProperties“. Da die Basisklasse und die abgeleiteten Klassen der Zielklasse verarbeitet werden, werden nun von der Dimension die Attribute von drei Klassen verarbeitet: „Vehicle“, „Car“ und „Sportscar“ (siehe folgende Abbildung).

Die Dimensionstabelle „CarDimension“ und die Transformation enthalten der Attribute in der folgenden Tabelle.
| Attribute vom Typ „CarDimension“ |
|---|
| Color |
| Make |
| Modell |
| NumDoors |
| NumCupHolders |
| PS |
| CargoSpace |
| TopSpeed |