andmylife / 設計 / サーバー / データモデル
- アプリケーション上で投稿されるデータは、更新・参照ともに活発に行われる。
参照に関わる考察
card は、複雑な条件での抽出に応えられるように構造化さればならない。
この点については、データウェアハウスなどで採用されるスター・スキーマを意識し、一部、設計に取り入れる。
具体的には、 card は user, item, action, motivation, counterpart などの属性をディメンジョンとして持つ。
ただし、ユーザーは、基本的には文章として card へ記入する。
システムは、文章から推測した属性をユーザーに提示する。
ユーザーは、確認と訂正をする。
ディメンジョン
内部構造を持たせたいディメンジョンは、エンティティとして独立させる。
- 例えば、tag, action は、コンテキストによる揺らぎ(同字異議/同義異字など)を持つので、エンティティとする。
捨てたアイディア
汎用の属性テーブルを導入することも考えられるが、それは選択しない。
その理由:
- 汎用の属性テーブルは正規化に逆行するものであり、参考文献によると、ディメンジョン でも ファクト でもない ファクトディメンジョン と呼ばれ、要注意とされている。
- Django での Models 定義が、明快さを失ってしまう。Django の設計思想にも反する(ような気がする)。
更新に関わる考察
特に card の追加・更新をタイムラインで追えるようにすることが、サービス上重要である。
このため、 card の属性の改変履歴を記録する。
ユーザーの文章も、この改変番号とを関連付けて記録する。
card の構造の概念図
http://www.gliffy.com/publish/1600050/
