8.3 實體、屬性與識別碼
資料分析與資料建模
8.3.1 資料實體
實體是系統需要獨立辨識及保存資訊的業務事物。實體名稱應採一致、具體的名詞。如果是使用英文，應該使用單數的名詞。例如「報名」而不是模糊的「報名資料」。
實體是分析概念，不等同於資料庫資料表。後續設計可能把一個實體拆成多張資料表，也可能因技術因素整合儲存。不應將實體關係圖視為與資訊系統的資料庫資料表，兩者仍有差異。在目前階段，也不必全面性的考慮資料庫資料表要如何設計。
8.3.2 屬性
屬性描述實體需要保存的特徵，例如報名編號、提交時間與報名狀態。好的屬性應具有明確意義、資料型態及適用限制。
| 屬性類型 | 說明 | 範例 |
|---|---|---|
| 必要屬性 | 每筆資料都必須有值 | 報名編號 |
| 選擇性屬性 | 特定情況下才有值 | 結果確認時間 |
| 衍生屬性 | 可由其他資料計算 | 評分總分 |
| 複合屬性 | 可分解為更小部分 | 聯絡地址 |
| 多值屬性 | 同一實體可能具有多個值 | 多個聯絡方式 |
實際的資料庫要如何設計與保存衍生資料或多值資料，必須考慮一致性及實際查詢需求，不能只因為目前的畫圖方便而決定。目前階段仍不需要確認資料庫資料表要如何設計。
8.3.3 識別碼與候選鍵
識別碼用來唯一區分實體實例。可唯一識別資料的屬性或屬性組合稱為候選鍵；從中選定的主要識別方式，可在概念模型中標為主識別碼。
舉例來說，在Case M01中，不同參賽隊伍可能選擇相同的隊名，因此團隊名稱可能重複，因此不適合單獨識別報名。系統產生的RegistrationId可以作為報名的候選識別碼。分析階段只需確認「必須唯一辨識」，不必決定資料庫採用整數、通用唯一識別碼（Universally Unique Identifier, UUID）或其他技術格式。這留待設計資料庫資料表才處理。
8.3.4 屬性命名與定義
系統分析者應該幫屬性的命名與定義設定規則，例如規定資料字典則應同時提供中文名稱、英文名稱、定義、型態、必填性及來源，避免僅憑欄位名稱猜測意義。
如果開發的資訊系統有舊版，或者已有關聯的資訊系統，在屬性命名可能有一些歷史因素要納入考量。某些時候可能會希望沿用目前使用中舊系統的資料字典，也可能希望優先採用其他使用中資訊系統的資料字典。或者可能決定採用文字加數字編號的屬性命名。
如果沒有這些限制，資料字典中的屬性命名應採用易於從字面上了解的命名。例如，本書圖例中的英文屬性名稱採大寫字母開頭，如RegistrationId、SubmittedAt與Status。