（朝の5時前まで起きてサンタを張ってたから来なかったのかなぁ・・）
あ・・、何でもないです。
続きまして、関係型データベースのお話です。
今回は２つの記事を連続で書いておりますので、
「その１：階層型データベース」をお忘れなくチェックして下さいね。
関係型データベースはおなじみですので、細かい説明はいらないですよね？
でも、ちょっとした例だけ載せておきます。
| 学校 |
住所 |
校長先生 |
| Ａ学校 |
Ａ県Ｂ市・・ |
○川×夫 |
| Ｂ学校 |
Ｂ県Ｃ市・・ |
△山□子 |
なんとも適当な例で申し訳ないですが；
このように、各列をデータ、各行をレコードとした表の形式で管理されます。
学校・クラス・生徒など、階層型データベースでいう階層ごとに表を作成すれば
データの管理がしやすいのではないでしょうか？
どのように表を作り、どのデータを持たせるのかという設計次第ですけどね。
さて、前回の最後にちょっとお話しましたが、
階層型データベースの各階層のデータに「キー」を設定して、
階層毎のポインタを切り離して考えると、関係型と同じ構造になってしまいます。
つまり、構造的には、階層型も関係型も違いはないのです。
ではなぜ、関係型データベースが主流となっているのでしょうか？
関係型には何かしらのメリットがあるハズのですが・・メリットって何でしょう？
シンキングターイム
・・
・・・
・・・・
はい、終了。
大きな特徴としまして、
関係型データベースでは「ＳＱＬ」が使えるのです。
ＳＱＬを使うことの利点は、
複数の表を結合してデータを取得できる点にあります。
例えば、ある生徒の学校やクラスを含めたデータを取得したいとき、
「学校」「クラス」「生徒」の各表を結合して、
| 学校 |
クラス |
生徒 |
| Ａ学校 |
1年1組 |
Ａ君 |
| Ａ学校 |
1年1組 |
Ｂ君 |
このように1つの表として管理することができるのです。
ＳＱＬを用いて、このような操作が行えるのです。
では、次の質問。
階層型でも、学校やクラスのデータを1つのレコードに入れてしまえば、
同じ構造で管理することになりませんか？
「表を結合させることができる」利点はなんでしょうか？
シンキング・・もういいか。
ズバリいいますと、
データの１元管理が楽にできる可能性があるという点にあります。
（１元管理 ： 何らかの情報やモノを一箇所で管理すること）
可能性という表現を用いたのは、
あくまで論理的な構造、設計次第によるからです。
ちょっと例を挙げてみましょうか。
ある製品・・野菜としましょうかね。野菜の、仕入れの単価と販売の単価は異なりますよね。
異なる２つの単価を持ちますが、同じ野菜のデータではあります。
野菜のレコードと単価のレコードを分けた場合、
階層型データベースでは、まず野菜のデータを取得してから、
欲しい方の単価のデータを取得する必要があります。
関係型データベースでは、ＳＱＬで野菜と欲しい方の単価の表を結合すれば、
一括でデータを確認する事ができます。
ただ、野菜のレコードに両方の単価のデータを含めるように設計した場合は、
階層型データベースと関係型データベースでは同じように機能します。
（↑ちょっと難しいかもしれません。よく読んで、考えてみてください。）
平たく言ってしまうと・・
データの設計によらず、関係型データベースはＳＱＬを用いて１箇所で管理できる点にあります。
階層型データベースでは、この限りではありません。
ということで、管理の点から関係型データベースが主流となったのです。
論理的な構造の面でなく、物理的な現実の面で説明します。
管理はともかく、単純な検索の繰り返しによる階層型データベースは探索が早く、
処理のスピードや信頼性が求められるメインフレームでは、現在でも用いられております。
それとは別に、
メインフレームが使われていた当初は、関係型データベースの処理そのものに
機械の性能が追いついていないという実態がありました。
これらの点から、初めは階層型データベースが主流となっていたのです。
コンピュータの性能が向上し、関係型データベースの処理が可能となり、
設計によらない管理のしやすさから、関係型データベースへの流れとなったのです。
・・とまぁ、こんな感じかと思われます。
これらの事をいくつものデータベース関連のウェブサイトを調べて勉強したのですが、
なんでかなぁ、データベース関連のサイトの誤字・脱字率の高さは酷かった！ｗ
今回のブログの内容にも誤字・脱字があったのなら、何かの呪いだと思います。
