!!ツリー構造のデータ 監査実務に従事する人は、表計算ソフトを使って二次元でデータを表現することに慣れている。というよりは、ディスプレイに表現されるのは二次元データが便利なことは否定し得ない。 その結果として生ずる問題は、数限りないデータの重複と、分析における「ドリルダウン」という考え方との対立である。 テーブル構造は、組織名とか商品名などをそれぞれのレコードに突っ込んでいるので、同じ名前のデータがたくさん発生する。この重複を回避しようとする方法の一つが、リレーショナル・データベース（RDB）という考え方であるが、RDBは個々のテーブルをインデックスで関連付けしてテーブル単位でのデータをシンプルにする。しかしデータ自体はドリルダウン構造にはなっていない。 ドリルダウンとは、対象を粗く分析し、特定された分野をさらに深く分析していきながら、深めていく手法である。二次元テーブル構造でも可能ではあるが、概念レベルではデータはツリー構造になっているはずだ。 !!例えば仕訳データで考えてみる。 !伝票の集約 通常の伝票単位は次のように整理集約される。 *会計期間 **会計単位 ***伝票単位 さらに個々の伝票は以下のような内容を最低限持っている。 *伝票単位 **伝票番号 **日付 **会計組織 **摘要 **明細単位 ***科目 ***金額 ***貸借区分 ***メモ !仕訳の集計 そして仕訳の集計は次のようになろう。 各科目に分類された取引金額は、仕訳から科目別に転記・集計され、総勘定元帳を通じて試算表に集約される。 *全組織合計試算表 **会計単位別合計試算表 ***総勘定元帳 *総勘定元帳 **科目１ ***借方金額 ***貸方金額 **科目２ ***借方金額 ***貸方金額 各科目の集計された金額は、試算表に分類集計されて、貸借合計の一致が確かめられる。これは転記の誤り（網羅的かつダブりなく正確に）を確かめている。 !財政状態・経営成績の計算 そして、試算表に集められた組織別の各科目の残高は、全組織で集計され、科目の属性（資産・負債・純資産・収益・費用や、長期・短期、営業損益・営業外損益・特別損益の区別）に従ってさらに区分される。これらはアプリオリなツリー構造であり、集計計算をも定義している。 !意味 伝票の集約は、取引を時系列に並べて集めたものだという解釈ができるが、仕訳の集計は伝票の明細単位を合計残高試算表の形式に並び替えて集計したものである。 監査では個々の明細データよりも、伝票データという塊でそれがどういう取引を表しているかを見るのが普通だ。なぜなら、仕訳は取引と決算との連結環であり、取引が正しく処理されているかどうかは偏にこの仕訳生成の正しさに依っているいるからだ。 分析の観点からは、伝票単位では取引を表している点を捉えて、資産・負債・純資産という大括りな単位で、どのような取引が影響しているかという点を見ることになる。一方、明細単位では、科目の組み合わせのパターンや出現頻度、金額帯などを時間や組織などをキーとして分析した上で特に着目すべき点を伝票単位に遡って取引としての意味を検証できるだろう。 仕訳データの形式は単に会計システムの形式をそのまま踏襲するのではなく、分析に用いるに便利な形式にするべきであり、ツリー型のデータをまず作ることが有用ではないかと考える所以である。 !パッケージを使う 世の中にはいろいろと考えてくれる人がいるもので、Rにはdata.frameを拡張させてdata.tree（ツリー構造のオブジェクト）というパッケージを使えば、ツリー構造を扱えるようになっている。 他にも、リスト型オブジェクトを拡張したrlistもあるようだ。