daniel valente , PhD, JMP Gerente sénior de productos, SAS
Jon Weisz , JMP Vicepresidente de Ventas y Marketing, SAS
Abstracto
JMP 13 presenta dos nuevas herramientas que facilitan al analista el manejo de problemas comunes de datos. A menudo, dos o más tablas de datos están relacionadas por una clave común, pero son muy diferentes en términos de frecuencia de muestreo o dimensiones (p. ej., largo versus ancho). Hacer una combinación real de estas dos (o más) tablas puede crear una tabla resultante que se vuelve muy grande en la memoria. Si bien esto es una molestia cuando las tablas de hechos y dimensiones son relativamente compactas, puede generar rápidamente una tabla unida que es demasiado grande para caber en la memoria. La solución es utilizar una combinación virtual, que conserva la relación combinada sin crear realmente la tabla combinada, lo que enriquece de manera efectiva la tabla de hechos sin sobrecargarla. Los analistas a menudo se ven en la necesidad de realizar combinaciones de tablas complejas o resúmenes en la base de datos y escribir SQL, lo que crea su propio conjunto de problemas, especialmente cuando hay relaciones complejas, como dimensiones que cambian lentamente. JMP Query Builder sirve como una herramienta sencilla de generación y escritura de SQL, cuyo código puede luego ejecutarse en una base de datos. Después de arrastrar y soltar la consulta correcta y deseable, Query Builder escribe automáticamente el código SQL por usted, evitando la necesidad de un tedioso trabajo manual y propenso a errores.
Descripción general de las estructuras de tablas relacionales
Los analistas necesitan datos en un formato que tenga variables en columnas y observaciones en filas. Los datos también pueden necesitar columnas categóricas que claramente subagrupan las observaciones (por ejemplo, nivel de ingresos, país, máquina, etc.). Los datos también pueden tener atributos que iluminen más las observaciones (p. ej., dirección, número de serie, identificación del cliente, etc.).
A menudo, los datos de origen para dicho análisis son estructuras de datos relacionales almacenadas en bases de datos. Muchos cursos de estudio modernos en ciencia de datos cubren temas relacionados con estructuras de datos relacionales, bases de datos y SQL. Pero la mayoría de los ingenieros, científicos y estadísticos no están expuestos a estos temas en un entorno académico, por lo que deben aprender sobre ellos como parte de la educación informal continua. JMP Query Builder ofrece a los analistas un puente entre las estructuras de datos relacionales y los datos listos para el análisis. Al aprender algunos términos y conceptos, los analistas pueden usar Query Builder para generar datos que estén listos para el análisis.
La breve discusión de las estructuras de datos relacionales en este documento no pretende reemplazar un estudio exhaustivo del tema; más bien presenta los términos y las definiciones que se usan cuando se trabaja con Query Builder y sus capacidades de unión virtual en JMP.
¿Por qué tener más de una tabla para almacenar datos importantes?
Imagine que necesita idear una forma de almacenar datos sobre las compras de los productos de su empresa por parte de los clientes. Primero puede comenzar enumerando todas las variables que pueden necesitar recopilarse, como:
- Fecha de compra
- Monto de la compra
- Método de compra (PO o CC)
- SKU del producto
- Descripción del Producto
- Nombre del cliente
- Dirección del cliente
- Número de teléfono del cliente
Ciertamente, esta no es una lista completa, pero es un buen comienzo. Ahora piense en mantener estos datos. Esta tabla tendrá ocho columnas y una fila para cada compra. Algunos campos pueden tener muchos valores distintos, como Monto de compra o Fecha de compra. Otros campos tendrán muchos menos valores distintos y muchos valores repetidos, como SKU del producto y Descripción.
Una forma común de reducir el tamaño de la tabla es dividir la tabla en tres grupos lógicos. La primera es la tabla que contiene transacciones o hechos , como la fecha de compra y el monto de la compra. La segunda tabla tendría la información del cliente y la tercera tendría la información del producto. Para mantener los vínculos entre las columnas de datos, habría que agregar una columna con información de vínculo para relacionar las tres tablas. Estas columnas se llaman llaves . Una forma común de mostrar este diseño es emplear un diagrama entidad relación (ER) . Cada entidad tiene un nombre de tabla, una clave o conjunto de claves que identifican de manera única cada fila y un conjunto de atributos o variables que brindan información sobre cada fila. El diagrama ER para la fecha de compra del cliente se muestra en la Figura 1.
Figura 1. Diagrama de relación de entidad para datos de compra de clientes
El símbolo de llave junto al ID de cliente en la tabla Dimensión de clientes significa que si conoce un ID de cliente, puede encontrar de forma única a ese cliente en la tabla y toda la información asociada. El ID de cliente también se encuentra en la tabla de hechos de compras. El ID de cliente se denomina clave externa cuando se encuentra en la tabla de hechos de compras porque puede aparecer muchas veces y define de forma única filas en una tabla externa a la que aparece.
Con el diseño de la Figura 1, es muy fácil ver cómo actualizar la descripción de un producto. Para hacer esto, solo tendría que editar la tabla Dimensión del producto y ese cambio se aplicaría a todas las compras realizadas, un beneficio denominado mantenibilidad . Si esta fuera una tabla con la descripción del producto repetida muchas veces, tendría que editar muchas filas, lo que inevitablemente conduciría a errores y problemas de calidad de datos.
Caso 1: Encuesta de Población Actual
Ahora veamos un ejemplo con Query Builder. El gobierno de los EE. UU. recopila una gran cantidad de datos interesantes con la Encuesta de población actual (CPS) [USGCPS]. El CPS es:
“ La Encuesta de Población Actual (CPS) es una de las encuestas más antiguas, más grandes y mejor reconocidas de los Estados Unidos. Es inmensamente importante, brinda información sobre muchas de las cosas que nos definen como individuos y como sociedad: nuestro trabajo, nuestras ganancias y nuestra educación. Además de ser la principal fuente de estadísticas mensuales de la fuerza laboral, la CPS se utiliza para recopilar datos para una variedad de otros estudios que mantienen a la nación informada sobre el bienestar económico y social de su gente. Esto se hace agregando un conjunto de preguntas complementarias a las preguntas básicas mensuales de CPS. Las consultas complementarias varían de un mes a otro y cubren una amplia variedad de temas, como manutención infantil, voluntariado, cobertura de seguro médico e inscripción escolar. Los suplementos generalmente se llevan a cabo anualmente o cada dos años, pero la frecuencia y la recurrencia de un suplemento dependen completamente de lo que mejor satisfaga las necesidades del patrocinador del suplemento”.
Estos datos están disponibles para descargar como 36 archivos de texto, que se abren fácilmente en JMP ya que los archivos son archivos de texto delimitados por tabulaciones. Mirando las tablas JMP, se creó un diagrama ER (Figura 2) para informar el trabajo en Query Builder.
Figura 2. Diagrama ER para las tablas de datos estadísticos de la fuerza laboral de CPS
Para usar Query Builder, deberá definir una tabla principal (hecho) y una tabla secundaria (dimensión ).
La tabla de hechos para los datos de CPS se llama AllData.jmp . La tabla tiene más de 5 millones de filas pero solo cinco columnas. Las columnas tienen un "series_id", fechas y una columna de "valor". Para dar algún sentido a los datos, es necesario averiguar cuál es el serie_id.jmp medio. El diagrama ER en la Figura 2 muestra que "series_id" está relacionado con el serie.jmp mesa. A continuación, abra ambas tablas en JMP y utilice Query Builder para definir la unión.
En JMP, seleccione AllData.jmp como la tabla primaria (hechos) y serie.jmp como la tabla Secundaria (dimensión) (Figura 3). JMP buscará automáticamente las claves que encajen y configurará la unión, pero debe verificarlo haciendo clic en el diagrama de Venn a la derecha de la tabla de series. Query Builder encontró "footnote_codes" en ambas tablas, pero no desea unirse a ellos como clave, solo "series_id", por lo que se debe eliminar esa relación clave.
Figura 3. Generador de consultas para la unión de AllData.jmp y Serie.jmp
Ahora necesita definir las columnas en la tabla unida (Figura 4). Para hacer eso, seleccione AllData.jmp en la parte superior izquierda y seleccione las columnas necesarias de esa tabla. Suelte "series_id" ahora, porque no necesitará esa clave en la tabla resultante ( serie y data.jmp ).
Figura 4. Generador de consultas para unirse serie y data.jmp a todos " _codigo.jmp " mesas
Darse cuenta de serie y data.jmp es unas cinco veces mayor que el AllData.jmp mesa. Esta inflación se debe a los valores repetidos de todos los campos “_code”. Claramente, el almacenamiento de los datos en 36 tablas reduce el almacenamiento requisitos sustancialmente. A continuación, seleccione serie y data.jmp como la tabla principal y todos los “_código.jmp ” tablas como tablas secundarias (Figura 5).
Figura 5. Generador de consultas para unir todos los “ _codigo.jmp ”
Cree la consulta solo con los campos "_text" de las tablas "_code" porque ya no necesita las variables clave. Con Cols > Columns Viewer en JMP, puede obtener fácilmente un resumen de las ahora 42 columnas en la tabla Unión completa.jmp. Seguirá teniendo 5,7 millones de filas, que es lo mismo que AllData.jmp , pero ahora tiene los campos de texto que describen los datos. Aunque la mesa Unión completa.jmp sigue siendo seis veces más grande que la mesa AllData.jmp, ahora tiene una tabla útil para el análisis.
Use Graph Builder para trazar la tendencia del desempleo en la industria manufacturera desde Unión completa.jmp . En la Figura 6, la interrupción en este sector durante la recesión se muestra con la línea de tendencia roja. Los niveles de desempleo en 2016 han vuelto a los niveles observados en 2006-2007. La línea de tendencia verde muestra los niveles de empleo del sector de fabricación de automóviles. Se agregaron más de 300,000 puestos de trabajo en la fabricación de automóviles entre 2010 y 2015.
Figura 6. Graph Builder que muestra datos de las estadísticas de la fuerza laboral de CPS
Caso 2: Datos de inspección del restaurante
Este caso explora el uso de unión virtual y JMP Query Builder para analizar los resultados de la inspección de restaurantes de la ciudad de Nueva York del DOHMH [DOHMH] . Imagínese como un nuevo inspector en el trabajo y explorando algunos datos históricos para ver qué revelan los datos. Desde el sitio web https://data.cityofnewyork.us/Health/DOHMH-New-York-City-Restaurant-Inspection-Results/xx67-kt59 , puede descargar una versión .csv de estos datos que se pueden abrir fácilmente en JMP. La descarga completa del 17 de julio de 2016 genera un archivo de 163,3 MB que incluye 448.149 registros.
Estos datos tienen una columna FECHA DE INSPECCIÓN, que es un M/D/Y del evento de inspección. Para ver cuántos años se incluyen en estos datos, haga clic con el botón derecho y use Nueva columna de fórmula > Fecha y hora > Año. Convertir eso de continuo a nominal y luego Analizar > Distribución se muestra en la Figura 7. Es probable que el nivel 1900 sea un código para datos faltantes, algo que necesitará abordar. No es un problema editar estos datos de forma destructiva (ya que JMP se usa aquí como una caja de arena y los datos reales siempre se almacenan en el servidor); luego use la utilidad Recode para cambiar estos niveles a faltantes.
Figura 7. Fechas de inspección para el conjunto de datos completo
En la ventana de recodificación, hay 1.151 registros que son 01/01/1900. Cambie este valor anterior a • eliminando la cadena y luego haciendo clic en Listo -> In situ. Dado que la FECHA DE REGISTRO es la fecha en que se extrajeron los datos y no es importante para este análisis, elimine la columna.
Este documento trata sobre la combinación virtual y el generador de consultas, por lo que es posible que se pregunte por qué estamos viendo una tabla desnormalizada. Parece haber una oportunidad para normalizar estos datos. Notablemente ausente de estos datos sin procesar está la ubicación geocodificada de los restaurantes individuales, una tarea que se puede realizar con un complemento de JMP más adelante. Dado que este proceso es costoso computacionalmente, tiene sentido geocodificar solo ubicaciones únicas, que pueden tener múltiples inspecciones en estos datos. Además, parece haber una oportunidad de tener una tabla adicional de infracciones, que son mucho menos que las inspecciones únicas.
Antes de dividir los datos, tome una muestra de estos datos para que los números sean más manejables para su ejercicio de exploración.
El muestreo es algo que se puede realizar fácilmente con Query Builder. Tablas > JMP Query Builder abrirá el cuadro de diálogo de inicio. Debido a que no está realizando una combinación en este caso, use DOHMH_Nueva_York_Ciudad_Restaurante_Inspección_Resultados.jmp como la Mesa Principal sin Mesas Secundarias en este punto. En Query Builder, hay una pestaña llamada Muestra. Al activar la casilla de verificación para "Muestra este conjunto de resultados", puede elegir Primero norte filas o aleatorio norte filas Tome una muestra aleatoria del 10 por ciento de estos datos, así que ponga 44,815 en el Aleatorio norte filas Agregue todas las columnas a la sección Incluir columnas y luego inspeccione el SQL. Query Builder ha generado automáticamente el SQL para realizar esta consulta:
SELECCIONE t1.CAMIS, t1.DBA, t1.BORO, t1.EDIFICIO,
t1.CALLE, t1.CÓDIGO POSTAL, t1.TELÉFONO, t1."DESCRIPCIÓN DE LA COCINA",
t1."FECHA DE INSPECCIÓN", t1."ACCIÓN", t1."CÓDIGO DE INFRACCIÓN", t1."DESCRIPCIÓN DE LA INFRACCIÓN",
t1."BANDERA CRÍTICA", t1.PUNTUACIÓN, t1.GRADO, t1."FECHA DE GRADO",
t1."TIPO DE INSPECCIÓN", t1."Año[FECHA DE INSPECCIÓN]"
DESDE DOHMH_Nueva_York_Ciudad_Restaurante_Inspección_Resultados t1
ORDEN POR LÍMITE ALEATORIO() 44815;
Después de usar el Orden Al Azar () función para nuestro muestreo, esta consulta generará el subconjunto apropiado de los datos. Guarde esto como un subconjunto y luego separe los datos demográficos del restaurante y los códigos de infracción. El Generador de consultas también se puede utilizar aquí. Comience con los códigos de infracción. Nuevamente, solo necesita una tabla principal. Arrastre y suelte CÓDIGO DE VIOLACIÓN y DESCRIPCIÓN DE VIOLACIÓN en la lista de variables y luego vuelva a arrastrar el CÓDIGO DE VIOLACIÓN, lo que le permite agregar por conteo y generar la tabla que tiene las propiedades deseadas. Cambie el nombre de JMP de la columna de agregación a CONTADOR DE VIOLACIONES. Esta capacidad de generar un alias para una columna o columna derivada es una característica poderosa de Query Builder. También puede optar por ordenar automáticamente por la columna agregada recién creada arrastrando el RECUENTO DE VIOLACIONES a la función Ordenar por, que se muestra en la Figura 8.
Figura 8. Columna de agregación renombrada como Recuento de infracciones, con una propiedad Ordenar por
Con solo 88 códigos de infracción únicos, esta consulta resultante es mucho más compacta. Después de nombrar esta tabla D-ViolationCodes.jmp , t ste es un buen momento para usar Graph Builder para explorar qué códigos tienen la mayor cantidad de registros. Arrastre DESCRIPCIÓN DE VIOLACIÓN al eje X y RECUENTO DE VIOLACIÓN al eje Y. A continuación, haga clic con el botón derecho en DESCRIPCIÓN DE VIOLACIÓN y Ordenar por CONTADOR DE VIOLACIÓN (descendente). Para centrarse solo en las categorías principales, puede utilizar el filtro de datos locales en CONTADOR DE VIOLACIONES con categorías de infracción, que tienen más de 2500 registros únicos (Figura 9).
Figura 9. Principales recuentos de infracciones (>2500 registros únicos en la tabla de muestra)
Alejándose de la tabla de infracciones por ahora, puede concentrarse en los datos demográficos únicos del restaurante. En este punto, también puede eliminar la descripción de la infracción, lo que guarda una cantidad de filas duplicadas en la tabla principal de hechos. Utilice el CÓDIGO DE VIOLACIÓN, que es una forma mucho más compacta de organizar estos datos (cadenas de tres letras frente a cadenas de una oración).
Nuevamente, use Query Builder para despegar los datos demográficos únicos del restaurante. Es muy probable que haya más de una pizzería con el mismo nombre en la ciudad de Nueva York, pero Query Builder puede manejar esa situación. La columna CAMIS funciona como una identificación que se puede usar para identificar restaurantes únicos. En el Generador de consultas, arrastre CAMIS dos veces, una de las cuales debe agregarse por conteo y cambiar el nombre de CONTADOR DE INSPECCIÓN. El resto de los datos demográficos son DBA, BORO, EDIFICIO, CALLE, CÓDIGO POSTAL, TELÉFONO y DESCRIPCIÓN DE LA GASTRONOMÍA. Finalmente, calcule una columna llamada DIRECCIÓN para el geocodificador, que se realizará como un script posterior a la consulta. Ejecute la consulta y luego utilice una columna de fórmula con la siguiente fórmula:
:EDIFICIO || " " || :CALLE || " " || :BORO || "Nueva York" || Carbonizarse ( :CÓDIGO POSTAL )
Esta fórmula reúne la dirección correcta. Mecanografía :DIRECCIÓN << obtener guión ; en un editor de secuencias de comandos producirá el JSL necesario para generar la columna para una secuencia de comandos posterior a la consulta. Copie y pegue ese código en la pestaña correspondiente en Query Builder y luego genere una columna que dividirá los datos en 20 grupos para una mejor interfaz con el geocódigo. Después de generar una nueva columna llamada Group and Initialize Data: Sequence Data, From 1 to 20, Step 1, Repeat 1, puede obtener el script y pegarlo en el script posterior a la consulta. Ahora que ambas columnas son scripts, puede eliminar la tabla de consulta y volver a ejecutar la consulta. Guarde esta tabla de datos como D-Restaurantes.jmp . Como paso final, elimine las columnas adicionales de la tabla de hechos ahora, que incluyen: DBA, BORO, EDIFICIO, CALLE, CÓDIGO POSTAL, TELÉFONO y DESCRIPCIÓN DE LA GASTRONOMÍA.
Guardar esta tabla como F-Inspecciones.jmp . Ahora está listo para geocodificar los grupos de restaurantes con un complemento creado por Xan Gregg disponible en JMP File Exchange [GREGG], que usa OpenStreetMaps.org para geocodificar ubicaciones. Este servicio es computacionalmente costoso y propenso a fallas, por lo que es mejor dividirlo D-Restaurantes por grupo usando Tablas > Subconjunto. La funcionalidad Subconjunto por de esta plataforma, que se muestra en la Figura 10, es útil aquí.
Figura 10. Plataforma de tablas de subconjuntos para dividir por grupo de restaurante
Las 20 tablas recién creadas se pueden geocodificar individualmente usando el complemento. El campo de dirección ayuda a determinar la latitud y la longitud correctas. Y finalmente, guarde los resultados en la misma tabla de datos.
Para que la tabla de datos vuelva a ser una tabla de una sola dimensión con ubicaciones, use la función Tablas > Concatenar, combinando los 20 grupos; se llama D-RestauranteswUbicación.jmp.
Ahora que ha desglosado esta tabla con el Generador de consultas, puede volver a crearla con la combinación virtual.
Primero, comience con nuestras tablas de dos dimensiones: Restaurantes-wLocation.jmp y ViolationCodes.jmp . Al hacer clic con el botón derecho en el CÓDIGO DE VIOLACIÓN y seleccionar ID de enlace, se configurará el inicio de la unión virtual. Observe que aparece un icono de llave pequeña en la lista de columnas. Muévase a la mesa de Restaurantes y haga lo mismo con CAMIS. Para finalizar la unión virtual, diríjase a la tabla de hechos, que tiene todas las inspecciones y luego seleccione Referencia de enlace para CAMIS y CÓDIGO DE VIOLACIÓN.
Todas las columnas aparecen en la tabla de hechos sin tener que unir físicamente las tablas en la memoria. La unión virtual también se puede programar a través de una propiedad de columna:
Para la referencia del enlace:
Establecer propiedad("Referencia de enlace", Tabla de referencia("D(f)-Restaurantes-wLocation.jmp"));
Para la identificación del enlace:
Establecer propiedad ("ID de enlace", 1);
Figura 11. unión virtual
La Figura 11 muestra que tiene acceso a las columnas en ambas tablas de dimensiones sin sobrecargar la tabla de hechos.
Finalmente, cree un tablero para visualizar y explorar estos datos aprovechando las columnas unidas virtualmente.
La Figura 12 muestra cómo Dashboard Builder muestra una colección de cinco gráficos. Para usar dos de los gráficos como filtros de selección, comience con la plantilla de filtro jerárquico en Dashboard Builder, usando la BANDERA CRÍTICA y BORO como filtro y filtro jerárquico. A continuación, utilice un gráfico de los recuentos de calificaciones, la puntuación media por cuantil en un mapa y, por último, un mapa de calor de los recuentos de fechas por tipo de inspección.
Figura 12. Modo Dashboard Builder de Application Builder con Final NYC Inspection Dashboard
Este es solo un ejemplo del tipo de visualización que puede hacer con estos datos, aprovechando las tablas vinculadas que ofrece la combinación virtual. Los datos geocodificados también le permiten, por ejemplo, profundizar en las ubicaciones de los restaurantes por tipo de cocina (Figura 13).
Figura 13. Restaurantes geocodificados coloreados por grado que se muestran en un mapa a nivel de calle
Generación e implementación de SQL
Otra gran ventaja de usar Query Builder es la generación de lenguaje de consulta estructurado (SQL). SAS puede usar SQL dentro de Proc SQL, y la mayoría de las bases de datos usan SQL como lenguaje de programación para unir y administrar tablas. SQL se puede generar a partir de una consulta que defina en la interfaz de apuntar y hacer clic de Query Builder.
A continuación se muestra el SQL creado por Query Builder para unir todas las tablas de dimensiones a la tabla unida de serie.jmp y AllData.jmp (del Caso 1) y el SQL de la unión de Unión completa.jmp y todo el _codigo.jmp mesas. El nombrelib declaración, referencias libname asociadas en las tablas y el proceso sql Se agregaron declaraciones. El resto del código fue generado por Query Builder.
Tenga en cuenta que la mayor parte del código es una lista de las columnas dentro de las instrucciones SELECT. El uso de Query Builder para generar dicho código es de gran ayuda, incluso si el usuario sabe SQL. ¿Por qué escribir tantos nombres de tablas y columnas si no es necesario?
nombrelib fuente 'la ubicación de su archivo' ;
proceso sql ;
crear mesa fuente.dataNseries como
SELECCIONAR t1.año, t1.período, t1.valor, t1.footnote_codes,
t2.lfst_code, t2.periodicity_code, t2.series_title, t2.absn_code,
t2.código_actividad, t2.código_edades, t2.código_clase, t2.código_duración,
t2.education_code, t2.entr_code, t2.expr_code, t2.hheader_code,
t2.código_hora, t2.código_indy, t2.código_jdes, t2.código_mirada,
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.buscar_código, t2.sexs_code, t2.tdat_code,
t2.vets_code, t2.wkst_code, t2.born_code, t2.chld_code,
t2.disa_code, t2.estacional, t2.footnote_codes, t2.begin_year,
t2.begin_period, t2.end_year, t2.end_period DE fuente.AllData t1
IZQUIERDA UNIÓN EXTERNA source.series t2
EN ( t1.series_id = t2.series_id ) ;
SELECCIONAR t1.año, t1.periodo, t1.valor, t1.series_title,
t1.estacional, 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.hora_texto, t14.hheader_text, t12.expr_text,
t11.entr_text, t10.education_text, t9.duration_text, t8.disa_text,
t7.class_text, t6.child_text, t5.born_text, t4.ages_text,
t3.texto_actividad, t2.texto_absn DE fuente.dataNseries t1
IZQUIERDA UNIÓN EXTERNA source.footnote t13
EN ( t1.códigos_notas al pie = t13.código_notas al pie )
IZQUIERDA UNIÓN EXTERNA source.wkst t34
EN ( t34.código_trabajo = t1.código_trabajo )
IZQUIERDA UNIÓN EXTERNA source.vets t33
EN ( t33.código_vets = t1.código_vets )
IZQUIERDA UNIÓN EXTERNA source.tdat t32
EN ( t32.tdat_código = t1.tdat_código )
IZQUIERDA UNIÓN EXTERNA source.sexs t31
EN ( t31.sexo_código = t1.sexo_código )
IZQUIERDA UNIÓN EXTERNA source.seek t30
EN ( t30.buscar_código = t1.buscar_código )
IZQUIERDA UNIÓN EXTERNA source.rwns t29
EN ( t29.rwns_código = t1.rwns_código )
IZQUIERDA UNIÓN EXTERNA source.rnlf t28
EN ( t28.rnlf_código = t1.rnlf_código )
IZQUIERDA UNIÓN EXTERNA source.rjnw t27
EN ( t27.CÓDIGO_RJNW = t1.código_rjnw )
IZQUIERDA UNIÓN EXTERNA source.race t26
EN ( t26.código_carrera = t1.código_carrera )
IZQUIERDA UNIÓN EXTERNA fuente.periodicidad t25
EN ( t25.periodicidad_código = t1.periodicidad_código )
IZQUIERDA UNIÓN EXTERNA source.pcts t24
EN ( t24.pcts_code = t1.pcts_code )
IZQUIERDA UNIÓN EXTERNA source.orig t23
EN ( t23.código_orig = t1.código_orig )
IZQUIERDA UNIÓN EXTERNA fuente.ocupación t22
EN ( t22.código_ocupación = t1.código_ocupación )
IZQUIERDA UNIÓN EXTERNA source.mjhs t21
EN ( t21.mjhs_código = t1.mjhs_código )
IZQUIERDA UNIÓN EXTERNA source.mari t20
EN ( t20.mari_code = t1.mari_code )
IZQUIERDA UNIÓN EXTERNA source.look t19
EN ( t19.código_aspecto = t1.código_aspecto )
IZQUIERDA UNIÓN EXTERNA source.lfst t18
EN ( t18.código_lfst = t1.código_lfst )
IZQUIERDA UNIÓN EXTERNA source.jdes t17
EN ( t17.jdes_código = t1.jdes_código )
IZQUIERDA UNIÓN EXTERNA source.indy t16
EN ( t16.indy_code = t1.indy_code )
IZQUIERDA UNIÓN EXTERNA fuente.hora t15
EN ( t15.código_hora = t1.código_hora )
IZQUIERDA UNIÓN EXTERNA source.hheader t14
EN ( t14.hheader_code = t1.hheader_code )
IZQUIERDA UNIÓN EXTERNA source.expr t12
EN ( t12.código_expr = t1.código_expr )
IZQUIERDA UNIÓN EXTERNA source.entr t11
EN ( t11.código_entrada = t1.código_entrada )
IZQUIERDA UNIÓN EXTERNA source.education t10
EN ( t10.código_educación = t1.código_educación )
IZQUIERDA UNIÓN EXTERNA fuente.duración t9
EN ( t9.código_duración = t1.código_duración )
IZQUIERDA UNIÓN EXTERNA source.disa t8
EN ( t8.código_disa = t1.código_disa )
IZQUIERDA UNIÓN EXTERNA source.class t7
EN ( t7.código_clase = t1.código_clase )
IZQUIERDA UNIÓN EXTERNA source.chld t6
EN ( t6.código_niño = t1.código_niño )
IZQUIERDA UNIÓN EXTERNA source.born t5
EN ( t5.código_nacido = t1.código_nacido )
IZQUIERDA UNIÓN EXTERNA fuente.edades t4
EN ( t4.código_edades = t1.código_edades )
IZQUIERDA UNIÓN EXTERNA fuente.actividad t3
EN ( t3.código_actividad = t1.código_actividad )
IZQUIERDA UNIÓN EXTERNA source.absn t2
EN ( t1.código_absn = t2.código_absn );
abandonar ;
Resumen
Los analistas necesitan datos en una tabla, organizados de una manera que haga posible la visualización y el análisis. Sin embargo, los datos a menudo se organizan para cargarlos, mantenerlos y almacenarlos en muchas tablas (normalizadas), de modo que los analistas tienen el desafío de unir y resumir muchas tablas en una tabla lista para el análisis.
JMP Query Builder es una forma eficaz de unir varias tablas desde JMP. La función de vista previa permite al usuario ver si la combinación está definida correctamente antes de ejecutar una operación de combinación de tablas que requiere mucho tiempo. El SQL generado se puede implementar en SAS o en una base de datos, lo que ahorra un tiempo considerable al escribir dicho código a mano.
Referencias
[UGSCPS] Estadísticas de Fuerza Laboral – Encuesta de Población Actual – CPS. Recuperado el 18 de agosto de 2016, de http://www.bls.gov/cps/data.htm .
[DOHMH] Resultados de la inspección de restaurantes de la ciudad de Nueva York del DOHMH. Recuperado el 17 de agosto de 2016, de https://data.cityofnewyork.us/Health/DOHMH-New-York-City-Restaurant-Inspection-Results/xx67-kt59 .
[GREGG] Gregg, X. (28 de mayo de 2014). Geocodificación de nombres de lugares. Recuperado el 18 de agosto de 2016, de https://community.jmp.com/docs/DOC-6175 .
