1

xml から db (Oracle 11) へのコンバーターを作成するタスクがあります。

顧客から提供された xsds が多数 (約 100) あります。各 xsd は、非常に複雑なデータを記述します。一部の xsd には共通の型がありますが、各 xsd は内部ですべての型を宣言しているため、共通の型を持つ xsd はありません。

DB モデルは提供されません。しかし、クライアントは oracle xmldb の使用に基づいてバリアントを拒否しました。

私の計画は次のとおりです。

  1. xmlspy を使用して db モデルを生成します。
  2. jaxb を使用して Java モデルを生成します。
  3. hibernate を使用して Java を db モデルにマップします。
  4. jaxb to Java モデルを使用して xml データを読み取ります。
  5. 休止状態を使用してデータを保存します。

しかし、db モジュールを生成しようとすると、xmlspy が 5000 を超えるテーブルを生成することがわかりました。それらの数を減らすことはできますが、テーブル間に生成されたリレーションを検証して修正するには、まだ作業が多すぎます。また、Java モデルを生成してデータベースにマップする作業も多くあります。

私の問題を解決する他の方法はありますか?

4

1 に答える 1

0

これは、XML データを分析してからデータベース内のリレーショナル データ モデルにマッピングしない限り、不可能な作業です。

あなたが概説したアプローチは、このプロセスを自動化することがいかに難しいかを示すかなり機械的なプロセスです... XSD の各 XSD タイプは、Java で一意のオブジェクト クラスを生成し、それがデータベース内の一意のテーブルに変換されました。休止状態...

スキーマで型の継承が使用されている場合、リレーショナル データ構造への手がかりが得られる可能性があります (共通の親型を継承する XSD 型は、同じテーブルに属している可能性があります)。おそらく、他の人は注意すべき他の一般的なパターンを提供することができます。

アップデート

基礎となる XML データを詳しく調べることをお勧めします。

受け取った未加工の XML データに基づいて、顧客のスキーマを完全に書き直した以前の Web サービス プロジェクトを覚えています。それらの複雑な XSD 型は完全に不必要であり、複雑さを増すだけであることが明らかになりました。

于 2012-11-13T19:34:40.973 に答える