Categories: データベース理論

データ中心アプローチ（DOA）とは？開発手順と概要を初心者向けに解説

システム開発における手法の1つであるデータ中心アプローチ。データベースの設計には、システム開発アプローチの理解が必要であり、その中でも最も「データ」への関連が深い手法がデータ中心アプローチです。

このアプローチは何を意味し、どのような流れで進行するのでしょうか？

この記事では、初心者の方でも理解できるようにデータ中心アプローチの概要と開発手順を詳しく解説します。

データ中心アプローチの概要

この章ではシステム開発アプローチのひとつである「データ中心アプローチ」について、基本的な概要と大まかな流れを説明します。

データ中心アプローチ（DOA）とは

データ中心アプローチ（Data Oriented Approach）は、システム開発のアプローチの1つで、業務で扱うデータの構造や流れを中心にシステム設計を行います。

システム開発アプローチとは？データベース設計の手法を解説

これは、システムがデータを基盤とし、それを中心に機能やプロセスを組み立てるという考え方です。特にデータの整合性や一貫性が重要なシステムや、将来的に柔軟に対応できるような設計が求められる場合に優れています。

このアプローチの対立概念としては、プロセス中心アプローチ（Process Oriented Approach）があります。POAは、業務上の処理（プロセス）を中心にシステムを設計する手法であり、現実の手順に基づいてシステムの動作を考えます。POAは業務プロセスの詳細な反映や高速なシステム導入が必要な場合などに適しています。

それぞれのアプローチはその強みと適用領域があり、どちらが絶対的に優れているわけではありません。システムの目的や要件、開発環境、開発チームのスキルセットなど、さまざまな要素を考慮して最適なアプローチが選択されます。

「データ活用」の重要性が高まっている現代では、システム開発手法においてもデータ中心アプローチの需要が高まっています。今後もこの傾向は続くでしょう。

データ中心アプローチの流れ

データ中心アプローチの開発フローは、大まかに下記の4つのステップで構成されます。

データモデリング: ここで業務で扱うデータの構造を定義します。これには、データの種類、関連性、整合性などの情報が含まれます。
データベース設計: データモデリングで定義したデータ構造を元に、データベースの設計を行います。
システム設計: ここで、データベースと連携するシステムの機能やプロセスを設計します。
システム開発・テスト: 設計したシステムを開発し、テストを行いながら最終的なシステムを構築します。

この流れはあくまで一例であり、具体的な開発フローはプロジェクトの具体的な要件や状況により異なります。データ中心アプローチでは基本的にデータから出発し、それを中心にシステム全体を設計・開発します。

データ中心アプローチにおける開発手順

この章では、データ中心アプローチにおける開発手順（主にモデリング）を詳しく説明します。各工程で、具体的にどのような定義、開発を行っているのか例示しますので、理解を進めていきましょう。

1. システム化対象業務の決定

データ中心アプローチの開発手順の最初のステップは、システム化対象となる業務を明確に決定することです。

ここでは、業務の内容、対象となるデータの種類とその関連性、業務の範囲などを明確にし、システム開発の対象範囲を定義します。この時点で詳細なデータモデリングを行う必要はありませんが、対象となる業務から得られるデータの全体像を把握することが重要です。

2. 概念設計（モデリング）と概念データモデルの作成

次に、概念設計（モデリング）を行い、概念データモデルを作成します。

このステップでは、システム化対象となる業務で扱うデータの構造と関係性を明確にします。具体的なテーブルやフィールドの設計はまだ行わず、ビジネスロジックやルールを反映したデータの関連性や属性を概念レベルで定義します。

たとえば、顧客と注文の関連性や、商品とカテゴリの関連性などを定義します。

補足

概念データモデルでは、それぞれのエンティティとその関連性を定義します。この段階では、具体的なテーブルやフィールドの設計は行いません。

Entities: 顧客, 書籍, 注文
Relationships:
- 顧客は0以上の注文を持つ
- 注文は1つの顧客に属する
- 注文は1以上の書籍を含む
- 書籍は0以上の注文に含まれる

エンティティとは？データベースとその他の分野での意味を解説

3. 論理設計と論理データモデルの作成

概念データモデルが完成したら、次は論理設計と論理データモデルの作成に移ります。

このステップでは、概念設計で定義したデータ構造をもとに、データベースに反映できる具体的なデータモデルを作成します。ここで定義するデータモデルではデータベースのテーブルやフィールド、その間のリレーションシップを表現します。

補足

論理データモデルでは、具体的なテーブルとフィールドを設計します。以下は、それぞれのエンティティに対応するテーブルと、それらの関連を定義しています。

Tables:
Customer (id, name, address)
Book (id, title, author, price)
Order (id, customer_id, date)
Order_Detail (order_id, book_id, quantity)

4. 物理設計と物理データモデルの作成

最後に、物理設計と物理データモデルの作成を行います。

このステップでは、実際のデータベースシステムに論理データモデルを実装します。論理データモデルがどのように物理データベースにマッピングされるか、また、どのようにデータが格納、アクセスされるかなどを定義します。

物理データモデルは、データベースの性能や効率を最適化するための詳細設計を含みます。

補足

物理設計では、具体的なデータベースの設定を行います。これにはテーブルのストレージ設定、インデックス、ビューなどが含まれます。

CREATE TABLE Customer (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    address VARCHAR(200)
);

CREATE TABLE Book (
    id INT PRIMARY KEY,
    title VARCHAR(100),
    author VARCHAR(100),
    price DECIMAL(5,2)
);

CREATE TABLE Order (
    id INT PRIMARY KEY,
    customer_id INT,
    date DATE,
    FOREIGN KEY (customer_id) REFERENCES Customer(id)
);

CREATE TABLE Order_Detail (
    order_id INT,
    book_id INT,
    quantity INT,
    FOREIGN KEY (order_id) REFERENCES Order(id),
    FOREIGN KEY (book_id) REFERENCES Book(id)
);

これらの手順は一連の流れとして行われますが、各ステップごとに適宜レビューと修正を行いながら進めることが大切です。また、開発プロジェクトの具体的な要件や状況に応じて、これらの手順をカスタマイズすることもあります。

データ独立の重要性

データ独立性とは、データベースの論理構造と物理構造が独立しているという概念であり、この原則が保たれていることにより、データベースの管理が容易になり、またシステム全体の変更に対する影響を最小限に抑えることが可能になります。

この概念は、システム開発においても非常に重要です。

データベースとは？初心者でも理解できる基本とやさしい解説

論理データ独立とその重要性

論理データ独立性とは、データベースの論理構造（データとその関連性を定義する設計）がアプリケーションプログラムから独立しているというデータベースの基本概念です。

これにより、データベースの論理構造が変更されても、それを利用するアプリケーションプログラムには影響がないという状態を維持できます。たとえば、あるテーブルに新たなフィールドを追加したとしても、既存のアプリケーションプログラムには影響がないということです。

この論理データ独立性が保たれることにより、データベースの構造を変更してもそれに伴うプログラムの修正の必要性が最小限に抑えられます。これにより、システムの保守性が向上し、開発の効率化やシステム全体の耐久性が高まります。

物理データ独立とその重要性

物理データ独立性とは、データベースの物理構造（データがどのようにストレージに保存されるか）が論理構造やアプリケーションプログラムから独立しているという概念です。

これにより、ストレージの設定やデータの配置が変更されても、データベースの論理構造やそれを利用するアプリケーションプログラムには影響がないという状態を維持できます。

物理データ独立性が保たれることにより、データベースの物理的な配置やストレージの変更（例えば、パフォーマンス改善のための再編成など）を行っても、それに伴うアプリケーションの修正の必要性が最小限に抑えられます。これにより、システムのパフォーマンスの最適化や拡張性の確保が容易になります。

以上のように、データ独立性はデータ中心アプローチにおいて非常に重要な概念であり、これによりシステムの効率性、拡張性、保守性が向上しているのです。

3層スキーマアーキテクチャの基本

3層スキーマアーキテクチャはデータベースの設計において非常に重要な概念であり、データ中心アプローチを理解するためにはこのアーキテクチャの理解も必要です。

なお、スキーマについては、データベースの根幹を成す重要な概念のため、後日、別記事で詳しく説明しますので、当記事では基本的な概要に留めています。

スキーマとは？データベース（DB）の豊富な実例を交えて初心者向けに解説

スキーマとは

スキーマとは、データベースの構造を定義するためのフレームワークです。

具体的には、データの種類、データ間の関係、データの属性などを含む、データベース内のデータの構造と組織を定義します。スキーマはデータの実際の内容ではなく、データがどのように構成され、どのように相互に関連しているかを定義する設計図のようなものと考えることができます。

補足

スキーマはデータの構造と属性を示すフレームワークで、データベースに格納されるデータの静的な側面を表します。つまり、具体的なデータではなく、データの形式や型、関連性を定義します。

たとえば、ある企業が顧客情報を管理するためのスキーマを設計するとします。その場合、下記のようなテーブルが想定されます。

Customer
- CustomerID
- FirstName
- LastName
- Email
- Phone

この例では、顧客（Customer）テーブルがCustomerID、FirstName、LastName、Email、Phoneのフィールドを持つことを定義しています。

3層スキーマアーキテクチャとは

3層スキーマアーキテクチャは、データベースの設計を3つのレベル、つまり外部スキーマ（ユーザーレベル）、概念スキーマ（企業レベル）、内部スキーマ（物理レベル）に分けて考える方法です。これにより、データベースの複雑さを抽象化し、各ステークホルダーが自分の関心領域に集中できるようにします。

アーキテクチャとは？主にIT用語として初心者向けに解説します

補足

3層スキーマアーキテクチャでは、データの実体、その論理的な表現、そして個々のユーザーが見るビューをそれぞれ異なるレベルで管理します。

具体的には、下記のようになります。

内部スキーマ（物理レベル）：データが物理的にどのようにストレージ上に格納されているかを定義します。このレベルは主にパフォーマンスや効率性を考慮します。
概念スキーマ（企業レベル）：全てのユーザーが必要とするデータとその関係性を定義します。ここで定義されるのは、前述の「Customer」テーブルのようなデータ構造です。
外部スキーマ（ユーザーレベル）：個々のユーザーやアプリケーションが見るビューを定義します。このレベルでは、具体的なビジネス要件に応じて必要なデータだけを見せるようにします。例えば、あるユーザーには「Customer」テーブルの「FirstName」と「LastName」フィールドだけが見える、というようなビューを定義することができます。

以上のように、3層スキーマアーキテクチャでは、各レベルのスキーマが異なる視点からデータを表現し、データの物理的な格納方法からユーザーが見るビューまでを網羅します。

3層スキーマアーキテクチャの役割

3層スキーマアーキテクチャの役割は、各スキーマレベルが独立して機能することで、データベースの変更に伴う影響を各レベル内に局所化することです。

つまり、物理スキーマの変更が概念スキーマや外部スキーマに影響を及ぼさないようにすることで、システムの柔軟性と保守性を向上させます。また、各ユーザーは自分の視点に合わせたデータビューを持つことができ、データベースの複雑さを抽象化します。

あとがき

この記事では、「データ中心アプローチ（DOA）」の概要と開発手順をテーマに、DOAがどのような仕組みで、どのような手順で行われるのか、またその一部として3層スキーマアーキテクチャの概要についても解説しました。

本文で説明した通り、現代のシステム設計では、データを中心に据えるDOAが多く採用されています。このため、システムがより効率的に動作し、業務変更にも柔軟に対応できるようにするためには、この記事で紹介したDOAの基本的な概念を理解することが重要です。

一方、データベースの活用にはさまざまなIT分野の知識も必要となります。当サイトでは、今回紹介した「データ中心アプローチ」以外の手法やデータベースに関する網羅的な情報を引き続き発信していきますので、またご覧頂けると幸いです。

Analytics沖縄

データサイエンス・機械学習・ディープラーニングを本格的に研究するフリーランスエンジニア。「Google データアナリティクスプロフェッショナル」の認定証を取得済み。この分野は専門知識がなければ理解し辛い情報が多いのですが、当サイトでは初学者も意識して発信していきますので、ご関心があればぜひご覧ください。