目前顯示的是有「ER Diagram」標籤的文章顯示全部
實作練習 : 員工與部門資料管理系統

實作練習 : 員工與部門資料管理系統

Jesse Yen - 5月 06, 2026

現在要建立一套管理公司員工與部門資料的系統，讓企業能有效掌握：員工基本資料、部門組織架構、 員工與部門隸屬關係、 員工異動歷程、 聯絡資訊管理、 進行查詢、報表、統計分析。 每位員工的基本資料要能夠允許多筆地址、多筆電話、多筆電子郵件，並且要能夠紀錄員工的職務名稱，部門要能夠紀錄誰是部門經理、課長、主任等主管的關聯，並且要允許員工可以擔任多個部門的主管，例如某員工是技術部經理，並兼任管理部資訊長。其他未述明的需求，請自行合理化的假設。 (1) 請根據以上需求，畫出這個系統的實體關係圖 (Entity Relationship Diagram)， 請以陳品山博士提出的模式來繪製。  陳品山的實體關係圖模式可以參考這篇" 實體關係模型(Entity-relationship model) " 從以上的需求，可以明顯看出有兩個實體 : 員工、部門。 並且由於員工異動歷程也要記錄，因此需要再透過一個任職的關聯 (這個關聯也會形成資料表)。再來還有一個需求，允許員工可以擔任多個部門的主管，這個部分也可以放在任職的關聯上，開個職務資料表，與任職以編號欄位來對應。 並且因為員工的基本資料要能夠允許多筆地址、多筆電話、多筆電子郵件，員工可以擔任多個部門的主管，所以可以設計如下 …

Vibe Coding 的真正核心競爭力：資料庫思維

Vibe Coding 的真正核心競爭力：資料庫思維

Jesse Yen - 1月 20, 2026

在這兩年，「 Vibe Coding (氛圍編碼)」從一個矽谷的迷因演變成了許多開發者與創作者口中的關鍵字，也讓寫不出程式的小白燃起一絲希望。有人把它理解成「用 AI 寫程式」，有人認為是「不被語法綁住，專注做出東西」。  然而隨著 AI 工具如 Cursor 、 Replit Agent 或 Lovable 的普及，我們開始發現一個弔詭的現象：為什麼同樣是用 AI 協作，有些人能在半天內做出一個可擴展的 SaaS 產品，而有些人卻在處理簡單功能需求時，系統就開始崩潰、出錯，最後陷入無止盡的錯誤循環？  關鍵在於：真正進入 Vibe Coding 狀態的人，幾乎一定具備扎實的資料庫思維，因為所有系統的主要目的都是正確的處理資料。只要你交給AI的需求與資料庫邏輯是正確的，就能產出正確的系統。 Vibe Coding 的本質從來不是在「寫 code」，而是在「組建系統」。   一、 範式轉移：從「語法導向」到「結構導向」  在傳統開發流程中，工程師的思維路徑通常是「由小到大」：先選擇程式語言，寫下第一個 Function (函式)，決定 Variable (變數) 命名，最後在功能快完成時，才去思考資料要怎麼存、Table Schema (資料表綱要) 要怎麼開。  但在 Vib…

ChatGPT、GPT-4o、GPT-4o mini 哪個比較適合協助資料表設計?

ChatGPT、GPT-4o、GPT-4o mini 哪個比較適合協助資料表設計?

Jesse Yen - 11月 13, 2024

ChatGPT的 GPT-4o 是ChatGPT的最新版本， GPT-4o mini 則是GPT-4o較為有效率的版本。 我們來比較一下ChatGPT、GPT-4o、GPT-4o mini 這些版本在資料表設計上，哪個表現比較好? 先準備好固定的問題 :  (1)需要設計一個線上購物的資料表結構，應該有哪些表單? (2)給我建立表單 以及插入範例資料的語法 (3)給我planttext UML 來建立 ER diagram (4)我想知道今年哪個產品銷售最好，應該怎麼寫MySQL指令? (5)我想知道A級客戶，今年最喜歡哪類產品，應該怎麼寫MySQL指令? 一、首先來看看GPT-4o的回答 以下是針對您的需求提供的設計建議和SQL範例： (1) 設計線上購物的資料表結構 一般的線上購物系統通常包含以下資料表： customers ：儲存顧客的基本資訊。 products ：儲存產品的詳細資訊。 orders ：記錄訂單資訊。 order_items ：記錄每筆訂單中的產品細節。 categories ：分類產品以方便管理和查詢。 payments ：儲存每筆訂單的付款資訊。 (2) 建立表單及插入範例資料的SQL語法 建立表單 CREATE TABLE customers (   …

好壞資料庫結構 (database schema) 的差異是什麼?

好壞資料庫結構 (database schema) 的差異是什麼?

Jesse Yen - 8月 07, 2024

好的資料庫結構 (database schema) 和壞的資料庫結構在多個方面存在顯著差異，這些差異會直接影響資料庫的效能、可維護性、擴展性和數據完整性。並且當開發系統時，好的資料庫結構可以讓程式容易撰寫及維護，而壞的資料庫結構可能讓程式變得很龐大，並且無法在變更系統需求時還能修改維護。 以上的說法，可能很難以理解，我們用實際的例子來說明。 我們用農民曆上的食物相剋圖來設計資料庫結構，狀況及需求如下 : (1)當兩個食物一起吃，會造成不適的症狀，例如拉肚子或是中毒。 (2)可以透過解毒物來解除不適的症狀。 我們先抓出物件 : 食物、解毒物、不適的症狀。 因此會有一個食物的資料表單，然後會有解毒物的資料表單，至於這兩個物件是應該兩個資料表單，還是合成一個資料表單，後面再來決定。 不適的症狀也會是一個資料表單，裡面會有兩個食物的欄位，如果症狀用文字表示，有違反正規化的情況，因此不適症狀資料表單中以症狀id來關連到另外一個症狀表，會比較恰當。 最後，特定症狀需要使用特定解毒物，也會形成一個解毒的資料表單。 綜合以上，形成資料表單如下 :  Food（食物）：包含食物id、食物名稱和描述等資料。 Interaction（相剋反應）：包含反應id、兩種食物的id和症狀id。 Symptom（…

UML 統一塑模語言是什麼? 作用是什麼?

UML 統一塑模語言是什麼? 作用是什麼?

Jesse Yen - 9月 17, 2023

UML 統一塑模語言 (Unified Modeling Language) 是一種標準化的建模語言，可用於視覺化軟體設計和架構。常被誤會的是為何他是語言 (Language)? 因為任何系統化的、用於表示資訊或表達思想的方法都可以稱為語言。 UML 的起源可以追溯到三位著名的軟體工程師：Grady Booch、Ivar Jacobson 和 James Rumbaugh。在 1990 年代初，他們創建一個統一的建模語言，即 UML。在 1997 年，OMG 採納了 UML 作為一個標準，並從此持續管理和發展它。隨著時間的推移，UML 經歷了多次修訂，以滿足不斷變化的軟體工程需求。

實作 : 工讀生薪資管理系統

實作 : 工讀生薪資管理系統

Jesse Yen - 5月 19, 2023

今天剛好碰到王老闆，他經營了三家飲料店、兩間拉麵餐廳、三間超市。因為工讀生越來越多，每個工讀生都有不同的工作時間。王老闆希望可以開發一套工讀生薪資管理系統，讓會計人員可以登錄工讀生的工作時間來計算薪資，並記錄登錄資料的會計人員，並提供工讀生以電子郵件登入查詢自己的薪資，你覺得這個工讀生薪資系統的DFD與ERD應該怎麼畫？

Data Flow Diagram (DFD) 與 Entity Relationship Diagram (ERD) 實作練習

Data Flow Diagram (DFD) 與 Entity Relationship Diagram (ERD) 實作練習

Jesse Yen - 3月 14, 2023

假如有進貨單格式如上，以往都是人工製作表單，現在老闆要我把這個作業電腦化，我應該怎麼做呢? (仔細檢視上面的進貨單，如果A公司要運送貨物給B公司，對A公司來說是出貨單，對B公司來說才是進貨單。出貨單才會需要運送地址，進貨單只需要供應商編號或是名稱。除非進貨會到不同倉庫，例如B公司有台中倉庫以及台南倉庫，以下分析過程先忽略進貨地址。)

如何將ERD轉換為邏輯資料?

如何將ERD轉換為邏輯資料?

Jesse Yen - 3月 15, 2018

(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

Database Design

Jesse Yen - 3月 09, 2018

(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 (資料塑模) : 概念塑模、邏輯塑模、實體塑模

Jesse Yen - 4月 30, 2015

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語法，最後會產生真…

實作練習~公司員工訂餐系統

實作練習~公司員工訂餐系統

Jesse Yen - 4月 15, 2015

某公司希望設計一個提供員工中午訂餐的服務，該系統需求如下: (1)該系統有數個餐廳的餐點提供員工點餐。 (2)該系統在每天早上讓員工線上點餐。 (3)為方便結帳，該系統採用預付制，也就是先存錢給秘書，然後依照訂餐扣款。 (4)希望每個訂餐依照所訂購的每位同事帳戶下扣款。 (5)每個每個人可以訂購多項餐點，也可以跨不同餐廳訂購。 (6)員工帳戶資料要能夠記載預付時間、金額，以及扣款時間、金額及對應的餐點。 (7)該系統必須能夠提供每位員工統計報告，記載每月的餐費。 (8)該系統必須能夠統計各餐廳/餐點的消費紀錄，以便知道員工對於餐廳/餐點的喜好。 該系統的 ERD應該如何設計呢? 該系統的實際資料庫應該如何設計呢? 步驟一: 先找出物件 (Entity) 員工(Employee)、餐廳(Restaurant)、餐點(Item)、帳戶(Account)、帳戶紀錄(Account Log)、訂單(Order)、訂單紀錄(Order Item)，我們也可以再多出一個部門物件，以紀錄員工的部門。 所以總共八個物件。 步驟二: 再找出物件間的關係 (Relationship) 餐廳(Restaurant) --> 餐點(Item) 員工(E…