好壞資料庫結構 (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
實機練習
需求~建立一個資料庫系統，紀錄公司的產品資料，並且記錄客戶的訂單、進貨、出貨、收款。 需要產出以下內容以及回答問題~ (因為答案不是只有一種，資料表結構不同，想法就可能不同) (1) 這個系統的ERD (2) 這個系統的資料表單結構(Schema) (3) 老闆想知道在某個時間區間內，哪個客戶購買金額最大?最少? 思考 : 從這個需求知道，需要一個客戶資料表(customer)，以及紀錄訂購的資料表，因為order是保留字，所以我們用order_main當訂購的表頭檔，用order_body當訂購的表身檔。 為何紀錄訂購資料需要訂購的表頭檔跟訂購的表身檔呢? 要知道某個時間區間內，哪個客戶購買金額最大?最少? 需要客戶資料表(customer)、order_main 與 order_body。 某個時間區間內，哪個客戶購買金額最大?最少? --> 從客戶資料表+訂購的表頭檔+訂購的表身檔，找到加總訂購金額最大( 最少 )的客戶名稱，條件是訂購資料在特定時間區間內。 (4) 老闆想知道目前總共還有多少應收款? 應收款最多的是哪個客戶? 思考 : 從這個需求知道，訂購的價錢需要紀錄已付或是未付，這個可以用一個欄位來表示，你可以…
什麼是DFD (Data Flow Diagram 資料流程圖) ?
資料流圖DFD是描述系統中資料流程的一種圖形工具，它標誌了一個系統的邏輯輸入和邏輯輸出，以及把邏輯輸入轉換邏輯輸出所需的加工處理。 資料流圖是從資料的角度來描述一個系統，他只描述WHAT而不描述HOW。所以資料流圖並不會看到詳細的程序流程，只看到程序與資料流的關係。 如果系統的規模較大，為了降低系統的複雜性，一般採取「逐層分解」的方法，繪製分層的DFD。 DFD的表示法 : DFD的範例 : 訂餐系統 Level 0 DFD (通常不包含 data store) Level 1 DFD (拆解Level 0 的程序) DFD 與 ERD 有何關係呢? 可以透過DFD的實體(Entity)與Data Store，知道應該包含那些資料。 在DFD之後，如果要更清楚的描繪整個系統，就可以使用 UML Diagram 。
如何將ERD轉換為邏輯資料?
(1) 把每個[實體]都做成一個[表單]，實體的[屬性]就是[欄位] ， 並訂下主鍵(PK)。 例如 : Person (person_id, Name, Lastname, Email, Phone) (2) 當存在多值屬性時(如Phone)，該多值屬性也變成一個表格。 例如 : Person (person_id, Name, Lastname, Email) 以及 Phone (person_id, phone_id, phone_number) (3) 當出現弱屬性時，該弱屬性可以由其他屬性得知，則該弱屬性不必成為一個欄位。 例如 : age可以由生日計算得知，age則不必成為一個欄位。 (4) 當實體A與實體B為 1:1 時，A表單加上FK連到B表單PK，或是B表單加上FK連到A表單 PK。 A(aid,a1,a2 …, bid) B(bid,b1,b2 …) 或是 A(aid,a1,a2 …) B(bid,b1,b2 …, aid) 以上A表單的bid為FK連接到B表單的bid (PK) 以上B表單的aid為FK連接到A表單的aid (PK) 例如 顧客 ~ 購物車關聯是1:1 (一個購物車對應一個顧客，一個顧客只能有一個購物車…
Database Design
(1)資料庫需求收集與分析 Requirement Collection and Analysis 使用的工具就是DFD (Data Flow Diagram 資料流程圖)，DFD是描述系統中資料流程的一種圖形工具，它標誌了一個系統的邏輯輸入和邏輯輸出，以及把邏輯輸入轉換邏輯輸出所需的加工處理。 值得注意的是，資料流圖不是傳統的流程圖或框圖，資料流也不是控制流。 參考 : https://www.visual-paradigm.com/tutorials/data-flow-diagram-dfd.jsp http://web.ydu.edu.tw/~alan9956/docu3/0992sa/sa04_dfd.pdf (2)資料庫概念設計 Conceptual Database Design 概念塑模(Conceptual Data Model)使用的工具，就是實體關係模型(Entity Relationship Model)，最後會產生實體關係圖(Entity Relationship Diagram)。 參考 : https://www.mysql.tw/2013/03/entity-relationship-model.html http…
Data Modeling (資料塑模) : 概念塑模、邏輯塑模、實體塑模
Data Modeling (資料塑模) 就是一種程序，用來定義跟分析資料需求，來支援某個商業程序。 下面就是維基百科所描述的資料塑模方法: 但是以上的方法，先經過邏輯塑模(Logical Data Model)，再經過概念塑模(Conceptual Data Model)，最後進行實體塑模(Physical Data Model)。 我們建議資料塑模，使用下圖的方式: 也就是先經過概念塑模(Conceptual Data Model)，然後進行邏輯塑模(Logical Data Model)，最後進行實體塑模(Physical Data Model)。 概念塑模(Conceptual Data Model)使用的工具，就是實體關係模型(Entity Relationship Model)，最後會產生實體關係圖(Entity Relationship Diagram)。 邏輯塑模(Logical Data Model)使用的工具，就是關聯模型(Relational Model)，最後會產生資料表的定義關聯綱目(schema)。 實體塑模(Physical Data Model)使用的工具，就是資料庫管理系統，或是 SQL語法，最後會產生真…
實作練習~公司員工訂餐系統
某公司希望設計一個提供員工中午訂餐的服務，該系統需求如下: (1)該系統有數個餐廳的餐點提供員工點餐。 (2)該系統在每天早上讓員工線上點餐。 (3)為方便結帳，該系統採用預付制，也就是先存錢給秘書，然後依照訂餐扣款。 (4)希望每個訂餐依照所訂購的每位同事帳戶下扣款。 (5)每個每個人可以訂購多項餐點，也可以跨不同餐廳訂購。 (6)員工帳戶資料要能夠記載預付時間、金額，以及扣款時間、金額及對應的餐點。 (7)該系統必須能夠提供每位員工統計報告，記載每月的餐費。 (8)該系統必須能夠統計各餐廳/餐點的消費紀錄，以便知道員工對於餐廳/餐點的喜好。 該系統的 ERD應該如何設計呢? 該系統的實際資料庫應該如何設計呢? 步驟一: 先找出物件 (Entity) 員工(Employee)、餐廳(Restaurant)、餐點(Item)、帳戶(Account)、帳戶紀錄(Account Log)、訂單(Order)、訂單紀錄(Order Item)，我們也可以再多出一個部門物件，以紀錄員工的部門。 所以總共八個物件。 步驟二: 再找出物件間的關係 (Relationship) 餐廳(Restaurant) --> 餐點(Item) 員工(E…
實作練習 ~ 選課資料
我們在" 從ER Model到資料庫的實作練習 "，了解從ER Model到資料庫的形成步驟，現在來進行實際的實體資料庫建立。 假設資料庫的關聯及結構如下圖 (下圖是以Access的工具製作而成): 其邏輯資料庫可以表示如下: 課程資料表 course( cid ,cname,credit,tid) 老師資料表 teacher( tid ,tname,tarea) 學生資料表 student( sid ,sname,did) 科系代碼表 department( tid ,tname,tboss) 選課資料表 enrollment( sid , cid ,score) 學務處資料表 score1( serial ,sid,score) 教務處資料表 score2( serial ,sid,score) 但是這個資料庫結構設計有些問題: (1)沒有表示年度與學期 (2)教務處資料表的學業成績是甚麼? (3)課程資料表是用來給學生選課，應該分成~課程基本資料表+開課資料表 所以我們將之更新如下: 課程基本資料表 course( cid ,cname,credit,ctype,did) 開課資料表 cour…
從ER Model到資料庫的實作練習
ER模型 全名為實體關聯模型或實體關係模型或實體關聯模式圖(Entity-relationship model，Entity-relationship Diagram)，由美籍華裔計算機科學家陳品山發明，是概念數據模型的高層描述所使用的數據模型或模式圖，它為表述這種實體聯繫模式圖形式的數據模型提供了圖形符號。 參考: 實體關係模型(Entity-relationship model) 從ER Model到資料庫的形成步驟為：(1)需求分析 (2)ER Model (3)邏輯資料庫 (4)實體資料庫。但是這些步驟並非標準答案，有些可能簡化成步驟(1)(2)(4)，也有些更細分出更多步驟。不過不管如何，ER Model都是從需求到資料庫形成的重要步驟。 假設現在需要設計學生選課系統，我們由四大步驟來看看過程。 (1)需求分析 ~ 我們與使用者訪談的結果，得到以下幾個需求 (a)每位專任老師在不衝堂下，可以開設多門課程。 (b)相同課程只能有一位老師開課。 (c)每個課程只要有10位以上同學修課，即可以開課。 (d)每個課程必須有一間不衝堂的教室。 (e)每位學生可以修多門課程，學分上下限為24與9學分。 (f)每個課程需依照教室可容納人數以限制修課人數…
實體關係模型(Entity-relationship model)
實體關係模型 ( Entity-relationship model ) 由美籍華裔計算機科學家陳品山（Peter Chen）發明，是概念數據模型的高層描述所使用的數據模型或模式圖，它為表述這種實體聯繫模式圖形式的數據模型提供了圖形符號。 下圖就是一個ER Model的範例 (可點選放大): 下圖是ER Model常用的符號: 實體(Entity)以長方形表示，實體可以被（粗略地）認為是名詞，如計算機、僱員、歌曲、數學定理。 屬性(Attribute)以橢圓形表示，實體和關聯都可以有屬性，用來代表實體或是關聯外在可以描述的值，例如「國民」這個實體有「身份證字號」這個屬性，「員工」與「公司」間的「雇用」關聯，會有一個「雇用開始日期」屬性。 關聯(Relationship)以菱形表示，關聯描述了兩個或更多實體相互如何關聯。聯繫可以被（粗略地）認為是動詞，如：在公司和計算機之間的擁有關聯，在僱員和部門之間的管理關聯，在演員和歌曲之間的表演關聯，在數學家和定理之間的證明關聯。 弱實體(Weak Entity)以雙線長方形表示，弱實體是指不能獨立存在，必須依靠某個實體而存在的物件。例如訂單品項(order item)就必須跟著訂單(order)而存在，訂單…
