好壞資料庫結構 (database schema) 的差異是什麼?
好的資料庫結構 (database schema) 和壞的資料庫結構在多個方面存在顯著差異，這些差異會直接影響資料庫的效能、可維護性、擴展性和數據完整性。並且當開發系統時，好的資料庫結構可以讓程式容易撰寫及維護，而壞的資料庫結構可能讓程式變得很龐大，並且無法在變更系統需求時還能修改維護。 以上的說法，可能很難以理解，我們用實際的例子來說明。 我們用農民曆上的食物相剋圖來設計資料庫結構，狀況及需求如下 : (1)當兩個食物一起吃，會造成不適的症狀，例如拉肚子或是中毒。 (2)可以透過解毒物來解除不適的症狀。 我們先抓出物件 : 食物、解毒物、不適的症狀。 因此會有一個食物的資料表單，然後會有解毒物的資料表單，至於這兩個物件是應該兩個資料表單，還是合成一個資料表單，後面再來決定。 不適的症狀也會是一個資料表單，裡面會有兩個食物的欄位，如果症狀用文字表示，有違反正規化的情況，因此不適症狀資料表單中以症狀id來關連到另外一個症狀表，會比較恰當。 最後，特定症狀需要使用特定解毒物，也會形成一個解毒的資料表單。 綜合以上，形成資料表單如下 : Food（食物）：包含食物id、食物名稱和描述等資料。 Interaction（相剋反應）：包含反應id、兩種食物的id和症狀id。 Symptom（…
B2B網站的資料流流向圖(Data Flow Diagram)與實體關係圖(Entity Relationship Diagram)應該怎麼畫?
之前練習過了 進貨單的DFD及ERD ，也練習過了 線上商店的UML ，現在來看看B2B網站的Data Flow Diagram跟線上商店有何差異。
Data Flow Diagram (DFD) 與 Entity Relationship Diagram (ERD) 實作練習
假如有進貨單格式如上，以往都是人工製作表單，現在老闆要我把這個作業電腦化，我應該怎麼做呢? (仔細檢視上面的進貨單，如果A公司要運送貨物給B公司，對A公司來說是出貨單，對B公司來說才是進貨單。出貨單才會需要運送地址，進貨單只需要供應商編號或是名稱。除非進貨會到不同倉庫，例如B公司有台中倉庫以及台南倉庫，以下分析過程先忽略進貨地址。)
UML練習範例 : 線上商店 (Online Shopping) 的Use Case Diagram/Activity Diagram/ER Diagram/DFD/Class Diagram
(系統開發流程 : 計畫 > 分析 > 設計 > 建置 > 測試整合 > 上線&維護) 現在我們用一個實際的例子來說明系統分析與設計的過程。
UML的使用案例圖、活動圖、類別圖練習 ~ 以網路選課為例
需求 : 我們希望開發一個提供學校學生可以在網路上選課的系統。 (1) 首先把需求畫成「使用案例圖 Use Case Diagram」。 使用案例圖的相關資訊，可以參考 : https://www.lucidchart.com/pages/uml-use-case-diagram
