スキーマ マッピングは、ソース リレーショナル スキーマをターゲットの 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コレクションには、 Customer 、 Order 、 Product 、および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 |
| |
CUSTOMER |
| |
OrderStatus |
| |
product |
|