1. ER/EER to Relational Data Model 1 Database Design

2. 2 Steps in building a database for an application: Real-world domain Conceptual model DBMS data model Create Schema (DDL) Load data (DML)

3. Relational Model 3 It uses the concept of mathematical relation In the relational model, all data is logically structured within relations (tables).

4. Relational Data Structure 4 4170010 4182000 4182034 4188134 4189860 4192134 StudentNo Al-Saleh Al-Ghanem Al-Fahad Saod Rashed Al-Fahad LName Amal Nora Laila Amal Rana Rania FNameInitial M. A. F. I. M. DOB 04-06-78 02-12-79 01-11-74 22-04-73 30-01-78 19-03-79 GPA 3.91 4.20 4.01 3.01 2.31 3.50 STUDENT Attributes Tuples Cadinality Relation Degree Relation’s name

5. Relational Data Structure 5 Relation is a table with columns & rows. Holds information about entities. Attribute is a named column of a relation. Domain is the set of allowable values for one or more attributes. Every attribute in a relation is defined on a domain. Tuple is a row of a relation.

6. Relational Data Structure 6 Degree of a relation is the number of attributes it contains. Cardinality of a relation is the number of tuples it contains. Relational database is a collection of normalized relations with distinct relation names.

7. Tuples 7 A tuple is a set of ( ) pairs. These tuples are identical: T1 = T2= The ordering of the tuples is not part of the relation.

8. Domain 8 Domain : set of atomic values Domain Constraints : values of each attributes must be an atomic (not divisable into components ) value from the domain. Associated to a data type. Dom(colors): {black,red, white},

9. Domains 9 4170010 4182000 4182034 StudentNo Al-Saleh Al-Ghanem Al-Fahad LName Amal Nora Laila FNameInitial M. A. DOB 04-06-78 02-12-79 01-11-74 GPA 3.91 4.20 4.01 STUDENT StudentNo LName FName Initial Student Name Last Name First Name Initial DefinitionAttribute DOB GPA Domain Name Date of Birth Great Point Average Digits: size 7 Character: size 15 Character: size 3 Date: range 01-01-20, format dd-mm-yy Real: size 3, decimal 2, range 0-5

10. Relational Keys 10 Candidate key (CK) It’s a minimal set of attributes necessary to identify a row. Its also called minimal super key. A relation schema may have more than one key, each of the keys is called a candidate key. Primary Key (PK) is the CK that is selected to identify tuples uniquely within the relation Foreign Key (FK) is an attribute, or set of attributes, within one relation that matches the CK of some relation. Used to represent relationship between tuples of two relations.

11. Relational Keys 11 4170010 4182000 4182034 4188134 4189860 StudentNo Al-Saleh Al-Ghanem Al-Fahad Saod Rashed LName Amal Nora Laila Amal Rana FNameInitial M. A. F. I. DOB 04-06-78 02-12-79 01-11-74 22-04-73 30-01-78 GPA 3.91 4.20 4.01 3.01 2.31 STUDENT D001 D002 D003 DeptNo Computer Science Business Administration Science Department Name Build # 20 Dept D001 D002 D003 D001 Location Build # 45 Build # 6 DEPARTMENT Primary Key Foreign Key

12. Basic Definitions 12 Relational Keys: PK : underlined with a straight line Composite keys FK: underlined with a dashed line Properties of tables: Each table has a unique name Each entry stores a single value Each row is unique Each column has a unique name There is no sequence of rows.

13. DB Relations 13 Relation schema is a named relation defined by a set of attributes If A 1, A 2,.., A n are a set of attributes, then relation schema R is: R = (A 1, A 2,.., A n ) Relational database schema is a set of relation schemas, each with a distinct name If R 1, R 2,.., R n are a set of relation schemas, then relational schema R is: R= {R 1, R 2,.., R n }

14. Relation Schema 14 STUDENT (StudentNo, Lname, Fname, Initial, DOB, GPA, Dept) 4170010 4182000 4182034 4188134 4189860 StudentNo Al-Saleh Al-Ghanem Al-Fahad Saod Rashed LName Amal Nora Laila Amal Rana FNameInitial M. A. F. I. DOB 04-06-78 02-12-79 01-11-74 22-04-73 30-01-78 GPA 3.91 4.20 4.01 3.01 2.31 STUDENT Dept D001 D002 D003 D001

15. Relation Schema 15 DEPARTMENT (DeptNo, Department Name, Location) D001 D002 D003 DeptNo Computer Science Business Administration Science Department Name Build # 20 Location Build # 45 Build # 6 DEPARTMENT

16. Relational Integrity 16 Data integrity refers to the validity, consistency, and accuracy of the data in the database. Integrity rules are constraints that apply to all instances of the DB. Two integrity rules for the relational model: - Entity integrity - Referential integrity

17. Entity Integrity 17 Entity Integrity: (in a single relation) Ensures that there are no duplicate records within the table. In a base relation, no attribute of a PK can be null. T[PK] ≠ Null for any tuple in R.

18. Referential Integrity 18 Referential Integrity: ( two relations) If a FK exists in a relation, either the FK value must match a CK value of some tuple in its home relation or the FK value must be wholly null. The referencing relation R1 has the FK that reference a PK in the referenced relation R2. => t 1 [FK] =t 2 [PK], t 1 in R1 and t 2 in R2

19. Referential Integrity Constraints 19 SSN | Fname | LName | Bdate | DNO Dnumber | Dname | MGRSSN | MgrStartDate EMPLOYEE DEPARTMENT

20. Properties of Relations 20 1. The relation has a distinct name from all other relation names in the relational DB (oracle enforces this rule) 2. Each cell of the relation (attribute) contains exactly single value 3. Each attribute has a distinct name (oracle enforces this rule) 4. The values of an attribute are all of the same domain 5. Each tuple is distinct. There are no duplicate tuples 6. The order of attributes has no significance 7. the order of tuples has no significance; theoretically.

21. Integrity constraints 21 Domain constraints Entity integrity constraints Referential integrity constraints Key Constraint Operational constraints

22. Operations of the Relational Model 22 Updates: changes the database’s state. Insert Delete Update/modify Retrievals: does not change the current state of the database.

23. The Insert Operation 23 This operation can violate all constraints of the relation. How? Domain constraint: attribute value does not apear in the corresponding domain. Key constraint: if the key value already exist in another tuple. Entity integrity: if the PK of the new tuple is NULL Referential integrity: if any value of the FK refers to a tuple that does not exist in the other relation.

24. The Delete Operation 24 This operation can violate only the referential integrity constraint. How? E.g: you can not delete a course that many students study in already.

25. The Update Operation 25 The new value must be of the correct data type and domain.

26. 26

27. Step -1- Strong Entity Type 27 Represent each entity type with a relation Entity type attributes become the relation attributes e.g. STUDENT (StudentNo, Lname, Fname, Initial, DOB, GPA, Dept) DEPARTMENT (DeptNo, Department Name, Location)

28. Step -2- Weak Entity Type 28 A weak entity type relation must include its key and its strong entity type PK as a FK. The combination of the two keys form the PK of the weak entity. EMPLOYEE EmpNo LNameFName DOB DepNo FName DEPENDENT has EMPLOYEE (EmpNo, Lname, Fname, DOB) DEPENDENT (DepNo, EmpNo, FName) FK

29. Step -3- Binary 1:1 Relationship Type 29 Identify an entity type (S) (preferably total participator) Include the PK of the other entity (T) as a FK in S Add attributes that describes the relationship BRANCH manage EMPLOYEE EMPLOYEE(EmpNo, Lname, Fname, DOB) BRANCH(BrnNo, Name, EmpNo, StartDate, EndDate) 1 1 (0,1)(1,1) StartDEndD EmpNo LNameFName DOB Name BrnNo FK ………..

30. Binary 1:1 Important Notes 30 For a 1:1 relationship, the PK of the partial is a FK in the total. What happens if have an equal multiplicity? Then it depends on the path analysis.

31. Step -4- Binary 1:N Relationship Type 31 Identify a participating entity type (S) on the m-side Include the PK of the other entity type (T) as a FK in S Add attributes that describes the relationship BRANCH allocate EMPLOYEE EMPLOYEE(EmpNo, Lname, Fname, DOB, BrnNo) BRANCH(BrnNo, Name) M 1 EmpNo LNameFName DOB Name BrnNo FK ………..

32. Binary 1:N Important Notes 32 For a 1:N relationship, the schema of the N side will have the PK of the 1 side as a foreign key. What if the 1 side has a composite key? All keys will be copied to the many side as foreign keys.

33. Step -5- Binary M:N Relationship Type 33 Create a relation R to represent the relationship Include the PK of participating entity types (T & S) as FK in R. The combination of the two FK will form the PK of R Add attributes that describes the relationship EMPLOYEE(EmpNo, Lname, Fname, DOB) PROJECT(ProjNo, Name) Work-on(EmpNo,ProjNo, hours) M N hours EmpNo LNameFName DOB Name ProjNo FK EMPLOYEE work-on PROJECT

34. Binary M:N Important Notes 34 For a M:N relationship, a new schema is created that contains the PK of N and PK of M plus any other attributes. Some times the situation of insufficient PK occurs … !! How? E.g. a patient gets a treatment several times a resulting table will contain the PK of patient and the PK of the treatment.. But the patient may have the same treatment for several times ….. Therefore a date field must be included as a PK of the relation.

35. Step -6- n-ary Relationship Type 35 Create a relation R to represent the relationship Include the PK of the participating entities as FK in R. The combination of all FK form the PK of R. Add attributes that describes the relationship SUPPLIER contract BUSINESS BUSINESS(BizNo) LAWYER(LawNo) SUPPLIER(SupNo) contract(BizNo, SupNo, LawNo, StartDate, EndDate) StartDEndD BizNo LawNo SupNo FK Lawyer FK

36. Ternary Relationship Important Notes 36 If the Ternary relationship is: N:N:N then a new intersection table is created that includes the 3 entities keys as a PK of that table. 1:N:N then the PK of the 1 is a FK in the intersection table.

37. Recursive Relationship 1:1 37 The schema for this relationship is going to have a new field called MarriedToPersonID, which shares the same domain of the PersonID. PERSON Married to PersonID 1 1 PERSON(PersonID, PersonName,MarriedToPersonID) FK

38. Recursive Relationship 1:N 38 The schema for this relationship is going to have a new field, Its exactly the same is a 1:1 uniary relationship EMPLOYEE supervises EmpID 1 N EMPLOYEE(EmpD, EmpName,DOB, ManagerEmpID) FK

39. Step-7- Multi-valued Attribute 39 Suppose A is a relation that contains the multi-valued attribute Create a relation R to represent the attribute Include the PK of A as FK in R The PK of R is the combination of the PK of A (FK) & the multi-valued attribute EMPLOYEE EmpNo DOB Tel_no EMPLOYEE(EmpNo, DOB) TELEPHONE(EmpNo, tel_no) FK

40. Composite Attribute 40 Include its simple components in the relation EMPLOYEE emp_no nameDOB LName initial FName EMPLOYEE(EmpNo, Fname, initial, Lname, DOB)

41. 41 EER To Relational Data Model

42. EER  Relational Model 42 In EER Model, there are sub-classes and super-classes and to convert them into relational schema we have to use one of the four options which will discuss in next slides: We have to remember these concepts which related to EER. o Total : all entities in super class must be a member of subclass. o Partial :an entity in super class may not belong to any subclass. o Disjoint : an entity be a member only in one subclass. o Over-lapping: an entity may be a member of more than one subclass

43. EER  Relational Model Mandatory(Total)/NonDisjoint(Overlapping) 43 Suppose specialization with subclasses (S1, S2,.., Sm} & a superclass C Create a relation L to represent C with PK & attributes Include the unshared attributes for each subclass Si, 1<= i <= m Add discriminator to distinguish the type of each tuple

44. EER  Relational Model Total/Non-Disjoint (Overlapping) Single Relation R PK(K) Boolean type attribute o

45. EER  Relational Model Total/Non-Disjoint (Overlapping) 45 EMPLOYEE( EmpNo, Fname, Lname, DOB, Salary,TypingSpeed,TGrade, EngType, Secretary Flag, Technician Flag, Engineer Flag)

46. EER  Relational Model Total/Disjoint 46 Suppose specialization with subclasses (S1, S2,.., Sm} & a superclass C Create a relation Li, 1≤ i ≤m, to represent each combination of super/subclass

47. EER  Relational Model Total/Disjoint Relation R2 for subclass TRUCK Relation R1 for subclass CAR PK(K) Tonnage d

48. EER  Relational Model Total/Disjoint d Car( VehicleId,LicensePlateNo, Price, MaxSpeed,NoOfPassengers) Truck ( VehicleId,LicensePlateNo, Price,NoOfAxles,Tonnago)

49. EER Optional/NonDisjoint(Overlapping) 49 Suppose specialization with subclasses (S1, S2,.., Sm} & a superclass C Create a relation L to represent C with PK & attributes Create a relation Li to represent each subclass Si, 1≤ i ≤m

50. Relation R1 EER Optional/NonDisjoint(Overlapping) Relation R Relation R2Relation R3 PK(K) O

51. EER Optional/NonDisjoint(Overlapping) O Employee( SSN,Fname,Minit,Lname,BirthDate,Address,JobType) Secretary( SSN,TypingSpeed) Technician( SSN, Tgrade) Engineer( SSN,EngType)

52. EER Optional/Disjoint 52 Suppose specialization with subclasses (S1, S2,.., Sm} & a superclass C Create a relation L1 to represent C with PK & attributes Create a relation L2 to represent all subclasses Si, 1≤ i ≤ m Add discriminator to distinguish the type of each tuple

53. Relation R1 EER Optional/Disjoint Relation R Relation R2Relation R3 PK(K) d

54. EER Optional/Disjoint 54 EMPLOYEE ( EmpNo, Fname, Lname, DOB, Salary) SECRETARY( EmpNo, TypingSpeed) TECHNICIAN( EmpNo, Tgrade) ENGINEER( EmoNo, EngType)

55. Views 55 Base relation is a named relation corresponding to an entity in the conceptual schema, whose tuples are physically stored in the DB View is a derived relation. Virtual, may not exist, but dynamically derived from one or more base relations. The only information about a view that is stored in the database is its structure. The external model can consist of both conceptual level relations (base relations) and derived views.

56. View 56

57. Purpose of Views 57 Provides security mechanism by hiding parts of the DB from certain users Customize data to user’s needs, so that the same data can be seen by different users in different ways Simplify complex operations. It allow you to work with data from different tables simultaneously. Supports logical data independence

58. Updating Views 58 All updates to a base relation should be immediately reflected in all views that reference that base relation. All updates to a view should be reflected in the underlying base relation, under the following rules: - Updates are allowed through a view defined using a simple query involving a single base relation & containing either the PK or a CK of the base relation - Update are NOT allowed through views involving multiple base relations - Updates are not allowed through views involving aggregation or grouping operations

59. Relational Integrity 59 Data integrity refers to the validity, consistency, and accuracy of the data in the database. Integrity rules are constraints that apply to all instances of the DB. Two integrity rules for the relational model: - Entity integrity - Referential integrity

60. Relational Integrity 60 Entity Integrity: Ensures that there are no duplicate records within the table. In a base relation, no attribute of a PK can be null Referential Integrity: If a FK exists in a relation, either the FK value must match a CK value of some tuple in its home relation or the FK value must be wholly null. Enterprise constraints: rules specified by the users or DBA of the DB based on the ways an organization perceives and uses its data (e.g.number of staff working in a branch is at most 20)

61. References 61 Elmasri,Ramez &Navathe,Shamkant B., Fundamentals Of Database System, fifth edition, Pearson,2007 Fatimah Alakeel’s Lectures http://webdocs.cs.ualberta.ca/~drafiei/291/notes/4.ER2Rel.pdf http://www.cs.sfu.ca/CC/354/zaiane/material/notes/Chapter2/nod e10.html#SECTION00190000000000000000 http://www.cs.sfu.ca/CC/354/zaiane/material/notes/Chapter2/nod e10.html#SECTION00190000000000000000 http://web.uettaxila.edu.pk/CMS/seADMSbsSp09/notes%5CADBMS -Lecture-6%20ER%20to%20Relational%20Mapping.pdf http://web.uettaxila.edu.pk/CMS/seADMSbsSp09/notes%5CADBMS -Lecture-6%20ER%20to%20Relational%20Mapping.pdf www.cs.gsu.edu/~cscbecx/.../Chapter%207.ppt http://www.mscs.mu.edu/~praveen/Teaching/Fa06/Db/Lectures/ch 7.pdf www.cs.uwm.edu/classes/cs557/powerpoint/chapter9.ppt