Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Regla de análisis de tablas de asignación de ID En AWS Clean Rooms, una *regla de análisis de tablas de mapeo de ID* no es una regla de análisis independiente. Este tipo de regla de análisis se administra mediante datos de identidad dispares AWS Clean Rooms y se utiliza para unirlos a fin de facilitar las consultas. Se agrega automáticamente a las tablas de asignación de ID y no se puede editar. Hereda los comportamientos de las demás reglas de análisis de la colaboración, siempre que esas reglas de análisis sean homogéneas. La regla de análisis de la tabla de asignación de ID refuerza la seguridad en una tabla de asignación de ID. Impide que un miembro de la colaboración seleccione o inspeccione directamente la población no superpuesta entre los conjuntos de datos de los dos miembros mediante la tabla de asignación de ID. La regla de análisis de la tabla de asignación de ID se usa para proteger la información confidencial de la tabla de asignación de ID cuando se usa implícitamente en consultas con otras reglas de análisis. Con la regla de análisis de la tabla de mapeo de ID, se AWS Clean Rooms impone una superposición en ambos lados de la tabla de mapeo de ID en el SQL expandido. Esto le permite realizar las siguientes tareas: + Utilice la superposición de la tabla de asignación de ID en las declaraciones JOIN. AWS Clean Rooms permite una INNER o una RIGHT unión en la tabla de mapeo de ID si respeta la superposición. LEFT Para proteger la información de mapeo confidencial, la tabla de mapeo de ID siempre debe estar en el lado inner «» de cualquier JOIN operación. Por ejemplo, las siguientes JOIN operaciones son válidas: + table LEFT JOIN id\_mapping\_table + id\_mapping\_table RIGHT JOIN table + table INNER JOIN id\_mapping\_table Las siguientes JOIN operaciones no son válidas: + id\_mapping\_table LEFT JOIN table + table RIGHT JOIN id\_mapping\_table Esto evita la exposición de los registros de mapeo que no tienen las coincidencias correspondientes en su conjunto de datos. Permitir este tipo de operaciones podría revelar información confidencial sobre las asignaciones de datos de otros miembros de la colaboración. + Utilice las columnas de la tabla de asignación en las declaraciones JOIN. No puede usar las columnas de la tabla de asignación en las siguientes declaraciones: SELECT, WHERE, HAVING, GROUP BY o ORDER BY (a menos que se modifiquen las protecciones en la asociación del espacio de nombres del ID de origen o la asociación del espacio de nombres del ID de destino). + En el SQL expandido, AWS Clean Rooms también es compatible con las versiones implícita OUTER JOIN y CROSSJOIN. JOIN Estas uniones no pueden satisfacer los requisitos de superposición. En su lugar, `requireOverlap` se AWS Clean Rooms utiliza para especificar en qué columnas se deben unir. La estructura y la sintaxis de consulta admitidas se definen en [Estructura y sintaxis de consultas de la tabla de asignación de ID](#id-mapping-table-query-controls). Los parámetros de la regla de análisis, definidos en [Controles de consulta de reglas de análisis de tablas de asignación de ID](#parameters-id-mapping-query-controls), incluyen los controles de consulta y los controles de resultados de las consultas. Sus controles de consulta incluyen la posibilidad de requerir la superposición de la tabla de asignación de ID en las instrucciones JOIN (es decir, `requireOverlap`). **Topics** + [Estructura y sintaxis de consultas de la tabla de asignación de ID](#id-mapping-table-query-controls) + [Controles de consulta de reglas de análisis de tablas de asignación de ID](#parameters-id-mapping-query-controls) + [Estructura predefinida de la regla de análisis de tablas de asignación de ID](#id-mapping-table-predefined-structure) + [Regla de análisis de tablas de asignación de ID: ejemplo](#id-mapping-table-example) ## Estructura y sintaxis de consultas de la tabla de asignación de ID Las consultas en tablas que tienen una regla de análisis de tabla de asignación de ID deben respetar la siguiente sintaxis. ``` --{{select_list_expression}} SELECT provider.data_col, consumer.data_col --{{table_expression}} FROM provider JOIN idMappingTable idmt ON provider.id = idmt.sourceId JOIN consumer ON consumer.id = idmt.targetId ``` ### Tablas de colaboración Las siguientes tablas representan las tablas configuradas que existen en una AWS Clean Rooms colaboración. La columna de **ID** en las tablas **cr\_drivers\_license** y **cr\_insurance** representa una columna que coincide con la tabla de asignación de ID. **cr\_drivers\_license** | | | | | --- |--- |--- | | id | nombre\_del\_conductor | estado\_de\_registro | | 1 | Eduard | TX | | 2 | Dana | MA | | 3 | Gweneth | IL | **cr\_insurance** | | | | | --- |--- |--- | | id | policyholder\_email | número\_política | | a | eduardo@internal.company.com | 17f9d04e-f5be-4426-bdc4-250ed59c6529 | | b | gwen@internal.company.com | 3f0092db-2316-48a8-8d44-09cf8f6e6c64 | | c | rosa@internal.company.com | d7692e84-3d3c-47b8-b46d-a0d5345f0601 | ### tabla de asignación de ID La siguiente tabla representa una tabla de asignación de ID existente que coincide con las tablas **cr\_drivers\_license** y **cr\_insurance**. No todas las entradas serán válidas para ambas tablas de colaboración. IDs | | | | --- |--- | | cr\_drivers\_license\_id | cr\_insurance\_id | | 1 | a | | 2 | null | | 3 | b | | null | c | La regla de análisis de la tabla de asignación de ID solo permite que las consultas se ejecuten en el conjunto de datos superpuestos, que tendría el siguiente aspecto: | | | | | | | | --- |--- |--- |--- |--- |--- | | cr\_drivers\_license\_id | cr\_insurance\_id | nombre\_del\_conductor | estado\_de\_registro | policyholder\_email | número\_política | | 1 | a | Eduard | TX | eduardo@internal.company.com | 17f9d04e-f5be-4426-bdc4-250ed59c6529 | | 3 | b | Gweneth | IL | gwen@internal.company.com | 3f0092db-2316-48a8-8d44-09cf8f6e6c64 | ### Consultas de ejemplo Los siguientes ejemplos muestran ubicaciones válidas para las uniones de la tabla de asignación de ID: ``` -- Single ID mapping table SELECT [ select_items ]FROM cr_drivers_license cr_dl [ INNER | LEFT ] JOIN cr_identity_mapping_table idmt ON idmt.cr_drivers_license_id = cr_dl.id [ INNER | RIGHT ] JOIN cr_insurance cr_in ON idmt.cr_insurance_id = cr_in.id ; -- Single ID mapping table (Subquery) SELECT [ select_items ]FROM ( SELECT [ select_items ] FROM cr_drivers_license cr_dl [ INNER | LEFT ] JOIN cr_identity_mapping_table idmt ON idmt.cr_drivers_license_id = cr_dl.id [ INNER | RIGHT ] JOIN cr_insurance cr_in ON idmt.cr_insurance_id = cr_in.id ) ; -- Single ID mapping table (CTE) WITH matched_ids AS ( SELECT [ select_items ] FROM cr_drivers_license cr_dl [ INNER | LEFT ] JOIN cr_identity_mapping_table idmt ON idmt.cr_drivers_license_id = cr_dl.id [ INNER | RIGHT ] JOIN cr_insurance cr_in ON idmt.cr_insurance_id = cr_in.id )SELECT [ select_items ]FROM matched_ids ; ``` ### Consideraciones Para la estructura y sintaxis de las consultas de tabla de asignación de ID, tenga en cuenta lo siguiente: + No puede editarlo. + Se aplica a la tabla de asignación de ID de forma predeterminada. + Utiliza una asociación de espacio de nombres de ID de origen y destino dentro de la colaboración. + La tabla de asignación de ID está configurada de forma predeterminada para proporcionar protecciones predeterminadas para la columna que proviene del espacio de nombres de ID. Puede modificar esta configuración para que la columna que proviene del espacio de nombres de ID (`sourceID` o `targetID`) se pueda permitir en cualquier parte de la consulta. Para obtener más información, consulte [Espacios de nombres de ID en AWS Clean Rooms](working-with-id-namespaces.md). + La regla de análisis de la tabla de asignación de ID hereda las restricciones de SQL de las demás reglas de análisis de la colaboración. ## Controles de consulta de reglas de análisis de tablas de asignación de ID Con los controles de consulta de tablas de mapeo de ID, controla cómo se utilizan las columnas de la tabla para consultarla. AWS Clean Rooms Por ejemplo, controla qué columnas se utilizan para unir y qué columnas deben superponerse. La regla de análisis de tablas de asignación de ID también incluye una funcionalidad que le permite proyectar `sourceID`, `targetID` o ambas sin necesidad de JOIN. La tabla siguiente explica cada control. | Control | Definición | De uso | | --- | --- | --- | | joinColumns | Las columnas que el miembro que puede realizar consultas puede usar en la instrucción INNER JOIN. | No puede usar joinColumns en ninguna otra parte de la consulta que no sea INNER JOIN.Para obtener más información, consulte [Controles de combinación](analysis-rules-aggregation.md#join-controls). | | dimensionColumns | Las columnas (si las hay) que el miembro que puede realizar consultas puede utilizar en las instrucciones SELECT y GROUP BY. | Se puede usar una `dimensionColumn` en SELECT y GROUP BY.
Puede aparecer una `dimensionColumn` como `joinKeys`.
Solo puede utilizar `dimensionColumns` en la cláusula JOIN si la especifica entre paréntesis. | | queryContraints:RequireOverlap | Las columnas de la tabla de asignación de ID que se deben unir para que se pueda ejecutar la consulta. | Estas columnas se deben usar para UNIR la tabla de asignación de ID y una tabla de colaboración. | ## Estructura predefinida de la regla de análisis de tablas de asignación de ID La estructura predefinida para una regla de análisis de tablas de asignación de ID incluye protecciones predeterminadas que se aplican a `sourceID` y `targetID`. Esto significa que la columna con las protecciones aplicadas se debe usar en las consultas. Puede configurar la regla de análisis de la tabla de asignación de ID de las siguientes maneras: + `sourceID` y `targetID` protegidos En esta configuración, no se pueden proyectar `sourceID` y `targetID`. `sourceID` y `targetID` se deben usar en una instrucción JOIN cuando se hace referencia a la tabla de asignación de ID. + Solo `targetID` protegido En esta configuración, `targetID` no se puede proyectar. `targetID` se debe usar en una instrucción JOIN cuando se hace referencia a la tabla de asignación de ID. `sourceID` se puede usar en una consulta. + Solo `sourceID` protegido En esta configuración, `sourceID` no se puede proyectar. `sourceID` se debe usar en una instrucción JOIN cuando se hace referencia a la tabla de asignación de ID. `targetID` se puede usar en una consulta. + Ningún `sourceID` o `targetID` protegido En esta configuración, la tabla de asignación de ID no está sujeta a ninguna aplicación específica que pueda usarse en una consulta. El siguiente ejemplo muestra una estructura predefinida para una regla de análisis de tablas de asignación de ID con las protecciones predeterminadas que se aplican a `sourceID` y `targetID`. En este ejemplo, la regla de análisis de la tabla de asignación de ID solo permite una instrucción INNER JOIN en la columna `sourceID` y en la columna `targetID`. ``` { "joinColumns": [ "source_id", "target_id" ], "queryConstraints": [ { "requireOverlap": { "columns": [ "source_id", "target_id" ] } } ], "dimensionColumns": [] // columns that can be used in SELECT and JOIN } ``` El siguiente ejemplo muestra una estructura predefinida para una regla de análisis de tablas de asignación de ID con las protecciones que se aplican a `targetID`. En este ejemplo, la regla de análisis de la tabla de asignación de ID solo permite una instrucción INNER JOIN en la columna `sourceID`. ``` { "joinColumns": [ "source_id", "target_id" ], "queryConstraints": [ { "requireOverlap": { "columns": [ "target_id" ] } } ], "dimensionColumns": [ "source_id" ] } ``` El siguiente ejemplo muestra una estructura predefinida para una regla de análisis de tablas de asignación de ID con las protecciones que se aplican a `sourceID`. En este ejemplo, la regla de análisis de la tabla de asignación de ID solo permite una instrucción INNER JOIN en la columna `targetID`. ``` { "joinColumns": [ "source_id", "target_id" ], "queryConstraints": [ { "requireOverlap": { "columns": [ "source_id" ] } } ], "dimensionColumns": [ "target_id" ] } ``` El siguiente ejemplo muestra una estructura predefinida para una regla de análisis de tablas de asignación de ID sin las protecciones que se aplican a `sourceID` o `targetID`. En este ejemplo, la regla de análisis de la tabla de asignación de ID permite una instrucción INNER JOIN en la columna `sourceID` y en la columna `targetID`. ``` { "joinColumns": [ "source_id", "target_id" ], "queryConstraints": [ { "requireOverlap": { "columns": [] } } ], "dimensionColumns": [ "source_id", "target_id" ] } ``` ## Regla de análisis de tablas de asignación de ID: ejemplo En lugar de escribir una larga declaración en cascada que haga referencia a la información de identificación personal (PII), por ejemplo, las empresas pueden utilizar la regla de análisis de la tabla de mapeo de identificadores para utilizar la transcodificación LiveRamp multipartita. El siguiente ejemplo demuestra cómo puede colaborar en el AWS Clean Rooms uso de la regla de análisis de tablas de mapeo de ID. La empresa A es un anunciante que tiene datos de clientes y ventas, que se utilizarán como origen. La empresa A también realiza la transcodificación en nombre de las partes de la colaboración y aporta las LiveRamp credenciales. La empresa B es un publicador que tiene datos de eventos, que se utilizarán como destino. **nota** La empresa A o la empresa B pueden proporcionar las credenciales de LiveRamp transcodificación y realizar la transcodificación. Para crear una colaboración que permita el análisis de tablas de asignación de ID en colaboración, las empresas hacen lo siguiente: 1. La empresa A crea una colaboración y crea una pertenencia. Se agrega la empresa B, que también crea una suscripción en la colaboración. 1. La empresa A asocia una fuente de espacio de nombres de ID existente o crea una nueva mediante la consola. AWS Entity Resolution AWS Clean Rooms La empresa A crea una tabla configurada con sus datos de ventas y una columna vinculada a `sourceId` en la tabla de asignación de ID. El origen del espacio de nombres de ID proporciona datos para la transcodificación. 1. La empresa B asocia un destino de espacio de nombres de ID existente o crea uno nuevo mediante la consola. AWS Entity Resolution AWS Clean Rooms La empresa B crea una tabla configurada con sus datos de eventos y una columna vinculada a `targetId` en la tabla de asignación de ID. El destino del espacio de nombres de ID no proporciona datos para transcodificar, solo metadatos relacionados con la configuración. LiveRamp 1. La empresa A descubre los dos espacios de nombres de ID asociados a la colaboración y crea y completa una tabla de asignación de ID. 1. La empresa A ejecuta una consulta en los dos conjuntos de datos mediante la unión en la tabla de asignación de ID. ``` --- this would be valid for Custom or List SELECT provider.data_col, consumer.data_col FROM provider JOIN idMappingTable-123123123123-myMappingWFName idmt ON provider.id = idmt.sourceId JOIN consumer ON consumer.id = idmt.targetId ```