統一された企業データウェアハウスの作成。エンタープライズデータモデルに基づいてデータウェアハウスモデルを作成します。業界データモデル

Zaitsev S.L.、Ph.D。

繰り返しグループ

繰り返しグループは、単一のエンティティインスタンスが複数の値を持つことができる属性です。たとえば、人は複数のスキルを持っている場合があります。ビジネス要件の観点から、すべての人のスキルレベルを知る必要があり、各人が2つのスキルしか持てない場合は、図に示すエンティティを作成できます。 1.6。これが実体です人それぞれのスキルとスキルレベルを保存するための2つの属性があります。

米。 1.6。この例では、繰り返しグループを使用しています。

グループを繰り返すことの問題は、人がどれだけのスキルを持っているかを正確に知ることができないことです。実生活では、1つのスキルを持っている人もいれば、いくつか持っている人もいれば、まだ持っていない人もいます。図1.7は、モデルを第一正規形に縮小したものを示しています。追加されたことに注意してください スキルID 、それぞれを一意に定義します スキル。

米。 1.7。モデルは第一正規形に縮小されました。

1つの場所に1つの事実

同じ属性が複数のエンティティに存在し、外部キーではない場合、その属性は冗長であると見なされます。論理モデルに冗長データを含めることはできません。

冗長性には追加のスペースが必要ですが、メモリ効率は重要ですが、本当の問題は他の場所にあります。冗長データの同期の保証にはオーバーヘッドが伴い、値が競合するリスクが常にあります。

前の例では スキルに依存します 個人IDとから スキルID。これはあなたが持っていないことを意味します スキル表示されるまで人、このスキルを持っています。また、スキル名の変更が難しくなります。各スキル名のエントリを見つけて、そのスキルを所有する人ごとに変更する必要があります。

図1.8は、第2正規形のモデルを示しています。エンティティが追加されていることに注意してください スキル、および属性 タイトルこのエンティティにスキルが転送されました。スキルレベルはそれぞれ交差点に残った 人とスキル。

米。 1.8。 2番目の正規形では、繰り返しグループは別のエンティティに移動されます。これにより、必要な数のスキルを追加し、スキル名またはスキルの説明を1か所で変更できる柔軟性が得られます。

各属性はキーに依存します

エンティティの各属性は、そのエンティティの主キーに依存する必要があります。前の例では 学校名と 地理的領域テーブルに存在する人しかし、人については説明しないでください。 3番目の正規形を実現するには、属性をエンティティに移動する必要があります。エンティティでは、属性はキーに依存します。図1.9。は、モデルを第3正規形で示しています。

米。 1.9。第3正規形 学校名と 地理的領域エンティティに移動しました。エンティティの値はキーによって異なります。

多対多の関係

関係 多対多環境の現実を反映します。図1.9では、間に多対多の関係があることに注意してください人と学校。この比率は、次の事実を正確に反映しています。人多くで勉強することができます学校とで学校たくさん学ぶことができます人。第4正規形を実現するために、学校と人の固有の組み合わせごとに個別のエントリを生成することにより、単数対多の関係を排除する連想エンティティが作成されます。図1.10は、第4正規形のモデルを示しています。

米。 1.10。第4正規形では、人と学校連想エンティティを導入することで解決されました。このエンティティでは、一意の組み合わせごとに個別のエントリが割り当てられます。学校と人。

正規形の正式な定義

以下の正規形の定義は、威圧的に見えるかもしれません。それらを単に正規化を達成するための公式と考えてください。正規形は関係代数に基づいており、数学的変換として解釈できます。この本は正規形の詳細な議論をカバーしていませんが、モデラーは主題をより深く掘り下げることが奨励されています。

与えられた関係Rにおいて、属性Yは属性Xに機能的に依存します。象徴的に、Rの各X値がRの1つのY値に関連付けられている場合に限り、RX-> RY（「RXは機能的にRYを定義する」と読みます）。いつでも）。属性XとYは複合することができます（日付K.J.データベースシステムの概要。第6版。Ed.Williams：1999、848 pp。）。

リレーションRは、そのすべてのドメインにアトミック値のみが含まれている場合にのみ、第一正規形（1NF）になります（日付、同上）。

関係Rは、それが1NFにあり、すべての非キー属性が主キーに完全に依存している場合にのみ、第2正規形（2NF）になります（日付、同上）。

関係Rは、それが2NFにあり、すべての非キー属性が主キーに一時的に依存していない場合にのみ、第3正規形（3NF）になります（日付、同上）。

関係Rは、各行列式がキーとして使用する候補である場合にのみ、ボイス-コッド正規形（BCNF）に準拠します。

ノート 以下は、Dateの定義で使用されているいくつかの略語の簡単な説明です。

MVD（多値従属性）-多値従属性。 3つ以上の属性を持つエンティティにのみ使用されます。多値従属性では、属性の値は主キーの一部のみに依存します。

FD（機能依存性）-機能依存性。 関数従属性では、属性の値は、主キーの一部ではない別の属性の値に依存します。

JD（結合依存関係）-結合依存関係。 結合の依存関係では、親エンティティの主キーは、元のキー結合で使用できる機能を保持しながら、少なくとも3番目のレベルの子孫まで追跡できます。

A®®BなどのMVDがRにある場合に限り、関係は第4正規形（4NF）になります。この場合、Rのすべての属性はAに機能的に依存しています。つまり、Rには、K®X形式の依存関係（FDまたはMVD）のみがあります（つまり、使用する候補に対する属性Xの機能依存性）。キーとしてK）。したがって、RがBCNFに準拠し、すべてのMVDが実際にFDである場合、Rは4NFの要件を満たします（日付、同上）。

5番目の正規形の場合、関係Rは、RがX、Y、...、Zへの射影と同等である場合に限り、和集合関係（JD）*（X、Y、…、Z）を満たします。 Y、。..、属性セットRのZサブセット。

複雑なデータ型や特定の状況には、他にも多くの正規形があり、ここでの説明の範囲を超えています。モデル開発のすべての愛好家は、他の正規形を探求したいと考えています。

ビジネス正規形

彼の著書CliveFinklestein（Finklestein Cl。情報工学入門：戦略的計画から情報システムまで。マサチューセッツ州レディング：Addison-Wesley、1989）は、正規化に対して異なるアプローチを採用しました。これは、ビジネスの正規形をそれらの形式への縮小という観点から定義します。多くのモデラーは、このアプローチがより直感的で実用的であると感じています。

First Business Normal Form（1BNF）は、繰り返しグループを別のエンティティにマップします。このエンティティは、元のエンティティとその繰り返しグループから独自の名前とプライマリ（複合）キー属性を取得します。

Second Business Normal Form（2BNF）は、主キーに部分的に依存する属性を別のエンティティにマップします。このエンティティの主（複合）キーは、属性が完全に依存している追加のキーとともに、元々存在していたエンティティの主キーです。

3番目のビジネス正規形（3BNF）は、主キーに依存しない属性を別のエンティティにマップします。この属性は、そのエンティティの主キーに完全に依存しています。

4番目のビジネス正規形（4BNF）は、主キーの値に依存する属性、または主キーの値に完全に依存する属性、またはそのエンティティに存在する必要がある（必須）属性をマップします。。

5番目のビジネス正規形（5BNF）は、セカンダリエンティティのインスタンス間に再帰的またはその他の依存関係がある場合、またはプライマリエンティティのインスタンス間に再帰的な依存関係が存在する場合、構造エンティティとして表示されます。

完成した論理データモデル

完成した論理モデルは、3番目のビジネス通常形式の要件を満たし、データ要件とデータに関連付けられたビジネスルールをサポートするために必要なすべてのエンティティ、属性、および関係を含む必要があります。

すべてのエンティティには、コンテンツを説明する名前と、明確で簡潔な完全な説明または定義が必要です。以下の出版物の1つでは、エンティティの名前と説明を正しく形成するための最初の一連の推奨事項が検討されます。

関係には、複数、存在の必要性、関係が存在しない可能性などの特性とともに、エンティティ間の関係を説明する動詞構文を含める必要があります。

ノート 複数性 リレーションシップは、元のエンティティのインスタンスに関連付けることができるセカンダリエンティティインスタンスの最大数を表します。存在の必要性 また欠席の可能性 関係は、元のエンティティのインスタンスに関連付けることができるセカンダリエンティティのインスタンスの最小数を定義するために使用されます。

物理データモデル

完全で適切な論理モデルを作成したら、実装プラットフォームの選択を決定する準備が整います。プラットフォームの選択は、データ使用の要件と組織のアーキテクチャの戦略的原則によって異なります。プラットフォームの選択は、この本の範囲を超えた複雑な問題です。

ERwinでは、物理モデルは実際のデータベースをグラフィカルに表現したものです。物理データベースは、テーブル、列、および関係で構成されます。物理モデルは、実装用に選択されたプラットフォームとデータ使用要件によって異なります。 IMSの物理モデルは、Sybaseの同じモデルとは大きく異なります。 OLAPレポートの物理モデルは、OLTP（オンライントランザクション処理）のモデルとは異なって見えます。

データモデラーとデータベース管理者（DBA）は、論理モデル、使用要件、および企業アーキテクチャの戦略的原則を使用して、物理データモデルを開発します。物理モデルを非正規化してパフォーマンスを向上させ、使用要件をサポートするビューを作成できます。次のセクションでは、非正規化とビューの作成のプロセスについて詳しく説明します。

このセクションでは、物理モデルを構築し、データを使用するための要件を収集し、物理モデルとリバースエンジニアリングのコンポーネントを定義するプロセスの概要を説明します。これらの問題については、今後の出版物で詳しく説明する予定です。

データ使用要件の収集

通常、インタビューや作業セッションの早い段階でデータ使用要件を収集します。同時に、要件では、ユーザーによるデータの使用を可能な限り完全に定義する必要があります。物理モデルの表面的な態度とギャップは、計画外のコストとプロジェクトの実装の遅延につながる可能性があります。使用要件は次のとおりです。

アクセスとパフォーマンスの要件

管理者がデータベースの物理ボリュームを表すことができるボリューム特性（保存されるデータ量の見積もり）

許容可能なレベルのパフォーマンスのためにデータベースを設計するのに役立つ、データへの同時アクセスを必要とするユーザーの数の見積もり

要約、要約、および耐久性のあるデータ構造でのストレージの候補と見なされる可能性のあるその他の計算または派生データ

データベース管理者がインデックスを作成するのに役立つレポートと標準クエリを生成するための要件

ユーザーがデータのマージまたはフィルタリング操作を実行するのを支援するビュー（永続的または仮想）。

議長、秘書、およびユーザーに加えて、使用要件セッションには、モデラー、データベース管理者、およびデータベースアーキテクトを含める必要があります。履歴データのユーザー要件について話し合う必要があります。データが保存される時間の長さは、データベースのサイズに大きな影響を与えます。多くの場合、古いデータは集約された形式で保存され、アトミックデータはアーカイブまたは削除されます。

ユーザーは、サンプルのクエリとレポートをセッションに持ち込む必要があります。レポートは厳密に定義する必要があり、サマリーフィールドとサマリーフィールドに使用されるアトミック値を含める必要があります。

物理データモデルのコンポーネント

物理データモデルのコンポーネントは、テーブル、列、および関係です。論理モデルのエンティティは、物理モデルのテーブルになる可能性があります。ブール属性は列になります。論理的な関係は、関係の整合性に対する制約になります。一部の論理関係は、物理データベースに実装できません。

リバースエンジニアリング

論理モデルが利用できない場合は、既存のデータベースからモデルを再作成する必要があります。 ERwinでは、このプロセスはリバースエンジニアリングと呼ばれています。リバースエンジニアリングは、いくつかの方法で実行できます。モデラーは、データベース内のデータ構造を調べて、ビジュアルモデリング環境でテーブルを再作成できます。データ定義言語（DDL）を、リバースエンジニアリングをサポートするツール（Erwinなど）にインポートできます。 ERwinなどの高度なツールには、既存のデータベースとのODBC通信を提供し、データ構造を直接読み取ることによってモデルを作成する機能が含まれています。 ERwinを使用したリバースエンジニアリングについては、今後の出版物で詳しく説明します。

企業の機能境界の使用

論理モデルを構築する場合、モデラーは新しいモデルがエンタープライズモデルと一致することを確認することが重要です。企業の機能境界を使用するということは、企業内で使用される用語でデータをモデル化することを意味します。企業でのデータの使用方法は、データ自体よりも急速に変化しています。各論理モデルでは、サポートするビジネスドメインに関係なく、データを全体的に表す必要があります。エンティティ、属性、および関係は、企業レベルでビジネスルールを定義する必要があります。

ノート 私の同僚の何人かは、これらの企業の機能境界を実際のモデリングと呼んでいます。実世界のモデリングは、モデラーが実際の関係と関係の観点から情報を表示することを奨励します。

適切に構築されたデータモデルに企業の機能境界を使用すると、任意の数のプロセスとアプリケーションの情報ニーズをサポートするフレームワークが提供され、企業は最も価値のある資産の1つである情報をより効果的に活用できます。

エンタープライズデータモデルとは何ですか？

エンタープライズデータモデル（EDM）企業の情報ニーズを表すエンティティ、属性、および関係が含まれています。 EDMは通常、特定のビジネスニーズのサポートに関連するエンティティのグループであるサブジェクトエリアに細分されます。一部のサブジェクト領域は、契約管理などの特定のビジネス機能をカバーする場合がありますが、他のサブジェクト領域は、製品またはサービスを説明するエンティティをグループ化する場合があります。

各論理モデルは、既存のエンタープライズデータモデルドメインに対応している必要があります。論理モデルがこの要件を満たしていない場合は、サブジェクト領域を定義するモデルを追加する必要があります。この比較により、企業モデルが改善または調整され、すべての論理モデリングの取り組みが企業内で調整されることが保証されます。

EDMキー属性の値の範囲を定義する特定のエンティティも含まれます。これらのエンティティには親がなく、独立していると定義されています。独立したエンティティは、関係の整合性を維持するためによく使用されます。これらのエンティティは、コードテーブル、参照テーブル、タイプテーブル、分類テーブルなど、いくつかの異なる名前で識別されます。「企業ビジネスオブジェクト」という用語を使用します。エンタープライズビジネスオブジェクトは、他のエンティティから独立している属性値のセットを含むエンティティです。企業内のエンタープライズビジネスオブジェクトは、一貫して使用する必要があります。

スケーリングによるエンタープライズデータモデルの構築

単一の協調努力の結果として、最初から最後まで企業モデルが構築された組織があります。一方、ほとんどの組織は、構築することによってかなり完全なエンタープライズモデルを構築します。

成長とは、カキが真珠を育てるのと同じように、層ごとに何かを積み上げることを意味します。作成された各データモデルは、EDMの形成への入力を提供します。この方法でEDMを構築するには、新しいデータ構造とドメインを追加したり、既存のデータ構造を拡張したりするための追加のモデリング手順が必要です。これにより、詳細レベルと改良を繰り返し追加して、エンタープライズデータモデルを構築できます。

モデリング方法論の概念

ビジュアルデータモデリングにはいくつかの方法論があります。 ERwinは2つをサポートします。

IDEF1X（情報モデリングの統合定義-情報モデルの統合された記述）。

IE（情報工学-情報工学）。

IDEF1Xは優れた方法論であり、その表記法は広く使用されています

情報モデルの統合された説明

IDEF1Xは、FIPS（連邦情報処理標準）標準として採用されているIDEF1手法を拡張した、高度に構造化されたデータモデリング手法です。 IDEF1Xは、高度に構造化されたモデリング構成タイプのセットを使用し、そのような情報を利用できるようにする前に、データの物理的性質を理解する必要があるデータモデルを作成します。

IDEF1Xの堅固な構造により、モデラーは、周囲の世界の現実に対応していない可能性のあるエンティティに特性を割り当てる必要があります。たとえば、IDEF1Xでは、すべてのエンティティサブタイプが排他的である必要があります。これは、人がクライアントと従業員の両方になることはできないという事実につながります。実際の練習ではそうではないと教えてくれますが。

情報工学

Clive Finklesteinは、情報工学の父と呼ばれることがよくありますが、James Martinは彼と同様の概念を共有していました（Martin、James。データベース環境の管理。ニュージャージー州アッパーサドルリバー：Prentice Hall、1983年）。情報エンジニアリングは、ビジネス主導のアプローチを使用して情報を管理し、異なる表記法を使用してビジネスルールを表します。 IEは、PeterChenによって提案されたER方法論の表記法と基本概念の拡張および開発として機能します。

IEは、企業の戦略的計画を開発中の情報システムと統合することにより、情報要件をサポートするインフラストラクチャを提供します。このような統合により、情報リソースの管理を企業の長期的な戦略的見通しとより密接に結び付けることが可能になります。このビジネス主導のアプローチにより、多くのモデラーは、主に当面の開発問題の解決に焦点を当てている他の方法論よりもIEを選択するようになります。

IEは、企業がデータを収集および管理し、情報オブジェクト間の関係を特定するために必要なすべての情報を特定するためのワークフローを提供します。その結果、情報要件は管理指令に基づいて明確になり、戦略的な情報ニーズをサポートする管理情報システムに直接変換できます。

結論

ERwinのようなデータモデリングツールの使用方法を理解することは、問題の一部にすぎません。さらに、データモデリングタスクがいつ実行されるか、およびデータモデルで表現するために情報要件とビジネスルールがどのように収集されるかを理解する必要があります。作業セッションを実施することは、対象分野の専門家、ユーザー、および情報技術の専門家を含む環境で情報要件を収集するための最も好ましい条件を提供します。

優れたデータモデルを構築するには、作業セッションやインタビュー中に収集された情報要件とビジネスルールの分析と調査が必要です。結果のデータモデルは、可能であればエンタープライズモデルと比較して、既存のオブジェクトモデルと競合せず、必要なすべてのオブジェクトが含まれていることを確認する必要があります。

データモデルは、情報要件とビジネスルールを表す論理モデルと物理モデルで構成されています。論理モデルは、第3正規形に縮小する必要があります。 3番目の正規形は、データ構造の異常を制限、追加、更新、および削除して、「1つの事実、1つの場所」の原則をサポートします。収集された情報要件とビジネスルールは、分析および調査する必要があります。それらをエンタープライズモデルと比較して、既存のオブジェクトモデルと競合しないこと、および必要なすべてのオブジェクトが含まれていることを確認する必要があります。

ERwinでは、データモデルには論理モデルと物理モデルの両方が含まれます。 ERwinはERアプローチを実装し、情報要件とビジネスルールを表す論理モデルオブジェクトと物理モデルオブジェクトを作成できるようにします。論理モデルオブジェクトには、エンティティ、属性、および関係が含まれます。物理モデルオブジェクトには、テーブル、列、および関係の整合性制約が含まれます。

次の出版物の1つでは、エンティティの識別、エンティティタイプの決定、エンティティの名前と説明の選択、およびエンティティの使用に関連する最も一般的なモデリングエラーを回避するためのいくつかのトリックについて検討します。

各エンティティに関するすべてのファクトをその属性で表すことができるように、エンティティには属性の完全なセットが必要です。各属性には、その値を反映する名前、ブールデータ型、および明確で短い完全な説明または定義が必要です。次の出版物の1つでは、名前と属性の説明を正しく形成するための最初の一連の推奨事項を検討します。関係には、複数、存在の必要性、関係が存在しない可能性などの特性とともに、エンティティ間の関係を説明する動詞構文を含める必要があります。

ノート 複数性 リレーションシップは、元のエンティティのインスタンスに関連付けることができるセカンダリエンティティインスタンスの最大数を表します。存在の必要性または不在の可能性 関係は、元のインスタンスに関連付けることができるセカンダリエンティティのインスタンスの最小数を決定するために使用されます

販売するには、何を販売しているのかを理解する必要があります。

用語と概念を定義しましょう。（（ データウェアハウス）は主要業績評価指標（KPI、KPI）のシステムではなく、これは大規模なデータベースではなく、分析ではありません OLAPツール、これは、新しいデータを抽出して統計的な依存関係を取得できるインテリジェントなシステムではありません。これは、単一の参照データのシステムではありません。単一のアイテムのコンテキストで説明する場合、これはデータウェアハウスではありません。

エンタープライズデータウェアハウス – これは、企業（組織）の特別に編成されたデータアレイであり、単一のハードウェアとソフトウェアの複合体で処理および保存され、運用および履歴情報、多次元データ分析（さまざまな測定のKPI）への迅速なアクセスを提供し、合意された規制参照情報（NSI）のコンテキスト。

企業のデータウェアハウスの潜在的な顧客と彼らは何を得るのですか？

データウェアハウスを必要とする潜在的な企業クライアントを特定するにはどうすればよいですか？

まず第一に、会社の日常の活動において多くの情報が生じるはずです。これには、電話、金融取引、顧客の苦情/レビュー、顧客の出荷要求、偵察衛星からの情報などがあります。原則として、何でも、主なことは、データがたくさんあるということです。
潜在的なクライアントは、この情報を見て分析したいという願望を持っている必要があります。同時に、分析期間は非常に広範囲である必要があります。1日または1時間から、数年の分析までです。
クライアントには、正常に機能しているインフラストラクチャが必要です（ツイストペアまたはUSBポートで接続されたサーバーがあってはなりません）。クライアントがインフラストラクチャを持っていない場合、彼はそれを販売する必要があります。

クライアントは、エンタープライズデータウェアハウスを実装することでどのようなメリットがありますか？

単一の参照情報を使用する、企業データ用の統合情報ストレージシステムが登場します。
ビジネスの包括的な分析を行う機会があります。例：どのクライアントが最も収益性が高く、収益性が高いか。どのサービス、どのクライアントが最も需要が高いか、どのような種類のクレームが最も頻繁に発生し、どの地域で発生するかなど。
履歴データを利用した分析が可能になります。多くの場合、運用（日常のビジネスプロセスの自動化）システムではこれが許可されておらず、履歴を保存するための十分なスペースと分析を実行する能力がありません。
以前に異なる情報システムに保存されていた情報を接続して分析することが可能になります。たとえば、さまざまな支店の交通データは、さまざまな開発者の課金システムに保存されます。データウェアハウスの実装後、単一のレポートでそれらを一緒に分析することが可能になります。
さまざまな種類のデータを分析して交差させることが可能になります。たとえば、お金とトラフィック、スタッフの数、拒否または請求の数などです。
サービスのコストをより適切に計算するための基礎があります。企業のデータウェアハウスからの情報に基づいて、自然分布ベースのより適切なデータを取得することが可能です。

企業のデータウェアハウスとは

企業のデータウェアハウスは、技術的な観点からどのコンポーネントを構築していますか？

コンポーネント 企業データウェアハウス 企業

クライアントには常にオペレーティングシステムがあります- データソース企業データウェアハウス用。 これらは、たとえば、会計、請求、銀行などです。システム。
使用する ETLアプリケーション（データの抽出、変換、およびロードを可能にするソフトウェア）、ソースシステムからのデータはデータウェアハウスデータベースに入ります。 ETLツールとして使用できるのは、Informatica Power Center、IBM DataStage、Oracle Data Integrator、Oracle WareHouseBuilderです。他のベンダーの製品もありますが、ロシア市場にはほとんど出回っていません。
自体 データベース企業ストレージは、その構造（テーブルのセット、テーブル内のフィールド、およびテーブル間の関係）が抽象的ではなく、に基づいて作成されます。 データモデル. 大多数のデータベースは、OracleまたはTeradataのいずれかを使用します。
データ・モデル企業データウェアハウスのすべてのエンティティ、データベースオブジェクトの説明であり、次のものが含まれます。概念データモデル、論理データモデル、および物理 データベースモデル 。概念モデルレベルでは、エンティティとそれらの間の関係が定義されます。論理モデルのレベルでは、エンティティはビジネスエリアに分割され、詳細で完全な説明が与えられ、関係が規定されます。物理データベースモデルを開発する場合、データベース構造全体が決定されます。テーブルやフィールドから、パーティションやインデックスまでです。 データモデルIBM、SAP、およびOracleは今日市場に供給していますが、データモデルを購入することは、適切なエンタープライズストアを自動的に構築することを意味するわけではありません。データ・モデルこれは箱入りの製品ではありません。特定のクライアントのニーズに合わせて変更する必要があります。
さらに、すでに企業データウェアハウスからのデータを使用して、分析、レポート、および データマート。その後、ユーザーは必要なレポートを独自に作成し、多変量解析を実行できます。 Business Objects、Oracle Discoverer、IBM AlphaBlocks、およびその他の製品は、主に分析ツールとして使用されます。

エンタープライズデータウェアハウスのコンポーネントはどのように見えるか（データモデル、ETLプロセス、データマート）

データモデル、ETLプロセスの実装、単一の参照データのサポート形式、データマートの例を示しましょう。

ロジックモデルデータ。
エンティティ、それらの属性、およびそれらの間の関係を定義します。

ETLプロセスソースデータの重複の排除

単一ディレクトリを形成するためのデータ入力フォーム

データ市場表形式のレポートの形式で

データ市場グラフィックと色で
与えられた条件に従ってデータを出力する

データ市場スケジュール付き

1.リレーショナルデータモデル

1.1リレーショナルデータモデル。基本的な定義

数学の分野では、「テーブル」の概念は「関係」（関係）の概念に対応しています。このテーブルは実世界のオブジェクト（エンティティ）を反映しており、その各行はエンティティの特定のインスタンスを反映しています。各列には、テーブルの一意の名前があります。文字列には名前がなく、順序も定義されておらず、文字列の数も論理的に制限されていません。リレーショナルデータモデルの主な利点の1つは、均質性です（テーブルの各行には1つの形式があります）。対応するエンティティが同質であるかどうかは、ユーザー自身が決定します。これにより、モデルの適合性の問題が解決されます。

基本概念：

*リレーションは、いくつかのデータを含む2次元テーブルです。

*エンティティ-あらゆる性質のオブジェクト。データはデータベースに保存されます。属性-エンティティ（列）を特徴付けるプロパティ。

*関係の程度-列の数。

*関係スキーム-属性名のリスト。たとえば、EMPLOYEE（番号、氏名、生年月日、役職、部門）。

*ドメイン-リレーション属性値のセット（データ型）。

*タプル-テーブル行。

*カーディナリティ（パワー）-テーブルの行数。

*主キーは、リレーションシップ内の行を一意に識別する属性です。複数の属性を持つ主キーは、複合キーと呼ばれます。主キーを完全にまたは部分的に空にすることはできません（null値を持つ）。主キーとして使用できるキーは、候補キーまたは代替キーと呼ばれます。

*外部キーは、別のテーブルの主キーとして機能できる1つのテーブルの属性です。別のテーブルの主キーへの参照です。

正規化は、データベース内の情報の冗長性を減らすことを目的としたプロセスです。データ自体に加えて、さまざまな名前、オブジェクト名、および式もデータベースで正規化できます。

正規化されていないデータベースには、1つ以上の異なるテーブルの情報が含まれています。これにより、特定のテーブルにデータが含まれているのは明らかな理由によるものではないという印象が生まれます。この状況は、データセキュリティ、ディスクスペース管理、クエリ速度、データベース更新効率、そしておそらく最も重要なこととして、保存されている情報の整合性に悪影響を与える可能性があります。正規化前のデータベースは、より管理しやすい小さなテーブルに論理的に分割されていない構造です。

正規形は、データベースの正規化のレベルまたは深さの一種の指標です。データベースの正規化レベルは、データベースの正規形に対応しています。

1.2関係の操作

テーブルを第一正規形（1NF）に変換するには、次の2つのルールに従う必要があります。

1.アトミシティまたは不可分性。各列には、分割できない値が1つ含まれている必要があります。

2.テーブルに繰り返し列またはデータグループを含めないでください。

たとえば、テーブルの1つのフィールドに個人の完全な住所（番地、都市、郵便番号）が含まれている場合、1つの列に異なる値が含まれるため、1NFのルールに準拠しません。原子性規則の違反。または、データベースに映画に関するデータが含まれていて、列がactor1、actor2、actor3である場合、データが繰り返されるため、ルールも満たされません。

正規化は、1NFとの互換性についてデータベース構造をチェックすることから始める必要があります。アトミックではないすべての列は、構成列に分割する必要があります。テーブルに重複する列がある場合は、別のテーブルを割り当てる必要があります。

テーブルを最初の正規形に変換するには：

*複数の情報を含むすべてのフィールドを検索します。

*構成要素に分解できるデータは、別々のフィールドに配置する必要があります。

*重複データを別のテーブルに移動します。

*すべてのテーブルが最初の正規形の条件に適合しているかどうかを確認します。

テーブルを第2正規形（2NF）に変換するには、結果のテーブルがすでに1NFになっている必要があります。正規化は順番に行う必要があります。

ここで、第2正規形では、条件が満たされている必要があります。キーではない列（外部の列を含む）は、主キーに依存している必要があります。通常、これらの列はキーに依存しない値を持っているため、簡単に識別できます。列に含まれるデータが行を説明するキーに関連していない場合は、それらを独自の個別のテーブルに分割する必要があります。主キーは古いテーブルに戻す必要があります。

ベースを第2正規形に変換するには：

*このテーブルの主キーに直接依存していないすべての列を特定します。

*ユーザーとフォーラムのテーブルに必要なフィールドを作成するか、既存のフィールドから選択するか、新しいフィールドから主キーを作成します。

*各テーブルには独自の主キーが必要です

*外部キーを作成し、テーブル間の関係を示します。 2NFへの正規化の最後のステップは、関連するテーブルに関連付けるための外部キーの割り当てです。あるテーブルの主キーは、別のテーブルの外部キーである必要があります。

ヒント：

スキーマを2NFにする別の方法は、テーブル間の関係を調べることです。理想的なオプションは、すべての1対多の関係を作成することです。多対多の関係を再構築する必要があります。

適切に正規化されたテーブルに重複する行が含まれることはありません（値がキーではなく、同じデータを含む2つ以上の行）。

データベースが第2正規形にキャストされ、各非キー列が互いに独立している場合、データベースは第3正規形になります。この時点まで正規化プロセスが正しく実行されていれば、3NFへの削減に問題はない可能性があります。ある列の値を変更するために別の列を変更する必要がある場合は、3NFに違反することに注意してください。

ベースを第3正規形に変換するには：

*どのテーブルのどのフィールドに相互依存があるかを判断します。シリーズ全体よりも相互に依存するフィールド。

*関連するテーブルを作成します。手順1で問題のある列がある場合は、その列用に個別のテーブルを作成します。

*主キーを作成または割り当てます。すべてのテーブルには主キーが必要です。

*関係のいずれかを形成する必要な外部キーを作成します。

4番目の正規形では、追加のルールは多値従属性を除外することです。つまり、すべてのテーブル行は互いに独立している必要があります。行Xが存在するからといって、行Yもこのテーブルのどこかにあるとは限りません。

2.企業情報システム

リレーショナルモデルデータシステム

システム（ギリシャ語のシステマから-全体、パーツで構成された接続）は、相互作用する要素のセットであり、特定の整合性、統一性を形成します。システムを特徴づけるためによく使用されるいくつかの概念を次に示します。

1.システム要素-特定の機能目的を持つシステムの一部。システムの複雑な要素は、相互接続された単純な要素で構成されており、サブシステムと呼ばれることがよくあります。

2.システムの組織化-内部秩序、システムの要素の相互作用の一貫性。これは、特に、システム内の要素の状態の多様性を制限することで明らかになります。

3.システムの構造-システムの基本的なプロパティを決定する、システムの要素の相互作用の構成、順序、および原則。システムの個々の要素が異なるレベルで分離されており、要素間の内部リンクが上位レベルから下位レベルにのみ編成されている場合、またはその逆の場合、システムの階層構造について説明します。純粋な階層構造は実際にはまれであるため、この概念をいくらか拡張すると、階層構造は通常、他の接続の中でも特に階層接続が最も重要であるような構造を意味すると理解されます。

4.システムアーキテクチャ-ユーザーにとって不可欠な一連のシステムプロパティ。

5.システムの完全性-システムのプロパティの個々の要素のプロパティの合計に対する基本的な還元不可能性（プロパティの出現）と同時に、各要素のプロパティのシステムへの依存性システム内に配置して機能します。

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

連邦法「情報、情報化および情報保護に関する」は、次の定義を提供します。

「情報システムは、情報プロセスを実装するコンピューター技術とコミュニケーションツールの使用を含む、組織的に順序付けられた一連の文書（文書の配列）と情報技術です。」

スケール分類

規模によって、情報システムは次のグループに分けられます。

* 独身;

* グループ;

*企業。

企業情報システムは、統一された管理を必要とする企業グループで構成される企業を含む、大中規模の企業のあらゆるタイプの経済活動の複雑な自動化のために設計されたスケーラブルなシステムです。

企業情報システムは、会社の部門の80％以上を自動化するシステムと見なすことができます。

最近、経済対象の管理における情報技術の使用を専門とする多くの出版物では、「企業情報システム」という用語がよく使用されます。これは、経済対象の実際の自動化された情報システムを指します。

自動化情報システム（AIS）は、さまざまなタイプのサポートと、会計および分析情報の処理を自動化するように設計されたスペシャリストを組み合わせたものです。構成の観点からのサポートのタイプは、原則として、さまざまなシステムに対して同種であり、これにより、システムの運用中にシステムの互換性の原則を実装することが可能になります。 AISを複雑なシステムとして研究する過程で、個々の部品や要素を選び出し、作成や運用の段階でそれらの使用の特徴を検討する必要があります。

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

グループおよび企業システムの場合、運用の信頼性とデータの安全性に対する要件が大幅に高まります。これらのプロパティは、データベースサーバー内のデータ、リンク、およびトランザクションの整合性を維持することによって提供されます。

範囲による分類

情報システムの範囲によると、通常、4つのグループに分けられます。

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

*意思決定システム;

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

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

参考文献

1. Agaltsov、V.P。データベース。 2巻。V。2。分散データベースとリモートデータベース：教科書/ V.P. アガルトソフ。 --M。：IDフォーラム、SIC INFRA-M、2013年。

2. Golitsyna、O.L。データベース：教科書/ O.L. Golitsyna、N.V。マクシモフ、I.I。ポポフ。 -M。：フォーラム、2012年。

3. Karpova、I.P。データベース：教科書/ I.P. カルポフ。 -サンクトペテルブルク：ピーター、2013年。

4. Kirillov、V.V。リレーショナルデータベースの紹介リレーショナルデータベースの紹介/V.V。キリロフ、G.Yu。グロモフ。 -サンクトペテルブルク：BHV-ピーターズバーグ、2012年。

5. Pirogov、V.Yu。情報システムとデータベース：組織とデザイン：教科書/V.Yu。ピロゴフ。 -サンクトペテルブルク：BHV-ピーターズバーグ、2009年。

6. G.N. フェドロフ。情報システム。 -M。：アカデミー、2013年。

7. A.E. Satunina、L.A。シソエフ。企業の企業情報システムのプロジェクト管理。 --M。：財務と統計、Infra-M、2009年。

Allbest.ruでホスト

...

同様の文書

データモデルのタイプの本質と特性：階層、ネットワーク、リレーショナル。リレーショナルデータモデルの基本概念。属性、データベース関係スキーマ。データ整合性条件。テーブル間の関係。データモデルに関する一般的な考え方。

タームペーパー、2011年1月29日追加

企業の情報システムとデータベース、ビジネスの改善とデバッグのためのそれらの使用。企業情報システムの分類。 OLTPクラスの情報システム。運用分析処理。

タームペーパー、2011年1月19日追加

2次元ファイルとリレーショナルデータベース管理システム（DBMS）を備えたデータベース。データベースを作成し、DBMSを使用してデータベースへのクエリを処理します。データベースの基本的なタイプ。リレーショナルデータベースの基本概念。人間関係の基本的な特性。

要約、2010年12月20日追加

データベースシステムの概念。リレーショナルモデルとその特性。リレーショナルモデルの整合性。関係代数。データベース設計の問題。関係の通常の形。実体関連法を使用したデータベースの設計。 ER図。 SQL言語。

講義コース、2008年3月10日追加

データベースに格納されているデータの特定の論理構造。基本的なデータモデル。リレーショナルデータモデルの要素。外部キーの使用例。リレーショナルデータモデルの関係の主な要件。

プレゼンテーション、2013年10月14日追加

データベースとそのコンピューティングでの使用。ネットワークデータモデルの特徴と基本構造単位。階層モデル、ドメインオブジェクト。リレーショナルモデル、その可視性、表形式でのデータの表示。

要約、2011年12月19日追加

データベース管理システムMicrosoftAccessの種類と機能。データベース記述の階層、ネットワーク、リレーショナルモデル。データベーステーブルの基本概念。データベースオブジェクト、基本的なフォームを作成する機能。アクセスでのインターネットへのアクセス。

制御作業、2011年1月8日追加

最新のデータベース管理システム（DBMS）。階層型データモデルの分析。リレーショナルデータモデル。テーブルレコードに格納されているデータの不可分性の制限を取り除く拡張リレーショナルモデルとしてのポストリレーショナルデータモデル。

科学的研究、2010年6月8日追加

データベース管理におけるデータモデル。概念的なデータモデル。情報システムにおけるデータベースの役割。リレーショナルデータモデル。サブジェクトエリアの定義。情報システム「ペット」のデータベースモデルを構築する。

タームペーパー、2011年4月19日追加

実際のオブジェクトまたはシステムの簡略化された代替としてのAccessの情報モデル。データの編成とそれらの間の関係を定義する基本構造。リレーショナルタイプのデータ編成。課税におけるデータベースの例。

Zaitsev S.L.、Ph.D。

繰り返しグループ

米。 1.6。この例では、繰り返しグループを使用しています。

米。 1.7。モデルは第一正規形に縮小されました。

1つの場所に1つの事実

各属性はキーに依存します

米。 1.9。第3正規形 学校名と 地理的領域エンティティに移動しました。エンティティの値はキーによって異なります。

多対多の関係

正規形の正式な定義

リレーションRは、そのすべてのドメインにアトミック値のみが含まれている場合にのみ、第一正規形（1NF）になります（日付、同上）。

関係Rは、それが1NFにあり、すべての非キー属性が主キーに完全に依存している場合にのみ、第2正規形（2NF）になります（日付、同上）。

関係Rは、それが2NFにあり、すべての非キー属性が主キーに一時的に依存していない場合にのみ、第3正規形（3NF）になります（日付、同上）。

関係Rは、各行列式がキーとして使用する候補である場合にのみ、ボイス-コッド正規形（BCNF）に準拠します。

ノート 以下は、Dateの定義で使用されているいくつかの略語の簡単な説明です。

FD（機能依存性）-機能依存性。 関数従属性では、属性の値は、主キーの一部ではない別の属性の値に依存します。

ビジネス正規形

完成した論理データモデル

物理データモデル

データ使用要件の収集

アクセスとパフォーマンスの要件

管理者がデータベースの物理ボリュームを表すことができるボリューム特性（保存されるデータ量の見積もり）

許容可能なレベルのパフォーマンスのためにデータベースを設計するのに役立つ、データへの同時アクセスを必要とするユーザーの数の見積もり

要約、要約、および耐久性のあるデータ構造でのストレージの候補と見なされる可能性のあるその他の計算または派生データ

データベース管理者がインデックスを作成するのに役立つレポートと標準クエリを生成するための要件

ユーザーがデータのマージまたはフィルタリング操作を実行するのを支援するビュー（永続的または仮想）。

物理データモデルのコンポーネント

リバースエンジニアリング

企業の機能境界の使用

エンタープライズデータモデルとは何ですか？

スケーリングによるエンタープライズデータモデルの構築

モデリング方法論の概念

ビジュアルデータモデリングにはいくつかの方法論があります。 ERwinは2つをサポートします。

IDEF1X（情報モデリングの統合定義-情報モデルの統合された記述）。

IE（情報工学-情報工学）。

IDEF1Xは優れた方法論であり、その表記法は広く使用されています

情報モデルの統合された説明

情報工学

結論

ITプロフェッショナルは、業界標準のデータモデルとビジネス決定テンプレートに基づくデータ管理ソリューションにますます注目するようになっています。すぐにロードできる複雑な物理データモデルと特定の活動領域のビジネスインテリジェンスレポートにより、企業の情報コンポーネントを統合し、ビジネスプロセスを大幅に高速化できます。ソリューションテンプレートを使用すると、サービスプロバイダーは、既存のシステムに隠されている非標準の情報の力を活用できるため、プロジェクトのタイムライン、コスト、およびリスクを削減できます。たとえば、実際のプロジェクトでは、データモデルとビジネスの意思決定テンプレートによって開発の労力を50％削減できることが示されています。

業界の論理モデルは、戦略的および戦術的なビジネス上の質問に答えるために企業のデータウェアハウスに存在する必要があるすべての情報のドメイン固有の統合された論理的に構造化されたビューです。モデルの主な目的は、データスペースでの方向付けを容易にし、ビジネス開発に重要な詳細を強調するのに役立つことです。今日のビジネス環境では、さまざまなコンポーネント間の関係を明確に理解し、組織の全体像を十分に理解することが絶対に必要です。モデルを使用してすべての詳細と関係を特定することにより、会社の作業を整理するための時間とツールを最も効率的に使用できます。

データモデルは、データの表現方法とアクセス方法を説明する抽象モデルです。データモデルは、特定の領域におけるデータ要素とそれらの間の関係を定義します。データモデルは、特定のクラスの実際の情報を正確に説明するために特定の記号と単語のセットを使用する、ビジネスとITの両方の専門家向けのナビゲーションツールです。これにより、組織内のコミュニケーションが改善され、より柔軟で安定したアプリケーション環境が作成されます。

当局および地方自治体モデルのGISの例。

今日、ソフトウェアおよびサービスプロバイダーが、技術革新、政府の規制の撤廃、およびサプライチェーンの複雑さに関連する業界の変化に迅速に対応できることが戦略的に重要です。ビジネスモデルの変化に伴い、企業の活動をサポートするために必要な情報技術の複雑さとコストが増大しています。企業の情報システムとその機能およびビジネス要件が絶えず変化している環境では、データ管理は特に困難です。

このプロセスを促進および最適化するために、ITアプローチを最新レベルに変換する際に、業界のデータモデルが求められます。

会社の業界データモデルEsri

Esri ArcGISプラットフォームのデータモデルは、GISプロジェクトで使用するための作業用テンプレートであり、さまざまなアプリケーション領域のデータ構造を作成します。データモデルの構築には、個人または企業のジオデータベースの構築に使用できる概念設計、論理構造、および物理構造の作成が含まれます。 ArcGISは、データベーススキーマを作成および管理するためのツールを提供し、データモデルテンプレートを使用して、さまざまなアプリケーションや業界でGISプロジェクトを迅速に立ち上げます。 Esriは、ユーザーコミュニティとともに、エンタープライズジオデータベースの設計を迅速に開始するのに役立つ多数のテンプレートの開発にかなりの時間を費やしてきました。これらのプロジェクトは、support.esri.com / datamodelsで説明および文書化されています。以下に、このサイトに表示される順序で、Esriの業界モデル名のセマンティック翻訳を示します。

アドレスレジスタ
農業
気象学
基本的な空間データ
生物多様性
建物の内部空間
温室効果ガス会計
管理境界の維持
軍事施設。インテリジェンスサービス
エネルギー（新しいArcGIS MultiSpeakプロトコルを含む）
生態学的な建物
緊急事態省。防火
森の地籍
林業
地質学
全国レベルのGIS（e-gov）
地下水と廃水
健康管理
考古学と記念碑の保護
国際セキュリティー
水文学
国際水路機関（IHO）。 ENCのS-57フォーマット
灌漑
土地登記所
市政
航海
州の地籍
石油とガスの構造
パイプライン
ラスターストア
深浅測量、海底地形
電気通信
輸送
配管、下水道、ユーティリティ

これらのモデルには、業界標準に必要なすべての機能が含まれています。

自由に利用できます。
「選択された」メーカーの技術に縛られていません。
実際のプロジェクトの実施の結果として作成されました。
業界の専門家の参加を得て作成されました。
さまざまな製品やテクノロジー間の情報の相互作用を提供するように設計されています。
他の規格や規制文書と矛盾しないでください。
世界中で実施されているプロジェクトで使用されています。
プロジェクト自体ではなく、作成中のシステムのライフサイクル全体で情報を処理するように設計されています。
他のプロジェクトやモデルとの互換性を失うことなく、顧客のニーズに合わせて拡張できます。
追加の資料と例を伴う。
さまざまな産業会社のガイドラインおよび技術資料で使用されます。
参加者の大規模なコミュニティ。コミュニティへのアクセスはすべての人に開かれています。
近年の出版物におけるデータモデルへの多数の参照。

Esriは、PODS（Pipeline Open Data Standards-石油およびガス業界向けのオープンスタンダード。現在、Esri PODS Esri SpatialとしてPODSの実装があります）など、さまざまな業界モデルの使用を推奨する独立機関の専門家グループの一部です。 5.1.1ジオデータベース）またはArcGIS for Aviationのジオデータベース（GDB）で、ICAOとFAAの推奨事項、およびAIXM5.0ナビゲーションデータ交換標準を考慮しています。さらに、S-57やArcGIS for Maritime（海洋および沿岸の機能）などの既存の業界標準に厳密に準拠する推奨モデルや、Esri Professional Servicesの作業から作成された、「事実上の」標準であるモデルがあります。関連分野で。たとえば、国と地方自治体のGISは、NSDIとINSPIREの標準に影響を与えていますが、HydroとGroundwaterは、無料で入手できるArcHydroプロフェッショナルパッケージと商用製品で頻繁に使用されています。 Esriは、NHDIなどの「事実上の」標準もサポートしていることに注意してください。提案されたすべてのデータモデルは文書化されており、エンタープライズITプロセスで使用できるようになっています。モデルに付属する資料は次のとおりです。

実体関連のUML図。
データ構造、ドメイン、ディレクトリ。
ArcGISGDB形式の既製のジオデータベーステンプレート。
サンプルデータとサンプルアプリケーション。
データ読み込みスクリプトの例、分析ユーティリティの例。
提案されたデータ構造に関する参考書。

Esriは、業界モデルの構築における経験を書籍の形で要約し、公開された資料をローカライズします。 Esri CISは、次の書籍をローカライズして公開しています。

地理空間サービス指向アーキテクチャ（SOA）;
輸送用のジオデータベースの設計。
企業の地理情報システム;
GIS：電気およびガス企業の新エネルギー。
デジタル地図上の石油とガス。
私たちの世界をモデル化する。 Esriジオデータベース設計ガイド;
GISについて考える。 GIS計画：管理者向けのガイド。
地理情報システム。基本;
管理および経済管理のためのGIS。
WebGIS。原則と適用;
システム設計戦略、第26版;
企業やGISシステムのユーザーによる出版物を含むArcReviewマガジンの68号。
...そして他の多くのテーマ別のメモや出版物。

たとえば、本 私たちの世界をモデル化...「（翻訳）は、GISデータモデリング全般、特にジオデータベースデータモデルの包括的なガイドおよびリファレンスガイドです。この本は、適切なデータモデリングの決定、GISプロジェクトのあらゆる側面に関係する決定を行う方法を示しています。データベース設計データとデータ収集から空間分析と視覚化までプロジェクトに適した地理データベースを設計する方法、プログラミングなしでデータベース機能を設定する方法、複雑なプロジェクトでワークフローを管理する方法、河川、輸送などのさまざまなネットワーク構造をモデル化する方法を詳細に説明しますまたは電気ネットワーク、衛星画像データを地理分析とマッピングに統合し、3DGISデータモデルを作成します。 輸送用のジオデータベースの設計「多数のプロジェクトでテストされ、ヨーロッパと米国の法的要件、および国際標準に完全に準拠している方法論的アプローチが含まれています。そして本の中で」 GIS：電気およびガス企業の新エネルギー実際の例を使用して、顧客サービス、ネットワーク運用、その他のビジネスプロセスなどの側面を含め、エンタープライズGISがエネルギー供給業者にもたらすメリットを示します。

EsriCISとDATA +によってロシア語で出版された、翻訳されたオリジナルの本の一部。それらは、GISテクノロジーに関連する概念的な問題と、さまざまな規模と目的のGISのモデリングと展開に適用される多くの側面の両方をカバーしています。

例として、BISDM（Building Interior Space Data Model）バージョン3.0データモデルを使用した業界モデルの使用を検討します。 BISDMは、より一般的なBIMモデル（建物情報モデル、建物情報モデル）の開発であり、建物や構造物の設計、建設、運用、廃止措置での使用を目的としています。 GISソフトウェアで使用され、地理データを他のプラットフォームと効果的に交換し、それらと対話することができます。一般的なタスクグループFM（組織インフラストラクチャ管理）を指します。 BISDMモデルの主な利点をリストします。これを使用すると、次のことが可能になります。

統一されたルールに従って、異種環境での情報交換を整理します。
BIMコンセプトの「物理的」な実施形態と建設プロジェクトを管理するための推奨ルールを取得します。
建物のライフサイクル全体（設計から廃止まで）を通じて、GISツールを使用して単一のリポジトリを維持します。
プロジェクトのさまざまな専門家の作業を調整します。
すべての参加者の計画されたスケジュールと建設段階を視覚化します。
コストと建設時間の予備的な見積もりを与える（4Dおよび5Dデータ）。
プロジェクトの進捗を管理します。
メンテナンスや修理を含む、建物の質の高い運用を確保する。
スペース使用の効率を分析する機能（賃貸、保管施設、従業員管理）を含む資産管理システムの一部になる。
建物のエネルギー効率を計算して管理します。
人間の流れの動きをシミュレートします。

BISDMは、建物の内部施設のレベルで空間データを操作するためのルールを定義します。これには、使用の目的と種類、敷設された通信、設置された機器、修理とメンテナンスの会計、インシデントの記録、他の会社の資産との関係が含まれます。このモデルは、地理データと非地理データの統合リポジトリを作成するのに役立ちます。世界をリードする企業の経験を利用して、建物自体とその内部の両方を形成するすべての物理要素の空間的および論理的関係をGDBレベル（ジオデータベース）でエンティティとモデルを分離しました。 BISDMの原則に従うことで、他のシステムとの統合タスクを大幅に簡素化できます。最初の段階では、これは通常CADとの統合です。次に、建物の運用中に、ERPおよびEAMシステム（SAP、TRIRIGA、Maximoなど）とのデータ交換が使用されます。

ArcGISを使用したBISDM構造要素の視覚化。

BISDMを使用する場合、施設の顧客/所有者は、施設の作成のアイデアから完全なプロジェクトの開発、最大で取得する建設管理まで、エンドツーエンドの情報交換を受け取ります-施設が稼働するまでの日付情報、稼働中のパラメータの制御、さらには施設の再建または廃止措置中。 BISDMパラダイムに従って、その助けを借りて作成されたGISとGDBは、関連するシステムの共通のデータリポジトリになります。多くの場合、GDBには、サードパーティのシステムによって作成および運用されるデータがあります。これは、作成するシステムのアーキテクチャを設計するときに考慮に入れる必要があります。

ある段階で、蓄積された「臨界量」の情報により、新しい定性的なレベルに移行することができます。たとえば、新しい建物の設計段階が完了すると、GISで3D測量モデルを自動的に視覚化し、設置する機器のリストを作成し、敷設するエンジニアリングネットワークのキロメートルを計算し、さまざまな検証を実行できます。、さらにはプロジェクトコストの予備的な財務見積もりを提供します。

繰り返しになりますが、BISDMとArcGISを一緒に使用すると、GDBには床に属するz座標、要素接続のタイプ、機器などのオブジェクトの完全な記述が含まれているため、蓄積されたデータから3Dモデルを自動的に構築することが可能になります設置方法、材料、利用可能な経路、人員の移動、各要素の機能目的など。等すべての設計資料をBISDMGDBに最初にインポートした後、次の追加コンテンツが必要になることに注意してください。

指定された場所にオブジェクトと機器の3Dモデルを配置する。
材料のコストとそれらの敷設および設置の手順に関する情報を収集する。
取り付けられている非標準機器の寸法に応じた開通性制御。

ArcGISを使用することで、外部ソースからの追加の3Dオブジェクトとリファレンスブックのインポートが簡素化されます。 ArcGIS Data Interoperabilityモジュールを使用すると、そのようなデータをインポートしてモデル内に正しく配置するためのプロシージャを作成できます。 IFC、AutoCAD Revit、Bentlye Microstationなど、業界で使用されているすべての形式がサポートされています。

IBMの業界データモデル

IBMは、さまざまな業界向けに一連のストレージ管理ツールとモデルを提供しています。

IBM Banking and Financial Markets Data Warehouse（finance）
IBM Banking Data Warehouse
IBMの銀行業務プロセスとサービスモデル
IBM Health Planデータモデル（health）
IBM Insurance Information Warehouse（保険）
IBMの保険プロセスとサービスモデル
IBM Retail Data Warehouse（小売）
IBM Telecommunications Data Warehouse（テレコミュニケーション）
InfoSphere Warehouse Pack：
-カスタマーインサイト用（顧客を理解するため）
-市場およびキャンペーンの洞察（会社と市場を理解するため）
-サプライチェーンインサイト用（サプライヤを理解するため）。

たとえば、モデル IBM銀行と金融市場データ倉庫データの観点から銀行業界の特定の課題に対処するように設計されており、 IBM銀行処理するとサービスモデル-プロセスとSOA（サービス指向アーキテクチャー）の観点から。電気通信業界向けに提示されたモデル IBM情報フレームワーク（IFW）と IBM電気通信データ倉庫（TDW）。これらは、分析システムの作成プロセスを大幅にスピードアップするだけでなく、通信業界の詳細を考慮して、ビジネスインテリジェンスアプリケーションの開発、企業データ管理、およびデータウェアハウスの編成に関連するリスクを軽減するのに役立ちます。 IBM TDWの機能は、有線および無線の電話サービス、データ伝送、マルチメディアコンテンツを提供するインターネットプロバイダーやケーブルネットワークオペレーターから、電話、衛星、長距離および国際通信サービスを提供する多国籍企業まで、電気通信市場の全範囲をカバーしています。組織のグローバルネットワークとして。現在、TDWは、世界中の大小の有線および無線サービスプロバイダーによって使用されています。

と呼ばれるツール カスタマーインサイト用のInfoSphereWarehouse Packは、銀行、保険、金融、健康保険プログラム、電気通信、小売、流通など、ますます多くのビジネスプロジェクトや業界向けに構造化された簡単に実装できるビジネスコンテンツです。ビジネスユーザー向け 市場およびキャンペーンの洞察のためのInfoSphereWarehouse Packステップバイステップの開発とビジネス固有のプロセスを通じて、マーケットインテリジェンスとマーケティングキャンペーンの効果を最大化するのに役立ちます。経由 サプライチェーンインサイトのためのInfoSphereWarehouse Pack組織には、サプライチェーンの運用に関する現在の情報を取得する機能があります。

IBMソリューションアーキテクチャー内でのEsriの位置。

特に注目すべきは、公益事業および公益事業会社に対するIBMのアプローチです。増大する消費者の需要を満たすために、公益事業会社は、現在使用しているよりも柔軟なアーキテクチャと、情報の自由な交換を容易にする業界標準のオブジェクトモデルを必要としています。これにより、より費用効果の高い通信が可能になり、エネルギー会社の通信機能が強化され、組織内のどこに配置されていても、新しいシステムが必要なすべてのリソースをより適切に把握できるようになります。このアプローチの基礎は、SOA（Service Oriented Architecture）です。これは、部門の機能と再利用可能なさまざまなアプリケーションのサービスとの間の対応を確立するコンポーネントモデルです。これらのコンポーネントの「サービス」は、ハードバインディングなしでインターフェイスを介して通信し、背後にあるシステムの完全な複雑さをユーザーから隠します。このモードでは、企業は、ソフトウェアベンダー、オペレーティングシステム、プログラミング言語、またはソフトウェアの他の内部特性に関係なく、新しいアプリケーションを簡単に追加できます。コンセプトはSOAに基づいて実装されています 安全な（エネルギー向けソリューションアーキテクチャにより、公益事業業界は、インフラストラクチャの標準ベースの全体像を把握できます。

Esri ArcGIS®は、地理情報システム（GIS）向けの世界的に認められたソフトウェアプラットフォームであり、電力、ガス伝送、配電、および電気通信ネットワークのデジタル資産の作成と管理を提供します。 ArcGISでは、空間的な位置を考慮して、配電ネットワークのコンポーネントの最も完全なインベントリを実行できます。 ArcGISは、スマートグリッドの管理に必要なツール、アプリケーション、ワークフロー、分析、および情報と統合機能を提供することにより、IBMSAFEアーキテクチャーを大幅に拡張します。 IBM SAFE内のArcGISを使用すると、インフラストラクチャオブジェクト、資産、顧客、および従業員に関するさまざまなソースから、場所に関する正確なデータを取得したり、企業資産（柱、パイプライン、ワイヤー、変圧器、ケーブルダクトなど）。 SAFEインフラストラクチャ内のArcGISを使用すると、GIS、SCADA、およびカスタマーサービスシステムからのデータをトラフィック、気象条件、衛星画像などの外部情報と組み合わせることで、主要なビジネスアプリケーションを動的に接続できます。ユーティリティは、C.O.R。からのさまざまな目的のために、この組み合わされた情報を使用します。（運用環境の全体像）サイトの検査、保守、ネットワーク分析、および計画。

電源企業の情報コンポーネントは、いくつかのレベルを使用してモデル化できます。これらのレベルは、最下位の物理レベルから最上位の最も複雑なレベルのビジネスプロセスロジックまでさまざまです。これらのレイヤーを統合して、自動測定ロギングや監視制御およびデータ取得（SCADA）制御などの一般的な業界要件を満たすことができます。 SAFEアーキテクチャを構築することにより、公益事業会社は、エネルギーおよび公益事業向けのCommon Information Model（CIM）と呼ばれる業界全体のオープンオブジェクトモデルの進歩に大きな進歩を遂げています。このモデルは、データとオブジェクトを構造化するためのオープンスタンダードの使用を促進するため、多くの企業をサービス指向アーキテクチャーに移行するために必要な基盤を提供します。すべてのシステムで同じオブジェクトを使用することにより、同じオブジェクトの異なる実装に関連する混乱と非弾性が最小限に抑えられます。したがって、「顧客」オブジェクトおよびその他の重要なビジネスオブジェクトの定義は、電力会社のすべてのシステムで統一されます。 CIMを使用すると、サービスプロバイダーとサービスコンシューマーが共通のデータ構造を共有できるようになり、CIMが情報共有を構築するための共通の基盤を確立するため、コストのかかるビジネスコンポーネントのアウトソーシングが容易になります。

結論

包括的な業界データモデルは、企業にビジネス情報の単一の統合されたビューを提供します。多くの企業は、データを統合することが難しいと感じていますが、これはほとんどの企業全体のプロジェクトの前提条件です。データウェアハウスインスティテュート（TDWI）の調査によると、調査対象の組織の69％以上が、統合が新しいアプリケーションの採用に対する重大な障壁であると感じています。それどころか、データ統合の実装は、会社に具体的な収入と効率の向上をもたらします。

適切に構築されたモデルは、データの意味を一意に定義します。この場合、データは構造化データです（値があいまいになる可能性がある画像、バイナリファイル、テキストなどの非構造化データとは対照的です）。最も効果的な業界モデルは、EsriやIBMなどのプロのベンダーによって提供されています。それらのモデルを使用することからの高いリターンは、それらの重要なレベルの詳細と正確さのために達成されます。通常、これらには多くのデータ属性が含まれています。さらに、EsriとIBMの専門家は、モデリングの豊富な経験があるだけでなく、特定の業界向けのモデルの構築にも精通しています。

データベースアーキテクチャ

CMDスキーマは、管理者の観点からのデータモデルの構造の記述です。

AMDスキーマは、内部モデルまたは物理モデルの記述です。メディア上のデータの物理的な場所の説明を保存します。このスキームは、メモリ内のデータの場所（ボリューム、ディスク）の直接的な指示を格納します。

CMDスキーマは、データ、レコード、およびフィールドの構造を記述します。

すべてのDBMSは、次の3つの主要なタイプのデータモデルをサポートしています。

1.階層モデル。ルートエントリを想定しています。枝は根から来ます。

すべてのオブジェクトがこのように便利に記述されているわけではありません。階層には接続がなく、情報の大きな冗長性が特徴です。

2.ネットワークモデル。関係のすべての複雑さを正しく表示できます。

このモデルは、外部環境からのデータを使用してリンクを表すのに便利ですが、データベースに記述するのにはあまり便利ではありません。これにより、ユーザーはリンクを介したナビゲーションを調べるための追加作業につながります。

3.リレーショナルモデル。これは、数学用語の関係（関係）に基づいていますが、単にテーブルです。たとえば、長方形の2次元。

リレーショナルデータ構造は、60年代後半に多くの研究者によって開発されましたが、その中で最も重要な貢献は、IBMの従業員であるEdgarCoddによって行われました。リレーショナルアプローチでは、データは2次元テーブルの形式で表示されます。これは人にとって最も自然なことです。同時に、データ処理のために、コッドは集合論の装置を使用することを提案しました-和集合、共通部分、差、デカルト積。

データ・タイプ-この概念は、プログラミング言語と同じ意味を持ちます（つまり、データ型は、コンピューターメモリの内部表現、データインスタンスの格納方法、およびデータインスタンスが取ることができる値のセットを定義します）および有効なデータ操作のセット）。既存のすべての最新のデータベースは、整数型、分数浮動小数点、文字と文字列、カレンダーの日付のデータを格納するように設計された特殊な型のデータをサポートしています。多くのデータベースサーバーは他のタイプを実装しています。たとえば、Interbaseには、大きなバイナリ情報配列（BLOB）を格納するための特別なデータタイプがあります。

ドメインは単純なデータ型の潜在的な値のセットであり、一部のプログラミング言語のデータサブタイプに似ています。ドメインは、データ型とデータに適用されるブール式の2つの要素によって定義されます。この式がtrueと評価された場合、データインスタンスはドメインに属します。

態度は、ヘッダーと本体で構成される特殊な種類の2次元テーブルです。

ヘッダは属性の固定セットであり、それぞれがいくつかのドメインで定義されており、属性と定義ドメインの間には1対1の対応があります。

各属性は、独自のドメインで定義されます。ドメインは整数データ型であり、ブール条件はn> 0です。関係本体とは異なり、見出しは時代を超越しています。 関係体-コレクションです タプル、それぞれが属性と値のペアです。

関係の力によってタプルの数であり、 態度の程度属性の数です。

比率の次数は特定の比率に対して一定の値ですが、比率の累乗は時間とともに変化します。比率の累乗は基数とも呼ばれます。

上記の概念は理論上のものであり、リレーショナルDBMS用の言語ツールおよびソフトウェアシステムの開発に使用されます。日常業務では、代わりにそれらの非公式な同等物が使用されます。

態度 - テーブル;

属性 -列またはフィールド。

タプル- レコードまたは行。

したがって、関係の程度はテーブルの列数であり、基数は行数です。

リレーションはセットであり、古典的なセット理論では、定義上、セットに一致する要素を含めることはできないため、リレーションに2つの同一のタプルを含めることはできません。したがって、特定の関係には、タプルを一意に識別する一連の属性が常に存在します。この属性のセットはと呼ばれます鍵。

キーは次の要件を満たしている必要があります。

一意である必要があります。

・最小限にする必要があります。つまり、キーから属性を削除すると、一意性が侵害されます。

原則として、キー内の属性の数は関係の次数よりも少なくなりますが、極端な場合、すべての属性の組み合わせが一意性条件を満たすため、キーにすべての属性が含まれる場合があります。通常、リレーションには複数のキーがあります。関係のすべてのキー（「可能なキー」とも呼ばれます）のうち、1つが次のように選択されます。 主キー。選ぶとき 主キー通常、属性の数が最も少ないキーが優先されます。また、長い文字列値を持つキーを使用することも不適切です。

実際には、特別な数値属性が主キーとして使用されることがよくあります。その値はトリガーによって生成できる自動インクリメントゼロ（トリガーはデータベースに変更が加えられたときに呼び出される特別なプロシージャです）またはDBMSメカニズムで定義された特別な手段によって。

この章で説明する概念は、特定のデータベース実装に固有のものではありませんが、それらすべてに共通しています。したがって、これらの概念は、リレーショナルデータモデルと呼ばれる特定の一般的なモデルの基礎となります。

リレーショナルアプローチの創設者であるDateは、リレーショナルモデルが次の3つの部分で構成されていることを確立しました。

構造;

・操作的;

ホリスティック。

リレーショナルモデルで使用される唯一のデータ構造として、モデルの構造部分でリレーションシップが固定されます。

操作の部分では、リレーショナルデータベースを操作するための2つの基本的なメカニズムが固定されています。関係代数と関係論理です。

不可欠な部分は、データの非破壊性を保証するための特定のメカニズムとして理解されています。整合性の部分には、リレーショナルデータベースの2つの基本的な整合性要件（エンティティの整合性と参照整合性）が含まれます。

要件 実体完全性つまり、関係のタプルは、この関係の他のタプルとは異なる必要があります。つまり、関係には主キーが必要です。関係の基本的なプロパティが満たされている場合は、この要件を満たす必要があります。

データ操作言語とクエリ言語では、関係代数と呼ばれる数学的装置が実行され、次のアクションが定義されています。

1.標準演算：-共通部分、-和集合、\-差、X-デカルト積。

2.特定：投影、制限、接続、分割。

a。協会。

SD SHM EI HP

R 1（部品コード、材料コード、測定単位、消費率）

R 2（SHD、SHM、EI、HP）

見つける必要があります

セットR1とR2を結合することになっています。この操作では、次数が保持され、結果のセットのカーディナリティが保持されます

b。交差点。

一致する行を強調表示します。

c。違い。

R2に一致するR1タプルから除外します。

d。デカルト積。

これは、タプルが連結される場所です。

1つのセットの各行は、他の各行と連結されます。

与えられた2つのセット：

デカルト積の形式は次のとおりです。

この場合、S度は次のようになります。 12行5列になります。

企業データベースは、企業情報システムの中心的なリンクであり、単一の企業情報スペースを作成することができます。企業データベース

ソーシャルネットワークで仕事を共有する

この作品があなたに合わない場合は、ページの下部に同様の作品のリストがあります。検索ボタンも使用できます

テーマV 企業データベース

V 。1。企業システムにおけるデータの編成。企業データベース。

V .2。企業システムにおけるDBMSと構造ソリューション。

V.3。インターネット/イントラネットテクノロジーおよび企業のデータベースアクセスソリューション。

V 。1。企業システムにおけるデータ組織。企業データベース

企業基盤データは企業情報システムの中心的なリンクであり、企業の単一の情報スペースを作成することができます。企業データベース（図1.1）。

データベースにはさまざまな定義があります。

データベース（DB）の下コンピュータのストレージデバイスに格納されている単一のデータセットを構成するような方法で論理的に関連する情報のセットを理解します。このセットは、自動制御システム、データ処理システム、情報およびコンピューティングシステムの機能の過程で解決されるタスクの初期データとして機能します。

データベースという用語は、共有を目的とした論理的に関連するデータのコレクションとして簡単に定式化できます。

データベースの下 1つ以上のアプリケーションに最適に使用できるように、最小限の冗長性で一緒に保存されたデータのコレクションを指します。

データベース作成の目的データストレージの一形態として 採用されたアルゴリズム（ソフトウェア）、使用された技術的手段、コンピューター内のデータの物理的な場所に依存しないデータシステムを構築する。データベースは、多目的な使用（複数のユーザー、多くの形式のドキュメント、および1人のユーザーのクエリ）を想定しています。

基本的なデータベース要件：

データ表示の完全性。データベース内のデータは、オブジェクトに関するすべての情報を適切に表し、ODSに十分である必要があります。
データベースの整合性。データは、ODSの処理中、および作業中に発生するあらゆる状況で保存する必要があります。
データ構造の柔軟性。データベースは、外部条件が変化したときにその整合性と完全性を損なうことなく、データ構造を変更できるようにする必要があります。
実現可能性。これは、さまざまなオブジェクト、それらのプロパティ、および関係を客観的に表現する必要があることを意味します。
可用性。データへのアクセスを差別化する必要があります。
冗長性。データベースは、任意のオブジェクトに関するデータを表す際に最小限の冗長性を備えている必要があります。

知識は理解されている問題を解決するための一連の事実、パターン、およびヒューリスティックルール。

ナレッジベース（KB） 意思決定者から受け取った、使用されたデータベースとルールのコレクション。知識ベースはエキスパートシステムの要素です。

区別する必要がありますデータを提示するさまざまな方法.

物理データ- これは、コンピュータのメモリに保存されているデータです。

データの論理表現ユーザーによる物理データの表現に対応します。データの物理的表現と対応する論理的表現の違いは、後者が物理データ間のいくつかの重要な関係を反映していることです。

企業データベースの下自動化された組織に関するすべての必要なデータと知識を何らかの形で組み合わせたデータベースを理解します。企業情報システムでは、統合データベース, 情報の単一入力と複数使用の原則が実装されています。

米。 1.1。部門と企業の情報リソースとの相互作用の構造。

企業データベースは焦点を当てた (一元化）および配布されます。

集中型（集中型）データベースは、データが1台のコンピューターのストレージデバイスに物理的に保存されているデータベースです。イチジクに 1.2は、さまざまなプラットフォームのデータベースにアクセスするためのサーバーアプリケーションの図を示しています。

図1.2。異種の図一元化されたデータベース

情報処理の集中化により、一貫性の欠如、一貫性の欠如、データの冗長性など、従来のファイルシステムの欠点を排除することが可能になりました。ただし、データベースが大きくなるにつれて、特に地理的に分散した組織で使用される場合、問題が発生します。たとえば、組織のさまざまな部門がデータにアクセスする通信ネットワークノードにある集中型データベースの場合、情報量とトランザクション数が増加すると、次の問題が発生します。

大規模なデータ交換フロー。
ネットワークトラフィックが多い。
信頼性が低い。
全体的なパフォーマンスが低い。

集中データベースでの更新中に情報のセキュリティ、整合性、および一貫性を確保する方が簡単ですが、これらの問題は特定の問題を引き起こします。これらの問題に対する可能な解決策として、データの分散化が提案されています。地方分権化は以下を達成します：

負荷分散による処理の同時性の向上。
リモート（リモート）クエリを実行する際のフィールドでのデータの使用を改善します。
低コスト;
ローカルデータベースの管理が簡単です。

ノードにワークステーション（小型コンピューター）を備えたネットワークを作成するコストは、メインフレームを使用して同様のシステムを作成するコストよりもはるかに低くなります。図1.3に、分散データベースの論理図を示します。

図1.3。分散型企業データベース。

分散データベースの次の定義を示します。

分散データベース- これは、情報ネットワークのさまざまなノードに格納され、単一のデータセットを構成するように論理的にリンクされた情報、ファイル（関係）のコレクションです（リンクは機能するか、同じファイルのコピーを介して機能します）。したがって、これは論理的にリンクされたデータベースのセットですが、同じコンピューターネットワークの一部である複数のマシンに物理的に配置されています。

分散データベースの特性に関する最も重要な要件は次のとおりです。

スケーラビリティ;
互換性;
さまざまなデータモデルのサポート。
移植性;
場所の透明性;
分散データベースノードの自律性（サイト自律性）;
分散リクエストの処理。
分散トランザクションの実行。
同種のセキュリティシステムのサポート。

場所の透過性により、ユーザーは自分の場所について何も知らなくてもデータベースを操作できます。分散データベースノードの自律性は、各データベースが他のデータベースから独立して維持できることを意味します。分散クエリは、さまざまなデータベースのオブジェクト（テーブルまたはビュー）にアクセスするクエリ（SQLステートメント）です。分散トランザクションを実行する場合、関連するすべてのデータベースに対して同時実行制御が実行されます。 Oracle7は、2フェーズの情報転送テクノロジーを使用して分散トランザクションを実行します。

分散データベースを構成するデータベースは、同種である（つまり、同じDBMSで実行される）必要はなく、同じオペレーティングシステム環境や同じタイプのコンピューターで実行される必要もありません。たとえば、1つのデータベースはSUN OS（UNIX）を実行しているSUNコンピューター上のOracleデータベースであり、2番目のデータベースはMVSオペレーティングシステムを実行しているIBM3090メインフレーム上のDB2DBMSによって実行され、3番目のデータベースはによって実行されます。 SQL / DS DBMSもIBMメインフレーム上にありますが、VMオペレーティングシステムを使用しています。必須の条件は1つだけです。データベースを備えたすべてのマシンは、それらが属するネットワークを介してアクセスできる必要があります。

分散データベースの主なタスク –ネットワークを介したデータの配布と、ネットワークへのアクセスの提供。この問題を解決するには、次の方法があります。

各ノードは、リモートクエリに使用できる独自のデータセットを保存して使用します。この分布は分割されています。
リモートサイトで頻繁に使用される一部のデータが重複している可能性があります。このような分布は、部分複製と呼ばれます。
すべてのデータは各ノードで複製されます。このような配布は、完全冗長と呼ばれます。
一部のファイルは、水平方向（レコードのサブセットが選択されている）または垂直方向（属性フィールドのサブセットが選択されている）に分割できますが、分割されたサブセットは、分割されていないデータとともに異なるノードに保存されます。このような分布は分割（断片化）と呼ばれます。

概念レベルで分散データベースを作成する場合は、次のタスクを解決する必要があります。

ネットワーク全体に対して単一の概念スキームを用意する必要があります。これにより、ユーザーに論理的なデータの透過性が提供され、その結果、ユーザーは別の端末でデータベース全体に要求を作成できるようになります（いわば、集中型データベースで機能します）。
ネットワーク上のデータを見つけるにはスキーマが必要です。これにより、データ配置の透明性が確保されるため、ユーザーは、必要なデータを取得するためにリクエストを転送する場所を指定する必要がありません。
分散データベースの異質性の問題を解決する必要があります。分散データベースは、ハードウェアとソフトウェアの点で同種または異種の場合があります。分散データベースがハードウェアに関しては異質であるが、ソフトウェアに関しては同質である場合（ノード内の同じDBMS）、異質性の問題は比較的簡単に解決できます。分散システムのノードで異なるDBMSが使用されている場合は、データ構造と言語を変換する手段が必要です。これにより、分散データベースノードでの変換の透過性が提供されます。
辞書管理の問題を解決する必要があります。分散データベースであらゆる種類の透明性を提供するには、多数の辞書と参考書を管理するプログラムが必要です。
分散データベースでクエリを実行するためのメソッドを定義する必要があります。分散データベースでクエリを実行する方法は、集中データベースでの同様の方法とは異なります。これは、クエリの個々の部分を対応するデータの場所で実行し、部分的な結果を他のノードに転送する必要があるためです。同時に、すべてのプロセスの調整を確実にする必要があります。
クエリの並列実行の問題を解決する必要があります。分散データベースでは、並行処理を管理するための複雑なメカニズムが必要です。特に、情報が更新されたときに同期を確保する必要があり、データの一貫性が保証されます。
分割を含む、データの分散と配置のための開発された方法論の必要性は、分散データベースの主要な要件の1つです。

非数値情報処理のための強力なツールである、コンピュータシステムアーキテクチャの積極的に開発されている新しい分野の1つは次のとおりです。データベースマシン。データベースマシンは、ドキュメントやファクトの保存、検索、変換、オブジェクトの操作など、数値以外のタスクを解決するために使用されます。周囲の世界のオブジェクトに関するデジタルおよびグラフィック情報としてのデータの定義に従って、数値および非数値処理中にデータの概念にさまざまなコンテンツが埋め込まれます。数値処理では、変数、ベクトル、行列、多次元配列、定数などのオブジェクトが使用されますが、非数値処理では、ファイル、レコード、フィールド、階層、ネットワーク、関係などのオブジェクトが使用されます。数値処理は、従業員ファイル自体ではなく、オブジェクト（たとえば、特定の従業員または従業員のグループ）に関する情報に直接関係します。特定の人を選択するために従業員ファイルにインデックスを付けることはありません。ここでは、目的のレコードの内容に関心があります。膨大な量の情報は通常、非数値処理の対象になります。さまざまなアプリケーションで、このような操作はこのデータに対して実行できます。次に例を示します。

会社の全従業員の給与を上げる。
すべての顧客の口座の銀行利息を計算します。
在庫のあるすべての商品のリストを変更します。
図書館または書誌情報検索システムに保存されているすべてのテキストから必要な要約を見つけます。
法的文書を含むファイルで目的の契約の説明を見つけます。
特許の説明を含むすべてのファイルを表示し、再度提案されたものと同様の特許（存在する場合）を見つけます。

データベースエンジンを実装するには、並列および連想ユニプロセッサの代替としてのアーキテクチャフォンノイマン構造により、大量の情報をリアルタイムで処理できます。

データベースエンジンは、知識表現、エキスパートシステム、推論、パターン認識などの人工知能の概念の調査と適用に関連して重要性を増しています。

情報ストレージ。今日、多くの企業は、ほとんどの企業がすでにいくつかのデータベースを運用しており、情報をうまく処理するには、さまざまな種類のデータベースだけでなく、さまざまな世代のDBMSが必要であることを認識しています。統計によると、各組織は平均2.5の異なるDBMSを使用しています。企業情報、つまりこのビジネスに関係する人々をデータベースの技術的特徴から「分離」して、物理的に保存されている場所に関係なく、ユーザーに企業情報の単一のビューを提供する必要性が明らかになりました。。これは、情報ウェアハウジング技術の出現を刺激しました（データウェアハウジング、DW）。

DWの主な目標はさまざまなタイプのデータベースに含まれるデータの単一の論理表現、つまり単一の企業データモデルの作成。

情報技術全般の進歩、特に並列クエリ処理に基づく新しいタイプのデータベースの出現により、DW開発の新しいラウンドが可能になりました。これは、並列コンピューターの分野の進歩に依存していました。作成されましたクエリビルダー複雑なデータベースクエリの作成を容易にする直感的なグラフィカルインターフェイスを備えています。その他のソフトウェアミドルウェア提供されたコミュニケーション異なるタイプのデータベース間、そしてついに価格が急落した情報ストレージデバイス.

データバンクは、企業の構造に存在する場合があります。

データベース -自動制御システムおよび情報およびコンピューティングシステムの機能的および組織的コンポーネント。ユーザーのグループまたはシステムで解決された一連のタスクに一元化された情報サポートを提供します。

データベース情報および参照システムと見なされ、その主な目的は次のとおりです。

自動化システム全体の情報ベースを構成する一連の情報、またはその中で解決される特定の一連のタスクの作業状態での蓄積および保守。
タスクまたはユーザーが必要とするデータの発行。
保存された情報への集合的なアクセスを提供すること。
情報ベースに含まれる情報の使用の必要な管理を確実にすることにおいて.

したがって、最新のデータバンクは、技術、システム、ネットワークツール、データベースとDBMS、さまざまな目的の情報検索システムを含む、複雑なソフトウェアとハードウェアの複合体です。

V .2。企業システムにおけるDBMSと構造ソリューション

データベースと知識管理システム

最新の情報システムの重要なコンポーネントは、データベース管理システム（DBMS）です。

DBMS -データベースを作成、維持、使用するために設計されたソフトウェアと言語ツールのセット。

データベース管理システムは、データ処理システムにデータベースへのアクセスを提供します。すでに述べたように、DBMSの重要な役割は、企業の情報システムの作成において獲得され、特に、最新のネットワークコンピューター技術に基づく分散情報リソースを使用した情報システムの作成において重要な役割を果たします。

最新のDBMSの主な機能は、最新のDBMSが次のようなテクノロジーをサポートしていることです。

クライアント/サーバーテクノロジー。
データベース言語のサポート。このスキーマ定義言語 DB （SDL-スキーマ定義言語）、データ操作言語（DML-データ操作言語）、統合言語 SQL（Structured Queue Language）、QDB（Query-By-Example）およびQMF（Query Management Facility ）は、クエリの指定とレポートの生成のための高度な周辺ツールです。 DB2など。
外部メモリ内のデータの直接管理。
メモリバッファ管理。
トランザクション管理。 OLTPテクノロジー（オンライントランザクション処理）、OLAP-テクノロジー（オンライン分析処理） DW用。
データの保護と整合性を確保します。システムの使用は、データにアクセスする権利を持っているユーザーにのみ許可されています。ユーザーがデータに対して操作を実行すると、保存されたデータの整合性（整合性）が維持されます。これは、企業のマルチユーザー情報システムでは重要です。
ジャーナル化。

最新のDBMSは、上記のデータベース要件を満たしている必要があります。さらに、次の原則に準拠する必要があります。

データの独立性。
汎用性。カスタム論理ビューを表示するには、DBMSが概念データモデルを強力にサポートしている必要があります。
互換性。 DBMSは、ソフトウェアとハードウェアの開発で動作し続ける必要があります。
データの冗長性。ファイルシステムとは異なり、データベースは単一の統合データセットである必要があります。
データ保護。 DBMSは、不正アクセスに対する保護を提供する必要があります。
データの整合性。 DBMSは、ユーザーがデータベースを改ざんするのを防ぐ必要があります。
並行作業の管理。 DBMSは、共有アクセスモードの不整合からデータベースを保護する必要があります。データベースの一貫した状態を保証するには、すべてのユーザー要求（トランザクション）を特定の順序で実行する必要があります。
DBMSはユニバーサルである必要があります。単一の論理的および物理的ベースでさまざまなデータモデルをサポートする必要があります。
DBMSは、集中型データベースと分散型データベースの両方をサポートする必要があるため、コンピュータネットワークの重要なリンクになります。

自動化されたシステムでデータベースを維持することに焦点を当てたソフトウェア製品のクラスとしてDBMSを考えると、DBMSのタイプを決定する最も重要な機能の2つを区別できます。彼らによると、DBMSは2つの観点から考えることができます。

分散（企業）データベースに関連するそれらの機能。
DBMSに実装されているデータモデルのタイプとの関係。

企業（分散）データベースに関連して、従来、次のタイプのDBMSを区別できます。

DBMS「デスクトップ」。これらの製品は、主に個人データ（デスクトップデータ）の操作に重点を置いています。共通のデータベースを共有するためのコマンドセットがありますが、サイズが小さい（小規模オフィスタイプ）。まず第一に、それはAccess、dBASE、Paradox、ExProのようなDBMSです。 Access、dBASE、Paradox、ExProが企業データにアクセスしにくい理由。事実、個人データと企業データの間の障壁を克服する簡単な方法はありません。そして、重要なのは、個人データDBMS（または小規模オフィス）のメカニズムが、多くのゲートウェイ、ゲートウェイ製品などを介したデータへのアクセスに焦点を合わせているということですらありません。問題は、これらのメカニズムには通常、完全なファイル転送と広範なインデックスサポートの欠如が含まれ、大規模なシステムではサーバーへのキューが実質的に停止することです。
特殊な高性能マルチユーザーDBMS。このようなDBMSは、マルチユーザーシステムカーネル、データ操作言語、および開発されたマルチユーザーDBMSに典型的な次の機能の存在を特徴としています。
バッファプールの編成。
トランザクションキューを処理するためのシステムの存在。
マルチユーザーデータブロッキングのメカニズムの存在。
トランザクションログ;
アクセス制御メカニズムの可用性。

これらは、Oracle、D²、SQL / Server、Informix、Sybase、ADABAS、TitaniumなどのDBMSであり、企業データベースを処理するための幅広いサービスを提供します。

データベースを操作する場合、トランザクションのメカニズムが使用されます。

取引論理的な作業単位です。

取引実行されるデータ操作ステートメントのシーケンスです一つとして（オールオアナッシング）およびデータベースの翻訳ある積分状態から別の積分状態へ.

トランザクションには、ASIDプロパティと呼ばれる4つの重要なプロパティがあります。

（A）原子性。トランザクションはアトミック操作として実行されます。トランザクション全体が実行されるか、トランザクション全体が実行されません。
（C）一貫性。トランザクションは、データベースをある一貫性のある（一貫性のある）状態から別の一貫性のある（一貫性のある）状態に移動します。トランザクション内では、データベースの一貫性が失われる可能性があります。
（I）分離。異なるユーザーのトランザクションは、互いに干渉してはなりません（たとえば、厳密に順番に実行されたかのように）。
（D）耐久性。トランザクションが完了すると、次の瞬間にシステムがクラッシュした場合でも、その作業の結果をデータベースに保存する必要があります。

トランザクションは通常、ユーザーがDBMSに参加した瞬間から自動的に開始され、次のいずれかのイベントが発生するまで続きます。

COMMIT WORKコマンドが発行されました（トランザクションをコミットするため）。
ROLLBACKWORKコマンドが発行されました。
ユーザーがDBMSから切断しました。
システムに障害が発生しました。

ユーザーにとって、彼女は通常着ていますアトミックキャラクター。実際、これはユーザー（アプリケーション）とデータベース間の相互作用の複雑なメカニズムです。エンタープライズシステムソフトウェアは、リアルタイムトランザクション処理エンジンを使用します（オンライントランザクション処理システム、OLTP）、特に会計プログラム、クライアントアプリケーション、財務アプリケーションを受信および処理するためのソフトウェアは、多くの情報を生成します。これらのシステムは、大量のデータ、複雑なトランザクション、および集中的な読み取り/書き込み操作を処理するために設計されています（適切に最適化されています）。

残念ながら、OLTPシステムのデータベースに配置された情報は、通常のユーザーによる使用にはあまり適していません（高度なテーブルの正規化、特定のデータ表示形式、およびその他の要因のため）。したがって、さまざまな情報パイプラインからのデータが（コピーされるという意味で）に送信されますストレージ倉庫、並べ替えとその後の消費者への配達。情報技術では、倉庫の役割は情報ストレージ。

エンドユーザーへの情報の配信-リアルタイムの分析データ処理のシステムが使用されます（オンライン分析処理、OLAP）、クエリを生成して結果を分析するための便利なツールを介して、データへの非常に簡単なアクセスを提供します。 OLAPシステムでは、さまざまな分析方法や統計処理を使用することで、情報製品の価値が高まります。さらに、これらのシステムは、データ抽出速度、一般化された情報の収集に関して最適化されており、通常のユーザーに焦点を合わせています（直感的なインターフェイスを備えています）。もしも OLTPシステム「199x年1月の地域Mでの製品Nの売上高はどのくらいでしたか？」などの簡単な質問に答えます。 OLAPシステムたとえば、「過去2年間と比較した、第2四半期の計画に従って、すべての地域の製品Nの売上を分析します。」などのより複雑なユーザー要求に対応できます。

クライアント/サーバーアーキテクチャ

最新のシステムでは分散情報処理テクノロジーが中心になりますクライアントサーバー。システム内クライアント/サーバーアーキテクチャデータ処理はクライアントコンピュータとサーバーコンピュータの間で分割され、それらの間の通信はネットワークを介して行われます。このデータ処理プロセスの分離は、機能のグループ化に基づいています。通常、データベースサーバーコンピューターはデータベース操作の実行専用であり、クライアントコンピューターはアプリケーションプログラムを実行します。図2.1は、サーバーとして機能するコンピューターとそのクライアントとして機能する別のコンピューターを含む単純なクライアント/サーバーアーキテクチャシステムを示しています。各マシンは異なる機能を実行し、独自のリソースを持っています。

		データベース
サーバーコンピューター
ネット
IBM互換PC	IBM互換PC	IBM互換PC
		アプリケーション

米。 2.1。クライアント/サーバーアーキテクチャシステム

クライアントコンピューターの主な機能は、アプリケーション（ユーザーインターフェイスとプレゼンテーションロジック）を実行し、アプリケーションで必要なときにサーバーと通信することです。

サーバ -これは、他のオブジェクトの要求に応じてサービスを提供するオブジェクト（コンピューター）です。

この用語が示すように、サーバーコンピュータの主な機能は、クライアントのニーズに対応することです。「サーバー」という用語は、ファイルサーバーとデータベースサーバーの2つの異なる機能グループを指すために使用されます（以下、これらの用語は、コンテキストに応じて、これらの機能グループを実装するソフトウェア、またはこのソフトウェアを搭載したコンピューターのいずれかを意味します。）。ファイルサーバーはデータベース操作を実行するようには設計されていません。その主な機能は、複数のユーザー間でファイルを共有することです。多くのユーザーがコンピューター上のファイル（ファイルサーバー）に同時にアクセスできるようにします。ファイルサーバーの例は、NovellのNetWareオペレーティングシステムです。データベースサーバーは、ファイルサーバーコンピューターにインストールして実行できます。 NLM（Network Loadable Module）形式のOracle DBMSは、ファイルサーバー上のNetWare環境で実行されます。

ローカルネットワークサーバーには、その機能目的とネットワークのニーズに対応するリソースが必要です。オープンシステムアプローチを志向しているため、必ずしも別のコンピューターに配置されているとは限らない論理サーバー（これらのリソースを介してサービスを提供する一連のリソースとソフトウェアツールを意味します）について話す方が正しいことに注意してください。オープンシステムの論理サーバーの機能は、効率の理由から、サーバーを別のコンピューターに移動するのが適切な場合、サーバー自体とアプリケーションの両方を変更することなく実行できることです。それを使用するプログラム。

重要なサーバー要件の1つは、データベースサーバーがホストされているオペレーティングシステムがマルチタスク（および、必ずしもそうである必要はありませんが、マルチユーザー）である必要があることです。たとえば、マルチタスクの要件を満たさないMS-DOS（またはPC-DOS）オペレーティングシステムを搭載したパーソナルコンピュータにインストールされたOracle DBMSは、データベースサーバーとして使用できません。また、マルチタスク（マルチユーザーではない）OS / 2オペレーティングシステムを搭載したコンピュータにインストールされている同じOracleDBMSをデータベースサーバーにすることができます。 UNIX、MVS、VM、およびその他のオペレーティングシステムの多くの種類は、マルチタスクとマルチユーザーの両方です。

分散コンピューティング

「分散コンピューティング」という用語は、補完的ではありますが、2つの異なる概念を指すためによく使用されます。

分散データベース;
分散データ処理。

これらの概念を適用することで、さまざまな手段を使用して、エンドユーザーが複数のマシンに保存されている情報へのアクセスを整理できます。

サーバーには多くの種類があります。

データベースサーバー;
プリントサーバー;
リモートアクセスサーバー;
ファックスサーバー;
Webサーバーなど

クライアント/サーバーテクノロジーの中核次のような基本的なテクノロジーがあります。

オペレーティングシステムのテクノロジー、オープンシステムの相互作用の概念、プログラムの機能のためのオブジェクト指向環境の作成。
電気通信技術;
ネットワークテクノロジー;
グラフィカルユーザーインターフェイステクノロジー（ GUI）;
等。

クライアント/サーバーテクノロジの利点：

クライアント/サーバーテクノロジーにより、異種コンピューティング環境でのコンピューティングが可能になります。プラットフォームの独立性：さまざまなオペレーティングシステムを搭載したさまざまな種類のコンピューターを含む、異種ネットワーク環境へのアクセス。
データソースからの独立性：異種データベースからの情報へのアクセス。このようなシステムの例としては、DB2、SQL / DS、Oracle、Sybaseがあります。
クライアントとサーバー間の負荷分散。
最も効率的に発生する場所で計算を実行します。
効率的なスケーリング機能を提供します。
クロスプラットフォームコンピューティング。クロスプラットフォームコンピューティングは、単にヘテロジニアスコンピューティング環境でのテクノロジーの実装として定義されています。ここでは、次のオプションを提供する必要があります。
アプリケーションは複数のプラットフォームで実行する必要があります。
すべてのプラットフォームで、同じインターフェースと作業ロジックを備えている必要があります。
アプリケーションは、ネイティブオペレーティング環境と統合する必要があります。
すべてのプラットフォームで同じように動作する必要があります。
シンプルで一貫性のあるサポートが必要です。

 分散コンピューティング。分散コンピューティングは、複数のコンピューター間での作業の分散を提供します（ただし、分散コンピューティングはより広い概念です）。

 ダウンスケーリング。ダウンスケーリングとは、メインフレームアプリケーションを小さなコンピュータープラットフォームに転送することです。

インフラストラクチャとハードウェアのコストを削減します。費用対効果：低コストのコンピューティングハードウェアの可用性とローカルエリアネットワークの普及により、クライアントサーバーテクノロジーは他のデータ処理テクノロジーよりも費用対効果が高くなっています。機器は必要に応じてアップグレードできます。

 アプリケーション全体の実行時間を短縮します。

 クライアントのメモリ使用量を削減。

 ネットワークトラフィックの削減。

マルチメディアを操作する機能：これまで、PC用のマルチメディアを操作するための多くのプログラムが作成されてきました。ターミナルホスト構成用のそのようなプログラムがないか、非常に高価です。
データベース操作により多くのコンピューティングリソースを使用する機能：アプリケーションはクライアントコンピューターで実行されるため、CPUや操作リソースなどのデータベース操作のためにサーバーコンピューター上で追加の（ターミナルホスト構成と比較して）リソースが解放されます。
プログラマーの生産性の向上：SQL * FormsやCASEなどのツールを使用して、C、PL1、COBOLなどのプログラミング言語よりも高速にアプリケーションを開発することで、プログラマーの生産性が向上します。
エンドユーザーの生産性の向上：今日、多くのエンドユーザーは、Lotus、Paradox、Word Perfect、HarvardGraphicsなどのシステムを採用しています。

バックエンドインターフェイスが定義され、修正されています。したがって、既存のシステムの新しいクライアント部分を作成することができます（システムレベルでの相互運用性の例）。

米。 2.2。サーバー共有へのクライアントアクセスの図。

クライアント/サーバーテクノロジを実装する方法

クライアント/サーバーテクノロジに基づいており、分散データ処理が可能なシステムのインストールについては、以下で説明します。次のコンピューターのハードウェアとソフトウェアが必要です。

データベースサーバーコンピューター;
クライアントコンピューター;
通信ネットワーク;
ネットワークソフトウェア;
アプリケーションソフトウェア。

SQL言語。高水準クエリ言語- SQL（構造化照会言語））は、NMD、NDL、PJDなどのデータベースへのクエリを実装するために使用され、標準として採用されています。言語 SQL もともとは会社のソフトウェア製品のデータ言語として採用されました IBM およびリレーショナルDBMSのYMD IBMによるSYSTEMR 。言語の重要な特徴 SQL 同じ言語が2つの異なるインターフェース、つまり、対話型インターフェースとアプリケーションプログラミングインターフェース（動的）を介して表されるということです。 SQL）。動的SQL 多くの組み込み言語機能で構成されています SQL 、インタラクティブアプリケーションを構築するために特別に提供されます。インタラクティブアプリケーションは、インタラクティブ端末で実行されているエンドユーザーによるデータベースへのアクセスをサポートするように作成されたプログラムです。言語 SQL データベースデータを定義、操作、および管理する機能を提供し、実装されたDBMSの観点からユーザーに透過的です。

米。 2.3。分散データベースへのユーザー要求を実行するためのスキーム。

データベースの内部構造は、使用されるデータモデルによって決定されます。概念モデルには、外部モデルよりも多くの抽象化機能と豊富なセマンティクスがあります。外部モデルは、多くの場合、構文モデルまたは運用モデルと呼ばれ、データベースとのユーザー対話の手段としての管理およびアプリケーションの構文上の性質を指します。情報モデリングには、概念モデルのレベルから物理データモデルのレベルまで、DBMSのアーキテクチャに影響を与えるさまざまなレベルの抽象化があります。

データモデルは、次の3つのコンポーネントで構成されています。

データベース上でユーザーの観点から表すデータ構造。
データ構造に対して実行される有効な操作。さまざまなDDLおよびNML操作を使用してこの構造を操作できる必要があります。豊富な構造は、その内容を操作できなければ意味がありません。
整合性制御の制約。データモデルには、その整合性を維持し、保護するための手段を提供する必要があります。例として、次の2つの制約について考えてみます。
各サブツリーにはソースノードが必要です。階層型データベースは、親ノードなしで子ノードを格納することはできません。
リレーショナルデータベースに関連して、同一のタプルが存在することはできません。ファイルの場合、この要件では、すべてのレコードが一意である必要があります。

DBMSの最も重要な特性の1つは、オブジェクトをリンクする機能です。

オブジェクト間のリンクには、次のタイプがあります。

1対1（1：1）。あるセットの1つのオブジェクトは、別のセットの1つのオブジェクトに関連付けることができます。
1対多（1：M）。あるセットの1つのオブジェクトは、別のセットの多くのオブジェクトに関連付けることができます。
多対多（M：N）。あるセットの1つのオブジェクトを別のセットの多くのオブジェクトに関連付けることができますが、同時に、別のセットの1つのオブジェクトを最初のセットの多くのオブジェクトに関連付けることができます。
分岐。 1つのセットの1つのオブジェクトは、多くのセットのオブジェクトに関連付けることができます。
再帰的。特定のセットの1つのオブジェクトを、同じセットのオブジェクトに関連付けることができます。

次の主なデータモデルがあります。

リレーショナルデータモデル。
階層データモデル。
不完全なネットワークデータモデル。
CODASYLデータモデル。
拡張ネットワークデータモデル。

V.3。インターネット/イントラネットテクノロジーおよび企業のデータベースアクセスソリューション

「クライアントサーバー」アーキテクチャに基づくシステムの主な問題は、オープンシステムの概念に従って、オープンシステムのハードウェアおよびソフトウェアソリューションの可能な限り幅広いクラスでモバイルである必要があることです。 UNIXベースのローカルエリアネットワークに限定したとしても、ネットワークが異なれば、使用する機器や通信プロトコルも異なります。考えられるすべてのプロトコルをサポートするシステムを作成しようとすると、機能が犠牲になり、ネットワークの詳細が過負荷になります。

この問題のさらに複雑な側面は、異種ローカルネットワークのさまざまなノードでデータのさまざまな表現を使用する可能性に関連しています。コンピュータが異なれば、アドレス指定、数値の表現、文字エンコードなども異なる場合があります。これは、通信、コンピューティング、データベースなどの高レベルのサーバーにとって特に重要です。

「クライアントサーバー」アーキテクチャに基づくシステムのモビリティの問題に対する一般的な解決策は、リモートプロシージャコールプロトコル（RPC-リモートプロシージャコール）を実装するソフトウェアパッケージに依存することです。これらのツールを使用すると、リモートホストでサービスを呼び出すことは、通常のプロシージャ呼び出しのように見えます。もちろん、RPCツールには、ローカルネットワーク機器とネットワークプロトコルの詳細に関するすべての情報が含まれており、呼び出しを一連のネットワーク相互作用に変換します。したがって、ネットワーク環境とプロトコルの詳細は、アプリケーションプログラマからは見えません。

リモートプロシージャが呼び出されると、RPCプログラムはクライアントデータ形式を中間のマシンに依存しない形式に変換してから、サーバーデータ形式に変換します。応答パラメーターを渡す場合、同様の変換が実行されます。

you.vshm>に興味があるかもしれない他の関連する作品
6914.		データベースの概念	11.56KB
	データベースは、裁判所の決定の規範的行為の計算の記事の客観的な形で提示された独立した資料のセットであり、これらの資料がロシア連邦の電子コンピュータ民法典を使用して見つけて処理できるように体系化された他の同様の資料美術。特定のルールに従って編成され、コンピュータのメモリに保持されているデータベース、一部の現在の状態を特徴付けるデータのセット...
8064.		分散データベース	43.66KB
	分散データベース分散RDBデータベースは、コンピューターネットワークのさまざまなノードに物理的に分散された論理的に相互接続された共有データのセットです。データアクセスは、データレプリカの有無に依存してはなりません。システムは、データ結合結合を実行する方法、転送される情報量を処理できるネットワークリンク、およびテーブルを結合するのに十分な処理能力を持つノードを自動的に決定する必要があります。 RDBMSは次の機能を備えている必要があります...
20319.		データベースとその保護	102.86KB
	オンラインオンラインデータベースは1960年代半ばに登場しました。運用データベースの操作は、端末を使用してインタラクティブに処理されました。単純なインデックスシーケンシャルレコード編成は、より強力なセット指向のレコードモデルに急速に進化しました。 Charles Bachmannは、データの記述とデータの操作のための標準言語を開発したデータベースタスクグループ（DBTG）の作業を主導したことでチューリング賞を受賞しました。
5031.		データベース開発ライブラリ	11.72MB
	データベース設計技術。エンティティ間の関係を定義し、データモデルを作成します。現代の情報技術の主なアイデアは、変化する現実の世界を適切に反映し、ユーザーの情報ニーズを満たすために、データをデータベースに編成する必要があるという概念に基づいています。これらのデータベースは、DBMSデータベース管理システムと呼ばれる特別なソフトウェアシステムの制御下で作成および運用されます。
13815.		階層型データベースモデル	81.62KB
	現代の情報技術の主なアイデアはデータベースの概念に基づいており、情報技術の基礎は、特定の主題分野の状態を適切に反映し、この主題分野の関連情報をユーザーに提供するデータベースに編成されたデータです。データは...
14095.		図書館データベースの開発	11.72MB
	保存されたデータの量と構造の複雑さの増加、情報システムのユーザーの輪の拡大により、最も便利で比較的理解しやすいリレーショナル（表形式）DBMSが広く使用されるようになりました。
5061.		ポリクリニックデータベースの作成	2.4MB
	コンピュータ技術と情報技術の発展は、さまざまな目的のための自動化情報システム（AIS）の作成と普及の機会を提供してきました。経済的および技術的施設を管理するための情報システムが開発され、実施されている
13542.		地質情報のデータベース	20.73KB
	最近、科学分野へのコンピューター技術、特にデータベースの導入が急速に進んでいます。大量の情報を保存して処理する必要があるのは自然科学であるため、このプロセスも地質学をバイパスしません。
9100.		データベース。基本概念	26.28KB
	データベースは、経済学、経営学、化学など、あらゆる分野の現実世界の特定のオブジェクトに関する情報のコレクションです。情報システムの目的は、オブジェクトに関するデータを保存するだけでなく、これらのデータを操作して取得することです。オブジェクト間の関係を考慮に入れます。各オブジェクトは、データベースでは属性と呼ばれるデータプロパティのセットによって特徴付けられます。
5240.		データベース「大学の学部長室」の作成	1.57MB
	データベース（DB）は、1つまたは複数のアプリケーションに最適な方法で使用できるように、そのような構成と最小限の冗長性を備えたコンピューターの外部ストレージメディアに一緒に格納された相互に関連するデータのコレクションです。

業界データモデル

モデルの主な目的は、データスペースでの方向付けを容易にし、ビジネス開発に重要な詳細を強調するのに役立つことです。今日のビジネス環境では、さまざまなコンポーネント間の関係を明確に理解し、組織の全体像を十分に理解することが絶対に必要です。モデルを使用してすべての詳細と関係を特定することにより、会社の作業を整理するための時間とツールを最も効率的に使用できます。

データモデルは、データの意味を一意に定義します。この場合、データは構造化データです（値があいまいになる可能性がある画像、バイナリファイル、テキストなどの非構造化データとは対照的です）。

原則として、より高いレベル（およびより一般的なコンテンツ）とより低いレベル（それぞれ、より詳細）のモデルが区別されます。モデリングの上位レベルは、いわゆる 概念データモデル（概念データモデル）。これは、企業または組織の機能の最も一般的な全体像を示します。概念モデルには、組織の機能にとって重要な主要な概念または主題領域が含まれます。通常、それらの数は12〜15を超えません。このようなモデルは、組織にとって重要なエンティティのクラス（ビジネスオブジェクト）、それらの特性（属性）、およびこれらのクラスのペア間の関連付け（つまり関係）を記述します。ビジネスモデリングの用語はまだ完全には決まっていないため、さまざまな英語のソースでは、概念データモデルはサブジェクトエリアモデル（サブジェクトエリアモデルとして変換可能）またはサブジェクトエンタープライズデータモデル（サブジェクト企業データモデル）と呼ばれることもあります。）。

次の階層レベルは 論理データモデル（論理データモデル）。これらは、エンタープライズデータモデルまたはビジネスモデルと呼ばれることもあります。これらのモデルには、データ構造、それらの属性、およびビジネスルールが含まれており、ビジネスの観点から企業が使用する情報を表します。このようなモデルでは、データはエンティティとそれらの間の関係の形で編成されます。論理モデルは、ビジネスユーザーが簡単に理解できるようにデータを表します。論理モデルでは、データディクショナリを割り当てることができます。これは、正確な定義を持つすべてのエンティティのリストです。これにより、さまざまなカテゴリのユーザーがモデルのすべての入力フローと情報出力フローを共通に理解できます。次の下位レベルのモデリングは、特定のソフトウェアツールと技術プラットフォームを使用した論理モデルの物理的な実装です。

論理モデルには、通常、正規化されたモデルの形式をとる詳細なエンタープライズビジネスの決定が含まれます。正規化は、モデル内の各データ要素が1つの値のみを持ち、主キーに完全かつ一意に依存することを保証するプロセスです。データ要素は、一意の識別に従ってグループに編成されます。データ要素を制御するビジネスルールは、それらの有効性と正確性を事前にチェックして、正規化されたモデルに完全に含まれている必要があります。たとえば、顧客名などのデータ要素は、ほとんどの場合、名と姓に分割され、他の関連するデータ要素とともに、顧客IDの主キーを持つ顧客エンティティにグループ化されます。

論理データモデルは、データベース、ネットワーキング、レポートツールなどのアプリケーションテクノロジとそれらの物理的な実装から独立しています。組織は、エンタープライズデータモデルを1つだけ持つことができます。論理モデルには通常、何千ものエンティティ、関係、および属性が含まれます。たとえば、金融機関や電気通信会社のデータモデルには、約3,000の業界概念が含まれている場合があります。

論理データモデルとセマンティックデータモデルを区別することが重要です。論理データモデルは企業のビジネスソリューションを表し、セマンティックデータモデルは適用されたビジネスソリューションを表します。同じ企業論理データモデルは、異なるセマンティックモデルを使用して実装できます。セマンティックモデルは、物理モデルに近づくモデリングの次のレベルと見なすことができます。さらに、これらの各モデルは、さまざまなアプリケーションの要件に応じて、企業データモデルの個別の「スライス」を表します。たとえば、企業の論理データモデルでは、エンティティClientは完全に正規化され、データマートのセマンティックモデルでは、多次元構造として表すことができます。

企業は、エンタープライズ論理データモデルを作成する2つの方法があります。それは、自分で構築するか、既製のものを使用することです。 業界モデル（業界の論理データモデル）。この場合、用語の違いは、同じ論理モデルを構築するための異なるアプローチのみを反映しています。企業が独自に論理データモデルを開発して実装する場合、そのようなモデルは、原則として、単に企業論理モデルと呼ばれます。組織がプロのサプライヤーの完成品を使用することを決定した場合、業界の論理データモデルについて話すことができます。後者は、特定の業界の機能を高い精度で反映する既製の論理データモデルです。業界の論理モデルは、戦略的および戦術的なビジネス上の質問に答えるためにエンタープライズデータウェアハウスに存在する必要があるすべての情報のドメイン固有の統合ビューです。他の論理データモデルと同様に、業界モデルはアプリケーションソリューションに依存しません。また、データ検索を高速化するための派生データやその他の計算も含まれていません。原則として、そのようなモデルの論理構造のほとんどは、その効果的な物理的実装において優れた実施形態を見つけます。このようなモデルは、金融、製造、観光、ヘルスケア、保険など、さまざまな分野の多くのベンダーによって開発されています。

業界の論理データモデルには、業界に共通する情報が含まれているため、企業にとって完全なソリューションにはなりません。ほとんどの企業は、データ要素を追加して定義を拡張することにより、モデルを平均25％増やす必要があります。完成したモデルには主要なデータ要素のみが含まれ、残りの要素は、会社にモデルをインストールするときに適切なビジネスオブジェクトに追加する必要があります。

業界の論理データモデルには、かなりの数の抽象化が含まれています。抽象化とは、イベントや参加者などの一般的な名前での同様の概念の結合を指します。これにより、業界モデルに柔軟性が追加され、より統一されます。したがって、イベントの概念はすべての業界に適用できます。

ビジネスインテリジェンスの専門家であるSteveHobermanが、業界データモデルを購入するかどうかを決定する際に考慮すべき5つの要素について概説します。 1つ目は、モデルの構築に必要な時間とリソースです。組織が結果を迅速に達成する必要がある場合は、業界モデルが有利になります。業界モデルを使用しても、組織全体の全体像をすぐに把握できるとは限りませんが、時間を大幅に節約できます。実際のモデリングの代わりに、既存の構造を業界モデルにリンクし、組織のニーズに合わせて最適にカスタマイズする方法（たとえば、どの定義を変更し、どのデータ要素を追加するか）について話し合うことに時間を費やします。

2番目の要素は、モデルの稼働を維持するために必要な時間と費用です。エンタープライズデータモデルが正確で最新の状態を維持する方法論の一部でない場合、モデルはすぐに時代遅れになります。業界データモデルは、外部リソースによって最新の状態に保たれているため、このリスクを防ぐことができます。もちろん、組織内で発生した変更は、会社自体がモデルに反映する必要がありますが、業界の変更は、サプライヤによってモデルに再現されます。

3番目の要素は、リスク評価とモデリングの経験です。エンタープライズデータモデルを作成するには、ビジネススタッフとITスタッフの両方からの熟練したリソースが必要です。原則として、マネージャーは組織全体の仕事、または特定の部門の活動のいずれかをよく知っています。彼らの中には、彼らのビジネスについて幅広い（全社的）知識と深い（ユニット全体的）知識の両方を持っている人はほとんどいません。ほとんどのマネージャーは通常、1つの領域しかよく知っていません。したがって、全社的な全体像を把握するためには、多大な経営資源が必要です。これにより、ITスタッフの要件も高まります。モデルの作成とテストに必要なビジネスリソースが多いほど、アナリストはより経験豊富である必要があります。彼らは、ビジネス担当者から情報を取得する方法を知っているだけでなく、物議を醸している分野の共通点を見つけ、これらすべての情報を統合された方法で提示できなければなりません。モデルを作成する人（多くの場合、これは同じアナリストです）は、優れたモデリングスキルを持っている必要があります。企業のロジックモデルを作成するには、「将来に向けた」モデリングと、複雑なビジネスを文字通り「正方形と線」に変換する機能が必要です。

一方、業界モデルでは、サードパーティのスペシャリストの経験を利用できます。業界固有のロジックモデルは、実績のあるモデリング手法と経験豊富な専門家のチームを使用して、組織内でエンタープライズデータモデルを開発するときに発生する可能性のある一般的でコストのかかる問題を回避します。

4番目の要素は、既存のアプリケーションインフラストラクチャとベンダーの関係です。組織がすでに同じベンダーの多くのツールを使用していて、それらとの関係を確立している場合は、それらから業界モデルを注文することも理にかなっています。このようなモデルは、同じサプライヤーの他の製品と自由に連携できるようになります。

第五の要因は、産業内の情報交換です。企業が同じ分野で活動している他の組織とデータを共有する必要がある場合、業界モデルはこの状況で非常に役立ちます。同じ業界内の組織は、同様の構造コンポーネントと用語を使用しています。今日、ほとんどの業界では、企業はビジネスを成功させるためにデータを共有することを余儀なくされています。

プロのベンダーが提供する業界モデルが最も効果的です。これらのモデルの非常に高いレベルの詳細と精度により、それらの使用の高い効率が達成されます。通常、これらには多くのデータ属性が含まれています。さらに、これらのモデルの作成者は、モデリングの豊富な経験があるだけでなく、特定の業界向けのモデルの構築にも精通しています。

業界データモデルは、企業にビジネス情報の単一の統合されたビューを提供します。多くの企業は、データを統合することが難しいと感じていますが、これはほとんどの企業全体のプロジェクトの前提条件です。データウェアハウスインスティテュート（TDWI）の調査によると、調査対象の組織の69％以上が、統合が新しいアプリケーションの採用に対する重大な障壁であると感じています。それどころか、データ統合の実装は会社にかなりの収入をもたらします。

業界データモデルは、既存のシステムとのリンクに加えて、エンタープライズリソースプランニング（ERP）、マスターデータ管理、ビジネスインテリジェンス、データ品質の向上、従業員の育成など、企業全体のプロジェクトに大きなメリットをもたらします。

したがって、業界の論理データモデルは、データを統合し、ビジネスの全体像を把握するための効果的なツールです。論理モデルの使用は、企業のデータウェアハウスの作成に向けた必要なステップのようです。

出版物

スティーブホバーマン。業界の論理データモデルをエンタープライズデータモデルとして活用する
クラウディア・イムホフ。インテリジェントデータモデリングによるデータウェアハウジングおよびビジネスインテリジェンスプロジェクトの迅速な追跡

この記事では、データウェアハウスのアーキテクチャに焦点を当てます。それを構築するときに何をガイドするか、どのアプローチが機能するか、そしてその理由。

「おとぎ話は嘘ですが、そこにはヒントがあります...」

祖父が植えた...ストレージ。そして、倉庫はどんどん大きくなりました。私はそれがどのように機能するのか本当に知りませんでした。そして祖父はレビューを始めました。祖父は家族評議会のために祖母、孫娘、猫とネズミを呼びました。そして、彼は次のトピックについて述べています。すべてのシステムからのデータが群がり、テーブルは表示および非表示になります。ユーザーはレポートを作成します。すべてが順調であるように思われます-生きて生きること。はい、ただ1つの悲しみ-それがどのように機能するか誰も知りません。それは明らかにディスクを必要とします-目に見えない-あなたは十分に得ることができません！そして、さまざまな不満を持って私に来るユーザーがいます：レポートがフリーズするか、データが古くなっています。そして時にはそれはかなりの惨事です-私たちは皇帝の父への報告を持っていますが、数字は互いに一致していません。時間は均等ではありません-王は怒ります-そしてあなたの頭を取り壊さないでください-私にとってもあなたにとっても。だから私はあなたを集めて相談することにしました：私たちは何をするつもりですか？

彼は集会に目を向けて尋ねました：
-おばあちゃん、ここにいます。私たちのストレージがどのように配置されているか知っていますか？
-いいえ、おじいさん、わかりません。そして、私はどのように知る必要がありますか？あそこには、なんと勇敢な若者たちが彼を守っています！いくつかの口ひげ！ステップアップしないでください。どういうわけか、焼きたてのパイを訪ねてきました。そして、彼らはいくつかのパイを食べ、口ひげを拭き、こう言いました。あなたのストレージは何ですか？必要なレポートの種類を教えてください-私たちはあなたのためにそれを行います！あなたは最も重要なことに、より頻繁にパイを持ってきます！痛々しいほど、彼らはおいしいです。」
-そして、私の最愛の孫娘であるあなたは、私たちのストレージがどのように配置されているか知っていますか？
-いいえ、おじいさん、わかりません。私にそれへのアクセスを与えてくれました。私は接続しました、私は見ます-そしてテーブルがあります-明らかに見えません。そして、さまざまなスキームが隠されています。目が大きくなる…。最初は戸惑いました。そして、私はよく調べました-それらのいくつかは空で、他は満たされていますが、半分だけです。また、データが繰り返されているようです。このような冗長性を備えたディスクを買いだめできないのも不思議ではありません。
-さて、あなた、猫、私たちのストレージについて何を言うことができますか？何か良いものはありますか？
-はい、おじいさん、言わないでください-私は言います。孫娘の依頼で、小さな陳列ケースという別の計画でパイロットパイロットを作ろうとしました。どのような貿易が私たちの州にとって有益であるか、どの製品が商人にとって有益であるかを理解するために、彼らは敬意を表します-財務省は補充されます。そして、どれが悪いのか。そして、私はこのリポジトリからデータを取得し始めました。収集された事実。そして彼はそれらを製品と比較しようとし始めました。そして、祖父、私が見たもの-製品は同じように見えますが、あなたは兆候を見てください-それらは異なっています！それから私は孫娘の櫛でそれらをとかし始めました。彼はひっかき、ひっかき、そして目を愛撫しながら、一定の均一性をもたらしました。しかし、早い段階で私は喜びました-翌日、ウィンドウ内の素晴らしいデータを更新するためにスクリプトを起動しました-そしてすべてが私のために消えました！ "どうして？" -私は思う-孫娘は動揺するだろう-今日は私たちのパイロットを大臣に見せなければならないだろう。そのようなデータを使用して、どのように対処しますか？
-はい、悲しい話、猫、あなたは言います。さて、あなた、小さなマウス、あなたは本当に金庫について調べようとしませんでしたか？あなたは活気があり、機敏で、社交的な女の子です！何を教えてくれますか？
-はい、おじいさん、試してはいけません-もちろん、私は静かなマウスですが、機敏です。どういうわけか、猫の孫娘は私たちの州のリポジトリのデータモデルにそれを取得するように頼みました。そしてもちろん、猫が私にやって来ました-あなたに、マウスは言います、すべての希望！さて、善行善良な人々（そして猫）ができないことは何ですか？私は城に行きました。そこでは、リポジトリの責任者がデータモデルを金庫に隠しています。そして隠した。私は彼がそのモデルを金庫から取り出すのを待った。彼がコーヒーを飲みに出かけるとすぐに、私はテーブルに飛び乗った。モデルを見ると何もわからない！どうして？私たちの金庫を認識していません！数え切れないほどのテーブル、データ、つまり飽くなきストリームがあります！そしてここで-すべてが調和していて美しいです...彼はこのモデルを見ました-そしてそれを金庫に戻しました。
-はい、非常に奇妙なことです、あなたは私たちに言った、マウス。
おじいちゃんは一生懸命考えました。
友達、どうしよう？結局のところ、そのようなリポジトリで長生きすることはありません...ユーザーはすぐに完全に忍耐力を失います。

おとぎ話の祖父が決定したものは何でも-新しい保管施設を建設するか、既存の保管施設を復活させようとする-私たちは再び「袖をまくり上げる」前に結論を出さなければなりません。
狭いクローズドグループに専門知識を集中させる危険性、制御プロセスの欠如、企業で使用されるシステムのアーキテクチャの透明性の確保など、組織的な側面は脇に置いておきましょう。
今日は、特定のシステム（またはシステムのグループ）のアーキテクチャー、つまりデータウェアハウスの構築に焦点を当てたいと思います。組織がストレージのような複雑で高価なシステムを構築し始めるとき、そもそも何に焦点を合わせる必要があるか。

デブリーフィング

システムの作成と開発に取り組んでいる私たちの誰も、それが「一時的な家」、または1、2年で「枯れる」ソリューションになることを望んでいません。顧客とビジネスの要件と期待に応えることができなくなります。今日、「柔軟な方法論」への移行がどれほど強くても、使い捨てドラムの棒を彫る職人よりも、バイオリンを作る「マスター」のように感じる方がはるかに快適です。
私たちの意図は自然に聞こえます。堅実で高品質なシステムを作成することです。これにより、定期的に「ファイルを使って夜警」を行う必要がなくなり、エンドユーザーの前で恥ずかしがらず、次のようになりません。すべての「初心者」フォロワーへの「ブラックボックス」。

まず、ストレージを操作するときに定期的に発生する一般的な問題をリストします。これまでのところ、合理化と形式化を試みることなく、私たちが持っているものを書き留めましょう。

原則として、優れたストレージがあります。触れない限り、すべてが機能します。確かに、変更が必要になるとすぐに、「ローカル崩壊」が始まります。
データは、規制に従って、1つの大きなプロセス内で8時間以内に毎日ロードされます。そしてそれは私たちに合っています。ただし、突然障害が発生した場合は、手動で介入する必要があります。そして、すべてが長期間にわたって予期せずに機能する可能性があります。その過程で人間の参加が必要です。
ロールリリース-問題が発生する可能性があります。
一部のソースは時間内にデータを提供できませんでした-すべてのプロセスが待機しています。
データの整合性はデータベースによって制御されているため、データが壊れるとプロセスがクラッシュします。
非常に大きなストレージがあります。1つの共通スキーマに2000個のテーブルがあります。そして他の多くのスキームではさらに3000。それらがどのように配置され、どのような理由で出現したのか、私たちはすでにほとんど理解していません。したがって、何かを再利用するのは難しい場合があります。そして、多くの問題を再び解決する必要があります。なぜなら、（「他の誰かのコードで」理解するよりも）簡単で速いからです。その結果、不一致や重複した機能が発生します。
ソースが高品質のデータを提供することを期待しています。しかし、そうではないことがわかりました。その結果、私たちは最終報告書の調整に多くの時間を費やしています。そして、彼らはそれで非常に成功しました。合理化されたプロセスもあります。確かに、時間がかかります。しかし、ユーザーは慣れています...
ユーザーは常に私たちのレポートを信頼しているわけではなく、特定の数字を正当化する必要があります。彼が正しい場合もあれば、間違っている場合もあります。しかし、私たちがそれらを実証することは非常に困難です。「エンドツーエンド分析」（またはデータ系統）の手段は提供していません。
追加の開発者を呼び込むことができます。しかし、私たちには問題があります-どうやってそれらを仕事に変えるのですか？作業を並列化するための最も効率的な方法は何ですか？
「システムの中核」を一年もかけて開発せずに、徐々にシステムを開発していくには？
データウェアハウスは、企業モデルに関連付けられています。しかし、モデルを無期限に構築できることは確かです（XYZ銀行で見ました）（XYZ銀行では、動きを伴わずに6か月間事業体について話し合いました）。なんで彼女なの？それとも、彼女に非常に多くの問題がある場合は、彼女がいない方が良いでしょうか？多分それをどうにかして生成しますか？
モデルをリードすることにしました。しかし、倉庫データモデルを体系的に開発するにはどうすればよいでしょうか。「ゲームのルール」が必要ですか、それは何でしょうか？それは私たちに何を与えるでしょうか？モデルを間違えた場合はどうなりますか？
「ビジネスでデータが必要ない」場合は、データまたはその変更履歴を保存する必要がありますか？「ゴミを保存」して、このデータを実際のタスクに使用することを複雑にしたくありません。ボールトは履歴を保持する必要がありますか？どんな感じ？ストレージは時間の経過とともにどのように機能しますか？
NSI管理システムを使用している場合、ストレージ内のデータを統合する必要がありますか？ MDMがある場合、これはマスターデータの問題全体が解決されたことを意味しますか？
主要な会計システムはまもなく交換される予定です。データストアはソース変更の準備ができている必要がありますか？これを達成する方法は？
メタデータが必要ですか？これで何がわかるでしょうか？正確にはどこで使用できますか？どのように実装できますか？それらを「1か所」に保管する必要がありますか？
お客様の要件と要望は非常に不安定です。何かが絶えず変化しています。一般的に、私たちのビジネスは非常にダイナミックです。私たちが何かをしている間、それはすでに不要になっています。ホットケーキのように、できるだけ早く結果を出すにはどうすればよいでしょうか。
ユーザーはスピードを要求します。ただし、メインのブートプロセスを頻繁に実行することはできません。これにより、ソースシステムがロードされます（パフォーマンスに悪影響を及ぼします）。したがって、追加のデータストリームをハングアップします。これには、ポイントごとに必要なものが含まれます。確かに、それは多くの流れになります。次に、一部のデータを破棄します。さらに、収束の問題があります。しかし、他の方法はありません...

かなり多くのことがすでに起こっています。しかし、これは完全なリストではありません-それを補足して開発するのは簡単です。テーブルに隠すのではなく、目立つ場所に吊るします。これらの問題は、作業の過程で私たちの注意を集中させます。
その結果、私たちの仕事は包括的なソリューションを開発することです。

抗脆弱性

私たちのリストを見ると、1つの結論を引き出すことができます。ある種の「レポート用データベース」を作成したり、そこにデータをスローしたり、ある種の定期的なデータ更新プロセスを構築したりすることは難しくありません。システムはなんとか機能し始め、ユーザーが現れ、義務とSLAが発生すると、新しい要件が発生し、追加のソースが接続され、方法論が変更されます。これらすべてを開発プロセスで考慮する必要があります。

しばらくすると、画像は次のようになります。
「これが金庫です。そして、あなたがそれに触れない場合、それは機能します。何かを変えなければならないときに問題が発生します。」

変化が起こり、その影響を評価して理解することはできません（最初はそのようなツールをシステムに組み込んでいなかったため）-リスクを冒さないために、私たちは何に触れずに、もう1つ作成します側の拡張、そしてもう1つ、そしてそれ以上-私たちの決定をスラム街に変えるか、ラテンアメリカで彼らが言うように、警察でさえ行くことを恐れている「貧民街」。
自分のシステムに対するコントロールの喪失、カオスの感覚があります。既存のプロセスを維持し、問題を解決するには、ますます多くの手が必要になります。そして、変更を加えるのはますます難しくなっています。言い換えれば、システムはストレスに対して不安定になり、変化に適応しなくなります。また、「カード」を持っている人がいないため、「フェアウェイを知っている」キャラクターに強く依存しています。

オブジェクトのこの特性は、混沌、ランダムなイベント、激動の影響下で崩壊することです-ナシムニコラスタレブは もろさ 。また、反対の概念を紹介します。 抗脆弱性 – オブジェクトがストレスや事故によって破壊されていないが、それから直接の利益を受け取っている場合。（「抗脆弱性。カオスから利益を得る方法」）
それ以外の場合は呼び出すことができます 適応性 また 変化への抵抗 .

この文脈でこれはどういう意味ですか？ ITシステムの「混乱の原因」とは何ですか？そして、ITアーキテクチャの観点から「カオスを活用する」とはどういう意味ですか？
最初に頭に浮かぶのは、外部からの変化です。システムの外の世界は何ですか？特に保管用。もちろん、まず第一に、リポジトリのデータソースからの変更：

受信データの形式を変更する。
一部のデータソースシステムを他のシステムに置き換える。
システム統合のためのルール/プラットフォームの変更。
データの解釈を変更する（フォーマットが保存され、データを操作するロジックが変更されます）。
統合がデータレベルで行われる場合は、データモデルを変更します（データベーストランザクションログファイルの解析）。
データ量の増加-ソースシステムにデータがほとんどなく、負荷が小さい間-いつでもデータを取得できますが、任意の負荷がかかると、データと負荷が増加します-現在、厳しい制限があります。
等

ソースシステム自体、情報の構成とその構造、統合の相互作用のタイプ、およびデータを操作するロジックそのものが変わる可能性があります。各システムは、システムの目標と目的を満たす独自のデータモデルとそれらを使用するためのアプローチを実装します。そして、彼らが業界モデルと参照慣行を統一しようとどれほど懸命に努力しても、とにかくニュアンスが必然的に現れるでしょう。（さらに、さまざまな理由から、業界統一のプロセス自体はあまり進んでいません。）
企業データを扱う文化-情報アーキテクチャの存在と制御、単一のセマンティックモデル、マスターデータ管理システム（MDM）は、ウェアハウス内のデータを統合するタスクをいくらか容易にしますが、その必要性を排除するものではありません。

それほど重要ではない変更は、ストレージコンシューマーによって開始されます（要件の変更）。

以前は、レポートを作成するのに十分なデータがありました。現在は、追加のフィールドまたは新しいデータソースを接続する必要がありました。
以前に実装されたデータ処理方法は時代遅れです-アルゴリズムとそれが影響するすべてのものを作り直す必要があります。
以前は、情報パネルの辞書属性の現在の値に誰もが満足していました。現在、分析されたファクト/イベントの発生時に関連する値が必要です。
データストレージの履歴の深さには、以前にはなかった要件がありました。データを2年間ではなく、10年間保存する必要がありました。
以前は、「1日の終わり/期間」のデータがあれば十分でした。現在は、「日中」のデータの状態、または特定のイベント（たとえば、ローン申請の決定）のデータが必要です。バーゼルII）;
以前は昨日（T-1）以降のデータのレポートに満足していましたが、今はT0が必要です。
等

ソースシステムとの統合の相互作用とデータウェアハウスの消費者からの要件の両方が、データウェアハウスの外部要因です。1つのソースシステムが別のソースシステムに置き換わる、データ量が増える、受信データ形式が変わる、ユーザー要件が変わるなどです。そして、これらはすべて、私たちのシステム（私たちのリポジトリ）が準備できていなければならない典型的な外部の変更です。適切なアーキテクチャがあれば、システムを殺してはなりません。

しかし、それだけではありません。
変動性について言えば、まず第一に、外的要因を思い出します。結局のところ、私たちはすべてを制御することができます、それは私たちに思えますよね？はいといいえ。はい、影響範囲外の要因のほとんどは外部です。しかし、「内部エントロピー」もあります。そして、それはまさにその存在のために、「ポイント0に」戻る必要がある場合があります。ゲームをやり直します。
人生において、私たちはしばしばゼロから始める傾向があります。なぜ私たちはこれをする傾向があるのですか？そして、それは悪いですか？
ITに適用されます。システム自体にとって（これは非常に優れている可能性があります）、個々の決定を再考する機能です。特にローカルでできる場合は。リファクタリングは、システム開発の過程で定期的に発生する「ウェブ」を解明するプロセスです。「最初に」戻ると便利です。しかし、それには代償があります。
適切なアーキテクチャ管理により、この価格は削減され、システム開発のプロセス自体がより制御可能で透過的になります。簡単な例：モジュール性の原則が守られている場合、外部インターフェースに影響を与えることなく、別のモジュールを書き直すことができます。そして、これはモノリシック構造では実行できません。

システムの脆弱性は、そのアーキテクチャによって決まります。そして、それを適応させるのはこの特性です。
私たちが話すとき アダプティブアーキテクチャ-システムが変更に適応できることを意味しますが、アーキテクチャ自体を絶えず変更しているわけではありません。逆に、アーキテクチャがより安定して安定しているほど、その改訂に伴う要件が少なくなり、システムの適応性が高まります。

アーキテクチャ全体の改訂が必要なソリューションは、はるかに高額になります。そしてそれらの採用のために、あなたは非常に正当な理由を持っている必要があります。たとえば、このような理由は、既存のアーキテクチャ内では実装できない要件である可能性があります。それから彼らは言う-アーキテクチャに影響を与える要件があった。
したがって、「抗脆弱性の限界」も知る必要があります。アーキテクチャは「真空中で」開発されたものではなく、現在の要件と期待に基づいています。そして、状況が根本的に変化した場合（現在のアーキテクチャを超えたことを理解する必要があります）、それを修正し、別のソリューションを開発し、移行パスについて考える必要があります。
たとえば、1日の終わりには常にウェアハウスにデータが必要であると想定し、標準のシステムインターフェイスを使用して（一連のビューを介して）データを毎日収集します。そして、リスク管理部門からは、一日の終わりではなく、貸し出しの意思決定時にデータを受け取る必要があるという要望がありました。「伸ばされていないものを伸ばす」ことを試みる必要はありません-あなたはこの事実を認識する必要があります-早いほど良いです。そして、私たちが問題を解決することを可能にするアプローチに取り組み始めます。
ここには非常に細かい線があります。「現時点での要件」のみを考慮し、数歩先（および数年先）を見ない場合、アーキテクチャに影響を与える要件に遅すぎるリスクが発生します。変更のコストは非常に高くなります。少し先を見据えて-私たちの地平線の範囲内で-誰にも害を与えたことはありません。

「ストレージのおとぎ話」のシステムの例は、壊れやすい設計アプローチに基づいて構築された非常に不安定なシステムの例にすぎません。そして、これが発生した場合、この特定のクラスのシステムでは、破壊がかなり迅速に発生します。
なぜ私はそう言うことができますか？ストレージのトピックは新しいものではありません。この時期に開発されたアプローチとエンジニアリング手法は、まさにこれを目的としており、システムの実行可能性を維持しています。
簡単な例を挙げると、離陸ストレージプロジェクトが失敗する最も一般的な理由の1つは、統合インターフェイスを一致させずに開発中のソースシステム上にストレージを構築しようとすることです。つまり、テーブルから直接データをプルしようとします。その結果、開発が開始され、この間にソースデータベースが変更され、ストレージ内のダウンロードストリームが動作しなくなりました。何かをやり直すには遅すぎます。また、ストレージ内に複数のテーブルレイヤーを作成して自分自身を保護していない場合は、すべてを破棄して最初からやり直すことができます。これはほんの一例であり、最も単純なものの1つです。

タレブの脆弱性と反脆弱性の基準は単純です。チーフジャッジは時間です。システムが時の試練に耐え、その「存続可能性」と「非破壊性」を示す場合、それは脆弱性防止の特性を持っています。
システムを設計するときに、脆弱性を要件として考慮する場合、これにより、システムを「外部からのカオス」と「内部からのカオス」の両方に適応させるアーキテクチャを構築するためのアプローチを使用することが奨励されます。」。そして最終的には、システムの寿命が長くなります。
私たちの誰もが「一時的」を作りたくないのです。そして、今は他に方法がないことを誤解しないでください。数歩先を見るのはいつでも、特に危機の時に人にとっては普通のことです。

データウェアハウスとは何ですか？なぜそれを構築するのですか？

ストレージアーキテクチャの記事は、読者がそれが何であるかを知っているだけでなく、そのようなシステムについてある程度の経験があることを前提としています。それにもかかわらず、私はこれを行う必要があると考えました-原点に戻るために、パスの最初に戻るためです。開発の「支点」がそこにあります。

人々はどのようにしてデータウェアハウスが必要であるという結論に達しましたか？そして、それらは単なる「非常に大きなデータベース」とどう違うのでしょうか。
昔、世界に単に「ビジネスデータ処理システム」があったとき、ITシステムをフロントエンドoltpシステム、バックオフィスdss、テキストデータ処理システム、データウェアハウスなどのクラスに分割することはありませんでした。。
これは、最初のリレーショナルDBMSIngresがMichaelStonebreakerによって作成されたときでした。
そして、これは、パーソナルコンピュータの時代が旋風のようにコンピュータ業界に突入し、当時のITコミュニティのすべてのアイデアを永遠に変えた時期でした。

その後、Clipper、dBase、FoxProなどのデスクトップクラスのDBMSに基づいて作成されたエンタープライズアプリケーションを簡単に見つけることができました。そして、クライアントサーバーアプリケーションとDBMSの市場は勢いを増しているだけでした。次々と、IT分野で長い間ニッチを占めるデータベースサーバー（Oracle、DB2など）が登場しました。
そして、「データベースアプリケーション」という用語が広まりました。そのようなアプリケーションには何が含まれていましたか？簡略化-ユーザーが同時に情報を入力できる入力フォーム、「ボタンで」または「スケジュールに従って」起動された計算、画面に表示されたりファイルとして保存されて封印に送信されたりするレポート。
「特別なことは何もありません。単純なアプリケーションであり、データベースです」と、私の初期のメンターの1人は述べています。「特別なことじゃないの？」 -そう思いました。

よく見ると、まだ機能があります。ユーザーが増えると、受信する情報の量が増え、システムの負荷が増えると、開発者と設計者は、パフォーマンスを許容レベルに維持するために、いくつかの「トリック」を実行します。 1つ目は、モノリシックな「ビジネスデータ処理システム」を、オンラインモードでのユーザーの作業をサポートする会計アプリケーションと、バッチデータ処理およびレポート用の個別のアプリケーションに分割することです。これらの各アプリケーションには独自のデータベースがあり、データベースサーバーの個別のインスタンスでホストされ、さまざまな種類のワークロード（OLTPとDSS）に対してさまざまな設定が行われます。そして、データストリームはそれらの間に構築されます。

それだけですか？問題は解決したようです。次は何が起こる？
そして企業は成長し、その情報は倍増する必要があります。外界との交流も増えています。その結果、すべてのプロセスを完全に自動化する1つの大きなアプリケーションではなく、さまざまなメーカーのいくつかの異なるアプリケーションがあります。情報を生成するシステムの数-社内のデータソースシステムは増加しています。そして遅かれ早かれ、さまざまなシステムから受け取った情報を確認して比較する必要があります。これが、新しいクラスのシステムであるデータウェアハウスが会社に登場する方法です。
このクラスのシステムの一般的に受け入れられている定義は次のとおりです。

データウェアハウス（またはデータウェアハウス）-組織内の意思決定をサポートするためにレポートの作成とビジネス分析のために特別に設計および意図されたドメイン固有の情報データベース

この上、統合さまざまなシステムからのデータ、特定の「単一の」（統一された）方法でそれらを見る機能は、データストレージクラスシステムの重要なプロパティの1つです。これが、ITシステムの進化の過程でストレージが誕生した理由です。

データウェアハウスの主な機能

もっと詳しく見てみましょう。これらのシステムの主な機能は何ですか？データウェアハウスが他のエンタープライズITシステムと異なる点は何ですか？

まず、これらは大量です。とても大きい。 VLDB -これは、主要ベンダーが製品の使用に関する推奨事項を提示するときに、このようなシステムを呼び出す方法です。会社のすべてのシステムから、データはこの大規模なデータベースに流れ込み、教科書で述べられているように「永遠に不変」に保存されます（実際には、人生はより複雑であることがわかります）。

第二に、それは履歴データです- 「企業記憶」 -いわゆるデータウェアハウス。ストレージ内の時間で作業するという点では、すべてが非常に興味深いものです。会計システムでは、データは現時点で関連しています。次に、ユーザーが何らかの操作を実行すると、データが更新されます。同時に、変更の履歴は保存されない場合があります-それは会計慣行に依存します。たとえば、銀行口座の残高を考えてみましょう。「現在」、1日の終わり、または何らかのイベント時（たとえば、スコアの計算時）の現在の残高に関心がある場合があります。最初の2つを非常に簡単に解決する場合、後者はおそらく特別な努力を必要とします。リポジトリを操作する場合、ユーザーは過去の期間にアクセスしたり、現在の期間と比較したりすることができます。データウェアハウスと会計システムを大幅に区別するのは、これらの時間関連の機能であり、過去の特定の深さまで、時間軸上のさまざまなポイントでデータの状態を取得します。

第三に、これ統合と データ統合 。それらの共同分析を可能にするために、それらを共通の形にする必要があります- 統合データモデル 、事実を統一された参考書と比較します。ここにはいくつかの側面と困難があります。主に- 概念 –同じ用語で、さまざまな部門のさまざまな人々がさまざまなことを理解できます。逆もまた同様です。本質的に同じものを別の方法で呼び出すことです。「単一のビュー」を確保すると同時に、特定のユーザーグループのビジョンの詳細を維持するにはどうすればよいですか？

第四に、それは データ品質 。データをストレージにロードするプロセスでは、データがクリーンアップされ、一般的な変換と変換が実行されます。一般的な変換は1つの場所で実行する必要があります。その後、さまざまなレポートを作成するために使用します。これにより、ビジネスユーザー、特に、互いに同意しないさまざまな部門の番号によってテーブルに連れてこられる管理者にとって、非常に苛立たしい原因となる不一致を回避できます。データ品質が低いと、レポートにエラーや不一致が生じ、その結果、レベルが低下します。 ユーザーの信頼 システム全体、分析サービス全体に。

建築コンセプト

リポジトリに出くわしたすべての人は、おそらくある種の「階層構造」を観察しました。このクラスのシステムに根付いたのは、このアーキテクチャのパラダイムです。そして偶然ではありません。ストレージレイヤーは、システムの個別のコンポーネントとして認識できます。独自のタスク、責任範囲、「ゲームのルール」があります。
階層化アーキテクチャは、システムの複雑さに対処する手段です。後続の各層は、前の層の内部実装の複雑さから抽象化されます。このアプローチにより、「自転車」を毎回ゼロから作り直すことなく、同じタイプのタスクを識別し、それらを均一な方法で解決することができます。
概略的な概念図を図に示します。これは、重要なアイデアである概念のみを反映した簡略化された図ですが、詳細のより深い研究で生じる「解剖学的詳細」は含まれていません。

図に示すように、概念的に次のレイヤーを選択します。データストレージ領域（塗りつぶされた長方形で示される）とデータ読み込みソフトウェア（条件付きで同じ色の矢印で示される）を含む3つの主要なレイヤー。ただし、補助的なサービスレイヤーは、データの読み込みと品質管理の管理という非常に重要な接続の役割を果たします。

プライマリデータレイヤー-プライマリデータレイヤー （また演出、また 操作層 ）-ソースシステムからロードされ、変換なしで一次情報を保存するように設計されています-元の品質で、変更の完全な履歴をサポートします。
この層のタスク–データソースの物理デバイス、データ収集の方法、および変更のデルタを抽出する方法から、後続のストレージレイヤーを抽象化します。

Core DataLayer-ストレージコア -システムの中心的なコンポーネント。ストレージを単なる「バッチ統合プラットフォーム」または「ビッグデータダンプ」と区別します。これは、その主な役割がデータ統合さまざまなソースから、均一な構造への縮小、キー。データ品質と一般的な変換を伴う主な作業が実行されるのはカーネルにロードするときであり、これは非常に複雑になる可能性があります。
この層のタスク-データソースの論理構造の特性と異なるシステムからのデータを比較する必要性から消費者を抽象化し、データの整合性と品質を確保します。

データマートレイヤー-分析ショーケース -データを分析に便利な構造に変換することを主な機能とするコンポーネント（BIがストアフロントで動作する場合、これは通常、次元モデルです）、または消費者システムの要件に従います。
原則として、データマートはコアからデータを取得します-信頼できる検証済みのソースとして-つまり、このコンポーネントのサービスを使用して、データを単一のフォームにまとめます。そのような窓を呼びます通常。場合によっては、ストアフロントはステージングから直接データを取得できます。つまり、プライマリデータ（ソースキー内）を操作します。このアプローチは、原則として、さまざまなシステムからのデータ統合が不要であり、データ品質よりも効率が必要なローカルタスクに使用されます。そのようなディスプレイはと呼ばれます オペレーティング 。一部の分析指標は、非常に複雑な計算方法を持つ場合があります。したがって、そのような自明でない計算と変換のために、いわゆる 二次ショーケース .
ストアフロントレイヤータスク–特定の消費者の要件に応じたデータの準備– BIプラットフォーム、ユーザーのグループ、または外部システム。

上記のレイヤーは、永続的なデータストレージ領域と、データをロードおよび変換するためのソフトウェアモジュールで構成されています。このレイヤーとリージョンへの分割は論理的です。これらのコンポーネントの物理的な実装は異なる場合があります。より効率的な場合は、異なるプラットフォームを使用して、異なるレイヤーにデータを保存または変換することもできます。
ストレージ領域には、データ変換およびデータ変換のプロセスで使用される技術（バッファテーブル）が含まれています。ターゲットテーブル、コンシューマコンポーネントによってアクセスされます。ビューでターゲットテーブルを「カバー」することをお勧めします。これにより、システムのその後の保守と開発が容易になります。 3つのレイヤーすべてのターゲットテーブルのデータは、特別な技術フィールド（メタ属性）でマークされています。これは、データの読み込みプロセスを保証し、ストレージ内のデータフローの情報監査を可能にするのに役立ちます。

すべてのレイヤーにサービス機能を提供する特別なコンポーネント（またはコンポーネントのセット）も区別されます。その重要なタスクの1つである制御機能は、システム全体に「ゲームの単一のルール」を提供し、上記の各レイヤーを実装するためにさまざまなオプションを使用する権利を残すことです。データのロードと処理、さまざまなストレージプラットフォームなどにさまざまなテクノロジーを使用します。彼と呼ぼう サービスレイヤー（サービスレイヤー） 。ビジネスデータは含まれていませんが、独自のストレージ構造があります。メタデータ領域と、データ品質を操作するための領域（および割り当てられている機能によっては他の構造）が含まれています。

システムを個別のコンポーネントにこのように明確に分割すると、システム開発の可制御性が大幅に向上します。

特定のコンポーネントの機能の開発者に割り当てられるタスクの複雑さが軽減されます（外部システムとの統合の問題を同時に解決し、データクリーニング手順を検討し、データの最適な表示について考える必要はありません。消費者）-タスクは、少量の配信を分解、評価、および実行するのが簡単です。
さまざまなパフォーマー（さらにはチームや請負業者）を作業に参加させることができます-なぜならこのアプローチにより、タスクを効果的に並列化して、相互の影響を減らすことができます。
永続的なステージングの存在により、コア全体またはサブジェクト領域全体のショーケースを設計せずにデータソースをすばやく接続し、優先順位に従って残りのレイヤーを徐々に構築できます（さらに、データはすでにリポジトリにあります-利用可能ですシステムアナリストに。これにより、その後のリポジトリ開発のタスクが大幅に容易になります。
コアの存在により、データ品質に関するすべての作業（および発生する可能性のあるミスやエラー）をストアフロントおよびエンドユーザーから隠すことができます。最も重要なことは、このコンポーネントをストアフロントの単一のデータソースとして使用することで、問題を回避できます。一般的なアルゴリズムを1か所に実装することによるデータコンバージェンス。
ストアフロントを強調表示すると、さまざまな部門のユーザーが持つ可能性のある理解データの違いと詳細を考慮に入れることができ、BI要件に合わせてそれらを設計すると、集計された数値を発行できるだけでなく、ドリルダウンする機会を提供することでデータの信頼性を確保できます。一次指標へ;
サービスレイヤーの存在により、エンドツーエンドのデータ分析（データリネージ）の実行、統合データ監査ツールの使用、変更のデルタを強調するための一般的なアプローチ、データ品質の操作、負荷管理、エラー監視、および診断ツールを使用できます。、および問題解決をスピードアップします。

分解へのこのアプローチはまた、システムを変更に対してより抵抗力のあるものにします（「モノリシック構造」と比較して）-それはその脆弱性を保証します：

ソースシステムからの変更はステージングで処理されます。カーネルでは、これらのステージングテーブルの影響を受けるスレッドのみが変更され、ストアフロントへの影響は最小限であるか、存在しません。
顧客の要件への変更は、主に店頭で処理されます（まだ倉庫にない追加情報が必要な場合を除く）。

次に、上記の各コンポーネントについて説明し、それらをもう少し詳しく見ていきます。

システムコア

「中間から」、つまりシステムのコアまたは中間層から始めましょう。コアレイヤーとしてラベル付けされていません。コアは、データ統合の役割を果たします-単一の構造、ディレクトリ、キーへの削減。ここでは、データ品質に関する主な作業（クリーニング、変換、統合）が実行されます。

このコンポーネントの存在により、アプリケーションストアフロントごとに同じ機能の実装を個別に繰り返すのではなく、共通のルールとアルゴリズムに従って、ソースシステムから受信したプライマリデータを単一の形式に変換するデータフローを再利用できます。リソースの非効率的な使用は、データの不一致にもつながる可能性があります。
ストレージコアは、一般的な場合、ソースシステムのモデルと、コンシューマーの形式および構造の両方とは異なるデータモデルで実装されます。

ストレージエンジンモデルとエンタープライズデータモデル

中間ストレージ層の主なタスクは安定性です。そのため、ここでの主な焦点はデータモデルです。これは一般に「エンタープライズデータモデル」と呼ばれます。残念ながら、神話と不条理の特定のハローがその周りに発達し、それは時々その建設を完全に放棄することにつながりますが、無駄になります。

神話1。 エンタープライズデータモデルは、数千のエンティティ（テーブル）で構成される巨大なモデルです。
実際。 あらゆる主題分野、あらゆるビジネスドメイン、あらゆる企業のデータ、最も複雑なものでさえ、基本的なエンティティはほとんどありません-20〜30。

神話2。 「独自のモデル」を開発する必要はありません。業界の参照モデルを購入し、それに応じてすべてを実行します。私たちはお金を使いますが、保証された結果が得られます。
実際。 参照モデルは非常に便利です。この領域のモデリングにおける業界の経験が含まれています。それらから、アイデア、アプローチ、命名慣行を引き出すことができます。重要なことを見逃さないように、エリアの「カバレッジの深さ」を確認してください。しかし、このようなモデルを「そのまま」使用できる可能性はほとんどありません。これは、たとえば、ERPシステム（またはCRM）を購入し、「自分でねじる」ことなく実装するのと同じ神話です。このようなモデルの価値は、この特定のビジネス、この特定の会社の現実に適応することで生まれます。

神話3。 ストレージコアモデルの開発には何ヶ月もかかる場合があり、その間、プロジェクトは実際に凍結されます。さらに、それは非常に多くの会議と多くの人々の参加を必要とします。
実際。 リポジトリモデルは、リポジトリとともに、1つずつ繰り返し開発できます。カバーされていない領域の場合、「拡張ポイント」または「スタブ」が配置されます。いくつかの「普遍的な構造」が適用されます。同時に、「データを入れる」ことも（さらに難しい）データを取得することも難しい、4つのテーブルの超普遍的なものを取得しないように、いつ停止するかを知る必要があります。そして、これはパフォーマンスの点で非常に最適ではありません。

モデルの開発には時間がかかります。ただし、これは「エンティティの描画」に費やされる時間ではありません。これは、データがどのように構造化されているかを理解して、サブジェクト領域を分析するために必要な時間です。そのため、アナリストはこのプロセスに非常に密接に関与しており、さまざまなビジネス専門家も関与しています。そして、これは選択的に行われます。そして、非常識な数の人々との会議を組織したり、膨大な質問票を郵送したりすることによってではありません。
質の高いビジネスとシステムの分析は、ストレージコアモデルを構築するための鍵です。多くのことを理解する必要があります。データがどこで（どのシステムで）生成されるか、どのように配置されるか、どのビジネスプロセスでデータが循環するかなどです。定性分析がシステムに害を及ぼすことはありません。むしろ、逆に、私たちの理解では「空白」から問題が発生します。

データモデルの開発は、何か新しいものを発明して考え出すプロセスではありません。実際、会社のデータモデルはすでに存在しています。そして、その設計のプロセスは、より「発掘」のようなものです。モデルは、企業データの「地面」から優しく注意深く明らかにされ、構造化された形で服を着ています。

神話4。 私たちの会社では、ビジネスは非常にダイナミックであり、すべてが急速に変化しているため、モデルを作成することはできません。システムのこの部分を稼働させる前に、モデルは古くなります。
実際。 コアの重要な要素は安定性であることを思い出してください。そして何よりも、モデルのトポロジー。どうして？中心であり、他のすべてに影響を与えるのはこのコンポーネントだからです。安定性もカーネルモデルの要件です。モデルがすぐに時代遅れになると、誤った設計になります。その開発のために、間違ったアプローチと「ゲームのルール」が選択されました。それは定性分析の問題でもあります。企業モデルの主要なエンティティが変更されることは非常にまれです。
しかし、「Products」ディレクトリの代わりに、たとえば菓子を販売する会社のためにやろうと思ったら、「Sweets」、「Cakes」、「Pies」を作成します。次に、ピザが商品のリストに表示されたら、はい、たくさんの新しいテーブルを入力する必要があります。そして、それは単なるアプローチの問題です。

神話5。 企業モデルの作成は、非常に深刻で、複雑で、責任あるビジネスです。そして、間違えるのは怖いです。
実際。 コアモデルは安定しているはずですが、それでも「金属で鋳造」されていません。他の設計上の決定と同様に、その構造を確認および変更できます。彼女のこの質を忘れないでください。しかし、これはあなたがそれに「呼吸できない」という意味ではまったくありません。そしてこれは、処理のために計画されるべき一時的な解決策と「スタブ」が受け入れられないという意味ではありません。

神話6。 データソース（たとえば、NSIシステム（またはマスターデータ管理システム）-MDM）がある場合、それは企業モデルに適切に対応している必要があります（特に、最近設計され、取得する時間がなかった場合）「副作用」、「伝統」および仮設建物）。この場合、カーネルモデルは必要ないことがわかりますか？
実際。 はい、この場合、ストレージコアモデルの構築が大幅に容易になります。トップレベルの既製の概念モデルに従います。しかし、それはまったく除外されていません。どうして？特定のシステムのモデルを構築する場合、特定のルールが適用されるため（エンティティごとに）使用するテーブルのタイプ、データのバージョン管理方法、履歴を保持する粒度、使用するメタ属性（使用する技術フィールド）など。。

さらに、NSIおよびMDMシステムがどれほど素晴らしく包括的であっても、原則として、他の会計システムに「ほぼ同じ」ローカルディレクトリが存在することに関連するニュアンスがあります。そして、この問題は、私たちが好むと好まざるとにかかわらず、レポートと分析がここで収集されるため、ストレージで解決する必要があります。

プライマリデータレイヤー（または履歴可能なステージングレイヤーまたは運用レイヤー）

その上でプライマリデータレイヤーとして指定されています。このコンポーネントの役割：ソースシステムとの統合、一次データのロードと保存、および予備的なデータクリーニング-ソースとの「相互作用インターフェイス契約」で修正されたフォーマット論理制御のルールへの準拠のチェック。
さらに、このコンポーネントは、ソースがデータの変更を追跡できるかどうか、およびその方法（どの基準で「キャッチ」できるか）に関係なく、ストレージの非常に重要なタスク（「真の変更デルタ」を強調表示）を解決します。。データがステージングに入るとすぐに、メタ属性によるマーキングのおかげで、デルタ選択の問題は他のすべてのレイヤーですでに明らかです。

このレイヤーのデータは、プライマリデータを元の形式にできるだけ近づけるために、ソースシステムにできるだけ近い構造で保存されます。このコンポーネントの別名は「運用レイヤー」です。
確立された用語「ステージング」を使用しないのはなぜですか？事実、「ビッグデータとVLDBの時代」以前は、ディスク容量は非常に高価でした。多くの場合、プライマリデータは、保存されている場合、限られた期間しかありませんでした。そしてしばしば「ステージング」という名前は呼ばれます掃除可能バッファ。
現在、テクノロジーは進歩しています。そして、すべての一次データを保存するだけでなく、可能な限りの粒度でそれらを履歴化する余裕があります。これは、データの増加を制御する必要がないことを意味するものではなく、使用の「温度」に応じて、データストレージのコストを最適化することで情報ライフサイクルを管理する必要性を排除するものではありません。需要の少ない「コールドデータ」をより安価なメディアおよびストレージプラットフォームに移行します。

「歴史的なステージング」の存在を私たちに与えるもの：

間違いを犯す可能性（構造、変換アルゴリズム、履歴保持の粒度）-ストレージアベイラビリティーゾーンに完全に履歴可能なプライマリデータがあるため、いつでもテーブルをリロードできます。
考える機会-リポジトリ開発のこの反復では、コアの大きなフラグメントの開発に時間をかけることができます。私たちのステージングでは、いずれにせよ、それらは同じ時間範囲であります（1つの「歴史の出発点」があります）。
分析の可能性-ソースに存在しなくなったデータも保存します-そこで上書きされたり、アーカイブに移動したりする可能性があります。 –私たちと一緒に、それらは分析のために利用可能なままです。
情報監査の可能性-最も詳細な一次情報のおかげで、ダウンロードがどのように機能したかを理解することができ、最終的にそのような番号を取得しました（このためには、メタ属性でマーキングする必要もありますおよびダウンロードが機能する対応するメタデータ-これはサービスレイヤーで決定されます）。

「歴史的ステージング」の構築でどのような困難が生じる可能性がありますか。

このレイヤーのトランザクション整合性の要件を設定するのは便利ですが、実際にはこれを達成するのは難しいことが示されています（これは、この領域では親テーブルと子テーブルの参照整合性を保証しないことを意味します）-整合性の調整は後続で発生しますレイヤー;
このレイヤーには非常に大きなボリュームが含まれ（分析構造のすべての冗長性にもかかわらず、ストレージで最大）、ロードとクエリの両方の観点からそのようなボリュームを処理できる必要があります（そうしないと、ストレージ全体のパフォーマンス）。

この層について他に何が言えますか。
まず、「エンドツーエンドの読み込みプロセス」パラダイムから離れると、「キャラバンは最後のラクダの速度で移動する」は機能しなくなります。つまり、「キャラバン」の原則を放棄して切り替えます。「コンベヤー」の原則に基づいて、ソースからデータを取得し、レイヤーに配置して、次の部分を取得できるようにしました。だということだ
1）他のレイヤーで処理が行われるのを待ちません。
2）他のシステムによるデータ提供のスケジュールに依存しません。
簡単に言うと、特定の接続方法を介して1つのソースからデータを取得し、デルタをチェックして抽出し、データをステージングターゲットテーブルに配置するロードプロセスをスケジュールします。以上です。

第二に、これらのプロセスは、明らかに、非常に単純に配置されています。論理の観点からは、簡単に言うことができます。これは、それらを非常に適切に最適化およびパラメーター化できることを意味し、システムの負荷を軽減し、ソースを接続するプロセス（開発時間）をスピードアップします。
これを実現するには、このコンポーネントが動作するプラットフォームの技術的特徴を十分に理解する必要があります。そうすれば、非常に効果的なツールを作成できます。

分析ショーケースの層

ストアフロントレイヤー（データマートレイヤー）は、データを準備し、エンドユーザー（人またはシステム）に提供する責任があります。このレベルでは、消費者の要件が可能な限り考慮されます-論理的（概念的）および物理的の両方。サービスは、必要なものを正確に提供する必要があります。それ以上でもそれ以下でもありません。

コンシューマーが外部システムである場合、原則として、コンシューマーは必要なデータ構造と情報を収集するためのルールを指示します。良いアプローチは、消費者が正しいデータ収集に責任を持つアプローチです。準備され、ストアフロントを形成したデータウェアハウスは、増分データ収集の可能性を提供し（デルタ変更の後続の選択のためにメタ属性でマークを付ける）、その後、コンシューマーシステムがこのストアフロントの使用方法を管理および担当します。ただし、特殊な点があります。システムにデータ収集用のアクティブコンポーネントがない場合、統合機能を実行する外部コンポーネントが必要になるか、ストレージが「統合プラットフォーム」として機能し、データの正しい増分アップロードを保証します。さらに–ストレージの外。ここには多くのニュアンスがあります。インターフェイスの相互作用のルールは、両方の当事者が考えて理解する必要があります（ただし、統合に関しては、いつものように）。原則として、このようなストアフロントには定期的なデータのクリーニング/アーカイブが適用されます（これらの「トランジットデータ」を長期間保存する必要はほとんどありません）。

分析タスクの観点から最も重要なのは、「人々のための」ショーケースです。より正確には、彼らが使用するBIツールのショーケースです。
ただし、「特に上級ユーザー」のカテゴリ（アナリスト、データサイエンティスト）があり、外部の特殊なシステムを埋めるためにBIツールや日常的なプロセスを必要としません。彼らはある種の「共通の店先」と「彼ら自身のサンドボックス」を必要とし、そこで彼らは彼らの裁量でテーブルと変換を作成することができます。この場合、リポジトリの責任は、これらの一般的なデータマートが規制に従って設定されていることを確認することです。
これとは別に、データマイニングツール（詳細なデータ分析）などの消費者を特定することができます。これらのツールには独自のデータ準備要件があり、データサイエンティストによっても使用されます。リポジトリの場合、タスクは削減されます。これも、合意された形式の特定のショーケースをダウンロードするためのサービスをサポートするためです。

ただし、分析ストアフロントに戻りましょう。このデータ層のストレージ設計者の観点から関心があるのはそれらです。
私の意見では、データマートを設計するための最も実績のあるアプローチは、現在ほとんどすべてのBIプラットフォームが「研ぎ澄まされている」ものであり、ラルフキンボールのアプローチです。彼は名前で知られています 次元モデリング –多次元モデリング。この主題に関する非常に多くの出版物があります。たとえば、基本的なルールは出版物に記載されています。そしてもちろん、多変量モデリングの達人からお勧めすることもできます。もう1つの役立つリソースは、キンボールのヒントです。
ストアフロントを作成するための多次元アプローチは、メソッドエバンジェリストと主要なソフトウェアベンダーの両方によって非常によく説明され、うまく機能しているため、ここで詳細に説明することは意味がありません。元のソースが常に望ましいです。

一つだけ強調したいと思います。「レポートと分析」は異なります。「大量のレポート」があります。これは、ファイルの形式で生成され、提供された配信チャネルを介してユーザーに配信される事前注文のレポートです。そして、情報パネル（BIダッシュボード）があります。基本的に、それらはWebアプリケーションです。また、これらのアプリケーションの応答時間要件は、他のWebアプリケーションの場合と同じです。これは、BIパネルの通常の更新時間は分ではなく秒であることを意味します。ソリューションを設計するときは、このことを覚えておくことが重要です。これを達成する方法は？標準の最適化方法：応答時間が何で構成され、何に影響を与えることができるかを調べます。あなたは何に最も時間を費やしていますか？データベースの物理（ディスク）読み取り用、ネットワークを介したデータ転送用。リクエストごとに読み取られて送信されるデータの量を減らすにはどうすればよいですか？答えは明白で単純です。データを集約するか、クエリに参加している大きなファクトテーブルにフィルターを適用し、大きなテーブルの結合を除外する必要があります（ファクトテーブルへの参照はディメンションのみを通過する必要があります）。

BIとは何ですか？どのように便利ですか？多変量モデルが効果的であるのはなぜですか？
BIを使用すると、ユーザーはいわゆる「アドホッククエリ」を実行できます。どういう意味ですか？つまり、事前にリクエストを正確に把握しているわけではありませんが、ユーザーがリクエストできるセクションのインジケーターはわかっています。ユーザーは、適切なBIフィルターを選択することにより、このようなクエリを生成します。また、BI開発者とショーケース設計者の仕事は、そのようなアプリケーション操作ロジックを確保して、データがフィルタリングまたは集約されるようにし、要求されたデータが多すぎてアプリケーションが「ハング」する状況を回避することです。通常、それらは集計された数値から始まり、次に詳細なデータを掘り下げますが、途中で必要なフィルターを設定します。

単に「正しいスター」を構築し、BIの便利な構造を取得するだけでは必ずしも十分ではありません。場合によっては、どこかで非正規化を適用する必要があり（負荷にどのように影響するかを振り返りながら）、どこかでセカンダリストアフロントとアグリゲートを作成する必要があります。インデックスまたはプロジェクションを追加する場所（DBMSによって異なります）。

したがって、「試行錯誤」を通じて、BIに最適な構造を得ることができます。これは、DBMSとBIプラットフォームの両方の機能、およびデータ表示に対するユーザーの要件を考慮に入れます。
「コア」からデータを取得する場合、そのようなストアフロントの処理はローカルな性質のものであり、ソースシステムから直接受信したプライマリデータの複雑な処理に影響を与えることはありません。データをBIに便利な形式に「シフト」するだけです。そして、さまざまな要件に応じて、さまざまな方法で何度もそれを行う余裕があります。「プライマリ」からアセンブルするよりも、カーネルデータに基づいてこれを行う方がはるかに簡単で高速です（その構造とルールは、私たちが知っているように、「フロート」することもできます）。

サービスレイヤー

サービスレイヤー（-サービスレイヤー）は、さまざまなストレージレイヤー（負荷管理、データ品質管理、問題診断および監視ツールなど）でデータを処理するために使用できる一般的な（サービス）機能の実装を担当します。
このレベルの存在は、ストレージ内の透過性と構造化されたデータフローを提供します。

このレイヤーには、次の2つのデータストレージ領域が含まれます。

メタデータ領域-データ読み込み制御メカニズムに使用されます。
データ品質領域-オフラインのデータ品質チェック（つまり、ETLプロセスに直接組み込まれていないもの）を実装します。

さまざまな方法で負荷管理プロセスを構築できます。考えられるアプローチの1つは、これです。ストレージテーブルのセット全体をモジュールに分割します。モジュールに含めることができるのは、1つのレイヤーのテーブルのみです。各モジュールに含まれるテーブルは、個別のプロセスの一部としてロードされます。それを呼びましょう 制御プロセス 。制御プロセスの開始は、独自のスケジュールで行われます。制御プロセスは、アトミックプロセスへの呼び出しを調整します。各プロセスは、1つのターゲットテーブルをロードし、いくつかの一般的なステップも含みます。
明らかに、ステージングテーブルをモジュールに分割するだけで十分です-ソースシステム、またはむしろそれらの接続ポイントに従って。しかし、カーネルの場合、これを行うのはすでに困難です。そこでは、データの整合性を確保する必要があります。つまり、依存関係を考慮する必要があります。それらの。解決する必要のある競合が発生します。そして、それらを解決するさまざまな方法があります。

負荷管理の重要なポイントは、エラー処理への統一されたアプローチの開発です。エラーは、重大度のレベルに従って分類されます。重大なエラーが発生した場合、プロセスは停止する必要があります。その発生は、ストレージ内のデータ破損につながる可能性のある重大な問題を示しています。したがって、負荷管理は、プロセスを開始するだけでなく、プロセスを停止し、（誤って）タイムリーに開始しないようにすることでもあります。

サービスレイヤーが機能するために、特別なメタデータ構造が作成されます。この領域には、ロードプロセス、ロードされたデータセット、増分を維持するために使用されるチェックポイント（どのプロセスがどのポイントまで読み取ったか）、およびシステムが機能するために必要なその他のサービス情報に関する情報が格納されます。
すべてのレイヤーのすべてのターゲットテーブルが特別なメタフィールドのセットでマークされていることに注意することが重要です。メタフィールドの1つは、この文字列を更新したプロセスのIDです。リポジトリ内のテーブルの場合、このプロセスマーキングにより、デルタ変更を後で抽出するための統一された方法が可能になります。データをプライマリデータレイヤーにロードする場合、状況はより複雑になります。ロードされたオブジェクトごとにデルタを抽出するためのアルゴリズムは異なる場合があります。一方、受け入れられた変更を処理し、コアとストアフロントのターゲットテーブルにロールするロジックは、すべてが非常に簡単なステージングよりもはるかに複雑です。パラメータ化して、再利用可能な一般的な手順（手順）を検討するのは簡単です。）。

このトピック（読み込みの構成）を完全にカバーするようにここでタスクを設定するのではなく、注意を払う価値のあるアクセントのみを配置します。
上記のアプローチは、オプションの1つにすぎません。彼はかなり順応性があります。そして彼の「概念的なプロトタイプ」はトヨタのコンベヤーと「ジャストインタイム」システムでした。それらの。「毎晩のデータの読み込み」という一般的なパラダイムから脱却し、さまざまなソースでデータの準備ができているため、日中は少しずつ読み込みを行っています。同時に、多くの並列プロセスが実行されています。そして、新鮮なデータの「ホットテール」は常に「点滅」し、しばらくすると消えてしまいます。この機能を考慮に入れる必要があります。そして、必要に応じて、すべてがすでに統合されているカスタムショーケース「スライス」を形成します。それらの。効率と一貫性（完全性）の両方を同時に達成することは不可能です。バランスが必要です。重要なのはどこか、別の場所です。

ロギングとモニタリングの手段を提供することは非常に重要です。型付きイベントを使用することをお勧めします。この場合、さまざまなパラメーターを設定し、通知システム（特定のイベントのサブスクリプション）を設定できます。なぜならシステム管理者の介入が必要な場合、システム管理者ができるだけ早くそれを知り、必要なすべての診断情報を受け取ることが非常に重要です。ログは、事後の問題分析や、システムの誤動作のインシデントの調査にも使用できます。データ品質。

倉庫データモデルの設計と保守

データベースが関与するシステム（特にウェアハウス）を開発するときに、データモデルの設計に注意を払うことが重要なのはなぜですか？テキストエディタでも、どこにでもテーブルのセットを入れてみませんか？なぜこれらの写真が必要なのですか？
奇妙なことに、経験豊富な開発者でさえそのような質問を投げかけます。
実際、そうです、テーブルをスケッチして使い始めるのを妨げるものは何もありません。もし...もし同時に頭の中で（！）開発者は彼が彫刻している構造の調和のとれた全体像を持っています。複数の開発者がいる場合はどうなりますか？しかし、他の誰かがこれらのテーブルを使用する場合はどうなりますか？しかし、時間が経過した場合はどうなりますか？人がこのエリアを離れてから、再びそこに戻りますか？

モデルなしでそれを理解することは可能ですか？基本的にはできます。そして、それを理解し、「一枚の紙に写真を推定」し、データを「スイープ-セトリング」します。しかし、既製のアーティファクト（データモデル）を使用する方がはるかに簡単で、明確で、高速です。また、「その構造の論理」を理解することもできます。ゲームの共通のルールがあるといいでしょう。

そして、最も重要なことはそれでさえありません。最も重要なことは、モデルを設計するときに、（オプションなしで！）対象領域をより綿密かつ深く研究することを余儀なくされていることです。データ構造の特徴とさまざまなビジネスケースでのそれらの使用。そして、私たちがサインを投げることによって、複雑で「ぼやけた」ものとして簡単に「押しのけて」しまうような質問は、設計モデル-レポートを作成し、毎回「互換性のないものを減らす方法」と「車輪の再発明」について考えるとき、分析と設計の間に、今、設定と決定を強いられます。

このアプローチは、脆弱性のないシステムの作成を可能にするエンジニアリング手法の1つです。わかりやすく、透明性があり、開発が容易で、「脆弱性の境界」がすぐにわかるため、新しい要件が発生したときの「災害の規模」と再設計に必要な時間（必要な場合）をより正確に評価できます。
したがって、データモデルは、システムの開発中に維持する必要のある主要な成果物の1つです。良い意味で、それはすべてのアナリスト、開発者などにとって「テーブルの上」にあるべきです。 –システム開発プロジェクトに関係するすべての人。

データモデルの設計は、別の非常に広範なトピックです。ストレージ設計には、主に2つのアプローチがあります。
このアプローチはカーネルに適しています 「実体関連」 -対象領域、より正確には、選択された領域の調査に基づいて正規化（3NF）モデルが構築された場合。ここでは、上で説明したのと同じ「企業モデル」が再生されます。

適切な分析ショーケースを設計する場合 多次元モデル 。このアプローチは、ビジネスユーザーの理解に役立ちます。これは、人間の知覚にとってシンプルで便利なモデルです。人々は、メトリック（インジケーター）とそれらが分析されるセクションの理解可能で馴染みのある概念で動作します。これにより、要件を収集するプロセスを簡単かつ明確に構築できます。さまざまな部門の代表者と連絡を取りながら、一連の「カットとインジケーターのマトリックス」を作成します。そして、それを1つの構造、つまり「分析モデル」にまとめます。「測定バス」を形成し、それらに定義されているファクトを決定します。その過程で、階層と集計ルールに取り組んでいます。

さらに、DBMSの機能を考慮した最適化要素を追加することで、物理モデルに移行するのは非常に簡単です。たとえば、Oracleの場合は、パーティショニング、インデックスのセットなどになります。 Verticaの場合、他の手法（並べ替え、セグメンテーション、セグメンテーション）が使用されます。
特別な非正規化も必要になる場合があります-データに冗長性を意図的に導入する場合、クエリのパフォーマンスは向上しますが、同時にデータの更新が複雑になります（冗長性を考慮してサポートする必要があるため）データ読み込みプロセス）。おそらく、パフォーマンスを向上させるために、追加の集計テーブルを作成するか、Verticaでのプロジェクションなどの追加のDBMS機能を使用する必要があります。

したがって、ウェアハウスデータをモデル化する場合、実際にはいくつかの問題を解決します。

タスクは、コアの概念（論理）モデル（システムおよびビジネス分析）を構築し、サブジェクト領域を調査し、詳細を深め、「ライブデータ」のニュアンスとビジネスでの使用を考慮に入れることです。
分析モデルを構築するタスク-次に、ストアフロントの概念（論理）モデル。
物理モデルを構築するタスクは、データの冗長性管理、クエリおよびデータのロードのためのDBMSの機能を考慮した最適化です。

概念モデルを開発するとき、データベース構造を設計している特定のDBMSの機能を考慮に入れていない場合があります。さらに、1つの概念モデルを使用して、さまざまなDBMS用に複数の物理モデルを作成できます。

まとめましょう。

データモデルは「きれいな絵」のセットではなく、それを設計するプロセスはそれらを描くプロセスではありません。モデルは、主題分野の理解を反映しています。そして、その編集のプロセスは、その研究と研究のプロセスです。これは時間が無駄になるところです。そして、「描画して色を付ける」ことはまったくありません。
データモデルは設計成果物であり、チームメンバー間で構造化された方法で情報を共有する方法です。これを行うには、すべての人が理解でき（これは表記法と説明によって提供されます）、アクセス可能（公開）である必要があります。
データモデルは一度作成されて凍結されるのではなく、システム開発の過程で作成および開発されます。私たち自身がその開発のルールを設定します。そして、それらをより良く、より単純に、より効率的にする方法がわかれば、それらを変更することができます。
データモデル（物理）を使用すると、最適化を目的とした一連のベストプラクティスを統合して使用できます。このDBMSですでに機能している手法を使用してください。

データウェアハウスプロジェクトの特徴

会社がデータウェアハウスを構築および開発するプロジェクトの機能について詳しく見ていきましょう。そして、建築的側面の影響という観点からそれらを見てみましょう。そのようなプロジェクトのために、そして最初からアーキテクチャを構築することが重要なのはなぜですか。また、データウェアハウスプロジェクトに柔軟性を与え、実行者間で作業を効果的に分散し、結果の予測とプロセスの予測を容易にする、よく考えられたアーキテクチャの存在です。

データウェアハウスはカスタムソフトウェアです

データウェアハウスは常に「カスタム開発」であり、ボックス化されたソリューションではありません。はい。参照データモデル、一般的なソース（ERPシステムなど）からの事前構成されたETLプロセス、一連の一般的なBIダッシュボードとレポートを含む業界固有のBIアプリケーションがあります。しかし実際には、ストレージが「ボックス」として実装されることはめったにありません。私はストレージを使って約10年間働いていますが、そのような話は見たことがありません。ビジネスとITの両方の状況で、会社の独自の機能に関連するニュアンスが常にあります。したがって、ソリューションを提供する「ベンダー」がアーキテクチャを提供することを期待するのはやや無謀です。このようなシステムのアーキテクチャは、組織自体の中で成熟することがよくあります。または、プロジェクトの主な請負業者である請負業者の専門家によって形成されます。

データウェアハウスは統合プロジェクトです

データウェアハウスは、多くのソースシステムからの情報をロードして処理します。そして、彼らとの「友好関係」を維持するためには、彼らに細心の注意を払う必要があります。特に、ソースシステムの負荷を最小限に抑え、「可用性とアクセス不能」ウィンドウを考慮し、アーキテクチャを考慮して対話型インターフェイスを選択する必要があります。そうすれば、ストレージは必要な頻度でできるだけ早くデータを収集できるようになります。それ以外の場合は、バックアップ回路に「転送」されます。バックアップ回路は、ほとんどの動作周波数で更新されません。
さらに、「人的要因」を考慮に入れる必要があります。統合は、マシンの相互作用だけではありません。人と人とのコミュニケーションでもあります。

データウェアハウスはチームプロジェクトです

大企業では、このようなシステムを1つのチームだけで実行できることはめったにありません。原則として、ここではいくつかのチームが働いており、それぞれが特定の問題を解決します。

アーキテクチャは、その整合性を維持し、異なる場所で異なる人々による同じ機能の重複を回避しながら、並列作業を編成する可能性を提供する必要があります。不必要な人件費に加えて、そのような重複は後でデータの不一致につながる可能性があります。

さらに、多くの場合散在している非常に多くの人々やチームがシステム開発のプロセスに関与している場合、必然的に問題が発生します。それらの間のコミュニケーションと情報の相互作用をどのように構築するかです。より標準的で理解しやすいアプローチと実践が使用されるほど、そのような作業を設定するのはより簡単で、より便利で、効率的です。そして、それを含めることは、「作業成果物」の構成について考える価値があります。その中で、データウェアハウスの第1は、データモデルです（前のセクションを参照）。

データウェアハウスは、他のシステムと比較して寿命が長くなります

はっきりさせておきますが、このステートメントは、主要なソースと統合され、履歴データを所有し、会社の多くの部門に情報と分析サービスを提供する、「ライブ」の作業用ストレージに当てはまります。

私はそう信じる理由は何ですか？
まず、ストレージの構築は非常にリソースを消費するプロセスです。機器の実際のコスト、必要な技術ソフトウェアと開発のライセンスに加えて、会社のほぼすべてのシステムと部門もこれに関与しています。このプロセス全体を最初から繰り返すことは、非常に大胆な取り組みです。

次に、ストレージに適切なアーキテクチャがあれば、ソースシステムの変更、エンドユーザーからの新しい要件の出現、およびデータ量の増加の両方に簡単に耐えることができます。
アーキテクチャが正しければ、情報の流れは透過的であり、そのようなシステムは、影響の評価が困難なために変更を加えるときに昏迷の状況に陥るリスクなしに、長期間開発できます。

段階的な反復型開発

お客様がストレージのストーリーに関与することを最後に望んでいるのは、完全な企業データモデルが設計され、すべてのソースが完全に接続されるまで、要件を1〜2年間凍結することです。

顧客の目には、データウェアハウスは絶対的な怪物のように見えることがよくあります。システム開発のタスク、目標、および範囲は非常に膨大です。そして、多くの場合、顧客は「予算を犠牲にして」IT部門がいくつかの「独自のタスク」を解決することを恐れています。そして再び、私たちは人々の間の相互作用と自分の立場を冷静に述べ、交渉する能力の問題に直面しています。

有能なアーキテクチャアプローチにより、システムを繰り返し開発し、機能を徐々に向上させることができます。結果を出す前に数年間「開発」を行う必要はありません。

「奇跡は起こらない」ということに注意する必要がありますが、「開始」にも時間がかかります。ストレージの場合、情報を処理するためのルールが現在のものと異なる可能性がある古い期間では、非常に大きくなる可能性があります（これらは大量のデータであるため、これは履歴データです）。したがって、分析開発、ソースシステムとの相互作用、および実際のデータの負荷テストを含む一連の「試行錯誤」には十分な時間が必要です。

データウェアハウス-「マルチプロジェクトストーリー」

データウェアハウスの単一のビジネス顧客を特定することは困難です。そして、ストレージプロジェクトの成功の鍵となる要素は、会社の経営陣、つまり直接最初の人のサポートであると（理由がないわけではありませんが）信じられています。
リポジトリが単一のプロジェクト内で構築および開発されることはめったにありません。原則として、データの統合と分析にはさまざまなニーズがあり、その背後にはさまざまな顧客とユーザーグループがあります。したがって、リポジトリは多くの場合、いくつかの並列プロジェクトのフレームワーク内で開発されます。

イノベーションと実証済みのソリューションのバランス

ストレージのトピックは非常に「古代」であり（そのような言葉がITなどの若い業界に当てはまる場合）、非常に保守的であるという事実にもかかわらず。それにもかかわらず、進歩は止まることはありません-そして、高価で遅いディスク、高価なメモリなどのために以前に存在した制限。 -削除されました。同時に、いくつかのアーキテクチャのアプローチを再考する時が来ました。さらに、これは技術プラットフォームとそれに基づく応用システムのアーキテクチャの両方に当てはまります。

ここでバランスを取ることが重要です。そして、リソースと保存された情報の両方に対してかなり「グリーン」なアプローチを維持することが重要です。それ以外の場合は、リポジトリを非常に迅速に半構造化された「ゴミ捨て場」に変えることができます。これは、整理できれば、かなりの労力を費やすことになります。
はい、私たちにはもっと多くの機会がありますが、これは、時間の経過とともに開発およびテストされたすべての慣行を否定する必要があるという意味ではありません。「イノベーション」の幽霊。
バランスを保つということは、新しい機会を開く新しい方法とアプローチを使用すると同時に、誰もキャンセルしていない緊急の問題を解決するために古い実績のあるものを使用することを意味します。
適用されたソリューションの開発者および設計者として何ができるでしょうか。まず第一に、私たちが取り組んでいるプラットフォームの技術的変化、それらの機能、機能、およびアプリケーションの限界を知り、理解することです。

ストレージにとって最も重要で重要なテクノロジープラットフォームとして、DBMSを見てみましょう。
最近、もともと「ユニバーサル」として作成されたリレーショナルデータベースが、専門化に向けて明確に変化しています。長い間、主要ベンダーは、さまざまなクラス（OLTP、DSS、およびDWH）のアプリケーション向けにさまざまなオプションをリリースしてきました。さらに、テキスト、地理データなどを操作するための追加の機会があります。

しかし、問題はこれに限定されていませんでした-最初は特定のクラスのタスクに焦点を合わせていた製品が登場し始めました-つまり、特殊なDBMS。リレーショナルモデルを使用する場合と使用しない場合があります。重要なことは、一般的な「ビジネス情報」の保存と処理だけでなく、特定のタスクのために、最初は「シャープ」になっていることです。

どうやら、中央集権化と専門化は、定期的に相互に置き換わり、開発とバランスを確保する2つの補完的な傾向です。進化的（段階的）な段階的発達と基本的な変化と同様に。したがって、90年代、Michael Stonebreakerは、第III世代データベースマニフェストの作成者の1人でした。これは、データベースの世界で世界に新たな革命は必要ないという考えを明確に示しています。しかし、10年後、彼は、DBMSの世界で新しい時代が始まるための前提条件を、正確にその専門分野に基づいて発表する作品を公開しています。
彼は、広く普及しているユニバーサルDBMSが、ハードウェアプラットフォームの変更や、アプリケーションをクラスに分割することを考慮しない「万能」アーキテクチャに基づいて構築されているという事実に焦点を当てています。普遍的な要件の実装。
そして、彼はこの考えに従って多くのプロジェクトを開発し始めます。それらの1つは、シェアードナッシング（SN）アーキテクチャで設計された列指向DBMSであるC-Storeであり、元々はデータストレージクラスシステム用に特別に作成されました。この製品は、HPVerticaとしてさらに商品化されました。

現在、データウェアハウスの開発のトピックは新しい開発ラウンドに滑り込んでいるようです。新しいテクノロジー、アプローチ、ツールが登場しています。彼らの研究、テスト、そして合理的なアプリケーションにより、私たちは本当に興味深く有用なソリューションを作成することができます。そして、それらを実装に持ち込み、開発が実際の作業で使用され、利益をもたらすという事実を楽しんでください。

エピローグ

この記事を準備するにあたり、私は主に、データウェアハウスを直接操作するアーキテクト、アナリスト、および開発者に焦点を当てようとしました。しかし、私は必然的に「トピックをもう少し広く取り上げた」ことがわかりました。そして、他のカテゴリーの読者が視野に入ったのです。いくつかの点は物議を醸すように見えるでしょう、いくつかは明確ではありません、いくつかは明白です。人々は異なります-異なる経験、背景、立場を持っています。
たとえば、管理者の典型的な質問は、「いつ建築家を引き付けるか」、「いつ建築を行うべきか」、「建築-それは高すぎるのではないか」です。私たち（開発者、設計者）にとってはかなり奇妙に聞こえます。なぜなら、私たちにとって、システムのアーキテクチャはその誕生とともに現れるからです。私たちがそれを実現するかどうかは関係ありません。また、プロジェクトにアーキテクトの正式な役割がない場合でも、通常の開発者は常に「内部アーキテクトをオンにします」。

物事の壮大な計画では、誰が建築家の役割を正確に果たしているかは実際には重要ではありません-重要なのは、誰かがこれらの質問をし、それらに対する答えを探求することです。アーキテクトが明確に選ばれている場合、これは彼が主にシステムとその開発に責任があることを意味するだけです。
なぜ私はこの主題に関連する「抗脆弱性」のトピックを見つけたのですか？

「脆弱性対策の独自性は、未知のものを処理し、自分が何をしているのか正確に理解していない状況で何かを実行し、成功することを可能にすることです。」/ナシムN.タレブ/

したがって、危機と高度な不確実性は、アーキテクチャの欠如の言い訳ではなく、その必要性を強化する要因です。

統一された企業データウェアハウスの作成。 エンタープライズデータモデルに基づいてデータウェアハウスモデルを作成します。 業界データモデル