資料庫設計 - 有效的使用系統資料 - 第四章 資料庫設計的實務分析流程與方法

單元 1 首先你要知道一些關鍵欄位的用法

主鍵、外來鍵與表格連接

關連式資料庫：

1. 資料間的關係以 table 的形式表達，並將資料儲存在 table 中

2. 設計 table 的屬性（欄位）來儲存資料

   在物件導向的程式語言中，table 就像一個物件

   • table → 物件
   • column → 物件的屬性

3. 可以透過 SQL 語法查詢多個 table 資料

主鍵 Primary Key (PK)

• 用來識別 table 的唯一值
• 不能重複
• 可提供資料索引 index，快速查找

外來鍵 Foreign Key

• 會存放其他 table 的 PK
• 只有經過確認的資料，才能夠輸入存放進 table

表格連結

在 WHERE 條件中Ｍ將 PK & Foreign Key 建立關係查詢

SELECT <column name> FROM <欲連接的 tableA & tableB>

WHERE <代表相同的 column name，tableA.column = tableB.column>

Ex: 到此網站

SELECT * FROM Orders, Customers
WHERE Orders.CustomerID = Customers.CustomerID

SELECT * FROM Orders, Employees
WHERE Orders.EmployeeID = Employees.EmployeeID

單元 2 使用者需求分析的方法與流程

訂單系統建立

系統建立三原則：

1. 有哪些角色（部門）人員要使用這個系統 Who?

   • 訂單管理員
   • 主管
   • 物流
   • 客戶
   • 產品廠商

2. 有哪些角色（部門）人員的面向去了解，他們要做什麼 What?

   • 訂單管理員：要管理訂單
   • 物流：要檢貨、寄送與簽收
   • 客戶：要下訂單，要付款
   • 產品廠商：要收訂單，要出貨，要收錢

3. 深談理解他們要如何達到第二點的目的 How?

   延伸出不同角色會需要什麼樣的功能，朝 CRUD 的方向去想

   • 訂單管理員：新增、修改、刪除、讀取資料
   • 物流：讀取貨物內容；讀取寄送客戶地址、新增客戶簽收表單

UML Unified Modeling Language

應用網址：

Flowchart Maker & Online Diagram Software

開發的方法：

用於說明，可視化，建構一個正在開發的軟體系統的方法

步驟

1. 定義角色
2. 定義 use case

圖型可以幫助看脈絡

IT 接這看如何協助

初步整理與歸納：

• 訂單管理系統使用者（角色）：

  訂單管理員、客戶、主管、主管、產品廠商、物流

• 客戶資料管理功能：

  • 使用者：客戶
  • 功能：新增、修改、刪除客戶資料

• 訂單管理功能：

  • 使用者：訂單管理員、物流、客戶
  • 新增、修改、刪除訂單資料

• 討論功能細節，如權限，物流可以刪除訂單嗎？

製作出使用者介面雛形

Balsamiq. Rapid, Effective and Fun Wireframing Software | Balsamiq

• 看得到的形體，有助於討論分析
• 不用管外觀是否好看
• 方便快速的調整

💡 如上圖，如果 DB 需要存取 User 資料時，如果其中有一個欄位需要存取圖片，圖片本身會存在主機硬碟，資料庫則存放圖片的主機位置路徑，前端要秀出圖片時，會去該路徑找檔案

  💡 日期 / 數字，在數量不多時，盡量用下拉選單，避免用戶輸入中英文或亂碼，導致型別上的錯誤

系統設計的重要階段

1. 資料庫設計：最底層，確定資料儲存欄位
2. 前端介面設計：延續資料庫儲存資料格式，才能知道前端需要開哪些欄位給 User 輸入
3. 後端程式架構設計：規劃架構，跟 database 溝通
4. 子系統 interface 與外部系統 API 設計：與外部人員串接
5. 整合測試案例設計：整格系統要如何測試

以下介紹設計架構時候好用的 ER Diagram

我們有 Orders & OrderDetails Table

Orders

OrderDetails

用 ER Diagram 可以畫出 Table 之間的關係

• 一對一
• 多對一
• 一對多
• 多對多（少用，因為很麻煩）

ER Diagram

• Orders → OrderDetails 為「一對多」 1 → 多
  之後會在 ER diagram 的部分詳細介紹 一對多可以減少資料庫儲存的資料量，否則 Orders 裡面會多一欄 Product，儲存很多重複的 Product 資料。
• User → City 為「多對一」
  多個 User 可能住在同一個 City
• City → Country 為「多對一」
  多個 City 在同一個 Country

欄位設計

• 欄位若有分隔，通常用底線：customer_id, first_name, last_name

• 關鍵欄位請加上註解：重要的 Table 如訂單，會加

  • create_by：訂單是誰做的
  • create_date：什麼時候產生的
  • update_by：誰更動的
  • update_date：什麼時候更動的

做這些是因為，當資料發生異常，是誰做了這些事情，以保護 IT 人員

這些欄位名字都很像，因此就需要特別註解

不太會變，不太會更動的 Table 就不需要加

開發文件

• 討論完後，製作開發文件，因為有效率的設計藍圖可以事半功倍，讓團隊溝通更加明確
  Ex: 資料型態，會牽涉到資料面的變數定義

• 盡可能設計出讓自己跟同事都能夠理解的設計藍圖

與使用者確認系統開發文件

• 變動需求的成本，參與的團隊成員都在與時間賽跑
• 做記錄，確認未來責任歸屬

作業練習

1. 請同學依據本課程的訂單管理系統範例，製作 UML，學習定義角色及 Use Case

   

2. 製作訂單管理功能的圖形介面，雛形

   
   
   

3. 用 ER Diagram 製作出訂單管理系統的每一張 Table

   • 了解他們之間的關係

• 參考同學的，覺得這樣表示更清楚，同學好棒

單元 3 實際案例分析

線上帳務管理系統

音樂往年收、月收

如何去向使用者收款

繪製帳務管理系統資料庫設計藍圖

1. 系統每個週期自動出帳，產生帳單：有人 1000 元吃到飽，有人月租 168
2. 自動出帳單，帳單存起來，每人要繳金額與內容
3. 多種付款方式：
4. 可以儲值付款
5. 消費者與公司的契約

單元 4 設計資料庫的重要觀念「正規化」

1. 避免資料重複，浪費空間和矛盾情形
2. 使資料庫更有效率，更容易維護
3. 共有七個階段，但通常前三就夠了：
   1. 1NF
   2. 2NF
   3. 3NF
4. 進行下一階段時，須先確認前一階段已完成
5. 正規化需要再資料庫設計階段就進行，不要等到塞資料時才來調整欄位或新增 table

1NF

• 確認主鍵：讓每個欄位可以相依在主鍵上
• 每一個欄位只能有一個資料：(2022/1/1~2022/12/31)
  • 這樣就要分兩欄 start date & end date
• 資料表中沒有意義相同的多個欄位（一階主管、二階主管）
  • 會另外開一個欄位叫階層

2 NF

• 完成 1NF

• 每一個欄位跟主鍵不能有「部分相依」

  OrderID & CustomerID 有相依相

  OrderDetailID & ProductID 有相依

  OrderID 跟 ProductID 就是部分相依

  因此 OrderID 及 OrderDetailID 應該要拆開成兩張 Table

  

3NF

• 完成 2NF

• 非主鍵之間不能有依賴關係

  

  Total 是由 Quantity & Price 計算出來的

  可以在下 SQL 時去計算，不需要開一欄去儲存資料，會浪費空間