メタデータ。 データモデル管理の理想に向けて

この投稿について

1. これは、経験、噂、読書の指示に基づいて、著者が知っているデータモデル管理オプションの事後レビューです。
2. この投稿は、既存のデータモデル管理オプションを分類する試みでもあります。
3. 最後に、データモデル管理システムの実装におけるアイデアと最初のタッチを示します。これには、以前の欠点の欠点は含まれません。

定義と制限

読者はエンタープライズアプリケーションの開発者である（または将来的になる）と想定されており、多くの場合、迅速かつ効率的に書く必要がありますが、「ファイルで特に細い場所を微調整する」ためにJPA / JTA / RMIのジャングルに入ることを恐れていません。



データは、アプリケーションデータベースに保存されるものです。 顧客、ユーザー、注文などに関するデータ



メタデータ-データ構造の説明。 データベースに保存されているオブジェクトのタイプの説明、オブジェクトが持っているフィールド（属性、要素）、オブジェクト間の依存関係の説明。 一般に、タイプは親タイプの属性を継承でき、一般的な場合の1つの属性は、継承関係によって関連付けられていない2つ以上のタイプに存在できます。





エンタープライズアプリケーションは、（ほとんどの場合）Application Server（WebLogic、JBOSS）および一部のRDBMS（Oracle、Informix、MySQL）を使用して機能します。 著者は、Tomcat / Hibernate / JOTM / DBCP /などに基づいたASの自己組織化に恥ずべきことは見ていませんが、非常に興味深いのですが、このトピックの範囲を超えています。



RDBMSは、Hibernate / OpenJPAでサポートされている標準の1つであると想定されています。



このトピックでは、XMLスキーマの名前空間、タイプ、属性の用語を使用しています。 後者の2つは、ある程度Javaクラス（クラスオブジェクト、ビン）とプロパティ（プロパティ、別名get + set、時にはフィールド、フィールド）の概念に対応しています。

はじめに 最も単純なケース

大規模なアプリケーション-ほとんどの場合、これらは大量のデータを持つアプリケーションだけではありません。 多くの場合、これらは、ビジネスロジックの観点とは異なる構造を持つ、多数の異種データを扱うアプリケーションです。 （ちなみに、最後は重要です-データ構造は、DBMSレベル、アプリケーションレベル、さらには内部で異なる場合があります）



最も単純なケースは、クラスのセットとデータベース内の対応するテーブルのセットの形式でのデータモデルの定義です。 大まかに言うと、1つのクラスはデータベース内のodeテーブルです。 オブジェクトの各プロパティは、Beanクラスのプロパティとデータベースの列で表されます。 ただし、このようなメカニズムには、エンタープライズアプリケーションを開発および使用するときに現れる欠点があります。

• データモデルを追加または変更するには、データベースの構造とプログラムコードの両方を変更し、その後に再コンパイルなどを行う必要があります。
• その結果、これを即座に行うことはできません。
• 子タイプから親タイプへの属性の転送などの複雑な変更も、データベース構造を更新するために手動スクリプト（DDL + DML）を書く必要があります。
• 構造を変更するには、SQL / Javaの専門知識が必要です

ただし、このアプローチの利点に注意する必要があります。

• 優れたパフォーマンスのための最高の価格。 文字通り、「すぐに使える」最も透明なデータストレージ構造を取得し、JPAレイヤー（休止状態など）とRDBMS（およびその管理者）の両方にとって最も明白です。
• データ構造を変更しないビジネスロジックプログラマーの観点から見ると、最も便利なAPIがすぐに使用できます

最後の文で重要な説明-「ビジネスロジック」に注目してください。 これは、データ構造の相互作用のプロセス、それらの変更などの記述です。つまり、データ構造について知っていなければならないコードです。 しかし、たとえば、WEBインターフェース（または他の方法）を介してBeanを編集することについて話している場合、オブジェクトの構造を事前に知らずに80％を編集できるエディター（いわゆる一般化）を作成するには、対処する必要がありますReflection / Beans / etcなど、原則として、あまり怖くない言葉。 （怖い-トピックの最後）。



最新の設計ツールを使用すると、たとえば、コードによるデータベース構造の更新、またはその逆など、データ構造の説明に従ってコードを生成または更新することに関連するプロセスの一部を自動化できます。 よくわかりませんが、たとえばXMLスキーマの形式で記述された抽象的なデータスキームに基づいて、コードとデータベース構造の両方を同時に作成するツールがあると思います。 （コードは非常に正確に生成できます-XML Beanなどを参照してください）。 ただし、これらのツールはすべてオフラインモードで動作し、実行中のアプリケーションには影響しません（もちろん、ライブから直接アップグレードした場合を除き、何も起こりません）。



ところで、いくつかの補助ユーティリティを作成して、オブジェクトのタイプごとに形状を描画できます。

柔軟なデータ構造

最も柔軟な構造が考えられます。各オブジェクトは、XMLなどの形式でデータベースにレコードとして保存されます。 つまり、2つの列がXMLのオブジェクトとそのコンテンツのIDである大規模なテーブルです。 当然のことながら、このような構造の主な欠点は、たとえばモスクワ市のすべての顧客を計算する必要があるときのデータベースのパフォーマンスが非常に低いことです。 これを行うには、データベースが各値を解析する必要があります。



構造の柔軟性を維持するために、データベースへの負荷を少なくするために、オブジェクトは断片に分割され、別々のテーブルに取り出されます。 例えば

-オブジェクト：ID、必須フィールド1、必須フィールド2

-値：オブジェクトID、属性識別子、値



さらに柔軟性を制限することなく、さまざまなタイプの属性をさまざまなテーブルまたは列に分離できます。 同様のスキームがアプリケーションで正常に使用され（カットアウト）、数テラバイトのデータを処理します。



その他の欠点：

柔軟性に費用がかかります。 まず、データレイヤーを個別に書き込む必要があります。 次に、お金を節約し、データベース構造を反映するビジネスロジック用のAPIを残したいという大きな要望があります。

-IDオブジェクトなどを与える

-などの属性IDを与える

-値を更新

-などのオブジェクトの属性IDを書き留めます

-オブジェクトのバージョンを更新（+1）



もちろん、一般化されたデータエディターの観点からは、getAllAttributes（）のようなメソッドを持つことは非常に便利です。 ただし、ビジネスロジックの観点からは、特に必要な属性のIDをすべて覚えておく必要がある場合は不便です（数値でもかまいません）。



ただし、APIは一般にデータベースの構造と一致する必要はないことに注意してください。 主なことは、アクションの80％が最も単純で最も明白な方法で実行されることです。 つまり、データベースにクライアントがある場合、クライアントの名前またはアドレスを取得するには、client.getAddress（）のようなコードが1行必要です。 ただし、柔軟な構造の場合、そのようなシェルを作成するとパフォーマンスが大幅に低下する可能性があり、次に、構造が変化する傾向があります



ただし、データアクセスプロシージャの作成を担当する人がそのようなシェルを作成しない場合は、数年以内に、多くのイニシアチブプログラマが「標準」APIを使用するのと同じ数の「単純化された」データアクセスシェルを使用できるように準備してください。

無効化された構造

このセクションでは、 あまり知られていないCMSで使用されている別のアプローチについて説明します。



コードの観点からは、オブジェクトの属性へのアクセスは、柔軟な構造の場合と同じ方法で、getAttribute / getAllAttributes /などのメソッドを介して行われます。 ただし、CMSの場合、主なタスクはオブジェクトを個別に（オブジェクト間の関係なしに）編集し、さらにオブジェクトをXMLで出力してさらに処理することです-このAPIで十分です。



興味深いことに、データ型のリストは何らかの構成ファイルに保存されます。 また、各タイプのこのファイルには、属性とそのタイプのリストが保存されています。 構成ファイルに基づいて、起動時にテーブル構造が作成または更新されます。 その後、オンザフライで、データ構造が変更されると、テーブルが更新されます。



長所：

-DBMSの明白なデータモデル

-その場での柔軟性

短所

-ビジネスロジックの観点から、APIは柔軟性が高すぎます（前のセクションを参照）

-独自のデータアクセスシステムを記述する必要があります。現時点では、残念ながら、システムオブジェクト（ユーザー、グループなど）とは異なり、トランザクション、キャッシュ、その他の機能は無視されます。

分類...試行

メタモデルを検討している場合、それを説明するには、次の質問に答える必要があります。

• モデルを説明するための出発点は何ですか？ （もちろん、これは一点であるべきです）オブジェクトとその属性に関する情報はどこに保存されますか？
• データベース内のデータストレージはどのように編成されていますか？
  • 最初の標準形式の要件は満たされていますか？
  • 2つの異なる単純な（複数ではない）属性が保存されます。
    • 2つの異なる列の形で
    • 2つの異なる行として
• データアクセスは、アプリケーションサーバーレベルでどのように整理されますか？
  • 標準のJPAメソッドが使用されます（EntityManagerなど）
  • データアクセスクラスが使用されます
• ビジネスロジックのレベルでデータアクセスはどのように整理されますか？
  • getName（）、getAddress（）などの標準メソッドが使用されます
  • getAttribtute（ID ...）などの非標準APIが使用されます
• プログラムからメタデータへのアクセスはありますか？
  • であり、あなたも変更することができます
  • そこにある
  • Reflections / Hibernate Mapping /などを通じてのみ

欲しい…著者にぴったり

データモデルを記述および操作するための理想的な（著者の観点から）システムの要件は、前の段落から簡単に導き出せます。

-データ構造の説明はデータベース内にある必要があります。これにより、おそらくアプリケーション自体を介して、モデルの説明をすばやく変更できます。

-データ自体は、正規化された（最大3〜4フォーム）データベースに保存する必要があり、各タイプには独自のデータテーブルがあります。 管理システム自体が、メタデータに従ってデータベーススキーマを管理する必要があります。

-データアクセスには、標準のJPA / EntityManagerインターフェイスを使用する必要があります。

-ビジネスロジックの観点から、メインオブジェクトタイプのメインフィールドは、追加の解決/キャスト/絞り込みなしで（つまり、EntityManagerからロードした直後に）シンプルなAPIを介してアクセスできる必要があります

-しかし、システムはメタデータへのアクセスも提供する必要があります。 特定のオブジェクトを含む-すべてのフィールドのリストを取得します。



現在、著者は以下を使用して同様のシステムを作成しています。

-Hibernate-データアクセスドライバーとして

-CGLIB / ASM-Hibernateの注釈を含む、記述に基づいたクラスの動的構築用

-XMLスキーマ-データ型とその属性を記述する



しかし、次回については。