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 permettent à l'analyste de traiter facilement les problèmes de données courants. Souvent, deux tableaux de données ou plus sont liés par une clé commune, mais ils sont très différents en termes de fréquence d'échantillonnage des faits ou de dimensions (par exemple, long par rapport à large). Faire une jointure réelle de ces deux tables (ou plus) peut créer une table résultante qui devient 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 générer rapidement une table jointe trop volumineuse pour tenir en mémoire. La solution consiste à utiliser une jointure virtuelle, qui préserve la relation jointe sans créer réellement la table jointe - enrichissant efficacement la table de faits sans la surcharger. Les analystes ont souvent besoin de faire des jointures ou des résumés de tables complexes dans la base de données et d'écrire du SQL, ce qui crée leur propre ensemble de difficultés, en particulier lorsqu'il existe des relations complexes telles que 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. Une fois que vous avez fait glisser et déposé la requête correcte et souhaitable, Query Builder écrit automatiquement le code SQL pour vous, évitant ainsi le besoin d'un travail manuel fastidieux et sujet aux erreurs.
Présentation des structures de table relationnelles
Les analystes ont besoin de données sous une forme comportant des variables dans des colonnes et des observations dans des lignes. Les données peuvent également nécessiter des colonnes catégorielles qui sous-groupent clairement les observations (par exemple, niveau de revenu, pays, machine, etc.). Les données peuvent également avoir des attributs qui éclairent davantage les observations (par exemple, adresse, numéro de série, ID client, etc.).
Souvent, les données sources pour une telle analyse sont des structures de données relationnelles stockées dans des bases de données. De nombreux programmes d'études modernes en science des données couvrent des sujets liés aux structures de données relationnelles, aux bases de données et à SQL. Mais la plupart des ingénieurs, scientifiques et statisticiens ne sont pas exposés à ces sujets dans un cadre universitaire, ils doivent donc les apprendre 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 pour l'analyse. En apprenant quelques termes et concepts, les analystes peuvent utiliser Query Builder pour générer des données prêtes à être analysées.
La brève discussion des structures de données relationnelles dans cet article n'est pas destinée à remplacer une étude approfondie du sujet ; il présente plutôt les termes et définitions utilisés lors de l'utilisation de Query Builder et de ses fonctionnalité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 des données sur les achats de produits de votre entreprise par les clients. Vous pouvez commencer par répertorier toutes les variables qu'il peut être nécessaire de collecter, telles que :
- date d'achat
- Montant des achats
- 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 certainement pas exhaustive, mais c'est un bon début. Pensez maintenant à maintenir ces données. Ce tableau aura huit colonnes et une ligne pour chaque achat. Certains champs peuvent avoir plusieurs valeurs distinctes, comme le montant de l'achat ou la date d'achat. D'autres champs auront beaucoup moins de valeurs distinctes et de nombreuses valeurs répétées, comme Product SKU et Description.
Une manière courante de réduire la taille du tableau consiste à diviser le tableau en trois groupes logiques. Le premier est le tableau contenant les transactions ou faits , comme la date d'achat et le montant de l'achat. La deuxième table contiendrait les informations sur les clients et la troisième les informations sur les produits. Pour maintenir les liens entre les colonnes de données, une colonne avec des informations de lien devrait être ajoutée pour relier les trois tables. Ces colonnes sont appelées clés . Une façon courante de montrer cette mise en page est d'employer un diagramme de relation d'entité (ER) . Chaque entité a un nom de table, une clé ou un ensemble de clés qui identifient de manière unique chaque ligne, et un ensemble d'attributs ou de variables qui donnent des informations sur chaque ligne. Le diagramme ER pour la date d'achat du client est illustré à la figure 1.
Figure 1. Diagramme de relation d'entité pour les données d'achat des clients
Le symbole de clé à côté de l'ID client dans le tableau de la dimension Clients signifie que si vous connaissez un ID client, vous pouvez trouver ce client de manière unique dans le tableau et toutes les informations associées. L'ID client se trouve également dans la table Purchases Fact. L'ID client est appelé clé étrangère lorsqu'il se trouve dans la table Purchases Fact car il peut apparaître plusieurs fois et définit de manière unique les lignes d'une table étrangère par rapport à celle qu'il apparaît.
Avec la mise en page de la figure 1, il est très facile de voir comment mettre à jour une description de produit. Pour ce faire, il vous suffirait de modifier la table Product Dimension et cette modification s'appliquerait à tous les achats effectués, un avantage appelé maintenabilité . S'il s'agissait d'un tableau avec la description du produit répétée plusieurs fois, vous devriez 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
Regardons maintenant un exemple avec Query Builder. Le gouvernement américain recueille beaucoup de données intéressantes avec le Current Population Survey (CPS) [USGCPS]. Le CPS c'est :
" La Current Population Survey (CPS) est l'une des enquêtes les plus anciennes, les plus importantes et les plus reconnues aux États-Unis. Il est extrêmement important, fournissant 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 recueillir des données pour diverses autres études qui tiennent la nation informée du bien-être économique et social de sa population. Cela se fait en ajoutant un ensemble de questions supplémentaires aux questions mensuelles de base du CPS. Les demandes de renseignements supplémentaires varient d'un mois à l'autre et couvrent une grande variété de sujets tels que la pension alimentaire pour enfants, le bénévolat, la couverture d'assurance maladie et la scolarisation. Les suppléments sont généralement administrés annuellement ou semestriellement, mais la fréquence et la récurrence d'un supplément dépendent entièrement de ce qui répond le mieux aux besoins du promoteur du supplément.
Ces données peuvent être téléchargées sous forme de 36 fichiers texte, qui s'ouvrent facilement dans JMP car les fichiers sont des fichiers texte délimités par des tabulations. En regardant les tables JMP, un diagramme ER (Figure 2) a été créé pour informer le travail dans Query Builder.
Figure 2. Diagramme ER pour les tableaux de données des statistiques sur la population active de la CPS
Pour utiliser Query Builder, vous devrez définir une table primaire (fait) et une ou plusieurs tables secondaires (dimension ).
La table de faits pour les données CPS est appelée AllData.jmp . Le tableau compte plus de 5 millions de lignes mais seulement cinq colonnes. Les colonnes ont un "series_id", des dates et une colonne "value". Pour donner un sens aux données, vous devez savoir ce que series_id.jmp moyens. Le diagramme ER de la figure 2 montre que "series_id" est lié au série.jmp tableau. Ensuite, ouvrez ces deux tables dans JMP et utilisez Query Builder pour définir la jointure.
Dans JMP, sélectionnez AllData.jmp comme table principale (faite) et série.jmp que le tableau secondaire (dimension) (Figure 3). JMP recherchera automatiquement les clés qui correspondent et configurera la jointure, mais vous devez le vérifier en cliquant sur le diagramme de Venn à droite du tableau des séries. Query Builder a trouvé "footnote_codes" dans les deux tables, mais vous ne voulez pas les joindre en tant que clé, juste le "series_id", de sorte que la relation de clé doit être supprimée.
Figure 3. Générateur de requêtes pour la jointure de AllData.jmp et Série.jmp
Vous devez maintenant définir les colonnes dans la table jointe (Figure 4). Pour ce faire, sélectionnez AllData.jmp en haut à gauche et sélectionnez les colonnes nécessaires dans ce tableau. Supprimez "series_id" maintenant, car vous n'aurez pas besoin de cette clé dans la table résultante ( series et data.jmp ).
Figure 4. Générateur de requêtes à rejoindre series et data.jmp à tous " _code.jmp " les tables
Remarquerez que series et data.jmp est environ cinq fois plus grand que le AllData.jmp tableau. Cette inflation est due aux valeurs répétées de tous les champs « _code ». Il est donc clair que le stockage des données dans 36 tables réduit la stockage exigences substantiellement. Ensuite, sélectionnez series et data.jmp comme table primaire et tous les "_code.jmp ” tables comme tables secondaires (Figure 5).
Figure 5. Query Builder pour rejoindre tous les " _code.jmp ”
Construisez la requête avec uniquement les champs "_text" des tables "_code" car vous n'avez plus besoin des variables clés. À l'aide de Cols > Columns Viewer dans JMP, vous pouvez facilement obtenir un résumé des 42 colonnes du tableau. Jointure complète.jmp. Vous aurez toujours 5,7 millions de lignes, ce qui équivaut à AllData.jmp , mais vous avez maintenant les champs de texte qui décrivent les données. Même si le tableau Jointure complète.jmp est encore six fois plus grand que la table AllData.jmp, vous avez maintenant un tableau utile pour l'analyse.
Utilisez le générateur de graphiques pour tracer la tendance du chômage dans le secteur manufacturier à partir de Jointure complète.jmp . Dans la figure 6, la perturbation de ce secteur pendant la récession est représentée par la ligne de tendance rouge. Les niveaux de chômage en 2016 sont revenus aux niveaux observés en 2006-2007. La ligne de tendance verte montre les niveaux d'emploi dans le secteur de la fabrication automobile. Plus de 300 000 emplois dans la fabrication automobile ont été ajoutés de 2010 à 2015.
Figure 6. Générateur de graphiques affichant les données des statistiques de la population active de la CPS
Cas 2 : Données d'inspection des restaurants
Ce cas explore l'utilisation de la jointure virtuelle et du générateur de requêtes JMP pour analyser les résultats d'inspection des restaurants du DOHMH à New York. [DOHMH] . Imaginez-vous en tant que nouvel inspecteur en poste et explorant des données historiques pour voir ce que les données révèlent. À partir du site Web https://data.cityofnewyork.us/Health/DOHMH-New-York-City-Restaurant-Inspection-Results/xx67-kt59 , vous pouvez télécharger une version .csv de ces données qui peut être facilement ouverte dans JMP. Le téléchargement complet du 17 juillet 2016 génère un fichier de 163,3 Mo qui comprend 448 149 enregistrements.
Ces données ont une colonne INSPECTION DATE, qui est un M/D/Y de l'événement d'inspection. Pour voir combien d'années sont incluses dans ces données, cliquez avec le bouton droit de la souris et utilisez une nouvelle colonne de formule > Date et heure > Année. La conversion de continu en nominal, puis Analyser> Distribution est illustrée à la figure 7. Le niveau 1900 est probablement un code pour les données manquantes, quelque chose dont vous aurez besoin d'adresse. Ce n'est pas un problème d'éditer ces données de manière destructive (puisque JMP est utilisé ici comme bac à sable et que les données réelles sont toujours stockées sur le serveur) ; utilisez ensuite l'utilitaire Recode pour définir ces niveaux sur manquants.
Figure 7. Dates d'inspection pour l'ensemble de données complet
Dans la fenêtre de recodage, il y a 1 151 enregistrements qui sont 01/01/1900. Remplacez cette ancienne valeur par • en supprimant la chaîne, puis en cliquant sur Terminé -> En place. Étant donné que la DATE D'ENREGISTREMENT est la date à laquelle les données ont été extraites et n'est pas pertinente pour cette analyse, supprimez la colonne.
Cet article concerne la jointure virtuelle et le générateur de requêtes. Vous vous demandez peut-être pourquoi nous examinons une table dénormalisée. Il semble y avoir une possibilité de normaliser ces données. L'emplacement géocodé des restaurants individuels est particulièrement absent de ces données brutes, une tâche qui peut être effectuée ultérieurement avec un complément JMP. Étant donné que ce processus est coûteux en termes de calcul, il est logique de géocoder uniquement des emplacements uniques, qui peuvent avoir plusieurs inspections dans ces données. De plus, il semble y avoir une possibilité d'avoir un tableau supplémentaire des violations, qui sont beaucoup moins nombreuses que les inspections uniques.
Avant de diviser les données, prenez un échantillon de ces données afin que les chiffres soient plus gérables pour votre exercice d'exploration.
L'échantillonnage est quelque chose qui peut être effectué facilement avec Query Builder. Tables > JMP Query Builder fera apparaître la boîte de dialogue de lancement. Étant donné que vous n'effectuez pas de jointure dans ce cas, utilisez DOHMH_New_York_City_Restaurant_Inspection_Results.jmp en tant que table principale sans tables secondaires à ce stade. Dans Query Builder, il existe un onglet nommé Sample. En cochant la case "Échantillonner cet ensemble de résultats", vous pouvez choisir Premier N lignes ou Aléatoire N Lignes. Prenez un échantillon aléatoire de 10 % de ces données, placez donc 44 815 dans l'Aléatoire N Lignes. Ajoutez toutes les colonnes à la section Inclure les colonnes, puis inspectez le SQL. Query Builder a automatiquement généré le SQL pour effectuer cette requête :
SÉLECTIONNER t1.CAMIS, t1.DBA, t1.BORO, t1.BÂTIMENT,
t1.STREET, t1.ZIPCODE, t1.PHONE, t1."CUISINE DESCRIPTION",
t1."DATE D'INSPECTION", t1."ACTION", t1."CODE D'INFRACTION", t1."DESCRIPTION D'INFRACTION",
t1."DRAPEAU CRITIQUE", t1.SCORE, t1.GRADE, t1."DATE DE NOTE",
t1."TYPE D'INSPECTION", t1."Année[DATE D'INSPECTION]"
DE DOHMH_New_York_City_Restaurant_Inspection_Results t1
ORDRE PAR ALÉATOIRE() LIMITE 44815 ;
Après avoir utilisé l'ordre par hasard () fonction pour notre échantillonnage, cette requête générera le sous-ensemble approprié de données. Enregistrez-le en tant que sous-ensemble, puis séparez les données démographiques du restaurant et les codes de violation. Le générateur de requêtes peut également être utilisé ici. Commencez par les codes de violation. Encore une fois, vous avez juste besoin d'une table primaire. Faites glisser et déposez VIOLATION CODE et VIOLATION DESCRIPTION dans la liste des variables, puis faites glisser à nouveau VIOLATION CODE, ce qui vous permet d'agréger par nombre et de générer le tableau qui a les propriétés souhaitées. Remplacez le nom JMP de la colonne d'agrégation par VIOLATION COUNT. Cette possibilité de générer un alias vers une colonne ou une colonne dérivée est une fonctionnalité puissante de Query Builder. Vous pouvez également choisir de trier automatiquement selon la colonne agrégée nouvellement créée en faisant glisser le VIOLATION COUNT vers le rôle Trier par, 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 de violation uniques, cette requête résultante est beaucoup plus compacte. Après avoir nommé cette table D-ViolationCodes.jmp , t C'est le bon moment pour utiliser Graph Builder pour explorer les codes qui ont le plus d'enregistrements. Faites glisser VIOLATION DESCRIPTION vers l'axe X et VIOLATION COUNT vers l'axe Y. Cliquez ensuite avec le bouton droit de la souris sur la DESCRIPTION DE LA VIOLATION et Trier par NOMBRE DE VIOLATIONS (décroissant). Pour vous concentrer uniquement sur les principales catégories, vous pouvez utiliser le filtre de données locales sur VIOLATION COUNT avec des catégories de violation, qui ont 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)
En vous éloignant du tableau des violations pour l'instant, vous pouvez vous concentrer sur les données démographiques uniques des restaurants. À ce stade, vous pouvez également supprimer la description de la violation, ce qui enregistre un certain nombre de lignes en double dans la table de faits principale. Utilisez le CODE DE VIOLATION, qui est un moyen beaucoup plus compact d'organiser ces données (chaînes de trois lettres par rapport aux chaînes de phrases longues).
Encore une fois, utilisez Query Builder pour retirer les données démographiques uniques des restaurants. Il est très probable qu'il y ait plus d'une pizzeria du même nom à New York, mais Query Builder peut gérer cette situation. La colonne CAMIS fonctionne comme un ID qui peut être utilisé pour identifier des restaurants uniques. Dans Query Builder, faites glisser CAMIS deux fois, dont l'une doit être Aggregated by count et renommée INSPECTION COUNT. Le reste des données démographiques est DBA, BORO, BUILDING, STREET, ZIPCODE, PHONE et CUISINE DESCRIPTION. Enfin, calculez une colonne appelée ADDRESS pour le géocodeur, ce qui sera fait comme un script post-requête. Exécutez la requête, puis utilisez une colonne de formules avec la formule suivante :
:BÂTIMENT || " " || :RUE || " " || :BORO || "New York," || Carboniser ( :CODE POSTAL )
Cette formule rassemble la bonne adresse. Dactylographie :ADRESSE << obtenir le script ; dans un éditeur de script produira le JSL requis pour générer la colonne pour un script post-requête. Copiez et collez ce code dans l'onglet approprié de Query Builder, 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 appelée Group and Initialize Data: Sequence Data, From 1 to 20, Step 1, Repeat 1, vous pouvez obtenir 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 réexécuter la requête. Enregistrez cette table de données sous D-Restaurants.jmp . Enfin, supprimez les colonnes supplémentaires de la table de faits actuelle, notamment : DBA, BORO, BUILDING, STREET, ZIPCODE, PHONE et CUISINE DESCRIPTION.
Enregistrez ce tableau sous F-Inspections.jmp . Vous êtes maintenant prêt à géocoder les groupes de restaurants avec un complément créé par Xan Gregg disponible sur le JMP File Exchange [GREGG], qui utilise OpenStreetMaps.org pour géocoder les emplacements. Ce service est coûteux en calcul et sujet aux échecs, 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 plate-forme, illustrée à la figure 10, est utile ici.
Figure 10. Plate-forme de sous-ensembles de tables pour le fractionnement par groupe de restaurants
Les 20 tables nouvellement créées peuvent être géocodées individuellement à l'aide du complément. Le champ d'adresse aide à déterminer la latitude et la longitude correctes. Et enfin, enregistrez les résultats dans la même table de données.
Pour ramener la table de données à une table de dimension unique avec des emplacements, utilisez la fonction Tables > Concaténer, en combinant les 20 groupes ; Il s'appelle D-RestaurantswLocation.jmp.
Maintenant que vous avez décomposé cette table à l'aide de Query Builder, vous pouvez la reconstruire à l'aide d'une jointure virtuelle.
Tout d'abord, commencez par nos tableaux à deux dimensions : Restaurants-wLocation.jmp et ViolationCodes.jmp . Un clic droit sur le CODE DE VIOLATION et la sélection de l'ID de lien configureront le début de la jointure virtuelle. Remarquez qu'une petite icône de clé apparaît dans la liste des colonnes. Déplacez-vous vers la table Restaurants et faites de même avec le CAMIS. Pour terminer la jointure virtuelle, accédez à la table des faits, qui contient toutes les inspections, puis sélectionnez Lien de référence pour le CAMIS et le CODE DE VIOLATION.
Toutes les colonnes apparaissent dans la table de faits sans avoir à 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 de lien :
Set Property("Link Reference", Reference Table("D(f)-Restaurants-wLocation.jmp"));
Pour l'ID de 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 alourdir la table de faits.
Enfin, créez un tableau de bord pour visualiser et explorer ces données en tirant parti des colonnes virtuellement jointes.
La figure 12 montre comment Dashboard Builder affiche une collection de cinq graphiques. Pour utiliser deux des graphiques comme filtres de sélection, commencez par le modèle de filtre hiérarchique dans Dashboard Builder, en utilisant CRITICAL FLAG et BORO comme filtre et filtre hiérarchique. Ensuite, utilisez un graphique des comptages de notes, le score moyen par quantile sur une carte et, enfin, une carte thermique des comptages de dates par type d'inspection.
Figure 12. Mode Dashboard Builder d'Application Builder avec tableau de bord d'inspection finale NYC
Ceci n'est qu'un exemple du type de visualisation que vous pouvez effectuer avec ces données, en tirant parti des tables liées offertes par la jointure virtuelle. Les données géocodées permettent également, par exemple, de creuser les emplacements des restaurants par 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 de l'utilisation de Query Builder est la génération de Structured Query Language (SQL). 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 des tables. SQL peut être généré à partir d'une requête que vous définissez dans l'interface pointer-cliquer de Query Builder.
Vous trouverez ci-dessous le SQL créé par Query Builder pour la jointure de toutes les tables de dimension à la table jointe de série.jmp et AllData.jmp (du cas 1) et le SQL de la jointure de Jointure complète.jmp et tout le _code.jmp les tables. Le nom de bibliothèque l'instruction, les références libname associées sur les tables et les proc sql déclaration ont été ajoutées. Le reste du code a été généré par Query Builder.
Notez que la majeure partie du code est une liste des colonnes dans les instructions SELECT. L'utilisation de Query Builder pour générer un tel code est d'une grande aide, même si l'utilisateur connaît SQL. Pourquoi taper autant de noms de tables et de colonnes si ce n'est pas nécessaire ?
nom de bibliothèque source 'l'emplacement de votre fichier' ;
proc sql ;
créer tableau source.dataNseries comme
SÉLECTIONNER t1.année, t1.période, t1.valeur, t1.footnote_codes,
t2.lfst_code, t2.periodicity_code, t2.series_title, t2.absn_code,
t2.activity_code, t2.ages_code, t2.class_code, t2.duration_code,
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.vets_code, t2.wkst_code, t2.born_code, t2.chld_code,
t2.disa_code, t2.seasonal, t2.footnote_codes, t2.begin_year,
t2.begin_period, t2.end_year, t2.end_period DEPUIS source.AllData t1
GAUCHE OUTER JOIN source.series t2
SUR ( t1.series_id = t2.series_id ) ;
SÉLECTIONNER t1.year, t1.period, t1.value, t1.series_title,
t1.saisonnier, t1.begin_year, t1.begin_period, t1.end_year,
t1.end_period, t13.footnote_text, t34.wkst_text, t33.vets_text,
t32.tdat_text, t31.sexs_text, t30.seek_text, t29.rwns_text,
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.class_text, t6.chld_text, t5.born_text, t4.ages_text,
t3.texte_activité, t2.texte_absn DEPUIS source.dataNseries t1
GAUCHE OUTER JOIN source.footnote t13
SUR ( t1.footnote_codes = t13.footnote_code )
GAUCHE OUTER JOIN source.wkst t34
SUR ( t34.wkst_code = t1.wkst_code )
GAUCHE OUTER JOIN source.vets t33
SUR ( t33.vets_code = t1.vets_code )
GAUCHE OUTER JOIN source.tdat t32
SUR ( t32.tdat_code = t1.tdat_code )
GAUCHE OUTER JOIN source.sexs t31
SUR ( t31.sexs_code = t1.sexs_code )
GAUCHE OUTER JOIN source.seek t30
SUR ( t30.seek_code = t1.seek_code )
GAUCHE OUTER JOIN source.rwns t29
SUR ( t29.rwns_code = t1.rwns_code )
GAUCHE OUTER JOIN source.rnlf t28
SUR ( t28.rnlf_code = t1.rnlf_code )
GAUCHE OUTER JOIN source.rjnw t27
SUR ( t27.RJNW_CODE = t1.rjnw_code )
GAUCHE OUTER JOIN source.course t26
SUR ( t26.race_code = t1.race_code )
GAUCHE OUTER JOIN source.périodicité t25
SUR ( t25.periodicity_code = t1.periodicity_code )
GAUCHE OUTER JOIN source.pcts t24
SUR ( t24.pcts_code = t1.pcts_code )
GAUCHE OUTER JOIN source.orig t23
SUR ( t23.code_orig = t1.code_orig )
GAUCHE OUTER JOIN source.occupation t22
SUR ( t22.code_occupation = t1.code_occupation )
GAUCHE OUTER JOIN source.mjhs t21
SUR ( t21.mjhs_code = t1.mjhs_code )
GAUCHE OUTER JOIN source.mari t20
SUR ( t20.code_mari = t1.code_mari )
GAUCHE OUTER JOIN source.look t19
SUR ( t19.look_code = t1.look_code )
GAUCHE OUTER JOIN source.lfst t18
SUR ( t18.lfst_code = t1.lfst_code )
GAUCHE OUTER JOIN source.jdes t17
SUR ( t17.jdes_code = t1.jdes_code )
GAUCHE OUTER JOIN source.indy t16
SUR ( t16.indy_code = t1.indy_code )
GAUCHE OUTER JOIN source.heure t15
SUR ( t15.code_heure = t1.code_heure )
GAUCHE OUTER JOIN source.hheader t14
SUR ( t14.hheader_code = t1.hheader_code )
GAUCHE OUTER JOIN source.expr t12
SUR ( t12.expr_code = t1.expr_code )
GAUCHE OUTER JOIN source.entr t11
SUR ( t11.entr_code = t1.entr_code )
GAUCHE OUTER JOIN source.éducation t10
SUR ( t10.education_code = t1.education_code )
GAUCHE OUTER JOIN source.durée t9
SUR ( t9.duration_code = t1.duration_code )
GAUCHE OUTER JOIN source.disa t8
SUR ( t8.disa_code = t1.disa_code )
GAUCHE OUTER JOIN source.classe t7
SUR ( t7.code_classe = t1.code_classe )
GAUCHE OUTER JOIN source.chld t6
SUR ( t6.chld_code = t1.chld_code )
GAUCHE OUTER JOIN source.born t5
SUR ( t5.born_code = t1.born_code )
GAUCHE OUTER JOIN source.âges t4
SUR ( t4.ages_code = t1.ages_code )
GAUCHE OUTER JOIN source.activité t3
SUR ( t3.activity_code = t1.activity_code )
GAUCHE OUTER JOIN source.absn t2
SUR ( t1.code_absn = t2.code_absn );
arrêter ;
Résumé
Les analystes ont besoin de données dans une seule table, organisées de manière à rendre la visualisation et l'analyse possibles. Cependant, les données sont souvent organisées pour le chargement, la maintenance et le stockage dans de nombreuses tables (normalisées) afin que les analystes soient mis au défi de joindre et de résumer de nombreuses tables en une seule table prête pour l'analyse.
JMP Query Builder est un moyen puissant de joindre plusieurs tables à partir de JMP. La fonction d'aperçu permet à l'utilisateur de voir si la jointure est correctement définie avant d'exécuter une opération de jointure de table chronophage. Le SQL généré peut être déployé dans SAS ou dans une base de données, ce qui permet de gagner un temps considérable en écrivant ce code à la main.
Les références
[UGSCPS] Statistiques de la population active – Current Population Survey – CPS. Extrait le 18 août 2016 de http://www.bls.gov/cps/data.htm .
[DOHMH] Résultats de l'inspection des restaurants du DOHMH à New York. Extrait le 17 août 2016 de https://data.cityofnewyork.us/Health/DOHMH-New-York-City-Restaurant-Inspection-Results/xx67-kt59 .
[GREGG] Gregg, X. (2014, 28 mai). Géocodage des noms de lieux. Extrait le 18 août 2016 de https://community.jmp.com/docs/DOC-6175 .
