第8章 資料設計
簡介 在系統分析階段，你已製作完成資料流程圖，從而建立資訊系統的邏輯設計。 在系統設計階段的這一部份，你將發展資料的組織、儲存，及擷取之實體計畫。
資料設計觀念(1) 資料結構 資料結構(data structure #)是在資訊系統中，組織及儲存資料的架構。 資料結構由檔案或資料表所組成，它們都會以不同的方式連結。 每個檔案(file)或資料表(table)包含有關人、地、物或事件的資料，這些資料都與資訊系統進行互動。 根據系統的檔案或資料表組織及連結的方式不同，資訊系統可以稱為檔案處理系統，或是資料庫管理系統。 檔案處理系統(file processing system)或稱為檔案導向系統(file-oriented system)，它會將資料儲存在一個或多個檔案中，並加以管理。(圖8-2) 。 檔案導向系統的主要缺點之一是相同的資料會存放在多個地方。
資料設計觀念(2) 資料庫系統(database system #)是由互相連接而構成整體資料結構的資料表所組成。 與檔案處理相較，資料庫系統提供比較大的彈性及效率。 (圖8-3) 檔案處理系統仍然存在，並用來處理特定的應用程式，但今日大部分的資訊系統都採用資料庫設計。 檔案處理概述 許多舊系統之所以使用檔案處理設計，是因為這種方式很適合大型主機的硬體架構與批次的輸入。 雖然在今日已較不普遍，但在某些狀況下，檔案處理還是相當有效率，且符合成本效益的原則。(圖8-4信用卡公司可能使用檔案處理系統，將每日的交易從TRAINSACTION檔過帳到CUSTOMER檔。)。
資料設計觀念(3) 在典型的檔案處理環境中，公司可能有三個部門，但每一個部門都有自己的資訊系統及資料檔案。 在檔案處理的環境中，存有三個潛在問題: 第一個問題是資料重複(data redundancy #)，意指兩個或多個資訊系統中之相同的資料被存放在許多地方。 資料重複需要更多的儲存空間，而且維護及更新多個地點的資料也比較為昂貴。 (圖8-2) 第二，如果無法同時更新每一個檔案，就會產生資料完整性(data integrity #)的問題。 只有更改系統中的一個檔案，將會產生不一致的資料，而導致在後續系統中的不正確資訊。
資料設計觀念(4) 在檔案導向的資訊系統，可能包含各種類型的檔案，包含: 主檔、對照表檔、交易檔、工作檔、安全檔，及歷史檔。 第三個問題是典型檔案處理環境中的僵硬資料結構(rigid data structure)。 企業必須依據整個公司的資料做出決策，經理人通常需要從數個企業單位及部門取得資訊。在檔案處理環境中，要從各個各自獨立檔案系統中取得資訊是很慢且沒有效率的。 (圖8-2) 在檔案導向的資訊系統，可能包含各種類型的檔案，包含: 主檔、對照表檔、交易檔、工作檔、安全檔，及歷史檔。 主檔(master file)儲存的是實體中比較持久性的資料。例如︰「產品」主檔，在每一紀錄中的「數量」欄可能每天變動，但是其他資料如產品代碼、名稱，及描述則不會變動。其他如︰課程、學生、及教職員主檔。
資料設計觀念(5) 對照表檔(table file)包含資訊系統所使用的參考資料。 與主檔相同，對照表檔的資料也比較持久，而不被資訊系統經常更動，例如︰稅率對照表、郵資對照表等。 交易檔(transaction file)儲存的紀錄，含有每日經營及運作的資料。 交易檔是用以更新主檔的輸入檔; 當完成更新後，交易檔即達成使命，除非基於安全或備份理由，通常交易檔是暫時性的檔案。例如︰用以更新顧客餘額檔案的收款及付款檔案。 工作檔(work file)是一種暫存檔(scratch file)，由資訊系統為了單一工作而產生。 例如︰列印報表所需的排序檔或是報表檔，它們會在列印之前，暫存報表的輸出內容。
資料設計觀念(6) 從檔案系統演進為資料庫系統 安全檔(security file)是基於備份與還原的目的，而建立及儲存的檔案。例如︰稽核檔以及主檔、對照表檔，及交易檔的備份。 系統必須定期產生新的安全檔，以便取代過期的檔案。 歷史檔(history file)是基於封存目的而建立的檔案。 例如︰在過去兩學期未註冊的學生紀錄，可從現行學生主檔中刪除，然後加到中輟檔中，此檔即是歷史檔的一種類型，如果中輟檔中的學生又再度註冊，則他的資料紀錄就從中輟檔中刪除並加到現行學生主檔中。 從檔案系統演進為資料庫系統 資料庫提供的是整體架構，可以避免資料重複及支援即時與動態的環境，這正是檔案處理系統兩個潛在的問題。
資料設計觀念(7) 在檔案處理環境中，資料檔案的作用是符合個別的企業系統。 相反地，在資料庫環境中，則可以根據單一資料庫而建立多套系統。(ref. p344 圖8-5)。 資料庫管理系統(DBMS, database management system #))指的是一組工具、功能與介面，可以讓使用者新增、更新、管理、存取及分析資料的內容。 從使用者的角度來看， DBMS的主要優點是它提供即時、互動，且彈性的資料存取。DBMS的具體優點如下列各點:
資料設計觀念(8) 擴充性(scalability)意指系統可以很容易擴充、更改，或縮小，以滿足企業經營中快速改變的需求。例如︰如果一個公司決定加入有關其所用原料的次級供應商資料時，就可以在關聯式資料庫中加入新的資料表，以一個共用欄位聯結起來。 提供主從式(client/server)系統更好的支援。 規模經濟。 大型電腦上，大量資料處理的效率稱為規模經濟(economy of scale)。 資料庫設計可使硬體有較好的利用率。 有彈性的資料分享。 因為資料庫設計是相當具有彈性的，故使用者能夠以不同方式來檢視相同資訊。資料可以分享給整個企業組織。
資料設計觀念(9) 涵蓋企業全體的應用系統。 通常， DBMS是由稱為資料庫管理師(DBA, database administrator #)的人所管理，他依據整個組織，而不是單一部門或個人的利益，來評估整體需求及維護資料庫。 更堅強的標準。 有效的資料庫管理可保證資料名稱、格式，及文件的標準，在整個組織中能夠被一致遵循。 資料重複的現象在控制範圍內。 資料重複意即在一個地方以上存放資料，而能造成不一致及資料錯誤。 因為資料儲存在一組相關的資料表中，資料項目不需要在不同位置中重複儲存。 更好的安全性。 DBA可以定義授權規則，以保證只有合法使用者可以存取資料庫及允許不同使用者具備不同等級的存取權限。
資料設計觀念(10) 資料庫的權衡與取捨 因為DBMS的功能相當強大，它們需要更貴的硬體、軟體，以及支援多使用者環境的資料網路。 提升程式設計師的生產力。 程式設計師不需要產生資料庫的基本檔案結構。如此，可讓他們專注於邏輯設計上。 資料的獨立性。 與DBMS互動的系統，比較可以不考慮實體資料的維護方式。這種設計提供DBA變更資料結構的彈性，但不需要更動使用這些資料的資訊系統。 資料庫的權衡與取捨 因為DBMS的功能相當強大，它們需要更貴的硬體、軟體，以及支援多使用者環境的資料網路。 DBMS也比檔案處理系統更複雜;因此，對於系統分析師、資料庫管理師，及使用者的學習曲線通常都較為陡峭，此即提高總持有成本。
資料設計觀念(11) 在資料庫環境中，安全性、備份，及回復等程序都相當複雜且重要。當公司將所有重要資料資源都放在一個資料庫時，一個DBMS的故障都將有可能嚴重癱瘓企業的營運。 雖然目前的趨勢是朝向整個企業組織的資料庫設計，許多公司仍然使用集中式DBMS與規模較小的、屬於部門等級的資料管理系統(即分散式資料管理系統)的組合。 採集中式DBMS之理由為︰大部分企業視資料為整個公司的資源而必須可以讓公司的所有使用者都能存取。 促成分散式設計之因素如下︰
資料設計觀念(12) 在許多狀況下，主從式設計就成為折衷方案，其中的資料處理可由數台電腦來分享。主從式系統將在第九章中說明。 網路費用降低。 不願意放棄較小但較有彈性的系統。 瞭解整個企業組織的DBMS的維護可能是非常複雜且昂貴。 在許多狀況下，主從式設計就成為折衷方案，其中的資料處理可由數台電腦來分享。主從式系統將在第九章中說明。
DBMS元件(1) DBMS提供資料庫與需要存取資料的使用者之間的介面。 除了給使用者、資料庫管理師，及相關系統的介面之外, DBMS也擁有資料處理語言、結構描述與子結構描述，及實體資料的儲存機制，如p346圖8-6所示。
DBMS元件(2) 使用者、資料庫管理師，及相關系統的介面 使用者 --- 使用者通常依據事先定義的查詢及切換表單的命令來進行操作，但也使用查詢語言來取用儲存的資料。 查詢語言(query language #)允許使用者指定一項工作而不用規定其實際的執行步驟。 利用範例式查詢(QBE, query by example #)語言，使用者可提供所需資料的例子。 許多資料庫程式也產生結構化查詢語言(SQL, structured query language #)，它可讓PC使用者與伺服器或大型電腦進行溝通。(p347 圖8-7a ，圖8-7b所示)
DBMS元件(3) 資料庫管理師 --- (DBA，Database Administrator #)負責DBMS (Database Management System #，資料庫管理系統)的管理及支援。 DBA所關心的是資料安全性及完整性、防止未經授權的存取、提供備份及還原、稽核軌跡，維護資料庫，與支援使用者的需求。 大部分的DBMS提供公用程式以協助DBA產生及更新資料結構、蒐集及報告資料庫的使用情況，與偵測及報告的資料庫異常狀況。
DBMS元件(4) 相關資訊系統 --- DBMS可以支援許多相關的資訊系統，提供輸入給DBMS或從DBMS取得特定資料。 與使用者介面不同的是，在DBMS與相關系統之間的雙向溝通中，並不需要人力的介入。 資料處理語言 資料處理語言(DML, data manipulation language #)控制資料庫的運作，包含資料的儲存、擷取、更新，及刪除。 大部分商用DBMS都使用DML ，如Oracle及IBM的DB/2。 許多資料庫產品，如 Microsoft Access, 也提供容易使用的圖形化環境，讓使用者得以使用選單式命令來操控資料庫的運作。
DBMS元件(5) 結構描述(綱目) 資料庫的完整定義稱為結構描述(schema #) ，包含所有欄位、資料表，及關係的描述。 資料表名稱、資料表屬性所成的集合與各屬性的相對資料型態，再加上主索引鍵的宣告及外部索引鍵的宣告，這些內容整個構成資料表的結構，用來描述該資料表，我們稱之為「資料表的結構描述」。 例如: Books(id(int), bookname(string), author(string), price(int), publisher(string))
DBMS元件(6) 子結構描述(subschema)是資料庫的檢視表，提供一個或多個系統或使用者使用。 子結構描述只定義該資料庫中，特定系統或使用者需要的或是被允許存取的部分。例如，為保護個人隱私，你可能不希望某專案管理系統可以取得個別員工的薪資。在這種狀況下，此一專案管理系統的子結構描述就不可以包含薪資欄位。資料庫設計者也使用子結構描述來限制所允許的存取等級。 實體資料的儲存機制 在系統開發程序的這個階段中，資料詞典將轉換成實體資料的儲存機制，它也包含結構描述及子結構描述。
DBMS元件(7) 實體儲存機制可以是集中式，或是分散於許多不同的地點。此外，存放的資料可能是由單一個DBMS或多個系統來管理。 為解決資料庫連結及存取的潛在問題，許多公司採用符合ODBC協定的軟體，而能夠在各種系統及DBMS之間互相通訊。ODBC意即開放式資料庫連結(open database connectivity #)，它是一套產業的標準協定，讓不同廠商開發的軟體能夠互動並交換資料。ODBC採用DBMS能瞭解並執行的SQL陳述。(Ref. ODBC的架構) 另一常見的標準是 JDBC (Java database Connectivity) 。 JDBC讓Java 應用程式能夠與任何使用SQL陳述且遵循JDBC的資料庫交換資料。
以網站(Web)為基礎的資料庫設計(1) 以網站(Web)為基礎的設計特徵 在以Web為基礎的設計中， Internet是作為資料庫管理系統的前端或介面。 網際網路科技提供強大的功能及彈性，因為該系統不受制於任何特定硬體及軟體的組合。只需要一個網頁瀏覽器及網路連線就可以取用資料庫。 以Web為基礎的系統之所以廣受採用，就是因為他們提供簡便、符合成本效益，且遍及全球的連結。 因為以internet為通訊網路，所以初期投資相當低。使用者只需要瀏覽器，而以Web為基礎的系統不需要強力的工作站。因為在開發、主機代管、維護及系統支援有各種的委外選擇，所以彈性大。
以Web為基礎的資料庫設計(2) 網際網路術語 網頁瀏覽器(Web browser #)，這是一種讓使用者能夠在Internet上遊走或瀏覽以及在其電腦上顯示網頁的應用程式。 所謂網頁(Web page #)是一個以超文字標記語言(HTML，Hypertext Markup Language #)所撰寫的純文字文件。 (參考:網頁實例) HTML使用許多稱為標記(tag)的格式化代碼，指示文字及視覺元素在網頁瀏覽器上的顯示方式。 網頁存放在網頁伺服器(Web server #)上，而它是一部接受使用者請求，並將網頁傳送給使用者的電腦。 將網頁伺服器和網頁的結合，就構成所謂的網站(Web site #)。
以Web為基礎的資料庫設計(3) 除了維護一個網站之外，許多公司使用企業內部網路及企業外部網路來支援企業運作及通訊。 企業內部網路(intranet #)是一個公司擁有的私有網路，可提供內部使用者存取網頁的內容。 企業外部網路(extranet #)則是企業內部網路的延伸，讓外部使用者，如顧客及供應商，也可以存取。 企業間(B2B)資料分享及EDI (電子資料交換， Electronic Data Interchange #)都是企業外部網路的典型範例。 因為intranet及extranet使用與lnternet相同的協定(protocols #)或資料傳輸標準，他們均被稱為以網際網路為核心(Web-centric)的通訊方式。 。
以Web為基礎的資料庫設計(4) 資料庫與網站的連結方式 Internet及公司的intranet/extranet都是主從式(client / server #)架構。 在主從式設計下，工作會在用戶端(client #)間進行切割，用戶端是使用者與伺服器互動的工作站，伺服器(server #)則是供應資料、處理能力及服務給用戶端工作站的電腦。 資料庫與網站的連結方式 如果要存取網站式(web)系統中的資料，該資料庫必須連接網際網路或企業內部網路。不過，資料庫和網際網路使用的是兩種不同的語言。 資料庫使用各種語言及指令來產生及管理資料，而這些與網站所使用的HTML語言完全無關。 因此，需要為資料庫與網站建立連結，以便檢視與更新資料。 爲了彌補此一差距，有必要使用中介軟體(middleware #) 。
以Web為基礎的資料庫設計(5) 資料的安全性 中介軟體(middleware #) 它是一種整合不同的應用系統，並允許它們交換資料的軟體。 中介軟體能夠瞭解用戶端以HTML形式發出的請求並將之轉譯為資料庫能夠執行的指令。當資料庫反應該指令時，中介軟體再將此結果轉換成使用者的瀏覽器能夠顯示的HTML網頁，如圖8-9 一個廣受採用的中介軟體如: Adobe的ColdFusion 。 資料的安全性 網站式的資料必須受到保護，但對有權使用的人又要能易於存取。為達到此一目標，設計完善的系統提供三個層次的安全性: 資料庫本身、網頁伺服器，及連結系統各元件的通訊線路。
資料設計的術語(1) 定義 實體(entity #)是指人、地點、事物或事件，它們都是資料蒐集與維護的對象。 例如: 線上銷售系統包含稱為「顧客」、「訂單」、「產品」，及「供應商」的實體。 當你在系統分析階段準備DFD時，你必須先確認各種不同的實體及資料儲存，現在你將分析它們之間的關係。 資料表或檔案--- 資料會組織成資料表或檔案。 資料表(table)或檔案(file)包含一組有關於某特定實體的相關紀錄。 資料表及檔案通常以二維結構表示，其中包含垂直行代表欄位及水平列代表紀錄。 雖然在某些特殊狀況下，資料表及檔案這兩個術語有不同的意義，但它們通常是可以交換使用的。
資料設計的術語(2) 主索引鍵 顧客ID 名 姓 地址 城市 州 郵遞區號 E-mail MOR976 James Morgan 114 Elmore Avenue Bremerton WA 98310 jm@ct.net PIC367 Kate Picadilly 6 Indian Trail Liberty MO 64068 pd@mon.com BEL245 Rex Bell PO Box 3, Route 1 Butte MT 59701 rxbell@xyz.com 紀錄 欄位 欄位(field #)或稱屬性(attribute #)，是關於某一個實體的單一特徵或事實。 共同欄位(common field)是指出現在一個以上的實體中之屬性。 共同欄位可用來連結不同關係類型的實體。 紀錄(record #)也稱作元組(tuple #，與couple諧音)，是用以描述實體的一個實例或其成員，例如: 一個顧客、一張訂單，或是一項產品的相關欄位集合。
資料設計的術語(3) 索引鍵欄位 在系統設計階段中，你使用索引鍵欄位(key fields)來組織、存取，及維護資料結構。索引鍵欄位有四種類型: 主索引鍵、候選鍵、外部索引鍵，及次選鍵。 主索引鍵(primary key #)是能夠唯一且最簡短地指出實體中的某一特定成員的一個欄位或是數個欄位的組合。 例如，在顧客資料表中，顧客號碼就是一個唯一的主索引鍵，因為沒有任兩個顧客會有相同的顧客號碼。
資料設計的術語(4) 主索引鍵也可以是由兩個或多個欄位組成。 若主索引鍵是由兩個或多個欄位所組成的，則此類主索引鍵稱為組合鍵(combination key #) 。 組合鍵也可被稱為複合鍵( composite key #), 接合鍵 (concatenated key #), 或是多值鍵(multi-valued key #)。 例如: 圖8-12所示「成績資料表」之「學號」與「課號」為一個組合鍵。 候選鍵 --- 有時候會有好幾個欄位或是欄位組合，可以讓你選擇何者作為主索引鍵。 任何可作為主索引鍵的欄位就稱為候選鍵(candidate key #)，例如: 你可以使用員工號碼或是社會安全號碼作為主索引鍵。
資料設計的術語(5) 你只能指定某一欄位為主索引鍵，通常是選擇資料量最少，而且最容易使用的欄位。 只要不是主索引鍵或是候選鍵的欄位，都稱為非索引鍵欄位(nonkey field)。 外部索引鍵 --- 在某資料表中的外部索引鍵(foreign key #)必須是另一資料表的主索引鍵，以建立此兩個資料表的關係。 外部索引鍵的值不一定是要唯一的，此點與主索引鍵不同。 兩個外部索引鍵也可以組合而成為另一資料表的主索引鍵，例如: 圖8-12所示「成績資料表」之「學號」與「課號」兩個外部索引鍵合而為一個主索引鍵。
資料設計的術語(6) 次選鍵(secondary key #)是一個欄位或是數個欄位的組合，可用以存取紀錄。 次選鍵的值不一定是唯一的，例如，如果你只需要存取特定郵遞區號中的顧客，就可以使用郵遞區號做為次選鍵。 次選鍵也可以用來排序或是以某種順序來呈現紀錄。例如，你可以用「學生」檔案中的GPA欄位，以評分高低為序，呈現所有學生的紀錄。 例如: 圖8-12所示，學生姓名及指導老師姓名都被視為是次選鍵，當然也是可以使用其他欄位的。
資料設計的術語(7) 參考完整性 有效性(驗證)檢查可以幫助避免資料輸入錯誤。 參考完整性(referential integrity #)是有效性(驗證)檢查的一種類型，它是可用來避免資料不一致及發生品質問題的一組規則。 在關聯式資料庫中，參考完整性是指，某個外部索引鍵值除非可對應到另一個資料表的一個已存在的主索引鍵值，否則不可以被輸入到資料表。例如，除非顧客已經存在於顧客資料表中，否則參考完整性將制止你輸入一個顧客訂單到訂單資料表中。如果沒有參考完整性，你可能會產生稱為孤兒(orphan)的訂單，因為它沒有相對應的顧客。
資料設計的術語(8) 如圖8-12中的例子所示，參考完整性將不允許使用者在「學生」資料表中輸入指導老師號碼(它是外部索引鍵)，除非該指導老師號碼(此處是主索引鍵)已經存在於「指導老師」資料表中。 如果某筆紀錄的主索引鍵值有對應到另一個資料表的某些外部索引鍵值時，參考完整性也可以避免你將這種紀錄刪除。 當產生關聯式資料庫時，你可以將參考完整性建構在設計中。圖8-13所示的是Microsoft Access的畫面，它指出一個讓使用者能夠實行參考完整性規則的共同欄位。
實體關係圖(1) 一個實體(entity #)可以是一個人、地點、事物，或事件，它們都是資料蒐集與維護的對象。 例如，實體可能是顧客、銷售區域、產品，或訂單。一個資訊系統必須分辨各實體之間的關聯性。例如，一個顧客實體能夠有數個訂單實體的實例，而一個員工實體可以有一個或沒有配偶實體的實例。 一個ERD(實體關係圖，Entity-Relationship Diagrams #)是一個顯示系統實體間邏輯關係和互動的模型， ERD提供系統的全貌及建立實體資料架構的藍圖。
實體關係圖(2) 繪製ERD的方法 第一步是列出系統分析階段中辨識出的實體，並考量連結它們的關係本質。 雖然有各種不同的方法可繪製ERD ，一個常用的方法是以矩形表示實體，而以菱形代表關聯性(relationship #)，實體矩形中標示單數名詞，關聯性菱形中則標示主動動詞，通常以由上而下，由左而右的方式呈現。例如，圖8-14中所示。
實體關係圖(3) 關係的類型 與資料流程圖不同的是，實體關係圖描述的是關聯性，而不描述資料流或資訊流。 實體之間有三種主要的關係類型: 一對一、一對多，及多對多。 一對一關係 (one-to-one relationship)，簡記為1:1 ，發生在當第一個實體的每一個執行個體只關聯到第二個實體中的一個執行個體時。圖8-15所示的是一些可能的1:1實體關係的ERD 。 一對多關係(one-to-many relationship)，簡記為1: M，發生在當第一個實體的每一個執行個體可以關聯到第二個實體中的多個執行個體時。 「多」可以是指任何數字，包含零。 圖8-16所示的是一些可能的1: M實體關聯的ERD 。
實體關係圖(4) 多對多關係(many-to-many relationship)，簡記為M : N，發生在第一個實體的每一個執行個體可以關聯到第二個實體中的多個執行個體，而且，第二個實體的每一個執行個體可以關聯到第一個實體中的多個執行個體時。 要注意的是M:N關係與1:1或是1:M關係是不相同的，因為連結這兩個實體的事件或交易事實上算是第三個實體，稱為關聯實體(associative entity #)，它有自己專有的屬性及特徵集合。 圖8-17所示的是一些M : N實體關係。 圖8-18展示出一個銷售系統的ERD 。
實體關係圖(5) 基數 基數(cardinality #)描述兩個實體間的數量關係，並展現一實體中的執行個體與另一實體中的執行個體如何相關聯。 例如: 考慮「顧客」與「訂單」兩個實體間的關係。 一個顧客可以有一個訂單，很多訂單，或是沒有訂單，但是每個訂單必須有一個且僅只有一個顧客。 系統分析師可藉由加入使用特殊符號表示關係的基數表示法(cardinality notation)來展現這種互動關係。 一個常用的基數表示法稱為鴨足表示法(crow's foot notation)， 它用一些圓圈、線條，及符號來表示各種可能性。 單線代表一個、雙線代表一個且僅只有一個、圓圈代表零個，而鴨足代表多個。 圖8-19所示的是基數的符號、意義，及UML表示法。
實體關係圖(6) 在圖8-20中所示的是基數表示法的四種範例。 圖8-21所示的是使用Visible Analyst CASE工具所畫的圖書館系統的部分ERD圖。值得注意的是，鴨足表示法是用以表示關係的本質，並從兩個方向加以描述。
實體關係圖轉關聯表(1) 補充教材 當一個E-R 模式建立完成之後，除了可瞭解資料庫的概念性架構外，最主要的是可以根據一定的轉換規則將實體關係圖轉換成關聯表（或稱資料表，即Table）。 ERD範例
實體關係圖轉關聯表(2) 補充教材 To P45 To P48 To P49 To P50
實體關係圖轉關聯表(3) 補充教材 對每一個一般性實體類型建立一個關聯表(Relation Table) ， 如: EMPLOYEE 實體關係圖轉關聯表(3) 補充教材 對每一個一般性實體類型建立一個關聯表(Relation Table) ， 如: EMPLOYEE 對每一個弱實體類型(Weak Entity Type)(*參考下兩頁投影片)建立一個關聯表，該關聯表之主索引鍵是由擁有者實體之主索引鍵與弱實體類型的不完全鍵所構成。如: DEPENDENT ESSN BDATE FNAME MNAME LNAME SEX ADDRESS SALARY ESSN NAME SEX BIRTHDAY RELATIONSHIP
實體關係圖轉關聯表(3-1) 補充教材 以下是上頁投影片中英文縮寫的英文全名及中文說明︰ 實體關係圖轉關聯表(3-1) 補充教材 以下是上頁投影片中英文縮寫的英文全名及中文說明︰ ESSN --- Employee's Social Security Number，社會安全碼(美國) BDATE -- Birth Date，生日 FNAME -- First Name，名字 MNAME -- Middle Name，另一名字 LNAME -- Last Name，姓氏
實體關係圖轉關聯表(4) 補充教材 在某些情況，一個實體案例(instance)之某一個屬性可能有一個以上的值，此情況稱 為多值屬性 (Multivalued Attributes)。 例如: 眷屬是員工(實體類型)的屬性之一，其眷屬資料為眷屬姓名、年齡與關係(配偶、孩子、父母等)，因一員工可能有多個眷屬，故眷屬是多值屬性。(To ERD) 兩種常用的多值屬性表示法: (1)用雙線的橢圖形表示﹔ (2)用另一實體類型表示，並以線條與原實體類型相連 (*參考前三頁投影片)，此種實體類型稱弱實體類型(Weak Entity Type)或屬性實體(Attribute Entity Type) 。
實體關係圖轉關聯表(5) 補充教材 對每一個多值屬性建立一個關聯表，其屬性是該多值屬性與擁有者實體類型之主索引鍵的集合，且其主索引鍵是由該關聯表之所有屬性所構成。 如: DEPT_LOCATION (假設: 一個部門不只在一個地方) DEPARTMENT DNUMBER DLOCATION DNAME DNUMBER MGRSSN MGRSTARTDATE
實體關係圖轉關聯表(5-1) 補充教材 以下是上頁投影片中英文縮寫的英文全名及中文說明︰ 實體關係圖轉關聯表(5-1) 補充教材 以下是上頁投影片中英文縮寫的英文全名及中文說明︰ DNAME --- Department Name，部門名稱 DNUMBER(或DNO) – Department Number，部門代號 MGRSSN – Manager's Social Security Number，經理的社會安全碼(是ESSN的部份集合) MGRSTARTDATE - Manager's Start Date，開始當經理的起始日期 DLOCATION - Department Location，部門所在地點
實體關係圖轉關聯表(6) 補充教材 對M:N(多對多)關係建立一個關聯表，其屬性是該關係上之所有屬性與兩個實體類型之主索引鍵的集合，且其主索引鍵為兩外部索引鍵之集合。如: (To ERD) EMPLOYEE PROJECT WORK_ON ESSN BDATE FNAME MNAME LNAME SEX ADDRESS SALARY DNO PNAME PNUMBER PLOCATION DNO ESSN PNUMBER HOUR
實體關係圖轉關聯表(7) 補充教材 對兩實體類型間之1:1關係作以下之處理 實體關係圖轉關聯表(7) 補充教材 對兩實體類型間之1:1關係作以下之處理 選擇任一實體類型視為S端(*參考第2項說明)，將另一實體類型視為R端，將R端的主索引鍵包含進S端中，當成外部索引鍵。 (To ERD) S端最好選擇具有完全參與關係的一端。 實體類型EMPLOYEE 與 DEPARTMENT有WORKS_ FOR之關係， EMPLOYEE對WORKS_FOR是完全參與關係，也就是說， EMPLOYEE實體類型中之每一案例必須為某一個DEPARTMENT實體工作。 EMPLOYEE對MANAGES是部分參與關係，也就是說，並非EMPLOYEE實體類型中之每一案例均是管理者，而僅是一部分的人當主管而已。 在實體關係圖中，完全參與常用雙線連接，而部分參與常用單線連接。 將關係上之所有屬性包含入S端。 例如:
實體關係圖轉關聯表(8) 補充教材 EMPLOYEE(R端) DEPARTMENT(S端) (MGRSSN是ESSN的部份集合) 實體關係圖轉關聯表(8) 補充教材 EMPLOYEE(R端) DEPARTMENT(S端) (MGRSSN是ESSN的部份集合) 對兩實體類型間之1:N關係作以下之處理 選擇N端當作S端，將R端的主索引鍵包含進S端中當成外部索引鍵。 (To ERD) 將關係上之所有屬性包含入S端。 例如: ESSN BDATE FNAME MNAME LNAME SEX ADDRESS SALARY DNAME DNUMBER MGRSSN MGRSTARTDATE 關係上之所有屬性包含入S端 將R端的主索引鍵包含進S端中
將R端的主索引鍵包含進S端中當成外部索引鍵 實體關係圖轉關聯表(9) 補充教材 DEPARTMENT(R端) EMPLOYEE(S端) (以上補充教材摘錄自「系統分析與設計理論與實務應用，吳仁和、林信惠 著，智勝文化公司」) DNAME DNUMBER MGRSSN MGRSTARTDATE 將R端的主索引鍵包含進S端中當成外部索引鍵 ESSN BDATE FNAME MNAME LNAME SEX ADDRESS SALARY DNO
正規化(1) 正規化(normalization #)是藉由指派特定欄位或屬性給資料庫中的每個資料表，而產生資料表設計的過程。 資料表設計(table design)會為某特定檔案或資料表規定其欄位，並指定其主索引鍵。 由初始的資料表設計開始著手，你使用正規化來發展一個簡單、具彈性，且可避免資料重複的整體資料庫設計。 正規化程序通常包含四個階段: 未正規化的設計、第一正規化型式、第二正規化型式，及第三正規化型式。 這三種正規化型式構成改進的順序，其中第三正規化型式代表最好的設計。 大多數與企業相關的資料庫，都必須設計成第三正規化型式。
正規化(2) 標準表示法格式 重複群組及未正規化的設計 如果你使用一套標準表示法格式(standard notation format)來顯示資料表的結構、欄位，及主索引鍵，那麼資料表的設計會比較容易。 其格式如下: 資料表名稱(欄位1，欄位2，欄位3，…) (其中主索引鍵欄位被加以底線標示出來。) 重複群組及未正規化的設計 重複群組(repeating group)指的是一組欄位，它們在單一紀錄中可能出現任何次數，而每次出現時的數值都不相同。
正規化(3) 重複群組經常發生在由使用者製作的手工文件。 重複群組的一個實例，如圖8-22所示。你可以將重複群組想像成包含在父(主)紀錄中的子(附屬)紀錄的集合。 一個含有重複群組的資料表設計，可稱為未正規化的(unnormalized)，標準表示法方法中表示一個未正規化設計的方式是以第二層的括弧將重複群組的欄位全部包在裏面， 如: 資料表名稱(欄位1，欄位2，欄位3， …(重複欄位1，重複欄位2，…)) 圖8-22中的未正規化的「訂單」資料表設計，你可以寫出這個紀錄的格式為: 訂單(訂單號碼，訂單日期，(產品號碼，產品說明，訂購數量))
正規化(4) 第一正規化型式 如果資料表中不含重複群組，它就屬於第一正規化型式(1NF, first normal form #) ，要將未正規化的設計轉成1NF，你必須先擴展主索引鍵，以包含重複群組的主索引鍵。 例如: 當你擴展「訂單」資料表的主索引鍵以包含「產品號碼」時，你就將重複群組消除，而「訂單」資料表變成1NF了，如下所示: 訂單(訂單號碼，訂單日期，產品號碼，產品說明，訂購數量) 圖8-23所示的「訂單」資料表是第一正規化型式。
正規化(5) 第二正規化型式 如果欄位X的值是依欄位Y的值而定，則欄位X是功能相依(functionally dependent)於欄位Y。例如，在圖8-23中，「訂單日期」是相依於「訂單號碼」; 意即給定某一訂單號碼，就會有唯一的一個相對應的日期。 ***以下文字(p56~p60)摘錄自「系統分析與設計理論與實務應用，吳仁和、林信惠 著，智勝文化公司」(詳細內容請參閱該書)*** 功能相依(Functional Dependency)可定義如下:假設有一關聯表R，且 A與B是R的屬性。 B功能相依於A，或稱A在功能上決定B，寫成R.AR.B，若且唯若A屬性之值只會對應到一個B屬性之值。其中，A與B都可以是複合屬性。
正規化(6) 補充教材 若屬性B功能相依於複合屬性A，但不功能相依於A的部分屬性，則稱B完全功能相依於A。一般所提之功能相依就是完全功能相依(Full Functional Dependency) 。 若B功能相依於A的某些部分，也就是說，若把A中之部分屬性刪除，而B仍然功能相依於A，則R.AR.B是部分功能相依(Partial Functional Dependency)。 若關聯表中存在非鍵屬性功能相依於一個或多個非鍵屬性，則稱此關聯表具有遞移相依(Transitive Dependency) 。
正規化(7) 補充教材 以下圖為例，關聯表R中有A、B、C、D與E五個屬性，其中A與B為主索引鍵，且{A，B} C、BD、BE、DE。在下圖中，D部分功能相依於主索引鍵{A，B} ，因為去除A後，BD仍具有功能相依。此外，該關聯表中存在非主索引鍵屬性間的功能相依; 因為BE可由BD與DE得到，故BE在關聯表中是遞移相依。 完全功能相依 C 部份功能相依 A D B E 主索引鍵 遞移相依
正規化(8) 補充教材 第一正規化型式(First Normal Form, 1NF #),主要除去關聯表中任何的重複群，使關聯表中任一行與任一列的交叉格(Cell)上均只有一個值。 第二正規化型式(Second Normal Form, 2NF #)，符合第一正規化型式，再除去資料的部分功能相依。 第三正規化型式(Third Normal Form, 3NF #)，符合第二正規化型式，再除去資料的遞移相依。
正規化(9) 補充教材 正規化的步驟 未經正規化的關聯表 除去重複群 第一正規化型式 除去部分相依 第二正規化型式 除去遞移相依 正規化(9) 補充教材 正規化的步驟 未經正規化的關聯表 除去重複群 第一正規化型式 除去部分相依 第二正規化型式 除去遞移相依 第三正規化型式
正規化(10) 如果資料表設計為1NF，且所有非主索引鍵的欄位皆相依於整個主索引鍵，則稱此資料表設計滿足第二正規化型式(2NF, second normal form)。 如果在1NF資料表中的任何欄位，只相依於組合主索引鍵中的任一個欄位，則該資料表就不是2NF。 如果1NF資料表的主索引鍵只由一個欄位組成，那麼就不會發生部分相依的問題，因為整個主索引鍵是單一欄位。因此，一個具有單一欄位主索引鍵的1NF資料表自動地成為2NF。 「訂單」資料表符合1NF但不符合2NF ︰ 訂單(訂單號碼，訂單日期，產品號碼，產品說明，訂購數量)
正規化(11) 部份功能相依 訂單日期 訂單號碼 訂購數量 完全功能相依 產品號碼 產品說明 部份功能相依 將資料表從1NF轉換成2NF有一個標準程序。其目的是將原來的資料表分割成兩個或更多的新資料表，並重新分派欄位使得每個非索引鍵欄位都會相依於其資料表中的整個主索引鍵。 為完成這個，你必須依照以下各步驟: 1. 為主索引鍵中的每一個欄位建立新的資料表並命名。在圖8-23的例子中，「訂單」資料表的主索引鍵有兩個欄位，所以你可以產生兩個資料表，其結果為:
正規化(12) 訂單(訂單號碼，…) 產品(產品號碼，…) 其中的點線(…)表示欄位稍後才會指 定。 產品(產品號碼，…) 其中的點線(…)表示欄位稍後才會指 定。 2. 為原來主索引鍵各欄位的每種可能組合，建立一個新資料表。 在圖8-23的例子中，你會為主索引鍵的組合「訂單號碼」及「產品號碼」建立一個新的資料表並加以命名。 如下所示: 訂單項目(訂單號碼，產品號碼，…) 3. 將其餘的欄位與適當的主索引鍵放在一起。 如下所示: 訂單(訂單號碼，訂單日期) 產品(產品號碼，產品說明) 訂單項目(訂單號碼，產品號碼，訂購數量)
正規化(13) 圖8-24展示了一個2NF的資料表設計。 為什麼從1NF轉到2NF會是重要的呢? 有四種問題會在1NF的設計中找到，而不會在2NF中發現。 (參閱圖8-23) 考慮當因為工作需要而必須更換某特定產品說明時，假設產品號碼為304的訂單目前有500張，更改產品號碼為304的產品說明即表示要修改500筆紀錄，修改這所有500筆紀錄是相當繁複且浪費金錢。 1NF資料表可能包含不一致的資料，因為必須有人將產品說明輸入每筆紀錄中，我們無法避免產品號碼304在不同紀錄中有不同的產品說明。
正規化(14) 第三正規化型式 上述問題在經過2NF後，則都可解決。 加入新產品是個問題，因為主索引鍵必須包含訂單號碼及產品號碼，你需要兩個欄位的值以新增紀錄，當你要新增一個從未被顧客訂購過的產品時，訂單號碼要用什麼值呢? 刪除一項產品也是問題。如果一項訂單完成並付款後，就刪除所有相關紀錄，那麼如果刪除了唯一一筆含有產品號碼633的紀錄，則關於該產品號碼及其產品說明的資訊都會消失。 上述問題在經過2NF後，則都可解決。 第三正規化型式 一個普通經驗法則是，如果每一個非索引鍵欄位都相依於索引鍵，且是整個索引鍵，而且除了索引鍵之外，不相依於其他東西，則稱此設計滿足第三正規化型式。
正規化(15) 以下顧客資料表設計，如圖8-25所示: 顧客(顧客號碼，顧客姓名，地址，業務代表號碼，業務代表姓名) 此資料表是1NF，因為它沒有重複群組; 此設計也是2NF，因為主索引鍵是單一欄位。 但是此設計仍有與前面1NF中所談及相類似的四個潛在問題。 這個潛在問題之所以發生的原因，是因為此設計不是3NF。 如果資料表為2NF設計，且所有非主索引鍵欄位，皆未功能相依於其他的非主索引鍵欄位，則稱此資料表設計滿足第三正規化型式 (3NF, third normal form) 。所謂非主索引鍵欄位是指不會成為主索引鍵的候選鍵之欄位。
正規化(16) 顧客姓名 顧客地址 顧客號碼 業務代表號碼 非主索引鍵欄位之間的功能相依 業務代表姓名 圖8-25中的「顧客」(CUSTOMER)範例不是3NF，因為有一個非主索引鍵欄位「業務代表姓名」是相依於另一個非主索引鍵欄位「業務代表號碼」(*參考上圖)。 要將此紀錄轉換成3NF，你必須將2NF紀錄中，相依於其他非主索引鍵欄位的所有欄位移除，將它們放在新的資料表中，而以該非主索引鍵欄位作為其主索引鍵。
正規化(17) 如圖8-26所示的是第三正規化型式所產生的兩個分別的資料表: 顧客(顧客號碼，顧客姓名，地址，業務代表號碼) 顧客地址 業務代表號碼 業務代表姓名 如圖8-26所示的是第三正規化型式所產生的兩個分別的資料表: 顧客(顧客號碼，顧客姓名，地址，業務代表號碼) 業務代表(業務代表號碼，業務代表姓名) 正規化的實例 學校指導體制中的幾個實體:「指導老師」(ADVISOR)，「課程」(COURSE)，「學生」(STUDENT) ，這三個實體間的關係如下︰
正規化(18) 在你開始正規化的步驟之前，「學生」資料表如圖8-29所示，其中有重複群組如下︰ 指導 M 指導老師 學生 M 選修 N 課程 在你開始正規化的步驟之前，「學生」資料表如圖8-29所示，其中有重複群組如下︰ 學生(學號，學生姓名，總學分，平均成績，指導老師號碼，指導老師姓名，(課號，課程名稱，學分數，成績)) 要將「學生」資料表轉換成1NF，你必須擴展主索引鍵使得它包含重複群組的鍵，而就產生:
正規化(19) 圖8-30所示的是「學生」範例資料的1NF形式。 學生(學號，學生姓名，總學分，平均成績，指導老師號碼，指導老師姓名，課號，課程名稱，學分數，成績) 圖8-30所示的是「學生」範例資料的1NF形式。 總學分 學生姓名 平均成績 學號 指導老師號碼 成績 指導老師姓名 課程名稱 課號 學分數
正規化(20) 依照先前描述1NF 2NF轉換程序，可以得到以下紀錄設計: 學生(學號，學生姓名，總學分，平均成績，指導老師號碼，指導老師姓名) 課程(課號，課程名稱，學分數) 成績(學號，課號，成績) 現在你已將原本1NF的「學生」資料表擴充為三個資料表，每一個都是2NF。 在每個資料表中，每一個非主索引鍵欄位都相依於整個主索引鍵。(圖8-31) 三個資料表中，「課程」及「成績」資料表是3NF，但是「學生」資料表不是3NF，因為「指導老師姓名」欄位相依於「指導老師號碼」欄位，而它並非「學生」資料表的主索引鍵的一部分。 你必須將「指導老師姓名」欄位從「學生」資料表中移除，將它放在另一個資料表中，並以「指導老師號碼」作為其主索引鍵。 如下︰
正規化(21) 圖8-32所示的是「學生」、「指導老師」 、 「課程」、與「成績」的3NF版本及範例資料。 學生(學號，學生姓名，總學分，平均成績，指導老師號碼) 指導老師(指導老師號碼，指導老師姓名) 課程(課號，課程名稱，學分數) 成績(學號，課號，成績) 圖8-32所示的是「學生」、「指導老師」 、 「課程」、與「成績」的3NF版本及範例資料。 大家都知道有超過3NF的正規化形式存在，只是它們很少使用在商業導向的系統中。
資料庫規劃實戰(摘自旗標SQL Server 2008 設計實務)
由上頁的「訂購單」(忽略「項目編號」此一欄位)可初步畫出其簡略的ERD圖如下: 資料庫規劃實戰 由上頁的「訂購單」(忽略「項目編號」此一欄位)可初步畫出其簡略的ERD圖如下: 客戶 1 填寫 n 訂購 m n 訂單 書籍
資料庫規劃實戰 加上屬性的ERD圖 聯絡人 客戶編號 送貨地址 客戶 填寫 數量 出版公司 訂購 客戶編號 訂單 書籍 訂單編號 書籍編號 1 填寫 數量 出版公司 n 訂購 m 客戶編號 n 訂單 書籍 訂單編號 書籍編號 應付總價 書籍編號 單價 下單日期 訂單編號 書籍名稱
資料庫規劃實戰 客戶資料表 訂單資料表 書籍資料表 訂購明細資料表 由上頁ERD圖, 可以寫下各關聯表綱要(Relational Schema)如下: 客戶(客戶編號, 聯絡人, 送貨地址) 訂單(訂單編號,下單日期,應付總價,客戶編號) 書籍(書籍編號,書籍名稱, 單價, 出版公司) 訂購明細(訂單編號, 書籍編號, 數量) 可將原本的「訂購單」上的資料分別列在以下四個資料表內(其中客戶編號, 訂單編號,書籍編號等資料為另外自行編定, 其餘皆按照原「訂購單」上的資料填入): 客戶資料表 訂單資料表 客戶編號 聯絡人 送貨地址 001 吳明士 台北市忠孝東路九段10號 … 訂單編號 下單日期 應付總價 客戶編號 102601 2008/11/10 162100 001 … 書籍資料表 訂購明細資料表 書籍編號 書籍名稱 單價 出版公司 TK001 Linux實務應用 620 旗旗出版公司 TK002 BIOS玩家實戰 299 TK003 Windows系統秘笈 490 … 訂單編號 書籍編號 數量 102601 TK001 150 TK002 100 TK003 80 …
資料庫規劃實戰 由以下四個資料表, 請問 (a) 訂單編號102601號的訂單其訂購客戶的聯絡人是誰? (b) 「 BIOS玩家實戰」一書被訂購的總金額為多少? … 客戶資料表 訂單資料表 客戶編號 聯絡人 送貨地址 001 吳明士 台北市忠孝東路九段10號 … 訂單編號 下單日期 應付總價 客戶編號 102601 2008/11/10 162100 001 … 書籍資料表 訂購明細資料表 書籍編號 書籍名稱 單價 出版公司 TK001 Linux實務應用 620 旗旗出版公司 TK002 BIOS玩家實戰 299 TK003 Windows系統秘笈 490 … 訂單編號 書籍編號 數量 102601 TK001 150 TK002 100 TK003 80 …
資料庫規劃實戰 下列資料表儲存學生選課資料，每一門課只由同一位老師授課，一間辦公室可能有多位老師共用，請畫出其ERD圖，寫出其對應的關聯表綱要(Relational schema) ，並將分割後的各資料表內容寫下來。 學號 姓名 課程編號 課程名稱 教師編號 教師姓名 辦公室編號 辦公室名稱 成績 S001 張三 CS101 CS203 CS222 CS213 計算機概論 程式設計 資料庫系統 資訊管理 T001 T003 T002 陳明德 林大山 蔡淑珍 K-5-3 K-5-2 網路中心 資料庫中心 85 75 90 80 S002 李四 S003 王五 CS121 離散數學
資料庫規劃實戰 ERD圖 姓 名 學 號 教師姓名 教師編號 辦公室編號 學 生 教 師 學 號 成 績 選修 任教 課程編號 分配於 姓 名 學 號 教師姓名 教師編號 辦公室編號 學 生 n 教 師 1 學 號 成 績 n 選修 任教 課程編號 分配於 m 課 程 關聯表綱要: 學生(學號,姓名) 課程(課程編號,課程名稱,教師編號) 修課成績(學號,課程編號,成績) 教師(教師編號,教師姓名,辦公室編號) 辦公室(辦公室編號,辦公室名稱) n 1 辦公室 課程編號 教師編號 課程名稱 辦公室編號 辦公室名稱
資料庫規劃實戰 學生資料表 修課成績資料表 教師資料表 課程資料表 辦公室資料表 關聯表綱要: 學生(學號,姓名) 課程(課程編號,課程名稱,教師編號) 修課成績(學號,課程編號,成績) 教師(教師編號,教師姓名,辦公室編號) 辦公室(辦公室編號,辦公室名稱) 學生資料表 學號 姓名 S001 張三 S002 李四 S003 王五 修課成績資料表 教師資料表 課程資料表 學號 課程編號 成績 S001 CS101 85 CS203 75 CS222 90 CS213 80 S002 S003 CS121 Cs213 教師編號 教師姓名 辦公室編號 T001 陳明德 K-5-3 T002 蔡淑珍 K-5-2 T003 林大山 課程編號 課程名稱 教師編號 CS101 計算機概論 T001 CS121 離散數學 T002 CS203 程式設計 T003 CS213 資訊管理 CS222 資料庫系統 辦公室資料表 辦公室編號 辦公室名稱 K-5-2 資料庫中心 K-5-3 網路中心
資料庫規劃實戰 功能相依圖 學號 姓名 課程名稱 關聯表綱要: 學生(學號,姓名) 課程編號 課程(課程編號,課程名稱,教師編號) 修課成績(學號,課程編號,成績) 教師(教師編號,教師姓名,辦公室編號) 辦公室(辦公室編號,辦公室名稱) 課程編號 教師編號 學號 成績 課程編號 教師姓名 辦公室編號 辦公室名稱 教師編號 辦公室編號
資料設計過程中的代碼用法(1) 代碼(code)是代表一個資料項目的一組字母或數字。 代碼可用來簡化輸出、輸入，及資料格式。 代碼的概述 代碼常常用來代表資料，例如，學號就是一個學校註冊系統中用來識別學生的獨特代碼。 美國的郵遞區號(ZIP code)它含有壓縮成為九個數字的多項資訊︰ 表示美國東部這個廣大的地理區域 (*註: ;美國分成十個地理區域) 表示這所學院的郵政信箱 2 790 6 2624 表示北卡羅來納州的Elizabeth市 表示在Albemarle學院的郵局
資料設計過程中的代碼用法(2) 因為代碼常常比它代表的資料要短，所以它們能夠節省儲存空間和成本，減少資料傳輸的時間，縮短資料輸入的時間。 在下列情況下，代碼還能減少資料輸入的錯誤︰ (1) 當編碼過的資料比原始資料更容易記憶和輸入時，如: ENG代表ENGLISH，或(2) 當只允許某些有效代碼存在時，如: M代表男生、F代表女生，以及(3) 在代碼本身之內的某種東西能夠提供對輸入正確性檢驗的時候，如: 檢查碼。 代碼的類型 以下描述八個常見的編碼方法:
資料設計過程中的代碼用法(3) 順序代碼(sequence codes)是就以特定順序指定的數字和字母。 順序代碼除了表明輸入系統的順序之外，不包含任何附加的資訊。例如，人力資源系統以連續的員工編號識別員工。 你可以利用這個代碼了解 584號員工是在433號員工之後被雇用的。然而，這個代碼並未表明開始雇用這兩個人的日期。 分段順序代碼(block sequence codes)用一些數字區塊用於不同的分類。 大學課程編號，通常都是用分段順序代碼來指定。 100階層的課程，例如化學110和數學125之類，是一年級新生水準的課程，而200階層的課程則表示二年級水準的課程。 在一個特定段落的內部，編號的順序可能有某些附加的意義，比如英語151為英語152的先修。 字母代碼(alphabetic codes)使用英文字母來區分各個項目。其方式可能是基於其種類、縮寫，或一個容易記憶的值叫做助憶碼。 許多分類碼都符合下列一項或數項的定義:
資料設計過程中的代碼用法(4) 分類代碼(category codes)用來分辨一群相關的項目。 例如，一家百貨商店可能使用兩字元分類代碼，識別出售某一種產品的部門: GN (Garden)表示園藝用品，HW (Hardware)表示五金，而EL (Electronics)表示電子零件。 縮寫代碼(abbreviation codes)採用字母縮寫。例如: 美國各州代碼， NY代表New York, ME代表Maine，而MN代表Minnesota 。 有些縮寫代碼被稱為助憶碼(mnemonic codes #)，因為它們使用易於記憶的特殊字母組合。 你在行李標籤上看到的三個字元機場代碼就是助憶碼: LAX代表洛杉磯國際機場(Los Angeles International Airport)，JFK是紐約甘迺迪國際機場(John F. Kennedy International Airport)。
資料設計過程中的代碼用法(5) 有意義的數字代碼(significant digit codes)採用一系列的數字段落來區別項目。例如，郵遞區號就是有意義的數字代碼。另外一個這類代碼可能是存貨位置代碼: 區域代碼 倉庫代碼 貨箱代碼 11 2 05 3 27 通道代碼 樓層代碼
資料設計過程中的代碼用法(6) 衍生代碼(derivation codes)結合不同項目的屬性或特徵建立代碼。大多數雜誌的訂戶代碼都是衍生代碼: John R. Anderson, 1834 Emberly Drive, Enigma, Georgia 31749 31749 ADE 34 EBE
資料設計過程中的代碼用法(7) 加密代碼(cipher codes)使用關鍵字為數字編碼。 一家零售商店可能用一個十個字母的字，比如CAMPGROUND，作為批發價格的代碼，其中C代表1,A代表2，依此類推。這樣， GRAND這個代碼，就表示零售店為這種貨物支付了$562.90 。 行動代碼(action codes)表示要對其所關聯的項目採取什麼行動。 例如，一個學生紀錄程式可能要求使用者輸入或點選一個行動代碼，例如D (表示你想要顯示一筆紀錄，Display)，A (表示增加一筆紀錄，Append)，及 X (表示要退出這個程式，Exit)。
資料設計過程中的代碼用法(8) 開發代碼的方法 如果設計的代碼包含太多特性，會讓它難以記憶、解讀與驗證。 在開發代碼時，要記住下列建議: 如果設計的代碼包含太多特性，會讓它難以記憶、解讀與驗證。 在開發代碼時，要記住下列建議: 保持代碼精簡。 不要建立比需要的長度更長的代碼。 例如，如果你需要識別250個顧客中的每一個，你就不需要六數位的代碼。 允許擴充。 代碼方案必須允許所指定代碼位數的合理增加。 如果公司目前有八個倉庫，你不應當使用一位數代碼給倉庫編號。 保持代碼穩定。 當面臨一些不得不改變的代碼，難免會在取代舊代碼時，造成一些重大問題。 在一個轉換時期中，新舊兩種代碼都在使用，可能需要一種特別程式來處理這兩種代碼。
資料設計過程中的代碼用法(9) 保持代碼的唯一性。 目的是用於識別的代碼，必須是唯一的才有意義。 如果代碼「HW」能夠表示硬體(hardware)或家庭用具(houseware)，這個代碼就沒有用處了。 採用可排序(sortable)的代碼。 避免代碼混淆。 代碼的格式、長度需一致。 避免在一個代碼中允許字母與數字可以出現在同一個位置，因為容易把數字零(0)與大寫字母O(O)，或數字一(1)與小寫字母L(l)或大寫字母I(I)相混淆。 例如，五個字元的代碼5z081，可能很容易誤讀為5zO81，或52081，甚至完全錯誤地讀成S2OBI 。 使代碼有意義。 代碼必須容易記憶，對使用者有用、方便使用，並且容易編寫與解釋。 例如把SW用做表示西南方銷售區域、或把ENG用做英語系的代碼遠比採用代碼14 、或代碼XQA更有意義。
資料設計過程中的代碼用法(10) 使用單一用途的代碼。 不要用一個單一的代碼去給兩種或更多無關的屬性分類。 例如，如果你用單一代碼識別一個員工的部門以及該員工的保險規劃類型，使用者就將難以分辨某一個保險計畫的全部認購人，或一個部門中的全部工作人員，或這兩者。 保持代碼的一致性。 如果薪資處理系統已經使用兩位數的數字代碼代表各部門，就不要建立一個不同的代碼方案(如: 一個英文字母代碼)用於人事系統。
設計資料庫的步驟(1) 建立初步的ERD。 從觀察DFD及類別圖開始，以辨認出各個系統實體。 另外，考慮DFD的資料儲存，判斷它們是否代表實體。 接著，建立ERD草圖。 仔細分析每一個關係，決定它是為1:1、1:M或是M:N的關係。 圖8-39所示的是在錄影帶出租系統中，「會員」(Member)及「錄影帶」(VIDEO)這兩個實體的初步ERD。 指派各個實體的資料元素。 確認每一個資料詞典中的資料要素都關聯到一個實體。 建立所有資料表的3NF設計，仔細確認所有主索引鍵、次選鍵，及外部索引鍵。 產生包含在正規化過程中所指認出的新實體之最終ERD。 圖8-40所示的是最終ERD及正規化後的設計。
設計資料庫的步驟(2) 檢驗資料詞典的所有內容。 確認資料詞典中所有資料儲存、紀錄、資料元素等記載的項目，都已經完整且正確地被記錄下來。 同時要確認在資料設計過程中所發展或指出的所有代碼，都記錄在資料詞典中。 在建立最終ERD及正規化資料表之後，你可以將它們轉變成一個資料庫。
資料庫模型(1) 目前最廣泛使用的兩種資料庫模式是: 關聯式，及物件導向式。 也有其他模式存在(如: 階層式(Hierarchical)、網路式(Network))，但他們通常是使用在較老舊的大型主機系統。 關聯式資料庫可以在許多平台中執行，包含個人電腦。 而且因為關聯式資料庫具有強大能力及具彈性，所以很適合使用於主從式電腦架構中。 物件導向式資料庫是模組化的、具有成本效益、也是物件導向分析程序的邏輯性延伸。 關聯式資料庫 使用關聯式資料庫中的共同欄位，也就是在超過一個以上的資料表中出現的屬性，來建立資料表之間的關係，而建構一個整體的資料結構。 關聯式模型(relational model #)是在1970年代推出的，三十年後，關聯式設計仍然是主要模型。 以下ERD所示的是一個電腦維修服務公司的關聯式資料庫設計:
資料庫模型(2) 顧客 需要 零件 提出 (維修零件細項) 維修申請 (維修工時細項) 要求 維修工作工資 指定 技師 1 n m m m 顧客名字 零件名稱 顧客地址 顧客姓氏 零件成本 顧客城市 零件號碼 申請號碼 零件號碼 顧客 顧客號碼 零件單價 零件數量 顧客州別 1 n 零件存量 需要 零件 提出 申請號碼 (維修零件細項) 顧客號碼 m m 申請日期 維修申請 m (維修工時細項) m 技師號碼 n 要求 維修工作工資 指定 申請號碼 僱用日期 1 工作時數 維修工作碼 時薪 技師 維修工作碼 技師名字 技師號碼 技師姓氏
資料庫模型(3) 因為資料表是相互連結著，使用者可以查詢滿足某些特殊條件的資料。 為能瞭解關聯式DBMS是如何處理複雜的查詢，請參考圖8-42並思考以下例子。 假設使用者想知道: 在12/15/2007之後來店維修的所有顧客。 (答案: Johns, Albert Belli, Mary ) 技師Marie Johnson所作超過四小時人工之所有維修服務。 (答案: 10798號的維修申請) 賣給Washington州的顧客的所有零件的號碼及其名稱。 (答案: 零件號碼為AB-6784的計量表(METER)共6個)
資料庫模型(4) 物件導向資料庫 十年前，幾乎所有的資訊系統都是以關聯式資料庫來設計與建構。 由於在1990年代後期，物件導向分析的普及，許多分析師開始以物件的方式來描述系統，然而不管分析方法為何，大部分的系統仍是被建構成關聯式資料庫。 今天，許多系統開發人員開始使用物件導向資料庫(OODB, object-oriented database #)設計，並將它視為物件導向分析程序的自然延伸。 許多資訊科技專家相信，物件導向資料庫必將產生巨大衝擊，而且可能取代關聯式設計方式。
資料庫模型(5) 在OODB中的每個物件都有唯一的物件識別碼(object identifier)，這與關聯式資料庫中的主索引鍵意義相近。此識別碼允許物件與其他物件互動，並建立關係，此種關係就像是在傳統ERD中的關係。 如圖8-44所示。
資料儲存及取用(1) 資料儲存及取用的策略工具 資料倉儲 --- 許多公司維護著大量的資料庫，而這些不見得互相連結而形成整體的架構。 為能快速取得各種資訊，許多公司使用套裝軟體，以特殊的組態組織與儲存資料，這些組態就稱為資料倉儲。 資料倉儲(data warehouse #)是整合性的資料集合，可以涵蓋似乎並不相關的資料，不管它們存放在公司內的什麼地方。因為它可以連結各種資訊系統及資料庫，所以資料倉儲能夠提供企業的全貌，並支援管理分析及決策的制訂。 資料倉儲系統允許使用者指定某些維度(dimension)，或特性(characteristics)，藉由對每一種特性選擇一個值，使用者就可以從儲存的資料中得到多維度的資料。 如圖8-45所示。
資料儲存及取用(2) 資料探勘 --- 資料探勘(data mining #)軟體會在資料間尋找有意義的模式及關係。 例如，資料探勘軟體可以幫助消費品公司利用顧客以前的購買狀況來辨認潛在顧客。 電子商務的迅速成長，大家開始注意到資料探勘，並將之視為一種分析網頁造訪者的行為及流量趨勢的工具。 因為在大量資料中能夠偵測出模式及趨勢，資料探勘對於必須對涉及複雜事項的管理決策下決定的管理人是非常有價值的工具。
資料儲存及取用(3) 邏輯與實體儲存 邏輯儲存(logical storage)係指透過使用者觀點所見到的資訊，而不管該資訊實際組織或儲存的方法及地點。 實體儲存(physical storage)純粹是硬體相關的，因為它涉及將二進位的資料從實體媒體，如: 硬碟或CD-ROM等讀出與寫入的程序。 例如，一個文件的一部分可能會被存放在一個硬碟上許多個不同的位置，但在使用者的電腦螢幕上只見到該文件為單一的邏輯實體。 邏輯儲存 --- 一些字元的集合稱為欄位，是關於人、地點、事物，或是事件的個別事實; 欄位也稱為資料元素(data element)或是資料項目(data item)。 當設計欄位時，必須提供足以容納可能最大值的空間，當然也不需要準備一個太大，而根本就不可能會用到的儲存容量。 邏輯紀錄(logical record)包含用以描述某一人、地點、事物，或是事件的欄位值。 應用程式視邏輯紀錄為一組相關欄位的集合，而不管此資料實體上是如何儲存，或是放在那裏。
資料儲存及取用(4) 實體儲存 --- 實體儲存涉及實體紀錄(physical record)或是區塊(block)，是作業系統所存取資料的最小單位，作業系統一次讀或寫一筆實體紀錄。 一個實體紀錄可能包含一個或是多個邏輯紀錄，一個實體紀錄中所包含的邏輯紀錄的個數，依區塊因數(blocking factor)而定。 例如，區塊因數為2意即每筆實體紀錄含有兩個邏輯紀錄。 資料儲存格式 電腦產業使用四種主要的資料儲存格式: EBCDIC、 ASCII、Unicode及Binary(二進位)。
資料儲存及取用(5) EBCDIC是Extended Binary Coded Decimal Interchange Code # 的縮寫，它是使用於大部分大型主機電腦的資料儲存方法。 ASCII是American Standard Code for Information Interchange # 的縮寫，使用於大部分的迷你型電腦及個人電腦。 EBCDIC與ASCII都需要使用一個位元組(byte)來存放每一個字元、數字，或是符號。 統一碼( Unicode )是比較新的編碼方法，它是將字元表示為整數。 Unicode的表示法，每個字元需要16位元(bit)(兩個位元組)，如此，最多可用以表示65,535個不同的字元。 這個特點在軟體設計全球化及大型公司需要使用多國語言電腦作業的狀況下，就顯得非常重要。 今日，大多數的國際軟體產品，如Microsoft Office，都使用並支援Unicode標準。
資料儲存及取用(6) 相較於以字元為主的編碼方式，每個文數字元均需要一個位元組，二進位儲存格式(binary storage format)提供更有效率之數字資料儲存。例如，整數格式(integer format)需要兩個位元組來存放範圍從-32768到32,767的數字; 長整數格式(long integer format)使用四個位元組來存放從-2,147,483,648到2,147,483,647的數字。 選擇一種資料儲存格式 在很多情況下，使用者可以選擇特定的資料儲存格式。你該如何選擇資料儲存格式? 最佳的答案是視情況而訂，Unicode雖然有許多優點，但它也有一些缺點。
資料儲存及取用(7) Microsoft建議只有在你必須處理多語系資料時才用Unicode ，而在選擇數值資料格式時，你應該採用一個對現在及未來所有可能資料均適用的格式。 例如，如果你確定在資料庫欄位中最大的數值將是10，你可以採用能夠以單一位元組的儲存空間就能處理0~255的數字的位元組格式(byte format) 。 日期欄位 在產業界全面地經歷過Y2K之後，目前大部分日期格式都是依照國際標準組織(ISO, International Organization for Standardization)所建立的標準，其中，年的部分有四位數，月的部分兩位數，日的部分也是兩位數，即YYYYMMDD ，以此格式所儲存的資料可以很容易排序並作比較。 絕對日期(absolute date)是指從某特定日期起算的總日數。
資料控制(1) 檔案與資料庫控制必須包含所有足以保證資料儲存正確、完整，及安全的必要方法。 一個設計良好的DBMS必須提供內建控制與安全功能，包含子結構描述、密碼、加密、稽核軌跡檔案，與維護資料所需的備份及回復程序。 子結構描述來讓某特定使用者或是某層級的使用者，只能檢視某部分的資料庫。 對檔案或資料庫的存取作限制設定，是保護儲存資料最常使用的方法。 使用者必須提供正確的使用者ID (user ID)及密碼(password)才可存取檔案或資料庫。可對不同使用者設定不同之存取權限(privilege),也稱為許可(permissions)，某些員工只能讀取資料，而某些員工可以更改或是刪除。
資料控制(2) 所儲存的資料也可以透過加密，以防制未授權存取。 加密(encryption)是一種將可閱讀的資料轉換成無法閱讀的資料之程序，以防制對該資料未授權的存取。 所有系統檔案及資料庫都必須定期做備份，所有的備份(backup)必須要保留一段規定的時間。 當檔案毀損時，回復程序(recovery procedure)就可用來將前一次的備份重灌到檔案或是資料庫，使其回復到備份時的狀態。 稽核紀錄檔(audit log file)記錄所有對檔案或資料庫所進行的存取或更動之詳細過程，它可用以回復前一次做備份之後的所有改變。另外有所謂的稽核欄位(audit field),它是一個特殊欄位，其中所記錄的資料可用以提供更進一步的控制或是安全資訊。 通常稽核欄位包含紀錄產生或更動的日期、執行此動作的使用者姓名，及該紀錄被存取的總次數等等。 -- End of this Chapter --