Avis pour DataPrep

Bonjour à tous,

Dernièrement j'ai énormément utilisé du langage SQL et revenant dans l'analyse petit à petit, il m'est (pour moi) 100 fois plus rapide de faire des requetes via SQL pour la Dataprep: analyser les modalités des données (problème de saisie,..), MAJ de certaines valeurs de champ en fonction d'autres etc..

Puis-je continuer ainsi ou il vaut mieux que j'essaye de tout faire via R (les boucles que je fais pour avoir le même résultat sont souvent très longues).
Le package sqldf correspondrait-il à mon besoin ? est-il aussi rapide en terme de performance que d'autres requêtes executables sous R ?

Merci d'avance

Ineedi²

Bonjour,

Pouvez-vous donner un exemple exécutable de vos boucles pour voir si elles sont vraiment nécessaires ?

Cordialement,

Bonjour mgdondon,

Voici un exemple de boucle, je cherche à remplacer les valeurs NULL de la table PremierTest, colonne Item_Weight en fonction d'une autre df ListeProduitPoid en matchant sur l'Item Identifier.

Code:

---

1 2 3 4 5 6

for (i in 1:nrow(PremierTest)){ for (j in 1:nrow(ListeProduitPoids)){ if (is.na(PremierTest$Item_Weight[i])==TRUE && PremierTest$Item_Identifier[i]==ListeProduitPoids$Item_Identifier[j]) {PremierTest$Item_Weight[i]=ListeProduitPoids$Item_Weight[j]} }}

---

Peut-etre que cette boucle est maladroite et qu'il existe un moyen plus rapide, je serais alors preneur.
Typiquement sur SQL ça donnerait du genre:

Code:

---

1 2 3 4 5 6

update PremierTest Set Item_Weight=B.Item_Weight FROM PremierTest A INNER JOIN ListeProduitPoids B ON A.Item_Identifier=B.Item_Identifier

---

Merci

Bonjour Ineed2,

• Vous pouvez mettre à jour les données de la table PremierTest avec celles de la table ListeProduitPoids, équivalent du update de SAS (source).

Code:

---

1 2 3 4 5

> PremierTest <- data.frame(item_identifier=c(1,2,3), + item_weight=c(1,NA,NA)) > > ListeProduitPoids <- data.frame(item_identifier=c(1,2,3), + item_weight=c(2,2,2))

---

Code:

---

1 2 3 4 5 6 7 8

> liste_item <- PremierTest$item_identifier[is.na(PremierTest$item_weight)] > liste_item [1] 2 3 > maj_weight <- ListeProduitPoids[liste_item,] > maj_weight item_identifier item_weight 2 2 2 3 3 2

---

Code:

---

1 2 3 4 5 6 7 8 9

> library(data.table) > Cols <- "item_weight" > iCols <- paste0("i.", Cols) > PremierTest <- setDT(PremierTest)[maj_weight, (Cols) := mget(iCols), on="item_identifier"][] > PremierTest item_identifier item_weight 1: 1 1 2: 2 2 3: 3 2

---

• Si vous utilisez les boucles, les opérations se font en parallèle sur les observations d'une table donc il suffit de faire une boucle sur la deuxième table. Il est préférable de faire la boucle sur la table ayant le moins d'observations, voir ici.

• Pour la performance, vous pouvez comparer les deux méthodes avec le code suivant :

Code:

---

1 2 3 4 5

T1<-Sys.time() # programme T2<-Sys.time() difftime(T2, T1)

---

Cordialement,

Merci, je vais de suite jeter un coup d'oeil.


Ineedi²

Pour ma part, j'ai aussi une préférence pour la préparation des données en SQL. Je regroupe toutes mes actions dans un flux ETL.

Je construis ma table, et je l'importe dans un data.frame sur R, comme suit :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

library("RJDBC")   drv <- JDBC("oracle.jdbc.driver.OracleDriver", classPath="D:/Drivers/ojdbc6.jar", " ")   con <- dbConnect(drv, "jdbc:oracle:thin:@server:port:database", "user", "mdp")   ##### GET DATA ON R #####   dta <- dbGetQuery(con," SELECT NO_CLIENT , LIB_CLIENT , NO_ARTICLE , DESC_ARTICLE , DATE_COMMANDE , TOP_LST_APPEL , QTE_COMMANDE , PREV_QTE_COMMANDE , JRS_SINCE_PREV_COMMANDE , SAM_DIM_OU_JF , TOP_COMMANDE FROM DATA_TEST.LST_COMMANDES " )   ####### Disconnetion #######   dbDisconnect(con) rm(drv) rm(con)

---

Et derrière je fais mes as.factor, mes as.date, mes subset pour la cross-validation, etc...

Je suis sur Oracle, mais j'utilise le package RJDBC, donc ça marche avec n'importe quelle base tant qu'il y a le driver correspondant.

Je n'ai pas la prétention que c'est la meilleure façon de faire, mais c'est clair que je maîtrise beaucoup mieux les fonctions analytiques en SQL, surtout pour la construction de features.
Je prendrais davantage de temps à le faire en R.

Merci pour vos contributions, je vous souhaite une bonne semaine