Download - Week06 - ERD

1

Database I

Methodology

Entity-Relationship Data Modelling

2

Entity Relationship (ER) Data Model

Developed by Chen in 1976 to facilitate the database design

Entity Relationship Model is a high-level conceptual data model

It is a semantic data model that is used for the graphical representation of the conceptual database design

It is independent of any particular implementation of the database

We first develop our conceptual database design in E-R data model and then later transform it into the data model of our target DBMS

3

Constructs in ER Data Model

The E-R data model supports following major constructs: Entity Attribute Relationship

The Entity The term entity is used in three different meanings or for

three different terms:

1. Entity Type: It is an object or concept that is identified by the enterprise

and having independent existence Or an entity can be a person, place, object, event, or

concept about which we wish to store data

4

The Entity (Cont.)

The process of identifying entity types, their properties and relationships between them is called abstraction

2. Entity Instance A particular object belonging to a particular entity type The following table lists the entity, defining properties

and instances:

5

The Entity (Cont.)

3. 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 The term entity is used for all of the three terms

Discussed Most of the time it is used to mention an entity

type, next it is used for an entity instance and least times for entity set

6

The Entity (Cont.)(Entity Types)

Classification of entity types Entity types (ETs) can be classified into

Regular or Strong or Independent ETs Weak or dependent ETs

Weak Entity Types An entity types that are existence-dependent on some other

entity type i.e. they can’t exists 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

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 it cannot exist without being linked to an instance of employee

7

The Entity (Cont.)(Entity Types)

Strong Entity Type An entity type whose instances can exist

independently, that is, without being linked to the instances of any other entity type is called strong entity type

A major property of the strong entity types is that they have their own identification (candidate key), which is not always the case with weak entity types

For example, an employee in the previous example is an independent or strong entity type, since its instances can exist independently

8

The Entity (Cont.)

Naming Entity Types Following are some recommendations for naming entity

types Singular noun recommended, but still plurals can also be

used Organization specific names, like customer, client, gahak

anything will work Write in capitals, yes, this is something that is generally

followed Abbreviations can be used, be consistent. Avoid using

confusing abbreviations, if they are confusing for others today, tomorrow they will confuse you too

9

The Entity (Cont.)

Symbols for Entity Types A rectangle is used to represent an entity type in

E-R 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

10

Attribute

Attribute An attribute of an entity type is a property or

quality of the instances of that entity type Entity instances of same entity type have the

same attributes (E.g. Student Identification, Student Name) However, values of these attributes may be same or different

An attribute is identified by a name allocated to it and that has to be unique with respect to that entity type

11

Attribute (Cont.)

Domain of an Attribute Domain is the set of possible values that an

attribute can have Domain is a form of a check or a constraint on

attribute that it cannot have a value outside this set Associating domain with an attribute helps in

maintaining the integrity of the database Domain is normally defined in form of data type

and some additional constraints like the range constraint

12

Attribute (Cont.)

Data type is defined as a set of values along with the operations that can be performed on those values

Symbol used for an attribute is shown in the figure below

13

Attribute (Cont.)(Types of Attribute)

Types of Attributes Attributes may be of different types:

Simple/Atomic Composite Single valued Multi-valued Stored or Derived

Simple/Atomic: Simple or atomic attributes cannot be further broken

down or subdivided For example, attributes stName, stFatherName,

stDateOfBorth of an entity type STUDENT are example of simple attributes

14


Composite Attributes: An attribute consists of collection of other simple or

composite attributes then it is called a composite attributes

For example, stAdres attribute may comprise of houseNo, streetNo, areaCode, city etc.

Single valued An attribute that holds a single value For example, branchNo attribute of branch entity

Multi-valued An attribute that holds multiple values For example, branch entity may have multiple values

for branch telephone no attribute

15


Stored or Derived Normally attributes are stored attributes, that is, their

values are stored and accessed as such from the database

However, sometimes attribute’s values are not stored as such, 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

16


Symbols used for different types of attributes are shown below

17

Attribute (Cont.)

The Keys A key is a set of attributes that can be used to

identify or access a particular entity instance of an entity type or out of an entity set

An entity type may have many instances, from a few to several thousands and even more

For example, think of whole population of Pakistan, the data of all Pakistanis lying at one place, say with NADRA people

Now if at sometime we need to identify a particular person out of all this data, how can we do that?

18

Attribute (Cont.)

Can we use name for that, well think of any name, like Mirza Zahir Iman Afroz, now we may find many people with this name in Pakistan

However, if you think about National ID Card number, then no matter

whatever is the population of Pakistan, you will always be able to pick precisely a single person

Here National ID Card is the key We can have super, candidate, primary, alternate

or foreign key

19

Example

Conceptual Design Entity

The database will store records data about STUENT, for each STUDENT in the database we record name, address, rollno, schools attanded

Attributes For each name, there always will be one and only one

name for each STUDENT. The value for name will be subdivided into first, middle and last name

For each address, there always will be one and only one

address for each STUDENT. The value for address will not be subdivided.

20

Example (Cont.)

For each student we will record schools, these may be more than one school recorded for each student

Keys For each STUDENT we will assume that there is an

attribute rollno, that will be unique to identify individual entity instances

STUDENTSTUDENT

name

firstname middlename lastname

rollno

addressschools

21

Example (Cont.)

Logical Design (Mapping to Relational Model) Map1: For strong entities, develop a new relations and

make the key attribute a primary key Map1(a): Map atomic attributes to columns of a relation Map1(b): Composite attributes form the columns from the

atomic parts of the composite attribute Map1(c): For multi-valued attributes develop the primary-

foreign key relationship

rollno schools

rollno firstname middlename lastname address

STUDENT

STUDENT_SCHOOL

22

Relationship

Relationship: A relationship is any association, linkage, or

connection between the entities of interest to the business

It is a two directional, association between two entities, or between an entity and itself

Each relationship has a name, an optionality (optional or mandatory), and a degree (how many)

23

Relationship (Cont.)

An example of a relationship would be: Employees are assigned to projects Projects have subtasks Departments manage one or more projects

Relationship Type: An abstraction of a relationship i.e. a set of

relationships instances sharing common attributes Participants:

Entities enrolled in a relationship

24


Naming Relationships: A relationship name is usually a verb or verb phrase that

denotes the connection between entities (noun) STUDENT and CLASS have ENROLL relationship. However,

it can also be named as STD_CLS

Symbol for Relationships: Shown as a Diamond Diamond is doubled if one of the

participant is dependent on the other Participants are connected by

continuous lines, labeled to indicate

cardinality

25


Relationship Roles: The labels “manager” and “worker” are called “roles” They specify how employee entities interact via the “works-

for” relationship set Roles are indicated in ER diagrams by labeling the lines

that connect diamonds to rectangles, Roles are optional

26

Relationship (Cont.)(Structural Constraints)

Structural Constraints Structural constraints are information about how two (or

more) entities are related to one another There are two types of structural constraints: Cardinality and participation

Cardinality Ratio of a Relationship Cardinality is the number of entities (one or more) that will

be related to another entity (or entities) For example, there are four ways in which the entities

AUTOMOBILE and STUDENT can be "numerically involved" in a relationship: one-to-one (1:1) many-to-one (M:1) one-to-many (1:M), and many-to-many (M:N).

27

Relationship (Cont.) (Structural Constraints)

One-to-One (1:1) In this type of relationship, one entity is

associated with one other entity, and vice versa E.g. the student/automobile relationship would be

one-to-one, symbolically: STUDENT:AUTOMOBILE :: 1:1

28


STUDENT:AUTOMOBILE :: 1:1

29


Many-to-One (M:1) More than one entity is associated with one entity If the STUDENT:AUTOMOBILE relationship

(shown in last slide) were many-to-one We would say that many students are associated

with one automobile and one automobile is associated with many students; that is:

STUDENT:AUTOMOBILE::M:1

30


STUDENT:AUTOMOBILE::M:1

31


One-to-Many (1:M) One entity is associated with more than one entity The sense of a one-to-many

STUDENT:AUTOMOBILE relationship would be that a student is associated with many automobiles and an automobile is associated with one student

Clearly, if we define a relationship as 1:M (or M:1), then we need to be very clear about which entity is 1 and which is M

STUDENT:AUTOMOBILE::1:M

32


STUDENT:AUTOMOBILE::1:M

33


Many-to-Many (M:N) In many-to-many relationships, many occurrences

of one entity are associated with many of the other

Many-to-many is depicted as M:N, as in M of one thing related to N of another thing

If our STUDENT:AUTOMOBILE relationship were many-to-many, a student would be associated with many automobiles and an automobile with many students:STUDENT:AUTOMOBILE::M:N

34


STUDENT:AUTOMOBILE::M:N

35


Participation: Full/Partial To show that every automobile is driven by a

student, but not every student drives an automobile

By putting a double line between the relationship diamond and the AUTOMOBILE entity to indicate that every automobile is driven by one student, Put another way, every automobile in the database participates in the relationship

The single/double lines are called participation constraints (a.k.a. optionality constraints) and are depicted in figure on next slides

36


Mandatory; if an automobile is in the database, itmust be related to some student.

Optional

37


A graphic on how

to read an ER

diagram is

presented in Figure

38


Types of Relationships (By number of participant entities): Unary Relationship

An ENTITY TYPE linked with itself, also called recursive relationship. Example Roommate, where STUDENT is linked with STUDENT

Binary relationship A Binary relationship is the one that links two entities sets

e.g. STUDENT-CLASS Ternary Relationship

A Ternary relationship is the one that involves three entities e.g.VENDOR-PART-WAREHOUSE

39

Example

Consider a model for a simplified airport that records PASSENGERS and FLIGHTS

Suppose that the attributes of PASSENGER are name, articles of luggage, and frequent flyer number. Suppose the attributes for FLIGHT are flight number, destination, time of departure, and estimated time of arrival

Draw the ER diagram

40

Example (Cont.) Carry out all the

steps performed for1st example on slide 19

Step 1: Examine attributes in the primary entity to find out if information about one of the attributes is to be recorded Step 2: If another entity is appropriate, draw the second

entity with its attributes. Repeat steps performed in 1st example

The other entity in this problem is FLIGHT as shown on next slide

41

Example (Cont.)

Step 3: Connect entities

with relationships if

relationships exist The specifications do not tell us whether this should be 1

or M, so we chose 1 We also chose full participation on both sides as shown

on next slide

42

Example (Cont.)

43

Example (Cont.)

Logical Design (Mapping to Relation Model) Perform all the mapping rules discussed in slide 21

name ffn luggage

flight# destination depart arrive

Passenger

Flight

44

Relationship (Cont.) (Mapping Rules)

Mapping to Relational Model Map2(a): For each M:N relationship,

create a new table with the primary

keys of each of the two entities that

are being related in the M:N relationship E.g. STUDENT, COURSE relationship

Fname Midname lstname RollNo Address

CNo CName CreditHrs CNo RollNo

Course Enroll

Student

45


Map2(b): For binary 1:1 relationships, include the primary key of Entity A into Entity B as the foreign key Map2(b)-i: if one of the sides has full participation in the

relationship, and the other has partial participation, then store the primary key of the side with the partial participation constraint on the side with the full participation constraint

Consider STUDENT-AUTOMOBILE relationship on slide 36

Fname Midname lstname StdNo Address

Student

VID Make BodyStyle Color Year StdNo Automobile

46


Map2(b)-ii: For binary 1:1 relationships, if both sides have partial participation constraints, there are three alternative ways to implement a relational database: You may select either one of the relations to store the key

of the other (and live with some null values) You can create a new relation to accommodate the

relationship that would contain the key of the two related entities (as is done in Map2a)

Create a new table with just the keys from the two tables e.g. STUDENT and AUTOMOBILE, in addition to the two tables, STUDENT and AUTOMOBILE. In this case we would map the relations as we did in the binary M:N case; and if there were any null values, these would be left out of the linking table

47


Map2(b)-iii: For binary 1:1 relationships, if both sides have full participation constraints, you may use the semantics of the relationship to select which of the relations should contain the key of the other

Map2(c): For binary 1:N relationships, we have to check what kind of participation constraints the N side of the relationship has: Map2(c)-i: For binary 1:N relationships, if the N-side has full

participation, include the key of the entity from the 1 side, in the relation on the N side as a foreign key

Example on next slide

48


Fname Midname lstname StdNo DormName

Student

DormName Supervisor

Dorm

49


Map2(c)-ii: For binary 1:N relationships, if the N-side has partial participation, the 1:N relationship is handled just like a binary M:N relationship with a separate table for the relationship. The key of the new relation consists of a concatenation of the keys of the related entities

Map3(a): For 1:N recursive relationships, reinclude the primary key of the table with the recursive relationship in the same table, giving it some other name

Map3(b): For M:N recursive relationships, create a separate table for the relationship (as in mapping rule Map2(a))

50

Relationship (Cont.)Crow’s Foot or Barker's Notation

Crow’s foot notation

51

Relationship (Cont.)Weak Entity

In the figure, the

EMPLOYEE–

DEPENDENT—

HOBBYAR is

depicted

52

Relationship (Cont.)Weak Entity

Map4-Develop a new relation for each weak entity, If there is a composite attribute, include only the atomic parts of the composite attribute. To relate the weak entity to its owner, include the primary key of the owner entity in the weak relation as a foreign key

53

Relationship (Cont.) Attributes of Relationships

In slide 44 we considered the M:N relationship STUDENT–COURSE

Now consider adding the attribute grade to the ER diagram If we put grade with the STUDENT entity, we would have a

multivalued attribute that had to be somehow related to the COURSE entity to make sense

Similarly, if we put the grade attribute with the COURSE entity, the COURSE entity would have to be related to the STUDENT entity

The correct place for the grade attribute in the diagram would be on the relationship, enroll, because grade requires both a STUDENT and a COURSE to make sense

This is shown on next slide

54


An attribute like gradeis called a "relationshipattribute" or "intersection

attribute“ When it is recognized

that the attribute has to be identified by more than one entity, the attribute is moved to the relationship between the two (or more) entities that identify it

55


So the diagram

will evolved to

the one shown

on left side

56

Enhancements in E-R Data Model (EER- Data Model)

The basic concepts of ER modeling (as originally developed by Chen) were not sufficient to represent the requirements of more complex applications, such Generalizations and Specializations

An ER model that supports these additional semantic concepts is called the Enhanced Entity Relationship (EER) model

57

Enhancements in E-R Data Model (EER- Data Model) (Cont.)

Generalizations and specializations are associated with the concepts of super-classes and sub-classes and attribute inheritance

For example, a STUDENT entity contains information about students

However, suppose we wanted to store information about all people at an institution say staff and faculty

Think of a super-class called PERSON that contained a sub-class for STUDENT, another sub-class for STAFF, and yet another sub-class for FACULTY

The super-class in a database is called a generalization, and the sub-classes are called specializations

58


To visualize a problem with ER diagrams Where one of the attributes for an entity has values

that vary according to "the situation" For example, suppose we are modeling student

athletes who may play more than one sport Some information in the ATHLETE entity contains

attributes that have different values for different sports

These different values are called "variants"Name RNo Sport Info

Ahmad 1234 Cricket 20 ODI, 3 Wickets

Saima 2345 Tennis 220,City Rank14Athlete

59


We are actually storing information about two different, but related, things: (1) a generalization called, "students," who have a name,

id, etc.; and (2) specializations — sports (tennis, cricket, golf, etc.),

each with their own different attributes These variants are most easily handled by removing

the variant from the generalization and treating it as a subclass entity and leaving the original, "fixed part" of the entity as a super-class

60


A superclass entity may be a member of more than one subclass of aspecialization

No overlapping

61


Map5: For each generalization/specialization entity

situation, create one table for the generalization entity and create one table for each specialization entity

Add the attributes for each entity in their each respective tables

Add the key of the generalization entity into the specialization entity

The primary key of the specialization will be the same primary key as the generalization

Download - Week06 - ERD

Top Related