とりあえずのデータチェック終了

ようやく受領したデータのチェックがひと段落つきました。
ＮＤＡの関係上、具体的な分析結果などについてはここでは詳しく触れられませんが、わかったことや今後の方針についてまとめていきたいと思います。
アドバイスなどございましたら、コメント・ＴＢやメールなどでいただけましたら幸いです。

◆データの中身について
・後ろの方で記述する原因により、正確な分析が出来ているとはいい難い。今回の結果はあくまでも傾向を把握し、今後の分析方針を立てるためだけのために用いる。
・ＤＢ１はデータ件数が少なかったため、タグの機能分類などである程度目検でトライすることができそうである。
・ＤＢ２はデータ件数が多いため、完全に機械に頼らざるを得ない。
・タグはＤＢ１・２ともに独立しているものは少ない。逆にレビューの対象はそれぞれ半数近くが独立している。

◆データフォーマットについて
フォーマットについては変更を要望することとなる。
要望とその原因をペアにして挙げる。
1)基本はカンマ区切り（CSV)形式でなくタブ区切り(TSV)形式とする
→ユーザの書き込みやURL情報などで","（カンマ）が使われることが多く、どのプログラムに読み込ませてもデータが崩れる場合があった。

2）テーブルをもう少し細かく分ける
→タグなど、レコードによって収録数が異なる項目は1フィールドに複数個格納するため、以下のようなフォーマットになっていた。

前のフィールドのデータ,"tag1,tag2,tag3,tag4",次のフィールドのデータ,

"ダブルクォーテーション"で囲むというやり方である。
このまま（上の例でいうと4つのタグを）1フィールドに読み込んでも全く分析できないため、

a:IDフィールドとタグのフィールドだけACCESSで切り出して別途テキストファイルを作成
b:そのテキストファイルをエディタで開き
c:"を置換で消去。増えた分のフィールドタイトルを1行目に追記
d:あらためてACCESSで読み込む

という作業を行っていた。
しかし、,(カンマ)や"（ダブルクォーテーション）が含まれたデータがあちこちにあるため、列区切りがずれ、aの時点ですでにデータがぐちゃぐちゃになるという事態になった。
そのため、もともとテーブルを細かく分け、別々にインポートすることでこうした事態を避けようと思います。

◆今後の分析方針
・基本的にはデータ件数の少ないＤＢ１でいろいろトライして、その中で有効な手法と思われたものからＤＢ２でもやってみるという手順をとる。
・とりあえずはクロス集計、コレスポンデンス分析、相関分析の３つを試してみる。ただし、上位のものに限定してまずは実施する。
・用いるアプリケーションはまずはACCESS(SQL)･SPSSで出来るところまで進める。そのあとはRにトライすることも想定。いきなりあれこれ手を出してどっちつかずになるよりも、１つの手段でどこまで出来るかきちんと突き詰める形でいこうと思います。