数据库基础 日语版

データベース基礎•（1）データを整理・統合して格納し、•（2）そのデータを検索・活用・管理しやすくした（コンピュータ上に構築された）仕組み•（3）特定のプログラムに依存しないこと（プログラムと独立したデータ・ファイルであること）•（4）データの格納形式が公開されていること（任意のプログラムから読み書きできること）•（5）容易にデータを操作できること（登録，読み出し，更新，削除，など）データベースの構造やデータの格納形式のことをスキーマ（schema）と呼ぶ.数据库Schema有两种含义，一种是概念上的Schema，指的是一组DDL语句集，该语句集完整地描述了数据库的结构。

还有一种是物理上的Schema，指的是数据库中的一个名字空间，它包含一组表、视图和存储过程等命名对象。

物理Schema可以通过标准SQL语句来创建、更新和修改。

データベース・エンジンの役割データをカンマで区切って格納する形式のデータ・ファイルのことを，CSV（Comma Separated Value）ファイルと呼びます。

CSVファイルは単純で取り扱いやすいので，異なるOSや異なるプログラムの間でデータを交換する際によく使われます。

CSVファイルなら，皆さんがオリジナルのプログラムを作成して，データを読み書きすることも容易でしょう。

ところが，実際のデータ・ファイルには，マイクロソフトのデータベース・ソフトであるAccessで使われているMDBファイルのように，データ・ファイルの構造が公開されていないものも多くあります。

この理由は(1)データ・ファイルの構造が企業秘密であるから，(2)たとえ構造を公開したとしても，複雑すぎるために取り扱いが困難だから，です。

そこで，市販のデータベース管理システム（マイクロソフトのAccess，Microsoft SQL Server，及びオラクルのOracleなど）では，データ・ファイルを読み書きするための専用のプログラムを提供しているのが一般的です。

このようなプログラムのことをデータベース・エンジンと呼びます。

エンジンとは，特定の機能に特化されたプログラムのことです。

特定のデータ・ファイルを読み書きする機能だけを持っているので，データベース・エンジンと呼ばれます。

データ・ファイルの構造は非公開であっても，データベースエンジンを操作する方法は公開されています。

したがって，データベース・エンジンを仲介させれば，さまざまなプログラムから目的のデータ・ファイルを読み書きすることができます（図2）。

デーデータベース・エンジンを仲介させて，データ・ファイルを読み書きする例えば，先ほど出てきたMDBファイルを読み書きするために，マイクロソフトはMicrosoft Jet Database Engine（単にJetとも呼ぶ）というデータベース・エンジンを提供しています。

皆さんがプログラミング・ツールのVisual Basicなどを使って作成したプログラムからMDBファイルを読み書きするためには，Jetを仲介させることになります。

そのほかのデータベース管理システムでも，ベンダーがそれぞれ専用のデータベース・エンジンを提供しています。

データベース・エンジンは，主にデータベースを作成，読み出し，更新，および削除する機能を提供します。

これらの4機能は，データベースの基本的な操作であり，Create（作成），Read（読み出し），Update（更新），Delete（削除）の頭文字を組み合わせてCRUD（クラッド）と呼びます。

データベースの実体は，フロッピ・ディスクやハード・ディスクに記録されたデータ・ファイルですが，データベースの構造を示すときには，テーブル（表）を使うことが一般的です。

物理的なデータ・ファイルの構造など気にしないで，論理的にはテーブルすなわち表形式でデータが格納されていると考えるのです。

どのような種類のデータベースであっても，その構造は，テーブルを使って統一的に表すことができます。

データベースを読み書きするプログラムでも，表形式のユーザー・インタフェースを提供するものが多くあります。

図3は，Microsoft Accessの画面の一部です。

表形式でデータが入力できるようになっているのが分かるでしょう。

図3●テーブル（表）は，フィールド（列）とレコード（行）で構成されるここで，重要な用語を2つ覚えてください。

テーブルを構成する列をフィールドと呼び，行をレコードと呼ぶ，ということです。

フィールドとは，レコードを構成する個々のデータを切り分ける単位です。

図3のテーブルには「氏名」と「電話番号」という2つのフィールドがあることになります。

レコードとは，関連するデータの集まりです。

ここでは「氏名」と「電話番号」の2つのフィールドが集まって1件のレコードとなっています。

レコードは，1つ，2つ，…ではなく，1件，2件，…と数えます。

図3のテーブルには3件のレコードがあることになります。

1つのデータ・ファイルの中には，テーブルが1つだけある場合も，テーブルが複数ある場合もあります。

さらに，複数のテーブルを含んだ複数のデータ・ファイルが集まって，1つのデータベースとなる場合もあります。

いずれにしても，データベースを物理的なデータ・ファイルの集合ではなく，論理的なテーブルの集合として考えることが重要です。

例えば，データベースの設計では，テーブルの内容と構成を設計することになります。

皆さんも，データベース・エンジニアが，複数のテーブルを組み合わせたような設計図（ER図などと呼ばれます）と格闘（？）しているところを見たことがあるでしょう。

今回は，データベースの設計を行いながら，リレーショナル・データベースの基礎をマスターしましょう。

データベースの設計には，掟（おきて）と呼べるほど確立された考え方がいくつかあります。

データベースは，複数のテーブル（表）の集合体として設計されます。

個々のテーブルは，ほかのテーブルと関連性（リレーション）を持つものとなります。

このような構造のデータベースのことをリレーショナル・データベース（RDB：Relational DataBase）と呼びます。

データベースの構造には，リレーショナル・データベースのほかに，カード型データベースと呼ばれるものもあります。

カード型データベースは，名刺のように1件のレコードを1枚のカードにまとめて記録するものです。

これは，ワープロの1ページに任意の情報を書き込んで，それを1枚のカードにするようなものです。

以下に，カード型データベースと，リレーショナルデータベースのイメージを示しておきます（図1）。

図1●カード型データベースとリレーショナル・データベースのイメージ現在では「データベースとは，リレーショナル・データベースのことである」と考えて間違いありません。

カード型データベースはめったに使われないからです。

なぜなら，リレーショナル・データベースの方が，カード型データベースよりさまざまな面で優れているからです。

市販のデータベース管理システムのほとんどは，リレーショナル・データベースを採用しています。

この講座でも，リレーショナル・データベースだけを取り上げます。

では，簡単なリレーショナル・データベースの設計を行ってみましょう。

●データの洗い出しと属性の決定データベースの設計は，必要とされるデータをすべて洗い出すことから始まります。

ここでは，電話帳のデータベースを作成することを想定して，必要なデータを洗い出してみましょう。

「氏名」「電話番号」「FAX番号」「会社名」「郵便番号」「住所」「E-mail」…などと，考えればきりがありませんね。

ただし，欲張るのは禁物です。

実際には必要とされないデータをデータベースに加えてしまうと，あとで管理が面倒になるからです。

本当に必要とされるデータなのかどうか，よく考えることが大切です。

ここでは，シンプルに「氏名」「電話番号」「会社名」の三つのデータだけにしましょう。

これらは，テーブルのフィールド（テーブルを構成する列のこと）となります。

テーブルの名前は，「電話帳テーブル」としておきましょう（図2）。

図2●電話帳テーブルの作成次に，個々のフィールドの属性を決定します。

これは，格納するデータが文字なら文字数を決定し，格納するデータが数値なら値の範囲を決定する作業です。

この作業は，慎重に行ってください。

テーブルにレコード（テーブルを構成する行のこと）を登録してしまった後は，フィールドの属性を変更できないからです。

ここでは，以下のようにフィールドの属性を決定しました。

電話番号をハイフンを含んで13文字にしたのは，携帯電話では111-2222-3333のように「11桁＋ハイフン二つ＝13文字」となるからです。

すべてのフィールドに対して，このような注意が必要です（図3）。

図3●フィールドの属性を決定する電話帳テーブルにレコードを登録してみましょう。

図4のように，3件のレコードを登録しました。

電話帳テーブルをよく見てください。

「日経BP社」という同じ会社名のフィールドを持つレコードが2件ありますね。

実は，これが大問題なのです。

図4●同じ値のフィールドを持つレコードが2件ある同じ値を持つフィールドを複数のレコードに登録できてしまうことは，次のような問題を引き起こすからです。

(1)同じ会社名を何度も登録することになり，面倒である(2)たとえば「（株）ヤザワ」と「株式会社ヤザワ」が，異なる会社名であるとみなされる(3)会社名が変更されたら，関係するレコードすべてに修正が必要となるこれらの問題を解決するためには，電話帳テーブルを二つのテーブルに分割し，個々のテーブルのフィールドが，同じ値にならないようにします。

これをテーブルの正規化と呼びます。

正規化とは「同じものをまとめる」という意味だと考えてください。

電話帳テーブルを「氏名」と「電話番号」のフィールドを持った個人情報テーブルと，「会社名」のフィールドだけを持った会社情報テーブルに分割してみましょう。

これによって，同じ値を持つフィールドを複数のレコードに登録できてしまうことが防げます。

こうすると，「日経BP社」というフィールドが一つだけになります（図5）。

図5●電話帳テーブルを２つに分割する●テーブル間の関連性の設定テーブルを分割したら，テーブル間の関連性（リレーション）を設定しなければなりません。

これは，たとえば「井上太郎」が「日経BP社」に勤務していることを特定できるようにすることです。

そのためには，2つのテーブルを関連付けるための新たなフィールドが必要となります。