上一篇文章介紹了 NULL，讓我們可以在欄位中表示「沒有資料」。 但反過來想：有些欄位是不是不應該允許空值？ 例如會員的姓名。一個會員一定要有姓名吧？如果連姓名都沒有，這個會員資料就不完整了。 這篇文...

前面的文章我們討論關係類型時，都在問「最多」： 一個會員最多可以有幾支電話？ 一支電話最多可以被幾個會員持有？ 但有沒有想過：最少呢？可不可以完全沒有？ 例如一個會員可不可以完全沒有電話？一個人可不可...

上一篇文章介紹了一對一、一對多、多對多三種關係類型，也學會了怎麼設計表單來記錄這些關係。 但有個問題：我們怎麼確保這些關係是正確的？ 例如會員和電話是「一對多」的關係，一支電話只能被一個會員持有。但如...

上一篇文章介紹了第一正規化形式，我們知道「一個會員有多支電話」這種情況要拆表單。 但這種「一個對應到多個」的關係，在資料庫設計中有專門的名稱，叫做「一對多關係」。 除了一對多，還有「一對一」和「多對多...

前面的文章介紹了第二正規化和第三正規化，都是從「欄位之間的相依關係」來決定要不要拆表單、刪欄位。 這篇文章要介紹的第一正規化形式，角度不太一樣——我們要從「資料列」的層級來看，有沒有需要調整的地方。...

上一篇文章我們學到了第二正規化形式：把相依的欄位放在同一張表單，不相依的欄位拆到不同的表單。 例如「會員」和「會員信箱」是相依的（知道會員就知道信箱），所以放在同一張會員表單。 但有時候，表單裡還會有...

上一篇文章我們學到：好的資料庫架構要避免重複，方法是用「關聯」讓每筆資料只存在一個地方。 但實際設計的時候，你會遇到一個問題：怎麼判斷哪些欄位該放在同一個表單？哪些該分開？ 這篇文章會用一個訂房網站的...

這篇文章進入資料庫系列文章的重要主題——架構設計。 架構設計在做什麼？簡單來說，就是在規劃你的表單要有哪些欄位、表單之間要怎麼關聯。而設計架構時，有一個最重要的核心精神： 避免資料重複。 為什麼資料重...

前面的文章我們學會了： 如何找出個體和關係 為什麼要分成多張表 如何透過關聯避免重複資料 這篇文章會透過三個實際案例，從簡單到複雜，讓你練習如何把日常生活中的資訊轉換成資料表。你會發現，有些看似簡單的...