24.06.2002

Aufbau eines SQL-Servers mit Anbindung an OLAP
der Aufbau mit OLAP

Die Analysis Services laufen auf einem getrennten DB-Server, welcher mit Access, einem OLE-DB-Provider und mit SQL laufen muss. Die Lizenz befindet sich auf einem SQL2k-Server, welcher mit dem English Query und den eigentlichen Analysis Service ausgerüstet ist. Genutzt wird das OLAP (Online Analytical Processing) vom Controlling, der Finanzverwaltung, welche auf Daten aus der Realität (OLTP , Online Transaction Processing) basiert.

Um das OLAP zu verstehen, stelle man sich einen Würfel vor, dessen Seiten folgende Beschriftung haben:

Der Idealfall eines Controllers sieht so aus, dass er jeden Punkt oder jede Fläche (von...bis...) innerhalb dieses Würfels erfassen kann. Das Ganze auch noch möglichst schnell. Es gibt natürlich auch mehr als drei Dimensionen, virtuelle Dimensionen und, oder Schnittmengen, die der Controller erhalten möchte (Multidimensional Cubes). Programmierer kennen sowas ähnliches als Array. Dabei muss man beachten, dass nicht alle Informationen aus einer DB benötigt werden. Deswegen erstellt man eine eigene OLAP-DB, welche sich unter Umständen von dem OLTP-Modell sehr stark unterscheiden kann. Man holt sich also sowohl die Kenndaten (Fakten), die Dimensionsdaten, als auch zusammengesetzte Kenn- und Dimensionsdaten heraus. Es kann durchaus vorkommen, dass Kenn- und Dimensionsdaten in einer einzigen Tabelle vorkommen.

Nehmen wir als Beispiel eine 50GB grosse Datenbank. Der Analysis Service nimmt u.U. die Daten auseinander und benötigt nicht alle Daten aus der DB.

Oder nehmen wir mal ein mittleres Chaos-Unternehmen:
Dort haben wir mehrere DBM-Systeme. Wir haben zum Beispiel in der Buchhaltung DOS-Multiplan, in der Produktion ein UNIX-System, im Einkauf und im Verkauf Access, im Personal eine CSV-Datei, die Kunden in Outlook und die Revision in Excel. Als Lösung kopiere ich die CSV-Datei in eine Freigabe, erzeuge auf meinem extra-SQL-Server ein DTS-Paket, welches zeitgesteuert läuft und importiere die Daten nach SQL. Allerdings ist hier schon der erste Fehlergrund: Wir können die Informationen nur bis zur Freigabe zurückverfolgen, nicht weiter. Wir können also nicht wie bei Access auf die Originaldaten zugreifen. Ähnlich verhält es sich mit allen anderen Daten auch.

Es gibt mehrere OLAP-Speichermodelle:

Das DataMining bedeutet soviel wie "Ursprung finden". Es lässt sich ziemlich genau ermitteln, wer was wann getan hat. Ein Beispiel: Am Montag mache ich eine Trendberechnung für den Tagesumsatz Ende diesen Jahres. Das System gibt mir eine Zahl mit 100.000 Euro. Am Dienstag erinnere ich mich nicht mehr an die Daten und mache eine zweite Trendberechnung. Diesmal kommt eine Zahl mit 1.000.000 Euro raus. Nun denke ich mir, dass irgendwo ein Fehler ist. Mit Hilfe eines Mining-Modells kann ich nun versuchen, den Fehler zu finden, sehe also eine Preiskurve, welche mir zwischen 15.05 und 15.06 Uhr eine aprupte Steigerung anzeigt. Nachträglich kann ich mir anschauen, in welcher Filiale die Steigerung aufgetreten ist, welche Mitarbeiter, wieviel Kunden und wieviel Geld dabei im Spiel ist. Im Endeffekt lässt sich dabei genau sagen, ob und wer falsche Eingaben auf dem System gemacht hat.

Wir unterscheiden Fakten und Dimensionen:
Will ich wissen, wieviel Umsatz der Mitarbeiter 1 am 1.1. gemacht hat, sind die Mitarbeiter-ID's und das Datum als Dimension zu sehen, und der Umsatz das Faktum. Will ich wissen, welcher Mitarbeiter am 1.1. einen Umsatz von 1000 Euro überschritten hat, ist der Umsatz die eine Dimension, und das Datum die Andere. Das Schnittmengenergebnis, der Mitarbeiter, ist in diesem Fall das Faktum.
Es kommt also immer auf die Betrachtungsweise an.

Das Zeitproblem:
1 Jahr hat entweder 365 oder 366 Tage. Wochen im Jahr gibt es 52. Die erste und letzte Woche sind variabel in ihrer Arbeitstaganzahl. Die Anzahl der Monate ist 12, allerdings haben sie unterschiedliche Tagesanzahlen (28 bis 31). Der Quartalsanfang stimmt auch nicht mit den Wochenanfängen überein. Das System definiert eindeutige Werte, nämlich Jahr, Quartal, Tag, denn diese sind fest definiert mit Grenzen. Nebenher läuft noch eine zweite Hierarchie mit Jahr, Quartal, Tag; diese ist komplett anders. Allerdings gibt es andere Kalender in anderen Ländern. In Arabien zum Beispiel gibt es den Mondkalender mit 28 Tagen. Allein in unseren Bundesländern existieren unterschiedliche Anzahl von Feier- und damit Arbeitstagen.

Die Lösung ist eine Tabelle mit dem jew. Datum in einer Spalte und weiteren Spalten für die KW's, Monate, Feiertag Bayern (J/N), usw. Somit lassen sich alle mögliche Kalender zusammenfassen. Als Schlüsselspalte bestimme ich eine Zahl 1, welche automatisch pro Tag hochzählt. Diese Spalte ist der interne Tag, an diesem Punkt starten wir und legen damit einen fixen Punkt für alle Kalender fest, die ich in die Tabelle einfügen will.

OLAP Entwicklungslösungen für DataWarehouses übersteigen laut Microsoft schnell die 5 Millionen Euro-Grenze. Die Zeit beträgt 2 bis 3 Jahre. Aus diesem Grunde gibt es DataMart. Das ist eine OLAP-Lösung auf Abteilungsebene. Diese lässt sich ab ca. 200.000 Euro mit einem Zeitfenster von 3 bis 5 Monaten entwickeln. DataMart ist also eine abgespecktere OLAP-Lösung.