データベース設計基礎講座の目的

　データベースを「複数の目的で共用する、冗長性の無い、相互に関連付いたデータの集まり」として作り込む事が出来るか出来ないかで、データベースを中心とする情報システムの全てが決まる。
　全てとは、先ずは生産性と品質、生産性と品質が下がれば、コストも増加し納期も守れなくなる。
　「複数の目的で共用する、冗長性の無い、相互に関連付いたデータの集まり」とは、データベースの定義だ。
　定義通りに作ったデータベースには冗長性が無いので、データ間の整合性を調整する機能が要らず、システム規模を最小のまま維持する事が出来る。
　システム規模を最小のまま維持出来るので、肥大化・複雑化で失われたデーターの整合性を回復するための、いわゆるシステム再構築を頻繁に繰り返す【注１】必要が無くなるので、システム寿命が長くなる。
　システム寿命が長くなり、半永久的になるので、安心して機能の追加変更が出来る。
　規模の最小化により、資源から管理組織までが縮小し、システム寿命が長くなるので、サイクリックな再構築費用も不要となり、大幅なシステムコストの削減が実現する。
　実は、これは、情報システムが到達する最終形であり、これを実現するための考え方、データ管理のフレームワークがデータ中心アプローチと呼ばれる考え方だ。
　データ中心アプローチを実践し、データの一元管理を実現することが、最も効率の良い情報システムとなるが、その成否も、結局のところ、データベースの設計品質に掛っていると言う訳だ。

　と言う事で「データベース設計基礎講座」は、情報システムの最終形を目指すデータ中心アプローチへの突破口として、データベース設計スキルの概要と必要性を理解して頂く事を目的にしている。

【注１】：システム再構築を頻繁に繰り返す
　我が社は、システム再構築を長い間やっていないので、「システム再構築を頻繁に繰り返す」には該当しないなと安心したあなた。
　安心するには及びません。（こんな言い方あるのかな、普通は心配するには及びませんだが？）
　この肥大化・複雑化するサイクル、いわゆるシステムディベロップメントライフサイクル⇒ＳＤＬＣと言う奴ですが、これが分かっていない経営者は多い。
　ＣＥＯも情報システム部長も、システム部門の管理者も多い。
　そのため、経営が左前に成って来ると、真っ先にシステム関係の予算をカットする。
　ま、金額が目立つし、多分それより大きい人件費ほ方を減らすのは難しいので、勢いシステム費用に御鉢が回って来ると言う事なのだが、要するに、必要性からでは無く、単に金が無いから再構築を行っていないだけのケースが多いので、その場合は保守性が維持出来ているので再構築を行う必要が無い状態とは別で、システム規模が最小のまま維持出来ている訳では無いので、同じ再構築無しでも、我が社がどちらのケースかは見れば分かるはずなので、確認しておく必要があるだろう。

データベース設計基礎講座のスキル修得

　残念ながら、当サイトや「お役立ち情報」で紹介しているサイトを隈なく見たとしても、実際のデータベース設計に必要なスキルの充足度はせいぜい50％と言う所だろう。
　但し、50％と言えども、何らの知識も無くファイル設計の要領で、データベース設計を行おうなどと言う無謀な作業に比べれば、数段まともには違いないし、それなりの効果も出るので「何だ50％か」と放り出したりしないようにして欲しい。
　世の中には、関連が全く表現されていないＥＲ図（関連が表現されていないのではE図というべきか）を描いて、データモデルを描いてデータベース設計をした積りになっている者もいるので、それに比べれば数段ましだ。
　エンティティの捕捉や関連の設定までは、特に問題は無いだろう。
　問題は、分類構造・繰り返し構造・再帰構造・関連エンティエィなど、ビジネス上の詳細なビジネスルールを表現する部分である。
　これをマスターするには、ある程度場数を踏んでもらうしか無いので、基本ルールを身につけたら、なるべく多くの分析経験を積んでもらいたい。

データベース設計基礎講座の後で

　本講座で、データベース設計の基礎を学習したら、分析の場数を踏んで経験を積み腕を磨いて貰いたいが、腕を磨いて何をするのかと言うと、全社データモデルの作成だ。
　折角のデータ中心アプローチも個別のシステム毎にバラバラに適用していたのでは、本来の効果は生まれない。
　それどころか、本来、一式で成立しているビジネスを、商品別とか、事業部別とか、機能別など都合よく分けて置いて、それぞれに独立したデータベースを作ったのでは、何の事は無いビジネスのスコープ全体で見れば、データの重複を作り込んでいるだけだ。
　企業・団体のスコープ全体に亘る、最終的な一元化を目指す必要があるが、急に全社一元化だと言って、データベースを物理的に一元化する作業に着手出来るものでも無いので、先ずは全社データモデルを作って、ビジネススコープの全体を把握し、効率的なデータ管理を実現するためには、如何なる方針で臨むかと言う「データ管理ポリシー」を検討すると言う訳だ。
データ管理ポリシーが出来たら、後は、個別の開発プロジェクトをデータ管理ポリシーに沿って運用し、データ管理ポリシーが目指すゴールを目指すと言う訳だ。

　データ管理ポリシーと言うと何か難しいものをイメージするかも知れないが、中核になるのは、どうしたい、どうしなければならないと言う方針レベルのものなので、難しく考える必要はない。
　例えば「運用の独立性を維持するために、サブシステム毎のデータベース設定は継続するが、スコープ内でデータ管理分化の一元化をするために、名称とデータ構造は統一し、エンティティ毎に主幹するサブシステムを決定して、データの連携をコントロールする」程度で、最初の出だしは良い。
　もっとも、それを実現するためには、必要に応じて色々と決めたり作ったりする事になり、方針に立ち返って矛盾を整理しなければならない場合も出てくるが、最初の出だしはこの程度で問題無い。

勘違い

　データベースの設計をしたつもりになって、従来からのファイルワークのデータレーアウトをデータベースマネージメントシステムに実装し、データベースを作ったつもりに成っているケースがある。
　一寸専門家に見せれば適切な指導があっただろうにと、データ移行やテスト環境でのデータ作成でデータの整合性が追えずに混乱している姿を見るにつけ情けない思いをするが、どうやら、手近に専門家が居る環境の方が少ないようだ。
　これらは全て不勉強による自業自得だと言ってしまえばそれまでだが、プロジェクトの中でファイル設計とデータベース設計の本質的な違いを理解している者が居なければ、自分たちが不勉強である事にすら気付けないのが、日々の作業に追われて忙しいだけのシステム部門の実情だ。
　前回、技術教育コースに参加したのは何時だっただろう。
　特にシステム業界は３文字略語が飛び交い、一体何が本質的なトレンドなのかを見極める事は容易ではない。
　用語解説レベルの一寸した蘊蓄を披露すれば、博識で通用する環境で誰が本気でスキルを磨こうと思うだろうか。
　言われて見れば、「ベンダーが納品したデータモデルも、大丈夫だからと言われて検収印だけ押して、そのまま保管庫に入れたままだが」と、気になりだした諸君には朗報だ。
　株式会社ＦＭＳのデータ分析専門家がデータモデルのレビュー、評価、作成指導などを代行してくれる。
　既に、リリースされたデータベースの評価も可能なので、今後の再構築に向けて検討を始めたプロジェクトの相談にも乗ることも可能だ。
　えー、俺たちには関係ないねっと思ったあなた、本当に関係無いかどうかは、下記のチェックリストで確認してから言ってもらおう。
　チェックは簡単、該当しないする項目にチェックを付けて数えて欲しい。
　まあ、三つもチェックが付くようなら、十分失格の資格はあるので、勉強し直す事を勧めるが、五つもチェックが付くようなら、自分達で立ち直るのは無理だから、すぐに私に連絡した方が良いだろう。

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