ソフトウェアテストシンポジウム 2013
JaSST’13: Japan Symposium on Software Testing 2013

データベースメトリックスの活用－システム内部品質の向上に向けて－蔭山 泰之††日本アイ・ビー・エム株式会社 〒103-8510 東京都中央区日本橋箱崎町 19-21
E-mail:†e01104@jp.ibm.com

あらまし 本稿はアプリケーションのデータベースシステムの内部品質を計測し，評価するための指標を客観的な観点から数値として取得し，それをデータベースの内部品質の維持・向上に役立たせるための方法について論じる．最初にソフトウェアの内部品質について説明し，データベースシステムの品質評価の指標として，主キー項目
比率，テーブルあたり項目数，CRUD マトリックスの密度の三つを選ぶ．次にあるシステムの計測値をもとにこれらの指標で得られた数値からデータベースシステムの内部品質についての推測を立て，最後に，そこからの品質維持・向上策について論じる．
キーワード データベース，内部品質，客観的指標，正規化，CRUD マトリックス

Utilization of Database Metrics－Towards Enhancement of System Internal Qualities－
Yasuyuki KAGEYAMA††IBM Japan Ltd. 19-21, Nihonbashi Hakozaki-cho, Chuo-ku, Tokyo, 103-8510 Japan
E-mail:†e01104@jp.ibm.com

Abstract In this paper I argue about the method of utilizing database metrics as objective indices for evaluating databaseinternal qualities, and for maintaining and enhancing them. I first explain the internal qualities of software systems, and thenselect the ratio of key items, number of items per a table, and the density of CRUD matrix as main metrics for evaluating
database internal qualities. Based on the values obtained from real measurements of a certain system, I conjecture its internal
qualities, and finally argue about the methods for enhancing them.
Keyword Database, Internal Qualities, Objective Indices, Nominalization, CRUD Matrix

1. は じ め に
アプリケーションシステムを構成する既存のアプ
リケーションプログラムに対してリファクタリングが通基盤的な役割を担っており，この意味ではデータベ
ースは個々のプログラムより重要なコンポーネントであると言える．

唱 え ら れ る よ う に な っ て き た 昨 今 で は ，「 シ ス テ ム は

この点からすると，システムの内部品質を語るうえ

動 き さ え す れ ば よ い 」，「 動 い て い る シ ス テ ム に は 触 る

では，プログラムの内部品質だけでは不十分であり，な」という旧来の考え方は成り立たなくなってきていデータベースについてもその内部品質を客観的に評価る．たとえ外からは見えなくても，プログラムの保守

し，維持・改善していく動き，活動が必要である．

性，可読性，拡張性などのシステムの内部品質を重視

本稿では，このような観点から，全体の議論のベーする動きが浸透しつつあり，プログラムの内部品質をスとなるシステムの内部品質についてポイントとなる測る指標が活用され，これを評価する動きも盛んにな

事項を明らかにすることから始めて，データベースのりつつある．

内部品質を測るための指標をどう評価し，そこからなけれども，システムはアプリケーションプログラムにが推測できるか，またデータベースの内部品質の改だけで成り立っているわけではない．日々の業務をこ善のためどのような手を打つことができるかなどにつなすシステムにおいては，業務を処理するアプリケー

いて，実際のアプリケーションシステムのデータベー

ションプログラムの他に，業務の情報を格納してあるスについて調査し，その調査結果を活用した事例をもデータベースも，システムの構成要素として極めて重とに報告し，検討する．

要な位置を占めている．むしろ，多くのプログラムが共通にアクセスする構成要素としてデータベースは共

2. ソ フ ト ウ ェ ア シ ス テ ム の バ ス タ ブ 曲 線
2.1. 故 障 率 の経 時 変 化
時間の経過とともに故障率などのハードウェアとしての工業製品の品質がどのように変化するかは，一般に「バスタブ曲線」で表わされる．
製品を使い始めた頃は，製造過程で紛れ込んだ不具合が顕在化する初期故障が発生する時期（第Ⅰ期）となる（もっとも，最近では製造技術が進んだため，初期 故 障 の 発 生 率 は 低 く な っ て き て い る ）．や が て そ の 時
期を過ぎると，故障が発生しにくくなる比較的安定した時期（第Ⅱ期）に入る．しかしながら，やがて製品

図 2-2． ソ フ ト ウ ェ ア の バ ス タ ブ 曲 線を構成する部品の摩耗，劣化，金属疲労などにより摩耗故障が増えて，また故障の発生頻度が高くなってい
く （ 第 Ⅲ 期 ）．

たとえば，機能改修や機能拡張の際に，適切な設計を行わないで該当箇所にいきなり必要なコードを書きこれらの時期の故障の発生率を曲線として描くと，

こ む よ う な こ と を し て し ま う と ， 図 2-3 に 示 し た よ う

右肩下がりで始まって水平線になり，やがて右肩上がに，メソッドやクラスのサイズや複雑さが徐々に肥大りの曲線になって，全体として故障の発生率のグラフ化していき，その結果としてコードの品質が低下しては 図 2-1 の よ う に バ ス タ ブ に 似 た か た ち に な る ．

いく可能性があるわけである．長年保守されたソース
コードを見ると，日付と担当者名を含んだコメントで挟んであるコード片を見かけることがあるが，そのようなコードを含むメソッド，関数はたいていの場合，かなりの長さ，複雑さに達している．

図 2-1． 故 障 の バ ス タ ブ 曲 線

2.2. ソフトウェアのバスタブ曲 線

図 2-3． 改 修 の 積 み 重 ね に よ る コ ー ド の 肥 大 化

このようなバスタブ曲線は，ふつうハードウェア製品に対してあてはまるものと考えられており，摩耗，劣化しないソフトウェアシステムにはあてはまらないとされている．
しかしながら，どのようなシステムも長い間使い続
けていれば，とくによく使われているシステムほど，

とくに機能的に重要なコードは改修の頻度が高いので，重要な部分ほどコードの品質が低下するという傾向があるが，そのような重要な部分は利用頻度が高い機能なので，その部分の品質低下はシステム全体の品質を左右することにもなりかねない．

その品質はハードウェアと似たようなバスタブ曲線を描 き ，そ の 品 質 は 経 過 時 間 に と も な っ て 劣 化 し て い く ．

3. 外 部 品 質 と 内 部 品 質

ただし，それは部品の摩耗や劣化によってではなく，

3.1. ソフトウェアの内 部 品 質

改修，機能拡張などの積み重ねにともなって内部品質が 劣 化 し て い く と い う こ と で あ る (図 2-2 参 照 )．
どんなによく管理されたソフトウェアでも，長い間使い続けていれば、機能改修や機能拡張にともなって一般に品質について語られる場合，それは使うときに 主 に ユ ー ザ ー か ら 分 か る 品 質 ，つ ま り 機 能 の 豊 富 さ ，
機能の正しさ，機能の使いやすさなどの外部品質に言及されている．

自然にコード量は増加し，保守性は低下していく（たこれに対して，ソフトウェアシステムを作るとき・と え ば ，UNIX の Free BSD の カ ー ネ ル と ユ ー ザ ー プ ロ

直すとき・拡張するときに主に開発者に分かる品質，

グラムについても，このような傾向が見られることが構造のわかりやすさ，機能改修・追加のしやすさ，テ

報 告 さ れ て い る [1]）．

ストのしやすさ，整合性のとりやすさなどの特性は内部 品 質 と い う こ と に な る (図 3-1 参 照 )．

段階で評価してその低下を早期に防止しておく必要がある．そしてこのことは，冒頭でも述べたように，ア
プリケーションプログラムだけでなく，データベース
システムについても当てはまることである．

4. デ ー タ ベ ー ス 評 価 の 指 標 と 方 法
4.1. 品 質 評 価 の指 標
プ ロ グ ラ ム コ ー ド に つ い て は ，早 く か ら LOC，NCSSなどの規模に関する指標があり，さらにコードの複雑さを表わすサイクロマチック数などの指標，さらにはハルステッドのメトリックスなども使われるようになっている．たとえば，サイクロマチック数と欠陥発生
図 3-1． 外 部 品 質 と 内 部 品 質率の間にはある程度の強い相関があることが研究により明らかになっているので，コードの複雑さはプログ

3.2. ソフトウェアの内 部 品 質
外部品質の低下は不具合としてただちに顕在化す

ラムの内部品質を測る重要な指標のひとつであると考え ら れ て い る [3]．

るので、すぐに対策がとられる一方で，内部品質の低

このように，プログラムについては，その内部品質

下は外からは見えにくいので、放置される場合も少なを評価するための客観的な数値で表わされる指標がすくない．だが，内部品質が伴わなければ、実質的にはでにいくつか開発されており，評価の目安となる数値

外部品質の確保も困難である．内的品質の構造に関すも公表されていて，実際のプロジェクトの現場で活かる品質が低下すると，保守性・生産性が低下し，結果されている．一方，データベースについてはどうであとして改修の影響を十分に調べ切れないうちに改修をろうか．

加えたり，影響範囲が不明なままテストを実施したりプログラムコードの内部品質が良くない場合の比するなど，内部品質が低下して信頼性などが低下し，喩として，ファウラーはリファクタリングを行うきっ

最終的にはそれが外的品質の低下として顕在化してくかけとしての「コードの不吉な匂い」に言及している

る か ら で あ る (図 3-2 参 照 )．

[4]．こ れ と ま っ た く 同 じ よ う に ，ア ン ブ ラ ー と サ ダ ラージはデータベースについて以下のような不吉な匂いを 指 摘 し て い る [5]．
1.複 数 の 目 的 に 使 わ れ る カ ラ ム ．
2.複 数 の 目 的 に 使 わ れ る テ ー ブ ル ．
3.冗 長 な デ ー タ ．
4.カ ラ ム の 多 す ぎ る テ ー ブ ル ．
5.行 の 多 す ぎ る テ ー ブ ル ．
6.「 ス マ ー ト 」 カ ラ ム ．
7.変 更 の 恐 怖 ．
コードの不吉な匂いと同じく，ここに挙げたデータ

図 3-2． 品 質 低 下 の 連 鎖

ベースの不吉な匂いも，客観的で定量的な性格のものもあれば，主観的で定性的な性格のものもある．

バスタブ曲線の第Ⅲ期はソフトウェアの陳腐化にソフトウェアシステムも，人間がかかわってくるもよ っ て も た ら さ れ る と い う 見 方 も あ る が [2]，何 十 年 ものである以上，主観的で定性的な評価はおろそかには使われているレガシー系のシステムに見られるように，できない．けれども，いきなり主観的で定性的な評価保守が可能な間は，必ずしも第Ⅲ期が訪れるとは限らから議論を始めると，不毛な結果に陥ってしまう恐れな い ．む し ろ 第 Ⅲ 期 の 招 来 を 不 可 避 に し て し ま う の は ，があるので，内部品質評価の導入部としては，評価・内部品質の劣化であると言える．

意見の不一致が生じにくい客観的で定量的な属性から内部品質の低下にともなう外部品質の低下という事態を避けるためにも，構造に関する内部品質を早い

着目すべきであろう．

ッ ク ス を 生 成 す る ツ ー ル で あ る (図 4-1) [5]．

4.2. 正 規 化 の観 点
ソフトウェアシステムは複雑であるため，複雑さを管 理 す る 定 石 と し て は 分 割 統 治 （ divide and conquer）の考え方が有効であり，ソースファイルや関数・メソッドなどのコンポーネント・モジュールの規模の指標
は，この分割統治の設計がどれだけ適用されているかを測る指標となりうる．
この考え方によって，プログラムの機能は管理可能なレベルにまで分割され，単純化され，それらの組合
せで複雑な機能が実現されることになるので，結果として機能のムダな重複も排除される．
データベース設計においてこの分割統治法に相当するものは正規化であろう．この正規化がどこまで進められているかによって，データモデルがどのような状態かをある程度評価，判断することができる．デー

図 4-1． CRUD マ ト リ ッ ク ス 生 成 ツ ー ル

タベースの正規化の結果はキー項目に関するものなので，数値としては主キー項目の比率などのかたちで現

こ の CRUD マ ト リ ッ ク ス 生 成 ツ ー ル を 利 用 し て ，主

われてくる．また正規化が進めば，エンティティが小キ ー 項 目 比 率 、 従 属 項 目 平 均 数 、 CRUD マ ー ク パ タ ー

さくなっていく傾向があるので，上掲の不吉な匂いのン な ど を 分 析 し た が ，こ こ で は CRUD マ ー ク の 密 度 と4 でも言及されているように，テーブルあたりの項目

い う 概 念 を 導 入 し よ う ． つ ま り ， CRUD マ ト リ ッ ク ス

数も品質の指標として取り上げることができる．

全 体 の な か で C,

R，U，D の マ ー ク が ど れ ほ ど 生 成 されているかという指標である．

4.3. CRUD マトリックスの利 用
主キーの比率やテーブルあたり項目数などは，デー
タモデルを設計したてのシステムとしてまだ稼働してこ う し て ，正 規 化 の 程 度 と CRUD の 密 度 を キ ー と して，データベースの品質を評価してみる．

いない時点，データベースにアクセスするアプリケー
シ ョ ン プ ロ グ ラ ム が ま だ な い 時 点 で も ，数 値 を 取 得 し ，

4.4. 複 数 システムの比 較 による評 価

評価することが可能である．しかしながら，システム

プ ロ グ ラ ム の 規 模 を 表 わ す LOC や NCSS，複 雑 さ をのバスタブ曲線の第Ⅲ期に見られるような時間経過に表わすサイクロマチック数などについては，得られたともなう内部品質の劣化についても評価するためには，値を評価する際の目安として一般的になっている値がこれらとは異なる観点の指標も欲しいところである．

あ る [7]．こ れ に 対 し て ，上 記 で 選 ん だ デ ー タ ベ ー ス のそ こ で そ の た め に ，ツ ー ル で 生 成 し た CRUD マ ト リ

指標については，たとえばテーブルあたりの主キー項

ックスから取得した値を品質評価の指標として利用す目の目安などはあるが，評価の目安はプログラムの指ることを考えてみた．ここで利用したのは，データデ

標ほどには必ずしも充実していないようである．

ィ ク シ ョ ナ リ （ テ ー ブ ル ID、 項 目 ID） と SQL 文 の 情

そこでデータベースの評価に際しては，複数のデー

報 を 元 に 、 DB 項 目 単 位 ， SQL 文 単 位 に CRUD マ ト リ

タベースシステムについて取得した同じ指標の数値を

表 4-1． デ ー タ ベ ー ス メ ト リ ッ ク ス の 比 較 対 照 表互いに比較して評価するというやり方をとることにし連関エンティティには連関を結ぶエンティティの主キ

た．こうして，実績データに照らして極端な値を示し

ー項目が外部キーとして含まれてきたりするので，リている部分の品質について，その値が極端になった原

レーションを表現するための主キー項目が増えてくる．

因を推測していくようにした．

そうすると，相対的に従属項目の比率は下がってくる

このような準備のもと，あるサービス会社の営業系ことになる．

システムのデータベースのメトリックスを取得した．
その結果と，他の企業システムのデータベースの指標を 比 較 対 照 さ せ た の が 表 4-1 で あ る (こ の 表 で 実 質 項 目と は ，テ ー ブ ル 中 の 項 目 の う ち ，更 新 日 時 ，更 新 者 IDなどのシステム管理上の項目を除いたアプリケーショ
図 4-2． 正 規 化 の 進 展

ントランザクションで利用される項目のことを意味して い る )．
SQL に つ い て は ，必 ず し も す べ て の デ ー タ ベ ー ス で実 際 ，こ の シ ス テ ム も そ の 2 の 直 後 か ら 運 用 に 入 り ，値を取得できたわけではなかったが，それでも比較す

その 3 ではすでに実運用に入ってしばらく経った段階

るのに十分なデータは取得できている．

で，テーブル数が増えた一方で，主キー項目比率が

表 4-1 の 中 で ， 今 回 の 評 価 対 象 の デ ー タ ベ ー ス の メ
トリックスは表の一番左の列にある．

27.9%に 減 っ て い る ． 傾 向 の 度 合 い に 違 い は あ る も のの，これと同じ現象は自動車部品メーカーB 設計部品
表システムにおいても見られる．こちらでもテーブル

4.5. 主 キー項 目 の比 率

数が増える一方で，主キー項目比率は減っている．

まず，この表から一見して分かることは，評価対象

これらの部品表システムでは，実運用に入ってからの今回のデータベースは，他と比べるとその規模の大は，業務上の必要に応じて後からいくつかテーブルをきさが際立っているということである．これの右側に追加していくことになったが，その際に，時間も限ら並んでいる他のデータベースの規模と比べると，テーれていたため，他のテーブルとの関連をあまり考慮す

ブ ル 数 ，デ ー タ 項 目 数 ， SQL 本 数 ， ど れ も 数 倍 の 規 模ることができず，必要なアプリケーションとセットでに達している．もっとも，このシステムの過去の履歴

新しいテーブルを設定するというケースが少なくなかを見ると，そのデータベースは，最初に設計した段階

った．つまり，正規化の度合いが低下したということからある程度大規模なものであったが，すでに数年使である．部品表データはもともと組合せが多いので，っていて，その間に徐々に大きくなってきた部分も確

他の業務データと一概に比較することは難しいかもしかにあった．

れないが，今回の評価対象のシステムでも，低い主キ

このような規模を示す今回の評価対象のデータベースについて，これらの値から計算した他の比率などに関する値について見てみると，次に目立つのは，今回の評価対象のデータベースは，他と比べて主キー項

ー項目比率はこれと同じことが起こっているのではな
いかと推測できる．
この推測は，次に述べる指標によっても裏書されるだろう．

目の比率が異様に低いという点である．
たとえば，そのすぐ右隣にある自動車メーカーA 設

4.6. テーブルあたり項 目 数

計 部 品 表 シ ス テ ム そ の １ の 46%を 超 え る 比 率 は 高 す ぎ

今回の評価対象のデータベースについてさらに言るにしても，表の右端の情報通信会社料金管理システ

えるのは，一テーブルあたりの項目数が多いというこ

ム の 一 番 低 い 比 率 16%と 比 べ て も ，今 回 の シ ス テ ム のとである．これは，先に挙げたデータベースの不吉な7.7%は お よ そ そ の 半 分 で あ る ．

匂いの 5 にあたるが，ここから，テーブルの凝集度が自動車メーカーA 設計部品表システムその 2 の場合，低いということがうかがえる．そして，テーブルの凝

主キー項目比率がおよそ半分に達するほど高いが，こ集度が低いと，以下のような問題が潜在化している可

れはデータモデルを最初に設計した時に，かなり徹底能性がある．

して正規化を進めたために，ひとつひとつのエンティ
ティのサイズが小さくなり，その代わりにエンティテ

・項目の重複，繰り返しが存在する

ィ同士の間にリレーションが増えてきた結果であるこ・主キーに従属しない項目があると が 分 か っ て い る （ 図 4-2 参 照 ）．

・推移従属がある

リレーションが増えると，親エンティティの主キー項目が外部キーとして子エンティティに降りてきたり，

正規化を進めれば，主キー項目によって決まる項目

だけが従属項目として残るので，ひとつひとつのエン

クスは，たとえば各プログラムがアクセスしている順

ティティは小さくなって，そこに本当に必要な項目だに テ ー ブ ル を 並 べ る と ， 極 端 に 表 現 す れ ば 図 4-3 の よ

け が 残 る ．結 果 と し て エ ン テ ィ テ ィ の 凝 集 度 が 高 ま る ．

う に な る だ ろ う ．こ の CRUD で は CRUD マ ー ク は 対 角

そして相対的に従属項目の比率は下がってくる．

線上にしか現れないので，マークの発生率は減ってし

このように見ると，従属項目が多いエンティティは，まい，疎なマトリックスになってしまっている．

そこに本来は必要のない項目が多く含まれている可能

これは，プログラムコードで言えば，機能改修が必性がある．そして，必要のない項目は，複数のエンテ

要 に な っ た 際 に ， 図 2-3 に 示 し た よ う に ， 他 に 似 た よィ テ ィ に 重 複 し て 存 在 し て い る 可 能 性 が あ る ．こ れ は ，うな機能がすでに既存のプログラム中に存在するかど

データ不整合の温床ということもできる．つまり，主うかを調べもせずに，必要な機能を必要な個所にだけ

キー項目の比率が低くて，従属項目が多いようなデー直接実装してしまい，結果として同じような機能を実

タベース，そのような値を示しているものは，高いサ

現するコードがプログラム中に分散して存在してしま

イクロマチック数を示しているプログラムと同じく，

う事態に相当するだろう．

問題ありと言えそうである．

実 際 に ，デ ー タ ベ ー ス の 規 模（ テ ー ブ ル 数 ，項 目 数 ）が大きくなればなるほど，それだけ調査範囲が広くな

4.7. CRUD マトリックスの密 度
最 後 に ， 経 過 時 間 に と も な う 指 標 と し て ， CRUD マ
トリックス上のマーク発生率を見てみる．これは，全るので，調査し切れずにこのように新規アプリケーシ
ョンごとのテーブルが新設されてしまう可能性が高くなってくる．

項 目 数 ×SQL 本 数 の マ ト リ ッ ク ス 上 の 全 セ ル 数 に 対 しこれに対して，新しい機能を追加する際に既存のテて ， C， R， U， D の マ ー ク が ど れ だ け 発 生 し て い る かー ブ ル ， DB 項 目 を 綿 密 に 調 査 し て ， 既 存 の 項 目 を 使の比率である．

うようにすれば，複数のアプリケーションから共通に

今 回 の 評 価 対 象 の デ ー タ ベ ー ス は 表 4-1 の 中 で 行 列

ア ク セ ス さ れ る テ ー ブ ル ， DB 項 目 が 多 い と ， 各 テ ー

ともに最大の規模であるにもかかわらず，意外なこと

ブ ル ， DB 項 目 行 あ た り の CRUD マ ー ク は 増 え る よ うに，マークの発生率が最も低い．つまり，評価対象のに な り ，結 果 と し て CRUD マ ト リ ッ ク ス と し て は 図 4-4

デ ー タ ベ ー ス は 他 と 比 べ て CRUD マ ト リ ッ ク ス で の マのように密になるだろう．

ークがまばら，疎であるということである．
ここからは，ある特定の目的のために設定されていて ，複 数 の ア プ リ で 共 有 さ れ て い な い テ ー ブ ル が 多 く ，
同じ意味の項目が複数のテーブルに散らばっているのではないかということが推測できる．
たとえば，システムの機能を拡張するにあたって，
参照，格納しなければならないようなデータ項目が既存のテーブルのどこに存在するかをあまりよく調査せずに，新しいアプリケーションプログラム専用のテーブルを新しく設けて，そこにアクセスするようにして

図 4-4． 密 な CRUD マ ト リ ッ ク ス

しまうと，そのデータベースはアプリケーションプロ
グラムごとの固有のテーブルの寄せ集めのようになっ

CRUD マ ト リ ッ ク ス が 疎 に な っ て し ま っ た こ と の 原て し ま う ．こ の よ う な デ ー タ ベ ー ス の CRUD マ ト リ ッ因として以上の推測が当てはまるとすると，そのようなデータベースはたとえば同じ意味のデータ項目が複数個所に散らばってしまっている可能性がある．このような状態はやはり，先の低い主キー項目比率や，項目数の多いテーブルなどと同じく，データ不整合の温床となりうる．プログラムコードで言えば，コピーペーストが積み重ねられていった結果，コードクローン
が多数存在するような状態とほぼ同じようなケースであると言うこともできるだろう．

図 4-3． 疎 な CRUD マ ト リ ッ ク ス

5. 内 部 品 質 向 上 へ 向 け て の 対 応 策
以上のような指標によって，プログラムコードと同
じく，データベースについてもその内部品質を客観的

難易度

5.1. データベース内 部 品 質 改 善 の難 しさい部分であるということもできる．

な 数 値 で 計 測 し ，評 価 し ，そ の 結 果 を 手 が か り と し て ，
データベースの内部品質を維持・向上させていくことができるだろう．そして継続的にそうした値を計測，

高

①

②

低

③

④

小

大
効果

評価することにより内部品質の推移を知ることも可能
である．
しかしながら，データモデルを設計しなおして品質

図 5-1． 品 質 改 善 作 業 の ポ ー ト フ ォ リ オ

を向上させる場合には，個々のプログラムのリファク
タリング以上に影響範囲が広く，なかなか難しい面がある．

これを逆に考えてみると，改善効果の高い部分は，これを放置した場合に危険度の高い部分でもあるとも

データベースはふつう複数のアプリケーションプ

言える．したがって，効果が大で難易度の低い④の部

ログラムからアクセスされていて，それらとの結合度分から始めるのがよいだろう．順番としては，④からが高い．このため，すでにシステムとして稼働してし始めて③に至り，最終的には②を目指す形になる．

まっているデータベースで，メトリックスの値がよく

なお①の部分については，改善に使える工数との兼ない部分を改善するためには，データベーステーブル

ね合いによって，場合によっては当面は放置しておなだけでなく，それにアクセスするアプリケーションプ

ざるをえないかもしれない．

ログラムも改善する必要があるからである．
けれども， 先に述べたように，システムの内部品

5.3. CRUD による未 使 用 テーブルの除 去

質は放置しておけば時間とともに劣化していく．とく以上のポートフォリオを使って，改善に取り組む順にメトリックス値のよくない部分のデータベースにア番 が 決 ま っ た ら ，ま ず て っ と り 早 く で き る 対 策 と し て ，

クセスしなければならないアプリケーションプログラ

メ ト リ ッ ク ス 値 を 取 得 す る の に 利 用 し た CRUD マ ト リ

ムは，たとえそのプログラム自体をリファクタリング

ッ ク ス を 使 っ て ，ど の SQL か ら も ア ク セ ス さ れ て い な

して改善できたとしても，アクセス先のデータベース

い項目・テーブルを除去することができる．

がそのままであれば，いつまでもデータ不整合の問題システムを長い間使っていると，データベースも未などに悩まされ続けてしまう恐れがある．この意味で使用項目，未使用テーブルが発生してしまう可能性がは，やはりデータベースの内部品質も放置すべきでは

あ る ．こ れ ら は プ ロ グ ラ ム 中 の 未 使 用 コ ー ド と 同 じ く ，なく，なんらかの対策を講じるべきである．

可読性を落としている．物理的に定義されているが，現状ではアプリケーションから使われていないテーブ

5.2. 内 部 品 質 改 善 のためのポートフォリオ

ルの有無をチェックし，あれば，それの必要性を検討

このようにデータベースの内部品質については，改して，不必要であれば削除する．これらが本当にどこ

善の難しさと改善の必要性の両方がつきまとう．そこからも使われていないということが確認できれば，除で，実際の内部品質改善作業にあたっては状況を整理

去してしまう．こうすることによって，テーブルの凝して具体的に対応していくべきだろう．

集度が高まる可能性がある．

表 4-1 は デ ー タ ベ ー ス 全 体 と し て の メ ト リ ッ ク ス でこうすることにより，不要なテーブル数が減ることあったが，計測対象をある程度，テーブルごと，あるで，システムの改修，機能拡張にともなう調査範囲がいはテーブル群ごとに分類して値を取得し，得られた減り，影響範囲調査などの人的工数が低減する．さら結果を改善の難易度と改善の効果を二軸にして，改善には，固定長項目を多数含むテーブルの場合など，う対 象 を 四 分 類 に し た 図 5-1 に 示 し た よ う な ポ ー ト フ ォ

まく行けば，たとえばディスクの容量に余裕ができる

リオに配置して，改善作業に取り組むのが効率的だろ

可能性もある．

う．
このポートフォリオにおいて，改善の効果がある部

5.4. CRUD によるテーブル項 目 の整 理

分とは，内部品質のメトリックス値がよくない部分でさ ら に 同 じ 意 味 の 項 目 が 散 ら ば っ て い て ， CRUD マ

ある．値がよくなくても，あまり使われていない部分

トリックスが疎になっている場合は，同じ意味の項目

であれば，大した問題ではないが，問題が解決されてをまとめる必要があるが，これについても作業工数を効果が出るということであれば，やはり利用頻度の高

削 減 す る た め に は ， ア ク セ ス し て い る SQL を CRUD

で確認して，基本的にはアクセスの多い方に少ない方する必要がなくなるので，改修・テスト工数を削減すを寄せるというかたちにすべきだろう．そのための前

る こ と が で き る ．さ ら に ，同 じ CRUD マ ー ク の 複 数 の段階の作業として，物理的に定義されているが，現状

SQL の 実 行 計 画 が 別 々 に な っ て し ま っ て い る 場 合 に は ，

で は ア プ リ ケ ー シ ョ ン か ら 使 わ れ て い な い DB 項 目 のこれらをひとつにすることによって，プロシージャキ

有 無 を チ ェ ッ ク し ，あ れ ば ，そ れ の 必 要 性 を 検 討 し て ，ャッシュの容量を増やすことができる．

不必要であれば削除する．

6. お わ り に5.5. CRUD による SQL の共 通 化
CRUD マ ト リ ッ ク ス 上 の マ ー ク に は デ ー タ ベ ー ス のデータ項目についての情報という意味だけではなく，

このようにできるところから少しずつ手を付けていくことにより，データベースの内部品質も改善させていくことができるだろう．

そ こ に ア ク セ ス し て い る SQL 文 に つ い て の 情 報 と い

放置しておけば時間とともに劣化していく内部品

う 意 味 も あ る ． そ こ で ， CRUD マ ー ク を 調 査 し て ， 図

質について対策を施すことで，外部品質の低下を防ぐ

5-2 が 示 し て い る よ う に ， 同 じ CRUD マ ー ク を 示 し てことにつながる．内部品質維持・向上のためにかける

い る SQL が あ れ ば ， そ れ ら の SQL は 同 じ 内 容 で あ る

工数は，中長期的には外部品質維持の工数削減，あると推測することができる．とすると，こうした調査のいは機能拡張の生産性向上というかたちで効果が現わ

結 果 ， 重 複 し た SQL を 除 去 で き る 可 能 性 が あ る ．

れてくる．
このことは，逆に言うとシステムの内部品質改善作
業には即効性はあまりないということである．このため，どうしても対策が遅れがちになり，問題が顕在化してくるころにはもう手遅れに近い状態になってしまっているかもしれない．
このような事態を避けるためには，やはり内部品質を示すシステムの指標を常日頃から取得し，評価するようにして，品質低下の兆候をできるだけ早いうちに捉えるということしかないだろう．

文[1]
図 5-2． 同 じ CRUD マ ー ク パ タ ー ン を 示 す SQL[2]

た と え CRUD マ ー ク が ま っ た く 同 じ で は な く て も ，[3]

述 部（ WHERE 句 以 降 ）が 同 じ CRUD マ ー ク の SQL を
調 査 し ，同 じ 内 容 の SQL で あ れ ば 重 複 を 除 去 す る（ 図5-3 参 照 ）．取 得 項 目 に 差 異 が あ っ て も ，検 索 条 件 が 同じであれば，ひとつにできる可能性がある．

[4]

[5]

[6]

[7]
図 5-3． 述 部 が 同 じ パ タ ー ン の SQL
こ れ に よ り SQL の 共 通 利 用 が 可 能 に な り ，SQL の 全
体本数が低減する．結果として，機能改修にともなう調査範囲を絞ることができて，調査工数を削減すること が で き る ．ま た ，SQL に 対 し て 改 修 ・ 改 善 を 施 さ な
け れ ば な ら な く な っ た 場 合 に ，同 じ 複 数 の SQL を 改 修

献Diomidis Spinellis，『 Code Quality， コ ー ド リ ー
デ ィ ン グ に よ る 非 機 能 特 性 の 識 別 技 法 』， 毎 日 コ
ミ ュ ニ ケ ー シ ョ ン ズ ， 東 京 ， 2007.
菅 野 文 友 ，『 ソ フ ト ウ ェ ア の 品 質 管 理 』，日 科 技
連 ， 東 京 ， 1986．
ス テ フ ァ ン H. カ ン , 『 ソ フ ト ウ ェ ア 品 質 工 学の 尺 度 と モ デ ル 』， 共 立 出 版 ， 東 京 , 2004.
マ ー チ ン ・ フ ァ ウ ラ ー ，『 リ フ ァ ク タ リ ン グ ，
プ ロ グ ラ ミ ン グ の 体 質 改 善 テ ク ニ ッ ク 』， ピ ア ソ
ン ・ エ デ ュ ケ ー シ ョ ン ， 東 京 , 2000.
ス コ ッ ト W. ア ン ブ ラ ー ，ピ ラ モ ド・サ ダ ラ ー
ジ ，『 デ ー タ ベ ー ス ・ リ フ ァ ク タ リ ン グ 』，ピ ア ソ
ン ・ エ デ ュ ケ ー シ ョ ン ， 東 京 , 2008.
蔭 山 泰 之 ，「 CRUD マ ト リ ッ ク ス の 自 動 生 成 によ る 品 質 管 理 」， ソ フ ト ウ ェ ア テ ス ト シ ン ポ ジ ウ
ム 2006 予 稿 集 ， 100-106 ペ ー ジ ．
リ ン ダ ・ M・ ラ イ ル ド ， M・ キ ャ ロ ル ・ ブ レ ナ
ン ，『 演 習 で 学 ぶ ソ フ ト ウ ェ ア メ ト リ ク ス の 基礎 』， 日 経 BP 出 版 セ ン タ ー ， 東 京 , 2009.