エンティティのライフサイクル

はじめに

エンティティのデータには作成から削除にいたるライフサイクルが存在します．言い換えれば，エンティティのデータには作成と削除のプロセスが存在しなければなりません．当然のことのようですが，システム開発の早い時期に整理する必要があります．注意しないと，本番稼動後までこれらの欠落に気がつかないこともあります．

ライフサイクル定義の目的

組織体の持つプロセスを洗出しエンティティと関連付けることで，作成プロセスや削除プロセスのないエンティティをなくすことがライフサイクル定義の目的です．

まず，ここではプロセス以下のように定義します．

プロセス

組織体におけるエンティティを使用した活動，およびエンティティを使用して発生する事象．

エンティティの定義はエンティティとリレーションシップで述べた通り「組織体が認識できるもの・概念」です．

作成プロセスのないエンティティ（誰も作れないのに，データは存在することになっている）に問題があることは言うまでもありません．削除のプロセスのないエンティティ（作ったら最後，誰も消すことができない）はデータが無制限に増加します．必要な記憶領域も無制限に増加し，システム破綻の一因となります．

複数のプロセスが同じエンティティに対して作成や削除を行っている場合には，それらの要否を検討します．重複している可能性があります．

また，作成と削除のプロセスは「これを行うための画面」とは異なるものです．エンティティは日々のプロセスの中で新しいデータを取得し，古いデータを抹消していかなければなりません．

セキュリティ

「作成と削除プロセスの存在しないエンティティをなくす」すなわち「エンティティには必ず作成と削除のプロセスが存在する」とは「データの作成と削除は誰にでもできる」ことではありません．「エンティティに存在しなければならない作成と削除のプロセス」と「これらのプロセスを使用できる権限」とは別問題です．

「作成・削除プロセスの存在しないエンティティ」と「これはエンドユーザは操作しないテーブルなので，登録・修正画面はいりません」とは異なるものです．

後者はセキュリティの問題です．「勝手にデータを変えると困る」と言う理由で特定のエンティティに作成や削除のプロセスを用意しないのは誤りです．俗に「マスタテーブル」と呼ぶものが，このような扱いを受けやすい性質を持っています．「エンドユーザは操作しない」ということは「エンドユーザ以外の人が操作する」と言うことです．エンドユーザ以外の人の操作をきちんと洗い出さなくてはなりません．

全てのエンティティには必ず作成と削除のプロセスを用意し，これらを実行する権限に制限を加えるべきです．そして，これらの実行体は後述するアプリケーションルールで検討します．

エンティティ・プロセス関連図

このライフサイクルを定義するために，ここではエンティティ・プロセス関連図を用います．エンティティ・プロセス関連図は下記のような表で，それぞれのセルに「C：作成・D：削除・U：更新・R：参照」の中から該当するものを記入します．

この例は次のような状態を表しています．

• エンティティ１はプロセス１を用いて必要なデータを作成，プロセス３により不要なデータを削除．
• エンティティ２はプロセス１を用いて必要なデータを作成・更新，参照にはプロセス２を使用．
• エンティティ３はプロセス２を用いて必要なデータを参照．

このように書くこともできます．

• プロセス１はエンティティ１とエンティティ２にデータを作成・更新．
• プロセス２はエンティティ２とエンティティ３のデータを参照．
• プロセス３はエンティティ１のデータを削除．

具体例

「エンティティとリレーションシップ」で作成した業務概要とER図を元に，エンティティのライフサイクルを検証します．業務概要とER図は以下の通りです．

ソフトウェアの管理システムです．保有しているソフトウェアや製造元・販売元・アップグレードの履歴を管理します．各ソフトウェアには管理者が存在し，アップグレードの手続きはこの管理者が行います．ソフトウェアの機器への導入は，管理者がライセンスの有無を確認した上で随時行います．使用しなくなったソフトウェアも導入機器から随時削除します．

図1.ER図

プロセスの抽出

業務概要から以下のプロセスを抽出します．

• アップグレード
• 機器への導入
• 機器からの削除

エンティティ・プロセス関連図を書くまでもなく，明らかに足りないプロセスは付け足しましょう．「ライセンスの購入」と「ライセンスの破棄」は明らかに必要です．この二つをプロセスに加え，エンティティ・プロセス関連図を作成します．

これは次のような状態を表しています．

• エンティティ「取引先」のデータはプロセス「ライセンスの購入」が参照している．
• エンティティ「ソフトウェア」データはプロセス「ライセンスの購入」が参照している．
• エンティティ「ライセンス」データはプロセス「ライセンスの購入」が作成，プロセス「アップグレード」と「機器への導入」が参照，プロセス「ライセンスの破棄」が削除している．
• エンティティ「社員」のデータはプロセス「ライセンスの購入」が参照している．
• エンティティ「管理者」のデータはプロセス「ライセンスの購入」が作成，プロセス「ライセンスの破棄」が更新，プロセス「アップグレード」と「機器への導入」が参照している．
• エンティティ「導入機器」のデータはプロセス「機器への導入」が作成，プロセス「ライセンスの破棄」が参照，プロセス「機器からの削除」が削除している．
• エンティティ「アップグレード」のデータはプロセス「アップグレード」で作成している．

このように書くこともできます．

• プロセス「ライセンスの購入」では，エンティティ「取引先」・「ソフトウェア」・「社員」のデータを参照し，エンティティ「ライセンス」・「管理者」にデータを作成する．
• プロセス「ライセンスの破棄」では，えとティティ「導入聞き」のデータを参照し，エンティティ「ライセンス」のデータを削除，エンティティ「管理者」のデータを更新する．
• プロセス「アップグレード」では，エンティティ「ライセンス」・「管理者」のデータを参照し，エンティティ「アップグレード」のデータを作成する．
• プロセス「機器への導入」では，エンティティ「ライセンス」・「管理者」のデータを参照し，エンティティ「導入機器」にデータを作成する．
• プロセス「機器からの削除」では，エンティティ「導入機器」からデータを削除する．

第１案には以下の問題点があります．

• エンティティ「取引先」・「ソフトウェア」・「社員」のデータには，作成プロセスも削除プロセスもない．
• エンティティ「アップグレード」には，作成プロセスのみで削除プロセスはない．

これらの問題点解決のため，業務を以下のように定義します．

• ライセンス購入時に，購入したライセンスに該当するデータが，エンティティ「取引先」・「ソフトウェア」になかった場合，新しくデータを作成する．内容が古かった場合は更新する．
• ライセンス破棄時に，破棄するライセンスに該当するアップグレード履歴を，エンティティ「アップグレード」から削除する．
• ライセンス破棄時に，他のライセンスが存在しないデータをエンティティ「ソフトウェア」から削除する．
• ライセンス破棄時に，他のソフトウェアが存在しないデータをエンティティ「取引先」から削除する．
• エンティティ「社員」のデータの改廃は「ソフトウェア管理システム」の範疇ではなく「人事システム」の範疇とする．

エンティティ「社員」について少し説明します．このエンティティは「ソフトウェア管理者となった社員」に関するデータを保管するものであると同時に，「ソフトウェア管理者ではない社員」のデータも蓄積できます．つまり，社員全般のデータを蓄積する性質を持ったエンティティです．このエンティティは今回開発対象となった「ソフトウェア管理システム」の範疇を越えています．既に他のシステム，例えば人事システムに存在している可能性があります．もしそうなら，そのエンティティを流用し，改廃はそのシステムに任せます．

今回は，この前提とします．したがって，ソフトウェア管理システムでは人事システムののエンティティ「社員」を流用します．

あいにく，エンティティ「社員」が他のシステムには存在しない場合，あるいは他のシステム自体が存在しない場合，プロセス「ライセンスの購入」でエンティティ「社員」のデータの追加・更新を，プロセス「ライセンスの破棄」でエンティティ「社員」のデータの削除を行うと定義します．

もし，「人事システムは人事システム用の社員エンティティなので流用はできない．ソフトウェア管理システムはソフトウェア管理システム用の社員エンティティを作るべきだ」と考えているのなら，概要の再読をお勧めします．

これらを考慮の上エンティティ・プロセス関連図を修正すると次のようになります．

まとめ

これまでの内容をまとめます．

1. エンティティには必ず，作成プロセスと削除プロセスが存在する．
2. プロセスとは「組織体におけるエンティティを使用した活動，およびエンティティを使用して発生する事象」である．
3. 作成プロセス・削除プロセスの有無とセキュリティとは別問題である．

参考文献

奥井規晶，岩宮伸幸 "クライアント/サーバソフトウェア開発" リックテレコム

蛇足

「プロセス」と言う名前がしっくりきません．プロセスだと工程とか手順そのものを表わしているような印象を受けます．「ファンクション」とか「機能」の方がよいかもしれませんが，判断がつきません．