LoginSignup
1
3

More than 1 year has passed since last update.

基本情報技術者試験 データベース編①

Last updated at Posted at 2021-07-13

初めに

この教本を参考に、備忘録として書いていきます。

キタミ式イラストIT塾 基本情報技術者 令和03年 | Amazon

◯データベースとDBMS

データベース(以下、DB)は様々なデータを保存したり、蓄積したり
そこから情報を取得したりと多くのデータを扱う為には欠かせないものです。

例えば、企業だと「顧客情報」や「社員情報」、「製品情報」など
色んな大量のデータを扱わないといけません。

バラバラに管理していれば、整合性が保てないのでまとめて管理しています。

特に、複数の利用者が大量のデータを共同利用する際に強力です。

DBにはいくつか種類があり、中でも関係型と呼ばれるDBが主流となっています。

・表、行、列で出来ている

関係DBは、表の形でデータを管理します。
スクリーンショット 2021-07-13 19.15.36.png
「表」なのでエクセルなんかを思い浮かびますが
そもそもの役割が違うので全くの別物です。

・DB:
データを貯め込むことが主な目的

・エクセル(表計算):
表を作ることが主な目的

タイトルにもあるようにで関係DBは構成されており、
データ1件が1つの行として記録され、追加・削除・更新も行単位で行われます。

この行が複数集まることにより、表の形が出来上がっていくイメージです。

先ほどの表で確認してみましょう。

表(テーブル)
複数のデータ(行)を収容する場所のこと。
スクリーンショット 2021-07-13 19.15.36.png
行(レコード、組、タプル)
1件分のデータのこと。
スクリーンショット 2021-07-13 19.15.42.png
列(フィールド、属性)
データを構成する各項目のこと。
スクリーンショット 2021-07-13 19.15.46.png
なんで「関係」なのかというとデータの内容次第で
複数の表を関係付けして扱うことができるからです。

この「関係」のことをリレーションシップと呼び
関係DBは、リレーショナルデータベース(RDB)と呼ばれます。

・DBMS(データベース管理システム)

DBの管理を効率化するDBMSというソフトウェアがあります。

これはユーザーに代わって、DBの整理やデータの検索、更新、共有などを行ってくれます。
手動で行うようりも、データ管理の手間が大幅に削減できます。

実際にDBを操作する際には、SQL言語を使用して操作していきます。

この言語については次の記事で書きます。

主な製品として

MySQL
Oracle Database
SQLSever

などがあります。

・主キー

例えば、「松本潤」さんが退職することになったとします。
そうなった場合、DB上にある社員情報を更新しなければいけません。

しかし、営業部と開発部に「松本潤」さんがいました。

こうなった場合、どの部署の「松本潤」さんかを特定する作業が発生してしまいます。

これを回避するためにDBの表には、その中のひとつひとつを識別できるようにキーとなる情報が含まれています。

これを主キーと呼びます。

現実世界で例えると、マイナンバーや社員番号などがまさにそれです。

・主キーは行を特定する

表の中で各行を識別するために使う列のことを主キーと呼びます。

先ほどの表だと、
スクリーンショット 2021-07-13 19.15.36.png
「社員番号」が主キーに適しています。
スクリーンショット 2021-07-13 19.15.48.png
主キーにできる条件として

表の中で内容が重複しないこと
内容が空ではないこと

の2点です。

・複合キー

ちなみに、ひとつの列では重複するけど、複数の列を組み合わせれば重複しないという場合があります。

例えば、以下の表があったとして
スクリーンショット 2021-07-13 19.28.12.png
この表から出席番号1番の人を取り出すと
「田中」さん、もしくは「佐藤」さんが該当してしまいます。

では、「出席番号 + 性別」だったらどうでしょうか?

出席番号1番の人で男性を取り出せば、「田中」さんしか該当しません。

このように「出席番号 + 性別」といった複数の列をワンセットとして
主キーとするのを複合キーと呼びます。

◯正規化

関係DBでは、蓄積されているデータに矛盾重複が生じないように
表を最適化するのがお約束となっています。

これを正規化と呼びます。

DBで管理する表の設計を行なっていく上で欠かす事ができません。

ちなみに正規化されていない表を非正規形と呼びます。

・非正規形

例えば、以下のような表があったとします。
スクリーンショット 2021-07-13 12.58.19.png

行の長さがバラバラで見にくいですね。
このような表が非正規形です。

関係DBではこのような表を管理することはできず、整える必要がある訳です。

・第1正規形

まず、非正規形から第1正規形にしないといけません。

素直な二次元の表にするため以下のように、切り離します。
スクリーンショット 2021-07-13 12.58.30.png

そして、独立した行を挿入してやることで
素直な二次元の表が出来上がります。
スクリーンショット 2021-07-13 12.57.51.png

・第2正規形

次に第1正規形から第2正規形にしていきます。

というわけで以下のようになります。

・受注表
スクリーンショット 2021-07-13 12.55.16.png

・商品表
スクリーンショット 2021-07-13 12.55.55.png

・明細表
スクリーンショット 2021-07-13 12.55.53.png

何故このように分離できるのかというと関数従属部分関数従属というのが関わってくるからです。

・関数従属と部分関数従属

これらは表の中における列と列との関係を表したもので
主キー(複合キー)に対して、その項目がどんな関係にあるかを表現しています。

○関数従属

以下は先ほど分離した表です。
スクリーンショット 2021-07-13 12.55.55.png
「商品コード」が決まれば「商品名」や「単価」も決まっていきます。
このように主キーが決まれば、列の値も決まる関係を関数従属と呼びます。

例えば、「商品名」は「商品コード」に関数従属していると使われます。

○部分関数従属

行の特定は主キー(または複合キー)で行うわけですが、以下の表のように
スクリーンショット 2021-07-13 12.57.51.png
複合キー(受注No + 商品コード)の一部の項目だけで列の値が決まる関係があります。

先ほど分離した以下の表です。

・受注表
スクリーンショット 2021-07-13 12.55.16.png
・商品表
スクリーンショット 2021-07-13 12.55.55.png
「受注No」が決まれば、「受注日時」、「顧客コード」、「顧客名称」が決まります。
そして、「商品コード」が決まれば、「商品名」、「単価」が決まります。

このような関係を部分関数従属と呼びます。

そして、最後に以下の表が出来て、計3つの表に分離できました。

・明細表
スクリーンショット 2021-07-13 12.55.53.png
これが第2正規形になります。

・第3正規形

最後に第2正規形から第3正規形にしていきます。
主キー以外の列に関数従属している列を切り出したものが第3正規形となります。

以下の表が切り出せそうですね。

・受注表
スクリーンショット 2021-07-13 12.55.16.png
「顧客名称」は主キーの「受注No」ではなく
「顧客コード」を主キーとして決定されそうです。

というわけで、以下のように分離できます。

・受注表
スクリーンショット 2021-07-13 14.30.24.png
・顧客表
スクリーンショット 2021-07-13 14.24.04.png

第3正規形で重要なのは更に分離できそうな所を分離するということです。

ちなみに、主キー以外の列に関数従属している列のことを
推移的関数従属と呼びます。

ここでは「顧客名称」がそうですね。

これで計4つの表が出来ました。

・受注表
スクリーンショット 2021-07-13 14.30.24.png
・顧客表
スクリーンショット 2021-07-13 14.24.04.png
・商品表
スクリーンショット 2021-07-13 12.55.55.png
・明細表
スクリーンショット 2021-07-13 12.55.53.png
このように正規化することによって効率的に管理できる表の構造となります。

おわりに

とりあえず、今回はここまでです。

次の記事ではSQLについて記事を書いています。

1
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
3