1. 1 Chapter 3 The Relational Data Model

2. 2 Contents u3.1 Basics of the Relational Model u3.2 From E/R diagrams to Relational Designs u3.4 Functional Dependencies u3.6 Design of Relational Database Schemas uReading Guide uExercise

3. 3 The things you should know… uThe basic principle of relational database is proposed by E.F.Codd in 1970. uThe first RDBMS production is System R uThe most popular RDBMS DB2, Oracle, Ingres, Sybase, Informix,…

4. 4 3.1 Basic of the Relational Model uThe relational model gives us a single way to represent data: as a two- dimensional table called a relation.

5. 5 uAttributes ( 属性 ) wAttributes of a relation serve us as names for the columns of the relation. wUsually, the attributes describes the meaning of entries in the column below.

6. 6 uSchemas （模式） wThe name of a relation and the set of attributes for a relation is called the schema for that relation. wWe show the schema for the relation with the relation name followed by a parenthesized list of its attributes.

7. 7 uTuples （元组）  The rows of a relation, other than the header row containing the attributes, are called tuple. For example: wRelations, however, are sets of tuples, and it is impossible for a tuple to appear more than once in a given relation.

8. 8 uDomains （域） wThe relational model requires that each component of each tuple be atomic; that is, it must be of some elementary type such as integers or string. wEach attributes of a relation has particular elementary type, thus domain is decided.

9. 9 uEquivalent Representations of a Relation wThe attributes of the relation can be reordered without change the relation.

10. 10 uRelation Instance （关系实例） wA relation about movies is not static; rather, relations change over time. wIt is not common for the schema of a relation to change. wWe shall call a set of tuples for a given relation an instance of that relation.

11. 11 An Example of Relation Instance Relation: Person (Name, Address, Telephone) Relation Instance: NameAddressTelephone Bob123 Main St555-1234 Bob128 Main St555-1235 Pat123 Main St555-1235 Harry456 Main St555-2221 Sally456 Main St555-2221 Sally456 Main St555-2223 Pat12 State St555-1235

12. 12 More … uRelation (Instance) = a set of tuples uDatabase = collection of relations uRelation schema = relation name + attributes wExample: Movies (title, year, length, fileType) uDatabase schema = a set of all relation schemas wMovies(Title, Year, Length, FileType) wStar(Name, Age) wStudio(StudioName, Addr)

13. 13 Name Addr Tel N1 A1 T1 N2 A2 T2 N3 A3 T3 N4 T4 N5 T5 T6 T7 Name Addr Tel N1 A1 T1 N1 A1 T2 N1 A1 T3. N1 A1 T7 N1 A2 T1 N1 A3 T1 N2 A1 T1 Tuple Domai n Component Attribute

14. 14 Integrity Constrain of Relations uEntity Constrain wThe attributes belong to key can not be set as NULL. uReference Constrain wForeign Key: an non-key attribute A in R is a key in S, then the A is called a foreign key of R. wThe value of foreign key can only be NULL or same as what is in S. uUser-define Constrain wUsers define the constrains themselves.

15. 15 补充：关系的完整性 u 实体完整性 u 参照完整性 u 用户定义完整性 实体完整性和参照完整性是关系模型必须满足 的，被称作关系的不变性，由关系数据库系统自 动支持 ★

16. 16 实体完整性 u 规则：若属性 A 是基本关系 R 的主属性，则属性 A 不能取空值 u 说明：基本关系的主码中的任何属性都不能取空 值，而不仅是主码整体不能取空值 u 依据：现实世界的实体是唯一可分的 例：学生（学号，姓名，性别，专业号，年龄） 课程（课程号，课程名，学分） 选修（学号，课程号，成绩）

17. 17 例１：学生实体与专业实体间的关系： 学生（学号，姓名，性别，专业号，年龄） 专业（专业号，专业名） 关系参照图 外码 参照关系 被参照关系 例２：学生，课程，学生与课程之间的多对多联系： 学生（学号，姓名，性别，专业号，年龄） 课程（课程号，课程名，学分） 选修（学号，课程号，成绩） 关系参照图 被参照关 系 参照关系 学生关系 专业关系 专业号 学生关系 选修关系 课程关系 学号课程号 参照完整性 主码？外码？

18. 18 参照完整性 u 定义：外码 但不是 R 的码 w 设 F 是参照关系 R 的一个或一组属性，但不是 R 的码， 若 F 与被参照关系 S 的主码相对应，则称 F 是 R 的外码 （ 详细定义见教材 P54 ） u 规则：参照关系 R 中每个元组在外码 F 上的值必须 为： 或者取空值（ F 的每个属性值均为空值） 或者等于 S 中某个元组的主码值 例３：学生（学号，姓名，性别，专业号，年龄，班长） 参照关系 被参照关系 外码

19. 19 用户定义完整性 u 用户定义的、具体应用中的数据必须满足的约束 条件 w 成绩： 0 － 100 之间 w 身份证、身份证和生日对应关系

20. 20 3.2 From E/R Diagrams to Relation uFrom Entity Sets to Relation wSimplest approach (not always best): convert each E.S. to a relation. wCreate a relation of the same name and with the same set of attributes.

21. 21 Movies (title, year, length, filmType) Stars (name, address) Studios (name, address) Example

22. 22 uFrom E/R Relationships to Relation wRelationships in the E/R model are also represented by relations. The relation for a given relationship R has the following attributes; 1.For each entity set involved in relationship R, we take its key attributes as part of the schema of the relation for R. 2.If the relationship has attributes, then these are also attributes of relation R.

23. 23 Example: Owns (title, year, studioname) Stars-in (title, year, starName)

24. 24 E-R 图向关系模型的转换原则  一个实体转换为一个关系模式，实体的属性就 是关系的属性，实体的码就是关系的码  对实体间的联系  一个 1:1 联系可以转换为一个独立的关系模式，也可 以与任意对应的关系模式合并  一个 1:n 联系可以转换为一个独立的关系模式，也可 以与 n 端对应的关系模式合并  一个 m:n 联系转换为一个关系模式  三个或三个以上实体间的一个多元联系可以转换为 一个关系模式  具有相同码的关系模式可以合并 补充：

25. 25 如公司部门管理系统的 E-R 图及其转换成的关系模式 部门项目 职工 电话 包括 承担 n 1 n1 办公室号，面积项目号，预算费 参与 m n 办公室 包含 1n 包括 n 1 部门号，预算费， 领导人职工号 电话号码，说明 职工号，姓名，办公电话 分担任务  部门 ( 部门号，部门预算费，领导人职工号 )  职工 ( 职工号，姓名，办公电话，部门号 )  办公室 ( 办公室号，面积，部门号 )  项目 ( 项目号，项目预算费，部门号 )  电话 ( 电话号码，说明，办公室号 )  项目承担情况 ( 职工号，项目号，分担任务 )

26. 26 Exercise uRequired: Convert the E-R diagram you designed in last exercise into a relational database schema.

27. 27 3.5 Functional Dependencies uDefinition of Functional Dependency( 函数依赖 ) wX -> A is an assertion about a relation R that whenever two tuples of R agree on all the attributes of X, then they must also agree on the attribute A. wSay “X -> A holds in R.” wConvention X, Y, Z represent sets of attributes; A, B, C,… represent single attributes.

28. 28 Example Movies (title, year, length, filmType, studioName, starname) We can assert the three dependencies: 1.title, year -> length 2.title, year -> filmType 3.title, year -> studioName

29. 29 uFD’s With Multiple Attributes wNo need for FD’s with multiple attribute on right. But sometimes for convenient we can combine them. Example: title, year -> length title, year -> filmType title, year-> starName become title, year -> length, filmType, starName wMultiple attribute on left may be essential. Example: title, year -> length

30. 30 uTrivial Dependencies wA functional dependency A 1 A 2 …A n ->B is said to be trivial( 平凡 ) if B is one of the A’s, otherwise is said to be nontrivial( 非平凡 ). wExample: Suppose Functional Dependencies title, year -> title is a trivial dependency.

31. 31 uTransitive( 传递 ) Functional Dependencies wSuppose we have a relation R with three attributes A, B, and C, wthe FDs A->B and B->C both hold for R. Then it is easy to see that the FD A->c also holds for R, w So C is said to depend on A transitively, via B

32. 32 uKeys of Relations from FD’s view wWe say a set of one or more attributes {A1, A2, …, An} is a key for relation if: 1.Those attributes functionally determine all other attributes of the relation. That is, it is impossible for two distinct tuples of R to agree on all of A1, A2, …, An. 2.No proper subset of {A1, A2, …, An} functionally determines all other attributes of R; i.e., a key must be minimal

33. 33 uExample wAttributes {title, year, starName} form a key for the Movie relation of Fig.above. wSometimes a relation has more than one key. If so, it is common to design one of the keys as the primary key.

34. 34 uSuperKeys wSuperkey satisfies the first condition of a key; wHowever, a superkey need not satisfy the second condition; wExample Attribute set {title, year, starName} form a key for the Movie. Any superset of this attribute set, such as {title, year, starName, length} is a superkey.

35. 35 uRules for discovering Keys of Relation wFirst rule: If the relation comes from an entity set then the key for the relation is the key attributes of this entity set. wSecond rule: If a relation R is comes from a relationship, then the multiplicity of the relationship affects the key for R. There are three cases: If the relationship is many-many, then the keys of both connected entity sets are the key attributes for R. If the relationship is many-one from entity set E 1 to entity set E 2, then the key attributes of E 1 are key attributes of R, but those of E 2 are not. If the relationship is one-one, then the key attributes for either of the connected entity sets are key attributes of R. Thus, there is not a unique key for R.

36. 36 wExample Owns: It is a many-one relation between Movies to Studios, Thus, the key for the relation Owns is the key attributes title and year, which come from the key for Movies. Owns (title, year, studioName) Star-in: It is a many-many relationship between Movies and Stars. So all attributes of the resulting relation are key attributes Stars-in (title, year, starName)

37. 37 3.7 Design of Relational Database Schema u Anomalies( 异常 ) wProblem occur when we try to cram too much into a single relation are called anomalies. Redundancy: Information may be repeated unnecessarily in several tuples. Insertion Anomalies: Tuple insertion may be failed due to lack some other information in the current database. Deletion Anomalies: If a set of values becomes empty, we may lose other information as a side effect. Update Anomalies: We may change information in one tuple but leave the same information unchanged in another.

38. 38 wExample: wGoal of relational schema design is to avoid anomalies and redundancy.

39. 39 uNormal Form wA relation schema is said to be in particular normal form if it satisfies a certain prescribed set of conditions. 1NF, 2NF, 3NF, BCNF uNormalization Procedure wThe successive reduction of a given collection of relation schema to some more desirable form.

40. 40 u1NF wA relation R is in 1NF if and only if, every tuple contains exactly one value for each attributes. Relations in Relational database always in 1NF. But, a relation schema only in 1NF is also always undesirable for a number of relations.

41. 41 u2NF wA relation R is in 2NF if and only if: it is in 1NF and every non-key attributes is full functional dependency on the primary key. wFull Functional Dependency In relation R, if X->Y, and any subset of X, X’-\>Y, say Y full functional dependency to X, that X- F >Y. Otherwise X- P >Y, Y is partly function dependency to X. wExample: If in relation R(A, B, C), existing functional dependencies (A, B)->C, A-\>C, B-\>C, so (A, B) - F >C and R is in 2NF

42. 42 u3NF wA relation R is in 3NF if: it is in 2NF and there is no transitive functional dependency existed. wExample: If in relation R(A, B, C), existing functional dependencies A->B and B->C, then R is not 3NF.

43. 43 uBCNF wWe say a relation R is in BCNF if: whenever X ->A is a nontrivial FD and X is a superkey. Nontrivial means A is not a member of set X. Superkey is any superset of a key (not necessarily a proper superset).

44. 44 uExample 1 wMovies (title, year, length, filmType, studioName, starName) FD: title, year -> length, filmType, studioName The only key is {title, year, starName} In each FD, the left side is not a superkey. These FD’s shows Movies is not in BCNF.

45. 45 uExample 2 wMovies (title, year, length, filmType, studioName) FD’s: title, year -> length, filmType, studioName The only key is {title, year}. In each FD, the left side is a superkey. These FD’s shows Movies is in BCNF

46. 46 uDecomposition( 分解 ) into BCNF wThe decomposition strategy is to look for a nontrivial dependency A 1, A 2, …, A n -> B 1, B 2, …, B m that violates BCNF; i.e., {A 1, A 2, …, A n } is not a superkey, was a heuristic, we shall generally add to the right side as many attributes as are functionally determined by {A 1, A 2, …, A n }.

47. 47 Example1 The key is (title, year, satrName), but the following FD exist: {title, year -> length, filmType, studioName} Thus, the relation is a BCNF violation. We shall decompose the relation into following two: R1 {title, year, length, filmType, studioName} R2 {title, year, starName}

48. 48 uExample2 wWe suppose a relation S-L-C (Sno, Sdept, Sloc, Cno, G) Only key of this relation is (Sno, Cno) FD’s: (Sno, Cno)- F >G, Sno->Sdept, (Sno, Cno)- p >Sdept Sno->Sloc, (Sno, Cno)- p >Sloc, Sdept->Sloc Relation S-L-C is only in 1NF. Please decompose it into BCNF.

49. 49 uStep1: Decompose it into 2NF wSC (Sno, Cno, G) wS-L (Sno, Sdept, Sloc) uStep2: Decompose it into 3NF Now, SC is in 3NF, but S-L only in 2NF. So we need to Decompose S-L into 3NF wSC (Sno, Cno, G) wS-D (Sno, Sdept) wD-L (Sdept, Sloc)

50. 50 uStep3: Decompose it into BCNF wNow, all of relations SC, S-D, D-L are in BCNF. uThe final result is wSC (Sno, Cno, G) wS-D (Sno, Sdept) wD-L (Sdept, Sloc)

51. 51 Reading Guide uA First Course in Database Systems: wRequired: 3.1,3.2, wRecommended: 3.4,3.6 u 数据库系统概论 w 推荐：第五章，第六章