構造化メタデータの小さな喜び

数日前、私はUltima Businesswareと別の会計システムの統合プロジェクトを支援しました。 とりわけ、「頭の外」だけでなく、何らかの客観的な方法でシステム内で同期すべきもののリストを取得したかったのです。

何が起こった-カットの下で。



まず、構造化メタデータについて少し説明します。

読者がUltima Businesswareのデータモデルのアイデアを持っていることを願っています(そうでなければ、なぜそれをすべて読むのでしょうか?) そうでない場合は、プラットフォームWebサイトのドキュメントからの以前の投稿と抜粋を参照してください。



メタデータは、データ構造に関する情報で構成されるデータです。 自分自身を含む。

構造化されたメタデータとは、正規化された(少なくとも2番目の形式に対して)テーブルまたはビューを意味します。



そのため、フィールドを持つディレクトリがあり、そのいくつかは他のディレクトリを参照できます。

測定値がディレクトリを参照する合計があります。

見出しと表部分で構成されるドキュメントがあり、それらはフィールドで構成され、その一部はディレクトリへのリンクになります。

さらに、ディレクトリのプロパティの値は、いくつかの言語の値を持つことができ、ディレクトリ、ドキュメント、および他のすべてのオブジェクトの名前自体は、いくつかの言語の値を持つことができます(ロシア語と英語の基本的な配信で)。

さらに、すべての構成コンポーネントはバージョン管理されています。 その結果、データベース内のディレクトリとその関係の説明についてのみ、次の構造が使用されます。





幸いなことに、アプリケーション開発者の神経を引き受け、実装の詳細をビューで隠しました。

プレゼンテーションレベルでは、回路はよりシンプルに見えます





さて、同様の構造がドキュメントに用意されています:





そして要約:



読者は、表レベルで省略された詳細を許してくれると思います。



なぜこれだけなのですか?



確かに、すべてがレイアウトされているという事実はどうでしょう。 さて、審美的な喜びに加えて、これは実際の実践で生じる多くの問題の解決を大幅に簡素化します。



統合のパズルに戻りましょう。 同じシステムと同期するために必要なものを決定する、ある程度客観的な方法が必要です。 外部条件に応じて、貸借対照表に含まれる合計を同期する必要があります。 これらは、IS_DOUBLE_ENTRYとしてマークされている合計です(ダブルエントリがサポートされているかどうかは不明です)。 したがって、これらの合計の測定値によって参照されるディレクトリを同期する必要があります。 正確に言うと、同期するもののリストを作成する必要がありました。次に、それを議論して短縮する必要がありました。



したがって、簡単かつ自然に、このクエリをスケッチしました(参考書はロシア語の名前を持つ合計の測定値と、測定値として実際に参加する合計の名前のリストです:

select a.*, MT.CAPTION as "Dictl18nName" from ( select d.id "DictID", d.name "DictSysName", listagg(mt.caption, ',') within group (order by t.name) as "DimensionOf" from KERNEL.VTOTAL_DIMENSIONS td join KERNEL.VTOTALS t on t.id=TD.TOTAL_OBJ_ID join KERNEL.VDICTIONARIES d on d.id=TD.REF_DICT_OBJ_ID join KERNEL.VMETADATA_TRANSLATIONS mt on MT.LANG_ID=2 and MT.REF_OBJ_ID=t.id where T.IS_DOUBLE_ENTRY = 1 and t.id not in (select MO.REF_OBJ_ID from KERNEL.VMETADATA_TAGS_TO_OBJECTS mo where MO.TAG_VALUE='warranty') group by d.id, d.name ) a join KERNEL.VMETADATA_TRANSLATIONS mt on MT.LANG_ID=2 and MT.REF_OBJ_ID=a.id
      
      







上の図に不要な詳細をロードしなかったため、METADATA_TRANSLATIONSテーブルにはプロパティ名とオブジェクト自体の翻訳が含まれていることを説明します。 さて、さらに、保証を含むオブジェクトを破棄しました(これは事前に知っていました)。



これらはとても小さな喜びです。

クエリを使用して他に何をしましたか? コード内の行をカウントしました。

特定のフィールドがあるすべてのディレクトリを見つけました。

どのドキュメントからも参照されていないディレクトリが見つかりました。

または、ここに頻繁に発生する状況があります-「なぜこのテーブルですか?」



はい、簡単です。構成に記載されていない場合は必要ありません。 必要に応じて-構成の説明とその理由をコメントに記入してください。 とにかく、開発者がいくつかのトリックのために生み出したすべてのタブレットを見つけましょう。

 select * from all_tables where owner='ULTIMA' and table_name not in ( select TABLE_NAME from KERNEL.VDICTIONARIES union all select TABLE_NAME from KERNEL.VDOC_TYPES union all select TABLE_NAME from KERNEL.VTABLE_PART_TYPES union all select TABLE_NAME from KERNEL.VLINK_TABLES ) order by table_name
      
      







構成内のゴミと戦うもう1つの例は、新しい年以降使用されていないディレクトリ上のコマンドを見つけて無慈悲に削除することです。

 select dc.id, dc.caption from KERNEL.VDICT_COMMANDS dc where DC.SCRIPT_OBJ_ID not in ( select script_obj_id from kernel.stat_command_events e where E.START_DT >= trunc(sysdate, 'YYYY') )
      
      







信じられないほど便利なもの、人生を大幅に簡素化します。



構造化されたメタデータと分析ツールとしてのSQL言語を使用すると、非常に興味深いことができることは明らかです。 あなた自身でそれを理解してみてください、あなたは手元にそのようなツールで何をしますか!



All Articles