MDM Lite – Benutzerhandbuch

Version: Oktober 2026

Was sich in den einzelnen Releases geändert hat, finden Sie in den Release Notes.

Inhaltsverzeichnis

1. Einstieg & Login
2. Hauptoberfläche verstehen
3. Umgebungen (Test & Produktion)
4. Datasets verwalten
5. Schema definieren
6. Daten bearbeiten
7. Hierarchien abbilden: Tabelle mit Beziehungen oder Baum?
8. Zeitliche Gültigkeit
9. Import (CSV / Excel)
10. Versionierung & Historie
11. Beziehungen zwischen Datasets
12. Export
13. Bereitstellung auf der Datenplattform (Microsoft Fabric) · → Detailliertes Integrationshandbuch
14. KI-Zugriff (MCP)
15. Sensitivitätsklassifizierung & Microsoft Purview
16. API-Keys verwalten
17. E-Mail-Versand konfigurieren
18. Nutzerverwaltung
19. Rollenmodell & Berechtigungen
20. Plattform-Datenbibliothek
21. Häufige Fragen (FAQ)

1. Einstieg & Login

Login

Das MDM Lite verwendet Microsoft Entra ID (Azure AD) zur Anmeldung. Es ist kein separates Passwort notwendig — Sie melden sich mit Ihrem bestehenden Microsoft-Unternehmenskonto an.

1. Die Anwendungs-URL im Browser öffnen
2. Auf „Mit Microsoft anmelden" klicken
3. Unternehmensdaten eingeben (falls nicht bereits angemeldet)
4. Nach erfolgreicher Authentifizierung werden Sie automatisch in Ihren Mandanten weitergeleitet

Mehrere Mandanten (Tenant-Auswahl)

Haben Sie Zugriff auf mehrere Mandanten (oder sind Sie AppAdmin), erscheint nach dem Login eine Mandantenauswahl. Der aktive Mandant wird oben in der Kopfzeile angezeigt; über das Wechsel-Symbol (⇄) lässt sich jederzeit ein anderer Mandant wählen. Beim Wechsel werden die Daten neu geladen — ein Browser-Reload ist nicht nötig.

Das angemeldete Konto sehen Sie rechts oben im Profilmenü.

Erstmaliger Zugriff

Beim ersten Login in einen freigeschalteten Mandanten erhalten Sie automatisch die Rolle Admin, sofern Sie der erste Nutzer sind. Alle weiteren Nutzer müssen von einem Admin eingeladen werden (siehe Nutzerverwaltung).

Falls Sie nach dem Login eine Fehlermeldung sehen, wurde Ihr Mandant noch nicht freigeschaltet — wenden Sie sich an Ihren MDM-Lite-Administrator.

2. Hauptoberfläche verstehen

Die Oberfläche ist in zwei Bereiche aufgeteilt:

┌──────────────────────┬─────────────────────────────────────────┐
│  Dataset Explorer    │  Detail-Bereich                         │
│  (linke Spalte)      │                                         │
│                      │  Tabs: Daten | Spalten | Beziehungen     │
│  [Suche / Filter]    │       Verlauf | Verwaltung | ...        │
│                      │                                         │
│  Ordner-Struktur     │  Inhalt des gewählten Datasets          │
│  ├─ Ordner A         │                                         │
│  └─ Ordner B         │                                         │
│  — Nicht zugeordnet  │                                         │
└──────────────────────┴─────────────────────────────────────────┘

Dataset Explorer (links): Zeigt alle Datasets des Mandanten in einer frei definierbaren Ordnerstruktur. Hier navigieren Sie, erstellen neue Datasets und Ordner.

Dataset-Übersicht (Kacheln/Liste): Wählen Sie einen Ordner, erscheinen dessen Datasets in drei nach Status getrennten Lanes: Veröffentlicht, Entwurf und Archiv. Die Archiv-Lane ist eingeklappt und wird erst auf Klick geladen. Über den Umschalter oben rechts wechseln Sie zwischen Kachel- und Listenansicht (die Wahl wird gespeichert). Datasets mit der Pflegeart „Automatisch geliefert" tragen einen Hinweis auf ihre Pflegeart, und nur wenn sie ihren erwarteten Lieferrhythmus überschreiten, zusätzlich „Lieferung überfällig". Manuell gepflegte Datasets zeigen keinen Hinweis, auch wenn sie lange unverändert sind.

Detail-Bereich (rechts): Zeigt den Inhalt des aktuell ausgewählten Datasets über mehrere Tabs:

Aktionsleiste (Explorer): Am Rand des Explorers liegen feste Symbol-Buttons für: 🌐 Bibliothek (Plattform-Datenbibliothek öffnen), Neuer Ordner, Neues Dataset, Aus Datei erstellen, Bulk-Import und Fabric-Bulk-Sync.

Systemordner „Plattformdaten": Ganz oben im Explorer erscheint immer ein geschützter Ordner 🌐 Plattformdaten (Globus-Icon). Dorthin werden Datensätze aus der Plattform-Datenbibliothek importiert. Dieser Ordner kann nicht umbenannt, verschoben oder gelöscht werden.

Kopfzeile: Rechts oben finden Sie den Sprachumschalter (DE / EN), eine Versionsanzeige (Build-Umgebung + Version) sowie das Profil-/Kontomenü — dort finden Sie auch den Umgebungs-Wechsler.

3. Umgebungen (Test & Produktion)

Ein Mandant kann mehrere Umgebungen enthalten — separate, isolierte Datenräume für z. B. Produktion und Test. Jedes Dataset lebt in genau einer Umgebung; Sie arbeiten immer im Kontext der aktuell gewählten Umgebung, und alle Explorer-Ansichten, die Suche und der Changes-Feed zeigen nur deren Inhalt.

Die Live-Umgebung

Bei der Anlage eines Mandanten existiert automatisch genau eine Umgebung: „Produktion". Sie ist die Live-Umgebung (dauerhaftes „Live"-Badge in der Oberfläche) und damit die Datenquelle für alle externen Abnehmer — DWH-Sync, Changes-Feed, MCP sowie jeden API-Aufruf ohne explizite Umgebungsangabe. Die Live-Umgebung kann weder deaktiviert noch gelöscht werden; ihr Anzeigename ist aber änderbar.

Umgebung wechseln

Im Profil-/Kontomenü (oben rechts) erscheint der Abschnitt „Umgebung" mit allen aktiven Umgebungen (Farbpunkt + Name; die Live-Umgebung trägt zusätzlich das „Live"-Badge, die aktuell gewählte einen Haken). Ein Klick wechselt die Umgebung — Dataset-Explorer, Suche und alle Listen laden sich mit dem Inhalt der neuen Umgebung neu. Ihre Wahl wird pro Mandant im Browser gemerkt.

Hinweis: Arbeiten Sie nicht in der Live-Umgebung, zeigt ein durchgehender farbiger Streifen am oberen Bildschirmrand den Namen der aktiven Umgebung — so ist jederzeit erkennbar, dass Sie sich außerhalb von Produktion befinden. In der Live-Umgebung erscheint kein Banner (Normalzustand, kein Alarm).

Umgebungen verwalten (Admin)

Aufrufen: Einstellungen → Umgebungen (Route /settings/environments). Erforderliche Rolle: Admin.

• Neue Umgebung anlegen: Name eingeben (ein Slug wird automatisch vorgeschlagen) und eine Farbe wählen → „Anlegen". Der Slug ist nach dem Anlegen unveränderlich — er dient als stabile Referenz für API/CI-Aufrufe.
• Umbenennen / Farbe ändern: „Bearbeiten" in der Zeile der gewünschten Umgebung.
• Deaktivieren: Setzt die Umgebung read-only und blendet sie im Umgebungs-Wechsler für Nicht-Admins aus. Reversibel — jederzeit über „Reaktivieren" rückgängig zu machen.
• Löschen: Nur möglich, wenn die Umgebung zuvor deaktiviert wurde. Zur Bestätigung muss der Umgebungsname exakt eingetippt werden; enthält die Umgebung noch Datasets, wird deren Anzahl angezeigt — sie werden inklusive Historie unwiderruflich mitgelöscht.
• Limit: Ein Mandant kann höchstens 10 Umgebungen haben.
• Ist noch keine zweite Umgebung vorhanden, empfiehlt die Seite per Hinweisbanner das Anlegen einer Test-Umgebung (Ein-Klick-Vorschlag: Name „Test", Slug test).

Integrationen und Umgebungen

Mehrere Einstellungen gelten je Umgebung. Oben auf diesen Seiten zeigt eine Kontextzeile, für welche Umgebung Sie gerade arbeiten (Umgebungsname, Farbpunkt, bei Live das „Live"-Badge) und den Satz „Diese Einstellungen gelten nur für die Umgebung „Test". Umgebung wechseln im Benutzermenü." Mandantenweite Seiten (Allgemein, Nutzer & Rollen, Umgebungen, E-Mail) tragen stattdessen den Hinweis „Gilt für alle Umgebungen."

Eine Umgebung liefert nie in das Ziel einer anderen Umgebung und fällt nie auf die Einstellung von Live zurück. Eine neue Umgebung startet ohne Integrationen. Wie Sie die Bereitstellung auf der Datenplattform einrichten, steht unter Bereitstellung je Umgebung einrichten in Kapitel 13.

Deaktivierte Umgebung: Die Bereitstellung läuft weiter, auch der Rückzug von Spalten. Deaktivieren heißt „nur lesbar für Nutzer", nicht „Plattform einfrieren". Einstellungen ändern und manuell synchronisieren können Sie in dieser Zeit nicht (409 environment_inactive). Wollen Sie die Bereitstellung einer deaktivierten Umgebung stoppen, reaktivieren Sie die Umgebung kurz, deaktivieren die Integration und deaktivieren die Umgebung wieder.

Umgebung löschen: MDM Lite löscht mit der Umgebung auch ihre Integrationen samt Zugangsdaten. Der Lösch-Dialog nennt die Zahl der mitgelöschten Integrationen. Tabellen auf der Datenplattform bleiben bestehen und müssen dort manuell entfernt werden.

Dataset zwischen Umgebungen kopieren

Über den Tab „Integration" eines Datasets → „In Umgebung kopieren…" übertragen Sie Schema und Daten der gewählten Version in eine andere Umgebung desselben Mandanten (z. B. Test → Produktion). Erforderlich: mindestens die Rolle Editor.

1. Zielumgebung wählen
2. Modus wählen:

3. Optional Quellversion (Standard: die zuletzt gültige Version — nicht zwangsläufig die neueste) und Zielordner wählen
4. Mit „Kopieren" bestätigen

Wichtig: Die Versionshistorie und das Änderungsprotokoll werden nicht mitkopiert — das Ziel-Dataset startet bei einer neuen Version. Woher ein Stand kopiert wurde, bleibt über das Audit-Log beider Datasets nachvollziehbar; es gibt kein Vorschau-/Diff wie beim Veröffentlichen, nur diesen Hinweis.

Liefer-Gate: Die kopierte Version durchläuft dieselbe Prüfung wie jede andere Änderung. Ohne ausgewählte Quellversion wird automatisch die zuletzt gültige Version des Quell-Datasets kopiert — ein gerade in Bearbeitung befindlicher, noch ungültiger Stand wird nie unbemerkt in eine andere Umgebung übertragen. Gibt es keine gültige Quellversion, meldet das Tool einen Fehler, und es wird nichts kopiert. Wählen Sie bewusst eine bestimmte (ggf. ungültige) Quellversion aus, wird diese zwar kopiert, aber ebenso als ungültig markiert und nicht ausgeliefert — bis eine gültige neuere Version vorliegt, bleibt in der Zielumgebung der vorherige gültige Stand aktiv.

Sensitivitätsstufen: Kopieren dürfen Sie nur, was Sie selbst sehen dürfen. Enthält das Quell-Dataset eine Spalte oberhalb Ihrer Stufe — im aktuellen Schema oder in der gewählten Quellversion —, lehnt MDM Lite die Kopie ab (403 classification_ceiling_exceeded), und es wird nichts angelegt. Hintergrund: Dataset-Rollen werden nicht mitkopiert; im Ziel gelten zunächst die Mandanten-Rollen. Bitten Sie in diesem Fall einen Admin des Datasets um die Kopie. Werte von Spalten, die im Schema nicht mehr existieren, werden nie mitkopiert.

Technischer Name: Das neue Dataset in der Zielumgebung übernimmt den technischen Namen des Quell-Datasets unverändert — dieselbe Tabelle heißt in Test und Produktion also gleich. Ist der Name in der Zielumgebung bereits vergeben (z. B. weil dort schon einmal in dieselbe Umgebung kopiert wurde), hängt MDM Lite automatisch einen Zahlensuffix an (_2, _3, …), statt das Kopieren abzulehnen.

Nach erfolgreichem Kopieren führt „In <Umgebung> öffnen" direkt zum neuen bzw. aktualisierten Dataset in der Zielumgebung.

Beziehungen beim Kopieren

Hat die Tabelle Spalten vom Typ „Verknüpfung" (Beziehungen zu anderen Tabellen), zeigt der Dialog einen Abschnitt „Beziehungen". Dort sehen Sie vor dem Kopieren, worauf jede Beziehung in der Zielumgebung zeigen wird. Die Prüfung läuft automatisch, sobald Zielumgebung, Modus, Name und Version feststehen, und schreibt nichts.

• Namensregel: Eine Beziehung wird an die Tabelle mit demselben Namen in der Zielumgebung gebunden. Damit das funktioniert, sollten Tabellen in allen Umgebungen gleich heißen. Das Kopieren übernimmt den Namen unverändert.
• Selbstbezug: Zeigt eine Spalte auf die Tabelle selbst, zeigt sie in der Kopie auf die Kopie.
• Explizite Bindung: Gibt es in der Zielumgebung keine passende Tabelle, wählen Sie über „Andere Tabelle wählen…" eine Tabelle der Zielumgebung aus. Die Auswahl gilt nur für diese Kopie. Eine archivierte Zieltabelle ist mit einem Warnsymbol markiert; sie wird trotzdem gebunden.
• Beziehung nicht bindbar: Solange eine Beziehung nicht gebunden werden kann, ist „Kopieren" deaktiviert. Der Dialog nennt den Grund, z. B. dass die Tabelle in der Zielumgebung fehlt, einen anderen Typ hat oder die verknüpfte Spalte nicht enthält.
• Abhängigkeiten mitkopieren: Fehlen die verknüpften Tabellen in der Zielumgebung, bietet der Dialog „Fehlende Abhängigkeiten zuerst kopieren (n)" an. Die Tabellen werden nacheinander kopiert, die jeweils benötigten zuerst (bei Land → Region → Kontinent also Kontinent, Region, dann Land). Sie landen als Entwurf in der Zielumgebung. Bei einem Fehler bricht der Ablauf ab; bereits kopierte Tabellen bleiben als Entwurf bestehen, und ein erneuter Versuch beginnt mit einer neuen Prüfung. Die eigentliche Kopie starten Sie danach selbst mit „Kopieren".
• Zirkelbezüge: Verweisen Tabellen im Kreis aufeinander, lassen sie sich nicht einzeln kopieren. Der Dialog zeigt die beteiligten Tabellen. Umgehung: Wandeln Sie in einer der Tabellen die Verknüpfung in eine Textspalte um, kopieren Sie alle Tabellen und legen Sie die Verknüpfung in der Zielumgebung im Tab „Spalten" wieder an.
• Ergebnis: Nach dem Kopieren nennt der Dialog, wie viele Beziehungen auf die Zielumgebung umgestellt wurden, mit einer aufklappbaren Liste.

Für Entwickler/CI: Das Kopieren steht auch über die API zur Verfügung (POST /api/datasets/{id}/copy-to-environment, mit Idempotency-Key für sichere Wiederholung) — z. B. für automatisierte Promotion Test → Prod. API-Aufrufe ohne X-Environment-Header treffen immer die Live-Umgebung (Abwärtskompatibilität bestehender DWH-Integrationen). Ein API-Key, der auf die Quell-Umgebung beschränkt ist, darf ein Dataset in der Zielumgebung nicht neu anlegen (403); er darf nur ein Ziel-Dataset aktualisieren, das zuvor aus genau diesem Quell-Dataset kopiert wurde. Legen Sie das Ziel-Dataset deshalb einmalig selbst über „In Umgebung kopieren…" (Modus „Neu anlegen") an; danach kann die Pipeline es mit „Bestehendes aktualisieren" (mode=update) befüllen. Details: API-Spezifikation ↗ (GitHub, ggf. Zugriff erforderlich), Abschnitt „Umgebungen".

4. Datasets verwalten

Erster Start (Onboarding)

Ist Ihr Mandant noch leer (kein Dataset vorhanden), startet automatisch ein kurzer Onboarding-Assistent: Sie vergeben einen Namen und wählen entweder eine Vorlage oder laden eine Datei hoch — und haben so in wenigen Sekunden Ihr erstes Dataset. Der Assistent lässt sich überspringen und erscheint nicht erneut, sobald mindestens ein Dataset existiert.

Neues Dataset anlegen

1. Im Dataset Explorer auf + klicken
2. „Neues Dataset" wählen
3. Optional „Mit Vorlage starten": eine der fertigen Vorlagen wählen (Filialhierarchie, Kostenstellen, Produktkategorien, ISO-Ländercodes, Mitarbeiter-Gruppen). Die Vorlage legt Typ und passende Spalten (inkl. Eindeutiger Bezeichner) automatisch an — Sie müssen nur noch Daten einpflegen.
4. Name, Beschreibung und Typ auswählen (Typ entfällt bei Vorlagen):
   • Tabelle — eine Zeile je Eintrag; für Lookup-Tabellen, Mappings und auch für Hierarchien mit festen Ebenen (über Beziehungen verbunden, siehe Abschnitt 7). Empfohlen und vorausgewählt.
   • Baum — für eine Eltern-Kind-Hierarchie innerhalb eines einzigen Datasets (Organigramm, Kontenplan). Nur nötig, wenn Einträge derselben Art beliebig tief verschachtelt sind und alle Ebenen dieselben Spalten haben.
   • ⚠ Diese Wahl ist dauerhaft — der Typ eines Datasets kann nach der Erstellung nicht mehr geändert werden. Im Zweifel Tabelle wählen.
5. Technischer Name prüfen oder anpassen: MDM Lite schlägt ihn aus dem Namen vor und aktualisiert den Vorschlag live, solange Sie das Feld nicht selbst bearbeitet haben. Das ist der Tabellenname auf der Datenplattform — siehe Technischer Tabellenname für die Regeln.
6. Mit „Erstellen" bestätigen

Das Dataset wird im Status Entwurf angelegt. Daten können sofort eingepflegt werden.

Dataset-Status & Lebenszyklus

Jedes Dataset durchläuft einen klaren Lebenszyklus, der oben in der Detailansicht als umschaltbares Statussteuerelement angezeigt wird:

Der Statuswechsel erfolgt über das Statussteuerelement auf der Detailseite oder das Aktionsmenü (⋮) im Explorer. Übergänge sind reversibel (z. B. Veröffentlicht → Entwurf zum Zurückziehen).

Verantwortliche Person (Owner) eines Datasets

Jedes Dataset hat genau eine verantwortliche Person: die Ansprechperson für Inhalt und Pflege. Sie muss nicht die Person sein, die das Dataset angelegt hat. Oft legt jemand aus IT oder BI das Dataset an, verantwortlich ist aber eine Person aus dem Fachbereich.

• Wo Sie sie sehen: In der Kopfzeile des Datasets (Feld „Verantwortlich") und in der Dataset-Übersicht (Kachel und Liste). Das Feld „Zuletzt geändert" zeigt weiterhin Datum und die Person, die zuletzt geändert hat.
• Beim Anlegen ist die anlegende Person die verantwortliche Person, egal ob Sie das Dataset in der Weboberfläche, per Datei-Upload, aus der Bibliothek oder über die API anlegen. Bestehende Datasets haben die Person, die sie angelegt hat.
• Ändern (Dataset-Admin und Mandanten-Admin): Dataset öffnen → Tab „Verwaltung" → Abschnitt „Verantwortlich" → „Ändern". Zur Auswahl stehen aktive Mitglieder Ihres Mandanten, die auf dieses Dataset mindestens Editor-Rechte haben. Editoren und Viewer sehen die Person, können sie aber nicht ändern. Jede Änderung steht mit altem und neuem Wert im Änderungsprotokoll.
• Die Zuweisung vergibt keine Rechte. Wer verantwortlich ist, darf deshalb nicht mehr als zuvor. Möchten Sie eine Person ohne Schreibrecht eintragen, geben Sie ihr zuerst die Editor-Rolle auf dem Dataset (siehe Rollen).
• Nicht mehr berechtigt: Wird die verantwortliche Person gesperrt, aus dem Mandanten entfernt oder verliert das Editor-Recht, bleibt sie eingetragen. MDM Lite markiert das Dataset dann mit „Owner nicht mehr berechtigt". Tragen Sie eine andere Person ein.
• Meine Datasets: In der Dataset-Übersicht blendet der Schnellfilter „Meine Datasets" alle Datasets aus, für die Sie nicht verantwortlich sind. Per API gilt GET /api/datasets?owner=me.
• Umgebungen: Beim Kopieren in eine andere Umgebung mit dem Modus „Neu anlegen" übernimmt die Kopie die verantwortliche Person, solange sie noch aktives Mitglied mit mindestens Editor-Rolle ist. Sonst werden Sie als kopierende Person eingetragen. Beim Aktualisieren eines bestehenden Ziel-Datasets bleibt dessen eigene verantwortliche Person erhalten.

Pflegeart eines Datasets

Die Pflegeart legt fest, auf welchem Weg Daten in ein Dataset kommen dürfen. Sie ist eine Regel, die MDM Lite durchsetzt, und kein bloßes Etikett.

Alle bestehenden und neuen Datasets sind zunächst Manuell gepflegt. Die Pflegeart sehen Sie in der Kopfzeile eines Datasets, bei automatisch gelieferten Datasets auch in der Übersicht.

Pflegeart ändern (nur Mandanten-Admin): Dataset öffnen → Tab „Verwaltung" → Abschnitt „Pflegeart". Dataset-Admins, Editoren, Viewer und API-Keys können sie nicht ändern. Jede Änderung steht im Änderungsprotokoll des Datasets.

Was die Pflegeart bewirkt:

• Schreiben per API-Key nur bei „Automatisch geliefert". Jeder Schreibzugriff mit API-Key auf die Zeilen eines Datasets, das Manuell gepflegt ist, wird mit 409 und dem Code MAINTENANCE_TYPE_MISMATCH abgewiesen, bevor MDM Lite die Daten verarbeitet. Das gilt für den Import über die API ebenso wie für Massenänderungen, Speichern (Commit), das Wiederherstellen einer Version und das Anlegen, Ändern oder Löschen von Knoten in Bäumen. Bei einer Ablehnung wird nichts geschrieben. Abgewiesene Importe erscheinen zusätzlich in der Import-Historie des Datasets (GET /api/datasets/{id}/imports) mit Status Rejected, Kanal api, dem Fehlercode und dem Namen des API-Keys. So sehen Sie, dass ein Quellsystem vergeblich liefert. Die Weboberfläche bleibt bei jeder Pflegeart uneingeschränkt nutzbar; das Kopieren in eine andere Umgebung und das Neuberechnen berechneter Spalten sind nicht betroffen.
• Lieferrhythmus (optional). Bei „Automatisch geliefert" können Sie einen erwarteten Rhythmus angeben: täglich, wöchentlich, monatlich oder eine eigene Anzahl Tage. Überschreitet die letzte Aktualisierung diesen Rhythmus, zeigt MDM Lite „Lieferung überfällig" (Übersicht und Kopfzeile). Ohne Rhythmus gibt es diesen Hinweis nie.
• Hinweis beim manuellen Bearbeiten. Bei „Automatisch geliefert" bleiben Bearbeiten und Upload in der Weboberfläche erlaubt, zum Beispiel für schnelle Korrekturen. Über dem Editor steht ein Hinweis, dass die nächste Lieferung Ihre Änderung überschreiben kann. Dauerhafte Korrekturen nehmen Sie im Quellsystem vor.

Beim Kopieren in eine andere Umgebung mit dem Modus „Neu anlegen" übernimmt die Kopie die Pflegeart (und den Lieferrhythmus). Beim Aktualisieren eines bestehenden Ziel-Datasets bleibt dessen eigene Pflegeart unverändert.

Hinweis: Die Pflegeart „Automatisch abgeholt" (MDM Lite holt Daten selbst aus einer Quelle) ist vorgesehen, aber noch nicht verfügbar.

Veröffentlichen & Zurückziehen (Publish-Workflow)

Erst durch Veröffentlichen wird ein Dataset für das DWH und automatisierte Abnehmer sichtbar. Das schützt Entwürfe vor verfrühtem Zugriff.

Veröffentlichen:

1. Auf der Detailseite „Veröffentlichen" wählen
2. Das Tool zeigt eine Pre-Publish-Validierung (blockierende Fehler + Warnungen) und eine Änderungsübersicht (Zeilen hinzugefügt / geändert / entfernt seit der letzten Veröffentlichung)
3. Einen Kommentar eingeben (Pflicht — dokumentiert, warum veröffentlicht wurde)
4. Warnungen ggf. bestätigen und mit „Veröffentlichen" abschließen

Zurückziehen (Unpublish): Über „Zurückziehen" wird ein veröffentlichtes Dataset wieder in den Entwurf-Status versetzt. Eine Wirkungswarnung weist darauf hin, dass DWH-Abnehmer das Dataset danach nicht mehr sehen.

Nicht veröffentlichte Änderungen: Bearbeiten Sie ein bereits veröffentlichtes Dataset, erscheint ein Indikator „Änderungen ausstehend" (auf der Kachel und im Detail-Header). Die Änderungen werden erst mit einer erneuten Veröffentlichung für das DWH wirksam. Im Dataset-Explorer zeigt ein Banner alle Datasets mit unveröffentlichten Änderungen — mit „Alle anzeigen" filtern Sie gezielt darauf.

Publish-Historie: Der Tab „Verlauf" enthält eine Zeitleiste aller Veröffentlichungen mit Datum, Nutzer und Kommentar.

Hinweis: Es handelt sich um einen Publish-Gate (Validierung + Kommentar durch eine berechtigte Person), nicht um ein Vier-Augen-Prinzip mit separater Genehmigung durch eine zweite Person.

Ordner erstellen und verwalten

• Neuen Ordner anlegen: +-Button im Explorer → „Neuer Ordner"
• Dataset verschieben: Drag & Drop im Explorer-Baum oder über das Kontextmenü (⋮) → „Verschieben"
• Ordner umbenennen/löschen: Rechtsklick auf den Ordner → entsprechende Aktion
• Ordner können beliebig tief verschachtelt werden
• Datasets ohne Ordner erscheinen unter „Nicht zugeordnet"

Dataset suchen

Das Suchfeld über dem Explorer-Baum filtert in Echtzeit nach Dataset-Name oder Ordner-Name. Die Checkbox „Unterordner einschließen" steuert, ob bei Klick auf einen Ordner auch Datasets aus Unterordnern angezeigt werden.

Archivierte Datasets endgültig löschen (Purge)

Archivierte Datasets bleiben standardmäßig dauerhaft erhalten (siehe Dataset-Status & Lebenszyklus). Für den Fall, dass ein Dataset versehentlich angelegt wurde oder endgültig entfernt werden soll, gibt es eine separate, unumkehrbare Endgültig-löschen-Funktion.

Aufrufen: Einstellungen → Daten → Archivierte Datasets (Route /settings/data/archived). Erforderliche Rolle: Admin.

Die Seite listet alle archivierten Datasets des Mandanten mit Typ, Archivierungsdatum, letzter Version und Zeilenzahl.

1. In der Zeile des gewünschten Datasets „Endgültig löschen" klicken
2. Im Bestätigungsdialog wird aufgelistet, was verloren geht: Dataset, alle Versionen, Schema und Daten
3. Enthält das Dataset bereits Daten (mindestens eine Zeile oder mehr als eine Version), muss zur Bestätigung der exakte Dataset-Name eingetippt werden, bevor der rot hervorgehobene Button „Endgültig löschen" aktiv wird
4. Bestätigen — das Dataset ist danach unwiderruflich entfernt

Achtung: Diese Aktion kann nicht rückgängig gemacht werden — anders als Archivieren betrifft sie auch die Versionshistorie und das Audit-Log des Datasets. Nutzen Sie sie nur für Datasets, die wirklich nicht mehr benötigt werden.

Sperre bei aktiven Referenzen: Wird das Dataset noch als Fremdschlüssel-Ziel von einer Spalte in einem anderen Dataset verwendet, lehnt das Tool das endgültige Löschen ab (Meldung „Dieses Dataset wird von anderen Datasets referenziert und kann nicht gelöscht werden."). Lösen Sie zuerst die Beziehung auf (siehe Beziehungen-Tab) und wiederholen Sie den Löschvorgang danach.

5. Schema definieren

Das Schema legt fest, welche Spalten ein Dataset hat. Es wird pro Dataset frei definiert — kein starres Systemmodell.

Schema-Tab öffnen

Auf ein Dataset klicken → Tab „Spalten" wählen. Der Tab zeigt die Spalten zunächst nur an. Zum Ändern klicken Sie auf „Spalten bearbeiten" (siehe Änderungen sammeln und speichern); alle Änderungen werden dort gesammelt und erst mit „Speichern" übernommen.

Änderungen sammeln und speichern

Im Tab „Spalten" ändern Sie das Schema im Bearbeitungsmodus. Alle Änderungen werden dort zunächst nur gesammelt (als Entwurf in Ihrem Browser) und erst mit „Speichern" gemeinsam übernommen. Bis dahin ändert sich weder das Dataset noch eine Version, und niemand sonst sieht Ihre Änderungen.

Bearbeitungsmodus starten und beenden

1. Öffnen Sie das Dataset und wählen Sie den Tab „Spalten".
2. Klicken Sie auf „Spalten bearbeiten". Bei archivierten Datasets ist die Schaltfläche gesperrt („Archivierte Datasets sind schreibgeschützt").
3. Die Leiste zeigt jetzt „Bearbeitungsmodus" mit dem Hinweis „Alle Änderungen an Spalten werden erst mit „Speichern" übernommen." sowie die Schaltflächen „FK-Erkennung", „Spalte hinzufügen", „Verwerfen" und „Speichern (+n ~n −n)".
4. Beenden Sie den Modus mit „Speichern" oder „Verwerfen". Eine Schaltfläche „Fertig" gibt es nicht.

Was Sie sammeln können — jede Aktion des Tabs:

• Spalte hinzufügen, auch eine berechnete Spalte
• Spalte bearbeiten: Name, Bezeichnung, Pflichtfeld, Eindeutig, Primärschlüssel, erlaubte Werte, Validierungsregel, Beziehung, Berechnung
• Typ ändern
• Spalte zum Löschen vormerken
• Sichtbarkeit, Klassifizierung, Glossar-Begriff und Reihenfolge der Spalten („Nach oben verschieben" / „Nach unten verschieben")
• „FK-Erkennung": „Annehmen" merkt die Umwandlung in eine Verknüpfung nur vor. Eine Vorschau der Umwandlung zeigt MDM Lite erst in der Zusammenfassung beim Speichern.

Die Dialoge schließen Sie mit „Spalte hinzufügen" (neue Spalte), „Übernehmen" (Bearbeiten, Typwechsel) bzw. „Zum Löschen vormerken" (Löschen) ab. Das speichert noch nichts, es legt die Änderung nur im Entwurf ab. Mehrere Änderungen an derselben Spalte fasst MDM Lite zu einer zusammen.

Rollen: Struktur-Änderungen (Spalte hinzufügen, löschen, Typ ändern, Name, Pflichtfeld, Eindeutig, Primärschlüssel, erlaubte Werte, Validierungsregel, Beziehung, Berechnung) sowie Bezeichnung, Breite und Reihenfolge erfordern die Rolle Dataset-Admin. Für Editoren sind diese Aktionen deaktiviert (Tooltip „Nur für Dataset-Admins"). Editoren ändern im Bearbeitungsmodus Sichtbarkeit, Klassifizierung (innerhalb ihrer Obergrenze) und Glossar-Begriff.

Markierungen in der Spaltenliste

Mit „Änderungen an dieser Spalte zurücknehmen" machen Sie in einer Zeile alle vorgemerkten Änderungen an dieser einen Spalte rückgängig. Eine zum Löschen vorgemerkte Spalte holen Sie mit „Spalte wiederherstellen" zurück.

Der Zähler am Button „Speichern (+n ~n −n)" zeigt, wie viele Spalten neu (+), geändert (~) und zum Löschen vorgemerkt (−) sind. Solange nichts vorgemerkt ist, ist der Button deaktiviert.

Verwerfen

„Verwerfen" verlässt den Bearbeitungsmodus und verwirft alle noch nicht gespeicherten Änderungen im Tab „Spalten". Liegen Änderungen vor, fragt MDM Lite nach: „Änderungen verwerfen? Alle nicht gespeicherten Änderungen gehen verloren." Ohne Änderungen verlassen Sie den Modus sofort. Verworfene Änderungen lassen sich nicht wiederherstellen; es entsteht keine Version.

Speichern und Zusammenfassung

1. Klicken Sie auf „Speichern (+n ~n −n)".
2. Enthält der Entwurf nur Anzeige-Einstellungen (Bezeichnung, Breite, Sichtbarkeit, Klassifizierung, Glossar-Begriff, Reihenfolge), speichert MDM Lite sofort, ohne Dialog.
3. Sonst prüft MDM Lite den gesamten Entwurf, ohne etwas zu schreiben, und öffnet den Dialog „Änderungen speichern" („Auswirkungen werden geprüft…"). Er zeigt:
   • Die Versionswirkung: „Es entsteht Version v{n}.", „Der Entwurf wird aktualisiert." (bei einem Dataset im Status Entwurf) oder „Keine neue Version — nur Anzeige-Einstellungen."
   • Eine Zeile je Änderung, zum Beispiel „Neue Spalte …", „Spalte … in … umbenennen", „Spalte …: Typwechsel zu …", „Spalte … löschen", „Reihenfolge der Spalten ändern".
   • Die Auswirkung auf die Daten: wie viele Zeilen in die neue Version übernommen werden, in wie vielen Zeilen ein Standardwert eingetragen oder ein Wert berechnet wird, wie viele Werte umgewandelt werden und wie viele nicht zum neuen Typ passen.
   • Hinweise zu Folgen: „Breaking Change" bei Umbenennen, Typwechsel und Löschen, „Datenverlust" mit der Zahl der betroffenen Zeilen (davon bereits beendete Zeilen) und der Hinweis auf defekte Beziehungen, wenn eine gelöschte Spalte Ziel einer Beziehung ist. Benennen Sie eine Spalte um, die Ziel von Beziehungen anderer Datasets ist, steht dort: „Die Fremdschlüssel-Spalten in n anderen Datasets werden automatisch auf den neuen Namen umgestellt." MDM Lite nennt die Zahl der anderen Datasets, nicht deren Namen.
4. Klicken Sie im Dialog auf „Änderungen speichern". MDM Lite meldet „Änderungen gespeichert (Version v{n})." (bzw. „Änderungen gespeichert.") und verlässt den Bearbeitungsmodus.

Speichern ist alles oder nichts: Lässt sich auch nur eine Änderung nicht übernehmen, wird nichts gespeichert, und Ihr Entwurf bleibt erhalten.

Verweisen nach dem Speichern Zeilen anderer Datasets über eine importierte Beziehung noch auf entfernte Werte, zeigt MDM Lite nach dem Speichern den Hinweis „Einige Einträge anderer Datasets verweisen über eine importierte Beziehung noch auf entfernte Werte." mit den betroffenen Zeilen und Schlüsseln. Zeilen in Datasets, auf die Sie keinen Zugriff haben, erscheinen nur als Zahl. Diesen Hinweis sehen Sie erst nach dem Speichern, nicht schon in der Zusammenfassung.

Wann entsteht eine neue Version?

Bei einem Dataset im Status Entwurf aktualisiert MDM Lite die vorhandene Arbeitsversion, statt eine neue anzulegen. Ältere Versionen behalten immer ihren damaligen Spaltenstand (siehe Schema-Stand historischer Versionen). Im Änderungsprotokoll steht ein Sammeleintrag schema_changes_saved mit der Zahl der Änderungen (ohne Spaltennamen) sowie je Spalte ein Einzeleintrag.

Fehler beim Speichern

Jemand anderes hat das Schema inzwischen geändert

Ändert eine andere Person die Spalten des Datasets, während Sie im Bearbeitungsmodus arbeiten, lehnt MDM Lite Ihr Speichern ab, damit deren Änderung nicht still überschrieben wird. Es erscheint der Dialog „Das Schema wurde inzwischen geändert." („Jemand anderes hat die Spalten dieses Datasets geändert, seit Sie sie geladen haben. Es wurde nichts gespeichert."). Sie haben zwei Möglichkeiten:

• „Neu laden und Änderungen behalten" lädt den aktuellen Stand und behält Ihre Änderungen. Prüfen Sie sie und speichern Sie erneut. Betrifft eine Änderung eine Spalte, die es inzwischen nicht mehr gibt, verwirft MDM Lite diese Änderung und listet die Spalte auf; die übrigen bleiben erhalten.
• „Änderungen verwerfen" verwirft Ihren Entwurf und lädt den aktuellen Stand.

Nur Änderungen an den Spalten lösen diesen Dialog aus; Änderungen an den Daten (Zeilen bearbeiten, Import) nicht.

Ungespeicherte Änderungen: Schutz beim Verlassen

Liegen im Tab „Spalten" oder im Tab „Daten" ungespeicherte Änderungen vor, fragt MDM Lite nach, bevor sie verloren gehen: „Es gibt ungespeicherte Änderungen. Trotzdem verlassen?" Die Rückfrage erscheint beim

• Wechsel auf einen anderen Tab des Datasets,
• Klick in der Seitenleiste auf ein anderes Dataset oder einen Ordner,
• Öffnen eines Ziels über die Befehlspalette,
• Klick auf einen Fremdschlüssel-Link zu einem anderen Dataset,
• Schließen des Browser-Tabs oder Neuladen der Seite (diese Rückfrage stammt vom Browser).

Mit Abbrechen bleiben Sie im Tab, mit OK verlassen Sie ihn und verwerfen die Änderungen.

Grenze: Die Zurück-Schaltfläche des Browsers fängt MDM Lite nicht ab. Wer damit die Seite verlässt, verliert ungespeicherte Änderungen ohne Rückfrage. Speichern oder verwerfen Sie deshalb bewusst, bevor Sie die Browser-Navigation nutzen.

Für API- und MCP-Nutzer: Der Bearbeitungsmodus bündelt die Änderungen in einem Aufruf PATCH /api/datasets/{id}/schema (Details: API-Spezifikation ↗ (GitHub, ggf. Zugriff erforderlich), Abschnitt 5.8). Die bisherigen Einzel-Endpunkte (POST/PUT/DELETE …/schema/columns…, PATCH …/schema/order, …/type, …/classification usw.) bleiben dauerhaft verfügbar, bestehende Skripte und Integrationen funktionieren unverändert. Sie wirken allerdings sofort, ohne Entwurf und Zusammenfassung.

Neue Spalte anlegen

1. Klicken Sie im Bearbeitungsmodus auf „Spalte hinzufügen"
2. Felder ausfüllen und den Dialog mit „Spalte hinzufügen" bestätigen. Die Spalte erscheint als „Neu" und wird erst mit „Speichern" angelegt:

Unterstützte Datentypen

Primärschlüssel (Business Key)

Genau eine Spalte muss als Primärschlüssel markiert werden. Dieser Business Key identifiziert eine Zeile eindeutig und wird beim Import für Abgleich und Deduplizierung verwendet.

Hinweis: Der Primärschlüssel ist unveränderlich, sobald Daten im Dataset vorhanden sind. Wählen Sie ihn sorgfältig.

Zusammengesetzter Schlüssel: Ist eine Zeile erst durch mehrere Spalten eindeutig (z. B. Land, Segment und Jahr), legen Sie eine berechnete Spalte an und markieren Sie diese als Primärschlüssel.

Enum-Werte definieren

Bei Typ Enum erscheint ein zusätzliches Feld „Erlaubte Werte". Tragen Sie jeden Wert ein und bestätigen mit Enter. Import-Zeilen mit einem nicht gelisteten Wert werden abgelehnt.

Nachträgliche Spalten und bestehende Daten

Neue Spalten können auch zu einem Dataset hinzugefügt werden, das bereits Zeilen enthält — die vorhandenen Zeilen gehen dabei nicht verloren: Sie werden automatisch in die neue Version übernommen, die neue Spalte ist dort zunächst leer.

Ausnahme: Legen Sie eine neue Spalte als Pflichtfeld ohne Standardwert an, obwohl das Dataset bereits Zeilen hat, weist das Tool die Änderung ab und bittet um einen Standardwert — dieser wird dann für alle bestehenden Zeilen automatisch eingesetzt. Alternativ die Spalte als optional anlegen.

Spalte umbenennen

Klicken Sie im Bearbeitungsmodus des Tabs „Spalten" in der Zeile der Spalte auf das Bearbeiten-Symbol, ändern Sie den Spaltennamen und bestätigen Sie mit „Übernehmen". Die Umbenennung gilt erst nach „Speichern"; die Zusammenfassung nennt sie als „Breaking Change". Alle Werte bleiben erhalten und stehen danach unter dem neuen Namen, auch beim Primärschlüssel: Die Zeilen behalten ihren Business Key, und die Version bleibt gültig. Ältere Versionen behalten den bisherigen Spaltennamen.

Zwei Einschränkungen:

• Ist die Spalte das Ziel einer Beziehung aus einem anderen Dataset, können Sie sie trotzdem umbenennen: Die Beziehungen der anderen Datasets (derselben Umgebung) werden automatisch auf den neuen Namen umgestellt und bleiben gültig. Im Protokoll jedes betroffenen Datasets erscheint dazu ein Eintrag „Beziehung geändert“. Ältere Versionen der anderen Datasets behalten den bisherigen Namen. Während der Umbenennung werden das Dataset und alle verknüpfenden Datasets kurz gesperrt; läuft dort gerade eine andere Änderung, erhalten Sie nach wenigen Sekunden den Hinweis, es später erneut zu versuchen.
• Umbenennen und Typwechsel speichern Sie bitte in zwei getrennten Schritten.

Hinweis für bereits betroffene Datasets: Wurde eine Spalte mit einer älteren Version von MDM Lite umbenannt und erscheint seitdem leer, benennen Sie sie auf ihren ursprünglichen Namen zurück. Die Werte sind dann wieder sichtbar. Anschließend können Sie die Spalte erneut umbenennen; die Werte wandern jetzt mit.

Spalte löschen

Klicken Sie im Bearbeitungsmodus des Tabs „Spalten" an der Spalte auf das Lösch-Symbol und bestätigen Sie mit „Zum Löschen vormerken". Die Spalte erscheint als „Wird gelöscht" und wird erst mit „Speichern" tatsächlich entfernt; bis dahin holen Sie sie mit „Spalte wiederherstellen" zurück. Spalten lassen sich auch löschen, wenn das Dataset bereits Zeilen enthält. Die folgenden Hinweise erscheinen im Löschdialog und in der Zusammenfassung beim Speichern.

Enthält die Spalte Werte, nennt der Dialog die Anzahl der betroffenen Zeilen, zum Beispiel: „Die Spalte enthält in 12 Zeilen Werte. In der neuen Version gehen diese Werte verloren." Gelöscht wird erst, wenn Sie den Verlust mit dem Kontrollkästchen ausdrücklich bestätigen. Die neue Version enthält die Spalte und ihre Werte dann nicht mehr.

Zu den betroffenen Zeilen zählen auch beendete Zeilen: Eine im Tab „Daten" gelöschte Zeile wird nicht entfernt, sondern mit einem Gültig-bis-Datum historisiert. Sie gehört weiter zur aktuellen Version, wird in der Tabellenansicht aber nicht mehr angezeigt. Der Dialog weist deshalb gesondert aus, wie viele der betroffenen Zeilen bereits beendet sind. So erklärt sich, warum eine scheinbar leere Tabelle trotzdem Werte enthält.

Ist die Spalte das Ziel einer Beziehung aus einem anderen Dataset, weist der Dialog darauf hin: Nach dem Löschen ist diese Beziehung defekt und muss im Tab „Beziehungen" angepasst werden.

Zusätzlich zeigt der Bestätigungsdialog einen Breaking-Change-Hinweis, denn eine Spaltenentfernung wirkt weitreichender als eine Spalten-Hinzufügung:

Breaking Change Das Entfernen einer Spalte ist eine strukturelle Änderung: Neue Versionen, Exporte und API-Antworten enthalten die Spalte {Spaltenname} ab sofort nicht mehr. API-Konsumenten und DWH-Abfragen, die diese Spalte erwarten, können fehlschlagen.

Historische Versionen behalten die Spalte und ihre Werte (Schema-Snapshot) und bleiben unverändert abrufbar.

Die Klassifizierung, die die Spalte beim Löschen hat, gilt in diesen älteren Versionen weiter (siehe Schema-Stand historischer Versionen). Eine Spalte zu löschen ist deshalb kein Weg, eine Hochstufung zu umgehen.

Der Hinweis blockiert das Löschen nicht — er macht die Tragweite sichtbar, bevor Sie bestätigen. Was „historische Versionen behalten die Spalte" konkret bedeutet, erklärt Schema-Stand historischer Versionen.

Berechnete Spalten

Eine berechnete Spalte setzt MDM Lite selbst aus den Werten anderer Spalten derselben Zeile zusammen. Sie tragen dort nichts ein: Der Wert entsteht beim Speichern, beim Massenändern und beim Import automatisch und wird bei jeder Änderung einer Quellspalte neu berechnet.

Wann nutzen Sie das? Vor allem für einen zusammengesetzten fachlichen Schlüssel. MDM Lite kennt als Primärschlüssel genau eine Spalte. Ist eine Zeile erst durch die Kombination mehrerer Spalten eindeutig, bilden Sie aus diesen Spalten eine berechnete Spalte und markieren sie als Primärschlüssel. Beispiel: Ein Dataset „Preisfaktoren" ist je Land, Segment und Jahr eindeutig. Die berechnete Spalte PK_PREIS ergibt dann zum Beispiel DE|Privat|2026. Auch der Import im Modus „Ergänzen & Aktualisieren" gleicht über diesen Schlüssel ab (siehe Import mit berechneten Spalten). Eine berechnete Spalte eignet sich außerdem als reine Anzeigespalte, etwa „Nachname, Vorname".

Voraussetzungen: Berechnete Spalten gibt es nur in Tabellen, nicht in Bäumen. Anlegen, Ändern und Zurückwandeln erfordern die Rolle Dataset-Admin. Im Assistenten „Dataset aus Datei erstellen" lässt sich keine berechnete Spalte anlegen: Legen Sie das Dataset an und ergänzen Sie die Spalte anschließend im Tab „Spalten".

Nicht zu verwechseln: Die Automatische Nummer (Auto-Increment) vergibt fortlaufende Nummern und ist keine berechnete Spalte im Sinne dieses Kapitels.

Berechnete Spalte anlegen

1. Öffnen Sie das Dataset und wählen Sie den Tab „Spalten". Klicken Sie auf „Spalten bearbeiten" und dann auf „Spalte hinzufügen". Wie alle Änderungen im Tab wird auch die berechnete Spalte erst mit „Speichern" angelegt (siehe Änderungen sammeln und speichern).
2. Wählen Sie bei „Werte" die Option „Berechnet aus anderen Spalten" (Standard ist „Eingabe").
3. Tragen Sie Spaltenname und Anzeigebezeichnung ein. Der Typ steht fest auf Text: „Berechnete Spalten sind immer Text."
4. Wählen Sie unter „Quellspalten" mindestens 2 und höchstens 10 Spalten. Die Reihenfolge bestimmt die Verkettung. Mit den Pfeilen verschieben Sie eine Quellspalte, mit „Quellspalte hinzufügen" ergänzen Sie eine weitere.
5. Legen Sie optional je Quellspalte die Stellen fest (siehe unten).
6. Wählen Sie das Trennzeichen.
7. Markieren Sie bei Bedarf „Primärschlüssel" und „Eindeutig". „Pflichtfeld" setzt MDM Lite selbst: Es gilt automatisch, sobald die Spalte Primärschlüssel ist.
8. Prüfen Sie die Vorschau und speichern Sie.

Sie erkennen die erfolgreiche Anlage an der Meldung „Spalte „…" angelegt. Die Werte von N vorhandenen Zeilen wurden berechnet." und am Chip „Berechnet" neben dem Typ der Spalte. Die Berechnung erzeugt eine neue Version des Datasets; bestehende Zeilen bleiben erhalten.

Eine vorhandene Text-Spalte machen Sie über „Spalte bearbeiten" → „Berechnen aus anderen Spalten" zur berechneten Spalte. Achtung: Die vorhandenen Werte werden überschrieben. Spalten anderer Typen lassen sich nicht umwandeln.

So fügt MDM Lite die Werte zusammen

Beispiel mit den Quellspalten BUCHUNGSKREIS = 305, JAHR = 2018, MONAT = 1:

Die Vorschau im Dialog zeigt Beispielwerte und die Zahl leerer Werte. Sie rechnet auf dem Server und speichert nichts. Bei einem Primärschlüssel meldet sie zusätzlich doppelte Schlüsselwerte und Verstöße gegen die Schlüsselregeln.

Als Primärschlüssel verwenden

Ist die berechnete Spalte der Primärschlüssel, gelten zusätzlich diese Regeln, damit der Schlüssel eindeutig bleibt:

• Alle Quellspalten müssen Pflichtfelder sein. Andernfalls meldet MDM Lite: „Alle Quellspalten eines berechneten Primärschlüssels müssen Pflichtfelder sein. Markieren Sie diese Spalten zuerst als Pflichtfeld: …". Das Pflichtfeld einer Quelle lässt sich danach nicht mehr entfernen.
• Doppelte Schlüssel blockieren das Speichern. Liefern die vorhandenen Zeilen für mehrere Zeilen denselben Schlüssel, meldet MDM Lite „Die berechneten Schlüsselwerte wären nicht eindeutig." Bereinigen Sie zuerst die Quelldaten.
• Kein Quellwert darf das Trennzeichen enthalten und keiner länger sein als seine Stellenzahl. Sonst nennt MDM Lite die Spalte, zum Beispiel „Der Wert von „Land" enthält das Trennzeichen des berechneten Schlüssels." Wählen Sie dann ein anderes Trennzeichen oder eine größere Stellenzahl. Das Trennzeichen - ist bei einer Datums-Quelle nicht erlaubt, weil Datumswerte selbst - enthalten.
• Ohne Trennzeichen brauchen alle Quellspalten außer der letzten eine feste Stellenzahl.
• Quellwerte bestehender Zeilen sind gesperrt, wenn sich dadurch der Schlüssel ändern würde. Für einen anderen Schlüssel legen Sie eine neue Zeile an und löschen die alte. Eine reine Änderung der Groß- und Kleinschreibung ist erlaubt.

Achtung beim Ändern der Berechnung: Ändern Sie Quellspalten, Reihenfolge, Trennzeichen oder Stellen eines Primärschlüssels, ändern sich alle Schlüsselwerte. Verweisende Datasets und die Bereitstellung im Modus „Aktualisieren & ergänzen (Upsert)" sehen dann neue Schlüssel. Der Dialog warnt davor. Wird ein Schlüssel noch von einem anderen Dataset referenziert, schützt MDM Lite diese Verweise wie beim Löschen (siehe Verwendete Einträge können nicht gelöscht werden).

Berechnete Spalten im Tab „Daten"

• Die Kopfzeile der Spalte trägt ein ƒ; der Tooltip nennt die Quellen: „Wird von MDM Lite aus … berechnet".
• Die Zellen sind immer schreibgeschützt („Berechnet und schreibgeschützt: wird von MDM Lite aus … abgeleitet."). Eine neue Zeile zeigt den Platzhalter „wird beim Speichern berechnet".
• Bei einem berechneten Primärschlüssel sind die Quellzellen bestehender Zeilen schreibgeschützt (Tooltipp: „Teil des Primärschlüssels. Für einen anderen Schlüssel eine neue Zeile anlegen und diese löschen."). In neuen Zeilen füllen Sie sie wie gewohnt.
• Bei Massenänderungen stehen berechnete Spalten und die Quellspalten eines berechneten Primärschlüssels nicht zur Auswahl („Berechnete Spalten und Quellspalten eines berechneten Schlüssels sind hier nicht wählbar.").
• Ändern Sie eine Quellspalte einer berechneten Spalte, die nicht Primärschlüssel ist, berechnet MDM Lite den Wert beim Speichern neu.

Import mit berechneten Spalten

Berechnete Spalten werden nicht aus der Datei gelesen.

• Steht eine berechnete Spalte in der Datei, ignoriert MDM Lite sie und zeigt eine Warnung: „Die Spalte „…" wird von MDM Lite berechnet; die Werte aus der Datei wurden ignoriert." Wichen die Dateiwerte vom berechneten Wert ab, nennt die Warnung die Zahl der Zeilen. Der Import läuft weiter.
• Im Zuordnungsschritt erscheint die Spalte als „wird berechnet — nicht aus der Datei" ohne Zuordnung; beim Schlüssel steht dort „Schlüssel wird aus … gebildet".
• Die Quellspalten müssen in der Datei stehen (bei einem berechneten Schlüssel sind sie Pflichtfelder). Die Schlüsselspalte selbst muss nicht in der Datei stehen.
• Im Modus „Ergänzen & Aktualisieren" (UPSERT) gleicht der Import über den berechneten Schlüssel ab: Eine Zeile mit denselben Quellwerten aktualisiert die bestehende Zeile, statt eine zweite anzulegen. Eine geänderte Quellspalte ergibt einen neuen Schlüssel und damit eine neue Zeile. Kommt derselbe berechnete Schlüssel in der Datei mehrfach vor, meldet MDM Lite wie bei jedem Business Key einen doppelten Schlüssel.
• Die Schlüsselregeln gelten auch im Import: Enthält ein Quellwert das Trennzeichen oder ist er länger als die Stellenzahl, nennt der Fehlerbericht Zeile, Wert und Spalte. Das Fehlerverhalten („Bei erstem Fehler stoppen" oder „Fehlerhafte Zeilen überspringen") gilt wie bei jedem Zeilenfehler.
• Das gilt für den Import in der Weboberfläche und für den API-Import.

Klassifizierung

Eine berechnete Spalte ist mindestens so hoch klassifiziert wie die höchste ihrer Quellspalten. MDM Lite setzt die Stufe beim Anlegen entsprechend. Eine niedrigere Stufe lehnt MDM Lite ab („Eine berechnete Spalte darf nicht niedriger klassifiziert sein als ihre Quellspalten (mindestens: …)"). Stufen Sie eine Quellspalte herauf, zieht die berechnete Spalte automatisch mit; im Änderungsprotokoll steht dafür ein eigener Eintrag. Eine Herabstufung der Quelle ändert die berechnete Spalte nicht. So gelangen vertrauliche Werte nicht über eine niedriger klassifizierte Verkettung in die Bereitstellung. Hintergrund: Welche Spalten auf die Datenplattform gehen.

Quellspalten umbenennen, ändern oder löschen

• Umbenennen: Die Berechnung folgt der Spalte automatisch, die Werte ändern sich nicht.
• Löschen: Solange eine berechnete Spalte eine Quellspalte nutzt, lässt sich die Quelle nicht löschen. Der Dialog zeigt „Wird von der berechneten Spalte … verwendet." Löschen Sie zuerst die berechnete Spalte oder wandeln Sie sie in eine normale Spalte um.
• Typ ändern: Ist die Quelle Teil eines berechneten Primärschlüssels, ist der Typwechsel gesperrt. Bei anderen berechneten Spalten ist er möglich; MDM Lite berechnet die Werte danach neu.

In normale Spalte umwandeln

Möchten Sie die Werte behalten, aber nicht mehr automatisch berechnen lassen: „Spalte bearbeiten" → „In normale Spalte umwandeln". Nach der Bestätigung („Die Werte der Spalte „…" bleiben erhalten und werden nicht mehr automatisch aktualisiert.") ist die Spalte eine normale Text-Spalte und frei editierbar. Auch das erfordert die Rolle Dataset-Admin. Berechnung ändern und Umwandeln lassen sich nicht in einem Schritt speichern.

Versionierung und Bereitstellung

Berechnete Werte werden gespeichert und überall wie eine normale Text-Spalte ausgeliefert: in der REST-API, im Export, in der Bereitstellungstabelle auf der Datenplattform und über MCP. Wird eine Berechnung geändert, entsteht wie bei jeder Schemaänderung eine neue Version; ältere Versionen behalten ihre Werte. Beim Wiederherstellen einer älteren Version berechnet MDM Lite die Werte nach der aktuellen Berechnung neu. Beim Kopieren in eine andere Umgebung wird die Berechnung mitkopiert.

Stimmen gespeicherte Werte einmal nicht mehr mit der Berechnung überein, stellt MDM Lite diese Version nicht bereit (Prüfregel COMPUTED_VALUE_MISMATCH, Meldung „Die berechnete Spalte „…" enthält N Werte, die nicht der Berechnung entsprechen."). Das ist nur nach außergewöhnlichen Ereignissen zu erwarten, etwa nach einem Rückbau der Software. Die Abhilfe steht im nächsten Abschnitt.

Werte weichen von der Berechnung ab (Neuberechnen)

Für Dataset-Admins. Meldet die Versionsprüfung, dass Werte einer berechneten Spalte nicht der Berechnung entsprechen, gleichen Sie sie mit dem Neuberechnen-Endpunkt ab:

POST /api/datasets/{datasetId}/schema/columns/{columnId}/recompute

1. Ermitteln Sie die Spalten-ID über GET /api/datasets/{datasetId}/schema/columns (die Spalte trägt das Feld computation).
2. Rufen Sie recompute mit einem Anmelde-Token oder API-Key mit Dataset-Admin-Rechten auf.
3. Antwort { "changed": n, "newVersion": v }: n abweichende Zeilen wurden in der neuen Version v korrigiert. Bei { "changed": 0, "newVersion": null } gab es nichts zu korrigieren, und es entsteht keine Version.

Gehen Sie ebenso vor, nachdem Ihr Betrieb auf einen Softwarestand vor Einführung der berechneten Spalten zurückgebaut hatte und dazwischen Daten geändert wurden. Auf einer normalen Spalte antwortet der Endpunkt mit 422 und not_computed. Eine Schaltfläche dafür gibt es in der Weboberfläche nicht.

Fehlermeldungen beim Einrichten

6. Daten bearbeiten

Tabellenansicht

Der Tab „Daten" zeigt alle Zeilen des aktuellen Bearbeitungsstands (Head) in einem Grid. Spalten entsprechen dem definierten Schema. Was „Head" bedeutet und wie er sich vom ausgelieferten Stand unterscheidet, erklärt Bearbeitungsstand (Head) & Auslieferungsstatus.

Das Grid lädt immer nur die angezeigte Seite (25, 100 oder 500 Zeilen). Suche, Spaltenfilter und die Filter „Betroffene Zeilen anzeigen" (Typabweichungen) bzw. „Nur fehlerhafte Zeilen" werden auf dem Server über alle Zeilen ausgewertet; die Zeilenzahl unten nennt die Treffer über alle Seiten. Auch sehr große Datasets öffnen deshalb ohne Wartezeit. Suche und Filter wirken auf die gespeicherten Werte — noch nicht gespeicherte Änderungen bleiben sichtbar, verändern aber die Trefferliste erst nach dem Speichern.

Bearbeitungsmodus aktivieren

Zellen sind nicht direkt editierbar. Klicken Sie zuerst oben im Grid auf „Bearbeiten", um den Bearbeitungsmodus zu öffnen. Erst dann erscheinen die Auswahl-Checkboxen, die Aktionsspalte (Duplizieren/Löschen) je Zeile und die Zeile „+ Zeile" am Tabellenende — im Lesemodus bleibt die Ansicht bewusst aufgeräumt und zeigt keine deaktivierten Bedienelemente.

Ein Banner „Bearbeitungsmodus aktiv" bleibt sichtbar, solange Sie im Grid arbeiten, und zeigt einen Hinweis: „Ihre Änderungen werden noch nicht gespeichert."

Zelle bearbeiten

1. Im Bearbeitungsmodus auf eine Zelle klicken → Zelle wird editierbar
2. Wert ändern, mit Enter oder Klick in eine andere Zelle bestätigen

Die Änderung ist damit nur lokal vorgemerkt (Entwurf) — noch nicht gespeichert. Der Button „Bearbeiten" wird zu „Speichern (+hinzugefügt ~geändert -gelöscht)" und zeigt laufend, wie viele Zeilen aktuell als hinzugefügt, geändert bzw. zum Löschen markiert vorliegen.

Primärschlüssel ist bei bestehenden Zeilen schreibgeschützt: Der Wert der Primärschlüssel-Spalte lässt sich bei bereits vorhandenen Zeilen nicht mehr ändern (Tooltipp: „Der Primärschlüssel identifiziert diese Zeile und kann nicht geändert werden."). Benötigen Sie einen anderen Schlüssel, legen Sie eine neue Zeile mit dem gewünschten Wert an und löschen die alte. Bei neu angelegten Zeilen (siehe unten) ist die Primärschlüssel-Spalte weiterhin frei editierbar.

Neue Zeile hinzufügen

Im Bearbeitungsmodus über den Button „+ Zeile" am Ende der Tabelle. Neue Zeilen existieren nur im Bearbeitungsmodus und werden beim Speichern dauerhaft angelegt.

Zeile löschen

Im Bearbeitungsmodus: Zeilenmarkierung (Checkbox links) aktivieren → „Löschen" in der Aktionsleiste. Ein Bestätigungsdialog weist darauf hin: „Diese Zeile wird zum Löschen markiert und beim Speichern dauerhaft entfernt." — die Zeile verschwindet also erst endgültig, wenn Sie anschließend speichern.

Bis dahin bleibt eine zum Löschen markierte Zeile an ihrer Stelle durchgestrichen sichtbar. Über das Symbol „Zeile wiederherstellen" in der Aktionsspalte nehmen Sie die Markierung wieder zurück.

Hinweis: Gelöschte Zeilen sind im Audit-Log weiterhin sichtbar und können in früheren Versionen eingesehen werden.

Änderungen speichern oder verwerfen

• „Speichern" (zeigt die Anzahl hinzugefügter/geänderter/gelöschter Zeilen) übernimmt alle vorgemerkten Änderungen in einem Schritt, verlässt den Bearbeitungsmodus und erzeugt die entsprechenden Audit-Einträge.
• „Verwerfen" löscht alle noch nicht gespeicherten Änderungen der aktuellen Sitzung nach Rückfrage („Änderungen verwerfen? Alle nicht gespeicherten Änderungen gehen verloren.") — bereits gespeicherte Versionen sind davon nicht betroffen.
• Enthalten die vorgemerkten Änderungen ungültige Fremdschlüsselwerte, blockiert das Tool das Speichern, bis diese korrigiert oder entfernt wurden (siehe Beziehungen zwischen Datasets).

Massenänderungen

Mehrere Zeilen im Bearbeitungsmodus über die Checkboxen markieren → Aktionsleiste zeigt Optionen für:

• Zeilen löschen
• Feldwert für alle markierten Zeilen setzen (Primärschlüssel-, berechnete Spalten und schreibgeschützte importierte Fremdschlüssel-Spalten ausgenommen)

Die Checkbox im Tabellenkopf markiert alle Zeilen der angezeigten Seite. Die Markierung bleibt beim Blättern und Filtern erhalten — so können Sie Zeilen über mehrere Seiten hinweg sammeln. Liegen markierte Zeilen außerhalb der angezeigten Seite, nennt die Aktionsleiste ihre Anzahl („davon N nicht auf dieser Seite"). Die Massenaktionen wirken immer auf alle markierten Zeilen.

Alle gefilterten Zeilen auswählen: Passen mehr Zeilen zum Filter, als die Seite zeigt, und haben Sie alle Zeilen der angezeigten Seite markiert, bietet die Aktionsleiste „Alle N gefilterten Zeilen auswählen“ an. Ein Klick markiert alle Treffer über alle Seiten hinweg, die Aktionsleiste bestätigt mit „Alle N gefilterten Zeilen sind ausgewählt.“ So ändern oder löschen Sie zum Beispiel alle Zeilen einer Suche in einem Schritt.

• Es lassen sich höchstens 5.000 Zeilen auf einmal auswählen. Passen mehr Zeilen zum Filter, grenzen Sie den Filter weiter ein.
• Ändern Sie danach den Filter, hebt MDM Lite diese Auswahl auf, damit keine Massenaktion Zeilen außerhalb des neuen Filters trifft.
• „Auswahl aufheben“ entfernt die Markierung wieder.

7. Hierarchien abbilden: Tabelle mit Beziehungen oder Baum?

MDM Lite bietet zwei Wege, eine Hierarchie abzubilden — welcher passt, hängt davon ab, ob die Ebenen fest oder variabel sind:

Standard ist „Tabelle". „Baum" ist nur dann die richtige Wahl, wenn alle drei Bedingungen zutreffen: (1) Einträge derselben Art sind ineinander verschachtelt, (2) die Tiefe ist variabel oder steht vorab nicht fest, (3) alle Ebenen haben dieselben Spalten. Der Typ ist nach dem Anlegen nicht mehr änderbar — im Zweifel „Tabelle" wählen.

Beispiel: Land → Region → Kontinent (Hierarchie über Beziehungen)

1. Drei Datasets vom Typ Tabelle anlegen: Kontinent, Region, Land.
2. Im Dataset Region eine Beziehung zu Kontinent anlegen (Tab „Beziehungen" → „+ Beziehung hinzufügen").
3. Im Dataset Land eine Beziehung zu Region anlegen.
4. Importreihenfolge: von oben nach unten — zuerst Kontinent, dann Region, zuletzt Land. Der Grund: FK-Werte werden beim Import gegen das jeweilige Ziel-Dataset geprüft, das Ziel muss also bereits befüllt sein.

Jede Ebene bleibt ein eigenständiges Dataset mit eigenem Lookup, eigenen Rollen und eigener Versionshistorie — siehe Abschnitt 11, Beziehungen zwischen Datasets.

7.1 Baum-Datasets (Eltern-Kind-Hierarchie)

Bei Datasets vom Typ Baum hat jede Zeile einen optionalen Parent (Elternknoten). Damit entstehen Eltern-Kind-Hierarchien beliebiger Tiefe innerhalb eines einzigen Datasets. Das ist etwas anderes als eine „Beziehung" (siehe Abschnitt 11) — der Elternknoten-Verweis verbindet Zeilen desselben Datasets, eine Beziehung verbindet zwei verschiedene Datasets.

Baumansicht vs. Tabellenansicht

• Baumansicht: Zeigt die Hierarchie als aufklappbaren Baum — ideal zur Navigation
• Tabellenansicht: Zeigt alle Zeilen flach mit der Spalte parent — ideal für Massenbearbeitung

Zwischen den Ansichten wechseln über den Schalter oben rechts im Tabellen-Tab.

Knoten anlegen & verschieben

In der Baumansicht legen Sie neue Knoten gezielt unter einem Elternknoten an: Knoten auswählen → „Unterknoten hinzufügen". Ohne Auswahl wird ein Root-Knoten angelegt.

Um einen bestehenden Knoten umzuhängen (anderen Elternknoten zuweisen), wechseln Sie in die Tabellenansicht und ändern den Wert in der Spalte parent. Alternativ lässt sich die Hierarchie per Import (Spalte parent/parent_business_key) neu setzen.

Root-Knoten

Knoten ohne Parent sind Root-Knoten (oberste Ebene). Ein Dataset kann mehrere Root-Knoten haben.

8. Zeitliche Gültigkeit

Jede Zeile kann mit einem Gültigkeitszeitraum versehen werden. Das ermöglicht historisch korrekte Auswertungen.

Felder

Regeln

• Gültig bis muss nach Gültig ab liegen
• Für denselben Business Key dürfen sich Zeiträume nicht überlappen
• Historisierung erfolgt durch neue Zeilen — bestehende Zeilen werden nicht überschrieben

As-Of-Abfrage

Über die API kann der Datenstand zu einem beliebigen Stichtag abgerufen werden:

GET /api/datasets/{id}/as-of?date=2024-12-31

Das DWH erhält damit genau die Datensätze, die am angegebenen Datum gültig waren.

Zusammenspiel mit der Versionsaufbewahrung: Ist für den Mandanten oder das Dataset ein Limit für vorgehaltene Versionen konfiguriert (siehe Versionsaufbewahrung (Retention)), liefert As-Of stets den besten noch vorhandenen gültigen Stand. Liegt der angefragte Stichtag vor dem ältesten noch vorhandenen Snapshot, ist das historisch exakte Ergebnis nicht mehr rekonstruierbar. Ohne konfiguriertes Limit (Standard: unbegrenzt) besteht diese Einschränkung nicht.

9. Import (CSV / Excel)

Wann Import statt manueller Eingabe?

Import empfiehlt sich für:

• Erstbefüllung eines neuen Datasets aus einer Quelldatei
• Regelmäßige Aktualisierungen aus einem Quellsystem
• Massenänderungen an vielen Zeilen gleichzeitig

Unterstützte Dateiformate

Import starten

1. Dataset öffnen → Button „Importieren" (oben rechts im Detail-Bereich)
2. Datei auswählen
3. Import-Modus wählen:

4. Fehlerverhalten wählen:

5. „Validieren" klicken — das Tool prüft die Datei, ohne sie zu importieren

Mehrere Excel-Blätter

Enthält eine Excel-Datei mehrere Arbeitsblätter, fragt das Tool, welches Blatt importiert werden soll, bevor Schema und Daten gelesen werden. Enthält nur eines der Blätter tatsächlich Daten (die übrigen sind leer), wählt das Tool dieses Blatt automatisch aus — unabhängig davon, an welcher Position es in der Datei steht — und die Abfrage entfällt.

Validierungsphasen

Das Tool prüft in mehreren Stufen:

1. Dateiformat — ist die Datei parsebar?
2. Schema-Konformität — sind alle Pflichtfelder vorhanden?
3. Zeilenebene — Typkonformität, Pflichtfelder, Enum-Werte
4. Konsistenz — keine doppelten Business Keys, keine Zeitüberlappungen
5. Referenzielle Integrität — alle Foreign-Key-Werte existieren im Zieldataset

Fehlerbericht

Bei Validierungsfehlern zeigt das Tool einen strukturierten Fehlerbericht:

Zeile 5:  Spalte 'filial_nr' — Pflichtfeld darf nicht leer sein
Zeile 12: Spalte 'sort_order' — Erwartet Integer, gefunden: "abc"
Zeile 23: Spalte 'region' — Wert 'Mitte' nicht in Auswahlliste

Der Import wird vollständig abgelehnt solange Fehler vorliegen — es gibt keinen Teilimport.

CSV-Format

• Trennzeichen: Semikolon (;) oder Komma (,) — wird automatisch erkannt
• Kodierung: UTF-8
• Erste Zeile: Spaltenüberschriften (müssen den Schema-Spaltennamen entsprechen)
• Datum: ISO 8601 (YYYY-MM-DD)

Import aus der Zwischenablage

Statt eine Datei zu speichern und hochzuladen, können Sie einen Ausschnitt direkt aus Excel, Google Sheets oder LibreOffice in ein bestehendes Dataset übernehmen:

1. Markieren Sie in der Tabellenkalkulation den Bereich inklusive Kopfzeile und kopieren Sie ihn mit Strg+C (Mac: Cmd+C).
2. Öffnen Sie in MDM Lite den Import-Dialog des Datasets und drücken Sie Strg+V, oder klicken Sie auf „Aus Zwischenablage einfügen". Verweigert der Browser den Zugriff auf die Zwischenablage, nutzen Sie Strg+V.
3. Prüfen Sie die Vorschau: Sie zeigt die Kopfzeile, die ersten 20 Zeilen sowie die Anzahl der Zeilen und Spalten. Kopfzeilen, die keiner Spalte des Datasets entsprechen, und fehlende Pflichtspalten sind markiert. Beim Abgleich spielen Groß-/Kleinschreibung sowie unsichtbare Zeichen und überzählige Leerzeichen keine Rolle.
4. Mit „Verwerfen" löschen Sie die Vorschau und können erneut einfügen. „Importieren" wird erst nach der Vorschau aktiv.

Gültig-ab, Erweiterte Einstellungen, Fehlerbehandlung und Protokollierung funktionieren wie beim Datei-Import. Zahlen und Datumswerte im deutschen Format (1.234,56, 01.10.2026) werden wie beim CSV-Import behandelt. Es gilt dieselbe Größenbegrenzung wie beim Datei-Upload.

Hinweis: Ist die Zwischenablage leer oder enthält nur eine einzelne Zelle ohne Kopfzeile bzw. keine Datenzeile, erscheint eine Fehlermeldung.

KI-gestützte Schema-Erkennung

Beim Onboarding eines neuen Datasets (noch ohne Schema) analysiert das Tool die hochgeladene Datei automatisch und schlägt vor:

• Spaltentypen (String, Integer, Datum, Enum)
• Welche Spalte der Business Key sein könnte
• Ob eine Spalte Enum-Charakter hat (wenige verschiedene Werte)

Die Vorschläge können vor dem Speichern angepasst werden.

Schnellimport (Vorschau & Bestätigen)

Für den häufigsten Fall ist der Import bewusst kurz gehalten: Nach dem Hochladen sehen Sie eine Vorschau (Zeilen- und Feldanzahl, erkannter Eindeutiger Bezeichner, erste Datenzeilen) und bestätigen direkt. Detaileinstellungen — Spalten umbenennen/ausschließen, Import-Modus, Fehlerverhalten — liegen unter „Erweiterte Einstellungen" und müssen nur im Bedarfsfall geöffnet werden. Wird kein Eindeutiger Bezeichner erkannt, öffnet sich dieser Bereich automatisch und fordert zur Auswahl auf.

Bulk-Import (mehrere Dateien)

Über das Symbol „Bulk-Import" in der Aktionsleiste des Explorers laden Sie mehrere Dateien gleichzeitig hoch — pro Datei entsteht ein eigenes neues Dataset. Jede Datei durchläuft einen kurzen Review-Schritt (Schema, Zielordner), danach werden alle in einem Durchgang importiert.

Duplikat-Erkennung

Beim Anlegen eines Datasets aus einer Datei prüft das Tool, ob bereits ein strukturell ähnliches Dataset existiert (gleiche/ähnliche Spalten). Ist das der Fall, erscheint ein Hinweisbanner mit dem passenden Dataset. Sie können dann direkt in das bestehende Dataset importieren, statt ein Duplikat anzulegen.

Dateigrößen-Limit

Das Limit gilt immer für die gesamte Datei, nicht für einzelne Spalten oder Zeilen. Wird es überschritten, meldet die Anwendung dies bereits beim Auswählen der Datei — mit der Größe Ihrer Datei und dem erlaubten Maximum.

10. Versionierung & Historie

Wie Versionierung funktioniert

Jede gespeicherte Änderung — Zelleditierung, Massenbearbeitung, Import, Schema-Änderung, Restore — erzeugt eine neue Dataset-Version. Versionen sind:

• Nummeriert (v1, v2, v3, ...), lückenlos vergeben
• Unveränderlich — eine einmal erstellte Version wird nie überschrieben; jede Korrektur legt eine neue Version an, nie eine rückwirkende Änderung an einer alten
• Per API abrufbar — das DWH kann jeden noch vorhandenen historischen Stand laden (Grenzen dazu siehe Versionsaufbewahrung (Retention))

Bearbeitungsstand (Head) & Auslieferungsstatus

Für die tägliche Arbeit sind zwei Begriffe wichtig:

Im Regelfall sind Head und ausgelieferte Version identisch. Sie können auseinanderfallen, wenn:

• die neueste Version fehlerhaft ist (z. B. Pflichtfeld verletzt, ungültige Referenz) — die Auslieferung bleibt dann auf der letzten fehlerfreien Version stehen, während der Head im Editor bereits die fehlerhaften Daten zeigt und zur Korrektur öffnet, oder
• die neueste Version zeitlich geplant ist (Stichtag in der Zukunft, siehe Zeitliche Gültigkeit) — sie wird erst zum Stichtag automatisch zur ausgelieferten Version.

Ein Banner oberhalb des Grids zeigt den jeweiligen Zustand:

Über „Fehler anzeigen" springen Sie zu den betroffenen Zeilen/Spalten, die direkt im Grid markiert werden; der Schalter „Nur fehlerhafte Zeilen" blendet alle übrigen Zeilen aus. Beheben Sie die Fehler und speichern Sie — sobald die neue Version gültig ist, verschwindet das Banner automatisch, und die Auslieferung schaltet auf den korrigierten Stand um. Ein eigener Bestätigungsschritt ist dafür nicht nötig.

Reine Leseansichten ohne Editor (z. B. der Explorer), die auf ein Dataset ohne auslieferbare Version treffen, zeigen den Hinweis „Keine auslieferbare Version vorhanden — im Editor korrigieren."

Baum-Datasets: Auslieferung angehalten. Bei einem Baum ändert MDM Lite Knoten an Ort und Stelle, ältere Versionen eines Baums lassen sich deshalb nicht wiederherstellen. Ist die neueste Version eines Baums fehlerhaft, liefert MDM Lite gar keine Version aus, auch keine ältere. Der Tab „Baum" zeigt dann das Banner „Auslieferung angehalten, bis die Fehler behoben sind" mit dem Button „Fehler anzeigen". Ist die neueste Version erst ab einem zukünftigen Stichtag gültig, lautet es „Auslieferung angehalten bis <Datum>". Solange die Auslieferung angehalten ist:

• antworten API, DWH-Notebook und Export mit einem Fehler (409, Code delivery_halted_invalid_tree bzw. delivery_halted_scheduled_tree), statt veraltete oder fehlerhafte Daten zu liefern,
• überträgt MDM Lite nichts an OneLake. Die Datenplattform behält den zuletzt bereitgestellten Stand, das Plattform-Kennzeichen zeigt „Plattform ⚠ v<M> · angehalten",
• liefert der KI-Zugriff (MCP) für den Baum keine Knoten, sondern einen entsprechenden Hinweis.

Sobald Sie die Fehler beheben (bzw. der Stichtag erreicht ist), läuft die Auslieferung automatisch mit der neuesten Version weiter. Bei Tabellen-Datasets bleibt alles wie oben beschrieben: Dort wird weiter die letzte fehlerfreie Version ausgeliefert.

Tipp: Ein Knoten mit einem Gültig-ab-Datum in der Zukunft macht die neue Baumversion zu einer geplanten Version. Die Auslieferung des ganzen Baums ist dann bis zu diesem Datum angehalten.

Schema-Stand historischer Versionen

Jede Version merkt sich, welche Spalten zum Zeitpunkt ihrer Entstehung im Schema existierten. Entfernen Sie später eine Spalte, bleibt sie in allen älteren Versionen unverändert sichtbar:

• Beim Öffnen einer älteren Version im Tab „Verlauf"
• Bei einer As-Of-Abfrage auf einen Stichtag vor der Entfernung
• Im Versionsvergleich (Diff)
• Beim Export einer historischen Version

Die Werte der entfernten Spalte gehen dabei nicht verloren — sie stehen weiterhin in den betroffenen Zeilen. Nicht mehr angezeigt werden sie nur im aktuellen Bearbeitungsstand (Head) und in neu erzeugten Versionen, weil die Spalte dort nicht mehr Teil des Schemas ist.

Die Klassifizierung bleibt beim Löschen erhalten: Beim Löschen einer Spalte merkt sich MDM Lite ihre letzte Klassifizierung. Diese Stufe gilt in allen älteren Versionen weiter, die noch Werte der Spalte enthalten, so als stünde die Spalte noch im Schema. Wurde eine Spalte also erst hochgestuft (etwa auf „Vertraulich") und dann gelöscht, sehen Nutzer und API-Keys unterhalb dieser Stufe ihre Werte auch in älteren Versionen nicht: nicht beim Öffnen im Verlauf, nicht bei As-Of-Abfragen, nicht im Versionsvergleich, nicht im Export, nicht über MCP und nicht in den Bereitstellungstabellen. Das gilt ebenso für eine Spalte, die beim Entfernen einer Beziehung oder beim Kopieren in eine andere Umgebung (Modus „Aktualisieren") wegfällt. Legen Sie später eine Spalte gleichen Namens neu an, hat sie ihre eigene Stufe, die nur für ihre eigenen Versionen gilt. Ein Restore einer älteren Version übernimmt die Werte der gelöschten Spalte nicht in die neue Spalte, wenn die gelöschte Spalte strenger eingestuft war.

Versionen von vor Einführung dieser Funktion kennen ihren damaligen Spaltenstand nicht. Sie zeigen deshalb mit dem ausdrücklichen Hinweis „Schema-Stand dieser Version wurde nicht aufgezeichnet (vor Einführung der Schema-Versionierung) — Anzeige mit dem aktuellen Schema." stattdessen das aktuelle Schema an. Das ist bewusst so gelöst: Statt einen historischen Spaltenstand zu erraten, kennzeichnet das Tool ihn klar als nicht aufgezeichnet — betrachten Sie „aktuelles Schema" in diesem Fall nicht als verlässliche Aussage über den damaligen Stand.

Versionsübersicht

Tab „Verlauf" zeigt:

• Alle noch vorhandenen Versionen mit Zeitstempel, Autor und Kommentar
• Validierungsstatus (gültig/ungültig) und ob die Version aktuell ausgeliefert wird
• Bei per Restore erzeugten Versionen das Badge „wiederhergestellt aus v{n}"
• Beim Öffnen einer Version deren damaligen Spaltenstand (siehe Schema-Stand historischer Versionen) — inkl. Spalten, die im aktuellen Schema nicht mehr existieren
• Ggf. einen Hinweis, dass ältere Versionen gemäß Aufbewahrungsrichtlinie entfernt wurden (siehe Versionsaufbewahrung (Retention))

Version vergleichen (Diff)

1. In der Versionsübersicht zwei Versionen auswählen
2. „Vergleichen" klicken
3. Das Tool zeigt Zeilen, die hinzugekommen, geändert oder entfernt wurden — inkl. Vorher/Nachher-Werten, auf Basis des jeweiligen Spaltenstands beider Versionen

Fehlt für eine der beiden verglichenen Versionen der aufgezeichnete Schema-Stand (Alt-Version, siehe oben), weist ein Hinweis darauf hin, dass für diesen Zeitpunkt ersatzweise das aktuelle Schema herangezogen wird.

Version wiederherstellen (Restore)

Eine ältere Version lässt sich als neuen Bearbeitungsstand reaktivieren, ohne die Historie zu verändern: Restore kopiert die Zeilen der gewählten Version forward-only in eine brandneue Version (Head + 1). Die Quellversion und alle dazwischenliegenden Versionen bleiben dabei unverändert — es handelt sich nicht um ein Zurücksetzen, sondern um eine neue Version mit altem Inhalt.

Wichtig — Restore betrifft ausschließlich die Daten, nicht das Schema: Restore stellt die Zeilen der gewählten Version wieder her. Das aktuelle Schema (welche Spalten es gibt) wird dabei nicht verändert und nicht zurückgesetzt — auch dann nicht, wenn die wiederhergestellte Version ursprünglich zusätzliche oder andere Spalten hatte. Erwarten Sie nach einem Restore, dass eine inzwischen entfernte Spalte automatisch wieder im Schema auftaucht: Das tut sie nicht. Auch ihre Werte werden nicht wiederhergestellt — Restore übernimmt nur Werte von Spalten, die es im aktuellen Schema gibt. Sonst stünden etwa die Werte einer gelöschten vertraulichen Spalte ohne Klassifizierung wieder in den Daten. Die Quellversion selbst behält ihre Werte unverändert; brauchen Sie eine entfernte Spalte samt Werten zurück, setzen Sie als Admin des Datasets den Spaltenstand mit „Daten und Schema wiederherstellen“ zurück, statt nur die Daten wiederherzustellen.

Voraussetzungen:

• Rolle Editor oder höher auf dem Dataset
• Dataset-Typ Tabelle — für Datasets vom Typ Baum steht Restore noch nicht zur Verfügung (Bäume sind nur teilversioniert; ein vollständiger Baum-Snapshot je Version existiert nicht)
• Die gewählte Version muss älter als der Head sein — der Head selbst lässt sich nicht auf sich selbst wiederherstellen

Vorgehen:

1. Im Tab „Verlauf" bei der gewünschten Version „Als neue Version wiederherstellen" wählen
2. Der Dialog nennt Quell- und Zielversionsnummer, verlinkt eine Diff-Vorschau und zeigt unter „Schema-Abweichung zu Version #{Quellversion}" die Unterschiede zwischen dem Schema-Stand der Quellversion und dem aktuellen Schema:
   • Seitdem entfernte Spalten — deren Werte werden nicht wiederhergestellt. Admins des Datasets sehen unter der Abweichung den Hinweis „Auch den Spaltenstand von Version #{Quellversion} wiederherstellen?“ mit dem Button „Daten und Schema wiederherstellen…“ (siehe Schema auf älteren Stand zurücksetzen). Alle anderen sehen „Den Spaltenstand kann ein Admin dieses Datasets zurücksetzen.“
   • Seitdem neu hinzugekommene Spalten — die wiederhergestellten Zeilen haben dafür keine Werte
   • Spalten mit geänderter Struktur (Typ/Pflicht/Unique/Primärschlüssel) seit der Quellversion
   • Ist für die Quellversion kein Schema-Stand aufgezeichnet (Alt-Version, siehe Schema-Stand historischer Versionen), weist der Dialog darauf hin, dass sich eine Abweichung nicht ermitteln lässt
3. Optional einen Kommentar eintragen (max. 500 Zeichen)
4. „Auf v{Zielversion} wiederherstellen" klicken

Ergebnis: Version #{Zielversion} entsteht als Kopie der Zeilen von Version #{Quellversion}. Zwei Sonderfälle:

• War die Quellversion selbst ungültig, übernimmt die Kopie diesen Zustand (der Dialog warnt vorab davon) — sinnvoll, wenn Sie den fehlerhaften Stand gezielt als neue Arbeitsbasis zur Korrektur übernehmen wollen.
• Die Kopie wird gegen das aktuelle Schema neu validiert, nicht gegen das Schema zum Zeitpunkt der Quellversion. Hat sich das Schema seitdem geändert („Schema-Drift", siehe Schritt 2 oben), kann das Ergebnis ungültig werden — die bisherige gültige Version bleibt dann weiterhin ausgeliefert, und das Banner aus Bearbeitungsstand (Head) & Auslieferungsstatus führt zur Korrektur.

Wiederhergestellte Versionen sind in der Versionsübersicht am Badge „wiederhergestellt aus v{Quellversion}" erkennbar.

Schema auf älteren Stand zurücksetzen

Der normale Restore stellt nur Daten wieder her. Mit „Schema auf Stand v{n} zurücksetzen…“ setzen Sie dagegen den Spaltenstand auf den Stand einer älteren Version zurück: welche Spalten es gibt, ihre Typen, Pflicht- und Eindeutigkeits-Einstellungen, Primärschlüssel, Beziehungen und die Reihenfolge. MDM Lite zeigt vorher genau, was sich ändert, und verlangt für jeden Konflikt eine bewusste Entscheidung.

Wann nutze ich das? Typische Fälle:

• Eine Spalte wurde versehentlich gelöscht, und Sie möchten sie samt ihren Werten zurück.
• Ein Typ, eine Pflicht-Einstellung oder der Primärschlüssel wurde geändert, und der frühere Stand war richtig.
• Spalten wurden vertauscht, und die frühere Reihenfolge soll wieder gelten.
• Sie möchten eine ältere Version samt ihrer Spalten wiederherstellen, nicht nur die Zeilen.

Voraussetzungen:

• Rolle Admin auf dem Dataset (wie jede Schemaänderung). Für Editor und Viewer fehlt die Aktion; im Restore-Dialog steht stattdessen der Hinweis „Den Spaltenstand kann ein Admin dieses Datasets zurücksetzen.“
• Dataset-Typ Tabelle. Für Baum-Datasets gibt es die Aktion nicht (siehe Grenzen).
• Die gewählte Version muss älter als der Head sein und einen gespeicherten Spaltenstand haben. Für Versionen aus der Zeit vor der Schema-Versionierung (siehe Schema-Stand historischer Versionen) bietet MDM Lite die Aktion nicht an.
• Die Version darf nicht per Aufbewahrungsrichtlinie entfernt worden sein.

Die zwei Umfänge

Beispiel: Version 5 hatte die Spalten Code, Name und Region. In Version 8 wurde Region gelöscht, danach wurden Zeilen geändert. Der Head ist Version 11.

• Mit „Nur Schema“ entsteht Version 12 mit Code, Name und Region. Die Zeilen sind die aus Version 11, Region ist aber leer, weil Version 11 keine Region-Werte mehr enthält.
• Mit „Schema und Daten von Version #5“ entsteht Version 12 mit Code, Name und Region und den Zeilen von Version 5, inklusive der Region-Werte. Änderungen an den Zeilen seit Version 5 enthält die neue Version nicht, sie bleiben aber in den Versionen 6 bis 11 erhalten.

Wollen Sie eine versehentlich gelöschte Spalte samt Werten zurück, wählen Sie meist „Schema und Daten“, sofern sich die Zeilen seit damals nicht wesentlich geändert haben. Sonst nutzen Sie „Nur Schema“ und tragen die Werte neu ein oder importieren sie.

Vorgehen

1. Öffnen Sie das Dataset und wechseln Sie in den Tab „Verlauf“.

2. Wählen Sie im Aktionsmenü der gewünschten Version „Schema auf Stand v{n} zurücksetzen…“. Der Dialog öffnet sich mit dem Umfang „Nur Schema“. Alternativ öffnen Sie bei der Version „Als neue Version wiederherstellen“. Zeigt der Dialog eine Schema-Abweichung, klicken Sie unter „Auch den Spaltenstand von Version #n wiederherstellen?“ auf „Daten und Schema wiederherstellen…“. Der Dialog zum Zurücksetzen öffnet sich dann mit dem Umfang „Schema und Daten“.

3. Wählen Sie unter „Was soll wiederhergestellt werden?“ den Umfang. Die Erklärung darunter nennt die Nummer der neuen Version.

4. MDM Lite ermittelt die Änderungen („Änderungen werden ermittelt …“) und zeigt sie gruppiert:

   • „Werden wieder angelegt“: Spalten, die es heute nicht gibt. Je Spalte steht dabei, ob sie leer startet („Wird ohne Werte angelegt …“) oder im Umfang „Schema und Daten“ „Werte aus Version #n: {Anzahl} Zeilen“ mitbringt.
   • „Werden entfernt“: Spalten, die es in Version #n noch nicht gab. Bei Spalten mit Werten steht, wie viele Zeilen betroffen sind und dass ältere Versionen die Werte behalten.
   • „Werden angeglichen“: Spalten, deren Typ, Bezeichnung, Pflicht, Eindeutigkeit, Primärschlüssel, Auswahlwerte, Validierungsregel oder Beziehung abweichen, mit Alt- und Neuwert. Eine geänderte Reihenfolge steht als eigene Zeile.
   • „Klassifizierung“: Spalten, deren Klassifizierung angehoben wird.
   • Hinweise zu Glossar-Zuordnungen (Purview), zur Auslieferung und zu Beziehungen anderer Datasets, die auf eine entfernte Spalte zeigen.

   Ist alles gleich, steht dort „Der Spaltenstand von Version #n entspricht dem aktuellen.“ und es gibt nichts auszuführen.

5. Lösen Sie jeden Konflikt (siehe unten). Solange einer offen ist, bleibt der Button gesperrt.

6. Bei Datenverlust (siehe unten) setzen Sie das Häkchen bei „Mir ist klar, dass die Werte entfernter Spalten in der neuen Version fehlen.“

7. Optional tragen Sie einen Kommentar ein (max. 500 Zeichen). Er erscheint in Verlauf und Änderungsprotokoll.

8. Klicken Sie auf „Schema zurücksetzen (Version #{neu})“ bzw. „Schema und Daten wiederherstellen (Version #{neu})“.

Ergebnis: Eine neue Version entsteht mit dem Spaltenstand von Version #n. MDM Lite meldet „Version #{neu} wurde mit dem Spaltenstand von Version #n erzeugt.“ (bei „Schema und Daten“: „… mit Spaltenstand und Daten von Version #n erzeugt.“). Im Tab „Verlauf“ trägt die Version das Badge „Schema aus v{n}“ bzw. „Daten und Schema aus v{n}“. Im Änderungsprotokoll steht je Spalte ein Eintrag zur Änderung sowie ein Sammeleintrag „hat das Schema auf einen früheren Stand zurückgesetzt“ (ohne Spaltennamen). Wird die neue Version ungültig, meldet MDM Lite „Version #{neu} wurde erzeugt, ist aber ungültig ({Anzahl} Fehler) – die bisherige gültige Version wird weiterhin ausgeliefert.“

Konflikte und wie Sie sie auflösen

Ein Konflikt blockiert das Zurücksetzen, bis Sie unter „Bitte für jeden Konflikt wählen, wie verfahren werden soll“ eine Auflösung wählen. MDM Lite entscheidet nie still für Sie.

Beziehungen (Fremdschlüssel-Spalten). Eine Spalte, die in Version #n auf ein anderes Dataset verwies, lässt sich nur wieder anlegen, wenn das Ziel heute noch passt. Sonst erscheint ein Konflikt, etwa „Das Ziel der Beziehung gibt es in dieser Umgebung nicht (mehr).“, „Das Ziel der Beziehung ist archiviert …“, „… ist ein Baum. Beziehungen gibt es nur zwischen Tabellen.“, „Die Zielspalte … fehlt im Ziel oder ist dort weder Primärschlüssel noch eindeutig.“ oder „Die Beziehung würde einen Kreis bilden.“ Dafür gibt es:

Daten, die nicht passen (Umfang „Nur Schema“). Passt der Typ der alten Version nicht zu den aktuellen Werten (z. B. Text in einer Zahl-Spalte: „{Anzahl} Werte lassen sich nicht von … in … umwandeln (z. B. …)“) oder wären mit einer Spalte als Primärschlüssel Schlüssel doppelt, wählen Sie „Diese Spalte nicht zurücksetzen“ oder bereinigen zuerst die Daten. Im Umfang „Schema und Daten“ entfallen Typkonflikte in der Regel, weil die Zeilen von Version #n bereits zum damaligen Spaltenstand passen.

Weitere Konflikte betreffen den Bereitstellungsmodus „Aktualisieren & ergänzen (Upsert)“ (er braucht einen Primärschlüssel), fortlaufende Nummern (lassen sich für vorhandene Zeilen nicht nachträglich anlegen), inzwischen reservierte Spaltennamen und berechnete Spalten, deren Berechnungsvorschrift in Version #n nicht gespeichert ist. Auch hier hilft „Diese Spalte nicht zurücksetzen“.

Ergibt die Kombination Ihrer Entscheidungen ein ungültiges Schema (etwa mehrere Primärschlüssel oder eine berechnete Spalte ohne Quellspalte), nennt MDM Lite den Grund. Lösen Sie die Konflikte dann anders auf.

Datenverlust bestätigen

Im Umfang „Nur Schema“ fehlen Spalten, die es in Version #n noch nicht gab, in der neuen Version, und damit ihre Werte. Tragen solche Spalten Werte, verlangt MDM Lite Ihre ausdrückliche Bestätigung (Häkchen „Mir ist klar, …“). Ältere Versionen behalten die Werte und sind weiterhin lesbar, sie gehen nicht verloren. Im Umfang „Schema und Daten“ ersetzt der Stand von Version #n die Zeilen vollständig. Die Vorschau nennt trotzdem je Spalte, wie viele Werte in der neuen Version fehlen.

Klassifizierung sinkt nie

Das Zurücksetzen senkt nie die Klassifizierung einer Spalte (siehe Sensitivitätsklassifizierung). Es gilt immer die strengste Stufe aus der aktuellen Stufe, der Stufe in Version #n und der gemerkten Stufe einer gelöschten Spalte. War eine Spalte damals strenger eingestuft als heute, wird sie wieder angehoben („Klassifizierung von {Spalte} wird angehoben: {alt} → {neu}“). Eine berechnete Spalte ist mindestens so streng wie ihre Quellspalten. Wollen Sie eine Stufe danach senken, tun Sie das bewusst im Tab „Spalten“. Ist eine beteiligte Spalte höher klassifiziert, als Ihre Rolle bearbeiten darf, lehnt MDM Lite den Vorgang ab.

Was zurückgesetzt wird und was bleibt

Spalten, die es heute und in Version #n gibt, behalten ihre Identität: Glossar-Zuordnungen, eingehende Beziehungen anderer Datasets und Links bleiben erhalten. Eine zurückgeholte Glossar-Zuordnung wird zur Prüfung markiert, weil sich der Begriff inzwischen geändert haben kann. Entfernte Spalten verlieren ihre Zuordnung, wie beim Löschen.

Auswirkung auf die Bereitstellung

Das Zurücksetzen ist eine gewöhnliche Schemaänderung mit neuer Version. Ist das Dataset veröffentlicht und die neue Version gültig, wird sie sofort ausgeliefert: REST-API, Export, die Bereitstellungstabelle auf der Datenplattform und MCP zeigen den geänderten Spaltenstand. Konsumenten sehen dann zum Beispiel eine zurückgeholte Spalte. Die Vorschau weist darauf hin („Das Dataset ist veröffentlicht …“). Wird die neue Version voraussichtlich ungültig, etwa weil Pflichtspalten ohne Werte entstehen, warnt die Vorschau, und ausgeliefert wird weiter die letzte gültige Version.

Wichtig zur Historie

Das Zurücksetzen schreibt die Historie nie um. Es entsteht immer eine neue Version; die Quellversion, alle Versionen dazwischen und das Änderungsprotokoll bleiben unverändert. Das gilt auch für ein Dataset im Status Entwurf. Der Vorgang läuft vollständig oder gar nicht: Bei einem Fehler oder Konflikt entsteht keine Version.

Grenzen des Schema-Zurücksetzens

• Nur Tabellen, nicht Bäume („Für Bäume lässt sich das Schema nicht zurücksetzen – nur für Tabellen.“).
• Nur für Admins des Datasets („Nur Admins dieses Datasets dürfen das Schema zurücksetzen.“). API-Keys können es nicht auslösen, auch nicht mit Schreibzugriff.
• Kein MCP-Werkzeug: KI-Assistenten lesen das Ergebnis, lösen das Zurücksetzen aber nicht aus.
• Nicht verfügbar für Versionen ohne gespeicherten Spaltenstand und für per Aufbewahrungsrichtlinie entfernte Versionen („Diese Version wurde durch die Aufbewahrungsrichtlinie entfernt und kann nicht mehr wiederhergestellt werden.“).
• Ändert jemand das Schema, während Ihre Vorschau offen ist, meldet MDM Lite „Das Schema hat sich inzwischen geändert. Die Vorschau wurde aktualisiert – bitte erneut prüfen.“ Prüfen Sie die aktualisierte Vorschau und bestätigen Sie erneut.
• Arbeitet gerade jemand anderes am Dataset („Das Dataset wird gerade von jemand anderem geändert. Bitte in wenigen Sekunden erneut versuchen.“), ändert sich nichts. Versuchen Sie es nach wenigen Sekunden erneut.
• Entfernte Spalten, auf die Beziehungen anderer Datasets zeigen, machen diese Beziehungen defekt. Die Vorschau nennt die Anzahl („{n} Beziehungen aus anderen Datasets zeigen auf diese Spalte und sind danach defekt.“). Prüfen Sie diese Datasets danach.
• Verweisen Zeilen anderer Datasets noch auf Einträge, die die neue Version nicht mehr enthält (Umfang „Schema und Daten“), speichert MDM Lite nichts und zeigt „Einträge werden noch verwendet“ (siehe Beziehungen).

Titel des Browser-Tabs anpassen (Tenant-Admin)

Sind mehrere MDM-Lite-Tabs offen (verschiedene Mandanten oder Umgebungen wie TEST und PROD), lassen sie sich am Tab-Titel unterscheiden. Ohne Konfiguration lautet der Titel <Mandantenname>@MDM Lite, z. B. Contoso@MDM Lite. Vor der Anmeldung und ohne ausgewählten Mandanten steht nur „MDM Lite". Beim Mandantenwechsel aktualisiert sich der Titel automatisch.

Voraussetzungen: Rolle Admin oder AppAdmin im Mandanten.

Schritte:

1. Einstellungen → Allgemein (Route /settings/general) öffnen
2. Im Feld „Titel des Browser-Tabs" ein Muster eintragen, z. B. {tenant} ({env})@MDM Lite — leer lassen für den Standard
3. Die Vorschau unter dem Feld prüfen, dann „Speichern" klicken

Beispiel: {tenant} ({env})@MDM Lite ergibt auf der TEST-Installation Contoso (TEST)@MDM Lite.

Verifikation: Nach dem Speichern und einem Neuladen der Seite zeigt der Browser-Tab den neuen Titel.

Troubleshooting:

Die Änderung wird im Änderungsprotokoll des Mandanten (alter und neuer Wert) festgehalten.

Versionsaufbewahrung (Retention)

Ohne Konfiguration hebt MDM Lite alle Versionen eines Datasets unbegrenzt auf. Bei Datasets mit häufigen Änderungen (z. B. mehrfach täglichem API-Import) wächst die Historie dadurch entsprechend schnell. Admins können deshalb pro Mandant und zusätzlich pro Dataset ein Limit für die Anzahl vorgehaltener Versionen setzen; überzählige ältere Versionen werden automatisch entfernt, sobald eine neue Version entsteht.

Was bleibt garantiert erhalten, auch wenn das Limit überschritten würde:

Das Limit ist damit eine Zielgröße, keine harte Garantie — die Schutzregeln haben immer Vorrang.

Speicherverbrauch

MDM Lite speichert je Version nur die tatsächlich geänderten Zeilen — eine unveränderte Zeile wird beim nächsten Commit, bei einer Massenänderung oder bei einem Import nicht neu geschrieben, sondern von der Vorversion übernommen. Der Speicherbedarf einer Historie wächst deshalb mit der Anzahl geänderter Zeilen (Δ), nicht mit „Anzahl Versionen × Anzahl Zeilen" wie bei einem reinen Voll-Snapshot-Modell. Bei einem Dataset mit täglichem Import und 1 % geänderten Zeilen macht das über ein Jahr einen Unterschied von Größenordnungen (Beispielrechnung: ≈ 50 MB statt ≈ 3,5 GB pro Jahr bei 15.000 Zeilen). Für Sie als Anwender ändert sich dadurch nichts am Verhalten — jede Version bleibt weiterhin vollständig lesbar (Diff, Restore, As-Of, Export), nur der Speicherplatz im Hintergrund wird effizienter genutzt.

Mandanten-weites Limit einrichten (Tenant-Admin)

Voraussetzungen: Rolle Admin oder AppAdmin im Mandanten.

Schritte:

1. Einstellungen → Allgemein (Route /settings/general) öffnen
2. Feld „Maximal vorgehaltene Versionen pro Dataset" ausfüllen — leer lassen für unbegrenzt
3. „Speichern" klicken

Verifikation: Die erfolgreiche Einrichtung erkennen Sie daran, dass beim nächsten Öffnen der Seite der gespeicherte Wert wieder angezeigt wird, und dass der Tab „Verwaltung" eines beliebigen Datasets denselben Wert unter „Mandanten-Limit: {n} Versionen" ausweist.

Troubleshooting:

Dataset-spezifisches Override einrichten

Ein Dataset kann ein strengeres (niedrigeres) Limit als das Mandanten-Limit erhalten — z. B. für ein besonders schreibintensives Dataset. Das Override kann das Mandanten-Limit nicht überschreiten.

Voraussetzungen: Rolle Admin auf dem Dataset (höhere Hürde als Editor, da Retention Historie unwiderruflich entfernt).

Schritte:

1. Dataset öffnen → Tab „Verwaltung"
2. Feld „Override für dieses Dataset" ausfüllen — leer lassen, um das Mandanten-Limit zu übernehmen
3. „Speichern" klicken

Verifikation: Die Anzeige „Effektives Limit: {n} Versionen" unterhalb des Formulars zeigt den tatsächlich wirksamen Wert — das Minimum aus Mandanten-Limit und Override.

Troubleshooting:

Auswirkung im laufenden Betrieb

• Im Tab „Verlauf" erscheint der Hinweis „{n} ältere Version(en) wurden gemäß Aufbewahrungsrichtlinie (max. {Limit}) entfernt.", sobald tatsächlich Versionen entfernt wurden.
• Ein direkter Zugriff auf eine entfernte Versionsnummer (Diff, Restore, API mit version=n) liefert „Diese Version wurde gemäß Aufbewahrungsrichtlinie entfernt." (HTTP 410 Gone, Fehlercode version_pruned) statt eines gewöhnlichen „nicht gefunden".
• As-Of-Abfragen (siehe Zeitliche Gültigkeit) liefern weiterhin den besten noch vorhandenen Stand — Stichtage vor dem ältesten erhaltenen Snapshot lassen sich dann nicht mehr exakt rekonstruieren.
• Das Entfernen läuft automatisch im Hintergrund des jeweils nächsten schreibenden Vorgangs (Commit, Import, Restore, Schema-Änderung); es gibt keinen manuell auszulösenden „Jetzt aufräumen"-Button und keinen separaten Zeitplan.

Audit-Log

Das Audit-Log ist das detaillierteste Protokoll: Jede einzelne Zellenänderung ist erfasst mit:

• Nutzer (Name / E-Mail)
• Zeitstempel
• Spalte, alter Wert, neuer Wert

Das Audit-Log kann nicht verändert oder gelöscht werden — es ist die unveränderliche Sicherheitsgrundlage.

Änderungs-Feed (dataset-übergreifend)

Über „Änderungen" in der Kopfzeile öffnen Sie einen dataset-übergreifenden Änderungs-Feed: alle Änderungen über sämtliche Datasets hinweg in einem wählbaren Zeitfenster (Standard: letzte 24 Stunden), neueste zuerst.

• Filter nach Zeitraum (von/bis) und optional einem Dataset
• Spalten: Zeitpunkt · Dataset · Art · Benutzer · Zusammenfassung · Version
• Klick auf ein Dataset springt direkt dorthin
• CSV-Export der angezeigten Einträge

Das ist das schnellste Werkzeug zur Ursachensuche, wenn das DWH Auffälligkeiten zeigt — eine Abfrage zeigt alle Änderungen im relevanten Zeitraum (API: GET /api/changes?since=…).

Globale Suche

Über das Suchfeld in der Kopfzeile (oder ⌘K / Strg+K) durchsuchen Sie tenant-weit Datasets, Ordner und Spalten. Treffer sind nach Typ gruppiert; mit den Pfeiltasten navigieren und mit Enter öffnen. Es werden nur Datasets angezeigt, auf die Sie Zugriff haben.

11. Beziehungen zwischen Datasets

Datasets können über Foreign-Key-Spalten miteinander verknüpft werden. Beispiel: Eine „Filiale"-Zeile verweist auf eine „Region" aus dem Regionen-Dataset.

Über Beziehungen bilden Sie auch Hierarchien mit festen Ebenen ab — siehe Abschnitt 7, Hierarchien abbilden für die Entscheidungsregel und das durchgerechnete Beispiel Land → Region → Kontinent. Beziehungen funktionieren derzeit nur zwischen Datasets vom Typ Tabelle — ein Dataset vom Typ Baum kann bisher weder Ziel noch Quelle einer Beziehung sein.

Beziehung anlegen

Variante A – Schema-Tab:

1. Im Schema-Tab eine neue Spalte vom Typ ForeignKey anlegen
2. Im Feld „Referenz-Dataset" das Ziel-Dataset (und die Schlüsselspalte) auswählen
3. Speichern

Variante B – Quick-Connect: Im Tab Beziehungen direkt „Verbinden" wählen und das Ziel-Dataset auswählen. Das Tool legt die FK-Spalte automatisch an und wählt den passenden Eingabemodus (Dropdown bei wenigen, Suchfeld bei vielen Zielzeilen).

In der Tabellenansicht erscheint die FK-Spalte je nach Modus als Dropdown oder Suchfeld — nur gültige Werte aus dem Referenz-Dataset sind auswählbar. „Gültig" heißt: Der Eintrag ist im Referenz-Dataset heute gültig. Gelöschte oder beendete Einträge werden nicht mehr angeboten. Importierte FK-Spalten sind im Grid schreibgeschützt; über das Symbol ↗ lässt sich der Zieldatensatz einsehen.

Verweist eine Zeile auf einen Eintrag, den es im Referenz-Dataset nicht mehr gibt, zeigt das Grid den Wert rot mit ⚠ an (Tooltip „Nicht gefunden – Eintrag existiert im Ziel nicht mehr"). Korrigieren Sie solche Werte, indem Sie einen gültigen Eintrag wählen, oder holen Sie den Eintrag im Referenz-Dataset zurück (z. B. per Restore einer früheren Version).

KI-gestützte FK-Erkennung

Das Tool kann passende Beziehungen automatisch vorschlagen: Im Schema- oder Beziehungen-Tab „Beziehungen erkennen" wählen. Die KI/Heuristik analysiert Spaltennamen und Werte und liefert Kandidaten mit Confidence-Score. Vorschläge können einzeln übernommen werden — dabei wird die FK-Spalte angelegt und (auf Wunsch) befüllt.

Wer darf das? Die Erkennung erfordert mindestens die Rolle Editor auf dem Dataset. Viewer und API-Keys ohne write-Scope erhalten eine Fehlermeldung (403). Ein API-Key, der auf bestimmte Datasets beschränkt ist, berücksichtigt nur diese.

Was wird vorgeschlagen? Nur Spalten, die Sie laut Datenklassifizierung sehen dürfen, und nur Ziel-Datasets, die Sie lesen dürfen und deren Schlüsselspalte für Sie sichtbar ist.

Was geht an den KI-Anbieter? Die Web-Oberfläche nutzt die heuristische Erkennung; der KI-Modus (mode: "ai" oder "hybrid") ist über die API erreichbar. Dabei gehen nur Spaltennamen, Beschriftungen und bis zu zehn Beispielwerte von Spalten bis zur Stufe internal an den KI-Anbieter — auch für Admins. Spalten der Stufen confidential und restricted und Ziel-Datasets mit einer solchen Schlüsselspalte werden nie übermittelt. Jeder KI-Aufruf erscheint im Änderungsprotokoll des Datasets als Eintrag ai_query (ohne die übermittelten Werte).

Ist kein KI-Provider konfiguriert, weist das Tool darauf hin; die heuristische Erkennung funktioniert weiterhin. Über die API liefert mode: "ai" dann 503 mit ai_not_configured, mode: "hybrid" die heuristischen Vorschläge mit dem Hinweis aiError.

Beziehungen-Tab

Der Tab „Beziehungen" zeigt eine visuelle Übersicht (mit Verbindungslinien) aller ein- und ausgehenden Verknüpfungen des Datasets. Jede Beziehung trägt einen Health-Status:

Zusätzlich zählt jede ausgehende Beziehung die Zeilen, deren Wert im Ziel nicht gefunden wird (z. B. „2 Zeilen verweisen auf nicht gefundene Einträge"). Gezählt werden nur Zeilen, die heute oder künftig gültig sind; abgelaufene Historie zählt nicht.

Eine Beziehung lässt sich hier per Papierkorb-Symbol wieder entfernen — das löscht die zugehörige Fremdschlüssel-Spalte. Der Bestätigungsdialog zeigt eine Vorschau, wie viele Zeilen Werte enthalten, sowie denselben Breaking-Change-Hinweis wie beim Löschen einer Spalte im Schema-Tab: Neue Versionen, Exporte und API-Antworten enthalten die Spalte danach nicht mehr, und API-Konsumenten oder DWH-Abfragen, die sie erwarten, können fehlschlagen. Historische Versionen behalten die Spalte und ihre Werte unverändert (siehe Schema-Stand historischer Versionen). Wollen Sie stattdessen nur die Verknüpfung auflösen und die Werte als normale Textspalte behalten, nutzen Sie „Beziehung entkoppeln" statt „entfernen".

Validierung bei Import & Pflege

Foreign-Key-Werte werden beim Import und beim Speichern im Grid geprüft: Ein Wert, der im Referenz-Dataset nicht existiert, führt zu einem Validierungsfehler bzw. blockiert das Speichern. Geprüft wird gegen die Einträge, die am Stichtag der Änderung gültig sind (bei einer Zeile mit späterem „Gültig ab" an diesem Datum). Ein Eintrag, der zum Stichtag bereits beendet ist, gilt als nicht gefunden. Der Beziehungen-Tab zeigt die Zahl der Zeilen mit nicht gefundenen Werten je Beziehung.

Verwendete Einträge können nicht gelöscht werden

Ein Eintrag, auf den Zeilen eines anderen Datasets noch verweisen, lässt sich nicht entfernen. Das gilt für das Löschen (auch Mehrfachauswahl), das Ändern des Schlüsselwerts, einen Import „Vollständig ersetzen" ohne diesen Eintrag, einen Restore auf eine Version ohne ihn und die Kopie aus einer anderen Umgebung. Das Tool speichert dann nichts und zeigt den Dialog „Einträge werden noch verwendet": welches Dataset, welche Spalte, wie viele Zeilen und welche Einträge betroffen sind, mit Link zum verweisenden Dataset. Datasets, die Sie nicht lesen dürfen, erscheinen nur als Zahl („2 Zeilen in Datasets ohne Ihre Leseberechtigung"). Ihre Änderungen im Grid bleiben erhalten, die betroffenen Zeilen sind markiert.

So gehen Sie vor:

1. Im verweisenden Dataset die betroffenen Zeilen ändern: einen anderen Eintrag wählen, den Wert leeren (wenn die Spalte kein Pflichtfeld ist) oder die Zeile zum selben Stichtag beenden.
2. Danach den Eintrag im Referenz-Dataset entfernen.

Nicht blockiert werden:

• Verweise aus Zeilen, die vor dem Stichtag der Löschung enden.
• Beziehungen mit Herkunft „Importiert": Die Werte gehören dem Quellsystem. Das Tool speichert die Änderung und zeigt einen Hinweis, welche Datasets jetzt auf entfernte Einträge verweisen.
• Andere Löschungen, wenn ein Verweis schon vorher ins Leere zeigte.

Der Schutz greift beim Entfernen einzelner Einträge. Das Löschen einer ganzen Schlüsselspalte im Schema-Tab bleibt erlaubt und zeigt nur eine Warnung.

12. Export

Manueller Export

Im Tab „Daten" einer Dataset-Detailseite: Button „Exportieren" → Format wählen:

Der Export enthält immer die aktuelle Version der Daten. Historische Versionen können über die API exportiert werden (?version= bzw. ?date=, alle Formate) — Spaltenkopf bzw. Feldsatz entsprechen dabei dem Schema-Stand der exportierten Version: Ein Export einer Version von vor einer Spaltenentfernung enthält diese Spalte samt Werten weiterhin.

SQL-Export konfigurieren

Der SQL-Export öffnet einen eigenen Dialog mit zwei Optionen:

Sowohl die generierte CREATE TABLE-Anweisung als auch der Dateiname des SQL-Exports verwenden standardmäßig den technischen Namen des Datasets als Tabellennamen.

13. Bereitstellung auf der Datenplattform (Microsoft Fabric)

MDM Lite stellt veröffentlichte Datasets auf der Datenplattform (Microsoft Fabric/OneLake) bereit — als Tabelle, die auf allen Bereitstellungswegen identisch aufgebaut ist. Eine vollständige Schritt-für-Schritt-Anleitung — einschließlich Azure-Konfiguration, SAS-Token-Einrichtung, Notebook-Generierung und Planung — finden Sie im dedizierten Integrationshandbuch:

→ Microsoft Fabric & OneLake – Integrationshandbuch

Wichtiger Hinweis für bestehende Tabellen: Der Tabellenvertrag in diesem Kapitel gilt seit dem Release von September 2026 ohne Übergangsfrist. Bereits auf der Datenplattform bestehende Tabellen werden beim nächsten Export bzw. Notebook-Lauf mit dem neuen Schema überschrieben (neue Systemspalten, andere Datentypen, die Spalte rdm_row_id entfällt ersatzlos). Views, Power-BI-Modelle oder Pipelines, die die alten Systemspalten lesen, müssen danach angepasst werden. Details siehe Moduswechsel und Aufbewahrung unten und den Abschnitt „Einmalige Umstellung“ im Integrationshandbuch.

Bereitstellungsweg und Bereitstellungsmodus

Zwei unabhängige Achsen bestimmen, was auf der Datenplattform ankommt:

Die Bereitstellungswege:

Gleich, welchen Weg Sie nutzen: Für dasselbe Dataset im selben Bereitstellungsmodus sind Tabellenname, Spalten, Datentypen, Systemspalten und Zeilen byte-identisch. Ein Wechsel des Wegs (z. B. von OneLake Shortcut zu OneLake direkt) ändert an der Tabelle selbst nichts.

Den Bereitstellungsmodus wählen

Ort: Dataset öffnen → Tab „Integration" → Abschnitt „Bereitstellung auf der Datenplattform" (derselbe Abschnitt wie der technische Tabellenname weiter unten).

Berechtigung: Nur ein Mitglied mit der effektiven Dataset-Rolle Admin kann den Modus ändern — dieselbe Hürde wie beim technischen Namen und bei der Versionsaufbewahrung. Editor und Viewer sehen die Auswahl schreibgeschützt. API-Keys können den Modus nie ändern (sie erreichen nie die Rolle Admin).

Standard: Jedes Dataset — neu angelegt oder bereits bestehend — startet im Modus „Aktueller Stand".

Die verfügbaren Modi:

„Aktualisieren & ergänzen (Upsert)" ist in der Oberfläche als dritter, geplanter Modus sichtbar, aber noch nicht verfügbar — ein Speicherversuch mit diesem Wert schlägt fehl. Bis dahin deckt die Historie mit einer entsprechend gefilterten Abfrage denselben Anwendungsfall ab (siehe Zwei Zeitachsen).

Entscheidungshilfe:

• Brauchen Berichte und Power-BI-Modelle nur den heutigen Stand? → Aktueller Stand.
• Muss das DWH jeden früheren Wert einer Zeile nachvollziehen können (SCD Typ 2, Revisionssicherheit)? → Vollständige Historie.
• Ist ein Dataset ein Baum? → nur Aktueller Stand möglich (siehe Baum-Datasets in der Bereitstellung).

Die Modi am Beispiel

Kostenstellen-Dataset mit Schlüsselspalte kostenstelle und Spalte name. Verlauf:

Aktueller Stand nach Version 8 — nur die heute gültige bzw. zuletzt gültige Zeile:

„Marketing" (die alte Bezeichnung) und 4799 fehlen — genau wie in einer normalen, nicht historisierten Tabelle.

Vollständige Historie nach Version 8 — jeder Stand, der je ausgeliefert war, als eigene Zeile:

Nichts wird überschrieben oder gelöscht: WHERE rdm_is_current ergibt exakt dieselben fachlichen Zeilen wie „Aktueller Stand".

Zwei Zeitachsen: fachliche Gültigkeit und Bereitstellungszeit

Die Bereitstellungstabelle unterscheidet zwei unabhängige Zeitachsen:

Ein leeres rdm_valid_to heißt „fachlich noch offen", nicht „aktueller Stand" — ein korrigierter Name ist ein überholter Stand, auch wenn seine fachliche Gültigkeit weiterhin offen ist (siehe Zeile 1 im Beispiel oben).

Drei typische Abfragen auf der Historie:

-- Heute fachlich gültige Zeilen (funktioniert in jedem Modus)
SELECT * FROM kostenstellen
WHERE rdm_valid_from <= current_date
  AND (rdm_valid_to IS NULL OR rdm_valid_to >= current_date)

-- Aktueller Stand, aus der Historie abgeleitet
SELECT * FROM kostenstellen_history WHERE rdm_is_current

-- Stand zum Monatsabschluss (30.06., 23:59 UTC)
SELECT * FROM kostenstellen_history
WHERE rdm_delivered_at <= '2026-06-30T23:59:00Z'
  AND (rdm_delivered_to IS NULL OR rdm_delivered_to > '2026-06-30T23:59:00Z')

Was passiert bei …

Welche Spalten auf die Datenplattform gehen (Klassifizierung)

Wie im Klassifizierungskapitel beschrieben, kann jede Spalte eine Sensitivitätsstufe tragen (public, internal, confidential, restricted). Für die Bereitstellung gilt zusätzlich eine mandantenweite höchste Klassifizierung für die Bereitstellung (in diesem Kapitel kurz „höchste Klassifizierung"): Nur Spalten, deren Stufe diese höchste Klassifizierung nicht überschreitet, verlassen MDM Lite auf irgendeinem Bereitstellungsweg. Es gibt genau eine höchste Klassifizierung für alle Wege — OneLake und Fabric-Notebook zeigen also nie unterschiedliche Spaltenmengen.

Die höchste Klassifizierung ist die einzige Einstellung, die steuert, was MDM Lite in Richtung Datenplattform verlässt. In der Oberfläche der Bereitstellung heißen die Stufen Öffentlich, Intern, Vertraulich und Eingeschränkt (technisch public bis restricted; im Schema-Tab heißt die höchste Stufe „Streng vertraulich" — gemeint ist dieselbe Stufe restricted).

Wichtig — API-Key-Klassifizierungsgrenzen gelten für OneLake nicht: Die Klassifizierungsgrenze eines einzelnen API-Keys oder einer Rolle formt die Tabelle auf dem OneLake-Weg (direkt und Shortcut) nie. Dort zählt ausschließlich die höchste Klassifizierung des Mandanten. Nur auf dem Notebook-Weg, der die Tabelle über die API abruft, wird ein Key mit niedrigerer höchste Klassifizierung abgewiesen (siehe unten).

Die höchste Klassifizierung einrichten und ändern

Voraussetzungen: Rolle Admin oder AppAdmin im Mandanten.

Schritte:

1. Einstellungen → Allgemein öffnen.
2. Im Feld „Höchste Klassifizierung für die Bereitstellung" die Stufe wählen — Öffentlich, Intern (Standard), Vertraulich oder Eingeschränkt.
3. „Speichern" klicken.
4. Ändert sich die Stufe, öffnet MDM Lite vor dem Speichern einen Bestätigungsdialog (siehe nächster Abschnitt). Lesen Sie ihn und bestätigen Sie mit „Klassifizierung anheben" bzw. „Klassifizierung senken" — oder brechen Sie mit „Abbrechen" ab. Ohne Bestätigung wird nichts gespeichert.

Verifikation: Der gespeicherte Wert wird beim nächsten Öffnen der Seite wieder angezeigt. Unter Einstellungen → Microsoft Fabric steht die höchste Klassifizierung schreibgeschützt als „Höchste Klassifizierung für die Bereitstellung: …" (mit dem Zusatz „Spalten bis einschließlich … werden übertragen; höher eingestufte bleiben in MDM Lite") und dem Hinweis „Ändern unter Einstellungen → Allgemein". Neben der Einstellung (Allgemein, Fabric, Bereitstellungs-Assistenten) erklärt das Info-Symbol i die Rangfolge der Stufen: Öffentlich < Intern < Vertraulich < Eingeschränkt. Es lässt sich per Tastatur öffnen und mit Esc schließen. Editoren und Viewer können die höchste Klassifizierung nicht ändern; wo die Oberfläche sie anzeigt, verweist sie für sie auf die Mandanten-Admins.

Der Bestätigungsdialog beim Ändern

Jede Änderung der höchsten Klassifizierung wird bestätigt, weil sie bestimmt, welche Daten MDM Lite verlassen. Der Text hängt von der Richtung ab:

Automatischer Rückzug: Beim Senken entfernt MDM Lite zurückgezogene Spalten auf dem OneLake-Weg von selbst, in der Regel innerhalb von etwa 30 Sekunden und auch ohne aktivierten Auto-Export; die abgelösten Dateien mit den Werten werden dabei sofort gelöscht (siehe Was beim Senken oder Hochstufen mit bereits bereitgestellten Daten passiert).

Ein bewusster „Vollexport": höchste Klassifizierung auf „Eingeschränkt"

Sollen alle Spalten eines Datasets auf die Datenplattform gehen — auch vertrauliche und eingeschränkte —, gibt es dafür keinen Sonderweg: Sie setzen die höchste Klassifizierung bewusst auf Eingeschränkt. Das ist eine Entscheidung des Mandanten, die für alle Datasets und alle Bereitstellungswege gilt.

1. Einstellungen → Allgemein → „Höchste Klassifizierung für die Bereitstellung" → Eingeschränkt wählen, „Speichern" klicken.
2. Im Dialog „Höchste Klassifizierung für die Bereitstellung auf „Eingeschränkt" anheben?" die Hinweise lesen und „Klassifizierung anheben" klicken.
3. Erwartetes Ergebnis: Ab der nächsten Bereitstellung enthält jede Tabelle alle Spalten. Die Hinweisboxen zeigen dann „Diese Bereitstellung enthält alle Spalten dieses Datasets, auch vertrauliche und eingeschränkte. Die Zugriffskontrolle auf der Datenplattform liegt bei Ihnen."

Was das bedeutet:

• Die Zugriffskontrolle liegt ab dann auf der Datenplattform. MDM Lite schützt die Werte dort nicht; wer das Lakehouse lesen darf, sieht sie. Prüfen Sie vorher die Berechtigungen im Fabric-Workspace.
• Lese-Keys und Notebooks: Bei Vertraulich kann ein Lese-Key die Bereitstellungstabelle nicht mehr abrufen, bei Eingeschränkt kein API-Key mehr. Die Notebook-Wege (Einzel- und Sammel-Notebook) sind dann nicht nutzbar; nutzen Sie OneLake direkt oder OneLake Shortcut.
• Ausweg bei „Vertraulich": Ein Admin kann für ein Notebook einen API-Key mit Schreibzugriff verwenden. Das ist deutlich mehr Recht, als das Notebook braucht (es schreibt nie zurück nach MDM Lite): Der Key kann Daten in MDM Lite verändern. Die Oberfläche schlägt das nie vor. Nutzen Sie diesen Weg nur, wenn OneLake keine Option ist, hinterlegen Sie den Key in Key Vault (siehe Sicherheitshinweise im Integrationshandbuch) und widerrufen Sie ihn, sobald er nicht mehr gebraucht wird. Ein eigener, nur lesender Schlüsseltyp für die Bereitstellung ist für ein späteres Release vorgesehen.

Die Hinweise in der Oberfläche

Damit Sie nicht raten müssen, was ein Bereitstellungsweg enthält, zeigt MDM Lite an fünf Stellen, welche Spalten auf die Datenplattform gehen. Dazu gehört die höchste Klassifizierung im Dataset („Höchste Klassifizierung in diesem Dataset: …"). MDM Lite leitet sie aus den Spalten des aktuellen Schemas ab und speichert sie nicht.

Der Text hängt von der höchsten Klassifizierung ab. „Diese Bereitstellung enthält alle Spalten …" erscheint nur, wenn es stimmt: bei höchster Klassifizierung Eingeschränkt oder wenn keine Spalte zurückgehalten wird und das Dataset vertrauliche Spalten hat. Sonst lautet der Text „Diese Bereitstellung enthält Spalten bis zur Stufe „[Stufe]". [n] Spalte(n) dieses Datasets liegen darüber und werden nicht bereitgestellt." (bzw. „… Keine Spalte dieses Datasets liegt darüber."). Die Namen zurückgehaltener Spalten nennt MDM Lite nie, nur ihre Anzahl.

Auch auf der Datenplattform sichtbar: Jede Bereitstellungstabelle trägt die Tabelleneigenschaft mdmlite.deliveryCeiling mit der höchsten Klassifizierung, mit der sie geschrieben wurde (public, internal, confidential oder restricted). So sehen auch Konsumenten und Governance-Werkzeuge in Fabric, bis zu welcher Stufe die Tabelle Daten enthält. Prüfen können Sie das mit SHOW TBLPROPERTIES <Tabelle> bzw. DESCRIBE DETAIL <Tabelle>. Nach einer Änderung der höchsten Klassifizierung zeigt die Eigenschaft den neuen Wert, sobald die Tabelle neu bereitgestellt wurde. Tabellen, die vor Einführung der Eigenschaft geschrieben wurden, erhalten sie bei ihrer nächsten Bereitstellung.

Auswirkungen auf die Tabelle

• Eine Spalte über der höchsten Klassifizierung fehlt komplett in der Tabelle (kein null-Platzhalter mit sichtbarem Spaltennamen — die Spalte existiert dort gar nicht). Sie wird nicht maskiert, und die Bereitstellung wird deswegen nicht blockiert.
• Liegt jede fachliche Spalte über der höchsten Klassifizierung, wird die Tabelle trotzdem bereitgestellt, nur mit den Systemspalten.
• Liegt die Schlüsselspalte über der höchsten Klassifizierung, meldet ein Speicherversuch von „Aktualisieren & ergänzen (Upsert)" einen Fehler, sobald dieser Modus verfügbar ist; bei Baum-Datasets wird die Bereitstellung zurückgehalten.
• Ein API-Key oder eine Rolle mit einer eigenen Klassifizierungsgrenze unterhalb der mandantenweiten höchsten Klassifizierung wird beim Abruf der Bereitstellungstabelle über die API (Notebook-Weg) mit 403 delivery_ceiling_exceeds_key abgewiesen — die Tabelle wird nie „für ihn" zusätzlich gekürzt, weil sie auf allen Wegen identisch bleiben muss. Diese Regel gilt in allen drei Modi gleich.
• In der Historie: Eine Spalte gehört zum Vertrag, sobald sie in mindestens einer je ausgelieferten Version innerhalb der höchsten Klassifizierung lag — auch wenn sie inzwischen höher eingestuft wurde. Wird sie später über die höchste Klassifizierung hochgestuft, verschwindet sie bei der nächsten Bereitstellung aus allen Ständen, auch aus bereits ausgelieferten historischen Zeilen (siehe Was passiert bei …).
• Eine Änderung der höchsten Klassifizierung oder der Klassifizierung einer Spalte wirkt erst bei der nächsten Bereitstellung. Wie der Rückzug bereits geschriebener Daten abläuft, steht im nächsten Abschnitt.

Was beim Senken oder Hochstufen mit bereits bereitgestellten Daten passiert

Wird eine Spalte hochgestuft oder die höchste Klassifizierung gesenkt, liegt die Spalte zunächst noch in der Tabelle auf der Datenplattform. MDM Lite nennt diesen Zustand Rückzug ausstehend (pending) und schreibt die Tabelle auf dem OneLake-Weg von selbst ohne die Spalte neu.

So läuft der Rückzug ab:

• Automatischer Rückzugslauf (OneLake direkt und Shortcut): Ein Hintergrundprozess erkennt den ausstehenden Rückzug und stellt die Tabelle in der Regel innerhalb von etwa 30 Sekunden ohne die zurückgezogenen Spalten neu bereit, auch wenn der automatische Export aus ist. Im Änderungsprotokoll erscheint das als Bereitstellung mit dem Auslöser retraction und dem Akteur system:retraction. Der Rückzug läuft für jedes Ziel jeder Umgebung, auch für deaktivierte Umgebungen.
• Abgelöste Datendateien werden sofort gelöscht: Direkt nach dem neuen Commit löscht MDM Lite alle abgelösten Datendateien der Tabelle, auch ältere, die sonst noch bis zu 7 Tage für die Delta-Zeitreise liegen blieben. Eine Zeitreise auf den Stand vor dem Rückzug ist danach nicht mehr möglich. Das gilt für jede Bereitstellung, die einen Rückzug schreibt, auch für einen manuellen Export.
• Fabric-Notebook: Das Notebook holt die Tabelle beim nächsten Lauf ohne die Spalte; was es auf der Plattform ablegt, verwaltet es selbst.
• Scheitert das Löschen einzelner Dateien, meldet der Export-Status einen Fehler, und MDM Lite wiederholt den Rückzug nach einer Wartezeit (Standard 5 Minuten) automatisch.
• Erst hochgestuft, dann gelöscht: Beim Löschen einer Spalte hält MDM Lite ihre letzte Stufe fest (siehe Schema-Stand historischer Versionen). Lag diese Stufe über
  höchsten Klassifizierung für die Bereitstellung, gilt der Rückzug als ausstehend, und MDM Lite stellt die Tabelle ohne die Werte älterer Versionen neu bereit, in beiden Modi und auf beiden Wegen. Das gilt auch dann, wenn die Spalte gelöscht wurde, bevor der Rückzugslauf die Hochstufung gesehen hat. Bestehende, vor dieser Funktion gelöschte Spalten hat MDM Lite beim Update aus den Schema-Snapshots und dem Änderungsprotokoll nachgetragen.

Den Status ansehen: Bei ausstehendem Rückzug zeigt die Oberfläche (Assistent, Tab „Integration") die Warnung „Die Tabelle auf der Datenplattform enthält noch Spalten, die inzwischen über
höchsten Klassifizierung für die Bereitstellung liegen. MDM Lite entfernt sie bei der nächsten Bereitstellung." Im Assistenten ersetzt sie den Hinweis „Die Daten wurden nach dem Export geändert". Dieselbe Information liefert die API im Block delivery_classification des OneLake-Status (Details im Integrationshandbuch):

Was tun bei pending?

1. Warten Sie ab: Der automatische Rückzug läuft in der Regel etwa 30 Sekunden nach der Änderung. Wer nicht warten will, löst die Bereitstellung selbst aus: Jetzt bereitstellen bzw. Exportieren → Export to OneLake; bei Notebooks der nächste Lauf.
2. Erwartetes Ergebnis: Die Warnung verschwindet, die Tabelle enthält die Spalten nicht mehr, und die abgelösten Datendateien sind gelöscht.
3. Prüfen Sie bei Bedarf die übrigen Stellen der Checkliste zu Rückständen (_delta_log, Papierkorb, Kopien).

Was tun bei blocked? MDM Lite schreibt dann nichts. Die Warnung nennt den Grund: „… kann sie derzeit nicht entfernen: [Grund]. Beheben Sie den Grund oder bereinigen Sie die Tabelle auf der Datenplattform."

Die manuelle Bereinigung beschreibt die folgende Checkliste. Blockierte Fälle bereinigt MDM Lite nicht automatisch.

Checkliste für Admins: Rückstände außerhalb von MDM Lite

Auch nach einer Bereitstellung ohne die Spalte können Werte oder Namen an Stellen bleiben, die MDM Lite nicht erreicht. Gehen Sie diese Liste durch, wenn eine Spalte wirklich verschwinden muss, etwa weil sie versehentlich zu niedrig eingestuft war:

Faustregel: Die Klassifizierung schützt davor, dass Daten MDM Lite verlassen. Was bereits auf der Datenplattform angekommen ist, kann MDM Lite nicht in jedem Fall zurückholen. Stufen Sie Spalten deshalb vor der ersten Bereitstellung richtig ein.

Änderungsprotokoll

Jede Bereitstellung auf dem OneLake-Weg erzeugt den Eintrag onelake_exported im Änderungsprotokoll des Datasets. Er enthält zusätzlich delivery_ceiling (die höchste Klassifizierung zum Zeitpunkt der Bereitstellung), withheld_column_count (Anzahl zurückgehaltener Spalten) retraction (true, wenn vor dieser Bereitstellung ein Rückzug ausstand) und deleted_file_count (Anzahl der dabei gelöschten Datendateien). Der automatische Rückzug trägt den Auslöser retraction und den Akteur system:retraction. Die Namen zurückgehaltener Spalten stehen bewusst nie im Protokoll. Das Ändern der höchsten Klassifizierung selbst wird mit Benutzer, Zeitpunkt sowie altem und neuem Wert als delivery_ceiling_changed festgehalten.

Moduswechsel und Aufbewahrung

Beim Ändern des Modus zeigt MDM Lite einen Bestätigungsdialog mit:

• welche Spalten neu hinzukommen oder entfallen,
• wie weit die Historie zurückreicht (abhängig von der Versionsaufbewahrung),
• dem Hinweis, dass Views und Berichte ggf. angepasst werden müssen,
• dem Hinweis, dass der bisherige Tabellenstand noch 7 Tage per Delta-Zeitreise erreichbar bleibt.

Nach dem Bestätigen gibt es keinen separaten Migrationsschritt: Die nächste reguläre Bereitstellung (OneLake in der Regel innerhalb von 30 Sekunden bei aktivem automatischem Export, sonst „Jetzt bereitstellen"; Notebook beim nächsten Lauf) schreibt die Tabelle unter demselben Namen im neuen Modus neu.

Aufbewahrung koppelt an den Modus: „Vollständige Historie" verlangt eine unbegrenzte Versionsaufbewahrung für das Dataset — weder ein Mandanten- noch ein Dataset-Limit darf gesetzt sein (siehe Versionsaufbewahrung). Ist ein Limit aktiv, schlägt das Umschalten auf „Vollständige Historie" mit einer entsprechenden Fehlermeldung fehl; umgekehrt lässt sich ein Aufbewahrungslimit nicht setzen, solange das Dataset im Modus „Vollständige Historie" steht. Die Historie auf der Datenplattform reicht dadurch nie weiter zurück als die in MDM Lite aufbewahrten Versionen — wer lange Historie auf der Datenplattform will, setzt in MDM Lite kein Limit.

Prüfbar über eine Tabelleneigenschaft: Im Modus „Vollständige Historie" trägt die Tabelle zusätzlich die Eigenschaft mdmlite.historyTruncated (true/false, in Fabric per SHOW TBLPROPERTIES bzw. DESCRIBE DETAIL sichtbar). Sie ist immer gesetzt, nicht nur bei tatsächlich abgeschnittener Historie — false bestätigt, dass die Historie lückenlos bis zur ersten je ausgelieferten Version zurückreicht, true zeigt an, dass ältere Versionen durch die Aufbewahrungsregel bereits entfernt wurden. Weil „Vollständige Historie" ohnehin nur bei unbegrenzter Aufbewahrung erlaubt ist, bleibt true in der Praxis auf Datasets beschränkt, die schon vor dem Umschalten auf diesen Modus eine begrenzte Aufbewahrung hatten.

Jede Moduswechsel-Aktion wird mit Benutzer, Zeitpunkt sowie altem und neuem Wert im Änderungsprotokoll des Datasets festgehalten.

Baum-Datasets in der Bereitstellung

Baum-Datasets (Eltern-Kind-Hierarchie) unterstützen aktuell ausschließlich den Modus „Aktueller Stand" — die Radio-Auswahl im Abschnitt „Bereitstellung auf der Datenplattform" zeigt für sie keine weiteren Optionen an, und ein Speicherversuch mit einem anderen Modus scheitert. Grund: Baum-Datasets sind teilversioniert (Knoten werden an Ort und Stelle geändert), frühere Stände lassen sich deshalb nicht exakt nachstellen. Die Tabelle enthält zusätzlich die Systemspalte rdm_parent_key mit dem Schlüssel des Elternknotens (leer = Wurzelknoten). Ist die neueste Version eines Baums fehlerhaft oder erst geplant, ist seine Auslieferung angehalten, siehe Bearbeitungsstand (Head) & Auslieferungsstatus.

Die Bereitstellungswege im Überblick

Jeder Weg transportiert exakt den in diesem Kapitel beschriebenen Tabellenvertrag — Tabellenname, Spalten, Systemspalten, Typen und Zeilen unterscheiden sich nicht danach, welchen Weg Sie wählen. Die vollständige Einrichtung — Azure-Konfiguration, SAS-Token, Service Principal, Notebook-Generierung, Planung, Fehlerbehebung — steht im Integrationshandbuch:

→ Microsoft Fabric & OneLake – Integrationshandbuch, insbesondere das dortige Kapitel „Der Tabellenvertrag".

Bereitstellung je Umgebung einrichten

Jede Umgebung hat ihr eigenes Ziel auf der Datenplattform. So schreibt „Test" in ein Test-Lakehouse, während „Produktion" das Produktiv-Lakehouse beliefert. Die Einrichtung des Ziels (Storage Account oder OneLake direkt) beschreibt das Integrationshandbuch Schritt für Schritt.

Voraussetzung: Rolle Admin.

1. Wechseln Sie im Benutzermenü in die Umgebung, die Sie einrichten möchten, zum Beispiel „Test".
2. Öffnen Sie Einstellungen → Integrationen → Microsoft Fabric. Die Kontextzeile oben nennt die Umgebung.
3. Hat die Umgebung noch kein Ziel, zeigt die Seite „Für die Umgebung „Test" ist keine Bereitstellung eingerichtet." Klicken Sie auf „Bereitstellung für „Test" einrichten".
4. Tragen Sie das Ziel ein und speichern Sie. In einer Umgebung, die nicht Live ist, erscheint beim ersten Aktivieren der Dialog „Bereitstellung in einer Nicht-Live-Umgebung aktivieren?": „Daten der Umgebung „Test" werden nach … geschrieben. MDM Lite gibt damit Daten dieser Umgebung an ein externes System." Bestätigen Sie mit „Aktivieren und Daten übertragen" oder brechen Sie ab. Die Bestätigung steht im Änderungsprotokoll (non_live_egress_confirmed).

Sie erkennen die erfolgreiche Einrichtung daran, dass die Übersicht „Bereitstellung je Umgebung" die Umgebung mit Art, Ziel und dem Status „Aktiv" zeigt und die Schaltfläche „Jetzt synchronisieren (Umgebung „Test")" verfügbar ist.

Übersicht „Bereitstellung je Umgebung": Die Tabelle zeigt je Umgebung die Spalten Umgebung, Art, Ziel, Automatik und Zeitplan und Status.

Mit „Zu dieser Umgebung wechseln" springen Sie in die Umgebung der Zeile. Die aktuelle Zeile trägt „Aktuelle Umgebung". Haben Sie ungespeicherte Eingaben, fragt MDM Lite vor dem Wechsel nach.

Verhalten im Betrieb:

Zielschutz: Zwei Umgebungen dürfen nicht in dieselben Tabellenordner schreiben. Beim Speichern prüft MDM Lite das und meldet sonst: „Dieses Ziel wird bereits von der Umgebung „Produktion" verwendet. Wählen Sie ein anderes Lakehouse oder einen anderen, nicht verschachtelten Pfad-Präfix." Gehört ein Tabellenordner schon einem anderen Dataset, bricht die Bereitstellung ab, bevor etwas geschrieben wird: „Der Tabellenordner gehört einem anderen Dataset. MDM Lite schreibt nicht darüber. Prüfen Sie Ziel und Pfad-Präfix." Ursachen und Lösungen: Zielschutz und Fehlermeldungen.

Mandantenweite Grenzen: Die höchste Klassifizierung für die Bereitstellung (Einstellungen → Allgemein) und die Bereitstellungs-Obergrenze gelten für den ganzen Mandanten, also für jedes Ziel jeder Umgebung gleich. Der Bestätigungsdialog nennt, wie viele Ziele in wie vielen Umgebungen betroffen sind, zum Beispiel „Die Änderung wirkt auf 3 Bereitstellungsziele in 3 Umgebungen."

Notebooks, KI-Zugriff und API-Keys: Sie sind je Umgebung getrennt konfiguriert (siehe Integrationen und Umgebungen). Notebook-Erzeugung und MCP-Zugriff sind in Nicht-Live-Umgebungen standardmäßig aus. Nutzen Sie einen Nicht-Live-MCP-Zugriff bisher per X-Environment-Header, schalten Sie ihn in der jeweiligen Umgebung unter Einstellungen → Integrationen → MCP-Server (KI-Zugriff) mit „KI-Zugriff (MCP) für diese Umgebung erlauben" einmalig ein. Ohne Freigabe antwortet MDM Lite mit 404.

Technischer Tabellenname

Jedes Dataset hat neben seinem frei änderbaren Anzeigenamen einen technischen Namen — den Tabellen- bzw. Ordnernamen, unter dem es auf der Datenplattform bereitgestellt wird. Er gilt für alle Bereitstellungswege gleichermaßen: OneLake-/Delta-Export, Datei- und SQL-Export, DWH-Notebook (Teil B/D des Integrationshandbuchs) und die Data-Lineage in Microsoft Purview (siehe Kapitel 15) zeigen alle auf denselben Namen.

Stabil und unabhängig vom Anzeigenamen: Der technische Name wird beim Anlegen festgelegt und ändert sich danach nicht mehr von selbst. Benennen Sie das Dataset um, bleibt der technische Name unverändert — Views, Power-BI-Modelle und Pipelines, die die Tabelle lesen, brechen dadurch nicht.

Vorschlag beim Anlegen: MDM Lite leitet den technischen Namen aus dem Dataset-Namen ab — Kleinbuchstaben, deutsche Umlaute ausgeschrieben (ä→ae, ö→oe, ü→ue, ß→ss), alles außer Buchstaben/Ziffern zu einem einzelnen Unterstrich zusammengefasst (z. B. wird „Filialen München Süd" zu filialen_muenchen_sued). Ist der Vorschlag schon vergeben, hängt MDM Lite automatisch _2, _3, … an. Solange Sie das Feld beim Anlegen nicht selbst bearbeiten, folgt der Vorschlag live Ihrer Eingabe im Namensfeld.

Format-Regeln: Buchstaben (groß oder klein), Ziffern und Unterstriche, darf nicht mit einer Ziffer beginnen, maximal 64 Zeichen. Groß-/Kleinschreibung ist erlaubt (KostenStelle ist ein gültiger Name), zwei Namen, die sich nur in der Schreibweise unterscheiden, gelten aber als derselbe Name: KostenStelle und kostenstelle können nicht nebeneinander bestehen. Der Name muss je Mandant und Umgebung eindeutig sein — innerhalb derselben Umgebung darf ein technischer Name also nur einmal vergeben sein, während Test und Produktion unabhängig voneinander denselben Namen verwenden dürfen.

Reservierte SQL-Wörter: Namen wie order, group, select oder user sind erlaubt — MDM Lite blockiert das Speichern nicht. Sie erhalten aber einen Hinweis, dass Abfragen auf der Datenplattform den Namen dann in Anführungszeichen setzen müssen (z. B. SELECT * FROM "order").

Ändern (nur Admin): Nur ein Mitglied mit der Rolle Admin kann den technischen Namen nach dem Anlegen ändern — im Tab „Integration" des Datasets, Abschnitt „Bereitstellung auf der Datenplattform". Editor und Viewer sehen den Wert dort nur lesend. Jede Änderung wird mit Benutzer, Zeitpunkt sowie altem und neuem Wert im Änderungsprotokoll des Datasets festgehalten.

Achtung — alte Tabelle bleibt bestehen: MDM Lite löscht auf der Datenplattform nie eine Tabelle. Ändern Sie den technischen Namen eines bereits bereitgestellten Datasets, bleibt die bisherige Tabelle unter ihrem alten Namen unverändert dort stehen — sie wird ab sofort nur nicht mehr aktualisiert. Der nächste Export schreibt ausschließlich in die neue Tabelle. Eine berechtigte Person muss die alte Tabelle manuell auf der Datenplattform löschen und Views bzw. Berichte, die sie lesen, auf den neuen Namen umstellen. MDM Lite zeigt diesen Hinweis vor und nach dem Speichern an, wenn das Dataset bereits einmal bereitgestellt wurde.

Bestehende Datasets: Für Datasets, die schon vor diesem Feature einmal per OneLake exportiert wurden, wurde der technische Name einmalig aus dem tatsächlichen OneLake-Ordnernamen übernommen — sie behalten also exakt den Namen, den Konsumenten heute schon lesen; MDM Lite hat dabei keine bestehende Tabelle umbenannt.

In der API/MCP: Der technische Name steht als technicalName in GET /api/datasets, im Dataset-Detail sowie in der MCP-Antwort get_dataset_info.

Verfügbare Integrationspfade

Schnellstart: Einzelnes Dataset synchronisieren

1. Dataset öffnen → „Connect to DWH"
2. Plattform: Microsoft Fabric wählen
3. Zieltabellenname und API-Key konfigurieren; der Parameter SYNC_MODE im generierten Notebook steuert nur noch die Übertragungstechnik — auto (Standard, überträgt nur bei einem geänderten Tabellenstand) oder full (überträgt bei jedem Lauf neu, z. B. nach einem manuellen Eingriff in die Zieltabelle)
4. Notebook als .ipynb herunterladen
5. In Fabric importieren, API-Key über notebookutils.credentials.getSecret() einbinden, ausführen

Im Assistenten „Connect to DWH" heißt das Auswahlfeld für SYNC_MODE „Aktualisierungsart" mit den Optionen „Automatisch" (Standard, entspricht auto) und „Immer vollständig neu schreiben" (entspricht full). Das Speicherziel ist fest auf „Lakehouse (Delta-Tabelle)" gesetzt — es gibt keine Auswahl mehr, da der generierte Code kein Fabric Warehouse (mehr) bedient (siehe Integrationshandbuch).

Für den vollständigen Ablauf inkl. Azure Storage Setup, SAS-Token, OneLake Shortcuts, Bulk-Sync und Fehlerbehebung → Integrationshandbuch.

Aktuell halten: Bei den Export-Pfaden nach Fabric (OneLake Shortcut, Direkt-Export) schalten Sie unter Einstellungen → Fabric OneLake → Automatischer Export die Option „Automatisch exportieren (Veröffentlichung & Änderungen)" ein. Danach landet nicht nur das Veröffentlichen, sondern jede spätere Änderung an einem veröffentlichten Dataset automatisch auf der Datenplattform — in der Regel innerhalb von 30 Sekunden, bei Massenänderungen gebündelt als ein Export des Endstands. Ohne diese Option bleibt der Fabric-Stand auf dem letzten manuellen Export stehen. Details: A8 – Automatischer Export.

Notebooks und Umgebungen: Ein Notebook gehört zu der Umgebung, in der Sie es erzeugen. Erzeugen Sie es in Live, folgt es immer der Live-Umgebung (unverändertes Verhalten). Erzeugen Sie es in einer anderen Umgebung, z. B. „Test", steht dort im Parameterblock RDM_ENVIRONMENT = "test", jeder API-Aufruf des Notebooks sendet den Header X-Environment: test, eine Hinweis-Zelle nennt die Umgebung, und der Dateiname endet auf _test. So liest ein Test-Notebook nur Test-Daten (nie unbemerkt Live-Daten) und ein Upload-Notebook schreibt nur in die Test-Datasets. Den Wert RDM_ENVIRONMENT ändern Sie nicht. Verwenden Sie einen API-Key ohne Umgebungsbeschränkung oder einen, der auf genau diese Umgebung beschränkt ist; ein auf eine andere Umgebung beschränkter Key wird schon beim Erzeugen mit 400 api_key_environment_mismatch abgelehnt. Die Data-Lineage in Microsoft Purview wird weiterhin nur für Notebooks aus Live registriert.

Notebooks je Umgebung – Schalter, Key-Auswahl, Bindung:

• Schalter „Notebook-Erzeugung in dieser Umgebung erlauben" (Einstellungen → Integrationen → Notebooks, nur Mandanten-Administratoren). In Live ist die Erzeugung ohne Einstellung erlaubt (unverändertes Verhalten), in jeder anderen Umgebung ist sie ausgeschaltet und muss dort ausdrücklich eingeschaltet werden. Ist der Schalter aus, antworten alle vier Erzeugungswege (einzeln und Sammel, Sync und Upload) mit 409 notebooks_disabled_for_environment; statt der Assistenten zeigt die Oberfläche einen Hinweis (für Administratoren mit Link zur Einstellung). Bereits erzeugte Notebooks bleiben unberührt: Sie lesen weiter über ihren API-Key. Um den Zugriff eines Notebooks zu stoppen, widerrufen Sie den Key. Jedes Umschalten wird im Änderungsprotokoll festgehalten.
• Bindung sichtbar: In einer Nicht-Live-Umgebung nennen die Assistenten und die Notebook-Einstellungen die Umgebung („Notebooks, die Sie hier erzeugen, lesen aus bzw. schreiben in die Umgebung „Test“.").
• Key-Auswahl: Die Assistenten bieten nur Keys an, die in der aktuellen Umgebung gültig sind: auf diese Umgebung beschränkte Keys und Keys ohne Beschränkung (als „alle Umgebungen“ markiert). Keys, die Sie direkt im Assistenten anlegen, sind auf die aktuelle Umgebung beschränkt (geringstes Recht) und funktionieren nur dort.

Hinweis für bestehende Nutzer: Wer bisher Notebooks in einer Nicht-Live-Umgebung erzeugt hat, muss den Schalter dort einmalig einschalten.

Zentrale Übersicht: Alle vier Notebook-Generatoren (Einzel- und Bulk-Sync in beide Richtungen) sind gebündelt auch über Einstellungen → Integrationen → Notebooks erreichbar — praktisch, wenn Sie nicht erst das jeweilige Dataset öffnen möchten. Diese Generatoren benötigen im Gegensatz zum OneLake-Shortcut-Pfad keinen Azure-Storage-Account, nur einen API-Key.

API-Endpunkte für eigene Integrationen

GET /api/datasets/{id}/delivery-table         → Bereitstellungstabelle (Schema + Zeilen), paginiert, ETag/304
GET /api/delivery-tables                      → Übersicht aller bereitstellbaren Datasets mit ETag (für Sammel-Abrufe)
GET /api/datasets/{id}/current                → aktuelle Version (versionierte Lese-API, kein Bereitstellungsweg)
GET /api/datasets/{id}/as-of?date=2025-12-31  → Stand zum Stichtag
GET /api/datasets/{id}/versions/{version}     → bestimmte Version
GET /api/datasets/changes?since=...           → alle geänderten Datasets (dataset-übergreifender Feed)
GET /api/server-time                          → Server-Zeitstempel

Alle Endpunkte erfordern einen API-Key (Authorization: ApiKey <API-Key>). Siehe API-Keys verwalten.

GET /api/datasets/{id}/changes entfällt: Der frühere zeilenbezogene Änderungs-Feed je Dataset antwortet seit diesem Release mit 410 Gone und verweist auf /api/datasets/{id}/delivery-table. Nutzen Sie stattdessen die Bereitstellungstabelle mit If-None-Match (liefert 304, wenn sich nichts geändert hat) — sie enthält bereits alle nötigen Zeitachsen (siehe Zwei Zeitachsen).

Für eigene Integrationen: Die versionsbezogenen Endpunkte (/current, /versions/{n}, /as-of, /export) liefern zusätzlich das Feld columns — den Spaltenstand, der zur jeweils gelieferten Version gehört (siehe Schema-Stand historischer Versionen) — sowie schema_snapshot_missing: true, wenn dieser Stand nicht aufgezeichnet wurde und ersatzweise das aktuelle Schema geliefert wird. Ein automatisierter Abnehmer, der Spalten strikt gegen ein erwartetes Schema prüft, sollte dieses Flag auswerten statt bei fehlenden Spalten hart abzubrechen. Vollständige Feldreferenz: design/api-spec.md ↗ (GitHub, ggf. Zugriff erforderlich).

Row-ID-Semantik (seit September 2026): Das Feld id einer Zeile (in /current, /versions/{n}, /as-of und im Diff als row_id) bezeichnet einen Zeilenzustand, nicht die Zeile über die gesamte Historie. Bleibt eine Zeile inhaltlich unverändert, behält sie dieselbe id über Commits, Massenänderungen, Import (Upsert/FullReplace), Umgebungskopie und Plattform-Import/-Aktualisierung hinweg — ändert sich der Inhalt, entsteht ein neuer Zeilenzustand mit neuer id. Eindeutig über Versionen hinweg ist deshalb nur das Paar aus Versionsnummer und id, nicht id allein. Schreiben Sie eigene Zeilen versionsübergreifend in eine Historientabelle, verwenden Sie diese Kombination als Schlüssel. Auch sys_created_at/sys_created_by folgen dieser Logik: Sie nennen den Zeitpunkt, seit dem der jeweilige Zeileninhalt unverändert existiert — eine unveränderte Zeile behält ihren ursprünglichen Zeitstempel auch über einen erneuten Import hinweg. Diese Semantik gilt ab sofort ohne Übergangsfrist für neu abgerufene Daten; ein Eingriff Ihrerseits ist nur nötig, wenn Sie Row-IDs bislang selbst versionsübergreifend als alleinigen Schlüssel gespeichert haben.

14. KI-Zugriff (MCP)

MDM Lite kann Referenzdaten für KI-Assistenten — Claude, Microsoft 365 Copilot und Copilot Studio — über das Model Context Protocol (MCP) bereitstellen. Der Zugriff ist ausschließlich lesend: Änderungen an Daten sind über MCP nicht möglich, sie erfolgen weiterhin nur in der Web-UI oder über die REST-API. Das gilt auch für das Schema: Das Zurücksetzen auf einen älteren Spaltenstand ist kein MCP-Werkzeug. Ein KI-Assistent kann das Ergebnis nur lesen (Spaltenstand, Versionsvergleich, Änderungsprotokoll).

Aufrufen: Einstellungen → Integrationen → MCP-Server. Ist das Feature für Ihren Mandanten nicht freigeschaltet, ist der Bereich gesperrt — wenden Sie sich an Ihren MDM-Lite-Administrator.

Die Seite zeigt:

• Den MCP-Endpunkt der aktuell gewählten Umgebung (Live: https://.../mcp, jede weitere Umgebung: https://.../mcp/{Kürzel}; Streamable-HTTP) zum Kopieren, für die Einrichtung im jeweiligen KI-Client
• Die OAuth-Discovery-URL (RFC 9728) dieses Endpunkts für clientseitige Authentifizierung
• Den Schalter „KI-Zugriff (MCP) für diese Umgebung erlauben" (Mandanten-Administratoren). In Live ist der KI-Zugriff ohne Einstellung erlaubt, in jeder anderen Umgebung ausgeschaltet (Anfragen erhalten dann 404) — er muss dort ausdrücklich eingeschaltet werden. Das gilt auch für Clients, die die Umgebung per X-Environment-Header wählen.
• Verlinkte Onboarding-Leitfäden: für Claude (Custom Connector/OAuth bzw. API-Key für Claude Code) und Copilot Studio, sowie ein eigenes Agent-Paket für Microsoft 365 Copilot

Berechtigungen & Sichtbarkeit

• Jede MCP-Anfrage berücksichtigt Rolle und Dataset-Berechtigungen des anfragenden Nutzers bzw. API-Keys — eine KI sieht nie mehr, als der Nutzer selbst im Tool sehen könnte. Hat ein Dataset eigene Dataset-Rollen, erscheint es über MCP nur für Nutzer und Keys mit einer eigenen Rolle darauf (und für AppAdmins, siehe Rollenmodell); für alle anderen existiert es nicht.
• Verfügbare Abfragen: Dataset-Liste & -Details, Zeileninhalte, Suche, Audit-Historie, Versions-Diffs und Import-Historie.
• Berechnete Spalten: In den Dataset-Details kennzeichnet MDM Lite eine berechnete Spalte mit read_only: true und beschreibt ihre Berechnung im Feld computed (Art, Trennzeichen, Quellspalten mit Stellenzahl, Klartext-Definition). Die KI sieht damit, dass der Wert nicht schreibbar ist und woraus er entsteht. Ist eine Quellspalte für den Aufrufer nicht sichtbar (Klassifizierung), enthält computed nur einen Hinweis ohne deren Namen.

15. Sensitivitätsklassifizierung & Microsoft Purview

MDM Lite kann Datasets in den Microsoft-Purview-Datenkatalog integrieren — ein separat lizenziertes Add-on. Ist es für Ihren Mandanten nicht aktiviert, bleiben die zugehörigen UI-Elemente (Purview-Tab, Sensitivitätskennzeichnung, Glossar-Spalte) ausgeblendet bzw. deaktiviert.

Aufrufen (Konfiguration): Einstellungen → Integrationen → Purview. Erforderliche Rolle: Admin.

Was die Integration bietet

• Asset-Registrierung: Jedes veröffentlichte Dataset wird automatisch als Custom-Asset in der Purview Data Map registriert (Best-Effort — blockiert die Veröffentlichung nie; Fehler werden im Hintergrund automatisch wiederholt).
• Data Lineage: Beim DWH-Export entsteht in Purview eine Lineage-Kante vom MDM-Lite-Dataset zur Ziel-Tabelle — nachvollziehbar, woher eine DWH-Tabelle stammt.
• Business-Glossar-Mapping: Im Schema-Tab kann pro Spalte ein Purview-Glossar-Begriff hinterlegt werden (Spalte „Glossar-Begriff", nur bei aktivem Add-on sichtbar).
• Sensitivitätskennzeichnung: Eine in Purview gesetzte Sensitivitätskennzeichnung wird auf das Dataset übernommen und im Dataset-Header sowie als Export-Header X-Sensitivity-Label sichtbar gemacht.
• Rückkanal (Webhook): Ändert sich ein verknüpfter Glossar-Begriff oder eine Sensitivitätskennzeichnung in Purview, benachrichtigt ein eingehender Webhook MDM Lite automatisch.

Eingebaute Sensitivitätsstufen (auch ohne Purview)

Unabhängig vom Purview-Add-on trägt jede Spalte eine der Stufen public, internal (Standard), confidential oder restricted. Wer welche Stufe sieht, hängt von der Rolle auf dem Dataset ab (Betrachter bis internal, Editor bis confidential, Admin alles); ein API-Key kann mit maxSensitivityLevel zusätzlich begrenzt werden.

Eine Spalte oberhalb Ihrer Stufe ist für Sie nicht vorhanden — weder ihre Werte noch ihr Name erscheinen: nicht in Tabelle, Export und API, nicht in der Suche, im Beziehungen-Tab, in der Duplikaterkennung, in DWH-Upload-Notebooks und nicht im Import-Bericht. Fehlerberichte zeigen dann nur den Fehlercode und die Zeile (z. B. „Pflichtspalte fehlt"), ohne den Spaltennamen; die Anzahl der Fehler bleibt vollständig. Die Stufe einer Spalte ändern können Sie nur, wenn die alte und die neue Stufe innerhalb Ihrer eigenen liegen.

Purview je Umgebung einrichten

Purview gehört, wie die Bereitstellung auf der Datenplattform, zu einer Umgebung. Ein Dataset wird nur in die Purview-Konfiguration seiner eigenen Umgebung registriert. Hat die Umgebung keine eigene, aktivierte Konfiguration, registriert MDM Lite nichts. Es greift nie auf die Konfiguration von Live zurück. Eine neue Umgebung startet deshalb ohne Purview.

Voraussetzung: Rolle Admin und das aktivierte Purview-Add-on.

1. Wechseln Sie im Benutzermenü in die Umgebung, die Sie einrichten möchten, zum Beispiel „Test".
2. Öffnen Sie Einstellungen → Integrationen → Microsoft Purview. Die Kontextzeile oben nennt die Umgebung.
3. Hat die Umgebung noch keine Konfiguration, zeigt die Seite „Für die Umgebung „Test" ist Purview nicht eingerichtet." Klicken Sie auf „Purview für „Test" einrichten".
4. Tragen Sie Purview-Endpunkt, Azure-AD-Tenant-ID, Service-Principal-Client-ID und das Client Secret ein. Optional geben Sie eine Collection an. Speichern Sie, prüfen Sie mit „Verbindung testen" und aktivieren Sie die Integration.

Sie erkennen die erfolgreiche Einrichtung daran, dass die Übersicht „Purview je Umgebung" die Umgebung mit Endpunkt, Collection und dem Status „Aktiv" zeigt.

Collection (optional): Microsoft Purview wird meist mit einem Konto je Organisation betrieben. Eine Collection trennt die Assets der Umgebungen innerhalb dieses Kontos. Tragen Sie den Referenznamen der Collection ein (die Purview-Eigenschaft name, nicht den Anzeigenamen). Bleibt das Feld leer, landen die Assets in der Standard-Collection des Kontos. Die Collection muss in Purview bereits existieren, und der Service Principal braucht dort Schreibrechte.

Übersicht „Purview je Umgebung": Die Tabelle zeigt je Umgebung Endpunkt, Collection und Status („Aktiv", „Deaktiviert", „Secret nicht lesbar", „Nicht eingerichtet"). Mit „Zu dieser Umgebung wechseln" springen Sie in die Einstellungen einer anderen Umgebung. Haben Sie im Formular ungespeicherte Eingaben, fragt MDM Lite vor dem Wechsel nach.

Webhook-Secret je Umgebung: Das Webhook-Secret für den Rückkanal (Glossar-Begriffe, Sensitivitätskennzeichnungen) gehört zur Konfiguration der Umgebung. Richten Sie in Azure ein eigenes Event-Grid-Abo je Umgebung ein und hinterlegen Sie darin das Secret genau dieser Umgebung. Ein Ereignis mit dem Secret von „Test" betrifft nur Datasets von „Test". Änderungen an Glossar-Begriffen wirken dagegen mandantenweit.

So erkennen Sie Assets einer Umgebung in Purview: Neu registrierte Assets einer Nicht-Live-Umgebung tragen das Umgebungskürzel im Schlüssel (rdm://{Mandant}/{Umgebungs-Slug}/{Dataset-ID}). Der Anzeigename bleibt unverändert. Der Schlüssel der Live-Umgebung ändert sich nicht. Ein einmal vergebener Schlüssel bleibt unverändert. Eine geänderte Collection gilt ab dem nächsten Sync eines Datasets; Purview legt das Asset dann in der neuen Collection an bzw. verschiebt es dorthin.

Hinweis zur Bestätigung: Anders als bei der Bereitstellung auf der Datenplattform erscheint für Purview kein Bestätigungsdialog beim ersten Aktivieren in einer Nicht-Live-Umgebung. Purview erhält nur Metadaten (Name, Schema, Beschreibung, Status), keine Datenzeilen. Das Speichern der Konfiguration steht mit Umgebung im Änderungsprotokoll.

Hinweis für bestehende Nutzer: Vor Release 1.3 registrierte MDM Lite nur Datasets der Live-Umgebung. Bereits früher registrierte Nicht-Live-Assets in Purview bleiben bestehen und werden nicht automatisch gelöscht. Wie Sie sie erkennen und bereinigen, beschreibt das Betriebs-Runbook „Nicht-Live-Altartefakte bereinigen"; Ihr Support-Ansprechpartner stellt es Ihnen bereit.

Pro Dataset

Der Tab „Purview" eines Datasets zeigt den Synchronisierungsstatus (synchronisiert / fehlgeschlagen / nie synchronisiert) und bietet „Mit Purview synchronisieren" zum manuellen Anstoßen. Der Sync geht in die Purview-Konfiguration der Umgebung des Datasets und ist in jeder Umgebung verfügbar. Hat die Umgebung keine eigene, aktivierte Konfiguration, zeigt der Tab statt der Schaltfläche den Hinweis „Purview ist für diese Umgebung nicht eingerichtet" (Admins mit Link zu den Einstellungen). Ist das Add-on für den Mandanten nicht aktiviert, ist der Tab mit dem Hinweis „Purview nicht aktiviert" gesperrt.

16. API-Keys verwalten

API-Keys ermöglichen maschinellen Zugriff für ETL-Pipelines, ohne einen persönlichen Login zu verwenden.

API-Key anlegen (Admin)

1. Einstellungen → Sicherheit → API-Keys (Route /settings/security/api-keys)
2. „Neuen Key erstellen" klicken
3. Name/Beschreibung eingeben (z. B. „Fabric Sync Job")
4. Bestätigen — der Key wird einmalig angezeigt, sofort sicher speichern

In den Einstellungen angelegte Keys haben die Scopes read und write und sind nicht auf einzelne Datasets beschränkt. Keys, die Sie direkt im Assistenten „Mit DWH verbinden" (einzelnes Dataset oder alle Datasets) anlegen, erhalten nur read — die erzeugten Notebooks lesen ausschließlich.

Was die Scopes erlauben:

• read: alle lesenden Abrufe (GET) sowie wenige lesende POST-Aufrufe (Schema aus Datei erkennen, Struktur-Abgleich, FK-Anzeigewerte, Notebook-Generatoren). Jeder andere Schreibaufruf wird mit 403 und dem Fehlercode api_key_scope_insufficient abgelehnt.
• write: zusätzlich alles, was ein Editor darf: Daten importieren und bearbeiten (auf Datasets ohne eigene Dataset-Rollen), Datasets anlegen, Ordner pflegen. Admin-Aktionen (Veröffentlichen, Spaltenstruktur, Rollen, Aufbewahrung, OneLake-Sync, Purview, Mandantenverwaltung) sind für API-Keys nie erlaubt.

In der Key-Liste sehen Sie zu jedem Schlüssel den Scope und den Zeitpunkt der letzten Verwendung (last_used_at).

Wichtig: Der API-Key wird nur bei Erstellung vollständig angezeigt. Danach ist nur noch der Name sichtbar.

Umgebungs-Scope: Ein API-Key kann optional auf eine einzelne Umgebung beschränkt werden, sodass er z. B. nur die Test-Umgebung ansprechen darf. Sie wählen den Scope beim Anlegen im Dialog „API-Key erstellen“ im Feld Umgebung (Standard: „Alle Umgebungen“ = keine Beschränkung); die Key-Liste zeigt den Scope in der Spalte Umgebung. Über die API setzen Sie ihn mit dem Feld environment (siehe API-Spezifikation ↗ (GitHub, ggf. Zugriff erforderlich)). Ein auf eine Nicht-Live-Umgebung gescopter Key muss den X-Environment-Header bei jedem Request explizit mitsenden. Er erreicht keine Daten anderer Umgebungen — auch nicht über Funktionen, die ohnehin in eine andere Umgebung greifen: Beim Kopieren in eine andere Umgebung darf er dort keine Datasets anlegen und nur Ziel-Datasets aktualisieren, die aus dem jeweiligen Quell-Dataset stammen; „Sync now" für OneLake (export-all) ist Mandanten-Admins in der Oberfläche vorbehalten, ein API-Key kann es nicht auslösen.

Scopes und Dataset-Beschränkung: Auch die Scopes (scopes: read oder read/write) und die Beschränkung auf einzelne Datasets (datasetIds) lassen sich derzeit nur über die API festlegen (POST /api/tenants/api-keys, Feldnamen in camelCase — unbekannte oder falsch geschriebene Felder werden mit 400 abgelehnt). Ein beschränkter Key sieht und nutzt ausschließlich die genannten Datasets: jedes andere Dataset beantwortet die API mit 404, Listen zeigen es nicht, und der Key kann keine neuen Datasets anlegen. Dataset-IDs gelten je Umgebung — die Kopie eines Datasets in einer anderen Umgebung hat eine eigene ID.

Leere Angaben werden abgelehnt, nicht stillschweigend zu „alle": Ein fehlendes Feld (scopes, datasetIds, environment einfach weglassen) behält seine dokumentierte Bedeutung „alles/unbeschränkt" — das ist der Weg, den die Web-UI beim Anlegen nutzt. Eine leere Liste (scopes: [], datasetIds: []) oder ein leerer/reiner Leerzeichen-Wert (environment: "") ist dagegen ein Fehler (400), kein gültiger Weg, „keine Einschränkung" auszudrücken. Jede datasetIds-ID muss außerdem tatsächlich existieren, zu Ihrem Mandanten gehören und — bei gesetztem environment — in dieser Umgebung liegen, sonst 400 unknown_dataset_ids. Details und die vollständige Fehlercode-Tabelle: API-Spezifikation §12.2 ↗ (GitHub, ggf. Zugriff erforderlich).

Gesperrte Datasets: Hat ein Dataset eigene Dataset-Rollen, braucht auch ein API-Key dort eine eigene Rolle (Benutzer-ID apikey:{Key-ID}), sonst erhält er 403.

API-Key verwenden

Im HTTP-Request-Header:

Authorization: ApiKey <API-Key>

API-Key widerrufen

In der Key-Liste: „Widerrufen" klicken. Der Key ist sofort ungültig — alle laufenden Jobs, die ihn verwenden, erhalten ab sofort 401 Unauthorized.

17. E-Mail-Versand konfigurieren

MDM Lite verschickt E-Mails — vor allem Einladungen an neue Nutzer (siehe Nutzerverwaltung). Damit diese Mails zugestellt werden, muss ein Versandweg konfiguriert sein. Es gibt zwei Ebenen:

1. MDM Lite built-in (Betreiber-Konto) — Standard: Versand über das zentrale, von der Data Prudentia GmbH (Anbieter von MDM Lite) bereitgestellte Absenderkonto. Jeder Mandant startet mit dieser Option; ist das Betreiber-Konto eingerichtet, funktioniert der Versand sofort — Sie müssen nichts tun. Die Mail kommt dann technisch vom Betreiberkonto, enthält im Text aber den Kontext: wer eingeladen hat und für welchen Mandanten. Antworten gehen per Reply-To an den einladenden Admin.
2. Eigenes Konto des Mandanten (empfohlen): Damit Einladungen aus Ihrer eigenen Domain stammen, hinterlegen Sie ein eigenes Absenderkonto. Empfohlen wird Microsoft 365.

Es ist immer nur eine Option aktiv. Den Wechsel zwischen beiden steuern Sie über die Auswahl oben in der E-Mail-Einstellung (siehe Option wählen).

Aufrufen: Einstellungen → Integrationen → E-Mail. Erforderliche Rolle: Admin.

Option wählen (built-in oder eigenes Konto)

Oben auf der E-Mail-Seite wählen Sie per Auswahlfeld zwischen den beiden Optionen:

• MDM Lite built-in E-Mail (Standard): Eine Statuszeile zeigt, ob das Betreiber-Konto tatsächlich versandbereit ist:
  • „Built-in-E-Mail ist aktiv und versandbereit" (ggf. mit angezeigter Absenderadresse) — Einladungen werden sofort verschickt.
  • „Die Standard-E-Mail wurde von der Data Prudentia GmbH (Anbieter von MDM Lite) noch nicht konfiguriert" — in diesem Fall schreiben Sie an den Support unter admin@data-prudentia.de oder hinterlegen ein eigenes Konto (Option 2).
• Eigene E-Mail-Konfiguration: Blendet die M365-/SMTP-Form ein (siehe unten).

Zurückwechseln ohne Datenverlust: Wechseln Sie von der eigenen Konfiguration zurück auf das built-in-Konto, bleibt Ihre eigene Konfiguration (inkl. verschlüsseltem Geheimnis) erhalten — sie wird nur deaktiviert. Ein späterer Rück-Wechsel auf das eigene Konto ist daher ohne erneute Eingabe des Secrets möglich.

Warum Microsoft 365 und nicht klassisches SMTP? Microsoft hat den klassischen SMTP-Login (Basic Auth) in Exchange Online deaktiviert. Für den Versand aus einem M365-Postfach wird daher eine App-Registrierung mit moderner Authentifizierung verwendet. Für Nicht-M365-Postfächer steht weiterhin die SMTP-Option bereit.

Variante A — Microsoft 365 (empfohlen)

Voraussetzung ist eine App-Registrierung in Ihrem Microsoft-Entra-ID (Azure AD). Diese richtet Ihr Microsoft-365-Administrator einmalig ein:

1. In Microsoft Entra ID → App-Registrierungen eine neue Registrierung anlegen.
2. Unter API-Berechtigungen die Anwendungsberechtigung Mail.Send (Microsoft Graph) hinzufügen und Administratorzustimmung erteilen.
3. Unter Zertifikate & Geheimnisse ein Client-Secret erzeugen und den Wert kopieren (wird nur einmal angezeigt).
4. (Optional, empfohlen) Per Application Access Policy den Zugriff der App auf genau das Absenderpostfach begrenzen.

Anschließend im MDM Lite unter Integrationen → E-Mail den Anbieter Microsoft 365 wählen und eintragen:

Variante B — SMTP (Alternative)

Für Postfächer außerhalb von Microsoft 365 wählen Sie den Anbieter SMTP und tragen ein: Host, Port (Standard 587), SSL/TLS, Benutzername, Passwort, Absenderadresse und optional Anzeigename.

Speichern, Testen, Aktivieren

• Geheimnisse werden verschlüsselt gespeichert und in der Oberfläche nie wieder im Klartext angezeigt — ein gesetztes Secret erkennen Sie nur an einer Markierung „gesetzt". Beim Bearbeiten lassen Sie das Feld leer, um das bestehende Geheimnis beizubehalten, oder geben einen neuen Wert ein, um es zu rotieren.
• Über „Verbindung testen" prüfen Sie die Konfiguration mit einem echten Verbindungsaufbau (#1144): Bei Microsoft 365 werden Mandanten-ID, Client-ID und Client-Secret gegen Microsoft geprüft (Token-Abruf) und zusätzlich im Token kontrolliert, ob die Berechtigung Mail.Send erteilt und konsentiert wurde. Bei SMTP baut der Test eine echte TCP-Verbindung zum Server auf, verhandelt TLS/STARTTLS und meldet sich — sofern ein Passwort hinterlegt ist — mit den Zugangsdaten an. Bei einem Fehler zeigt die Meldung, woran es lag (z. B. Server nicht erreichbar, TLS-Fehler, falsche Zugangsdaten, Zeitüberschreitung) statt eines allgemeinen „fehlgeschlagen". In keinem Fall wird eine Test-Mail versendet — ob der Versand tatsächlich beim Empfänger ankommt, zeigt erst eine echte Einladung.
• Speichern aktiviert den eigenen Versandweg automatisch (eine separate Ein/Aus-Umschaltung gibt es auf der Mandanten-Seite nicht — die Optionsauswahl steuert dies). Solange die eigene Konfiguration ausgewählt und gültig ist, werden alle Einladungen dieses Mandanten darüber verschickt; bei Auswahl von „built-in" greift der Plattform-Standard.

Hinweis (Nachvollziehbarkeit): Jede Änderung an der E-Mail-Konfiguration (Anlegen, Ändern, Löschen) wird im Audit-Log protokolliert — ohne das Geheimnis selbst.

Plattform-Standard (Betreiber-Konto) einrichten (nur AppAdmin)

Das built-in-Konto, das alle Mandanten mit Option 1 nutzen, pflegt der AppAdmin zentral in der Oberfläche — eine separate Server-Konfiguration ist nicht mehr nötig.

Aufrufen: Plattform-Verwaltung (/admin) → Tab „E-Mail". Erforderliche Rolle: AppAdmin.

Für das Betreiber-Konto stehen drei Anbieter zur Verfügung — einer mehr als auf Mandantenseite:

Zusätzlich gilt:

• Geheimnis verschlüsselt at rest, wird nie wieder im Klartext angezeigt (nur als „gesetzt" markiert); leer lassen behält das bestehende Secret, neuer Wert rotiert es.
• „Verbindung testen" führt für alle drei Anbieter einen echten Aufruf gegen den jeweiligen Dienst aus (#1144), keine reine Feldvollständigkeits-Prüfung mehr: Microsoft 365 ruft ein Token ab und kontrolliert darin die Berechtigung Mail.Send (aber nicht, ob das Absenderpostfach existiert oder eine Application Access Policy den Zugriff sperrt); SMTP baut eine echte TCP-Verbindung inkl. TLS/STARTTLS-Handshake auf und meldet sich mit den Zugangsdaten an; Azure Communication Services legt über den Endpoint eine Wegwerf-Identität an und löscht sie sofort wieder, um Endpoint und Access Key zu verifizieren. Fehler werden differenziert gemeldet (Server nicht erreichbar, TLS-Fehler, abgelehnte Zugangsdaten, Zeitüberschreitung) statt eines allgemeinen „fehlgeschlagen". Eine Test-Mail wird nie versendet — prüfen Sie den tatsächlichen Versand mit einer echten Einladung.
• Ein Aktiv-Schalter bestimmt, ob das built-in-Konto versandbereit ist.
• „Entfernen" löscht das Betreiber-Konto. Achtung: Danach erhalten alle Mandanten, die auf der built-in-Option stehen, keine E-Mails mehr, bis das Konto neu konfiguriert ist (sofern kein Server-seitiger Fallback hinterlegt ist).
• Änderungen am Betreiber-Konto sind über „zuletzt geändert von/am" nachvollziehbar (das Geheimnis wird dabei nie gespeichert/angezeigt).

Hinweis: Diese Plattform-Einstellung ist mandantenübergreifend und nur für AppAdmins zugänglich. Normale Mandanten-Admins sehen und ändern ausschließlich die E-Mail-Konfiguration ihres eigenen Mandanten.

Für Betreiber: Die vollständige Schritt-für-Schritt-Anleitung zur Einrichtung des Betreiber-Kontos (App-Registrierung in Entra ID, Mail.Send, Application Access Policy, ACS-Domain, Secret-Rotation, Fehlerbilder) steht im internen Plattform-Admin-Handbuch ↗ (GitHub, nur für Betreiber mit Repo-Zugriff).

Was passiert ohne Konfiguration?

Ist weder ein eigenes Konto noch ein Plattform-Standard hinterlegt, wird keine E-Mail versendet. Die Einladung wird trotzdem angelegt; Sie können den Einladungslink in diesem Fall manuell weitergeben oder den Versand später über „Erneut versenden" auslösen (siehe Nutzerverwaltung).

18. Nutzerverwaltung

Allgemeine Mandanten-Einstellungen

Unter Einstellungen → Allgemein (Route /settings/general) ändern Admins den Anzeigenamen des Mandanten — den Namen, unter dem Ihre Organisation in der Kopfzeile, der Mandantenauswahl und E-Mail-Einladungen erscheint. Wert eintragen und „Speichern" klicken.

Nur Nutzer mit der Rolle Admin oder AppAdmin haben Zugriff auf die Nutzerverwaltung.

Aufrufen: Profilmenü oben rechts → „Nutzer verwalten" (oder Einstellungen → Nutzer verwalten)

Nutzer einladen

1. Tab „Einladungen" wählen
2. E-Mail-Adresse und Rolle auswählen (Viewer / Editor / Admin)
3. „Einladen" klicken

Der Eingeladene erhält eine E-Mail mit Bestätigungslink (gültig 7 Tage). Beim Klick meldet er sich mit seinem Microsoft-Konto an; danach wird sein Account automatisch dem Mandanten hinzugefügt.

Der Link allein genügt nicht: Angenommen werden kann eine Einladung nur von der Person, an deren Adresse sie verschickt wurde. Meldet sich jemand mit einem anderen Konto an, weist MDM Lite die Annahme ab („Diese Einladung wurde an eine andere E-Mail-Adresse gesendet") — auch dann, wenn der Link weitergeleitet oder abgefangen wurde. Laden Sie deshalb genau die Adresse ein, unter der sich die Person bei Microsoft anmeldet.

Voraussetzung: Der Mailversand muss konfiguriert sein, damit die Einladung tatsächlich zugestellt wird — siehe E-Mail-Versand konfigurieren. Ist kein Versandweg eingerichtet, wird die Einladung zwar angelegt, aber keine Mail verschickt.

Erneut versenden / widerrufen: In der Liste offener Einladungen können Sie pro Zeile die Mail erneut versenden (z. B. wenn sie nicht angekommen ist oder der Link abgelaufen ist; die Gültigkeit wird dabei auf 7 Tage zurückgesetzt) oder die Einladung widerrufen.

Rolle ändern

Im Tab „Mitglieder": Dropdown rechts neben dem Namen → neue Rolle wählen. Wirkt sofort.

Einschränkungen:

• Der letzte verbleibende Admin kann nicht heruntergestuft werden
• Die eigene Rolle kann nicht geändert werden

Nutzer sperren / entsperren

Schalter in der Zeile des Nutzers: Sperren unterbindet den Zugriff auf diesen Mandanten sofort (403 Forbidden) — auch mitten in einer laufenden Sitzung, denn die Prüfung erfolgt bei jedem Request neu und nicht nur beim Login. Ein bereits angemeldeter, gesperrter Nutzer wird also nicht erst beim nächsten Login ausgesperrt, sondern schon bei seiner nächsten Aktion. Das Konto und alle Rollen bleiben erhalten und können jederzeit entsperrt werden — im Unterschied zu „Entfernen" unten, das die Mitgliedschaft löscht. Diese Sperre wirkt nur im aktuellen Mandanten; Mitgliedschaften des Nutzers in anderen Mandanten sind davon nicht betroffen (siehe auch die mandantenübergreifende Sperre unter „Plattform-Verwaltung").

Nutzer entfernen

„Entfernen" in der Zeile des Nutzers: Entfernt die Mitgliedschaft vollständig. Der Nutzer muss neu eingeladen werden.

Plattform-Verwaltung (nur AppAdmin)

Nutzer mit der Rolle AppAdmin haben einen zusätzlichen, mandantenübergreifenden Verwaltungsbereich (Route /admin):

• Mandanten (Tenants) anlegen und umbenennen
• Plattform-Admins verwalten (AppAdmins hinzufügen/entfernen)
• Globale Nutzer über alle Mandanten hinweg einsehen und global sperren/entsperren — diese plattformweite Sperre wirkt zusätzlich zur mandantenweiten Sperre oben und unabhängig von ihr: Sie unterbindet den Zugriff auf alle Mandanten des Nutzers gleichzeitig (auch für AppAdmins selbst), ebenfalls sofort ab dem nächsten Request und ohne dass laufende Sessions durch ein noch gültiges Login-Token geschützt wären
• Tenant-Audit-Log (z. B. Purge-Ereignisse) einsehen
• E-Mail (Plattform-Standard) — das zentrale Betreiber-Absenderkonto setzen, testen und entfernen (siehe Plattform-Standard einrichten)
• Funktionen je Mandant freischalten: In der Detailansicht eines Mandanten (Tab „Mandanten") schaltet der AppAdmin die separat lizenzierten Zusatzfunktionen Microsoft Fabric / OneLake, Microsoft Purview und MCP-Server (KI-Zugriff) einzeln frei bzw. wieder ab. Zu jeder Funktion wird angezeigt, wer sie wann aktiviert hat; das Deaktivieren erfordert eine Bestätigung. Dies ist der Vorgang, auf den die Hinweise „wenden Sie sich an Ihren MDM-Lite-Administrator" in den Kapiteln Bereitstellung auf der Datenplattform, KI-Zugriff (MCP) und Sensitivitätsklassifizierung & Microsoft Purview verweisen.

19. Rollenmodell & Berechtigungen

Datasets & Ordner anlegen umfasst: neues Dataset (Formular, aus Datei, Massenimport), Ordner anlegen, umbenennen, verschieben und löschen. Viewer sehen die entsprechenden Schaltflächen im Explorer nicht, und Drag & Drop ist für sie abgeschaltet.

Dataset verschieben richtet sich nach der Rolle auf dem Dataset: Wer dort Editor ist, darf es in einen anderen Ordner verschieben — auch ein Mandanten-Viewer mit Dataset-Rolle Editor. Ein Mandanten-Editor ohne eigene Rolle auf einem gesperrten Dataset darf es nicht.

AppAdmin: Ein AppAdmin hat im gewählten Mandanten immer mindestens die Rechte eines Mandanten-Admins. Auf jedem Dataset gilt er als Dataset-Admin — auch auf gesperrten Datasets (mit eigenen Dataset-Rollen), ohne dort selbst eingetragen zu sein. Das ist der Support-Zugang des Betreibers. Er gilt nur im gewählten Mandanten. Jede Änderung, die ein AppAdmin vornimmt, steht mit seiner eigenen E-Mail-Adresse im Änderungsprotokoll.

Purview-Lineage: Das Notebook im Assistenten „Mit DWH verbinden" darf jeder erzeugen, der das Dataset lesen darf. Die Lineage im Purview-Katalog wird aber nur registriert, wenn Sie auf dem Dataset mindestens Editor sind.

Hinweis: AppAdmin hat zusätzlich mandantenübergreifende Plattformrechte — wird typischerweise nur für den Systemadministrator vergeben.

20. Plattform-Datenbibliothek

Die Plattform-Datenbibliothek („Bibliothek") liefert vorkonfigurierte, gepflegte Referenzdatensätze, die Sie mit einem Klick in Ihren Mandanten übernehmen. Statt ISO-Ländercodes oder Branchensystematiken selbst zu beschaffen und aufzubereiten, importieren Sie ein fertiges, versioniertes Dataset.

Verfügbare Datensätze

Datensätze vom Typ Baum (NUTS, NACE, UN M.49) werden mit ihrer Baumstruktur importiert; die EU-MwSt-Sätze und die Bankleitzahlen (BLZ/BIC) nutzen Gültig ab / Gültig bis (siehe Zeitliche Gültigkeit).

Bibliothek öffnen

Klicken Sie auf das Symbol 🌐 Bibliothek in der Aktionsleiste des Dataset Explorers. Die Bibliothek-Seite zeigt alle verfügbaren Datensätze als Karten.

• Kategorie-Filter: Über die Leiste oben (Alle / Geographie / Finanzen / Handel / Industrie / Logistik / …) die Auswahl eingrenzen.
• Suche: Das Suchfeld filtert nach Name, Beschreibung und Schlagwörtern.

Bekannte Einschränkung: Für die Kategorie „Zeit" (Datumsdimension, Feiertage) fehlt aktuell die passende Filter-Kachel samt Symbol in der Bibliothek-Oberfläche — beide Datensätze sind über die Suche trotzdem auffindbar. Als Bug zur Behebung vorgemerkt.

Vorschau

Auf einer Karte „Vorschau" wählen — ein Dialog zeigt das Schema (Spalten, Typen, Schlüssel) sowie die ersten 10 Datenzeilen. So prüfen Sie den Datensatz vor dem Import.

Importieren (Copy-on-Import)

1. Auf der Karte (oder im Vorschau-Dialog) „Importieren" klicken
2. Im Bestätigungsdialog den Import bestätigen — der Datensatz wird in den Ordner „Plattformdaten" kopiert
3. Eine Erfolgsmeldung erscheint; über „Zum Dataset" springen Sie direkt zum importierten Dataset

Beim Import entsteht eine vollständige, eigenständige Kopie in Ihrem Mandanten (kein Live-Link). Sie können sie anschließend frei anpassen — eigene Spalten oder Zeilen ergänzen. Der Datensatz wird im Status Entwurf angelegt.

• Bereits importiert: Karten bereits importierter Datensätze zeigen „Importiert" mit einem Häkchen statt der Schaltfläche — ein zweiter Import desselben Datensatzes ist nicht möglich.
• Berechtigung: Importieren erfordert mindestens die Rolle Editor. Viewer sehen die Bibliothek, die Import-Schaltflächen sind jedoch deaktiviert (mit Hinweis).

Bibliothek-Badge

Aus der Bibliothek importierte Datasets tragen auf der Detailseite ein Badge 🌐 Bibliothek: <slug> v<n>. Ein Klick darauf öffnet den zugehörigen Katalog-Eintrag.

Aktualisierungen übernehmen

Veröffentlicht der Plattform-Betreiber eine neue Version eines Datensatzes, erscheint auf der Detailseite des importierten Datasets ein Banner 🔔 Neue Plattformversion verfügbar.

• Mit „Aktualisieren" übernehmen Sie die neueste Version. Dabei entsteht eine neue Dataset-Version: Plattform-Zeilen werden per Business Key ergänzt bzw. aktualisiert, Ihre eigenen Zeilen bleiben erhalten (UPSERT — Plattform-Felder gewinnen für Plattform-Schlüssel).
• Die Aktualisierung ist optional: Solange Sie nicht aktualisieren, bleibt Ihre Version unverändert. Auch das Banner ist nur ein Hinweis.
• Aktualisieren erfordert ebenfalls mindestens die Rolle Editor.

Katalogverwaltung (nur AppAdmin)

Nur AppAdmins (Plattform-Betreiber) pflegen den Katalog: neue Datensätze registrieren, Metadaten bearbeiten, neue Versionen veröffentlichen und Datensätze deaktivieren. Diese Funktionen sind mandantenübergreifend und für normale Mandanten-Admins nicht zugänglich.

21. Häufige Fragen (FAQ)

Ich kann mich nicht anmelden — was tun?
Ihr Mandant wurde möglicherweise noch nicht freigeschaltet. Wenden Sie sich an den MDM-Lite-Administrator Ihres Unternehmens.

Ein eingeladener Nutzer hat keine E-Mail erhalten — was tun?
Prüfen Sie zuerst, ob ein Versandweg konfiguriert ist (Einstellungen → Integrationen → E-Mail, siehe E-Mail-Versand konfigurieren). Ohne Konfiguration wird keine Mail verschickt. Lassen den Empfänger zudem den Spam-Ordner prüfen. Anschließend können Sie die Einladung über „Erneut versenden" erneut auslösen oder den Bestätigungslink manuell weitergeben. Bei eigenem M365-/SMTP-Konto hilft der „Verbindung testen"-Button, die Zugangsdaten zu prüfen.

Ich habe einen zusammengesetzten fachlichen Schlüssel (z. B. Land + Segment + Jahr). Wie bilde ich ihn ab?
Legen Sie im Tab „Spalten" eine berechnete Spalte aus den beteiligten Spalten an (Trennzeichen |) und markieren Sie sie als Primärschlüssel. Der Import im Modus „Ergänzen & Aktualisieren" gleicht dann über diese Kombination ab. Die Schritte und Regeln stehen unter Berechnete Spalten.

Warum kann ich eine Zelle nicht bearbeiten, obwohl ich im Bearbeitungsmodus bin?
Berechnete Spalten sind immer schreibgeschützt, ebenso die Quellzellen bestehender Zeilen, wenn die berechnete Spalte der Primärschlüssel ist. Siehe Berechnete Spalten im Tab „Daten".

Mein Import schlägt fehl. Was tun?
Den Fehlerbericht genau lesen — er gibt pro Zeile und Spalte an, was nicht passt. Häufige Ursachen: fehlende Pflichtfelder, falsche Datumsformate (YYYY-MM-DD verwenden), Enum-Werte nicht in der Auswahlliste, Business Key doppelt in der Datei.

Kann ich eine versehentliche Änderung rückgängig machen?
Ja, über „Als neue Version wiederherstellen" im Tab „Verlauf" — siehe Version wiederherstellen (Restore). Das gilt für Datasets vom Typ Tabelle; für Datasets vom Typ Baum steht Restore noch nicht zur Verfügung — dort hilft der Versions-Diff zum manuellen Nachvollziehen der alten Werte, oder ein erneuter Import im Modus „Vollständiger Ersatz".

Ich brauche eine Hierarchie — muss ich den Typ Baum wählen?
Nicht unbedingt. Bei festen Ebenen (z. B. Land → Region → Kontinent) ist eine Hierarchie über Beziehungen zwischen mehreren Tabellen-Datasets meist die bessere Wahl: voller Funktionsumfang je Ebene (Restore, eigene Rollen, eigene Versionen). Nur wenn Einträge derselben Art beliebig tief und mit denselben Spalten verschachtelt sind (Organigramm, Kontenplan), ist Baum die richtige Wahl. Siehe Abschnitt 7.

Warum sehe ich ein Dataset nicht, das ein Kollege erstellt hat?
Prüfen Sie: Haben Sie mindestens die Rolle Viewer? Ist das Dataset im Status Active oder Draft? Im Draft-Status ist das Dataset für Viewer möglicherweise nicht sichtbar.

Kann ich Spalten im Schema nachträglich ändern oder löschen?
Ja, solange das Dataset im Status Draft ist. Nach Veröffentlichung (Active) sind Schema-Änderungen eingeschränkt — bestehende Daten dürfen nicht inkonsistent werden. Sprechen Sie komplexe Schema-Migrationen mit dem Admin ab.

Wie bekommt mein DWH automatisch aktuelle Daten?
Entweder über den automatischen OneLake-Export oder über das generierte Fabric-Notebook (siehe Bereitstellung auf der Datenplattform) oder über die REST-API mit API-Key. Für Notebooks: SYNC_MODE = "auto" (Standard) überträgt nur, wenn sich die Tabelle tatsächlich geändert hat.

Was passiert, wenn ich einen API-Key widerrufe, der noch in einem laufenden Job verwendet wird?
Der Job erhält beim nächsten API-Request sofort 401 Unauthorized. Es werden keine neuen Daten übertragen. Legen Sie vor dem Widerrufen einen neuen Key an und aktualisieren Sie zuerst die Job-Konfiguration.

Gibt es ein Limit für die Datenmenge pro Dataset?
Einzelne CSV/Excel-Dateien können bis zu 50 MB (Web UI) bzw. 100 MB (API) groß sein. Für größere initiale Datenmengen sprechen Sie mit dem MDM-Lite-Administrator.

Kann ich die Oberfläche auf Englisch umstellen?
Ja. Über den Sprachumschalter DE / EN rechts oben in der Kopfzeile. Die Auswahl wird im Browser gespeichert.

Mein Dataset zeigt „Änderungen ausstehend" — was bedeutet das?
Das Dataset wurde nach der letzten Veröffentlichung bearbeitet. Diese Änderungen sind für das DWH erst sichtbar, wenn Sie das Dataset erneut veröffentlichen (siehe Veröffentlichen & Zurückziehen).

Warum sieht mein DWH ein Dataset nicht?
Nur veröffentlichte Datasets erscheinen im Export und im Changes-Feed. Prüfen Sie den Status — Entwürfe und archivierte Datasets sind für automatisierte Abnehmer bewusst nicht sichtbar.

Wie bekomme ich fertige ISO-Codes oder Branchencodes, ohne sie selbst zu pflegen?
Über die Plattform-Datenbibliothek (Symbol 🌐 Bibliothek im Explorer). Dort importieren Sie u. a. ISO-Länder-, Währungs- und Sprachcodes, Incoterms, NUTS-/NACE-Systematiken, EU-MwSt-Sätze sowie deutsche PLZ, BLZ/BIC, GS1-Präfixe und IBAN-Formatregeln mit einem Klick.

Überschreibt eine Bibliotheks-Aktualisierung meine eigenen Anpassungen?
Nein. Beim Import entsteht eine eigenständige Kopie. Eine spätere Aktualisierung übernimmt die Plattform-Zeilen per Business Key (UPSERT) und legt eine neue Version an — Ihre selbst hinzugefügten Zeilen bleiben erhalten, und die Vorversion bleibt in der Historie verfügbar.

Ich finde den Ordner „Plattformdaten" — kann ich ihn löschen?
Nein. Es ist ein geschützter Systemordner für importierte Bibliotheks-Datensätze; er kann nicht umbenannt, verschoben oder gelöscht werden. Eigene Unterordner und Datasets dürfen Sie darin aber anlegen.

Was ist eine Umgebung, und wie wechsle ich sie?
Umgebungen (z. B. Produktion, Test) sind getrennte Datenräume innerhalb desselben Mandanten — jedes Dataset lebt in genau einer davon. Wechseln über das Profil-/Kontomenü oben rechts → Abschnitt „Umgebung". Details: Umgebungen (Test & Produktion).

Wie bekomme ich einen geprüften Datenstand aus der Test- in die Produktions-Umgebung?
Über „In Umgebung kopieren…" im Tab „Integration" des Datasets (Rolle Editor genügt) — im Modus „Bestehendes aktualisieren" landet der Stand als neue Version im Produktions-Dataset, die eigene Historie des Ziel-Datasets bleibt dabei erhalten. Für CI-gesteuerte Promotion steht derselbe Vorgang auch über die API bereit. Details: Umgebungen (Test & Produktion).

Ich kann keine Zelle in der Tabelle anklicken und bearbeiten — was mache ich falsch?
Zellen sind erst im Bearbeitungsmodus editierbar. Klicken Sie zuerst oben im Grid auf „Bearbeiten" — danach lassen sich Zellen bearbeiten, Zeilen hinzufügen und löschen. Details: Daten bearbeiten.

Ich kann den Primärschlüssel einer Zeile nicht mehr ändern — ist das ein Fehler?
Nein, das ist beabsichtigt: Der Primärschlüssel identifiziert eine Zeile eindeutig und ist bei bereits vorhandenen Zeilen schreibgeschützt. Legen Sie für einen anderen Schlüssel eine neue Zeile an und löschen Sie die alte.

Ich habe ein Dataset versehentlich angelegt — kann ich es vollständig entfernen, nicht nur archivieren?
Ja, über Einstellungen → Daten → Archivierte Datasets kann ein Admin ein zuvor archiviertes Dataset endgültig löschen (inkl. Historie und Audit-Log). Das ist unwiderruflich und getrennt von der reversiblen Archivierung. Details: Archivierte Datasets endgültig löschen.

In welchen Formaten kann ich ein Dataset exportieren?
JSON, CSV, Excel (.xlsx) und SQL (als INSERT-Skript, wahlweise mit vorangestelltem CREATE TABLE, in den Dialekten ANSI/PostgreSQL, T-SQL oder Fabric/Azure Warehouse). Details: Export.

Ich habe eine Spalte gelöscht — warum taucht sie in alten Versionen noch auf?
Das ist beabsichtigt: Jede Version merkt sich den Spaltenstand, der bei ihrer Entstehung galt. Eine entfernte Spalte bleibt deshalb beim Öffnen älterer Versionen, bei As-Of-Abfragen vor der Entfernung und im Versionsvergleich sichtbar, samt ihrer Werte. Nur der aktuelle Bearbeitungsstand (Head) sowie neue Versionen und Exporte zeigen sie nicht mehr. Sichtbar ist sie dabei nur für Nutzer, deren Berechtigung die letzte Klassifizierung der Spalte vor dem Löschen erlaubt. Details: Schema-Stand historischer Versionen.

Ich habe eine alte Version wiederhergestellt — warum ist die damalige Spalte trotzdem nicht wieder im Schema?
Weil der normale Restore ausschließlich Daten wiederherstellt, nicht das Schema. Das aktuelle Schema bleibt davon unberührt, und die Werte entfernter Spalten werden dabei nicht übernommen. Der Restore-Dialog zeigt die Abweichung vorab an. Wollen Sie Spalten und Daten zurück, nutzen Sie als Admin des Datasets „Daten und Schema wiederherstellen…“ (im Restore-Dialog) oder „Schema auf Stand v{n} zurücksetzen…“ (im Tab „Verlauf“). Details: Schema auf älteren Stand zurücksetzen.

Ich habe versehentlich Spalten gelöscht — wie bekomme ich sie zurück?
Wenn Sie Admin des Datasets sind: Öffnen Sie den Tab „Verlauf“, wählen Sie bei einer Version vor dem Löschen „Schema auf Stand v{n} zurücksetzen…“ und im Dialog „Schema und Daten von Version #n“ (mit den Werten von damals) oder „Nur Schema – die aktuellen Daten bleiben“ (Spalte kommt leer zurück). Prüfen Sie die Vorschau, lösen Sie ggf. Konflikte und bestätigen Sie. Es entsteht eine neue Version; die Historie bleibt unverändert, und die Klassifizierung wird dabei nie gesenkt. Editoren bitten einen Admin des Datasets darum. Für Baum-Datasets gibt es das nicht. Details: Schema auf älteren Stand zurücksetzen.

Kann ich das Zurücksetzen des Schemas über die API oder per KI-Assistent auslösen?
Nein. Es ist nur in der Web-Oberfläche durch einen Admin des Datasets möglich, weil dabei Konflikte bewusst entschieden werden. API-Keys und MCP lesen das Ergebnis nur.