XMLデータ統合は別の方法です

この記事では、「従来とは異なる」が非常に強力なXML処理テクノロジーについて説明します。これにより、XMLデータをインポートし、その構造を効率的かつ簡単に変換できます。 。



中間データ交換フォーマットとしてのXMLは、特殊なエディター、DOMパーサー、XQUERY / XPATH、XSLT、特別なETLモジュールなど、それと連携するためのテクノロジーとツールのエコシステムに成長しました。ツールキットのこの多様性と開発はすべて、イデオロギー的につながりますデータだけでなく、特別なXMLデータを操作するための技術があることを確認しました。 これは、別個の「化学の科学」であり、別個に「青い箱に保管されている物質の化学の科学」です。



以下に説明する処理原理により、条件付きの技術の進歩をわずかに「巻き戻し」、特定のXMLツールを使用せずにXMLデータのほとんどすべての作業を「クリーンな」DBMSのレベルに転送できました。 このアプローチにより、XMLデータの統合ストレージを編成し、必要な情報にすばやくランダムにアクセスできるようになりました。 さらに、ETL機能を普遍的かつ低コストで（実際にはコーディングなしで）実装することが可能になりました。



説明されたアプローチは、データスキームが頻繁に変更される大容量で複雑な構造のデータソースで特に優れていることが証明されました。 少量の情報を処理する必要がある場合、および/または構造が単純な場合-この技術はおそらく（これまで）必要ありません。



このテクノロジーの適切なデモケースは、適切なFTPで利用可能な公共調達サーバーzakupki.gov.ruからのオープンデータです。毎日の更新の量は、新しいバージョンがリリースされてから数週間で平均で数ギガバイトまたは数十ギガバイトのXMLファイルですデータスキーマ。



データ構造は法律の要件に準拠しているため、たとえば、公共調達通知に関する情報は、購入の種類に応じて、十数種類を超えるドキュメントfcsNotificationによって提示されます（電子オークションfcsNotificationEF、見積り依頼fcsNotificationZK、単一サプライヤーfcsNotificationEPからの購入など）。

これらの文書はすべて、同じ基本的な種類の通知に基づいていますが、詳細が異なります。そのため、分析の目的で、このすべての種類をある時点で「折りたたみ」、「共通分母」にインポートする必要があります。



公的調達データに基づいて、説明されたアプローチは正常に適用され、効果的に機能しています。



説明された技術の簡単な段階/要素：



（1） すべてのXMLデータを統一された構造テーブルにインポートします 。 これは、ドキュメント全体をデータベースに保存することではなく、「要素名」-「値」または「属性名」-「値」のペアとして要素ごとにデータ要素をインポートします。 この段階の結果として、ストレージ形式としてXMLを取り除き、あらゆる構造のインポートされたすべてのXMLドキュメントのデータへの高速な統合アクセスを取得します（XQUERY / XPATHはもう必要ありません）。



（2）テクノロジーの 2番目の要素は、必要なデータを「引き出す」ための仕様の作成です。データを入れる結果のテーブルを識別し、ソースフィールドと結果フィールドをマッピングします。 この段階は、最初の段階でダウンロードされた文書のサンプルの分析を通じて、文書のXSDスキームに基づいて、およびスキームを使用せずに実行できます。 この段階では、プログラミングや特別なスキルは必要ありません。ここでのメインツールキットはスプレッドシートです。



（3）最終ステップ-仕様（2）を使用してプライマリインポートリポジトリから必要な情報を取得（2）、「列」ビューへの変換（「ピボット」）、および最終的な「分析」形式への自動変換 -分析データウェアハウスに関して「星」構造のファクトのテーブル。測定リファレンスブック（ディメンション）および数値メジャー（メジャー）へのリンクがあります。

1.プライマリインポート。

XMLドキュメントは、頂点が名前と値のペアであるツリーと見なされます。 したがって、説明したアプローチは非常に普遍的であり、データのツリーのような表現に適用できます。



XMLからデータをロードするためのテーブル構造：

• Record_ID ：特別な階層型の要素の識別子。ドキュメントの異なるレベルを相互にリンクできます
• File_ID ：テーブルは多くのXMLファイルのコンテンツをロードする必要があるため、ファイル識別子も保存する必要があります
• Path ：ドキュメントルートから始まる特定の要素へのフルパス（実際、これはこの要素へのXPATHパスです）
• Element_Name ：要素または属性の名前
• Element _Value ：要素または属性の値（文字列として-XMLに保存されているものと同じ）
• タイプ ：レコードタイプ（これが要素か属性か）-念のため、突然テーブルからXMLを復元する必要がある場合

ツリーをテーブルにロードするというアイデアは非常に明白です。 MS SQLには（他のDBMSについては何も言わず、見ていません）そのような組み込み機能があります。スキーマをインポートしないXMLは、いわゆるEDGEテーブルにインポートされます。 EDGE形式では、要素の名前とその値は別々のレコードに保存されているため（つまり、名前は値の親レコードです）、これは必要なものではありません。この形式は、以降の操作に使用するには不便です。 さらに、ツリーのEDGE通信テーブルには、ParentIDの指示を使用して登録されます。



要するに、EDGEテーブルからデータの希望する表示を作成することは可能ですが、要素の名前と値を「接着」し、各要素にXPATHを再作成し、階層識別子を作成するために少し汗をかかなければなりません（すぐ下に構築する方法について）。 大量のデータを使用する場合、これらの問題を解決するにはかなりのリソースが必要になりますが、単一のツール/言語で実行できます。



より正確な方法は、XMLパーサーを使用してドキュメントツリーを取得し（ほとんどすべての言語および開発環境に何らかの実装があります）、ドキュメントを1回パスすることで必要な情報を入力することです。



特定の例を見てみましょう。 デモXMLファイルdeliveryies.xmlおよびreturns.xmlがあります。 deliveryies.xml（配信）ファイルには、データがアップロードされる期間の開始日と終了日の最上位にDeliveriesルート要素が含まれています。その後、名前とサプライヤを持つ製品が示されます。各製品には、配信情報の詳細（日付、数量、価格）があります。





ファイルreturns.xml（returns）はまったく同じで、ルート要素のみがReturnsと呼ばれ、詳細には日付を持つ要素が異なって呼び出されます。





ダウンロードしたファイルの名前は別のテーブルに保存され、そこにあるファイルのコードは2006（配信）と2007（戻り）に等しくなります。



レシーバーテーブルでは、デモドキュメントの画像は次のようになります。





階層識別子Record_IDについて：その目的は、すべての祖先との関係に関する情報を保持しながら、ドキュメントツリーのノードに一意に番号を付けることです。





与えられた例では、ツリーの各レベルで要素カウンターを順次連結する、プラットフォームに依存しない単純な実装を使用します。 固定長の部分文字列を割り当てることで、任意のレベルの祖先の識別子を簡単かつ迅速に選択できるように、各レベルのカウンターを特定の固定深さまでゼロで「仕上げ」ます。



これがすべてこの段階です。 これで、これらの製品のSQLサブセット、配信用のパーツ、または単純なSQLクエリで返されるパーツを選択し、ファイルと要素の識別子を介して互いに関連付けることができます。



多くの場合、このアプローチは、効率的なデータストレージとそれらへのアクセスの編成に十分であり、以下で説明する「高度な」技術は必要ない場合があります。



実際、ドキュメントの構造の違いに注意を払わずに、すべてのデータを単一のリポジトリに既にロードしました。単純なSQLクエリを使用して配列全体から必要な情報を分離するかなり効果的な方法を取得しました。



インデックスやその他のトリックを最適化しない場合でも、ワンタイムクエリ用のXMLソースストレージシステムなどのソリューションのパフォーマンスは、XMLをファイルに保存したり、特別なデータベースフィールドに書き込んだりする場合よりもはるかに高くなります。 この場合、各ドキュメントに対してXPATH検索手順（新しい解析を意味します）を実行する必要はありません。一度実行してから、保存した結果をかなり単純なクエリで静かに使用します。





次の手順では、これらのXMLドキュメントを、 MovementReports （移動のタイプ-配信または返却、ドキュメントルートからの開始日と終了日）、 Products （名前とサプライヤ）、 MovementDetails （価格、数量、日付）の3つのテーブルを含む単一のデータ構造への変換を検討します-結果としての日付フィールドは、ソースファイルではフィールドの呼び出し方法が異なるにもかかわらず、両方のソースドキュメントで同じになります）

2.結果テーブルへの変換の仕様の作成。

ソースデータと結果テーブルをマッピングするための仕様を作成するプロセスを検討してください。 このような仕様を作成するには、何か他のものが必要です。

2.1。 ドキュメントの構造を備えたプレートを取得します。

さらに処理を行うには、すべてのXMLドキュメントの詳細な構造が必要です。そのため、それに基づいて、どのテーブル構造をすべてに変換するかを決定できます。

このタスクに特定のサンプルXMLドキュメントは必要ありません。特定のドキュメントには、他のドキュメントに予期せず表示されるオプション要素がない場合があります。



XSDスキームがない場合、または連絡したくない場合は、XMLドキュメントの代表的なサンプルをテーブルにアップロードし、 PathフィールドとElement_Nameフィールドでグループ化して必要なリストを作成すれば十分です。



ただし、最終的にターゲットの「最終」テーブルに情報をロードすることを忘れないでください。そのため、 1対多の関係がXMLのどこに格納されているかを知る必要があります。 つまり、再生が発生する「娘」テーブルを構成する要素を理解する必要があります。



文書のレイアウトがそれほど複雑でない場合は、経験的に「目」ですぐに理解できることがあります。 また、「代表サンプル」のデータをグループ化するときに、要素の数を計算し、これらの統計から「乗算」を開始する場所を確認できます。 しかし、一般的な場合、通常のXSDスキームがある場合は、それを使用する方が良いです。XSD構造体maxoccurs = unboundedを明らかにすることにより、データの乗算を「キャッチ」します。



ご覧のとおり、タスクはもう少し複雑です。ドキュメントのすべての要素のXPATHパスのリストを含む単純なラベルだけでなく、データの伝播が開始される場所の表示も取得したいです。 （そして、よく書かれたXSDスキームを分析するとき、素晴らしいボーナスは、要素とそのタイプの説明を引き出すことができることです。）



XMLエディターの機能を使用してこのようなラベルを取得することは非常に良いことですが、XSDスキーム（長い間検索され、試行されました）に従って必要な文書構造を提供するようなツールは見つかりませんでした。



これらのOxygen、Altova、Liquid、および洗練されていないものすべてで、必要な情報は間違いなく使用されていますが、正しい形式で提供することはできません。 原則として、高度なエディターでは、スキーマに基づいてサンプルXMLを生成できますが、XSDでは、ドキュメントにいくつかの異なる要素から選択するものが含まれる場合、 選択構造が存在する場合があります。その後、実際の「戦闘」サンプルドキュメントを分析することをお勧めします そしてまだ-文書のモデルまたはサンプルによると、明示的な形式で1対多の情報を複製する瞬間も捉えません。



その結果、私は自分で車輪を再発明し、そのようなプレート（実際には、特別な種類のXSDパーサー）のジェネレーターを作成する必要がありました。 XSDの利点はXMLでもあり、リポジトリにロードして、リレーショナル操作で目的のビューを引き出すこともできます。 スキームが単純で、複雑な要素タイプを参照せず、基本タイプから継承しない場合、これは非常に簡単です。 このタイプの継承がすべて利用できる場合（たとえば、公共調達の場合）、タスクはより複雑になります。

2.2。 変換の説明

ドキュメントの表形式の仕様の形式で初期データを受け取ったら、データ変換の設計に進みます。 この変換の結果として、ソースプライマリXMLストレージのデータを、ターゲットテーブルの新しいフィールド名と一意のレコードコードを持つ新しいテーブルに変換します。 特別なソフトウェアツールは必要ありません。このプレートにいくつかの新しい列を追加するだけです。





追加したフィールドは次のとおりです。

• TargetTableターゲットテーブル名 。 1対多の育種情報（maxoccurs列）を考慮して、どのテーブルにどのデータをアップロードするかを決定することに注意してください。
  
  
  
  
• TargetFieldターゲットテーブルのフィールド名。 構成アプローチよりも慣習をさらに使用し、参照ブック（ディメンション）になるフィールドには接尾辞_Dim 、日付フィールドには接尾辞_Date 、数値メジャー（メジャー）には接尾辞_Valを割り当てます。 プロセスの次の段階で、対応するユーティリティはサフィックスによってこのフィールドで何をするかを理解します-必要なディレクトリを構築および更新するか、値を適切な形式に変換します。
  
  
  
  
• ElementDepth要素の効果的なネストの深さ。 Record_IDフィールドとFile_IDフィールドの内容に基づいた後続の変換のために、ターゲットテーブルの単一のレコードコードを保存する必要があります 。 XMLでは、要素の深さは異なる場合がありますが、同じターゲットテーブルに分類する必要があるため、階層Record_IDコードのどの部分を保存する必要があるかを示し、不要な残基を破棄します。 階層コードの各セグメントの長さが固定されているため、これは長さ[コードセグメントあたりの文字数] * ElementDepthのサブストリングを選択するかなり「安い」操作になります。
  
  
  
  
• 追加情報AdditionalInfo 。 変換の結果、ターゲットテーブルによって分解されたソースデータを新しいフィールド名を持つ類似の構造にリロードしますが、一部の場所では、ソースデータを取得したXPATHパスに関する重要な情報を保存する必要があります。

この手法は、データ変換を操作するための興味深い可能性を開きます。 詳細に進むことなく、できることだけをリストします。

• 複数の初期XMLデータエンコーディングスキーム（たとえば、95の連邦法の「古い」公的調達スキームと44の連邦法の「新しい」公法）がある場合、変換を記述する段階で、フィールド名の統一を通じてそれらを単一のデータ構造にすることができます。
  
  
  
  
• 前述のように、この例のように、1つまたは複数のドキュメントスキーム内の異なるセクションを単一のよりコンパクトなストレージ構造に「折りたたむ」ことができます。
  
  
  
  
• また、さまざまな深さのデータを統一された表現に「崩壊」させることもできます。 たとえば、公的調達の通知のスキームを採用する場合、異なるスキームでは、調達ロットに関する情報は、単一ロット購入のアドレス\ロット （唯一の要素）および複数ロット購入の\ロット\ロット （複製）にあります。 このアプローチを使用すると、この動物園全体を、ロットに関する情報の単一のテーブルにマップできます。

変換仕様プレートの準備ができたら、データベースにロードし、 PathフィールドとElement_Nameフィールドを使用してプライマリリポジトリに結合します。



Record_IDフィールドの値とAdditionalInfoの値のElementDepthに従って「トリミング」されたFile_IDを連結することにより 、ターゲットテーブルの複合キーを形成します。



各ターゲットテーブルの結合の結果を個別の「一時」テーブルに注ぎます（データ量に応じて、クエリ結果を「オンザフライ」で使用できます）、次の段階で、「パイプライン」の最終ユーティリティがこれらのテーブルで機能します。





この例の出力で何が起こったのか見てみましょう：





受け取ったキーは、ターゲットテーブルの対応するレコードに含まれるすべてのフィールドで同じであることに注意してください。

3.最終処理。

3.1。 ピボット

前の変換の結果、トリプル<キー>-<フィールド名>-<値>に分割された初期データを含むターゲットテーブルの「空白」を受け取ったら、それを多くのフィールドを持つより馴染みのあるテーブルに変換する必要があります。 この変換のアルゴリズムは明らかです。まず、複合キーの値をグループ化して、テーブルの「スケルトン」を取得し、次に、この「スケルトン」と、複合キーの値による変換のテーブル結果との結合を実行します。 （いわば「肉を造る」。）



つまり、フィールド名で選択された変換結果テーブルのサブセットを持つ「スケルトン」のN個の化合物を取得します。ここで、Nはターゲット変換結果テーブルのフィールド名の数です。



この段階でAdditionalInfoフィールドを安全に「作成」し、複合キー内でエンコードしました。 ここで、この「負担」からキーを解放し、AdditionalInfoパーツを新しいフィールドAdditionalInfo_Dimにカットする必要があります。



1つのフィールドのキーをピボットステージに転送するために、ファイルコードとレコード識別子を組み合わせました。 「最終」ストレージの場合、ファイルコードと階層識別子を2つのフィールドに分割し直すことをお勧めします。結果のテーブルを相互にリンクしやすくなります。



その結果、私たちはそのようになります

3.2。 正規化

次の段階は条件付きで正規化と呼ばれます。すべてのフィールドを接尾辞_Dimに対応するディレクトリへの参照に置き換え、接尾辞_Dateおよび_Valのフィールドをそれぞれ日付と数値に変換します。 必要に応じて、データ型の他のサフィックスを使用できますが、これは定説ではありません。



_Dimフィールドごとに、対応するディレクトリの可用性を確認し（ディレクトリがない場合は作成します）、ピボットテーブルのフィールドから新しい値を追加します。



プロセスの最後に、ピボットテーブルとフィールド値に関する更新されたリファレンスブックを組み合わせて、データを最終的なストレージ構造に転送します。



その結果、ファイルコード、階層識別子、ディレクトリの値へのリンク、および必要なタイプに変換された他のフィールドを含むターゲットテーブルを取得します。

プロセスの説明を終了するには

各ターゲットテーブルの階層識別子により、これらのテーブルを互いに関連付けることができます（必要に応じて、任意の順序で中間リンクを省略できます）。 上記のように、階層識別子の要素のサイズが固定されているため、ターゲットテーブルをリンクするための式を簡単に作成できます。



もちろん、必要に応じて、通常の自動インクリメントキーの値を介したリンクでテーブル構造を補完できます。



(, , ). , , – , .



“” , .



「小さな」データ変換のためにフィールドのマッピングを規定することは可能です-必要な欠落しているフラグメントに対してのみ。不足しているデータを「引き出し」た後、一連の階層識別子を介してメインの処理済み配列に簡単に「ピックアップ」できます。

結論

, , “” ad-hoc.



- ETL task, XML-.



, “” ( ) , XML .