前のページに戻りますホームへサイトマップへ
           
   
 
 



データベース設計基礎>データベースの基礎知識  
 
     
   ホーム >お役立ち情報>データベース設計基礎>データベースの基礎知識  
       

 データベースの基礎知識

データベースを設計しようと言うからには、データベースとは一体何なのかを分かっていないと話になりません。
 分からないままに、見よう見まねで外形の模倣をするので、恣意的なファイル設計をER図に描いたものをデータベース設計などと主張する馬鹿げたことが起こっているのだと思います。
 ここでは、データベースについての理解を助ける断片を集めて見ました。
 先ずは、このページをお読み頂ければ、データベース設計の段取りや技法の理解を容易にしてくれると思います。
データベースとは何か
 データベースは「複数の目的で共用する、相互に関連付いた、冗長性の無いデータの集まり」と定義されています。
 ビジネスシステムでは、ビジネスの中で生まれるデータを全て一元的に記録するものがデータベースです。
 全てのデータを一元的に記録しているので、当然、中間ファイルやローカルマスターなど、他にデータを記録する必要はありません。
 また、新しくデータ項目が増える場合には、データベースの中に関連付けて持つ必要がありますが、従来は、調査・調整能力の不足から多用される事が多かった、付加ファイルによる追加データの保持も出来ません。(⇒もちろんやれば出来るがデータベースを使う目的が果たせなくなるのでやってはいけない。 また、実際問題として、正確にビジネスをモデル化したデータ構造が整理されていれば、新規のデータ項目追加で悩む必要はありません。)
 よって、データベースとは、スコープ内のデータを一元管理し共用する仕組みと考えて頂ければ良いでしょう。
 なお、DBMSで実装したデータを指してデータベースと呼ぶことがあるが、DBMSで実装することと、前述の定義を満たすことは関係無いので、DBMSで実装されたデータ群を無条件でデータベースと呼ぶのは不適切です。 
 更に言うと、データベースは情報が電子化されている必要すらありません。
 名刺を集め、会社別に分類(相互に関連付けて)して、名寄せして一覧表を作り(冗長性のない)整理するだけで、要件を満たしており、自らの営業活動と言うビジネススコープでの立派なデータベースであると言えます。
なぜデータベースを使うのか
  データベースと言う概念が考えられる以前は、データは全てシステムやアプリケーションに従属していました。
 システムやアプリケーションは「取引先を指定して、該当する取引先別の受注残高を表示する」など、それぞれに固有の目的があり、目的を満たすためには、どのデータ項目を画面に表示しなければならないかと言う仕様が特定出来るので、それぞれに都合の良いデータの持ち方と言うものがあります。
 先の例で言うと、月別取引先別に売り上げ金額を集計したデータを取引先別にまとめて持ち、ついでに取引先毎の名称や住所、連絡先などのデータも持っておくと都合が良いと言うことになります。
 そのために、サブシステム毎や機能毎、アプリケーション毎など、より小さな単位で専用のデータを持とうとする力が働くことになります。
 これを放置すると、多くの中間ファイルやローカルマスタを生むことになってしまいます。
 しかし、実際は都合が良いのは直接ユーザインターフェースを実現する機能部分だけで、データの入力・複写・編集・変換・管理など不必要に増加した冗長機能が生む、無駄と不整合がシステム寿命の低下を招き、システム全体としての収支で考えると、とても容認できるものではない事は明らかです。
 幸い、元よりデータは幾ら使っても減る事も無ければ内容が劣化する事も無いので、一つあれば良いと言う事に関しては議論の余地は無いでしょう。
 そこで、ビジネスシステムの冗長性を排除するために、個別にデータを持つ事を禁止し、スコープ全体でデータを一元管理し共用しようと言う概念が「データベース」として生まれたので、データベースと言いながらも、冗長性を抱えていたのでは、データベースを使っているとは言えないと言うことです。
ファイル設計とデータベース設計
ファイル設計とは、特定のプログラムで実現しようとする機能で使うデータ群の持ち方を決める事です。
 そのため、評価の指標が、如何にプログラムの機能実現に有用であるか、つまり、どれだけプログラムが作り易くなるかと言うことになります。
 例えば、受注マスターに取引先番号に加えて「取引先名称」や「取引先住所」・「取引先電話番号」なども持っていれば、方々のマスターを読む手間が無くなるので、プログラムを作る負荷が軽減する良いファイル設計と言うことになります。
 簡単に言うと、必要なデータをなるべくまとめて持とうと言う方向に向かうことになります。
 そうは言っても、アプリケーション毎に個別のファイルを持つとデータを変更する場合などに、大きな負荷が掛ることは明らかなので、利用頻度の高いデータについては、マスターと言う形で共用化を図る事になります。
 しかし、データのまとめ方・一元管理などの管理方針・マスターに存在するデータは必ずマスターから直接アクセスして使うなどのデータの使い方・などのようなポリシーがはっきりしていない事が多く、マスターが多くの選択肢の一つに成り下がる事になっています。
 もちろんマスターを複写してサブシステム専用のサブマスターを作る事にもお構いなしです。
 お構いなしどころか、その様な状況を管理牽制する組織が存在することも少ないのが現実でしょう。

 これに対して、データベース設計は、データベースにスコープ全体のデータを如何に持つかを決めますが、個別具体的な目的は無いので、ファイル設計のやり方は使えません。
 そこでデータベース設計が拠り所としたのは、データは全てビジネスによって作られると言う事実です。
  ビジネスの中での新たに認識したものや新たに発生した出来事について、必要なデータを認識・発生した単位で扱えば、最も合理的に処理出来ます。
 例えば、新しい見込み客が出来れば、その顧客のデータを顧客単位に登録すれば良いし、後に、その顧客と成約した場合は、成約したと言う事実だけを記録すれば良く、既に顧客のデータとして登録済みの部分について再登録する必要も無いし、改めて、顧客のデータを呼び出し、契約データに付加して二重に持つ必要も無いと言う使い方です。
 このように、実際のビジネスに倣って存在・行為・出来事とそれらの関係に従って、データを整理すれば、データの重複が発生する訳も無く、容易にスコープ内のデータを一元管理する構造が明らかになります。
 この作業がデータ分析/データモデリングで、いわゆるデータベース設計と言う事になります。

 と言う訳で、データベース設計とファイル設計は、どちらも一見ファイルやテーブルのデータ項目編成を決めると言う、外形的には似た作業に見えますが、アプローチの方向が全く逆になっているのです。
 また、一般的に成果物であるマスター設計とデータベース設計の内容が、一元化度の観点からは大きく異なっています。
 最後にはっきり言っておきますが、従来からのファイル設計の経験しかないままでは、如何に頑張ろうが、工夫しようが、全くデータベース設計にはならない。
 データベース設計に関する書籍・ホームページ・セミナーなど、どれを見ても「ファイル設計の経験を活用したデータベース設計」などと言うものはありません。
 データベースに関する情報に、ほんのわずかでも触れれば、表現にバラつきこそあれ「データ分析/データモデリング」が、データベース設計には必要だと言うことは容易に理解出来ると思います。
 データベース設計にはデータベース設計の必須技術である「データ分析/データモデリング」を、使えるスキルとして修得する以外に対応する手段はありません。
 なお、本講座を見れば分かると思いますが、データ分析/データモデリングのスキルを修得する事自体は、大して難しい事ではありません。
 ある事を知らない、必要性を知らない、方法を知らない、学習法を知らない、要するに知らないから出来ないだけのことなのです。
 企業は、大枚叩いて作ったシステムの寿命を、エンジニアの不勉強で縮められては、堪ったものではありません。
 組織的な指導体制・検証体制で、必要なスキル修得へ誘導する事が、情報システムの寿命を延ばすとなれば、教育・研修のコストと時間は効率の良い投資であると言うべきでしょう。
データベース設計の方法
 データベースの設計方法は、一見多様に見えますが、ビジネスの中で発生するデータの適切な配置と言う観点から考えると、本質的には一つしかありません。
 ビジネスの構成要素(エンティティ)を特定し、それら構成要素間の関連(リレーションシップ)を整理した上で、ビジネスの構成要素を説明しているデータ項目(アトリビュート)を、ビジネスの構成要素別に配置します。
 但し、実際のデータ分析では、データの全てが、エンティティに配置出来る訳ではないので要注意です。
 二次的に導出されたデータ項目や、現在の状況を表すために刻々と変化するデータ、システムの管理や運営のために持つ(ビジネスの状況を記録するためには無関係な)データもあるので、それらの扱いをどうするかについて、違いが生じている場合もありますが、大した問題ではありません。
 細かい相違に惑わされず、基本を押さえた上で、技法の特長は目的によって使い分ける位のスキルは欲しい所です。
 また、独自性を強調したり、流行りに乗るために、ほとんど同じ内容にも関わらず、技法や方法論の呼称に流行りの表現を含むものが増えており混乱を招いています。
 目的の中心をコードの再利用に置こうが、表現を汎用的なUMLで行おうが、データベース設計の本質に変わりが生じる訳が有りません。
 少なくとも、自説を世に問おうかと言う先生方が、風説を流布して世間を混乱させようなどと馬鹿な事をする訳は無いので、それぞれから有益な示唆を頂こうと言う謙虚さは持たねばならないでしょう。
 最後に、データベース設計は特定の目的を持たないので、特定のユーザインターフェースから見れば、当然、使い難い場合があります。
 常にパワフルな運用環境が約束されている訳でも無ければ、尚更使い難い状況は発生し易くなります。
 その場合には、使い方の工夫として、中間ファイルを検討する事も起こって来ます。
 但し、くれぐれもデータベース設計の部分を処理の都合で変更する事の無いようにしなければなりません。
 同じDBMSに実装しているとは言え、データベースと中間ファイルの扱いは違います。
 使い方の工夫と設計を混同してはいけません。
 データベースの設計を変えて良いのは、ビジネスそのものが変わる時だけしかあり得ません。
基幹系データベースと情報系データベース
 データベースに、基幹系データベースと情報系データベースと言う言い方があります。
 確かに実装段階では、基幹系と言われるクリティカルな定期定例処理群と、情報系処理に多い不定期不定形処理とを、一つのデータベースとして実装された一組のテーブル群で共用すると言う事は、情報セキュリティの可用性の観点から見ても、到底容認出来る事ではありません。

 ならば、データベース設計ではどうでしょうか。
 この二つのデータベースの設計に於いて、概念データモデルの段階で何か相違が考えられるでしょうか。
 データベースの定義をもう一度思い出して貰いたいのですが、データベースとは「複数の目的で共用する、相互に関連付いた冗長性の無いデータの集まり」でした。
 基幹系処理も情報系処理ももちろん複数の目的から除く理由は何もありません。
 と言う事は、このビジネスのスコープにおけるデータ構造はこうだ、と言う事を示す概念データモデルに相違が出来る訳がありません。
 つまり、データベース設計は、ビジネススコープに対して唯一つであり、基幹系データベース設計とか、情報系データベース設計と言うものはそもそも存在しないのです。
 データベースには目的が存在しないと言う事です。
 逆に、「このデータ項目を、ここに設定しておけば、あのユーザインターフェースの編集が楽になる」などと、処理目的との関係が頭に浮かぶようでは、データベースとしての洗練が足りないと言うことになるのです。
 但し、データベースとしての設計は同じでも、時系列の集計データや、履歴データなど、データベースの設計対象ではない部分も、DBMSの実装対象にはなります。
 通常、基幹系では集計データや履歴データは使わないが、情報系や分析系と言われる処理では、時系列の集計データや履歴データによる変化や推移の把握が中心になるので、当然、それらのデータ群も実装する必要があります。
 よって、実装形に限って見ると、複数のデータベースが存在する事になると言う訳です。
 こうであると言う「設計」(実際は分析)と、このほうが使いやすいと言う「工夫」を混同してはならないと言うことです。
情報基盤
 データベースと言う用語は、通常そのままデータベースで使われているが、日本語で適切に表現するなら、情報基盤が相応しいと思います。
 システム開発の不可視性を言う場合に、建築を引き合いに出す事がありますが、その意味では正に基盤に相当すると言う事に成るでしょうか。
 建築では、土地の形状や地質に合わせて基礎を築く事になりますが、ビジネスに合わせて情報基盤を構築する部分が正に基礎作りに相当する事になるでしょう。
 建築に於いて、基礎が土地の形状に馴染めず不安定だと、どんなに華麗な意匠も、安全性に問題があったのでは使い物になりません。
 同様に、ビジネスシステムに於いては、情報基盤がビジネスの実体と遊離していたのでは、基幹系であろうが、情報系であろうが、その上に構築するアプリケーションを安定的に運用する事は難しくなってしまいます。
 建築が斜面には斜面の基盤を作るように、システムも、それぞれのビジネスに合った情報基盤を先ず確立しなければ、工夫も応用も無いと言う訳です。
中間ファイル
 中間ファイルの意味する所ははっきりしませんが、現時点では、データベースやマスターなど、データを共有管理しているものと、ユーザインターフェースの間に存在するものと考えるのが良いでしょう。
 その存在自体は、データの使い方の工夫として、必要な存在ではありますが、特定ユーザインターフェースでの利用から、機能別、サブシステム別、全システムと、便利であればあるほど共用化が進み、共用データの範囲が混乱します。
 これは、中間ファイルの存在自体に問題があるのでは無く、その中間ファイルに相当する共用データが準備できなかった設計の不備であると考えるべきでしょう。
記録
 記録とは、存在する事実や発生した行為・出来事を書き残す事なので、誤って記録した事を正す以外に修正や更新は有り得ません。
 例えば、記録した契約が解約された場合は、契約を変更するのでは無く、新たに契約に対する解約を記録すと言う要領です。
 データベースは、ビジネスの事実を記録する部分と、その記録から二次的に導出される集計データなどを持つ部分に大きく分かれるのですが、少なくとも、ビジネスの事実を記録する部分に関しては更新と言うものは存在しません。
 よって、締めや月末に定期更新するデータベースなど有り得ないと言うことです。
一元管理
 既に、物理的に全てのデータをまとめて一カ所で持つ事も難しい事では無くなりました。
 しかし、情報系・DWHなど不定期不定形処理が増加する中で、クリティカルな定期定例処理とデータを共用するのは、情報セキュリティの可用性の観点からも止めておいた方が無難でしょう。
 但し、物理的な多重化は概念的一元化を前提にしています。
 全体のデータ管理に関して運営の指針(データ管理ポリシー)を明らかにする必要があります。
 またPCの活用などで、ローカルデータ・アンフォーマルデータが増加していますが、これらも当然ながら一元管理の対象となります。
 これらのデータは、矢継ぎ早にデータを要求する経営と、動きの鈍いシステム部門の間で、板挟みとなった経営支援部門が狗肉の策で運営している場合が多く、結構な確率で重要な会議への定期報告などに使われています。
 経営の根幹に関わる会議で使われるデータの値に、何の保証も裏付けも無いとなれば、議論自体が無意味となってしまいます。
 利用を制限する必要はありませんが、組織的な管理体制の整備・充実でローカルデータ・アンフォーマルデータもフォーマルデータへ吸収し値を保証する必要があるでしょう。
 データの間違いが、重大な判断ミスを犯した後で「エクセルのマクロ間違えてました」では済まないでしょう。
一元管理体制
 一元管理をするには、一元管理が出来る相応しい体制が必要です。
 ここで、概念的存在であるデータベースを物理的DBMSの管理と混同し、肝心のデータ構造の管理を、各サブグループに分散させて管理とも呼べない状況に置いている企業は多く見られます。
 当然、個別のサブシステムや、個別の機能の目的に沿った要求をする事になるのですが、要求を受け付ける方が容量やレスポンスの物理的管理しか行っていないのでは、何の牽制にもならず、従来のマスターと中間ファイル体制同様に初期の一元管理構造が急速に崩壊する事になってしまいます。
 データベースの管理は初期開発時と同様に、継続的な対応が必要であると言うことです。
台帳の比喩
 データベースの重要性やデータの普遍性を言う時に「江戸の昔も台帳が存在し」と言う言い方を聞くことがあります。
 ビジネスは昔からデータの記録を中心に運用されていました。
 その記録が昔は帳面・帳簿・台帳だったのが、データの電子化で今はデータベースに記録される様になったと言う主張です。
 確かにその通りで、あらゆるビジネスはデータをアクションの切っ掛けとしており、それらデータを記録し管理する事は、ビジネスを円滑に進める上で大切な要素に違いありません。
 しかし、帳面・帳簿・台帳とデータベースは、決定的な相違が存在します。
 それは、帳面・帳簿・台帳は、それ自体が記録であると同時に、ユーザーインターフェースでもあると言う事です。
 そのため、説明したい本質と逆の解釈、つまり「見たい形式でデータを持つものだ」と言う解釈も可能なので、誤解を与えないためには、説明上の配慮が必要になります。
 
 
 
 
 


   トップページへ