Das Unified Dimensional Model (UDM). Eine Einführung.

Das Unified Dimensional Model (UDM). Eine
Einführung.
Autoren: Paul Sanders, Microsoft Corporation
Veröffentlichung: März 2005
Zusammenfassung: Dieses Dokument bietet eine Einführung für das Unified
Dimensional Model (UDM), einschließlich des grundlegenden Endbenutzer-Modells, und
einen kurzen Überblick der Architektur und Sicherheits-Modelle.
Copyright
Dies ist ein vorläufiges Dokument und kann vor der endgültigen kommerziellen Veröffentlichung der hier beschriebenen
Software noch wesentliche Veränderungen erfahren.
Die in diesem Dokument enthaltenen Informationen repräsentieren die augenblickliche Meinung der Microsoft Corporation
zu den diskutierten Themen zum Zeitpunkt der Publikation. Da Microsoft den wechselnden Ansprüchen des Marktes
entsprechen muss, sollte dieses Dokument nicht als eine Haftung seitens Microsoft interpretiert werden, und Microsoft
kann nicht für die Genauigkeit jeglicher gegebener Information nach dem Datum der Veröffentlichung garantieren.
Dieses Whitepaper dient nur der Information. MICROSOFT GIBT KEINE GARANTIEEN, AUSDRÜCKLICHE, ANGEDEUTETE
ODER STATUTARISCHE, DIE DIE INFORMATIONEN IN DIESEM DOKUMENT BETREFFEN.
Es liegt in der Verantwortung des Benutzers, allen maßgeblichen Urheberrechten zu entsprechen. Kein Teil dieses
Dokuments kann reproduziert werden, in einem Verteilersystem gespeichert oder in ein Verteilersystem eingespeist
werden, oder in irgend einer Form auf irgend eine Art übertragen werden (elektronisch, mechanisch, durch Photokopieren,
Aufnehmen oder ähnliches), ohne Urheberrechte zu verletzten und darf nur geschehen mit einer ausdrücklichen
schriftlichen Genehmigung der Microsoft Corporation.
Microsoft kann Patente, Patentanmeldungen, Schutzmarken, Urheberrechte oder andere Rechte geistigen Eigentums
haben, die in diesem Dokument behandelte Gegenstände betreffen. Soweit nicht eine ausdrückliche schriftliche
Lizenzgenehmigung seitens Microsoft vorliegt, gibt die Ausstattung dieses Dokuments Ihnen keinerlei Lizenz über Patente,
Schutzmarken, Urheberrechte oder andere geistige Eigentümer.
 2005 Microsoft Corporation. Alle Rechte vorbehalten.
Microsoft, ActiveX, Visual Basic, Visual C#, Visual Studio, Windows, und Windows Server sind entweder eingetragene
Handelsmarken oder Handelsmarken der Microsoft Corporation in den Vereinigten Staaten und/oder anderen Ländern.
Die Namen hier erwähnter tatsächlicher Unternehmen oder Produkte können Handelsmarken ihrer entsprechenden
Besitzer darstellen.
Inhaltsverzeichnis
Das Unified Dimensional Model (UDM). Eine Einführung. .................................. 1
Copyright .......................................................................................................... 2
Inhaltsverzeichnis ............................................................................................ i
Einführung ........................................................................................................ 1
Grundlegendes Endbenutzermodell .................................................................. 3
Direkter Zugriff auf Datenquellen ..................................................................... 4
Zugriff mittels eines UDM ................................................................................. 6
Über die Grundlagen hinaus .............................................................................. 7
Hierarchien .................................................................................................... 8
Kategorisierung ............................................................................................ 10
Zeitangaben ................................................................................................. 11
Übersetzungen ............................................................................................. 12
Perspektiven ................................................................................................ 12
Attributsemantik ........................................................................................... 13
Key Performance Indicators (KPIs) .................................................................. 13
Leistung .......................................................................................................... 14
Analyse ........................................................................................................... 16
Grundlegende Analyse ................................................................................... 16
Erweiterte Analyse ........................................................................................ 17
Integration mit Data Mining ........................................................................... 18
Der vollendete Kreislauf ................................................................................. 18
Rückschreiben .............................................................................................. 19
Aktionen ...................................................................................................... 19
Architektur ..................................................................................................... 19
Proaktives Zwischenspeichern ........................................................................ 22
Sicherheit ....................................................................................................... 22
Gelieferte Technonolgie .................................................................................. 23
i
Einführung
Ein Endbenutzer, der Informationen direkt von einer Datenquelle – wie z.B. einer ERPDatenbank (Enterprise Resource Planning) - beziehen möchte, sieht sich mit einer
Vielzahl von Herausforderungen konfrontiert:

Die Inhalte solcher Datenquellen sind sehr häufig schwer verständlich, da sie eher
für Systeme und Entwickler entworfen wurden als für Endbenutzer.

Informationen, die für Benutzer von Interesse sind, werden gewöhnlich auf
verschiedene heterogene Datenquellen verteilt. Auch, wenn der Benutzer sich
häufig mit verschiedenen relationalen Datenbanken beschäftigt, muss er die
Einzelheiten jeder Datenbank (den verwendeten SQL-Dialekt beispielsweise)
verstehen. Schlimmer noch, die Datenquellen können aus verschiedenen Arten
bestehen, nicht nur relationalen Datenbanken, sondern auch Dateien und WebDiensten.

Während viele Datenquellen entworfen sind, große Mengen von
Transaktionsebendetails aufzunehmen, bedürfen die Abfragen, die nötig sind, um
geschäftliche Entscheidungen zu treffen, zusammengefasster, aggregierter
Information. Mit wachsenden Datenmengen ist die Zeit, die benötigt wird, um für
eine interaktive Endbenutzeranalyse solche zusammengefassten Werte zu erhalten,
häufig hinderlich.

Die Geschäftsregeln sind generell nicht in den Datenquellen enthalten. Die
Benutzer sind mit der Interpretation der Daten sich selbst überlassen.
1
Die Rolle eines Unified Dimensional Model (UDM) ist es, als Brücke zwischen dem
Benutzer und der Datenquelle zu fungieren. Ein UDM wird für eine oder mehrere
physikalische Datenquellen erstellt, und anschließend gibt der Endbenutzer Abfragen an
das UDM aus, wobei er eine Vielzahl von Client-Werkzeugen benutzt, wie Microsoft Excel
beispielsweise.
ClientWerkzeuge
Datenquellen
Relationale Datenbanken
Dateien
Webdienste
Abbildung 1. Das UDM fungiert als Brücke zwischen Endbenutzer und ihren
Daten (für eine vergrößerte Version auf das Bild klicken)
Im minimalsten Fall, wenn das UDM nur als dünne Schicht über der Datenquelle liegt,
liegen die Vorteile für den Endbenutzer in einem einfacheren, leichter verständlichen
Modell der Daten, einer Abschirmung von heterogenen Datenquellen, und verbesserter
Geschwindigkeit von zusammengefassten Abfragen. In einigen Szenarien wird ein
einfaches UDM wie dieses vollkommen automatisch erstellt. Mit einem höheren Aufwand
beim Erstellen eines UDM entsteht zusätzlicher Nutzen aus einer Fülle von Metadaten,
die das Modell zur Verfügung stellen kann.
Dieses Dokument ist eine Einführung für das UDM. Als erstes wird anhand eines
Beispielszenarios das grundlegende Benutzer-Modell eines UDM gezeigt. Dann werden
einzelne Aspekte eines solchen Szenarios genauer untersucht, um zu zeigen, wie ein
UDM:

Es ermöglicht, ein Benutzer-Modell umfassend zu verbessern.
2
2

Abfragen von hoher Geschwindigkeit ermöglicht, um interaktive Analysen auch
großer Datenmengen zu unterstützen.

Es ermöglicht, dass Geschäftsregeln im Modell erfasst werden, um ergiebigere
Analysen zu unterstützen.

Rückkopplungen unterstützt, wo Benutzer auf die angezeigten Daten reagieren.
Abschließend wird ein kurzer Überblick der Architektur und Sicherheits-Modelle gegeben.
Grundlegendes Endbenutzermodell
Stellen Sie sich das Beispiel eines Endbenutzer vor, der Verkäufe mit Sollvorgaben
verschiedener Zeiträume vergleichen möchte.
Die Verkaufsdaten werden in der Sales- und Inventory-Hauptdatenbank gespeichert, die
natürlich noch andere zahlreiche Tabellen enthält. Selbst nach dem Finden der
relevanten Tabellen stellen wir fest, dass Daten einer einzelnen Einheit, wie Produkt,
über verschiedenste Tabellen verstreut sind, und da referenzielle Integrität von der
Anwendungslogik verstärkt wird, wurden keine Beziehungen zwischen den Tabellen
definiert. Die Sollzahlen sind in der Datenbank einer anderen Anwendung gespeichert.
Keine der Datenbanken hat Geschäftsregeln erfasst, wie z.B. die Tatsache, dass beim
Vergleichen von Sollvorgaben mit tatsächlichen Verkäufen das Auslieferungsdatum
verwendet werden muss, und nicht andere Daten wie etwa das Bestellungsdatum,
Fälligkeitsdatum oder geplantes Lieferdatum.
3
Abbildung 2. Datenquellen, die Sales und Sales Quotas enthalten (für eine
vergrößerte Version auf das Bild klicken)
Direkter Zugriff auf Datenquellen
Betrachten Sie zunächst den Fall, bei dem der Endbenutzer auf die Datenquellen direkt
zugreift. Ein Beispiel einer mit Hilfe eines Beispielwerkzeugs erstellten Abfrage wird in
der folgenden Abbildung veranschaulicht.
Abbildung 3. Die Datenquellen direkt abfragen (für eine vergrößerte Version
auf das Bild klicken)
Bis hier hin haben die Benutzer beachtliche Fortschritte gemacht:

Sie haben eine Vielzahl kryptisch benannter Tabellen durchsiebt, um die von Belang
herauszufinden.

Sie haben die Spalten identifiziert, die zum Verknüpfen der Tabellen verwendet
werden sollen.

Sie haben die Spalten, die interessante Details enthalten, aus einem Meer von
systemorientierten Details gefischt. Zum Beispiel sind unter den elf Spalten der
Tabellen, die Produktkategoriendetails enthalten, nur zwei Namensspalten für den
Benutzer von tatsächlicher Bedeutung.
4
4
Der Benutzer muss nun entscheiden, wo eher äußere oder innere Verknüpfungen
anzuwenden sind, und wie die Details zu gruppieren sind, um die richtigen Aggregate zu
erhalten.
Allerdings kommt das Schlimmste noch. Wie kann der Benutzer Daten aus anderen
Datenquellen einbeziehen? Selbst, wenn eine der Datenbanken verteilte Abfragen
unterstützt, ist den meisten Benutzern nicht möglich, die erforderliche Abfrage zu
entwerfen, und Werkzeuge zieren sich meist, den Benutzer dabei zu unterstützen.
SELECT Quotas.QuotaAmount, Quotas.EmployeeId, ...
FROM OPENROWSET('SQLOLEDB','seattle1';
'Sales';'MyPass',
'SELECT * FROM Forecasts.dbo.SalesQuota' ) As Quotas
Datenquellen wie Web-Dienste stellen eine weitere Hürde für den Benutzer dar; er muss
bestimmen, wie Remoteaufrufe getätigt werden müssen, und den zurückgegebenen
XML-Code bearbeiten, um ihn mit den anderen Daten zu verknüpfen.
Der endgültige Schlag besteht darin, dass die Arbeit, die für eine Abfrage investiert
wurde, ('Anzeigen der Verkäufe und Sollvorgaben nach Kategorien’), für die nächste
Abfrage neu investiert werden muss ('... und jetzt nach Mitarbeitern'), sowie für jede
folgende Abfrage.
5
Zugriff mittels eines UDM
Im Kontrast dazu wird nun gezeigt, wie das Erstellen einer Abfrage seitens des
Benutzers gestaltet ist, wenn er auf ein einfaches UDM zugreift. Die Benutzeroberfläche
stammt aus den von Microsoft SQL Server bereitgestellten Entwicklungs-Werkzeugen.
Sie könnte auch aus anderen Client-Werkzeugen stammen, wie etwa Office Excel oder
Office Web Components (OWC), oder einer Vielzahl von anderen Berichterstellungs- und
Analyse-Werkzeugen, die das UDM unterstützen.
Abbildung 4. Ein einfaches UDM (für eine vergrößerte Version auf das Bild
klicken)
Die Baumansicht links zeigt den Inhalt des UDMs. Beachten Sie, dass:

Nur benutzerorientierte, relevante Elemente gezeigt werden. Die 'Systemspalten' wie
Rowguid oder das letzte Änderungsdatum, sind nicht sichtbar.

Die verwendeten Namen bekannte Namen sind und nicht von den
entwicklerorientierten Benennungskonventionen der zu Grunde liegenden Datenbank
stammen.
Das UDM gruppiert auch alle Attribute jeder Geschäftseinheit (wie Product oder
Employee) in separate 'Dimensionen'. Der Benutzer kann sich so auf Product Color,
Subcategory, und Category in diesem Beispiel beziehen, ohne Verbindungen zwischen
den vielen beteiligten Tabellen herstellen zu müssen.
Die Spalten, die Transaktionswerte oder Messungen darstellen, die ein Benutzer
üblicherweise für die Aggregation benötigt, wie z. B. Sales Amount oder Quota, werden
dann als Measures dargestellt. Die Methode, Daten als Measures und Dimensionen
darzustellen, wird als Dimensionsmodellierung bezeichnet, und hat sich in der Branche
als ein erfolgreiches Modell für die Endbenutzerverständlichkeit bewährt.
6
6
Die rechte Seite des Diagramms zeigt die in der aktuellen Abfrage enthaltenen
Elemente. In diesem Fall erstellte der Benutzer die Abfrage 'Verkäufe und Sollvorgaben
nach Produktkategorie' einfach, indem er die drei relevanten Elemente aus der
Baumansicht zog. Es war nicht nötig, dass der Benutzer die für den Zugriff auf die zwei
verschiedenen Datenquellen benötigten Details angab, und die nötigen Verknüpfungen
zwischen den betroffenen Tabellen herstellte.
Das Modell erstellt die einfache zu verwendende Formatierung durch Voreinstellung (wie
den Gebrauch von Währungszeichen). Eine reichhaltigere Formatierung, in der bedingte
Formatierung enthalten ist, kann auch definiert werden, (so kann beispielsweise ein
Wert, der unterhalb eines bestimmten Schwellenwertes liegt, rot dargestellt werden).
Das selbe Modell unterstützt eine Vielzahl von Abfragen. So können Zahlen
beispielsweise nach Mitarbeitern eingeteilt werden, indem ein Attribut aus der
Mitarbeiterdimension gezogen wird.
Über die Grundlagen hinaus
Während das vorhergegangene Beispiel zeigte, wie auch ein einfaches UDM das
grundlegende Untersuchen von Daten erheblich vereinfachen kann, so gibt es doch
weitere Probleme beim Bereitstellen von Daten für den Endbenutzer. Beispiele:

Ein UDM, das viele verschiedene Abfragetypen von verschiedenen Nutzern
unterstützt, kann beachtlich groß werden. Wie können wir absichern, dass ein
Nutzer, der bestimmte Daten benötigt, nicht von unwichtigen Informationen
überwältigt wird?

Wie kommen wir dem Wunsch weltweiter Nutzer, Berichte in ihrer Muttersprache
einzusehen, entgegen?

Wie können wir die Fragestellungen nach verschiedenen Zeiträumen vereinfachen?
(beispielsweise, 'zeige die Verkäufe im Vergleich zum selben Zeitraum letztes Jahr').
Dieser Abschnitt untersucht einige der Fragen, um zu zeigen, wie das UDM erweiterte
Datenuntersuchungen unterstützt.
7
Hierarchien
Wenn auch die Konsolidierung aller Attribute einer Einheit in eine Dimension das Modell
erheblich benutzerfreundlicher gestaltet, so gibt es doch zusätzliche Verbindungen, die
durch eine einfache Liste nicht ausgedrückt werden können. Im vorherigen Beispiel
wurde mit den Category-, SubCategory- und SKU-Ebenen eine der Hierarchien erstellt,
in denen Produkte organisiert werden können. Da Benutzer häufig auf solchen
Hierarchien basierende Analysen ausführen wollen, beispielsweise das Anzeigen der
Summen auf Category-Ebene, dann per Drilldown auf die Sub-Category-Ebene und
schließlich zur untersten SKU-Ebene, ermöglicht das UDM die Definition solcher
Hierarchien. Jede Hierarchie stellt lediglich eine Sequenz von Attributen dar, die für
Abfragen verwendet werden können, um solche Drilldown- und Drill-Up-Szenarien zu
erleichtern.
Im Folgenden findet sich ein Beispiel dafür, wie Hierarchien in einer
Endbenutzeroberfläche angezeigt werden können. Das Modell enthält verschiedene
Hierarchien, in denen Produkte organisiert sind. Die Abfrage ('zeige Verkäufe und
Sollvorgaben nach Produktkategorie, dann nach Unterkategorie') wurde einfach durch
das Ziehen der Products By Category-Hierarchie erstellt, und durch Doppelklicken die
Bike-Kategorie erweitert, um detailliertere Informationen einzusehen.
Abbildung 5. Ein UDM mit Hierarchien (für eine vergrößerte Version auf das Bild
klicken)
8
8
Das UDM erledigt das Navigieren zwischen den Hierarchie-Ebenen und kümmert sich,
wie in diesem Fall, darum, dass Sollvorgaben nicht auf der SubCategory-Ebene, sondern
nur auf der Category-Ebene verfügbar sind.
Eine besondere Art der Hierarchie ist die Eltern-Kind- Hierarchie, in der Einheiten
enthalten sind, die verwickelte Beziehungen zu sich selbst haben. In der nächsten
Abbildung ist Employee-Dimension mit der Hierarchie Employees By Organization
Structure versehen. Der Gebrauch dieser Hierarchie ermöglicht einfaches Navigieren
durch die Eltern-Kind-Beziehung und eine Analyse der aufgezeigten Werte. Die
Sollvorgabe für den Verkaufsleiter Charles Marshall beinhaltet die Summe aller
Sollvorgaben seiner Mitarbeiter, sowie aller Sollvorgaben, die ihm direkt zugeordnet
sind.
Abbildung 6. Eine Eltern-Kind-Hierarchie (für eine vergrößerte Version auf das
Bild klicken)
9
Kategorisierung
Es ist üblich, dass Nutzer ihren Daten Kategorisierungen zuweisen. Beispiel: 'Diese
Attribute beinhalten alle persönliche Details eines Mitarbeiters; jenes Attribut beinhaltet
eine E-Mail-Adresse'. Das UDM stellt zwei Mechanismen zu Verfügung, die speziell dafür
gemacht sind, es den Endbenutzer-Werkzeugen zu ermöglichen, einen Mehrwert,
basierend auf den Kategorisierungen, beizusteuern, sowie den Bedeutungen der
präsentierten Daten:

Dimensionen, Attribute und andere Objekte können in semantisch aussagekräftige
Kategorien gefasst werden, die ein intelligenteres Vorhegen innerhalb eines ClientWerkzeugs ermöglichen. So kann ein Attribut beispielsweise als URL markiert
werden, worauf hin der Bericht das Navigieren auf Basis der URL ermöglicht. Ein
anderes Attribut kann als E-Mail-Adresse markiert werden, womit ein Berichtersteller
automatisch eine neue E-Mail für eine bestimmte Benutzeraktion öffnen kann.

Measures, Hierarchien und andere Objekte können in für den Benutzer
aussagekräftige Ordner gruppiert werden, was es dem Berichterstellungs-Werkzeug
ermöglicht, eine große Anzahl von Attributen auf überschaubare Art darzustellen. So
kann es beispielsweise eine Gruppe von Attributen 'Kunden\Demographie' geben.
10
10
Zeitangaben
Zeitangaben werden gewöhnlich in der zu Grunde liegenden Datenquelle einfach durch
die Verwendung von DataTime- oder Date-Datentypen erfasst. Während Benutzer mit
SQL-Erfahrung (oder mit Erfahrungen in XPath im Zusammenhang mit Webdiensten) die
benötigten Teile (wie beispielsweise die Summe von Daten pro Jahr) extrahieren
können, ist es sehr schwierig, Fragen auf Basis anderer Zeitangaben zu stellen, wie z. B.
Anzeigen von Verkäufen nach Tagen oder Wochen oder Anzeigen nach Geschäftsjahr,
beginnend am 1. Juli.
Das UDM aber verfügt über eingebaute Zeitangaben, einschließlich verschiedener
Kalender:

regulärer Kalender

Geschäftskalender

Berichtskalender ('445' usw.)

Produktionskalender (13 Zeiträume)

ISO8601-Kalender
Auf diese Art kann das Modell eine Zeitdimension beinhalten, die eine reichhaltige
Anzahl von Attributen bietet, um die Details eines jeden Tages zu definieren. Im
folgenden Beispiel entschied sich der Benutzer, die Verkäufe und Sollvorgaben des
Geschäftsjahrs 2001 einzusehen. Es müssen nur die relevanten Elemente aus dem Baum
in den Filterbereich gezogen werden. Einerseits kann das UDM die Auswahl in einen
Datumsbereich übersetzen, andererseits kennt es die Geschäftsregel, dass es die zu
diesem Datum ausgelieferten Bestellungen in die Abfrage aufzunehmen hat, und nicht
die fälligen oder bestellten. Natürlich kann das Fälligkeitsdatum, wenn relevant, in die
Abfrage eingeschlossen werden. Die richtige Verknüpfung wird implizit vom UDM erstellt.
11
Abbildung 7. Ein UDM für Zeitangaben (für eine vergrößerte Version auf das
Bild klicken)
Weiterhin bietet das UDM spezielle Unterstützung für die Beantwortung häufig gestellter
zeitbezogener Fragen (wie z.B. der Vergleich von Zeiträumen — 'Vergleiche diesen
Monat mit dem selben Monat im letzten Jahr ').
Übersetzungen
In den vorhergegangenen Beispielen wurden sowohl die Inhalte der Modelle als auch die
Daten in englisch angezeigt. Wäre das die einzige Möglichkeit, stellte es ein Problem dar
für Organisationen mit internationalen Nutzern.
Deshalb ermöglich es das UDM, dass Metadaten in jeder beliebigen Sprache zur
Verfügung gestellt werden können. Ein Client, der mittels eines bestimmten
Gebietsschemas eine Verbindung herstellt, sähe dann die Metadaten in der
entsprechenden Sprache.
Weiterhin kann das Modell Übersetzungen der Daten liefern. Ein Attribut kann
verschiedenen Elementen in der Datenquelle zugeordnet werden und so die
Übersetzungen in Verschiedenen Sprachen ermöglichen. Wenn beispielsweise mit Hilfe
des in den vorherigen Beispielen verwendeten Werkzeugs die Verbindung von einem
französischen Client herstellt wird, werden das UDM und die Abfrageergebnisse, wie im
unteren Beispiel dargestellt, in Französisch angezeigt.
Abbildung 8. Das UDM in den Augen eines französischen Benutzers (für eine
vergrößerte Version auf das Bild klicken)
Perspektiven
Während das hier verwendete Beispiel-Modell von eher bescheidener Größe ist, können
in der Praxis Modelle von weit größerem Umfang definiert werden, die Dutzende von
Measures und Dimensionen enthalten können, wobei jede Dimension wiederum
Dutzende oder Hunderte von Attributen enthält. Im Allgemeinen ist es jedoch für
Benutzer, die eine bestimmte Aufgabe ausführen, nicht nötig, dass sie das gesamte
Modell einsehen. Es ist nötig, dass spezielle Sichten des gesamten Modells definiert
werden können, damit Benutzer nicht von seiner Größe überwältigt werden.
12
12
Das UDM stellt diese Ansichten durch Perspektiven zur Verfügung. Ein UDM kann eine
Vielzahl von Perspektiven haben, von denen jede einzelne nur den bestimmten Teil des
Modells zeigt (Measures, Dimensionen, Attribute u.s.w.) der für eine bestimmte Gruppe
von Benutzern von Relevanz ist. Die einzelnen Perspektiven können dann den
Benutzersicherheitsrollen zugeordnet werden, die jene Benutzer, die diese Perspektive
einsehen dürfen, definieren.
So kann beispielsweise eine 'Seattle Inventory'-Perspektive definiert werden, die nur
Measures der Inventory-Measure-Gruppe enthält und die 'Warehouse By Location'Hierarchie verbirgt und Seattle als Standard für City erklärt.
Attributsemantik
Ein UDM stellt für jedes Attribut zusätzliche Semantik bereit, die darauf ausgerichtet ist,
Informationen optimiert zur Verfügung zu stellen. Im Folgenden einige Beispiele:
Namen kontra Schlüssel: Wenn man eine relationale Datenbank betrachtet, ist es
nicht sofort ersichtlich, dass es sich bei EmployeeID um einen bedeutungslosen,
eindeutigen, vom System erstellten Schlüssel handelt. Das UDM aber ermöglicht beim
Attribut Empoyee sowohl die Verwendung eines Schlüssels (die eindeutige EmlpoyeeID),
als auch eines Namens (in diesem Fall die Verkettung von FirstName und LastName). Mit
einer Abfrage, z. B. Anzeigen der Mitarbeiter, werden nun Mitarbeiter mit demselben
Namen ordnungsgemäß unterschieden. Dem Benutzer wird jedoch der aussagekräftige
Name angezeigt.

Sortierung: Es ist manchmal der Fall, dass die Werte von Attributen in einer festen
Reihenfolge angezeigt werden müssen, die nicht in einer einfachen alphabetischen
oder numerischen Reihenfolge besteht. Beispiele:

Die Wochentage werden als 'Sonntag', 'Montag', 'Dienstag' u.s.w. dargestellt.

Prioritäten werden dargestellt als 'Hoch', 'Mittel’, 'Niedrig'.
Das UDM ermöglicht es, Standardreihenfolgen zu definieren, die dem Rechnung
tragen.

Diskretisierung: Bei numerischen Attributen ist das Anzeigen jedes einzelnen
Attributwertes häufig nicht sinnvoll. Beispielsweise ist das Anzeigen Hunderter
verschiedener Preise bei der Abfrage 'Sales by Product Price', ( $9.97, $10.05,
$10.10,...) weniger sinnvoll als die anzeige der Verkäufe nach Preisbereich ( <$10,
$10 - $15,...). Das UDM ermöglicht die Diskretisierung von Attributen in solche
Bereiche mit Hilfe unterschiedlicher Kriterien.
Key Performance Indicators (KPIs)
In vielen Fällen definieren Unternehmen Key Performance Indicators (KPIs), die wichtige
Metriken zur Messung der Geschäftsintegrität darstellen. Das UDM ermöglicht das
Definieren solcher KPIs, die für eine weitaus verständlichere Gruppierung und
Darstellung von Daten sorgen.
Jeder KPI eines UDMs definiert bis zu vier Ausdrücke für bestimmte Leistungsmetriken,
z. B. Sales-Ebene:
13

Der tatsächliche Wert.

Der Zielwert.

Der Status. Ein normalisierter Wert zwischen -1 und 1, der den Status zwischen dem
tatsächlichen Wert und dem Zielwert anzeigt (-1 steht für 'sehr schlecht', 1 steht für
'sehr gut').

Der Verlauf. Ein normalisierter Wert zwischen -1 und 1, der den Verlauf über einen
Zeitraum darstellt (-1 steht für 'wird sehr schlecht', 1 steht für 'wird sehr gut').
Zusätzlich kann ein KPI eine empfohlene Graphik definieren, wie die einer Ampel, um
Status und Verläufe wie 'gut, durchschnittlich, schlecht' anzuzeigen.
Die Verwendung von KPIs erlaubt es Client-Werkzeugen, verwandte Measures in einer
Art anzuzeigen, die dem Benutzer das Verständnis sehr erleichtert. Die untere Abbildung
zeigt, wie drei KPIs, die in Anzeigeordnern geordnet sind, von einem Client-Werkzeug
angezeigt werden können.
Abbildung 9. KPIs (für eine vergrößerte Version auf das Bild klicken)
Leistung
Das interaktive Durchsuchen seitens des Endbenutzers erfordert schnelle Antwortzeiten.
Aufgrund sehr großer Datenmengen, die häufig untersucht werden müssen, stellt die
Geschwindigkeit ein Problem dar.
Um die Leistung zu verbessern, stellt das UDM Dienste zum Zwischenspeichern bereit.
Es werden potentiell sowohl die aus der zu Grunde liegenden Datenbank gelesenen
detaillierten Daten zwischengespeichert, als auch im Voraus aus diesen Daten
berechnete aggregierte Werte. Die Verwendung zwischengespeicherter Werte kann
jedoch einen gewissen Grad von „Abgestandenheit“ der Daten bedeuten. Die Umstände
in Unternehmen diktieren, wie aktuell die Informationen sein müssen. Es kann wichtig
sein, dass manche Daten jeder Zeit mit den aktuellsten Zahlen angezeigt werden,
während es für die Zahlen anderer Daten ausreichend ist, wenn sie zwei Stunden, zwei
Tage oder drei Tage alt sind.
14
14
Um diesem Umstand zu entsprechen, bietet das UDM zwei Möglichkeiten: die explizite
Verwaltung des Zwischenspeichers (beispielsweise kann ein Plan definiert werden, um
den Zwischenspeicher täglich um zwei Uhr nachts zu aktualisieren), oder die
transparente Verwaltung durch 'proaktives Zwischenspeichern'. Der Benutzer kann hier
bestimmen, wie aktuell die Daten sein müssen (einschließlich der Möglichkeit, sie jeder
Zeit aktuell zu halten), und das UDM liefert eine automatische Erstellung und Verwaltung
des Zwischenspeichers, um eine schnellstmögliche Abfragebeantwortung zu bieten,
wobei die Richtlinien zur Steuerung des Datenflusses widergespiegelt werden.
15
Analyse
In den vorigen Abschnitten wurde behandelt, wie das UDM das interaktive Durchsuchen
von Daten unterstützt. Es ist jedoch nicht ausreichend, die Informationen aus den
zugrunde liegenden Datenquellen einfach zur Verfügung zu stellen, selbst in
verständlicher und einfach verwendbarer Form, wenn in den Benutzermodellen
bedeutende Geschäftslogik enthalten sein soll.
Deshalb bietet das UDM die Möglichkeit, sowohl einfache, als auch komplexe
Berechnungen der Daten zu definieren.
Grundlegende Analyse
Am Ende einer einfachen Abfrage stehen für gewöhnlich aggregierte Daten ('zeige die
Verkäufe nach Kategorie', und nicht 'zeige jede einzelne Verkaufsauftragszeile'). Wie
aber verschiedene Measures aggregieren? Beispielsweise findet sich nichts in den zu
Grunde liegenden relationalen Daten, das besagt, dass es zwar Sinn macht, 'Sales
Amount' zu summieren, von 'Unit Price' aber der Durchschnitt errechnet werden sollte.
Das UDM liefert diese Semantik. Die Aggregationsmethode kann anhand einer Vielzahl
von Schemas definiert werden:

Es kann eine einfache Aggregationsfunktion, bestehend aus Sum, Count, Distinct
Count, Max oder Min verwendet werden.

Die Aggregation kann als semi-additiv definiert werden. Hierbei wird eine einfache
Funktion wie 'Sum' für alle Dimensionen außer der Zeitdimension definiert, für die
'Last period' verwendet wird. Während beispielsweise die Inventory-Ebene pro
Produkt-Kategorie summiert werden kann, stellt die Summe der Inventory-Ebenen
eines jeden Tages nicht die Inventory-Ebene eines Monats dar; die Inventory-Ebene
eines Monats wird dargetsellt durch die Inventory-Ebene des letzten Tages im Monat.

Die Aggregation kann auf dem Kontentyp basieren, beispielsweise Income kontra
Expense.

Die Aggregation kann benutzerdefiniert gestaltet werden, um jedem Anspruch
gerecht zu werden.
Ein UDM kann auch berechnete Elemente enthalten. Diese Elemente stehen in keiner
direkten Verbindung zu den Quelldaten, sondern sind von den Daten abgeleitet. So kann
z.B. ein berechnetes Element, Variance, definiert werden, um die Differenz zwischen
'Sales' and 'Quota' zu errechnen.
Auf ähnliche Art kann ein UDM Einheiten definieren, die für den Benutzer von Interesse
sind, wie die zehn besten Kunden etwa (nach Verkaufsvolumen), oder die wichtigsten
Produkte. Diese Gruppen können dann einfach zur Beschränkung des Umfangs einer
Abfrage auf die Einheiten verwendet werden.
16
16
Erweiterte Analyse
Selbst bei der Betrachtung des einfachen Beispiels, das hier dargestellt wird, ist es
schnell ersichtlich, dass die für Benutzer erforderlichen Berechnungen weit über das
einfache Variance-Beispiel hinausgehen. Beispiel:

'Zeige den Durchschnitt der herausragendsten 3 Monate für jeden Zeitraum'

'Im welchem Verhältnis steht der Jahreszuwachs des laufenden Jahres im Vergleich
zum gleichen Zeitraum im letzten Jahr?'

'Verkäufe werden in der Basiswährung berichtet. Rückkonvertieren der Verkäufe in
die ursprüngliche Währung mit Hilfe des zum Zeitpunkt des Verkaufs gültigen
durchschnittlichen Wechselkurses.'

'Berechnen der im Haushaltsplan vorgesehen Verkäufe nach Kategorien für folgendes
Jahr mit zusätzlichen 10 % im Vergleich zum laufenden Jahr sowie Zuordnen dieser
Verkäufe zu jedem Produkt auf Basis der relativen Durchschnittsverkäufe der letzten
3 Jahre.
Das UDM bietet ein reiches Modell für die Definition solcher Berechnungen. Es ähnelt
einem mehrdimensionalen Arbeitsblatt, in dem der Wert einer Zelle (z.B. AverageSales
für die Kategorie 'Bike' im Jahr '2003'), basierend auf dem Wert anderer Zellen
berechnet werden kann. Aber auch dieses Beispiel kann Berechnungen im UDM nicht
genau beschreiben. Das liegt teilweise daran, dass der Inhalt einer Zelle nicht nur auf
dem Wert einer anderen Zelle berechnet wird, sondern auch basierend darauf, was der
Wert dort darstellte. Daher können gleichzeitige Formeln unterstützt werden; so wird der
Gewinn aus Einnahmen minus Ausgaben abgeleitet, aber der (in den Ausgaben
enthaltene) Bonus hingegen wird vom Gewinn abgeleitet.
Neben der leistungsstarken MDX-Sprache (Multi Dimensional Expressions), die genau für
den Entwurf solcher Berechnungen geschaffen wurde, unterstützt das UDM Integration
mit .Net. Diese Integration ermöglicht es, dass gespeicherte Prozeduren und Funktionen
in jeder überprüfbaren .NET-Sprache (wie C#.NET oder Visual Basic.NET) geschrieben,
und anschließend von MDX für die Berechnungen aufgerufen werden.
Der Client ist von den Details solcher Berechnungen selbstverständlich abgeschottet. Für
Clientanwendungen verfügt das Modell nun einfach über eine größere Anzahl von
nützlichen Measures. Im unteren Beispiel sieht der Benutzer verschiedene berechnete
Measures, die, basierend auf Verkäufen, die profitabelsten in den USA verkauften
Produkte anzeigen.
17
Abbildung 10. Ein UDM, das Analyse einbezieht (für eine vergrößerte Version
auf das Bild klicken)
Integration mit Data Mining
Das Anzeigen von Daten in reicher, leicht verständlicher Form ist extrem nützlich; aber
wie sieht es damit aus, Informationen aus diesen Daten zu beziehen?
Das UDM ist eng mit der Data Mining-Technologie integriert, um Data Mining zu
ermöglichen und die ermittelten Muster dann für Vorhersagen zu nutzen.
Der vollendete Kreislauf
Die Einsicht von Daten führt beim Benutzer häufig zu weitergehenden Fragen, oder zu
dem Bedürfnis, zu handeln. Beispiele:

'Welche Verkäufe genau fließen in diese Zahl mit ein?'

'Diese Sollvorgabe ist zu niedrig – ich muss sie erhöhen.'

'Das sieht seltsam aus – ich möchte diese Zahl mit einem Kommentar versehen.'

'Welche Einzelheiten zu dieser Promotion stehen auf unserer Web-Site?'
Deshalb ist es nicht ausreichend, die Daten dem Benutzer in leicht verständlicher Art zu
präsentieren. Es ist nötig, dem Benutzer ein Handeln auf Grund der eingesehenen Daten
zu ermöglichen.
Das UDM unterstützt den Benutzer hier auf zwei Arten:

Es werden Änderungen der Daten ermöglicht.

Es werden Aktionen zu den Daten ermöglicht.
18
18
Rückschreiben
Das UDM ist nicht schreibgeschützt. Weiterhin ist es möglich, die Daten mittels des UDM
zu aktualisieren. Bei Measures können die Aktualisierungen separat von den
ursprünglichen Werten, als Delta-Werte für diese Werte, durchgeführt werden.
Zusätzlich ist es möglich, zusammengefasste Zahlen zu aktualisieren. Es soll hierzu ein
Budgetierungs-Szenario betrachtet werden: Während die Höhe der budgetierten Summe
schon bis zur einer detaillierten Ebene hinab bekannt sein kann (wie einem Team oder
Konto), könnten die Werte erst auf einer zusammengefassten Ebene (Abteilung oder
Kontotyp) ersichtlich sein.
Aktionen
Das UDM unterstützt Aktionen, die eine Verbindung zwischen den Daten und auf Grund
der Daten ausgeführter Handlungen darstellen. Die wichtigsten Aktions-Arten:

URL: Öffnet eine bestimmte URL. Es wird sowohl das Navigieren zu einer
bestimmten URL zwecks Einholens weiterer Informationen unterstützt, als auch das
Navigieren zu einer webbasierten Anwendung, um eine Aufgabe auszuführen.
Beispiele:

Für ein Produkt: Öffnen der Firmen-Web-Site, auf der das Produkt beschrieben
ist.

Für eine Kombination Produkt/Lager: Öffnen einer Webbasierten Anwendung zur
Lagerverwaltung, wobei die Produkt/Lager-Kombination als Parameter
weitergegeben wird, um den um den Sicherheitsstand zu erhöhen.

Berichterstellung: Ausführen eines bestimmten Berichts. So kann diese Aktion
beispielsweise für ein Produkt einen parametrisierten Produktbericht ausführen, in
dem das Produkt und der aktuelle Bestellstatus beschrieben werden.

DrillThrough: Ausführen eines Drillthrough zur niedrigst möglichen Detail-Ebene.
Ein Benutzer, der die Summe aller Verkäufe nach Produkt und Kunden untersucht,
kann so beispielsweise alle Verkaufstransaktionen, die zu dieser Summe beitragen,
per Drillthroug anzeigen.
Die Aktionen können mit bestimmten Datenregionen verknüpft werden. Zum Beispiel
kann eine Aktion, die das Navigieren zu einer Webseite ermöglicht, jedem Produkt
zugeordnet werden. Die Aktion zum Anzeigen der detaillierten
Bestandsübertragungsaktionen wird aber für jeden Wert der Quantity-Daten je nach
Produkt und Lager angewendet.
Während die Aktionen Teil des UDM sind, sorgt die Clientanwendung dafür, dass die
anwendbaren Details der Aktion abgerufen und dem Benutzer zu Verfügung gestellt
werden, und dann die Aktion nach Bedarf gestartet wird.
Architektur
Während der vorhergegangene Teil sich auf das Endbenutzer-Modell konzentrierte, soll
dieser Teil kurz die Architektur und APIs behandeln.
19
Ein UDM wird für eine oder mehrere Datenquellen definiert. Diese Datenquellen können
verschiedener Art sein, einschließlich:

Relationale Datenbanken

Web-Dienste

Dateien
Obwohl ein bestimmter Satz von Datenquellen unterstützt wird, können Cartridges von
Dritten als zusätzliche Datenquellen verwenden.
Client-Werkzeuge haben Datenzugriff über das UDM (allgemeine Berichterstellung und
OLAP-Clients wie auch Benutzeranwendungen). Die Client-API ist die bekannte
Standard-XML/A, ein SOAP-basiertes Protokoll für die Ausgabe von Befehlen und das
Empfangen von Antworten, dargestellt als Web-Dienst. Zusätzlich werden über XML/A
Client-Objektmodelle geliefert, die sowohl einen verwalteten Provider (ADO MD.Net), als
auch einen systemeigenen OLE DB-Provider beinhalten.
Abfragebefehle können in SQL oder MDX (Multi-dimensional Expressions, eine
Abfragesprache nach Industrienorm, die analyseorientiert ist) ausgegeben werden.
20
20
Der 'UDM-Server' ist Microsoft Analysis Services.
ClientWerkzeuge
Datenquellen
Relationale DB
XML/SQLAbfragen
ADO MD.NET/
OLE DB für
OLAP
Beispielabfrage:
SELECT
{Measures Sales} on Columns
Top10ProuctsByProfabiloty on Rows
From Sales
Dateien
Web-Dienste
Abbildung 11. Die UDM-Architektur (für eine vergrößerte Version auf das Bild
klicken)
Da die Client-Schnittstellen des UDM kompatibel sind mit dem existierenden Analysis
Services-Produkt in SQL Server 2000, gibt es zahlreiche Client-Werkzeuge, die bereits
jetzt schon mit dem UDM arbeiten können, wie:

Office 10-Werkzeuge (Excel und Office Web-Komponenten)

Zahlreiche externe Werkzeuge zur Analyse und Berichterstellung (wie ProClarity und
Crystal Reports)

SQL Server Reporting Services
Zusätzlich wird das Microsoft Reporting Services-Produkt, das mit dem nächsten SQL
Server erscheint, auch mit dem UDM arbeiten.
UDMs können mit der selben XML/A-Schnittstelle erstellt und verwaltet werden. Ein
entsprechendes Objekt-Modell AMO (Analysis Management Objects) unterstützt solche
Verwaltungs-Operationen. Die Veröffentlichung von SQL Server wird einen reichhaltigen
Satz von Entwicklungs-Werkzeugen für den Bau eines UDM enthalten. Dennoch bleibt
der Entwurf komplexerer Modelle Datenbankadministratoren und Power-Usern und –
Analytikern vorbehalten. In anderen Szenarien kann ein reduziertes, einfaches UDM
ohne Zutun des Benutzers über einer Datenquelle erstellt werden.
21
Proaktives Zwischenspeichern
Beim proaktiven Zwischenspeichern werden an das UDM ausgegebene Abfragen
beantwortet durch Abfragen der neuesten Daten in der Datenquelle. Währenddessen
wird in Zwischenspeicher mit den Daten und den aggregierten Daten gebildet, und bis
zur Fertigstellung werden nachfolgende Abfragen wesentlich schneller aus dem
Zwischenspeicher beantwortet. Bei Änderung der Daten oder Überschreiten der
Wartezeit wird der Zwischenspeicher verworfen, Abfragen wieder an die Datenquelle
ausgegeben und ein neuer Zwischenspeicher wird errichtet.
Sicherheit
Der Zugriff auf ein UDM kann kontrolliert werden. Dieses Dokument bietet nur einen
kurzen Überblick über dieses wichtige Thema.
Die Schlüssel-Features für Sicherheit:

Das UDM bietet rollenbasierte Sicherheit. Rollen (beispielsweise 'Regional analyst')
können definiert werden, den Rollen können Berechtigungen erteilt werden, und
Benutzer können als Mitglieder einer Rolle zugeteilt werden. Die tatsächlichen
Berechtigungen eines Benutzers stellen eine Vereinigung aller Berechtigungen einer
jeden Rolle dar, zu der ein Benutzer gehört. Die Berechtigungen einer Rolle können
auch Zugriffsverweigerungen definieren, wobei Rechte aufgehoben werden
unbeachtet anderer Rollen, denen Benutzer angehören mag.

Administrative Berechtigungen (beispielsweise das Ändern eines UDMs) können
unabhängig von Datenzugriffsberechtigungen erteilt werden. Auch können einzelne
Berechtigungen für folgende Aktionen definiert werden:

Die Metadaten eines Objekts lesen;

Zugriff (Lese-/Schreibzugriff) auf die Daten.

Daten können auf einer präzisen Granularitätsebene gesichert werden, bis hin zu
einzelnen Zellen (z.B. Verkäufe des Produkts 'Widget' an den Kunden 'ACME').
Sicherheit kann auch bedingt sein. Einer Rolle kann erlaubt sein, die Gehälter einer
gesamten Abteilung nur dann einzusehen, wenn diese Abteilung mehr als fünf
Mitarbeiter hat.

Die Berechtigungen können definieren, ob sichtbare Summen verwendet werden
sollen, in welchem Fall die Summen nur die niedrigeren Ebenen-Elemente
wiedergeben, für die der Benutzer eine Berechtigung hat. Der Zugriff auf Zellen kann
auch beschränkt werden. In diesem Fall können Zellen nur eingesehen werden, wenn
die Zellen, von denen sie abgeleitet sind (so wie das Ableiten des Gewinns von
Einnahmen und Ausgaben) auch eingesehen werden können.
22
22
Gelieferte Technonolgie
Die Technologie, die das UDM unterstützt, wird mit SQL Server ausgeliefert. Die
Veröffentlichung wird folgendes beinhalten:

Ein Server-Produkt, das als NT-Dienst läuft und einen Web-Dienst liefert, der das
Entwerfen, Verwalten und Abfragen eines UDMs ermöglicht.

Eine DLL, die viele der Dienste des NT-Dienstes auch ermöglicht, einschließlich
erstellen und abfragen eines UDMs. Das erlaubt das Einbetten der Technologie in
andere Produkte. Ein Beispiel dafür sei, dass SQL Server Reporting Services diese
Funktionalität nutzen wird, um Berichte als Datenquellen darzustellen. In Folge
dessen wird dynamisch ein UDM erstellt werden, um die Daten einer Vielzahl von
Client-Abfrage- und Analyse-Werkzeugen des Serverprodukts zur Verfügung zu
stellen.
Die APIs sind eine Weiterentwicklung der in der Analysis Services-Komponente von SQL
Server 2000 verwendeten. Als solche sind viele Microsoft- und externe Client-Werkzeuge
bereits UDM-fähig.
23