データベース設計チェックリスト

　1.データベース設計チェックリストの使い方

今時ビジネスシステムの開発で、データベースを使わないプロジェクトは無いと思いますが、データベースを使っていながら、まともにデータベース設計が出来ていないプロジェクトも多いと言う嘆かわしい状況が分かって来ました。
　ついては、データベース設計者の皆さんには、データベース設計の猛勉強をして頂く必要が有るわけですが、大体、人間と言うものは、自分だけは他とは違っていると自惚れているものです。
　確かに、世の中に、頭の良い人は居るので、皆さんの中にすでに十分なるスキルを持った方が居る可能性は十分あるので、このチェックリストで自分がどちらか判断して頂こうと言う趣向です。
　自分が作ったデータ構造（データベース設計でもデータ分析でも好きに呼べば良いのですが、それらの成果物としてのＥＲ図など）をチェックして下さい。

自分で作成したものが無ければ、現行システムのデータモデルなど、身近にあるデータモデルをチェックして見てはどうでしょう。
　もちろん、ここで確認するのは概念構造（論理設計と表現している場合も多いが、要するにビジネスをモデル化した部分）なので、物理的設計やデータベース定義情報しかない場合は、物理設計時の追加項目は考慮してチェックして下さい。
　ここの確認事項の設問で○が大半と言う方がいれば、ＤＡ（Data administrator⇒データ管理者）と名乗るに相応しい実力の持ち主であると言えます。
　なお、システム開発プロジェクトが作るビジネスシステムとは何かについては、コラムで詳しく述べているので、興味のある方はそちらを参照して下さい。⇒

　2.データベース設計チェックリスト

　チェックしようとするデータ構造が、以下の設問に対し是とする場合は○を、非とする場合は×を、該当しない場合は-とします。
　×が１０以上も有る場合、事態は至って深刻なので、直ちに作業を中止し、コンサルタントの判断を仰ぐ必要があるでしょう。
　また、既に稼働中の場合は、直ちににスキルアップに励み、再構築の機会に備えるべきでしょう。

○ 前提
１	□ 作図の基準は文書になって周知されている。⇒データモデル作成基準など
２	□ 構成要素の命名基準が作られ周知されている。⇒データ命名基準など
３	□ データモデルの変更管理を行う手順や仕組みがある。
○ データモデルの外形など
４	□ スコープ全体のデータモデルがある。
○ エンティティ
５	□ エンティティ名称はビジネス中の存在や行為・出来事自体の名前である
６	□ 同じ名前は存在しない
７	□ エンティティの識別子が設定されている
８	□ エンティティ内に集団項目や繰り返し項目はない
○　リレーションシップ
９	□ 関連の無いエンティティはない
１０	□ 関連によって関連キーが設定されている（どの関連キーがどの関連を辿って挿入されたか分かる）
○　多重度（カーディナリティ・オプショナリティ）
１１	□ 全ての関連にはカーディナリティが設定されている
１２	□ Ｎ：Ｎの関係は関連エンティティによって整理されている
○　属性（アトリビュート・データ項目）
１３	□ 属性データ項目に重複は存在しない
１４	□ 属性に初期値を設定するものはない
１５	□ 属性にＮｕｌｌを設定するものはない
１６	□ 集計計算で導出する属性データはない
１7	□ 属性の名称に「前月～」など、相対的な時間を表す修飾子を持つデータはない

　3.チェック結果の検証

　細かい事を言うと切りがありませんが、技法や表現方法での流儀の違いもあるので、チェック項目は重要な項目だけを厳選しています。
　従って、これが１項目でも出来ていないと言う事は、それだけで既にデータベース設計としての品質は、かなり怪しいと言わざるを得ませんが、まあ、大目に見ても５項目までと言う所でしょうか。
　６つ以上×の場合、データベース設計について、何も分かっていないと自覚すべきでしょう。
　そのまま、データベース設計を続けるなどとんでもないので、直ちに、データベース設計の勉強を始めて下さい。

　４.失敗の本質

データベース設計に失敗する理由は明白です。
　外形的には、従来のファイル設計と似ているので、従来のファイル設計の考え方のままで、データベースの設計も出来ると思い込んでしまう事です。
　もちろん、従来のファイル設計が特定の機能、特定のユーザインターフェースを前提に、必要なデータ項目を集めるのに対し、データベースは全体構造の最適化、全体の整合性を整理する所から始まるので、従来のファイル設計のスキルは全く通用しません。
　但し、データベース設計自体は、体系的に学びさえすれば、大して難しいスキルでもありません。
　ファイル設計とは別物なのだと理解出来れば、修得は早いのですが、概念と実装、設計とチューニングなどを、まとめて教えようとして、結局、データベース設計の本質が伝わらないまま、小手先のテクニックに終始しているコースも多いようです。
　設計と利用上の創意工夫は、根本的にレベルが違う話なので混同してはいけません。
　もちろん、株式会社エフ・エム・エスでは、データベース設計スキルを修得出来る研修を用意しています。⇒「ERD基礎」
　また、データベース設計の技法修得に特化した「データベース設計基礎」を新設しました。
出来れば、データベース設計に着手する前に余裕を持って受講して下さい。
　なお、このチェックリストの意味が分からないと言う場合は、株式会社エフ・エム・エスが無償で定期開催している「ＤＯＡ紹介」セミナーの受講をお勧めします。
　孫子も形編第二節で「勝ちを見ること、衆人の知る所に過ぎざるは、善の善なる者に非ざるなり」と言っています。
　岩波文庫の孫子（金谷治訳注）では「勝利を読み取るのに一般の人々にも分かる〔ようなはっきりしたものについて知る〕ていどでは、最高にすぐれたものではない」と注釈しています。
　システム開発プロジェクトでは、勝ち（プロジェクトの成功）を見るのなら、衆人の知る所に過ぎなくても何の問題もありませんが、負け（プロジェクトの失敗）に関しては、他の誰よりも早く、その予兆を察知して、予兆のままに解決する必要があります。
　もちろん筆者は善の善なる者なので、データベース設計の内容を一目見れば、勝ち負けを見る事が出来ます。
　さすがに成功は、他にもうまく解決しなければならない要素が多いので、データベース設計が満点であったとしても最終的な成功を保証するものにはなりません。
　しかし、失敗についてははっきりと見る事が可能です。
　例え、最終的にそのプロジェクトが全ての機能を実装し、運用に漕ぎつけたとしても、整合性のとれたデータの一元管理が実現出来ていなければ、データベースシステムとしては明らかな失敗です。
　そのシステムが使われる間、保守性の低さに高いコストを支払わされる事になってしまいます。
　このチェックリストは、その判断のポイントを簡単なまとめたものなので、大いに活用し、真のプロジェクト成功の切っ掛けにして頂ければ幸いです。