Cómo unir orígenes de datos

Puede unir dos o más orígenes de datos para crear una estructura más grande de datos integrados, desde la que puede crear un informe con una sola solicitud. La estructura combinada es virtual. Es una manera de acceder a los múltiples orígenes de datos como si fueran uno solo origen de datos. Hasta 1023 joins pueden estar en efecto a la vez, para un total de 1024 segmentos, dependiendo del número de segmentos activos y el número y la longitud de campos (hay un límite de 32K en la longitud de todos los campos).

Luego el procedimiento añade un empleado nombrado Fred Newman al EMPINFO que no tiene registro que encaja en los orígenes de datos JOBINFO o EDINFO.

La solicitud que sigue imprime los contenidos de EMPINFO. Note que se añadió Fred Newman al origen de datos.

El comando JOIN siguiente genera una join interna entre los orígenes de datos EMPINFO y JOBINFO.

Note que el comando JOIN especifica una join múltiple. En una join única, el segmento de referencia cruzada nunca se considera no disponible y se muestran todos los registros desde el archivo host en la salida de informe. Se muestran valores predeterminados (en blanco para campos alfanuméricos y cero para numéricos) si no existen datos verdaderos.

Se omite Fred Newman desde la salida de informe ya que su código de trabajo no tiene coincidencia en el origen de datos JOBINFO:

El comando JOIN siguiente genera una join externa izquierda entre los orígenes de datos EMPINFO y EDINFO.

Todos los registros de empleado se muestran en la salida de informe. Los informes para aquellos empleados sin registros coincidentes en el origen de datos EDINFO muestran el carácter de datos no disponibles (.) en la columna COURSE_NAME. Si la join fuera única, se muestran espacios en blanco en lugar del carácter de datos no disponibles.

Los siguientes comandos JOIN crean una join interna entre los orígenes de datos EMPINFO y JOBINFO y una join interna entre los orígenes de datos EMPINFO y EDINFO:

Con MULTIPATH=SIMPLE, las rutas independientes generan joins independientes. Todos los registros de empleado aceptados por cualquier join se muestra en la salida de informe. Sólo se omite Fred Newman (quien no tiene registros coincidentes en ninguno de los archivos de referencia cruzada):

Con MULTIPATH=COMPOUND, sólo se muestran empleados con registros coincidentes en ambos archivos de referencia cruzada en la salida de informe:

Referencia: requisitos para campos de referencia cruzada en un equijoin

Los campos de referencia cruzada utilizados en un JOIN, deben tener los caracteres siguientes en orígenes de datos específicos:

En orígenes de datos relacionales y en un origen de datos CA-DATACOM/DB el campo de referencia cruzada puede ser cualquier campo.
En orígenes de datos FOCUS y XFOCUS, el campo de referencia cruzada debe estar indexado. Los campos indexados tienen el atributo FIELDTYPE=I o INDEX=I o INDEX=ON en el archivo máster. Si el campo de referencia no tiene este atributo, adjunte el atributo a la declaración de campo en el archivo máster y reconstruya el archivo mediante la utilidad REBUILD con la opción INDEX. Esto añade un índice a su origen de datos FOCUS o XFOCUS.
Nota: Los campos indexados pueden ser externos. Consulte el manual Cómo describir datos con el lenguaje WebFOCUS. , para más información sobre los campos indexados y la herramienta Rebuild.
En orígenes de datos IMS, el campo de referencia cruzada debe ser un campo clave en el segmento de raíz. Puede ser un índice primario o secundario.
En archivos secuenciales de formato fijo o delimitados, cualquier campo puede ser un campo de referencia cruzada. Sin embargo, tanto el host como el archivo de referencia cruzada deben recuperarse en orden ascendente en el campo nombrado (clave), si está en vigor el comando ENGINE INT SET CACHE=OFF. En este caso, si los datos no siguen el mismo orden de clasificación, aparecen errores y el join de varios a varios deja de funcionar. Sin embargo, cuando ENGINE INT SET CACHE = ON está en vigor, los archivos no necesitan seguir un orden ascendente y se permite el uso del join de varios a varios. El archivo delimitado, usado como archivo de referencia cruzada en el join, debe tener solo un segmento. Si el join está basado en campos múltiples, un archivo secuencial de formato fijo debe tener solo un segmento. Si el archivo secuencial de formato fijo usado como archivo de referencia cruzada contiene solo un segmento, el archivo anfitrión debe tener una declaración de segmentos.

Referencia: Restricciones de campos de grupo

Cuando se utilizan campos de grupo en una estructura unida, el grupo en el archivo host y el grupo en el archivo de referencia cruzada deben tener el mismo número de elementos:

En orígenes de datos ISAM, el campo debe ser la clave primaria completa si es que emite un enlace único, o un subconunto inicial de la clave primaria, si se trata de un enlace no único. En el archivo máster, la clave primaria se describe mediante una clave GROUP; el subconjunto inicial es el primer campo en ese grupo.
En orígenes de campo VSAM KSDS, el campo debe ser la clave primaria completa o la clave alterna, si es que emite un enlace único, o un subconjunto inicial de la clave primaria o de la alterna, si emite un enlace no único. En el archivo máster, la clave primaria aparece descrita mediante un GROUP clave. El subconjunto inicial es el primer campo del grupo.
En orígenes de campo VSAM ESDS, el campo puede ser cualquier campo, siempre y cuando el archivo esté ya clasificado en ese campo.
En orígenes de datos Model 204, el campo debe ser un campo clave. En el archivo de acceso, los campos clave son de tipo alfanumérico (KEY), de caracteres ordenado (ORA), numérico ordenado (ORN), rango numérico (RNG), invisible (IVK) o rango invisible (IVR).
En orígenes de datos ADABAS, el campo debe ser un campo descriptor, un superdescriptor definido con el nombre sufijo de campo .SPR o .NOP o un subdescriptor definido con el nombre sufijo de campo .NOP. La descripción de campo en el archivo máster debe contener el atributo FIELDTYPE=I.
En el archivo de acceso, el segmento de referencia cruzada debe especificar ACCESS=ADBS y CALLTYPE=Buscar o CALLTYPE=RL. Si fuera CALLTYPE=RL, el campo host se puede unir con la porción de orden alto de un descriptor, un superdescriptor o un subdescriptor, si la porción de orden alto es más larga que el campo host.
En orígenes de datos CA-IDMS/DB, el campo debe tratarse de un campo indexado situado en un registro de red, identificado por el atributo FIELDTYPE=I en el archivo máster, de un campo CA-IDMS/DB CALC de un registro de red, identificado por la frase CLCFLD en el archivo de acceso o de cualquier campo de un registro LRF o ASF.

Referencia: Notas sobre el uso para sintaxis de comandos JOIN internos y externos

La sintaxis ignora los comandos SET ALL y SET CARTESIAN.
El parámetro ALL. no está admitido. Si se usa el parámetro ALL., se muestra el siguiente mensaje:
```
(FOC32452) Use of ALL. with LEFT_OUTER/INNER not allowed
```
Si define varios joins, la estructura resultante puede tratarse de un origen de datos de ruta individual o mútiple.
- Si la configuración MULTIPATH=SIMPLE está en efecto y se basa en el informe en rutas múltiples, cada una de las joins individuales se construye por separado sin considerar las otras joins y los registros que encajan desde cada una de las rutas por separado se muestran en la salida de informe. Por eso, la salida puede contener registros que tendrían que omitirse si sólo una de las joins estuviera en efecto.
- Si la configuración MULTIPATH=COMPOUND está en efecto con un informe de ruta múltiple, o si el informe sólo muestra datos desde una ruta individual, la salida de informe sólo muestra aquellos registros que satisfacen todas las joins.

Cómo unir desde un campo virtual con un campo real mediante un equijoin

Cómo:

Combinar desde un campo virtual con un campo real

Referencia:

Notas sobre el uso de campos virtuales con orígenes de datos unidos

Puede utilizar sintaxis JOIN basada en DEFINE para crear un campo host virtual que puede unir con un campo de referencia cruzada real. La expresión DEFINE que crea el campo host virtual puede contener solamente campos en el archivo host y constantes. (Puede que no contenga campos en el archivo de referencia cruzada.) Puede hacer más de un join desde un campo virtual.

Puede crear el campo host virtual en un comando DEFINE independiente o en el archivo máster. Para más información sobre archivos máster, consulte el manual Cómo describir datos con el lenguaje WebFOCUS.

La misma solicitud de informe puede usar campos virtuales basados en JOIN y campos virtuales no relacionados con la join.

Tenga en cuenta que al crear un campo virtual en un comando DEFINE, debe emitir DEFINE después del comando JOIN, pero antes de la solicitud TABLE, pues un comando JOIN borra todos los campos creados por comandos DEFINE para el archivo host y la estructura unida. No se borran los campos virtuales definidos en los archivos máster.

Sugerencia: Si un comando DEFINE precede al comando JOIN, puede ajustar KEEPDEFINES ON para que restituya los campos virtuales durante el análisis de un comando JOIN posterior . Para más información, consulte Cómo conservar campos virtuales con KEEPDEFINES.

Principio de página

Sintaxis: Cómo Combinar desde un campo virtual con un campo real

El comando JOIN basado en DEFINE le permite unir un campo virtual en el archivo host con un campo real en el archivo de referencia cruzada. La sintaxis es:

JOIN [LEFT_OUTER|INNER] deffld WITH host_field ... 
     IN hostfile [TAG tag1]
     TO [UNIQUE|MULTIPLE] 
     cr_field IN crfile [TAG tag2] [AS joinname]
END

donde:

JOIN deffld

Es el nombre de un campo virtual para el archivo host (el campo host). Se puede definir el campo virtual en el archivo máster o con un comando DEFINE. Para obtener información relacionada, consulte Notas sobre el uso de campos virtuales con orígenes de datos unidos.

WITH host_field

Es el nombre de cualquier campo real en el segmento host con el que desea asociar el campo virtual. Esta asociación es necesaria para localizar el campo virtual.

La frase WITH es obligatoria a no ser que el parámetro KEEPDEFINES está activado y deffld se definió antes de emitir el comando JOIN.

Para determinar cuál segmento contiene el campo virtual, utilice la consulta ? DEFINE después de emitir el comando DEFINE. Consulte el manual Cómo desarrollar aplicaciones de informes para obtener detalles sobre los comandos de consulta.

INNER

Especifica una join izquierda externa. Si no especifica el tipo de join en el comando JOIN, la configuración de parámetro ALL determina el tipo de join a realizar.

LEFT_OUTER

Especifica un join izquierdo externo. Si no especifica el tipo de join en el comando JOIN, la configuración de parámetro ALL determina el tipo de join a realizar.

IN hostfile

Es el nombre del archivo host.

TAG tag1

Es un nombre de etiqueta de hasta 66 caracteres (normalmente, el nombre del archivo máster), que se utiliza como calificador único para campos y alias en archivos host.

El nombre de etiqueta del archivo host debe ser el mismo en todos los comandos JOIN de una estructura de join.

TO [UNIQUE|MULTIPLE] crfld1

Es el nombre de un campo real en los orígenes de datos de referencia cruzada cuyos valores hacen juego con los del campo virtual. Esto debe ser un campo real declarado en el archivo máster.

Nota: Único sólo devuelve un caso y si no hay un caso que encaje en el archivo de referencia cruzada, proporciona valores predeterminados (en blanco para campos alfanuméricos y cero para campos numéricos).

Utilice el parámetro MULTIPLE cuando crfld1 puede tener instancias múltiples en común con un valor en hfld1. Fíjese que se trata de un sinónimo de MULTIPLE y la completa omisión de este parámetro es sinónimo de UNIQUE. Para más información, consulte Estructuras unidas únicas y no únicas.

IN crfile

Es el nombre del archivo de referencia cruzada.

TAG tag2

Es un nombre de etiqueta de hasta 66 caracteres (normalmente, el nombre del archivo máster), que se utiliza como un calificador único para campos y alias en archivos de referencia cruzada. En una estructura de join recurrente, si no se provee el nombre de etiqueta, todos los nombres de campo y alias se prefijan con los primeros cuatro caracteres del nombre de join. Para más información, consulte Notas sobre el uso de estructuras unidas recursivas .

El nombre de etiqueta del archivo host debe ser el mismo en todos los comandos JOIN de una estructura de join.

AS joinname

Es un nombre opcional de hasta ocho caracteres que puede asignar a la estructura unida. Debe asignar un nombre único a una estructura de join si:

Verifique que un comando JOIN posterior no lo sobrescriba.
Desea borrarlo selectivamente más tarde.
La estructura es recurrente y no especifica nombres de etiqueta. Consulte Estructuras recursivas unidas.

Si no asigna un nombre a la estructura de join con la frase AS, se supone que el nombre está en blanco. Una join sin un nombre sobrescribe una join existente sin un nombre.

END

Es obligatorio cuando el comando JOIN ocupa más de una línea. Finaliza el comando. Debe estar en una línea para sí solo.

Principio de página

Referencia: Notas sobre el uso de campos virtuales con orígenes de datos unidos

Las solicitudes que lean orígenes de datos unidos pueden contener igualmente campos virtuales que se definen:

En el archivo máster del origen de datos host.
En un comando CDEFINE en que la sintaxis
```
DEFINE FILE hostfile								
```
identifica el origen de datos host en la estructura unida.

Nota: La expresión que define el campo host de la join solamente puede usar campos anfitriones y constantes.

Todos los demás campos virtuales pueden contener campos reales desde el archivo host y el archivo de referencia cruzada.

Sugerencia: Dado que la emisión de un comando JOIN borra todos los comandos DEFINE del archivo host y de la estructura join, debe emitir el comando DEFINE después de JOIN o activar KEEPDEFINES para conservar los campos virtuales. Para más información, consulte Cómo conservar campos virtuales mientras se analiza una join .

Principio de página

Ejemplo: Cómo crear un campo host virtual para una estructura unida

Supongamos que una cadena de tiendas manda a cuatro gerentes de sucursales a tomar clases. Cada uno de estos gerentes, con su número de identificación, administra una tienda en una ciudad diferente. Tanto las tiendas como las ciudades en que trabajan estos gerenes están incluidas en el origen de datos SALES. Las identificaciones de los gerentes, sus clases y las fechas en que asistieron a éstas aparecen en el origen de datos EDUCFILE.

El procedimiento que sigue lista los cursos a los que asistieron los gerentes, identificando a los gerentes por la ciudad en que trabajan. Tenga en cuenta que el procedimiento consta de tres elementos:

El comando JOIN, que combina el origen de datos SALEs con el origen de datos EDUCFILE a partir de los valores comunes con el campo ID_NUM (que contiene las identificaciones de los gerentes) en SALES y el campo EMP_ID de EDUCFILE. Observe que el campo ID_NUM todavía no existe y que será creado por el comando DEFINE.
El comando DEFINE crea el campo ID_NUM, que le asigna las identificaciones de los gerentes que trabajan en las cuatro ciudades.
El comando TABLE genera el informe.

El procedimiento es:

JOIN ID_NUM WITH CITY IN SALES TO ALL EMP_ID IN EDUCFILE AS SALEDUC

DEFINE FILE SALES
ID_NUM/A9 = DECODE CITY ('NEW YORK' 451123478 'NEWARK' 119265415
                         'STAMFORD' 818692173 'UNIONDALE' 112847612);
END

TABLE FILE SALES
PRINT DATE_ATTEND BY CITY BY COURSE_NAME
END

La salida es:

CITY                    COURSE_NAME                 DATE_ATTEND
----                    -----------                 -----------
NEW YORK                FILE DESCRPT & MAINT           81/11/15
NEWARK                  BASIC RPT NON-DP MGRS          82/08/24
STAMFORD                BASIC REPORT PREP DP MGRS      82/08/02
                        HOST LANGUAGE INTERFACE        82/10/21
UNIONDALE               BASIC REPORT PREP FOR PROG     81/11/16
                        FILE DESCRPT & MAINT           81/11/15

Formatos de datos de campos compartidos

Por lo general, los campos que contienen los valores compartidos en los campos host y de referencia cruzada deben tener los mismos formatos.

Si especifica campos con múltiples archivos anfitriones, el comando JOIN los trata como si fueran un solo campo concatenado. Añada las longitudes de los formatos de campo para obtener la longitud del campo concatenado. Debe observar las reglas que siguen:

Si el campo host es alfanumérico, el campo de referencia cruzada debe ser también alfanumérico y tener la misma longitud.
Los formatos podrían tener diferentes opciones de edición.

Tenga en cuenta que no se puede utilizar un campo de texto para unir orígenes de datos.
Si el campo host es numérico, el formato del campo host, especificado en el atributo USAGE (o FORMAT) en el archivo máster, deben tener de un tipo similar (I, P, F o D) que el formato del campo de referencia cruzada especificado por el atributo USAGE (o FORMAT). Para obtener información detallada, consulte
Cómo unir campos con tipos diferentes de datos numéricos.
Las opciones de edición podrían ser diferentes. La longitud también puede ser diferente, pero con el efecto siguiente:
- Si el formato del campo anfiitrión (especificado por el atributo USAGE) es un decimal empaquetado (P) o un número entero (I) y tiene una longitud superior al formato del campo de referencia cruzada ( especificado por el atributo USAGE para orígenes de datos de FOCUS o por el atributo ACTUAL para otros orígenes de datos), sólo se compara la longitud del formato del campo de referencia cruzada y esto sólo con los dígitos más a la derecha en el campo más corto. Por ejemplo, si un formato de campo de decimal empaquetado de cinco dígitos se combina con un formato de campo de decimal empaquetado de tres dígitos, cuando se recupere un registro host de decimal empaquetado de tres dígitos, también se recuperarán todos los registros de referencia cruzada con los últimos tres dígitos de ese número.
- Si el formato del campo host es de doble precisión (D), sólo se comparan los ocho bytes más a la izquierda de cada campo.
Si el campo host es un campo de fecha, el campo de referencia cruzada también debe ser un campo de fecha. Los campos de fecha y de hora y fecha deben tener los mismos componentes, aunque no necesariamente en el mismo orden.
Se puede describir a los campos host y de referencia cruzada como grupos en el archivo máster si contienen el mismo número de campos componentes. Los campos componentes correspondientes en cada grupo (por ejemplo, el primer campo en el grupo host y el primer campo en el grupo de referenica cruzada) deben obedecer a las reglas que aparecen más arriba. Para obtener información relacionada, consulte Restricciones de campos de grupo.
Aunque el campo host no sea un campo de grupo, el campo de referencia cruzada puede ser un grupo. Si el campo host es un grupo, el campo de referencia cruzada debe ser un grupo.

Cómo unir campos con tipos diferentes de datos numéricos

Cómo:

Habilitar joins con conversión de tipo de datos

Puede unir dos o más orígenes de datos que contengan diferentes tipos de datos numéricos. Por ejemplo, puede unir un campo con un formato de decimal empaquetado corto con un formato de decimal empaquetado largo, o bien un campo con un formato de número entero con otro con formato de decimal empaquetado. Esto le proporciona significativa flexibilidad para crear informes desde orígenes de datos unidos.

Cuando se combina un campo corto con uno más largo, el valor de referenica cruzada se acomoda a la longitud del campo host, añadiendo espacios (para campos alfa) o ceros hexadecimales (para campos numéricos). Este nuevo valor se utiliza para búsquedas en el archivo de referencia cruzada.
Cuando se combina un campo largo con uno más corto, se trunca el valor FROM. Si se trunca parte de su valor debido a la longitud de USAGE en el archivo de referencia cruzada, sólo se hallarán en el archivo de referenica cruzada los registros que correspondan al valor truncado.

Nota:

Para que las comparaciones con campos de decimal empaquetado se ejecuten correctamente, todos los signos de valores positivos se convierten en hex C, y todos los negativos, en hex D.
Además, el parámetro JOINOPT corrige los valores retrasados en los joins únicos. Para más información, consulte Cómo Corregir cuando valores restantes quedan en un Join único.

Principio de página

Sintaxis: Cómo Habilitar joins con conversión de tipo de datos

Para habilitar joins con conversión de tipos de datos, emita el comando

SET JOINOPT = [NEW|OLD]

donde:

NEW: Le permite unir con conversión de tipos de datos.
OLD: Deshabilita las joins con conversión de tipos de datos. Este valor es el predeterminado.

Principio de página

Ejemplo: Cómo emitir joins con conversión de tipos de datos

Dado que puede enlazar un campo con un formato de decimal corto a un campo con formato de decimal largo, se puede definir una join en los siguientes archivos máster:

FILE=PACKED,SUFFIX=FIX,$
  SEGNAME=ONE,SEGTYPE=S0
   FIELD=FIRST,,P8,P4,INDEX=I,$

FILE=PACKED2,SUFFIX=FIX,$
  SEGNAME=ONE,SEGTYPE=S0
   FIELD=PFIRST,,P31,P16,INDEX=I,$

El comando JOIN podría tener el siguiente aspecto:

JOIN FIRST IN PACKED TO ALL PFIRST IN PACKED2 AS J1

Al unir campos empaquetados, el formato preferido de signo X'C' para valores positivos y X'D' para valores negativos continúa siendo un requisito. Todos los otros signos no preferidos se convierten a X'C' o a X'D'.