1. Lesson 4: The Relational Model

2. Lesson Overview Database Design Entities Relationships E-R Diagrams

3. Database Design LOGICAL DESIGN PHYSICAL DESIGN REQUIREMENTS ANALYSIS Data Structure Design Data Structure Refinement E-R Diagrams Data Models

4. Database Design The first step in database design is the requirement analysis where database designers interview prospective users to understand and document their data requirements.

5. Database Design Once the requirements have been analysed, the designer creates a conceptual schema for the database to make a graphic representation of the organisations’ data requirements independent of the DBMS and the hardware.

6. Database Design Steps in Database Design involve: 1.Users’requirements analysis 2.Creation of the conceptual schema by the database designers in the logical design. 2a.Design the Data Structure 2b.Refine the Data Structure The conceptual schema is a graphic representation of the organisations’ data requirements independent of the DBMS and the hardware.

7. Database Design In the first phase of the logical design, i.e. the data structure design, the conceptual schema of the database is developed. This is DBMS-independent. One way of representing the logical design is by using the Entity-Relationship (E- R) Diagram

8. Database Design In Data Structure refinement the DBMS- independent logical design is transformed into a data model compatible with the chosen DBMS. An Entity is a real world object which exist and is distinguishable from other objects. An entity is represented by a set of attributes which are properties that described the entity’s characteristics.

9. Database Design The identifier of an entity instance is one or more attributes. This identifier may be unique or not unique. A unique identifier identifies one and only one, entity instance. The unique identifier is known as a superkey. The superkey can be one attribute or a combination of attributes.

10. Entities An Entity is a real world object which exist and is distinguishable from other objects. We wish to record the data about these objects. An entity may be concrete such as a person, a book, a course etc.

11. Entity An entity may also be abstract or a concept such as a holiday, registration, a flight reservation etc. An entity set or an entity class is a set of all entities of the same type. It is the general form or description.

12. Entities The set of all students registered for a particular course for instance can be defined as the entity set STUDENT. The entity set CUSTOMER might represent the set of all persons having an account at a bank.

13. Entities Entity sets are not disjoint. For e.g.. we may define the entity set of all the customers of the bank, CUSTOMER, and the entity set of all employees of the bank, EMPLOYEE. A Person entity may be an EMPLOYEE entity, a CUSTOMER entity, both or neither.

14. Entities an entity instance is the representation of a particular entity, e.g. customer with the name Lim is an instance of the entity CUSTOMER.

15. Attributes An entity is represented by a set of attributes. Attributes are properties which described the entity’s characteristics. For the entity employee, possible attributes are EMPLOYEENO, EMPLOYEENAME, DATEOFHIRE.

16. Attributes Attributes can be single or multiple valued, simple or composite, stored or derived. For each attribute there is a set of permitted values, called the domain of that attribute.

17. Attributes The domain of the attribute CustomerName may be the set of all text strings of length 50.

18. Simple (atomic) Composite Single-valued Multi-valued Attribute types

19. Simple Attributes (Atomic) A simple attribute is an attribute that cannot be further divided into its components. E.g.. ?

20. Composite Attribute An attribute that can be further subdivided is a composite attribute. E.g.?

21. Single-Valued Attribute A single valued attribute can only have one value. E.g.An employee can have only one date of birth, one First Name, one Social security number An employee can have more than one degree, so EMP_Degree is a multivalued attribute Tip: Good database designs ensure that only signle valued attributes are stored in the database.

22. Identifiers Entity instances have names that identify them. CUSTOMER has CustomerName or CustomerNO STUDENt has Name or StudentNo COURSE has CourseName or CourseNo

23. Identifiers The identifier of an entity instance is one or more attributes. The identifier may be unique or not unique. If it is unique, then, it identifies one and only one, entity instance. If it is not unique, the value will identify more than one instance.

24. Identifiers n CustomerName is not a unique identifier because it can produce a set of instances. n Two or more customers may have the same name. n If CustomerName is to be used then additional data, such as Address, TelephoneNo or DateOfBirth is required to find a unique instance.

25. Relationships A relationship is an association between entities. A relationship set is a set of relationships of the same type. Relationship sets are associations between entity sets.

26. Relationships Relationship instances are association between entity instances. A relationship can have attributes.

27. Relationships STUDENT Course COURSE Register

28. Relationships Register is a relationship between STUDENT and COURSE A possible attribute for Register is Date. Relationships have degrees and cardinalities. The number of entities in the relationship is the degree of the relationship.

29. Relationship Degrees : Binary (Degree 2) LECTURER STUDENT Teach

30. Relationship Degrees: Ternary (Degree 3) CHILD MOTHER FATHER Parent

31. Relationship Degrees In a binary relationship (degree 2) each relationship set involves two entity sets. In a ternary relationship each relationship set involves three entity sets.

32. Binary Relationships :Relationship Types There are three types of binary relationships: one-to-one, one-to-many, many-to-one and many-to-many. These are the cardinalities of the relationships.

33. One-to-one Relationship (1:1) a1 a2 a3 b1 b2 b3 AB

34. One-to-one Relationship (1:1) In a one-to-one relationship an entity in A is associated with one and only one entity in B. A relationship between a wife and a husband is a1:1 relationship. WIFE HUSBAND Marriage has 1 1

35. One-to-many Relationship (1:M) a1 a2 a3 b1 b2 b3 A B b4 b5

36. One-to-many Relationship (1:M) An entity in A is associated with any number of entities in B. The relationship between Faculty and Students is a 1:M relationship FACULTY STUDENT Enrols 1 M

37. Many-to-one Relationship (M:1) a1 a2 a3 b1 b2 b3 A B a4 a5

38. Enrollment Is-Enrolled Many-to-one Relationship (M:1) An entity A is associated with at most one entity in B. An entity in B, however, can be associated with any number of entities in A. The relationship between Student and Faculty is M:1 STUDENT FACULTY M1

39. Many-to-many Relationship (M:M) a1 a2 a3 b1 b2 b3 AB

40. Many-to-many Relationship (M:M) An entity in A is associated with many entities in B, and an entity in B is associated with many entities in A. LECTURER STUDENT 1:M Teach MM

41. Many-to-many Relationship (M:M) The relationship between Lecturer and Student is M:M In the relational model, M:M relationships are broken into sets of 1:M relationships LECTURER STUDENT LECT-STUD 1 M 1 M

42. Composite Entity –Designed to transform an M:N relationship into two 1:M relationships –Key comprises at least the primary keys of the entities that it connects

43. Weak Entity Sets An entity set that does not have a primary key is referred to as a weak entity set. The existance of a weak entity set depends on the existence of a strong entity set; it must relate to the strong set via a on-to-many relationship set. A weak entity cannot exist without the related entity’s presence. E.g. Dependent is a weak entity EMPLOYEE DEPENDENTS Has

44. Weak Entity The primary key of a weak entity set is formed by the primary key of the strong entity set on which the weak entity set’s existence depends on.

45. Optional Relationship The relationship between Employee and Dependent is an optional one. An employee can have 0 or more dependents. Thus there will be cases of particular employee without dependents.

46. Mandatory Relationships The relationship between an EMPLOYEE and DEPARTMENT A Department must be occupied by an employee An employee must be the occupant of a department. 2 nd e.g.: An EMPLOYEE must have one EMPLOYMENT_CONTRACT and each EMPLOYMENT _CONTRACT must have one EMPLOYEE associated with it.

47. Subtype/Supertype Relationship The relationship between EMPLOYEE and LECTURER is a 1:1 relationship. It is also a subtype/supertype relationship because the LECTURER entity contains attributes that are unique to LECTURERS while the EMPLOYEE entity contains the entity’s common attribute.

48. Recursive Relationship Happens when an entity is related to itself. COURSE prerequisite

49. Entity-Relationship(E-R) Diagram The overall logical structure of a database is expressed graphically by an Entity- Relationship (E-R) diagram. The diagram consists of Rectangles which represent entity sets. Ellipses which represent attributes.

50. Entity-Relationship(E-R) Diagram Diamonds which represent relationship sets. Lines which link attributes to entity sets and entity sets to relationship sets.

51. Symbols Entity Relationship Composite Entity Optionality CUSTOMER generates INV_LINE DEPENDENT (Weak entity)

52. An ERD Segment CUSTOMERgenerates INVOICE 1 M (0,N) (1,1) cardinalities connectivities Business rules: 1. One customer may generate many invoices 2. Each invoice is generated by one customer 3. Some customers have never generated an invoice (The customer list apparently includes potential customers. Therefore, INVOICE is optional to CUSTOMER.)

53. An expanded ERD segment CUSTOMERgeneratesINVOICE INV_LINE PRODUCT 1 M (0,N) (1,1) (O,N)(1,1) 1 M

54. 1:M Relationships CUSTOMERgeneratesINVOICE 1 M (0,N) (1,1) EMPLOYEE has DEPENDENT 1 M (0,N)(1,1)

55. A supertype/subtype relationship EMPLOYEEis a PILOT 1 1 (0,1) (1,1) The supertype contains all common attributes such as names, addresses, etc. The subtype contains all specialized attributes, such as pilot license, flight check dates, etc.

56. EMPLOYEEDEGREE EMP_DEGREE 1M (0,N)(1,1) M1 Implementing multi-valued attributes (1,N) Business rules: Some employees do not have degrees. (Employees are not required to have a degree.) Therefore, some employees do not occur in the EMP_DEGREE (composite) entity. A degree is entered only if at least one employee has earned that degree. But a degree can be earned by many employees.

57. (1,1) EMPLOYEE 1 (0,N) (1,1) M M MM (1,N) CUSTOMER 1 1 (1,N) (0,N) (1,1) contractscoordinates leads PROJECT PROJ_EMP 1 M 1 An ERD for a consulting company

58. 1 M M1 CUSTOMERINVOICELINE (0,N)(1,1) (1,N) PRODUCT generates M 1 (1,1) (0,N) An Invoicing ERD: Composite Entity LINE Relational Schema

59. 1 M M1 CUSTOMERINVOICELINE (0,N)(1,1) (1,N) PRODUCT generates appears in contains M 1 (1,1) (0,N) An Invoicing ERD: Composite Entity LINE Decomposed Through Named Relationships Relational Schema

60. 1 1 M1 EMPLOYEEMECHANICMAINT_LOG (0,1)(1,1) (1,N) MAINT_LINE is a contains writes M 1 (1,N) (1,1) 1 M CUSTOMERCAR (0,N)(1,1) owns needs 1 M (1,1) (0,N) 1 PART (0,N) is in (0,1) M A Car Maintenance ERD

61. 1 M M 1 TEAM GAME PLAYER (1,N) (1,1) uses (1,1) M (1,N) 1 M CITY (1,N) (1,1) sponsors 1 A recursive M:N relationship. Implemented through the composite entity GAME. (TEAM plays TEAM in a GAME.) Relational Schema

62. E-R Diagram for a BANK Database BANKBRANCH ACCOUNT CUSTOMER LOAN Name Code Add Addr BrNo LoanNo Type Amt AcctNo Balance Type CustNo PhoneNameAdd ACCTS A-C LOANS BRANCHES

63. Summary Steps in Database Design involve: 1.Users’requirements analysis 2.Creation of the conceptual schema by the database designers in the logical design. 2a.Design the Data Structure 2b.Refine the Data Structure The conceptual schema is a graphic representation of the organisations’ data requirements independent of the DBMS and the hardware.

64. Summary In the first phase of the logical design, i.e. the data structure design, the conceptual schema of the database is developed. This is DBMS-independent. One way of representing the logical design is by using the Entity-Relationship (E- R) Diagram.

65. Summary In Data Structure refinement the DBMS- independent logical design is transformed into a data model compatible with the chosen DBMS. An Entity is a real world object which exist and is distinguishable from other objects.

66. Summary An entity is represented by a set of attributes which are properties that described the entity’s characteristics. The identifier of an entity instance is one or more attributes.

67. Summary This identifier may be unique or not unique. A unique identifier identifies one and only one, entity instance.

68. Summary The unique identifier is known as a superkey. The superkey can be one attribute or a combination of attributes.

69. Summary {CustomerName, Address} is a superkey. Candidate keys are superkeys such that the subset of that key is not a superkey. {CustomerName, Address} is a candidate key. {CustomerNo, Address} is a superkey but not a candidate key.

70. Summary The candidate key chosen by the database designer as the identifier is called a primary key.

71. Summary A relationship is an association between entities. A binary relationship (degree 2) each relationship set involves two entity sets. binary relationships can be one-to-one, one-to-many, many-to-one and many-to- many.

72. Summary (E-R) diagram consists of Rectangles which represent entity sets. Ellipses which represent attributes. Diamonds which represent relationship sets. E-R diagrams are used to represent the logical structure of a database.

73. Next Lecture Lesson 5: Normalization I

74. Q & A H_khanpour@yahoo.com