1.用戶管理
(1).管理員
添加:
更改:
刪除: 邏輯是刪除,不讓登錄,爲得是不破壞賬目記錄
(2).普通用戶
更改: 登錄名,姓名,密碼等等
2.類別管理
(1).大類管理
添加:
更改:
刪除: 有帳目記錄的不能刪除,只能修改
排序: 爲了輸入的方便,地時要適當的人性化
(2).小類管理: 附屬於大類
添加:
更改:
刪除: 有帳目記錄的不能刪除,只能修改
3.帳目管理
(1).收入
添加: ①沒有日賬，要先添加日賬;②有日賬，在其下添加明細帳.最好有備註或是日記
更改:
刪除: 刪除前要確認
(2).支出
添加: ①沒有日賬，要先添加日賬;②有日賬，在其下添加明細帳.最好有備註或是日記
更改:
刪除: 刪除前要確認
4.節日管理
添加:
更改:
刪除: 有帳目記錄的不能刪除，只能修改
5.分析統計
查看: 根據不同的要求,出現不同統計表,可以以文檔的形式保存
6.系統管理
備份: 數據庫的備份
其它: 隱喻
關係數據庫：
先簡要地設計了七張表,先暫不考慮權限，多語言,
[USER用戶] 登錄後方可以記錄
[TOTAL總帳] 總的已收帳 已負賬 資產 現金 銀行款 基金
[BIGCLASS大類] 衣食住行消費類和收入分類
[SMALLCLASS小類]大類下的小類
[GALA特殊節日] 週末 法定假日 特殊節日等 （用於分析,更高地說就是加了一個時間維度）
[LIST日賬] 每日收支
[ITEM日賬明細] 每日收支明細
本設計的主鍵只用來表示關係，不含有現實意義，所有主鍵全是bigint 絕對夠用了吧 人能活100歲 每天買1000件東西，一年365天
1000*100*365=? 當然這是簡要的設計，其實我要做的並不是記錄工作，記錄是爲了更好地分析，然後怎樣去收支。
存在問題:
(1)收入和支出是不是要再關聯到個人
(2)總帳是不是又要分出個人
關係圖:
圖有點錯誤:
(1)USER表裏少一個字段USER_LEVEL
(2)ITEM裏少了一個LIST_NO
(3)應該是LIST_NO和LIST裏的LIST_NO對應)
