Home > Database basics >
Google
WWW を検索 このサイト内を検索
 
 
   
データベースの基礎知識

データベースとは何か

・データベースの定義
 データベースは「複数の目的で共用する、相互に関連付いた、冗長性の無いデータの集まり」と定義されている。
 そのため、与えられたデータの集まりを、定義通りに整理したものがデータベースであると思っている技術者も多く、また、それは、間違いと言う訳でもない。
 業務設計を経て、確定されたデータ項目をシステム設計工程で、正規化などによって整理し、データベース設計すると言うアプローチは、この考え方による手順と言う事に成るだろう。
 確かに、データベース設計を単にデータベースのレイアウトを決める作業であると理解すると、その対応も尤もだと言う事になる。

・データベース発生の経緯
 しかし、データベースが出来た経緯を考えると、与えられたデータを整理するだけで満足している訳には行かない。
 データベース以前のデータは、ユーザインターフェースをどうやって実現するかと言う目的指向で考えられていたため、ユーザインターフェース毎、又は、ユーザインターフェース群毎に、それぞれ専用のデータを持つ仕組みになっていた。
 そのため、何重にもデータが重複し、それら重複間の整合性をコントロールするためだけのアプリケーションも増え、情報システムの中の冗長性・無駄が情報システムを不必要に肥大化/複雑化させる。
 肥大化/複雑化が進むと、アクションを起こすまでの調査や調整が増加するので、保守作業の生産性を低下させる。
 この生産性低下の破壊力は、凄まじい威力を持っている。
 そのため、あまりの生産性の悪さに、保守作業と言う事が実質的に破綻する。
 そこでシステム内の整合性を再整理し、保守の生産性を回復するための「システム再構築」が必要になると言う訳だ。
 データベースは、この不毛のサイクルに終止符を打つ事を目的に構想された仕組みだ。
 その仕組みは単純で、データは全てデータベースに一元化する。
 全てのデータを一元的に記録しているので、当然、中間ファイルやローカルマスターなど、他にデータを記録する必要は無くなる。(必要は無くなるが、もちろん処理の都合で、中間ファイルを設けることに問題は無い)
 また、データを一元化する事で、全てのユーザインターフェース対データベースの間に1:1の関係を成立させる。
 そのため、ユーザインターフェースを実現するためには、データベースだけがあれば良いので、重複の元凶となる中間ファイルが不要となる。
 また、新しくデータ項目が増える場合などは、データベースの中に関連付けて持つ必要があるので、従来、調査・調整能力の不足から多用される事が多かった、付加ファイルによる追加データの保持は出来ない。(⇒もちろんやれば出来るがデータベースを使う目的が果たせなくなる。 また、実際問題として、正確にビジネスをモデル化したデータ構造が整理されていれば、新規のデータ項目追加で悩む必要は無い。)
 よって、データベースとは、スコープ内のデータを一元管理し共用する仕組みと考えれば良い。(実は、このスコープ内と言うのが曲者なのだが・・・) 
 なお、単にDBMSで実装したデータを指してデータベースと呼ぶケースも多いが、DBMSで実装することと、前述の定義を満たすことは関係無いので、DBMSで実装されたデータ群を無条件でデータベースと呼ぶのは不適切である。 
 更に言うと、データベースは情報が電子化されている必要すらない。
 名刺を集め、会社別に分類(相互に関連付けて)して、名寄せして一覧表を作り(冗長性のない)整理するだけで、要件を満たしており、自らの営業活動と言うビジネススコープでの立派なデータベースとなるのである。

・生産性低下の程度
 かねがね企業の経営者、CIO、情報システム部門の責任者、データベース管理の責任者などが、システム保守作業の生産性低下に関して、余りに大らかな事を疑問に思っていた。
 どうやら、彼らが大らかな原因は、手元に生産性の低下状況を示す具体的なデータが無いためのようだ。
 しかし、保守作業の生産性は、3年で1/2に低下する。
 6年で1/4、9年で1/8と追いこまれていけば、堪らず再構築に走ると言う訳だ。
 しかし、最近、不況やITの見かけのトレンドを追うあまり、再構築を無視しようと言う傾向がある。
 そして、そのことが誘発する著しい保守性低下の原因が、情報システム部門にあると考えている経営者が居るようだ。
 情報システム部門も、システムの構造的な問題の責任を押し付けられては良い迷惑だが、今まで、問題の所在を特定し、解決先を検討して来なかったのだから仕方がないか。
 しかし、この誤解が原因で、経営層と情報システム部門の間に齟齬が出来ては、情報戦略上も良い影響はないので、状況認識を共有して問題解決に協力する必要があるだろう。

なぜデータベースを使うのか

   データベースと言う概念が考えられる以前は、データは全てシステムやアプリケーションに従属していた。(と言うか、従属する扱いを受けていた)
 システムやアプリケーションは「取引先を指定して、該当する取引先別の受注残高を表示する」など、それぞれに固有の目的があり、目的を満たすためにはどのデータ項目を画面に表示しなければならないかなどと言う仕様が特定出来るので、それぞれに都合の良いデータの持ち方がある。
 先の例で言うと、月別取引先別に売り上げ金額を集計したデータを取引先別にまとめて持ち、ついでに取引先毎の名称や住所、連絡先などのデータも持っておくと都合が良い。
 そのために、サブシステム毎や機能毎、アプリケーション毎など、より小さな単位で専用のデータを持とうとする力が働く。
 これを放置すると、多くの中間ファイルやローカルマスタを生む。
 しかし、実際は都合が良いのは直接ユーザインターフェースを実現する機能部分だけで、データの入力・複写・編集・変換・管理など、本来、データを共用すれば不必要な冗長機能が生む無駄と不整合がシステム寿命の低下を招き、システム全体としての収支で考えると、とても容認できるものではない事が明らかになった。
 幸い、元よりデータは幾ら使っても減る事も無ければ内容が劣化する事も無いので、一つあれば良い。
 そこで、ビジネスシステムの冗長性を排除するために、個別にデータを持つ事を禁止し、スコープ全体でデータを一元管理し共用しようと言う概念が「データベース」として生まれたので、データベースと言いながらも冗長性を抱えていたのでは、データベースを使っているとは言えないと言う訳だ。

ファイル設計とデータベース設計

  ファイル設計とは、特定のプログラムで実現しようとする機能で使うデータ群の持ち方を決める事だ。
 そのため、評価の指標が、如何にプログラムの機能実現に有用であるかと言うことになる。
 例えば、受注マスターに取引先番号に加えて「取引先名称」や「取引先住所」・「取引先電話番号」なども持っていれば、方々のマスターを読む手間が無くなるので、プログラムを作る負荷が軽減する良いファイル設計となる。
 簡単に言うと、必要なデータをなるべくまとめて持とうと言う方向に向かう。
 そうは言っても、アプリケーション毎に個別のファイルを持つとデータを変更する場合などに大きな負荷が掛ることは明らかなので、利用頻度の高いデータについては、マスターと言う形で共用化を図る事になる。
 しかし、データのまとめ方・一元管理などの管理方針・マスターに存在するデータは必ずマスターから直接アクセスして使うなどのデータの使い方・のようなポリシーがはっきりしていない事が多く、マスターが多くの選択肢の一つに成り下がる事になる。
 もちろんマスターを複写してサブシステム専用のサブマスターを作る事にもお構いなしだ。
 お構いなしどころか、その様な状況を管理牽制する組織が存在することも少ないのが大方の企業のデータ管理実態ではなかろうか。。

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

 と言う訳で、データベース設計とファイル設計は、どちらも一見ファイルやテーブルのデータ項目編成を決めると言う、外形的には似た作業に見えるが、アプローチの方向が逆である。
 また、一般的に成果物であるマスター設計とデータベース設計の内容が、一元化度の観点からは大きく異なっている場合が多い。
 最後にはっきり言っておくが、従来からのファイル設計の経験しかないままでは、如何に頑張ろうが、工夫しようが、全くデータベース設計にはなっていない。
 データベース設計に関する書籍・ホームページ・セミナーなど、どれを見ても「ファイル設計の経験を活用したデータベース設計」などと言うものは無い。
 データベースに関する情報に、ほんのわずかでも触れれば、表現にバラつきこそあれ「データ分析/データモデリング」が、データベース設計には必要だと言うことは容易に理解出来る。
 データベース設計にはデータベース設計の必須技術である「データ分析/データモデリング」を、使えるスキルとして修得する以外に対応する手段はない。
 なお、本講座を見れば分かると思うが、データ分析/データモデリングのスキルを修得する事自体は、大して難しい事ではない。
 ある事を知らない、必要性を知らない、方法を知らない、学習法を知らない、要するに知らないから出来ないだけだ。
 企業が、大枚叩いて作った情報システムの寿命を、エンジニアの不勉強で縮められては、堪ったものではない。


データベース設計の方法

 データベースの設計方法は、様々な方法論として紹介されるので、一見多様に見えるが、ビジネスの中で発生するデータの適切な配置と言う観点から考えると、本質的には一つしかない。
 ビジネスの構成要素(エンティティ)を特定し、それら構成要素間の関連(リレーションシップ)を整理した上で、ビジネスの構成要素を説明しているデータ項目(アトリビュート)を、ビジネスの構成要素別に配置する。
 但し、実際のデータ分析では、データの全てが、エンティティに配置出来る訳ではない。
 二次的に導出されたデータ項目や、現在の状況を表すために刻々と変化するデータ、システムの管理や運営のために持つ(ビジネスの状況を記録するためには無関係な)データもあるので、それらの扱いをどうするかについて、違いが生じている場合もあるが、大した問題では無い。
 細かい相違に惑わされず、基本を押さえた上で、技法の特長は目的によって使い分ける位のスキルは欲しい所だ。
 また、独自性を強調したり、流行りに乗るために、ほとんど同じ内容にも関わらず、呼称に流行りの表現を含むものが増えており混乱を招いている。
 目的の中心をコードの再利用に置こうが、表現を汎用的なUMLで行おうが、データベース設計の本質は同じである。
 少なくとも、自説を世に問おうかと言う先生方が、風説を流布して世間を混乱させようなどと馬鹿な事をする訳は無いので、それぞれから有益な示唆を頂く謙虚さは持たねばなるまい。
 最後に、データベース設計は特定の目的を持たないので、特定のユーザインターフェースから見れば、当然使い難い場合がある。
 常にパワフルな運用環境が約束されている訳でも無ければ尚更だ。
 その場合には、使い方の工夫として中間ファイルを検討する事もあろう。
 但し、くれぐれもデータベース設計の部分を処理の都合で変更する事の無いように。
 同じDBMSに実装しているとは言え、データベースと中間ファイルの扱いは違う。
 使い方の工夫と設計を混同してはならない。
 データベースの設計を変えて良いのは、ビジネスそのものが変わる時だけである。

基幹系データベースと情報系データベース

  基幹系データベースと情報系データベースなどと言う言い方がある。
 確かに実装段階では、基幹系と言われるクリティカルな定期定例処理群と、情報系処理に多い不定期不定形処理とを、一つのデータベースとして実装された一組のテーブル群で共用すると言う事は、情報セキュリティの可用性の観点から見ても、容認出来る事ではない。

 ならば、データベース設計ではどうか。
 この二つのデータベースの設計に於いて、概念データモデルの段階で何か相違が考えられるだろうか。
 データベースの定義をもう一度思い出して欲しい「複数の目的で共用する、相互に関連付いた冗長性の無いデータの集まり」である。
 基幹系処理も情報系処理ももちろん複数の目的から除く理由は何も無い。
 と言う事は、このビジネスのスコープにおけるデータ構造はこうだと言う事を示す概念データモデルに相違が出来る訳がない。
 つまり、データベース設計は、ビジネススコープに対して唯一つであり、基幹系データベース設計とか、情報系データベース設計と言うものはそもそも存在しない。
 データベースには目的が存在しないと言う事だ。
 逆に、「このデータ項目を、ここに設定しておけば、あのユーザインターフェースの編集が楽になる」などと、処理目的との関係が頭に浮かぶようでは、データベースとしての洗練が足りないと言うことになる。
 但し、データベースとしての設計は同じでも、時系列の集計データや、履歴データなど、データベースの設計対象ではない部分も、DBMSの実装対象にはなる。
 通常、基幹系では集計データや履歴データは使わないが、情報系や分析系と言われる処理系では、時系列の集計データや履歴データによる変化や推移の把握が中心になるので、当然、それらのデータ群も実装する必要がある。
 よって、実装形に限って見ると、複数のデータベースが存在する事になると言う訳だ。
 再度言うが、こうであると言う「設計」(実際は分析)と、このほうが使いやすいと言う「工夫」を混同してはならない。
 
情報基盤

  データベースは、通常そのまま「データベース」と表記して使われているが、日本語で適切に表現するなら、情報基盤が相応しいだろう。
 システム開発の不可視性を言う場合に、建築を引き合いに出す事が多いが、その意味では正に基盤に相当することになるだろう。
 建築では土地の形状や地質に合わせて基礎を築く事になるが、ビジネスに合わせて情報基盤を構築する部分が正に基礎作りに相当する事になるだろう。
 建築に於いて、基礎が土地の形状に馴染めず不安定だと、どんなに華麗な意匠も、安全性に問題があったのでは使い物にならない。
 同様に、ビジネスシステムに於いては、情報基盤がビジネスの実体と遊離していたのでは、基幹系であろうが、情報系であろうが、その上に構築するアプリケーションを安定的に運用する事は難しい。
 建築が斜面には斜面の基盤を作るように、システムも、それぞれのビジネスに合った情報基盤を先ず確立しなければ、工夫も応用も無いと言う事だ。
中間ファイル

 中間ファイルの意味する所ははっきりしないが、現時点では、データベースやマスターなどデータを共有管理しているものと、ユーザインターフェースの間に存在するものと考えると良いだろう。
 その存在自体は、データの使い方の工夫として、当然の存在だが、特定ユーザインターフェースでの利用から機能別、サブシステム別、全システムと、便利であればあるほど共用化が進み、共用データの範囲が混乱する。
 これは、中間ファイルの存在自体に問題があるのでは無く、その中間ファイルに相当する共用データが準備できなかったデータベース設計の不備であると考えるべきだろう。
記録

 記録とは存在する事実や発生した行為・出来事を書き残す事なので、誤って記録した事を正す以外に修正や更新は有り得ない。
 例えば、記録した契約が解約された場合は、契約を変更するのでは無く、新たに契約に対する解約を記録する。
 データベースは、ビジネスの事実を記録する部分と、その記録から二次的に導出される集計データなどを持つ部分に大きく分かれるが、少なくとも、ビジネスの事実を記録する部分に関して言えば、構造的に更新は発生しない。
 よって、締めや月末に定期更新するデータベースなど有り得ないので、データベース設計くぉ評価する一つの指標と考えて良い。(Viewデータをテーブルに実装した部分に関しては、造りによっては更新が発生するので、先ずはその見極めが必要となる)
一元管理

 既に、物理的に全てのデータをまとめて一カ所で持つ事も難しい事では無くなった。
 しかし、情報系・DWHなど不定期不定形処理が増加する中で、クリティカルな定期定例処理とデータを共用するのは、情報セキュリティの可用性の観点からも止めておいた方が無難だろう。
 但し、物理的な多重化は概念的一元化を前提にしている。
 全体のデータ管理に関して運営の指針(データ管理ポリシー)を明らかにする必要がある。
 またPCの活用などで、ローカルデータ・アンフォーマルデータが増加しているが、これらも当然ながら一元管理の対象である。
 これらのデータは、矢継ぎ早に経営判断のためのデータを要求する経営と、動きの鈍いシステム部門の間で、板挟みとなった経営支援部門が狗肉の策で運営している場合が多く、結構な確率で重要な会議への定期報告などに使われている。
 経営の根幹に関わる会議で使われるデータの値に何の保証も裏付けも無いとなれば、議論自体が無意味である。
 利用を制限する必要は無いが、組織的な管理体制の整備・充実でローカルデータ・アンフォーマルデータもフォーマルデータへ吸収し、値を保証する事を勧める。
 重大な判断ミスを犯した後に「エクセルのマクロ間違えてました」では済まない。
一元管理体制

 一元管理をするには、相応しい体制が必要となる。
 ここで、概念的存在であるデータベースを物理的DBMSの管理と混同し、肝心のデータ構造の管理を各サブグループに分散させて管理とも呼べない状況に置いている企業は多い。
 当然、個別のサブシステムや個別の機能の目的に沿った要求をする事になるが、要求を受け付ける方が容量やレスポンスの物理的管理しか行っていないのでは、何の牽制にもならず、従来のマスターと中間ファイル体制同様に、初期の一元管理構造が急速に崩壊する。
 データベースの管理は初期開発時と同様に、継続的な対応が必要である事に留意したい。

台帳や帳面の比喩

 データベースの重要性やデータの普遍性を言う時に「江戸の昔も台帳が存在し・・・」と言う言い方を聞くことがあります。
 ビジネスは昔からデータの記録を中心に運用されていた。
 その記録が昔は帳面・帳簿・台帳だったのが、データの電子化で今はデータベースに記録されう様になったと言う主張だ。
 確かにその通りで、あらゆるビジネスはデータをアクションの切っ掛けとしており、それらデータを記録し管理する事はビジネスを円滑に進める上で大切な要素に違いない。
 しかし、帳面・帳簿・台帳とデータベースは、決定的な相違が存在する。
 それは、帳面・帳簿・台帳は、それ自体が記録であると同時に、ユーザーインターフェースでもあると言う事だ。
 そのため、説明したい本質と逆の解釈、つまり「見たい形式でデータを持つものだ」と言う解釈も可能なので、誤解を与えない説明上の配慮が必要だ。