Comments
Description
Transcript
ファイル属性情報の データベースによる体系化
平成 19 年度 学士学位論文 ファイル属性情報の データベースによる体系化 Systematization of File Attribute Information on Database 1080373 高橋 格之進 指導教員 酒居 敬一 2008 年 3 月 7 日 高知工科大学 情報システム工学科 要 旨 ファイル属性情報の データベースによる体系化 高橋 格之進 情報化の浸透により，計算機で扱われる情報が大容量化，複雑化しており正確で柔軟な情 報の管理方法が必要となっている． 現在，計算機の情報の管理には主にファイルシステムが利用されている．ディレクトリに 意味のある名前を付け，そのディレクトリにファイルを格納することでファイルを管理して いる．しかし，ファイル自身は複数の意味情報を持っており，また従来のファイルシステム はディレクトリ構造が静的であるため，多様な整理ができないという問題点がある． これを解決するため，データベースと動的なディレクトリ構造を持つファイルシステムを 組み合わせる方法が考えられる．この方法を用いることで多様な整理が可能となる． そこで本研究では，リレーショナルデータベースによりファイルの属性情報を体系化し ， 動的なディレクトリ構造へ対応付けることを目的としている．そして，リレーショナルデー タベースへ属性情報を体系的に記述し，その情報を動的なディレクトリ構造へ写像する．そ れにより，リレーショナルデータベースと動的なディレクトリ構造を持つファイルシステム を組み合わせた．その結果，多様なファイル整理が可能なことを確認した． キーワード データベース，ファイルシステム，体系化 –i– Abstract Systematization of File Attribute Information on Database Kakunoshin Takahashi By spreading of the informatization, processed informations have been increasing explosively. Therefore, we require flexible information management system. In general file system is used as the management system in the computers widely. By supply a meaningful name for the directory and store the file on this directory, we assign the meaning to the file. However the problems are as follows: the various rearranging of the file is difficult because file have many meaning raised although directory structure is static. In this paper, we propose unique combination of the relational database and the dynamic directory structure. The combination facilitate the various rearranging of the file. Therefore, we systemize the file attribute information on the relational database, and we mapped attribute information to dynamic directory structure. Thereby we combined the relational database and the dynamic directory structure. And, we confirm possibility of ordering files by various basis. key words Database，File System，Systemize – ii – 目次 第1章 序論 1 第2章 計算機での情報管理 3 2.1 緒言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 ファイルシステム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.3 データベース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3.1 2.4 データモデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 階層モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 ネットワークモデル . . . . . . . . . . . . . . . . . . . . . . . . . . 5 関係モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3.2 リレーショナルデータベース . . . . . . . . . . . . . . . . . . . . . 5 2.3.3 リレーショナルデータベースに対する操作 . . . . . . . . . . . . . . 6 2.3.4 ビューテーブル . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.5 リレーションの正規化 . . . . . . . . . . . . . . . . . . . . . . . . . 8 ファイルシステムによる管理方法の問題点 . . . . . . . . . . . . . . . . . 9 2.4.1 付随情報の不足 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4.2 意味関係の表現力の不足 . . . . . . . . . . . . . . . . . . . . . . . 11 2.5 データベースによる管理方法の問題点 . . . . . . . . . . . . . . . . . . . . 11 2.6 本研究の目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.7 結言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 ファイル属性情報の体系化 14 3.1 緒言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2 解決手法の提案 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 第3章 – iii – 目次 ファイルの属性情報 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 対象とするファイル . . . . . . . . . . . . . . . . . . . . . . . . . . 15 ID3 タグ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 ID3v2 の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.5 ID3 タグからの情報取得 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.6 データベースへの記述 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.7 ファイルシステムへの写像 . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.3 3.3.1 3.4 3.4.1 3.7.1 ディレクトリの親子関係 . . . . . . . . . . . . . . . . . . . . . . . 21 3.7.2 ファイルの絞り込み . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.8 RDB とファイルシステム間の通信 . . . . . . . . . . . . . . . . . . . . . 25 3.9 実装環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.10 サーバの実装 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.11 結言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 動作確認 28 4.1 緒言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.2 動作確認 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.3 結言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 結論 32 第4章 第5章 謝辞 34 参考文献 35 – iv – 図目次 2.1 受注管理データベース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 複数の意味情報 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3 複数の意味の付加 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.4 多様な分類基準による分類 . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1 1 対多の関係 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2 多対多の関係 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3 ID3 タグの構造 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.4 ID3v2.4 – ヘッダ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.5 ID3v2.4 – フレーム識別子 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.6 ビューテーブル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.7 ディレクトリ構造 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.8 ディレクトリ構造 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.9 ディレクトリ構造 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.10 システムの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.1 動作結果 CUI – マウントポイントでの ls . . . . . . . . . . . . . . . . . . . 29 4.2 動作結果 CUI – 絞り込み . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.3 動作結果 GUI – 動作結果ファイルブラウザでの利用 . . . . . . . . . . . . . 30 4.4 音楽ファイルの探索と実行 . . . . . . . . . . . . . . . . . . . . . . . . . . 30 –v– 表目次 2.1 検索結果：例 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 検索結果：例 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1 ID3 タグから取得する情報 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 – vi – 第1章 序論 情報化の浸透により，計算機で扱われる情報が大容量化，複雑化しており正確で柔軟な情 報の管理方法が必要となっている． 現在，計算機の情報管理には主にファイルシステムによる管理方法が 利用されている． ファイルシステムは一般的に木構造で管理されている． ファイルはファイル名，更新日時，所有者，パーミッション等の複数の属性情報を持って いるが，ユーザはほぼファイル名のみで識別している．ユーザは一つのファイルに複数の情 報を見出すが，ファイル自体が表せる情報はほぼファイル名のみである．そこで従来のファ イルシステムではファイルに意味を持たせる為，ディレクトリに意味のある名前をつけ，そ のディレクトリにファイルを所属させることで意味情報を付加している．また，ファイルの 持つ意味を複数表すため，複数のディレクトリにリンク等を置き管理している．この作業は ファイルの持つ意味の数だけ行わなければならないため面倒である． このようなファイル整理は，通常あるひとつ整頓ポリシに則り静的なディレクトリ構造を 作ることで行っている．そのため，その整理ポリシに束縛される限り，ファイルの多様な整 頓ができない．意味情報を複数保持するファイルを分類する場合，そもそもその関係を木構 造で表す事が困難な場合がある [1]．つまり，従来のファイルシステムでは整頓の基準とな る意味情報がファイルに複数存在しても，ある一つの整頓ポリシのみにしたがった固定的な ディレクトリ構造をとるしかなく，ファイルを木構造に写像することが困難な状況もあると いうことである． 一つのファイルが複数の意味情報を持つことをより自然に表すため，ファイルとそれの持 つ複数の意味を体系的にまとめる手段が必要となる．また，多様な基準によって整理を行う –1– 為には，静的なディレクトリ構造でなく，動的にディレクトリを構築する必要がある． リレーショナルデータベースではエンティティ(実体) をテーブルで表し ，更にエンティ ティとエンティティのリレーション（ 関連）を別テーブルで表す．このような，エンティティ とリレーションを表すテーブルを複数作成することで，実世界での複数の関係を表現でき る．また，情報は一元的に管理されるので情報の重複を防ぐことができる．そのため，複数 の意味情報を体系的に記述しファイルに付加できると考える [2]． 近年，知識間の関係を視覚的に表す研究やファイル内容に基づく名前空間生成の研究が盛 んに行われている [3, 4, 5, 6]．そこで，本研究では，ファイルの持つ複数の意味情報をリ レーショナルデータベースに体系的に記述し，ファイルに複数の意味情報を付加する．また， 体系的に記述された情報をディレクトリ構造へ写像することで，リレーショナルデータベー スと動的なディレクトリ構造を持つファイルシステムを組み合わせた情報管理システムの構 築へ繋げる．それにより，ファイルの意味関係を可視化する．そして，その結果により多様 なファイル整理が可能になることを確認する． 本稿は本章を含め，5 章で構成される．第 2 章では，計算機での情報管理について概説し， 従来の情報管理での問題点を考察する．第 3 章では問題の解決策の検討と提案を行い，例と して MP3 ファイルの持つ ID3 タグを属性情報とした DB への記述とファイルシステムへ写 像する方法について述る．第 4 章では，構築されたシステムの動作結果を示す．最後に第 5 章で本研究の成果をまとめ，今後の課題を考察する． –2– 第2章 計算機での情報管理 2.1 緒言 本章では，計算機での情報管理方法として，ファイルシステムとデータベースについて概 説し，従来の情報管理における問題点を考察し，本研究の目的を明らかにする． 2.2 ファイルシステム ファイルは，データの集合に名前付けをしたもので，データとプログラムを表現，管理す るための論理的な単位である [7]．ファイルシステムは，この論理的な単位であるファイル を，ディスク等の記憶媒体を抽象化し，これに写像する．ファイルシステムは，ファイルへ のアクセス方法や，データの編成法を提供し ，2 次記憶上での領域割り付けを管理し ，ファ イルの一貫性の制御等を行う．加えて，CPU の処理時間に比してアクセス速度の遅い二次 記憶装置に対して非同期書き込みを行うことで，応答時間の向上を図っている． また，ファイルシステムは，ユーザがファイルを簡単に使用可能にするために，ファイル に関する各種の情報を格納しているディレ クト リの管理を行う．ファイルを管理する際の ディレクトリ構造として，有向グラフや木構造がある．有向グラフはパスに閉路ができファ イルが一意に定まらないが，木構造をとるとファイルを一意に定められる．そのため，ディ レクトリのハード リンクはできない OS が多く，有向グラフを用いる FS はほとんど 存在し ない． また，ファイルシステムは，複数のユーザがファイルにアクセスしたとき，アクセスした –3– 2.3 データベース ユーザの権限によってアクセス範囲を限定する機能を提供している．この機能は，アクセス 制御あるいはファイル保護として知られている． 2.3 データベース データベース (以下，DB) とは， 「 様々な目的を考慮して整理整頓されたデータの集まり」 だといえる．複数のプログラム間でデータの共用を図るのが DB の基本的な考え方であり， 以下のような特徴を持つ． • データは一元的に管理され，重複しないのでファイル領域の浪費が回避できる • データは重複して存在しないので，更新は 1ヶ所で済む • データは重複して存在しないので，更新する時の漏れはない また，DB を計算機上で管理するためのシステムをデータベース管理システム（ DBMS ） という．DBMS は利用者が要求するデータと DB に実際に記録されている物理データの仲 介役となり，DB の操作を行う． 2.3.1 データモデル データを DB として記述するためのモデルをデータモデルという．現在，広く認知されて いるデータモデルは，階層モデル，ネットワークモデル，関係モデルなどがある． 以下に，階層モデル，ネットワークモデル，関係モデルについて記述する． 階層モデル データ間の関係を木構造で表現するモデルである．一般で使用されている場面として，会 社の組織図の部，課，係というような階層構造を有する場合などがそれに当たる．この様 に，データを階層的に把握するデータモデルを階層モデルという． –4– 2.3 データベース ネット ワークモデル 階層モデルでは実体データをすべて木構造でとらえようとするが，実体データをもう少し 詳細にながめてみようとすると木構造で表現できない場合もある．例えば，複数の親レコー ド を持ち得る子レコード を必要とするような論理表現は数多く存在する．これを無理に木構 造で表現しようとすると，構造の歪みやレコード の重複が生じる．そこで，実体データの多 様な構造を無理なく表現可能なデータモデルとして提案されたのがネットワークモデルで ある． ネット ワークモデルや階層モデルではデ ータの論理化・抽象化が 十分に進んでおらず， データの独立性が十分に達成されていない．そのため，次に説明する関係モデルが広く採用 されている． 関係モデル 関係モデルでは，データはすべて表（ テーブル ）より表現される．階層モデルやネット ワークモデルでは，データ自身をグラフの節で表し，データ間の関連付けを節を結ぶリンク で表したのに対して，関係モデルでは関連付けそのものも節の中の情報として表現する．例 えば，二つの節に「学籍番号」という属性があると，二つの節のデータの関連付けはこの属 性を介して必要になった時点で随時，動的に行われる．この「 随時，行える」というのは， 関係モデルの重要な点であり，DB へ情報を記述する際に，きわめて柔軟に定義でき，DB の実際の運用面での使いやすさに反映されることになる．以下で，リレーショナルデータ ベース (以下，RDB) について述べる． 2.3.2 リレーショナルデータベース 関係データモデルに基づく DB が RDB であり，現在，実用レベルで広く利用されている． RDB そのものは，関連する名前のついたテーブルの集まりと考えられる． RDB はテー ブルという極度に抽象化された表現をデータモデルとすることにより，高度なデータの独立 –5– 2.3 データベース 図 2.1 受注管理データベース 性を保証されている． RDB のテーブル例を図 2.1 に示す．これは顧客という実体を表す顧客情報テーブルと商 品という実体を表す商品情報テーブル，顧客が注文した商品と数量を管理する顧客と商品の 関連を表す受注情報テーブルからなっている．このように，RDB は実体と実体間の関連を テーブルに記述することでデータの関連付けを行っている． 2.3.3 リレーショナルデータベースに対する操作 RDB に対する操作はリレーショナルデータベース管理システム（ RDBMS ）を介して行 う．また，RDBMS においてデータの操作や定義を行うためにはデータベース言語「 SQL 」 を用いる． データの検索や更新，削除等の命令を DBMS に発行する際，DBMS に対する処理要求を 文字列として表したものをクエリという．クエリの記述には主に SQL を使用する．以下に –6– 2.3 データベース RDB からデータを検索する際に使用するクエリの例を示す．検索対象となる DB は図 2.1 の受注管理データベースとする． • 検索 指定された検索条件の下にいくつかの演算を組み合わせた操作を定義する SELECT 文により検索する． [ 例 1 ] 顧客番号’1001’ の注文番号と商品番号と数量を検索する． – 検索文 顧客情報. 注文番号, SELECT FROM 顧客情報. 商品番号, 顧客情報. 数量 顧客情報 WHERE 顧客情報. 顧客番号 = ’1001’; – 結果 表 2.1 検索結果：例 1 注文番号 商品番号 数量 2001 G3 1 2001 G1 2 • サブクエリ SELECT 文の検索結果に対して，更に検索を行いたい場合サブ クエリ (副問い合わ せ) を利用する．サブ クエリとは検索条件の名に置かれた SELECT 文であり，その SELECT 文の検索結果を検索条件として使用する． [ 例 2 ] 注文数量が 1 で，商品番号’G3’ を購入した顧客の名前と住所を検索する． – 検索文 SELECT 顧客情報. 氏名, 顧客情報. 住所 WHERE 顧客番号 IN ( SELECT 受注情報. 顧客番号 FROM –7– FROM 受注情報 顧客情報 2.3 データベース WHERE 受注情報. 数量 = 1 AND 受注情報. 商品番号 = ’G3’ ); – 結果 表 2.2 検索結果：例 2 2.3.4 氏名 住所 佐藤一郎 京都 青山一郎 大阪 ビューテーブル SELECT 文により RDB のテーブルは検索され，検索結果は新しいテーブルを与える． こうしてできた新しいテーブルは，元のテーブルのように物理的な記憶ファイルとして存在 するわけではない．この新しいテーブルは実際に存在している元のテーブルの中のど の部 分を利用するかという範囲を指定したものにすぎない仮想的なテーブルである．表 2.1，表 2.2 がこれにあたる．元のテーブルを実テーブル，新しくできるテーブルをビューテーブル と呼ぶ． 通常，このようなビューテーブルは一時的なものであり，検索文の実行結果として表示し た時点で消滅しまう．しかし，ビューテーブル定義文により，名前をつけてビューテーブル として定義することができる．これにより，ビューテーブルとはいえ，以後，実テーブルと ほぼ同等に扱うことがきる．以降，本稿では単に「ビューテーブル」といえば，定義されて ビューテーブルのことをいう． 2.3.5 リレーションの正規化 リレーションの正規化は RDB において，正規形と呼ばれる形式にリレーションを準拠さ せることにより，データの一貫性の維持と効率的なデータアクセスを可能にするリレーショ ン設計を導く方法である．正規化を行うことにより，データの冗長性と不整合が起きる機会 –8– 2.4 ファイルシステムによる管理方法の問題点 を減らすことができる． 2.4 ファイルシステムによる管理方法の問題点 以降で，先に述べた従来のファイルでの情報整理手法が持つ問題について考察する．従来 の手法には 2 つの問題点がある． 2.4.1 付随情報の不足 まず，ファイル自体が持つ意味が少ないという問題が挙げられる．ファイルに付随する属 性には主に次に示すものがある． • ファイル名 • 更新日時 • 所有者 • パーミッション 通常，ユーザがファイル識別に利用するのは主にファイル名である． 従来のファイルシステムで，ファイルの分類を行うには，ユーザがファイル名や内容から その意味を判断する必要がある．そして，その意味を持つ事を示すディレクトリにファイル を格納することで意味属性を与える． ファイルは 1 つ以上の意味を持つ．画像ファイルを例に挙げると，作者，テーマ，作品名 等が意味情報として考えられる．ユーザによっては，その画像の風景や人物に意味を見出す だろう (図 2.2)． ある一つのファイルが複数の意味を持つことを表すには，複数のディレクトリ内にファイ ルをコピーしたり，ハード リンクを張るなどの処理をする必要があるが，これでは，ファイ ルの保持する意味の数だけハード リンクを張る等の必要があり，煩わしい．図 2.3 にファイ ルが複数の意味を持つ場合のディレクトリ構造の例を示す． –9– 2.4 ファイルシステムによる管理方法の問題点 図 2.2 複数の意味情報 図 2.3 複数の意味の付加 – 10 – 2.5 データベースによる管理方法の問題点 これを解決するため，ファイルにメタ情報を持たせ，付加されたメタ情報に基づいて管理 する手法が用いられている．しかし，この手法では，メタ情報に対応したアプリケーション でしかファイルの整理ができない．そこで，ファイルに複数の意味を付加し ，且つアプ リ ケーションに依存しないような管理をする必要がある． 2.4.2 意味関係の表現力の不足 次に整頓ポリシが限られるという問題が挙げられる．従来のファイルシステムではファイ ルを整理するために，ある一つの整頓ポリシに則り静的にディレクトリ構造を保持する．整 頓のポリシの例として Filesystem Hierarchy Standard が挙げられる． ファイルの持つ意味情報を基準としてファイルがディレクトリによって分類される事は先 で述べたとおりである．分類基準となる意味属性をファイルが複数保持しているなら，その 整頓ポリシも一つに限る必要はなく，複数の分類基準を適用でき，複数の分類方法が可能に なると考える．ファイルに複数の意味情報を持たせても，静的な木構造で表現することが困 難な場合がある．画像ファイルの例を挙げると，図 2.4 に示すように，作者で分類したもの の下で作品名やテーマで分類ができたり，逆にテーマで分類されたものをさらに作者名や作 品名で分類できるように，分類基準となる意味情報が増えると当然分類も多様化する． この様に，元々親子関係にないものを，親子関係である木構造に写像することが困難な場 合がある．付加された意味情報を用いて多様にディレクトリ構造を作るには，動的にディレ クトリを構築するシステムが望ましいと考える． 2.5 データベースによる管理方法の問題点 ここでは，先に述べた DB によるファイルの管理についての問題点を考察する．DB で ファイルを管理する方法には以下の問題が挙げられる． DB は情報の管理を行うものであり情報自体は利用できるが，ファイルの参照等，ファイ ルを直接利用することができない． – 11 – 2.6 本研究の目的 図 2.4 多様な分類基準による分類 先に述べたメタ情報による管理のように，特定のアプリケーションで DB を利用しファイ ルを管理・参照することはできるが，そのアプ リケーションに依存してし まう．そのため， アプ リケーションに依存せずファイルを利用するために OS レベルでのサポートが必要に なる． 2.6 本研究の目的 以上で述べた問題を解決するため，ファイルに意味情報を付加し DB へ体系的にデータ記 述する．加えて，そのデータを処理しファイルの意味関係をディレクトリ構造として表現で きるシステムを構築し，分類基準を一つに限らない多様なファイル管理を行うシステムを構 築することを目標とする．また，これを OS レベルでサポートすることによりアプ リケー – 12 – 2.7 結言 ションに依存しないシステムの構築を目指す． そこで，本研究ではファイルの意味情報を DB へ体系的に記述し，そのデータをファイル システムのディレクトリ構造へ写像することを目的とする．それにより，アプリケーション に依存しない，多様なファイル管理を行うシステムを構築へ繋げることとなる． 2.7 結言 以上本章では，RDB と FS についての概説を行った．また，従来の管理方法の問題点を 考察し，本研究の目的を明らかにした．次章では，ファイル属性情報の体系化手段を示す． – 13 – 第3章 ファイル属性情報の体系化 3.1 緒言 本章では，まず実験内容の検討と提案を行う．次に，属性情報の研究対象とし た MP3 ファイルに付随する ID3 タグについてを概説し，ID3 タグより取得した情報の RDB への記 述方法，RDB へ記述した情報のディレクトリ構造への写像方法を述べる． 3.2 解決手法の提案 前章で触れたように，従来のファイルシステムには，次の 2 つの問題点がある． • ファイル自体が保持できる意味情報が少ない • 静的木構造を持つために複数の意味情報を持つファイルを木構造に写像することが困難 ここで，これらの問題に対し解決手法の提案を行う． まず，ファイル自体の意味情報の不足という問題を解決するには，ファイルに複数の意味 情報を持たせる必要がある．また，付加した意味情報を利用することを考えると，意味情報 の体系的記述が必要となる．そこで，ファイルに意味情報を付加し体系的にデータ記述する ために RDB を用いる． 次に，複数の意味情報をファイルが持つ場合に静的木構造として表現が困難な問題を解決 するには，動的なディレクトリ構造が必要になると考える．そこで，体系化した意味情報を 処理し，その結果を元にディレクトリを構築し，ファイルの関係をディレクトリ構造として 表現するファイルシステムを構築する． – 14 – 3.3 ファイルの属性情報 これにより，分類基準を一つに限らない多様なファイル管理を行うシステムを構築できる と考える．また，これをファイルシステムとして実装することで，OS レベルでサポートで き，アプリケーションに依存しないファイルアクセスが実現できると考える． 以上から本研究では，RDB と動的にディレクトリ構造を構築するファイルシステムを組 み合わせた情報管理システムの構築へ繋げるためにファイルの意味情報の体系化を行う． 3.3 ファイルの属性情報 ファイルの属性情報とは一般的に，ファイルの更新日時，サイズ，所有者，パーミッショ ン等を指す．また，それ以外にもファイルの持つ意味を指す場合もある．ファイルには，メ タ情報（データ）が付随しているものがある．メタ情報とは，データについてのデータとい う意味であり，あるデータが付随して持つそのデータ自身についての付加的なデータ，つま りファイルの意味情報である．本稿ではこのファイルに付随するメタ情報を属性情報として 扱う． 3.3.1 対象とするファイル 本研究では，例として ID3 タグという非正規形のメタ情報が付随されている MP3 ファイ ルを取り上げる．本来，従来のファイルシステムでとられている木構造は，図 3.1 のように 一つの親ディレクトリ（アーティスト ）に複数の子ディレクトリ（ 楽曲），といった 1 対多 の関係しか存在しないため階層モデルで表すのが自然である．しかし，ID3 タグような非正 規形データは図 3.2 のようにアーティストの他にジャンルという複数の属性情報を持つため， 多対多の関係が存在する．そのため，ID3 タグを階層モデルで表現するのは適切ではなく， 従来のファイルシステムで多様な整理を行うことが困難である．よって，本研究で提案する 管理方法で MP3 ファイルの多様な分類が可能となれば，提案手法が有効だと確認できる． – 15 – 3.3 ファイルの属性情報 図 3.1 1 対多の関係 図 3.2 多対多の関係 – 16 – 3.4 ID3 タグ 3.4 ID3 タグ MP3 ファイルには，ID3 タグと呼ばれる文字情報が確保されている．この ID3 タグを使 用すれば ，タイトルやアーティスト名，制作年など 曲についての付加情報を MP3 ファイル に保存しておくことが可能である． ID3 タグには，現在 ID3v2（ ID3 Tag Version 1 ）と ID3v2（ ID3 Tag Version 2 ）の 2 つ のバージョンが存在する．本研究では，ID3v2 のみ考慮している． ID3 タグはヘッダとフレーム，そして残りの領域 (Pdding 領域:無くても良い) から構成さ れ (図 3.3)．そして，すべてのフレームはフレームヘッダと実際のデータを格納したフィー ルドで構成されている．[8] 図 3.3 ID3 タグの構造 – 17 – 3.5 ID3 タグからの情報取得 3.4.1 ID3v2 の概要 ID3v2 は MP3 ファイルの先頭に格納されている．ID3v2 タグのヘッダの先頭 3 バイトに は常に「 ID3 」という文字列が入っている (図 3.4)．ID3v2 はフレームと呼ばれる情報を格 納したコンテナの集合体として作られている．各フレームの先頭にはそのフレームのフォー マットと中身を特定するための虚空な定義済みの識別子 (図 3.5) と，フレームサイズが格納 されている． 図 3.4 ID3v2.4 – ヘッダ 3.5 ID3 タグからの情報取得 ID3 タグのフレーム領域には多くの情報が格納できる．このフレーム領域からファイルを 分類する際に必要になると思われる情報のみを各フレームから取得する．取得する情報の内 容とそれぞれのフレーム識別子を表 3.1 に示す．これらはファイルを分類する際の整理ポリ シになる． – 18 – 3.5 ID3 タグからの情報取得 図 3.5 ID3v2.4 – フレーム識別子 表 3.1 ID3 タグから取得する情報 内容 識別子 解説 アルバム / 映画のタイトル TALB オーディオファイルの音源となった録音のタイトル を意味する 主な演奏者 / ソリスト TPE1 主なアーティストを格納するのに用いる 内容のタイプ (ジャンル ) TCON ジャンルを格納する 作詞者 TEXT 作詞者の名前を意味する 作曲者 TCOM 作曲者の名前を意味する 年 TYER レコーディングされた年を格納する コメント COMM オーディオファイルに対するコメントを格納する – 19 – 3.6 データベースへの記述 また曲名（タイトル ）はファイル名で表す．各フレームの識別子から取得する情報を判別 し ，情報が存在しない場合は，年・コメント以外は ”Unkown” ，年・コメントはそのまま 空白とする．そして，取得した情報を属性として，RDB へ体系的に記述する． 3.6 データベースへの記述 情報を RDB へ体系的に保持させるために正規化を行う． RDB に属性間の関係を記述するため，ID3 タグから取得した属性情報とファイル名にお ける関係を明確にする．そして，非正規形であった ID3 タグの属性情報を正規化することで データの体系的に保持させる． 次に，ファイルシステムから参照するテーブルを定義する．ファイルシステムからは「 1 対多 」の関係が 求められ るため，ビューテーブ ルを用意することで 対応する．図 3.6 に ビューテーブルの例を示す．このビューテーブルはファイル名と属性の関連を記述している． file name はファイル名，name はファイルの属性の値を表す．以下のような，属性情報を 持ったファイルを記述している． • ファイル名： you.mp3 – アーティスト：YURIA – ジャンル：Anime Best – アルバム：Anime • ファイル名：style.mp3 – アーティスト：YURIA – ジャンル：Game Best – アルバム：Game • ファイル名：せかいにさよなら .mp3 – アーティスト：Marica – ジャンル：GWAVE 2005 –2nd Impact– – 20 – 3.7 ファイルシステムへの写像 – アルバム：Game この場合，Artist「 YURIA 」には「 you.mp3 」と「 style.mp3 」という二つの曲（ファイル ） が所属する．同様に，Genre「 Anime Best 」には「 you.mp3 」が所属する． 図 3.6 ビューテーブル 3.7 3.7.1 ファイルシステムへの写像 ディレクト リの親子関係 本研究で写像するファイルシステムのディレクトリ構造は，属性を表すキーとその値（バ リュー）の繰り返しである (図 3.7，図 3.8，図 3.9)．キーはテーブル名，バリューは name の値になる．キーディレクトリ下にバリューディレクトリが存在し，バリューディレクトリ の下にファイルと，上位ディレ クト リで選択したキーを除くキーディレ クト リが存在する． また，ルートには全てのキーディレクトリとファイルが存在する． – 21 – 3.7 ファイルシステムへの写像 つまりビューテーブルのテーブル名と name の値，name の値と file name の値でディレ クトリ構造での親子関係を表現している． 3.7.2 ファイルの絞り込み ファイルの絞り込みはパスを基に 行う．例えば ，/Artist/YURIA/Genre/Anime とい うディレ クト リパスでは ，Artist に「 YURIA 」，Genre に「 Anime 」とい う両方の属性 情報を 持つファイルが 絞り込まれ る ．こ の よ うに ，複数の 属性で ファイル を 絞り込 む ことがで き る．し かし ，上位で 選択し たキ ーのディレ クト リは 以降では 存在し な いの で，/Artist/YURIA/Artist/Marica というような，同じ属性での絞り込みはできない． ファイルを絞り込むクエリを以下で説明する． ファイルの絞り込みは SELECT 文と条件文で DB から該当するファイル名を検索する． 1. ルートディレクトリでの検索 ルートではすべてのファイルが存在するため，ファイル名を記述しているテーブル file に存在するファイル名 (file name) とそのファイルパス (path) を全て検索する．ディ レ クト リは，キーとなる属性が記述されているテーブル attribute から全ての値を検 索する．attribute に記述されている情報は図 3.6 のにおけるビューテーブル名である． ファイル名を検索するクエリは図 3.7 のファイル名 a，ディレクトリを検索するクエリ はディレクトリ a である． 2. キーディレクトリでの検索 ルートで選択したディレクトリ直下ではファイルの絞り込みは行われない．ディレクト リはルートで選択したキーのバリューである．図 3.7 では，Artist を選択しているた め，その値である「 YURIA 」と「 Marica 」というディレクトリ名が検索される．この ディレクトリを検索するクエリはディレクトリ名 b である．このクエリはビューテーブ ル Artist から属性の値を全てを検索する（ DISTINCT は重複する値を除く）． – 22 – 3.7 ファイルシステムへの写像 図 3.7 デ ィレクトリ構造 1 3. バリューディレクトリでの検索 バリューディレ クト リにはキーディレ クト リと絞り込まれたファイルが存在する（ 図 3.8 ）．ここでのキーディレクトリは，上位階層で選択されたキーディレクトリが除かれ る．ここでのキーディレクトリを検索するクエリはディレクトリ c になる．また，ファ イルは Artist「 YURIA 」という属性情報を持つファイル名とファイルパスを検索する． このクエリはファイル名 b である．上位ディレクトリで検索されたファイル名からのみ ファイルを絞り込むため，サブクエリを使用する． 4. 複数属性での絞り込み 複数の属性で絞り込む場合，バリューディレ クト リより任意のキーディレ クト リを下 る．図 3.8 では /Artist/YURIA/Genre とディレ クト リを探索している．この Genre ディレクトリ下のディレクトリを検索するクエリはディレクトリ名 d になる．YURIA 下に存在するファイルが持つ Genre の値を検索するため，サブ クエリを使用する．更 – 23 – 3.7 ファイルシステムへの写像 に，Genre/Anime とディレ クト リを下る（ 図 3.9 ）．ここでのディレ クト リは Artist， Genre 以外の属性が存在し，それを検索するクエリはディレクトリ e になる．ファイル の検索は Artist「 YURIA 」かつ Genre「 Anime 」という属性情報を持つファイルが検 索される．クエリはファイル名 c である． 図 3.8 デ ィレクトリ構造 2 以上のファイルを検索するクエリは階層を下る毎に WHERE 句での条件文の長さが長く なるため，条件文の長さで階層の深さを表現できる．つまり，サブクエリを使用することで 階層構造を持たせている．また，参照するテーブル名 (FROM Artist) と条件文 (WHERE name=’YURIA’) で選択したディレクトリを表現している． – 24 – 3.8 RDB とファイルシステム間の通信 図 3.9 デ ィレクトリ構造 3 3.8 RDB とファイルシステム間の通信 本研究の目標とする情報管理システムの概要を図 3.10 に示す． RDB とファイルシステム間の通信を行うため，中間にサーバを設ける．サーバに必要な 要素を以下に挙げる． • カーネル空間との通信手段 • 受け取ったパスをクエリに変換する手段 • クエリによって RDB に問い合わせる手段 動作の概要を以下に示す． 1. DB に接続する 2. カーネル空間との通信の準備を行う 3. 通信処理 – 25 – 3.8 RDB とファイルシステム間の通信 図 3.10 システムの概要 （ a ）カーネル空間からの通信を待つ （ b ）パス名をカーネル空間から取得 （ c ）パス名をクエリに変換 （ d ）生成したクエリによって RDB に問い合わせ （ e ）バッファに検索結果を格納 （ f ）結果からディレクトリ名を抜きだしカーネル空間へ送出 （ g ）受け取り確認後、ファイル名とそのパスを結果から抜きだしカーネル空間へ送出 4. DB を閉じる 本研究で実装したのは，クエリの発行，検索結果のバッファへの格納と DB との通信部であ り，カーネル空間との通信部は別研究 [9] で実装を行っている． – 26 – 3.9 実装環境 3.9 実装環境 以下に実装環境を示す． • OS : Linux • 使用言語 : C 言語 • RDBMS : SQLite 3.10 サーバの実装 ファイルシステム側からパスが送信されるので，それを基に 3.7.2 に示したクエリを発行 する．ファイル名 a とディレ クト リ名 a はパス “/” を基にクエリ発行している．同様に， ディレ クト リ名 b は “/Artist”，ファイル名 b とディレ クト リ名 c は “/Artist/YURIA”， ディレ クト リ 名 d は “/Artist/YURIA/Genre”，ファイル 名 c とディレ クト リ 名 e は “/Artist/YURIA/Genre/Anime” を基にクエリを発行する． これらのクエリで RDB からファイル名，ファイルパス，ディレクトリ名を検索する．そ して検索結果をバッファに格納し，ファイルシステム側へ送信する．一つパスに対して送信 するバッファ二つあり， 「ディレクトリ名」と「ファイル名・対応するファイルパス」を格納 する．また，バッファのヘッダには，それぞれディレクトリの数，ファイルの数の情報が格 納さている． 以上の処理をサーバの DB との通信部に実装した． 3.11 結言 本章では，MP3 ファイルに付随する ID3 タグの情報を RDB に記述し ，ファイルシステ ムのディレクトリ構造へ写像する方法を述べた．次章では，RDB により体系化されたファイ ルの属性情報を利用した動的ディレクトリ構造を持つファイルシステムの動作結果を示す． – 27 – 第4章 動作確認 4.1 緒言 本章では，体系化を行った属性情報を利用したファイルシステムの動作を見る． 4.2 動作確認 ファイルシステムで，実際に意味情報を名前として持つディレクトリが作られ，かつディ レクトリを下ることでファイル整理が行われているか確認を行った． CUI(bash) で確認を行った．図 4.1 はファイルシステムのマウントポイントでの ls コマ ンド を発行した際の表示である． 絞り込みを行っていないので，ここでは，ディレクトリと全てのファイルが表示されてい る．次に，図 4.2 にファイルを絞り込む過程を示す． Artist，続いて Year でファイルを絞り込む．その結果，選択した属性情報を持つファイ ルを絞り込め，分類が行われていることを確認した． CUI だけでなく GUI(ファイルブラウザ) で同様にディレクトリをたどった．同様に分類 されることが確認できた (図 4.3)． また，通常のアプリケーションでファイルが実行できるかを確認する．ここでは，図 4.4(a) で示すように，xmms を用いて，ファイルシステムのマウントポイントからディレクトリを 下り，ファイルの追加が行えるかを見る．ここでも，同様にファイルが分類され，音楽ファ イルも問題なく再生されることを確認した (図 4.4(b))． – 28 – 4.2 動作確認 図 4.1 動作結果 CUI – マウントポイントでの ls 図 4.2 動作結果 CUI – 絞り込み – 29 – 4.2 動作確認 図 4.3 動作結果 GUI – 動作結果ファイルブラウザでの利用 図 4.4 音楽ファイルの探索と実行 – 30 – 4.3 結言 以上より，アプリケーションに依存することなく，多様な基準でファイルが分類されるこ とを確認した． 4.3 結言 本章では，本研究で体系化した属性情報を利用したファイルシステムがアプリケーション に依存せず，CUI，GUI のど ちらでも利用可能であることを確認した．次章では，全体のま とめを行う． – 31 – 第5章 結論 情報化が浸透している現在において，爆発的に増大した情報を取り扱う際，膨大な情報を 分類する作業や，適切な情報を検索する作業等の，情報管理方法が必要となる． 本研究では従来の情報管理における問題点を分析し，特定のアプリケーションに依存せず 情報を参照できるファイルシステムと，ファイルの持つ意味情報を体系的に表現，保持，参 照できる RDB に注目した．さらに，ファイルシステムのディレクトリ構造を動的に変化さ せ，RDB に保持している情報を参照，利用することで，ファイルの多様な整頓が可能な情 報管理システムを提案した． 本研究ではファイルに付随するメタ情報をファイルの属性情報として扱った．そのデータ は通常，非正規形であり，また静的な木構造には写像できない．そのような情報の例とし て，ID3 タグというメタ情報が付随する MP3 ファイルを取りあげた． ID3 タグからファイ ルの分類に必要な情報を取得し，それぞれの属性間の関連，属性情報とファイル名との関連 を RDB へ記述した．また RDB に体系的に記述した情報を，ファイルを整理する際の整頓 ポリシとしてファイルシステムで利用するために，記述した情報をディレクトリ構造へ写像 した．そして，RDB と動的なディレクトリ構造を持つファイルシステムを繋げ，動作の確 認を行った．その結果，本研究の目標とした情報管理システムで情報の管理を行うことによ り，従来の静的なディレクトリ構造を持つファイルシステムでは表現が困難であったファイ ルの多様な分類が可能になることを確認した． 今後の課題は，次の通りである． • 属性情報の編集を行うインタフェースの提供 – 32 – ファイルの属性情報は不変とは限らない．また，ファイルのメタ情報に情報を記述して いない場合もある．そのため，ユーザが任意のファイルの情報を追加・変更・削除と いった作業を行う機会があると考えられる．現状ではすでに DB に記述してある情報を 編集する作業は直接 DB を操作する必要がある．また，ファイルを DB へ追加するに は直接，情報を取得し DB へ挿入を行うプログラムを実行しなければならない．そこ で，ファイルの追加やファイルの属性情報の編集を行うためのユーザインタフェースを 設計，実装することが必要となる． • 他のファイルへの対応 本研究では，例として MP3 音楽ファイルを取り上げた．対応しているのは音楽ファイ ルのみで，他タイプのファイルへの対応はできていない．そのため，音楽ファイル以外 のファイルの属性情報を対応させる方法を考える必要がある． MP3 ファイルには ID3 タグというメタ情報が付随しているため情報の取得が容易で あった．しかし，メタ情報を持たないファイルも存在する．そのため，メタ情報を持た ないファイルの属性情報をどの様に決定するかも考えなければならない． 以上の課題を解決し，情報をより管理しやすい方法を検討している． – 33 – 謝辞 指導教員である高知工科大学情報システム工学科 酒居敬一 講師には，本研究の指導のみ ならず，社会人としての生き方から心構えに至まで多大なるご指導を頂きました．心より厚 く御礼申し上げます． ご 多忙な中，本研究の副査をお引き受け頂きました同学科，高田喜朗 講師，妻鳥貴彦 講 師に心より厚く御礼申し上げます． また，情報システム工学科の諸先生方には，お忙しい中，貴重な時間を割いていただきな がらも，有意義なご意見，ご助言を頂きました．深く感謝致します． 酒居研究室において日頃から多くの御助言，御支援を頂いた大学院修士課程の小糸啓介 氏に心から感謝致します． 研究室配属時から終始お世話になり，研究に行き詰まった時に相談を受けて頂きました， 学部四回生 大崎史裕 氏，柴田淳一郎 氏，高橋浩太朗 氏，田所光平 氏，田内一吏 氏，渡辺 直貴 氏に心から感謝の意を表します． 日頃から暖かいご支援，ご協力を頂きました学部三回生 川又悠 氏，柴田昌典 氏，西尾花 織 氏，宮元裕樹 氏に感謝致します。 最後に ，いつ何時でも心の支えてとなって下さった清浦刹那 氏に心より深く感謝致し ます． – 34 – 参考文献 [1] 有次正義 「 マルチ メディア時代のデータベース索引技術」 『 情報処理 vol.42 No.10 』 pp.951-952, 2001． [2] 都司達夫，宝珍輝尚 『データベース技術教科書 – DBMS の原理・設計・チューニング 』 （ CQ 出版社，2003 年）． [3] 堀井秀之 「 社会問題解決のための知の構造化」 『 情報処理 vol.48 No.8 』pp.819-823, 2007． [4] 滝田裕，多田好克 「ファイル内容に基づくインクリメンタルな名前空間生成」 『 情報 処理学会研究報告．[システムソフトウェアとオペレーティング・システム] Vol.2004 No.63 』pp.23-28, 2004． [5] David K. Gifford, Pierre Jouvelot, Mark A. Shldon, and James W. O’Toole, Jr.Semantic filesystems. In Proceedings of the thirteenth ACM symposium on Operating systems principles, pp.16-25. ACM Press, 1991. [6] Burra Gopal and Udi Manber. Integrating content-based access mechanisms with hierarchical file systems. In Proceedings of the third symposium on Operating systems design and implementation, pp.265-278. USENIX Association, 1999. [7] 大久保英嗣『オペレーティングシステム』 （ 株式会社オーム社，2005 年），pp.65-86． [8] id3v2.4.0 – structure， http://www.id3.org/id3v2.4.0-structure，最終アクセス 2007 年 2 月 14 日． [9] 大崎史裕， 「データベースに対するインタフェースとしてのファイルシステムの実装」 『高知工科大学 情報システム工学科 学士学位論文』2008（ 掲載予定）． – 35 –