■□■━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
中小企業経営者のための
「サルでもわかる」やさしいIT・情報システム用語解説
第 6 号（2005/5/17）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━■□■
こんにちは、インフォバリューの福島です。
今回は、データベースの主流「RDB」についてです。
■今日の用語■■■■■■■■■■■■■■■■■■■■■■■■■■■■
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
▼RDB（Relational DataBase）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
□（>_<）小難しい定義 □□□□□□□□□□□□□□□□□□□□□□□
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1970年にIBM社のEdgar F. Codd氏によって提唱されたリレーショナルデータ
モデル理論基づくデータベース。数学の集合論に立脚している。１件のレコ
ードはフィールドの集合であり、レコードの集合が表を構成する。RDB内の
表は結合等の操作を行うことができ、その操作にはSQLが用いられる。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
□（^_^）やさしい解説 □□□□□□□□□□□□□□□□□□□□□□□
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
━━ 情報システムでは必須概念 ━━━━━━━━━━━━━━━━━━
RDBは、殆ど全ての企業の情報システムで使われているデータベースの形式
です。情報システムを構築する場合、避けては通れない概念です。
細かい技術は専門家に任せれば良いのですが、せめて概略だけでもおさえま
しょう。
身近なRDBとして、マイクロソフト社のACCESSがあります。機会がありまし
たら、軽く触ってみてください。
━━ 主キー ━━━━━━━━━━━━━━━━━━━━━━━━━━━
さて、RDBについてですが、これも、ゴチャゴチャ論ずるより、例を見てみ
ましょう。
顧客名 |都道府県|業種 |初回契約日|最新契約日
----------------+--------+--------+----------+----------
インフォバリュー|神奈川県|IT |2005/01/01|2005/01/01
ライブドア |東京都 |IT |2000/04/01|2004/12/04
フジテレビ |東京都 |マスコミ|1980/12/31|2005/02/14
ニッポン放送 |東京都 |マスコミ|1971/09/05|2005/04/20
前回にも用いた顧客リスト（少し短くしてます）です。
RDBでは、「レコード（→第５回）」を区別するために「主キー」と呼ばれ
る「フィールド（→第５回）」を設定します。
顧客コード|顧客名 |都道府県|業種 |初回契約日|最新契約日
----------+----------------+--------+--------+----------+----------
0000000001|インフォバリュー|神奈川県|IT |2005/01/01|2005/01/01
0000000002|ライブドア |東京都 |IT |2000/04/01|2004/12/04
0000000003|フジテレビ |東京都 |マスコミ|1980/12/31|2005/02/14
0000000004|ニッポン放送 |東京都 |マスコミ|1971/09/05|2005/04/20
「顧客コード」フィールドが主キーです。
主キーは、必ず一意（他のレコードと重複しない）である必要があります。
そうしないと、レコードの区別ができないからです。
例えば、同じ名前の顧客名があった場合、区別できなくなってしまいますね。
━━ 繰り返しの削除 ━━━━━━━━━━━━━━━━━━━━━━━
RDBでは、「冗長性」という無駄に長い繰り返しなどの部分をなくす必要が
あります。この作業のことを「正規化」といいます。
例えば、上の顧客リストでは「都道府県」「業種」などが同じものを繰り返
してますね。具体的には下記のように「正規化」します。
表：【顧客リスト】
顧客コード|顧客名 |都道府県ID|業種ID|初回契約日|最新契約日
----------+----------------+----------+------+----------+----------
0000000001|インフォバリュー|02 |0001 |2005/01/01|2005/01/01
0000000002|ライブドア |01 |0001 |2000/04/01|2004/12/04
0000000003|フジテレビ |01 |0002 |1980/12/31|2005/02/14
0000000004|ニッポン放送 |01 |0002 |1971/09/05|2005/04/20
表：【都道府県マスタ】
都道府県ID|都道府県名
----------+----------
01 |東京都
02 |神奈川県
表：【業種マスタ】
業種ID|業種名
------+--------
0001 |IT
0002 |マスコミ
このように「正規化」することによって、例えば、（ずいぶ んと現実離れ
した例ですが）「東京都」が名前を変更し、「大江戸都」と改名した場合、
都道府県が「東京都」である「ライブドア」「フジテレビ」「ニッポン放送」
のレコードを「大江戸都」に変更しなければならなかったのが、「都道府県
マスタ」の「01：東京都」を変更するだけでよくなりました。
「都道府県マスタ」「業種マスタ」の主キーはそれぞれ「都道府県ID」「業
種ID」です。「顧客リスト」には、それぞれの主キーを設定するように変更
し、表を複数に分けました。このように分けた表のことを「マスタ」と呼び
ます。
━━ 顧客リストも「マスタ」 ━━━━━━━━━━━━━━━━━━━
実は、「顧客リスト」のような表も、一般的には「マスタ」と呼ばれます。
では、顧客マスタを更に「正規化」していきましょう。
ついでに「顧客リスト」も「顧客マスタ」と名前を変えます。
※「都道府県マスタ」「業種マスタ」は省略
表：【顧客マスタ】
顧客コード|顧客名 |都道府県ID|業種ID
----------+----------------+----------+------
0000000001|インフォバリュー|02 |0001
0000000002|ライブドア |01 |0001
0000000003|フジテレビ |01 |0002
0000000004|ニッポン放送 |01 |0002
表：【受注データ】
受注伝票番号|顧客コード|受注日 |受注金額
------------|----------+----------+--------
000000000001|0000000001|2005/01/01| 20,000
000000000002|0000000002|2000/04/01| 30,000
000000000003|0000000002|2002/08/06| 40,000
000000000004|0000000002|2004/12/04| 20,000
000000000005|0000000003|1980/12/31| 100,000
000000000006|0000000003|2005/02/14| 300,000
000000000007|0000000004|1971/09/05| 10,000
000000000008|0000000004|1981/09/05| 20,000
000000000009|0000000004|1991/09/05| 40,000
000000000010|0000000004|2005/04/20| 80,000
上記のようになります。
「初回契約日」「最新契約日」がなくなってます。これらのフィールドは、
「受注データ」を見ればわかることですので、あえて、「顧客マスタ」に追
加する必要はありません。
そうしないと、新たな受注を行うたびに、「受注データ」にレコードを追加
すると同時に、「顧客マスタ」の「最新契約日」を更新しなければなりませ
ん。もし仮に、「顧客マスタ」の「最新契約日」の更新を忘れた場合、デー
タの不整合が生じてしまいます。
今回は、「顧客マスタ」から「受注データ」を新たに作りましたが、本来は
逆なのです。
表：【受注データ】
受注伝票番号|顧客名 |都道府県|業種 |受注日 |受注金額
------------|----------------+--------+--------+----------+--------
000000000001|インフォバリュー|神奈川県|IT |2005/01/01| 20,000
000000000002|ライブドア |東京都 |IT |2000/04/01| 30,000
000000000003|ライブドア |東京都 |IT |2002/08/06| 40,000
000000000004|ライブドア |東京都 |IT |2004/12/04| 20,000
000000000005|フジテレビ |東京都 |マスコミ|1980/12/31| 100,000
000000000006|フジテレビ |東京都 |マスコミ|2005/02/14| 300,000
000000000007|ニッポン放送 |東京都 |マスコミ|1971/09/05| 10,000
000000000008|ニッポン放送 |東京都 |マスコミ|1981/09/05| 20,000
000000000009|ニッポン放送 |東京都 |マスコミ|1991/09/05| 40,000
000000000010|ニッポン放送 |東京都 |マスコミ|2005/04/20| 80,000
元々は、受注データは上記のような形をしてます。
その受注データに対して、まず、顧客マスタを分離、更に、都道府県マスタ
と業種マスタを分離したという感じです。
━━ まとめ ━━━━━━━━━━━━━━━━━━━━━━━━━━━
以上のように、RDBでは、
表：【都道府県マスタ】
都道府県ID|都道府県名
----------+----------
01 |東京都
02 |神奈川県
表：【業種マスタ】
業種ID|業種名
------+--------
0001 |IT
0002 |マスコミ
表：【顧客マスタ】
顧客コード|顧客名 |都道府県ID|業種ID
----------+----------------+----------+------
0000000001|インフォバリュー|02 |0001
0000000002|ライブドア |01 |0001
0000000003|フジテレビ |01 |0002
0000000004|ニッポン放送 |01 |0002
表：【受注データ】
受注伝票番号|顧客コード|受注日 |受注金額
------------|----------+----------+--------
000000000001|0000000001|2005/01/01| 20,000
000000000002|0000000002|2000/04/01| 30,000
000000000003|0000000002|2002/08/06| 40,000
000000000004|0000000002|2004/12/04| 20,000
000000000005|0000000003|1980/12/31| 100,000
000000000006|0000000003|2005/02/14| 300,000
000000000007|0000000004|1971/09/05| 10,000
000000000008|0000000004|1981/09/05| 20,000
000000000009|0000000004|1991/09/05| 40,000
000000000010|0000000004|2005/04/20| 80,000
というように、複数の表に分けて管理します。
そして、これらの表からデータを取り出したり、更新したりする場合は、
SQL（※）というコマンドを用います。
（※）SQLについては、次回説明しますが、RDB関連に関連した用語がいっぱ
い出てきましたので以下にまとめておきます（そのために１号さくほどの用
語でもないので・・）。
フィールド：表内の列、つまり項目のこと。
レコード：表内の行、つまり１データのこと。
表：フィールドとレコードの集合。テーブルともいう。
主キー：表内でレコードを一意に識別するためのフィールド。
正規化：冗長性をなくし、データの不整合が発生しないようにする手続き。
マスタ：正規化し分離した表のこと。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■このメルマガは？■■■■■■■■■■■■■■■■■■■■■■■■■
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
このメルマガでは、中小企業経営者の方々を想定して、IT・情報システム用
語をやさしく解説いたします。また、新人情報システム担当者、新人システ
ム・エンジニア、新人コンサルタント、学生の方々もお読み頂けます。
中小企業経営者の方々にとって、情報化は大きな問題でしょう。
しかし、「IT」等と言っても、よくわからない・・・。SCM、CRM、DSS、EC、
EDI、ERP、TCP/IP、SMTP、POP3等と、アルファベットの組み合わせがいっぱ
い出てきてわけわからない・・・。本当は、企業のトップとして旗振り役で
なければならないのに、若い奴らに任せている。
そんな、中小企業経営者の方々のために「少しでもお役に立てたら」という
思いで発行してます。
本メルマガは、「小難しい定義」と「やさしい解説」の２部構成です。
「小難しい定義」は、どこにでもありそうな、いわゆる用語説明です。
一方、「やさしい解説」は、小難しい表現（IT用語）を一切使わない解説で
す。また、「やさしい解説」中でやむなく使用したIT用語については、別の
号で別途解説していきます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■編集後記■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
「RDB」はいかがでしたか？
ちょっと今回は、かなり踏み込んだ内容になってしまい、「サル」でもわか
らなかったかもしれません。
もし不明確な点がありましたら、遠慮なくご質問ください。
ところで、このメルマガのタイトルにもある「IT」という言葉ですが、メル
マガのタイトルにしているくせに、実は私、あまり好きじゃないのですよね。
何年前くらいからでしょうか、７，８年前くらいでしょうかね、この言葉が
突然使われるようになったのは。
「IT」というと、なんとなく「かっこよさげ」な感じがしますが、日本語に
すると、何のこともない「情報技術」です。
実際は、典型的な労働集約的な産業であり、もっとドロドロした産業なので
すが・・・。
例えば、「ITを導入することにより、ソリューションの提供を・・・」など
という宣伝文句をよく聞きますね？
何となくかっこよさげな（頭よさげな）言い回しですが、実は単に
「情報技術を導入することにより、解決策の提供を・・・」
と、なんとも抽象的なことを言っているだけなのです。
「日本語使えよ！！！」
と言ってしまいそうです。
日本では、高齢の方へのIT普及が大きな壁となってます（そんなこと言いな
がらここでも「IT」を使ってますが・・あぁ、矛盾・・）。
その大きな理由は、カタカナやアルファベットの略語が多く、理解できない、
ということが挙げられるかと思います。
ところが、中国では全て漢字で表現されているため、世代普及率に大きな差
がないという話を聞きました。
それが中国での近年のIT普及率の躍進の源泉なのかもしれません。
このメルマガの目的もそういったことにありまして、何とか簡単に説明でき
ないか、と考えたことが始まりです。
日本のIT普及率をどうのこうのと大それたことまで考えてませんが、「かっ
こよさげで、頭よさげな」カタカナやアルファベットの用語に対して、少し
でも抵抗感がなくなって頂ければ良いのですが・・。
では、また。
■□■━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
発行元：有限会社インフォバリュー
http://www.infovalue.co.jp/
発行者：代表取締役 福島雅規
melmaga@infovalue.co.jp
※ご意見、ご希望、ご相談等、お気軽にお寄せください
配信中止はこちら http://www.infovalue.co.jp/melmaga.htm
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━■□■
|
