Docs Menu
Docs Home
/ /
Atlas App Services
/ /

スキーマの定義と強制

項目一覧

  • スキーマを定義する
  • Null 型の検証

スキーマを定義することで、コレクション内のドキュメントの形状と内容を制御できます。 スキーマを使用すると、特定のフィールドを要求したり、フィールドの値のタイプを制御したり、書込み操作をコミットする前に変更を検証したりできます。

このガイドでは、リンクされた MongoDB Atlas コレクションのスキーマを定義、構成、および配置する方法を説明します。

注意

フェデレーティッド データソースは、ルールまたは スキーマ をサポートしていません。 フェデレーティッド データソースには、システム関数からのみアクセスできます。

App Services UI または App Services CLI を使用して、コレクションのスキーマを定義できます。

App Services UI を使用する場合は、次の操作を選択できます。

  • コレクション内の既存のデータからスキーマを生成し、必要に応じて変更します。

  • フィールドレベルのスキーマ定義を追加して、スキーマを手動で定義します。

1

左側のナビゲーション メニューで、 の下の をクリックして、スキーマSchema Data Accessエディターを開きます。[Collections(コレクションCollections ] タブに [Collections(コレクション)] タブに表示されます。 Atlas App Services はリンクされたクラスターで既存のコレクションをスキャンし、スキーマ エディターの左側に一覧表示します。

メニューからコレクションを検索して選択すると、スキーマ エディターの右側にコレクション構成が表示されます。

App Services UI の「スキーマ」画面
クリックして拡大します
2

コレクションにすでにデータがある場合は、App Services はコレクション内のドキュメントのサブセットをサンプリングし、サンプルに基づいてスキーマを生成できます。 すでにスキーマがある場合、またはスキーマを手動で定義したい場合は、次の手順に進みます。

サンプリングするドキュメント数を構成し、MongoDB クエリ言語を使用して、サンプルを特定のドキュメントに制限できます。 デフォルトでは、App Services はコレクション全体から最大 500 のドキュメントをランダムにサンプリングします。

既存のデータからスキーマを生成するには、次の手順に従います。

  1. スキーマ エディターの右側のコレクション構成から、 Generate Schemaをクリックしてサンプル構成画面を開きます。

  2. サンプル サイズを最大 50,000 ドキュメントまで指定します。

  3. 必要に応じて、 Advancedをクリックし、クエリ、プロジェクション、並べ替えを指定してサンプル クエリを絞り込みます。 クエリフィルターとソート フィルターを使用してドキュメントの特定のサブセットをサンプリングし、プロジェクション フィルターを使用して各ドキュメントからフィールドの特定のサブセットをサンプリングします。

  4. [ Generateをクリックしてサンプル クエリを実行し、スキーマを生成します。 サンプリングされたドキュメントの数と内容によっては、このプロセスには最大 分かかる場合があります。

Atlas App Services UI の 生成サンプル サイズ の入力
クリックして拡大します
3

スキーマを手動で定義したり、フィールドレベルのスキーマ定義を追加して既存のスキーマを変更したりできます。

コレクションごとに 1 つの BSON スキーマを定義できます。 各コレクション スキーマのルートレベル タイプは、コレクション内のドキュメントを表す objectスキーマです。 ルート スキーマのpropertiesフィールド内のドキュメント フィールドに追加のスキーマを定義できます。

JSON schema オブジェクトで使用できるフィールドは、スキーマが定義する値の型によって異なります。 サポートされているタイプのリストとその構成方法の詳細については、「スキーマ タイプ 」を参照してください。

あるグループが App Services を使用して投票アプリを実行しており、13 以降のユーザーがお気に入りの色の順位付きリストを送信できます。 投票は、 votesという名前の MongoDB コレクションに保存され、各ドキュメントが 1 人の投票を表します。 各投票には、名前、年数、お気に入りの色の配列を含める必要があります。 各色にはranknamehexCodeがあります。 以下は、 votesコレクション内の一般的なドキュメントです。

{
"name": "Jane Doe",
"age": 42,
"favoriteColors": [
{ "rank": 1, "name": "RebeccaPurple", "hexCode": "#663399" },
{ "rank": 2, "name": "DodgerBlue", "hexCode": "#1E90FF" },
{ "rank": 3, "name": "SeaGreen", "hexCode": "#2E8B57" },
]
}

グループは次のスキーマを使用して、 votesコレクション内の各ドキュメントに対してリストされた制約が満たされていることを保証できます。

{
"bsonType": "object",
"required": ["name", "age", "favoriteColors"],
"properties": {
"name": {
"bsonType": "string"
},
"age": {
"bsonType": "int",
"minimum": 13,
"exclusiveMinimum": false
},
"favoriteColors": {
"bsonType": "array",
"uniqueItems": true,
"items": {
"bsonType": "object",
"properties": {
"rank": { "bsonType": "int" },
"name": { "bsonType": "string" },
"hexCode": {
"bsonType": "string",
"pattern": "^#([A-Fa-f0-9]{6}|[A-Fa-f0-9]{3})$"
}
}
}
}
}
}
4

各フィールドの内容を構成するだけでなく、スキーマのvalidateフィールドに検証を定義することで、ドキュメントへの変更を検証できます。 検証式は、 %%prevおよび%%prevRootの展開を使用して、挿入またはアップデート操作が発生する前にフィールドまたはドキュメントの値にアクセスできます。

ドキュメントのowner_idフィールドが各ドキュメントの所有者を表すコレクションを検討します。 このコレクションのビジネス ルールでは、ドキュメントに所有者がいないと、 owner_idの値は変更されないことが指定されています。 次の検証式を使用してこの制約を強制できます。これにより、以前は存在しなかった所有者が割り当てられる場合を除き、アップデート操作によってowner_id値が変更されないことが保証されます。

"owner_id": {
"validate": {
"%or": [
{ "%%prev": { "%exists": false } },
{ "%%prev": "%%this" }
]
}
}

また、 %%prevRoot展開を使用して、次の同等の検証式を作成することもできます。

"owner_id": {
"validate": {
"%or": [
{ "%%prevRoot.owner_id": { "%exists": false } },
{ "%%prevRoot.owner_id": "%%root.owner_id" }
]
}
}
5

スキーマを設定したら、[ Save ] をクリックします。 保存後、App Services によってすぐに、今後のすべてのクエリに対するスキーマの強制が開始されます。

注意

スキーマに一致しない既存のドキュメントは自動的に更新または検証されないため、これらのドキュメントに対する将来の変更によってスキーマ検証が失敗する可能性があります。

6

コレクション スキーマを保存したら、コレクション内の既存のドキュメントがスキーマに準拠していることを検証できます。

App Services は、スキーマの自動生成で行われるのと同様に、検証のためにドキュメントをサンプリングします。

コレクション内のデータを検証するには、次のようにします。

  1. Run Validation ] ボタンをクリックして、検証構成ウィンドウを開きます。

  2. サンプル サイズを最大 50,000 ドキュメントまで指定します。

  3. オプションで、 Advancedをクリックし、クエリやソートを指定して、ドキュメントの特定のサブセットへの検証を絞り込みます。

  4. コレクションのドキュメントをサンプリングし、スキーマに対して各ドキュメントを検証するには、 Run Validationをクリックします。

検証が完了すると、App Services はサンプルからの検証エラーをJSON Validation Errorsテーブルに一覧表示します。 表の各行は、特定のフィールドに対する特定のタイプの検証エラーを表し、その方法で検証に失敗したドキュメントの数を示します。

検証エラーごとに、 Actionsメニューを使用して、失敗した未加工のドキュメントをダウンロードしたり、失敗したドキュメントを検索する MongoDB クエリをコピーしたりできます。

App Services UI でスキーマ検証エラーを表示するテーブル
クリックして拡大します
1

appservices を使用してアプリを構成するには、アプリを含む組織またはプロジェクトにスコープが設定された API キーを使用して MongoDB Cloud にログインする必要があります。

appservices login --api-key="<MongoDB Cloud Public API Key>" --private-api-key="<MongoDB Cloud Private API Key>"
2

appservicesを使用してドキュメント スキーマを定義するには、アプリケーションの構成ファイルのローカル コピーが必要です。

アプリの最新バージョンのローカルコピーを取得するには、次のコマンドを実行します。

appservices pull --remote="<Your App ID>"

Tip

App Services UI のDeploy > Import/Export App画面からアプリケーションの構成ファイルのコピーをダウンロードすることもできます。

3

コレクションのスキーマを定義または変更するには、コレクションの構成ディレクトリ内のschema.json構成ファイルを開きます。

Tip

コレクションの足場

コレクションのルールやスキーマをまだ定義していない場合は、その設定ディレクトリと schema.json を手動で作成する必要があります。

# Create the collection's configuration directory
mkdir -p data_sources/<service>/<db>/<collection>
# Create the collection's schema file
echo '{}' >> data_sources/<service>/<db>/<collection>/schema.json

すべてのドキュメントのルートレベル スキーマは タイプobjectである必要があります。 追加のスキーマを使用して、 properties配列内の特定のフィールドを構成できます。 少なくとも、スキーマは次のようになります。

/data_sources/<service>/<db>/<collection>/schema.json
{
"bsonType": "object",
"properties": {
"<Field Name>": <Schema Document>,
...
}
}
4

スキーマのvalidateフィールドに検証を定義することで、ドキュメントに対する変更を検証できます。 検証式は、 %%prevおよび%%prevRootの展開を使用して、挿入またはアップデート操作が発生する前にフィールドまたはドキュメントの値にアクセスできます。

ドキュメントのowner_idフィールドが各ドキュメントの所有者を表すコレクションを検討します。 このコレクションのビジネス ルールでは、ドキュメントに所有者がいないと、 owner_idの値は変更されないことが指定されています。 次の検証式を使用してこの制約を強制できます。これにより、以前は存在しなかった所有者が割り当てられる場合を除き、アップデート操作によってowner_id値が変更されないことが保証されます。

"owner_id": {
"validate": {
"%or": [
{ "%%prev": { "%exists": false } },
{ "%%prev": "%%this" }
]
}
}

また、 %%prevRoot展開を使用して、次の同等の検証式を作成することもできます。

"owner_id": {
"validate": {
"%or": [
{ "%%prevRoot.owner_id": { "%exists": false } },
{ "%%prevRoot.owner_id": "%%root.owner_id" }
]
}
}
5

schema.jsonを定義して保存したら、更新された構成をリモート アプリにプッシュできます。 App Services CLI はプッシュ時に新しいスキーマをすぐに配置します。

appservices push --remote="<Your App ID>"

App Services のデフォルトの動作では、各フィールドに対して 1 つの型のみを受け入れます。 スキーマ フィールドはデフォルトで null 許可されていませんnullは一意のBSON type であるためです。

任意の フィールドでnull値を使用する場合、スキーマ検証に合格するように App Services を設定できます。 null 型検証を有効にすると、フィールドの値をスキーマ内の 型またはBSON null型として保持できます。 null 型スキーマ検証を有効にしない場合、App Services は任意フィールドに渡されるnull値を拒否します。 null 型検証を有効にしても、必須 フィールドは null になりません。

App Services UI で null 型スキーマ検証を有効にするには、次の手順に従います。

  1. Manageヘッダーの下の左側のナビゲーション メニューで、 App Settingsを選択します。

  2. [ Generalタブで、 Null Type Schema Validationセクションに移動します。 スイッチをONに切り替えます。

  3. Saveボタンをクリックします。

戻る

Schemas