データセット・テーブル・スキーマ

この章と今後の章で使う演習用データセット handson_ch02 を、US ロケーションに作成します。サンドボックスで完走可・無料枠内（データセット作成自体は課金対象になりません）。

1. bq CLI でデータセットを作成します。ロケーションは必ず US を指定してください（あとから変更できません）。

bq mk \
  --dataset \
  --location=US \
  --description="第2章 データセット・テーブル・スキーマの演習用" \
  --default_table_expiration=86400 \
  --label=purpose:handson \
  PROJECT_ID:handson_ch02

PROJECT_ID は自分の Google Cloud プロジェクト ID に置き換えてください（gcloud config get-value project で確認できます）。--default_table_expiration は秒単位で、86400 秒 = 1 日です。作成したテーブルは 1 日で自動削除されるため、片付け忘れても安心です。

2. メタデータを確認します。

bq show --format=prettyjson PROJECT_ID:handson_ch02

期待される出力: "location": "US" と、指定したラベル・説明・defaultTableExpirationMs が JSON に含まれています。

後片付け: このデータセットは本章の後続ハンズオンでも使うため、ここでは削除しません。ハンズオン 2-4 の後片付けでデータセットごと削除します。

JSON スキーマファイルを使い、複数のデータ型を持つテーブルを明示的なスキーマで作成します。サンドボックスで完走可・無料枠内（テーブル作成はスキャンを伴わないため課金対象外）。

1. スキーマファイル orders_schema.json を作成します。

[
  { "name": "order_id",    "type": "STRING",    "mode": "REQUIRED" },
  { "name": "customer_id", "type": "STRING",    "mode": "NULLABLE" },
  { "name": "amount",      "type": "NUMERIC",   "mode": "NULLABLE" },
  { "name": "created_at",  "type": "TIMESTAMP", "mode": "NULLABLE" }
]

2. スキーマファイルを指定してテーブルを作成します。

bq mk --table \
  PROJECT_ID:handson_ch02.orders \
  orders_schema.json

3. INFORMATION_SCHEMA で型が意図どおりに反映されているか確認します。

-- 処理: メタデータ照会のため課金対象外
SELECT column_name, data_type, is_nullable
FROM `PROJECT_ID.handson_ch02.INFORMATION_SCHEMA.COLUMNS`
WHERE table_name = 'orders'
ORDER BY ordinal_position;

期待される出力: order_id が STRING / NO（REQUIRED）、amount が NUMERIC / YES、created_at が TIMESTAMP / YES という 4 行。

後片付け: テーブルはハンズオン 2-3 でスキーマ変更の題材として使うため、ここでは削除しません。

ハンズオン 2-2 で作った orders テーブルに対して、列追加・列名変更・型変更・列削除を実際に実行し、可否のルールを体で確認します。サンドボックスで完走可・無料枠内（すべて DDL でスキャンを伴わないため課金対象外）。

1. JSON 型の列を追加します（新規列は常に NULLABLE／REPEATED のみ可）。

ALTER TABLE `PROJECT_ID.handson_ch02.orders`
ADD COLUMN payload JSON;

ALTER TABLE `PROJECT_ID.handson_ch02.orders`
ADD COLUMN memo STRING;

2. 列名を変更します。

ALTER TABLE `PROJECT_ID.handson_ch02.orders`
RENAME COLUMN customer_id TO client_id;

3. 型を「制限の少ない方向」へ変更します（NUMERIC → BIGNUMERIC）。

ALTER TABLE `PROJECT_ID.handson_ch02.orders`
ALTER COLUMN amount SET DATA TYPE BIGNUMERIC;

4. 不要になった列を削除します（メタデータ操作のみで、ストレージは即座には解放されません）。

ALTER TABLE `PROJECT_ID.handson_ch02.orders`
DROP COLUMN memo;

5. 最終的なスキーマを確認します。

bq show --schema --format=prettyjson PROJECT_ID:handson_ch02.orders

期待される出力: order_id / client_id / amount（BIGNUMERIC）/ created_at / payload（JSON）の 5 列。memo は表示されません。

後片付け: テーブルはハンズオン 2-4 の後片付けでデータセットごと削除します。

US に作った handson_ch02 に対して、わざと別ロケーションでクエリを実行してエラーを確認し、続けて正しいロケーションで一般公開データセットへ小さくクエリします。サンドボックスで完走可・無料枠内（公開データセットへのスキャンは数 MB 程度）。

1. ロケーションを asia-northeast1 に指定して、US にあるテーブルへクエリしてみます。

bq query --use_legacy_sql=false --location=asia-northeast1 \
  'SELECT COUNT(*) FROM `PROJECT_ID.handson_ch02.orders`'

期待される出力: ジョブのロケーションとデータセットのロケーションが一致しないため、エラーで失敗します。BigQuery は「リクエストに関わるすべてのデータセットのロケーションが、ジョブのロケーションと一致しなければならない」というルールでこれを弾きます。

2. 今度は正しく US を指定し、一般公開データセットに小さくクエリします。列を絞り、dry run で処理量も確認します。

bq query --use_legacy_sql=false --location=US --dry_run \
  'SELECT word, word_count
   FROM `bigquery-public-data.samples.shakespeare`
   WHERE corpus = "hamlet"
   ORDER BY word_count DESC
   LIMIT 10'

bq query --use_legacy_sql=false --location=US \
  'SELECT word, word_count
   FROM `bigquery-public-data.samples.shakespeare`
   WHERE corpus = "hamlet"
   ORDER BY word_count DESC
   LIMIT 10'

期待される出力: dry run は数 MB 程度の処理量見積もりを返し、実行結果は "the" や "and" など頻出単語が上位に並ぶ 10 行です。bigquery-public-data は US マルチリージョンにあるため、こちらは --location=US のジョブと一致し、正常に実行できます。

後片付け: この章で作成したリソースをすべて削除します。

bq rm -r -f -d PROJECT_ID:handson_ch02