Überblick über das Customizing des Service Manager-Datawarehouse

Nachdem das Data Warehouse des Dienstmanagers bereitgestellt wurde und Sie sich die Berichte angesehen haben, können Sie die Informationen in den Berichten anpassen, um sie besser an Ihr Unternehmen anzupassen. So können Sie beispielsweise Berichte, die Sie in der Vergangenheit mit anderen Informationssystemen verwendet haben, mit Hilfe des Dienstmanagers neu erstellen. Oder Sie möchten die Berichte an Ihre internen Geschäftsprozesse für Vorfälle oder das Änderungsmanagement anpassen.

Anhand der Informationen in diesem Abschnitt können Sie ermitteln, wie Sie das Data Warehouse erweitern und anpassen können, um tiefgreifende Analysen zu ermöglichen.

Dimensionale Modellierung des Data Warehouse mithilfe eines Sternschemas

Das Data Warehouse im Dienstmanager besteht aus einer Reihe von Datenbanken und Prozessen. Die Prozesse fügen die Informationen automatisch zu den Datenbanken hinzu. Kurz gesagt, der Zweck des Data Warehouse besteht darin, Informationen zum Data Mart hinzuzufügen, in dem Sie und andere Benutzender Berichte erstellen und Analysen durchführen, um Ihr Unternehmen zu verwalten. Der Service Manager speichert Data-Warehouse-Daten länger im Warehouse als in der Service Manager-Datenbank, da die Daten für Trend und Analyse nützlich sind. Außerdem sind Data-Warehouse-Daten oft nicht mehr für die normale Transaktionsverarbeitung geeignet.

Das Data Warehouse ist dafür optimiert, eine große Menge an Daten auf einmal auf viele scheinbar unvorhersehbare Arten zu aggregieren und zu analysieren. Dieses Verhalten unterscheidet sich von transaktionalen Verarbeitungssystemen, die für den Schreibzugriff auf wenige Datensätze in einer bestimmten Transaktion optimiert sind, was das Verhalten dieser Transaktionen vorhersehbarer macht.

Um das Data Warehouse im Hinblick auf Leistung und Benutzerfreundlichkeit zu optimieren, verwendet der Dienstmanager den Kimball-Ansatz für die dimensionale Modellierung. (Weitere Informationen über den Kimball-Ansatz finden Sie unter Dimensionale Modellierung). Das bedeutet, dass die Tabellen in der DWDataMart-Datenbank logisch in Sachgebieten gruppiert sind, die in einem Diagramm einem Stern ähneln. Daher werden diese Gruppierungen oft als Sternschemata bezeichnet und umfassen die folgenden:

• In der Mitte des Sterns befindet sich eine Faktentabelle. Faktentabellen repräsentieren Beziehungen, Kennzahlen und Key Performance Indicators (KPIs). Faktentabellen sind in der Regel lang und haben relativ wenige Spalten, aber sie enthalten eine große Anzahl von Transaktionen.
• Die Faktentabelle wird mit Dimensionstabellen verbunden, die Klassen, Eigenschaften und Aufzählungen darstellen. Dimensionstabellen enthalten in der Regel viel weniger Zeilen als Faktentabellen, sind aber breiter, da sie Attribute enthalten, mit denen Benutzende Berichte nach verschiedenen Kriterien aufschlüsseln können. Diese Attribute können Status, Klassifizierungen und Datumsattribute (z. B. Erstellungsdatum oder Auflösungsdatum) einer Klasse umfassen.
• Ein Outrigger ist eine spezielle Art von Bemaßungstabelle, die aus Gründen der Leistung und der Benutzerfreundlichkeit an eine andere Bemaßungstabelle angehängt wird.

Wenn Sie an ein Sternschema denken, überlegen Sie, wie ein Sternschema für ein Café aussehen könnte. Wenn es sich bei den Transaktionen um Kaffeekäufe handelt, könnten die Dimensionen Folgendes umfassen:

• Eine Datumsdimension zur Konsolidierung der Transaktion nach gregorianischem und fiskalischem Kalender
• Eine Kundendimension, die angibt, wer den Kaffee gekauft hat
• Eine Mitarbeiterdimension, die angibt, wer den Kaffee gemacht hat
• Eine Produktdimension, die den Kaffeetyp angibt, z. B. Espresso, Filterkaffee, Latte oder Breve
• Eine Speicher-Dimension

Wenn Sie die Maßnahmen in Betracht ziehen, die eine Faktentabelle enthalten könnte, könnte die Liste Folgendes umfassen:

• Verkaufte Menge
• Einzelpreis
• Gesamter Umsatz
• Gesamtrabatte

Die Prozesse der Informationstechnologie (IT) unterscheiden sich nicht von dem Beispiel des Cafés, wenn Sie ein dimensionales Modell entwerfen. Es gibt Vorgänge wie die Erstellung, Lösung und Schließung von Ereignissen, die interessante und nützliche Metriken hervorbringen können, z. B. die Zeit bis zur Lösung, die Einhaltung des Lösungsziels, die von den Analysten in Rechnung gestellte Zeit und die Dauer des Status.

Berücksichtigen Sie beim Erweitern und Anpassen Ihres Data Warehouses die geschäftsspezifischen Fragen, die Sie beantworten möchten, und untersuchen Sie die dimensionale Modellierung für nützliche Informationen und bewährte Methoden. Weitere Informationen zum Anpassen des Data Warehouse finden Sie in den anderen Abschnitten dieses Artikels.

Faktentabellen im Data Warehouse

In diesem Abschnitt wird beschrieben, wie Sie Beziehungsfakten im Data Warehouse im Dienstmanager definieren. Ein Beziehungsfakt im Data Warehouse des Dienstmanagers ist einer Beziehung im Dienstmanager ähnlich. Sie können einen Beziehungsfakt nutzen, um Abfragen anzunehmen, wie die folgende:

• Welche Arbeitselemente sind momentan dem Benutzender John Smith zugeordnet, so dass Sie deren Status ermitteln können?
• Wie lautet die Liste aller Computer in der Domäne, auf denen momentan Windows 10 installiert ist, damit Sie sie auf die neueste Version aktualisieren können?
• Welche Prüfaktivitäten listen Samantha Smith als Prüfer auf, damit sie neu zugewiesen werden können, weil sie im Urlaub ist?

In jedem dieser Szenarien gibt es eine Quellinstanz und eine Zielinstanz, die durch eine Beziehung miteinander verbunden sind. Ohne einen Beziehungfakt ist es schwierig, die Zusammenhänge zwischen den Instanzen zu ermitteln. Betrachten Sie die Beziehung in der Microsoft.Windows.ComputerHostsOperatingSystem im Microsoft.Windows.Library Management Pack im folgenden Beispiel:

<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 die Quelle und das 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“ ist das Ziel. Die folgenden Informationen definieren die entsprechende Beziehungsfakt basierend auf der Microsoft.Windows.ComputerHostsOperatingSystem-Beziehung:

<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 der Beziehungsfakt eine Quelldimension und eine Zieldimension definiert. Möglicherweise stellen Sie fest, dass die Quell- und Zieldimensionen auf die Quell- und Zielklassen aus der ursprünglichen Beziehung abzielen, für die der Beziehungsfakt modelliert ist.

Sie können Beziehungsfakten verwenden, indem Sie zwei Dimensionen miteinander verknüpfen, wodurch Berichte die Zuordnung verwenden können, um wichtige Informationen aus jeder Dimension in Bezug auf die andere anzuzeigen. Sie können beispielsweise die WorkItemAssignedToUser-Beziehung verwenden, um Informationen zu Vorfällen oder Änderungsanforderungen für einen bestimmten Benutzenden im Bericht anzuzeigen. Dies ermöglicht es Ihnen, in den Daten zu navigieren, um Informationen zu finden, die für Ihre Anforderungen spezifisch sind. Dies ist nur ein Beispiel dafür, inwiefern Beziehungsfakten hilfreich sind, um spezielle Ansichten von Daten in Berichten zu erstellen.

Die Attribute und Unterelementtags, die zum Modellieren einer Beziehung in einem benutzerdefinierten Management Pack erforderlich sind, werden in der folgenden Tabelle für das <RelationshipFact>-Tag beschrieben.

Merkmal	Beschreibung
ID	Ein eindeutiger Bezeichner für das Beziehungsfaktelement. Dies ist auch der Tabellenname des Beziehungsfakts im Data Warehouse und Data Mart.
Zugriff	Dieses Element sollte immer auf „Öffentlich“ festgelegt werden, da der Bereitstellungsprozess systembasierte Management Packs erstellt, die während der Generierung der automatisierten Transformationen auf diesen Outrigger verweisen.
Domäne	Der Umfang des Beziehungsfakts. Mögliche Werte umfassen die folgenden: Instanzverwaltung, Aktivitätsverwaltung, Vorfallmanagement, Änderungsmanagement und Problemverwaltung. Der Wert für dieses Attribut muss eine Aufzählung sein, die ein Kindelement der übergeordneten Domänen-Aufzählung ist, die im Microsoft.SystemCenter.Datawarehouse.Base Management Pack definiert ist.
TimeGrain	Die Detailebene des Beziehungsfakts. Der Wert muss einer der folgenden sein: stündlich, täglich, wöchentlich oder monatlich.
SourceType	Die Management Pack-Klasse für die Quelle der Beziehung.
Quellendimension	Die Dimension, die auf die Quellklasse abzielt. Dies ist ein optionales Feld. Wenn keine SourceDimension angegeben ist, findet der Service Manager automatisch die Dimension, die direkt auf die Quellklasse selbst oder die nächstgelegene übergeordnete Klasse der Quellklasse in der Klassenhierarchie abzielt.

In einem Mehrbeziehungsfakt bleibt die Quelldimension immer gleich. Die Zieldimension kann sich jedoch je nach spezifischer Beziehung ändern. Jedes Beziehungstyp-Attribut in einem Beziehungsfakt mit mehreren Beziehungen muss eindeutig sein. Das folgende ist ein Beispiel für den Beziehungsfakt im WorkItemAssignedToAndCreatedByUser Management Pack:

<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 können Sie sehen, dass die Zieldimension zwar für beide Beziehungen identisch ist, aber die Beziehungen selbst eindeutig sind. Daher ist der Beziehungsfakt gültig. Für weitere Beispiele von Outriggertabellen, Dimensionen und Beziehungsfakten können Sie eines der Data Warehouse-Management Packs untersuchen, die im Service Manager enthalten sind. Ein gutes Beispiel ist das grundlegende Data Warehouse Management Pack mit dem Namen „Microsoft.SystemCenter.Datawarehouse.Base“.

Outriggers im Data Warehouse

Ein Outrigger im Data Warehouse im Service Manager ist im Wesentlichen eine Liste, die eine Gruppe von Werten logisch gruppieren kann. Die folgenden Tabellen zeigen zwei Beispiele, die eine logische Gruppierung von Werten darstellen, die Priorität und Windows-Betriebssysteme kennzeichnen.

Priorität
Low
Medium
High

Windows-Betriebssystem
Windows 7
Windows 8
Windows 10

Ein Outrigger ist auf zwei Arten nützlich:

• Sie können diskrete Werte von einem Outrigger als Dropdownmenü für einen Berichtsparameter verwenden, wenn Sie Berichte in der Service Manager-Konsole erstellen und anzeigen.
• Sie können Outriggerwerte verwenden, um Daten in Berichten für die erweiterte Analyse zu gruppieren.

Outrigger im Data Warehouse können auf eine oder mehrere Klasseneigenschaften abzielen und diese in einem einzigen Satz von diskreten Werten konsolidieren. Diese Eigenschaften können nur vom Datentyp „String“ oder „ManagementPackEnumeration“ sein. Wenn sie auf einer Enumeration basieren, bewahren Outrigger auch die Hierarchie. Service Manager unterstützt keinen Outrigger, der für einen anderen Datentyp als „String“ oder „ManagementPackEnumeration“ definiert ist.

Obwohl der Vorteil der Definition eines Outriggers auf einer Enumeration offensichtlich ist, besteht ein Vorteil der Definition eines Outriggers auf einer Zeichenfolgenspalte darin, dass die Data Warehouse-Infrastruktur die unterschiedlichen Werte einer Eigenschaft aus dem Instanzraum in eine kleine Liste vereint. Sie können die Liste dann in einer benutzerfreundlichen Dropdownliste in einem Bericht verwenden. Ein gutes Beispiel für einen zeichenfolgenbasierten Outrigger ist die Eigenschaft Manufacturer der Klasse Computer, die als Zeichenfolge in der Service Manager-Datenbank modelliert wird. Durch die Definition eines Eigenschaftsauslösers auf dieser Eigenschaft bietet der Service Manager die Möglichkeit, einen Wert aus der Dropdownliste auszuwählen, anstatt unter den Herstellern zu suchen, von denen Sie Ihre Computer beschafft haben.

Um ein Beispiel für die Verwendung eines Outriggers in einem Bericht im Parameterheader anzuzeigen, ö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 als Nächstes die Status-Liste, um die Werte des Outriggers anzuzeigen. Sie können im folgenden Beispiel sehen, wie das Outrigger im Management Pack modelliert wurde. Beachten Sie die Klasse System.WorkItem.Activity, die im Management Pack „System.Workitem.Activity.Library“ definiert ist:

<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>

Definieren Sie als Nächstes einen Outrigger basierend auf der Enumerationseigenschaft Status. Das folgende Beispiel zeigt, 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 bereits beschrieben, können Sie – als Management Pack-Autor – einen Outrigger für eine oder mehrere Klasseneigenschaften definieren. Jede Klasseneigenschaft wird durch ein entsprechendes Attribut im Outrigger modelliert. Im Folgenden sehen Sie ein Beispiel einer enumerationsbasierten Outriggervisualisierung. In diesem Beispiel basiert der Aktivitätsstatus 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 in der Menge der diskreten Werte der Outriggertabelle enthalten. In der folgenden Tabelle sind die Spalten-ID und „ActivityStatusValue“ aus dem „ActivityStatus“-Outrigger aufgeführt, der alle Enumerationswerte aus „ActivityStatusEnum“ enthält.

ID	ActivityStatusValue
ActivityStatusEnum.Completed	Abgeschlossen
ActivityStatusEnum	Aktivitätsstatus
ActivityStatusEnum.Active	In Bearbeitung
ActivityStatusEnum.OnHold	Gesperrt
ActivityStatusEnum.Rerun	Rerun
ActivityStatusEnum.Failed	Gescheitert
ActivityStatusEnum.Ready	Ausstehend
ActivityStatusEnum.Cancelled	Storniert

In der vorherigen Tabelle enthält die ID-Spalte der Outriggertabelle alle EnumerationValue-IDs aus dem Aktivitätsstatus-Aufzählungstyp. „ActivityStatusValue“ ist der tatsächliche benutzerfreundliche Anzeigename, der in den Dropdownmenüs des Berichts angezeigt wird.

Das folgende Beispiel enthält weitere Details zum Konstruieren und Modellieren eines Outriggers. Auch hier wird der „ActivityStatus“-Outrigger 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 des <Outrigger>-Tags beschrieben.

Merkmal	Beschreibung
ID	Ein eindeutiger Bezeichner für das Outriggerelement. Dies ist auch der Tabellenname der Outriggertabelle im Data Warehouse und Data Mart.
Zugriff	Dieses Element sollte immer auf „Öffentlich“ festgelegt werden.

Jedes übergeordnete <Outrigger>-Tag enthält mindestens ein <Attribute>-Unterelementtag. In der folgenden Tabelle werden die Attribute dieses Tags beschrieben.

Merkmal	Beschreibung
ID	Ein eindeutiger Bezeichner für jedes Outrigger-Attribut
PropertyPath	PropertyPath-Syntax, die die Klasse und das Attribut eindeutig identifizieren muss, auf die das Outrigger-Attribut ausgerichtet ist.

Dimensionen im Data Warehouse

Eine Dimension im Service Manager Data Warehouse in Service Manager entspricht ungefähr einer Management Pack-Klasse. Jede Verwaltungsklasse verfügt über eine Liste von Eigenschaften, während jede Dimension eine Liste von Attributen enthält. Jedes Dimensions-Attribut entspricht einer Eigenschaft in einer Klasse.

Angenommen, Benutzende möchten, dass ein Bericht im Service Manager Informationen zu den Attributen für die Computer in einer bestimmten Domäne anzeigt. Die Benutzenden möchten z. B. die IP-Adresse, die Anzahl der logischen Prozessoren und den DNS-Namen (Domain Name System) für jeden Computer anzeigen. Mithilfe von Dimensionen können Benutzende die Daten von Service Manager in das Data Warehouse übertragen, in dem Berichte diese Daten für jeden Computer abfragen und anzeigen können.

Im Service Manager Data Warehouse zielt eine Dimension immer auf eine einzelne Klasse ab. Die Dimensionsattribute werden dann den Eigenschaften der Zielklasse zugeordnet. In diesem Beispiel gibt es zum Abrufen der Informationen zu den Attributen von einem Computer eine Computerdimension, die auf die Klasse „Microsoft.Windows.Computers“ ausgerichtet ist.

In bestimmten Fällen, die in diesem Artikel noch genauer beschrieben werden, kann eine Dimension auch den Eigenschaften der Basis- und abgeleiteten Klassen einer Zielklasse zugeordnet werden. Daher kann eine Dimension ungefähr mit einer Management Pack-Klasse verglichen werden. Sie kann auch Eigenschaften enthalten, die sich in der Hierarchie dieser Management Pack-Klasse befinden.

Sie können ein Beispiel für die Verwendung einer Dimension im Aktivitätsverteilungsbericht sehen. Wenn Sie im Bericht unter Betroffenes Konfigurationselement auswählen (optional) die Option Hinzufügen auswählen, wird das Feld Dimensionsobjekte auswählen angezeigt, und Sie können in der ConfigItemDim-Dimension nach Dimensionsinstanzen suchen. Sie können nach der Eigenschaft Anzeigename filtern. Wenn Sie Alle Windows-Computer als Dimensionsobjekt auswählen, wird der Berichtskopf mit dem ausgewählten Filterwert aktualisiert. Wenn Sie den Bericht ausführen, werden nur Aktivitäten angezeigt, die sich auf das ausgewählte Konfigurationselement Alle Windows-Computer auswirken.

Um zu sehen, wie die Dimension modelliert wurde, können Sie sich die Klassen „System.Entity“ und „System.ConfigItem“ ansehen, die im „System.Library“-Management Pack definiert sind:

<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>

Um die Konfigurationselementdimension so zu überarbeiten, dass sie auf die Eigenschaften „ObjectStatus“ und AssetStatus“ von „System.ConfigItem“ und die Eigenschaft „DisplayName“ der Basisklasse „System.Library“ ausgerichtet ist, 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 Untersuchen der XML-Schemaelemente und -Attribute für eine <Dimension>.

Merkmal	Beschreibung
ID	Ein eindeutiger Bezeichner für das Dimensions-Element Dies ist auch der Tabellenname der Dimension im Data Warehouse und in Datamart.
Zugriff	Dieses Element sollte immer auf „Öffentlich“ festgelegt werden.
Ziel	Der Management Pack-Klassenname, auf den die Dimension abzielt.
InferredDimension	Dieser Wert ist immer auf wahr gesetzt.
Hierarchieunterstützung	Die Hierarchie von Klassen, mit denen die Eigenschaften definiert werden, die in der Dimension enthalten sein werden. Es gibt drei mögliche Werte: 1. Genau 2. Erweiterte Klassenattribute Einbeziehen 3. Abgeleitete Klasse Eigenschaften einbeziehen Ausführliche Informationen zu diesen Werten finden Sie in den nächsten Abschnitten dieses Artikels.
Erweitert	Optionales boolesches Flag zur Angabe, ob die Dimension eine Basisdimension ist oder eine andere Dimension erweitert. 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 Flag „Erweitert“ auf „true“ festgelegt ist, muss „HierarchySupport“ auf „Exact“ festgelegt sein, und alle Erweiterungsattribute müssen aufgelistet werden. Dieses Flag ist standardmäßig auf „false“ festgelegt.
Versöhnen	Optionale boolesche Flag, die angibt, ob zwei Instanzen, die ansonsten identisch sind und sich nur in der Quelle der Daten unterscheiden, zu einer einzigen Datenzeile zusammengefasst werden sollen. Dieses Flag ist standardmäßig auf „false“ festgelegt. Dimensionen, die sich auf Konfigurationselemente beziehen, sollten dieses Kennzeichen auf „true“ festgelegt haben, und Dimensionen, die mit Arbeitsaufgaben zusammenhängen, haben dieses Kennzeichen auf „false“ festgelegt.

Das HierarchySupport-Attribut bestimmt, welche Klassen verarbeitet werden, und die spezifischen Attribute, die in der Dimension enthalten sind. Details zu jedem möglichen Wert werden in den folgenden Abschnitten beschrieben.

Genau

Wenn das Attribut „HierarchySupport“ auf „Exact“ gesetzt ist, müssen Sie jedes Attribut, das in die Dimension aufgenommen werden soll, manuell mithilfe des <InclusionAttribute>-Tags definieren. Diese Attribute können entweder aus der Zielklasse oder einer der Basis- und abgeleiteten Klassen der Zielklasse stammen. Jedes Einschluss-Attribut entspricht einer Klasseneigenschaft. In der folgenden Tabelle werden die Attribute des <InclusionAttribute>-Tags beschrieben.

Merkmal	Beschreibung
ID	Ein eindeutiger Bezeichner für das Attributelement.
PropertyPath	PropertyPath-Syntax, die die Klasse und das Attribut eindeutig identifizieren muss, auf die das Dimension-Attribut ausgerichtet ist.
Langsam änderndes Attribut	Dieses Attribut sollte immer „false“ sein.

Das vorherige ConfigItemDim-Dimensionbeispiel hatte einen HierarchySupport-Wert von Exact. Daher werden nur die aufgelisteten Inklusionsattribute (DisplayName, ObjectStatus, AssetStatus) in der Transformation verarbeitet und in die Dimensionstabelle im Data Warehouse-Repository und Datamart eingeschlossen.

Der Wert „Exact HierarchySupport“ erfordert, dass Sie jedes in der Dimension gewünschte Attribut manuell auflisten. Möglicherweise möchten Sie jedoch, dass alle Attribute für eine Klasse sowie Attribute aus ihren Basis- und abgeleiteten Klassen in die Dimension aufgenommen werden sollen. In diesen Fällen kann es sehr aufwändig sein, jedes Attribut explizit aufzulisten. Um Ihnen zu helfen, enthält Service Manager zwei weitere HierarchySupport-Werte, die diese Fälle automatisch für Sie behandeln. Diese Werte werden in den folgenden Abschnitten beschrieben.

IncludeExtendedClassProperties

Für eine Dimension mit einem HierarchySupport von IncludeExtendedClassProperties werden alle Attribute der Zielklasse und aller zugehörigen Basisklassen in die Dimensionstabelle und -transformation einbezogen. Die folgende Illustration zeigt ein Beispiel: CarDimension, das auf die Klasse Auto abzielt und eine Hierarchieunterstützung von Einschluss erweiterter Klasseneigenschaften hat.

Da CarDimension auf die Car-Klasse ausgerichtet ist und einen HierarchySupport-Wert von IncludeExtendedClassProperties aufweist, verarbeitet sie sowohl die Car-Klasse als auch die Basisklasse Vehicle. Die resultierende Tabelle und Transformation enthalten die Attribute in der folgenden Tabelle.

AutoDimensionsattribute
Farbe
Make
Modell
NumDoors
NumCupHolders
Pferdestärke
CargoSpace

IncludeDerivedClassProperties

Bei einer Dimension mit einem HierarchySupport von IncludeDerivedClassProperties werden alle Attribute der Zielklasse, deren Basisklassen und der abgeleiteten Klassen in die Dimensionstabelle und die zugehörige Transformation einbezogen.

Durch eine leichte Modifikation des vorherigen Beispiels hat CarDimension jetzt einen Hierarchie-Support von Einschluss der Eigenschaften abgeleiteter Klassen unten. Da sie sowohl die Basisklassen als auch abgeleitete Klassen der Zielklasse verarbeitet, verarbeitet die Dimension nun die Attribute von drei Klassen: Fahrzeug, Auto und Sportwagen, wie in der folgenden Abbildung dargestellt.

Die CarDimension-Dimensionstabelle und die Transformation enthalten die Attribute in der folgenden Tabelle.

AutoDimensionsattribute
Farbe
Make
Modell
NumDoors
NumCupHolders
Pferdestärke
CargoSpace
Höchstgeschwindigkeit