システム開発＜基本編＞データベースの分析

DB
2025.06.04

今回は、データベースの分析について、記載をしたいと思います。

これらを分析しながら、システム構築を行う業務についても分析しながら、ER図の作成を

行ってみようと思いますが、その前に、開発アプローチの変遷について確認しておきます。

開発アプローチの変遷

POA

POAとは、Process Oriented Approach（プロセス中心アプローチ）の事です。

1960～70年代は、業務プロセスやシステムの機能に着目するPOAが主流でした。

業務プロセスと機能をモデリングし、それを忠実にプログラム言語で記述して行く

開発スタイルで、モデリングでは、DFD（Data Flow Diagram：データフローダイヤグラム）

が採用されていました。

  • 起源：1960年代後半の「構造化プログラミング」と言われる
  • 長所：プログラムのアルゴリズムとの親和性が高いので、プログラミングに直結する
  • 短所：データがプログラム毎にバラバラに設計されるので、重複や不整合が起こりやすい
  • ツール：DFD、フローチャート

DOA

DOAとは、Data Oriented Approach（データ中心アプローチ）の事です。

業務システムが複雑になるにつれて、データの重複や不整合、システムの保守性の

低下といったPOAの問題点が顕在化になりました。

1980～90年代は、業務プロセスの着目から、データに着目したDOAが主流でした。

データ構造をER図などでモデリングして、システムを開発していました。

ERモデルは、データ項目の集まりである「エンティティ（Entity：実体）」と、

エンティティ間の論理的な繋がりを定義した「リレーションシップ（Relationship：関連）」

を使って、データ構造を図示したものになります。

  • 起源：1975年にピーター・チェンが提唱した「ER（Entity Relationship）モデル」と言われる
  • 長所：ER図でモデリングしたデータ構造は、RDBMSで実装し易かった
  • 短所：システムの追加・修正でデータ構造を変更する場合、多大な手間と時間が掛かる
  • ツール：ER図

OOA

OOAは、Object Oriented Approach（オブジェクト指向アプローチ）の事です。

一度モデリングしたデータ構造を変更すると、関連するプログラムを特定するのが極めて難しく、

手間と時間が掛かると言ったDOAの問題点が顕在化になりました。

「データ」と「プログラム」が切り離されているのが起因とされ、「データ」と「プログラム

（メソッド）」の一体化が求められ、「カプセル化したオブジェクト」が登場しました。

2000～10年代は、データのみの着目から、オブジェクトに着目したOOAが主流となりました。

オブジェクト内部のデータ構造が、他のオブジェクトに依存しない為、オブジェクト同士が部品の

ように組み合わせたり、機能の追加や修正、再利用が可能で、メンテナンスが容易となりました。

  • 起源：1950年代にアラン・ケイ氏が提唱された「オブジェクト指向」の概念と言われる
  • 長所：カプセル化に寄るセキュリティ強化と、クラスを継承して再利用したり、機能の追加・修正も容易である
  • 短所：クラスを細分化して実装すると、類似した処理が重なってしまったり、全体像が見えなくなる場合が有ります
  • ツール：クラス図、シーケンス図などのUML（Unified Modeling Language：統一モデリング言語）

SOA

SOAは、Service Oriented Architecture（サービス指向アーキテクチャ）の事です。

2000年を過ぎて来ると、インターネットも普及しクラウドサービスも出てきました。

既に作られた機能や類似のデータ、類似のサービスがある世の中になったので、

開発スタイルもサービスを組み合わせて、新しいサービスを作るアプローチが出てきます。

「ソフトウェアの機能」と「サービス」を、ネットワーク上で連携させてシステムの全体を

構築していく手法になります。

2020年以降は、オブジェクトの着目から、サービスへの注目したSOAが、一部の自治体や

一部の大手企業、ネットワークを介した多国籍企業、ECサイトで普及しています。

  • 起源：1990年代に、Gartner社が提唱したと言われる
  • 長所1：高度なシステム構築、プログラミング言語の仕様、サーバー、ネットワーク部分の機能を作らずに、既に提供されているサービスの組み合わせで出来る
  • 長所2：ライブラリなどの関数1行で、高度な機能が実現できるので、コードを書くとしても、少なくて済む「ローコード開発」も出来るようになり、流行っています。
  • 短所1：多額の先行投資を必要とすることや、運用の際、サービス間の相互連携の度に、全てのパラメータで完全な検証が行われるため、レスポンス時間は長くなります
  • 短所2：企業のシステム開発を手掛ける一般の開発者に、SOAを理解してもらうのは非常に難しく、技術としてマスターするのも、実装するのも、メンテナンスするのも、簡単には行かない
  • ツール：サービス仮想化

データベースの分析

上記において、開発アプローチの変遷を見て来ましたが、多くの開発現場では、下記のスタイルで、

アプリケーションやシステム開発を実施している状況です。

  • 開発言語：オブジェクト指向プログラミング言語（OOP）→Java/JavaScript/TypeScript/C++/C#/Python/Ruby/Swift/Kotrin等
  • データベース：RDBMS（DOA）→MySQL/Oracle Database/Microsoft SQL Server等
  • O/Rマッピング：上記2つの間で、データの相互交換を実現する機能で、フレームワークやO/Rマッピングツール等利用して実装します

コード体系の分析

【データを扱う上で、データベース（DB）を知り、設計・実装・操作が出来れば、様々なアプリや

システムの設計・開発に対して、柔軟に対応が出来る】と、下記の記事で記載していました。

システム開発＜基本編＞先ずはDB設計がお勧め

では、多くの開発現場で、未だに利用されている

  • データベース：RDBMS（DOA）

について、データベースの分析、コード体系の分析をしながら、ER図の作成をして行きます。

ER図のサンプル（問題提起）

下記のER図のサンプルを見て下さい。

これは、開発現場で多く見掛ける「販売管理システム」のER図の一部です。

全体のER図が描かれていないので、少し判断が難しいかもしれませんが、

  • 【メーカー（エンティティ：makers）】
  • 【製品（エンティティ：products）】
  • 【カテゴリー（エンティティ：categories）】

と「リレーションシップ（Relationship：関連）」は、正しいでしょうか？

利用ツール：A5:SQL Mk-2

各エンティティに、「削除日」が含まれていないので正しくない…とか、

【製品（エンティティ：products）】の中に含まれている「製品希望売値」が、

自社の業務には含まれていないので正しくない…とか、

細かな部分について、指摘する問題提起では無いです。

【前提】として、各エンティティ内の「コード」と「アトリビュート（属性）」は

正しいものとして下さい。

では、ER図のサンプルは、正しいでしょうか？

まとめ

最後に、サンプルのER図を見てもらって、問題提起をしました。

このサンプルER図についての回答と解説は、別の記事で投稿しようと思います。

 

コメント

タイトルとURLをコピーしました