Zum Inhalt springen

Häufig gestellte Fragen

Was ist der Unterschied zwischen OLAP und OLTP?

OLTP (Online Transaction Processing) bezeichnet die operative Verarbeitung einzelner Geschäftsvorfälle wie Buchungen, Bestellungen oder Lagerbewegungen und ist auf schnelle, zeilenweise Schreibzugriffe optimiert. OLAP (Online Analytical Processing) dient demgegenüber der nachgelagerten analytischen Auswertung, bei der Kennzahlen über große Datenmengen entlang mehrerer Dimensionen verdichtet und gelesen werden. Beide Welten nutzen unterschiedlich strukturierte Datenbestände: das transaktionale ERP-System auf der einen, eine analytische Schicht wie ein Data Warehouse auf der anderen Seite. Der Begriff OLAP wurde 1993 von E. F. Codd geprägt, dem auch das relationale Datenbankmodell zugeschrieben wird.

Worin unterscheiden sich MOLAP, ROLAP und HOLAP?

Diese drei Begriffe beschreiben unterschiedliche technische Speicherarchitekturen für OLAP. MOLAP (multidimensionales OLAP) hält Daten in vorberechneten, vorab aggregierten Würfelstrukturen und liefert dadurch sehr schnelle Antwortzeiten, ist bei sehr großen Datenmengen aber speicherintensiver und starrer. ROLAP (relationales OLAP) belässt die Daten in relationalen Tabellen und erzeugt Aggregate erst zur Abfragezeit, was besser skaliert, aber bei großen Datenmengen langsamer reagiert. HOLAP (hybrides OLAP) kombiniert beide Ansätze, indem es häufig genutzte Verdichtungen vorberechnet und Detaildaten relational vorhält, um Geschwindigkeit und Skalierbarkeit auszubalancieren.

Brauche ich OLAP zusätzlich zum Standard-Reporting des ERP-Systems?

Das hängt stark von Datenvolumen und Analysetiefe ab. Solange Auswertungen überschaubar bleiben, genügen die im ERP integrierten Reports häufig vollständig. Bei großen historischen Datenbeständen und vielen kombinierten Dimensionen werden direkte Abfragen auf den operativen Tabellen jedoch träge und belasten das Produktivsystem. Eine analytische OLAP-Schicht setzt dann meist auf einem separaten Data Warehouse auf und entlastet das ERP, weshalb die Entscheidung am konkreten Analysebedarf und der vorhandenen IT-Landschaft des Unternehmens festgemacht werden sollte.

Sind klassische OLAP-Cubes noch Stand der Technik?

Im klassischen Data-Warehouse-Stack werden vorberechnete OLAP-Cubes weiterhin eingesetzt, vor allem dort, wo komplexe In-Memory-Berechnungen und sehr niedrige Latenz gefragt sind. In modernen Cloud-Architekturen werden sie zunehmend von spaltenorientierten (columnaren) In-Memory-Engines abgelöst, die OLAP-typische Aggregationen direkt per SQL über Millionen von Zeilen leisten, ohne dass ein eigener Würfel gebaut und gepflegt werden muss. Entscheidend ist weniger die Frage MOLAP gegen Columnar als die Trennung zwischen transaktionaler und analytischer Verarbeitung, die in beiden Varianten erhalten bleibt.

Was ist MDX und wie unterscheidet es sich von SQL?

MDX (Multidimensional Expressions) ist eine von Microsoft Ende der 1990er-Jahre eingeführte Abfragesprache, die speziell für multidimensionale Strukturen wie OLAP-Würfel entwickelt wurde. Während SQL auf relationale Tabellen mit Zeilen und Spalten ausgerichtet ist, adressiert MDX Dimensionen, Hierarchien und Kennzahlen (Measures) und liefert mehrdimensionale Ergebnismengen zurück. MDX hat sich als verbreiteter Standard etabliert und wird unter anderem von Microsoft Analysis Services genutzt; auch Excel-PivotTables greifen im Hintergrund über MDX auf Cube-Daten zu. Die Sprache ersetzt SQL nicht, sondern ergänzt es für analytische Fragestellungen.

Welche Werkzeuge und Anbieter werden für OLAP-Analysen eingesetzt?

Im Markt finden sich sowohl in ERP- und Data-Warehouse-Suiten integrierte Analysemodule als auch eigenständige BI- und OLAP-Werkzeuge. Häufig genannt werden etwa Microsoft Analysis Services, SAP-BI-Lösungen (etwa BW/HANA), Oracle Essbase sowie Open-Source-Lösungen wie Apache Kylin; im Self-Service-Bereich kommen Werkzeuge wie Power BI, Tableau oder Looker hinzu. Diese Nennungen dienen der Veranschaulichung und stellen keine Wertung oder Empfehlung dar. Welches Werkzeug passt, richtet sich nach der vorhandenen Datenarchitektur, dem benötigten Datenmodell und dem geplanten Pflegeaufwand und sollte herstellerneutral anhand der eigenen Anforderungen geprüft werden.