Översikt över modellering av Service Manager OLAP-kuber i hanteringspaket
Viktigt
Den här Service Manager har nått slutet av supporten, rekommenderar vi att du uppgraderar till Service Manager 2022.
Möjligheten att definiera anpassade hanteringspaketelement användes för att modellera OLAP-kubhanteringspaketelementen (Online Analytical Processing) som ingår i Service Manager. Dessa hanteringspaketelement gör det möjligt för användare att deklarativt definiera och anpassa en OLAP-kub på en högre abstraktionsnivå. Med utgångspunkt från denna definition skapas rätt relationer, komponenter och grundläggande byggblock för OLAP-kuben på en mer detaljerad nivå vid distributionen av dessa hanteringspaketelement, utan att användaren behöver ange några inställningar. Följande två huvudsakliga hanteringspaketelement ingår i OLAP-kuberna:
SystemCenterCube
CubeExtension
SystemCenterCube
SystemCenterCube-elementet definierar OLAP-kuben på varierande detaljnivå beroende på de specifika behoven. Elementet innehåller följande delelement:
MeasureGroup
Ersättning
CustomMDX
NamedCalculation
Mått
KPI
Åtgärd (för närvarande stöds dock endast detaljgranskningsåtgärder)
ManyToManyRelationship
MeasureGroup
Varje OLAP-kub innehåller en samling fakta som finns i datamarten, där varje medlem i samlingen motsvarar en måttgrupp. Varje måttgrupp måste ha ett eget unikt namn inom OLAP-kuben. Ett enskilt faktum kan dock motsvara flera måttgrupper i en OLAP-kub. Till exempel kan den abstrakta relationen WorkItemAssignedToUser definieras tre gånger i en OLAP-kub, med de unika måttgruppnamnen ChangeRequestAssignedToUser, IncidentAssignedToUser och ProblemAssignedToUser. Du kan anpassa det faktum så att endast ändringsbegäranden, incidenter och problem ingår i respektive måttgrupp för OLAP-kuben.
I följande exempel visas hanteringspaketelementet för måttgruppen IncidentAssignedToUser:
<MeasureGroup DateDimAlias="IncidentAssignedToUserDateDim" MeasureGroupName-"IncidentAssignedTouser" Fact="DWBase!WorkItemAssignedToUserFact"/>
När OLAP-kuben distribueras beräknas automatiskt relationerna för dimension, utriggare och främmande nycklar och datakällvyn uppdateras med dessa nya element. I följande tabell beskrivs attributen för måttgrupp.
| Attribut | Obligatorisk | Värden | Definition |
|---|---|---|---|
| DateDimAlias | Inga | Sträng | Namnet på datumdimensionen som används för att filtrera måttgruppen. Om inget alias har definierats blir rollspel automatiskt "(MeasureGroupName)_DateDim" |
| MeasureGroupName | Ja | Sträng | Namnet på måttgruppen i kuben. Det här namnet måste vara unikt inom kuben. |
| Fakta | Yes | Relation eller CustomFact | Målet för måttgruppen, vilket måste vara ett faktum i datalagret. |
Ersättning
Eftersom relationsfakta i datalagret kan ha abstrakta relationer och dimensioner som mål måste du ersätta dem med konkreta dimensioner så att måttgruppen endast innehåller sådana instanser som du vill bläddra i.
Det kan illustreras med följande exempel.
<Substitution MeasureGroupName="IncidentAssignedTouser" RelationshipEndpoint="Source" Relationship="Workitem!System.WorkItemAssignedToUser" TargetDimension="DWBase!WorkItemDim" ReplacementDimension="IncidentDW!IncidentDim"/>
I det här exemplet mäter måttgruppen IncidentAssignedToUser vid workitemAssignedToUser-relationen . Den här relationen kommer dock inte bara att innehålla incidenter, utan även ändringsbegäranden och problem som också har tilldelats till alla användare. För att säkerställa att den här måttgruppen endast innehåller incidenter Service Manager WorkItemDim med IncidentDim. Det innebär att tabellen som skapas i datakällvyn för måttgruppen automatiskt genomför en inre koppling på WorkItemDim med IncidentDim och endast returnerar sådana instanser där en koppling är giltig baserat på EntityDimKey eller BaseManagedEntityId.
Kom ihåg att du måste definiera den slutpunkt för relationen där du vill utföra ersättningen. Det här elementet krävs eftersom det finns en möjlighet att källans och slutpunktens dimensioner är identiska, och en metod krävs för att unikt identifiera vilken dimension som ska ersättas. Ett exempel på en sådan relation är WorkItemRelates till WorkItem.
Ersättningselementet används också för att definiera aliasdimensioner för kuben. Du kan med andra ord definiera ett aliasnamn för en dimension, men det krävs inte för att i praktiken ersätta en dimension. I praktiken sker ersättningen i det här fallet inte på dimensionen utan på kubdimensionen eller aliasnamnet för dimensionen, som följande exempel visar:
<Substitution MeasureGroupName="IncidentAssignedToUser" RelationshipEndpoint="Target" Relationship="Workitem!System.WorkItemAssignedToUser" AliasTargetDimensionAs="AssignedToUserDim" TargetDimension="DWBase!UserDim"/>
I det här exemplet är aliaskubens dimensionsnamn AssignedToUserDim. Det här är namnet på dimensionen som ska användas för att filtrera på kuben. Genom att tillåta användare att definiera aliasnamn kan namn skräddarsys specifikt för att möjliggöra önskade många-till-många-relationer i kuben. Det skapar möjligheter för mer avancerade filter och analysfunktioner.
Slutligen är ersättningar giltiga inte bara för relationsfakta utan även för anpassade fakta. I det här scenariot skulle relationsslutpunkten anges till Ingen. I följande tabell beskrivs ersättningsattributen.
| Attribut | Obligatorisk | Värden | Definition |
|---|---|---|---|
| MeasureGroupName | Ja | Sträng | Måttgruppens namn på vilken ersättningen ska utföras |
| RelationshipEndPoint | Yes | (Mål, Källa, Ingen) | Slutpunkten för relationen där ersättningen ska utföras. Som standard är värdet Inget för anpassade fakta. |
| Relation | No | ManagementPackRelationship | Relationen som ska användas för ersättningen. |
| AliasTargetDimensionAs | Inga | Sträng | Aliasnamnet på den ursprungliga riktade dimensionen |
| AliasReplacementDimensionsAs | Inga | Sträng | Aliasnamnet för den ersatta dimensionen |
| DimensionAlias | No | ManagementPackDimension | Dimensionens alias från ett anpassat faktum om sådant finns |
Anpassat MDX
Du kan använda anpassade MDX-skript (Flerdimensionellt uttryck) för att ändra och skräddarsy OLAP-kuben efter de exakta specifikationer som uppfyller dina behov. Eftersom Service Manager är modellbaserade är det omöjligt att fastställa alla möjliga semantiska behov när du tar hänsyn till det breda spektrumet av krav och exakta specifikationer för en viss användares domänspecifika affärsbehov. Med hjälp av anpassade MDX kan du definiera MDX-skript som kan tillämpas på OLAP-kuben för att möjliggöra specifika scenarier för mätning och instrumentering.
Namngiven beräkning
Du kan använda namngivna beräkningar för att definiera nya attribut på en dimension som ett anpassat mått senare kan riktas mot. Det innebär att du kan utsträcka det dimensionella schemat och anpassa det till dina specifika behov. Följande exempel är hämtat från SystemCenterWorkItemsCube:
<NamedCalculation ID="IncidentsPastTargetResolutionTime" Target="IncidentDW!IncidentDim" ColumnType="Int">
<Calculation>(case when ( (([Status] = 'IncidentStatusEnum.Resolved' OR [Status] = 'IncidentStatusEnum.Closed') AND ResolvedDate > TargetResolutionTime) OR (([Status] != 'IncidentStatusEnum.Resolved' AND [Status] != 'IncidentStatusEnum.Closed') AND GETUTCDATE() > TargetResolutionTime)) then 1 else 0 end )</Calculation>
</NamedCalculation>
I det här exemplet innehåller incidentdimensionen data, till exempel status för incidenten och förväntad lösningstid. Det finns dock inget internt mått som beräknar antalet incidenter som överstiger den förväntade lösningstiden, även om denna typ av data är mycket användbar för en systemadministratör. Du kan skapa det här scenariet genom att använda en namngiven beräkning och aggregera data så att ett anpassat mått kan riktas mot det nya attributet och sedan presentera informationen för en slutanvändare.
Kom ihåg Service Manager endast stöder namngivnaberäkningsmåldimensioner. NamedCalculation kan inte riktas mot fakta. I följande tabell beskrivs attributen för namngiven beräkning.
| Attribut | Obligatorisk | Värden | Definition |
|---|---|---|---|
| ID | Ja | Sträng | Namn på den namngivna beräkningen |
| Mål | Yes | ManagementPackDimension | Måldimensionen för måttet |
| ColumnType | Yes | (Int, Double) | Kolumnens Structured Query Language (SQL) typ |
| Typ | No | (Antal, Summa) | Typen av mått |
Underelementet <Beräkning> innehåller, som dess värde, definitionen av den namngivna beräkningen. Värdet lagras som ett MDX-uttryck.
Mått
Du kan använda anpassade mått för att sammanställa och visa data baserat på numeriska attribut från dimensioner. Service Manager stöder inte anpassade mått baserat på fakta. Vi fortsätter med exemplet där han heter Beräkning ovan och Service Manager definierar ett anpassat mått på IncidentsPastTargetResolutionTime som följande:
<Measure ID="IncidentsPastTargetResolutionTimeCount" Target="IncidentDW!IncidentDim" Type="Sum" Property="IncidentsPastTargetResolutionTime"/>
Genom att granska den här XML-koden är målet för måttet IncidentDimension och den specifika egenskapen är IncidentsPastTargetResolutionTime. Det här är den anpassade egenskapen som definierades tidigare. Anpassade mått kan riktas antingen mot inbyggda eller beräknade egenskaper i dimensionen.
Slutligen definieras måttypen som en summa. Bland de möjliga värdena för en måttyp är Sum och Count. Prestandaöverväganden gör att Service Manager måtttyperna Distinkt antal inte tillåts. I följande tabell beskrivs måttattributen.
| Attribut | Obligatorisk | Värden | Definition |
|---|---|---|---|
| ID | Ja | Sträng | Namnet på måttet |
| Mål | Yes | ManagementPackDimension | Måldimensionen för måttet |
| Egenskap | Ja | Sträng | Egenskapen för den riktade dimensionen |
| Typ | No | (Antal, Summa) | Typen av mått |
ManyToManyRelationship
Med ManyToManyRelationship kan du, kubdesignern, lägga till anpassade många-till-många-dimensioner i en OLAP-kub för att aktivera avancerade analysscenarier. Att definiera många-till-många-relationer ligger utanför omfånget för det här dokumentet. Du kan dock undersöka detta begrepp och dess fördelar. Mer information om ManyToManyRelationship finns i Många-till-många-revolutionen 2.0.
Under kubdistributionen Service Manager automatiskt många-till-många-dimensioner i kuben för alla "one-hop"-relationer, utan någon interaktion från dig. Men Service Manager lägger inte till många-till-många-dimensioner för sammanhängande relationer (flera hopp) på grund av den exponentiella ökningen av möjliga relationer som kan läggas till. Om du lägger till alla dessa relationer kan prestanda försämras avsevärt medan OLAP-kuben söks igenom. Det beror på att sammansättningar av många-till-många-relationer vanligtvis inte beräknas under bearbetningen och eftersom kopplingarna utvärderas när OLAP-kuben bläddras. Om du vill ha en specifik, sammanhängande många-till-många-relation kan du definiera relationen med ett hanteringspaketelement så läggs den till i OLAP-kuben. På samma sätt kan du skriva över en automatiskt genererad många-till-många-relation för att använda en annan mellanliggande måttgrupp i instanser där det finns flera mellanliggande grupper. I det här Service Manager automatiskt den första gruppen som påträffas. Följande är ett exempel på ett många-till-många-relationselement för hanteringspaket:
<ManyToManyRelationship CubeDimension="ServiceDim" TargetMeasureGroup="AlertAboutConfigItem" IntermediateMeasureGroup="ServiceContainsConfigItem" />
I följande tabell beskrivs attributen för många-till-många-relationen.
| Attribut | Obligatorisk | Värden | Definition |
|---|---|---|---|
| CubeDimension | Ja | Sträng | Namnet på kubdimensionen många-till-många |
| TargetMeasureGroup | Ja | Sträng | Målgruppen för att skapa många-till-många-relationen |
| IntermediateMeasureGroup | Ja | Sträng | Den mellanliggande måttgruppen för att skapa många-till-många-relationen |
KPI
Organisationer och företag kan använda KPI:er (Key Performance Indicators) för att snabbt uppskatta hälsotillståndet för ett företag genom att mäta dess framsteg mot ett fördefinierat mål. Varje KPI har ett målvärde och ett faktiskt värde. Målvärdet är ett kvantitativt värde som är avgörande för att verksamheten ska lyckas. Stora mängder data filtreras till ett diskret värde som kan användas för att övervaka prestanda och framsteg mot mål och jämförelsevärden. Några exempel på KPI:er är ett universitet som har som mål att 90 % av eleverna tar examen inom fyra år eller ett basketteam med målet att få det motsatta teamet att gå mindre än 50 procent för en match. Du kan använda ett styrkort för att visa en grupp med nyckeltal, vilket ger en ögonblicksbild över verksamhetens allmänna hälsotillstånd. Följande är ett exempel på ett KPI:
<KPI ID="IncidentResolutiuonKpi" >
<Caption> The ratio of incidents resolved </Caption>
<Value>IIF(([Measures].[IncidentDimCount])> 0,([Measures].[IncidentsResolvedCount]/[Measures].[IncidentDimCount]),null)</Value>
<Goal>1.0</Goal>
<GreenThreshold> 0.75</GreenThreshold>
<YellowThreshold>0.5 </YellowThreshold>
<Direction>Up</Direction>
<StatusGraphic>Thermometer</StatusGraphic>
</KPI>
I följande tabell beskrivs KPI-attributen.
| Attribut | Obligatorisk | Värden | Definition |
|---|---|---|---|
| ID | Ja | Sträng | Namnet på KPI |
| Caption | Ja | Sträng | Beskrivning på KPI |
| Värde | Ja | Sträng | MDX-skript som definierar det numeriska värdet för KPI:t |
| Mål | Ja | Sträng | Målvärdet för KPI:t |
| Grönt tröskelvärde | Yes | Sträng (mellan 0.1 och 1) | Alla värden ovanför eller under det här tröskelvärdet, beroende på riktning, markeras med grön färg i statussymbolen. |
| Gult tröskelvärde | Yes | Sträng (mellan 0.1 och 1) | Alla värden ovanför eller under det här tröskelvärdet, beroende på riktning, men som inte överensstämmer med gröna tröskelvärdet markeras med gul färg i statussymbolen. Ett värde som inte överensstämmer med det gula tröskelvärdet markeras med röd färg i symbolen för statusen. |
| Riktning | Yes | (Upp, Ned) | Om riktningen är upp markeras alla värden ovanför det gröna eller gula tröskelvärdet med motsvarande symbol. Samma sak gäller om riktningen är nedåt, dvs. värden för det gröna eller gula tröskelvärdet markeras med motsvarande symbol. |
| Grafik för status | Yes | (Former, TrafficLight, RoadSigns, Gauge, ReversedGauge, Termometer, Cylinder, Faces, VarianceArrow) | Symbolen som ska representera KPI:t. |
Åtgärd
Åtgärder är händelser som du kan utlösa på en OLAP-kub när du använder data i kuben. Endast detaljgranskningsåtgärder stöds av Service Manager. Följande är ett exempel på en åtgärd:
<Action ID="DrillThroughOnWICreatedByUser" MeasureGroupName="CreatedByUser" ActionType="DrillThrough">
<DrillThroughColumns CubeDimension="WorkItemCreatedByUser_UserDim">
<Property PropertyName="FirstName" />
<Property PropertyName="LastName" />
<Property PropertyName="Company" />
<Property PropertyName="Department" />
<Property PropertyName="Office" />
</DrillThroughColumns>
</Action>
I följande tabell beskrivs åtgärdsattributen.
| Attribut | Obligatorisk | Värden | Definition |
|---|---|---|---|
| ID | Ja | Sträng | Namnet på detaljgranskningsåtgärden |
| MeasureGroupName | Ja | Sträng | Den riktade måttgruppen för åtgärden |
| ActionType | Yes | (DrillThrough) | Typ av åtgärd. Endast detaljgranskningsåtgärder stöds av Service Manager. |
| CubeDimension | Ja | Sträng | Kubdimensionen som är mål för åtgärden, måste vara ett utsnitt av måttgruppen |
| PropertyName | Ja | Sträng | Attribut för dimensionen som visas när detaljgranskningsåtgärden körs |
CubeExtension
Det huvudsakliga syftet med CubeExtension-elementet är att göra det möjligt att modifiera OLAP-kuben efter att den distribuerats på SSAS, utan att behöva avinstallera och ominstallera den. I situationer där OLAP-kuben har bearbetats fullständigt med årsvis med data, kan det ta lång tid att skapa om kuben eftersom alla partitioner måste bearbetas på nytt helt och hållet.
CubeExtension-elementet kan definiera följande element:
NamedCalculation
ManyToManyRelationship
KPI
Mått
Åtgärd
CustomMdx
Varje anpassning som definierats i ett CubeExtension-element kan också definieras i ett SystemCenterCube-objekt. Den enda anpassning som inte tillåts är att lägga till fakta eller måttgrupper och ersättningar till kuben.
Nästa steg
- Om det behövs felsöker du OLAP-kuber.