關聯式資料庫設計 1｜部落格

在從事前端工程的這段時間中，跟後端的協作多半來自串接 API，對於後端在資料庫設計，資料表的欄位設計等沒有著墨太深，只知道資料庫設計跟效能上也有很大的關係。這系列可能不會涉及太深或太複雜的資料庫設計，多半是我為了釐清學習過程中的問題以及複習的文字紀錄。

在開始之前，想先彙整一些資料庫設計會用到的台灣繁體中文翻譯跟英文對照。

不一樣的資料庫類別

在第一部分 Introduction of Database Design，講師透過簡報說明資料庫以及資料庫設計的一些概要與原則。

簡易的資料庫，所有資料儲存在單一表格或是試算表，適用於規模較小的資料集，常見的有 CSV, TXT。

專為非結構化或半結構化資料設計，適用於大規模或快速變化的資料，市場常見的有 MongoDB, Cassandra。

一種將資料組成由行和列組成的表（即「關係」）的資料庫

一張表格有固定的結構，基本原則如下：

不符合資料庫設計結構的表格

first_name	last_name	date_of_birth	state	country	playlists
Andrew	Smith	1998-03-11	Wisconsin	USA	Easy Listening
Michael	Portman	Dec 3rd 1995	New Hampshire	USA	best of 2024, best of 2025
Joseph	Samuel	2003-07-20	New York	USA	90's classics

符合資料庫設計結構的表格

sb_id	first_name	last_name	date_of_birth	state	country
1	Andrew	Smith	1998-03-11	Wisconsin	USA
2	Michael	Portman	2000-09-15	New Hampshire	USA
3	Joseph	Samuel	2003-07-20	New York	USA

從不符合設計結構的表格來看，它主要違反了：

未達成原子性:
- playlists 欄位中儲存了多個以逗號分隔的值（例如：best of 2024, best of 2025）。在 1NF 的規範下，每個欄位都必須是不可分割的單一值（即原子值），不能在同一個欄位內塞入多個資料。
- date_of_birth 欄位格式不一致（例如：Dec 3rd 1995 與標準的 YYYY-MM-DD 格式不同），這也會導致資料型態不一致與後續查詢、排序上的困難。
無主鍵

這邊是概念的部分，我覺得可以記一下，然後去對照資料庫是否有違反設計原則，再來思考怎麼最佳化。

涉及資料庫中所儲存資料的準確性、一致性和可靠性。