6. Integration von Informationssystemen

Integration von Informationssystemen

Daten liegen selten in einem einzigen System. Ein Betrieb hat eine Warenwirtschaft, eine Tabellenkalkulation, eine Webanwendung, dazu Schnittstellen zu Lieferanten und Ämtern. Damit diese Systeme zusammenspielen, müssen Daten zwischen ihnen ausgetauscht, umgewandelt und dargestellt werden. Das ist der Kern der Integration von Informationssystemen und der Abschluss dieses Jahrgangs.

Dieses Kapitel bündelt vieles aus dem Jahr: die Formate aus Kapitel 5, das analytische Denken aus OLAP & Data Warehousing und die Schnittstellen aus der 4. Klasse. Am Ende steht die Frage, wie aus verteilten Rohdaten eine nutzbare Aussage wird.

Warum überhaupt integrieren?

Historisch wächst jede Organisation zu einer Landschaft aus Insellösungen: Jede Abteilung schafft sich das System an, das ihr Problem löst. Der Vertrieb pflegt Kundendaten in einem System, die Buchhaltung in einem anderen, die Produktion in einem dritten. Dieselbe Kundin steht dann dreimal in leicht abweichender Form da.

Integration bekämpft die Folgen dieser Zersplitterung:

• Redundanz — dieselben Daten mehrfach gepflegt, mit dem ständigen Risiko, dass sie auseinanderlaufen.
• Medienbrüche — Daten werden von Hand aus einem System ins nächste übertragen (abgetippt), langsam und fehleranfällig.
• Kein Gesamtbild — Fragen, die mehrere Systeme betreffen („Welche Region ist am profitabelsten?”), lassen sich nicht beantworten, solange die Daten getrennt bleiben.

Ziel ist ein konsistenter, gemeinsam nutzbarer Datenbestand, ohne dass jedes System sein eigenes aufgibt.

Wege der Integration

Wie Daten von A nach B kommen, lässt sich grob in drei Muster einteilen:

Weg	Prinzip	Wann sinnvoll
Dateiaustausch	Ein System exportiert eine Datei, ein anderes importiert sie	einfacher, zeitversetzter Austausch (nächtlicher Export)
Schnittstelle (API)	Systeme fragen sich gegenseitig live über das Netzwerk ab	aktuelle Daten, Kommunikation zwischen Anwendungen
Gemeinsame Datenbank	Mehrere Anwendungen greifen auf denselben Datenspeicher zu	eng gekoppelte Systeme unter einer Kontrolle

Quer dazu steht die Frage nach dem Zeitverhalten:

• Batch (Stapelverarbeitung): Daten werden gesammelt und in Blöcken übertragen, etwa jede Nacht. Einfach und robust, aber die Daten sind nie ganz aktuell.
• Echtzeit (real-time / streaming): Jede Änderung wird sofort weitergegeben. Aktuell, aber aufwendiger und störanfälliger.

ETL als Sonderfall

Das im OLAP-Kapitel beschriebene ETL (Extract, Transform, Load) ist ein durchstrukturierter Integrationsablauf: Daten werden aus Quellsystemen gezogen (extract), umgewandelt und bereinigt (transform) und in ein Zielsystem geladen (load). Diese drei Schritte tauchen im Kapitel als Export, Konvertierung und Import wieder auf.

Datenimport und -export

Der klassische Weg läuft über Dateien in einem gemeinsamen Format. Ein System exportiert seine Daten, ein anderes importiert sie. Die verbreitetsten Formate:

• CSV: einfache Tabellen als Textzeilen mit Trennzeichen. Von praktisch jedem System lesbar, aber ohne Typen und ohne Struktur über die Tabelle hinaus.
• JSON / XML: semistrukturierte Formate (siehe Kapitel 5) für verschachtelte Daten und den Austausch mit Web-Schnittstellen.
• SQL-Dump: eine Datei aus INSERT-Anweisungen (und dem Schema), mit der sich eine Datenbank in einer anderen Datenbank desselben Typs wiederherstellen lässt.

In der Praxis exportiert man etwa aus PostgreSQL eine Tabelle als CSV und liest sie anderswo wieder ein:

Export

-- Write a table to a CSV file, first row as header
COPY kunden TO '/tmp/kunden.csv' WITH (FORMAT csv, HEADER);

-- Export only a selection via a query
COPY (SELECT id, name, ort FROM kunden WHERE aktiv)
  TO '/tmp/aktive_kunden.csv' WITH (FORMAT csv, HEADER);

Import

-- Read a CSV file back into a table
COPY kunden FROM '/tmp/kunden.csv' WITH (FORMAT csv, HEADER);

Ein SQL-Dump entsteht auf der Kommandozeile und eignet sich für vollständige Sicherungen oder Umzüge:

# Export the whole database into a portable SQL script
pg_dump meine_db > backup.sql

# Restore it into another database of the same type
psql neue_db < backup.sql

Die Tücken von CSV

CSV sieht harmlos aus, macht aber oft Ärger: unterschiedliche Trennzeichen (Komma vs. Semikolon — im deutschsprachigen Raum wegen des Dezimalkommas oft Semikolon), Zeichenkodierung (UTF-8 vs. Windows-1252, was zu Zeichen wie „ü” statt „ü” führt), Datumsformate (2026-07-29 vs. 29.07.2026) und Werte, die selbst Kommas, Anführungszeichen oder Zeilenumbrüche enthalten. Beim Import lohnt es sich, diese Punkte zuerst zu prüfen.

Datenkonvertierung

Zwei Systeme sprechen selten dasselbe Format. Bei der Konvertierung wandelt man Daten von einer Form in eine andere um, ohne ihre Bedeutung zu verändern. Typische Fälle:

• Format wechseln: CSV nach JSON, XML nach CSV, JSON nach SQL.
• Werte vereinheitlichen: Datumsformate, Einheiten (kg vs. g), Währungen, Ländercodes (Österreich vs. AT).
• Struktur anpassen: verschachteltes JSON in flache Tabellenzeilen „ausrollen” oder umgekehrt aus flachen Zeilen verschachtelte Objekte bauen.

Für strukturierte Formate gibt es eigene Werkzeuge: XSLT wandelt XML in andere XML- oder Textformate um, jq verarbeitet JSON (beide aus Kapitel 5). Oft schreibt man aber einfach ein kleines Skript, das die Quelldatei liest, die Werte anpasst und im Zielformat wieder ausgibt. In Python etwa der Weg von JSON zu CSV:

import json, csv

# 1. Read (extract) the source
with open("bestellungen.json", encoding="utf-8") as f:
    orders = json.load(f)

# 2. Convert (transform): flatten and normalize each record
rows = []
for o in orders:
    rows.append({
        "id":     o["id"],
        "datum":  o["created_at"][:10],          # ISO timestamp -> just the date
        "kunde":  o["customer"]["name"],          # pull a value out of a nested object
        "betrag": round(o["amount_cents"] / 100, 2)  # cents -> euro
    })

# 3. Write (load) the target
with open("bestellungen.csv", "w", newline="", encoding="utf-8") as f:
    writer = csv.DictWriter(f, fieldnames=["id", "datum", "kunde", "betrag"])
    writer.writeheader()
    writer.writerows(rows)

Man erkennt darin dieselben drei Schritte wie bei ETL: lesen, umwandeln, schreiben.

Portable Datenformate

Ein portables Datenformat ist so aufgebaut, dass es unabhängig von einem bestimmten Programm gelesen werden kann. CSV, JSON und XML sind portabel; ein proprietäres Binärformat einer einzelnen Anwendung ist es nicht. Für den langfristigen Austausch und die Archivierung wählt man portable, offen dokumentierte Formate — sonst sind die Daten irgendwann nur noch mit einer Software lesbar, die es vielleicht nicht mehr gibt.

Schnittstellen über APIs

Der modernere Weg verzichtet auf Zwischendateien: Systeme fragen sich direkt über das Netzwerk ab. Die verbreitetste Form ist die Web-API, meist als REST über HTTP. Ein System (der Client) schickt eine Anfrage, ein anderes (der Server) antwortet — üblicherweise mit JSON.

GET /api/kunden/42 HTTP/1.1
Host: warenwirtschaft.example.at
Accept: application/json

{
  "id": 42,
  "name": "Andrea Hofer",
  "ort": "Villach",
  "umsatz": 12500.00
}

Die HTTP-Methode sagt, was geschehen soll — GET (lesen), POST (anlegen), PUT/PATCH (ändern), DELETE (löschen). Das entspricht genau den CRUD-Operationen aus dem Datenbankumfeld. So kann ein System die Daten eines anderen abrufen, ohne dessen Datenbank direkt zu kennen — die API ist ein klar definierter Vertrag zwischen beiden.

Warum API statt Datei?

Eine API liefert aktuelle Daten auf Anfrage, statt eines nächtlichen Standes. Sie entkoppelt die Systeme: Solange der Vertrag (welche Felder, welches Format) gleich bleibt, darf jede Seite ihre interne Technik ändern. Und sie erlaubt Rechteprüfung — die API entscheidet, wer welche Daten sehen darf. Der Preis: Beide Systeme müssen gleichzeitig laufen und erreichbar sein.

Datenqualität

Zwischen den Systemen entstehen fast immer Qualitätsprobleme, die vor der Weiterverarbeitung behoben werden müssen — sonst gilt: „garbage in, garbage out”. Typische Fälle und ihre Behandlung:

Problem	Beispiel	Gegenmittel
Dubletten	Kundin steht doppelt drin	nach Schlüssel/Ähnlichkeit zusammenführen
Fehlende Werte	kein Ort angegeben	Standardwert, Nachfrage oder Datensatz verwerfen
Uneinheitliche Formate	AT, Österreich, Austria	auf eine Schreibweise normalisieren
Ungültige Werte	negativer Preis, Datum in der Zukunft	gegen ein Schema prüfen (Kapitel 5)

Deshalb wird ein importiertes Dokument immer erst validiert, dann verarbeitet. Dafür sind XSD und JSON Schema aus dem vorigen Kapitel da: Sie fangen strukturell falsche Daten an der Grenze ab, bevor sie sich im Zielsystem ausbreiten.

Daten darstellen und interpretieren

Am Ende der Integration steht die Frage, was die Daten eigentlich aussagen. Rohe Zahlen in einer Tabelle beantworten keine Frage; erst eine passende Darstellung macht Zusammenhänge sichtbar.

• Tabellen eignen sich, wenn es auf einzelne, genaue Werte ankommt.
• Diagramme zeigen Zusammenhänge — die Wahl des Typs folgt der Frage:

Diagramm	Gut für	Beispiel
Linie	Verlauf über die Zeit	Umsatz pro Monat
Balken	Vergleich von Kategorien	Umsatz je Region
Kreis	Anteile an einem Ganzen (sparsam!)	Marktanteile
Streuung	Zusammenhang zweier Größen	Preis vs. Absatz

• Kennzahlen (KPIs) verdichten viele Daten zu einer Aussage, etwa Umsatz pro Monat, Zahl aktiver Nutzer oder durchschnittliche Bearbeitungsdauer. Ein Dashboard fasst mehrere solcher Kennzahlen und Diagramme auf einen Blick zusammen.

Zum Interpretieren gehört, kritisch zu bleiben. Dieselben Daten lassen sich so darstellen, dass sie gegensätzliche Eindrücke erzeugen:

• eine abgeschnittene Achse, die kleine Unterschiede dramatisch wirken lässt,
• eine verzerrte Skala oder ungleiche Klassenbreiten,
• herausgepickte Zeiträume (cherry picking), die einen Trend vortäuschen,
• fehlender Bezug — absolute Zahlen ohne Grundgesamtheit.

Eine sachlich korrekte Darstellung soll die Daten klären, nicht ein gewünschtes Ergebnis nahelegen.

Werkzeuge zur Darstellung reichen von der Tabellenkalkulation bis zu spezialisierten BI-Werkzeugen (Business Intelligence) wie Power BI, Tableau oder Metabase, die sich über Schnittstellen (siehe Datenbank-Schnittstellen der 4. Klasse) direkt an die Datenquellen anbinden.

Ein durchgängiges Anwendungsbeispiel

Ein fachbezogenes Beispiel bindet die Themen zusammen. Ein Handelsbetrieb betreibt mehrere Quellsysteme — darunter ein ERP für Bestellungen und Lagerbestände und ein CRM für die Kundenpflege — und will daraus einen wöchentlichen Vertriebsbericht gewinnen:

1. Die Webanwendung und das ERP exportieren ihre Bestellungen nächtlich als JSON bzw. stellen sie über eine API bereit.

2. Ein Skript konvertiert die Daten in flache CSV-Zeilen und vereinheitlicht dabei Datumsformate und Währungen (der Transform-Schritt oben).

3. Vor dem Laden werden die Daten validiert und bereinigt — Dubletten entfernt, fehlende Orte ergänzt, Ländercodes normalisiert.

4. Die bereinigten Daten werden in eine analytische Datenbank importiert und dort mit dem Kundenstamm aus dem CRM verknüpft.

5. Ein Dashboard stellt Umsatz je Region und Monat dar, aus dem das Management abliest, welche Region wächst.

Genau diese Kette — vom Quellsystem über Austauschformate und Konvertierung bis zur Darstellung — ist der Alltag der Integration von Informationssystemen.

ERP und CRM — nur das Beispiel, nicht das Thema

ERP (Enterprise Resource Planning) und CRM (Customer Relationship Management) sind betriebliche Anwendungssysteme: das ERP steuert Ressourcen wie Waren, Aufträge und Finanzen, das CRM die Kundenbeziehungen. Für dieses Kapitel sind sie Quellsysteme — Lieferanten von Daten, die integriert werden. Ihr innerer Aufbau ist Stoff der Wirtschaftsinformatik, nicht des INSY-Lehrplans; hier interessiert nur, wie ihre Daten heraus- und zusammenkommen.

Zusammenfassung

• Organisationen bestehen aus vielen Insellösungen; Integration bekämpft Redundanz, Medienbrüche und das fehlende Gesamtbild.
• Daten wandern über Dateiaustausch, APIs oder eine gemeinsame Datenbank — als Batch (zeitversetzt) oder in Echtzeit; ETL ist der strukturierte Ablauf aus Extract, Transform, Load.
• Systeme tauschen Daten über gemeinsame Formate aus: CSV, JSON/XML und SQL-Dumps; COPY importiert/exportiert in PostgreSQL, pg_dump sichert ganze Datenbanken.
• CSV ist verbreitet, aber tückisch (Trennzeichen, Kodierung, Datumsformate).
• Bei der Konvertierung wird die Form geändert, nicht die Bedeutung; portable Formate sind unabhängig von einem einzelnen Programm und damit archivierbar.
• APIs (meist REST über HTTP mit JSON) liefern aktuelle Daten und entkoppeln die Systeme über einen klaren Vertrag.
• Datenqualität (Dubletten, fehlende/ungültige Werte) wird an der Grenze geprüft: erst validieren, dann verarbeiten.
• Erst die passende Darstellung (Tabelle, Diagramm, KPI, Dashboard) macht Daten aussagekräftig; dabei kommt es auf eine sachlich korrekte, nicht irreführende Aufbereitung an.
• Ein typischer Ablauf verbindet Export, Konvertierung, Bereinigung, Import und Darstellung zu einer durchgängigen Kette — ERP/CRM treten dabei nur als Quellsysteme (Anwendungsbeispiel) auf.