前面幾篇我們討論的都是理論，像是資料庫的架構要怎麼設計。 從這篇開始，我們終於要動手操作資料表和資料了！ 不過在寫程式之前，有一件事要先說明。 市面上有很多種資料庫系統，像是 MySQL、Postgr...

學完正規化和限制之後，我們來做一個實戰練習。 這次的任務是：幫一間補習班設計班務系統的資料庫。 這個系統要記錄什麼？ 有哪些課程（科目 + 年級） 有哪些老師 有哪些學生 老師在什麼時間、什麼教室上什...

我們已經學了三種正規化形式： 第一正規化：表單要有主鍵，同一欄位只能存一筆資料 第二正規化：相依性高的欄位要拆表 第三正規化：可以從其他欄位推算出來的欄位要刪掉 也學了四種欄位限制：UNIQUE、NO...

前面我們介紹了主鍵（Primary Key），它幫助我們唯一識別每一筆資料。 有了主鍵之後，我們終於可以介紹另一個很重要的限制：外部鍵（Foreign Key）。 什麼是外部鍵？為什麼需要它？我們來看...

前面我們介紹了第二正規化、第三正規化，還有第一正規化的後半。 現在終於要進入第一正規化的前半，也就是整個正規化形式的最開頭。 第一正規化的前半告訴我們：表單要有一個欄位是主鍵（Primary Key）...

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

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

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

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