どの会社も､ 小さな会社の簡単な記録簿､ もしかしたら日記や紙切れにデータを保存しているかもしれません｡
アマゾンのような巨大企業で､ ペタバイト級のデータを保存するためにコンピュータを必要とする企業に対して｡
さて､ これらの情報を蓄積するために､ 多くの企業､ 時には個人も含めて､ データベースと呼ばれるものが必要になります｡
前節では､ サーバーに新しいユーザーを記憶させることがいかに難しいかを学びました｡
サーバーがクラッシュするたびに､ 変数がリセットされ､ また最初からやり直し｡
また､ ログインやサインインをチェックするために､ メールやパスワードをJavaScriptでループさせながら繰り返し処理するのは非効率です｡
そこで活躍するのがデータベースです｡
では､ 「データベースとは何か？
データベースとは､ データの集合体である｡
そして､ データの意味するところ｡
いろいろな形があるんですね｡
数字もあれば､ 日付もあり､ パスワードのハッシュ化もありうる｡
ユーザー情報がある可能性があります｡
データベースは､ このデータを私たちに役立つように整理し､ データ管理を容易にするものです｡
そして､ そこから生まれたのがデータベース管理システム､ 略してDB MBSと呼ばれるものです｡
データベースにアクセスし､ データを扱うことができるプログラムの集合体であり､ データベースユーザーへの制御アクセスも可能です｡
db mbsはこの箱の中に入っているものなんですね｡
私たちにツール､ つまりコミュニケーションを可能にするソフトウェアの一部を提供するものです｡
データベースは､ 私たちにとって有用な情報を保存し､ また､ 更新､ 挿入､ 削除､ ルックアップなど､ データベース内のあらゆることを可能にします｡
そして､ このDB PBMという考え方は1960年代から本格的に始まり､ 今では様々なエキサイティングなことの最前線にいます｡
データベースはとても重要なので､ データベースを扱うだけのエンジニアの業界全体があるのです｡
さて､ このコースでご紹介するDMSには､ 現在とても人気のある2つのタイプがあります｡
そして､ この2つのタイプは､ Post GressとMongoDBが実によく表しています｡
まず､ 1つ目のリレーショナル・データベースについて説明しよう｡
右側にあるように､ リレーショナル・データベース､ ポストグラス､ オラクル､
SQL Serverなど､ おそらく最も一般的なデータベースです｡
MySQLのSQL Lightをご存じでしょうか｡
これらはすべて､ このリレーショナル・データベースというタグを持つデータベースの一種である｡
しかも､ どれも似たり寄ったりなのがいいところです｡
これらはすべて同じ標準的なフォーマットに従っています｡
リレーショナルデータベースは､ 列と行を持つ2つ以上のテーブルで構成される｡
つまり､ この場合､ usersはテーブルで､ フルネームusernameのテキストは列で作成され､ ここにあるどんな値も行になるのです｡
各行はエントリーを表し､ 各列は名前､ 住所､ 電話番号など非常に特定のタイプの情報を並べ替えます｡
そして､ テーブルとフィールドの関係｡
リレーショナルデータベースではスキーマと呼ばれるものです｡
情報を追加する前に､ スキーマを明確に定義する必要があります｡
これからデータベースを作成します｡
だから､ あなたにとって意味があるんです｡
例えば､ Twitterがあったとして､ どのようなテーブルがあり､ どのように構成されるかは､ こちらでご覧いただけます｡
ユーザーの安定性､ ツイートのテーブル､ フォローのテーブルを持つことになります｡
そして､ これらの情報を､ 例えば､ テーブルの異なる部分をつなげることでつなげることができるのです｡
例えば､ ユーザー名は､ ユーザーのテーブルでも､ ツイートでも同じになります｡
安定している｡
そうすると､ tweetsテーブルのユーザー名がuserテーブルのユーザー名の外部キーになり､ userからと言うことができる｡
以下のテーブルのusernameの外部キーになります｡
今は､ フルネームやIDなど､ テーブルの各行を識別するようなものが主流です｡
これは主キーと呼ばれるもので､ このセクションの後半で説明します｡
わかりました｡
これからPostgreSQLについて学びますが､ これらのデータベースはどれもほとんど同じです｡
だから､ 1つ知っていれば､ 他のものを手に入れるのはかなり簡単なんです｡
実際にバックエンドを持つサーバーとどのように通信しているのでしょうか？
さて､ すべてのリレーショナル・データベースは､ SQLというものを使っています｡
そしてSQLによって､ フロントエンドとバックエンドの間でHTTPが行っていたような通信をSQLで行うことができるのです｡
データベースと通信して､ 好きなように修正したり､ 取得したり､ 更新したりすることができるんだ｡
そして､ このテーマについては､ ビデオも用意する予定です｡
わかりました｡
それがリレーショナルデータベースなんですね｡
2つ目のタイプはどうでしょうか？
2つ目のタイプは､ 非リレーショナルデータベースまたはNoSQLデータベースと呼ばれるものです｡
そしてまた､ Couch DBやHyper Tableのようなかっこいい名前のデータベースが､
たくさんあります｡
MongoDBやノンリレーショナルデータベースでは､ 最初にスキーマを定義することなくアプリケーションを構築することができます｡
リレーショナルデータベースとは異なります｡
リレーショナル・データベースに戻ると､ スキーマやテーブルはあらかじめ定義されている必要がありますね｡
アプリが公開されたら､ ユーザー情報やツイート､ フォロワーの入力を開始できるように､ アプリの外観を把握し､
これらのテーブルを作成する必要があります｡
SQLや非リレーショナルデータベースを使用しない場合､ その都度定義すればよく､ それぞれ異なる方法でこの情報を保存することができます｡
だから､ ひとつひとつがすごく違うんです｡
また､ プロジェクト開始時にデータ要件が明確でなく､ 大量の非構造化データがある場合､
スキーマが明確に定義されたリレーショナルデータベースを開発する余裕がないことも､
ノンリレーショナルデータベースを使用する強力な理由です｡
その代わり､ 非リレーショナルデータベースは､ あらゆる種類の関連情報を集めたフォルダーのようなもので､
より柔軟性があります｡
さて､ MongoDBはドキュメントオリエンテッドと呼ばれるものです｡
情報をドキュメントとして保存するのです｡
この点を説明しましょう｡
ここにデスクトップがあり､ 2つのフォルダがあります｡
1つはリレーショナルデータベースで､ ここにはユーザーのツイートやプロフィールのフォローがあります｡
そして､ この情報を保存しているコンピュータのどこかにこのフォルダが住んでいる､ このタイプのストレージでリレーショナルデータベースを考えることができます｡
そして､ データベースに何かを依頼する必要があるときは､ いつでも､ ユーザーをつかまえるのです｡
そして､ そのユーザーのツイートも取得したい場合は､ 興味のあるユーザーを見つけ､
そのユーザーとリンクしている外部キーで､ 同じく興味のあるユーザーのツイートを見つけます｡
また､ そのユーザーが何人のフォロワーを持っているかもわかります｡
その情報を取得して､ Webアプリに表示するのです｡
一方､ MongoDBは､ 実際には各ユーザーをドキュメントとして持っていることになる｡
ですから､ 最初のユーザーを取得したい場合､ このドキュメントを取得するだけで､ すべてのフォロワー､ ツイート､
プロフィール､ すべてがこの1つのドキュメントに含まれることになります｡
そして､ これを持つよりMongoDBの方が良さそうだ､ と思うかもしれません｡
正しいやり方をすること｡
まあ､ ニーズにもよりますが｡
だからこそ､ データベースは複雑なテーマなのです｡
本当に､ あなたの状況次第です｡
LinkedInのプロフィールのようなものがあれば､ このMongoDBの方法は非常に便利です｡
しかし､ フォローデータやツイートデータを扱う必要がある場合､ 例えばツイートで､
平均ツイートサイズはどれくらいか？
このファイルを読み込んで計算するのは簡単ですが､ ユーザーひとりひとりからデータを抽出するのは大変です｡
だから､ 本当にニーズ次第なんです｡
もうひとつ､ ありそうな図をお見せしましょう｡
便利です｡
リレーショナルデータベースとノンリレーショナルデータベースを比較すると､ リレーショナルデータベースは各テーブルにブログ記事､
ブログタグ､ ブログコメントがあり､ これらのテーブルをリンクしてブログ情報を提供するのに対し､ ノンリレーショナルはブログ記事全体をエントリとして保存し､
コメント､ タグ､ カテゴリ､ その他すべての関連データを1箇所にまとめて保存する､ と考えることができます｡
では､ MongoDBは何を使って通信しているのでしょうか｡
ここで例に戻ると､ Post Pressのようなリレーショナル・データベースにはSQLが使われていました｡
さて､ MongoDBには独自のクエリ言語と呼ばれるものがあります｡
しかし､ どちらも目指しているものは同じです｡
つまり､ データベースと通信するために､ サーバーがデータベースと通信するための簡単な方法を提供することです｡
そして､ このセクションでは､ そのことについてお話します｡ 最終的に点と点を結びつけ､
サーバーに接続された後のデータベースの威力をお見せしたいと思います｡
次回作でお会いしましょう｡