5.3.4. イベント
SQL Server コネクターによって生成されたすべてのデータ変更イベントにはキーと値がありますが、キーと値の構造は、変更イベントの発生元となるテーブルによって異なります（ Topic name を参照）。
SQL Server コネクターは、すべての Kafka Connect スキーマ名が 有効な Avro スキーマ名 であることを確認します。つまり、論理サーバー名は、ラテン文字またはアンダースコア（例： [a-z,A-Z,_]）で開始し、論理サーバー名の残りの文字と、スキーマおよびテーブル名の残りの文字は、ラテン文字、数字、またはアンダースコア([a-z,A-Z,0-9,\_])で始まる必要があります。そうでない場合には、無効な文字はすべて自動的にアンダースコアに置き換えられます。
これにより、論理サーバー名、スキーマ名、およびテーブル名に他の文字が含まれる場合に予期しない競合が発生し、テーブルのフルネーム間の文字のみが無効となり、アンダースコアに置き換えられます。
Debezium および Kafka Connect は、イベントメッセージの継続的なストリームについて設計されており、これらのイベント の構造は徐々に変わる可能性があります。これはコンシューマーによる対応が困難になる可能性があるため、Kafka Connect による各イベントの自己完結が容易になります。各メッセージキーと値には、スキーマ と ペイロード の 2 つの部分があります。スキーマはペイロードの構造を記述し、ペイロードには実際のデータが含まれます。
5.3.4.1. イベントキーの変更
特定のテーブルでは、変更イベントのキーには、イベントの作成時にテーブルのプライマリーキー（または一意の鍵制約）にある各列のフィールドが含まれる構造があります。
inventory データベースのスキーマで定義されている customers テーブルについて考えてみましょう dbo。
CREATE TABLE customers ( id INTEGER IDENTITY(1001,1) NOT NULL PRIMARY KEY, first_name VARCHAR(255) NOT NULL, last_name VARCHAR(255) NOT NULL, email VARCHAR(255) NOT NULL UNIQUE );
database.server.name 設定プロパティーに値がある場合 server1、この定義がある間に customers テーブルのすべての変更イベントは、JSON で使用する同じキー構造に対応します。
{
"schema": {
"type": "struct",
"fields": [
{
"type": "int32",
"optional": false,
"field": "id"
}
],
"optional": false,
"name": "server1.dbo.customers.Key"
},
"payload": {
"id": 1004
}
}
キーの schema 部分には、キー部分に含まれるものを記述する Kafka Connect スキーマが含まれます。この場合、payload 値はオプションではなく、という名前のスキーマによって定義される構造で server1.dbo.customers.Key、id type という名前の必須フィールドが 1 つあることを意味し int32ます。キーのフィールドの値を確認すると、値が 1 つの payload フィールド（JSON のオブジェクトにある）の構造で id あることがわかり 1004ます。
そのため、このキーは、プライマリーキーコラムにの id 値がである dbo.customers テーブル（コネクターから出力 server1）の行の説明として解釈でき 1004ます。
