第7回 IoT(もののインターネット)とデータベース

第7回 IoT(もののインターネット)とデータベース

1.データベース(RDBMS)の考え方

前回のIoTの記事で、データベース(以下DBと略)の例として、「住所録は1枚の紙に書けるものをわざわざ細分化する」という流れが分かりにくくなるので、決して正しいとは言えないとお話ししました。

また、DBはデータを扱うすべての物だともお話ししました。

そこで今回DBが、そしてRDBMSがどういう考え方をしているのかを説明するにあたり、HPを題材に取り上げたいと思います。

これはDBの必要性を理解していただくためのものですので、少々違和感を伴うかも知れませんが、その点はご容赦願います。

2.単一のデータを処理するだけか?複数のデータを同時に処理するのか?

2-1.HPをDBと見立てた場合。(データ抽出)

さて、具体例としてあげるHPですが、今回は『ユニクロ』のHPを例題にしたいと思います。

私も時々利用させてもらっているのですが、ここのHPは非常に良くできていて、分かり易いですよね。それにさり気ない配慮があって、それがDBとして見てもなかなかに良いので、今回例題にすることにしました。

まずトップページですが、最上部に位置するメニューバー。スクロールしても動きません。つまりこれは常に表示させておくべき『入り口』として設定してあるので、いつでもどこでもスタート地点に戻れるようにしてくれています。

そのメニューバーですが、一番左にユニクロのロゴがあって、その隣から順に『Woman』『Man』『Child』『Baby』の順に並んでいます。

ユニクロTOP

まずここで、来たお客さんを細分化することができます。HPを訪れた人が『女性』なのか『男性』なのか。それとも『子供服』が欲しいのか?といった具合にです。

そして次に『Man』の男性用を選ぶと、新たにメニューが表示され、今度は上から下に、『新作&お買い得』『アウター』『トップス』『ボトムス』『インナー』etc.と順に並んでいて、そのどこかにカーソルを重ねると、より細かなメニューが右側に表示されるようになっています。

このようにHPを訪れたユーザーは次々に表示されていく内容の中から、自分が欲しいものを選択して、最終的にはそれを購入する訳です。

ではこのHPにもし、RDBMS(Relational DataBase Management System)の考え方が無かったらどうなるのでしょうか?

RDBMSの考え方がないHPを訪れたあなたは、HPを開いた途端、そこにある何千、何万種類の商品の中から、自分の欲しいものを見つけ出さなければなりません。しかも検索機能はほとんど動かない状態でです。

それは不可能に近い状況でしょう。でも、そうなってしまうのです。

 RDBMSは、テーブルという『Excel』のスプレッドシートのようなものに、データを納めています。その中から必要なデータを抽出していきます。    先ほどの例で言えば、メニューに『Woman』『Man』『Child』『Baby』があって、次に『新作&お買い得』『アウター』『トップス』『ボトムス』『インナー』があります。これらが全て『テーブル』にデータとして納められているのです。

例えば、男性用のタートルネックの今年新発売のヒートテックで、Lサイズの青色が欲しいとしましょう。   その場合あなたは、『Man』⇒『インナー』⇒『新ヒートテック』の順に選んでいき、ヒートテックが表示されるページに行きます。

この時DBは、あなたが選んだ『Man』『インナー』『新ヒートテック』を検索条件として受け取り、その検索条件に合致するデータを抽出して、表示する。という作業を行っているのです。

2-2.RDBMSのR(Relational)とは?

先ほどの抽出の説明だと、前回挙げた住所録の中から必要なデータを取り出すのと同じです。だったら、住所録の説明で十分だといわれる方もあるでしょう。確かに抽出だけならそれでも良いでしょう。

ですが、RDBMSは一番最初にR(Relational)が付いています。実はそれがDBをDBたらしめている部分なのです。その事をお話ししたいと思います。

先ほどのユニクロのページに戻りましょう。

するとそこには、中央に大きな写真があり、その周囲に様々な選択条件のボタンがあります。

右側にあるのは色とサイズのボタン。左側には価格と映像写真の選択ができるようになっています。

ここでポイントになるのが、左側にある価格の表示です。今私が見ている時点では、今日いっぱいが特別価格で、明日からは通常価格で販売することになっています。

つまり明日から価格が変わるということになります。

この場合、もし先に挙げた住所録のように、1つのテーブルに価格のデータを載せていたとしたら、日付が切り替わる時点で全てのデータを入れ替える必要が出てきます。

「そんなのプログラムにやらせればいいじゃないか」という声が聞こえてきそうですが、ことはそんなに単純ではありません。その1つのテーブルに書かれた価格の全てを検索し書き換える場合、かなりの時間データがロックされてしまいます。

DBはデータの書き換えを行う時に、書き換え以前と書き換え以降でデータのズレが起きないように、データをロックさせるようになっています。その間データを触ることはできません。つまりこの間、データがロックされるため、DBは価格に関する操作(購入や商品閲覧など)が全てストップすることになる訳です。

そうなったら、HPがフリーズしてしまうことにもなりかねません。ですのでこのように大量のデータを1度に触ることは避けねばならないのです。

そして、ここでRDBMSのR(Relational)を使うのです。

先にお話ししていたテーブルを分割し、価格テーブルというモノを作っておきます。そしてその価格テーブルのヒートテックの価格だけをある日時を境に切り替わるようにプログラミングしておきます。

商品の価格を表示する際、商品テーブルではなくその価格テーブルを見に行っていれば、対象の商品の価格テーブルだけを書き換えれば良いだけで、他のテーブルは一切触らずに済みます。

書き換えは価格テーブルの『価格』の欄だけなので、他のデータはロックされません。しかも価格テーブルの価格も、時間が来れば自動的に書き換わるようになっていますから、その処理時間はほんのわずかで済むのです。

こうしておけば、データの書き換えを行ったとしてもかかる時間もわずかで済みますし、処理も1回で、そして一瞬で終わることになります。

このようにデータを細分化してそれを別テーブルに納め、それぞれのテーブルで一番重要なデータを分割して管理する。価格テーブルなら価格を、サイズテーブルならサイズを管理し、商品テーブルではその価格テーブルの価格を見に行くように設定しておく。

こうして各テーブルに関係性を持たせ、それをつなげて大きなデータを小さな処理で管理できるようにしたのが、RDBMSなのです。

このやり方の最大の特徴は、1つのテーブルだけを触ることで、他のテーブルを触ることなく全体のデータの書き換えができる点にあります。住所録のように、大きなテーブルから必要なデータを検索する必要がなくなります。

この方法を使うことで、先程も言いましたが、書き換えの手間と時間を省くことができ、その上全体のデータも正確に保つことができるのです。

DBの最大の目的は、正しいデータを正しく保ち、一貫性を持たせることにあります。だから前回ご紹介した『トランザクション』といったような定義が必要になるのです。

DB、特にRDBMSの構築は、作る前に決まると言っても過言ではありません。取り扱うデータによってテーブル構造を決め、抽出したいデータに一貫性を持たせるための設計を行わなければなりません。

DBが他のアプリケーションと大きく変わるのがこの点です。

他の大半のアプリケーションが、それを使いながら何かを作っていくのに対して、RDBMSはソフトを使ってDBを作る前に、そのDBの設計図を書き出し、全体像を描く必要があるのです。

この工程を経たDBは、トランザクションによるデータの一貫性が保たれます。それに更新時にかかるコストもわずかで済みますし、複雑な条件であってもSQLによる『検索』『抽出』『集計』が可能になります。

何より、長年培われた実績とノウハウがありますので、様々なケースに対応することができるのです。

逆にこの工程を経ずにDBを作ると、そのDBは求める性能を十分に満たさないものにしかならないのです。

この点だけは、『Oracle』であっても、IBMの『DB2シリーズ』であっても、『MySQL』も、『PostgreSQL』も同じです。

その分、DBは他のソフトやアプリに比べると敷居が高いように思われがちです。それは今挙げたように、DB専門の知識が必要になるという理由からなのです。

ということで、RDBMSのごくごく表面的な部分だけを、簡単に説明させていただきました。

さて次回は、ビッグデータに対応するDBとは?という切り口でやってみたいと思っています。

今回取り上げたRDBMSでは、どうしてもビッグデータに対応出来ない部分が出てきています。そしてビッグデータに対応出来るようにとNoSQL(Not Only SQL)という新しいDBが出てきています。

その辺りのことも含めて、お話ししていきたいと思います。

3.終わりに

DBというのは『縁の下の力持ち』的要素が強いソフトであり、アプリケーションです。ですが、だからこそSystemをきちんと動くようにするためには、一番に整備されていなければならないものでもあります。

またDBは、導入の際に大きなコストが必要になるものでもあります。世の経営陣はそれを嫌って、汎用型のDBを購入したりするのですが、会社のSystemとDBの整合性が取れず、ムダなコストを延々と払い続けることになってしまうことも珍しくありません。

これはDBに対する正しい知識を持った人材が少ないためでもあります。

インターネットも企業のSystemも全て、DBがあってこそなのです。この機会に1度、DBというものに触れてみられてはいかがでしょうか?

LEAVE A REPLY

*
* (公開されません)

CAPTCHA


*

COMMENT ON FACEBOOK