David M. Kroenke and David J. Auer Database Processing Fundamentals, Design, and Implementation

Transcription

1 David M. Kroenke and David J. Auer Database Processing Fundamentals, Design, and Implementation Chapter Six: Transforming Data Models into Database Designs 6-1

2 Chapter Objectives To understand how to transform data models into database designs 從資料模型到資料庫設計 To be able to identify primary keys and understand when to use a surrogate key 代理索引 To understand the use of referential integrity constraints 參考完整性 To understand the use of referential integrity actions To be able to represent ID dependent, 1:1, 1:N, and N:M relationships as tables To be able to represent weak entities as tables 6-2

3 Chapter Objectives To be able to represent supertypes/subtypes as tables 超類別 / 亞類別 To be able to represent recursive relationships as tables 遞迴關係 To be able to represent ternary relationships as tables 三元關係 To be able to implement referential integrity actions required by minimum cardinalities 6-3

4 Steps for Transforming a Data Model into a Database Design 將資料模型轉換為資料庫設計的步驟 6-4

5 Create a Table for Each Entity 為每個實體建立一個表格 EMPLOYEE (EmployeeNumber, EmployeeName, Phone, , HireDate, ReviewDate, EmpCode) Primary key is designated by the key symbol 主索引加上鑰匙符號 有陰影的是實體 Note shadowless table 沒陰影的是表格 2012 Pearson Prentice Hall 6-5

6 選擇主要索引 Select the Primary Key The ideal primary key is short, numeric, and fixed. Surrogate keys meet the ideal, but have no meaning to users Pearson Prentice Hall 6-6

7 Specify Candidate (Alternate) Keys 選擇替代索引 The terms candidate key and alternate key are synonymous. 候選選引和替代索引在別的書中不見得意義相同 Candidate keys are alternate identifiers of unique rows in a table. Will use AKn.m notation, where n is the number of the alternate key, and m is the column number in that alternate key. 6-7

8 Specify Candidate (Alternate) Keys 選擇替代索引 注意 AKn.m 符號的用法 6-8

9 Specify Column Properties: 選擇欄位性質 : 空值狀態 Null status indicates whether or not the value of the column can be NULL. Null Status 不可以為空值 Primary keys can never be NULL In the ASCII coding system: NUL is 0 Space is 32 0 is Pearson Prentice Hall 6-9

10 Specify Column Properties: 選擇欄位性質 : 資料種類 Generic data types: CHAR(n) VARCHAR(n) DATE TIME MONEY INTEGER DECIMAL Data Type 2012 Pearson Prentice Hall 6-10

11 Specify Column Properties: Data Type + Null Status 選擇欄位性質 : 空值狀態 + 資料種類 期末報告中應有類似的資料庫設計文件 2012 Pearson Prentice Hall 6-11

12 Specify Column Properties: SQL Server 2008 R2 Data Types 不同的資料庫軟體對於資料格式有不同的定義 6-12

13 Specify Column Properties: Oracle Database 11g Data Types 不同的資料庫軟體對於資料格式有不同的定義 6-13

14 Specify Column Properties: MySQL 5.5 Data Types I 不同的資料庫軟體對於資料格式有不同的定義 6-14

15 Specify Column Properties: MySQL 5.5 Data Types II 不同的資料庫軟體對於資料格式有不同的定義 6-15

16 Specify Column Properties: 選擇欄位性質 : 預設值 Default Value A default value is the value supplied by the DBMS when a new row is created. 預設值 2012 Pearson Prentice Hall 6-16

17 Specify Column Properties: 選擇欄位性質 : 資料限制 Data Constraints Data constraints are limitations on data values: Domain constraint column values must be in a given set of specific values. 值域限制 Range constraint column values must be within a given range of values. 範圍限制 Intrarelation constraint column values are limited by comparison to values in other columns in the same table. 表格內限制 Interrelation constraint column values are limited by comparison to values in other columns in other tables (referential integrity constraints on foreign keys). 表格外限制 6-17

18 確認正規化 Verify Normalization The tables should be normalized based on the data model. Verify that all tables are: BCNF 4NF 6-18

19 Create Relationships: 1:1 Strong Entity Relationships 建立關係 :1 對 1 強實體關係 Place the key of one entity in the other entity as a foreign key. 把一個實體的鍵值放在另一個實體中作為外部關鍵索引 Either design will work no parent, no child. Minimum cardinality considerations may be important. O M will require a different design than M O. One design will be very preferable. 6-19

20 Create Relationships: 1:1 Strong Entity Relationships 建立關係 :1 對 1 強實體關係 兩種插入 FK 的方式都可以 6-20

21 Create Relationships: 1:N Strong Entity Relationships 建立關係 :1 對多強實體關係 Place the primary key of the table on the one side of the relationship into the table on the many side of the relationship as the foreign key. 將 1 邊的鍵值放在多邊作為外部關鍵索引 The one side is the parent table and the many side is the child table, so place the key of the parent in the child. 6-21

22 Create Relationships: 1:N Strong Entity Relationships 建立關係 :1 對多強實體關係 6-22

23 Create Relationships: N:M Strong Entity Relationships 建立關係 : 多對多強實體關係 In an N:M strong entity relationship there is no place for the foreign key in either table. A COMPANY may supply many PARTs. A PART may be supplied by many COMPANYs Pearson Prentice Hall 6-23

24 Create Relationships: N:M Strong Entity Relationships 建立關係 :1 對多強實體關係 The solution is to create an intersection table that stores data about the corresponding rows from each entity. 產生第三個表格 : 交叉表 The intersection table consists only of the primary keys of each table which form a composite primary key. Each table s primary key becomes a foreign key linking back to that table. COMPANY_PART_INT (CompanyName, PartNumber) 6-24

25 Create Relationships: N:M Strong Entity Relationships 建立關係 :1 對多強實體關係 COMPANY_PART_INT (CompanyName, PartNumber) 2012 Pearson Prentice Hall 6-25

26 Relationships Using ID-Dependent Entities: Four Uses for ID-Dependent Entities ID 依賴實體的關係 1. Representing N:M Relationships We just discussed this 2. Association Relationships 組合關係 3. Multivalued Attributes 多值屬性 4. Archetype/Instance Relationships 原型 / 實例關係 6-26

27 Relationships Using ID-Dependent Entities: Association Relationships ID 依賴實體的關係 : 組合關係 An intersection table 交叉表 Holds the relationships between two strong entities in an N:M relationship 表示兩個強實體間的多對多關係 Contains only the primary keys of the two entities: As a composite primary key As foreign keys An association table 組合關係比上述的例子多 nonkey attributes Has all the characteristics of an intersection table PLUS it has one or more columns of attributes specific to the associations of the other two entities 6-27

28 Relationships Using ID-Dependent Entities: Association Relationships ID 依賴實體的關係 : 組合關係 QUOTATION (CompanyName, PartNumber, Price) 2012 Pearson Prentice Hall 6-28

29 Relationships Using ID-Dependent Entities: Multivalued Attributes ID 依賴實體的關係 : 多值屬性 As a data model As a database design 6-29

30 Relationships Using ID-Dependent Entities: Archetype/Instance Pattern ID 依賴實體的關係 : 原型 / 實例關係 As a data model As a database design 6-30

31 Relationships Using Weak Entities: Archetype/Instance Pattern ID 依賴實體的關係 : 原型 / 實例關係 As a data model As a database design 改用代理索引 6-31

32 Mixed Entity Relationships 混合實體關係 As a data model As a database design 6-32

33 Mixed Entity Relationships: 混合實體關係 : 訂單 The SALES_ORDER Pattern As a data model 請在 MS Access 中建立此對應的資料庫關聯圖 6-33

34 Mixed Entity Relationships: 混合實體關係 : 訂單 The SALES_ORDER Pattern As a database design 6-34

35 Subtype Relationships 次類別關係 As a data model As a database design 6-35

36 Recursive Relationships: 1:1 Recursive Relationships 遞迴關係 :1 對 1 As a data model As a database design 車廂 6-36

37 Recursive Relationships: 1:N Recursive Relationships 遞迴關係 :1 對多 As a data model As a database design 6-37

38 Recursive Relationships: N:M Recursive Relationships 遞迴關係 : 多對多 As a data model As a database design 6-38

39 Representing Ternary and Higher- 三元以上關係 Order Relationships Ternary and higher order relationships may be constrained by the binary relationship that comprise them. MUST constraint requires that one entity must be combined with another entity in the ternary (or higherorder) relationship. 一定要有 MUST NOT constraint requires that certain combinations of two entities are not allowed to occur in the ternary (or higher order) relationship. 一定不能有 MUST COVER constraint a binary relationship specifies all combinations of two entities that must appear in the ternary (or higher order) relationship. 一定要包括 6-39

40 一定要有的限制 MUST Constraint 顧客由固定的售貨員負責 6-40

41 MUST NOT Constraint 一定不能有的限制 對指定的藥物過敏 6-41

42 MUST COVER Constraint 一定要包括的限制 每一種修理包含一組固定的工作 6-42

43 請在 MS Access 中建立此對應的資料庫關聯圖

44

45 Design for Minimum Cardinality 最低基數的設計 Relationships can have the following types of minimum cardinality: O O: parent optional and child optional M O: parent mandatory and child optional O M: parent optional and child mandatory M M: parent mandatory and child mandatory We will use the term action to mean a minimum cardinality enforcement action. 對應最低基數的行為 No action needs to be taken for O O relationships. 6-45

46 Cascading Updates and Deletes 串連更新和刪除 A cascading update occurs when a change to the parent s primary key is applied to the child s foreign key. Surrogate keys never change and there is no need for cascading updates when using them. A cascading delete occurs when associated child rows are deleted along with the deletion of a parent row. For strong entities, generally do not cascade deletes. For weak entities, generally do cascade deletes. 6-46

47 Actions When the Parent Is Required [Figure 6-28(a)] 當親代實體是必要時的行為 6-47

48 Actions When the Child Is Required [Figure 6-28(b)] 當子代實體是必要時的行為 6-48

49 Application Programming: Triggers 程式設計 : 激發器 Application programming uses SQL embedded in triggers, stored procedures, and other program code to accomplish a specific task. A trigger is a stored program that is executed by the DBMS whenever a specified event occurs on a specified table or view (defined in Chapter Seven). Triggers are used to enforce specific minimum cardinality enforcement actions not otherwise programmed into the DBMS. Triggers will be discussed in detail in Chapters 7, 10 (SQL Server), 10A (Oracle Database), and 10B (MySQL 5.5). 6-49

50 Actions To Apply to Enforce Minimum Cardinality 執行最小基數限制的行為 6-50

51 Implementing Actions for M-O Relationships 實作 M-O 關係的行為 See Figure 6-28(a) Make sure that: Every child has a parent. Operations never create orphans. The DBMS will enforce the action as long as: Referential integrity constraints are properly defined. The foreign key column is NOT NULL. 6-51

52 Implementing Actions for O-M Relationships 實作 O-M 關係的行為 See Figure 6 28(b) The DBMS does not provide much help. 目前各資料庫軟體幫不上太多的忙 Triggersor other application codes will need to be written. 6-52

53 Implementing Actions for M-M Relationships 實作 M-M 關係的行為 The worst of all possible worlds: Especially in strong entity relationships. In relationships between strong and weak entities the problem is often easier when all transactions are initiated from the strong entity side. All actions in both Figure 6 28(a) and Figure 6 28(b) must be applied simultaneously. Complicated and careful application programming will be needed. 建議盡可能避免 6-53

54

55 Implementing Actions for M-O Relationships: DEPARTMENT and EMPLOYEE 實作 M-O 關係的行為 DEPARMENT is parent EMPLOYEE is child. Actions on parent: DEPARTMENT rows can be created. DEPARTMENT primary key cascade updates if not surrogate key. IF a DEPARTMENT is deleted, do we delete the associate EMPLOYEEs? IF YES cascade deletes. IF NO prohibit associate employees. 6-55

56 Implementing Actions for M-O Relationships: DEPARTMENT and EMPLOYEE 實作 M-O 關係的行為 Actions on child Set referential integrity constraint and set foreign key to NOT NULL. A new EMPLOYEE must have a valid DEPARTMENT or disallow the insert. EMPLOYEEs can be reassigned to a different DEPARTMENT if a valid DEPARTMENT or disallow the update. EMPLOYEEs can be deleted. 6-56

57 Implementing Actions for O-M Relationships: DEPARTMENT and EMPLOYEE 實作 O-M 關係的行為 DEPARMENT is parent EMPLOYEE is child. There must be at least one child row for each parent at all time. Actions on parent: DEPARTMENT rows can only be created when a relationship is created to a child row REQUIRES A TRIGGER. DEPARTMENT primary keys can only be updated if at least one EMPLOYEE foreign key is also updated REQUIRES A TRIGGER. Can a DEPARTMENT be deleted? YES it is the EMPLOYEE who is required. 6-57

58 Implementing Actions for O-M Relationships: DEPARTMENT and EMPLOYEE 實作 O-M 關係的行為 Actions on child OK to insert a new EMPLOYEE. There must be one EMPLOYEE for each department. Cannot change EMPLOYEE foreign key (DEPARTMENT) if last EMPLOYEE in the DEPARTMENT. Cannot delete an EMPLOYEE if last EMPLOYEE in the DEPARTMENT. 6-58

59 Implementing Actions for M-M Relationships: DEPARTMENT and EMPLOYEE 實作 M-M 關係的行為 DEPARMENT is parent EMPLOYEE is child. All of the previous (M O and O M) apply at the same time! This creates conflicts that require careful programming to avoid or fix problems such as: A new DEPARTMENT insert will run a trigger that tries to create a new EMPLOYEE, but the EMPLOYEE row is checked by the DBMS for a valid DEPARTMENT before the transaction is completed. If we try to delete a DEPARTMENT with any EMPLOYEEs we will find the trigger on EMPLOYEE delete will not let us delete the last EMPLOYEE, so we can t delete the DEPARMENT. 6-59

60 Documenting the Minimum Cardinality Design: Documenting Required Parents 書面記載最小基數設計 : 記錄所需親代 COMPANY is parent, DEPARTMENT is child. The relationship is M O. This can often be done in the database design tools. 6-60

61 Documenting the Minimum Cardinality Design: Documenting Required Children 書面記載最小基數設計 : 記錄所需子代 Needs written documentation Can use Figure 6 2b(b) as a boilerplate document and fill it out for each specific situation 6-61

62 Documenting the Minimum Cardinality Design: Documenting Required Children 書面記載最小基數設計 : 記錄所需子代 HOUSE is parent, INSPECTION is child. The relationship is O M. Use documentation based on Figure 6 28(b) see the next slide. 6-62

63 Documenting the Minimum Cardinality Design: Documenting Required Children 書面記載最小基數設計 : 記錄所需子代 6-63

64 Summary of Minimum Cardinality Design 最小基數設計總結 6-64

65 View Ridge Gallery 範例資料庫 :View Ridge Gallery View Ridge Gallery is a small art gallery that has been in business for 30 years. It sells contemporary European and North American fine art. 當代歐洲和北美洲的藝術品 View Ridge has one owner, three salespeople, and two workers. View Ridge owns all of the art that it sells; it holds no items on a consignment basis. 全部是藝廊所有, 沒有委託代賣 6-65

66 Application Requirements 應用程式需求 View Ridge application requirements: Track customers and their artist interests Record gallery s purchases Record customers art purchases List the artists and works that have appeared in the gallery Report how fast an artist s works have sold and at what margin Show current inventory in a Webpage 6-66

67 資料模型 View Ridge Data Model 6-67

68 View Ridge Database Design 1 資料庫設計

69 View Ridge Database Design 資料庫設計 Surrogate keys are needed for: CUSTOMER WORK TRANS We can also use a surrogate key for ARTIST. This will change the identifying relationships to nonidentifying relationships. WORK and TRANS become weak, non ID dependent entities. Foreign keys: TRANS.CustomerID is NULL to allow acquisitions without an immediate sale to a CUSTOMER. 只有這個 FK 可以是空值 ( 沒有顧客 ) All other foreign keys are NOT NULL. 6-69

70 View Ridge Database Design 2 資料庫設計

71 Minimum Cardinality Enforcement: 最小基數限制 View Ridge Relationships 6-71

72 Minimum Cardinality Enforcement: View Ridge M-O Relationships 最小基數限制 :M-O 關係 ARTIST-to-WORK 6-72

73 Minimum Cardinality Enforcement: View Ridge M-O Relationships 最小基數限制 :M-O 關係 WORK-to-TRANS 6-73

74 Minimum Cardinality Enforcement: View Ridge M-O Relationships CUSTOMER-to-CUSTOMER_ARTIST_INT 最小基數限制 :M-O 關係 6-74

75 Minimum Cardinality Enforcement: View Ridge M-O Relationships ARTIST-to-CUSTOMER_ARTIST_INT 最小基數限制 :M-O 關係 6-75

76 Minimum Cardinality Enforcement: View Ridge M-M Relationships 最小基數限制 :M-M 關係 6-76

77 View Ridge Table Designs: 表格設計 :Artist ARTIST 6-77

78 View Ridge Table Designs: 表格設計 :Work WORK 6-78

79 View Ridge Table Designs: 表格設計 :Trans TRANS 6-79

80 View Ridge Table Designs: 表格設計 :Customer CUSTOMER 6-80

81 View Ridge Table Designs: CUSTOMER_ARTIST_INT 表格設計 :Customer_Artist_Int 6-81

82 VRG Data CUSTOMER I 7-82

83 VRG Data CUSTOMER II 7-83

84 VRG Data ARTIST 7-84

85 VRG Data CUSTOMER_ARTIST_INT 7-85

86 VRG Data WORK I 7-86

87 VRG Data WORK II 7-87

88 VRG Data TRANS I 7-88

89 VRG Data TRANS II 7-89

90 David Kroenke and David Auer Database Processing Fundamentals, Design, and Implementation (11th Edition) End of Presentation: Chapter Six 6-90

91 All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher. Printed in the United States of America. Copyright 2012 Pearson Education, Inc. Publishing as Prentice Hall 6-91