--- a/abst.tex	Thu Dec 01 18:56:10 2016 +0900
+++ b/abst.tex	Thu Dec 01 19:28:13 2016 +0900
@@ -2,7 +2,7 @@
 プログラムからデータを分離して扱うデータベースには、
 プログラム中のデータ構造とRDBの表構造のインピーダンスミスマッチ\cite{Atkinson:1995:OPO:615224.615226}という問題がある。
 データベースのレコードをプログラム中のオブジェクトとして使えるOR Mapper\cite{Lamb:1991:ODS:125223.125244}\cite{Henry:2001:OVJ:367884.367889}や、
-データベース自体も、表に特化したKey Value Store\cite{cassandra09} \cite{cassandra}や、Jsonなどの不定形のデータ構造を格納するように機能拡張されてきている。
+データベース自体も、表に特化したKey Value Store\cite{cassandra09} \cite{cassandra} や、Jsonなどの不定形のデータ構造を格納するように機能拡張されてきている。
 しかし、プログラム中のデータは複雑な構造をメモリ上に構築しており、これらの方法でもまだギャップがある。
 今回提案する木構造データベースJungle\cite{kono11b} \cite{kono11e}はプログラム内部に直接木構造を構築する。
 そして、木のルートをアトミックに入れ替えることでトランザクションを実現する。

--- a/compareDatabase.tex	Thu Dec 01 18:56:10 2016 +0900
+++ b/compareDatabase.tex	Thu Dec 01 19:28:13 2016 +0900
@@ -1,67 +1,74 @@
-\section{OR-MapperとJungleの検索の比較}
-本章ではJungleとOR-Mapper\cite{Henry:2001:OVJ:367884.367889}の検索方法の比較を行う。
-
+\appendix
+\section{JDBCとJungleの検索の比較}
+本章ではJungleとJDBCの検索方法の比較を行う。
 検索には、人間関係を表した木構造データを用いる。
-MySqlでは、表\ref{User}の構造を持つテーブルuserを用いて木構造を表現する。
+MySqlでは、表\ref{User}の構造を持つテーブル{\tt user}を用いて木構造を表現する。
 
 
 \begin{table}[htb]
 \begin{center}
 \caption{User table}
 \begin{tabular}{|l|l|l|l|l|}        \hline
-id & name & age & type &parrent \\ \hline
+{\tt id} & {\tt name} & {\tt age} & {\tt type} &{\tt parrent} \\ \hline
 \end{tabular}
 \label{User}
 \end{center}
 \end{table}
 
-テーブルuserのカラムの説明を表\ref{UserTableColumn}11に記す。
+テーブル{\tt user}のカラムの説明を表\ref{UserTableColumn}に記す。
 
 \begin{table}[htb]
 \begin{center}
 \caption{User tableのColumn}
 \begin{tabular}{|l|l|}        \hline
-id   & ユーザーのID \\ \hline
-name & 名前  \\ \hline
-age  &年齢  \\ \hline
-type &ユーザのタイプ(Teacher or Student) \\ \hline
-parrent & 自身の親のID  \\ \hline
+{\tt id}   & ユーザーのID \\ \hline
+{\tt  name} & 名前  \\ \hline
+{\tt  age}  &年齢  \\ \hline
+{\tt  type} &ユーザのタイプ(Teacher or Student) \\ \hline
+{\tt  parrent} & 自身の親のID  \\ \hline
 \end{tabular}
 \label{UserTableColumn}
 \end{center}
 \end{table}
 
-このテーブルuserに対して、名前が{\tt kono} タイプが{\tt Teacher}のユーザー以下のノードを全て取得したい。
-木構造の深さがわかっている場合、以下のコードのように、副問合せを複数回使用することで一回のSQLで取得可能である。
+このテーブル{\tt  user}に対して、名前が{\tt kono} タイプが{\tt Teacher}のユーザー以下のノードを全て取得したい。
+ノード以下の木構造の深さがわかっている場合、以下のコードのように、副問合せを複数回行うことで、一回のSQLで取得可能である。
 \begin{lstlisting}[frame=lrbt,label=index,numbers=left]
 ResultSet set = stmt.executeQuery("select * from user where parent_id in (select id from user where parent_id = (select id from user where name = \"kono\" AND type = \"Teacher\")) union select * from user where parent_id = (select id from user where name = \"kono\" AND type = \"Teacher\") union select * from user where  name = \"kono\" AND type = \"Teacher\";");
 while (set.next()) {
   System.out.println("user -> " + set.getString(2));
 }
 \end{lstlisting}
-しかし、深さが変わると上記のSQLは使用できないうえ、SQL文が長くわかりづらくなる。
-なので、特定のユーザー以下のノードを全て取得する場合は、プログラム内で再帰的に複数回SQLを発行する必要がある。
+しかし、深さがわからない場合、プログラム内で再帰的に複数回SQLを発行する必要がある。
 
 しかし、Jungleでは以下の一回の検索で全てのノードを取得することが可能である。
 以下にJungleでの検索コードを記述する。
 
 \begin{lstlisting}[frame=lrbt,label=index,numbers=left]
-tree = jungle.getTreeByName("user");
+tree = jungle.getTreeByName("user"); (1)
 InterfaceTraverser traverser = tree.getTraverser(true);
 Iterator<TreeNode> iterator = traverser.find((TreeNode node) -> {
     String value = node.getAttributes().getString("Name");
     if (value == null) return false;
     return value.equals("Kono");
-    },"Type", "Teacher");
+    },"Type", "Teacher");(2)
 
 while (iterator.hasNext()) {
-  TreeNode node = iterator.next();
-  AllNodeIterator nodeIterator = new AllNodeIterator(node);
+  TreeNode node = iterator.next();(3)
+  AllNodeIterator nodeIterator = new AllNodeIterator(node);(4)
   while (nodeIterator.hasNext()) {
-    System.out.println(nodeIterator.next().getAttributes().getString("Name"));
+    System.out.println(nodeIterator.next().getAttributes().getString("Name"))(5);
   }
 }
 \end{lstlisting}
 
 
+\begin{enumerate}
+\item Jungleから名前が{\tt user}の木を取得する。
+\item 木から属性名 {\tt  Type}、 属性値 {\tt Teacher}、属性名 {\tt name}、属性値 {\tt Kono}の値を持つノードを取得する。 
+\item 検索で取得したノードの{\tt Iterator}オブジェクトから、ノードを取得する。
+\item 引数で渡したノード以下にあるノードを全て取得する、{\tt AllNodeIterator}クラスを生成する。
+\item {\tt AllNodeIterator}クラスから全てのノードを取得する。
+\end{enumerate}
 
+このようにJungleでは、JDBCに比べて非常に直感的に検索を行うことが可能である。

--- a/maTrix.tex	Thu Dec 01 18:56:10 2016 +0900
+++ b/maTrix.tex	Thu Dec 01 19:28:13 2016 +0900
@@ -123,6 +123,7 @@
 
 図\ref{fig:PersonTree}の人物Treeに対して、上記の検索を行うとNode3が取得できる。
 
+付録AにJDBCとの検索方法の比較を記述する。
 \subsection{ノードの親をたどるIndex}
 maTrixがJungleに検索を行う際、親をたどる処理が必要になったが、Jungleは親から子への単一リンクしか持っていなかった。
 しかし、Jungleは非破壊という性質上、子に親への参照をもたせることが難しいため、ノードを渡すと親ノードを返すParentIndexを実装した。