Im Altsystem steht der Kunde einmal in der Stammtabelle. Dazu gibt es zwei Anschriften und drei Ansprechpartner in eigenen Tabellen. Werden alle drei Tabellen ungeprüft miteinander verbunden, entstehen für denselben Kunden plötzlich sechs Ergebniszeilen. Die Importdatei ist gefüllt – aber ihre Mengen und Beziehungen sind falsch.
Mehrere SQL-Tabellen in eine ERP-Importdatei umzuwandeln bedeutet deshalb nicht, möglichst viele Spalten in einer großen Abfrage nebeneinanderzustellen. Zuerst muss feststehen, welche fachliche Einheit eine Zielzeile darstellt. Anschließend werden Quelltabellen, Beziehungen und Wiederholungen so aufbereitet, wie das Migrationsobjekt des neuen ERP sie tatsächlich erwartet.
Ein Join – also die Verbindung von Tabellen über gemeinsame Schlüssel – ist dafür ein wichtiges Werkzeug. Ob das Ergebnis migrationsfähig ist, entscheidet jedoch nicht die SQL-Syntax. Entscheidend sind Zielstruktur, fachliche Beziehungen und nachgewiesene Mengen.
Mehrere SQL-Tabellen in eine ERP-Importdatei umwandeln: Zuerst die Zielzeile verstehen
Bevor Quelltabellen verbunden werden, braucht das Projekt eine einfache Antwort: Was repräsentiert genau eine Zeile im Ziel?
Bei einem Kundenstamm kann eine Zeile die allgemeinen Kundendaten darstellen. Anschriften und Ansprechpartner können dagegen eigene Zeilen in getrennten Tabellenblättern, Segmenten oder Dateien benötigen. Eine Stücklistenposition steht wiederum nicht für die gesamte Stückliste, sondern für genau eine Komponente innerhalb einer Baugruppe.
Diese Ebene wird auch Granularität genannt. Gemeint ist schlicht, wie fein ein Datensatz beschrieben wird: ein Kunde, eine Kundenadresse, ein Ansprechpartner oder eine einzelne Zuordnung. Wenn Quell- und Zielgranularität nicht zusammenpassen, entstehen Dubletten, verlorene Details oder unzulässige Wiederholungen.
Warum eine breite Ergebnistabelle Beziehungen vervielfachen kann
Das Kundenbeispiel zeigt das typische Risiko einer Mehrfachverbindung:
- ein Kunde in der Haupttabelle,
- zwei zugehörige Anschriften,
- drei zugehörige Ansprechpartner.
Wer Anschriften und Ansprechpartner direkt an dieselbe Kundenzeile hängt, erhält jede Kombination aus beiden Kindtabellen: zwei mal drei, also sechs Zeilen. Weder existieren sechs Kunden noch gehört jeder Ansprechpartner automatisch zu jeder Anschrift.
Eine solche Vervielfachung kann unauffällig bleiben, wenn die Datei nur stichprobenartig geöffnet wird. Sie wird aber spätestens im Ziel zum Problem: Stammsätze werden doppelt angelegt, Mengen summieren sich falsch oder das Importwerkzeug weist nicht eindeutige Schlüssel zurück.
Die Zielstruktur entscheidet zwischen Zusammenführen und Trennen
Das neue ERP kann mehrere Quellinformationen in einer Zielzeile verlangen. Dann ist eine kontrollierte Verbindung sinnvoll. Es kann aber auch eine hierarchische Struktur mit Kopf, Positionen und weiteren abhängigen Segmenten erwarten. In diesem Fall sollten die Quellbeziehungen erhalten und auf mehrere Zielbereiche verteilt werden.
Ein migrationsfähiger Entwurf beantwortet deshalb je Zielbereich:
- Welches Zielobjekt oder Segment wird befüllt?
- Welcher fachliche Schlüssel identifiziert genau eine Zielzeile?
- Welche Quelltabelle liefert den führenden Datensatz?
- Welche zusätzlichen Tabellen liefern einzelne Attribute?
- Welche Tabellen enthalten wiederholbare Kinddatensätze?
- Wie werden Kopf und Kindzeilen im Import miteinander verbunden?
Erst danach wird entschieden, ob eine einzige Datei, mehrere Tabellenblätter oder mehrere aufeinander bezogene Dateien erzeugt werden.
Die führende Quelltabelle legt den erwarteten Umfang fest
Für jeden Export braucht es eine führende Datenmenge. Beim Kundenstamm kann das die Tabelle der migrationsrelevanten Kunden sein. Alle weiteren Informationen werden kontrolliert dazu ergänzt.
Diese Entscheidung liefert zugleich den ersten Mengennachweis. Wenn 8.240 Kunden im festgelegten Umfang liegen, sollte die allgemeine Kundenausgabe nicht nach mehreren Joins plötzlich 12.600 Zeilen enthalten. Eine Abweichung kann fachlich begründet sein, muss dann aber zur Zielgranularität passen.
Der Umfang sollte außerdem vor dem Join gefiltert werden. Sonst ziehen abhängige Tabellen möglicherweise historische oder nicht migrationsrelevante Datensätze zurück in die Ausgabe.
Inner Join und Left Join haben unterschiedliche Folgen
Ein Inner Join liefert nur Datensätze, für die auf beiden Seiten eine passende Beziehung gefunden wurde. Fehlt bei einem migrationsrelevanten Kunden eine optionale Zusatzinformation, kann der gesamte Kunde dadurch aus der Ausgabe verschwinden.
Ein Left Join behält alle Datensätze der führenden linken Tabelle und ergänzt passende Werte aus der rechten Tabelle. Fehlt die Zusatzinformation, bleiben deren Felder leer. Das ist für optionale Angaben oft näher an der benötigten Logik – aber nicht automatisch richtig. Ein leeres Pflichtfeld muss weiterhin als Fehler sichtbar werden.
Welcher Join benötigt wird, ergibt sich deshalb aus der fachlichen Regel:
- Ist die Beziehung für jeden Zielkopf zwingend vorhanden?
- Darf die Zusatzinformation fehlen?
- Soll ein fehlender Bezug den Datensatz ausschließen oder einen Befund erzeugen?
- Kann es mehrere passende Kinddatensätze geben?
Eins-zu-viele-Beziehungen nicht in eine Kopfzeile pressen
Eine Eins-zu-viele-Beziehung liegt vor, wenn ein Stammsatz mehrere zugehörige Datensätze besitzt – etwa ein Material mit mehreren Verkaufseinheiten oder ein Kunde mit mehreren Bankverbindungen.
Für solche Beziehungen gibt es je nach Zielstruktur drei saubere Möglichkeiten:
- Eigenes Zielsegment: Jede Kindzeile wird mit dem Schlüssel des Zielkopfs ausgegeben.
- Bewusste Auswahl: Eine fachliche Regel bestimmt genau einen Datensatz, beispielsweise die als Hauptanschrift bestätigte Adresse.
- Regelbasierte Verdichtung: Mehrere Quellzeilen werden zu einem Zielwert zusammengefasst, wenn das Ziel dies fachlich vorsieht.
Ungeeignet ist eine zufällige Auswahl wie „erste gefundene Zeile“. Ohne eindeutige Sortierung und fachliche Priorität kann bei jedem Lauf eine andere Information in der Importdatei landen.
Fehlende Fremdschlüssel verlangen einen belegten Ersatzweg
Alte ERP-Datenbanken enthalten nicht immer sauber definierte Fremdschlüssel. Ein Fremdschlüssel ist ein Feld, das einen Datensatz eindeutig mit einem Datensatz in einer anderen Tabelle verbindet. Fehlt diese technische Definition, kann die fachliche Beziehung trotzdem vorhanden sein.
Dann wird sie über mehrere Belege rekonstruiert: wiederkehrende Schlüsselwerte, passende Datentypen, gemeinsame Verwendung in Anwendungsmasken, vorhandene Indizes, Quellcode oder Berichte und schließlich reale Stichproben. Der Beitrag zum Finden und Belegen relevanter ERP-Tabellen beschreibt diesen Analyseschritt ausführlich.
Eine Beziehung darf nicht allein deshalb verwendet werden, weil zwei Spalten ähnlich heißen. Vor der produktiven Transformation muss gezeigt werden, dass sie für die ausgewählten Daten vollständig, eindeutig und fachlich plausibel ist.
Ein stabiler Migrationsschlüssel verbindet getrennte Zielbereiche
Wenn das Importformat Kopf- und Kinddaten trennt, benötigen alle Ausgaben einen stabilen Bezug. Das kann eine beibehaltene Alt-ID, eine bestätigte neue Nummer oder ein eigens für den Migrationslauf erzeugter technischer Schlüssel sein.
Wichtig sind drei Eigenschaften:
- Der Schlüssel ist innerhalb des vorgesehenen Datenobjekts eindeutig.
- Er wird in jedem wiederholten Lauf nach derselben Regel erzeugt.
- Er bleibt von Quelle über Importdatei bis zum Zielnachweis nachvollziehbar.
Eine laufende Excel-Zeilennummer erfüllt diese Anforderungen selten. Sobald sortiert, gefiltert oder eine Zeile ergänzt wird, verschiebt sich die Zuordnung.
Die Transformation sollte einen klaren Zielaufbau erzeugen
Eine gut strukturierte SQL-Aufbereitung trennt Analyse, Auswahl, Beziehungen und Zielausgabe. Praktisch kann der Ablauf so aussehen:
- migrationsrelevante Schlüssel in einer klaren Ausgangsmenge bestimmen,
- benötigte Quelltabellen auf diese Schlüssel begrenzen,
- eindeutige Attribute kontrolliert ergänzen,
- wiederholbare Kinddaten separat aufbereiten,
- Werte und Formate nach den freigegebenen Mappingregeln transformieren,
- jede Zieltabelle oder jedes Zielsegment in der vorgeschriebenen Spaltenreihenfolge ausgeben und
- parallel Mengen-, Ausnahme- und Beziehungsnachweise erzeugen.
Ob dafür SQL-Abfragen, Views, ein ETL-Werkzeug oder eine andere kontrollierte Technik eingesetzt wird, hängt vom Projekt ab. Der entscheidende Maßstab ist, dass der vollständige Lauf aus denselben Eingaben und Regeln wiederholbar erzeugt werden kann.
Wie aus einer solchen Aufbereitung eine technisch saubere Datei wird, zeigt der Beitrag CSV für den ERP-Import umwandeln.
Sieben Prüfungen schützen vor falschen Joins
- Ausgangsmenge: Wie viele führende Stammsätze liegen im beschlossenen Umfang?
- Eindeutigkeit: Bleibt der vorgesehene Zielschlüssel pro Zielzeile eindeutig?
- Vervielfachung: Welche Joins erhöhen die Zeilenzahl – und entspricht das einer echten Ziel-Kindzeile?
- Verlust: Welche führenden Datensätze verschwinden durch eine Verbindung oder einen Filter?
- Verwaiste Kinddaten: Welche Anschriften, Positionen oder Zuordnungen besitzen keinen gültigen Zielkopf?
- Summen und Verteilungen: Stimmen relevante Mengen, Werte und Häufigkeiten vor und nach der Transformation?
- Fachliche Stichprobe: Sind bei bekannten Beispielen alle Beziehungen im Ziel korrekt nutzbar?
Diese Prüfungen sollten nicht erst nach dem Import stattfinden. Ein Teil lässt sich bereits direkt gegen die SQL-Ergebnisse ausführen. So wird eine falsche Vervielfachung erkannt, bevor sie zur vermeintlich fertigen Migrationsdatei wird.
Typische Fehlversuche beim Zusammenführen von ERP-Tabellen
- Alle Tabellen mit einer großen Abfrage verbinden: unterschiedliche Granularitäten vervielfachen sich.
- Jeden Join als Inner Join schreiben: Stammsätze ohne optionale Zusatzinformation verschwinden.
- Ähnlich benannte Felder als Beziehung verwenden: technisch passende Werte bilden nicht zwingend denselben fachlichen Schlüssel.
- Pro Gruppe irgendeine erste Zeile auswählen: das Ergebnis ist nicht fachlich begründet und kann zwischen Läufen wechseln.
- Kinddaten in Textfelder zusammenkleben: Struktur und spätere Prozessnutzung gehen verloren.
- Nur die Dateizeilenzahl prüfen: verlorene und vervielfachte Datensätze können sich rechnerisch ausgleichen.
Wer entscheidet über die richtige Zielzeile?
Das Zielsystemteam stellt Struktur, Pflichtfelder, Segmente und Importreihenfolge bereit. Fachbereiche bestätigen, welche Quellinformationen dieselbe Bedeutung besitzen und welche Kinddatensätze fachlich relevant sind. Die technische Datenmigration analysiert Quelltabellen und Beziehungen, entwickelt die ausführbare Aufbereitung und liefert Mengen- sowie Beziehungsnachweise.
Externe Unterstützung kann genau die Lücke zwischen Datenbank und Importvorlage schließen: Tabellenbeziehungen ermitteln, die Zielgranularität in reproduzierbare SQL-Ausgaben übersetzen, Vervielfachungen sichtbar machen und die fertigen Zielbereiche mit prüfbaren Schlüsseln erzeugen.
Die richtige Importdatei beginnt mit dem richtigen Datenmodell
Mehrere Quelltabellen lassen sich technisch schnell verbinden. Eine migrationsfähige Datei entsteht aber erst, wenn jede Zielzeile eine klar definierte fachliche Einheit darstellt und alle Beziehungen in der vom Zielsystem erwarteten Form erhalten bleiben.
Wenn Ihre SQL-Abfrage plötzlich mehr Datensätze liefert als erwartet oder unklar ist, wie Kopf-, Positions- und Zusatzdaten in die ERP-Vorlage gehören, prüfen wir mit Ihnen Quellmodell, Zielstruktur und Joinlogik. Anschließend kann daraus ein wiederholbarer Export mit sichtbaren Mengen-, Eindeutigkeits- und Beziehungsprüfungen entstehen.
So werden nicht einfach mehrere Tabellen zusammengezogen. Sie werden zu einem belastbaren Migrationsobjekt aufgebaut.