實作練習 : 如何從實體表單轉換為資料庫表單?
這篇的重點要談到以下幾個 : (1)資料表單設計的一些實務程序。 (2)資料欄位中代碼的設計。 (3)資料表單中外鍵約束的例外。 (4)資料表單有時需要違反正規化。 (5)資料表單中有時還是需要必要的冗餘資料。 在前面 這篇 已經談過將實體表單轉換為資料庫表單，但是並沒有說明過程。這篇來說明一下過程，並且再修正一下之前的答案。 要把紙面資料電子化，先把紙面資料的欄位整理出來，然後再看各欄位適合放在哪些資料表單中。我們從上面「出貨單」，看到以下的資訊 : (1) 公司資訊 (公司名稱、電話、傳真、地址) (2) 客戶資訊 (客戶名稱、電話、傳真、送貨地址) (3) 出貨日期、出貨單號 (4) 產品資訊 (產品編號、品名及規格、數量、單價、金額、備註) (5) 經手人資訊 (助理、業務) (6) 備註 (7) 簽收資訊 (簽收狀態、誰簽收、簽收日期) 通常「出貨單」資料都會從「訂單」資料轉過來，因此之前文章產生以下表單 客戶資料表 customer(cusno, cusname, cuszipcode, cusaddress, custel, cusfax, cuscontact) 職員資料表 employee(empno, empname, deptno, emptitle) 公…
實作測驗 ~ 正規化 + SELECT
有如下表單，你應該如何進行正規化呢? 學號 學生姓名 學生電話 課程代號 課程名稱 年級 老師姓名/電話 老師代號 科系代號 科系名稱 成績 101001 張大頭 0910111222 0922111000 A001 資料庫 三年級 王老師 0933111333 001 001 資管系 80 A002 網路概論 林老師 0955111222 002 003 資工系 50 101002 劉三哥 0912333222 0922111333 A003 程式設計 三年級 孫老師 0912000333 003 001 資管系 85 A002 網路概論 林老師 0955111222 002 003 資工系 76 我們正規化後，資料結構如下~ studnt 學生資料表 ( studno , studname, deptid) teacher 老師資料表 ( teano , teaname, deptid) department 科系資料表 ( deptid , deptname) telephone 電話資料表 ( ownerno, tel ) cou…
資料庫正規化實作練習
如下的資料，我們應該如何進行正規化呢? 如果無正規化，對於處理上有何問題呢? 資料表1: 問題在於欄位並非atomic(基元值)，學號、學生姓名、成績欄位中有多個數值，所以並不符合1NF的條件。改成資料表3，所有記錄中的項目都是基元值，即無重覆資料項目，就可符合1NF的條件。 資料表2: 問題在於無法決定學生1、學生2、學生3 ... 到底需要多少個欄位，成績亦同，所以這個資料表無法決定相依關係。 資料表3: 問題在於不符合2NF的條件，也就是每一個非鍵屬性無法完全相依於主鍵。 所以必須拆開成幾個表單~ 如資料表4，以符合2NF的條件。 課程資料表 ( 課程編號 , 課程名稱, 教師編號, 教師姓名) ， 學生資料表 ( 學號 , 學生姓名) ， 成績資料表 ( 課程編號 , 學號 , 成績)。 資料表4: 但是上面的課程資料表，尚不符合3NF，所以再拆成如下資料表5。 資料表5: 所以就得到 .... 課程資料表 ( 課程編號 , 課程名稱, 教師編號) ， 老師資料表 ( 教師編號 , 教師姓名) ， 學生資料表 ( 學號 , 學生姓名) ， 成績資料表 ( 課程編號, 學號 , …
資料庫正規化 (normalization)
資料庫正規化 (normalization)的定義: Database normalization is the process of organizing the fields and tables of a relational database to minimize redundancy and dependency. 資料庫正規化就是指把關聯式資料庫的欄位與表單做規劃，讓資料重覆性與相依性能夠降到最低。當然這個"資料重覆性與相依性能夠降到最低"情況下，還必須讓資料庫可以正常運作。 重複的資料 會浪費磁碟空間，並產生維護方面的問題， 不一致的相依性 會讓資料出錯誤。 資料庫正規化有一些規則。每條規則都稱為「正規形式 Normal Form」。如果遵守第一條規則，資料庫就稱為屬於「第一正規形式」。如果遵守前三條規則，資料庫就被視為屬於「第三正規形式」。 雖然可能會有其他層級的正規形式，但第三正規形式被視為大部分應用程式所需的最高階正規形式。雖然有許多正式規則與規格，但真實情況不一定永遠完全都相同。一般而言，正規化需要其他資料表，有些客戶也會嫌麻煩。如果您決定違反正規化前三個原則中的其中一個原則，請確定您的應用程式能夠掌握所有可能發生的問題…
