時代は変わりました。
以前は、データは主に手動で入力され、専用のネットワーク プロトコルを備えた端末から「ガラスの家」の大きな鉄の箱に転送されていました。現在、情報は遍在し、常に存在していますが、常に社内に集約されているとは限りません。多くの場合、誰もが「フラット」な世界でデータを共有するため、情報源のチャネルが増え、情報自体がより頻繁に変化します。それだけでなく、Web 2.0、Enterprise 2.0、Internet Service Bus などの一連の概念の出現により、自社の「ガラスの家」からサプライヤーが提供する倉庫の住所を見つけるのは、Google よりもはるかに不便であることがわかりました。地図。
インターネットの下でこれまでのデータの束縛が一つ一つ解けてきたように思えますが、私たちIT実務者はユーザーが必要とするデータや情報を入手したい手段を提供するのが仕事なので、アプリケーションはこれまで懸念されていたユーザーインターフェイスの変更、アプリケーション間の呼び出しの変更、アプリケーションの内部ロジックの変更など、さまざまな変化が起きており、そのペースはますます速くなっているが、最も根本的なものは変更 - データ自体の変更。
関係モデルは、情報世界を記述するために二次元のテーブルを使用するように指示しますが、これはあまりにも「非」自然です。手元の本や家の装飾計画、または今後のプロジェクトのタスクを見てください。分解では、それを 2 次元のテーブルに入れるのは常に不適切であるようです。たとえ「エンティティとリレーションシップ」を切り取ったとしても、急速に変化する「データとアプリケーションとフロントエンドの相互作用」が常に含まれます。一連の環境の変化は、しばしば体全体に影響を及ぼします。
多くの新世代アプリケーションは、私たち自身の考えに近い方法でアプリケーションとユーザーエクスペリエンスを整理するという新しいトレンドであるXMLにより適したソリューションを見つけたようです。では、企業にとって、データを整理するという比較的基本的な作業も XML の考え方を使用して実行できるのでしょうか?大丈夫なはずです。
デザイン パターン を使用するか、さまざまなオープンソース開発フレームワーク (これらのフレームワーク自体を含む) を採用するかにかかわらず、データ エンティティは常にアプリケーションの最も安定した部分であると想定されてきました。アプリケーション自体の変化に対応するために最善を尽くしますが、実際はどうですか？
l 私たちが交換する必要があるデータ エンティティは、私たち自身とパートナーのニーズに応じて変更されることがよくあります。
l パートナーから提供されるデータ エンティティは、頻繁に変更されます。データ エンティティ自体は複数のソースからマッシュアップされ、データ エンティティ自体は繰り返し組み立てられ、結合されます
l ビジネスがより洗練されるにつれて、当社の従業員は常により豊富で詳細な情報を取得することを望んでいます
したがって、以前は、需要や設計に応じて最も早く修正されると考えられていたデータ エンティティは、ますます機敏になるテクノロジーとビジネスの現状に直面して継続的に調整する必要があります。この要件に適応するには、トップダウンから始めてアプリケーション自体の柔軟性を常に調整することができます。もう 1 つの方法は、この問題に「根本」から対処し、これらの変化に継続的に適応できる新しいデータ モデルを採用することです。 XML データ モデルや XML 関連テクノロジ ファミリなど。
たとえば、ユーザー エンティティを定義する場合、最初は次の情報で十分です。ここで、ICustomer はアプリケーションが使用するユーザー
インターフェース であり、CUSTOMER はリレーショナル データベース モードで表され、
しかしその後、この物理的な設計にはいくつかの問題があることがわかりました。ユーザーのオフィスの電話番号、自宅の電話番号、そしておそらく 1 つまたは 2 つの電子メール、MSN または Skype 番号なども追加する必要があったからです。他の問題とは関係なく、リレーショナル モデル仕様 1 の要件に基づいて、RDBMS と XML の 2 つのモデルを開発した結果は次のようになります:
「顧客」データ エンティティの末尾にある「連絡先情報」が変更されただけであるにもかかわらず、リレーショナル モデルと XML モデルの間の適応性に非常に大きな違いがあることを理解するのは難しくありません。モデルは、記述するために新しい関係を継続的に拡張する必要があります。データ エンティティは継続的に改良され、XML モデル自体の階層的な性質により、変化する条件下でそれ自体の継続的な拡張と拡張が可能になります。実際のプロジェクトにおいても、リレーションモデルでは「学歴」や「職歴」などの情報についても同様の問題が存在し、ある段階で顧客が勤務状況に「出向」という方法を追加したいと考えても、対応するフィールドは予約されているため、「ワークユニット」フィールドの文字列として使用し、その後に「(秒)」を付ける必要があります。剛直なデータ モデル自体はデータのビジネス セマンティクスを消去し、階層モデルはそれを子ノードまたは 属性 として記述することができるため、複数の関係 (顧客、学歴、職歴、連絡先情報) を記述することができます。リレーショナルモデルでは、1つのデータエンティティに集約する必要があり、さらに、各エンティティ独自の拡張情報（出向、交換、短期集中などの「勤務形態」）などもデータエンティティ内に記述することができます。同時に、「顧客」エンティティ自体は依然として外部アプリケーションのエンティティであるため、より使いやすくなります。実際のビジネス シナリオに近いデータ エンティティのみが、外部の変化により効果的に適応できます。
上記で説明したのは 1 つのデータ エンティティだけです。特定のビジネス ドメイン モデルにさらに発展すると、多くの場合、連携してビジネス機能を完了するために複数のデータ エンティティを同時に統合する必要があります。例: 保険契約では、上記の情報に加えて、個人の健康情報、子供、両親、パートナーの主な家族情報の提供が求められます。同時に、ユーザーの信用情報も他の機関から取得され、別のデータが取得されます。エンティティの組み合わせは主に企業内でさまざまなアプリケーション分野で使用されるため、データ利用の観点からアプリケーション部分をできるだけ安定させるには、データ エンティティが安定していることが最善ですが、連絡先情報部分のみが安定しています。ユーザー情報の一部が繰り返し変更される可能性があるため、アプリケーションがこれらの変化要因の組み合わせに完全に依存している場合、その結果、アプリケーションの安定性を保証することが実際に困難になります。そのため、ソースからの最初のステップは、それを保証することです。さまざまなアプリケーションが可能な限り特定のエンティティのみに依存するようにすることで、この情報を自由に組み合わせることができるなど、XML の階層的特性の利点が改めて明らかになります。
このようにして、アプリケーションは統合された
上記のデータ エンティティについては、一元化されたコンテキストで詳しく説明されていますが、概念設計に加えて、使用中にはどのように統合するかという特定の問題もあります。これは通常、データセットを通じて実現されます。
(ただし、「アーキテクチャ」という言葉が乱用されているように、「データ統合」もさまざまなメーカーが自社の製品特性に基づいた異なる概念の組み合わせとして定義しています。たとえば、BIメーカーはそれを説明しようと努めています。 ETL と同義で、データ交換プラットフォームを提供するベンダーは、BizTalk フレームワーク を実装する製品を指します。SOA 製品企業にとって、データ統合とは、効果的なガバナンスを前提としてデータ サービスが提供されることを保証する方法を意味します。さらに、一部のメーカーにとっては、データ統合にはビジネス セマンティックの組み合わせなども含まれます)
しかし、ユーザーとして、データ統合においてどのような問題に焦点を当てるべきでしょうか?
l データ エンティティのマッピング関係
l さまざまな交換プロトコル、業界データ標準、およびセキュリティ制御制約に基づくデータ ソースの相互接続
l データ交換プロセスのオーケストレーション。 - データ エンティティの調査。
l データ メディアとデータ キャリアの変換。理論的には、これらのタスクをコーディングで完了することは問題ではありませんが、エンタープライズ統合ロジックはますます複雑になり、より速く変化します。コードを変更することで 1 :N 統合にも対応できますが、M:N の場合が多い場合は不十分であると思われます。もっと簡単な方法はありますか? 「マッピング」の論理レベルから言えば、次のようになります。
l
オブジェクト指向このアイデアは、依存関係の逆転に依存し、エンティティ タイプではなくインターフェイスに依存するなど、具体性ではなく抽象化に依存するように努めます。 l デザインパターンからわかることは、互換性のあるインターフェイスアダプター (アダプター) を使用しないことが良い方法であるということです
では、データ分野にも同様のテクノロジーはあるのでしょうか? XML スキーマ + XSLT がオプションになる場合があります。
上記は、新しいユーザー エンティティと古いユーザー エンティティとの互換性を保つために行われる変換です。同様に、異なるサブジェクトに対してデータ エンティティ 集計 操作の上記の部分を実行する必要がある場合は、XSLT (スキーマ) を使用することもできます。抽象データ定義（スキーマ）レベルでの適応関係）が完成します。
このようにして、データがデータ エンティティ レベルでどのように集約されているかがわかりますが、その前に解決する必要がある問題がまだあります。レガシー システムからの車両情報、信用情報、顧客情報はすべてこのデータ チャネルをパートナーの Web サービスに接続するにはどうすればよいですか?これからも XML が良い選択です。
さまざまなデータメディア上のデータは、プレーンテキスト、リレーショナルデータベース、EDIメッセージ、SOAPメッセージなどの元の形式で抽出でき、さまざまな情報チャネルを通じてデータ統合コンバージェンスポイントに送信され、その後、目的のデータ ソースは、アダプターを介して異種データ ソースを変換する必要があります。
現時点で、2 つのタイプごとにポイントツーポイント アダプターを設計すると、全体の規模は N^2 レベルの傾向に沿って発展するため、この情報と互換性のある XML に統一するとよいでしょう。 、その後、上記で紹介した XSLT を使用します。このテクノロジがデータ エンティティ間のマッピングを実行した後、XML がターゲット データ ソースに必要な形式に変換されるため、アダプテーション システム全体の複雑さが N レベルに軽減されます。
次に、XML テクノロジーが前提条件となるデータ統合要件をどのように満たしているかを見てみましょう:
l データ エンティティのマッピング、データ メディア、データ キャリアの変換、データ エンティティの検証と再構築:
上記と同様、まず、データは均一に XML に変換され、XML の階層的な利点を使用して処理され、XML 固有のテクノロジと組み合わせられます。
l さまざまな交換プロトコル、業界データ標準、セキュリティ制御制約に基づくデータ ソースの相互接続
XML データは、ネットワークやファイアウォールを越えるだけでなく、インターネット環境でも簡単に使用できます。 message queue メソッドはそれらをメッセージとして定義します)、そしてデータ自体は特別なバイナリ操作により交換プロトコルによって制限されません。現在、さまざまな業界標準は、データベース設計や歴史的遺産などの問題により、内部システム自体のデータ エンティティがこれらの DM に準拠していない場合でも、基本的に XML を使用して独自の業界 DM (データ モーダル) を記述しています。 XML データの統一管理の標準により、変換が容易になります。セキュリティに関しては、WS-* 関連プロトコルほどインターネット環境に適したセキュリティ標準ファミリはないようです。すべての標準は例外なく、XML エンティティを使用してデータと追加のセキュリティ メカニズムの組み合わせ関係を定義できます。
l データ交換プロセスのオーケストレーション;
同種のシステム環境、または互換性のある ミドルウェア システムのみに基づくプラットフォームの場合、データ交換プロセスをオーケストレーションするためにレガシー ワークフロー メカニズムを使用できますが、これはサービス指向に適応するためです。この時代では、クロスプラットフォームとして宣伝されてきた Java テクノロジと比較して、XML はデータであるだけでなく、実行命令の形式としても採用されています。 XML で定義されたプロセスはさらにクロスランゲージになります。
統合によって多くの問題が解決されたように見えますが、明らかな問題は、すべての作業を自分で実装し、その方法を段階的にアプリケーションに指示する必要があるかもしれないということです。 Web を単なる「新しいもの」として、そしてそれを情報コンテンツに提供し、対話できるシステムとして考えるとき、これらの散在するサービス機能をどのように自分自身に提示すればよいでしょうか?おそらくこの時点で、XML のオープンなメタデータ定義の利点が実際に明らかになるでしょう。
さまざまなセマンティックアルゴリズムに加えて、散在するさまざまなサービスをどのように集約してサービスを提供するかが、XML の重要な要素の 1 つは、データの手がかりを見つけてそれを作成することです。クリア このバックボーン上のエンティティ間の関係と、その段階的な分解と洗練のプロセス。このレベルのデータは、アプリケーションによって受動的に呼び出されるオブジェクトであるだけでなく、それ自体がアプリケーションによるさらなる推論のサポートを提供します。例:
ここで、アプリケーションは、現在処理されているオブジェクトがガチョウの肉であることを最初に学習します。ガチョウの肉は一種のダークミートであり、ダークミートはある種の家禽肉（家禽）であるため、アプリケーションは徐々に推測することができます。そのガチョウの肉は食べられます。上記の推論プロセスは複雑ではありませんが、リレーショナル データベースを使用して実装する場合、鶏肉、野菜、デザートなどのすべての関係をプレーン テキストで記述すると、実装はさらに難しくなります。魚介類はすべて関係性の観点から表現されます。データベースやテキストの記述は非常に使いにくいです。 XML は、企業の ERP 環境での制作資料の準備プロセスであっても、誕生日パーティーの料理の準備であっても、私たちの思考習慣に自然に近く、オープンかつ複雑に絡み合った方法で表現できます。プランを購入するため。
おそらく、あまりにも長い間 2 次元グリッドの制約に制限されてきたため、アプリケーションの設計やアイデアはコンピューター処理自体によってますます制約されるようになりました。しかし、ビジネス環境の変化に伴い、ビジネス要件の発生から、オンラインになるまでの間隔はますます短くなり、私たちはますますコンピューターから思考を遠ざけなければならない現在、よりオープンで私たちに近いデータテクノロジーを採用することがより望ましいと思われます。多様な考え方。組織では、データが実装された後も、さまざまな成熟したテクノロジーを使用してデータを完成させることができますが、より近いビジネス レベルで、より不安定な環境に近い場合、XML は柔軟で強力であると思われます。
以上がXML の考え方を使用してデータを整理する方法の詳細な紹介 (図)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
