Daniel Valente, PhD, JMP Chef de produit senior, SAS
Jon Weisz , vice-président des ventes et du marketing de JMP, SAS
Abstrait
JMP 13 introduit deux nouveaux outils qui simplifient la gestion des problèmes de données courants par les analystes. Souvent, deux tables de données ou plus sont liées par une clé commune, mais elles présentent des différences importantes en termes de fréquence d'échantillonnage des faits ou de dimensions (par exemple, longueur ou largeur). Une jointure réelle de ces deux tables (ou plus) peut générer une table résultante très volumineuse en mémoire. Bien que cela soit gênant lorsque les tables de faits et de dimensions sont relativement compactes, cela peut rapidement générer une table jointe trop volumineuse pour la mémoire. La solution consiste à utiliser une jointure virtuelle, qui préserve la relation de jointure sans créer la table jointe, enrichissant ainsi la table de faits sans la surcharger. Les analystes sont souvent amenés à réaliser des jointures ou des résumés complexes en base de données et à écrire du code SQL, ce qui engendre des difficultés, notamment lorsque les relations sont complexes, comme des dimensions à évolution lente. JMP Query Builder est un outil simple de génération et d'écriture de code SQL, dont le code peut ensuite être exécuté dans une base de données. Après avoir glissé et déposé la requête correcte et souhaitée, Query Builder écrit automatiquement le code SQL pour vous, évitant ainsi un travail manuel fastidieux et sujet aux erreurs.
Présentation des structures de tables relationnelles
Les analystes ont besoin de données sous une forme comportant des variables en colonnes et des observations en lignes. Les données peuvent également nécessiter des colonnes catégorielles permettant de sous-regrouper clairement les observations (par exemple, niveau de revenu, pays, machine, etc.). Elles peuvent également comporter des attributs qui éclairent davantage les observations (par exemple, adresse, numéro de série, identifiant client, etc.).
Les données sources de ces analyses sont souvent des structures de données relationnelles stockées dans des bases de données. De nombreux cursus modernes en science des données abordent des sujets liés aux structures de données relationnelles, aux bases de données et à SQL. Cependant, la plupart des ingénieurs, scientifiques et statisticiens ne sont pas exposés à ces sujets dans un cadre universitaire ; ils doivent donc les acquérir dans le cadre d'une formation continue et informelle. JMP Query Builder offre aux analystes un pont entre les structures de données relationnelles et les données prêtes à l'analyse. En maîtrisant quelques termes et concepts, les analystes peuvent utiliser Query Builder pour générer des données prêtes à l'analyse.
La brève discussion sur les structures de données relationnelles dans cet article n'est pas destinée à remplacer une étude approfondie du sujet ; elle présente plutôt les termes et définitions utilisés lors de l'utilisation de Query Builder et de ses capacités de jointure virtuelle dans JMP.
Pourquoi avoir plus d’une table pour stocker des données importantes ?
Imaginez que vous deviez concevoir un moyen de stocker les données relatives aux achats de produits de votre entreprise par vos clients. Vous pourriez commencer par lister toutes les variables à collecter, telles que :
- Date d'achat
- Montant de l'achat
- Méthode d'achat (PO ou CC)
- Référence du produit
- Description du produit
- Nom du client
- Adresse du client
- Numéro de téléphone du client
Cette liste n'est certes pas exhaustive, mais c'est un bon début. Pensez maintenant à gérer ces données. Ce tableau comportera huit colonnes et une ligne pour chaque achat. Certains champs peuvent contenir de nombreuses valeurs distinctes, comme le montant ou la date d'achat. D'autres champs en auront beaucoup moins et de nombreuses valeurs répétées, comme le SKU et la description du produit.
Une méthode courante pour réduire la taille d'une table consiste à la diviser en trois groupes logiques. La première contient les transactions ou les faits , tels que la date et le montant d'achat. La deuxième table contient les informations client et la troisième les informations produit. Pour maintenir les liens entre les colonnes de données, il est nécessaire d'ajouter une colonne contenant les informations de lien reliant les trois tables. Ces colonnes sont appelées clés . Une méthode courante pour représenter cette disposition est d'utiliser un diagramme entité-relation (ER) . Chaque entité possède un nom de table, une clé ou un ensemble de clés identifiant chaque ligne de manière unique, et un ensemble d'attributs ou de variables fournissant des informations sur chaque ligne. Le diagramme ER pour la date d'achat client est illustré à la figure 1.
Figure 1. Diagramme entité-relation pour les données d'achat des clients
Le symbole de clé à côté de l'ID client dans la table de dimension Clients signifie que si vous connaissez un ID client, vous pouvez le retrouver de manière unique dans la table et toutes les informations associées. L'ID client figure également dans la table de faits Achats. Lorsqu'il figure dans cette table, l'ID client est appelé clé étrangère, car il peut apparaître plusieurs fois et définit de manière unique les lignes d'une table étrangère par rapport à celle dans laquelle il apparaît.
Grâce à la présentation de la figure 1, il est très facile de comprendre comment mettre à jour une description de produit. Pour ce faire, il suffit de modifier la table « Dimensions du produit » : cette modification s'applique à tous les achats effectués, un avantage appelé « maintenabilité » . S'il s'agissait d'une seule table avec la description du produit répétée plusieurs fois, il faudrait modifier de nombreuses lignes, ce qui entraînerait inévitablement des erreurs et des problèmes de qualité des données.
Cas 1 : Enquête sur la population actuelle
Prenons maintenant un exemple avec Query Builder. Le gouvernement américain collecte de nombreuses données intéressantes grâce à l'Enquête sur la population actuelle (CPS) [USGCPS]. L'enquête CPS est :
“L'Enquête sur la population active (CPS) est l'une des enquêtes les plus anciennes, les plus vastes et les plus reconnues des États-Unis. Son importance est immense : elle fournit des informations sur de nombreux éléments qui nous définissent en tant qu'individus et en tant que société : notre travail, nos revenus et notre éducation. En plus d'être la principale source de statistiques mensuelles sur la population active, la CPS est utilisée pour collecter des données pour diverses autres études qui informent le pays sur le bien-être économique et social de sa population. Pour ce faire, des questions supplémentaires sont ajoutées aux questions mensuelles de base de la CPS. Ces questions supplémentaires varient d'un mois à l'autre et couvrent un large éventail de sujets tels que les pensions alimentaires pour enfants, le bénévolat, la couverture maladie et la scolarisation. Les enquêtes supplémentaires sont généralement menées annuellement ou semestriellement, mais leur fréquence et leur récurrence dépendent entièrement de ce qui répond le mieux aux besoins de leur commanditaire.
Ces données sont téléchargeables sous forme de 36 fichiers texte, facilement ouvrables dans JMP grâce à leur délimiteur de tabulations. L'analyse des tables JMP a permis de créer un diagramme ER (figure 2) pour éclairer le travail dans le générateur de requêtes.
Figure 2. Diagramme ER pour les tableaux de données sur la population active du CPS
Pour utiliser le générateur de requêtes, vous devrez définir une table principale (fait) et une ou plusieurs tables secondaires (dimension ).
La table de faits pour les données CPS est appeléeAllData.jmpLe tableau comporte plus de 5 millions de lignes, mais seulement cinq colonnes. Ces colonnes contiennent une colonne « series_id », des dates et une colonne « value ». Pour comprendre les données, il faut déterminer ce queseries_id.jmp signifie. Le diagramme ER de la figure 2 montre que « series_id » est lié àsérie.jmptable. Ensuite, ouvrez ces deux tables dans JMP et utilisez le générateur de requêtes pour définir la jointure.
Dans JMP, sélectionnezAllData.jmpcomme la table principale (fait) etsérie.jmpcomme table secondaire (dimension) (Figure 3). JMP recherchera automatiquement les clés correspondantes et établira la jointure. Pour vérifier, cliquez sur le diagramme de Venn à droite de la table des séries. Le générateur de requêtes a trouvé des « footnote_codes » dans les deux tables, mais vous ne souhaitez pas utiliser ces clés comme jointure, mais uniquement le « series_id ». Cette relation de clé doit donc être supprimée.
Figure 3. Générateur de requêtes pour la jointure deAllData.jmpetSérie.jmp
Vous devez maintenant définir les colonnes de la table jointe (Figure 4). Pour cela, sélectionnezAllData.jmpen haut à gauche et sélectionnez les colonnes nécessaires dans cette table. Supprimez « series_id » maintenant, car vous n'aurez pas besoin de cette clé dans la table résultante (séries et données.jmp).
Figure 4. Générateur de requêtes pour rejoindreséries et données.jmpà tous «_code.jmp"tables
Notez queséries et données.jmpest environ cinq fois plus grand que leAllData.jmpTable. Cette augmentation est due aux valeurs répétées de tous les champs « _code ». Le stockage des données dans 36 tables réduit donc considérablement les besoins de stockage . Ensuite, sélectionnezséries et données.jmp comme la table principale et toutes les« _code.jmp« tables comme tables secondaires (Figure 5).
Figure 5. Générateur de requêtes pour joindre tous les «_code.jmp”
Créez la requête avec uniquement les champs « _text » des tables « _code », car vous n'avez plus besoin des variables clés. Grâce à la visionneuse « Colonnes > Colonnes » de JMP, vous pouvez facilement obtenir un résumé des 42 colonnes de la table.Join.jmp complet.Vous aurez toujours 5,7 millions de lignes, ce qui est la même chose queAllData.jmp, mais vous disposez désormais des champs de texte qui décrivent les données. Même si le tableauJoindre complètement.jmpest toujours six fois plus grand que la tableToutes les données.jmp,vous disposez désormais d'un tableau utile à l'analyse.
Utilisez Graph Builder pour tracer la tendance du chômage dans le secteur manufacturier à partir deJoindre complètement.jmpLa figure 6 illustre les perturbations subies par ce secteur pendant la récession par la ligne de tendance rouge. En 2016, le chômage est revenu aux niveaux observés en 2006-2007. La ligne de tendance verte indique les niveaux d'emploi dans le secteur automobile. Plus de 300 000 emplois ont été créés dans ce secteur entre 2010 et 2015.
Figure 6. Générateur de graphiques affichant les données des statistiques sur la population active du CPS
Cas 2 : Données d'inspection des restaurants
Cette étude explore l'utilisation de la jointure virtuelle et du générateur de requêtes JMP pour analyser les résultats de l'inspection des restaurants de la ville de New York par le DOHMH.[DOHMH]Imaginez-vous en tant que nouvel inspecteur en poste, explorant des données historiques pour en comprendre les conséquences. Extrait du site web.https://data.cityofnewyork.us/Health/DOHMH-New-York-City-Restaurant-Inspection-Results/xx67-kt59Vous pouvez télécharger une version .csv de ces données, facilement ouvrable dans JMP. Le téléchargement complet, effectué le 17 juillet 2016, génère un fichier de 163,3 Mo contenant 448 149 enregistrements.
Ces données comportent une colonne DATE D'INSPECTION, correspondant à la date de l'inspection (J/M/A). Pour connaître le nombre d'années incluses dans ces données, faites un clic droit et sélectionnez « Nouvelle colonne de formule > Date et heure > Année ». La conversion de cette valeur de continue à nominale, puis « Analyser > Distribution », est illustrée à la figure 7. Le niveau 1900 correspond probablement à un code de données manquantes, un problème que vous devrez résoudre. La modification destructive de ces données ne pose aucun problème (JMP étant utilisé comme sandbox et les données réelles étant toujours stockées sur le serveur). Utilisez ensuite l'utilitaire Recode pour modifier ces niveaux comme manquants.
Figure 7. Dates d'inspection pour l'ensemble des données
Dans la fenêtre de recodage, 1 151 enregistrements sont datés du 01/01/1900. Modifiez cette ancienne valeur en « • » en supprimant la chaîne, puis en cliquant sur Terminé -> En place. La DATE D'ENREGISTREMENT étant la date d'extraction des données et n'étant pas pertinente pour cette analyse, supprimez la colonne.
Cet article porte sur la jointure virtuelle et le générateur de requêtes. Vous vous demandez peut-être pourquoi nous étudions une table dénormalisée. Il semble possible de normaliser ces données. L'emplacement géocodé de chaque restaurant est particulièrement absent de ces données brutes, une tâche qui peut être réalisée ultérieurement avec un module complémentaire JMP. Ce processus étant coûteux en calculs, il est judicieux de ne géocoder que les emplacements uniques, susceptibles de faire l'objet de plusieurs inspections. De plus, il semble possible de disposer d'une table supplémentaire de violations, bien moins nombreuses que les inspections uniques.
Avant de diviser les données, prenez un échantillon de ces données afin que les nombres soient plus faciles à gérer pour votre exercice d’exploration.
L'échantillonnage est facile à réaliser avec le Générateur de requêtes. Tables > Générateur de requêtes JMP ouvrira la boîte de dialogue de lancement. Comme vous n'effectuez pas de jointure dans ce cas, utilisezDOHMH_New_York_City_Restaurant_Inspection_Results.jmpComme table principale, sans tables secondaires pour le moment. Dans le Générateur de requêtes, un onglet « Échantillon » est disponible. En cochant la case « Échantillonner cet ensemble de résultats », vous pouvez choisir les N premières lignes ou les N lignes aléatoires. Prenez un échantillon aléatoire de 10 % de ces données, et placez 44 815 lignes dans les N lignes aléatoires. Ajoutez toutes les colonnes à la section « Inclure les colonnes », puis examinez le code SQL. Le Générateur de requêtes a généré automatiquement le code SQL pour exécuter cette requête :
SÉLECTIONNEZ t1.CAMIS, t1.DBA, t1.BORO, t1.BUILDING,
t1.RUE, t1.CODE POSTAL, t1.TÉLÉPHONE, t1."DESCRIPTION DE LA CUISINE",
t1."DATE D'INSPECTION", t1."ACTION", t1."CODE D'INFRACTION", t1."DESCRIPTION DE L'INFRACTION",
t1."DRAPEAU CRITIQUE", t1.SCORE, t1.NOTE, t1."DATE DE LA NOTE",
t1."TYPE D'INSPECTION", t1."Année[DATE D'INSPECTION]"
Résultats de l'inspection des restaurants de la ville de New York (DOHMH) t1
ORDONNANCE PAR RANDOM() LIMITE 44815 ;
Après utilisationl'ordre aléatoire () Pour notre échantillonnage, cette requête générera le sous-ensemble de données approprié. Enregistrez-le comme sous-ensemble, puis séparez les données démographiques et les codes d'infraction du restaurant. Le Générateur de requêtes peut également être utilisé ici. Commencez par les codes d'infraction. Là encore, une table principale suffit. Glissez-déposez le CODE D'INFRACTION et la DESCRIPTION DE L'INFRACTION dans la liste des variables, puis faites glisser à nouveau le CODE D'INFRACTION. Cela vous permettra d'agréger par nombre et de générer la table avec les propriétés souhaitées. Modifiez le nom JMP de la colonne d'agrégation en NOMBRE D'INFRACTIONS. La possibilité de générer un alias vers une colonne ou une colonne dérivée est une fonctionnalité puissante du Générateur de requêtes. Vous pouvez également choisir de trier automatiquement selon la colonne agrégée nouvellement créée en faisant glisser le NOMBRE D'INFRACTIONS vers le rôle Trier par, comme illustré à la figure 8.
Figure 8. Colonne d'agrégation renommée Nombre de violations, avec une propriété Trier par
Avec seulement 88 codes d'infraction uniques, la requête résultante est beaucoup plus compacte. Après avoir nommé cette table Codes de violation D.jmp , utilisez le générateur de graphiques pour identifier les codes contenant le plus d'enregistrements. Faites glisser la description de l'infraction sur l'axe des abscisses et le nombre d'infractions sur l'axe des ordonnées. Cliquez ensuite avec le bouton droit sur la description de l'infraction et triez par nombre d'infractions (décroissant). Pour vous concentrer uniquement sur les catégories principales, vous pouvez utiliser le filtre Données locales sur le nombre d'infractions avec les catégories d'infractions contenant plus de 2 500 enregistrements uniques (Figure 9).
Figure 9. Nombre de violations les plus fréquentes (> 2 500 enregistrements uniques dans la table échantillonnée)
Pour l'instant, abandonnez la table des infractions et concentrez-vous sur les données démographiques spécifiques au restaurant. Vous pouvez également supprimer la description de l'infraction, ce qui évite de nombreuses lignes en double dans la table de faits principale. Utilisez le CODE D'INFRACTION, une méthode beaucoup plus compacte pour organiser ces données (chaînes de trois lettres plutôt que de longues phrases).
Utilisez à nouveau le Générateur de requêtes pour extraire les données démographiques spécifiques aux restaurants. Il est fort probable qu'il existe plusieurs pizzerias du même nom à New York, mais le Générateur de requêtes peut gérer cette situation. La colonne CAMIS sert d'identifiant permettant d'identifier des restaurants uniques. Dans le Générateur de requêtes, glissez deux fois la colonne CAMIS : l'une d'elles doit être agrégée par nombre et renommée NOMBRE D'INSPECTIONS. Les autres données démographiques sont : DBA, BORO, BUILDING, STREET, ZIPCODE, PHONE et CUISINE DESCRIPTION. Enfin, calculez une colonne intitulée ADDRESS pour le géocodeur, ce qui sera effectué via un script post-requête. Exécutez la requête, puis utilisez une colonne de formule avec la formule suivante :
:BÂTIMENT ||" "|| :RUE ||" "|| :BORO ||"NEW YORK,"||Carboniser( :CODE POSTAL )
Cette formule permet de trouver l'adresse correcte. Saisie:ADRESSE <<obtenir le script; Dans un éditeur de script, vous produirez le JSL nécessaire à la génération de la colonne pour un script post-requête. Copiez-collez ce code dans l'onglet approprié du Générateur de requêtes, puis générez une colonne qui divisera les données en 20 groupes pour une meilleure interface avec le géocode. Après avoir généré une nouvelle colonne intitulée « Grouper et initialiser les données : Séquencer les données, De 1 à 20, Étape 1, Répéter 1 », vous pouvez récupérer le script et le coller dans le script post-requête. Maintenant que les deux colonnes sont des scripts, vous pouvez supprimer la table de requête et relancer la requête. Enregistrez cette table de données sousD-Restaurants.jmp. En guise d'étape finale, supprimez les colonnes supplémentaires de la table désormais factuelle, notamment : DBA, BORO, BUILDING, STREET, ZIPCODE, PHONE et CUISINE DESCRIPTION.
Enregistrer ce tableau sous F-Inspections.jmp. Vous êtes maintenant prêt à géocoder les groupes de restaurants grâce à un module complémentaire créé par Xan Gregg, disponible sur JMP File Exchange [GREGG], qui utilise OpenStreetMaps.org pour géocoder les emplacements. Ce service est coûteux en calcul et sujet aux pannes ; il est donc préférable de le scinder.D-Restaurants Par groupe en utilisant Tables > Sous-ensemble. La fonctionnalité « Sous-ensemble par » de cette plateforme, illustrée à la figure 10, est utile ici.
Figure 10. Plateforme de tables de sous-ensembles pour la répartition par groupe de restaurants
Les 20 tables nouvellement créées peuvent être géocodées individuellement grâce au module complémentaire. Le champ d'adresse permet de déterminer la latitude et la longitude correctes. Enfin, enregistrez les résultats dans la même table de données.
Pour ramener la table de données à une table à dimension unique avec des emplacements, utilisez la fonction Tables > Concaténer, en combinant les 20 groupes ; elle est nommée D-RestaurantswLocation.jmp.
Maintenant que vous avez décomposé cette table à l'aide du Générateur de requêtes, vous pouvez la reconstruire à l'aide d'une jointure virtuelle.
Tout d’abord, commençons par nos deux tableaux de dimensions : Restaurants-wLocation.jmp etCodes de violation.jmp. Un clic droit sur le CODE D'INFRACTION et la sélection de l'ID de lien permettent de configurer le début de la jointure virtuelle. Une petite icône en forme de clé apparaît dans la liste des colonnes. Accédez à la table Restaurants et faites de même avec la table CAMIS. Pour finaliser la jointure virtuelle, accédez à la table de faits contenant toutes les inspections, puis sélectionnez Référence de lien pour la table CAMIS et le CODE D'INFRACTION.
Toutes les colonnes apparaissent dans la table de faits sans qu'il soit nécessaire de joindre physiquement les tables en mémoire. La jointure virtuelle peut également être scriptée via une propriété de colonne :
Pour la référence du lien :
Définir la propriété("Référence de lien", Table de référence("D(f)-Restaurants-wLocation.jmp"));
Pour l'ID du lien :
Définir la propriété (« ID de lien », 1) ;
Figure 11. Jointure virtuelle
La figure 11 montre que vous avez accès aux colonnes des deux tables de dimension sans surcharger la table de faits.
Enfin, créez un tableau de bord pour visualiser et explorer ces données en exploitant les colonnes virtuellement jointes.
La figure 12 montre comment Dashboard Builder affiche un ensemble de cinq graphiques. Pour utiliser deux de ces graphiques comme filtres de sélection, commencez par le modèle de filtre hiérarchique de Dashboard Builder, en utilisant l'indicateur critique et BORO comme filtre et filtre hiérarchique. Ensuite, utilisez un graphique du nombre de notes, le score moyen par quantile sur une carte et, enfin, une carte thermique du nombre de dates par type d'inspection.
Figure 12. Mode Générateur de tableau de bord d'Application Builder avec tableau de bord d'inspection final de NYC
Ceci n'est qu'un exemple du type de visualisation que vous pouvez réaliser avec ces données, en exploitant les tables liées offertes par la jointure virtuelle. Les données géocodées permettent également, par exemple, d'explorer la localisation des restaurants par type de cuisine (Figure 13).
Figure 13. Restaurants géocodés colorés par niveau affichés sur une carte au niveau de la rue
Génération et déploiement SQL
Un autre avantage majeur du Générateur de requêtes est la génération de langage SQL (Structured Query Language). SAS peut utiliser SQL dans Proc SQL, et la plupart des bases de données utilisent SQL comme langage de programmation pour joindre et gérer les tables. Le SQL peut être généré à partir d'une requête définie dans l'interface pointer-cliquer du Générateur de requêtes.
Vous trouverez ci-dessous le SQL créé par Query Builder pour la jointure de toutes les tables de dimension à la table jointe desérie.jmpetAllData.jmp(du cas 1) et le SQL de la jointure deJoindre complètement.jmpet tous les_code.jmptables. Lenom de la bibliothèquedéclaration, références libname associées sur les tables et leprocédure SQL Des instructions ont été ajoutées. Le reste du code a été généré par Query Builder.
Notez que la majeure partie du code consiste en une liste des colonnes des instructions SELECT. Utiliser le Générateur de requêtes pour générer ce code est très utile, même si l'utilisateur maîtrise SQL. Pourquoi saisir autant de noms de tables et de colonnes si ce n'est pas nécessaire ?
nom de la bibliothèque source « l'emplacement de votre fichier »;
procédure SQL;
créer tableausource.dataNseriescomme
SÉLECTIONNERt1.année, t1.période, t1.valeur, t1.codes_notes_de_bas_de_page,
t2.lfst_code, t2.periodicity_code, t2.series_title, t2.absn_code,
t2.code_activité, t2.code_âges, t2.code_classe, t2.code_durée,
t2.education_code, t2.entr_code, t2.expr_code, t2.hheader_code,
t2.hour_code, t2.indy_code, t2.jdes_code, t2.look_code,
t2.mari_code, t2.mjhs_code, t2.occupation_code, t2.orig_code,
t2.pcts_code, t2.race_code, t2.rjnw_code, t2.rnlf_code,
t2.rwns_code, t2.seek_code, t2.sexs_code, t2.tdat_code,
t2.code_vétérinaires, t2.code_semaine, t2.code_naissance, t2.code_enfant,
t2.disa_code, t2.saisonnier, t2.footnote_codes, t2.begin_year,
t2.début_période, t2.fin_année, t2.fin_périodeDEPUISsource.AllData t1
GAUCHEJOINTURE EXTERNE source.series t2
SUR ( t1.series_id = t2.series_id ) ;
SÉLECTIONNERt1.année, t1.période, t1.valeur, t1.titre_série,
t1.saisonnier, t1.début_année, t1.début_période, t1.fin_année,
t1.fin_période, t13.texte_note_de_bas_de_page, t34.texte_semaine, t33.texte_vétérinaires,
t32.tdat_texte, t31.sexs_texte, t30.seek_texte, t29.rwns_texte,
t28.rnlf_text, t27.RJNW_TEXT, t26.race_text, t25.periodicity_text,
t24.pcts_text, t23.orig_text, t22.occupation_text, t21.mjhs_text,
t20.mari_text, t19.look_text, t18.lfst_text, t17.jdes_text,
t16.indy_text, t15.hour_text, t14.hheader_text, t12.expr_text,
t11.entr_text, t10.education_text, t9.duration_text, t8.disa_text,
t7.texte_classe, t6.texte_enfant, t5.texte_né, t4.texte_âge,
t3.activity_text, t2.absn_textDEPUISsource.dataNseries t1
GAUCHEJOINTURE EXTERNE source.footnote t13
SUR ( t1.footnote_codes = t13.footnote_code )
GAUCHEJOINTURE EXTERNE source.wkst t34
SUR ( t34.wkst_code = t1.wkst_code )
GAUCHEJOINTURE EXTERNE source.vets t33
SUR ( t33.vets_code = t1.vets_code )
GAUCHEJOINTURE EXTERNE source.tdat t32
SUR ( t32.tdat_code = t1.tdat_code )
GAUCHEJOINTURE EXTERNE source.sexs t31
SUR ( t31.sexs_code = t1.sexs_code )
GAUCHEJOINTURE EXTERNE source.seek t30
SUR ( t30.seek_code = t1.seek_code )
GAUCHEJOINTURE EXTERNE source.rwns t29
SUR ( t29.rwns_code = t1.rwns_code )
GAUCHEJOINTURE EXTERNE source.rnlf t28
SUR ( t28.rnlf_code = t1.rnlf_code )
GAUCHEJOINTURE EXTERNE source.rjnw t27
SUR ( t27.RJNW_CODE = t1.rjnw_code )
GAUCHEJOINTURE EXTERNE source.race t26
SUR ( t26.race_code = t1.race_code )
GAUCHEJOINTURE EXTERNE source.périodicité t25
SUR ( t25.periodicity_code = t1.periodicity_code )
GAUCHEJOINTURE EXTERNE source.pcts t24
SUR ( t24.pcts_code = t1.pcts_code )
GAUCHEJOINTURE EXTERNE source.orig t23
SUR ( t23.orig_code = t1.orig_code )
GAUCHEJOINTURE EXTERNE source.occupation t22
SUR ( t22.occupation_code = t1.occupation_code )
GAUCHEJOINTURE EXTERNE source.mjhs t21
SUR ( t21.mjhs_code = t1.mjhs_code )
GAUCHEJOINTURE EXTERNE source.mari t20
ON ( t20.mari_code = t1.mari_code )
GAUCHEJOINTURE EXTERNE source.look t19
SUR ( t19.look_code = t1.look_code )
GAUCHEJOINTURE EXTERNE source.lfst t18
SUR ( t18.lfst_code = t1.lfst_code )
GAUCHEJOINTURE EXTERNE source.jdes t17
SUR ( t17.jdes_code = t1.jdes_code )
GAUCHEJOINTURE EXTERNE source.indy t16
SUR ( t16.indy_code = t1.indy_code )
GAUCHEJOINTURE EXTERNE source.heure t15
SUR ( t15.hour_code = t1.hour_code )
GAUCHEJOINTURE EXTERNE source.hheader t14
SUR ( t14.hheader_code = t1.hheader_code )
GAUCHEJOINTURE EXTERNE source.expr t12
SUR ( t12.expr_code = t1.expr_code )
GAUCHEJOINTURE EXTERNE source.entr t11
SUR ( t11.entr_code = t1.entr_code )
GAUCHEJOINTURE EXTERNE source.education t10
SUR ( t10.education_code = t1.education_code )
GAUCHEJOINTURE EXTERNE source.duration t9
SUR ( t9.duration_code = t1.duration_code )
GAUCHEJOINTURE EXTERNE source.disa t8
SUR ( t8.disa_code = t1.disa_code )
GAUCHEJOINTURE EXTERNE source.class t7
SUR ( t7.class_code = t1.class_code )
GAUCHEJOINTURE EXTERNE source.chld t6
SUR ( t6.chld_code = t1.chld_code )
GAUCHEJOINTURE EXTERNE source.born t5
SUR ( t5.born_code = t1.born_code )
GAUCHEJOINTURE EXTERNE source.ages t4
SUR ( t4.ages_code = t1.ages_code )
GAUCHEJOINTURE EXTERNE source.activité t3
SUR ( t3.activity_code = t1.activity_code )
GAUCHEJOINTURE EXTERNE source.absn t2
SUR ( t1.absn_code = t2.absn_code );
quitter;
Résumé
Les analystes ont besoin de données rassemblées dans un seul tableau, organisées de manière à permettre la visualisation et l'analyse. Cependant, les données sont souvent organisées pour être chargées, maintenues et stockées dans de nombreuses tables (normalisées) de sorte que les analystes sont mis au défi de joindre et de résumer de nombreuses tables en une seule table prête à être analysée.
Le générateur de requêtes JMP est un outil puissant pour joindre plusieurs tables depuis JMP. La fonction d'aperçu permet de vérifier si la jointure est correctement définie avant d'exécuter une opération fastidieuse. Le code SQL généré peut être déployé dans SAS ou une base de données, ce qui permet de gagner un temps considérable par rapport à l'écriture manuelle de ce code.
Références
[UGSCPS] Statistiques sur la population active – Enquête sur la population active – CPS. Consulté le 18 août 2016.http://www.bls.gov/cps/data.htm.
[DOHMH] Résultats de l'inspection des restaurants de New York par le DOHMH. Consulté le 17 août 2016.https://data.cityofnewyork.us/Health/DOHMH-New-York-City-Restaurant-Inspection-Results/xx67-kt59.
[GREGG]Gregg, X. (28 mai 2014). Géocodage des noms de lieux. Consulté le 18 août 2016.https://community.jmp.com/docs/DOC-6175.
