Institute of Southern Punjab, Multan

Transcription

1 Institute of Southern Punjab, Multan Mr. Muhammad Nouman Farooq BSC-H (Computer Science) MS (Telecomm. and Networks) Honors: Magna Cumm Laude Honors Degree Gold Medalist! Blog Url: noumanfarooqatisp.wordpress.com

2 Database Systems Data Modeling Lecture#4 2

3 Lecture 4: Data Modeling Data Modeling/Database Design Entity Relationship Diagram (ERD) Data Dictionary Relational Schema Diagram 3

4 Data Modeling/Database Design 4

5 Data Modeling Database Modeling follows the analysis phase. Documenting rules and policies of an organization that govern data and implementing them into a design which is an Entity Relationship Diagram (ERD). 1. Business Rule 2. Conceptual Data Modeling 5

6 Database Design/Data Modeling The Data Modeling basically stores the Conceptual Model of the database and the relationships between data that should be stored to meet the user s requirements in the form of an Entity Relationship Diagram (ERD) and must be read as per business rules. Than; Database Design is stored in the Relational Schema Diagram (skeleton structure of the entire transformed ERD), which is in turn stored in the Data Dictionary (Collection of descriptions of the data objects or items in a data model for the benefit of programmers and others who need to refer to them) 6

7 Continued... Top-Down Approach: - Design by Analysis Only Database Administrator s can firstly design the structure of the database (makes an ERD in Conceptual Data Modeling Phase) and than transforms it into Relations in Logical Data Modeling Phase and than afterwards code that structure of transformed ERD in Implementation Phase using a DBMS (MySQL in XAMPP) making a Database System; This approach is termed as Design by Analysis. A good design must reduces duplication of data, reduces anomalies in data, we must makes it in 3 rd Normal Form (3-NF) for commercial applications. In Physical Design phase; It requires a knowledge of the specific DBMS that will be used to implement the database (data types, triggers, indexes etc). Bottom-Up Approach: - Design by Synthesis 7

8 Database Modeling It is a very important process because the designing of the application provides us the basis for running our database system. If the database is not designed properly, the implementation of the system can not be done properly. Generally, the design of the database is represented graphically because it provides an ease in design and adds flexibility for the understanding of the system easily. 8

9 Continued... 9

10 A GOOD Business Rule Is: 10

11 Business Rules 11

12 CLASS EXERCISE (ERD Reading as per Business Rule) 12

13 SOLUTION OF CLASS EXCERCISE 13

14 ERD Reading 1. A STUDENT may be assigned to some POST like Monitor, Perfect, and each POST must be responsible by at most one STUDENT. a) One (Optional) to One (Optional) b) Many (Optional) to One (Mandatory) c) One (Mandatory) to Many (Mandatory) d) Many (Mandatory) to Many (Optional) Correct Answer is:- Many (Optional) to One (Mandatory) Logically Explain why??? 14

15 Continued 2. An EMPLOYEE must be assigned by only one PARKING_PLACE, and a PARKING_PLACE must be assigned to Only one EMPLOYEE a) One (Optional) to One (Optional) b) Many (Mandatory) to One (Mandatory) c) One (Mandatory) to One (Mandatory) d) Many (Mandatory) to Many (Optional) Correct Answer is:- One (Mandatory) to One (Mandatory) Logically Explain why??? 15

16 Continued 3. An EMPLOYEE of an ISP Organization must contain at least two number of CAR s, and each pair of CAR must be assigned to only one EMPLOYEE a) One (Mandatory) to One (Optional) b) One (Mandatory) to Many (Mandatory) c) One (Mandatory) to One (Optional) d) Many (Optional) to One (Mandatory) Correct Answer is:- One (Mandatory) to Many (Mandatory) Logically Explain why??? 16

17 Continued 4. A STUDENT may register for at least one COURSE, and each COURSE may have many STUDENTS a) One (Optional) to One (Optional) b) Many (Optional) to One (Mandatory) c) One (Optional) to One (Mandatory) d) Many (Optional) to Many (Optional) Correct Answer is:- Many (Optional) to Many (Optional) Logically Explain why??? 17

18 Entity Relationship Diagram (ERD) 18

19 Standard used for Database System Designing Standards are used for describing the design process on some predefined rules. If there is no standard available for designing a specific systems; Then everyone will have to use its own design notation, and a notation used by one designer may not be understandable to the another one. This misunderstanding can be more drastic if both the designers are working for the development of the same system. Tools/Simulator can also help the designer and the user to mutually agree on a specific design. 19

20 Continued Peter Chen developed ERDs in 1976 and introduces standard to design database ERD Model. We will be using Information Engineering Style and Crow s Foot Notation through out this semester. 20

21 E-R Model Constructs 21

22 Components of ER Diagram The ER data model supports following major constructs: 1. The Entity 2. Attribute 3. Relationship 22

23 The Entity Entity is basic building block of the ER data model. The term entity is used in three different meanings or for three different terms and that are: 1. Entity Type 2. Entity Instance 3. Entity Set 23

24 Entity Type Anything that receives or generates data from or to the system is an entity. Entity Type is transformed into a Table in any DBMS engine. They are typically singular nouns, e.g. customer, supervisor, location or promotion. Entity type is name assigned to a collection of properties of different things existing in an environment. 24

25 Continued Generally, the entity types and their properties are established by nature, by very existence of the things. For example, a bulb is an electric accessory, a cricket bat is a sports item, a computer is an electronic device, a shirt is a clothing item etc. 25

26 Classification Of Entity Types Entity types (ETs) can be classified into regular ETs or weak ETs. Regular ETs are also called strong or independent ETs, whereas weak ETs are also called dependent ETs. 26

27 Weak Entity Types It depend on some other entity type and have no meaning in the diagram without depending on another entity. Example: Course (Course cannot be taught without teacher) An entity type whose instances cannot exist without being linked with instances of some other entity type, i.e., they cannot exist independently. For example, in an organization we want to maintain data about the vehicles owned by the employees. Now, a particular vehicle can exist in this organization only if the owner already exists there as employee. 27

28 Continued Similarly, if employee leaves the job and the organization decides to delete the record of the employee then the record of the vehicle will also be deleted. Since, Entity cannot exist without being linked to an instance of employee. This type of entity is called as weak entity or dependent entity. 28

29 Strong Entity Types An entity type whose instances can exist independently, that is, without being linked to the instances of any other entity type is called strong or regular entity type. A major property of the strong entity types is that they have their own identification, which is not always the case with weak entity types. For example, employee in the previous example is an independent or strong entity type, since its instances can exist independently. 29

30 Entity Instance Each entity instance possesses certain values against the properties with the entity type to which it belongs. For example, In the given table on next slide; we have identified that entity type EMPLOYEE has name, father name, registration number, qualification, designation. Now, an instance of this entity type will have values against each of these properties, like (M. Sajjad, Abdul Rehman, EN-14289, BCS, and Programmer) may be one instance of entity type EMPLOYEE. There could be many others. Entity Instance is termed as Rows/Tuples or Records in any DBMS engine. 30

31 Continued The entity instance can be defined as a name/label assigned to items/objects that exist in an environment and that have similar properties. 31

32 Continued 32

33 Entity Set A group of entity instances of a particular entity type is called an entity set. For example, all employees of an organization form an entity set. Like all students, all courses, all of them form entity set of different entity types. 33

34 Naming Entity Types Following are some recommendations for naming entity types. Good Designs usually follow these practices: 1. Singular Noun Recommended 2. Organization specific names, like CUSTOMER, CLIENT 3. Write in Capitals 4. Abbreviations can be used, be consistent. Avoid using confusing abbreviations. 34

35 Symbols for Entity Types A rectangle is used to represent an entity type in ER data model. For strong entity types rectangle with a single line is used whereas double lined rectangle is drawn to represent a weak entity type as is shown below: 35

36 Attribute Attributes are characteristics of an entity in a relationship. Attributes are termed as a Columns/Fields in any DBMS engine. An attribute of an entity is a defining property of that entity type. Entity instances of entity type STUDENT have attributes like stdregno, stdname etc. 36

37 Continued However, values of these attributes may be same or different. For example, all instances of the entity type STUDENT may have the attributes stdname, stdfathername, stdage; but the values against each of these attributes for each instance must be different in most of the cases. An attribute is identified by a name allocated to it and that has to be unique with respect to that entity type. It means one entity type cannot have two attributes with the same name. However, different entity types may have attributes with the same name. 37

38 Continued Standard of writing Attributes is: 1. The notation that has been adopted in this course as a Standard is that attribute name generally consists of two parts. The name is started in lower case, and usually consists of abbreviation of the entity types to which the attribute belongs. 2. Second part of the attribute name describes the purpose of attribute and only first letter is capital. For example employeename means name attribute of entity type EMPLOYEE, stdaddress means address attribute of the entity type STUDENT. 38

39 Domain of an Attribute As every Attribute has got a name. Next thing is that a domain is also associated with an attribute. These two things, name and the domain, are important part of an attribute. Domain is a form of a check on attribute that it cannot have a value outside of this set. Domain is known as Data Type in Physical Design (DS) 39

40 Continued Associating domain with an attribute helps in maintaining the integrity of the database, Since only legal values could be assigned to an attribute. Legal values mean the values that an attribute can have in an environment or system. For example, if we define a salary attribute of EMPLOYEE entity type to hold the salary of employees, the value assigned to this attribute should be numeric, it should not be assigned a value like date 10/10/2004, because they are not legal salary values. But, It must be numeric. 40

41 Continued Not only specify that the value of salary will be numeric but also associated with a range, a lower and upper limit. It reduces the chances of mistake. Domain is normally defined in form of data type and some additional constraints like the range constraint. Data type is defined as a set of values along with the operations that can be performed on those values. Some common data types are Integer, Float, AutoNumber, Date/Time, Currency etc. 41

42 Continued Another important thing is that once we associate a domain to an attribute, all the attributes in all entity instances of that entity type will have the values from the same domain. For example, it is not possible that in one entity instance the attribute salary has a value and in another instance the same attribute has a value All attribute will have values from same domain, values may be different or same, whatever, but the domain will be the same. 42

43 Types of Attributes Attributes may be of different types. They may be: 1. Simple or Composite 2. Single Valued or Multi-Valued 3. Stored or Derived 4. Key or Non-Key 5. Required or Optional 43

44 Simple or Composite An attribute that is a single whole is a simple attribute. The value of a simple attribute is considered as a whole, not as comprising of other attributes or components. For example, attributes stid of an entity type STUDENT are example of simple attribute. On the other hand if an attribute consists of collection of other simple attributes then it is called a composite attributes. For example, stadres attribute may comprise of houseno, streetno, areacode, city etc. In this case stadres will be a composite attribute. 44

45 Single Valued or Multi-Valued Attributes Some attribute have single value at a time, whereas some others may have multiple values. For example, hobby attribute of STUDENT or skills attribute of EMPLOYEE, since a student may have multiple hobbies, likewise an employee may have multiple skills so they are multi-valued attributes. On the other hand, name, father name, designation are generally single valued attributes. 45

46 Stored or Derived Attributes Normally attributes are stored attributes, that is, their values are stored and accessed from the database. However, sometimes attributes values are not stored, rather they are computed or derived based on some other value. For example, we may store the name, father name, address of employees, but age can be computed from date of birth. The advantage of declaring age as derived attribute is that whenever we will access the age, we will get the accurate, current age of employee since it will be computed right at the time when it is being accessed. 46

47 Class Activity (Classify the following Attributes) 1. empfirstname 2. emplastname 3. empidno 4. emphobbies 5. emppassword 47

48 Solution of Class Activity (Classification of Attributes) 1. empfirstname Simple, Required, Stored, Non Key, Single Valued 2. emplastname Simple, Optional, Stored, Non Key, Single Valued 3. empidno Key, Simple, Required, Stored, Single Valued 4. emphobbies Simple, Optional, Stored, Non Key, Multi Valued 5. emppassword Simple, Required, Stored, Non Key, Single Valued 48

49 Symbols for Attributes (Standard of Designing Attributes) 49

50 50

51 Relationships Relationships, which represent the link between different entities. Each relationship has a Name. Each relationship has a Cardinality (Optional or Mandatory) Each relationship has a Degree (how many entity types which are participating in a relationship for example Unary, Binary and ternary) Each relationship has a type (One-to-One, One-to-Many and Many-to- Many). 51

52 Symbol for Relationships 1. Shown as a Diamond. 2. Diamond is doubled if one of the participant is dependent on the other. 3. Participants are connected by continuous lines, labeled to indicate cardinality. 4. In partial relationships role, It is written on the line connecting the partially participating entity rectangle to the relationship diamond. 5. Total participation is indicated by double lines. 52

53 Relationship Representation 1 53

54 Crow s Foot ERD-Relationship Representation 2 54

55 Naming Relationships Entities enrolled in a relationship are called its Participants. If there is no proper name of the association in the system then participant s names abbreviations are used. STUDENT and CLASS have enrolled relationship. However, it can also be named as STD_CLS. 55

56 Continued STUDENT and CLASS have enrolled relationship. However, it can also be named as STD_CLS. Or 56

57 Relationships Instances 57

58 Types of Relationships One-to-One When only one instance of an entity is associated with the relationship, it is marked as '1:1'. Any Example?? EMPLOYEE to PARKING_PLACE?? E.g. an EMPLOYEE must be assigned to one and only one PARKING_PLACE, and each PARKING_PLACE must be assigned to only one EMPLOYEE 58

59 Continued One-to-Many- When more than one instance of an entity is associated with a relationship, it is marked as '1:N'. Any Example?? TEACHER to STUDENT Relationship?? E.g. TEACHER must teaches at least five number of STUDENT. STUDENT must be taught by at most one TEACHER 59

60 Continued Many-to-One- When more than one instance of entity is associated with the relationship, it is marked as 'N:1'. Any Example?? STUDENT to TEACHER Relationship? E.g. STUDENT must be taught by at most one TEACHER. TEACHER must teaches at least five number of STUDENT. 60

61 Continued Many-to-Many- The following image reflects that more than one instance of an entity on the left and more than one instance of an entity on the right can be associated with the relationship. Any Example??? STUDENT to COURSE Relationship?? E.g. STUDENT may completes one or more than one COURSE, and each COURSE may be completed by many number of STUDENT 61

62 Continued 62

63 Degree of a Relationship 63

64 Continued 64

65 Continued 65

66 Continued 66

67 n-ary Relationships 67

68 Cardinality of Relationship 68

69 Relationship Cardinalities Cardinality is the number of instance of an entity from one relation that can be associated with the other relation. Symbols for Maximum and Minimum cardinalities are given on next slide. 69

70 Continued 70

71 Continued 71

72 Continued 72

73 Type of Relationship and Cardinality in a Relationship 73

74 ERD reading (Crow s Foot Notation) 74

75 How to Create an ERD 1. Identify entities 2. Identify relationships 3. Describe the relationship (Degree, Cardinality and Type of Relationship) 4. Add Attributes 5. Complete the diagram 75

76 Entities VS Relationships 76

77 Scenarios 77

78 Data Dictionary 78

79 Data Dictionary A data dictionary is a collection of descriptions of the data objects or items in a data model for the benefit of programmers and others who need to refer to them. 79

80 80

81 Continued 81

82 Continued 82

83 83

84 Relational Schema Diagram 84

85 Relational Schema Diagram A relational schema diagram is the skeleton structure that represents the conceptual view (transformed ERD) of the entire database. It defines how the data is organized and how the relations among them are associated. It expresses about the constraints/checks that are to be applied on the data. 85

86 Continued 86

87 ERD Reading 87

88 Continued 88

89 Continued 89

90 Exercise Draw the ERD (Information Engineering Standard) for the following scenarios: i. CITY to COUNTRY (real time scenario) Cardinality and Degree of Relationship. ii. Player plays for a at most one Cricket team, In a Cricket team at least eleven players must play. iii. Each patient has one or more patient histories; each instance of patient history belongs to one patient only. iv. An employee may be recorded as having many jobs; a particular job may be recorded as having been held by many employees. v. A person must be a citizen of at most one Country. A country must have one or more than one person as citizens. 90

91 Exercise (Solution) Solution of Scenario 5: - A person must be a citizen of at most one Country. A country must have one or more than one person as its citizens. Entities:- There are two number of Entities (COUNTRY and PERSON) which are participating in this given scenario Degree of Relationship:- There are two Entities participating in this relationship so it is in Binary Relationship Cardinality of Relationship:- Both Entities are in Mandatory (COUNTRY) to (PERSON) Mandatory cardinalities Type of Relationship:- Type of relationship is One (COUNTRY) to Many (PERSON) 91

92 92

93 1) Is the scenario on last slide is in Relational Database or in Flat File System? It is in Relational Database because two tables relates with each other with Primary Key and Foreign Key. Primary Key (countryid in COUNTRY table) Foreign Key (countryid in PERSON table) Because, Scenario is in One (COUNTRY) to Many (PERSON) type of relationship. 93

94 2) Is the designed scenario on last slide is 100% correctly designed to achieve the core objective of Relational Database System? Yes, It is 100% correctly designed because there is no repetition of Countries Instances (records) in COUNTRY table; When related to PERSON table as many citizens in one country must exists. There are many citizens of Pakistan so we don t need to repeat Pakistan as many times the record of PERSON is stored. We can refer it from COUNTRY table via Primary Key to Foreign Key in PERSON table. 94

95 3) If In Relational Database; Than, How it is minimizing Duplication of Data? Duplication of Instances is removed because there is no repetition of Countries Instances in COUNTRY table. Country instance must be called via Foreign Key in PERSON table and there are many number of instances of persons in PERSON table as citizens of Pakistan, these instances can be related to a single instance of Country Pakistan in COUNTRY table. 95

96 4) Is it minimizing Update and Delete Anomaly/Irregularity? Yes, We have removed Update and Delete Anomaly. When Country instance is updated or deleted in COUNTRY table than it will automatically show updated or deleted record against countryid in PERSON table where ever It is referred by Foreign Key. So, we don t have to update or delete millions of records in PERSON table against countries. 96

97 1) Is the above designed scenario is in Relational Database or in Flat File System? It is in Relational Database because two tables relates with each other with Primary Key and Foreign Key. Primary Key (personcnic in PERSON table) Foreign Key (personcnic in COUNTRY table) Because, Scenario is in One (PERSON) to Many (COUNTRY) type of relationship.

98 2) Is the designed scenario on last slide is 100% correctly designed to achieve the core objective of Relational Database System? No, It is not designed correctly because there is repetition of Countries Instances (records) in COUNTRY table; When related to PERSON table as many citizens in one country must exists. There are many citizens of Pakistan so we have to repeat Pakistan as many times the record of PERSON is stored because we have Foreign Key personcnic in COUNTRY table and Primary Key personcnic in PERSON table. 98

99 Case Study-1 In a school, Each STUDENT must be allocated to exactly one CLASS and a CLASS must be formed by at least twenty or more than twenty number of STUDENTs. There are Many Mandatory posts for STUDENT s exists in every CLASS and there are Many Mandatory STUDENT s assigned to different posts like Class Representative (CR), Girls Representative (GR), Boys Representative (BR) in every CLASS. 99

100 Entities Step 1: Identifying Entities: - STUDENT CLASS 100

101 Step 2: Writing Scenario with Type and Cardinality of Relationship as per Business Rules: - 101

102 Reasoning for Type of Relationships: - 102

103 Step 3: ERD Designing in Information Engineering Style: - 103

104 Entities Step 4: Transforming ERD into Relations (If Required): - Transformed/Mapped Entities into Relations: - STUDENT CLASS POST (Associative/Junction Entity) 104

105 Reasoning behind finding Type of Relationships with a Junction Table: - 105

106 POST Entity/Table is known as Associative or Junction Entity/Table because it relates two number of Table s as shown in previous diagram. Associative/Junction Entity/Table can store some information that is linked to both tables as per relationship existence as in previous diagram classpost detail is stored in POST entity like who is CR, BR or GR of which class and these details cannot be stored in STUDENT and in CLASS Entity/Table. Only STUDENT details are stored in STUDENT table and CLASS details are stored in CLASS table. All the instances/records in Associative Entity/Table must be unique. Primary key of Associative Entity/Table can be a Cumbersome Key (Group of Primary Keys) in Associative/Junction Entity/Table that uniquely identifies a record in a relation/table. In previous diagram, classname, stdregno and posttitle can make a Cumbersome key in associative table/entity. 106

107 Step 5: Transforming ERD into Relations: -

108 Case Study-2 Odeon Cinema and other international cinemas have decided to install a centralized database. This database should keep information regarding cinemas including its name, address and phone number. Each cinema must have one or more theaters and each theater has a specific showing time. During these showing times a particular movie is shown to the general public 108

109 Entities CINEMA THEATER SHOW MOVIE 109

110 Relationships A CINEMA must contain one or more THEATERs. A THEATER must belong to only and only one CINEMA. A THEATER has one or more SHOW times. A particular SHOW time for a movie must belongs to only and only one THEATER. A MOVIE may have many SHOW times and a particular SHOW time must belongs to one MOVIE only. 110

111 111 ERD Simulators/Tools ERD Online Simulator: Desktop Simulators for ERD: - Smart Draw RISE Editor Rational Rose

112 Projects Recommendation Prediction Database System (A system which can dynamically predict and changes record where required) Any Database Management System (Any System which must manage real time instance of data) Important Note: 1. All Projects must dynamically changes record; Based on Parent Table s record. 112

113 Recommended Readings Chapter 3 from: Modern Database Management-8 th Edition by Jeffrey A. Hoffer, Mary B. Prescott & Fred R. McFadden (Page No ) Chapter 11 from: Database Systems-A Practical Approach to Design, Implementation and Management by Thomas Connolly and Carolyn BEGG, 4 th Edition (Page No ) Chapter 4 from: Database Systems - Design, Implementation, and Management by Carlos, Steven and Peter, 9 th Edition (Page No ) 113

114 Summary of Lecture Lecture 4 Data Modeling/Database Design Entity Relationship Diagram (ERD) Data Dictionary Relational Schema Diagram 114

115 END OF LECTURE 4 115