情報システムアーキテクチャの概念。 情報システムの構造とアーキテクチャ

建築 情報システム– これは、情報システムのモデル、実行される機能、およびコンポーネントの関係を定義する構造の概​​念的な説明です。

情報システムのアーキテクチャには、次の 3 つのコンポーネントが存在します。

1. 情報技術

2.機能サブシステム

3. 情報システム管理

次のタイプのアーキテクチャが区別されます。 ファイルサーバー。 クライアントサーバー。 マルチレベル。 データウェアハウスベースのアーキテクチャ。 インターネット/イントラネット。

ファイルサーバーのアーキテクチャ。ファイル サーバー アーキテクチャには、PS ダイアログ コンポーネントと PL ダイアログ コンポーネントがネットワークで分離されておらず、表示機能にコンピュータを使用するため、グラフィカル インターフェイスの構築が容易になります。 ファイルサーバーはファイルからデータのみを取得するため、 追加のユーザーまた、アプリケーションが追加する CPU 負荷はごくわずかです。 毎 新しいクライアントネットワークにコンピューティング能力を追加します。 ファイル サーバー アプリケーションの開発オブジェクトは、ダイアログ ロジック PL、BL およびデータ管理 DL を処理するためのロジックを定義するアプリケーション コンポーネントです。 開発されたアプリケーションは、完全なブート モジュールとして、またはブート モジュールとして実装されます。 特別なコード解釈のために。 ただし、このアーキテクチャには、 重大な欠点: 一部のデータベース クエリでは、大量のデータがクライアントに送信され、ネットワークに負荷がかかり、予測不能な応答時間が発生する可能性があります。

クライアントサーバーアーキテクチャ。クライアント サーバー アーキテクチャは、アプリケーション コンポーネントを分離し、最も効率的に機能する場所に配置することで、ファイル サーバー アプリケーションの問題を解決するように設計されています。 クライアント/サーバー アーキテクチャの特徴は、その言語でのクエリを理解する専用のデータベース サーバーを使用することです。 構造化クエリ SQL (Structured Query Language) と情報の検索、並べ替え、集計を実行します。 特徴的な機能データベース サーバー - データ ディレクトリの存在。データベースの構造、データ整合性の制限、形式、さらには呼び出しやプログラム内のイベントによってデータを処理するためのサーバー プロシージャが記録されます。 このようなアプリケーションの開発オブジェクトは、ダイアログや処理ロジックに加えて、まずリレーショナル データ モデルと、典型的なデータベース クエリに関連する一連の SQL ステートメントです。 ほとんどのクライアント/サーバー構成では、クライアントがサーバーのサービスにアクセスする 2 層モデルが使用されます。 ダイアログ コンポーネント PS および PL はクライアント上でホストされていると想定されています。 GUI。 データ管理コンポーネント DS および FS はサーバー上に配置され、ダイアログ (PS、PL)、BL および DL ロジックはクライアント上に配置されます。 クライアント/サーバー アーキテクチャの 2 レベルの定義では、まさにこのオプションが使用されます。アプリケーションはクライアントで実行され、DBMS はサーバーで実行されます。 この方式ではサーバーへの要求が最小限に抑えられるため、スケーラビリティが最も優れています。 ただし、多くのデータベース対話を伴う複雑なアプリケーションは、クライアントとネットワークの両方に大きな負荷を課す可能性があります。 SQL クエリの結果は、決定ロジックが存在する場所であるため、処理のためにクライアントに返される必要があります。 この設計により、さまざまなクライアント ノードに分散したアプリケーションの管理がさらに複雑になります。 ネットワーク負荷を軽減し、アプリケーション管理を簡素化するために、BL コンポーネントをサーバー上でホストできます。 この場合、すべての意思決定ロジックはストアド プロシージャの形式で形式化され、データベース サーバー上で実行されます。 ストアド プロシージャ - を含むプロシージャ SQL文データベースにアクセスするには、名前で呼び出し、必要なパラメータを渡してデータベース サーバー上で実行します。 ストアド プロシージャはコンパイルできるため、実行速度が向上し、サーバーの負荷が軽減されます。 マルチターミナルシステムに基づいてクライアントサーバーアーキテクチャを構築することも可能です。 この場合、ユーザー プログラムはマルチタスク アプリケーション サーバー環境で実行され、クライアント ノードは縮退して端末で表されます。 同様の情報システム方式は、UNIX では一般的です。

マルチレベルのアーキテクチャ。多層アーキテクチャはクライアント/サーバー アーキテクチャを発展させたもので、古典的な形式では次の 3 つの層で構成されます。

最下層は、PS ビューと PL ビューの機能とロジックの実行専用のクライアント アプリケーションを表し、中間層のアプリケーションを呼び出すためのプログラミング インターフェイスを備えています。

中間層は、アプリケーション ロジック BL が実行され、データ処理ロジック DL がデータベース操作 DS を呼び出すアプリケーション サーバーです。

最上位レベルは、DS データ処理サービス専用のリモート特化データベース サーバーです。 ファイル操作 FS (ストアド プロシージャを使用するリスクなし)。

インターネット/イントラネット技術。インターネット/イントラネット技術の開発においては、これまでのところソフトウェア ツールの開発が主に重点を置かれてきました。 同時に、データベースと連携するアプリケーションを開発するための開発ツールも不足しています。 データベースと効果的に連携する、便利で使いやすく保守しやすい情報システムを構築するための妥協案は、インターネット/イントラネット テクノロジとマルチレベル アーキテクチャの組み合わせでした。 同時にその構造は、 情報アプリケーション取得する 次のビュー: ブラウザ – アプリケーション サーバー – データベース サーバー – サーバー 動的ページ– Webサーバー。 インターネット/イントラネット テクノロジとクライアント サーバー アーキテクチャの統合により、企業情報システムの実装と保守のプロセスが大幅に簡素化され、同時に非常に高い効率と情報共有の容易さが維持されます。

4. 開発段階と基本的な知財規格 .

情報システム開発の主な段階:

1950 年から 1960 年 - 紙の決済文書の作成。 機能: 電気機械および会計機械での決済文書の処理。 目標: 文書処理の速度を向上させ、請求書の処理と給与の支払い手順を簡素化します。

1960 ～ 1970 年 - レポートの生成。 機能：生産情報管理。 目標: レポート作成プロセスのスピードアップ

1970年から1980年 - 生産と販売の管理統制。 機能: 意思決定のサポート。 目標: 生産 最適解

1980年代 - 現在、企業開発戦略を管理しています。 機能: 戦略的意思決定を行うための情報を生成します。 目標: ビジネス戦略管理のサポート

企業管理システムの最初の標準は、70 年代に登場した MRP (資材所要量計画) 標準でした。 生産のための資材の計画が含まれます。

MRP システムは、生産ニーズを満たす資材計画に基づいており、MRP 機能、生産能力利用率 CRP (Capacity Resources Planning) を記述および計画する機能を直接含み、作成することを目的としています。 最適な条件製品リリースに向けた生産計画を実行します。 MRP システムの基本的な考え方は、製品の生産に必要な材料またはコンポーネントの会計単位が、いつでも利用可能でなければならないということです。 適切な時期そしてで 適切な量。 MRP システムの主な利点は、材料とコンポーネントによる一連の生産作業を形成し、完成品生産の主な生産計画の実行に向けてコンポーネント (半製品) をタイムリーに生産できるようにすることです。

次のスタンダード企業のすべての生産リソース (原材料、材料、設備など) を計画できる MRP II (Manufacturing Resource Planning) がありました。

ERP システムは、MRP II システムをさらに発展させたもので、すべての主要な活動に対するエンタープライズ リソース プランニングが含まれています。

CRM システム。 新しい顧客関係管理テクノロジーにより、サービスが大幅に向上し、市場に人気の製品をタイムリーに提供できるようになります。 これらの焦点は、ビジネス プロセスではなく、会社の顧客にあります。 CRM システムを使用すると、企業は顧客とそのニーズについて可能な限りの情報を取得し、このデータの分析に基づいて、生産、マーケティングと広告、販売、サービス、サービスなどの活動のあらゆる側面に関連する組織戦略を構築できます。 CRM を使用すると、さまざまなチャネル (電話、ファックス、ウェブサイト、 電子メール、個人訪問など）、一般顧客との多角的なコミュニケーションを調整し、インターネットを含む販売および顧客志向のマーケティングを一元管理します。 このようなシステムを通じて、次のことが可能になります。 フィードバッククライアントを会社全体でサポートします。

企業経営情報システムの分類

情報システム- 所定の目標を達成するために、情報を保存、処理、発行するために使用される、相互に接続された一連の手段、方法、および人員。

で 連邦法「情報、情報化および情報保護」については、次のように定義されています。

「情報システム」- 組織的に順序付けられた一連の文書 (文書の配列) および情報技術 (以下の使用を含む) コンピューター技術とコミュニケーションの実装 情報プロセス»

規模による分類

情報システムは規模に応じて次のグループに分類されます。

・ シングル;

・ グループ;

・法人。

単一の情報システム原則としてスタンドアロンのパーソナルコンピュータ上で実装されます（ネットワークは使用されません）。 このようなシステムには、いくつかのものが含まれる場合があります。 単純なアプリケーション共通の情報基金によって接続されており、1 人のユーザーまたは情報を共有するユーザーのグループの作業用に設計されています。 職場. 同様のアプリケーションいわゆるデスクトップを使用して作成するか、 ローカルシステムデータベース管理 (DBMS)。 ローカル DBMS の中で最も有名なのは、Clarion、Clipper、FoxPro、Paradox、dBase、Microsoft Access です。

グループ情報システムワークグループのメンバーによる情報の共同使用に焦点を当てており、ほとんどの場合、ローカル コンピューター ネットワークに基づいて構築されます。 このようなアプリケーションを開発する場合、データベース サーバー (SQL サーバーとも呼ばれます) がワークグループに使用されます。 商用および無料配布の両方で、非常に多くの異なる SQL サーバーが存在します。 その中で最も有名なデータベースサーバーはOracle、DB2、Microsoftです。 SQLサーバー、InterBase、Sybase、Informix。

企業情報システムワークグループ用のシステムの開発であり、次のことに重点を置いています。 大企業地理的に分散したノードやネットワークをサポートできます。 基本的に、それらはいくつかのレベルの階層構造を持っています。 このようなシステムは、サーバーを特化したクライアント/サーバー アーキテクチャまたはマルチレベル アーキテクチャによって特徴付けられます。 このようなシステムを開発する場合、グループ情報システムを開発する場合と同じデータベースサーバーを使用できます。 ただし、大規模な情報システムでは、最も普及しているのは Oracleサーバー、DB2 および Microsoft SQL Server。

グループ向けや 企業システム運用の信頼性とデータのセキュリティに対する要件が大幅に増加しています。 これらのプロパティは、データベース サーバー内のデータ、リンク、トランザクションの整合性を維持することによって提供されます。

応用分野による分類

アプリケーションの範囲に応じて、情報システムは通常、次の 4 つのグループに分類されます。

· トランザクション処理システム。

· 意思決定システム。

· 情報および参照システム。

・オフィス情報システム。

トランザクション処理システム、データ処理の効率に応じて、パッケージ情報システムと運用情報システムに分けられます。 組織管理の情報システムではこのモードが主流 運用処理反映するトランザクション 関連する州 対象分野いつでも、そして バッチ処理非常に限られた部分を占めています。

意思決定支援システム - DSS (意思決定支援システム) - 別のタイプの情報システムを表し、非常に複雑なクエリを使用して、時間、地理、その他の指標などのさまざまなコンテキストでデータが選択および分析されます。

充実した授業 情報および参照システムハイパーテキストドキュメントとマルチメディアに基づいています。 このような情報システムはインターネット上で最も大きく発展しました。

クラス オフィス情報システム紙の文書を～に翻訳することを目的としています。 電子ビュー、オフィスオートメーションと文書管理。

組織の方法による分類

組織の方法に従って、グループおよび企業の情報システムは次のクラスに分類されます。

· ファイルサーバーアーキテクチャに基づくシステム。

· クライアントサーバーアーキテクチャに基づくシステム。

· マルチレベルアーキテクチャに基づくシステム。

· インターネット/イントラネット テクノロジに基づくシステム。

どのような情報システムでも、さまざまな情報システム アーキテクチャの制限を理解するのに役立つ必要な機能コンポーネントを特定することができます。

ファイルサーバーのアーキテクチャファイルからデータのみを抽出するため、ユーザーやアプリケーションが追加されても CPU 負荷は無視できます。 新しいクライアントごとに、ネットワークにコンピューティング能力が追加されます。

クライアントサーバーアーキテクチャは、アプリケーション コンポーネントを分離し、最も効率的に機能する場所に配置することで、ファイル サーバー アプリケーションの問題を解決するように設計されています。 クライアント/サーバー アーキテクチャの特徴は、構造化言語でクエリを理解する専用のデータベース サーバーを使用することです。 SQLクエリ(構造化クエリ言語) と情報の検索、並べ替え、および集約。

現在、クライアント サーバー アーキテクチャは、ワークグループやエンタープライズ レベルの情報システム用のアプリケーションを編成する方法として認識され、広く使用されています。 この作業の編成により、データベース サーバーの機能を使用し、ネットワークの負荷を軽減し、データの整合性制御を確保することで、アプリケーションの実行効率が向上します。

階層化されたアーキテクチャクライアント/サーバー アーキテクチャの発展形となり、古典的な形式では次の 3 つのレベルで構成されます。

· 下位レベルは、中位レベルのアプリケーションを呼び出すためのプログラム インターフェイスを持つクライアント アプリケーションを表します。

· 中間レベルはアプリケーション サーバーです。

· トップレベルはリモートに特化したデータベース サーバーです。

3層アーキテクチャこれにより、さまざまなノードやネットワーク上の負荷のバランスをさらに調整できるようになり、アプリケーション開発ツールの専門化が促進され、2 層クライアント/サーバー モデルの欠点が解消されます。

開発中 インターネット/イントラネット技術これまでのところ、主にソフトウェア ツールの開発に重点を置いています。 同時に、データベースと連携するアプリケーションを開発するための開発ツールも不足しています。 データベースと効果的に連携する、便利で使いやすく保守しやすい情報システムを構築するための妥協案は、インターネット/イントラネット テクノロジとマルチレベル アーキテクチャの組み合わせでした。 この場合、情報アプリケーションの構造は、ブラウザ - アプリケーション サーバー - データベース サーバー - ダイナミック ページ サーバー - Web サーバーという形式になります。

保存される情報の性質に基づいて、データベースは次のように分類されます。 事実上のそして ドキュメンタリー。 上で説明した情報リポジトリの例で類推すると、事実データベースはカードのインデックスであり、文書データベースはアーカイブです。 事実データベースストア 簡単な情報厳密に定義された形式で。 ドキュメント データベースには、あらゆる種類のドキュメントが含まれています。 さらに、これだけでなく、 テキストドキュメントだけでなく、グラフィックス、ビデオ、サウンド (マルチメディア) も含まれます。

自動制御システム (ACS) は、生産環境、科学環境、または公共環境におけるオブジェクト (複合体) の制御を提供する、組織構造 (個人またはチーム) と組み合わせた一連の技術ツールおよびソフトウェア ツールです。

教育管理 (人事、志願者、学生、図書館プログラムなど) のための情報システムがあります。 自動化システム 科学研究(ASNI) は、さまざまな種類の実験施設からのデータを処理するソフトウェアおよびハードウェア システムです。 測定器、その分析に基づいて、新しい効果とパターンの発見を促進します。 コンピュータ支援設計および地理情報システム。

特定の主題分野に関する質の高い専門知識（専門家、つまりこの分野の専門家から得た）に基づいて構築された人工知能システムは、エキスパートシステムと呼ばれます。 エキスパート システム (人工知能システムの数少ないタイプの 1 つ) は広く普及しており、 実用化。 軍事科学、地質学、工学、コンピューター科学、宇宙技術、数学、医学、気象学、工業、農業、経営、物理学、化学、電子、法律などの専門家システムがあります。 そして、エキスパート システムが依然として非常に複雑で高価であり、そして最も重要なことに高度に専門化されたプログラムであるという事実だけが、そのさらなる広範な普及を妨げています。

エキスパートシステム（ES）は、 コンピュータプログラム、人間の専門家が実行できるような種類のアクティビティを実行するために作成されました。 これらは人間の専門家の動作を模倣する方法で機能し、ほとんどの従来の設計における正確で合理的なアルゴリズムや数学的手順とはまったく異なります。

情報システムのアーキテクチャ– 情報システムのモデル、構造、実行される機能、およびコンポーネントの相互接続を定義する概念。

構造的には、アーキテクチャは通常、次の質問に対する一連の回答として定義されます。

· システムが行うこと。

· これらの部分がどのように相互作用するか。

· これらの部品が配置されている場所。

どの部分に分かれているのでしょうか？

分布の程度に応じて、次のように区別されます。

すべてのコンポーネント (DB、DBMS、クライアント アプリケーション) が 1 台のコンピューター上に配置されているデスクトップまたはローカル情報システム。

分散型 IC。コンポーネントが複数のコンピュータに分散されています。

分散情報システムは、次のように分類されます。

- ファイルサーバーIS(ファイルサーバーアーキテクチャの IS);

専用のファイル サーバーの使用に基づいた情報システムの構成は、可用性の理由から依然として一般的です。 大量 パーソナルコンピュータ さまざまなレベル PC をローカル ネットワークに接続する開発と比較的安価な方法。

もちろん、この最大の利点は、 建築それは組織のシンプルさです。 マルチプレイヤーモードデータの操作。

• 集中アクセス制御の利便性。
• 開発コストが低い。
• 高い開発スピード。
• ソフトウェアの更新と変更のコストが低い。

欠点:

• データを扱うマルチユーザーの問題: 順次アクセス、整合性保証の欠如。
• パフォーマンスが低い (ネットワーク、サーバー、クライアントのパフォーマンスに依存)。
• 新しいクライアントを接続する能力が低い。
• システムの信頼性の低さ。

- クライアント/サーバー IS (クライアント/サーバー アーキテクチャの IS)。

クライアントサーバー– コンピューティングまたは ネットワークアーキテクチャ、どのタスクまたは ネットワーク負荷サーバーと呼ばれるサービスプロバイダー (サービス) とクライアントと呼ばれるサービス顧客の間で分散されます。

この利点 建築は：

• ほとんどの場合、機能を分散する機能 コンピューティング システムネットワーク上の複数の独立したコンピュータ間。
• すべてのデータはサーバーに保存され、通常、ほとんどのクライアントよりもはるかに保護されています。また、適切なアクセス権を持つクライアントのみにデータへのアクセスを許可するようにサーバー上で権限制御を提供することも簡単です。
• マルチユーザー作業のサポート。
• データの完全性の保証。

欠点:

• サーバー障害により全体がレンダリングされる可能性があります コンピュータネットワーク;
• このシステムの管理には資格のある専門家が必要です。
• 設備のコストが高い。
• アプリケーションのビジネス ロジックはクライアント ソフトウェアに残りました。

ファイル サーバー IS では、データベースはファイル サーバー上に配置され、DBMS とクライアント アプリケーションはワークステーション上に配置されます。

クライアントサーバー IS では、データベースと DBMS がサーバー上に配置され、クライアント アプリケーションがワークステーション上に配置されます。

次に、クライアント/サーバー IS は 2 リンクとマルチリンクに分けられます。

2 層 IS には、データベースと DBMS が配置されるデータベース サーバーと、クライアント アプリケーションが配置されるワークステーションの 2 種類の「リンク」のみがあります。 クライアント アプリケーションは DBMS に直接アクセスします。

多層 IS では、アプリケーション サーバーという中間の「リンク」が追加されます。 ユーザー クライアント アプリケーションは、中間リンクと対話して DBMS に直接アクセスしません。 多層の使用の典型的な例は、データベースを使用する最新の Web アプリケーションです。 このようなアプリケーションでは、Web ブラウザで実行される DBMS リンクとクライアント リンクに加えて、少なくとも 1 つの中間リンク (対応するサーバー ソフトウェアを備えた Web サーバー) が存在します。

組織の方法に従って、グループおよび企業の情報システムは次のクラスに分類されます。

マルチレベルアーキテクチャに基づくシステム。

インターネット/イントラネット技術に基づいたシステム。

どのような情報システムでも、さまざまな情報システム アーキテクチャの制限を理解するのに役立つ必要な機能コンポーネントを特定することができます (表 3.2)。

表 3.2 – 情報システムの典型的な機能コンポーネント

指定	名前	特性
	プレゼンテーションサービス （プレゼンテーションの手段）	ユーザーからの入力を受け付け、処理結果を表示するデバイスによって提供されます。
	プレゼンテーションロジック	ユーザーとコンピューター間の対話を管理します。 メニューからコマンドを選択するとき、ボタンを押すとき、またはリストから項目を選択するときのユーザーのアクションを処理します。
	ビジネスまたはアプリケーション ロジック (応用ロジック)	アプリケーションが実行する必要がある決定、計算、および操作を行うための一連のルール。
	(データ管理ロジック)	適用されたデータ管理ロジックを実装するために実行する必要があるデータベース操作 (SQL ステートメント)。
	(データベース操作)	データ操作、データ定義、トランザクションのコミットまたはロールバックなどのデータ管理ロジックを実行するために呼び出される DBMS アクション。通常、DBMS は SQL ステートメントをコンパイルします。
	(ファイル操作)	DBMS およびその他のコンポーネントのディスク読み取りおよび書き込み操作 (ファイル操作)。 通常は関数です オペレーティング·システム(OS)

情報アプリケーションを構築するためのオプションの機能を詳しく見てみましょう。 情報システムは、機能コンポーネントの位置に基づいてクラスに分類されます。 さまざまな情報システム アーキテクチャの制限を理解するのに役立つ、必要な機能コンポーネントを特定することができます。 情報アプリケーションを構築するためのオプションの機能を詳しく見てみましょう。

情報システムは組織化の方法に応じて次のように分類されます。

ファイルサーバーアーキテクチャに基づくシステム。

クライアントサーバーアーキテクチャに基づくシステム。

マルチレベルアーキテクチャに基づいたシステム。

ファイルサーバーのアーキテクチャ コンポーネントはネットワークで分離されておらず、クライアント コンピュータを使用してダイアログとデータ処理機能を実行するため、グラフィカル インターフェイスの構築が容易になります。 ファイル サーバーはファイルからデータのみを取得するため、ユーザーやアプリケーションが追加されても CPU にかかる負荷はごくわずかです。 新しいクライアントごとに、コンピューティング ネットワークにコンピューティング能力が追加されます。

ファイル サーバー アプリケーションの開発オブジェクトは、ダイアログ ロジック PL、処理ロジック BL、データ管理 DL を定義するアプリケーション コンポーネントです。 . 開発されたアプリケーションは、完全なブート モジュールとして、または解釈用の特別なコードとして実装されます。

ただし、このアーキテクチャには重大な欠点があります。一部のデータベース クエリを実行すると、大量のデータがクライアントに転送され、ネットワークに負荷がかかり、応答時間が予測不能になる可能性があります。 大量のネットワーク トラフィックは、低速通信チャネルを介してファイル サーバー上のデータベースへのリモート アクセスを組織する場合に特に大きな影響を与えます。 この欠点を解消するオプションの 1 つは、ネットワーク上のファイル サーバー アプリケーションをリモートで管理することです。 この場合、アプリケーション サーバーはローカル ネットワーク上に配置され、電気通信サーバー (通常はアクセス サーバーと呼ばれます) と組み合わせられ、そこで通常のファイル サーバー アプリケーションが実行されます。 このような組織の特徴は、対話型の入出力が遠隔のクライアントから通信を通じて行われることです。

クライアントサーバーアーキテクチャ は、アプリケーション コンポーネントを分離し、最も効率的に機能する場所に配置することで、ファイル サーバー アーキテクチャの問題を解決するように設計されています。 クライアント/サーバー アーキテクチャの特徴は、構造化照会言語 (SQL) のクエリを理解し、情報の検索、並べ替え、および集計を実行する専用のデータベース サーバーを使用することです。

データベース サーバーの特徴は、データ ディレクトリの存在です。データ ディレクトリには、データベースの構造、データ整合性の制限、形式、さらには呼び出しやプログラム内のイベントによってデータを処理するためのサーバー プロシージャが記録されます。 このようなアプリケーションの開発オブジェクトは、ダイアログや処理ロジックに加えて、まず、リレーショナル データ モデルと、標準データベース クエリ用の関連する SQL 演算子のセットです。

ほとんどのクライアント/サーバー構成では、クライアントがサーバーのサービスにアクセスする 2 層モデルが使用されます。 ダイアログ コンポーネント PS および PL はクライアント上でホストされ、グラフィカル インターフェイスを提供すると想定されています。 データ管理コンポーネント DS および FS はサーバー上に配置され、ダイアログ (PS、PL)、ロジック BL および DL はクライアント上に配置されます。 2 層のクライアント/サーバー アーキテクチャでは、まさにこのオプションが使用されます。アプリケーションはクライアントで実行され、DBMS はサーバーで実行されます。

このアーキテクチャはサーバーへの要求が最小限であるため、最高のスケーラビリティを備えています。 ただし、多くのデータベース対話を伴う複雑なアプリケーションは、クライアントとネットワークの両方に大きな負荷を課す可能性があります。 SQL クエリの結果は、決定ロジックが存在する場所であるため、処理のためにクライアントに返される必要があります。 この設計により、さまざまなクライアント ノードに分散したアプリケーションの管理がさらに複雑になります。

ネットワーク負荷を軽減し、アプリケーション管理を簡素化するために、BL コンポーネントをサーバー上でホストできます。 この場合、意思決定ロジック全体は次の形式で形式化されます。 ストアドプロシージャそしてデータベースサーバー上で実行されます。 ストアド プロシージャ -データベースにアクセスするための SQL ステートメントを含むプロシージャを名前で呼び出し、必要なパラメータを渡してデータベース サーバー上で実行するストアド プロシージャをコンパイルできるため、実行速度が向上し、サーバーの負荷が軽減されます。

ストアド プロシージャにより、アプリケーションとデータベースの整合性が向上し、共有操作と計算が最新の状態に保たれます。 このような手順のサポートとデータ セキュリティが向上しました (データへの直接アクセスはありません)。

2 層のクライアント/サーバー アーキテクチャは、多くのユーザーと複雑なロジックを備えた複雑な情報アプリケーションで問題を引き起こす可能性があります。 これらの問題の解決策は、多層アーキテクチャを使用することです。

マルチレベル アーキテクチャはクライアント サーバー アーキテクチャを発展させたもので、古典的な形式では次の 3 つのレベルで構成されます。

最下層は、PS および PL ビューの機能とロジックの実行専用のクライアント アプリケーションであり、中間層のアプリケーションを呼び出すためのプログラミング インターフェイスを備えています。

中間層は、アプリケーション ロジック BL が実行され、データ処理ロジック DL がデータベース操作 DS を呼び出すアプリケーション サーバーです。

最上層は、DS データ処理サービスと FS ファイル操作 (ストアド プロシージャを使用しない) 専用のリモート専用データベース サーバーです。

3 層アーキテクチャは、さまざまなノードとネットワークにわたる負荷のバランスをさらに高めながら、アプリケーション開発のためのツールの特化を促進し、2 層クライアント/サーバー モデルの欠点を解消します。

アプリケーションロジックを一元化することで、管理とメンテナンスが簡素化されます。 インターフェイスとアプリケーション ロジックを実装するためのプラットフォームとツールは明確に分離されているため、高度に専門化された専門家が最大限の効率で実装することができます。 最後に、アプリケーション ロジックの変更はインターフェイスには影響せず、その逆も同様です。 ただし、コンポーネント PL 間の境界があるため、 , BL と DL は曖昧であり、アプリケーション ロジックは 3 つのレベルすべてに表示されます。 アプリケーション サーバーは、トランザクション モニターを使用して、クライアントおよび他のサーバーとのインターフェイスを提供し、トランザクションを管理し、分散データベースの整合性を保証できます。 リモート プロシージャ コール ツールは、分散コンピューティングの考え方と最も一致しています。リモート プロシージャ コール ツールは、任意のネットワーク ノードから別のノードにあるアプリケーション プロシージャへの呼び出し、パラメータの転送、リモート処理、および結果の返しを提供します。 クライアント/サーバー システムの成長に伴い、3 つのレベルの必要性がますます明らかになってきています。

したがって、分散アプリケーションのマルチレベル アーキテクチャにより、企業情報システムの効率が向上し、ソフトウェアおよびハードウェア リソースの分散が最適化されます。 しかし今のところ、クライアントサーバーアーキテクチャが依然としてロシア市場を支配している。

インターネット/イントラネット技術。 インターネット イントラネット テクノロジの開発において、これまでのところ主に重点を置いているのはソフトウェア ツールの開発です。 同時に、データベースと連携するアプリケーションを開発するための開発ツールも不足しています。 データベースと効果的に連携する、便利で使いやすく保守しやすい情報システムを構築するための妥協案は、インターネット/イントラネット テクノロジとマルチレベル アーキテクチャの組み合わせでした。 この場合、情報アプリケーションの構造は、ブラウザ – アプリケーション サーバー – データベース サーバー – ダイナミック ページ サーバー – Web サーバーという形式になります。

インターネット/イントラネット テクノロジとクライアント/サーバー アーキテクチャの統合により、企業情報システムの実装と保守のプロセスが大幅に簡素化され、同時に非常に高い効率と情報共有の容易さが維持されます。

結論:JSC NESK-ELECTROSETI の修理サービスの修理スタッフの空き状況を監視するための情報システムの設計の問題を解決するには、このシステムは少量のデータを処理するため、マルチレベル アーキテクチャに基づくインターネット/イントラネット技術が適しています。また、クライアント側でそれを使用するための追加ソフトウェアがあってはなりません。

JSC NESK-ELECTROSETI の修理サービスの修理チームの空き状況を監視するための情報システムのアーキテクチャを図 3.1 に示します。

図 3.1 – システムアーキテクチャ

システムアーキテクチャについて説明します。 リレーショナル データベースは、永続的なデータ ストレージとして使用されます。 データのみが一連のリレーショナル エンティティ (関連テーブル) の形式でデータベースに配置され、プログラマブル ロジックの要素 (トリガー、ストアド プロシージャ、ビューなど) は含まれません。 システムは、特定の機能要件を満たすサーバーを使用する場合があります。

アプリケーション サーバーは、たとえば Java で実行され、Java サーブレット標準を実装するランタイム環境のコンテキストで実行できる WEB アプリケーションとして実装されます。 送信されたコンテンツをキャッシュしたり、仮想ホスト、SSL などの追加機能を実装したりして、アプリケーション サーバーの負荷を軽減するには、次のいずれかをアプリケーション サーバーの前にインストールできます。 一般的な Web サーバー: Apache、nginx、MS IIS。

アプリケーションはモジュラー アーキテクチャを採用しています。システムの機能は、互いに独立して動作し、共通のサービス バスを通じて対話する複数のモジュールに集中しています。

IS の効率は、そのアーキテクチャに大きく依存します。

IPアーキテクチャ– 情報システムのモデル、構造、実行される機能、およびコンポーネントの相互接続を定義する概念。

簡単に言うと、 ICアーキテクチャ– どれを決定するかを決定する抽象的な概念 コンポーネントアプリケーションは (要素、コンポーネント) で構成され、これらの部分がどのように相互作用するか。 アプリケーション コンポーネントは通常、個別の比較的分離されたタスクを実行するプログラムまたはソフトウェア モジュールを指します。

プログラミングインターフェースまたはAPI(アプリケーション プログラミング インターフェイス) は、アプリケーションのコンポーネントが対話する方法を定義します。 ソフトウェアインターフェースさまざまな性質 (タイプ) があります: エクスポートされた DLL 関数、パッケージ/アセンブリのパブリック クラス、COM、EJB、CORBA、SOAP など。 特定のタスク、統一化と標準化の傾向があります。

AIS には、さまざまなサブタスクを解決することを目的とした 3 つの機能グループが含まれています (図 1.1)。

1. データ入力および表示機能 (ユーザー対話を提供)。

2. 特定の主題領域に固有の機能を適用します。

3. リソース管理機能（ファイルシステム、データベースなど）。

これらの機能のパフォーマンスは主に保証されます ソフトウェア、相互接続されたコンポーネントとして表すことができます (図 1.1.)。

図 1.1 - ネットワーク アプリケーションのコンポーネント

ユーザーインターフェース (プレゼンテーション サービス (PS) データ プレゼンテーション ツール、プレゼンテーション ロジック (PL) プレゼンテーション ロジック ) – データの表示と編集、およびデータとアプリケーション全体の管理 (ボタンを押す、マウスを動かす、画像を描画する、検索結果を表示するなど) を提供します。

ビジネスロジック(アプリケーション ロジック ビジネス ロジックまたはアプリケーション ロジック (BL)、ロジック データロジック (DL)) – ユーザーのアクションや内部イベントに対するアプリケーションの応答のためのルール、アルゴリズム、データ処理ルール。

データ管理(Data Services (DS) データベース管理ツール、File Services (FS) ファイル管理ツール) – 以下が含まれます。

データを送受信するメカニズムは、データ ソースへの接続を (多くの場合間接的に) 提供します。 双方向のデータ フローを確保するには、どこに行くべきか、どの通信プロトコルを使用するかを「認識」する必要があります。

バックエンド エンジンはデータベース アプリケーションの中核であり、取得したデータをアプリケーション内に保存し、アプリケーションの他の部分から要求されたときに利用できるようにします。

自律システム (ネットワークに接続されていないコンピューター) は、さまざまなレベル (OS、ユーティリティ ソフトウェアとユーティリティ、アプリケーション ソフトウェア) とアプリケーション レベル (最近のプログラムでは一般的ではありません) の両方で、これらすべてのコンポーネントを表します。 ネットワークは同じです。ネットワークはこれらすべてのコンポーネントを表しますが、一般にノード間に分散されます。 課題は結局のところ、 ネットワーキングこれらのコンポーネントの間。

AIS アーキテクチャは、ネットワーク アプリケーションの層間のコンポーネントの分散を決定します。

現時点では有望です クライアントサーバーアーキテクチャ.

サーバ特定のリソース コンピュータネットワークこのリソースを管理するコンピュータ (プログラム) と呼ばれる、 クライアント- このリソースを使用するコンピュータ (プログラム)。 コンピュータ ネットワーク リソースには、たとえば、データベース、ファイル システム、印刷サービス、 郵便サービス。 サーバーのタイプは、管理するリソースのタイプによって決まります。 たとえば、管理対象リソースがデータベースの場合、対応するサーバー データベースサーバーと呼ばれる.

このようなアーキテクチャの実際の実装は次のように呼ばれます。 クライアントサーバーテクノロジー。 各テクノロジーは、独自のルールを定義するか、クライアントとサーバー間の対話のための既存のルールを使用します。これらのルールは、 交換プロトコル (対話プロトコル).

クライアントサーバーテクノロジーは、マルチユーザー データベース内の処理機能を複数のコンピューターに分散することを含むコンピューティング モデルです。 コンピュータ間の処理機能の分散はプロトコルを利用して行われます。 サービスリクエスト、つまり 1 台の「クライアント」コンピュータが別の「サーバー」コンピュータにサービスを要求し、サーバーがサービスを実装してその結果を「クライアント」に送信します。

下 自動情報システム(AIS) は、意思決定プロセス、設計、生産、販売の最新の管理をリアルタイムで提供する、マルチコンポーネント情報システムを実装するハードウェアおよびソフトウェア ツールの複合体を理解しています。 トランザクション処理データ。

取引実行を中断できない一連のデータベース操作です。 トランザクションに含まれる操作の実行中にデータベースに加えられた変更をデータベースに記録するには、すべての操作が正常に完了する必要があります。 DBMS に対するこのような影響の結果、DBMS はある統合状態から別の統合状態に移行します。

尊厳クライアント/サーバー アーキテクチャに基づく AIS 組織は、一元化されたストレージ、メンテナンス、共通アクセスへの集合的アクセスをうまく組み合わせたものです。 企業情報個人情報に関するユーザーの個別の作業。 クライアント/サーバー アーキテクチャでは、さまざまな実装オプションが可能です。

最新のネットワーク上に構築されたあらゆるネットワーク (ピアツーピアでも) ネットワーク技術、クライアントとサーバーの相互作用の要素があり、ほとんどの場合、それに基づいています。 2層アーキテクチャ。 分散する必要があるため、2層（2層、2層）と呼ばれます。 三つ基本的な コンポーネント間 2つのノード(クライアントとサーバー)。

2 層アーキテクチャはクライアントサーバー システムで使用され、サーバーはクライアントの要求に直接応答し、 完全に独自のリソースのみを使用しながら。 それらの。 サーバーは、リクエストのどの部分も完了するためにサードパーティのネットワーク アプリケーションを呼び出したり、サードパーティのリソースにアクセスしたりしません (図 1.2)。

図 1.2 – 2 層クライアント/サーバー アーキテクチャ

クライアント側またはサーバー側のコンポーネントの場所によって、2 層アーキテクチャ内での相互作用の次の基本モデルが決まります。

- ターミナルサーバー- 分散データのプレゼンテーション。

- ファイルサーバー- リモートデータベースおよびファイルリソースへのアクセス。

- データベースサーバー- リモートデータプレゼンテーション;

- アプリケーションサーバー- リモートアプリケーション。

リストされたモデルとバリエーションを図 1.3 に示します。

歴史的には、分散データ プレゼンテーション モデル (ターミナル サーバー モデル) が最初に登場しました。 これは、サーバーとして機能する汎用コンピューター (メインフレーム) 上に実装され、英数字端末が接続されていました。 ユーザーは端末のキーボードからデータを入力し、そのデータはメインフレームに転送されて、結果の「画像」の形成を含めてそこで処理されました。 この「写真」は端末画面上でユーザーに返されました。

図 1.3 - クライアントとサーバーの対話のモデル

図1.2。 集中型データベース (図 1.2 - a) と集中型 DBMS (図 1.2 - b) を備えたターミナル サーバーのモデルが示されています。

図 1.4 - 分散データプレゼンテーションのモデル (ターミナルサーバーモデル)

利点:

ユーザーは高価なコンピュータ リソースを共有し、 周辺機器;

リソースと機器を一元化することで、コンピューティング システムの保守と運用が容易になります。

ユーザーのワークステーション (端末ステーション) を管理する必要はありません。

主な欠点:

ユーザーはメインフレーム管理者に完全に依存しています。

パーソナルコンピュータの出現により、 ローカルネットワーク、モデルが実装されました ファイルサーバー、リモート データベースを含むファイル リソースへのアクセスを提供します (図 1.5)。 このような情報システムでは、ユーザーの要求に基づいてデータベース ファイルがパーソナル コンピュータ (PC) に転送され、そこで処理されます。 別のネットワーク ノードは、データベース ファイルが配置されるファイル サーバーです。 クライアントは、プレゼンテーション コンポーネント ( ユーザーインターフェース ) およびアプリケーションコンポーネント ( ビジネスロジック) (DBMS と アプリケーションプログラム)、接続されたリモート データベースをローカル ファイルとして使用します。 Exchange プロトコルは一連の低レベルの操作呼び出しを表します ファイルシステム. 短所このアーキテクチャ オプションは、処理されたデータの転送強度が高いことを特徴としています。 さらに、冗長データが転送されることもよくあります。ユーザーが必要とするデータベースのレコードの数に関係なく、データベース ファイル全体が転送されます。

図 1.5 - ファイルサーバーを備えた AIS の構造

利点:

データを操作するためのマルチユーザー モード。

集中アクセス制御の利便性。

開発コストが低い。

高速発達;

ソフトウェアの更新と変更のコストが低い。

欠点:

マルチユーザーによるデータ作業の問題。

パフォーマンスが悪い;

新しいクライアントを接続する能力が低い。

システムの信頼性が低い。

分布 機能部品 V ファイルサーバーのアーキテクチャ図 1.6 に示します。

欠点からわかるように、このようなモデルは、次のような理由により非効率であることが示されています。 活発な仕事データベーステーブルを使用すると、ネットワークに大きな負荷がかかります。 部分的な解決策は、テーブルとクエリのレプリケーションをサポートすることです。 この場合、たとえば、データが変更されたときに、テーブル全体が更新されるのではなく、その変更された部分のみが更新されます。

特殊な DBMS の出現により、リモート データベースへの別のアクセス モデルを実装できるようになりました。 データベースサーバーモデル。 この場合、DBMS カーネルはサーバー上で動作し、アプリケーション プログラムはクライアント上で動作し、交換プロトコルは以下を使用して提供されます。 SQL言語.

図 1.6 - ファイル サーバー アーキテクチャにおける機能コンポーネントの分散

図 1.7 – データの複製

このアプローチは、ファイル サーバーと比較して、ネットワーク負荷の軽減とクライアント/サーバー インターフェイスの統合につながります。 で クライアントサーバーアーキテクチャを使用して データベースサーバー大量のデータ処理がサーバー上で実行されるようにします。 ユーザーまたはアプリケーションによって生成されたクエリは、SQL ステートメントの形式でデータベース サーバーに送信されます。 データベース サーバーは必要なデータを検索して取得し、ユーザーのコンピュータに転送します。

しかし、ネットワーク トラフィックは依然として非常に多く、さまざまな機能が 1 つのプログラムに組み合わされているため、アプリケーションを満足に管理することは依然として不可能です。

データベース サーバーを備えたクライアント/サーバー アーキテクチャを図 1.8 に示します。

図 1.8 - データベース サーバーを備えた AIS の構造

クライアント/サーバー アーキテクチャにおける機能コンポーネントの分布 (図 1.9) は次のとおりです。クライアント ワークステーションには、DBMS にアクセスするためのユーザー インターフェイスとオペレーターがあります。 ファイル サーバーにはデータベースが保存され、これを実装するストアド プロシージャが含まれています。 サーバー部分ビジネス ロジック、リクエストが実行され、トランザクションが処理されます。

データベース サーバー レベルでのストアド プロシージャ メカニズムの開発と実装により、 アクティブなサーバー DB。 この場合、アプリケーション コンポーネントの機能の一部は、サーバー側で実行されるストアド プロシージャの形式で実装されます。 アプリケーション ロジックの残りの部分はクライアント側で実行されます。 対話プロトコルは、SQL 言語の対応する方言です。

利点:

コンピューティング システムの機能を複数の独立したコンピューター間で分散する機能。

すべてのデータは安全なサーバーに保存されます。

アプリケーション機能の集中管理が可能。

マルチユーザー作業のサポート。

データの完全性の保証。

大幅な削減 ネットワークトラフィック(送信されるのは SQL クエリではなく、ストアド プロシージャの呼び出しであるため)。

欠点:

サーバーに障害が発生すると、コンピュータ ネットワーク全体が動作不能になる可能性があります。

複雑な管理。

高コスト装置;

アプリケーションのビジネス ロジックの一部はクライアント ソフトウェアに残りました。

高級言語と比較したストアド プロシージャ開発ツールの制限。

図 1.9 - クライアント/サーバー アーキテクチャにおける機能コンポーネントの分散

サーバー側のアプリケーションコンポーネントの実装は、次のモデルを表します- アプリケーションサーバー。 アプリケーション コンポーネントの機能をサーバーに移行すると、クライアントの構成要件が軽減され、管理が簡素化されますが、サーバーのパフォーマンス、セキュリティ、および信頼性に対する要求が高まります。

もう一つの傾向は、 クライアントサーバーテクノロジー使用量の増加に伴う 分散コンピューティング。 それらは以下に基づいて実装されています。 アプリケーションサーバーモデル、 どこ ネットワークアプリケーション 2 つ以上の部分に分かれており、それぞれの部分で実行できます。 別のコンピューター。 アプリケーションの専用部分は相互に通信し、事前に合意された形式でメッセージを交換します。 この場合、2 層のクライアント/サーバー アーキテクチャは次のようになります。 三段（三段、三段）.

通常、3 層アーキテクチャの 3 番目のリンクはアプリケーション サーバーです。 コンポーネントは次のように分散されます (図 1.10)。

1. データ プレゼンテーション (ユーザー インターフェイス) – クライアント側。

2. アプリケーション コンポーネント (ビジネス ロジック) – 専用のアプリケーション サーバー上。

3. リソース管理 (データ管理) – 要求されたデータを提供するデータベース サーバー上で。

図 1.10 - マルチレベルのクライアント/サーバー アーキテクチャ

利点:

クライアント ソフトウェアは管理を必要としません。

スケーラビリティ。

構成可能性。

高い安全性と信頼性。

端末とアプリケーションサーバー間のチャネル速度の要件が低い。

パフォーマンス要件が低く、 技術仕様端子。

しかし、これに伴い次のようなデメリットもあります。

管理とメンテナンスの複雑さ。

アプリケーション作成の複雑さ。

アプリケーションサーバーとデータベースサーバーの高いパフォーマンス要件。

データベース サーバーとアプリケーション サーバー間のチャネル (ネットワーク) 速度に対する高い要件。

マルチレベルのクライアント/サーバー アーキテクチャにおける機能コンポーネントの分散を図 1.11 に示します。

図 1.11 - マルチレベルのクライアント/サーバー アーキテクチャにおける機能コンポーネントの分散

Web ベースの情報システムのアーキテクチャを図 1.12 に示します。

図 1.12 - Web システムのアーキテクチャ

利点:

追加のソフトウェアを使用する必要はありません

クライアント - これにより、クライアント部分をすべてのクライアントに自動的に実装できます。

プラットフォーム;

接続は仮想的に 数量無制限

クライアント;

単一のデータ保管場所とシステム可用性のおかげで

データベース管理では、次の最小要件が提供されます。

データの整合性を維持する。

サーバーと通信チャネルが動作しているときの可用性。

欠点:

サーバーまたは通信チャネルが動作していない場合は利用できません。

Web サーバーとデータ伝送チャネルの速度が非常に遅い。

データ量に関しては、Web システムのアーキテクチャにはありません。

重大な制限。

Web ベースの情報システムのアーキテクチャにおける機能コンポーネントの分布を図 1.13 に示します。

図 1.13 - Web ベースの情報システムのアーキテクチャにおける機能コンポーネントの分布

要約すると、2 層アーキテクチャはすべてのリクエストが 1 つのサーバーによって処理されるためシンプルであると結論付けることができますが、まさにそのため、信頼性が低くなり、サーバーのパフォーマンスに対する要求が高くなります。

3 層アーキテクチャはより複雑ですが、機能が 2 番目と 3 番目のレベルのサーバーに分散されているため、このアーキテクチャは次のことを表します。

1. 高い柔軟性と拡張性。

2. 高いセキュリティ（サービスまたはレベルごとに保護を定義できるため）。

3. 高性能(タスクがサーバー間で分散されるため)。

今日、産業企業は、コンピュータ ネットワークと、企業データベース (CBD) や個人データベース (PDD) などの分散データベースの存在を前提としています。 CBD はサーバー コンピュータ上にあり、PDB は企業データベースのクライアントである部門従業員のコンピュータ上にあります。

個人データベースとそれと連動するアプリケーションを作成および管理するには、Microsoft の Access や Visual FoxPro、Borland の Paradox などの DBMS が使用されます。

企業データベースは、Microsoft SQL Server や Oracle Server などのデータベース サーバーの制御下で作成、維持、運用されます。

組織の規模と解決されるタスクの特性に応じて、情報システムは次のいずれかの構成になります。

企業および個人のデータベースを含むコンピュータ サーバー。

PDB を備えたサーバー コンピュータおよびパーソナル コンピュータ。

PDB を備えた数台のサーバー コンピューターとパーソナル コンピューター。

共通データベースを企業データベースと個人データベースに分割すると、集中型オプションと比較してデータベース設計の複雑さが軽減され、設計エラーの可能性や設計コストが削減されます。

産業用自動情報システム開発の現段階では、データベースに対して次の要件が提示されています。

マルチユーザーデータアクセスの一元管理。

データの冗長性を削減します。

データ表示における標準の確保と実装。

データの整合性とセキュリティを確保する。

データの独立性。

コンピュータネットワークにおける分散データ処理。

IS アーキテクチャは、モデル、実行される機能、およびそのコンポーネントの関係を定義する構造の概​​念的な記述であり、3 つのコンポーネントの存在を規定します。

1. 情報技術。 2. 機能サブシステム。 3. 情報システム管理。

アーキテクチャの種類:

1. ファイル サーバー – ファイル I/O 操作を実行するために最適化され、あらゆる種類のファイルを保存するように設計された専用サーバー。

2. クライアント/サーバー – アプリケーションがクライアント プロセスとサーバー プロセスに分割される分散コンピューティング システムのアーキテクチャ。

3. マルチレベル - ネットワークとシステム ノードの負荷のバランスをとり、管理を簡素化します。

4. インターネット/イントラネット – インターネット/イントラネット テクノロジーとマルチレベル アーキテクチャの包括的な組み合わせ。 ツールデータベースと連動するアプリケーションを開発するための高度なツールによって補完されます。

5. 5. 基本的な IS 標準: MRP、MRP II、ERP、ERP II など。

MRP基準生産プロセスを確保するために必要な資材の計画を規制します。 MRPシステムは次のことを示す必要があります。

1. 量産スケジュール（MPS）

2. MRP のソフトウェア実装により、決定が可能になります。 材料要件。

3. 材料供給スケジュール、発注スケジュール、生産供給プロセスを管理するためのレポート。

MRP の目標は、倉庫内の原材料と最終製品の在庫を最小限に抑え、生産への材料のタイムリーな受け入れを最適化することです。

MRP の欠点: 調達計画の実施を制御できないこと、および生産要素の会計処理に制限があること。

標準 MRPⅡすべての企業リソースの効果的な計画を確実にします。 機能: 予測、販売管理、数量カレンダー計画、製品構成管理、在庫管理、部門管理、購買、財務、財務管理。 会計の分析と保守。

交換するには MRP、MRPⅡ来た ERPシステム。 標準 ERP組織活動のすべての主要なプロセスを単一のシステムでカバーする包括的な管理情報システムについて説明します。 情報空間。 短所: 企業の内部活動が自動化されます。 システム ERP II –バックオフィスとフロントオフィスを自動化し、企業の企業システムという 1 つの全体を表します。

コンセプト ERPⅡ: 1. 取引相手との自由な企業を確保する。 2. あらゆるセクターおよび市場セグメントの企業をターゲットにします。 3. すべてのビジネス機能の自動化のサポート。 4. 企業データは、ビジネスコミュニティのすべてのメンバーが利用できます。 5. システムは Web ベースのアプリケーションになります。