Day 06 把 VoCare 的資料流整理完成之後，下一個問題就是：

這些資料進到後端之後，到底要怎麼存？

目前 VoCare 的資料可以先整理成：

使用者資料
→ 對話紀錄
→ Memory / Context
→ 問卷資料
→ 鏡頭觀察資料
→ Status Event
→ Trend Analysis

VoCare 裡的資料其實不是同一種類型。像是長者和 AI 的聊天，需要保存完整的對話內容；而從聊天中整理出的興趣、家庭、工作經歷等資訊，則比較適合另外存成 Memory。至於「最近睡不好」、「這幾天比較少出門」這類短期狀況，則不適合直接當成永久記憶，而是要另外保存成近期狀況資料。

所以在資料庫設計上，聊天紀錄和 AI 記憶會分開處理。每一次聊天可以用 Conversation 表示，而聊天中的每一句內容則保存成 Message。這樣之後不管是要重新查看完整對話，還是從某一段對話中重新萃取資訊，都可以找到原始資料。

當系統從聊天中發現具有長期價值的內容，例如長者的興趣、家庭、過去工作或重要人生經驗，就會另外整理成 Memory。每一筆 Memory 除了內容之外，也會保存來源，這樣之後還能知道這筆記憶是從哪一次聊天產生的。

另一邊，聊天、問卷和鏡頭其實都可能產生「近期狀況」。例如聊天裡提到睡不好、問卷裡睡眠品質較差，或鏡頭觀察到某些活動變化。這些資料來源不同，但最後都可以整理成統一的 Status Event。

Status Event 可以包含：

使用者、時間、類型、內容、資料來源以及原始資料位置。

例如：

9/21｜睡眠｜聊天｜提到昨晚睡不好

或：

9/22｜睡眠｜問卷｜睡眠品質較差

這樣做的好處是，後面的趨勢分析就不需要分別去讀聊天、問卷和鏡頭資料，而是可以直接分析整理好的 Status Event。

當 Status Event 累積之後，系統就能進一步計算最近 7 天、14 天或 30 天的變化，產生 Trend Analysis，最後再提供給家屬端使用。

所以目前 VoCare 的資料大致可以分成四層：

原始資料：聊天、問卷、鏡頭
→ 長期資料：Memory
→ 近期狀況：Status Event
→ 分析結果：Trend Analysis

這樣的設計可以讓不同用途的資料分開保存，但又能透過使用者 ID、時間和來源互相連結。

簡單來說：

Memory 負責記住「這位長者是誰」。

而：

Status Event 負責記錄「這位長者最近發生了什麼」。

最後 Trend Analysis 再負責回答：

「最近和以前相比，有沒有什麼變化？」

這就是目前 VoCare 資料庫設計最核心的方向。