敏捷開發框架下的軟體工程/第二階段/資料建模
| 資料建模 |
|
 |
資料是...
為什麼有人認為資料是最重要的東西
系統的靜態結構 - 就像地圖一樣
資料庫方法的優勢 程式-資料獨立性 最小化資料冗餘 改進資料一致性 改進資料共享 改進資料質量 降低程式維護成本
建模過程
資料建模是設計 需要創造性的解決方案 資料模型是需求的一種解決方案
資料建模很重要 需要藍圖來建造房子
資料建模是一門學科 需要專業的判斷
資料建模貫穿整個開發過程。 
實體關係模型: 實體和關聯的詳細圖形表示
關注點純粹是資料 不是資料發生的事情 描述資料的形式 不是資料值 特定於業務需求
人、地點、物體、事件、概念，對組織來說很重要 單一、明確的名稱 學生、書籍、產品
時間 空間 模糊的
一個或多個實體型別例項之間的關聯 名字 強大 用一句話來描述關係 可能有屬性 - 關聯實體
一本書被一位讀者借閱 一位讀者可以借閱一本書
概念模式 對資料庫整體結構的詳細、與技術無關的規範 物理模式 從概念模式中儲存資料的規格說明，儲存在計算機的輔助儲存器中
假設我們正在開發一個高中記錄系統。從我們最初的需求確定階段，我們收集了一批材料：班級名單、個人成績單、班級成績等等。資料建模的任務是提取資訊的底層結構。這就是資料模型。
資料模型的核心是實體。實體是組織持有資訊的某樣東西。它可以是實際的東西，也可以是像概念（或學生成績）那樣不太具體的東西。請注意，這裡的“實體”描述的是事物的通用級別：因此是 STUDENT，而不是 Bob。Bob、Jane 和他們的朋友都是 STUDENT 的例項。
在我們簡單的學校裡，我們可以輕鬆識別出三個實體：STUDENT、TEACHER 和 COURSE。
每個實體都由屬性描述。這些屬性是我們用來描述每個實體例項的。屬性有嚴格的規則，它們需要是獨立的，並且不能重複資訊。它們還需要是原子性的（不能分解），並且不能依賴於其他值。
在下面的示例中，StudentName 不合適，因為它可以分解為姓和名；StudentAge 沒有必要，因為它可以計算出來（手動輸入會導致麻煩），StudentGrades 不是原子性的 - 它包含多個值 - 這將不起作用（我們稍後會回到這個問題）。
我們還需要一種方法來唯一地識別每個例項，這將成為實體的主鍵。它必須是不變的並且是唯一的。我們可以使用姓名，但儘管我們都感覺很特別，但我們的姓名並不唯一。我們可以將姓名與出生日期組合起來，生成一個連線鍵。不幸的是，日期非常難以處理（9 月 12 日的意義是什麼？），而且它不能解決我們的非唯一性問題。因此，我們必須使用一個新值：STUDENT_ID。
我們可以從這些屬性中獲取相同的資訊，並且資料結構更強大。
學生成績不僅僅是關於學生的資訊，它們是關於該學生與課程互動的資訊。
學生註冊的課程更難解決，但解決方案是基於資料（因此是資料庫）方法來理解業務並實施解決方案的核心力量。
在上面的示例中，Bob 只學習地理（明智的選擇），所以處理起來很容易。然而，Jane 學習了法語、地理和歷史。如果我們嘗試將這些資訊儲存在一個名為 Courses 的屬性中，那麼提取這些資訊非常困難 - 雖然很容易獲得 Jane 的課程列表，但獲得學習地理的人員列表將非常困難（並且涉及複雜的字串操作等）。
資料建模的真正優勢在於識別關係。關係描述實體之間的關聯。我們從在實體之間畫一條線開始
我們可以看到 STUDENT 和 COURSE 以及 COURSE 和 TEACHER 之間存在明確的關係。我們可以在圖上表示這些關係。沿著箭頭方向閱讀，這些關聯可以用句子表達：“一位 STUDENT 學習這門 COURSE”、“一門 COURSE 由一位 TEACHER 教授”。（我們稍後會討論數量，當我們檢視基數時）。
然而，STUDENT-TEACHER 關聯並不那麼清晰。關係（至少是我們這裡考慮的關係）已經由模型表達。我們可以透過他們教授和註冊的 COURSE 來提取哪個老師教授了哪些學生。我們不需要顯式的 STUDENT-TEACHER 關係。
即使在這個層面的考慮中，我們也正在被迫仔細考慮我們正在處理的業務。我們可以描述一個 STUDENT-TEACHER-COURSE 模型。為什麼我們選擇沒有 STUDENT-TEACHER 關係而不是沒有 STUDENT-COURSE？
我們還需要表達可能參與關係的例項數量。我們使用“烏鴉腳”來做到這一點，烏鴉腳在多端。
這裡我們有“許多 STUDENTS 可能學習許多 COURSES”，或者反過來，“許多 COURSES 可能被許多 STUDENTS 學習”。我們在圖上用“烏鴉腳”（掛在多端）來表示“許多”。
在概念模型開發的早期階段，擁有這樣的關係是可以的，但我們需要做更多工作才能使其有用。像這樣的雙端烏鴉腳被稱為“非特定關係”，我們知道我們有很多學生和很多課程，但不知道誰在學習什麼。
解決這些不連線列表的一種方法是在每個課程的屬性中包含學習該課程的人員姓名（如下）。不幸的是，這也不起作用。當有人註冊的課程比您之前考慮的更多時會發生什麼，結果實際儲存在哪裡，我們仍然沒有辦法找出誰註冊了地理。
我們需要一個新的實體來表示這種關係。這被稱為關聯實體。
我們可能在早些時候就識別出來了，因為它在“事物性”方面真的很強。STUDENT 和 COURSE 之間的關係本身也有一些引數：日期、結果、也許還有內部評估成績等等。關係具有屬性這一事實表明它實際上是一個實體。
我們再次回到這個過程在理解業務中的價值。它僅僅是一個實體嗎？我們可以想到幾個可能的實體名稱 - 它們是同一個東西嗎。
在某些情況下，多個名稱表示多個關聯 - 人力資源經理授權支付薪酬（一種關係），但她自己也在工資單上。
這個中間實體顯示了學生和課程之間的關聯，即註冊。當我們實現模型時，註冊實體（表）不包含學生的姓名或課程——計算機可以非常有效地獲取它們。相反，我們只使用其他實體的主鍵——它們會變成外部索引鍵。
但是，我們的模型存在一個缺陷。Jane Smith 似乎在歷史課上註冊了兩次。這不是錯誤（除了 Jane），而是她第一次考試不及格。為了允許這種情況發生，我們需要表示更多資訊，即註冊年份。我們的模型可以生成所需的資訊，隨著開發的進行，它將變得更加有用，因為我們努力使其定義更加嚴格。
功能需求的主要重點是過程本身，透過開發這樣的模型，我們被迫仔細考慮我們正在處理的業務。
此模型描述了工程公司的作業管理系統。
另一個小組為同一個系統製作了這個模型。
圖書館系統。在開發這個模型時，大多數人會想到“書”，但“書”在不同的情況下有不同的含義。是實際的書被借出，但人們實際上想讀的是“書名”（以及特定類別，例如大字版）。請注意專案和使用者之間關於借閱和預約的兩種關係。
該系統描述了農業環境規劃系統。
