Contexte Métier
Un data scientist tente de nettoyer une table issue d'une source de données non fiable. Il veut effectuer plusieurs opérations complexes simultanément. Ce scénario teste la robustesse de l'action `alterTable` en lui fournissant des instructions contradictoires ou erronées, afin de vérifier que les messages d'erreur sont clairs et que l'action ne corrompt pas les données.
À propos du Set : table
Chargement, sauvegarde et gestion des tables en mémoire.
Découvrir toutes les actions de table Préparation des Données
Création d'une table 'LEGACY_DATA' avec des noms de colonnes incohérents.
Copié !
| 1 | DATA casuser.LEGACY_DATA; |
| 2 | LENGTH id_op $8 status_code $4; |
| 3 | INPUT id_op $ amount_eur status_code $; |
| 4 | DATALINES; |
| 5 | OP001 1000 OK |
| 6 | OP002 2500 ERR |
| 7 | OP003 . OK |
| 8 | ; |
| 9 | RUN; |
Étapes de réalisation
1
Tentative 1 : Appel contradictoire en essayant de renommer et supprimer la même colonne ('status_code') dans un seul appel.
Copié !
| 1 | PROC CAS; |
| 2 | TABLE.alterTable / |
| 3 | caslib="casuser", |
| 4 | name="LEGACY_DATA", |
| 5 | columns=[{name="status_code", rename="StatusCode"}], |
| 6 | drop={"status_code"}; |
| 7 | RUN; |
| 8 | QUIT; |
2
Tentative 2 : Appel erroné en spécifiant une colonne inexistante dans le paramètre `columnOrder`.
Copié !
| 1 | PROC CAS; |
| 2 | TABLE.alterTable / |
| 3 | caslib="casuser", |
| 4 | name="LEGACY_DATA", |
| 5 | columnOrder={"id_op", "colonne_inexistante", "amount_eur"}; |
| 6 | RUN; |
| 7 | QUIT; |
3
Tentative 3 : Appel valide et complexe après avoir compris les erreurs précédentes, pour corriger la table.
Copié !
| 1 | PROC CAS; |
| 2 | TABLE.alterTable / |
| 3 | caslib="casuser", |
| 4 | name="LEGACY_DATA", |
| 5 | rename="OPERATIONS_FINANCIERES", |
| 6 | label="Opérations financières nettoyées", |
| 7 | columns=[ |
| 8 | {name="id_op", rename="ID_Operation"}, |
| 9 | {name="amount_eur", rename="Montant_EUR", FORMAT="COMMA10."} |
| 10 | ], |
| 11 | drop={"status_code"}; |
| 12 | RUN; |
| 13 | QUIT; |
Résultat Attendu
L'étape 1 doit échouer ou se comporter de manière prévisible (par exemple, la suppression a priorité sur le renommage). Le log SAS doit contenir un AVERTISSEMENT ou une ERREUR claire expliquant le conflit. L'étape 2 doit échouer avec une ERREUR explicite indiquant que 'colonne_inexistante' n'a pas été trouvée dans la table. L'étape 3 doit réussir. La table 'LEGACY_DATA' est renommée, la colonne 'status_code' est supprimée, et les autres colonnes sont renommées et formatées correctement. Ce scénario valide la gestion des erreurs de l'action.