翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# AWS Marketplace データフィードのストレージと構造
<a name="data-feed-details"></a>

AWS Marketplace は、構造化された最新の製品および顧客情報を AWS Marketplace システムから販売者の Amazon S3 バケットに送信し、販売者が所有するビジネスインテリジェンスツール間の ETL (抽出、変換、ロード) を行うためのメカニズムとしてデータフィードを提供します。このトピックでは、データフィードの構造とストレージについて詳述します。

データフィードは、カンマ区切り値 (CSV) ファイルを収集し、これを指定先の暗号化された Amazon S3 バケットに配信します。CSV ファイルの特性は次のとおりです。
+ [4180 標準](https://tools.ietf.org/html/rfc4180)に準拠しています。
+ 文字エンコーディングは UTF-8 (BOM なし) です。
+ カンマは、値間の区切り文字として使用されます。
+ フィールドは二重引用符でエスケープ 
+ `\n` は改行文字です。
+ 日付は UTC タイムゾーンで報告され、日時形式は ISO 8601 に従い、精度は 1 秒以内です。
+ すべての `*_period_start_date` 値および `*_period_end_date` 値は包括的です。つまり、`23:59:59` は任意の日の最後のタイムスタンプです。
+ すべての金銭情報フィールドの先頭に通貨フィールドが付きます。
+ 金銭情報フィールドでは、小数点の区切り文字としてピリオド (`.`) を使用し、3 桁の区切り文字としてカンマ (,) を使用しません。

データフィードは次のように生成されて保存されます。
+ データフィードは 1 日以内に生成され、前日の 24 時間のデータが含まれます。
+ Amazon S3 バケットの場合、データフィードは次の形式を使用して月別に整理されます。

  `bucket-name/data-feed-name_version/year=YYYY/month=MM/data.csv`
+ 毎日のデータフィードが生成されると、当月の既存の CSV ファイルに追加されます。新しい月が始まると、データフィードごとに新しい CSV ファイルが生成されます。
+ データフィードの情報は、2010 年 1 月 1 日から 2020 年 4 月 30 日 (当日を含む) にバックフィルされ、`year=2010/month=01` サブフォルダの [CSV ファイル](#data-feed-details)で確認できます。

  特定のデータフィードの当月のファイルに列ヘッダーのみが含まれ、データが含まれていない場合があります。これは、当月のフィードに新しいエントリがなかったことを意味します。製品フィードなど、更新頻度が低いデータフィードで発生する場合があります。このような場合、データはバックフィルされたフォルダで利用できます。
+ Amazon S3 では、[Amazon S3 ライフサイクルポリシー](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-lifecycle.html)を作成して、バケットにファイルを保持する期間を管理できます。
+ 暗号化された Amazon S3 バケットにデータが配信されたときに通知するように Amazon SNS を設定できます。通知を設定する方法の詳細については、「*Amazon Simple Notification Service デベロッパーガイド*」の「[Amazon SNS の開始方法](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html)」を参照してください。

## データの履歴化
<a name="data-feed-historization"></a>

各データフィードには、データの履歴を示す列があります。`valid_to` を除き、これらの列はすべてのデータフィードに共通です。これらは共通の履歴スキーマとして含まれており、データのクエリに役立ちます。


| 列名  | 説明  | 
| --- | --- | 
| valid\$1from | 主キーの値が他のフィールドの値に関連して有効である最初の日付。 | 
| valid\$1to | この列は[住所](data-feed-address.md)データフィードにのみ表示され、常に空白です。 | 
| insert\$1date | レコードがデータフィードに挿入された日付。 | 
| update\$1date | レコードが最後に更新された日付。 | 
| delete\$1date | この列は常に空白です。 | 

これらの列の例を次に示します。


|  valid\$1from  |  valid\$1to  |  insert\$1date  |  update\$1date  |  delete\$1date  | 
| --- | --- | --- | --- | --- | 
|  2018-12-12T02:00:00Z  |   |  2018-12-12T02:00:00Z  |  2018-12-12T02:00:00Z  |   | 
|  2019-03-29T03:00:00Z  |   |  2019-03-29T03:00:00Z  |  2019-03-29T03:00:00Z  |   | 
|  2019-03-29T03:00:00Z  |   |  2019-03-29T03:00:00Z  |  2019-04-28T03:00:00Z  |   | 

`valid_from` と `update_date` フィールドが一緒になって双時データモデルを形成します。**`valid_from` フィールドは、その名のとおり、アイテムがいつ有効になるかがわかります。項目が編集された場合、フィードにはそれぞれ、`update_date` が異なり、`valid_from` の日付が同じレコードが複数含まれている可能性があります。例えば、ある項目の現在の値を調べるには、最新の `valid_from` の日付があるレコードのリストから最新の `update_date` のレコードを検索します。

上の例では、レコードは元々 2018 年 12 月 12 日に作成されたものです。その後、2019 年 3 月 29 日に変更されました (レコード内のアドレスが変更された場合など)。その後、2019 年 4 月 28 日に、アドレスの変更が修正されました (`valid_from` は変更されず、`update_date` は変更されました)。アドレスを修正すると (まれなイベント)、レコードが元の `valid_from` の日付から遡って変更されるため、そのフィールドは変更されませんでした。最新の `valid_from` レコードを検索するクエリでは 2 つのレコードが返され、最新の `update_date` から現在の実際のレコードが得られます。