Realdaten konsistent verwürfeln?

[stahli]

Ich glaube es ja nicht, aber kennt jemand evtl. ein Tool für folgende Aufgabenstellung?


Ich habe diverse größere CSV´s in der Form

"KdNr";"Vorname";"Nachname";"KontoNr"
"01";"Klaus";"Müller";"2222"
"09";"Gerhard";"Müller";"3333"
"02";"Klaus";"Meier";"1111"
"03";"Bernd";"Lehmann";"4444"

"KontoNr";"Guthaben"
"1111","999"
"2222","9999"
"3333","99"
"4444","99999"

Jetzt möchte ich die Daten anonymisieren.
Ich könnte z.B. alle oder einige Spalten beider Dateien im Excel jeweils isoliert aufsteigend sortieren. Dann gäbe es keine Bezüge mehr zu den realen Datensätzen.
Lediglich die KontoNr als Bezug der Tabellen untereinander wäre noch vorhanden.

Optimaler Weise würde ich aber gern einen zeitlichen Stapel solcher Dateien "transferieren".
Ich habe diese Dateien nämlich monatlich vorliegen und würde daraus gern konsistente monatliche Testdaten generieren.

Das heisst, die csv´s müssten automatisiert zerlegt, mit Hilfe eines Dictionarys in Demodaten umgeschrieben und wieder in gleicher Form ausgegeben werden.

Dazu müsste pro Datei ein Schlüsselfeld angegeben werden und es müsste für jeden Monat konsistent aus
original
"KdNr";"Vorname";"Nachname";"KontoNr"
"01";"Klaus";"Müller";"2222"
nun
"01";"Gerhard";"Lehmann";"4444"

Erst wenn Klaus Müller wegen Heirat Klaus Maier heisst, sollte auch der Demo-Nachname geändert werden.


Kennt jemand Lösungen für so etwas?
Ich denke ja eher nicht, da das Ganze ja doch recht komplex werden kann.

Andererseits kann es Bedarf für solche "konsistenten" Anonymisierungen ja schon gelegentlich geben.

[Jumpy]

Habe gerade ein ähnliches Problem, aber auf Datenbank ebene, nicht in einer Datei.
Ich plane, z.B. einmalig eine Vornamens-Nachschlage-tabelle zu machen ala:

SQL-Code:

Create Table VornamenNachschlageTabelle
Select Distinct Rownum as ID, Vorname From Tabelle
Where Rownum<=500

Das wäre dann sowas wie bei dir das Dictionary.

Dann, um das reproduzierbar zu halten, wird anhand der Personalnummer aus dieser Tabelle ein Name gezogen, ungefähr so:

SQL-Code:

Update Personaltabelle P
Set P.Vorname= (Select V.Vorname von VornamenNachschlageTabelle V Where V.ID=MOD(Personalnummer,500))

Analog dann bei Nachname, Strasse usw.

Keine Ahnung ob es da nicht schlauere Lösungen gibt um Testdaten zu generieren. Den Namenswechsel bei Hochzeit, bekommt man so in den Testdaaten nicht mit, aber das ist auch nicht nötig für uns.

[mensch72]

Wir nutzen simpel einen MD5 Hash zur Anonymisierung...

Also würde ich einen MD5 aus ("KdNr";"Vorname";"Nachname") berechnen und dann habe ich im Test/Demo-CSV nur noch "HASH";"KontoNr" :)

[stahli]

Die Demodaten will ich ggf. weiter geben können.
Es sollen also umfangreiche echte Daten sein, aber ohne realen Personen-Bezug (originale Form der Dateien und innere - auch zeitliche - Konsistenz).

[Jumpy]

Zitat:

Zitat von mensch72 (Beitrag 1345837)

Wir nutzen simpel einen MD5 Hash zur Anonymisierung...

Also würde ich einen MD5 aus ("KdNr";"Vorname";"Nachname") berechnen und dann habe ich im Test/Demo-CSV nur noch "HASH";"KontoNr" :)

War auch unser erster Ansatz. Leider wollte der Kunde, das auch bei den Testdaten die Vornamen noch wie Vornamen aussehen usw.

[mensch72]

aus den 16Bytes MD5 kann man auch 2x 8Bytes machen und eine sagen wir CRC16 darüber rechen umd dann diese nochmal per Modulo auf die Anzahl der verfügbaren Records zu begrenzen... dann bekommt man 2x einen "Index", welchen Vornamen und welchen Nachnamen man jeweils kombinieren soll.

Das sollte ausreichend flexibel sein, um genug anonyme Verwürfelung der Klarnamen zu bekommen... vorwärts eindeutig zu bestimmen, aber rückwärts nicht rückrechenbar

[Mavarik]

Zitat:

Zitat von stahli (Beitrag 1345843)

Die Demodaten will ich ggf. weiter geben können.
Es sollen also umfangreiche echte Daten sein, aber ohne realen Personen-Bezug (originale Form der Dateien und innere - auch zeitliche - Konsistenz).

Leg dir einfach eine Liste mit Vornamen und Nachnamen an und stelle diese per Random zu neuen Namen zusammen...

Original

[0] Petra;Putzig;Gartenstraße 7;53111; Bonn
[1] Rudi;Rastlos;Hofgarten 42;52223 Stolberg;

Daraus 5 Listen machen

Dann 5x Random; Randomwerte 1-5 müssen unterschiedlich sein.
Randomwert verbraucht, aus der Liste werfen..

So hast Du n Adressen aber keine ist real...

[Namenloser]

Zitat:

Zitat von mensch72 (Beitrag 1345851)

Das sollte ausreichend flexibel sein, um genug anonyme Verwürfelung der Klarnamen zu bekommen... vorwärts eindeutig zu bestimmen, aber rückwärts nicht rückrechenbar

Das kann man sehr leicht mit einer Wörterbuchattacke zurückrechnen. Bitte auf keinen Fall MD5 oder sonstige Hashes zur „Anonymisierung“ verwenden! Außer du verwendest einen zufälligen, ausreichend langen Salt, den du anschließend wegschmeißt.

[BUG]

Da gabs doch auch mal was aus der c't.

[Mavarik]

Zitat:

Zitat von Namenloser (Beitrag 1345880)

Zitat:

Zitat von mensch72 (Beitrag 1345851)

Das sollte ausreichend flexibel sein, um genug anonyme Verwürfelung der Klarnamen zu bekommen... vorwärts eindeutig zu bestimmen, aber rückwärts nicht rückrechenbar

Das kann man sehr leicht mit einer Wörterbuchattacke zurückrechnen. Bitte auf keinen Fall MD5 oder sonstige Hashes zur „Anonymisierung“ verwenden! Außer du verwendest einen zufälligen, ausreichend langen Salt, den du anschließend wegschmeißt.

Es geht nicht um Hashing.... Es geht um ganz normal lesbare Demo-Daten! :stupid:

[mensch72]

im einfachsten Fall exportiere man Namensdaten aus einer Telefonbuch CD.
Dann jeweils die Datensatznummerm von Vornamen und Nachnamen gegenläufig indiziert wieder zusammensetzen.. vola, fertig ist eine braucbar lesbare Namensliste mit zufälliger Kombination aus Vor- & Nachnamen.

Sagen wir das ergibt 65536 Datensätze mit "Demo-Namen"... dann rechne ich über die zu anonymisierenden Teile (oder einem HASH davon) meiner sagen wir 10000 org. Daten einen CRC16 und nutze diesen als Index auf meine 65536 DemoDatensätze. Da lässt sich nix per Wörterbüchern oder CRC16/MD5 Revers eineindeutig zurückrechnen, also es lässt sich so definitiv nicht wieder deanonymisieren:)

[Mavarik]

Zitat:

Zitat von mensch72 (Beitrag 1345902)

Sagen wir das ergibt 65536 Datensätze mit "Demo-Namen"... dann rechne ich über die zu anonymisierenden Teile (oder einem HASH davon) meiner sagen wir 10000 org. Daten einen CRC16 und nutze diesen als Index auf meine 65536 DemoDatensätze. Da lässt sich nix per Wörterbüchern oder CRC16/MD5 Revers eineindeutig zurückrechnen, also es lässt sich so definitiv nicht wieder deanonymisieren:)

Vergiss doch mal den Hash quatsch... Darum geht es doch überhaupt nicht...

[mensch72]

Zitat:

Zitat von Mavarik (Beitrag 1345918)

Vergiss doch mal den Hash quatsch... Darum geht es doch überhaupt nicht...

Hier im Post 1 steht, das:
..."Dazu müsste pro Datei ein Schlüsselfeld angegeben werden und es müsste für jeden Monat konsistent aus original
"KdNr";"Vorname";"Nachname";"KontoNr"
"01";"Klaus";"Müller";"2222"
nun
"01";"Gerhard";"Lehmann";"4444"
Erst wenn Klaus Müller wegen Heirat Klaus Maier heisst, sollte auch der Demo-Nachname geändert werden."...

Es geht also nach meinem Verstädnis nicht nur um x-beliebige Zuordnung von puren Zufallsdatensätzen.
=> Ich würde deshalb speziell bei/wegen dieser Anforderung vorschlagen, eine Hash oder CRC basierte Indexauswahl von konstanten Listen mit zufälligen Werten zu verwenden, denn damit bleibt die "zufällige" Zuordnung solange gleich, bis sich im Ausgangswert(Namen) etwas ändert.

[fillibuster]

Hallo,

wenn es PHP sein darf - für die Erstellung von Demodaten nutze ich immer Faker. Das Script sollte locker deine Anforderungen erfüllen.

Viele Grüße ...

[bernau]

Zitat:

Zitat von mensch72 (Beitrag 1345936)

Zitat:

Zitat von Mavarik (Beitrag 1345918)

Vergiss doch mal den Hash quatsch... Darum geht es doch überhaupt nicht...

Hier im Post 1 steht, das:
..."Dazu müsste pro Datei ein Schlüsselfeld angegeben werden und es müsste für jeden Monat konsistent aus original
"KdNr";"Vorname";"Nachname";"KontoNr"
"01";"Klaus";"Müller";"2222"
nun
"01";"Gerhard";"Lehmann";"4444"
Erst wenn Klaus Müller wegen Heirat Klaus Maier heißt, sollte auch der Demo-Nachname geändert werden."...

Es geht also nach meinem Verständis nicht nur um x-beliebige Zuordnung von puren Zufallsdatensätzen.
=> Ich würde deshalb speziell bei/wegen dieser Anforderung vorschlagen, eine Hash oder CRC basierte Indexauswahl von konstanten Listen mit zufälligen Werten zu verwenden, denn damit bleibt die "zufällige" Zuordnung solange gleich, bis sich im Ausgangswert(Namen) etwas ändert.

Nicht wirklich gut von Stahli beschrieben. Demodaten aus original Daten zu erstellen, ohne diese im Unfang noch einzuschmelzen finde ich kritisch. Aber darum geht es anscheinend auch nicht.

Mich würde interessieren, wiso die Zuordnung stattfinden muss.

• Sollen die Demodaten in Originaldaten zurück gerechnet werden?
• Soll mit den Demodaten richtig gearbeitet werden?
• Vileicht sind es auch nur konvertierte Daten aus einer Konkurenz-Software, die erst mal getestet werden sollen.

Mit mehr Input könnte man ggf. die passende Lösung finden.

[bra]

Zitat:

Zitat von Mavarik (Beitrag 1345853)

Leg dir einfach eine Liste mit Vornamen und Nachnamen an und stelle diese per Random zu neuen Namen zusammen...

Original

[0] Petra;Putzig;Gartenstraße 7;53111; Bonn
[1] Rudi;Rastlos;Hofgarten 42;52223 Stolberg;

Daraus 5 Listen machen

Dann 5x Random; Randomwerte 1-5 müssen unterschiedlich sein.
Randomwert verbraucht, aus der Liste werfen..

So hast Du n Adressen aber keine ist real...

Das halte ich aber für alles andere als sauber. Man hat immer noch die reellen Namen und Daten, nur in gequirlter Zuordnung. Datentechnisch halte ich das für nicht unbedenklich.

[stahli]

Sorry, ich habe das etwas unscharf beschrieben, aber andererseits will ich mich nicht nur auf meinen Spezialfall beschränken. Vielleicht kann man das gleich etwas allgemeiner betrachten.

Grundsatz:
- Es sollen Testdaten für Entwickler erzeugt werden, die nach Struktur und Umfang Realdaten entsprechen, aber keinen Bezug auf reale Personen- oder Firmendaten (Namen, Adressen, Kontonummern, Schulden) zulassen.
- "Max Mustermann"-Datensätze sind unerwünscht, um Grenzfälle ausreichend testen zu können.

Spezialfall:
Bei uns liegen pro Monat mehrere Importdateien als csv vor, die monatlich in das Hauptprojekt importiert wurden.
Die Dateien bilden untereinander relationale Beziehungen ab und monatlich chronologische Änderungen der Importdaten.

allgemeines Problem:
Für eine Neuerstellung des Hauptprojektes sollen anonyme Demodaten zur Verfügung gestellt werden.
Einmalig im Hauptprojekt die Kundennamen und Adressen zu verwürfeln wäre kein sehr großes Problem. Allerdings wären dann beispielhaft z.B. Rechnungsnummern und Auftragsnummern noch original. Gut, das könnte man vielleicht so hinnehmen.

spezielles Problem:
Vorliegend sollen aber auch die gesamten Importfiles in Demodaten umgewandelt werden, also je alle 6 csv´s über mehrere Monate (ggf. auch über alle Jahre).

Das Tool müsste also erfahren, welche "Spalte" in welcher csv wie zu ändern ist.
Wenn Kunde Id=10, Name=Müller z.B. umgewandelt wurde in Kunde=10, Name=Meier müsste das in allen späteren Konvertierungen gleichermaßen gemacht werden.
Wenn gleichzeitig die Id geändert wird (Kunde Id=10, Name=Müller in Kunde=999, Name=Meier) geändert würde, müsste auch in Rechnungsdaten die KundenId angepasst werden.

Auch wäre sinnvoll, eMail-Adressen, Telefonnummern und Kontonummern zu verfälschen und künftig auch immer diese verfälschte Nummer wieder zu verwenden. Also wirklich über ein Dictionary.

Tool:
Ich habe schon eine Vorstellung, wie ich unsere Daten entsprechend umstellen könnte, wollte aber mal generelle Meinungen (zu Bedarfen und Lösungen) hören.
Ich werde mal ein Tool erstellen. Vielleicht kann man das ja dann allgemein einsetzen (wobei unser eigener Anwendungsfall vermutlich schon sehr speziell ist).


PS:
Danke für den Heise-Artikel. Habe ich mir gekauft.
Danke auch für das PHP-Tool. Das scheint aber nicht ganz zu passen, soweit ich das nachvollziehen kann.

[himitsu]

Du hast doch eine Datenbank, wo die Spalten auch untereinander ordentlich verbunden sind.
Wozu also in den CSV das nochmal versuchen zu verknubbeln?

Importiere die Daten in eine leere/neue Datenbank, verändere dort die Namen und die Abhängigkeiten sollten sich dann alle von Alleine anpassen.
REFERENCES ON UPDATE CASCADE
Und so Dinge, wie "ausversehn" doppelte Namen, welche ausversehn entstehen könnten, sollten sich ebenfalls mit den passenden CHECK-CONSTRAINTS verhindern lassen.

Und dann kann man das gern wieder als CSV exportieren.

[stahli]

Es geht bei uns auch darum, den regelmäßigen Datenimport neu zu realisieren.
Deshalb ist es nicht ausreichend, die Datenbanken umzustellen.
Wir benötigen auch über einen größeren Zeitraum passende umgestellte Demodaten für den Import-Test.

Aber ich sehe schon, das wird eher ein Sonderfall sein.

[nahpets]

Ich versuche mal die Aufgabenstellung etwas flacher darzustellen:

Ich bekommt irgendwann mal die Daten für:

Peter Müller, KundenID = 4711, Kontonummer = 4812 bei der Postbank.

Daraus sollen nun Testdaten werden, bei denen nicht mehr nachvollziehbar ist, welcher Person sie ursprünglich zugehörig waren.

Also wird aus o. g. Person nunmehr durch "irgendeinen Zufall" für die Testdaten:

Hansi Meier, KundenID = 1234, Kontonummer = 9876 bei der Targo-Bank.

Bei einer einmaligen Datenlieferung wäre das ok.

Nun kommt aber zu einem späteren Zeitpunkt mal wieder was an Daten für Peter Müller.
Bei den Originaldaten ist eine Zuordnung kein Problem.

Für die Testdaten muss der o. g. "irgendeinen Zufall" aber die Daten wiederum korrekt dem zufällig entstandenen Hansi Meier zugeordnet werden.

Letztlich wird hier also ein "reproduzierbarer Zufall" benötigt. Damit ist es aber letztlich keiner mehr.

Was meiner Meinung nach gehen müsste wäre:

Über die Originaldaten wird pro Satz irgendein Wert (Hash, MD5 ...) ermittelt und gespeichert.

Dieser Wert wird mit der eindeutigen ID der Testdaten verbunden.

• Zuordnung Original zu Testdaten
• Hashwert
• TestdatenID

Nun kann man beim Eintreffen neuer Daten in der Tabelle den Wert des Originals suchen und die zu den Testdaten gehörige TestdatenID finden und damit eine entsprechende Zuordnung machen.

Über diese Tabelle wird aber immer ein Rückschluss von den Testdaten auf die Originaldaten möglich sein, es sei denn:

Den Algorithmus zur Ermmittlung des Hashwertes macht man nicht bekannt.

Aus dem MD5-Wert kann man z. B. nicht zurückschließen, wie der Originalwert war. Bei ihm ist die Eindeutigkeit aber nicht sichergestellt.
Aber: MD5 über Vorname + MD5 über Nachname + MD5 über KundenID sollten sicher reichen.

Eine "Rückwärtssuche" über die TestdatenID in dieser Tabelle und dann diese drei MD5-Werte ermitteln, um ans Original zu kommen, dürfte schon etwas "umfangreicher" werden, da für alle Originaldaten geprüft werden muss, ob sie den entsprechenden Wert ergeben. Ist der Algorithmus nicht bekann, dürfte es sehr schwierig werden.

Wenn sichergestellt ist, dass die Entwickler ... keinen Zugriff auf diese Tabelle bekommen, dürfte ein ausreichend sicherer Schutz der Originaldaten gegeben sein.

[stahli]

Die Zusammenfassung ist korrekt aber ich denke eine Lösung ohne Hashwerte an.

aus
Peter Müller, KundenID = 4711, Kontonummer = 4812 bei der Postbank
wird
Hansi Meier, KundenID = 1234, Kontonummer = 9876 bei der Targo-Bank


Ich werde dafür ein Dictionary benutzen.

Beim ersten mal wird für den ersten Kundendatensatz:
"Kunde: Peter Müller" = "Hansi Meier"
"KundenId: 4711" = "9876"
"Bank: Postbank" = "Targo-Bank"
angelegt.

Die Zielwerte werden pro neuem Eintrag für jedes Feld aus einem zufälligen Record aus dem realen Datenbestand geholt (und auf Wunsch verstümmelt) oder auf Wunsch neu generiert.

Wenn künftig "Kunde: Peter Müller" verwendet wird, wird der immer in "Hansi Meier" übersetzt.
Wenn eine Rechnung an "KundenId: 4711" geht, wird die ID in 9876 geändert.

Dazu muss das Tool sozusagen global für alle csv erfahren, welche Zuordnungen die einzelnen Felder tatsächlich haben und wie diese anzupassen sind.


Vielleicht muss ich noch etwas präzisieren: Ich möchte einen Stapel von z.B. 100*6 csv-Dateien auf einen Rutsch verändern, so dass 600 neue csv-Dateien entstehen, die in sich weiterhin konsistent sind aber möglichst wenig Rückschlüsse auf die Originaldateien zulassen.
Es geht also nicht um einen Import in das Hauptprojekt sondern um eine Anonymisierung vorliegender externer Importdaten zu Testzwecken.

[nahpets]

Also ich versuchs nochmal:

Du möchtest reproduzierbar aus den Daten A die Daten B bekommen.

Dies soll für Dich nachvollziehbar sein.
Anhand der "Übersetzung" von A nach B ist auch der umgekehrte Weg (theoretisch) möglich.

Die Nutzer der Testdaten haben jedoch keinen Zugriff darauf und können daher keine Rückschlüsse ziehen.

Wenn dies für Dich ausreichend "sicher" ist, so scheint für mich der von Dir gewählte Weg ausreichend.

Über Nachschlagtabellen kann für jedes A jederzeit nachgesehen werden, wie das zugehörige B auszusehen hat.

Die Datenmenge sollte für die von Dir anvisierte Vorgehensweise irrelvant sein. Sie funktioniert für 1 bis n Datensätze in einer beliebigen Menge von Dateien.

[stahli]

Genau so ist es zutreffend.
Rückwandlung von B nach A ist nicht notwendig.

Für mich werde ich ein entsprechendes Tool bauen.

Die Frage ist, ob es generell Nachfrage dafür geben kann, wenn man das etwas allgemeiner hält.
Ggf. könnte man so ein Tool auch auf eine rel. Datenbank anwenden, wobei das dann sicherlich etwas komplexer wird - zumindest wenn mach die Schlüssel und Fremdschlüssel ändern will.

Braucht man keine Schlüsseländerung (was sicherlich meist der Fall ist), wäre dann ein Tool dafür sinnvoll und flexibel genug?
Man könnte natürlich einzelne Tabellen auch als csv exportieren, umwandeln und die neuen csv wieder in eine neue Datenbank importieren.

Also die Frage: Wäre so ein allgemeines, flexibles Tool wohl interessant?

[BUG]

Zitat:

Zitat von nahpets (Beitrag 1346082)

Du möchtest reproduzierbar aus den Daten A die Daten B bekommen.

Wozu reproduzierbar, er speichert das Ergebnis eh in einer Tabelle.

Blöd wird es mit Daten, die vielleicht allein schon identifizierend sind: IBANs, Telefonnummern, ...
Gerade Telefonnummern will man aber auch nicht unbedingt genieren, da hier die Struktur bei realen (eingegebenen) Daten doch ziemlich variieren kann.

[nahpets]

Testdaten werden immer und überall gebraucht und ich weiß nicht wieviele Leute ich schon kennengelernt habe, die vor genau Deinem Problem standen:

Wie bekomme ich reproduzierbare Testdaten hin?

Oder zu Deiner Frage konkret:

Zitat:

Zitat von stahli

Also die Frage: Wäre so ein allgemeines, flexibles Tool wohl interessant?

Meiner Meinung nach eindeutig: Ja

Die Fragen dazu sind nur:

• Gibt jemand dafür Geld aus?
• Und wenn ja, wieviel?

Für Deine Aufgabenstellung wäre eigentlich (wenn man's datenbankgestützt sieht), eine dreispaltige Tabelle erforderlich.

Spaltenname|Originalwert|Testwert
Name|Peter Maier|Hansi Müller
KundenID|4711|1234
Bank|Postbank|Targo-Bank

@BUG

Reproduzierbar deshalb, weil stahli immer wieder Datenergänzungen per CSV-Dateien bekommt, die er sowohl den Originaldaten als auch den Testdaten zuordnen muss. Und zwar nicht irgendwie, sondern konsistent.

Es muss also immer aus Peter Meier Hansi Müller werden, es muss immer aus der KundenID 4711 die KundenID 1234 werden.

Und wenn stahli diese Informationen in einer Tabelle ablegt, dann ist die erstmalig per Zufall erstellte Zuordnung anschließend über eben diese Tabelle reproduzierbar.

Und wenn er die Testdaten vollständig löscht und anschließend neu erstellt, dann müssen sie mit den ursprünglichen Testdaten zu 100% übereinstimmen.
Und damit müssen sie reproduzierbar ein.

Oder sollte ich die Aufgabenstellung immer noch nicht verstanden haben?

[stahli]

@nahpets

Vollkommen korrekt, aber etwas einfacher.
Normalerweise sollte für uns jetzt eine einmalige Konvertierung von 600 Testdateien reichen um ein neues Projekt aufzubauen und den Import zu testen.

Für andere Projekte könnte es ggf. interessant sein, dass man nach und nach immer weitere Dateien umwandelt. Das wäre dem Tool dann aber letztlich egal. Man müsste nur die Übersatzungstabelle aufheben.

Ich bastle mal was. Kann aber etwas dauern...

@BUG

Für IBANS, Telefonnummern und eMailadressen könnte man zum normalen verwürfeln noch eine Verstümmelung von 0..100% einstellen.
Max Mustermann würde dann die eMail "[e-mail]" zugeordnet und da diese in sich ja noch real ist könnten z.B. 80% der Zeichen noch verändert bzw. gelöscht werden.

[BUG]

Zitat:

Zitat von stahli (Beitrag 1346087)

Für IBANS, Telefonnummern und eMailadressen könnte man zum normalen verwürfeln noch eine Verstümmelung von 0..100% einstellen.
Max Mustermann würde dann die eMail "[e-mail]" zugeordnet und da diese in sich ja noch real ist könnten z.B. 80% der Zeichen noch verändert bzw. gelöscht werden.

Bei IBANs sollte das gut gehen, eventuell muss man die Prüfsumme noch neu errechnen. Bei Telefonnummern wird es schwerer, die so zu verstümmeln, das die Struktur erhalten bleibt: Vorwahlen, nicht numerische Zeichen, usw. Wenn so etwas in den realen Daten ist, wäre es nett, wenn das in den Testdaten auch mit dabei ist.

[nahpets]

Zitat:

Zitat von stahli (Beitrag 1346087)

@nahpets

Vollkommen korrekt, aber etwas einfacher.
Normalerweise sollte für uns jetzt eine einmalige Konvertierung von 600 Testdateien reichen um ein neues Projekt aufzubauen und den Import zu testen.

Und meiner Meinung nach braucht man dazu reproduzierbare Testdaten.
Wenn der Importtest (aus welchen Gründen auch immer) scheitert, "dumme Sachen macht", also nicht perfekt funktioniert, so muss mit den Originaldaten wieder ein Testdatenbestand erstellt werden und der Import erneut getestet werden.
Klar, man kann auch alle "Testdatenzwischenstufen" für immer und wiederholte Nutzung aufheben. Und man muss da dann auch (hoffentlich) den Durchblick behalten.

Klar, die Übersetzungstabelle "muss" erhalten bleiben. Ist sie nicht mehr vorhanden, so kann man neue Daten "würfeln".

Und nach der erstmaligen Befüllung des Projektes mit Testdaten kommt ganz bestimmt sehr bald irgend jemand, der sagt: "Du, stahli, Testdaten kaputt, kannst Du bitte mal eben neu machen?" ;-)
Und wenn jemand sagt: "Das brauchen wir garantiert nur einmalig!" Jede Wette, der kommt bald wieder und sagt: "Nochmalhabenwollen" ;-)

Zitat:

Zitat von stahli (Beitrag 1346087)

Für andere Projekte könnte es ggf. interessant sein, dass man nach und nach immer weitere Dateien umwandelt. Das wäre dem Tool dann aber letztlich egal. Man müsste nur die Übersatzungstabelle aufheben.

Sowas würd' ich immer einplanen, wenn ich mir sowieso schon viel Arbeit machen muss, dann ist das sicherlich einfacher sofort integriert, als später (in vier Wochen oder 'nem Jahr) noch nachträglich einzubauen.

Zitat:

Zitat von stahli (Beitrag 1346087)

Kann aber etwas dauern ...

Wenn das morgen fertig wäre, dann aber Hut ab ;-)

Zitat:

Zitat von stahli (Beitrag 1346087)

@BUG

Für IBANS, Telefonnummern und eMailadressen könnte man zum normalen verwürfeln noch eine Verstümmelung von 0..100% einstellen.
Max Mustermann würde dann die eMail "[e-mail]" zugeordnet und da diese in sich ja noch real ist könnten z.B. 80% der Zeichen noch verändert bzw. gelöscht werden.

Für die Mails würd' ich mir 'ne Domaine aussuchen, die es nicht gibt und (höchstwahrscheinlich) nie geben wird.
Vor die Domaine kommen Vorname.Nachname.KundenID und fertig ist die Laube. Email-Dubletten sind damit dann (hoffentlich) auch ausgeschlossen. Z. B.: [e-mail]
Sollte es mehrere Peter Meier geben, was bei 'nem größeren Datenbestand wahrscheinlich ist, so unterscheiden sich die Emailadressen auf jeden fall, ohne dass man mehr oder weniger komplizierte Algorithmen über die Originalemailadressen jagen muss.

Telefonnummern und IBAN würd' ich aus der KundenID (oder sowas) erstellen, indem ich die solange mit sich selbst repliziere, bis die Länge passt. Bei der IBANs könnte man noch die Prüfziffer der Kontonummer berechnen, falls die nachfolgende Software da irgendeine Prüfung drinne hat, die sonst über ungültige IBANs stolpert.
Z.B.: DE47114711471147114711 = DE + KundenID sooft aneinandergehängt, bis mehr als 20 Zeichen entstanden sind und davon dann die ersten 20 Zeichen nehmen.

Bei mir sieht 'ne Test-ISBN so aus: 978-699-2-00000-6.
Wirkt echt, ist sie aber nicht, weil 699 nicht vergeben.

Telefonnummern werden (laut Norm) von rechts nach links zweistellig durch Leerzeichen getrennt. Wir nehmen dann halt die Vorwahl des Ortes + KundenID, ergibt für Peter Meier aus Köln dann "02 21 / 47 11". Naja, wenn wir 'ne Handynummer haben, dann behalten wir die Vorwahl und hängen die Kundennummer dran. Also z. B. "0160 / 47 11". Man könnte auch noch die Auslandsvorwahl davorschreiben, wenn erforderlich ...

Daten so repräsentativ wie nötig mit so wenig Aufwand wie möglich.

Ist eine Abbildung von fehlerhaften Daten (insbesondere in Bezug auf IBAN, Telefonnummern ...) nötig, dann geht's halt nicht so einfach, aber hier würd' ich dann erstmal abklären, ob der "allgemeine Datenerfassungshumbug in den Quelldaten" auch in den Testdaten erforderlich ist.

Also: Muss mit 'nem Peter Meier aus Köln mit der Kundennummer 4711 auch dann noch korrekt umgegangen werden, wenn er auf einmal als Petr Maier aus Cölln mit der Kundennummer 4711 daher kommt. Sind "Besonderheiten" in der Telefonnummer wie z. B. [phone], +49 0160/4711, 01604711, 00491604711 ... auch "originalgetreu" abzubilden?

Fragen über Fragen ... garantiert etwas mehr Arbeit ;-)