最近、さまざまな所で、データベースが使われております。プログラミング言語処理においても、処理する対象が各種データであり、そのデータをデータ ベースから持ってくる場面が多いと思われます。但し、データベースを直接操作するのではなく、プログラミング言語のソースコードの中で、必要とされるデー タをロードし、必要な処理を施すような使い方が一般的であると思われます。
ここでは、コマンドラインにおけるデータベース操作に焦点を当ててすすめています。
とりわけ、sqlite はデータベース管理システムモジュールとして広く使われているので、手元のマシンで、いろいろいじってみてみることにしました。
リレーショナルデータベースとは
データベースとして使用されているものにはさまざまな種類のものがあります。sqlite はその中でも、リレーショナルデータベースシステム RDBMS( Relational Database Management System ) として、位置づけされております。
データベースというと、何か特別なものと考えてしまいますが、日常生活のそこかしこにつかわれております。家計簿は、品目ごとに、支出額、購入先が 記入されております。この品目、支出額、購入先が属性として、その属性に対して、お米、2500円、○×商店というのが値として記入されています。この属 性と値の累積がデータベースのテーブルとなります。また、購入先も購入先名、購入先℡番号などの属性に対して、もう一つのテーブルを構成するものといえます。そ して、二つのテーブルが購入先名という共通の属性によって、結び付けられることを、関係性をもつということとしてとらえられることができます。
尚、属性は「フィールドキー」「カラム」「列」、値は「レコード」「ロー」「行」、この2つの組み合わせで格納されたものを「テーブル」と呼ばれております。
データは表に似た構造で管理されるが、関係（リレーション）と呼ぶ概念でモデル化される。関係（リレーション）は組（タプル、表における行に相当する）、属性（アトリビュート、表における列に相当する）、定義域（ドメイン）、候補キー（主キー）、外部キーなどによって構成される。SQLなどに代表されるデータベース言語（問い合わせ言語）を用いて、関係に対して制限・射影・結合・和・差・交わりなどの関係代数演算（集合演算を含む）ないし関係論理演算を行うことで結果を取り出す。
WikiPedia
主キーと外部キーをもち、テーブルとして、グループ化されている。
データベースはデータを行と列からなる、2次元のテーブルとして表現しております。テーブルのデータを特定するものとして、主キー （primary_key）と、他のテーブルとの関連付けとなる外部キー(foreign key)、フィールドキーが必要となります。（ 但し、外部キー、主キーは必須ではない。）
主キーとは
- レコードを特定できる、一個、または複数個のキーの組み合わせになる。
- データが必ず存在する（NULではない）。
- 「候補キー」と呼ばれている、一意（ユニーク）である。
外部キーとは
- 他表を参照するキーである。
- 参照される側の表では主キーになっている
- 各表のレコードの追加・削除による、整合性を保つ必要がある。
- 一つの表に複数の外部キーが存在することもありえる。
データが正規化されている
- テーブル内に同じレコードの繰り返しがないように冗長性を排除し、保守効率を高めている。
- 各テーブル間が関係性を持つキーでつながっており、参照一貫性と整合性を保証している。
データの正規化
上記は架空のお買い上げ伝票です。このような伝票は日常生活において、普通に存在するので、正規化の題材として取り上げてみました。
データベースとしてシステム化するには、利用する主体によって取り上げる属性（フィールド）が異なることに留意する必要があります。お買い上げ当事者が家計簿として管理したい場合は、商品コードではなく独自のカテゴリー化がされることでしょう。家計簿としては、注文番号やお買い上げ氏名は必要とは しないことになります。
ここでは、商品を販売する側、つまりは、伝票発行者の立場から考えてみたいと思います。
正規化の方法
データをテーブルとしてまとめるために、ある属性の値が決まると他の値の属性の値が決まる（関数従属）となる項目に着目し、複数の関連する最小の属性の集合体としたテーブルに細分化し、重複を排除して、管理しやすくします。
一般的には、以下の3段階でデータの正規化を進めていくようです。
非正規形
- 注文番号
- 購入者名（お買い上げ氏名）
- 発行日
- 商品コード （繰り返し項目）
- 商品名（繰り返し項目）
- 数量（繰り返し項目）
- 単価（繰り返し項目）
- 購入金額（お買い上げ金額）
- 社名（固定情報）
- 店名
- 本部℡番号・所在地（固定情報）
必要とする属性をすべて洗い出した状態である。上記の伝票においては、一つのお買い上げ明細票にたいして、表として印字されている箇所がテーブルとしてまとめると、上記の繰り返し項目のように、フィールドの重複が存在してしまうことになります。
第一正規形
注文
- 注文番号（主キー）
- 購入者名
- 発行日
- 購入金額
- 店名
注文明細
- 注文番号（主キー）（外部キー）
- 商品コード（主キー）
- 商品名
- 数量
- 単価
繰り返しの属性を分離します。外部キーとして、注文の主キーである注文番号をもたせ、注文番号と商品コードを組み合わせたものがそのテーブルのレコードを特定する主キーとします。固定属性はテーブルに含めません。
第2正規形
注文
- 注文番号（主キー）
- 購入者名
- 発行日
- 購入金額
- 店名
商品
- 商品コード（主キー）
- 商品名
注文明細
- 注文番号（主キー）（外部キー）
- 商品コード（主キー）（外部キー）
- 数量
- 単価
第一正規形 注文明細主キーである商品コードから同じテーブル内の商品名を導くことが出来ますので、分割できます。新たに、商品テーブルを定義しています。これは、主キーまたは主キーの一部に従属する属性を分離した状態です。
第3正規形
注文 Orders
- 注文番号（主キー）
- 購入者コード（外部キー）
- 発行日
- 購入金額
- 店コード（外部キー）
購入者 Buyer
- 購入者コード（主キー）
- 購入者名
店 Branch
- 店コード（主キー）
- 店名
商品 Goods
- 商品コード（主キー）
- 商品名
注文明細 Details
- 注文番号（主キー）（外部キー）
- 商品コード（主キー）（外部キー）
- 数量
- 単価
注文テーブルでは主キーではない購入者コード・店コードがお買い上げ明細票では記載していない購入者名・店名として導くことが出来、分離することが出来ます。これは、主キーではない属性を分離した状態です。
正規化を進める判断
前段で示した、データベースとしての冗長性、一貫性、整合性を保つ為には、テーブル作成は、この3段階の正規化を行う必要があります。但し、必要な データを析出する際に、テーブル同士を結合する処理がありますので、実行コストがかかります。重複を無くす第一正規形までは、必須であると思われますが、 データベースとしてはここまでで止めておき、ロードされたデータをアプリケーション内で、処理するほうが扱いやすい事もあります。
E-R図によるデータのモデル化
データをテーブルとしてまとめ、リレーショナルデータベースとして構築することを、データのモデル化ということができます。データのモデル化を可視 化する分析手法として、E-R図というものがあります。E-R図とは、テーブル一つ一つを Entity(実体)、テーブル同士の関係性を Relationship(関連)として図として表現したものです。
図中の矢印はエンティティの依存関係を示しております。注文テーブルは購入者テーブルと店テーブルを参照しています。一つの注文テーブルには購入 者・店それぞれ一つのレコードを参照しています。一つの購入者テーブルでは、複数の注文テーブルから参照される関係にあります。同じように、一つの注文 テーブルでは複数の注文明細テーブルから参照されています。このように、リレーショナルデータベースでは、必ず1対多、1対1の関係になる必要がありま す。
