Unified Dimensional Model (UDM)

Ein Benutzer, der Informationen direkt aus einer Datenquelle abrufen möchte, wie z. B. aus einer ERP-Datenbank (Enterprise Resource Planning), steht mehreren bedeutenden Herausforderungen gegenüber:

• Die Inhalte solcher Datenquellen sind häufig schwer verständlich, da sie für Systeme und Entwickler entwickelt wurden, ohne dabei die Anforderungen des Benutzers zu berücksichtigen.
• Die vom Benutzer benötigten Informationen werden häufig auf mehrere heterogene Datenquellen verteilt. Auch wenn verschiedene relationale Datenbanken verwendet werden, muss der Benutzer die Einzelheiten jeder Datenbank, wie z. B. den verwendeten SQL-Dialekt, verstehen. Umso schwieriger wird es für den Benutzer, wenn diese Datenquellen unterschiedlichster Arten sind, die neben relationalen Datenbanken auch Dateien und Webdienste beinhalten.
• Während viele Datenquellen so ausgerichtet sind, dass sie große Mengen an Transaktionsebenendetails aufnehmen, schließen die zur Unterstützung von Geschäftsentscheidungen durchgeführten Abfragen in vielen Fällen zusammengefasste, aggregierte Informationen ein. Bei sehr großen Datenmengen kann die zum Abrufen solcher zusammengefasster Werte für die interaktive Endbenutzeranalyse erforderliche Zeit ein Hindernis darstellen.
• Die Geschäftsregeln sind im Allgemeinen nicht in den Datenquellen gekapselt. Die Benutzer müssen daher die Daten selbst interpretieren.

Die Rolle eines UDM (Unified Dimensional Model) besteht darin, eine Brücke zwischen dem Benutzer und den Datenquellen bereitzustellen. Ein UDM wird aus mindestens einer physikalischen Datenquelle hergeleitet. Der Benutzer gibt Abfragen für das UDM mithilfe einer Vielzahl von Clienttools wie Microsoft Excel aus.

Es ergeben sich Vorteile für den Endbenutzer, auch wenn das UDM nur als minimale Schicht über der Datenquelle erstellt wird: ein einfacheres, verständlicheres Modell der Daten, das Isolieren heterogener Back-End-Datenquellen sowie Leistungsverbesserungen bei zusammengefassten Abfragen. In einigen Szenarien kann ein einfaches UDM automatisch erstellt werden. Durch zunehmende Investitionen in der Erstellung des UDMs können sich zusätzliche Vorteile aus umfangreicheren Metadaten ergeben, die das Modell bereitstellen kann.

Das UDM bietet die folgenden Vorteile:

• Deutlich verbessertes Benutzermodell.
• Stellt Abfragen mit hoher Leistung bereit und unterstützt so interaktive Analysen sogar von großen Datenmengen.
• Erfasst Geschäftsregeln im Modell zur Unterstützung umfangreicherer Analysen.
• Ermöglicht eine Rückkopplung, bei der Benutzer auf die angezeigten Daten reagieren können.

Grundlegendes Endbenutzermodell

Betrachten Sie folgendes Beispiel, bei dem ein Benutzer die Verkäufe mit den Sollvorgaben für verschiedene Zeiträume vergleichen möchte.

Die Verkaufsdaten werden in der Sales- und Inventory-Hauptdatenbank gespeichert, in der viele andere Tabellen enthalten sind. Sogar nach dem Angeben der relevanten Tabellen stellt der Benutzer möglicherweise fest, dass die Daten für eine einzelne Entität wie Product auf viele Tabellen verteilt sind. Weil die referentielle Integrität von der Anwendungslogik erzwungen wird, sind keine Beziehungen zwischen diesen Tabellen definiert. Die Sales Quotas-Daten werden dabei in der Datenbank einer anderen Anwendung gespeichert. Darüber hinaus werden in der Datenbank keine Geschäftsregeln erfasst, wie z. B. die Tatsache, dass zum Vergleichen von Sollvorgaben mit den tatsächlichen Verkäufen anstelle der vielen anderen Datumsangaben für Bestellungen (z. B. Bestelldatum, Fälligkeitsdatum, geplantes Lieferdatum usw.) das Lieferdatum verwendet wird.

Direkter Zugriff auf die Datenquellen

Betrachten Sie zunächst den Fall, bei dem der Benutzer auf die Datenquellen direkt zugreift. Die folgende Abbildung zeigt ein Beispiel für eine Abfrage, die mithilfe eines Beispieltools erstellt wird.

Bisher hat der Benutzer eine beträchtliche Anzahl von Vorgängen durchgeführt: Diese beinhalten Folgendes:

• Durchsuchen einer Vielzahl von Tabellen mit kryptischen Namen nach benötigten Tabellen.
• Identifizieren der Spalten, die zum Verknüpfen der Tabellen zusammen verwendet werden können.
• Auswählen dieser Spalten, die die benötigten Details enthalten, aus vielen Tabellen mit vielen systemorientierten Details. Beispielsweise sind unter den 11 Spalten, in denen Produktkategoriendetails enthalten sind, nur die zwei Namensspalten für den Benutzer tatsächlich von Bedeutung.

Der Benutzer muss nun selbst definieren, an welchen Stellen äußere und innere Verknüpfungen verwendet und wie die Details gruppiert werden sollen, um die erforderlichen Aggregate bereitzustellen.

Allerdings ist der Benutzer mit noch schwierigeren Aufgaben konfrontiert. Wie kann der Benutzer z. B. Daten aus den anderen Datenquellen miteinander verknüpfen? Auch wenn eine der Datenbanken verteilte Abfragen unterstützt, ist es für die meisten Benutzer nicht möglich, die erforderliche Abfrage zu erstellen. Darüber hinaus bieten Tools dem Benutzer bei dieser Aufgabe möglicherweise nicht genügend Unterstützung. Das Codebeispiel zeigt eine Methode zum Abfragen der externen Daten.

SELECT Quotas.QuotaAmount, Quotas.EmployeeId, …
FROM OPENROWSET('SQLOLEDB','seattle1';
'Sales';'MyPass',
   'SELECT * FROM Forecasts.dbo.SalesQuota’ ) As Quotas

Wenn andere Datenquellen verwendet werden, wie z. B. Webdienste, steht der Benutzer einer weiteren großen Herausforderung gegenüber. Der Benutzer muss nämlich bestimmen, wie die notwendigen Remoteaufrufe durchgeführt werden sollen, und muss den zurückgegebenen XML-Code (Extensible Markup Language) zur Verknüpfung mit anderen Daten verarbeiten.

Nachdem schließlich die erste Abfrage fertig gestellt ist, muss ein Großteil der Angaben für die nächste Abfrage sowie für jede nachfolgende Abfrage erneut vorgenommen werden.

Zugreifen auf die Datenquellen mithilfe eines UDM

Zur Gegenüberstellung wird im folgenden Diagramm ein Beispiel für das Erstellen einer Abfrage dargestellt, bei dem ein Benutzer auf die Datenquellen mithilfe eines einfachen UDMs zugreift.

Die in diesem Beispiel gezeigte Entwurfsoberfläche ist in den Entwicklungstools verfügbar, die mit Microsoft SQL Server 2005 bereitgestellt werden. Es kann jedoch jede beliebige Oberfläche verwendet werden, von der das UDM unterstützt wird. Dazu zählen auch Clienttools wie Office Excel oder Office Web Components (OWC) oder eines der vielen Berichterstellungs- und Analysetools.

Die Strukturansicht links stellt die Inhalte des UDMs dar. Beachten Sie die folgenden Punkte in diesem Beispiel:

• Es werden nur benutzerorientierte, relevante Elemente für den Benutzer verfügbar gemacht. Systemspalten, wie z. B. Zeilen-GUIDs oder das letzte Änderungsdatum, sind nicht sichtbar.
• Die verwendeten Namen sind die Anzeigenamen, und nicht die Namen, die sich aus den entwicklungsorientierten, in der zugrunde liegenden Datenbank verwendeten Benennungskonventionen ergeben.

Das UDM gruppiert auch alle Attribute jeder einzelnen Geschäftsentität in separate Dimensionen, wie z. B. Product oder Employee. Der Client kann daher in diesem Beispiel auf Product Color, Subcategory und Category verweisen, ohne dabei explizit Verknüpfungen zwischen den vielen beteiligten Tabellen auszuführen.

Spalten, die Transaktionswerte oder Messungen darstellen, werden dann als Measures dargestellt. So sind z. B. Benutzer normalerweise daran interessiert, Spalten wie die Verkaufssumme oder Sollvorgaben zu aggregieren. Diese Darstellungsmethode der Daten als Measures und Dimensionen wird als Dimensionsmodellierung bezeichnet.

Auf der rechten Seite des Diagramms werden die in der aktuellen Abfrage verwendeten Elemente gezeigt. Die Abfrage "Verkäufe und Sollvorgaben nach Produktkategorien" wird vom Benutzer durch einfaches Ziehen der drei relevanten Elemente aus der Strukturansicht in die rechte Seite der Entwurfsoberfläche definiert. Der Benutzer musste weder die Details angeben, die für den tatsächlichen Zugriff auf die zwei verschiedenen Datenquellen notwendig sind, noch die richtigen Verknüpfungen zwischen den vielen beteiligten Tabellen ausführen.

Das Modell erstellt die standardmäßige einfache Formatierung, wie z. B. die Verwendung von Währungssymbolen. Sie haben auch die Möglichkeit, eine umfangreiche Formatierung zu definieren, in der bedingte Formatierung enthalten ist. Ein Beispiel hierfür ist die Anzeige eines Wertes in Rot, wenn dieser unterhalb eines bestimmten Schwellenwertes liegt.

Dasselbe Modell unterstützt verschiedene Abfragen. Beispielsweise können Ergebnisse nach Mitarbeitern unterteilt werden, indem Sie diese aus der Employee-Dimension einfach in ein Attribut ziehen.

Erweitern des Grundmodells

Im vorigen Beispiel wird gezeigt, wie selbst ein einfaches UDM das grundlegende Durchsuchen von Daten deutlich vereinfachen kann. Bei der Bereitstellung des Endbenutzerzugriffs auf die Daten müssen jedoch noch weitere Herausforderungen berücksichtigt werden. Beispiel:

• Ein UDM, das viele unterschiedliche Abfragetypen von verschiedenen Benutzern unterstützt, kann eine beträchtliche Größe annehmen. Wie kann sichergestellt werden, dass einem Benutzer, der an einer bestimmten Aufgabe arbeitet, nur die relevanten Informationen angezeigt werden?
• Wie werden die Anforderungen globaler Benutzer unterstützt, die Berichte in der Muttersprache anzeigen möchten?
• Wie können allgemeine Fragen im Hinblick auf verschiedene Zeiträume einfach gestellt werden? So könnte ein Benutzer z. B. die Verkäufe im Vergleich zum selben Zeitraum im Vorjahr anzeigen wollen.

In diesem Abschnitt werden einige dieser Fragen behandelt, um zu zeigen, wie das UDM die Erweiterung des Grundmodells unterstützt, um ein erweitertes Durchsuchen von Daten zu ermöglichen.

Hierarchien

Obwohl durch die Konsolidierung aller Attribute einer Entität in eine Dimension das Modell für den Benutzer bedeutend vereinfacht wird, gibt es weitere Beziehungen zwischen Attributen, die mit einer einfachen Liste nicht ausgedrückt werden können. Im vorigen Beispiel wird mit den Category-, SubCategory- und SKU-Ebenen eine der Hierarchien definiert, in denen Produkte organisiert werden können. Das UDM ermöglicht Ihnen die Definition solcher Hierarchien, weil Benutzer häufig eine Analyse basierend auf solchen Hierarchien durchführen wollen. So könnte z. B. der Benutzer nach Anzeigen der Summen nach der Category-Ebene einen Drilldown auf die SubCategory-Ebene und nachfolgend auf die unterste SKU-Ebene durchführen. Jede Hierarchie stellt eine Sequenz von Attributen dar, die dann zur Vereinfachung solcher Drilldown- und Drillupszenarien in Abfragen verwendet werden kann.

Das folgende Diagramm ist ein Beispiel für das Anzeigen von Hierarchien in einer Endbenutzer-UI. Das Modell enthält mehrere verschiedene Hierarchien, in denen die Produkte organisiert werden können. Die Abfrage in diesem Beispiel beantwortet die Frage nach dem Anzeigen von Verkäufen und Sollvorgaben nach Produktkategorien sowie nach Unterkategorien. Die Abfrage wurde durch Ziehen der Products By Category-Hierarchie in das Raster definiert. Der Benutzer doppelklickt auf die Bike-Kategorie, um die Unterkategorien zu erweitern und die detaillierten Daten anzuzeigen.

Das UDM sorgt für das Navigieren zwischen den Ebenen einer Hierarchie. Das UDM sorgt auch dafür, dass Quotas-Daten nicht auf der SubCategory-Ebene, sondern nur auf der Category-Ebene verfügbar sind.

Eine spezielle Art der Hierarchie ist die Parent-Child-Hierarchie, in der Entitäten enthalten sind, die komplexe Beziehungen zu sich selbst aufweisen. Im Folgenden wird die Employee-Dimension mit der Hierarchie namens Employees By Organization Structure veranschaulicht. Diese Hierarchie ermöglicht das einfache Navigieren durch die Parent-Child-Beziehung und das Analysieren zusammengefasster Werte auf jeder Ebene der Organisation. So beinhalten z. B. die Sollvorgaben für den Verkaufsleiter Charles Marshall die Summe der Sollvorgaben aller Verkaufsmitarbeiter, plus aller Sollvorgaben, die dem Verkaufsleiter direkt zugeordnet sind.

Kategorisierung

Benutzer wenden natürlich Kategorisierungen auf ihre Daten an. So könnte sich ein Benutzer beispielsweise sagen: "Diese Attribute beinhalten alle persönlichen Details eines Mitarbeiters. Dieses Attribut beinhaltet eine E-Mail-Adresse.". Das UDM stellt zwei Mechanismen bereit, die speziell darauf ausgerichtet sind, auf Basis dieser Kategorisierungen einen Mehrwert zur Verfügung zu stellen:

• Dimensionen, Attribute und weitere Objekte können in semantisch sinnvolle Kategorien gestellt werden, die die intelligentere Verwendung des Objekts durch ein Clienttool ermöglichen. So kann z. B. ein Attribut als URL gekennzeichnet werden. Der Bericht, der dieses Attribut enthält, könnte dann die Navigation basierend auf den Werten des URL ermöglichen. Ein weiteres Attribut könnte als E-Mail-Adresse gekennzeichnet werden. In diesem Fall könnte ein Berichterstellungsclient automatisch eine neue E-Mail für eine bestimmte Benutzeraktion öffnen.
• Measures, Hierarchien und andere Objekte können in Ordner gruppiert werden, die für den Benutzer verständlich sind. Somit kann das Berichterstellungstool eine hohe Anzahl von Attributen auf überschaubare Weise anzeigen. Beispielsweise ist eine Gruppe mit der Bezeichnung Customer Demographics vorhanden.

Zeitangaben

Zeitangaben werden im Allgemeinen in der zugrunde liegenden Datenquelle mithilfe der DataTime- oder Date-Datentypen erfasst. Obwohl Benutzer mit fundierten SQL- oder XPath-Erfahrungen die benötigten Datumsinformationen, wie z. B. die Summe von Daten pro Jahr, extrahieren können, fällt es ihnen möglicherweise schwer, eine Abfrage für Fragen auf Basis anderer Zeitangaben zu erstellen, wie z. B. Anzeigen von Verkäufen nach Wochentagen oder Anzeigen einer Aufteilung nach Geschäftsjahr, beginnend am 1. Juli.

Das UDM verfügt jedoch über integrierte Zeitparameter. Hierzu zählen die folgenden Kalenderarten:

• Regulärer Kalender
• Geschäftskalender
• Berichtskalender (445 usw.)
• Produktionskalender (13 Zeiträume)
• ISO8601

Das Modell kann daher eine Zeitdimension beinhalten, die eine große Menge an Attributen bereitstellt, mit der die Details der jeweiligen Tage definiert werden. In der folgenden Abbildung werden die Ergebnisse dargestellt, die der Benutzer erhält, wenn er die Verkäufe und Sollvorgaben für das Geschäftsjahr 2001 anzeigt. Zu diesem Zweck zieht der Benutzer einfach das relevante Element aus der Struktur in den Filterbereich. Das UDM kennt die Übersetzung dieser Auswahl in einen Datumsbereich und versteht zusätzlich die Geschäftsregel, die besagt, dass die zu diesen Daten gelieferten Aufträge und nicht die zu diesen Daten fälligen oder bestellten Aufträge in die Abfrage eingeschlossen werden müssen. Die richtige Verknüpfung wird implizit vom UDM erstellt.

Des Weiteren unterstützt das UDM das Beantworten allgemeiner zeitbezogener Fragen, wie z. B. das Vergleichen zweier Zeiträume (Vergleichen dieses Monats mit demselben Monat im Vorjahr).

Übersetzungen

In den vorigen Beispielen werden sowohl die Modellinhalte als auch die Daten in einer einzigen Sprache angezeigt. Internationale Benutzer benötigen jedoch häufig die Anzeige der Metadaten in ihrer eigenen Sprache.

Hierzu bietet das UDM die Möglichkeit, Übersetzungen von Metadaten in einer beliebigen Sprache bereitzustellen. Eine Clientanwendung, die mithilfe eines bestimmten Gebietsschemas eine Verbindung herstellt, erhielte dann alle Metadaten in der entsprechenden Sprache.

Das Modell kann auch Übersetzungen von Daten bereitstellen. Ein Attribut kann verschiedenen Elementen der Datenquelle zugeordnet werden. Auf diese Weise werden die Übersetzungen für diese Elemente in verschiedenen Sprachen bereitgestellt. Wenn z. B. der Benutzer mithilfe des in den vorigen Beispielen verwendeten Tools, jedoch von einem Computer mit einem französischen Gebietsschema, die Verbindung herstellt, werden sowohl das UDM als auch die Abfrageergebnisse, wie in der Abbildung dargestellt, in Französisch angezeigt.

Perspektiven

Obwohl das in diesem Beispiel verwendete Modell von bescheidener Größe ist, können Modelle für die Praxis einen größeren Umfang haben und Dutzende von Measures und Dimensionen enthalten, wobei jede dieser Dimensionen Dutzende oder Hunderte von Attributen enthält. Benutzer, die eine bestimmte Aufgabe ausführen, müssen nicht das gesamte Modell anzeigen. Erforderlich ist die Möglichkeit, eine kompakt Ansicht des Modells zu definieren, sodass sich die Benutzer auf die benötigten Informationen konzentrieren können.

Das UDM stellt diese Ansichten, als Perspektiven bezeichnet, bereit. Ein UDM kann über eine Vielzahl von Perspektiven verfügen. Jede dieser Perspektiven stellt dabei nur eine bestimmte, für eine bestimmte Gruppe von Benutzern relevante Teilmenge des Modells dar (Measures, Dimensionen, Attribute usw.). Die einzelnen Perspektiven können dann den Benutzersicherheitsrollen zugeordnet werden, die die Benutzer, die diese Perspektive anzeigen dürfen, definieren.

Eine Perspektive namens Seattle Inventory kann beispielsweise definiert werden, die nur Measures aus der Inventory-Measuregruppe enthält, die die Hierarchie Warehouse By Location ausblendet und die Seattle als Standard für City verwendet.

Attributsemantik

Ein UDM stellt zusätzliche Semantik für Attribute bereit. Diese Semantik zielt darauf ab, die Informationen besser verwertbar zu machen. Folgendes sind einige Beispiele für Semantik, die auf Attribute angewendet werden kann:

• Namen kontra Schlüssel: Beim Betrachten der relationalen Datenbank ist es möglicherweise nicht offensichtlich, dass es sich bei EmployeeID um einen bedeutungslosen, eindeutigen, vom System generierten Schlüssel handelt. Das UDM löst dieses Problem, indem es beim Employee-Attribut die gleichzeitige Verwendung eines Schlüssels (die eindeutige EmployeeID) und eines Namens (in diesem Beispiel die Verkettung von FirstName und LastName) ermöglicht. Mit einer Abfrage, z. B. Anzeigen der Mitarbeiter, werden nun Mitarbeiter mit demselben Namen anhand ihrer eindeutigen IDs ordnungsgemäß unterschieden. Dem Benutzer wird jedoch der aussagekräftige Name angezeigt.
• Sortierung: Die Werte von Attributen müssen häufig in einer festen Reihenfolge angezeigt werden, bei der es sich nicht um eine einfache alphabetische oder numerische Reihenfolge handelt. Das UDM ermöglicht das Definieren einer Standardreihenfolge, um dieser Anforderung zu entsprechen. Beispiel:
  • Die Wochentage werden als Sunday, Monday, Tuesday usw. angezeigt.
  • Prioritäten werden in der Reihenfolge High, Medium und Low angezeigt.
• Diskretisierung: Bei numerischen Attributen ist das Anzeigen der unterschiedlichen Attributwerte manchmal nicht sinnvoll. So ist z. B. die Anzeige der Verkäufe für die verschiedenen Preise ($9.97, $10.05, $10.10…) weniger sinnvoll als die Anzeige der Verkäufe pro Preisbereich (<$10, $10 - $15…). Das UDM ermöglicht die Diskretisierung von Attributen in solche Bereiche mithilfe 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, sodass Unternehmen für eine verständlichere Gruppierung und Darstellung von Daten sorgen können. Ein KPI kann zum Anzeigen des Status und des Trends eine Grafik verwenden, wie z. B eine Verkehrsampel zur Angabe von 'gut, befriedend, unzureichend'.

Jeder KPI eines UDM definiert bis zu vier Ausdrücke für sämtliche Leistungsmetriken:

• Tatsächlicher Wert
• Zielwert
• Status Ein normalisierter Wert zwischen -1 und 1, der das Verhältnis des tatsächlichen Wertes gegenüber dem Zielwert darstellt (-1 steht für 'sehr schlecht', 1 für 'sehr gut').
• Trend Ein normalisierter Wert zwischen -1 und 1, der den Trend über einen Zeitraum darstellt (-1 steht für 'negativ', 1 für 'positiv').

Die Verwendung von KPIs ermöglicht die Darstellung von zugehörigen Measures in Clienttools, die für den Benutzer schneller verständlicher ist. Die folgende Abbildung zeigt ein Beispiel dafür, wie drei KPIs, die in Anzeigeordnern organisiert sind, von einem Clienttool angezeigt werden können.

Leistung

Für Benutzer, die Daten interaktiv durchsuchen, sind schnelle Antwortzeiten erforderlich. Aufgrund der sehr großen Datenmengen, in denen häufig solche Durchsuchungsvorgänge ausgeführt werden, stellt diese Anforderung eine Herausforderung dar.

Das UDM stellt zur Verbesserung der Leistung Dienste zum Zwischenspeichern bereit. In Caches können die aus der zugrunde liegenden Datenquelle gelesenen detaillierten Daten und die auf Basis dieser Daten im Voraus berechneten aggregierten Werte zwischengespeichert werden. Zwischengespeicherte Werte können jedoch einen bestimmten Grad an Abgestandenheit der Daten mit sich bringen. Geschäftsanforderungen geben vor, wie aktuell Informationen sein müssen. In manchen Fällen kann das Anzeigen der aktuellsten Daten wichtig sein, während es in anderen Fällen absolut akzeptabel sein kann, Daten, die zwei Stunden oder zwei Tage alt sind, anzuzeigen.

Zur Berücksichtigung dieser Richtlinien, die die Aktualität der Daten vorgeben, stehen im UDM zwei Möglichkeiten zur Verfügung: die explizite Verwaltung des Caches, z. B. ein Plan, mit dem die Aktualisierung des Caches jeweils um 2 Uhr nachts definiert werden kann, und die transparente Verwaltung des Caches durch proaktives Zwischenspeichern. Der Benutzer kann angeben, wie aktuell die Daten sein müssen. Das UDM stellt dabei die automatische Erstellung und Verwaltung des Caches bereit, um schnellstmögliche Abfrageantworten sicherzustellen.

Analytik

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 im Modell des Benutzers Geschäftslogik enthalten sein soll. Das UDM stellt hierzu das Definieren sowohl einfacher als auch komplexer Berechnungen der Daten bereit.

Basisanalytik

Abfragen geben im Allgemeinen aggregierte Daten zurück. So zeigt z. B. eine typische Abfrage die Verkäufe nach Kategorie, statt jede einzelne Bestellung anzuzeigen. Allerdings gibt es in den zugrunde liegenden relationalen Daten nicht, was definiert, wie ein bestimmtes Measure aggregiert werden soll. Zum Beispiel kann die Verkaufssumme sinnvoll summiert werden, vom Stückpreis sollte jedoch der Durchschnitt werden. Das UDM fügt diese Semantik hinzu.

Die Aggregationsmethode kann mithilfe einer Vielzahl von Schemas definiert werden:

• Eine einfache Aggregationsfunktion wie Sum, Count, Distinct Count, Max oder Min kann verwendet werden.
• Die Aggregation kann als semiadditiv definiert werden. Dies bedeutet, dass eine einfache Funktion wie Sum für alle Dimensionen außer Time verwendet wird, bei denen Last Period verwendet wird. Obwohl die Inventory-Ebene beispielsweise von Product in Product Category summiert werden kann, stellt die Inventory-Ebene für den Monat nicht die Summe der Inventory-Ebenen für jeden Tag dar. Stattdessen handelt es sich bei der Inventory-Ebene des Monats um die Inventory-Ebene des letzten Tages im Monat.
• Die Aggregation kann auf dem Kontotyp basieren, wie z. B. Income kontra Expense.
• Die Aggregation kann zur Erfüllung spezieller Anforderungen angepasst werden.

Ein UDM kann auch berechnete Elemente enthalten. Diese Elemente sind der Datenquelle nicht direkt zugeordnet. Sie sind stattdessen von diesen Daten abgeleitet. Das berechnete Element, in diesem Fall Variance, kann beispielsweise definiert werden, um die Differenz zwischen Sales- und Quota-Daten zu berechnen.

Ein UDM kann auf ähnliche Weise vom Benutzer benötigte Gruppen von Entitäten definieren. Dies können z. B. die wichtigsten 10 Kunden nach Verkaufsvolumen sein oder die wichtigsten Produkte. Diese Gruppen können dann zum Einschränken des Abfrageumfangs auf bestimmte Entitäten verwendet werden.

Erweiterte Analytik

Manchmal sind die für Benutzer erforderlichen Berechnungen viel komplexer als das zuvor aufgeführte Variance-Beispiel. Nachfolgend finden Sie einige Beispiele für komplexe Berechnungen.

• Anzeigen des Durchschnitts der herausragendsten 3 Monate für jeden Zeitraum.
• Vergleichen des Jahreszuwachses für diesen Zeitraum und den gleichen Zeitraum im Vorjahr.
• Wenn die Verkäufe in der Basiswährung berichtet werden, Rückkonvertieren der Verkäufe in die ursprüngliche Währung mithilfe des zum Zeitpunkt des Verkaufs gültigen durchschnittlichen Wechselkurses.
• Berechnen der budgetierten Verkäufe nach Kategorien für folgendes Jahr mit zusätzlichen 10 % im Vergleich zum laufenden Jahr sowie Zuordnen des Budgets zu jedem Produkt auf Basis der relativen Durchschnittsverkäufe der letzten 3 Jahre.

Das UDM stellt ein umfangreiches Modell zum Definieren solcher Berechnungen bereit, das einem mehrdimensionalen Arbeitsblatt ähnelt, in dem der Wert einer Zelle auf Basis der Werte anderer Zellen berechnet werden kann. Allerdings beschreibt selbst diese Metapher die Berechnungen im UDM nicht entsprechend. Der Wert einer Zelle wird möglicherweise nicht nur auf Basis des Wertes einer anderen Zelle berechnet, sondern auch auf Basis des in der anderen Zelle enthaltenen alten Wertes. Daher können gleichzeitige Formeln unterstützt werden. Beispielsweise wird der Gewinn vom Umsatz minus der Ausgaben abgeleitet. Der in den Ausgaben enthaltene Bonus hingegen wird vom Gewinn abgeleitet.

Neben der leistungsstarken MDX-Sprache (Multi Dimensional Expressions), die insbesondere zum Schreiben dieser Berechnungen entworfen wurde, bietet das UDM auch die Integration mit Microsoft .NET. Durch diese Integration können gespeicherte Prozeduren und Funktionen in jeder beliebigen überprüfbaren .NET-Sprache, wie z. B. C#.NET oder Visual Basic.NET, geschrieben werden. Die gespeicherte Prozedur oder Funktion kann dann von MDX zur Verwendung in Berechnungen aufgerufen werden.

Dabei ist der Client von den Details dieser Berechnungen isoliert. In Clientanwendungen verfügt das Modell nun anscheinend nur über nützlichere Measures. Im folgenden Beispiel werden dem Benutzer unter anderem verschiedene berechnete Measures auf Basis der Sales-Daten für die rentabelsten Produkte angezeigt, die in den USA verkauft wurden.

Integration mit Data Mining

Die Möglichkeit zum Anzeigen von Daten in umfangreicher, leicht verständlicher Form ist nützlich, die Benutzer benötigen jedoch auch die Möglichkeit, neue Informationen aus diesen Daten abzuleiten.

Das UDM ist eng mit der Data Mining-Technologie integriert und ermöglicht so das Data Mining und die spätere Verwendung von ermittelten Mustern für die Vorhersage.

Bereitstellen aussagefähiger Daten

Wenn einem Benutzer beispielsweise Daten angezeigt werden, hat dies häufig zur Folge, dass der Benutzer zusätzliche Fragen stellen oder weitere Aktionen durchführen möchte. Beispiel:

• Welche detaillierten Verkäufe fließen in diese Zahl mit ein?
• Die Sollvorgaben für den Verkauf sind zu niedrig. Sie müssen erhöht werden.
• Diese Zahl muss überprüft werden. Ich möchte sie deshalb mit einem Kommentar versehen.
• Welche detaillierten Informationen stehen auf unserer Website zu dieser Promotion bereit?

Die Darstellung der Daten auf verständliche Art und Weise ist daher nicht ausreichend. Zudem ist es notwendig, den Benutzern das Durchführen einfacher Aktionen auf Basis der angezeigten Daten zu ermöglichen.

Das UDM unterstützt dies auf zweierlei Arten:

• durch Zurückschreiben von Änderungen in die Daten
• durch Ermöglichung der Zuordnung durchgeführter Aktionen zu den Daten.

Rückschreiben

Das UDM ist nicht schreibgeschützt. Des Weiteren ist es möglich, die Daten durch das UDM zu aktualisieren. Bei Measures werden beispielsweise die Aktualisierungen von den ursprünglichen Werten separat gespeichert, nämlich als Deltawerte, die die Differenzen zu diesen Werten darstellen.

Zusätzlich ist es möglich, zusammengefasste Zahlen zu aktualisieren. Betrachten Sie hierzu beispielsweise ein Budgetierungsszenario. Die budgetierte Summe ist möglicherweise bis zu einer detaillierten Ebene, z. B. ein Team oder Konto, bekannt, die Werte sind jedoch zuerst nur auf einer zusammengefassten Ebene, z. B. eine Abteilung oder ein Kontotyp, zu sehen.

Aktionen

Das UDM unterstützt Aktionen in Form von Verknüpfungen zwischen den Daten und der auf Basis der Daten durchgeführten Aktionen. Zu den wichtigsten Aktionsarten zählen:

• URL: Öffnen eines angegebenen URLs. Dieser Aktionstyp unterstützt sowohl das Leiten des Benutzers zu URLs, um weitere Informationen zu erhalten, als auch das Leiten des Benutzers zu einigen webbasierten Anwendungen, um eine neue Aufgabe auszuführen. Beispiel:
  • Bei einem Produkt: Öffnen der Firmenwebsite, auf der Beschreibungen für dieses Produkt zu finden sind.
  • Bei einer Produkt-/Lagerkombination: Öffnen der webbasierten Lagerverwaltungsanwendung, wobei die Produkt-/Lagerkombination als Parameter weitergegeben wird, um die Erhöhung des Sicherheitsbestands sicherzustellen.
• Berichterstellung: Ausführen eines angegebenen Berichts. Bei einem angegebenen Produkt kann die Aktion beispielsweise einen parametrisierten Produktbericht ausführen, der die Produktbeschreibung und den aktuellen Bestellstatus bereitstellt.
• Drillthrough: Ausführen eines Drillthroughs zur niedrigsten Detailebene. Ein Benutzer, der beispielsweise die Summe aller Verkäufe nach Produkten und Kunden überprüft, kann einen Drillthrough ausführen, um alle Verkaufstransaktionen, die zu dieser Summe beitragen, anzuzeigen.

Die Aktionen können bestimmten Regionen der Daten zugeordnet werden. Eine Aktion, die zum Navigieren zu einer Webseite durchgeführt wird, kann beispielsweise für jedes Produkt angewendet werden. Die Aktion zum Anzeigen der detaillierten Bestandsübertragungstransaktionen wird jedoch für jeden Wert der Quantity-Daten je nach Produkt und Lager angewendet.

Während Aktionen als Teil des UDMs definiert werden, sorgt die Clientanwendung dafür, dass die anwendbaren Details der Aktionen abgerufen, die Aktionen dem Benutzer zur Verfügung gestellt und dann die Aktion nach Bedarf initialisiert wird.

Sicherheit

Der Zugriff auf das UDM kann gesteuert werden. Zu den Schlüsselfeatures der Sicherheit zählen:

• Das UDM stellt rollenbasierte Sicherheit bereit. Rollen können definiert werden. Des Weiteren können den Rollen Berechtigungen erteilt und Benutzer als Mitglieder der jeweiligen Rolle eingeschlossen werden. Die tatsächlichen Berechtigungen eines Benutzers stellt die Gruppe von Berechtigungen dar, die den einzelnen Rollen, die der Benutzer angehört, erteilt wurden. Die Berechtigungen einer Rolle können auch sichere Zugriffsverweigerungen enthalten, durch die Rechte aufgehoben werden, unabhängig von anderen Rollen, denen ein Benutzer möglicherweise angehört.
• Administrative Berechtigungen, wie z. B. das Ändern eines UDM, können unabhängig von den Datenzugriffsberechtigungen erteilt werden. Auch können separate Berechtigungen zum Lesen der Metadaten des Objekts und für Lese-/Schreibzugriff auf die Daten definiert werden.
• Daten können auf Granularitätsebenen bis auf die Ebene einzelner Zellen gesichert werden. Sie können z. B. die Möglichkeit für Benutzern begrenzen, die Verkäufe für das Produkt Widget für den Kunden ACME anzuzeigen. Die Sicherheit kann auch bedingt sein. Beispielsweise darf eine Rolle die Summe aller Gehälter einer Abteilung nur dann anzeigen, wenn in dieser Abteilung mehr als fünf Mitarbeiter arbeiten.
• Die Berechtigungen können definieren, ob sichtbare Summen verwendet werden sollen, wobei diese Summen nur die niedrigeren Ebenenelemente widerspiegeln, für die der Benutzer über Berechtigungen verfügt. Der Zellenzugriff kann auch abhängig sein, d. h. dass Zellen, die von anderen Zellen abgeleitet werden, nur angezeigt werden, wenn alle anderen Zellen ebenfalls angezeigt werden können. Wenn z. B. der Gewinn von Einnahmen und Ausgaben abgeleitet wird, können die Benutzer den Gewinn nur für Produkte anzeigen, für die die Berechtigung dazu besitzen, sowohl Einnahmen als auch Ausgaben anzuzeigen.

Siehe auch

Andere Ressourcen

Konzepte von Analysis Services

Hilfe und Informationen

Informationsquellen für SQL Server 2005