Docs Menu
Docs Home
/ /

スキーマ マッピング

スキーマ マッピングは、ソース リレーショナル スキーマをターゲットの MongoDB database で表現する方法を決定するプロセスです。 カスタマイズされたマッピング ルールを使用して、Relational Migrator のスキーマ マッピング プロセスを円滑化します。

スキーマ マッピング設計プロセス中に、Relational Migrator は関係データベースのスキーマからソース データモデルを自動的に生成します。 宛先データモデルは、以下のカスタマイズによって影響を受ける可能性があります。

  • マッピングルールのオプション

  • プロジェクト ID フィールド オプション

スキーマ マッピングの概念

Tip

Relational Migrator はOracle のマテリアライズドビューをサポートします。データモデルで多数のテーブルを含む複雑なマッピングが必要な場合は、代わりにカスタムSQLクエリを使用してマテリアライズドビューを作成できます。マテリアライズドビューは単一のソーステーブルとして機能し、必要なマッピングを簡素化します。Oracleソースデータベースで複雑な結合を実行すると移行プロジェクトが効率化され、同じ変換をライブで実行する移行ジョブと比較してパフォーマンスが向上する可能性があります。詳細については、 Oracle SQL言語リファレンスを参照してください。

Relational Migrator は現時点では、他のデータベースのマテリアライズドビューをサポートしていません。

このセクションでは、スキーママッピング プロセスのシナリオと実装例を示します。 この例では、リレーショナル データモデルを MongoDB データモデルに変換します。

MongoEnterprisesリレーショナル データベースを使用することで、データベースのすべてのテーブルがフラット化され、すべての注文とカスタマー データが単一の MongoDB コレクションで利用できるようになります。

次の画像は、Relational Migrator を使用して非正規化するリレーショナル データモデルを示しています。

関係データモデル

Relational Migrator を使用する場合、目的は次の MongoDB データモデルを実現することです。 Orderコレクションには、 CustomerOrderProduct 、およびOrder Lineテーブルのすべての子要素が含まれています。 コレクションには、移行されたテーブル用にネストされたオブジェクトがあります。 結果は次のようになります。

{
"_id": {
"OrderID": 1
},
"CustomerID": 1,
"OrderStatusID": 1,
"TotalAmount": 550,
"Customer": {
"CustomerID": 1,
"Name": "Joelynn Fawthrop",
"Address1": "86 Dwight Pass",
"Address2": "Carregal",
"Address3": "3800-854"
},
"OrderLines": [
{
"OrderLineID": 1,
"OrderID": 1,
"ProductID": 1,
"Quantity": 1,
"Product": {
"ProductID": 1,
"Name": "MongoDB 5.0 Action Figure",
"Price": 50
}
},
{
"OrderLineID": 4,
"OrderID": 1,
"ProductID": 3,
"Quantity": 1,
"Product": {
"ProductID": 3,
"Name": "Gold Plated MongoDB Compass",
"Price": 500
}
}
],
"OrderStatus": {
"OrderStatusID": 1,
"Name": "Order Placed"
}
}

Relational Migrator でターゲット データモデルの結果を実現するには、次のマッピング ルール オプションを使用してOrderテーブルを構成します。

関係テーブル
マッピングルールタイプ
ルート パス

注文

新しいドキュメント

該当なし

OrderLine

OrderLines

CUSTOMER

Customer

OrderStatus

OrderStatus

product

OrderLInes.Product

戻る

リレーショナルモデルの管理

項目一覧