Home >
Google
WWW を検索 このサイト内を検索
 
 
データベース基礎講座の説明とデータベースチェックリスト    
データベース設計って何だ?

設計とは
 そもそもデータベースを設計出来る等と思い上がるとは・・・ ま、物理的な実装面の設計はあるかな
 データベース設計について説明しようと言うからには、先ずデータベースを設計するとは、そもそもどう言う事なのかについて、意識合わせをしておく必要があるだろう。
 データベース設計と言う表現は、何のためらいも無く、一般的に使われているようだが、実はそこにデータベースを、ただのファイルに落としてしまう理由があるように思う。
 そもそも「設計」と言う表現には、設計の目的に対する、創意工夫を盛り込んで行こうとする積極性がある。
 そのため、設計目的に如何に上手く適合したかによって善し悪しが生じる。
 「金は幾らかかっても良いので、思いっきり豪華にしてくれ」と言う場合と「なるべく費用は押さえて実用本位に」と言う場合では、建物にせよ、乗り物にせよ、食べ物にせよ、着るものにせよ、違った設計になると言う訳だ。
 設計者は目的に応じて、豪華さ、使いやすさ、安さなどに、自らの知識と経験を賭けて創意し工夫することになる。
 そのため「設計」と言う概念の中には、創意工夫を重ねて、より良いものを生み出そうとする、積極的な感覚が含まれて来ると言う訳だ。

データベース設計とは

 だから、データベースは分析するもので、設計するものじゃ無いってば・・・
 では、データベースの設計も、設計と付くからには、設計者の知識と経験から、様々な創意工夫を凝らして、良い形を追求するものかと言うと、この辺りから少々話が違ってくる。
 確かにデータベースを実装する場合は、全てのデータをRAID0+1として速度と安全性に最大限の配慮をし、遠隔サイトへの自動バックアップ機能も装備した「豪華」なデータベースや、無償のDBMSを使って既存サーバーに外付けハードディスクを追加して運用する「安い」データベースと言うものがあるかも知れない。
 しかし、ここで議論しているのは、データ項目を何の単位で如何に配置するかと言う概念設計の話である。
 そこでは「豪華」にデータ項目を何重にも重複させたり、テーブルを統合して数を減らし「安く」するなどと言う事はありえない。(⇒後の実装段階での検討は有り得るが、それはパフォーマンス・チューニングの話であり、設計では無い⇒この、設計とチューニングを一連の作業のように表現することも、データベースの設計の本質を曖昧にしてしまう元凶であると考えられる)
 つまり、データベース設計には、相違工夫の余地は無く、誰が設計しても、基本的に同じになるべきものである。
 これは、ビジネスのモデルを描いているので、当然と言えば当然である。
 と言う事で、積極性を持って創意工夫を行う事を示唆する「設計」と言う表現が使い難いと言う訳だ。
 むしろ、本来あるべき形がどんな形であるかを明らかにすると言う意味での「分析」と言う表現が適切であろう。
 そのため、「データ分析」は「データベース設計」と同じ意味になると言う訳だ。
ここで、老婆心ながら「データベース設計とは、相違や工夫の余地は無く、誰が設計しても、同じになる」のは、データベース設計の基本、即ち、データ分析・データモデリングの方法を理解した上で、十分なスキルを持っていればと言う前提がある話なので、誤解のないように。
 「何も知らない担当者を集めても、ER図を描かせると、何故か皆な同じ図になっているんだ」などと言う調子の良いことは起こらない。
 なお、十分なスキルを持ったエンジニアが分析した場合でも、細かい表現までが一度で一致する訳ではない。
 相互にER図などのデータモデルで、自分の認識を示し、他者の認識を確認し、図面を使って、相互にコミュニケーションを繰り返し、調整する中で、相互に納得の行く形に収斂して行くと言う訳だ。
 この段階で、ビジネスを可視化したデータモデルをベースに、十分なコミュニケーションが行われる事には大きな意義がある。
 と言うか、可視化して人目に晒し、多数の有識者から意見を貰って反映する事で、モデルを洗練して行く事に、モデルとして表現する意味があるので、少数の設計者だけでモデルを作り、モデルは読めない有識者に説明したのでは形式的なレビュー会になってしまい、実質的な議論は期待できない。
 データモデルもそれなりに使うためには、関係者を、書けないまでも、読める位はリテラシを高めるなど、それなりの準備が必要になると言う事だ。
 なお、この文脈では、基本的に分析技法や表現方法の違いによる差は、原則的には無いと考えて良い。
 過去の経験からしても、一定以上の分析力を持つ技術者は、流派手法に関わらず、必要なポイントはきちんと押さえているものだ。
 彼らは、流派技法に従属している訳ではなく、ビジネスに対する自分の解釈が先ずあり、たまたま使っている表現手法が今使っている流派技法であると言うことなので、ある概念が先ずしっかり存在しているので、日本語で言おうが英語で言おうが言いたい事の内容は同じになると言う訳だ。
 
 

データベース設計が難しいのは、技術より考え方

 そりゃそうだよな、恣意的なファイル設計と同じ調子でやろうとすれば・・・
  以上、以前から気になっていた事の一つを解説して見たが、世の大勢には逆らえない。
 本講座でも「データベース設計」と言う表現は使うが、その真意はここに説明しているようなものだとの理解で読んで欲しい。
 更に、ことデータベースに関しては、他にも沢山の誤解や無理解があり、そのために重要な情報が無視されたり、不要な情報が付加される場合も多く、不必要にデータベース設計の難易度を上げる結果になっていると感じる。
 本講座は、成果物の外形的な模倣に終始すること無く、データベース設計とは如何なる作業かと言う事について、本質的で正しい概念を持てるよう、技術的な説明と合わせて、ベースとなる考え方や、物の見方についても十分な解説を行う(つもりだ)。
 それでは、本講座が諸君のシステムライフに、より良い変化を起こす事を祈っている。
 あ、より悪い変化が起こっても、当方は何ら責任を負うものでは無い事は、良く分かっていると思うが、あくまでも自己責任でお願いする。

 We must be the Change we wish to see in the world.
 Mohandas Karamchand Gandhi
このサイトについて
 既に、RDBが情報システムの中核に位置付けられてから、設計や開発に携わる人材の世代交代に、十分な時間が経過したにも関わらず、旧弊な設計思想やデータ管理をベースに情報システムを構築しようとするケースが後を絶たない事には驚かされる。
  このサイトは、その様な状況を改善するために、筆者がDOA Evangelistとして活動する中で散見された、拙いデーターベース設計で情報システムを台無しにする事例への予防策として、辛口ノウハウと警告を提供するものだ。
知的所有権について
 著作権法に定められた私的利用の範囲で、このサイトに掲載されているコンテンツを利用することができる。
 さらに、このウェブサイトからの引用である旨のクレジットを明記すれば、勤務先での教育資料や、社内の報告書や企画書への利用も自由に行ってもらって構わない。
 それを超えた利用、たとえば出版など営利目的で利用したい場合にも、利用して構わないが、内容は確認しておきたいので、一応連絡を欲しい。

コンテンツの内容
 本ホームページは、管理者がコンサルタントをする中で得た知識と経験を生かし、趣味で作ったもので、現時点で分かる限りの範囲で、情報の完全性、正確性、適用性、有用性などに留意しているものの、それらを保証するものでは無い。

継続性について
 このサイトでは、いかなる理由であろうと、提供の遅延または中断などの結果、本ホームページを参照した本人または他の第三者が被った損害について、一切の責任は負わない。
      
 データ中心指向技術導入支援のコンサルタント、株式会社FMSへ
 
  データベースの前提であり、情報システム開発の王道でもあるデータ中心アプローチについて、その考え方と技術を解説