| | 1 | [[TOC]] |
| | 2 | = andmylife / 設計 / サーバー / データモデル = |
| | 3 | |
| | 4 | * アプリケーション上で投稿されるデータは、更新・参照ともに活発に行われる。 |
| | 5 | |
| | 6 | == 参照に関わる考察 == |
| | 7 | |
| | 8 | '''card''' は、複雑な条件での抽出に応えられるように構造化さればならない。 |
| | 9 | |
| | 10 | この点については、データウェアハウスなどで採用されるスター・スキーマを意識し、一部、設計に取り入れる。 |
| | 11 | |
| | 12 | 具体的には、 '''card''' は '''user''', '''item''', '''action''', '''motivation''', '''counterpart''' などの属性を'''ディメンジョン'''として持つ。 |
| | 13 | |
| | 14 | ただし、ユーザーは、基本的には'''文章'''として '''card''' へ記入する。 |
| | 15 | |
| | 16 | システムは、'''文章'''から推測した属性をユーザーに提示する。 |
| | 17 | |
| | 18 | ユーザーは、確認と訂正をする。 |
| | 19 | |
| | 20 | === ディメンジョン === |
| | 21 | |
| | 22 | 内部構造を持たせたい'''ディメンジョン'''は、エンティティとして独立させる。 |
| | 23 | * 例えば、tag, action は、コンテキストによる揺らぎ(同字異議/同義異字など)を持つので、エンティティとする。 |
| | 24 | |
| | 25 | === 捨てたアイディア === |
| | 26 | |
| | 27 | 汎用の属性テーブルを導入することも考えられるが、それは選択しない。 |
| | 28 | |
| | 29 | その理由: |
| | 30 | |
| | 31 | 1. 汎用の属性テーブルは正規化に逆行するものであり、参考文献によると、'''ディメンジョン''' でも '''ファクト''' でもない '''ファクトディメンジョン''' と呼ばれ、要注意とされている。 |
| | 32 | 2. Django での Models 定義が、明快さを失ってしまう。Django の設計思想にも反する(ような気がする)。 |
| | 33 | |
| | 34 | |
| | 35 | == 更新に関わる考察 == |
| | 36 | |
| | 37 | 特に '''card''' の追加・更新をタイムラインで追えるようにすることが、サービス上重要である。 |
| | 38 | |
| | 39 | このため、 '''card''' の属性の改変履歴を記録する。 |
| | 40 | |
| | 41 | ユーザーの'''文章'''も、この改変番号とを関連付けて記録する。 |
| | 42 | |
| | 43 | |
| | 44 | == card の構造の概念図 == |
| | 45 | |
| | 46 | http://www.gliffy.com/publish/1600050/ |
| | 47 | |
| | 48 | |
| | 49 | == ER 図 == |
| | 50 | |
| | 51 | http://www.gliffy.com/publish/1570130/ |
