Workbench

Überblick

Die Workbench führt von einer angebundenen Quelle zu einem geprüften DATAMIMIC-Modell. Wähle eine Umgebung, prüfe ihre Struktur, triff die zur Quelle passenden Entscheidungen und konfiguriere anschließend ein Modell. Sie bietet drei quellspezifische Modi:

Umgebungstyp	Modus	Zentraler Ablauf
Relationale Datenbank	Database	Tabellen-Scope wählen, Abhängigkeiten validieren, anschließend ein Modell konfigurieren.
MongoDB	Mongo	Eine Collection scannen, ihren Snapshot prüfen, anschließend ein Modell konfigurieren.
Object Storage	Object Storage	Eine unterstützte Datei oder ein Parquet-Dataset scannen, die Struktur prüfen, anschließend ein Modell konfigurieren.

Öffne Workbench in der Projektnavigation und wähle eine Umgebung. Lege die passende Umgebung vorher unter Settings → Environments an.

Ein erzeugtes Modell wird nicht automatisch ausgeführt

Die Workbench erstellt eine Projektdatei und öffnet sie im Editor. Sie ändert weder automatisch datamimic.xml, noch fügt sie ein Include hinzu oder startet einen Lauf. Entscheide bewusst, ob das Modell Teil der Projektkomposition werden soll. Nutze danach die Include-Referenz und die Aktion Generate im Editor.

Database-Modus

Der Database-Modus plant ein relationales Modell aus gescannten Metadaten. Auf einem breiten Bildschirm können Scope, Columns und Database workbench gleichzeitig geöffnet sein. Du kannst einzelne Bereiche fokussieren oder einklappen, ohne deine Auswahl zu verlieren.

Tabellen-Scope und das Öffnen einer Tabelle sind getrennte Steuerelemente: Die Checkbox ändert den Modell-Scope; das benachbarte Tabellen-Steuerelement öffnet die Spalten.

Ein Datenbankmodell planen

1. Scanne die Metadaten der gewählten Datenbankumgebung, wenn sie nicht aktuell sind.
2. Nutze im Bereich Scope die Tabellen-Checkbox, um eine Tabelle zum Modell-Scope hinzuzufügen oder daraus zu entfernen. Öffne die Spalten über das benachbarte Tabellen-Steuerelement; das Öffnen ändert den Scope nicht.
3. Prüfe unter Columns die gewählte Tabelle. Schlüssel- und Beziehungsmarker, Personal-Data-Kandidaten, Entity-Vorschläge und kompakte Empfehlungen wie Script · Person.email, Generator · StringGenerator oder Default · Preserve geben Kontext für das Modell. Nach der Planung wechselst du mit Previous und Next durch die geplanten Tabellen.
4. Nutze für bekannte personenbezogene Daten Mark as personal data. Remove manual mark entfernt nur deine explizite Markierung. Die sichtbare Empfehlung bleibt eine Empfehlung und ist keine Katalogregel.
5. Wähle Plan subset. Die Workbench validiert Abhängigkeiten und übernimmt die benötigte Tabellen-Closure in den Scope. Prüfe Verdict und Zähler unter Validate dependencies. Löse erforderliche Abhängigkeitsentscheidungen oder bestätige sie ausdrücklich, bevor die Modellkonfiguration verfügbar ist.
6. Wähle Configure model und anschließend das gewünschte Ergebnis:

Modelltyp	Was das erzeugte Modell macht
Synthetic data model	Liest die Metadaten der gewählten Quelle und schreibt nicht in eine Ziel-Datenbank.
De-identification model	Liest Quelldaten und schreibt de-identifizierte Daten in die explizit gewählte Ziel-Datenbank.
ML training model	Liest die Metadaten der gewählten Quelle und schreibt nicht in eine Ziel-Datenbank.

1. Für ein De-identification-Modell kann der Wizard anhand des Projekt-Schwellenwerts Personal-Data-Kandidaten im geplanten Scope vorauswählen. Prüfe diese Auswahl vor dem Erstellen.
2. Vergib einen Namen und erstelle das Modell. Die neue XML-Datei öffnet sich im Editor.

Zuerst Plan subset ausführen, den Abhängigkeitsstatus prüfen und dann über Configure model das Ergebnis auswählen und konfigurieren.

Nutze Weighting nur zum Erzeugen von Weighting-Artefakten aus dem bestehenden Datenbank-Scope. Unter Schema history prüfst du Metadaten-Snapshots und Drift; dies ersetzt keine aktuelle Planungsentscheidung.

Details zu Datenbank-Metadaten, Refresh und Relationship-Quellen findest du unter Datenbankansicht.

Mongo-Modus

Der Mongo-Modus prüft jeweils einen begrenzten Collection-Snapshot. Der Scan verändert die Collection nicht.

MongoDB: Collection auswählen, begrenztes Sample scannen und dann Feld-Scope, Empfehlungen und Personal-Data-Entscheidungen prüfen.

Eine MongoDB-Collection scannen und prüfen

1. Durchsuche Datenbanken, öffne die benötigte Datenbank und wähle eine Collection. Die Browse-Zeile zeigt unabhängig voneinander Scan-Ziel, aktuell geprüfte Collection und den neuesten Snapshot-Status.
2. Setze Sample limit und Max nesting depth und wähle Scan Collection. Der Button nennt das gewählte Ziel; der vollständige Locator bleibt als Tooltip verfügbar.
3. Lies den Snapshot-Kontext über dem Review: Quelle, Locator, Zeit, Feldanzahl, Sample-Anzahl, Warnungsanzahl und Status.
4. Wähle unter Review die Felder für das Modell. Suche, Filter, Expand all, Select all und Clear helfen bei größeren Dokumenten. Speichere Änderungen mit Save selection, bevor du ein Modell konfigurierst.
5. Bestätige für bewertete Blattfelder Personal data oder wähle Not personal data. Die Entscheidung speichert Bearbeiter und Zeitpunkt und lässt sich rückgängig machen. Unbewertete Felder zeigen statt eines Entscheidungs-Controls ihren Auswertungsstatus.
6. Behandle Tiefenwarnungen als Scope-Entscheidung: Akzeptiere die Warnung, wenn das aktuelle Sample ausreicht, oder nutze die angebotene erneute Tiefe, wenn du mehr Struktur brauchst.
7. Öffne Scan history, um persistierte Snapshots zu prüfen. Jeder Eintrag zeigt Quelle, Locator, Zeitstempel, Feldanzahl, Warnungen und den Status Latest, Superseded oder Failed. Use scan lädt einen Snapshot; überholte Snapshots sind schreibgeschützt.
8. Wähle Generate und dann Configure model. Wähle Modelltyp und Dateinamen im Wizard. Für ein MongoDB-De-identification model wählst du eine Zielumgebung und eine von der Source-Collection abweichende Ziel-Collection und gibst die Anzahl der Datensätze an. Die Quell-_id bleibt erhalten.
9. Erstelle das Modell. Die neue XML-Datei öffnet sich im Editor.

Scan history zeigt den persistierten Snapshot-Kontext, der für die Wahl der passenden Review-Basis nötig ist.

Die Modellkonfiguration verwendet den gespeicherten Review-Scope; ein MongoDB-De-identification-Modell verlangt ein explizites Ziel.

Object-Storage-Modus

Der Object-Storage-Modus prüft die Struktur einer einzelnen unterstützten Datei oder eines Parquet-Datasets. Er bietet bewusst keine Personal-Data-Review-Controls: Die Quelle ist ein gescanntes Objekt, keine angebundene Source-Collection für Data De-identification.

Object Storage: unterstützte Objekte durchsuchen, formatabhängige Scan-Controls verwenden, anschließend Modell prüfen und konfigurieren.

1. Navigiere zu einer unterstützten CSV-, JSON- oder Parquet-Datei. Wähle eine Datei, oder öffne ein Verzeichnis, um es als Parquet-Dataset zu scannen. Nicht unterstützte Formate bleiben deaktiviert und erläutern den Grund beim Überfahren.
2. Setze die quellabhängigen Limits: CSV nutzt Row limit; JSON nutzt Record limit und Max nesting depth; Parquet nutzt Row limit und Max partition size.
3. Wähle die Scan-Aktion, die die gewählte Datei oder das Dataset nennt.
4. Wähle unter Review die für das Modell benötigten Felder und nutze Save selection. Recommendation-Badges beschreiben die erkannte Aktion; ihr vollständiger Token ist über Fokus oder Hover verfügbar. In diesem Modus gibt es keine Personal-Data-Entscheidungen.
5. Nutze Scan history, um den persistierten Snapshot für Review oder Generierung auszuwählen.
6. Wähle Generate und dann Configure model. Erstelle das Modell, um es im Editor zu öffnen.

Im Editor fortfahren

Nach erfolgreicher Modellerstellung wechselt die Workbench zu Editor und wählt die erzeugte Datei aus.

Die erzeugte XML-Datei ist eine Projektdatei. Prüfe und komponiere sie bewusst, bevor du das Projekt ausführst.

Prüfe die Datei, entscheide, ob sie aus datamimic.xml eingebunden werden soll, und starte danach einen Projektlauf im Editor. Die Include-Referenz ist die verbindliche Dokumentation für XML-Komposition; diese Seite dokumentiert nur den Workbench-Ablauf.