[[TOC]]
= andmylife / 設計 / サーバー / データモデル =

 * アプリケーション上で投稿されるデータは、更新・参照ともに活発に行われる。

 == 参照に関わる考察 ==

 '''card''' は、複雑な条件での抽出に応えられるように構造化さればならない。

 この点については、データウェアハウスなどで採用されるスター・スキーマを意識し、一部、設計に取り入れる。
 
 具体的には、 '''card''' は '''user''', '''item''', '''action''', '''motivation''', '''counterpart''' などの属性を'''ディメンジョン'''として持つ。

 ただし、ユーザーは、基本的には'''文章'''として '''card''' へ記入する。

 システムは、'''文章'''から推測した属性をユーザーに提示する。

 ユーザーは、確認と訂正をする。
 
 === ディメンジョン ===

 内部構造を持たせたい'''ディメンジョン'''は、エンティティとして独立させる。
 * 例えば、tag, action は、コンテキストによる揺らぎ(同字異議/同義異字など)を持つので、エンティティとする。

 === 捨てたアイディア ===

 汎用の属性テーブルを導入することも考えられるが、それは選択しない。

 その理由:

 1. 汎用の属性テーブルは正規化に逆行するものであり、参考文献によると、'''ディメンジョン''' でも '''ファクト''' でもない '''ファクトディメンジョン''' と呼ばれ、要注意とされている。
 2. Django での Models 定義が、明快さを失ってしまう。Django の設計思想にも反する(ような気がする)。


 == 更新に関わる考察 ==

 特に '''card''' の追加・更新をタイムラインで追えるようにすることが、サービス上重要である。

 このため、 '''card''' の属性の改変履歴を記録する。

 ユーザーの'''文章'''も、この改変番号とを関連付けて記録する。


 == card の構造の概念図 ==

http://www.gliffy.com/publish/1600050/


 == ER 図 ==

http://www.gliffy.com/publish/1570130/