OLAP und OLTP – der Unterschied einfach erklärt

Wer sich mit Datenarchitekturen beschäftigt, stösst früh auf zwei Abkürzungen: OLAP und OLTP. Beide beschreiben, wie Systeme mit Daten umgehen – aber mit grundlegend verschiedenen Zielen. In diesem Artikel erklären wir den Unterschied, zeigen konkrete Beispiele aus Industrie und Verkehr und ordnen ein, wie moderne Plattformen die beiden Welten zusammenführen.

Was ist OLTP?

OLTP steht für Online Transaction Processing und beschreibt Systeme, die operative Geschäftsprozesse in Echtzeit abwickeln. Jedes Mal, wenn eine Buchung ausgelöst, ein Auftrag erfasst oder ein Sensorwert geschrieben wird, ist ein OLTP-System im Spiel.

Typische Merkmale von OLTP-Systemen:

• Viele kurze Transaktionen: Tausende einfache Lese- und Schreibvorgänge pro Sekunde – etwa das Erfassen einer Bestellung oder das Aktualisieren eines Lagerbestands.
• Echtzeitanforderung: Antwortzeiten im Millisekundenbereich sind essenziell. Wenn ein Fahrgast am Automaten ein Ticket kauft, muss die Transaktion sofort abgeschlossen sein.
• Aktuelle Daten: OLTP-Systeme speichern den aktuellen Zustand – den heutigen Lagerbestand, den aktuellen Maschinenstatus, den letzten Sensorwert.
• Normalisierte Datenstruktur: Daten werden redundanzfrei gespeichert, um Inkonsistenzen zu vermeiden.

Beispiele für OLTP-Systeme: ERP-Systeme (SAP, Microsoft Dynamics), MES-Systeme in der Produktion, Ticketing-Systeme im ÖV, SCADA-Systeme für Anlagensteuerung, CRM-Systeme.

In unserer Arbeit begegnen uns OLTP-Systeme vor allem in Form von operativen Datasystems – Systeme, die den Betrieb am Laufen halten und dabei kontinuierlich Daten erzeugen.

Was ist OLAP?

OLAP steht für Online Analytical Processing und beschreibt Systeme, die auf die Analyse grosser Datenmengen ausgelegt sind. Während OLTP den Betrieb steuert, hilft OLAP, den Betrieb zu verstehen.

Typische Merkmale von OLAP-Systemen:

• Komplexe Abfragen: Statt «Wie hoch ist der Lagerbestand von Produkt X?» beantwortet OLAP Fragen wie «Wie haben sich unsere Ausschussraten pro Produktionslinie und Quartal über die letzten drei Jahre entwickelt?»
• Historische Daten: OLAP-Systeme speichern nicht nur den aktuellen Stand, sondern die gesamte Historie – oft über Jahre hinweg.
• Asynchrone Verarbeitung: Daten fliessen periodisch oder in Near-Realtime aus den OLTP-Quellsystemen ein. Ob eine Auswertung 2 oder 20 Sekunden dauert, ist selten geschäftskritisch.
• Denormalisierte Datenstruktur: Daten werden bewusst redundant gespeichert, um Abfragen zu beschleunigen.

Beispiele für OLAP-Systeme: Data Warehouses, Business-Intelligence-Plattformen wie Power BI, analytische Datenbanken in Microsoft Fabric oder Snowflake.

Das klassische OLAP-Szenario ist ein BI-Dashboard, das Kennzahlen aus verschiedenen Quellsystemen konsolidiert und für Entscheidungsträger aufbereitet.

OLAP vs. OLTP – der direkte Vergleich

Auf den Punkt gebracht: OLTP-Systeme erzeugen die Daten, OLAP-Systeme machen sie nutzbar. In der Praxis brauchen Unternehmen beides – und eine saubere Verbindung dazwischen.

Wie hängen OLAP und OLTP zusammen?

Die beiden Systeme sind keine Alternativen, sondern arbeiten zusammen. Der typische Datenfluss sieht so aus:

OLTP-Systeme (ERP, MES, Sensoren) → Data Pipeline (ETL/ELT) → Data Warehouse oder Data Lake (OLAP) → Dashboards, Berichte, KI-Modelle

Daten entstehen in den operativen Systemen und werden über automatisierte Data Pipelines in ein analytisches System übertragen. Dort werden sie bereinigt, historisiert und für Analysen bereitgestellt. Dieser Prozess – Extrahieren, Transformieren, Laden – ist das Rückgrat jeder modernen Datenarchitektur.

Ein konkretes Beispiel: Bei den Basler Verkehrs-Betrieben (BVB) fliessen operative Daten aus dem Fahrbetrieb über dbt und Microsoft Fabric in eine zentrale Analyseplattform. Die OLTP-Systeme steuern den Betrieb. Die OLAP-Schicht darüber macht die Daten auswertbar.

OLAP und OLTP in Industrie und Verkehr

Die Unterscheidung zwischen OLAP und OLTP ist überall relevant, aber in datenintensiven Branchen wie Industrie & Logistik und öffentlichem Verkehr wird sie besonders spürbar – weil hier physische Systeme (Maschinen, Fahrzeuge, Sensoren) permanent Daten erzeugen.

In der Produktion

OLTP-Seite: Eine SPS schreibt alle 100 Millisekunden Temperatur-, Druck- und Vibrationswerte. Ein MES-System erfasst Auftragsstart und -ende. Ein BDE-Terminal registriert Stillstandsgründe. Das sind klassische Transaktionen – hochfrequent, zeitkritisch, operativ.

OLAP-Seite: Ein Produktionsleiter will wissen, welche Maschine die höchste Ausfallrate hatte, welche Stillstandsgründe am häufigsten vorkommen und ob sich der OEE-Wert im Vergleich zum Vorquartal verbessert hat. Dafür braucht er ein System, das Millionen von Transaktionen aggregieren und über Zeiträume vergleichen kann.

Genau diese Verbindung – vom OLTP-Shopfloor zur OLAP-Analyse – beschreiben wir im Detail in unserem Artikel Vom Shopfloor zum Insight. Die zugrundeliegende Architektur erklären wir in Manufacturing Data Architecture.

Im öffentlichen Verkehr

OLTP-Seite: Ein Fahrzeug meldet seinen GPS-Standort. Ein Weichensensor registriert einen Schaltvorgang. Ein Ticketautomat verarbeitet einen Kauf. Alles Echtzeit-Transaktionen.

OLAP-Seite: Die Betriebsleitung will wissen, wie sich die Pünktlichkeit über die letzten 12 Monate entwickelt hat, welche Linien am stärksten von Störungen betroffen sind und wo sich Predictive Maintenance lohnt. Dazu müssen Millionen operativer Datenpunkte analytisch aufbereitet werden.

Wie das auf einer modernen Plattform zusammenkommt, beschreiben wir in Microsoft Fabric für Verkehrsunternehmen.

Warum die Trennung wichtig ist

Wer versucht, analytische Abfragen direkt auf operativen Systemen laufen zu lassen, riskiert Performance-Probleme im Betrieb. Eine komplexe Reporting-Abfrage kann ein MES oder ERP-System so stark belasten, dass operative Prozesse verlangsamt werden. Deshalb ist die saubere Trennung zwischen OLTP und OLAP nicht nur eine akademische Frage, sondern ein architektonischer Grundsatz.

Moderne Plattformen: Wenn OLAP und OLTP verschmelzen

Traditionell waren OLAP und OLTP strikt getrennte Systeme. In den letzten Jahren verwischen diese Grenzen zunehmend:

Lakehouse-Architekturen kombinieren die Flexibilität eines Data Lakes (Rohdaten in allen Formaten) mit der Abfrage-Performance eines Data Warehouses (strukturierte, optimierte Daten). Plattformen wie Microsoft Fabric oder Snowflake ermöglichen beides auf derselben Infrastruktur. Wir beleuchten dieses Thema ausführlich in unserem zweiteiligen Artikel Data Warehouse oder Lakehouse für Industrie 4.0.

Streaming-Architekturen ermöglichen Near-Realtime-Analysen. Anstatt Daten periodisch per Batch in ein OLAP-System zu laden, fliessen sie kontinuierlich – was die Grenze zwischen «operativ» und «analytisch» weiter aufweicht.

HTAP (Hybrid Transactional/Analytical Processing) ist ein Ansatz, bei dem ein einzelnes System sowohl Transaktionen als auch Analysen effizient abwickeln kann. Noch nicht überall praxistauglich, aber ein klarer Trend.

Für die meisten Schweizer Industrie- und Verkehrsunternehmen bleibt die Empfehlung dennoch klar: OLTP und OLAP bewusst trennen, mit einer sauberen Data Pipeline dazwischen. Das schafft Stabilität im Betrieb und Flexibilität in der Analyse.

Wo anfangen?

Wenn Sie gerade vor der Frage stehen, wie Sie Ihre operativen Daten analytisch nutzbar machen können, empfehlen wir drei Einstiegspunkte:

Standort bestimmen: Unsere Datenmaturitätsanalyse zeigt Ihnen in 10 Minuten, wie reif Ihre Organisation im Umgang mit Daten ist – kostenlos.

Datenlandschaft verstehen: Mit einer Datenlandkarte erfassen Sie, welche OLTP-Systeme welche Daten erzeugen und wo analytische Lücken bestehen. So haben wir es bei PUBLICA gemacht.

Strategie formulieren: Eine Datenstrategie definiert, welche Daten in welchem System landen sollen und wie OLTP und OLAP zusammenspielen. Ein gutes Beispiel ist die Datenstrategie der Stadt Luzern.

Sie möchten Ihre operativen Daten analytisch erschliessen? Kontaktieren Sie uns – wir zeigen Ihnen, wie OLAP und OLTP in Ihrer Organisation zusammenfinden.

Weiterführende Glossar-Einträge

• Was ist ein Data Warehouse? – Das klassische OLAP-System im Detail
• Was ist ein Data Lake? – Rohdaten flexibel speichern
• Data Pipeline – Die Brücke zwischen OLTP und OLAP
• dbt + Microsoft Fabric – Modernes Data Engineering
• Manufacturing Data Architecture – Vom Sensor zur Entscheidung
• Vom Shopfloor zum Insight – Wie Produktionsdaten analytisch nutzbar werden
• Data Warehouse oder Lakehouse? – Welche Architektur passt?
• Big Data – Wenn die Datenmenge OLAP-Systeme herausfordert
• Data Governance – Qualität über OLTP und OLAP hinweg sichern