Daniele Valente , PhD, Senior Product Manager di JMP, SAS
Jon Weisz , Vicepresidente Vendite e Marketing di JMP, SAS
Astratto
JMP 13 introduce due nuovi strumenti che facilitano all'analista la gestione di problemi di dati comuni. Spesso due o più tabelle di dati sono correlate da una chiave comune, eppure sono molto diverse in termini di frequenza di campionamento dei fatti o dimensioni (ad esempio, lungo rispetto a largo). L'effettivo join di queste due (o più) tabelle può creare una tabella risultante che diventa molto grande in memoria. Anche se questo è fastidioso quando le tabelle dei fatti e delle dimensioni sono relativamente compatte, può generare rapidamente una tabella unita troppo grande per essere contenuta nella memoria. La soluzione consiste nell'utilizzare un join virtuale, che preserva la relazione unita senza creare effettivamente la tabella unita, arricchendo efficacemente la tabella dei fatti senza appesantirla. Gli analisti spesso si trovano a dover creare complesse unioni di tabelle o riepiloghi nel database e scrivere SQL, che creano la propria serie di problemi, in particolare quando ci sono relazioni complesse come le dimensioni che cambiano lentamente. JMP Query Builder funge da semplice strumento di generazione e scrittura SQL, il cui codice può quindi essere eseguito in un database. Dopo aver trascinato e rilasciato la query corretta e desiderabile, Query Builder scrive automaticamente il codice SQL per te, eliminando la necessità di noioso lavoro manuale e soggetto a errori.
Panoramica delle strutture di tabelle relazionali
Gli analisti hanno bisogno di dati in una forma che abbia variabili in colonne e osservazioni in righe. I dati possono anche richiedere colonne categoriche che sottogruppino chiaramente le osservazioni (ad esempio, livello di reddito, paese, macchina, ecc.). I dati possono anche avere attributi che illuminano ulteriormente le osservazioni (ad esempio, indirizzo, numero di serie, ID cliente, ecc.).
Spesso i dati di origine per tale analisi sono strutture di dati relazionali memorizzate nei database. Molti corsi di studio moderni in scienza dei dati trattano argomenti relativi a strutture di dati relazionali, database e SQL. Ma la maggior parte degli ingegneri, scienziati e statistici non sono esposti a questi argomenti in un contesto accademico, quindi devono conoscerli come parte di un'educazione continua e informale. JMP Query Builder offre agli analisti un ponte tra strutture di dati relazionali e dati pronti per l'analisi. Imparando alcuni termini e concetti, gli analisti possono utilizzare Query Builder per generare dati pronti per l'analisi.
La breve discussione delle strutture di dati relazionali in questo articolo non intende sostituire uno studio approfondito dell'argomento; piuttosto introduce i termini e le definizioni utilizzati quando si lavora con Query Builder e le sue funzionalità di virtual join in JMP.
Perché avere più di una tabella per archiviare dati importanti?
Immagina di dover escogitare un modo per archiviare i dati sugli acquisti dei prodotti della tua azienda da parte dei clienti. Potresti prima iniziare elencando tutte le variabili che potrebbero dover essere raccolte, come ad esempio:
- Data di acquisto
- Ammontare dell'acquisto
- Metodo di acquisto (PO o CC)
- SKU del prodotto
- Descrizione del prodotto
- Nome del cliente
- Indirizzo del cliente
- Numero di telefono del cliente
Questo non è certamente un elenco completo, ma è un buon inizio. Ora pensa a mantenere questi dati. Questa tabella avrà otto colonne e una riga per ogni acquisto. Alcuni campi possono avere molti valori distinti, come Importo acquisto o Data acquisto. Altri campi avranno molti meno valori distinti e molti valori ripetuti, come SKU prodotto e Descrizione.
Un modo comune per ridurre le dimensioni della tabella consiste nel suddividere la tabella in tre gruppi logici. La prima è la tabella contenente le transazioni o fatti , come la data di acquisto e l'importo di acquisto. La seconda tabella conterrebbe le informazioni sul cliente e la terza conterrebbe le informazioni sul prodotto. Per mantenere i collegamenti tra le colonne di dati, dovrebbe essere aggiunta una colonna con informazioni sui collegamenti per mettere in relazione le tre tabelle. Queste colonne sono chiamate chiavi . Un modo comune per mostrare questo layout è utilizzare un file diagramma delle relazioni tra entità (ER) . Ogni entità ha un nome di tabella, una chiave o un insieme di chiavi che identificano in modo univoco ciascuna riga e un insieme di attributi o variabili che forniscono informazioni su ciascuna riga. Il diagramma ER per la data di acquisto del cliente è mostrato nella Figura 1.
Figura 1. Diagramma delle relazioni tra entità per i dati di acquisto dei clienti
Il simbolo della chiave accanto all'ID cliente nella tabella Dimensione clienti indica che se conosci un ID cliente, puoi trovare in modo univoco quel cliente nella tabella e tutte le informazioni associate. L'ID cliente si trova anche nella tabella Fatti acquisti. L'ID cliente viene chiamato chiave esterna quando si trova nella tabella Fatti acquisti perché può apparire molte volte e definisce in modo univoco le righe in una tabella esterna rispetto a quella in cui appare.
Con il layout in Figura 1, è molto facile vedere come aggiornare una descrizione del prodotto. Per fare ciò, dovresti solo modificare la tabella Product Dimension e quella modifica si applicherebbe a tutti gli acquisti mai effettuati, un vantaggio denominato manutenibilità . Se questa fosse una tabella con la descrizione del prodotto ripetuta molte volte, dovresti modificare molte righe, il che porterebbe inevitabilmente a errori e problemi di qualità dei dati.
Caso 1: Indagine sulla popolazione attuale
Ora diamo un'occhiata a un esempio con Query Builder. Il governo degli Stati Uniti raccoglie molti dati interessanti con il Current Population Survey (CPS) [USGCPS]. Il CPS è:
“ Il Current Population Survey (CPS) è uno dei sondaggi più antichi, più grandi e più riconosciuti negli Stati Uniti. È immensamente importante, fornendo informazioni su molte delle cose che ci definiscono come individui e come società: il nostro lavoro, i nostri guadagni e la nostra istruzione. Oltre ad essere la principale fonte di statistiche mensili sulla forza lavoro, il CPS viene utilizzato per raccogliere dati per una serie di altri studi che tengono informata la nazione sul benessere economico e sociale della sua popolazione. Questo viene fatto aggiungendo una serie di domande supplementari alle domande CPS di base mensili. Le richieste supplementari variano di mese in mese e coprono un'ampia varietà di argomenti come il mantenimento dei figli, il volontariato, la copertura assicurativa sanitaria e l'iscrizione scolastica. I supplementi vengono generalmente condotti annualmente o semestralmente, ma la frequenza e la ricorrenza di un supplemento dipendono completamente da ciò che meglio soddisfa le esigenze dello sponsor del supplemento.
Questi dati possono essere scaricati come 36 file di testo, che possono essere facilmente aperti in JMP poiché i file sono file di testo delimitati da tabulazioni. Osservando le tabelle JMP, è stato creato un diagramma ER (Figura 2) per informare il lavoro in Query Builder.
Figura 2. Diagramma ER per le tabelle di dati delle statistiche sulla forza lavoro CPS
Per utilizzare Query Builder, dovrai definire una tabella primaria (fact) e una o più tabelle secondarie (dimension ).
Viene richiamata la tabella dei fatti per i dati CPS AllData.jmp . La tabella ha più di 5 milioni di righe ma solo cinque colonne. Le colonne hanno una colonna "id_serie", date e una colonna "valore". Per dare un senso ai dati, è necessario scoprire cosa id_serie.jmp significa. Il diagramma ER nella Figura 2 mostra che "series_id" è correlato a serie.jmp tavolo. Successivamente, apri entrambe le tabelle in JMP e utilizza Query Builder per definire il join.
In JMP, seleziona AllData.jmp come tabella primaria (fatto) e serie.jmp come tabella secondaria (dimensione) (Figura 3). JMP cercherà automaticamente le chiavi adatte e imposterà il join, ma dovresti verificarlo facendo clic sul diagramma di Venn a destra della tabella delle serie. Query Builder ha trovato "footnote_codes" in entrambe le tabelle, ma non vuoi unirti a quelli come chiave, solo "series_id", in modo che la relazione chiave debba essere rimossa.
Figura 3. Costruttore di query per l'unione di AllData.jmp E Serie.jmp
Ora è necessario definire le colonne nella tabella unita (Figura 4). Per farlo, seleziona AllData.jmp in alto a sinistra e seleziona le colonne necessarie da quella tabella. Rilascia "series_id" ora, perché non avrai bisogno di quella chiave nella tabella risultante ( serie e dati.jmp ).
Figura 4. Costruttore di query a cui partecipare serie e dati.jmp a tutti " _code.jmp ” tavoli
Notare che serie e dati.jmp è circa cinque volte più grande del AllData.jmp tavolo. Questa inflazione è dovuta ai valori ripetuti di tutti i campi “_code”. Quindi chiaramente l'archiviazione dei dati in 36 tabelle riduce il magazzinaggio sostanzialmente i requisiti. Quindi, seleziona serie e dati.jmp come la tabella principale e tutti i file “_codice.jmp ” tabelle come tabelle secondarie (Figura 5).
Figura 5. Costruttore di query per unire tutte le " _code.jmp "
Costruisci la query solo con i campi "_text" delle tabelle "_code" perché non hai più bisogno delle variabili chiave. Utilizzando Cols > Columns Viewer in JMP, è possibile ottenere facilmente un riepilogo delle attuali 42 colonne nella tabella Join.jmp completo. Avrai ancora 5,7 milioni di righe, che è lo stesso di AllData.jmp , ma ora hai i campi di testo che descrivono i dati. Anche se il tavolo Join.jmp completo è ancora sei volte più grande del tavolo AllData.jmp, ora hai una tabella utile per l'analisi.
Usa Graph Builder per tracciare l'andamento della disoccupazione nel settore manifatturiero Join.jmp completo . Nella Figura 6, la perturbazione in questo settore durante la recessione è mostrata con la linea di tendenza rossa. I livelli di disoccupazione nel 2016 sono tornati ai livelli visti nel 2006-2007. La linea di tendenza verde mostra i livelli di occupazione per il settore manifatturiero automobilistico. Dal 2010 al 2015 sono stati aggiunti più di 300.000 posti di lavoro nel settore automobilistico.
Figura 6. Costruttore di grafici che mostra i dati delle statistiche sulla forza lavoro CPS
Caso 2: Dati di ispezione del ristorante
Questo caso esplora l'utilizzo di virtual join e JMP Query Builder per l'analisi dei risultati delle ispezioni dei ristoranti DOHMH a New York City [DOHM] . Immagina di essere un nuovo ispettore sul lavoro e di esplorare alcuni dati storici per vedere cosa rivelano i dati. Dal sito web https://data.cityofnewyork.us/Health/DOHMH-New-York-City-Restaurant-Inspection-Results/xx67-kt59 , puoi scaricare una versione .csv di questi dati che può essere facilmente aperta in JMP. Il download completo il 17 luglio 2016 genera un file da 163,3 MB che include 448.149 record.
Questi dati hanno una colonna INSPECTION DATE, che è un M/D/Y dell'evento di ispezione. Per vedere quanti anni sono inclusi in questi dati, fare clic con il pulsante destro del mouse e utilizzare Nuova colonna formula > Data ora > Anno. La conversione da continua a nominale e quindi Analizza > Distribuzione è mostrata nella Figura 7. Il livello 1900 è probabilmente un codice per i dati mancanti, qualcosa che dovrai affrontare. Non è un problema modificare in modo distruttivo questi dati (poiché JMP viene utilizzato come sandbox qui e i dati reali sono sempre archiviati sul server); quindi utilizzare l'utilità Ricodifica per modificare questi livelli in mancanti.
Figura 7. Date di ispezione per il set di dati completo
Nella finestra di ricodifica, ci sono 1.151 record che sono 01/01/1900. Modificare questo vecchio valore in • eliminando la stringa e quindi facendo clic su Fatto -> Sul posto. Poiché RECORD DATE è la data in cui i dati sono stati estratti e non è rilevante per questa analisi, eliminare la colonna.
Questo documento riguarda l'unione virtuale e il generatore di query, quindi potresti chiederti perché stiamo osservando una tabella denormalizzata. Sembra esserci un'opportunità per normalizzare questi dati. Particolarmente assente da questi dati grezzi è la posizione geocodificata dei singoli ristoranti, un'attività che può essere eseguita successivamente con un componente aggiuntivo di JMP. Poiché questo processo è costoso dal punto di vista computazionale, ha senso geocodificare solo posizioni univoche, che possono avere più ispezioni in questi dati. Inoltre, sembra esserci l'opportunità di disporre di una tabella aggiuntiva delle violazioni, che sono molto meno delle ispezioni uniche.
Prima di suddividere i dati, prendi un campione di questi dati in modo che i numeri siano più gestibili per il tuo esercizio di esplorazione.
Il campionamento è qualcosa che può essere eseguito facilmente con Query Builder. Tabelle > JMP Query Builder aprirà la finestra di dialogo di avvio. Poiché in questo caso non stai eseguendo un join, usa DOHMH_New_York_City_Restaurant_Inspection_Results.jmp come tabella primaria senza tabelle secondarie a questo punto. In Query Builder è presente una scheda denominata Esempio. Attivando la casella di controllo "Esempio di questo set di risultati", puoi scegliere Primo N righe o casuale N righe. Prendi un campione casuale del 10 percento di questi dati, quindi inserisci 44.815 nel Casuale N righe. Aggiungere tutte le colonne alla sezione Includi colonne e quindi ispezionare l'SQL. Query Builder ha generato automaticamente l'SQL per eseguire questa query:
SELEZIONA t1.CAMIS, t1.DBA, t1.BORO, t1.EDIFICIO,
t1.VIA, t1.CAP, t1.TELEFONO, t1."DESCRIZIONE CUCINA",
t1."DATA ISPEZIONE", t1."AZIONE", t1."CODICE VIOLAZIONE", t1."DESCRIZIONE VIOLAZIONE",
t1."FLAG CRITICO", t1.PUNTEGGIO, t1.GRADO, t1."DATA DEL GRADO",
t1."TIPO ISPEZIONE", t1."Anno[DATA ISPEZIONE]"
DA DOHMH_New_York_City_Restaurant_Inspection_Results t1
ORDINA PER LIMITE CASUALE() 44815;
Dopo aver usato l'ordine per caso () funzione per il nostro campionamento, questa query genererà il sottoinsieme appropriato dei dati. Salvalo come sottoinsieme e poi separa i dati demografici del ristorante e i codici di violazione. Query Builder può essere utilizzato anche qui. Inizia con i codici di violazione. Ancora una volta, hai solo bisogno di una tabella primaria. Trascina e rilascia CODICE DI VIOLAZIONE e DESCRIZIONE DELLA VIOLAZIONE nell'elenco delle variabili, quindi trascina nuovamente il CODICE DI VIOLAZIONE, che ti consente di aggregare per conteggio e generare la tabella con le proprietà desiderate. Modificare il nome JMP della colonna di aggregazione in VIOLATION COUNT. Questa capacità di generare un alias per una colonna o una colonna derivata è una potente funzionalità di Query Builder. È inoltre possibile scegliere di ordinare automaticamente in base alla colonna aggregata appena creata trascinando VIOLATION COUNT nel ruolo Order By, illustrato nella Figura 8.
Figura 8. Colonna di aggregazione rinominata Violation Count, con una proprietà Order By
Con solo 88 codici di violazione univoci, questa query risultante è molto più compatta. Dopo aver nominato questa tabella D-ViolationCodes.jmp , T Questo è un buon momento per utilizzare Graph Builder per esplorare quali codici hanno il maggior numero di record. Trascina VIOLATION DESCRIPTION sull'asse X e VIOLATION COUNT sull'asse Y. Quindi fare clic con il pulsante destro del mouse su VIOLATION DESCRIPTION e Order By VIOLATION COUNT (decrescente). Per concentrarti solo sulle categorie principali, puoi utilizzare il filtro Dati locali su VIOLATION COUNT con le categorie di violazione, che hanno più di 2.500 record univoci (Figura 9).
Figura 9. Principali conteggi delle violazioni (>2500 record univoci nella tabella campionata)
Allontanandoti dalla tabella delle violazioni per ora, puoi concentrarti sui dati demografici unici del ristorante. A questo punto, puoi anche eliminare la descrizione della violazione, che salva un numero di righe duplicate nella tabella dei fatti principale. Usa il CODICE DI VIOLAZIONE, che è un modo molto più compatto per organizzare questi dati (stringhe di tre lettere rispetto a stringhe lunghe una frase).
Ancora una volta, usa Query Builder per eliminare i dati demografici unici del ristorante. È molto probabile che ci sia più di una pizzeria con lo stesso nome a New York, ma Query Builder è in grado di gestire questa situazione. La colonna CAMIS funziona come un ID che può essere utilizzato per identificare ristoranti univoci. In Query Builder, trascina CAMIS due volte, una delle quali dovrebbe essere Aggregata per conteggio e rinominata INSPECTION COUNT. Il resto dei dati demografici è DBA, BORO, BUILDING, STREET, CAP, PHONE e CUISINE DESCRIPTION. Infine, calcola una colonna denominata ADDRESS per il geocoder, che verrà eseguita come script post-query. Eseguire la query e quindi utilizzare una colonna formula con la seguente formula:
:EDIFICIO || " " || :VIA || " " || :BORO || "NY", || Car ( :CAP )
Questa formula mette insieme l'indirizzo corretto. Digitando :INDIRIZZO << ottenere la sceneggiatura ; in un editor di script produrrà il JSL necessario per generare la colonna per uno script post-query. Copia e incolla quel codice nella scheda appropriata in Query Builder, quindi genera una colonna che suddividerà i dati in 20 gruppi per una migliore interfaccia con il geocodifica. Dopo aver generato una nuova colonna denominata Group and Initialize Data: Sequence Data, From 1 to 20, Step 1, Repeat 1, puoi ottenere lo script e incollarlo nello script post-query. Ora che entrambe le colonne sono script, puoi eliminare la tabella della query ed eseguire nuovamente la query. Salva questa tabella dati con nome D-Ristoranti.jmp . Come passaggio finale, elimina le colonne extra dalla tabella dei fatti ora, tra cui: DBA, BORO, BUILDING, STREET, CAP, PHONE e CUISINE DESCRIPTION.
Salva questa tabella con nome F-Ispezioni.jmp . Ora sei pronto per geocodificare i gruppi di ristoranti con un componente aggiuntivo creato da Xan Gregg disponibile su JMP File Exchange [GREGG], che utilizza OpenStreetMaps.org per geocodificare le posizioni. Questo servizio è costoso dal punto di vista computazionale e soggetto a guasti, quindi è meglio separarsi D-Ristoranti per gruppo utilizzando Tabelle > Sottoinsieme. La funzionalità Subset By di questa piattaforma, illustrata nella Figura 10, è utile in questo caso.
Figura 10. Piattaforma di sottoinsiemi di tabelle per la suddivisione per gruppo di ristoranti
Le 20 tabelle appena create possono essere geocodificate individualmente utilizzando il componente aggiuntivo. Il campo dell'indirizzo aiuta a determinare la latitudine e la longitudine corrette. Infine, salva i risultati nella stessa tabella dati.
Per riportare la tabella dati a una tabella a dimensione singola con posizioni, utilizzare la funzione Tabelle > Concatena, combinando i 20 gruppi; è nominato D-RistorantiwPosizione.jmp.
Ora che hai suddiviso questa tabella utilizzando Query Builder, puoi ricostruirla utilizzando il virtual join.
Innanzitutto, inizia con le nostre tabelle delle due dimensioni: Ristoranti-wLocation.jmp E ViolationCodes.jmp . Facendo clic con il pulsante destro del mouse sul CODICE DI VIOLAZIONE e selezionando ID collegamento verrà impostato l'inizio dell'unione virtuale. Notare che una piccola icona a forma di chiave viene visualizzata nell'elenco delle colonne. Passa al tavolo Ristoranti e fai lo stesso con il CAMIS. Per completare l'unione virtuale, passa alla tabella dei fatti, che contiene tutte le ispezioni, quindi seleziona Link Reference sia per CAMIS che per VIOLATION CODE.
Tutte le colonne vengono visualizzate nella tabella dei fatti senza dover unire fisicamente le tabelle in memoria. Il virtual join può anche essere programmato tramite una proprietà della colonna:
Per il riferimento al collegamento:
Set Property("Link Reference", Reference Table("D(f)-Restaurants-wLocation.jmp"));
Per l'ID collegamento:
Imposta proprietà("Link ID", 1);
Figura 11. Partecipazione virtuale
La Figura 11 mostra che è possibile accedere alle colonne in entrambe le tabelle delle dimensioni senza appesantire la tabella dei fatti.
Infine, crea una dashboard per visualizzare ed esplorare questi dati sfruttando le colonne virtualmente unite.
La Figura 12 mostra come Dashboard Builder visualizza una raccolta di cinque grafici. Per utilizzare due dei grafici come filtri di selezione, iniziare con il modello Filtro gerarchico in Dashboard Builder, utilizzando CRITICAL FLAG e BORO come Filtro e Filtro gerarchico. Successivamente, utilizza un grafico dei conteggi dei voti, il punteggio medio per quantile su una mappa e, infine, una mappa termica dei conteggi delle date per tipo di ispezione.
Figura 12. Modalità Dashboard Builder di Application Builder con Final NYC Inspection Dashboard
Questo è solo un esempio del tipo di visualizzazione che puoi realizzare con questi dati, sfruttando le tabelle collegate offerte dal virtual join. I dati geocodificati consentono inoltre, ad esempio, di scavare nella posizione dei ristoranti per tipo di cucina (Figura 13).
Figura 13. Ristoranti geocodificati colorati per grado visualizzati su una mappa a livello stradale
Generazione e distribuzione SQL
Un altro grande vantaggio dell'utilizzo di Query Builder è la generazione di Structured Query Language (SQL). SAS può utilizzare SQL all'interno di Proc SQL e la maggior parte dei database utilizza SQL come linguaggio di programmazione per unire e gestire le tabelle. SQL può essere generato da una query definita nell'interfaccia point-and-click di Query Builder.
Di seguito è riportato l'SQL creato da Query Builder per l'unione di tutte le tabelle delle dimensioni alla tabella unita di serie.jmp E AllData.jmp (dal caso 1) e l'SQL dall'unione di Join.jmp completo e tutto il _code.jmp tabelle. IL nomelib istruzione, i riferimenti libname associati sulle tabelle e il file proc sql dichiarazione sono stati aggiunti. Il resto del codice è stato generato da Query Builder.
Si noti che la maggior parte del codice è un elenco delle colonne all'interno delle istruzioni SELECT. L'utilizzo di Query Builder per generare tale codice è di grande aiuto, anche se l'utente conosce SQL. Perché digitare così tanti nomi di tabelle e colonne se non è necessario?
nomelib fonte 'la posizione del tuo file' ;
proc sql ;
creare tavolo source.dataNseries COME
SELEZIONARE t1.anno, t1.periodo, t1.valore, 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.inizio_periodo, t2.fine_anno, t2.fine_periodo DA fonte.AllData t1
SINISTRA OUTER JOIN source.series t2
SU ( t1.series_id = t2.series_id ) ;
SELEZIONARE t1.anno, t1.periodo, t1.valore, t1.series_title,
t1.stagionale, t1.inizio_anno, t1.inizio_periodo, t1.fine_anno,
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.activity_text, t2.absn_text DA source.dataNseries t1
SINISTRA OUTER JOIN fonte.nota a piè di pagina t13
SU ( t1.footnote_codes = t13.footnote_code )
SINISTRA OUTER JOIN source.wkst t34
SU ( t34.wkst_code = t1.wkst_code )
SINISTRA OUTER JOIN source.vets t33
SU ( t33.vets_code = t1.vets_code )
SINISTRA OUTER JOIN sorgente.tdat t32
SU ( t32.tdat_code = t1.tdat_code )
SINISTRA OUTER JOIN sorgente.sessi t31
SU ( t31.sexs_code = t1.sexs_code )
SINISTRA OUTER JOIN source.seek t30
SU ( t30.seek_code = t1.seek_code )
SINISTRA OUTER JOIN source.rwns t29
SU ( t29.rwns_code = t1.rwns_code )
SINISTRA OUTER JOIN source.rnlf t28
SU ( t28.rnlf_code = t1.rnlf_code )
SINISTRA OUTER JOIN source.rjnw t27
SU ( t27.RJNW_CODE = t1.rjnw_code )
SINISTRA OUTER JOIN source.race t26
SU ( t26.race_code = t1.race_code )
SINISTRA OUTER JOIN sorgente.periodicità t25
SU ( t25.codice_periodicità = t1.codice_periodicità )
SINISTRA OUTER JOIN sorgente.pcts t24
SU ( t24.pcts_code = t1.pcts_code )
SINISTRA OUTER JOIN sorgente.orig t23
SU ( t23.orig_code = t1.orig_code )
SINISTRA OUTER JOIN fonte.occupazione t22
SU ( t22.codice_occupazione = t1.codice_occupazione )
SINISTRA OUTER JOIN sorgente.mjhs t21
SU ( t21.mjhs_code = t1.mjhs_code )
SINISTRA OUTER JOIN fonte.mari t20
SU ( t20.mari_code = t1.mari_code )
SINISTRA OUTER JOIN source.look t19
SU ( t19.look_code = t1.look_code )
SINISTRA OUTER JOIN source.lfst t18
SU ( t18.lfst_code = t1.lfst_code )
SINISTRA OUTER JOIN sorgente.jdes t17
SU ( t17.jdes_code = t1.jdes_code )
SINISTRA OUTER JOIN fonte.indy t16
SU ( t16.indy_code = t1.indy_code )
SINISTRA OUTER JOIN sorgente.ora t15
SU ( t15.codice_ora = t1.codice_ora )
SINISTRA OUTER JOIN sorgente.hheader t14
SU ( t14.hheader_code = t1.hheader_code )
SINISTRA OUTER JOIN sorgente.expr t12
SU ( t12.expr_code = t1.expr_code )
SINISTRA OUTER JOIN sorgente.entr t11
SU ( t11.entr_code = t1.entr_code )
SINISTRA OUTER JOIN source.education t10
SU ( t10.education_code = t1.education_code )
SINISTRA OUTER JOIN sorgente.durata t9
SU ( t9.duration_code = t1.duration_code )
SINISTRA OUTER JOIN sorgente.disa t8
SU ( t8.codice_disa = t1.codice_disa )
SINISTRA OUTER JOIN sorgente.classe t7
SU ( t7.class_code = t1.class_code )
SINISTRA OUTER JOIN sorgente.chld t6
SU ( t6.chld_codice = t1.chld_codice )
SINISTRA OUTER JOIN source.born t5
SU ( t5.born_code = t1.born_code )
SINISTRA OUTER JOIN sorgente.età t4
SU ( t4.codice_età = t1.codice_età )
SINISTRA OUTER JOIN sorgente.attività t3
SU ( t3.activity_code = t1.activity_code )
SINISTRA OUTER JOIN sorgente.absn t2
SU ( t1.absn_code = t2.absn_code );
esentato ;
Riepilogo
Gli analisti hanno bisogno di dati in una tabella, organizzata in modo da rendere possibili la visualizzazione e l'analisi. Tuttavia, i dati sono spesso organizzati per il caricamento, la manutenzione e l'archiviazione in molte tabelle (normalizzate) in modo che gli analisti debbano unire e riepilogare molte tabelle in un'unica tabella pronta per l'analisi.
JMP Query Builder è un modo efficace per unire più tabelle dall'interno di JMP. La funzione di anteprima consente all'utente di vedere se il join è definito correttamente prima di eseguire un'operazione di join della tabella che richiede tempo. L'SQL generato può essere distribuito in SAS o in un database, risparmiando molto tempo dalla scrittura manuale di tale codice.
Riferimenti
[UGSCPS] Statistiche sulla forza lavoro – Indagine sulla popolazione attuale – CPS. Estratto il 18 agosto 2016 da http://www.bls.gov/cps/data.htm .
[DOHMH] Risultati dell'ispezione dei ristoranti di DOHMH a New York City. Estratto il 17 agosto 2016 da https://data.cityofnewyork.us/Health/DOHMH-New-York-City-Restaurant-Inspection-Results/xx67-kt59 .
[GREGG] Gregg, X. (2014, 28 maggio). Geocodifica dei nomi dei luoghi. Estratto il 18 agosto 2016 da https://community.jmp.com/docs/DOC-6175 .
