スキーマの定義と強制
スキーマを定義することで、コレクション内のドキュメントの形状と内容を制御できます。 スキーマを使用すると、特定のフィールドを要求したり、フィールドの値のタイプを制御したり、書込み操作をコミットする前に変更を検証したりできます。
このガイドでは、リンクされた MongoDB Atlas コレクションのスキーマを定義、構成、および配置する方法を説明します。
注意
フェデレーティッド データソースは、ルールまたは スキーマ をサポートしていません。 フェデレーティッド データソースには、システム関数からのみアクセスできます。
スキーマを定義する
App Services UI または App Services CLI を使用して、コレクションのスキーマを定義できます。
App Services UI を使用する場合は、次の操作を選択できます。
コレクション内の既存のデータからスキーマを生成し、必要に応じて変更します。
フィールドレベルのスキーマ定義を追加して、スキーマを手動で定義します。
既存のデータからスキーマを生成する(任意)
コレクションにすでにデータがある場合は、App Services はコレクション内のドキュメントのサブセットをサンプリングし、サンプルに基づいてスキーマを生成できます。 すでにスキーマがある場合、またはスキーマを手動で定義したい場合は、次の手順に進みます。
サンプリングするドキュメント数を構成し、MongoDB クエリ言語を使用して、サンプルを特定のドキュメントに制限できます。 デフォルトでは、App Services はコレクション全体から最大 500 のドキュメントをランダムにサンプリングします。
既存のデータからスキーマを生成するには、次の手順に従います。
スキーマ エディターの右側のコレクション構成から、 Generate Schemaをクリックしてサンプル構成画面を開きます。
サンプル サイズを最大 50,000 ドキュメントまで指定します。
必要に応じて、 Advancedをクリックし、クエリ、プロジェクション、並べ替えを指定してサンプル クエリを絞り込みます。 クエリフィルターとソート フィルターを使用してドキュメントの特定のサブセットをサンプリングし、プロジェクション フィルターを使用して各ドキュメントからフィールドの特定のサブセットをサンプリングします。
[ Generateをクリックしてサンプル クエリを実行し、スキーマを生成します。 サンプリングされたドキュメントの数と内容によっては、このプロセスには最大 分かかる場合があります。
スキーマを定義または変更する
スキーマを手動で定義したり、フィールドレベルのスキーマ定義を追加して既存のスキーマを変更したりできます。
コレクションごとに 1 つの BSON スキーマを定義できます。 各コレクション スキーマのルートレベル タイプは、コレクション内のドキュメントを表す object
スキーマです。 ルート スキーマのproperties
フィールド内のドキュメント フィールドに追加のスキーマを定義できます。
JSON schema オブジェクトで使用できるフィールドは、スキーマが定義する値の型によって異なります。 サポートされているタイプのリストとその構成方法の詳細については、「スキーマ タイプ 」を参照してください。
例
あるグループが App Services を使用して投票アプリを実行しており、13 以降のユーザーがお気に入りの色の順位付きリストを送信できます。 投票は、 votes
という名前の MongoDB コレクションに保存され、各ドキュメントが 1 人の投票を表します。 各投票には、名前、年数、お気に入りの色の配列を含める必要があります。 各色にはrank
、 name
、 hexCode
があります。 以下は、 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})$" } } } } } }
変更検証式を追加する(任意)
各フィールドの内容を構成するだけでなく、スキーマの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" } ] } }
スキーマに対するドキュメントの検証
コレクション スキーマを保存したら、コレクション内の既存のドキュメントがスキーマに準拠していることを検証できます。
App Services は、スキーマの自動生成で行われるのと同様に、検証のためにドキュメントをサンプリングします。
コレクション内のデータを検証するには、次のようにします。
Run Validation ] ボタンをクリックして、検証構成ウィンドウを開きます。
サンプル サイズを最大 50,000 ドキュメントまで指定します。
オプションで、 Advancedをクリックし、クエリやソートを指定して、ドキュメントの特定のサブセットへの検証を絞り込みます。
コレクションのドキュメントをサンプリングし、スキーマに対して各ドキュメントを検証するには、 Run Validationをクリックします。
検証が完了すると、App Services はサンプルからの検証エラーをJSON Validation Errorsテーブルに一覧表示します。 表の各行は、特定のフィールドに対する特定のタイプの検証エラーを表し、その方法で検証に失敗したドキュメントの数を示します。
検証エラーごとに、 Actionsメニューを使用して、失敗した未加工のドキュメントをダウンロードしたり、失敗したドキュメントを検索する MongoDB クエリをコピーしたりできます。
MongoDB Cloud へのログイン
appservices を使用してアプリを構成するには、アプリを含む組織またはプロジェクトにスコープが設定された API キーを使用して MongoDB Cloud にログインする必要があります。
appservices login --api-key="<MongoDB Cloud Public API Key>" --private-api-key="<MongoDB Cloud Private API Key>"
スキーマを定義する
コレクションのスキーマを定義または変更するには、コレクションの構成ディレクトリ内の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
配列内の特定のフィールドを構成できます。 少なくとも、スキーマは次のようになります。
{ "bsonType": "object", "properties": { "<Field Name>": <Schema Document>, ... } }
変更検証の定義(任意)
スキーマの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" } ] } }
Null 型の検証
App Services のデフォルトの動作では、各フィールドに対して 1 つの型のみを受け入れます。 スキーマ フィールドはデフォルトで null 許可されていませんnull
は一意のBSON type であるためです。
任意の フィールドでnull
値を使用する場合、スキーマ検証に合格するように App Services を設定できます。 null 型検証を有効にすると、フィールドの値をスキーマ内の 型またはBSON null型として保持できます。 null 型スキーマ検証を有効にしない場合、App Services は任意フィールドに渡されるnull
値を拒否します。 null 型検証を有効にしても、必須 フィールドは null になりません。
App Services UI で null 型スキーマ検証を有効にするには、次の手順に従います。
Manageヘッダーの下の左側のナビゲーション メニューで、 App Settingsを選択します。
[ Generalタブで、 Null Type Schema Validationセクションに移動します。 スイッチをONに切り替えます。
Saveボタンをクリックします。