Stammdaten integrieren: Warum eine Artikelnummer nicht automatisch ein stabiler Schlüssel ist
Eine Artikelnummer erscheint häufig eindeutig, solange nur ein einzelnes System betrachtet wird. Bei Migrationen, Firmenzusammenführungen oder angebundenen Lieferanten kann dieselbe Nummer jedoch mehrfach vorkommen. Wirtschaftsinformatik trennt deshalb zwischen fachlich verwendeten Kennungen und technischen Identitäten. Ein sauberer Schlüsselentwurf verhindert, dass eine Umbenennung unbemerkt eine neue Identität erzeugt.
Eindeutigkeit braucht einen Geltungsbereich
Die Nummer 4711 kann im eigenen Warenwirtschaftssystem ein Ersatzteil und beim Lieferanten eine Verpackung bezeichnen. Erst die Kombination aus Nummer und zuständigem Nummernraum macht den Bezug eindeutig. Dazu können Organisation, Quellsystem oder Produktkatalog gehören. Diese Informationen sollten in einer Zuordnungstabelle ausdrücklich geführt werden. Eine stillschweigende Annahme wie „Nummern sind überall einmalig“ funktioniert häufig nur bis zur ersten zusätzlichen Datenquelle und verursacht dann schwer erklärbare Fehlzuordnungen.
Identität von Bezeichnung trennen
Ein stabiler interner Schlüssel kann Beziehungen erhalten, wenn sich eine sichtbare Artikelnummer oder Beschreibung ändert. Die neue Bezeichnung wird dann als Eigenschaft derselben Entität behandelt. Das bedeutet nicht, dass technische Schlüssel fachliche Prüfung ersetzen. Zwei verschiedene Datensätze können weiterhin dasselbe reale Objekt meinen. Die Frage nach Dubletten ist eine Frage der Identitätsklärung; sie lässt sich nicht allein dadurch beantworten, dass beide Zeilen unterschiedliche technische Kennungen besitzen.
Zusammenführen hat Folgen
Werden zwei Artikelstämme zusammengeführt, hängen daran Bestellungen, Lagerbestände, Dokumente und externe Referenzen. Ein bloßes Überschreiben der Nummer reicht deshalb nicht. Vorab ist zu klären, welche Identität bestehen bleibt, welche Beziehungen angepasst werden und wie frühere Kennungen weiterhin auflösbar sind. Sinnvoll ist ein nachvollziehbares Register alter und neuer Zuordnungen. Dadurch bleiben alte Belege interpretierbar, ohne die frühere Nummer als dauerhaft gültige Hauptnummer weiterführen zu müssen.
Nicht nur positive Fälle testen
Ein Integrationstest sollte Umbenennung, Wiederverwendung einer Nummer, mehrere Lieferantennummern und echte Dubletten unterscheiden. Auch Löschung oder Stilllegung eines Artikels darf keine verwaisten Verweise erzeugen. Datenbankregeln können eindeutige Schlüssel und gültige Referenzen absichern, aber die fachliche Entscheidung über Gleichheit nicht vollständig automatisieren. Dafür braucht es definierte Merkmale und Verantwortliche. Der Nutzen eines guten Schlüsselmodells zeigt sich besonders dann, wenn das Unternehmen seine Organisationsstruktur oder seine Systemlandschaft verändert.
Bei einer Migration sollte außerdem feststehen, wie unbekannte Kennungen behandelt werden. Eine fehlende Zuordnung darf nicht automatisch einen neuen Artikel erzeugen, wenn dadurch bereits vorhandene Identitäten unbemerkt verdoppelt würden.
Integrating master data: Why an item number is not automatically a stable key
An item number often appears unique while only one system is considered. During migrations, company integrations or supplier connections, however, the same number can occur more than once. Business information systems therefore distinguish identifiers used in everyday operations from technical identities. A sound key design prevents a simple renaming from accidentally creating a different identity.
Uniqueness needs a scope
The number 4711 might identify a spare part in an internal inventory application and a packaging material in a supplier's catalogue. Combining the number with the responsible namespace establishes its meaning. That scope may include an organisation, source system or product catalogue. A mapping table should record these details explicitly. Assuming that numbers are globally unique frequently works only until the first additional source is introduced, when unexplained matches and incorrect references begin to appear.
Separate identity from description
A stable internal key can preserve relationships when the visible item number or description changes. The new description then becomes a property of the same entity. Technical keys do not, however, replace business validation. Two distinct records may still refer to the same real-world object. Resolving duplicates requires a decision about identity. The fact that both rows have different technical identifiers does not by itself prove that they represent different items or should remain separate.
Merging has consequences
When two item records are merged, purchase orders, inventory, documents and external references may depend on them. Merely overwriting a number is therefore insufficient. The design must establish which identity survives, which relationships change and how earlier identifiers can still be resolved. A traceable register of old and new mappings is useful. It allows historical documents to remain interpretable without requiring every former identifier to continue indefinitely as the item's current primary number.
Test more than successful matches
Integration tests should distinguish renaming, reuse of a number, several supplier numbers and genuine duplicate records. Deactivating or deleting an item must not leave orphaned references. Database constraints can enforce unique keys and valid references, but cannot fully automate the business decision that two records are equivalent. Explicit comparison criteria and responsible owners are needed. The value of a good identity model becomes particularly apparent when an organisation changes its structure or connects additional operational systems.
A migration should also define how unknown identifiers are handled. A missing mapping must not automatically create a new item when doing so would silently duplicate an identity that already exists in the destination system.