LECTURE 3: ENTITY-RELATIONSHIP MODELING

Transcription

1 LECTURE 3: ENTITY-RELATIONSHIP MODELING Ref. Chapter11 + Appendix F from Database Systems: A Practical Approach to Design, Implementation and Management. Thomas Connolly, Carolyn Begg. 1 IS220 : D a t a b a s e F u n d a m e n t a l s

2 Chapter Objectives 2 In this chapter you will learn: How to use Entity Relationship (ER) modeling in database design. The basic concepts associated with the Entity Relationship (ER) model, namely entities, relationships, and attributes.

3 Main Terms 3 Entity. Relationship. Attribute. Key attribute. Relationship constraint: Multiplicity Cardinality participation Strong and weak entities.

4 Entity-Relationship model 4 The Entity-Relationship (ER) model is a popular high-level conceptual data model. The Entity-Relationship Diagram (ERD) is a graphical model for representing the conceptual model for the data. ER model describes data as: Entities. Relationships. Attributes.

5 Example of ER-diagram for company database 5

6 Entity 6 The basic object that the ER model represents is an entity, which is a thing in the real world with an independent existence. An entity may be an object with a physical (or real ) existence (student, car) or it may be an object with a conceptual (or abstract ) existence (company, course). Each entity is shown in ER-model as a rectangle labeled with the name of the entity, which is normally a singular noun. Student

7 Attribute 7 Attributes hold values that describe each entity occurrence and represent the main part of the data stored in the database. For example, a Staff entity may be described by the staffno, name, position, and salary attributes. Each attribute is shown in ER-model as Oval labeled with the name of the attribute. st_name Student

8 Attribute (cont.) 8 Each attribute is associated with a set of values called a domain. For example: a set of integer values for number of (rooms) attribute between 1 and 15. Attributes can be classified as being: Simple or Composite. Single-valued or Multi-valued. Stored or Derived.

9 Simple and Composite attributes 9 Simple attribute: E.g. ID, Salary, Gender Composite attribute: ID Composite attribute indicated with sub ovals. E.g. Name (FirstName, MiddleName, LastName).

10 Simple and Composite attributes(cont.) 10 Example: FirstName St_no MiddleName name LastName DOB Tel_no Area_cd no EX STUDENT

11 Single-valued and Multi-valued attributes 11 Single-valued: The majority of attributes are single-valued. E.g: ID Multi-valued: ID Represent in ER-model as double line oval E.g: colors attribute for a car - {Color} Color

12 Stored and Derived attributes 12 Stored attribute: An attribute that represent a stored value. E.g. Birth_date. Derived attribute: Birth_date Represent in ER-model as dotted line oval. E.g. Age The age value can be determined from the current date and the value of the birth_date of a person, so: age is a derived attribute and birth_date is a stored attribute. Total_cost is derived from quantity*unit_price

13 Stored and Derived attributes (cont.) 13 Some attribute values can be derived from related entities. E.g. an attribute Number_of_employees of a DEPARTMENT entity can be derived by counting the number of employees related to that department. Dept_Name ID name Employee works-on Department Dept_No No_of_employee

14 Key Attributes 14 Candidate key: It cannot contain NULL value. E.g. Each branch has a unique branch number There could be more than one candidate key; if so, we select one of them as the primary key and the other will be an Alternate Key E.g. Staff(Staff_No, NID) Primary key Alternate key (National ID Number)

15 Key Attributes (cont.) 15 Primary key: primary key attribute indicated with underline The choice of Primary Key (PK) for an entity is based on: Attribute length. Minimal number of attributes required. Future certainty of uniqueness. PK s may be simple PK (single attribute) CUSTOMER (custno,.) composite PK (multiple attributes) ORDERLINE (orderno, prodno, quantity, )

16 Drawing Entity and attributes 16 stu_id name dob age student phone address Rectangles represent entities street Oval represent attributes derived attributes use dotted line multi-valued attributes use double line primary key attribute indicated with underline Composite attribute indicated with sub ovals. city

17 17 Lecture1

18 Relationship 18 A relationship type is a set of associations between one or more participating entity types. Each relationship type is given a name that describes its function. E.g. Students Register for Subjects School Has Staff Driver Commits Traffic Offence Customer Orders Product Supplier Supplies Parts To Projects Each Relationship is shown in ER-model as diamond labeled with the name of the relationship. ENTITY Relationship ENTITY

19 Degree of Relationship 19 The degree of a relationship indicates the number of entity types involved in a relationship. Degree of relationship includes: UNARY between entities from one entity set BINARY between entities from two entity sets N-ARY among entities from more than two entity sets

20 Relationship Degree: Unary (Recursive) 20 Unary (Recursive )relationship is a relationship type where the same entity type participates more than once in a different role. Relationships may be given Role names to indicate the purpose that each participating entity type plays in a relationship. Role names can be important for recursive relationships to determine the function of each participant.

21 Relationship Degree: Binary Relationship 21 Binary Relationship is a relationship type between two entity types. E.g. Employee Works for Department

22 Relationship Degree: Binary Relationship(cont.) 22 When two entities are associated through more than one relationship, Role can be used to classify the purpose of each relationship.

23 Relationship Degree: Ternary Relationship 23 Ternary Relationship is a relationship type between three entity types. E.g. Supplying a part to a project by a supplier. Supplier Supply Project Part

24 Attributes on Relationship 24 Relationship types can also have attributes. E.g. Customer Orders a Product quantity is attribute of orders relationship customer orders product E.g. Employee WORKS-ON Project To record the number of hours per week that an employee works on a particular project. The attribute Hours can be included to the WORKS- ON relationship type. Employee quantity works-on Project Hours

25 Constraints on Relationships 25 There are three types of constraint on relationships: Cardinality. Multiplicity. Participation.

26 Constraints on Relationships: Cardinality 26 Cardinality Express the maximum number of relationships an entity can participate in. There are three types of Relationships: one-to-one (1:1) one-to-many (1:M) Many-to-one (M:1) many-to-many (M:N)

27 One-to-One (1:1) Relationships 27 E.g. Professor Manage Department P1 r1 D001 P2 P3 r2 D002 Professor 1 Manage 1 Department Each professor manages at most one department. Each department is managed by only one professor.

28 One-to-Many (1:M) Relationship 28 E.g. Professor teach Section P1 r1 3C01 r2 3C03 P2 r3 3C02 Professor 1 teach M Section Each professor teaches many sections; but each section is taught by only one professor (or at most one professor) Lecture3

29 Many-to-One Relationship (M:1) 29 E.g. Professor work-in Department P1 r1 Com. Science P2 r2 Network P3 r3 Info. Sys Professor M Work-in 1 Department Each professor works in only one Department; but each Department has many professors (many professors work in one department) Lecture3

30 Many-to-Many (M:M) Relationship 30 E.g. Student Enroll-in Course S1 r1 is300 r2 is301 S2 r3 is400 S3 r4 is500 S4 r5 is600 Student M Enroll-in M course Each student can enroll in many courses; and each course can be enrolled by many students. Lecture3

31 Constraints on Relationships: Multiplicity 31 Multiplicity constrains the way that entities are related. Multiplicity is shown in ER-model as (min#, max#) Lecture3

32 Multiplicity in One-to-One (1:1) Relationships 32 E.g. Professor Manage Department P1 r1 D001 P2 P3 r2 D002 Professor 1 Manage (0,1) (1,1) 1 Department Each Professor may manage 0 to 1 department, Each Department should be managed by only one Professor.

33 Multiplicity in One-to-Many (1:M) Relationship 33 E.g. Professor teach Section P1 r1 3C01 r2 3C03 P2 r3 3C02 Professor 1 teach (0,5) (1,1) (0,*) Each Professor may teach 0 to 5 Sections, M Section Each Section should be taught by only one Professor. * = many.. Use it if the number is not specified Lecture3

34 Multiplicity in Many-to-Many (M:M) Relationship 34 E.g. Student Enroll-in Course S1 r1 is300 S2 r2 is301 S3 r3 is400 S4 r4 is500 Student M Enroll-in Each student should enroll in 1 to 7 Courses, Each Course may be enrolled by 0 to 100 students. * = many.. Use it if the number is not specified M (1,7) (0,100) (1,*) (0,*) course Lecture3

35 Constraints on Relationships: Multiplicity 35 A summary of the possible ways that multiplicity constraints can be represented along with a description of the meaning.

36 Constraints on Relationships: Participation 36 Participation constraints determine whether all or only some entities participate in a relationship. Two type of participation: Mandatory (Total) Optional (Partial) Lecture3

37 Constraints on Relationships: Participation 37 Optional (partial) (0:*): if an entity s existence does not require a corresponding entity in a particular relationship. (Not existence-dependent). E.g. An employee may not have a spouse E.g. Not every staff manages a department Optional participation is represented in ER-model by single line. R E Lecture3

38 Constraints on Relationships: Participation 38 Mandatory (total) (1:*) if an entity s existence requires the existence of an associated entity in a particular relationship (existence-dependent). E.g. Every spouse must be that of an employee. E.g. Every department is managed by some staff. Mandatory participation is represented in ER-model by double line. R E Lecture3

39 Examples 39 employee 1 1 has spouse CUSTOMER 1 N place (0,M) (1,1) ORDER STUDENT M (1:M) enrol (0:N) N SUBJECT Lecture3

40 40 Lecture1

41 Strong & Weak Entity Type 41 Entity types can be classify as being strong or weak. A Strong Entity type is an entity that have a key attribute. An entity type is referred to as being strong if its existence does not depend upon the existence of another entity type. A characteristic of a strong entity type is that each entity occurrence is uniquely identifiable using the primary key attribute(s) of that entity type. E.g. Staff is strong entity type has ( staffno as primary key) Lecture3

42 Strong & Weak Entity Type (cont.) 42 A Weak entity type is an entity that does not have a key attribute. A weak entity type is dependent on the existence of another entity type. A characteristic of a weak entity is that each entity occurrence cannot be uniquely identified using only the attributes associated with that entity type. The entity type which the weak entity type depends on is called the identifying entity type (owner). E.g EMPLOYEE Weak entities are identified by the combination of: A partial key of the weak entity type. The primary key of the owner entity type. Lecture3

43 Representing Weak Entities and Relationships 43 Weak entity is indicated by a double line rectangle, and weak relationship is represented by a double line diamond. Employee 1 Has M Dependent The relationship between the weak entity and its owner entity is called weak relationship. Participation of weak entity in weak relationship is always mandatory. Lecture3

44 Weak Entity Type Example 44 E.g. Employee Has Dependent Dependent can be regarded as a weak entity only when the attributes of Dependent can not uniquely identify a dependent. E.g. Dependent has the attributes d_name and d_birthdate only, but two employees may have dependents with the same name and date of birth. However employee_no and d_name uniquely identify each dependent. Employee is the owner entity Has is the weak relationship Lecture3

45 Weak Entity Type Example (cont.) 45 SSN Salary Name Sex EMPLOYEE 1 N DEPENDENTS -OF DEPENDENT BDate Relationship Lecture3

46 Modelling with E-R Diagram 46 List the major entity sets in the system Represent the entity sets graphically by a rectangle Search for relationships between the entities and represent them graphically by a diamond Add attributes, underline PK attribute/s Model relationship cardinality and participation Lecture3

47 The Chen notation for ER modeling 47

48 The Chen notation for ER modeling 48 Composite attribute

49 Example (Company) 49 The COMPANY database keeps track of a company s employees, departments and projects. The company is organized into departments. Each department has a unique number, name, several locations, and a particular employee who manages the department. We keep track of the start date when that employee began managing the department. Each department may control many projects. However, Each project should be controlled by one department only. Project has a unique number, name, and a single location. Lecture3

50 Example (Company) 50 We store each employee s name, social security number, address, salary, sex, and birth date. An employee should be assigned to one department only but each department must have many employees. Each employee should work on several projects and each project should run by many employees. We keep track of the number of hours per week that an employee works on each project. We also keep track of the direct supervisor of each employee. We want to keep track of the dependents of each employee for insurance purposes. We keep each dependent s first name, sex, birth date, and relationship to the employee. Lecture3

51 51 Lecture3

52 Alternative ER Modeling Notations 52 It is important to note that there are many other alternative diagrammatic notations. For examples: Chen notation: the original notation. UML (Unified Modeling Language) notation Crow s Feet notation Barker s notation: is used by the Oracle modelling tools. It s a variation of the "crows foot.

53 53

54 54

55 55 Tool For Drawing ER Diagrams In Oracle software Lecture3

56 56 Lecture1