データアーキテクチャ

データアーキテクチャは、収集されるデータとそのデータの保存方法、整理方法、統合方法、データシステムや組織での使用方法を規定するモデル、ポリシー、ルール、標準で構成されています。 ^{[1]データは通常、}エンタープライズアーキテクチャまたはソリューションアーキテクチャの柱となる複数のアーキテクチャドメインの1つです。^[2]

データアーキテクチャは、すべてのデータ システムのデータ標準を、それらのデータ システム間の最終的な相互作用のビジョンまたはモデルとして設定することを目的としています。たとえば、データ統合では 2 つ以上のデータ システム間のデータ相互作用が必要になるため、データ統合はデータ アーキテクチャ標準に依存する必要があります。データ アーキテクチャは、部分的には、ビジネスとそのコンピューターアプリケーション ソフトウェアで使用されるデータ構造を記述します。データ アーキテクチャは、保存されているデータ、使用中のデータ、移動中のデータ、データ ストア、データ グループ、データ項目の説明、およびそれらのデータ成果物とデータ品質、アプリケーション、場所などのマッピングに対応します。

データ アーキテクチャは、目標状態を実現するために不可欠であり、情報システムでデータがどのように処理、保存、使用されるかを記述します。データ フローを設計し、システム内のデータ フローを制御する ためのデータ処理操作の基準を提供します。

データアーキテクトは通常、ターゲット状態の定義、開発中の調整、そして元のブループリントの精神に沿って機能強化が行われるようにフォローアップする責任を負います。

ターゲット状態の定義中に、データ アーキテクチャは主題を原子レベルまで分解し、それを目的の形式に再構築します。データ アーキテクトは、次の 3 つの従来のアーキテクチャ段階を経て主題を分解します。

• 概念的 - すべてのビジネス エンティティを表します。
• 論理的 - エンティティがどのように関連しているかのロジックを表します。
• 物理的 - 特定の種類の機能のためのデータ メカニズムの実現。

エンタープライズアーキテクチャの ザックマンフレームワークの「データ」列–

2 番目のより広い意味では、データ アーキテクチャには、組織の機能、利用可能なテクノロジ、およびデータ タイプ間の関係の完全な分析が含まれます。

データ アーキテクチャは、新しいデータ処理およびストレージ システムの設計の計画段階で定義する必要があります。企業をサポートするために必要な主要なデータの種類とソースは、完全で一貫性があり、理解しやすい方法で識別する必要があります。この段階での主な要件は、コンピューター ハードウェア項目を指定することではなく、関連するすべてのデータ エンティティを定義することです。データ エンティティとは、組織または個人がデータを保存したい実際のものまたは抽象的なもののことです。

情報システムの物理データ アーキテクチャは、テクノロジ プランの一部です。テクノロジ プランは、データ アーキテクチャ設計の実装で使用される実際の具体的な要素に重点を置いています。物理データ アーキテクチャには、データベース アーキテクチャが含まれます。データベース アーキテクチャは、設計されたデータ アーキテクチャをサポートする実際のデータベース テクノロジの スキーマです。

データ アーキテクチャ スキーマの設計フェーズでは、特定の要素を定義する必要があります。たとえば、データ リソースを管理するために確立する管理構造を記述する必要があります。また、データを格納するために使用する方法論を定義する必要があります。さらに、使用するデータベース テクノロジの説明と、データを操作するプロセスの説明を生成する必要があります。他のシステムによるデータへのインターフェイスを設計することや、一般的なデータ操作 (緊急手順、データのインポート、データのバックアップ、データの外部転送など)をサポートするインフラストラクチャの設計も重要です。

適切に実装されたデータ アーキテクチャ設計のガイダンスがなければ、共通のデータ操作がさまざまな方法で実装される可能性があり、そのようなシステム内のデータ フローを理解して制御することが困難になります。このような断片化は、潜在的なコストの増加やデータの切断が発生する可能性があるため、望ましくありません。このような困難は、急速に成長している企業や、さまざまな事業分野にサービスを提供している企業で発生する可能性があります。

情報システム計画のデータアーキテクチャフェーズを適切に実行すると、組織は内部と外部の両方の情報フローを指定および記述する必要があります。これらは、組織がこれまで時間をかけて概念化していなかったパターンです。したがって、この段階で、データアーキテクチャ分析の前には明らかではなかった可能性のある、コストのかかる情報不足、部門間の断絶、組織システム間の断絶を特定できます。^[4]

データ アーキテクチャの設計には、さまざまな制約と影響が影響します。これには、企業の要件、テクノロジの推進要因、経済性、ビジネス ポリシー、データ処理のニーズなどが含まれます。

エンタープライズ要件

これらには一般に、経済的で効果的なシステム拡張、許容可能なパフォーマンス レベル (特にシステム アクセス速度)、トランザクションの信頼性、透過的なデータ管理などの要素が含まれます。さらに、データ ウェアハウスなどの機能を使用して、トランザクションレコードや画像ファイルなどの生データをより有用な情報形式に変換することも、経営上の意思決定やその他の組織プロセスを可能にするため、一般的な組織要件です。アーキテクチャ手法の 1 つは、トランザクション データと (マスター)参照データの管理を分割することです。もう 1 つは、データ キャプチャ システムとデータ検索システムを分割することです(データ ウェアハウスで行われるように)。

テクノロジーの推進要因

これらは通常、完成したデータ アーキテクチャとデータベース アーキテクチャの設計によって提案されます。さらに、一部のテクノロジ ドライバーは、既存の組織統合フレームワークと標準、組織の経済性、および既存のサイト リソース (以前に購入したソフトウェア ライセンスなど) から派生します。多くの場合、複数のレガシー システムを統合するには、データ仮想化テクノロジを使用する必要があります。

経済

これらも、データ アーキテクチャ フェーズで考慮する必要がある重要な要素です。一部のソリューションは、原則的には最適であっても、コストの面から候補にならない可能性があります。ビジネス サイクル、金利、市況、法的考慮事項などの外部要因はすべて、データ アーキテクチャに関連する決定に影響を及ぼす可能性があります。

事業方針

データ アーキテクチャ設計を推進するビジネス ポリシーには、社内組織ポリシー、規制機関の規則、専門基準、該当する政府機関によって異なる適用法などが含まれます。これらのポリシーと規則は、企業がデータを処理する方法を規定します。

データ処理のニーズ

これらには、大量に実行される正確で再現可能なトランザクション、管理情報システム（および潜在的なデータマイニング）をサポートするためのデータウェアハウス、反復的な定期レポート、アドホックレポート、および必要に応じてさまざまな組織イニシアチブ（年間予算、新製品開発など）のサポートが含まれます。

• 制御された語彙
• データメッシュ、ドメイン指向データアーキテクチャ
• 異なるシステム
• エンタープライズ情報セキュリティ アーキテクチャ(EISA) は、データ セキュリティをエンタープライズ情報フレームワークに位置付けます。
• FDIC エンタープライズ アーキテクチャ フレームワーク
• 情報サイロ
• トガフ

• Bass, L.; John, B.; & Kates, J. (2001).ソフトウェアアーキテクチャによるユーザビリティの実現、カーネギーメロン大学。
• ルイス、G.コメラ・ドルダ、S.プレイス、P.プラコシュ、D. & Seacord、R.、(2001)。エンタープライズ情報システム データ アーキテクチャ ガイド、カーネギーメロン大学。
• Adleman, S.; Moss, L.; Abai, M. (2005).データ戦略Addison-Wesley Professional.

ウィキメディア・コモンズには、データ アーキテクチャに関連するメディアがあります。

• ソフトウェアアーキテクチャによるユーザビリティの実現、sei.cmu.edu 2001
• 論理データアーキテクチャ、Nirmal Baid 著
• 最新のデータと分析アーキテクチャの構築
• DataOps による「修復する権利」データ アーキテクチャ、DataOps ブログ
• TOGAF 9: 準備プロセス