2019/0121/計概IT分工&資料庫正規化

需求分析

質/量評估 SA/SD 可行性評估 PM 市場需求文件

設計

RD 軟體規格文件 RD 系統架構文件 QA 測試文件

實作整合

DB 進行分工

測試

輸入出正確性/操作複雜度/執行效率/錯誤容忍度/壓力測試/安全性...

維護

錯誤修正 / 根據現況需求擴充版本

螺旋式 瀑布式 開發模式 ...

語言特性 邏輯架構 表達方式

物件導向 UML 基於 OMT

屬性 定義物件資料

方法 定義物件行為

封裝 行為與資料直接定義在物件上

類別 物件的集合

階層 上階 EX 學生 下層 資工系學生

繼承 下階 繼承上階屬性與方法

設計步驟

遞迴重複

類別圖 活動圖

IaaS PaaS SaaS

NP-Complete

資料庫正規化

學號( primary key ) 姓名 性別 (科別代號) 年級 班級 電話 地址 2NF

書籍編碼( primary key ) 書名 作者 (出版商代號) 購買日期 借閱次數 是否借書 2NF

出版商代號( primary key ) 出版商 3NF 遞移相依

科別代號( primary key ) 科別名稱 3NF 遞移相依

流水號( primary key ) (學號 書籍編碼) 借出日 還書日 2NF 功能相依

功能相依 : 有我一定有他 、 衛生紙 跟 擦屁股 、 水 跟 擦屁股 、 關聯性 透過 A查到B 所以 B功能相依於A

部分功能相依 要兩個欄位才能決定

遞移相依 : 要兩個鍵頭才會指到他

遞移相依的主鍵在其他表單也有但不當主鍵使用

系統分析師 -> 規格書 -> 系統設計師

第三

BC正規化 BCNF 第三的延伸

學生資料 學號 姓名 身分證

課程資料 課號 學分 老師

選課明細 學號 身分證 課號

切完後發現

身分證 可以互相決定 學號 明明就可以互相取代

主鍵 學號+課號 OR 身分證 + 課號

就沒滿足 BC正規化

具代表性 短的 但卻不用短學號而 使用 身分證字號 當主KEY 原因為 (不會重複)

Last updated