Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Analyseregeln in AWS Clean Rooms
Im Rahmen der Aktivierung einer Tabelle AWS Clean Rooms für die Kollaborationsanalyse muss das Kollaborationsmitglied eine *Analyseregel* konfigurieren.
Bei einer Analyseregel handelt es sich um eine Kontrolle zur Verbesserung des Datenschutzes, die jeder Datenbesitzer in einer konfigurierten Tabelle einrichtet. Eine Analyseregel bestimmt, wie die konfigurierte Tabelle analysiert werden kann.
Bei der Analyseregel handelt es sich um eine Kontrolle auf Kontoebene für die konfigurierte Tabelle (eine Ressource auf Kontoebene). Sie wird in jeder Zusammenarbeit durchgesetzt, der die konfigurierte Tabelle zugeordnet ist. Wenn keine Analyseregel konfiguriert ist, kann die konfigurierte Tabelle Kollaborationen zugeordnet, aber nicht abgefragt werden. Abfragen können nur auf konfigurierte Tabellen mit demselben Analyseregeltyp verweisen.
Um eine Analyseregel zu konfigurieren, wählen Sie zuerst einen Analysetyp aus und geben dann die Analyseregel an. Bei beiden Schritten sollten Sie berücksichtigen, welchen Anwendungsfall Sie aktivieren möchten und wie Sie Ihre zugrunde liegenden Daten schützen möchten.
AWS Clean Rooms erzwingt die restriktiveren Kontrollen für alle konfigurierten Tabellen, auf die in einer Abfrage verwiesen wird.
Die folgenden Beispiele veranschaulichen die restriktiven Kontrollen.
**Example Restriktive Kontrolle: Ausgabebeschränkung**
+ Mitarbeiter A hat eine Ausgabebeschränkung für die Kennungsspalte 100.
+ Mitarbeiter B hat eine Ausgabebeschränkung für die Identifikatorspalte von 150.
Eine Aggregationsabfrage, die auf beide konfigurierten Tabellen verweist, benötigt mindestens 150 unterschiedliche Bezeichnerwerte innerhalb einer Ausgabezeile, damit sie in der Abfrageausgabe angezeigt werden kann. Die Abfrageausgabe gibt nicht an, dass Ergebnisse aufgrund der Ausgabebeschränkung entfernt wurden.
**Example Restriktive Kontrolle: Analysevorlage nicht genehmigt**
+ Mitarbeiter A hat eine Analysevorlage mit einer Abfrage zugelassen, die in ihrer benutzerdefinierten Analyseregel auf konfigurierte Tabellen von Collaborator A und Collaborator B verweist.
+ Mitarbeiter B hat die Analysevorlage nicht zugelassen.
Da Mitarbeiter B die Analysevorlage nicht zugelassen hat, kann das Mitglied, das Abfragen durchführen kann, diese Analysevorlage nicht ausführen.
## Typen von Analyseregeln
Es gibt drei Arten von Analyseregeln: [Aggregationsregeln](analysis-rules-aggregation.md), [Listenregeln](analysis-rules-list.md) und [benutzerdefinierte](analysis-rules-custom.md) Regeln. In den folgenden Tabellen werden die Analyseregeltypen verglichen. Jeder Typ hat einen eigenen Abschnitt, in dem die Angabe der Analyseregel beschrieben wird.
**Anmerkung**
Es gibt einen Analyseregeltyp, der als Analyseregel für ID-Zuordnungstabellen bezeichnet wird. Diese Analyseregel wird jedoch von verwaltet AWS Clean Rooms und kann nicht geändert werden. Weitere Informationen finden Sie unter [Regel zur Analyse von ID-Zuordnungstabellen](analysis-rules-id-mapping-table.md).
In den folgenden Abschnitten werden unterstützte Anwendungsfälle und Kontrollen für jeden Analyseregeltyp beschrieben.
### Unterstützte Anwendungsfälle
Die folgenden Tabellen enthalten eine Vergleichszusammenfassung der unterstützten Anwendungsfälle für jeden Analyseregeltyp.
| Anwendungsfall | [Aggregation](analysis-rules-aggregation.md) | [Liste](analysis-rules-list.md) | [Custom (Benutzerdefiniert)](analysis-rules-custom.md) |
| --- | --- | --- | --- |
| Unterstützte Analysen | Abfragen, die Statistiken mithilfe der Funktionen COUNT, SUM und AVG anhand optionaler Dimensionen aggregieren | Abfragen, die Listen mit Überschneidungen zwischen mehreren Tabellen auf Zeilenebene ausgeben | Jede benutzerdefinierte Analyse, sofern die Analysevorlage oder der Analyseersteller überprüft und zugelassen wurden |
| Allgemeine Anwendungsfälle | Segmentanalyse, Messung, Zuordnung | Bereicherung, Segmentbildung | Zuordnung auf Anhieb, inkrementelle Analysen, Zielgruppenfindung |
| SQL-Konstrukte | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/clean-rooms/latest/userguide/analysis-rules.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/clean-rooms/latest/userguide/analysis-rules.html) | Die meisten SQL-Funktionen und SQL-Konstrukte sind mit dem SELECT-Befehl verfügbar |
| Unterabfragen und allgemeine Tabellenausdrücke () CTEs | Nein | Nein | Ja |
| Vorlagen für Analysen | Nein | Nein | Ja |
### Unterstützte Steuerelemente
Die folgenden Tabellen zeigen eine vergleichende Zusammenfassung darüber, wie die einzelnen Analyseregeltypen Ihre zugrunde liegenden Daten schützen.
| Kontrolle | [Aggregation](analysis-rules-aggregation.md) | [Liste](analysis-rules-list.md) | [Custom (Benutzerdefiniert)](analysis-rules-custom.md) |
| --- | --- | --- | --- |
| Kontrollmechanismus | Steuern Sie, wie Daten in der Tabelle in einer Abfrage verwendet werden können*(Lassen Sie beispielsweise COUNT und SUM der Spalte hashed\$1email zu.)* | Steuern Sie, wie Daten in der Tabelle in einer Abfrage verwendet werden können*(Erlauben Sie beispielsweise die Verwendung der Spalte hashed\$1email nur für den Beitritt.)* | Steuern Sie, welche Abfragen in der Tabelle ausgeführt werden dürfen*(Lassen Sie beispielsweise nur Abfragen zu, die in den Analysevorlagen „Benutzerdefinierte Abfrage 1" definiert sind.)* |
| Integrierte Techniken zur Verbesserung der Privatsphäre | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/clean-rooms/latest/userguide/analysis-rules.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/clean-rooms/latest/userguide/analysis-rules.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/clean-rooms/latest/userguide/analysis-rules.html) |
| Überprüfen Sie die Abfrage, bevor sie ausgeführt werden kann | Nein | Nein | Ja, mithilfe von Analysevorlagen |
Weitere Informationen zu den Analyseregeln, die in verfügbar sind AWS Clean Rooms, finden Sie in den folgenden Themen.
+ [Regel für die Aggregationsanalyse](analysis-rules-aggregation.md)
+ [Regel für die Listenanalyse](analysis-rules-list.md)
+ [Benutzerdefinierte Analyseregel in AWS Clean Rooms](analysis-rules-custom.md)
# Regel für die Aggregationsanalyse
In AWS Clean Rooms generiert eine *Aggregationsanalyseregel* aggregierte Statistiken mithilfe der Funktionen COUNT, SUM und and/or AVG anhand optionaler Dimensionen. Wenn die Aggregationsanalyseregel zu einer konfigurierten Tabelle hinzugefügt wird, ermöglicht sie dem Mitglied, das Abfragen durchführen kann, Abfragen in der konfigurierten Tabelle auszuführen.
Die Aggregationsanalyseregel unterstützt Anwendungsfälle wie Kampagnenplanung, Medienreichweite, Frequenzmessung und Zuordnung.
Die unterstützte Abfragestruktur und Syntax sind in definiert. [Struktur und Syntax von Aggregationsabfragen](#agg-query-structure-syntax)
Zu den Parametern der Analyseregel, die in definiert sind[Regel für die Aggregationsanalyse — Steuerelemente abfragen](#agg-query-controls), gehören Abfragesteuerelemente und Steuerelemente für Abfrageergebnisse. Zu den Abfragesteuerelementen gehört die Möglichkeit, zu verlangen, dass eine konfigurierte Tabelle mit mindestens einer konfigurierten Tabelle verknüpft wird, deren Eigentümer das Mitglied ist, das Abfragen entweder direkt oder transitiv durchführen kann. Mit dieser Anforderung können Sie sicherstellen, dass die Abfrage an der Schnittstelle (INNERJOIN) zwischen Ihrer und ihrer Tabelle ausgeführt wird.
## Struktur und Syntax von Aggregationsabfragen
Abfragen in Tabellen, für die eine Aggregationsanalyseregel gilt, müssen der folgenden Syntax entsprechen.
```
--select_aggregate_function_expression
SELECT
aggregation_function(column_name) [[AS] column_alias ] [, ...]
--select_grouping_column_expression
[, {column_name|scalar_function(arguments)} [[AS] column_alias ]][, ...]
--table_expression
FROM table_name [[AS] table_alias ]
[[INNER] JOIN table_name [[AS] table_alias] ON join_condition] [...]
--where_expression
[WHERE where_condition]
--group_by_expression
[GROUP BY {column_name|scalar_function(arguments)}, ...]]
--having_expression
[HAVING having_condition]
--order_by_expression
[ORDER BY {column_name|scalar_function(arguments)} [{ASC|DESC}]] [,...]]
```
In der folgenden Tabelle werden alle in der vorherigen Syntax aufgeführten Ausdrücke erklärt.
| Expression | Definition | Beispiele |
| --- | --- | --- |
| select\$1aggregate\$1function\$1expression | Eine durch Kommas getrennte Liste mit den folgenden Ausdrücken: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/clean-rooms/latest/userguide/analysis-rules-aggregation.html) Es muss mindestens einen `select_aggregation_function_expression` in der geben. `select_aggregate_expression` | `SELECT SUM(PRICE), user_segment` |
| select\$1aggregation\$1function\$1expression | Eine oder mehrere unterstützte Aggregationsfunktionen, die auf eine oder mehrere Spalten angewendet werden. Nur Spalten sind als Argumente von Aggregationsfunktionen zulässig. Es muss mindestens einen `select_aggregation_function_expression` in der `select_aggregate_expression` geben. | `AVG(PRICE)` `COUNT(DISTINCT user_id)` |
| select\$1grouping\$1column\$1expression | Ein Ausdruck, der einen beliebigen Ausdruck enthalten kann, wobei Folgendes verwendet wird: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/clean-rooms/latest/userguide/analysis-rules-aggregation.html) `select_aggregate_expression`kann Spalten mit oder ohne den `AS` Parameter als Alias kennzeichnen. Weitere Informationen finden Sie in der [AWS Clean Rooms SQL-Referenz](https://docs.aws.amazon.com/clean-rooms/latest/sql-reference/sql-reference.html). | `TRUNC(timestampColumn)` `UPPER(campaignName)` |
| table\$1expression | Eine Tabelle oder eine Verknüpfung von Tabellen, mit der bedingte Join-Ausdrücke miteinander verbunden `join_condition` werden. `join_condition`gibt einen booleschen Wert zurück. Die `table_expression` Stützen: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/clean-rooms/latest/userguide/analysis-rules-aggregation.html) | FROM consumer_table
INNER JOIN provider_table
ON
consumer_table.identifier1 = provider_table.identifier1
AND
consumer_table.identifier2 = provider_table.identifier2
|
| where\$1expression | Ein bedingter Ausdruck, der einen booleschen Wert zurückgibt. Er kann aus Folgendem bestehen: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/clean-rooms/latest/userguide/analysis-rules-aggregation.html) Unterstützte Vergleichsbedingungen sind (`=, >, <, <=, >=, <>, !=, NOT, IN, NOT IN, LIKE, IS NULL, IS NOT NULL`). Unterstützte logische Operatoren sind (`AND, OR`). Die `where_expression` ist optional. | `WHERE where_condition` `WHERE price > 100` `WHERE TRUNC(timestampColumn) = '1/1/2022'` `WHERE timestampColumn = timestampColumn2 - 14` |
| group\$1by\$1expression | Eine durch Kommas getrennte Liste von Ausdrücken, die den Anforderungen für entsprechen. `select_grouping_column_expression` | `GROUP BY TRUNC(timestampColumn), UPPER(campaignName), segment` |
| having\$1expression | Ein bedingter Ausdruck, der einen booleschen Wert zurückgibt. Sie verfügen über eine unterstützte Aggregationsfunktion, die auf eine einzelne Spalte angewendet wird (z. B.`SUM(price)`), und sie werden mit einem numerischen Literal verglichen. Unterstützte Bedingungen sind ()`=, >, <, <=, >=, <>, !=`. Unterstützte logische Operatoren sind (`AND, OR`). Die `having_expression` ist optional. | `HAVING SUM(SALES) > 500` |
| order\$1by\$1expression | Eine durch Kommas getrennte Liste von Ausdrücken, die mit den gleichen Anforderungen kompatibel ist, die zuvor definiert `select_aggregate_expression` wurden. Die `order_by_expression` ist optional. `order_by_expression`Genehmigungen `ASC` und Parameter. `DESC` Weitere Informationen finden Sie unter ASC DESC-Parameter in der [AWS Clean Rooms SQL-Referenz](https://docs.aws.amazon.com/clean-rooms/latest/sql-reference/sql-reference.html). | `ORDER BY SUM(SALES), UPPER(campaignName)` |
Beachten Sie bei der Struktur und Syntax von Aggregationsabfragen Folgendes:
+ Andere SQL-Befehle als SELECT werden nicht unterstützt.
+ Unterabfragen und allgemeine Tabellenausdrücke (z. B.WITH) werden nicht unterstützt.
+ Operatoren, die mehrere Abfragen kombinieren (z. B.UNION), werden nicht unterstützt.
+ TOPLIMIT, und OFFSET Parameter werden nicht unterstützt.
## Regel für die Aggregationsanalyse — Steuerelemente abfragen
Mit Steuerelementen für Aggregationsabfragen können Sie steuern, wie die Spalten in Ihrer Tabelle zur Abfrage der Tabelle verwendet werden. Sie können beispielsweise steuern, welche Spalte für die Verknüpfung verwendet wird, welche Spalte gezählt werden kann oder welche Spalte in WHERE Anweisungen verwendet werden kann.
In den folgenden Abschnitten werden die einzelnen Steuerelemente erläutert.
**Topics**
+ [Steuerelemente für die Aggregation](#agg-functions)
+ [Steuerelemente verbinden](#join-controls)
+ [Steuerelemente für Dimensionen](#dimension-controls)
+ [Skalarfunktionen](#scalar-functions)
### Steuerelemente für die Aggregation
Mithilfe von *Aggregationssteuerelementen* können Sie definieren, welche Aggregationsfunktionen zulässig sind und auf welche Spalten sie angewendet werden müssen. Aggregationsfunktionen können in den Ausdrücken SELECTHAVING, und verwendet werden. ORDER BY
| Steuerung | Definition | Usage |
| --- | --- | --- |
| aggregateColumns | Spalten konfigurierter Tabellenspalten, die Sie für die Verwendung innerhalb von Aggregationsfunktionen zulassen. | `aggregateColumns`kann innerhalb einer Aggregationsfunktion in den Ausdrücken SELECTHAVING, und ORDER BY verwendet werden. Einige `aggregateColumns` können auch als `joinColumn` (später definiert) kategorisiert werden. Given `aggregateColumn` kann nicht auch als `dimensionColumn` (später definiert) kategorisiert werden. |
| function | Die Funktionen COUNT, SUM und AVG, die Sie zusätzlich zu verwenden zulassenaggregateColumns. | `function`kann auf eine angewendet werden`aggregateColumns`, die damit verknüpft ist. |
### Steuerelemente verbinden
Eine `JOIN` Klausel wird verwendet, um Zeilen aus zwei oder mehr Tabellen auf der Grundlage einer zugehörigen Spalte miteinander zu kombinieren.
Mithilfe von *Join-Steuerelementen* können Sie steuern, wie Ihre Tabelle mit anderen Tabellen in der verknüpft werden kann`table_expression`. AWS Clean Rooms unterstützt nur INNERJOIN. INNERJOINAnweisungen können nur Spalten verwenden, die `joinColumn` in Ihrer Analyseregel explizit als a kategorisiert wurden, und zwar vorbehaltlich der von Ihnen definierten Kontrollen.
Sie INNER JOIN müssen mit einer Tabelle `joinColumn` aus Ihrer konfigurierten Tabelle und mit einer Tabelle `joinColumn` aus einer anderen konfigurierten Tabelle in der Kollaboration arbeiten. Sie entscheiden, als welche Spalten aus Ihrer Tabelle verwendet werden können`joinColumn`.
Jede Übereinstimmungsbedingung innerhalb der ON Klausel muss die Gleichheitsvergleichsbedingung (`=`) zwischen zwei Spalten verwenden.
Es können mehrere Übereinstimmungsbedingungen innerhalb einer ON Klausel sein:
+ Kombiniert mit dem `AND` logischen Operator
+ Mit dem `OR` logischen Operator getrennt
**Anmerkung**
Alle JOIN Spielbedingungen müssen einer Zeile auf jeder Seite von entsprechenJOIN. Alle Bedingungen, die durch einen `OR` oder einen `AND` logischen Operator miteinander verbunden sind, müssen dieser Anforderung ebenfalls entsprechen.
Das Folgende ist ein Beispiel für eine Abfrage mit einem `AND` logischen Operator.
```
SELECT some_col, other_col
FROM table1
JOIN table2
ON table1.id = table2.id AND table1.name = table2.name
```
Das Folgende ist ein Beispiel für eine Abfrage mit einem `OR` logischen Operator.
```
SELECT some_col, other_col
FROM table1
JOIN table2
ON table1.id = table2.id OR table1.name = table2.name
```
| Steuerung | Definition | Usage |
| --- | --- | --- |
| joinColumns | Die Spalten (falls vorhanden), die Sie dem Mitglied, das Abfragen durchführen kann, in der INNER JOIN Anweisung verwenden dürfen. | Ein bestimmtes `joinColumn` Objekt kann auch als `aggregateColumn` (siehe[Steuerelemente für die Aggregation](#agg-functions)) kategorisiert werden. Dieselbe Spalte kann nicht gleichzeitig als `joinColumn` und verwendet werden `dimensionColumns` (siehe später). Sofern sie nicht auch als a kategorisiert wurde`aggregateColumn`, `joinColumn` kann sie in keinem anderen Teil der Abfrage als dem verwendet werden INNERJOIN. |
| joinRequired | Steuern Sie von dem Mitglied, das Abfragen durchführen kann, ob Sie eine INNER JOIN mit einer konfigurierten Tabelle benötigen. | Wenn Sie diesen Parameter aktivieren, INNER JOIN ist ein erforderlich. Wenn Sie diesen Parameter nicht aktivieren, INNER JOIN ist an optional. Angenommen, Sie aktivieren diesen Parameter, muss das Mitglied, das Abfragen durchführen kann, eine Tabelle, deren Eigentümer es ist, in die aufnehmen INNERJOIN. Sie müssen JOIN Ihre Tabelle mit ihrer Tabelle entweder direkt oder transitiv verbinden (d. h. sie verknüpfen ihre Tabelle mit einer anderen Tabelle, die wiederum mit Ihrer Tabelle verknüpft ist). |
Im Folgenden finden Sie ein Beispiel für Transitivität.
```
ON
my_table.identifer = third_party_table.identifier
....
ON
third_party_table.identifier = member_who_can_query_table.id
```
**Anmerkung**
Das Mitglied, das Abfragen durchführen kann, kann den `joinRequired` Parameter auch verwenden. In diesem Fall muss die Abfrage ihre Tabelle mit mindestens einer anderen Tabelle verknüpfen.
### Steuerelemente für Dimensionen
*Dimensionssteuerelemente* steuern die Spalte, anhand derer die Aggregationsspalten gefiltert, gruppiert oder aggregiert werden können.
| Steuerung | Definition | Usage |
| --- | --- | --- |
| dimensionColumns | Die Spalten (falls vorhanden), die Sie dem Mitglied, das Abfragen durchführen kannSELECT, in, WHERE GROUPBY, und verwenden dürfen. ORDER BY | A `dimensionColumn` kann in SELECT (`select_grouping_column_expression`), WHERE GROUPBY, und verwendet werden ORDERBY. Dieselbe Spalte kann nicht gleichzeitig a `dimensionColumn``joinColumn`, a und and/or an sein`aggregateColumn`. |
### Skalarfunktionen
*Skalarfunktionen* steuern, welche Skalarfunktionen für Dimensionsspalten verwendet werden können.
| Steuerung | Definition | Usage |
| --- | --- | --- |
| scalarFunctions | Die Skalarfunktionen, die `dimensionColumns` in der Abfrage verwendet werden können. | Gibt die Skalarfunktionen (falls vorhanden) an, auf die Sie (z. B.CAST) zulassen. `dimensionColumns` Skalarfunktionen können nicht zusätzlich zu anderen Funktionen oder innerhalb anderer Funktionen verwendet werden. Argumente von Skalarfunktionen können Spalten, Zeichenkettenliterale oder numerische Literale sein. |
Die folgenden Skalarfunktionen werden unterstützt:
+ Mathematische Funktionen — ABS, CEILING, FLOOR, LOG, LN, ROUND, SQRT
+ Funktionen zur Formatierung von Datentypen — CAST, CONVERT, TO\$1CHAR, TO\$1DATE, TO\$1NUMBER, TO\$1TIMESTAMP
+ Zeichenkettenfunktionen — LOWER, UPPER, TRIM, RTRIM, SUBSTRING
+ Für RTRIM sind benutzerdefinierte Zeichensätze zum Kürzen nicht zulässig.
+ Bedingte Ausdrücke — COALESCE
+ Datumsfunktionen — EXTRACT, GETDATE, CURRENT\$1DATE, DATEADD
+ Andere Funktionen — TRUNC
Weitere Informationen finden Sie in der [AWS Clean Rooms SQL-Referenz.](https://docs.aws.amazon.com/clean-rooms/latest/sql-reference/sql-reference.html)
## Regel für die Aggregationsanalyse — Steuerelemente für Abfrageergebnisse
Mit den Steuerelementen für Aggregationsabfrageergebnisse können Sie steuern, welche Ergebnisse zurückgegeben werden, indem Sie eine oder mehrere Bedingungen angeben, die jede Ausgabezeile erfüllen muss, damit sie zurückgegeben wird. AWS Clean Rooms unterstützt Aggregationseinschränkungen in der Form von. `COUNT (DISTINCT column) >= X` Dieses Formular erfordert, dass jede Zeile mindestens X verschiedene Werte einer Auswahl aus Ihrer konfigurierten Tabelle aggregiert (z. B. eine Mindestanzahl von unterschiedlichen `user_id` Werten). Dieser Mindestschwellenwert wird automatisch durchgesetzt, auch wenn die übermittelte Abfrage selbst die angegebene Spalte nicht verwendet. Sie werden gemeinsam für jede konfigurierte Tabelle in der Abfrage anhand der konfigurierten Tabellen aller Mitglieder der Kollaboration durchgesetzt.
Jede konfigurierte Tabelle muss mindestens eine Aggregationsbeschränkung in ihrer Analyseregel enthalten. Besitzer konfigurierter Tabellen können mehrere `columnName` und zugeordnete Tabellen hinzufügen, `minimum` und sie werden gemeinsam durchgesetzt.
### Einschränkungen bei der Aggregation
*Aggregationseinschränkungen* steuern, welche Zeilen in den Abfrageergebnissen zurückgegeben werden. Um zurückgegeben zu werden, muss eine Zeile die angegebene Mindestanzahl an unterschiedlichen Werten in jeder Spalte erfüllen, die in der Aggregationsbeschränkung angegeben ist. Diese Anforderung gilt auch dann, wenn die Spalte in der Abfrage oder in anderen Teilen der Analyseregel nicht ausdrücklich erwähnt wird.
| Steuerung | Definition | Usage |
| --- | --- | --- |
| columnName | Die`aggregateColumn`, die in der Bedingung verwendet wird, die jede Ausgabezeile erfüllen muss. | Es kann sich um eine beliebige Spalte in der konfigurierten Tabelle handeln. |
| minimum | Die Mindestanzahl an eindeutigen Werten für die Verknüpfung`aggregateColumn`, die die Ausgabezeile haben muss (z. B. COUNT DISTINCT), damit sie in den Abfrageergebnissen zurückgegeben wird. | Das `minimum` muss mindestens den Wert 2 haben. |
## Struktur der Regeln für die Aggregationsanalyse
Das folgende Beispiel zeigt eine vordefinierte Struktur für eine Aggregationsanalyseregel.
*`MyTable`*Bezieht sich im folgenden Beispiel auf Ihre Datentabelle. Sie können jede Information *user input placeholder* durch Ihre eigenen Informationen ersetzen.
```
{
"aggregateColumns": [
{
"columnNames": [MyTable column names], "function": [Allowed Agg Functions]
},
],
"joinRequired": ["QUERY_RUNNER"],
"joinColumns": [MyTable column names],
"dimensionColumns": [MyTable column names],
"scalarFunctions": [Allowed Scalar functions],
"outputConstraints": [
{
"columnName": [MyTable column names], "minimum": [Numeric value]
},
]
}
```
## Regel für die Aggregationsanalyse — Beispiel
Das folgende Beispiel zeigt, wie zwei Unternehmen AWS Clean Rooms mithilfe der Aggregationsanalyse zusammenarbeiten können.
Unternehmen A verfügt über Kunden- und Vertriebsdaten. Unternehmen A ist daran interessiert, die Aktivitäten zur Produktrückgabe zu verstehen. Unternehmen B ist einer der Einzelhändler von Unternehmen A und verfügt über Rückgabedaten. Unternehmen B verfügt auch über Segmentattribute für Kunden, die für Unternehmen A nützlich sind (z. B. ähnliche Produkte gekauft, den Kundendienst des Einzelhändlers in Anspruch genommen). Unternehmen B möchte keine Kundenrückgabedaten und Attributinformationen auf Zeilenebene bereitstellen. Unternehmen B möchte nur eine Reihe von Abfragen für Unternehmen A aktivieren, um aggregierte Statistiken über sich überschneidende Kunden bei einem Mindestaggregationsschwellenwert zu erhalten.
Unternehmen A und Unternehmen B beschließen, zusammenzuarbeiten, damit Unternehmen A die Produktrückgabeaktivitäten nachvollziehen und bessere Produkte für Unternehmen B und andere Vertriebskanäle liefern kann.
Um die Zusammenarbeit aufzubauen und eine Aggregationsanalyse durchzuführen, gehen die Unternehmen wie folgt vor:
1. Unternehmen A erstellt eine Kollaboration und erstellt eine Mitgliedschaft. Die Kollaboration hat Firma B als weiteres Mitglied der Kollaboration. Unternehmen A aktiviert die Abfrageprotokollierung in der Kollaboration und aktiviert die Abfrageprotokollierung in ihrem Konto.
1. Unternehmen B erstellt eine Mitgliedschaft in der Kollaboration. Es aktiviert die Abfrageprotokollierung in seinem Konto.
1. Firma A erstellt eine für den Vertrieb konfigurierte Tabelle.
1. Unternehmen A fügt der konfigurierten Tabelle für Verkäufe die folgende Aggregationsanalyseregel hinzu.
```
{
"aggregateColumns": [
{
"columnNames": [
"identifier"
],
"function": "COUNT_DISTINCT"
},
{
"columnNames": [
"purchases"
],
"function": "AVG"
},
{
"columnNames": [
"purchases"
],
"function": "SUM"
}
],
"joinColumns": [
"hashedemail"
],
"dimensionColumns": [
"demoseg",
"purchasedate",
"productline"
],
"scalarFunctions": [
"CAST",
"COALESCE",
"TRUNC"
],
"outputConstraints": [
{
"columnName": "hashedemail",
"minimum": 2,
"type": "COUNT_DISTINCT"
},
]
}
```
`aggregateColumns`— Unternehmen A möchte die Anzahl der einzelnen Kunden in der Überschneidung zwischen Verkaufsdaten und Retourendaten zählen. Unternehmen A möchte auch die Anzahl der `purchases` hergestellten Produkte summieren, um sie mit der Anzahl von zu vergleichen`returns`.
`joinColumns`— Unternehmen A `identifier` möchte damit Kunden aus Verkaufsdaten mit Kunden aus Retourendaten abgleichen. Dies hilft Unternehmen A dabei, Retouren den richtigen Käufen zuzuordnen. Es hilft Unternehmen A auch dabei, Kunden zu segmentieren, die sich überschneiden.
`dimensionColumns`— Unternehmen A filtert `dimensionColumns` nach einem bestimmten Produkt, vergleicht Käufe und Rücksendungen über einen bestimmten Zeitraum, stellt sicher, dass das Rückgabedatum nach dem Produktdatum liegt, und hilft dabei, sich überschneidende Kunden zu segmentieren.
`scalarFunctions`— Unternehmen A wählt die `CAST` Skalarfunktion aus, um Datentypformate bei Bedarf auf der Grundlage der konfigurierten Tabelle, die Unternehmen A der Zusammenarbeit zuordnet, zu aktualisieren. Außerdem werden Skalarfunktionen hinzugefügt, um bei Bedarf die Formatierung von Spalten zu erleichtern.
`outputConstraints`— Unternehmen A legt Mindestbeschränkungen für die Produktion fest. Die Ergebnisse müssen nicht eingeschränkt werden, da der Analyst Daten auf Zeilenebene aus seiner Verkaufstabelle einsehen kann
**Anmerkung**
Unternehmen A nimmt in der Analyseregel nichts `joinRequired` auf. Es bietet ihren Analysten die Flexibilität, nur die Verkaufstabelle abzufragen.
1. Firma B erstellt eine konfigurierte Tabelle für Renditen.
1. Unternehmen B fügt der konfigurierten Tabelle für Rücksendungen die folgende Aggregationsanalyseregel hinzu.
```
{
"aggregateColumns": [
{
"columnNames": [
"identifier"
],
"function": "COUNT_DISTINCT"
},
{
"columnNames": [
"returns"
],
"function": "AVG"
},
{
"columnNames": [
"returns"
],
"function": "SUM"
}
],
"joinColumns": [
"hashedemail"
],
"joinRequired": [
"QUERY_RUNNER"
],
"dimensionColumns": [
"state",
"popularpurchases",
"customerserviceuser",
"productline",
"returndate"
],
"scalarFunctions": [
"CAST",
"LOWER",
"UPPER",
"TRUNC"
],
"outputConstraints": [
{
"columnName": "hashedemail",
"minimum": 100,
"type": "COUNT_DISTINCT"
},
{
"columnName": "producttype",
"minimum": 2,
"type": "COUNT_DISTINCT"
}
]
}
```
`aggregateColumns`— Unternehmen B ermöglicht es Unternehmen A, eine Summe zu erstellen`returns`, um sie mit der Anzahl der Käufe zu vergleichen. Sie haben mindestens eine Aggregatspalte, da sie eine Aggregatabfrage ermöglichen.
`joinColumns`— Unternehmen B ermöglicht es Unternehmen A, sich zusammenzutun`identifier`, um Kunden anhand von Rückgabedaten mit Kunden aus Verkaufsdaten abzugleichen. `identifier`Daten sind besonders sensibel, und wenn sie als A verwendet werden, wird `joinColumn` sichergestellt, dass die Daten niemals in einer Abfrage ausgegeben werden.
`joinRequired`— Unternehmen B verlangt, dass sich Abfragen zu den Rückgabedaten mit den Verkaufsdaten überschneiden. Sie möchten es Unternehmen A nicht ermöglichen, alle Personen in ihrem Datensatz abzufragen. Sie haben sich auch in ihrer Kooperationsvereinbarung auf diese Einschränkung geeinigt.
`dimensionColumns`— Unternehmen B ermöglicht es Unternehmen A, nach `state``popularpurchases`, und eindeutigen Attributen zu filtern und zu gruppieren, `customerserviceuser` die bei der Analyse für Unternehmen A hilfreich sein könnten. Unternehmen B ermöglicht es Unternehmen A, die Ausgabe `returndate` danach `returndate` zu filtern`purchasedate`. Mit dieser Filterung ist die Ausgabe genauer, was die Bewertung der Auswirkungen der Produktänderung ermöglicht.
`scalarFunctions`— Unternehmen B ermöglicht Folgendes:
+ TRUNC für Daten
+ LOWER und UPPER, falls `producttype` die in ihren Daten in einem anderen Format eingegeben wurden
+ CASTwenn Unternehmen A die Datentypen im Vertrieb so konvertieren muss, dass sie den Datentypen in Rücksendungen entsprechen
Unternehmen A aktiviert keine anderen Skalarfunktionen, da sie nicht der Meinung sind, dass sie für Abfragen erforderlich sind.
`outputConstraints`— Unternehmen B legt Mindestbeschränkungen für die Produktion fest`hashedemail`, um die Möglichkeit zu verringern, Kunden neu zu identifizieren. Außerdem werden Mindestbeschränkungen für die Produktion eingeführt`producttype`, um die Möglichkeit zu verringern, bestimmte Produkte, die zurückgegeben wurden, erneut zu identifizieren. Bestimmte Produkttypen könnten aufgrund der Größe der Produktion dominanter sein (z. B.`state`). Ihre Produktionsbeschränkungen werden immer durchgesetzt, unabhängig von den Produktionsbeschränkungen, die Unternehmen A ihren Daten hinzugefügt hat.
1. Firma A erstellt eine Verkaufstabelle, die der Zusammenarbeit zugeordnet ist.
1. Firma B erstellt eine Verknüpfung der Tabelle mit Rücksendungen zur Zusammenarbeit.
1. Unternehmen A führt Abfragen wie das folgende Beispiel durch, um besser zu verstehen, wie viele Retouren in Unternehmen B im Vergleich zu den Gesamteinkäufen pro Standort im Jahr 2022 getätigt wurden.
```
SELECT
companyB.state,
SUM(companyB.returns),
COUNT(DISTINCT companyA.hashedemail)
FROM
sales companyA
INNER JOIN returns companyB ON companyA.identifier = companyB.identifier
WHERE
companyA.purchasedate BETWEEN '2022-01-01' AND '2022-12-31' AND
TRUNC(companyB.returndate) > companyA.purchasedate
GROUP BY
companyB.state;
```
1. Unternehmen A und Unternehmen B überprüfen die Abfrageprotokolle. Unternehmen B überprüft, ob die Anfrage mit dem übereinstimmt, was in der Kooperationsvereinbarung vereinbart wurde.
## Behebung von Problemen mit Regeln für die Aggregationsanalyse
Verwenden Sie die Informationen hier, um häufig auftretende Probleme bei der Arbeit mit Aggregationsanalyseregeln zu diagnostizieren und zu beheben.
**Topics**
+ [Meine Abfrage lieferte keine Ergebnisse](#query-no-results)
### Meine Abfrage lieferte keine Ergebnisse
Dies kann passieren, wenn es keine passenden Ergebnisse gibt oder wenn die übereinstimmenden Ergebnisse einen oder mehrere Mindestaggregationsschwellenwerte nicht erreichen.
Weitere Informationen zu Mindestschwellenwerten für die Aggregation finden Sie unter. [Regel für die Aggregationsanalyse — Beispiel](#agg-analysis-rule-example)
# Regel für die Listenanalyse
In AWS Clean Rooms gibt eine *Listenanalyseregel* Listen mit Überschneidungen zwischen der konfigurierten Tabelle, der sie hinzugefügt wurde, und den konfigurierten Tabellen des Mitglieds, das Abfragen durchführen kann, auf Zeilenebene aus. Das Mitglied, das Abfragen durchführen kann, führt Abfragen aus, die eine Listenanalyseregel enthalten.
Der Regeltyp „Listenanalyse“ unterstützt Anwendungsfälle wie Anreicherung und Zielgruppenbildung.
Weitere Informationen zur vordefinierten Abfragestruktur und Syntax für diese Analyseregel finden Sie unter[Vordefinierte Struktur der Listenanalyseregel](#intersection-list-params-template).
Die Parameter der in [Regel für die Listenanalyse — Steuerelemente abfragen](#parameters-list-query-controls) definierten Listenanalyseregel verfügen über Abfragesteuerelemente. Zu den Abfragesteuerelementen gehört die Möglichkeit, die Spalten auszuwählen, die in der Ausgabe aufgeführt werden können. Für die Abfrage ist mindestens eine Verknüpfung mit einer konfigurierten Tabelle des Mitglieds erforderlich, das Abfragen entweder direkt oder transitiv durchführen kann.
Es gibt keine Steuerelemente für Abfrageergebnisse wie bei der [Aggregationsanalyseregel](analysis-rules-aggregation.md).
Listenabfragen können nur mathematische Operatoren verwenden. Sie können keine anderen Funktionen (wie Aggregation oder Skalar) verwenden.
**Topics**
+ [Struktur und Syntax von Abfragen auflisten](#list-query-controls)
+ [Regel für die Listenanalyse — Steuerelemente abfragen](#parameters-list-query-controls)
+ [Vordefinierte Struktur der Listenanalyseregel](#intersection-list-params-template)
+ [Regel zur Listenanalyse — Beispiel](#list-example)
## Struktur und Syntax von Abfragen auflisten
Abfragen in Tabellen, für die eine Listenanalyseregel gilt, müssen der folgenden Syntax entsprechen.
```
--select_list_expression
SELECT DISTINCT column_name [[AS] column_alias ] [, ...]
--table_expression
FROM table_name [[AS] table_alias ]
[[INNER] JOIN table_name [[AS] table_alias] ON join_condition] [...]
--where_expression
[WHERE where_condition]
--limit_expression
[LIMIT number]
```
In der folgenden Tabelle werden alle in der vorherigen Syntax aufgeführten Ausdrücke erklärt.
| Expression | Definition | Beispiele |
| --- | --- | --- |
| select\$1list\$1expression | Eine durch Kommas getrennte Liste, die mindestens einen Tabellenspaltennamen enthält. Ein `DISTINCT` Parameter ist erforderlich. `select_list_expression`Sie können Spalten mit oder ohne den `AS` Parameter als Alias verwenden. Weitere Informationen finden Sie in der [AWS Clean Rooms SQL-Referenz](https://docs.aws.amazon.com/clean-rooms/latest/sql-reference/sql-reference.html). | `SELECT DISTINCT segment` |
| table\$1expression | Eine Tabelle oder eine Verknüpfung von Tabellen, mit der eine `join_condition` Verbindung hergestellt `join_condition` werden soll. `join_condition`gibt einen booleschen Wert zurück. Die `table_expression` Stützen: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/clean-rooms/latest/userguide/analysis-rules-list.html) | FROM consumer_table
INNER JOIN provider_table
ON
consumer_table.identifier1 = provider_table.identifier1
AND
consumer_table.identifier2 = provider_table.identifier2
|
| where\$1expression | Ein bedingter Ausdruck, der einen booleschen Wert zurückgibt. Er kann aus folgenden Elementen bestehen:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/clean-rooms/latest/userguide/analysis-rules-list.html)Unterstützte Vergleichsbedingungen sind (`=, >, <, <=, >=, <>, !=, NOT, IN, NOT IN, LIKE, IS NULL, IS NOT NULL`). Unterstützte logische Operatoren sind (`AND, OR`).Die `where_expression` ist optional. | `WHERE state + '_' + city = 'NY_NYC'` `WHERE timestampColumn = timestampColumn2 - 14` |
| limit\$1expression | Dieser Ausdruck muss eine positive Ganzzahl enthalten. Die `limit_expression` ist optional. | `LIMIT 100` |
Beachten Sie bei der Struktur und Syntax von Listenabfragen Folgendes:
+ Andere SQL-Befehle als SELECT werden nicht unterstützt.
+ Unterabfragen und allgemeine Tabellenausdrücke (z. B.WITH) werden nicht unterstützt
+ Die BY Klauseln GROUP BY HAVING, und ORDER werden nicht unterstützt
+ Der OFFSET-Parameter wird nicht unterstützt
## Regel für die Listenanalyse — Steuerelemente abfragen
Mit Steuerelementen für Listenabfragen können Sie steuern, wie die Spalten in Ihrer Tabelle zum Abfragen der Tabelle verwendet werden. Sie können beispielsweise steuern, welche Spalte für die Verknüpfung verwendet wird oder welche Spalte in der SELECT-Anweisung und WHERE -Klausel verwendet werden kann.
In den folgenden Abschnitten werden die einzelnen Steuerelemente erläutert.
**Topics**
+ [Steuerelemente verbinden](#list-controls-join-controls)
+ [Steuerelemente auflisten](#list-controls)
### Steuerelemente verbinden
Mit *Join-Steuerelementen* können Sie steuern, wie Ihre Tabelle mit anderen Tabellen in **table\$1expression** verknüpft werden kann. AWS Clean Rooms unterstützt INNER nur JOIN. In der Regel für die Listenanalyse ist mindestens ein INNER JOIN erforderlich, und das Mitglied, das Abfragen durchführen kann, muss eine Tabelle, deren Eigentümer es ist, in den INNER JOIN aufnehmen. Das bedeutet, dass sie Ihre Tabelle entweder direkt oder transitiv mit ihrer Tabelle verknüpfen müssen.
Im Folgenden finden Sie ein Beispiel für Transitivität.
```
ON
my_table.identifer = third_party_table.identifier
....
ON
third_party_table.identifier = member_who_can_query_table.id
```
INNERJOIN-Anweisungen können nur Spalten verwenden, die `joinColumn` in Ihrer Analyseregel explizit als a kategorisiert wurden.
Der INNER JOIN-Befehl muss für eine Tabelle `joinColumn` aus Ihrer konfigurierten Tabelle und für eine Tabelle `joinColumn` aus einer anderen konfigurierten Tabelle in der Kollaboration ausgeführt werden. Sie entscheiden, als welche Spalten aus Ihrer Tabelle verwendet werden können`joinColumn`.
Jede Übereinstimmungsbedingung innerhalb der ON Klausel muss die Gleichheitsvergleichsbedingung (`=`) zwischen zwei Spalten verwenden.
Es können mehrere Übereinstimmungsbedingungen innerhalb einer ON Klausel sein:
+ Kombiniert mit dem `AND` logischen Operator
+ Mit dem `OR` logischen Operator getrennt
**Anmerkung**
Alle JOIN Spielbedingungen müssen einer Zeile auf jeder Seite von entsprechenJOIN. Alle Bedingungen, die durch einen `OR` oder einen `AND` logischen Operator miteinander verbunden sind, müssen dieser Anforderung ebenfalls entsprechen.
Das Folgende ist ein Beispiel für eine Abfrage mit einem `AND` logischen Operator.
```
SELECT some_col, other_col
FROM table1
JOIN table2
ON table1.id = table2.id AND table1.name = table2.name
```
Im Folgenden finden Sie ein Beispiel für eine Abfrage mit einem `OR` logischen Operator.
```
SELECT some_col, other_col
FROM table1
JOIN table2
ON table1.id = table2.id OR table1.name = table2.name
```
| Steuerung | Definition | Usage |
| --- | --- | --- |
| joinColumns | Die Spalten, die Sie dem Mitglied, das Abfragen durchführen kann, in der INNER JOIN-Anweisung verwenden dürfen. | Dieselbe Spalte kann nicht sowohl als als `joinColumn` auch kategorisiert werden `listColumn` (siehe[Steuerelemente auflisten](#list-controls)). `joinColumn`kann in keinem anderen Teil der Abfrage als INNER JOIN verwendet werden. |
### Steuerelemente auflisten
*Listensteuerelemente* steuern die Spalten, die in der Abfrageausgabe aufgeführt (d. h. in der SELECT-Anweisung verwendet) oder zum Filtern von Ergebnissen (d. h. in der WHERE Anweisung verwendet) verwendet werden können.
| Steuerung | Definition | Usage |
| --- | --- | --- |
| listColumns | Die Spalten, die Sie dem Mitglied, das Abfragen abfragen kann, in SELECT verwenden dürfen und WHERE | A listColumn kann in SELECT und verwendet werdenWHERE.Dieselbe Spalte kann nicht gleichzeitig als ein `listColumn` und verwendet werden`joinColumn`. |
## Vordefinierte Struktur der Listenanalyseregel
Das folgende Beispiel enthält eine vordefinierte Struktur, die zeigt, wie Sie eine Listenanalyseregel abschließen.
*`MyTable`*Bezieht sich im folgenden Beispiel auf Ihre Datentabelle. Sie können jede Information *user input placeholder* durch Ihre eigenen Informationen ersetzen.
```
{
"joinColumns": [MyTable column name(s)],
"listColumns": [MyTable column name(s)],
}
```
## Regel zur Listenanalyse — Beispiel
Das folgende Beispiel zeigt, wie zwei Unternehmen AWS Clean Rooms mithilfe der Listenanalyse zusammenarbeiten können.
Unternehmen A verfügt über Daten zum Kundenbeziehungsmanagement (CRM). Unternehmen A möchte zusätzliche Segmentdaten über seine Kunden erhalten, um mehr über ihre Kunden zu erfahren und möglicherweise Attribute als Input für andere Analysen zu verwenden. Unternehmen B verfügt über Segmentdaten, die aus eindeutigen Segmentattributen bestehen, die das Unternehmen auf der Grundlage seiner eigenen Daten erstellt hat. Unternehmen B möchte Unternehmen A die eindeutigen Segmentattribute nur für Kunden zur Verfügung stellen, deren Daten sich mit den Daten von Unternehmen A überschneiden.
Die Unternehmen beschließen, zusammenzuarbeiten, damit Unternehmen A die sich überschneidenden Daten anreichern kann. Unternehmen A ist das Mitglied, das Abfragen durchführen kann, und Unternehmen B ist der Mitwirkende.
Um eine Zusammenarbeit zu erstellen und gemeinsam eine Listenanalyse durchzuführen, gehen die Unternehmen wie folgt vor:
1. Unternehmen A erstellt eine Kollaboration und erstellt eine Mitgliedschaft. Die Kollaboration hat Firma B als weiteres Mitglied der Kollaboration. Unternehmen A aktiviert die Abfrageprotokollierung in der Kollaboration und sie aktiviert die Abfrageprotokollierung in ihrem Konto.
1. Unternehmen B erstellt eine Mitgliedschaft in der Kollaboration. Es aktiviert die Abfrageprotokollierung in seinem Konto.
1. Firma A erstellt eine für CRM konfigurierte Tabelle
1. Unternehmen A fügt die Analyseregel der vom Kunden konfigurierten Tabelle hinzu, wie im folgenden Beispiel gezeigt.
```
{
"joinColumns": [
"identifier1",
"identifier2"
],
"listColumns": [
"internalid",
"segment1",
"segment2",
"customercategory"
]
}
```
`joinColumns`— Unternehmen A möchte `hashedemail` and/or `thirdpartyid` (von einem Identitätsanbieter bezogen) verwenden, um Kunden aus CRM-Daten mit Kunden aus Segmentdaten abzugleichen. Auf diese Weise kann sichergestellt werden, dass Unternehmen A angereicherte Daten den richtigen Kunden zuordnet. Sie verfügen über zwei JoinColumns, um die Trefferquote der Analyse potenziell zu verbessern.
`listColumns`— Unternehmen A verwendet`listColumns`, um zusätzlich angereicherte Spalten zu erhalten und `internalid` sie in ihren eigenen Systemen zu verwenden. Sie fügen `segment1` hinzu `segment2` und `customercategory` beschränken die Anreicherung möglicherweise auf bestimmte Segmente, indem sie sie in Filtern verwenden.
1. Firma B erstellt eine segmentkonfigurierte Tabelle.
1. Firma B fügt die Analyseregel zur segmentkonfigurierten Tabelle hinzu.
```
{
"joinColumns": [
"identifier2"
],
"listColumns": [
"segment3",
"segment4"
]
}
```
`joinColumns`— Unternehmen B ermöglicht es Unternehmen A, gemeinsam Kunden `identifier2` anhand von Segmentdaten mit CRM-Daten abzugleichen. Unternehmen A und Unternehmen B arbeiteten mit dem Identitätsanbieter zusammen, um herauszufinden, `identifier2` welcher Anbieter für diese Zusammenarbeit geeignet wäre. Andere wurden nicht hinzugefügt, `joinColumns` da sie der Meinung waren, dass sie die höchste und genaueste Trefferquote `identifier2` bieten und andere Identifikatoren für die Abfragen nicht erforderlich sind.
`listColumns`— Unternehmen B ermöglicht es Unternehmen A, seine Daten mit `segment3` `segment4` Attributen anzureichern. Dabei handelt es sich um einzigartige Attribute, die das Unternehmen im Rahmen der Datenanreicherung erstellt, gesammelt und (mit Kunde A) abgestimmt hat. Sie möchten, dass Unternehmen A diese Segmente für die Überschneidung auf Zeilenebene erhält, da es sich um eine Zusammenarbeit im Bereich der Datenanreicherung handelt.
1. Unternehmen A erstellt eine CRM-Tabellenzuordnung zur Kollaboration.
1. Unternehmen B erstellt eine Segmenttabellenzuordnung zur Kollaboration.
1. Unternehmen A führt Abfragen wie die folgende aus, um sich überschneidende Kundendaten anzureichern.
```
SELECT companyA.internalid, companyB.segment3, companyB.segment4
INNER JOIN returns companyB
ON companyA.identifier2 = companyB.identifier2
WHERE companyA.customercategory > 'xxx'
```
1. Unternehmen A und Unternehmen B überprüfen die Abfrageprotokolle. Unternehmen B überprüft, ob die Anfrage mit dem übereinstimmt, was in der Kooperationsvereinbarung vereinbart wurde.
# Benutzerdefinierte Analyseregel in AWS Clean Rooms
In AWS Clean Rooms ist eine *benutzerdefinierte Analyseregel* ein neuer Typ von Analyseregel, mit dem benutzerdefinierte Abfragen für die konfigurierte Tabelle ausgeführt werden können. Benutzerdefinierte SQL-Abfragen sind weiterhin darauf beschränkt, nur den SELECT Befehl zu verwenden, können aber mehr SQL-Konstrukte als [Aggregations](analysis-rules-aggregation.md#agg-query-controls) - und [Listenabfragen](analysis-rules-list.md#list-query-controls) verwenden (z. B. Fensterfunktionen, OUTER JOIN oder Unterabfragen; eine vollständige Liste finden Sie in der [AWS Clean Rooms SQL-Referenz](https://docs.aws.amazon.com/clean-rooms/latest/sql-reference/sql-reference.html)). CTEs [Benutzerdefinierte SQL-Abfragen müssen nicht wie [Aggregations](analysis-rules-aggregation.md#agg-query-structure-syntax) - und Listenabfragen einer Abfragestruktur folgen.](analysis-rules-list.md#list-query-controls)
Die benutzerdefinierte Analyseregel unterstützt komplexere Anwendungsfälle als solche, die von der Aggregations- und Listenanalyseregel unterstützt werden können, z. B. benutzerdefinierte Attributionsanalysen, Benchmarking, Inkrementalitätsanalysen und Zielgruppenerkennung. Dies gilt zusätzlich zu einer Vielzahl von Anwendungsfällen, die von der Aggregations- und Listenanalyseregel unterstützt werden.
Die benutzerdefinierte Analyseregel unterstützt auch den differenziellen Datenschutz. Differential Privacy ist ein mathematisch strenges Rahmenwerk für den Datenschutz. Weitere Informationen finden Sie unter [AWS Clean Rooms Differenzierter Datenschutz](differential-privacy.md). Wenn Sie eine Analysevorlage erstellen, überprüft AWS Clean Rooms Differential Privacy die Vorlage, um festzustellen, ob sie mit der allgemeinen Abfragestruktur für Differential Privacy kompatibel ist. AWS Clean Rooms Durch diese Überprüfung wird sichergestellt, dass Sie keine Analysevorlage erstellen, die in einer durch Differential Privacy geschützten Tabelle nicht zulässig ist.
Um die benutzerdefinierte Analyseregel zu konfigurieren, können Datenbesitzer festlegen, dass bestimmte benutzerdefinierte Abfragen, die in [Analysevorlagen gespeichert sind, für](create-analysis-template.md) ihre konfigurierten Tabellen ausgeführt werden. Datenbesitzer überprüfen Analysevorlagen, bevor sie sie der zulässigen Analysesteuerung in der benutzerdefinierten Analyseregel hinzufügen. Analysevorlagen sind nur in der Kollaboration verfügbar und sichtbar, in der sie erstellt wurden (auch wenn die Tabelle mit anderen Kollaborationen verknüpft ist). Sie können nur von dem Mitglied ausgeführt werden, das in dieser Kollaboration Abfragen durchführen kann.
Alternativ können sich Mitglieder dafür entscheiden, anderen Mitgliedern (Abfrageanbietern) zu gestatten, Abfragen ohne Überprüfung zu erstellen. Mitglieder fügen in der benutzerdefinierten Analyseregel Konten von Abfrageanbietern hinzu, die über die zulässigen Abfrageanbieter verfügen. Wenn der Abfrageanbieter das Mitglied ist, das Abfragen durchführen kann, könnten sie jede Abfrage direkt in der konfigurierten Tabelle ausführen. Abfrageanbieter könnten Abfragen auch erstellen, indem sie [Analysevorlagen erstellen](create-analysis-template.md). Alle Abfragen, die von den Abfrageanbietern erstellt wurden, dürfen automatisch für die Tabelle in allen Kollaborationen ausgeführt werden, in denen die AWS-Konto vorhanden und die Tabelle verknüpft ist.
Datenbesitzer können nur Analysevorlagen oder Konten erlauben, Abfragen zu erstellen, nicht beides. Wenn der Datenbesitzer dieses Feld leer lässt, kann das Mitglied, das Abfragen durchführen kann, keine Abfragen für die konfigurierte Tabelle ausführen.
**Topics**
+ [Benutzerdefinierte Analyseregel, vordefinierte Struktur](#custom-predefined-structure)
+ [Beispiel für eine benutzerdefinierte Analyseregel](#custom-example)
+ [Benutzerdefinierte Analyseregel mit differenziellem Datenschutz](#custom-diff-privacy)
## Benutzerdefinierte Analyseregel, vordefinierte Struktur
Das folgende Beispiel enthält eine vordefinierte Struktur, die zeigt, wie Sie eine benutzerdefinierte Analyseregel mit aktiviertem differenziellen Datenschutz abschließen. Der `userIdentifier` Wert ist die Spalte, die Ihre Benutzer eindeutig identifiziert, z. B. *user\$1id*. Wenn Sie in einer Kollaboration zwei oder mehr Tabellen mit aktiviertem differenziellen Datenschutz haben, AWS Clean Rooms müssen Sie in beiden Analyseregeln dieselbe Spalte wie die Benutzer-ID-Spalte konfigurieren, um eine konsistente Definition der Benutzer in allen Tabellen aufrechtzuerhalten.
```
{
"allowedAnalyses": ["ANY_QUERY"] | string[],
"allowedAnalysisProviders": [],
"differentialPrivacy": {
"columns": [
{
"name": "userIdentifier"
}
]
}
}
```
Führen Sie dazu einen der folgenden Schritte aus:
+ Fügen Sie der Steuerung „Zulässige Analysen“ eine Analysevorlage ARNs hinzu. In diesem Fall ist das `allowedAnalysisProviders` Steuerelement nicht enthalten.
```
{
allowedAnalyses: string[]
}
```
+ Fügt AWS-Konto IDs dem `allowedAnalysisProviders` Steuerelement ein Mitglied hinzu. In diesem Fall fügen Sie dem `allowedAnalyses` Steuerelement etwas `ANY_QUERY` hinzu.
```
{
allowedAnalyses: ["ANY_QUERY"],
allowedAnalysisProviders: string[]
}
```
## Beispiel für eine benutzerdefinierte Analyseregel
Das folgende Beispiel zeigt, wie zwei Unternehmen AWS Clean Rooms mithilfe der benutzerdefinierten Analyseregel zusammenarbeiten können.
Unternehmen A verfügt über Kunden- und Vertriebsdaten. Unternehmen A ist daran interessiert, die Umsatzsteigerung einer Werbekampagne auf der Website von Unternehmen B zu verstehen. Unternehmen B verfügt über Zuschauerdaten und Segmentattribute, die für Unternehmen nützlich sind (z. B. das Gerät, mit dem sie sich die Werbung angesehen haben).
Unternehmen A hat eine spezielle Inkrementalitätsabfrage, die im Rahmen der Zusammenarbeit ausgeführt werden soll.
Um eine Zusammenarbeit zu erstellen und gemeinsam eine benutzerdefinierte Analyse durchzuführen, gehen die Unternehmen wie folgt vor:
1. Unternehmen A erstellt eine Kollaboration und erstellt eine Mitgliedschaft. Die Kollaboration hat Firma B als weiteres Mitglied der Kollaboration. Unternehmen A aktiviert die Abfrageprotokollierung in der Kollaboration und sie aktiviert die Abfrageprotokollierung in ihrem Konto.
1. Unternehmen B erstellt eine Mitgliedschaft in der Kollaboration. Es aktiviert die Abfrageprotokollierung in seinem Konto.
1. Firma A erstellt eine für CRM konfigurierte Tabelle
1. Unternehmen A fügt der für den Vertrieb konfigurierten Tabelle eine leere benutzerdefinierte Analyseregel hinzu.
1. Firma A ordnet der Kollaboration eine für den Vertrieb konfigurierte Tabelle zu.
1. Unternehmen B erstellt eine für die Zuschauerzahl konfigurierte Tabelle.
1. Unternehmen B fügt der für die Zuschauerzahl konfigurierten Tabelle eine leere benutzerdefinierte Analyseregel hinzu.
1. Unternehmen B ordnet der Kollaboration eine für die Zuschauerzahl konfigurierte Tabelle zu.
1. Unternehmen A zeigt die der Kollaboration zugeordnete Verkaufstabelle und die Tabelle mit den Zuschauerzahlen an und erstellt eine Analysevorlage, in der die Inkrementalitätsabfrage und der Parameter für den Kampagnenmonat hinzugefügt werden.
```
{
"analysisParameters": [
{
"defaultValue": ""
"type": "DATE"
"name": "campaign_month"
}
],
"description": "Monthly incrementality query using sales and viewership data"
"format": "SQL"
"name": "Incrementality analysis"
"source":
"WITH labeleddata AS
(
SELECT hashedemail, deviceid, purchases, unitprice, purchasedate,
CASE
WHEN testvalue IN ('value1', 'value2', 'value3') THEN 0
ELSE 1
END AS testgroup
FROM viewershipdata
)
SELECT labeleddata.purchases, provider.impressions
FROM labeleddata
INNER JOIN salesdata
ON labeleddata.hashedemail = provider.hashedemail
WHERE MONTH(labeleddata.purchasedate) > :campaignmonth
AND testgroup = :group
"
}
```
1. Unternehmen A fügt sein Konto (z. B. 444455556666) zur Steuerung des zulässigen Analyseanbieters in der benutzerdefinierten Analyseregel hinzu. Sie verwenden das Steuerelement für zugelassene Analyseanbieter, weil sie zulassen möchten, dass alle von ihnen erstellten Abfragen in ihrer für den Vertrieb konfigurierten Tabelle ausgeführt werden.
```
{
"allowedAnalyses": [
"ANY_QUERY"
],
"allowedAnalysisProviders": [
"444455556666"
]
}
```
1. Unternehmen B sieht die erstellte Analysevorlage in der Kollaboration und überprüft ihren Inhalt, einschließlich der Abfragezeichenfolge und des Parameters.
1. Unternehmen B stellt fest, dass die Analysevorlage den Anwendungsfall Inkrementalität erfüllt und die Datenschutzanforderungen hinsichtlich der Art und Weise, wie die für die Zuschauerzahl konfigurierte Tabelle abgefragt werden kann, erfüllt.
1. Unternehmen B fügt den ARN der Analysevorlage zur zulässigen Analysesteuerung in der benutzerdefinierten Analyseregel der Zuschauerschaftstabelle hinzu. Sie verwenden das zulässige Analysesteuerelement, weil sie nur zulassen möchten, dass die Inkrementalitätsabfrage für ihre für die Zuschauerzahl konfigurierte Tabelle ausgeführt wird.
```
{
"allowedAnalyses": [
"arn:aws:cleanrooms:us-east-1:111122223333:membership/41327cc4-bbf0-43f1-b70c-a160dddceb08/analysistemplate/1ff1bf9d-781c-418d-a6ac-2b80c09d6292"
]
}
```
1. Unternehmen A führt die Analysevorlage aus und verwendet den Parameterwert. `05-01-2023`
## Benutzerdefinierte Analyseregel mit differenziellem Datenschutz
In AWS Clean Rooms, die benutzerdefinierte Analyseregel unterstützt differenziellen Datenschutz. Differential Privacy ist ein mathematisch strenger Rahmen für den Datenschutz, der Ihnen hilft, Ihre Daten vor Reidentifikationsversuchen zu schützen.
Differential Privacy unterstützt aggregierte Analysen wie die Planung und post-ad-campaign Messung von Werbekampagnen, Benchmarking in einem Konsortium von Finanzinstituten und A/B-Tests für die Gesundheitsforschung.
Die unterstützte Abfragestruktur und Syntax sind in definiert. [Struktur und Syntax der Abfrage](#dp-query-structure-syntax)
### Beispiel für eine benutzerdefinierte Analyseregel mit differenziertem Datenschutz
**Anmerkung**
AWS Clean Rooms Differential Privacy ist nur für Kollaborationen verfügbar, bei denen die Daten in Amazon S3 gespeichert sind.
Sehen Sie sich das [Beispiel für eine benutzerdefinierte Analyseregel](#custom-example) an, das im vorherigen Abschnitt vorgestellt wurde. Dieses Beispiel zeigt, wie Sie Differential Privacy nutzen können, um Ihre Daten vor Reidentifikationsversuchen zu schützen und gleichzeitig Ihrem Partner die Möglichkeit zu geben, geschäftskritische Erkenntnisse aus Ihren Daten zu gewinnen. Gehen Sie davon aus, dass Unternehmen B, das über die Zuschauerdaten verfügt, seine Daten mithilfe von Differential Privacy schützen möchte. Um die Einrichtung des differenzierten Datenschutzes abzuschließen, führt Unternehmen B die folgenden Schritte durch:
1. Unternehmen B aktiviert den differenziellen Datenschutz und fügt gleichzeitig eine benutzerdefinierte Analyseregel zur konfigurierten Tabelle für die Zuschauerzahl hinzu. Unternehmen B wählt diese `viewershipdata.hashedemail` Spalte als Benutzer-ID aus.
1. Unternehmen B [fügt der Zusammenarbeit eine differenzierte Datenschutzrichtlinie](configure-differential-privacy.md) hinzu, um die Tabelle mit den Zuschauerzahlen für Abfragen verfügbar zu machen. Unternehmen B wählt die Standardrichtlinie aus, um die Einrichtung schnell abzuschließen.
Unternehmen A, das die Umsatzsteigerung einer Werbekampagne auf der Website von Unternehmen B verstehen möchte, führt die Analysevorlage aus. Da die Abfrage mit der allgemeinen [Abfragestruktur von AWS Clean Rooms Differential Privacy kompatibel ist, wird die Abfrage](#dp-query-structure-syntax) erfolgreich ausgeführt.
### Struktur und Syntax der Abfrage
Abfragen, die mindestens eine Tabelle enthalten, für die Differential Privacy aktiviert ist, müssen der folgenden Syntax entsprechen.
```
query_statement:
[cte, ...] final_select
cte:
WITH sub_query AS (
inner_select
[ UNION | INTERSECT | UNION_ALL | EXCEPT/MINUS ]
[ inner_select ]
)
inner_select:
SELECT [user_id_column, ] expression [, ...]
FROM table_reference [, ...]
[ WHERE condition ]
[ GROUP BY user_id_column[, expression] [, ...] ]
[ HAVING condition ]
final_select:
SELECT [expression, ...] | COUNT | COUNT_DISTINCT | SUM | AVG | STDDEV
FROM table_reference [, ...]
[ WHERE condition ]
[ GROUP BY expression [, ...] ]
[ HAVING COUNT | COUNT_DISTINCT | SUM | AVG | STDDEV | condition ]
[ ORDER BY column_list ASC | DESC ]
[ OFFSET literal ]
[ LIMIT literal ]
expression:
column_name [, ...] | expression AS alias | aggregation_functions | window_functions_on_user_id | scalar_function | CASE | column_name math_expression [, expression]
window_functions_on_user_id:
function () OVER (PARTITION BY user_id_column, [column_name] [ORDER BY column_list ASC|DESC])
```
**Anmerkung**
Beachten Sie bei der Struktur und Syntax von Differential Privacy Abfragen Folgendes:
Unterabfragen werden nicht unterstützt.
Common Table Expressions (CTEs) sollte die Benutzer-ID-Spalte ausgeben, wenn eine Tabelle oder ein CTE Daten enthält, die durch Differential Privacy geschützt sind. Filter, Gruppierungen und Aggregationen sollten auf Benutzerebene vorgenommen werden.
Final\$1Select ermöglicht die Aggregatfunktionen COUNT DISTINCT, COUNT, SUM, AVG und STDDEV.
Weitere Informationen darüber, welche SQL-Schlüsselwörter für Differential Privacy unterstützt werden, finden Sie unter. [SQL-Funktionen von AWS Clean Rooms Differential Privacy](dp-sql-capabilities.md)
# Regel zur Analyse von ID-Zuordnungstabellen
In AWS Clean Rooms ist eine *Analyseregel für ID-Zuordnungstabellen* keine eigenständige Analyseregel. Diese Art von Analyseregel wird von unterschiedlichen Identitätsdaten verwaltet AWS Clean Rooms und verwendet, um das Abfragen zu erleichtern. Sie wird automatisch zu ID-Zuordnungstabellen hinzugefügt und kann nicht bearbeitet werden. Es erbt das Verhalten der anderen Analyseregeln in der Zusammenarbeit — sofern diese Analyseregeln homogen sind.
Die Analyseregel für die ID-Zuordnungstabelle erzwingt die Sicherheit einer ID-Zuordnungstabelle. Sie verhindert, dass ein Mitglied der Kollaboration anhand der ID-Zuordnungstabelle die Population, die sich nicht überschneidet, zwischen den Datensätzen der beiden Mitglieder direkt auswählt oder überprüft. Die Analyseregel für die ID-Zuordnungstabelle wird verwendet, um die sensiblen Daten in der ID-Zuordnungstabelle zu schützen, wenn sie in Abfragen mit impliziten anderen Analyseregeln verwendet wird.
AWS Clean Rooms Erzwingt mit der Analyseregel für ID-Zuordnungstabellen in erweitertem SQL eine Überlappung auf beiden Seiten der ID-Zuordnungstabelle. Auf diese Weise können Sie die folgenden Aufgaben ausführen:
+ Verwenden Sie die Überlappung der ID-Zuordnungstabelle in JOIN Anweisungen.
AWS Clean Rooms erlaubt einen INNERLEFT, oder RIGHT -Join in der ID-Zuordnungstabelle, sofern dabei die Überlappung berücksichtigt wird. Um vertrauliche Zuordnungsinformationen zu schützen, muss sich die ID-Zuordnungstabelle bei jeder JOIN Operation immer auf der Seite inner "" befinden. Beispielsweise sind die folgenden JOIN Operationen gültig:
+ table LEFT JOIN id\$1mapping\$1table
+ id\$1mapping\$1table RIGHT JOIN table
+ table INNER JOIN id\$1mapping\$1table
Die folgenden JOIN Operationen sind ungültig:
+ id\$1mapping\$1table LEFT JOIN table
+ table RIGHT JOIN id\$1mapping\$1table
Dadurch wird verhindert, dass Kartendatensätze offengelegt werden, für die Ihr Datensatz keine entsprechenden Treffer enthält. Wenn Sie solche Operationen zulassen, könnten möglicherweise vertrauliche Informationen über die Datenzuordnungen anderer Kollaborationsmitglieder preisgegeben werden.
+ Verwenden Sie die Spalten der Zuordnungstabelle in Anweisungen. JOIN
Sie können die Spalten der Zuordnungstabelle nicht in den folgenden Anweisungen verwenden:SELECT,, WHEREHAVING, oder ORDER BY (es sei dennGROUP BY, die Schutzmaßnahmen für die Quell-ID-Namespace-Zuordnung oder die Ziel-ID-Namespace-Zuordnung wurden geändert).
+ Unterstützt in erweitertem SQL AWS Clean Rooms auch implizit OUTER JOIN und CROSSJOIN. JOIN Diese Verknüpfungen können die Anforderungen an Überschneidungen nicht erfüllen. Wird stattdessen AWS Clean Rooms verwendet, `requireOverlap` um anzugeben, für welche Spalten eine Verbindung hergestellt werden muss.
Die unterstützte Abfragestruktur und Syntax sind in definiert. [Struktur und Syntax der Abfrage in der ID-Zuordnungstabelle](#id-mapping-table-query-controls)
Zu den Parametern der Analyseregel, die unter definiert sind[Steuerelemente für die Abfrage von ID-Zuordnungstabellen für Analysen](#parameters-id-mapping-query-controls), gehören Abfragesteuerelemente und Steuerelemente für Abfrageergebnisse. Zu den Abfragesteuerelementen gehört die Möglichkeit, eine Überlappung der ID-Zuordnungstabelle in JOIN Anweisungen vorzuschreiben (d. h.`requireOverlap`).
**Topics**
+ [Struktur und Syntax der Abfrage in der ID-Zuordnungstabelle](#id-mapping-table-query-controls)
+ [Steuerelemente für die Abfrage von ID-Zuordnungstabellen für Analysen](#parameters-id-mapping-query-controls)
+ [Vordefinierte Struktur der Regel für die Analyse der ID-Zuordnungstabelle](#id-mapping-table-predefined-structure)
+ [Analyseregel für ID-Zuordnungstabellen — Beispiel](#id-mapping-table-example)
## Struktur und Syntax der Abfrage in der ID-Zuordnungstabelle
Abfragen für Tabellen, für die eine Analyseregel für ID-Zuordnungstabellen gilt, müssen der folgenden Syntax entsprechen.
```
--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
```
### Tabellen für die Zusammenarbeit
Die folgenden Tabellen stellen konfigurierte Tabellen dar, die in einer AWS Clean Rooms Kollaboration existieren. Die **ID-Spalte** in den Tabellen **cr\$1drivers\$1license und cr\$1insurance** **stellt eine Spalte dar, die mit der ID-Zuordnungstabelle** übereinstimmt.
**cr\$1drivers\$1license**
| | | |
| --- |--- |--- |
| id | Treibername | Staat der Registrierung |
| 1 | Eduard | TX |
| 2 | Dana | MA |
| 3 | Gweneth | IL |
**Autoversicherung**
| | | |
| --- |--- |--- |
| id | E-Mail des Versicherungsnehmers | Policy\$1number |
| 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 |
### ID-Zuordnungstabelle
**Die folgende Tabelle stellt eine bestehende ID-Zuordnungstabelle dar, die mit den Tabellen **cr\$1drivers\$1license und cr\$1insurance** übereinstimmt.** Nicht alle Einträge sind für beide Kollaborationstabellen gültig. IDs
| | |
| --- |--- |
| cr\$1drivers\$1license\$1id | cr\$1insurance\$1id |
| 1 | a |
| 2 | Null |
| 3 | b |
| Null | c |
Die Analyseregel für die ID-Zuordnungstabelle lässt nur zu, dass Abfragen für den Satz sich überschneidender Daten ausgeführt werden, was wie folgt aussehen würde:
| | | | | | |
| --- |--- |--- |--- |--- |--- |
| cr\$1drivers\$1license\$1id | cr\$1insurance\$1id | Treibername | Staat der Registrierung | E-Mail des Versicherungsnehmers | Policy\$1number |
| 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 |
### Beispielabfragen
Die folgenden Beispiele zeigen gültige Speicherorte für die Verknüpfungen der ID-Zuordnungstabellen:
```
-- 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
;
```
### Überlegungen
Beachten Sie bei der Struktur und Syntax der Abfrage von ID-Zuordnungstabellen Folgendes:
+ Sie können es nicht bearbeiten.
+ Es wird standardmäßig auf die ID-Zuordnungstabelle angewendet.
+ Es verwendet eine Quell- und Ziel-ID-Namespace-Zuordnung innerhalb der Kollaboration.
+ Die ID-Zuordnungstabelle ist standardmäßig so konfiguriert, dass sie Standardschutz für die Spalte bietet, die aus dem ID-Namespace stammt. Sie können diese Konfiguration so ändern, dass die Spalte, die aus dem ID-Namespace stammt (entweder `sourceID` oder`targetID`), an beliebiger Stelle in der Abfrage zulässig ist. Weitere Informationen finden Sie unter [ID-Namespaces in AWS Clean Rooms](working-with-id-namespaces.md).
+ Die Analyseregel für die ID-Zuordnungstabelle erbt die SQL-Einschränkungen der anderen Analyseregeln in der Kollaboration.
## Steuerelemente für die Abfrage von ID-Zuordnungstabellen für Analysen
Steuert mit Abfragesteuerelementen für ID-Zuordnungstabellen, AWS Clean Rooms wie die Spalten in Ihrer Tabelle zur Abfrage der Tabelle verwendet werden. Sie steuert beispielsweise, welche Spalten für die Verknüpfung verwendet werden und welche Spalten sich überlappen müssen. Die Analyseregel für ID-Zuordnungstabellen umfasst auch Funktionen, mit denen Sie die Projektion von `sourceID``targetID`, dem oder beiden zulassen können, ohne dass ein JOIN erforderlich ist.
In der folgenden Tabelle werden die einzelnen Steuerelemente erläutert.
| Steuerung | Definition | Usage |
| --- | --- | --- |
| joinColumns | Die Spalten, die das Mitglied, das Abfragen durchführen kann, in der INNER JOIN-Anweisung verwenden kann. | Sie können sie joinColumns in keinem anderen Teil der Abfrage als INNER JOIN verwenden.Weitere Informationen finden Sie unter [Steuerelemente verbinden](analysis-rules-aggregation.md#join-controls). |
| dimensionColumns | Die Spalten (falls vorhanden), die das Mitglied, das Abfragen durchführen kann, in SELECT- und GROUP BY-Anweisungen verwenden kann. | A `dimensionColumn` kann in SELECT und verwendet werden GROUPBY. A `dimensionColumn` kann erscheinen als`joinKeys`. Sie können es `dimensionColumns` in der JOIN-Klausel nur verwenden, wenn Sie es in Klammern angeben. |
| queryContraints:RequireOverlap | Die Spalten in der ID-Zuordnungstabelle, die verknüpft werden müssen, damit die Abfrage ausgeführt werden kann. | Diese Spalten müssen verwendet werden, um die ID-Zuordnungstabelle und eine Kollaborationstabelle miteinander zu verknüpfen. |
## Vordefinierte Struktur der Regel für die Analyse der ID-Zuordnungstabelle
Die vordefinierte Struktur für eine Analyseregel für ID-Zuordnungstabellen enthält Standardschutzmaßnahmen, die auf das und angewendet werden. `sourceID` `targetID` Das bedeutet, dass die Spalte mit den angewendeten Schutzmaßnahmen in Abfragen verwendet werden muss.
Sie können die Analyseregel für die ID-Zuordnungstabelle auf folgende Weise konfigurieren:
+ Beides `sourceID` und `targetID` geschützt
In dieser Konfiguration `targetID` können `sourceID` sowohl das als auch das andere projiziert werden. Das `sourceID` und `targetID` muss in einem JOIN verwendet werden, wenn auf die ID-Zuordnungstabelle verwiesen wird.
+ Nur `targetID` geschützt
In dieser Konfiguration `targetID` kann das nicht projiziert werden. Das `targetID` muss in einem JOIN verwendet werden, wenn auf die ID-Zuordnungstabelle verwiesen wird. Das `sourceID` kann in einer Abfrage verwendet werden.
+ Nur `sourceID` geschützt
In dieser Konfiguration `sourceID` kann das nicht projiziert werden. Das `sourceID` muss in einem JOIN verwendet werden, wenn auf die ID-Zuordnungstabelle verwiesen wird. Das `targetID` kann in einer Abfrage verwendet werden.
+ Weder `sourceID` noch `targetID` geschützt
In dieser Konfiguration unterliegt die ID-Zuordnungstabelle keiner bestimmten Erzwingung, die in Abfragen verwendet werden kann.
Das folgende Beispiel zeigt eine vordefinierte Struktur für eine Analyseregel für ID-Zuordnungstabellen, bei der die Standardschutzmaßnahmen auf und angewendet werden. `sourceID` `targetID` In diesem Beispiel erlaubt die Analyseregel für die ID-Zuordnungstabelle nur einen INNER JOIN sowohl für die Spalte als auch für die `sourceID` Spalte. `targetID`
```
{
"joinColumns": [
"source_id",
"target_id"
],
"queryConstraints": [
{
"requireOverlap": {
"columns": [
"source_id",
"target_id"
]
}
}
],
"dimensionColumns": [] // columns that can be used in SELECT and JOIN
}
```
Das folgende Beispiel zeigt eine vordefinierte Struktur für eine Analyseregel für eine ID-Zuordnungstabelle, auf die Schutzmaßnahmen angewendet wurden. `targetID` In diesem Beispiel erlaubt die Analyseregel für ID-Zuordnungstabellen nur einen INNER JOIN für die Spalte. `sourceID`
```
{
"joinColumns": [
"source_id",
"target_id"
],
"queryConstraints": [
{
"requireOverlap": {
"columns": [
"target_id"
]
}
}
],
"dimensionColumns": [
"source_id"
]
}
```
Das folgende Beispiel zeigt eine vordefinierte Struktur für eine Analyseregel für ID-Zuordnungstabellen mit Schutzmaßnahmen für. `sourceID` In diesem Beispiel erlaubt die Analyseregel für ID-Zuordnungstabellen nur einen INNER JOIN für die Spalte. `targetID`
```
{
"joinColumns": [
"source_id",
"target_id"
],
"queryConstraints": [
{
"requireOverlap": {
"columns": [
"source_id"
]
}
}
],
"dimensionColumns": [
"target_id"
]
}
```
Das folgende Beispiel zeigt eine vordefinierte Struktur für eine Analyseregel für ID-Zuordnungstabellen ohne Schutzmaßnahmen für das Oder. `sourceID` `targetID` In diesem Beispiel ermöglicht die Analyseregel für die ID-Zuordnungstabelle einen INNER JOIN sowohl für die Spalte als auch für die `sourceID` Spalte. `targetID`
```
{
"joinColumns": [
"source_id",
"target_id"
],
"queryConstraints": [
{
"requireOverlap": {
"columns": []
}
}
],
"dimensionColumns": [
"source_id",
"target_id"
]
}
```
## Analyseregel für ID-Zuordnungstabellen — Beispiel
Anstatt eine lange Wasserfall-Anweisung zu verfassen, die beispielsweise auf personenbezogene Daten (PII) verweist, können Unternehmen die Analyseregel für die ID-Zuordnungstabelle verwenden, um die Transcodierung mehrerer Parteien LiveRamp zu verwenden. Das folgende Beispiel zeigt, wie Sie gemeinsam die Analyseregel für ID-Zuordnungstabellen AWS Clean Rooms verwenden können.
Unternehmen A ist ein Werbetreibender, der über Kunden- und Verkaufsdaten verfügt, die als Quelle verwendet werden. Unternehmen A führt auch die Transcodierung im Namen der an der Zusammenarbeit beteiligten Parteien durch und bringt die LiveRamp Anmeldeinformationen mit.
Firma B ist ein Herausgeber, der über Veranstaltungsdaten verfügt, die als Ziel verwendet werden.
**Anmerkung**
Entweder Unternehmen A oder Unternehmen B können Anmeldeinformationen für die LiveRamp Transcodierung bereitstellen und die Transcodierung durchführen.
Um eine Zusammenarbeit aufzubauen, die die Analyse der ID-Zuordnungstabellen in Zusammenarbeit ermöglicht, gehen die Unternehmen wie folgt vor:
1. Unternehmen A erstellt eine Kollaboration und erstellt eine Mitgliedschaft. Es fügt Unternehmen B hinzu, das auch eine Mitgliedschaft in der Kollaboration einrichtet.
1. Firma A ordnet entweder eine vorhandene ID-Namespace-Quelle zu oder erstellt AWS Entity Resolution mithilfe der AWS Clean Rooms Konsole eine neue.
Firma A erstellt eine konfigurierte Tabelle mit ihren Verkaufsdaten und einer Spalte mit dem Schlüssel `sourceId` in der ID-Zuordnungstabelle.
Die ID-Namespace-Quelle stellt Daten für die Transcodierung bereit.
1. Firma B ordnet entweder ein vorhandenes ID-Namespace-Ziel zu oder erstellt AWS Entity Resolution mithilfe der Konsole ein neues. AWS Clean Rooms
Firma B erstellt eine konfigurierte Tabelle mit ihren Ereignisdaten und einer Spalte mit dem Schlüssel `targetId` in der ID-Zuordnungstabelle.
Das ID-Namespace-Ziel stellt keine Daten für die Transcodierung bereit, sondern nur Metadaten rund um die Konfiguration. LiveRamp
1. Unternehmen A erkennt die beiden ID-Namespaces, die der Kollaboration zugeordnet sind, und erstellt eine ID-Zuordnungstabelle und füllt sie auf.
1. Unternehmen A führt eine Abfrage über die beiden Datensätze durch, indem es die ID-Zuordnungstabelle verknüpft.
```
--- 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
```