\chapter{既存のデータベース}
本章では, まずデータベースの種類であるRelational DatabaseとNoSQL について述べる。
次に、データベースに値を格納する際に、発生する問題であるインピータンスミスマッチについて触れ、
最後に既存のデータベースの例として、PostgreSql・MongoDB・Cassandraについて述べる。

\section{Relational Database}
Relational Database(RDB)は、列と行からなる2次元のテーブルにより実装されるデータベースである。
RDBが保持しているデータへのアクセスは、SQLを用いて行われる。
テーブルに格納されるデータ型として、文字列・数値・日付・BOOL型があり、システムによりデータに型が強制される。
RDBはスキーマの決まったデータを扱うことに長けている。
また、既存のテーブルを結合することで、１つのテーブルとして扱うことが可能である。
RDBの例として、MySQL・PostgreSQLなどがある。

\section{NoSQL}
NoSQLはNot Only SQLの略で、SQLを使わないデータベースのことを指す。
NoSQLデータベースはRDBとは違いスキーマがない。
そのため、扱おうとしているデータの形が決まっていなくても気軽に使うことができる。
NoSQLの例として、MongoDB・Cassandra・当研究室で開発を行っているJungleなどがある。


\section{インピータンスミスマッチ}
インピータンスミスマッチとは、プログラム中のデータ構造とRDBの表構造の間に生まれるギャップのことである。
例えばRPGゲーム中のユーザが持つアイテムという単純なものでも、RDBではユーザとアイテムの組をキーとする巨大な表として管理することになる。
プログラム中では、ユーザが持つアイテムリストという簡単な構造を持つが、データのネスト構造を許さない第一正規形を要求するRDBとは相容れない。
レコードをプログラム中のオブジェクトに対応させるOR Mapperという技術では、これを本質的には解決することはできない。
そこで、 MySQLやPosgreSQLなどは、Jsonなどの不定形のデータ構造を格納するように機能拡張されるようになってきた。
しかし、不定形の構造の変更をトランザクションとして、どのように処理するかはJsonの一括変更という形で処理されてしまっており、
並列処理が中心となってきている今のアプリケーションには向いているとは言えない。つまり、この拡張はRDBよりの拡張であり、
並列処理を含むプログラミングからの要請とのミスマッチが残っている。


\section{MongoDB}
MongoDB は2009年に公開された NoSQL のデータベースである。
JSON フォーマットのドキュメントデータベースであり、スキーマが無い
リレーショナルテーブルに例えられる。
スキーマが無いため、事前にデータの定義を行う必要がなく、同じコレクションであっても、他のドキュメントが持っていないフィルドやデータ型をドキュメントに含めることができる。
そのためリレーショナルデータベースに比べてデータの追加・削除が行いやすい。


\section{Cassandra}
Cassandraは2008年7月にFacebookによってオープンソースとして公開された Key-Value なデータベースである。
データは4次元か、5次元の連想配列のようになっている。
4次元の場合、{\tt [KeySpace][ColumnFamily][Key][Column]}・5次元の場合{\tt [KeySpace][ColumnFamily][Key][SuperColumn][Column]} の形で値にアクセスする。
例えば、SuperColumnに対して特定のKeyでアクセスを行うと、KeyとペアのColumnが返ってくる。
このように、Cassandraはネストしているデータに対して、Keyを使ってアクセスを行う。
また、Column等は、予めデータの型を定義する必要がないため、柔軟にいろいろなデータを格納できる。
Cassandraは、スキーマレスな NoSQL データベースとなる。