Presentation is loading. Please wait.

Presentation is loading. Please wait.

ITS232 Introduction To Database Management Systems Siti Nurbaya Ismail Faculty of Computer Science & Mathematics, Universiti Teknologi MARA (UiTM), Kedah.

Similar presentations


Presentation on theme: "ITS232 Introduction To Database Management Systems Siti Nurbaya Ismail Faculty of Computer Science & Mathematics, Universiti Teknologi MARA (UiTM), Kedah."— Presentation transcript:

1 ITS232 Introduction To Database Management Systems Siti Nurbaya Ismail Faculty of Computer Science & Mathematics, Universiti Teknologi MARA (UiTM), Kedah | sitinurbaya@kedah.uitm.edu.my | http://www.sitinur151.wordpress.com | | A2-3039 | ext:2561 | 012-7760562 | CHAPTER 4 Entity Relationship (E-R) Modeling (ERD)

2 4.0 Entity Relationship (E-R) Modeling 4.1 The Entity Relationship (ER) Model 4.2 Developing An E-R Diagram 4.3 Database Design Challenges Chapter 4: Entity Relationship (E-R) Modeling

3 Chapter 4: Entity Relationship (E-R) Modeling Basic Modeling Concept 3 A model is description or analogy used to visualize something that cannot be directly observed.

4 Chapter 4: Entity Relationship (E-R) Modeling Basic Modeling Concept 4 Relatively simple representations of complex real world data structures Represents: – data structures and their characteristics – relation and constraints Can be physical or abstract: – car, student = physical – subject, register= abstract Used by database designer as: – communications tools to communicate and understanding between a client and the database designer, which the database to be develop.

5 Chapter 4: Entity Relationship (E-R) Modeling Basic Modeling Concept 5 The importance of data modeling: Data –constitute the most basic information units employed by a system Application –is created to manage data and to transform data to information View –different people views the same data differently based on their understanding Model –helps different user to have the holistic view of the same data

6 Chapter 4: Entity Relationship (E-R) Modeling Basic Modeling Concept 6 The importance of data modeling: Data Application View 1 View 2 View n Model

7 Chapter 4: Entity Relationship (E-R) Modeling Basic Modeling Concept 7 2. Conceptual level 3. Internal level Physical data organization 1. External level View 1View 2View n Conceptual Schema Internal Schema Database User n User 2 User 1 … Conceptual Model External Model Internal Model Physical Model -designer’s view -h/w independent -s/w independent -DBMS’s view -h/w independent -s/w dependent -h/w dependent -s/w dependent -user’s view ERD Three Level ANSI-SPARC Architecture

8 Chapter 4: Entity Relationship (E-R) Modeling 4.1 The Entity Relationship (E-R) Model 8 Based on the set theory and the relational theory, it is used as tools to: –translate different views of data among managers, users and programmers to fit into a common work –define data processing and constraints to help meet the different views –help implement the database –considered as a stage in a database design preceding the relational database modeling –gives data structures representation of: *what information have to be stored *the relationships between informational elements and constraint on the data structure *relationship

9 Chapter 4: Entity Relationship (E-R) Modeling 4.1 The Entity Relationship (E-R) Model 9 ER model forms the basis of an ER diagram (ERD) ERD represents conceptual database as viewed by end user ERDs depict database’s main components: –Entities –Attributes –Relationships

10 10 Entity Refers to entity set and not to single entity occurrence Corresponds to table and not to row in relational environment In both Chen and Crow’s Foot models, entity is represented by rectangle containing entity’s name Entity name, a noun, is usually written in capital letters Chen ModelCrow’s Foot Model STUDENTSUBJECTSTUDENTSUBJECT

11 11

12 12 Attribute Characteristics of entities Property that explains about entity Correspondents to fields of a table Primary key are underline with a straight line Foreign key are underline with dotted line or an * Chen ModelCrow’s Foot Model attributes are represented by ovals and are connected to entity rectangle with a line each oval contains the name of attribute it represents attributes are written in attribute box below entity rectangle

13 13 Chen ModelCrow’s Foot Model STUDENT studentID name course SUBJECT code credit name STUDENT studentID course name SUBJECT credit name code

14 Chapter 4: Entity Relationship (E-R) Modeling 4.1 The Entity Relationship (E-R) Model 14 Chen ModelCrow’s Foot Model ERD TABLE RATIONAL SCHEMA STUDENT(studentID, name, course) SUBJECT(code, name, credit) STUDENT studentID name course SUBJECT code name credit STUDENT studentID name course SUBJECT credit name code studentIDnamecourse ……………………………………… codenamecredit ………………………………………… STUDENTSUBJECT

15 Chapter 4: Entity Relationship (E-R) Modeling 4.1 The Entity Relationship (E-R) Model: Relationship 15 Relationship Associates between entities Logical interaction among the entities in a relational database Operate in both directions Chen ModelCrow’s Foot Model Weak Relationship Strong Relationship Weak Relationship Strong Relationship works has works has works

16 Chapter 4: Entity Relationship (E-R) Modeling 4.2 Developing An E-R Diagram 16 Development of ER model is an Iterative Process that involved: Step1: General narrative of organizational operations developed Step2: Basic E-R Model graphically depicted and reviewed Step3: Modifications made to incorporate newly discovered ER components Repeat process: Until designers and users agree on complete E-R Diagram

17 Chapter 4: Entity Relationship (E-R) Modeling 4.2 Developing An E-R Diagram: Model Components 17 Chen ModelCrow’s Foot Model ENTITY ATTRIBUTE RELATIONSHIP STUDENT studentID name course STUDENT studentID course name works

18 Chapter 4: Entity Relationship (E-R) Modeling 4.2 Developing An E-R Diagram: Model Components 18 ENTITYVariations of entity: i.Weak ii.Recursive iii.Composite iv.Supertype/Subtype ATTRIBUTETypes of attribute: i.Simple attributes ii.Composite attributes iii.Multivalued attributes iv.Derived attributes RELATIONSHIPRelationship can be describes by: i.Degree of the relationship ii.Connectivity of the relationship iii.Cardinality of the relationship iv.Participation

19 19 Entity Corresponds to table and not to row in relational environment Represented by rectangle containing entity’s name Entity name, a noun, is usually written in capital letters Examlpe: Entity STUDENT with attributes STUDENT studentID name course email address

20 20 Variations of Entity: i.Weak Entity ii.Recursive Entity iii.Composite Entity iv.Entity Supertype and Subtype

21 21 Variations of Entity: i.Weak Entity Existence dependency Primary key derived from parent entity Example: DEPENDENT entity EMPLOYEE(employeeNO, employeeNAME) DEPENDENT(employeeNO, depNO, depDATE, depNAME) EMPLOYEE employeeNO employeeNAME DEPENDENT employeeNO depNAME depDATE depNO has 1 (0,N) 1 (1,N) employeeNOemployeeNAME 111Ali 222Ah Chong 333Bazil employeeNOdepNOdepNAMEdepDATE 1111Zara05/05/05 1112John25/12/09 3333Syamil28/10/09 3331Jazmeen01/01/11

22 22 Variations of Entity: ii.Recursive Entity Entity set that have relationship with the same entity set Example: EMPLOYEE entity employeeNOemployeeNAMEemployeeSPOUSE 111Ali444 222Ah Chong 333Bazil 444Sheriz111 employeeNOemployeeNAMEemployeeMANAGER 111Ali333 222Ah Chong333 Bazil333 444Sheriz EMPLOYEE employeeNO employeeNAME married 11 employeeSPOUSE EMPLOYEE employeeNO employeeNAME manage 11 employeeMANAGER

23 Variations of Entity: iii.Composite Entity Originally a relationship between 2 entities that involved in M:N relationship Composite entity takes its primary key from both entities that it bridges Example: enroll studentIDstudentNAME 200922222 200933333 200944444 200955555 courseIDcourseNAME ITS232Database CSC318IP CSC203OS STUDENT studentID studentNAME enroll M grade COURSE courseID courseNAME N studentIDcourseIDgrade 200922222ITS232A+ 200922222CSC318B+ 200933333CSC203B 200955555ITS232A- STUDENTSTUDENT_COURSE / ENROLL COURSE

24 24 Variations of Entity: iv.Entity Supertype & Subtype Parent-Child relationship Supertype  contains the shared attributes  an entity type that include distinct subclasses that required to be presented in data model  parent Subtype  contains the unique attributes  an entity type that has a distinct role and also a member of supertype  child

25 25 Variations of Entity: iv.Entity Supertype & Subtype Example: Superype ( EMPLOYEE ) Subtype ( Engineer & Full-Time )

26 26 Variations of Entity: iv.Entity Supertype & Subtype Have two types of relationship: DisjointOverlapping Unique subtype Non-overlapping: subtypes can be one of the types Overlapping: Subtypes can be either one or both of the subtypes Indicate with: GGs

27 27 Variations of Entity: iv.Entity Supertype & Subtype Example: Disjoint & Overlap Disjoint Overlap G Gs

28 28 Variations of Entity: iv.Entity Supertype & Subtype Example: Disjoint

29 29 Variations of Entity: iv.Entity Supertype & Subtype Example: Disjoint & Overlap

30 30 Attributes Represented by ovals that are connected to entity with a line Oval contains of attribute (field) it represents PK are underlined with straight line FK are underlined with doted line or * Example: Entity STUDENT with attributes name, course, studentID, address, email STUDENT studentID name course email address

31 31 Attributes types: i.Simple Attributes ii.Composite Attributes iii.Multivalued Attributes iv.Derived Attributes

32 32 Attributes types: i.Simple Attributes An attribute composed of single component with an independent existence Cannot be subdivided into smaller components Example: gender, martial statues STUDENT studentID phoneNO age gender name address addressTOWN addressPOSTCODE addressNO Simple Attributes

33 33 Attributes types: ii.Composite Attributes An attribute composed of multiple components, each with an independent existence Can be further subdivide to yield additional attributes Example: name  first, middle, last address  street, city, state, zip Composite Attributes STUDENT studentID phoneNO age gender name address addressTOWN addressPOSTCODE addressNO

34 34 Attributes types: iii.Multivalued Attributes attribute that holds multiple values for each occurrence of an entity type Should not be implemented multivalued attributes in relational database Can simplifies multivalued attributes by: a.Create several attributes b.Create new entity of the original multivalued attributes components Example: phone number  handset,office,home qualification  diploma,degree,master

35 35 Attributes types: iii.Multivalued Attributes Can simplifies multivalued attributes by: a.Create several attributes b.Create new entity of the original multivalued attributes components gender STUDENT studentID handsetNO age address CONTACT has homephoneNO studentID* STUDENT age gender address handsetNO homephoneNO studentID

36 36 Attributes types: iv.Derived Attributes An attributes that represents a value that is derived from the value of related attribute or set of attributes, not necessarily in the same entity type. Should not implement derived attributes in relational database Example: age, cgpa Derived Attributes STUDENT studentID phoneNO age gender name address

37 Chapter 4: Entity Relationship (E-R) Modeling 4.2 Developing An E-R Diagram: Chen Model: Relationship 37 Relationship Associations between entities Logical interaction among the entities in a relational database Operates in both directions Naming Relationships: Relationship name is a verb phrase Avoid vague names Defining Relationships: Definition explains what action is being taken and why it is important Give examples to clarify the action Optional participation should be explained Explain reasons for any explicit maximum cardinality Explain any restrictions on participation in the relationship Explain extent of the history that is kept in the relationship Explain whether an entity instance involved in a relationship instance can transfer participation to another relationship instance

38 Chapter 4: Entity Relationship (E-R) Modeling 4.2 Developing An E-R Diagram: Chen Model: Relationship 38 Relationship is described by: i.Degree of the relationship ii.Connectivity of the relationship iii.Cardinality of the relationship iv.Participation

39 39 Relationship is described by: i.Degree of the relationship Indicates number of associated entities within the relationship There are three types: a.Unary Relationship b.Binary Relationship c.Ternary Relationship STAFF married LECTURER teach CLAS CANDIDATE teach INTERVIEW MANAGEMENT

40 40 Relationship is described by: ii.Connectivity of the relationship Logical interaction among entities in a relational database There are three types: a.1:1 b.1:M c.M:N STUDENT under PROGRAM UiTMBRANCH have RECTOR STUDENT register COURSE 1 1 1 M N M

41 41 Relationship is described by: iii.Cardinality of the relationship Express the specific number of entity occurrences associated with one occurrence of the related entity Function of organizational policy  business rules

42 42 Relationship is described by: iii.Cardinality of the relationship Example 1: One student can register 1 to 9 courses One course maximum can have 35 student (1,9) (0,35) STUDENT register COURSE N M

43 43 Relationship is described by: iii.Cardinality of the relationship Example 2: One lecturer can teaches maximum 3 courses One course can be thought by 1 lecturer only (0,3) (1,1) LECTURER teach COURSE M 1

44 Relationship is described by: iii.Cardinality of the relationship Relationship Strength  Existence Dependence Entity’s existence depends on the existence of one or more other entities name staffNO STUDENT name studentID staffNO* refer supervise SUPERVISOR staffNO name ______ ____ STUDENT studentID name staffNO ________ ____ ______ refer SUPERVISOR

45 Relationship is described by: iii.Cardinality of the relationship From Existence Dependence, exist two relationship strength: a.Weak Relationship  Entity not existence-independent on other entity  PK of related entity doesn’t contain PK component of parent entity  Non-Identifying Relationship b.Strong Relationship  Existence dependence  PK of related entity contains PK component of parent entity  Identifying Relationship 45

46 Relationship is described by: iv.Participation Determines whether all or some entity occurrences participates in a relationship There are two types: a.Optional (Partial)  Condition in which other participating entity may or may not be associated with occurrences of the optional entity in the relationship b.Mandatory (Total)  Condition in which one participating entity must be associated with one or more occurrences of the other participating entity in the relationship 46

47 Relationship is described by: iv.Participation Example 1: One lecturer can teaches maximum 3 courses One course can be thought by 1 lecturer only (0,3) (1,1) LECTURER teach COURSE M 1 connectivity cardinality One class can be thought by one lecturer only One lecturer can teaches maximum 3 classes participation ‘not all lecturer teach class’ optional participation for course ‘all class are teach’ (mandatory participation for lecturer)

48 Chapter 4: Entity Relationship (E-R) Modeling 4.2 Developing An E-R Diagram: Comparison of E-R Model 48 Alternate style developed to enable easier use of CASE tools. Chen Model The Chen notation favors conceptual modeling Crow’s Foot Model Crow’s Foot notation favors a more implementation-oriented approach UML Model UML notation can be used for both conceptual and implementation modeling

49 Comparison of E-R Modeling Symbols Cardinality & ParticipationChen ModelCrow’s Foot Model Entity Weak Entity Composite Entity Relationship line Relationship Option Symbol One (1) Symbol Many (M) Symbol 1 Chapter 4: Entity Relationship (E-R) Modeling 4.2 Developing An E-R Diagram: Comparison of E-R Model M

50 Summary of Cardinality and Participation for a Strong Relationship Cardinality & ParticipationChen ModelCrow’s Foot Model 1:1, both side mandatory 1:M, both side mandatory M:N, both side mandatory 1:1, both side optional 1:M, both side optional M:N, both side optional 1:M, one side mandatory and many side optional has 11 (1,1) has 1M (1,n) (1,1) has MN (1,n) has 11 (0,1) has 1M (0,n) (0,1) has MN (1,n) (0,n) has 1M (0,1) (1,1) has Chapter 4: Entity Relationship (E-R) Modeling 4.2 Developing An E-R Diagram: Comparison of E-R Model

51 Chen Model Chapter 4: Entity Relationship (E-R) Modeling 4.2 Developing An E-R Diagram: Comparison of E-R Model

52 Crow’s Foot Model Chapter 4: Entity Relationship (E-R) Modeling 4.2 Developing An E-R Diagram: Comparison of E-R Model

53 Chapter 4: Entity Relationship (E-R) Modeling 4.3 Database Design Challenges Conflicting Goals Database designers often must make design compromises that are trigged by conflicting goals, such as comply with the design standards, processing speed and information requirements. In order to do so, – it is very important to have the entities, attributes, and relationships clearly identified and well-defined – there is a need in balancing between the customer needs and a design that meets logical requirements and conventions – The more thinking and modeling is done the less money and time are needed later on for rework Additional concerns are security, performance, shared access and integrity 53

54 Chapter 4: Entity Relationship (E-R) Modeling Exercise 1 54 An employee manages one store; each store is managed by one employee

55 Chapter 4: Entity Relationship (E-R) Modeling Exercise 2 55 A painter can paint many paintings; each painting is painted by one painter. A gallery can have many paintings. A painting can be exhibited by a gallery.

56 Chapter 4: Entity Relationship (E-R) Modeling Exercise 3 (a): 56 Students in Morris College discover that each course can have many sections, but each section refers to only one course.

57 Chapter 4: Entity Relationship (E-R) Modeling Exercise 3 (b): 57 Each student in Morris College can take many classes (or none) and each class can contain many students.

58 Chapter 4: Entity Relationship (E-R) Modeling Exercise 3 (c): 58 Apply business rules in exercise 3(a) & 3(b). Students in Morris College discover that each course can have many sections, but each section refers to only one course. Each student in Morris College can take many classes (or none) and each class can contain many students. (class and course in Morris College refer to the same entity)

59 Chapter 4: Entity Relationship (E-R) Modeling Exercise 3 (d): Apply business rules in exercise 3(a) & 3(b). Students in Morris College discover that each course can have many sections, but each section refers to only one course. Each student in Morris College can take many classes (or none) and each class can contain many students. (class and course in Morris College refer to the same entity) Some course in Morris College may have prerequisite course. Students will have enroll grade for every course they have taken.


Download ppt "ITS232 Introduction To Database Management Systems Siti Nurbaya Ismail Faculty of Computer Science & Mathematics, Universiti Teknologi MARA (UiTM), Kedah."

Similar presentations


Ads by Google