Kontakt

Einsatz des MS SQL Server 2005

OLAP-Systeme werden wie umfangreiche Berichtssysteme heute nicht mehr von Grund auf neu entwickelt. Stattdessen konzentriert man sich auf die individuellen Datenstrukturen, die unternehmensbezogenen Berechnungen und eine optimale Verteilung und Nutzung der geschaffenen Auswertungsmöglichkeiten. Die technische Architektur lässt sich mit Software- und DB-Komponenten entwickeln, die einen hohen Standardisierungsgrad erreicht haben. Wir konzentrieren uns dabei im Wesentlichen auf die Möglichkeiten und Einsatzszenarien, die sich mit Hilfe der Analysis Services des MS SQL Servers realisieren lassen. In Kombination mit weiteren Microsoft-Produkten wie MS BizTalk Server für die Datenintegration, MS Sharepoint Portal Server für die Bereitstellung von Verwendungssoftware oder Produkten wie MS Excel, MS Business Scorecard ermöglichen wir so unseren Kunden, dass wir uns gemeinsam mit Ihnen ausdrücklich auf Ihre Auswertungen, Daten- und Sicherheitsbedürfnisse konzentrieren. Individuelle Entwicklung von Desktop- oder Web-Anwendungen erlauben dann hier eine optimale Nutzung der geschaffenen OLAP-Strukturen.

Komponenten

Mithilfe der analytischen Onlineverarbeitung (Online Analytical Processing, OLAP) können Sie auf aggregierte und organisierte Daten aus Geschäftsdatenquellen, z. B. Data Warehouses, in einer multidimensionalen Struktur, die als Cube bezeichnet wird, zugreifen. Microsoft SQL Server 2005 Analysis Services (SSAS) stellt Tools und Features für OLAP zur Verfügung, mit deren Hilfe Sie Cubes und andere unterstützende Objekte entwerfen, bereitstellen und verwalten können.

Cube

Bei einem Cube handelt es sich um eine zum Analysieren von Daten verwendete Gruppe verwandter Measures und Dimensionen. Anschließend wird ein Cube mit Berechnungen, Key Performance Indicators (KPIs), Aktionen, Partitionen, Perspektiven und Übersetzungen erweitert. Ein Cube entspricht im Wesentlichen einem UDM (Unified Dimensional Model) Weitere Informationen zu UDMs finden Sie unter Unified Dimensional Model (UDM). In Microsoft SQL Server 2005 Analysis Services (SSAS) wird ein Cube basierend auf Tabellen und Sichten entwickelt, die in einer Datenquellensicht definiert werden. Ein Cube kann mit oder ohne eine zugrunde liegende relationale Datenquelle entwickelt werden.
In Microsoft SQL Server 2005 Analysis Services (SSAS) stellen Dimensionen eine wesentliche Komponente von Cubes dar. Mit Dimensionen werden Daten nach Interessensbereichen geordnet, z. B. nach Kunden, Geschäften oder Angestellten. Dimensionen in Analysis Services enthalten Attribute, die den Spalten in den Dimensionstabellen entsprechen. Diese Attribute erscheinen in der Form von Attributhierarchien und können in benutzerdefinierten Hierarchien organisiert, oder basierend auf den Spalten der zugrunde liegenden Dimensionstabelle als Parent-Child-Hierarchien definiert werden. Hierarchien werden dazu verwendet, die in einem Cube enthaltenen Measures zu ordnen.

Measure

Bei einem Measure handelt es sich um einen Fakt, der einen Transaktionswert oder ein Maß darstellt, den bzw. das ein Benutzer möglicherweise aggregieren möchte. Measures stammen aus Spalten einer oder mehrerer Quelltabellen und sind in Measuregruppen gruppiert.

Dimension

Bei einer Dimension handelt es sich um eine Gruppe von Attributen, die einen mit den im Cube enthaltenen Measures verknüpften Interessenbereich darstellen und zum Analysieren der Measures im Cube verwendet werden. Beispielsweise kann eine Customer-Dimension die Attribute Customer Name, Customer Gender und Customer City beinhalten, die das Analysieren der im Cube enthaltenen Measures nach dem Namen, dem Geschlecht und der Stadt des Kunden ermöglichen. Attribute stammen aus Spalten einer oder mehrerer Quelltabellen. Die in den einzelnen Dimensionen enthaltenen Attribute können in Hierarchien angeordnet werden, um Pfade für die Analyse bereitzustellen.

Fakten

Fakten in einem Cube werden basierend auf den Dimensionshierarchien über alle Dimensionen hinweg aggregiert.

Client-Architektur

Microsoft SQL Server 2005 Analysis Services (SSAS) unterstützt eine Thin Client-Architektur. Das Analysis Services-Berechnungsmodul ist vollständig serverbasiert, sodass alle Abfragen auf dem Server aufgelöst werden. Daher ist für jede Abfrage nur ein Roundtrip zwischen dem Client und dem Server erforderlich, was zu skalierbarer Leistung führt, wenn die Komplexität der Abfragen zunimmt.

Das native Protokoll für Analysis Services ist XMLA (XML for Analysis). Analysis Services stellt mehrere Datenzugriffsschnittstellen für Clientanwendungen zur Verfügung. Diese Komponenten verwenden jedoch alle XMLA für die Kommunikation mit einer Instanz von Analysis Services.

Zusammen mit Analysis Services werden mehrere unterschiedliche Anbieter zur Verfügung gestellt, um unterschiedliche Programmiersprachen zu unterstützen. Ein Anbieter kommuniziert mit einem Server mit Analysis Services, indem XMLA in SOAP-Paketen über TCP/IP oder durch Internetinformationsdienste (Internet Information Services, IIS) über HTTP gesendet und empfangen wird. Eine HTTP-Verbindung verwendet ein von IIS instanziiertes COM-Objekt, das als Datapump bezeichnet wird und als Datenleitung für Analysis Services-Daten fungiert. Die im HTTP-Datenstrom enthaltenen zugrunde liegenden Daten werden von der Datapump nicht untersucht, und auch die zugrunde liegenden Datenstrukturen stehen für Code in der Datenbibliothek selbst nicht zur Verfügung.

Analysis Services verfügt über eine Webarchitektur mit einer vollständig skalierbaren mittleren Ebene, die sowohl in kleineren als auch in großen Organisationen bereitgestellt werden kann. Analysis Services stellt umfassende Unterstützung auf mittlerer Ebene für Webdienste zur Verfügung. ASP-Anwendungen werden von OLE DB für OLAP und ADO MD unterstützt, ASP.NET-Anwendungen werden von ADOMD.NET unterstützt. Die mittlere Ebene, in der folgenden Abbildung dargestellt, ist für viele gleichzeitige Benutzer skalierbar.

Online Analytical Processing

Online Analytical Processing (OLAP) ermöglicht die multidimensionale Betrachtung von Daten zwecks Ermittlung eines entscheidungsunterstützenden Analyseergebnisses. Dabei ist insbesondere das Management in seiner Rolle als Entscheidungsträger die Zielgruppe für OLAP-Anwendungen. Die Daten liegen in einem Data Warehouse, welches eine globale Sicht auf heterogene und
verteilte Datenbestände ermöglicht, indem die für die globale Sicht relevanten Daten aus den Datenquellen zu einem gemeinsamen konsistenten Datenbestand zusammenführt und langfristig speichert. Dabei ist es die Basis für die Aggregation von betrieblichen Kennzahlen und Analysen innerhalb mehrdimensionaler Matrizen (OLAP-Cube/-Würfel).

Szenarien

OLAP kann in nahezu allen betrieblichen Bereichen zum Einsatz kommen und bietet durch sein Fundament, heterogene Daten zu einer gemeinsamen Datenbasis zu sammeln und diese entlang von Dimensionen mit Hierarchien und Aggregaten auszustatten, vielfältige Einsatzbereiche:

• Klassifizierungen und Zuordnungen von Kunden-, Verkaufs- und Bewegungsstrukturen
• Erkennen von Kunden-Verhaltensmustern
• Untersuchungen entlang von Zeit- und Geographieachsen zur Erkennung von Märkten, ihre Bewegungen und Entwicklungen
• Ableitung von Prognosemodellen für die Vorhersagen von Bestellvorgängen, Marktveränderungen und Entscheidungsverhalten von Kunden, Mitarbeitern und Lieferanten
• Ableitung von Regeln

Lösungen

OLAP bietet für eine Reihe von betriebswirtschaftlichen Fragestellungen im Bereich der Datenanalyse Lösungen an:

• Multidimensionale Untersuchungen
• Intgration von unterschiedlichen internen und externen Datenquellen zur gemeinsamen Untersuchung
• Kombination von Standardfragestellungen und ad-hoc-Untersuchungen
• Datenabfragen über natürliche und domänenspezifische Hierarchien hinweg
• Bereitstellung von unternehmens-/branchenbezogenen Aggregaten
• Berechnung und Bereitstellung von Kennzahlen
• Statistische Auswertungen für beschreibende und schließende Fragestellungen bis hin zu komplexen Data Mining-Analysen
• Muster-Entdeckung und regelbasierte Auswertungen
• Umsetzen von Auswertungen über Heuristiken

OLAP in der Theorie

Das OLAP-Konzept wurde von Codd mit 12 Evalutationsregeln in die DB-Theorie eingeführt. Diese Regeln sollen von einem OLAP-fähigen System alle gleichermaßen erfüllt werden.

Mehrdimensionale konzeptionelle Perspektiven

Da die Natur von Unternehmensanalysen interner und externer Art ohnehin multidimensional ist, sollte die konzeptionelle Sicht der OLAP-Modelle ebenfalls multidimensional sein. Dies führt zu einer Aufgliederung der relevanten Kennzahlen einer Unternehmens oder einer Organisation anhand verschiedener Kriterien.

Transparenz

OLAP-Werkzeuge müssen sich unproblematisch und einfach in die Arbeitsumgebung des Benutzers einfügen. Berichte und Analysen müssen ad hoc und ohne weitere technische Kentnnise verfügbar sein.

Zugriffsmöglichkeit

Die Architektur eines OLAP-Systems soll möglichst offen sein, sodass alle internen und viele externe Datenquellen gleichmermaßen zu einem multidimensionalen Bild der Unternehmung zusammenfließen können.

Stabile Antwortzeiten

Die Antwortzeiten des Systems sollten auch bei steigender Komplexität oder einer starken Zunahme an Dimensionen und Daten annähernd gleich bleiben, um einfaches Arbeiten mit dem System zu ermöglichen.

Client-Server-Architektur

Die Basis-Architektur muss für einen schnellen und nahezu unbegrenzten Zugriff optimiert werden, sodass nur eine Client-Server-Architektur zum Einsatz kommen kann.

Grundprinzip der gleichgestellten Dimensionen

Die einzelnen Dimensionen sollen funktional und strukturell äquivalent zueinander sein, sodass auch umfassende Datenmodelle nachvollziehbar bleiben. Dadurch muss sich ein einheitlicher Sprachumfang für die Dimensionsverwaltung nutzen lassen können.

Dynamische Verwaltung dünn besetzer Matrizen

Sind Ausprägungen aufgrund unterschiedlicher Bedingungen nicht vorhanden, d.h. enthalten Datenmatrizen Lücken und sind daher dünn besetzt, so müssen diese Datenstrukturen optimal vom System gespeichert werden.

Mehrbenutzerfähigkeit

Die Daten und damit das gesamte OLAP-System müssen simultan von mehreren Benutzern genutzt werden können. Dazu gehöhrt auch ein Sicherheitskonzept, um lesende und schreibende Zugriffe individuell zu definieren.

Unbeschränkte kreuzdimensionale Operationen

Insbesondere für Kennzahlensysteme muss die Fähigkeit vorhanden sein, Aggregationen über mehrere Dimensionen hinweg abzubilden.

Intuitive Datenmanipulation

Gerade für den Einsatz des OLAP-Systems durch Benutzer ohne weitere technische Erfahrungen muss der Einsatz des Systems einfach und schnell erlernbar zu bedienen sein. Auswahlmenüs und Verknüpfungen für die Navigation innerhalb verschiedener Hierarchiestufen und Aggregationsebenen müssen dies unterstützen.

Flexibles Berichtswesen

Die Informationen aus multidimensionalen Vegleichen, Kennzahlenergebnissen und Szenarien sowie auf den einzelnen Aggregationsstufen müssen sich leicht in konfiguierbare Berichte ausgeben lassen. Dazu gehören auch Visualisierungen mit Diagrammen und Tabellen.

Unbegrenzte Dimensions- und Aggregationsstufen

Die Anzahl der Dimensionen und Aggregationsstufen soll unbegrenzt sein, um jeden beliebigen realen Sachverhalt abbilden zu können.

OLAP-Projekte

In einer ersten Phase muss der Informationsbedarf analysiert werden. Dies bezieht sich auf den Zweck, den das OLAP-System erfüllen soll, und aus dem die Einzelinformationen zu bestimmen sind, welche im OLAP-System explizit zu erfassen sind. Dies stellt eine analytische und beratende Aktivität dar, bei welche die Anwender ausdrücklick mit einbezogen sind. Zusätzlich muss die Herfkunft der Daten bestimmt werden, wobei bei externen Datenquellen auch Übertragungsformate und Schnittstellen zu berücksichtigen sind. Greift man auf historische Daten zurück, so müssen diese für eine kontinuierliche Nutzung im neuen System migrieren.
In einer zweiten Phase wird die Lösung des zuvor beschriebenen Anforderungskatalogs entwickelt. Dabei werden geeignete Standardwerkzeuge ausgewählt und um die entsprechenden individuellen Bedingungen erweitert. Zwei grundlegende Fragen bei der Umsetzung der Lösung stellen dabei die Aktualität der Daten im OLAP-System und die möglichen Aggregationsformen der Daten dar. Aus den Aggregationsformen lassen sich später die Dimensionen ableiten, in denen die Analyseroutinen durchgeführt werden sollen. In jedem Fall ergeben sich grundlegende Unterschiede in Größe, Komplexität und Datenmodellierung der OLAP-Datenbank im Vergleich zu den operativen Datenbanken den Organisation.
In einer dritten Phase wird die Lösung dann umgesetzt und implementiert. Dies sollte auch immer eine Anwenderschulung zur optimalen Nutzung der bereit gestellten Werkzeuge und Ausgabemedien enthalten. Weitere Phasen für Tests und und evtl. Korrektur- oder Erweiterungsaktivitäten können sich sofort oder zu einem späteren Zeitpunkt bei z.B. geänderten Anforderungen anschließen.

• DB-Entwicklung
• Analysewerkzeuge wie Data Mining oder Knowledge Discovery
• Installation und Konfiguration in Oracle oder MS SQL Server
• Programmierung mit C sharp, VB.NET, VBA, Java oder innerhalb des DBMS mit Transact SQL oder PL/SQL