21.14 マイグレータ構成のみでは修正できないエラー
フィールドまたはその値を外れ値と見なさないようにマイグレータを構成した場合でも、マイグレータは他の種類の問題を検出できます。単純な例では、異なるドキュメント・セット間のデータ矛盾を検出します。
ドキュメント・セットを移行しようとすると、外れ値フィールドが存在すること以外に、他の潜在的なデータの問題が発見される場合があります。つまり、構成フィールドminFieldFrequencyおよびminTypeFrequencyにゼロ値を指定して変換する場合でも、マイグレータでエラーが発生する可能性があります。これは、移行の簡易レシピ(外れ値なし以外はデフォルトの動作)を使用して二面性ビューへの移行を開始するもう1つの理由です。
その例を次に示します。2つのドキュメント・セットは明らかに互いに矛盾しており、データを変更せずに調整することはできません。各ドキュメント・セットは、構造的にもフィールド・タイプに関しても、それぞれ一貫性がありますが、2つのセットは互いに適合しません。
(マイグレータは、データを移行しない場合でも、このようなデータの一貫性の問題を検出するのに役立ちます。)
ここで使用されるデータは、他のマイグレータのトピックで示されているデータと同じですが、コースのドキュメントでは、Natalie C.がコースMATH101を教えていると記述され、教師のドキュメントではAbdul J.が教えていると記述されているという点が異なります。他のトピックで使用されているデータでも、コースのドキュメントではAbdul J.を教師としていますが、Natalie C.はコースを教えていません。
例21-38 Natalie C.を教師とするコースMATH101のドキュメント
これは、Natalie C.をMATH101の教師とするコースの入力ドキュメントです。その他すべてのコースのドキュメントは、「学校経営の例(マイグレータの入力ドキュメント)」の例「コースのドキュメント・セット(マイグレータの入力)」と同様であり、教師および学生のドキュメントはすべて以前と同じです。
{"courseId" : "MATH101",
"name" : "Algebra",
"creditHours" : 3,
"students" : [ {"studentId" : 1, "name" : "Donald P."},
{"studentId" : 5, "name" : "Hye E."} ],
"teacher" : {"teacherId" : 104, "name" : "Natalie C."},
"Notes" : "Prerequisite for Advanced Algebra"}
...-
Natalie C.の教師のドキュメントにはcoursesTaughtが示されていませんが、MATH101のコースのドキュメントにはNatalie C.がteacherとして示されています。 -
Abdul J.の教師のドキュメントにはAbdulがMATH101とMATH102の両方を教えていることが示されていますが、MATH101のコースのドキュメントにはAbdulではなく、Natalie C.がteacherとして示されています。
インポータは以前と同様に成功します(minFieldFrequencyおよびminTypeFrequencyの値はゼロ)。ただし、DBMS_JSON_DUALITY.validate_import_reportは、これらの矛盾を検出してレポートします。
例21-39 矛盾するドキュメント・セットのVALIDATE_IMPORT_REPORT
ここでも同様に従うことが想定される簡易レシピについては、「二面性への移行、簡易レシピ」を参照してください。ステップはすべて同じです。唯一の違いは、ここで使用されるMATH101のコースのドキュメントが、前述の例「Natalie C.を教師とするコースMATH101のドキュメント」のとおりであることです。
これは、エラーをレポートする教師のドキュメント・セットのインポート検証レポートです。教師Abdul J.およびNatalie C.のドキュメントがレポートされています。
SELECT * FROM DBMS_JSON_DUALITY.validate_import_report(
table_name => 'TEACHER_TAB',
view_name => 'TEACHER');DATA
----
{"_id":101,"name":"Abdul J.","phoneNumber":["222-555-011","222-555-012"],"salary
":200000,"department":"Mathematics","coursesTaught":[{"courseId":"MATH101","name
":"Algebra","classType":"Online"},{"courseId":"MATH102","name":"Calculus","class
Type":"In-person"}],"studentsAdvised":[{"studentId":4,"name":"Georgia D.","dormI
d":203},{"studentId":7,"name":"Jatin S.","dormId":204},{"studentId":9,"name":"Lu
is F.","dormId":201},{"studentId":10,"name":"Ming L.","dormId":202}]}
{"_id":104,"name":"Natalie C.","phoneNumber":"222-555-044","salary":180000,"depa
rtment":"Computer Science","coursesTaught":[],"studentsAdvised":[]}
ERRORS
------
[{"op":"remove","path":"/coursesTaught/0"}]
[{"op":"replace","path":"/coursesTaught","value":[{"name":"Algebra","courseId":"
MATH101","classType":"Online"}]}]
この例を「二面性への移行、簡易レシピ」の例「VALIDATE_IMPORT_REPORT (外れ値なしのユースケース)」と比較します。
インポート検証レポートでは、Abdulの教師のドキュメントからMATH101を削除してNatalieのドキュメントに追加することで問題を解決することが提案されています。
-
返されたエラー・ログの1行目の列
dataにはAbdulの教師のドキュメントが含まれており、2行目の列dataにはNatalieのドキュメントが含まれています。 -
1行目(Adbulのドキュメントに対応)の列
errorsは、配列coursesTaughtの最初の要素を削除するように指示しています(配列の索引付けはゼロベースであるため、パスは/coursesTaught/0です)。それは、コースMATH101を記述しているオブジェクト:{"courseId":"MATH101","name":"Algebra","classType":"Online"}です。2行目(Natalieのドキュメントに対応)の列
errorsは、フィールドcoursesTaughtの値である空の配列を配列:[{"name":"Algebra","courseId":"MATH101","classType":"Online"}]に置き換えるように指示しています。
検証レポートでは、1つの解決策が提案されています。しかし、別の解決策として、MATH101のコースのドキュメントを教師のドキュメントに適合するように変更(教師をAbdulに変更)するという方法があります。アプリケーションで特定のデータが異常であるかどうかは、その使用状況に応じて、ユーザーのみが知っており、不適合を調整するのにどの方法がより適切であるかがわかるのはユーザーのみです。
矛盾しているように見えるデータが実際には正しい場合、おそらく教師およびコースのドキュメントで教師/コースの割当てを共有しない必要があります。その場合の解決策として、教師およびコースの二面性ビュー定義で、別個の基礎となる表を使用します。
親トピック: JSONから二面性への移行