カテゴリ:データベース( 12 )
 テクニカルエンジニア(データベース)試験をめざして、学習しています。
 おなじように迷っている方の参考になれば幸いです。
 誤りをみつけた方はお教えいただけると非常に助かります。

 正規化理論
    繰り返しグループ(非単純定義域)
    第一正規形にはなぜ2種類あるのか
    候補キーと主キーの違い
    候補キーの定義
    関数従属性に関する推測論

 データモデル作成
    正規化とER図の関係
    トップダウンアプローチ
    ボトムアップアプローチ

 トランザクション管理機能
    ACID特性
    障害回復処理
[PR]
by nwdb | 2006-01-01 00:00 | データベース
データベースの耐久性(Durability)は、障害回復処理によって実現されます。
障害回復処理をかんがえてみましょう。

毎日、データを入力しているエクセルのファイルがあるとします。
しごとが終わってから帰るまえに、
昼間作業した分をフロッピーにコピーしているとしましょう。
つまり日次バックアップです。

さて、今日は張り切ってたくさんデータを追加入力しました。
ところが、突然、ハードディスクがいかれてしまったとします。
さあ困りました。
昨日までのデータは、フロッピーにバックアップしてあります。
すっからかんにならなくてよかったです。
まずこれを復元します。
さて、今日やっとのことで入力したたくさんのデータを、
もう一度はじめから入力しなおすことにしましょう。
これが、ロールフォワードです。

あるデータを入力している最中に、
とつぜん、エクセルのマクロが異常終了してしまったとします。
途中まで入力したままそれが一件となってしまうとまずいです。
一件のデータは、全部入力したか、
まったく入力していないかのどちらかでないと、
統計が狂ってしまいます。
この、完全に実行されたかまったくされなかったかの
どちらかでないといけないことを原子性(Atomicity)といいます。
まずはとりあえず、
そのデータはなかったことにしましょう、
というのがロールバックです。

さて、エクセルで入力している最中に、
とつぜん異常終了することがあるので、
ある程度入力したら、
フロッピーのバックアップファイルに「上書き保存」をする習慣にしています。
この上書き保存が、チェックポイントです。
上書き保存してしまえば、
それ以前に入力したデータは保証されます。

入力している一件のデータにはいろんな項目があり、
いくつかのマクロがながれてはじめて成立しているとします。
データの入力はじめが、
トランザクションの開始(BIGIN TRANZACTION)です。
データ一件が最後まで入力されて、
すべてのマクロがながれおわると、
トランザクションの終了、コミット(COMMIT)です。
トランザクションが異常終了して、
ロールバック(ROLLBACK)すると、
そのトランザクションはなかったものとして、BIGINの位置まで戻ります。

例えが低俗ですみません。

どこで上書き保存(チェックポイント)するかによって、
障害回復処理がかわってきます。

ハード的な障害なら、
コミットしていない(完了していない)部分は、
ログの順序どおり、
チェックポイントからもういちど再実行するしか方法がありません。

トランザクション障害(処理実行中の障害)なら、
そのトランザクション(実行中だった処理全体)はなかったものとする、
つまりロールバックです。

この、チェックポイントというのが、
上書き保存のようなものだとわかったら、
障害回復処理はわかったようなものです。
[PR]
by nwdb | 2004-11-22 08:42 | データベース
トランザクションとは、ユーザーからみた一連の処理のまとまりのこと。

トランザクションは、ACID特性(アシッド特性)をもつ。
このACID特性をもつことによって、トランザクションの信頼性が得られる。
これを実現するために、DBMSは、トランザクション管理機能(コミットメント制御機能、排他制御機能、障害回復機能)をもつ。


原子性(Atomicity)

トランザクションは、完全に実行されるか、まったく実行されないかのどちらかでなければならない。
コミットメント制御により実現。


一貫性(Consistency)

トランザクションの終了状態にかかわらず、データベースの状態は矛盾のない状態であること。トランザクションは、内部で整合性が保たれなければならない。
排他制御(同時実行制御)により実現。


独立性(Isolation)

トランザクションは、同時に実行している他のトランザクションからの影響を受けないこと。また、並行実行の場合も、単独で実行しているのと同じ結果を返さなければならない。
排他制御(同時実行制御)により実現。


耐久性(Durability)

トランザクションの結果は、障害が発生しても失われることがないこと。
障害回復により実現。


[PR]
by nwdb | 2004-11-14 07:27 | データベース
まず、集合の記号を確認します。

  A⊆B   「AはBの部分集合」「AはBに含まれる」
  A∈B   「AはBの要素」
  A∪B   「和集合」

和集合とは、
少なくともどちらか一方の集合に属する要素全体の集合のことです。
たとえば
  A={1,2,7,8}
  B={1,2,3,6,9}
とすると
  A∪B={1,2,3,6,7,8,9}

関数従属性に関する推測論は、
データベース技術 新版(専門分野シリーズ)」(ITEC)のp.52にあります。

この関数従属性に関する推測論はまだ正確に理解してはいません。
イメージはなんとなくですがわからないこともありません。

1.反射律
Y⊆X⊆Uのとき、X→Yは関数従属である。

  YがXに含まれ(YがXの部分集合であり)、
  XがUに含まれる(Xがその表の属性である)とき、
  X→Yという関数従属が成り立つ。

2.増加律
X→Yが成立し、かつZ⊆Uのとき、X∪Z→Y∪Zが成り立つ。


3.推移律
X→YとY→Zが成立すると、X→Zが成立する。

  (学生番号,氏名,学部,学部所在地)
  のばあいで、
  {学生番号}→{学部}
  {学部}→{学部所在地}
  が成立すると、
  {学生番号}→{学部所在地}
  が成立する。

4.合併律
X→Y,X→Zが成立すると、X→Y∪Zが成立する。

  (学生番号,氏名,学部)
  のばあいで、
  {学生番号}→{氏名}
  {学生番号}→{学部}
  が成立すると、
  {学生番号}→{氏名,学部}
  が成立する。

これを利用して、問題を解いてみます。

------------------------------------------------
例題:
関係「購入申込」の候補キーをすべて挙げよ。

(H15、午後Ⅰより)

カタログ販売の主な関数従属性

購入申込(顧客番号,申込番号,日付,支払方法,住所,顧客名,電話番号)
------------------------------------------------

候補キーの条件「どの属性YjもXに関数従属であり(一意性)」から、
このような図があったばあい、
すべての属性に矢印が到達しているのが候補キーだといえます。
矢印がすべてにつながっているものを選べばよいはずです。

日付、電話番号、支払方法
の3つは、矢印の終点なので、候補キーにはなりません。

  {顧客番号,申込番号}→{支払方法}
  {顧客番号,申込番号}→{日付}

{顧客番号,申込番号}のうち{顧客番号}だけから、

  {顧客番号}→{住所,顧客名}→{電話番号}

と、推移律によりたどることができます。
というのをみると、
{顧客番号,申込番号}は、候補キーといえます。

{住所,顧客名}だけからでは、支払方法と日付にたどりつきません。
顧客番号には向かってきている矢印があります。

  {住所,顧客名}→{顧客番号}

です。
ということは、あと申込番号があれば、候補キーになりえます。
{住所,顧客名,申込番号}も候補キーといえます。

解答:
{顧客番号,申込番号}{住所,顧客名,申込番号}
[PR]
by nwdb | 2004-11-07 03:54 | データベース
関係Rのどの属性YjもXに関数従属であり(一意性)、Xが極小あるいは非冗長のとき、このXを候補キーまたは単にキーという。Xが極小あるいは非冗長とは、Xから属性の一部を取り除くと、関数従属にならないような属性Y1が存在することを意味する。

最初なにをいっているのかわかりませんでした。
データベース技術 新版(専門分野シリーズ)」(ITEC)のp.51にありました。
例をあげて考えてみましょう。

  学生(学生番号,氏名,学年,学部,学部所在地)
  履修(学生番号,科目名,成績,先生)

という表があったとします。

まず、学生表からみてみましょう。

学生番号をXとします。
その他の属性はYとします。

  学生(X,Y1,Y2,Y3,Y4)

  {学生番号}→{氏名}
  {学生番号}→{学年}
  {学生番号}→{学部}
  {学生番号}→{学部所在地}

学生表のY1,Y2,Y3,Y4も、
学生番号Xに関数従属しています。

では、学生番号Xが極小あるいは非冗長であるかをみてみます。

学生番号という属性がなければ、
Xがないのですから当然ですが
関数従属にはなりえません。

この場合、「どの属性Yjも」というのが重要です。
Y1,Y2,Y3,Y4のうち
ひとつでもXに関数従属していなかったら、
一意性が保たれないのですから、
Xは候補キーにはならないのです。


履修表はどうでしょうか。

  (学生番号科目名,成績,先生)

学生番号と科目名を、候補キーXとします。
その他の属性はYとします。

  履修(X1,X2,Y1,Y2)

となっています。

  {学生番号,科目名}→{成績}
  {学生番号,科目名}→{先生}

学生番号と科目名がわかってはじめて成績がわかります。
学生番号と科目名がわかってはじめて先生がわかります。
どちらかでも欠けてしまったら、
成績Y1,先生Y2は、関数従属しない、ということになります。

X1,X2のどちらか片方でもかけてしまったら、
Xは候補キーにはなりえません。

つまり、学生番号と科目名は、
欠けてはならない。
つまり、両方そろってはじめて、X(候補キー)といえます。

  {学生番号,科目名}

という複合キーなわけです。


p.s.
じつはこの定義のあとに「関数従属性に関する推測論」というのが載っていました。おそらくこの推測論は前述の定義から導かれるのだろうとおもいます。候補キーや主キー、外部キーを列挙させる問題はよく出題されています。もしかしたらこれがわかったらずいぶん楽になるのでは?と期待をしています。

関数従属性に関する推測論

関係Rに複雑な関数従属関係がある場合、属性Xがキーであることを導くためには次に示す関数従属性に関する推測論を用いる。

これらの推測論によりXが関係Rのすべての属性を関数決定することが導ければ、Xはキーである。

1.反射律
Uを関係Rの属性集合とする。Y⊆X⊆Uのとき、X→Yは関数従属である。これは、右辺が左辺に含まれるという自明の従属性を与える。

2.増加律
X→Yが成立し、かつZ⊆Uのとき、XZ→YZが成り立つ。X,Y,Zは属性の集合であり、XZはX∪Zの略記である。

3.推移律
X→YとY→Zが成立すると、X→Zが成立する。

4.合併律
X→Y,X→Zが成立すると、X→YZが成立する。

[PR]
by nwdb | 2004-11-06 16:02 | データベース
候補キーは、主キーの候補となるキーのことであると説明されます。

特定の行を識別できる列(項目)のことを、候補キーといいます。

一般に、候補キー(candidate key)は、
1つの表(リレーション)のなかに複数あることが多いのですが、
このうちの、ただ1つだけをえらんで、主キー(primary key)とします。

候補キーは、複合キー(連結キー)のばあいがあります。
そのうちの1つから主キーをえらびますので、
主キーも複合キーのばあいがあります。

主キーは1つの属性とはかぎりません。
「ただひとつ」というのは、
数ある候補キーの組み合わせのうち1つ、
という意味です。

候補キーをみつけるのはとてもだいじなことです。
そして、そのうちからえらんだたった1つの主キーが
他の表とむすびつけるためのキーになります。

それでは、どのようにキーを選択するのでしょう。

データベース技術 新版(専門分野シリーズ)」(ITEC)のp.34-35の説明をみてみると、
候補キー
関係の中でn個組(行)を一意に識別し、冗長性のない1個または1個以上の属性を候補キーという。関係の中に候補キーは複数個あってもよい。
主キー
候補キーのうちのどれか一つの主たるものを主キーという。主キーは一つの表内にただ一つ定義でき、一意性を保証するためにナル値は認められない。

とあります。
主キーの説明にある、
ナル値は認められない
というところがたいせつです。

つまり、主キーの条件(キー制約)は、
1.一意性制約
2.非ナル制約
ですが、
候補キーの条件は、1の一意性制約のみです。

たとえば、

{登録No,住基コード,氏名,生年月日,住所,電話番号}

という表があったとします。
あたらしい住民を登録するときに、
登録No は、登録する際に自動的に振られる、とします。

登録No は、おなじものはありえませんし、
値がないということもありません。
これは主キーになりえる、といえます。

住基コードですが、
同じ住基コードは日本中に2つとないため、
これは一意であるといえます。
住基コードから行(レコード)を特定できるわけです。

ところが、
データの登録時、
住基コードがわからないときがあるかもしれないとします。
住基コード欄に何も入れない、という状態です。
これをナル値といいます。

ナル値(NULL値)とは、
値の全く入っていない状態を指します。

このとき、住基コードは候補キーではあるが、
主キーではない、といえます。
[PR]
by nwdb | 2004-11-06 13:18 | データベース
ようは、繰り返しグループ(非単純定義域)さえなくなればよいのです。

データベース技術 新版(専門分野シリーズ)」(ITEC)の p.53 には、
関係Rがその属性に繰り返しグループ(非単純定義域)を一つも含まないものを第1正規形という。

とあります。
リレーショナルデータベースであつかうことができるデータは、
最低でも第一正規形をみたしていないとなりません。

関係モデルには、データ構造、データインテグリティ(整合性)、データ操作の三つの要素があります。
データ構造は、
  定義域、
  任意の次数の関係(任意の数の属性からなる関係)、
  属性、
  組(タプル:行のこと)、
  候補キー、
  主キー
からなります。
データベース技術 新版(専門分野シリーズ)」(ITEC)によると、

・表形式では、列や行がある順番をもって並んでいるという概念はない。順番には意味がない。
・関係は、集合の要素の一般的性質を引き継いでいるため、同じ行(組)が複数個存在することがない。また、繰り返し項目を含む表は扱えない。

とあります。リレーショナルデータベースでは、レコードの格納順は保証されません。リレーショナルデータベースはデータの集合体に過ぎません。データの格納順序を考えること自体が無意味なのです。さて最後の「繰り返し項目を含む表は扱えない」に注目してください。
データベースシステム概論」C.J.DATE著、丸善刊によると、リレーショナルデータベースは、
すべての表のすべての列―行の場所には、
常に1つのデータの値のみ存在し、
決していくつかの値の集合であってはならない。

ということです。そして、
すべての基礎をなす定義域がスカラ値のみを含むとき、
そのときに限り、この関係を1NFという。

スカラというのは「分割不可能」ということです。
すなわち、リレーショナルデータベースにおいては、
すべてのデータは、分割不可能(scalar)でなければならないのです。

リレーショナルデータベースの原則は、
1行(1組)が1件のデータ(レコード)です。
さきほど
表形式では、列や行がある順番をもって並んでいるという概念はない
とありました。
たとえ行が入れ替わったり、列が入れ替わったりしても、
内容が変わることはありえない、
というのがリレーショナルデータベースの構造です。
つまり各行(組)が1つ1つ独立して扱える、というのが大事なのです。

なので、ひとつの項目のなかに、
複数のデータが格納されているのは扱えないわけです。
すべての表のすべての列―行の場所には、
常に1つのデータの値のみ存在し、
決していくつかの値の集合であってはならない。

データはそれ以上分割できない(スカラ)という単位とし、
けっして集合としてはならないのです。

第一正規化にあたって、方法は2つあります。

  1.フラットなテーブルにする方法
  2.繰り返しグループを分解する方法

です。
本来ならば、フラットなテーブルの形が最初にあるべきであろうとおもいます。
エクセルなどでも、
最初からそういったフラットなテーブルで入力している、
ということはあります。

しかし、もし仮に繰り返し項目のあるテーブルがあったとしたら、
あなたならどうしますか?

一組を一件とし、繰り返しグループ以外に値を入れてフラットなテーブルを作成する、
という作業は、
入力ミスによる不整合などの間違いをしでかすかもしれません。
これはリレーショナルデータベースの目指しているのとは正反対のことです。
フラットなテーブルにする、というのは、
重複更新・重複登録の危険性をわざわざ増やしているようなものです。

ようは、繰り返し項目(非単純定義域)がなくなればよいのですから、
そのまま分解してしまう、
という方法が生まれるのもわかるというものです。
[PR]
by nwdb | 2004-11-01 21:01 | データベース
非正規形とは、繰り返しグループを含む状態のことです。
この「繰り返し」は,データの中身を言うのではなく、
テーブルの構造に対して使用している言葉です。

この「繰り返し」ということばはとても誤解を生みやすいようです。

たとえば、エクセルなどにデータを入力するとすると、
たいていは第一正規形で入力することになります。
この際、何度もおなじ項目におなじ内容を入力することになります。
その何度も入力する項目が「繰り返し項目」なのではありません

データベースシステム概論」C.J.DATE著、丸善刊
索引に「繰り返しグループ」という単語がありました。

階層レコード型は、単一のAフィールドと、Bの繰り返しグループ(repeating group)とから構成され、繰り返しグループは、aのフィールド、bのフィールド、cのフィールドから構成されている。
(A,B,a,b,cには具体的な名称が入ってました)
というような表現をしてありました。
非正規形は、ここでいう階層レコード型のようなものだな、とおもいました。

やや強引ですが、

「関係(Relation)」=「2次元表形式のデータの集まり」=「表」
「属性(Attribute)」=「項目」=「列」=「表の縦軸」
「組(Tapple)」=「行」=「表の横軸」

とすると、
繰り返し項目」とは「データの繰り返し構造をもつ列(属性)」でしょうか。

検索で引っかかったページ、http://www.scs.carleton.ca/~mengchi/3005/day.3
によると、

 atomic value =「内部構造のない値」
 ドメイン=「atomic value の集合(set)」
 ドメインの所有物(要素)は、複数の属性に属することができる。

となっています。

データベース技術 新版(専門分野シリーズ)」(ITEC)によると、
非正規形とは、

関係の属性の定義域が、その集合のなかにさらに集合を含んでいる場合がある。これを非単純定義域といい、関係が非単純定義域を含むとき、この関係を非正規形という。
(中略)
一方、属性の定義域の集合の中に集合を含まないものを単純定義域といい、次に述べる第1正規形以降の正規形はすべて単純定義域からなっている。

と、やや概念的ですが、わかりやすい解説がありました。
[PR]
by nwdb | 2004-11-01 08:29 | データベース
ボトムアップアプローチによるデータモデル作成では、はじめにデータ分析をおこない、そのうえで部分的なデータモデルを作成し、統合化していきます。ビューからデータ項目を抽出し、正規化をおこない、部分ER図を作成し、既存のデータモデルと統合、という作業をくりかえす、ということです。

■手順
1.ユーザービューの収集
2.データ項目の抽出とデータ(主キー、外部キー)の定義
3.ユーザビューごとにデータ正規化と部分図の作成を行う
4.データモデルの作成

■例
非正規形の帳簿(社員管理帳)をもとに、正規化を行います。

 社員(所属コード、所属名、社員コード、
      氏名、住所、資格コード、資格名)


繰り返し部分を分解し、第一正規化。
(埋め込んでフラットにしてもよい)
それに伴ない部分関数従属の発生。

 社員(所属コード、所属名、社員コード、氏名、住所)
 資格(社員コード、資格コード、資格名)

完全関数従属と部分関数従属の分解。
推移的関数従属が残る可能性があります。

 社員(所属コード、所属名、社員コード、氏名、住所)
 資格(資格コード、資格名)
 取得(社員コード資格コード

さて、これをもとに社員に関する部分のER図を作成します。
このER図をみると、

 [社員]→[取得]←[資格]

となっているのがわかります。
[PR]
by nwdb | 2004-10-25 14:12 | データベース
トップダウンアプローチによるデータモデルの作成手順は、はじめにエンティティの識別とエンティティ間の関連を明確にし、概念データモデル(ER図)を作成します。そのうえで、概念データモデルの各エンティティに対してデータを分析し、データモデルの詳細化をおこないます。

■例

1.社員のデータ項目の洗出し。
2.資格のデータ項目の洗出し。
3.社員の基本データ項目を社員コードと定義。
4.資格の基本データ項目を資格コードと定義。
5.エンティティ間の間連の識別。
6.社員と資格の関係は多対多。
7.連関エンティティを追加。
8.最後に正規化でチェック。

■手順

 社員(所属コード,所属名,社員コード,氏名)
 資格(資格コード,資格名)

社員と資格の関係は多対多
連関リレーションとして取得を追加。

 [社員]←取得→[資格]

 社員(所属コード,所属名,社員コード,氏名)
 資格(資格コード,資格名)
 取得(社員コード資格コード,取得日)

これを正規化でチェックしてみます。

社員の主キーは、所属コードと社員コードの複合キー。

 {所属コード,社員コード}→{所属名}
 {所属コード,社員コード}→{氏名}

これには、部分関数従属がある。

 {所属コード}→{所属名}
 {社員コード}→{氏名}

よってこれは第一正規形。

■参考

あるいは、ER図の段階で、
社員から所属を分離することを思いついたとする。
(ここでは部分関数従属は考えない。混乱の元)
社員と所属の関係は、
[所属]→[社員]
であり、一対多である。
そこで、[社員]に所属コードを外部キーとして与える。

 所属(所属コード,所属名)
 社員(所属コード,社員コード,氏名)
 資格(資格コード,資格名)

エンティティ間の間連の識別をします。
社員と資格の関係は多対多でした。
そこで連関リレーションとして取得を追加。

 [社員]←取得→[資格]

 所属(所属コード,所属名)
 社員(所属コード社員コード,氏名)
 資格(資格コード,資格名)
 取得(社員コード資格コード,取得日)

これを正規化でチェックします。

このように、ER図で作成したものを正規化でチェックするのがトップダウンアプローチ、と考えるとわかりやすいかとおもいます。

ERモデルを提案したP.P.チェンによると、適切に実体、関連を定義すれば、それによるERモデルは第3正規形になる、とのことです。
[PR]
by nwdb | 2004-10-25 13:53 | データベース