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

DB

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

これらを分析しながら、システム構築を行う業務についても分析しながら、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をコピーしました