1、1,第7章 資料設計,Prepared by S. F. Chang,2,簡介 P394,在系統分析階段，你已製作出資料流程圖、確認資料元素、資料流，和資料儲存，並從而建立資訊系統的邏輯設計。在系統設計階段的這一部份，你將發展一個資料的組織、儲存，及取用之實體計畫。,3,資料設計觀念(1) P397,資料結構 資料結構(data structure #)是組織及儲存資訊系統資料的架構。資料結構由一或多個檔案或一些以不同方式連結的資料表所組成。 每個檔案(file)或資料表(table)存放著與資訊系統互動的人、地、物，或事件等資料。 資訊系統可以依據系統檔案或資料表組成及連結的方式，而稱為檔案
2、處理系統，或是資料庫管理系統。 檔案處理系統(file processing system)或稱為檔案導向系統(file-oriented system)將資料以單一或多個檔案作儲存與管理。(ref. p397 圖7-2) 。 檔案導向系統的主要缺點是相同的資料會存放在好幾個地方。,4,資料設計觀念(2) P398,資料庫系統(database system #)是由互相連接而構成整體資料結構的資料表所組成。與檔案處理相較，資料庫環境具較大彈性及較高效率。(ref. p398 圖7-3) 檔案處理系統仍然存在，以供特殊需要使用，但今日大部分的資訊系統都已設計成資料庫。 檔案處理概述 許多舊系統
3、使用檔案處理設計是因為此種方式很適合使用在主機式硬體架構及批次處理的輸入。雖然在今日已較不普遍，但是檔案處理在某些狀況下，是可以比DBMS(資料庫管理系統，Database Management System #)更具有效率及節省成本(ref. p399 圖7-4)。,5,資料設計觀念(3) P399,公司可能有三個部門，而每一個部門都有自己的資訊系統及資料檔案。 有三個潛在問題存在檔案處理環境中: 第一個問題是資料重複(data redundancy #)，意指兩個或數個資訊系統中之相同的資料被存放在許多地方。 資料重複需要更多的儲存空間，而且維護及更新不同地點的資料較為昂貴。(圖7-2)
4、第二，如果無法同時更新每一個檔案，就產生資料完整性(data integrity #)問題。 只有更改系統中的一個檔案，將會產生不一致的資料，而導致在後續系統中的不正確資訊。 (圖7-2),6,資料設計觀念(4) P399,第三個問題是典型檔案處理環境中的僵硬資料結構(rigid data structure)。 企業必須依據整個公司的資料做決策，經理人通常需要從數個企業單位及部門取得資訊。在檔案處理環境中，要從各個各自獨立檔案系統中取得資訊是很慢且沒有效率的。 (圖7-2) 檔案導向資訊系統使用各種類型的檔案，包含主檔、對照表檔、交易檔、工作檔、安全檔，及歷史檔。 主檔(master fil
5、e)儲存有關於一個實體比較持久性的資料。例如產品主檔，在每一紀錄中的數量欄可能每天變動，但是其他資料如產品代碼、名稱，及描述則不會變動。其他如課程、學生、及教職員主檔。,7,資料設計觀念(5) P400,對照表檔(table file)包含資訊系統所使用的參考資料。與主檔相同，對照表檔的資料也比較持久，而不被資訊系統經常更動，例如稅率對照表、郵資對照表等。 交易檔(transaction file)儲存含有每日經營及運作資料的紀錄。交易檔是用以更新主檔的輸入檔; 當完成更新後，交易檔即達成使命，除非基於安全或備份理由，通常交易檔是暫時性的檔案。例如用以更新客戶餘額檔案的收款及付款檔案。 工作檔
6、(work file)也稱作暫用檔(scratch file)，是暫時性的檔案，是由資訊系統因特定單一工作而產生。大部分工作檔是由資訊系統中的某一個程序所產生，且由在同一系統中的另一程序所使用。例如列印報表所需的排序檔或是報表檔。,8,資料設計觀念(6) P400,安全檔(security file)是為作為備份或是回復目的而產生及儲存的檔案。例如稽核檔或主檔、表單檔，及交易檔的備份。新的安全檔必須定期產生以替換過期檔案。 歷史檔(history file)是為歷史或典藏目的而產生的檔案。例如在過去兩學期未註冊的學生紀錄，可從現行學生主檔中刪除，然後加到中輟檔中，此檔即是歷史檔的一種類型，如果
7、中輟檔中的學生又再度註冊，則他的資料紀錄就從中輟檔中刪除並加到現行學生主檔中。 資料庫系統概述 資料庫提供可避免檔案處理系統潛在的兩個問題，亦即資料重複及支援即時與動態環境的整體架構。,9,資料設計觀念(7) P401,在檔案處理環境中，資料檔案是設計來符合個別營運系統。相反地，在資料庫環境中，許多系統可以圍繞單一資料庫而建立(ref. p401 圖7-5)。 資料庫管理系統(DBMS, database management system #)是一套讓使用者能夠新增、更新、管理、取用，及分析資料庫內容的工具、機能、及介面的組合。 從使用者的角度來看， DBMS的主要優點是它提供適時的、互動的
8、，及彈性的資料存取。DBMS的具體優點如下列各點:,10,資料設計觀念(8) P401,規模彈性(scalability)意指系統可以很容易擴充更改，或縮小以滿足企業經營中迅速改變的需求。例如如果一個公司決定加入有關其所用原料的次級供應商資料時，就可以在關聯式資料庫中加入新的資料表，以一個共用欄位聯結起來。 提供主從式(client/server)系統更佳的支援。 經濟規模。延續自大型電腦大量資料處理的效率稱為經濟規糢(economy of scale)。資料庫設計可使硬體有較好的利用率。 有彈性的資料分享。因為資料庫設計是相當具有彈性的，使用者能夠以不同方式來檢視相同資訊。資料可以分享給整個
9、企業組織。,11,資料設計觀念(9) P402,能有效支援普及企業全體的應用系統。通常， DBMS是由稱為資料庫管理師(DBA, database administrator #)的人所管理，他依據整個組織，而不是單一部門或個人的利益，來評估整體需求及維護資料庫。 更強化的標準。有效的資料庫管理可保證資料名稱、格式，及文件的標準，在整個組織中能夠被一致遵循。 受控制的資料重複。資料重複意即在一個地方以上存放資料而能造成不一致及資料錯誤。因為資料儲存在一組相關的資料表中，資料項目不需要在不同位置中重複儲存。 更好的安全。DBA可以定義授權規則，以保證只有合法使用者可以存取資料庫及允許不同使用者具
10、備不同等級的存取權限。,12,資料設計觀念(10) P402,提升程式設計師生產力。程式設計師不需要產生資料庫的基本檔案結構。如此，可讓他們集中力氣在邏輯設計上。 資料獨立性。與DBMS互動的系統相對地較獨立於實體資料的維護方式。 資料庫的一些取捨 因為DBMS力量強大，它們需要更貴的硬體、軟體，及資料網路，以提供支援多種使用者環境。 DBMS也比檔案處理系統更複雜;因此，對於系統分析師、資料庫管理師，及使用者的學習曲線通常都較為陡峭，此即提高了經營的整體成本(TCO, Total Cost of Ownership)。,13,資料設計觀念(11) P403,在資料庫環境中，安全、備份，及回復
11、等程序都相當複雜且重要。當公司將所有重要資料資源都放在一個資料庫時，一個DBMS的故障都將有可能嚴重癱瘓企業的營運。 雖然目前的趨勢是朝向整個企業組織的資料庫設計，許多公司仍然使用集中式DBMS與較小的、部門位階的資料管理系統(即分散式資料管理系統)的組合。 採集中式DBMS之理由為大部分企業視資料為整個公司的資源而必須可以讓公司的所有使用者都能存取。 促成分散式設計之因素如下,14,資料設計觀念(12) P403,網路費用降低。不願意放棄較小但較有彈性的系統。了解整個企業組織的DBMS的維護可能是非常複雜且昂貴。在許多狀況下，主從式設計是很合適的折衷方案，其中的資料處理可由數個電腦來分享。主
12、從式系統將在第八章中說明。,15,DBMS元件(1) p403,DBMS提供介於資料庫與需要存取該資料庫的使用者之間的介面。除了給使用者、資料庫管理師，及相關系統的介面之外, DBMS也擁有資料處理語言、綱目及子綱目，及實體資料儲存空間，如p404圖7-6所示。,16,DBMS元件(2) p403,給使用者、資料庫管理師，及相關系統的介面 使用者 - 使用者通常依據事先定義的查詢及控制面板命令來進行操作，但也使用查詢語言來取用儲存的資料。 查詢語言(query language #)允許使用者指定一項工作而不用規定其實際的執行步驟。 利用實例查詢(QBE, query by example #
13、)語言，使用者可提供所需資料的例子。 許多資料庫程式也產生結構化查詢語言(SQL, structured query language #)，它可讓PC使用者與伺服器或大型電腦進行溝通。(p405 圖7-7a ，圖7-7b所示),17,DBMS元件(3) p404,資料庫管理師 - (DBA，Database Administrator #)負責DBMS (Database Management System #，資料庫管理系統)的管理及支援。 DBA所關心的是資料安全性及完整性、防止未經授權的存取、提供備份及回復、稽核軌跡維護資料庫，與支援使用者需求。大部分的DBMS提供公用程式以協助DBA
14、產生及更新資料結構、資料庫使用情況的收集及報告，與資料庫異常狀況的偵測及報告。,18,DBMS元件(4) p405,相關資訊系統 - DBMS可支援許多提供輸入給DBMS或是從DBMS取得特定資料的相關資訊系統。 與使用者介面不同的是，在DBMS與相關系統之間的雙向溝通中，並不需要使用者的介入。 資料處理語言 資料處理語言(DML, data manipulation language #)控制資料庫的運作，包含資料的儲存、取用、更新，及刪除。 大部分商用DBMS，如Oracle及IBM的DB/2, 都使用DML。 許多資料庫產品，如 Microsoft Access, 也提供容易使用的圖形介
15、面環境，讓使用者得以使用選單式命令來操控資料庫的運作。,19,DBMS元件(5) p406,綱目 資料庫的完整定義，包含所有欄位、各資料表，及關聯性的描述，稱之為綱目(schema #)。 資料表名稱、資料表屬性所成的集合與各屬性的相對資料型態，再加上主鍵的宣告及外來鍵的宣告，這些內容整個構成資料表的結構，用來描述該資料表，我們稱之為資料表綱目。 例如:Books(id(int), bookname(string), author(string), price(int), publisher(string),20,DBMS元件(6) p406,子綱目(subschema)是一個或多個系統或使用
16、者對其所使用的資料庫的觀點。 子綱目只定義該資料庫中，此特定系統或使用者需要的或是被允許存取的部分。例如，為保護個人隱私，你可能不希望某專案管理系統可以取得個別員工的薪資。在這種狀況下，此一專案管理系統的子綱目就不可以包含薪資欄位。資料庫設計者也使用子綱目來限制所允許的存取等級。實體資料儲存空間 在系統發展程序的本階段中，資料詞典將轉換成實體資料儲存，它也包含綱目及子綱目。,21,DBMS元件(7) p406,實體儲存庫可以是集中式，或是分散於許多不同的位置。此外，存放的資料可能是由單一個DBMS或數個系統來管理。 為解決潛在的資料庫連結及取用問題，許多公司採用遵遁ODBC的軟體而能夠在各種系
17、統及資料庫之間互相通訊。ODBC意即開放資料庫連結(open database connectivity #)，它是一套讓從不同廠商來的軟體能夠互動並交換資料的產業標準協定，ODBC採用DBMS了解並能執行的SQL陳述。(Ref. ODBC的架構) 另一常見的標準是 JDBC (Java database Connectivity) 。 JDBC讓Java 應用程式能夠與任何使用SQL陳述且遵循JDBC的資料庫交換資料。,22,以Web為基礎的資料庫設計(1) p407,以Web為基礎的設計之特質 以Web為基礎的設計特質包括全球取用、容易使用、多種平台、成本效益、安全問題，以及調適問題。 在
18、以Web為基礎的設計中， Internet是作為資料庫管理系統的前端或介面。 網際網路科技提供了大量的力量及彈性，因為該系統不受制於任何特定硬體及軟體的組合。只需要一個Web瀏覽器及上Internet的連結就可以取用資料庫。 以Web為基礎的系統之所以廣受採用，就是因為他們提供簡便、符合成本效益，且遍及全球的連結。 因為以internet為通訊網路，所以初期投資相當低。使用者只需要瀏覽器，而以Web為基礎的系統不需要強力的工作站。因為在開發、主機代管、維護及系統支援有各種的委外選擇，所以彈性大。,23,以Web為基礎的資料庫設計(2) p407,網際網路術語 Web瀏覽器(Web browse
19、r #)，這是一種讓使用者能夠在Internet上遊走或瀏覽以及在其電腦上顯示網頁的應用程式。 所謂網頁(Web page)是一個以超文件標示語言(HTML，Hypertext Markup Language #)所撰寫的純文字文件。 (參考:網頁實例) HTML使用許多稱為標籤(tag)的格式化代碼，而這些指示出文字及視覺元件將如何被顯示在Web瀏覽器上。 網頁存放在Web伺服器(Web server)上，而它是一部接受使用者請求，並將網頁傳送給使用者的電腦。將Web伺服器和網頁加在一起稱為網站(Web site #)。,24,以Web為基礎的資料庫設計(3) p408,除了維護一個網站之外
20、，許多公司使用企業內部網路及企業外部網路來支援企業運作及通訊。 企業內部網路(intranet #)是一個私有的、公司擁有的網路，可提供內部使用者取用，以Web為基礎的應用。 企業外部網路(extranet #)則是公司intranet的延伸，讓外部使用者，如客戶及供應商，也可以取用。 extranet是企業間(B2B)資料分享及EDI (電子資料交換， Electronic Data Interchange #)的典型範例。 因為intranet及extranet使用與lnternet相同的協定(protocols #)，或資料傳輸標準，他們均被稱為Web-centric，意即以Web為中心
21、的。,25,以Web為基礎的資料庫設計(4) p408,Internet及公司的intranet/extranet都是用戶端/伺服器(client / server #)架構。 在用戶端/伺服器設計下，工作分別分配在與使用者互動的用戶端(client #)，以及供應資料、處理運算、及服務給用戶端工作站的電腦，即伺服器(server #) 。 將資料庫連上Web 為了在以Web為基礎的系統中取用資料，該資料庫必須連接上Internet或intranet。 但是，資料庫和lnternet使用兩種不同的語言。資料庫使用各種語言及指令來產生及管理資料，而這些與Web所使用的HTML語言完全無關。而我們
22、的目的是將資料庫連上Web，而使得資料可以被觀看及更新。 爲了彌補此一差距，有必要使用中間軟體(middleware #),26,以Web為基礎的資料庫設計(5) p408,中間軟體(middleware #) 它是一種整合數種應用系統並允許它們交換資料的軟體。中間軟體能夠了解用戶端以HTML形式發出的請求並將之轉譯為資料庫能夠執行的指令。當資料庫反應該指令時，中間軟體再將此結果轉換成使用者的瀏覽器能夠顯示的HTML網頁，如圖7-9 一個廣受採用的中間軟體如: Macromedia 的 ColdFusion 。 資料安全 以Web為基礎的資料必須完全安全，但對有權使用的人又要易於取用。為達到此
23、一目標，設計完善的系統提供三階層的安全性: 資料庫本身、Web伺服器，及連結系統各元件的通訊線路。,27,資料設計術語(1) p410,定義 實體(entity #)是指人、地點、事物，或是資料收集與維護的事件。 例如: 線上銷售系統包含稱為客戶、訂單、產品，及供應商的實體。 當你在系統分析階段準備DFD時，你必須先確認各種不同的實體及資料儲存，現在你將分析它們之間的關係。 檔案或資料表 - 資料集合在一起形成檔案或是資料表。 資料表(table)或檔案(file)包含了一組有關於某特定實體的相關紀錄。 資料表及檔案通常以二維結構表示，其中包含垂直行代表欄位及水平列代表紀錄。 雖然在某些特殊狀
24、況下，資料表及檔案這兩個術語有不同的意義，但它們通常是可以互用的。,28,欄位(field #)或稱屬性(attribute #)，是關於某一個實體的單一特徵或事實。 共同欄位(common field)是指出現在一個以上的實體中之屬性。 共同欄位可用來在不同類型的關係中聯結數個實體。 紀錄(record #)也稱作列錄(tuple #，與couple諧音)，是用以描述實體的一個實例或其成員，例如: 一個客戶、一張訂單，或是一項產品的相關欄位集合。,資料設計術語(2) p411,主鍵,紀錄,欄位,29,資料設計術語(3) p411,鍵欄位在系統設計階段中，你使用鍵欄位(key fields)來
25、組織、存取，及維護資料結構。 鍵有四種類型: 主鍵、備選鍵、外來鍵，及次級鍵。 主鍵(primary key #)是能夠唯一且最簡短地指出實體中的某一特定成員的一個欄位或是數個欄位的組合。 例如，在客戶資料表中，客戶號碼就是一個唯一的主鍵，因為沒有任兩個客戶會有相同的客戶號碼。,30,資料設計術語(4) p412,主鍵也可以是由兩個或多個欄位組成。 若主鍵是由兩個或多個欄位所組成的，則此類主鍵稱為組合鍵(combination key #) 。 組合鍵也可被稱為複合鍵( composite key #), 接合鍵 (concatenated key #), 或是多值鍵(multi-valued
26、 key #)。 例如: 圖7-12所示成績資料表之學號與課號為一個組合鍵。 備選鍵 - 有時候會有好幾個欄位或是欄位組合，可以讓你選擇何者作為主鍵。 任何可作為主鍵的欄位就稱為備選鍵(candidate key #)，例如: 你可以使用員工號碼或是社會安全號碼作為主鍵。,31,資料設計術語(5) p412,你只能指定某一欄位為主鍵，通常是選擇資料量最少的欄位，比較容易使用。 只要不是主鍵或是備選鍵的欄位，都稱為非鍵欄位(nonkey field)。 外來鍵 - 在某資料表中的外來鍵(foreign key #)必須是另一資料表的主鍵，以建立此兩個資料表的關聯性。 外來鍵的值不一定是要唯一的，
27、此點與主鍵不同。 兩個外來鍵也可以組合而成為另一資料表的主鍵，例如: 圖7-12所示成績資料表之學號與課號兩個外來鍵合而為一個主鍵。,32,資料設計術語(6) p414,次級鍵(secondary key #)是一個欄位或是數個欄位的組合，可用以存取紀錄。 次級鍵的值不一定是唯一的，例如，如果你要取得郵遞區號是某個特定值的客戶，就可以使用郵遞區號做為次級鍵。 次級鍵也可以用來排序或是以某種順序來呈現紀錄。例如，你可以用學生檔案中的GPA欄位，以評分高低為序，呈現所有學生的紀錄。 例如: 圖7-12所示，學生姓名及指導老師姓名都被視為是次級鍵，當然也是可以使用其他欄位的。,33,資料設計術語(7
28、) p415,參照完整性 驗證檢查可以幫助避免資料輸入錯誤。 參照完整性(referential integrity #)是驗證檢查的一種類型，它是可用來避免資料不一致及發生品質問題的一組規則。 在關聯式資料庫中，參照完整性是指，某個外來鍵值除非可對應到另一個資料表的一個已存在的主鍵值，否則不可以被輸入到資料表。例如，除非客戶已經存在於客戶資料表中，否則參照完整性將制止你輸入一個客戶訂單到訂單資料表中。如果沒有參照完整性，你可能會產生稱為孤兒(orphan)的訂單，因為它沒有相對應的客戶。,34,資料設計術語(8) p415,如圖7-12中的例子所示，參照完整性將不允許使用者在學生資料表中輸入
29、指導老師號碼(它是外來鍵)，除非該指導老師號碼(此處是主鍵)已經存在於指導老師資料表中。 如果某筆紀錄的主鍵值有對應到另一個資料表的某些外來鍵值時，參照完整性也可以避免你將這種紀錄刪除。 當產生關聯式資料庫時，你可以將參照完整性建構在設計中。圖7-13所示的是Microsoft Access的畫面，它指出一個讓使用者能夠實行參照完整性規則的共同欄位。,35,實體關聯圖(1) p415,一個實體(entity #)可以是一個人、地點、物件，或是資料收集及維護的事件。例如，實體可能是客戶、銷售區域、產品，或訂單。一個資訊系統必須分辨各實體之間的關聯性。例如，一個客戶實體能夠有數個訂單實體的實例，而
30、一個員工實體可以有一個或沒有配偶實體的實例。一個ERD(實體關聯圖，Entity-Relationship Diagrams #)是一個展示各系統實體間的關聯性和互動的模型， ERD提供系統的全貌及產生實體資料架構的藍圖。,36,實體關聯圖(2) p416,繪製初步ERD(實體關聯圖，Entity-Relationship Diagrams #) 第一步是列出所有你在發現事實的過程中所指出的所有實體，並考量連結他們之間的關聯性的特性。 雖然有各種不同的方法可繪製ERD ，一個常用的方法是以方形表示實體，而以菱形代表關聯性(relationship #)，實體方形中標示單數名詞，關聯性菱形中則標
31、示主動動詞，通常以由上而下，由左而右的方式。例如，圖7-14中所示。,37,實體關聯圖(3) p416,與資料流程圖不同的是，實體關聯圖敘述關聯性，而不描述資料流或資訊流。(*需修改課文) 關聯性的類型 實體之間有三種主要的關聯性類型: 一對一、一對多，及多對多。 一對一關聯性 (one-to-one relationship)，簡記為1:1 ，發生在當第一個實體的每一個事例只關聯到第二個實體中的一個事例時。圖7-15所示的是一些可能的1:1實體關聯性的ERD 。 一對多關聯性(one-to-many relationship)，簡記為1: M，發生在當第一個實體的每一個事例可以關聯到第二個實
32、體中的多個事例時。 多可以是指任何數字，包含零。 圖7-16所示的是一些可能的1: M實體關聯的ERD 。,38,實體關聯圖(4) p418,多對多關聯性(many-to-many relationship)，簡記為M : N，發生在第一個實體的每一個事例可以關聯到第二個實體中的多個事例，而且，第二個實體的每一個事例可以關聯到第一個實體中的多個事例時。要注意的是M:N關聯性與1:1或是1:M關聯性是不相同的，因為連結這兩個實體的事件或交易事實上算是第三個實體，稱為結合實體(associative entity #)，它有自己專有的屬性及特徵集合。圖7-17所示的是一些M : N實體關聯性。 圖
33、7-18展示出一個銷售系統的ERD 。,39,實體關聯圖(5) p420,資料維數 資料維數(cardinality #)描述兩個實體間的數量關聯性，並展現一實體中的事例與另一實體中的事例如何相關聯。 例如: 考慮客戶與訂單兩個實體間的關聯性。 一個客戶可以有一個訂單，很多訂單，或是沒有訂單，但是每個訂單必須有一個且僅只有一個客戶。 系統分析師可藉由加入使用特殊符號表示關聯性的資料維數標記法(cardinality notation)來展現這種互動關係。 一個常用的資料維數標記法稱為鴨足標記法(crows foot notation)， 它用一些圓圈、線條，及符號來表示各種可能性。 單線代表一
34、個、雙線代表一個且僅只有一個、圓圈代表零個，而鴨足代表多個。 圖7-19所示的是資料維數的符號、意義，及UML表示法。,40,實體關聯圖(6) p421,在圖7-20中所示的是資料維數標記法的四種範例。 圖7-21所示的是使用Visible Analyst CASE工具所畫的圖書館系統的部分ERD圖。值得注意的是，鴨足標記法是用以表示關聯性的本質，它可以用來作雙向的解說。,41,實體關聯圖轉關聯表(1) 補充教材,當一個E-R 模式建立完成之後，除了可瞭解資料庫的概念性架構外，最主要的是可以根據一定的轉換規則將實體關聯圖轉換成關聯表（或稱資料表， 即Table）。 ERD範例,42,實體關聯圖
35、轉關聯表(2) 補充教材,43,實體關聯圖轉關聯表(3) 補充教材,對每一個一般性實體類型建立一個關聯表(Relation Table) ， 如: EMPLOYEE 對每一個弱實體類型(Weak Entity Type)(*參考下一投影片)建立一個關聯表，該關聯表之主鍵是由擁有者實體之主鍵與弱實體類型的不完全鍵所構成。如: DEPENDENT,44,實體關聯圖轉關聯表(3-1) 補充教材,以下是上頁投影片中英文縮寫的英文全名及中文說明 ESSN - Employees Social Security Number，社會安全碼(美國) BDATE - Birth Date，生日 FNAME -
36、First Name，名字 MNAME - Middle Name，另一名字 LNAME - Last Name，姓氏,45,實體關聯圖轉關聯表(4) 補充教材,在某些情況，一個實體案例(instance)之某一個屬性可能有一個以上的值，此情況稱 為多值屬性 (Multivalued Attributes)。 例如: 眷屬是員工(實體類型)的屬性之一，其眷屬資料為眷屬姓名、年齡與關係(配偶、孩子、父母等)，因一員工可能有多個眷屬，故眷屬是多值屬性。 兩種常用的多值屬性表示法: (1)用雙線的橢圖形表示 (2)用另一實體類型表示，並以線條與原實體類型相連 (*參考前兩頁投影片)，此種實體類型稱弱
37、實體類型(Weak Entity Type)或屬性實體(Attribute Entity Type) 。,46,實體關聯圖轉關聯表(5) 補充教材,對每一個多值屬性建立一個關聯表，其屬性是該多值屬性與擁有者實體類型之主鍵的集合，且其主鍵是由該關聯表之所有屬性所構成。如: DEPARTMENTDEPT_LOCATION (假設: 一個部門不只在一個地方),47,實體關聯圖轉關聯表(5-1) 補充教材,以下是上頁投影片中英文縮寫的英文全名及中文說明 DNAME - Department Name，部門名稱 DNUMBER(或DNO) Department Number，部門代號 MGRSSN Ma
38、nagers Social Security Number，經理的社會安全碼(是ESSN的部份集合) MGRSTARTDATE - Managers Start Date，開始當經理的起始日期 DLOCATION - Department Location，部門所在地點,48,實體關聯圖轉關聯表(6) 補充教材,對M:N(多對多)關係建立一個關聯表，其屬性是該關係上之所有屬性與兩個實體類型之主鍵的集合，且其主鍵為兩外來鍵之集合。如: EMPLOYEEPROJECTWORK_ON,49,實體關聯圖轉關聯表(7) 補充教材,對兩實體類型間之1:1關係作以下之處理 選擇任一實體類型視為S端(*參考第
39、2項說明)，將另一實體類型視為R端，將R端的主鍵包含進S端中，當成外鍵。 S端最好選擇具有完全參與關係的一端。實體類型EMPLOYEE 與 DEPARTMENT有WORKS_ FOR之關係， EMPLOYEE對WORKS_FOR是完全參與關係，也就是說， EMPLOYEE實體類型中之每一案例必須為某一個DEPARTMENT實體工作。 EMPLOYEE對MANAGES是部分參與關係，也就是說，並非EMPLOYEE實體類型中之每一案例均是管理者，而僅是一部分的人當主管而已。 在實體關係圖中，完全參與常用雙線連接，而部分參與常用單線連接。 將關係上之所有屬性包含入S端。 例如:,50,實體關聯圖轉關
40、聯表(8) 補充教材,EMPLOYEE(R端)DEPARTMENT(S端) (MGRSSN是ESSN的部份集合) 對兩實體類型間之1:N關係作以下之處理 選擇N端當作S端，將R端的主鍵包含進S端中當成外鍵。 將關係上之所有屬性包含入S端。 例如:,51,實體關聯圖轉關聯表(9) 補充教材,DEPARTMENT(R端)EMPLOYEE(S端)(以上九張補充教材摘錄自系統分析與設計理論與實務應用，吳仁和、林信惠 著，智勝文化公司),52,正規化(1) P424,正規化(normalization #)是你經由指定特定欄位或屬性給資料庫中的每個資料表，而產生資料表設計的過程。資料表設計(table
41、design)為某特定檔案或資料表規定其欄位，並指定其主鍵。由初始的資料表設計開始著手，你使用正規化來發展一個單純、具彈性，且可避免資料重複的整體資料庫設計。正規化程序通常包含四個階段: 未正規化的設計、第一正規形式、第二正規形式，及第三正規形式。 這三種正規形式構成一個進程，其中第三正規形式則代表最好的設計。 大多數業務相關的資料庫必須設計成第三正規形式。,53,正規化(2) P424,標準標記格式如果你使用一套標準標記格式(standard notation format)來顯示資料表的結構、欄位，及主鍵，那麼資料表的設計會比較容易。 其格式如下:資料表名稱(欄位1，欄位2，欄位3，)(其
42、中主鍵欄位被加以底線標示出來。) 重複群組及未正規化的設計 重複群組(repeating group)是指在單一紀錄中，可以出現任意次的單一或多個欄位的集合，其中每次發生均有不同的值。,54,正規化(3) P424,重複群組經常發生在由使用者製作的手工文件。 重複群組的一個實例，如圖7-22所示。你可以將重複群組想像成包含在父(主)紀錄中的子(附屬)紀錄的集合。 一個含有重複群組的資料表設計，可稱為未正規化的(unnormalized)，標準標記方法中表示一個未正規化設計的方式是以第二層的括弧將重複群組的欄位全部包在裏面， 如:資料表名稱(欄位1，欄位2，欄位3， (重複欄位1，重複欄位2，)
43、圖7-22中的未正規化的訂單資料表設計，你可以寫出這個紀錄的格式為:訂單(訂單號碼，訂單日期，(產品號碼，產品說明，訂購數量),55,正規化(4) P425,第一正規形式 如果資料表中不含重複群組，它就屬於第一正規形式(1NF, first normal form #) ，要將未正規化的設計轉成1NF，你必須先擴展主鍵，以包含重複群組的主鍵。 例如: 當你擴展訂單資料表的主鍵以包含產品號碼時，你就將重複群組消除，而訂單資料表變成1NF了，如下所示:訂單(訂單號碼，訂單日期，產品號碼，產品說明，訂購數量)圖7-23所示的訂單資料表是第一正規形式。,56,正規化(5) P427,第二正規形式 如果
44、欄位X的值是依欄位Y的值而定，則欄位X是函數相依(functionally dependent)於欄位Y。例如，在圖7-23中，訂單日期是相依於訂單號碼; 意即給定某一訂單號碼，就會有唯一的一個相對應的日期。*以下文字(p56p60)摘錄自系統分析與設計理論與實務應用，吳仁和、林信惠 著，智勝文化公司(詳細內容請參閱該書)* 功能相依(Functional Dependency)可定義如下:假設有一關聯表R，且 A與B是R的屬性。 B功能相依於A，或稱A在功能上決定B，寫成R.AR.B，若且唯若A屬性之值只會對應到一個B屬性之值。其中，A與B都可以是複合屬性。,57,正規化(6) 補充教材,若
45、屬性B功能相依於複合屬性A，但不功能相依於A的部分屬性，則稱B完全功能相依於A。一般所提之功能相依就是完全功能相依(Full Functional Dependency) 。 若B功能相依於A的某些部分，也就是說，若把A中之部分屬性刪除，而B仍然功能相依於A，則R.AR.B是部分功能相依(Partial Functional Dependency)。 若關聯表中存在非鍵屬性功能相依於一個或多個非鍵屬性，則稱此關聯表具有遞移相依(Transitive Dependency) 。,58,正規化(7) 補充教材,以下圖為例，關聯表R中有A、B、C、D與E五個屬性，其中A與B為主鍵，且A，B C、BD
46、、BE、DE。在下圖中，D部分功能相依於主鍵A，B ，因為去除A後，BD仍具有功能相依。此外，該關聯表中存在非主鍵屬性間的功能相依; 因為BE可由BD與DE得到，故BE在關對聯表中是遞移相依。,A,B,E,D,C,主鍵,59,正規化(8) 補充教材,第一正規化型式(First Normal Form, 1NF #),主要除去關聯表中任何的重複群，使關聯表中任一行與任一列的交叉格(Cell)上均只有一個值。 第二正規化型式(Second Normal Form, 2NF #)，符合第一正規化型式，再除去資料的部分功能相依。 第三正規化型式(Third Normal Form, 3NF #)，符合
47、第二正規化型式，再除去資料的遞移相依。,60,正規化(9) 補充教材,正規化的步驟,未經正規化的關聯表,第一正規化型式,第二正規化型式,第三正規化型式,除去重複群,除去部分相依,除去遞移相依,61,正規化(10) P427,如果資料表設計為1NF，且所有非主鍵的欄位皆相依於整個主鍵，則稱此資料表設計滿足第二正規形式(2NF, second normal form)。 如果在1NF資料表中的任何欄位，只相依於組合主鍵中的任一個欄位，則該資料表就不是2NF。 如果1NF資料表的主鍵只由一個欄位組成，那麼就不會發生部分相依的問題，因為整個主鍵是單一欄位。因此，一個具有單一欄位主鍵的1NF資料表自動地
48、成為2NF。 訂單資料表符合1NF但不符合2NF 訂單(訂單號碼，訂單日期，產品號碼，產品說明，訂購數量),62,正規化(11) P427,將資料表從1NF轉換成2NF有一個標準程序。其目的是將原來的資料表分割成兩個或更多的新資料表，並重新分派欄位使得每個非鍵欄位都會相依於其資料表中的整個主鍵。 為完成這個，你必須依照以下各步驟:1. 為主鍵中的每一個欄位建立新的資料表並命名。在圖7-23的例子中，訂單資料表的主鍵有兩個欄位，所以你可以產生兩個資料表，其結果為:,訂單號碼,產品號碼,訂單日期,訂購數量,產品說明,部份功能相依,部份功能相依,完全功能相依,63,正規化(12) P428,訂單(訂單號碼，) 產品(產品號碼，) 其中的點線()表示欄位稍後才會指 定。2. 為原來主鍵各欄位的每種可能組合建立一張新資料表。 在圖7-23的例子中，你會為主鍵的組合訂單號碼及產品號碼建立一個新的資料表並加以命名。 如下所示: 訂單項目(訂單號碼，產品號碼，)3. 將其餘的欄位與適當的主鍵放在一起，亦即它所相依的最小鍵，並給每一個紀錄命名。如下所示: 訂單(訂單號碼，訂單日期) 產品(產品號碼，產品說明) 訂單項目(訂單號碼，產品號碼，訂購數量),
