データベースの基礎

ファイルの構造

ファイルに持つべき項目

簡単な例（例題１）により，ファイルに入れるべき内容を検討します。

売上伝票と請求書

当社では，売上が発生するたびに売上伝票が起票して，コンピュータに入力され，売上ファイルとして蓄積されます。毎月末になると，売上ファイルから請求書を出力して得意先に請求します。このときの売上ファイルのデザインを設計することを例にします。

1. まず最初に，請求書に印刷されている事項を，すべての請求書に共通な部分（コダマ電器あての請求書でもリラックスあての請求書でも同じ部分）と，個々の請求書で異なる部分（コダマ電器の××年１０月分の請求書に特有な部分）に区分します。
• 請求書の「請求書」，「下記の通り～」，「商品名」などの文字や罫線は，すべての請求書に共通な部分である。これらは，事前に用紙に印刷しておくことができます（プログラムでフォームを作ることもできます）。それで，これらは売上ファイルのデータとして持つ必要はありません。
• それに対して，「コダマ電器」などの得意先名，「目立テレビ」などの商品名，数量，単価などは，個々の請求書によって異なる部分ですから，売上ファイルのデータとして持っておき，それをプログラムで読んで請求書に出力する必要があります。
2. ファイルに入れておかなければならない項目と，それらの項目から計算できる項目を分離します（後者はファイルに入れません）。
• 金額は，数量と単価から計算できますし。合計金額は，個々の金額を集計できます。このように，他のデータからプログラムで計算できるものは，それをデータには入れません。
• 請求書の日付や「ただし○○分」の日付は，これ自体は出力処理時にオペレータがプログラムに指示するものであり，もし売上ファイルが当月分のデータしか持たないのであれば不要だといえます。しかし，用途によっては月をまたがって持つ場合もあるし，伝票発行の日付が必要になることもあるので，ここでは年月日もデータとして持つことにします。

これらの結果，年月日，得意先コード，得意先名，商品コード，商品名，商品区分コード，商品区分名，数量，単価の項目を売上ファイルとして持つことになります。それをここでは次のように表記します。

　　　売上ファイル＝
                 ＋得意先コード＋得意先名
                 ＋商品コード＋商品名
                 ＋商品区分コード＋商品区分名
                 ＋数量＋単価

項目，レコード，ファイル

売上ファイルのデザインは下表のようになります。

項目

年月日や商品コードなど，縦に並んでいるものを項目といいます。そして「年月日」や「商品コード」などの項目の名称を項目名といいます。

レコード

１組の全項目を並べた１件のデータのことをレコードといいます。よく「〇〇件のデータがある」というのは「レコード数が〇〇である」ことになります。

ファイル

同じデザインのレコードを集めたものをファイルといいます。すなわち，ここでの売上ファイルは同じ項目を持つ売上レコードを集めたものです。

これらは，いろいろな用語で呼ばれています。

　一般的用語として　　ファイル　レコード　項目
　ＲＤＢでの用語）　　表　　　　行　　　　列
　その他　　　　　　　テーブル　レコード　フィールド，属性

初級シスアド等の過去問題→データベース一般

ファイルの持ち方

データの正規化

実際には，売上ファイルを単一のファイルとして持つのでなく，得意先マスタファイル，商品マスタファイル，商品区分マスタファイルそして売上ファイルのように分解して持つのです。

このように分解することを正規化といいます。正規化することにより，多くの利点があります。

多用途での利用

マスタファイルはいわば台帳です。得意先マスタや商品マスタは，販売システムだけでなく，会計システムや購買システムでも利用できます。

管理の容易性

多様なシステムがあっても，得意先に関係する項目は得意先マスタファイル１ヶ所に集中しているので，追加や変更が容易にできます。

データ容量の削減

「コダマ電器」などの得意先名，「目立テレビ」のような商品名が何度もデータに持つことがなくなり，全体としてデータの容量が少なくなります。

正規化は，一般的には第３正規化まで行います。

第１正規化

第１正規化とは，繰り返しの部分を複数のレコードにして，繰り返しを排除する操作です。

第２正規化

第２正規化とは，部分関数従属する項目を分離することです（説明省略）。例えば，得意先コードが決まれば得意先名が決まるので，得意先コードと得意先名で一つのファイルとします。同様にして，次の３つのファイルになります。
　　　　得意先マスタファイル＝得意先コード＋得意先名
　　　　商品マスタファイル＝商品コード＋商品名＋商品区分コード＋商品区分名＋単価
　　　　売上ファイル＝年月日＋得意先コード＋商品コード＋数量

第３正規化

第３正規化は，主キー以外のキーに関数従属する項目を分離します。商品マスタでは，主キー以外のキーとは商品区分コードであり，商品区分コードが決まれば商品区分名が決まるので，
　　　　商品区分マスタファイル＝商品区分コード＋商品区分名
　　　　商品マスタファイル＝商品コード＋商品名＋商品区分コード＋単価
の２ファイルになります。

主キーとは，ユニークキーともいいます。得意先マスタファイルの得意先コードのように，その項目が決まれば他の項目が決まる項目のことです。マスタファイルは主キーを持ち，主キーが同じ値を持つレコードは存在しないことになります。
　商品と得意先により販売単価が決まるというような場合には，商品コード＋得意先コード（このように複数の項目をあわせたものを複合項目といいます）が主キーになることもあります。

初級シスアド等の過去問題→データの正規化

Ｅ－Ｒ図

エンティティ(Entity)とは，システム化対象業務において管理すべき実体で，「得意先」「商品」「商品区分」「売上」などです。リレーションシップ(Relationship)とは，エンティティ間の関連のことです。そしてエンティティとリレーションシップを図式化したものをＥ－Ｒ図といいます。

エンティティ商品とエンティティ商品区分の間には，商品が商品区分に「属する」というリレーションシップがあります。エンティティは長方形，リレーションシップはひし形で表示します（リレーションシップのひし形を省略して矢印をつけた矢線で表示する図法もあります）。そして，「すべての商品は，それぞれ唯一の商品区分に属する」し，「すべての商品区分は，いくつかの商品を持つ」という関連を，１：Ｎの対応といいます。また，１のほうを親，Ｎのほうを子として，親子の関連があるということもあります。

対応は１：Ｎ以外にも，部と部長のような１；１，所属と資格のようなＭ：Ｎの対応もあります。なお，Ｎではなく＊で表示することもあります。

初級シスアド等の過去問題→ＥＲＤ

発展

正規化やＥ－Ｒ図の詳しい説明は，本シリーズの「データの正規化（db-seikika）」，「Ｅ－Ｒ図（db-ermodel）」を参照してください。

データベース

データベースの種類

データベースとは，データの持ち方であり，それを管理する仕組みです。それをＤＢＭＳ（データベース管理システム）といいます。

ＲＤＢ以前

現在は，一般的な用途では後述のＲＤＢが主流になっていますが，それまでに次のＤＢＭＳがありました。これらは，現在では特定の用途以外には使われていません。

階層型データモデル

木構造データベースともいいます。すべて親子関係になっています。階層の上位から下位に節点をたどることによって，データを取り出すことができる構造です。

網型データモデル

ＮＤＢ（ネットワークＤＢ）ともいいます。図のように親になるものが複数ある場合です。

関係モデル

ＲＤＢ（リレーショナルＤＢ）ともいいます。現在，一般的な用途ではほとんどがこのデータベースになっています。正規化されたファイルを，例えば売上ファイルと得意先マスタファイルを得意先コードで関係づけるようにして用います。
ＲＤＢを作成したり，ＲＤＢを加工する言語にＳＱＬがあります。初級シスアド試験では重視されている言語で，このシリーズ全体で詳述しますので，ここでは省略します。

最近の動向

最近は，次のＤＢＭＳが注目されています。

オブジェクト指向データベース

オブジェクト指向によるデータベースで，ＲＤＢよりも複雑な関係を取扱えます。現行のＲＤＢもこの機能を取り込むようになってきました，

多次元データベース

検索加工を主とする分野であるデータウェアハウスなどの分野に特化したデータベースです。

機密保護

データベースに蓄えられているデータのなかには，特定の人以外には秘密にするべきデータもあります。通常のファイルでもファイル単位にユーザＩＤやパスワードにより，
　　　読み書き両方ができる
　　　読むことはできるが書くこと（更新）はできない
　　　読み書き両方ともできない
に分けてアクセス制御することができます。 　さらにデータベースでは，ＤＢＭＳが独自に
　　　列（項目）単位，行（レコード）単位でのアクセス制御できる
　　　アクセス資格を多様なグループ分けにして指定できる
など，きめの細かい機密保護ができるようになっています。
過去問題：「ファイルへのアクセス管理」（ file-access-kanri）

インデクス

データベースでは，ファイルとファイルをキーにより結びつけたり，大量のレコードから条件に合致したレコードを取り出す処理が多く発生します。
　それを効率的に行うためには，図書の巻末にある索引のような機能が求められます。それをインデクスといいます。

排他制御

たとえば販売システムでは，売上データは各支店で発生するので，多数の人が同じデータベースである売上ファイルを更新することが発生します。このように複数のジョブで同時にデータベースを更新することを同時更新といい，その更新命令をトランザクションといいます。あるトランザクションが更新処理をしている間に他のトランザクションが発生すると，次のような問題が発生します。

在庫テーブルのある商品の在庫が２００個であった。１００個の入荷をＡが入力し，それに続いて１００個の出荷をＢが入力したとする。正しい在庫は，２００＋１００－１００＝２００個になるはずですが，処理のタイミングにより，２や３のように誤った結果になる危険があります。

1. Ａが入荷データを入れて在庫が３００になった後にＢが出荷データを入力したのであれば，在庫は２００個になり正しく処理される。
2. Ａの処理が完了しない内にＢが入力されると，このときＢは在庫が２００だと認識している。そのため，Ａの処理が完了して在庫が３００になっても，Ｂの処理では２００－１００＝１００としてしまう。
3. 逆に，Ａの処理が完了しない内にＢの処理が完了すると，在庫はＢにより１００となったのが，Ａにより３００になってしまう。

ＤＢＭＳでは，このようなトラブルを回避するために排他制御の機能を持っています。上図（４）のように，一方（ここではＡ）が旧データをつかんだ瞬間に旧データに「ロック」をかけて，Ａが処理している間にＢの入力があったときは，ロックが解除するまで待たせ，Ａの処理が完了したときにロックを解除して，Ｂの処理を開始します。このようにして，データを正しく管理することをインテグリティ（一貫性）の保持といいます。

ここまでは，同時更新だけを取り上げましたが，データの照会をしているときでも途中で更新されると不都合が生じる場合があります。それで，占有ロックと共有ロックに区分されます。

　　　　　　　　　　　他の処理での　　　　他の処理からのロック
　　　　　　　　　更新・削除　　照会　　　占有ロック　共有ロック
　　　占有ロック　　　禁止　　　禁止　　　　禁止　　　　禁止
　　　共有ロック　　　禁止　　　許可　　　　禁止　　　　許可

初級シスアド等の過去問題→排他制御

バックアップとリカバリー

障害回復（リカバリ）

万一のトラブルによりデータの整合性を失ったとき，データベースを正しく回復する機能が必要になります。それには，バックアップとリカバリーを行います。

定期的に（それをチェックポイントといいます）に，データベース全体をバックアップファイルにコピーします。その間は，更新が行われるたびに，更新前と更新後の情報をジャーナルファイルに記録しておきます。

トラブルが発生したときには，リカバリー（回復）処理をします。それには，ロールフォワードとロールバックがあります。

ロールフォワード

データベースに障害が発生したときの対応です。バックアップファイルからデータベースを復元して，ジャーナルファイルにより更新を行い，障害直前の状態にまで回復します。リカバリーの順序が更新と同じ順序で行われます。

ロールバック

更新中に障害が発生したときの対応です。図では，状態２は正常に完了し，状態３になるときに障害が発生したことを示しています。このときは，ジャーナルファイルに状態２と状態３の違いが残っているので，それを用いて状態２にまで戻します。リカバリーの順序は更新の順と逆になります。

過去問題：「バックアップとリカバリ」（ backup-recovery）