--- a/Slide/prosym.md	Sun Dec 25 17:07:24 2016 +0900
+++ b/Slide/prosym.md	Sun Dec 25 17:40:41 2016 +0900
@@ -6,14 +6,8 @@
 
 # はじめに
 
-データベースは1960年代後半に階層型、ネットワーク型により注目が集まった。
-
-CODASYLの規格によりデータ操作言語とデータ記述言語の分離を主流とした。
-
-その後RDBが主流になった。
-
-しかし、プログラムからデータを分離して扱うデータベースには、
-プログラム中のデータ構造とRDBの表構造の<u>インピーダンスミスマッチ</u>という問題がある。
+プログラムからデータを分離して扱うデータベースには、
+プログラム中のデータ構造とRDBの表構造のずれにより、<u>インピーダンスミスマッチ</u>という問題がある。
 
 データベースのレコードをプログラム中のオブジェクトとして使える<u>OR Mapper</u>や、
 データベース自体も、表に特化したKey Value Storeや、Jsonなどの不定形のデータ構造を格納するように機能拡張されてきている。
@@ -37,14 +31,14 @@
 
 PythonのpeeweeやRubyのActiveRecordなどスクリプト言語にもある。
 
-しかしレコードをプログラム中のオブジェクトに対応させるOR Mapperという技術では、これを本質的には解決することはできない。
+しかし、レコードをプログラム中のオブジェクトに対応させるOR Mapperという技術では、インピーダンスミスマッチを本質的には解決することはできない。
 
 # 問題点
 
-そこで、 MySQLやPosgreSQLなどは、Jsonなどの不定形のデータ構造を格納するように機能拡張されるようになってきた。
+MySQLやPosgreSQLなどは、Jsonなどの不定形のデータ構造を格納するように機能拡張されるようになってきた。
 
 しかし、不定形の構造の変更をトランザクションとして、どのように処理するかはJsonの一括変更という形で処理されてしまっており、
-並列処理が中心となってきている今のアプリケーションには向いているとは言えない。
+並列処理が中心となってきている今のアプリケーションには向いていない。
 
 つまり、この拡張はRDBよりの拡張であり、
 並列処理を含むプログラミングからの要請とのミスマッチが残っている。
@@ -169,7 +163,7 @@
 
 Jungleの木の編集はJungleTreeEditorクラスを用いて行われる。
 
-JungleTreeEditorクラスには編集を行うために、次の定義されているAPIが実装されている。
+JungleTreeEditorクラスには編集を行うために、定義されているAPIを記述する。
 
 また、ノードを指定して編集を行う際に<u>NodePathクラス</u>を用いる。
 
@@ -266,7 +260,7 @@
 の３つの要素を持っている。
 maTrixはアクセス要求に応じたポリシーファイルを参照することで許認可の判断を行う。
 
-ポリシーファイルは組織構造中の人や役職をidを用いて参照している。
+ポリシーファイルは組織構造中の人や役職をidを用いて参照し表現している。
 
 - 許認可を下すためには、その人がどこの組織に所属して、その役割がどの権限を持っているかを返す検索が必要。
 
@@ -274,10 +268,15 @@
 
 - 組織構造は、それぞれの木構造がidを用いた参照を行う
 - 過去のアクセス要求を全て保存する
-- ファイルポリシーを用いた場合の人物検索
+[](なんでアクセス要求を保存する必要があるのか)
+- ポリシーファイルを用いた場合の人物検索
+
+[](ポリシーファイルが必要な部分)
 
 # Indexの実装
 
+[](indexがなんで必要かを入れる必要がある。)
+
 Jungleは、非破壊的木構造というデータ構造上、過去の版の木構造を全て保持しているため、全ての版に独立したIndexが必要となる。
 
 そのため、前の版のIndexを破壊すること無く、Indexを更新する必要があった。
@@ -322,7 +321,7 @@
 return nodeListOp.get().iterator();
 ```
 
-・属性名"name"でgetを行うと対応したIndexが包まれて返ってくる。
+・属性名"name"でgetを行うと対応したIndexがOptionalに包まれて返ってくる。
 
 ・中身が入っているか確認、入っていた場合Indexを取得する。