ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

情報処理試験ぐらいのお勉強のポイント 2.データベース

2008-04-17 12:09:17 | Weblog

 この前からはじめた、情報処理試験ぐらいのお勉強のポイント今回はデータベースです。
イントロダクションを書いて、その後、3層スキーマ構造(後述)に沿って、ポイントです。




■イントロダクション

●電気を切っても、データを保存しておく必要がある

 コンピューターは、電気が入れば、計算とか、処理をさせることが出来ます。
 でも、電気を切ったら、どうでしょう。。
 もし、すべてのデータが消えてしまったら、こまります。
 昨日、入力した従業員データが、今日、消えちゃっていたら困ります。また今日も、従業員全員、入れ直さないといけません。

 これはこまるので、コンピューターは、ハードディスクなどに保存して、電気を切っても、データが残っているようにします。これを、永続性(Durability)といいます。
 この永続性を実現するには、ファイルなどに、データを保存しておけば良いわけです。

●みんなで使える必要がある
 じゃあ、ファイルがあればいいんだね。。と、いうと、初めのうちはそれでも良かったのですが、そのうち、プログラムがいっぱいになると、それだけでは、困る問題が出てきました。

(A)たとえば、従業員ファイル。プログラムごとに同じ従業員ファイルを持ってしまうと、従業員が1人入社したら、それらの従業員ファイル全部に追加しないといけません!

(B)じゃあ、同じ従業員ファイルをみればいいじゃん!ということになりますが、もし、従業員ファイル中、あるプログラムで、1項目ふやしたいとなると、他のプログラムでは、その項目は必要ないのに、ファイルのフォーマットが変わってしまうので、修正しないといけません。
 これは困ります。プログラムがふえてしまうと、おちおち修正も出来ません。

(C)さらに、従業員Aさんが、新規にできた部署Bに所属しているとしたとき、プログラムXで、従業員Aさんを書き出し後、これから、部署Bを追加しようとしたとき、プログラムYが従業員を検索したら困ります。Aさんは、まだ部署ファイルに書かれていないBに所属??幽霊部署所属??になってしまいます。

 これらの問題を解決する必要があります。

●問題Aの解決策-ファイルを共有する
 問題Aは簡単です。データを1事実1箇所にあつめ、みんなでそのデータを共有すればいいわけです。
 (で、共有すると、B、Cの問題が出てきたわけです)

●問題Bの解決法-プログラムごとに見え方をかえる
 問題Bは、データは共有するんだけど、プログラムごとに、データのみえかた(レコードの構造)は変えて、あるプログラムでデータ構造を変更かけても、他のプログラムにおいては、データのみえかた(レコードの構造)は変わらないというようにすればいいです。

 これは、ビューという方法で解決します。

●問題Cの解決法-トランザクション
 問題Cの、データ矛盾を起こさないことを満たすのには、以下の3つの機能が必要です。

・一貫性(Consistency)
 そのデータが満たすべき条件を、つねに矛盾ないようにする。
 たとえば、従業員がかならず、どこかの部署に属しているとすれば、従業員が所属する部署データはかならず、存在しないといけません。このような制約(参照制約)つけて、データを矛盾ないようにすることを一貫性といいます。

・独立性(Isolation)
 一貫性を満たすということは、他のプログラムからみたとき、従業員ファイルを書き出し後、部署ファイル書き出し中なんていう状態が見えないようにしないといけません。
 つまり、複数ファイル書き出し中は、他のプログラムから見ると、書き出し前の状態が見え、全部書き出したら、書き出し後の状態が見えるようにしないといけません。
 この他のプログラムからみたとき、書き出し前と書きだし後しかみえなく、操作中の内容が隠蔽されることを、独立性といいます。

・原子性(Atomicity)
 じゃあ、操作中の内容が隠蔽されるだけでよいかというと、もし、操作中にエラーがあったらどうなるの?という話になります。そのままだと、操作中の状況になってしまいます。こうすると、一貫性がたもてなくなるので、プログラム上でも、書き出し前と書きだし後しかない(ロールバックとコミットといいます)ようにします。

 この3つの機能+永続性を、Atomicity+Consistency+Isolation+Durabilityってことで、ACID特性といいます。そして、これを実現するのに、トランザクションというものを用います。これで、データ上の矛盾がありません。

●で、結局
このように、ファイルでの問題を解決するため

  ・データを1事実1箇所にあつめ
  ・ビューによって、プログラムごとに見え方を変え
  ・トランザクション機能をいれた

ものが、データベースです。




■データベースにデータを入れるには?
 では、データベースにデータを入れるには、どのようにしたら良いでしょうか?
 まず、データベースは、上記のように、1つの事実は、1箇所に格納するようにしなければいけません(1事実1箇所)。
 この手法を正規化といいます。そして、正規化したものを、目で見て分かるようにしたものがER図です(厳密に言うとちょっと違うけど・・)

・つまり、(正規化などをして)データをどのようにDBに格納するか、設計します。

  そのあと、そのデータを、実際に、データベースに入れます。

・つまり、データをDBに物理的に格納します。

 で、データベースは、プログラムごとにあった見え方にするのでした。
 これには、ビューを使いますが、テンポラリに必要なデータをとってくることもできます。
 ま、どちらにしろ、データをとってくるには、SQLなどのデータベース操作言語を使います(Accessではクエリですが、クエリはボタンを押すとSQLになります)。

・つまり、外部のプログラムでデータを利用できるように加工します。

以下、この順に説明しますが、これには、それぞれ、名前がついています。

 概念スキーマ:正規化などをして、データをDBに格納できるように設計します。
 内部スキーマ:データをDBに物理的に格納します
 外部スキーマ:外部のプログラムでデータを利用できるように加工します

そして、この3つの関係を、3層スキーマ構造といいます。

●Accessとの関係
Accessの場合は、

概念スキーマ:正規化作業(Accessの外で行います)→ER図相当は、「リレーション」を設定
内部スキーマ:テーブルを作成します
外部スキーマ:クエリを作成します


 そのあと、プログラミングとして、レポートやフォームを作成します。それで書ききれない機能は、マクロなどを使うことになります。




■概念スキーマのポイント
・正規化理論
  第一正規形(繰り返しを除く)
  第二正規形(主キーをきめ、複合キーの場合は、従属項目の排除)
  第三正規形(主キー以外の項目に従属する項目(推移従属)の排除)
 BCNF、第四、第五正規形(多値従属)は、データベーススペシャリストのはんいかな?

・ER図
  標準:IDEF1X
  カーディナリティ(主キー側が1になるはず)




■内部スキーマ
・インデックス
  B木関係(B+など)
  ハッシュ-シノニムの問題
・データ部分
  行移動のはなしとかは、実務上あるけど。。




■外部スキーマ
・RDBと階層型データベース
  ・RDB:関係演算(射影とか)、SQL、ビュー
  ・階層型:親子関係

・ドライバ
  ODBC,JDBC

・トランザクション
  ・コミット、ロールバック
  ・ジャーナルファイル
  ・デッドロック




なかんじですかにょ・・
P.S 試験までには、全然間に合わないね(^^;)


この記事についてブログを書く
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする
« 正規表現でのチェック方法を... | トップ | 「あの人猛獣役になったんだ... »
最新の画像もっと見る

Weblog」カテゴリの最新記事