Daniele Valente, PhD, Responsabile prodotti senior JMP, SAS
Giornalista , Vicepresidente vendite e marketing JMP, SAS
Astratto
JMP 13 introduce due nuovi strumenti che semplificano la gestione dei comuni problemi di dati da parte dell'analista. Spesso due o più tabelle di dati sono correlate da una chiave comune, ma sono molto diverse in termini di frequenza di campionamento dei fatti o dimensioni (ad esempio, lunghe rispetto a larghe). Eseguire un join effettivo di queste due (o più) tabelle può creare una tabella risultante che diventa molto grande in memoria. Mentre questo è un fastidio quando le tabelle dei fatti e delle dimensioni sono relativamente compatte, può generare rapidamente una tabella unita che è troppo grande per essere inserita nella memoria. La soluzione è usare 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 join o riepiloghi di tabelle complessi nel database e scrivere SQL, che creano il loro set di problemi, in particolare quando ci sono relazioni complesse come 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 desiderata, Query Builder scrive automaticamente il codice SQL per te, evitandoti la necessità di un noioso lavoro manuale soggetto a errori.
Panoramica delle strutture delle tabelle relazionali
Gli analisti hanno bisogno di dati in un formato che abbia variabili in colonne e osservazioni in righe. I dati potrebbero anche aver bisogno di colonne categoriali che sottoraggruppino chiaramente le osservazioni (ad esempio, livello di reddito, paese, macchina, ecc.). I dati potrebbero anche avere attributi che illuminano ulteriormente le osservazioni (ad esempio, indirizzo, numero di serie, ID cliente, ecc.).
Spesso i dati sorgente per tale analisi sono strutture di dati relazionali archiviate in database. Molti corsi di studio moderni in data science coprono argomenti correlati 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 apprenderli come parte di un'istruzione informale continua. 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 usare Query Builder per generare dati pronti per l'analisi.
La breve trattazione delle strutture dati relazionali contenuta 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 join virtuale in JMP.
Perché avere più di una tabella per memorizzare dati importanti?
Immagina di dover escogitare un modo per archiviare dati sugli acquisti dei clienti dei prodotti della tua azienda. Potresti iniziare elencando tutte le variabili che potrebbero dover essere raccolte, come:
- Data di acquisto
- Importo di acquisto
- Metodo di acquisto (ordine o carta di credito)
- SKU del prodotto
- Descrizione del prodotto
- Nome del cliente
- Indirizzo del cliente
- Numero di telefono del cliente
Questo non è certamente un elenco esaustivo, ma è un buon inizio. Ora pensa a come gestire questi dati. Questa tabella avrà otto colonne e una riga per ogni acquisto. Alcuni campi potrebbero 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 è quello di suddividerla in tre gruppi logici. La prima è la tabella contenente le transazioni o i fatti , come Data di acquisto e Importo di acquisto. La seconda tabella conterrebbe le informazioni sul cliente e la terza le informazioni sul prodotto. Per mantenere i collegamenti tra le colonne di dati, una colonna con informazioni di collegamento dovrebbe essere aggiunta per collegare le tre tabelle. Queste colonne sono chiamate chiavi . Un modo comune per mostrare questo layout è quello di utilizzare un diagramma entità-relazione (ER) . Ogni entità ha un nome di tabella, una chiave o un set di chiavi che identificano in modo univoco ogni riga e un set di attributi o variabili che forniscono informazioni su ogni 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 a Customer ID nella tabella Customers Dimension significa che se si conosce un Customer ID, è possibile trovare in modo univoco quel cliente nella tabella e tutte le informazioni associate. Il Customer ID è anche nella tabella Purchases Fact. Il Customer ID è chiamato Chiave esterna quando è nella tabella Purchases Fact perché può apparire più 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 di prodotto. Per farlo, dovresti semplicemente modificare la tabella Product Dimension e quella modifica si applicherebbe a tutti gli acquisti mai effettuati, un vantaggio definito manutenibilità . Se questa fosse una tabella con la Product Description ripetuta più 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 è:
“La Current Population Survey (CPS) è una delle indagini più antiche, più grandi e più riconosciute negli Stati Uniti. È immensamente importante, poiché fornisce informazioni su molte delle cose che ci definiscono come individui e come società: il nostro lavoro, i nostri guadagni e la nostra istruzione. Oltre a essere la fonte primaria di statistiche mensili sulla forza lavoro, la CPS viene utilizzata per raccogliere dati per una serie di altri studi che tengono informata la nazione sul benessere economico e sociale della sua gente. Ciò avviene aggiungendo una serie di domande supplementari alle domande mensili di base della CPS. 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 a scuola. Le integrazioni vengono solitamente condotte annualmente o semestralmente, ma la frequenza e la ricorrenza di un'integrazione dipendono completamente da ciò che meglio soddisfa le esigenze dello sponsor dell'integrazione".
Questi dati sono disponibili per il download come 36 file di testo, che sono 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 dei dati statistici sulla forza lavoro del CPS
Per utilizzare Query Builder, sarà necessario definire una tabella primaria (fatto) e una o più tabelle secondarie (dimensione ).
La tabella dei fatti per i dati CPS è chiamataTutti i dati.jmp. La tabella ha più di 5 milioni di righe ma solo cinque colonne. Le colonne hanno una colonna "series_id", date e una colonna "valore". Per dare un senso ai dati, devi scoprire cosaserie_id.jmp significa. Il diagramma ER nella Figura 2 mostra che "series_id" è correlato aserie.jmptabella. Quindi, apri entrambe le tabelle in JMP e usa Query Builder per definire il join.
In JMP, selezionaTutti i dati.jmpcome la tabella primaria (dei fatti) eserie.jmpcome tabella secondaria (dimensione) (Figura 3). JMP cercherà automaticamente le chiavi adatte e imposterà il join, ma dovresti verificarlo cliccando 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 quelle come chiave, solo a "series_id", quindi quella relazione chiave dovrebbe essere rimossa.
Figura 3. Query Builder per l'unione diTutti i dati.jmpESerie.jmp
Ora è necessario definire le colonne nella tabella unita (Figura 4). Per farlo, selezionaTutti i dati.jmpin alto a sinistra e seleziona le colonne necessarie da quella tabella. Elimina “series_id” ora, perché non ti servirà quella chiave nella tabella risultante (serie e dati.jmp).
Figura 4. Query Builder per unirsiserie e dati.jmpa tutti “_codice.jmp” tavoli
Nota cheserie e dati.jmpè circa cinque volte più grande delTutti i dati.jmptabella. Questa inflazione è dovuta ai valori ripetuti di tutti i campi “_code”. Quindi, è chiaro che l'archiviazione dei dati in 36 tabelle riduce sostanzialmente i requisiti di archiviazione . Quindi, selezionaserie e dati.jmp come la tabella primaria e tutti i“_codice.jmp” tabelle come tabelle secondarie (Figura 5).
Figura 5. Query Builder per unire tutti i “_codice.jmp”
Crea la query solo con i campi “_text” dalle tabelle “_code” perché non hai più bisogno delle variabili chiave. Utilizzando Cols > Columns Viewer in JMP, puoi facilmente ottenere un riepilogo delle 42 colonne nella tabellaJoin.jmp completo.Avrai ancora 5,7 milioni di righe, che è lo stesso diTutti i dati.jmp, ma ora hai i campi di testo che descrivono i dati. Anche se la tabellaJoin completo.jmpè ancora sei volte più grande del tavoloTutti i dati.jmp,Ora hai una tabella utile per l'analisi.
Utilizzare Graph Builder per tracciare il trend della disoccupazione nel settore manifatturiero daJoin completo.jmp. Nella Figura 6, la rottura di questo settore durante la recessione è mostrata dalla 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. Sono stati aggiunti più di 300.000 posti di lavoro nel settore manifatturiero automobilistico dal 2010 al 2015.
Figura 6. Generatore di grafici che mostra i dati delle statistiche sulla forza lavoro del CPS
Caso 2: Dati di ispezione del ristorante
Questo caso esplora l'utilizzo di join virtuale e JMP Query Builder per analizzare i risultati dell'ispezione dei ristoranti DOHMH di New York City[DOHMH]Immagina di essere un nuovo ispettore al lavoro e di esplorare alcuni dati storici per vedere cosa rivelano. Dal sito webhttps://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 del 17 luglio 2016 genera un file da 163,3 MB che include 448.149 record.
Questi dati hanno una colonna DATA ISPEZIONE, che è un M/G/A dell'evento di ispezione. Per vedere quanti anni sono inclusi in questi dati, fai clic con il pulsante destro del mouse e usa una 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 dati mancanti, qualcosa che dovrai affrontare. Non è un problema modificare in modo distruttivo questi dati (dato che JMP è usato come sandbox qui e i dati reali sono sempre archiviati sul server); quindi usa l'utilità Recode per cambiare 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. Cambia questo vecchio valore in • eliminando la stringa e quindi cliccando Fatto -> In Place. Poiché la DATA RECORD è la data in cui i dati sono stati estratti e non è rilevante per questa analisi, elimina la colonna.
Questo documento riguarda il join virtuale e il Query Builder, quindi potresti chiederti perché stiamo esaminando una tabella denormalizzata. Sembra esserci un'opportunità per normalizzare questi dati. In particolare, da questi dati grezzi è assente la posizione geocodificata dei singoli ristoranti, un'attività che può essere eseguita con un componente aggiuntivo JMP in seguito. Poiché questo processo è costoso dal punto di vista computazionale, ha senso geocodificare solo posizioni univoche, che potrebbero avere più ispezioni in questi dati. Inoltre, sembra esserci un'opportunità per avere una tabella aggiuntiva di violazioni, che sono molto meno delle ispezioni univoche.
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, usaDOHMH_New_York_City_Restaurant_Inspection_Results.jmpcome Tabella primaria senza tabelle secondarie a questo punto. In Query Builder, c'è una scheda denominata Sample. Attivando la casella di controllo per "Sample this results set", puoi scegliere First N rows o Random N rows. Prendi un campione casuale del 10 percento di questi dati, quindi inserisci 44.815 nelle righe Random N. Aggiungi tutte le colonne alla sezione Include Columns e quindi ispeziona il codice SQL. Query Builder ha generato automaticamente il codice SQL per eseguire questa query:
SELEZIONA t1.CAMIS, t1.DBA, t1.BORO, t1.EDIFICIO,
t1.VIA, t1.CODICE POSTALE, t1.TELEFONO, t1."DESCRIZIONE CUCINA",
t1."DATA DI ISPEZIONE", t1."AZIONE", t1."CODICE DI VIOLAZIONE", t1."DESCRIZIONE DELLA VIOLAZIONE",
t1."SEGNALE CRITICO", t1.PUNTEGGIO, t1.VOTO, t1."DATA VOTO",
t1."TIPO DI ISPEZIONE", t1."Anno[DATA DI ISPEZIONE]"
DA DOHMH_Risultati_dell'ispezione_del_ristorante_di_New_York_City t1
ORDINA PER RANDOM() LIMITE 44815;
Dopo l'utilizzol'ordine casuale () funzione per il nostro campionamento, questa query genererà il sottoinsieme appropriato dei dati. Salvalo come sottoinsieme e quindi separa i dati demografici del ristorante e i codici di violazione. Qui può essere utilizzato anche Query Builder. Inizia con i codici di violazione. Di nuovo, hai solo bisogno di una tabella primaria. Trascina e rilascia VIOLATION CODE e VIOLATION DESCRIZIONE nell'elenco delle variabili e quindi trascina di nuovo VIOLATION CODE, che ti consente di aggregare per conteggio e generare la tabella con le proprietà desiderate. Modifica 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. Puoi anche scegliere di ordinare automaticamente in base alla colonna aggregata appena creata trascinando VIOLATION COUNT nel ruolo Ordina per, mostrato nella Figura 8.
Figura 8. Colonna di aggregazione rinominata Conteggio violazioni, con una proprietà Ordina per
Con solo 88 codici di violazione univoci, questa query risultante è molto più compatta. Dopo aver denominato questa tabella D-Codici di violazione.jmp , questo è un buon momento per usare Graph Builder per esplorare quali codici hanno più record. Trascina VIOLATION DESCRIZIONE sull'asse X e VIOLATION CONTEGGIO sull'asse Y. Quindi fai clic con il pulsante destro del mouse su VIOLATION DESCRIZIONE e Ordina per VIOLATION CONTEGGIO (decrescente). Per concentrarti solo sulle categorie principali, puoi usare il filtro Dati locali su VIOLATION CONTEGGIO con categorie di violazione, che hanno più di 2.500 record univoci (Figura 9).
Figura 9. Conteggi delle violazioni più frequenti (>2500 record univoci nella tabella campionata)
Allontanandoci per ora dalla tabella delle violazioni, puoi concentrarti sui dati demografici unici del ristorante. A questo punto, puoi anche eliminare la descrizione della violazione, il che salva un certo numero di righe duplicate nella tabella dei fatti principale. Utilizza il CODICE VIOLAZIONE, che è un modo molto più compatto per organizzare questi dati (stringhe di tre lettere anziché stringhe lunghe una frase).
Di nuovo, usa Query Builder per eliminare i dati demografici unici dei ristoranti. È molto probabile che ci sia più di una pizzeria con lo stesso nome a New York, ma Query Builder può gestire questa situazione. La colonna CAMIS funziona come un ID che può essere usato per identificare ristoranti unici. 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, ZIPCODE, PHONE e CUISINE DESCRIZIONE. Infine, calcola una colonna chiamata ADDRESS per il geocodificatore, che verrà eseguita come uno script post-query. Esegui la query e quindi utilizza una colonna formula con la seguente formula:
:COSTRUZIONE ||" "|| :STRADA ||" "|| :BORO ||"NY,"||Cartello( :CAP )
Questa formula mette insieme l'indirizzo corretto. Digitando:INDIRIZZO <<ottenere lo script; 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 e quindi genera una colonna che dividerà i dati in 20 gruppi per una migliore interfaccia con il geocodice. 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 delle query e rieseguire la query. Salva questa tabella dati comeD-Ristoranti.jmp. Come passaggio finale, elimina le colonne extra dalla tabella dei fatti attuale, tra cui: DBA, BORO, EDIFICIO, VIA, CODICE POSTALE, TELEFONO e DESCRIZIONE DELLA CUCINA.
Salva questa tabella come 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 suddividerloD-Ristoranti per gruppo usando Tabelle > Sottoinsieme. La funzionalità Sottoinsieme per di questa piattaforma, mostrata nella Figura 10, è utile qui.
Figura 10. Piattaforma di tabelle di sottoinsieme per la suddivisione per gruppo di ristoranti
Le 20 tabelle appena create possono essere geocodificate individualmente usando il componente aggiuntivo. Il campo indirizzo aiuta a determinare la latitudine e la longitudine corrette. E infine, salva i risultati nella stessa tabella dati.
Per riportare la tabella dati a una tabella con una sola dimensione e posizioni, utilizzare la funzione Tabelle > Concatena, combinando i 20 gruppi; è denominata D-RistorantiwLocation.jmp.
Ora che hai suddiviso questa tabella utilizzando Query Builder, puoi ricostruirla utilizzando un join virtuale.
Per prima cosa, iniziamo con le nostre tabelle a due dimensioni: Ristoranti-wLocation.jmp EViolationCodes.jmp. Facendo clic con il tasto destro del mouse su VIOLATION CODE e selezionando Link ID verrà impostato l'inizio del virtual join. Nota che nell'elenco delle colonne compare una piccola icona a forma di chiave. Passa alla tabella Restaurants e fai lo stesso con CAMIS. Per concludere il virtual join, passa alla tabella fact, 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 fisicamente unire le tabelle in memoria. L'unione virtuale può anche essere programmata tramite una proprietà di colonna:
Per il riferimento del collegamento:
Imposta Proprietà("Riferimento collegamento", Tabella di riferimento("D(f)-Ristoranti-wLocation.jmp"));
Per l'ID collegamento:
Imposta Proprietà("ID collegamento", 1);
Figura 11. Unione virtuale
La Figura 11 mostra che è possibile accedere alle colonne in entrambe le tabelle dimensionali senza appesantire la tabella dei fatti.
Infine, crea una dashboard per visualizzare ed esplorare questi dati sfruttando le colonne unite virtualmente.
La Figura 12 mostra come Dashboard Builder visualizza una raccolta di cinque grafici. Per utilizzare due dei grafici come filtri di selezione, inizia con il modello Hierarchical Filter in Dashboard Builder, utilizzando CRITICAL FLAG e BORO come Filter e Hierarchical Filter. Quindi, 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 Dashboard Final NYC Inspection
Questo è solo un esempio del tipo di visualizzazione che puoi realizzare con questi dati, sfruttando le tabelle collegate fornite dal virtual join. I dati geocodificati consentono anche, ad esempio, di approfondire le posizioni dei ristoranti in base alla cucina (Figura 13).
Figura 13. Ristoranti geocodificati colorati in base al livello visualizzato 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 il codice SQL creato da Query Builder per l'unione di tutte le tabelle dimensionali alla tabella unita diserie.jmpETutti i dati.jmp(dal caso 1) e l'SQL dall'unione diJoin completo.jmpe tutti i_codice.jmptavoli. Ilnomelibreriaistruzione, riferimenti libname associati sulle tabelle eprocedere codice sql sono state aggiunte istruzioni. Il resto del codice è stato generato da Query Builder.
Nota che la maggior parte del codice è un elenco delle colonne all'interno delle istruzioni SELECT. Utilizzare 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?
nomelibreria fonte 'la posizione del tuo file';
procedere codice sql;
creare tavoloorigine.dataNseriesCOME
SELEZIONAREt1.anno, t1.periodo, t1.valore, t1.codici_nota_a_piede,
t2.lfst_code, t2.periodicity_code, t2.series_title, t2.absn_code,
t2.codice_attività, t2.codice_età, t2.codice_classe, t2.codice_durata,
t2.codice_istruzione, t2.codice_entrata, t2.codice_espressione, t2.codice_intestazione,
t2.codice_ora, t2.codice_indy, t2.codice_jdes, t2.codice_look,
t2.codice_mari, t2.codice_mjhs, t2.codice_occupazione, t2.codice_orig,
codice_t2.pcts, codice_t2.race, codice_t2.rjnw, codice_t2.rnlf,
codice t2.rwns, codice t2.seek, codice t2.sexs, codice t2.tdat,
codice_t2.vets, codice_t2.wkst, codice_t2.born, codice_t2.chld,
t2.disa_code, t2.seasonal, t2.footnote_codes, t2.begin_year,
t2.inizio_periodo, t2.fine_anno, t2.fine_periodoDAorigine.Tutti i dati t1
SINISTRAJOIN ESTERNO origine.serie t2
SU ( t1.serie_id = t2.serie_id ) ;
SELEZIONAREt1.anno, t1.periodo, t1.valore, t1.titolo_serie,
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_testo, t31.sexs_testo, t30.seek_testo, t29.rwns_testo,
t28.rnlf_testo, t27.RJNW_TESTO, t26.race_testo, t25.periodicità_testo,
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.testo_classe, t6.testo_bambino, t5.testo_nato, t4.testo_età,
t3.attività_testo, t2.absn_testoDAorigine.dataNseries t1
SINISTRAJOIN ESTERNO fonte.nota a piè di pagina t13
SU ( t1.footnote_codes = t13.footnote_code )
SINISTRAJOIN ESTERNO origine.wkst t34
SU ( t34.wkst_code = t1.wkst_code )
SINISTRAJOIN ESTERNO source.vets t33
SU ( t33.vets_code = t1.vets_code )
SINISTRAJOIN ESTERNO origine.tdat t32
SU ( t32.tdat_code = t1.tdat_code )
SINISTRAJOIN ESTERNO source.sexs t31
SU ( t31.codice_sexs = t1.codice_sexs )
SINISTRAJOIN ESTERNO origine.seek t30
SU ( t30.seek_code = t1.seek_code )
SINISTRAJOIN ESTERNO origine.rwns t29
SU ( t29.rwns_codice = t1.rwns_codice )
SINISTRAJOIN ESTERNO origine.rnlf t28
SU ( t28.rnlf_codice = t1.rnlf_codice )
SINISTRAJOIN ESTERNO origine.rjnw t27
SU ( t27.RJNW_CODE = t1.rjnw_code )
SINISTRAJOIN ESTERNO origine.race t26
SU ( t26.codice_gara = t1.codice_gara )
SINISTRAJOIN ESTERNO origine.periodicità t25
SU ( t25.periodicity_code = t1.periodicity_code )
SINISTRAJOIN ESTERNO origine.pcts t24
SU ( t24.pcts_codice = t1.pcts_codice )
SINISTRAJOIN ESTERNO origine.orig t23
SU ( t23.orig_code = t1.orig_code )
SINISTRAJOIN ESTERNO origine.occupazione t22
SU ( t22.codice_occupazione = t1.codice_occupazione )
SINISTRAJOIN ESTERNO origine.mjhs t21
SU ( t21.mjhs_codice = t1.mjhs_codice )
SINISTRAJOIN ESTERNO source.mari t20
SU ( t20.mari_code = t1.mari_code )
SINISTRAJOIN ESTERNO origine.guarda t19
SU ( t19.look_code = t1.look_code )
SINISTRAJOIN ESTERNO origine.lfst t18
SU ( t18.lfst_codice = t1.lfst_codice )
SINISTRAJOIN ESTERNO origine.jdes t17
SU ( t17.jdes_code = t1.jdes_code )
SINISTRAJOIN ESTERNO origine.indy t16
SU ( t16.indy_code = t1.indy_code )
SINISTRAJOIN ESTERNO origine.ora t15
SU ( t15.codice_ora = t1.codice_ora )
SINISTRAJOIN ESTERNO origine.hheader t14
SU ( t14.hheader_code = t1.hheader_code )
SINISTRAJOIN ESTERNO origine.expr t12
SU ( t12.expr_codice = t1.expr_codice )
SINISTRAJOIN ESTERNO origine.entr t11
SU ( t11.codice_di_ingresso = t1.codice_di_ingresso )
SINISTRAJOIN ESTERNO origine.istruzione t10
SU ( t10.codice_istruzione = t1.codice_istruzione )
SINISTRAJOIN ESTERNO origine.durata t9
SU ( t9.duration_code = t1.duration_code )
SINISTRAJOIN ESTERNO origine.disa t8
SU ( t8.codice_disa = t1.codice_disa )
SINISTRAJOIN ESTERNO origine.classe t7
SU ( t7.codice_classe = t1.codice_classe )
SINISTRAJOIN ESTERNO origine.chld t6
SU ( t6.chld_code = t1.chld_code )
SINISTRAJOIN ESTERNO origine.born t5
SU ( t5.codice_nato = t1.codice_nato )
SINISTRAJOIN ESTERNO origine.ages t4
SU ( t4.ages_code = t1.ages_code )
SINISTRAJOIN ESTERNO origine.attività t3
SU ( t3.codice_attività = t1.codice_attività )
SINISTRAJOIN ESTERNO origine.absn t2
SU ( t1.codice_absn = t2.codice_absn );
esentato;
Riepilogo
Gli analisti hanno bisogno di dati in una tabella, organizzati in modo da rendere possibile la visualizzazione e l'analisi. Tuttavia, i dati sono spesso organizzati per essere caricati, gestiti e archiviati in numerose tabelle (normalizzate), cosicché gli analisti sono sfidati a unire e riassumere numerose tabelle in un'unica tabella pronta per l'analisi.
JMP Query Builder è un modo potente per unire più tabelle da JMP. La funzionalità di anteprima consente all'utente di vedere se l'unione è definita correttamente prima di eseguire un'operazione di unione di tabelle che richiede molto tempo. Il codice SQL generato può essere distribuito in SAS o in un database, risparmiando molto tempo rispetto alla scrittura manuale di tale codice.
Riferimenti
[UGSCPS] Statistiche sulla forza lavoro – Indagine sulla popolazione attuale – CPS. Recuperato il 18 agosto 2016 dahttp://www.bls.gov/cps/data.htm.
[DOHMH] Risultati dell'ispezione dei ristoranti DOHMH di New York City. Recuperato il 17 agosto 2016 dahttps://data.cityofnewyork.us/Health/DOHMH-New-York-City-Restaurant-Inspection-Results/xx67-kt59.
[GREGG]Gregg, X. (2014, 28 maggio). Geocoding Place Names. Recuperato il 18 agosto 2016 dahttps://community.jmp.com/docs/DOC-6175.
