今回は、データベースの分析について、記載をしたいと思います。
これらを分析しながら、システム構築を行う業務についても分析しながら、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)を知り、設計・実装・操作が出来れば、様々なアプリや
システムの設計・開発に対して、柔軟に対応が出来る】と、下記の記事で記載していました。
では、多くの開発現場で、未だに利用されている
- データベース:RDBMS(DOA)
について、データベースの分析、コード体系の分析をしながら、ER図の作成をして行きます。
ER図のサンプル(問題提起)
下記のER図のサンプルを見て下さい。
これは、開発現場で多く見掛ける「販売管理システム」のER図の一部です。
全体のER図が描かれていないので、少し判断が難しいかもしれませんが、
- 【メーカー(エンティティ:makers)】
- 【製品(エンティティ:products)】
- 【カテゴリー(エンティティ:categories)】
と「リレーションシップ(Relationship:関連)」は、正しいでしょうか?
利用ツール:A5:SQL Mk-2
各エンティティに、「削除日」が含まれていないので正しくない…とか、
【製品(エンティティ:products)】の中に含まれている「製品希望売値」が、
自社の業務には含まれていないので正しくない…とか、
細かな部分について、指摘する問題提起では無いです。
【前提】として、各エンティティ内の「コード」と「アトリビュート(属性)」は
正しいものとして下さい。
では、ER図のサンプルは、正しいでしょうか?
まとめ
最後に、サンプルのER図を見てもらって、問題提起をしました。
このサンプルER図についての回答と解説は、別の記事で投稿しようと思います。
- イラスト:いらすとや より引用
コメント