Discussion :

[taliane]

Bonjour,

Je suis un peu newbie en Oracle c'est pourquoi je vais essayer de me faire comprendre, je recherche un script, une S.P ou une piste pour me permette de mélanger tout les records de differente table en fonction d'une clé sans casser les relations entre les tables de paramètre et celle de donnée ( sous Oracle 9i )

Exemple:

Table Data Employe
Champ : N° Employe ( clé ) varchar(7) ===> "0034555"
Type EmployeID Smallint ===> "4"
Nom varchar(50) ===> "Oraculus"
Prenom varchar(50) ===> "Gerard"

Table Data Famille
Champ : N° Employe ( clé ) varchar(7) ===> "0034555"
Marié Bit ===> "1"
Nombre Enfant smallint ===> "4"

Table Param Type Employe
Champ : Type EmployeID ( clé ) smallint ===> "4"
Type varchar(50) ===> "Cadre"

L'idée principale étant de mélanger les données afin de faire une copie de la production vers un environement de test et ces informations etant confidentiel, empecher de connaitre la situation réel d'un employé mixant les donnée tel que N° Employe ( clé ), Nom , Prenom . Les contraintes sont que ces données se retrouve sur plusieur table donc redondante et surtout que ne l'on puisse pas reconnaitre quelqu'un. Par contre il faut que cela reste logique .

Voilà j'éspere avoir été clair, sorry pour l'ortho et toute idée est bienvenue

Merci d'avance

[plabrevo]

dbms_obfuscation_toolkit sous 8i et 9i, et dbms_crypto sous 10g, fournissent des routines d'encryption.
L'algorithme de scambling devra, de maniere generale, veiller a ne pas toucher ni les PKs et FKs, ni les donnees correspondants a des lookup codes. Si les libelles ne posent pas de difficulte particuliere, en revanche, le scrambling des montants et des dates est autrement plus complique a realiser si l'on souhaite conserver une coherence globale de l'application.

[laurentschneider]

Il n'y a pas de méthode 100.00% sûre. Par expérience, j'ai développé des algorythme du style

compte : 1234567 ==> compte 7123456 (formule secrète maison, réversible)
Prénom : Abraham - Azalée ==> André, Basile - Bydule ==> Bernard, ...
Nom : A - Azyz ==> Aristote, ...

Un truc fait maison quoi... Il est généralement préférable d'avoir un algorythme non-salé (not salted) permettant de traduire chaque identifiant (clé client) en un nombre unique. La "sécurité" n'est pas absolue, cependante tout à fait acceptable en environnement bancaire. Pour les clients qui testent, il est beaucoup plus sympa d'avoir Tintin Ducon que A%123++#1 B**991

J'espère que mon avis te sera utile

[taliane]

Merci pour vos réponses...

Je vais encore méditer puis me lancer dans des expériences ...

[orafrance]

pourquoi ne pas simplement remplacé les données sensibles par des valeurs complétement bidons : XXXXX ou 99999, la réversibilité n'a aucune importance non ?

[laurentschneider]

En fait, le problème est le suivant.

Si le compte 1234567 donne toujours 7123456, c'est que la fonction est réversible. Il est alors possible de changer le compte dans toutes les tables. Le compte est peut-être utilisé comme clé primaire, et la valeur anonyme pour 1234567 doit être ok dans tous les comptes.

La localité doit par exemple aussi être anonyme. Afin de conserver une certaine cohérence et une certaine conviviabilité, je me plais à utiliser des noms de localités soit existants, soit extra-terrestres ou qu'importe, mais pas tous les clients qui habitent à 12345-XXXXX



Une forme d'anonymisation peut-être plus efficace est en créant une table qui effectue la traduction.