Entity-Relationship Data Model, Classification of entity types, Attributes

<< Data Flow Diagram, Data Dictionary, Database Design, Data Model

Attributes, The Keys >>

Database Management System (CS403)

Lecture No. 07

Reading Material

"Database Systems Principles, Design and Implementation"

Section: 5.2 5.3

written by Catherine Ricardo, Maxwell Macmillan.

Hoffer

Page: 85 - 95

Overview of Lecture

Entity

Different types of Entities

Attribute and its different types

In the previous lecture we discussed the importance and need of data models.

From this lecture we are going to start detailed discussion on a data model, which

is the entity relationship data model also known as E-R data model.

Entity-Relationship Data Model

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

database design. We have discussed in the previous lecture that semantic data models

provide more constructs that is why a database design in a semantic data model can

contain/represent more details. With a semantic data model, it becomes easier to design

the database, at the first place, and secondly it is easier to understand later. We also know

that conceptual database is our first comprehensive design. It is independent of any

particular implementation of the database, that is, the conceptual database design

expressed in E-R data model can be implemented using any DBMS. For that we will have

to transform the conceptual database design from E-R data model to the data model of the

particular DBMS. There is no DBMS based on the E-R data model, so we have to

transform the conceptual database design anyway.

A question arises from the discussion in the previous paragraph, can we avoid this

transformation process by designing our database directly using the data model of our

selected DBMS. The answer is, yes we can but we do not do it, because most commercial

DBMS are based on the record-based data models, like Hierarchical, Network or

Relational. These data models do not provide too much constructs, so a database design

Database Management System (CS403)

in these data models is not so expressive. Conceptual database design acts as a reference

for many different purposes. Developing it in a semantic data model makes it much more

expressive and easier to understand, that is why we first develop our conceptual database

design in E-R data model and then later transform it into the data model of our DBMS.

Constructs in E-R Data Model

The E-R data model supports following major constructs:

· Entity

· Attribute

· Relationship

We are going to discuss each one of them in detail.

The Entity

Entity is basic building block of the E-R data model. The term entity is used in three

different meanings or for three different terms and that are:

· Entity type

· Entity instance

· Entity set

In this course we will be using the precise term most of the time. However after knowing

the meanings of these three terms it will not be difficult to judge from the context which

particular meaning the term entity is being used in.

Entity Type

The entity type can be defined as a name/label assigned to items/objects that exist in an

environment and that have similar properties. It could be person, place, event or even

concept, that is, an entity type can be defined for physical as well as not-physical things.

An entity type is distinguishable from other entity types on the basis of properties and the

same thing provides the basis for the identification of an entity type. We analyze the

things existing in any environment or place. We can identify or associate certain

properties with each of the existing in that environment. Now the things that have

common or similar properties are candidates of belonging to same group, if we assign a

name to that group then we say that we have identified an entity type.

Generally, the entity types and their distinguishing 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. So

identification of entity types is guided by very nature of the things and then items having

properties associated with an entity type are considered to be belonging to that entity type

or instances of that entity type. However, many times the grouping of things in an

environment is dictated by the specific interest of the organization or system that may

supersede the natural classification of entity types. For example, in an organization, entity

Database Management System (CS403)

types may be identified as donated items, purchased items, manufactured items; then the

items of varying nature may belong to these entity types, like air conditioners, tables,

frying pan, shoes, car; all these items are quite different from each other by their

respective nature, still they may be considered the instances of the same entity type since

they are all donated or purchased or manufactured.

What particular properties of an entity type should be considered or which particular

properties jointly form an entity type? The answer to this question we have discussed in

detail in our very first lecture, where we were discussing the definition of database. That

is, the perspective or point of view of the organization and the system for which we are

developing the database is going to guide us about the properties of interest for a

particular group of things. For example, if you have a look around you in your bedroom,

you might see tube light, a bulb, fan, air conditioner, carpet, bed, chair and other things.

Now fan is an item that exists in your room, what properties of the fan we are interest in,

because there could be so many different properties of the fan. If we are developing the

database for a manufacturer, then we may be interested in type of material used for wings,

then the thickness of the copper wire in the coil, is it locally manufactured or bought

ready made, what individual item costs, what is the labor cost, what is the total cost,

overhead, profit margin, net price etc. But if we are working for a shopkeeper he might

be interested in the name of the company, dealer price, retail price, weight, color of fan

etc. From the user perspective; company name, color, price, warranty, name of the dealer,

purchase date and alike. So the perspective helps/guides the designer to associate or

identify properties of things in an environment.

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

called abstraction. The abstraction process is also supported by the requirements gathered

during initial study phase. For example, the external entities that we use in the DFDs

provide us a platform to identify/locate the entity types from. Similarly, if we have

created different cross reference matrices, they help us to identify different properties of

the things that are of interest in this particular system and that we should the data about.

Anyway, entity types are identified through abstraction process, then the items possessing

the properties associated with a particular entity type are said to be belonging to that

entity type or instances of that entity type.

While designing a system, you will find that most of the entity types are same as are the

external entities that you identified for the DFDs. Sometimes they may be exactly the

same. Technically, there is a minor difference between the two and that is evident from

their definitions. Anything that receives or generates data from or to the system is an

external entity, where as entity type is name assigned to a collection of properties of

different things existing in an environment. Anything that receives or generates data is

considered as external entity and is represented in the DFD, even if it is a single thing. On

the other hand, things with a single instance are assumed to be on hand in the

environment and they are not explicitly identified as entity type, so they are not

represented in the E-R diagram. For example, a librarian is a single instance in a library

system, (s)he plays certain role in the library system and at many places data is generated

Database Management System (CS403)

from or to the librarian, so it will be represented at relevant places in the DFDs. But the

librarian will not be explicitly represented in the E-R diagram of the library system and

its existence or role is assumed to be there and generally it is hard-coded in the

application programs.

Entity Instance

A particular object belonging to a particular entity type and how does an item becomes an

instance of or belongs to an entity type? By possessing the defining properties associated

with an entity type. For example, following table lists the entity types and their defining

properties:

Entity Types

Properties

Instances

EMPLOYEE

Human being, has name, has father name,

M. Sharif, Sh. Akmal

has a registration number, has qualification,

and many others

designation

FURNITURE

Used to sit or work on, different material,

Chair, table etc.

having legs, cost, purchased

ELECTRIC

Need electricity to work, purchased

Bulb, fan, AC

APPLIANCES

OFFICE

Used for office work, consumable or non- Papers, pencil, paper

EQUIPMENT

consumable,

weight etc.

Table 1: Entity types, their properties and instances

Each entity instance possesses certain values against the properties with the entity type to

which it belongs. For example, in the above table 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 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

As has been mentioned before that the term entity is used for all of the three terms

mentioned above, and it is not wrong. 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. We will be precise

most of the time, but if otherwise you can judge the particular meaning from the context.

Database Management System (CS403)

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. In

the following we discuss them in detail.

Weak Entity Types

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.

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.

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, 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.

Naming Entity Types

Following are some recommendations for naming entity types. But they are just

recommendations; practices considered good in general. If one, some or all of them are

ignored in a design, the design will still be valid if it satisfies the requirements otherwise,

but good designs usually follow these practices:

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, otherwise will

also work.

Abbreviations can be used, be consistent. Avoid using confusing abbreviations, if

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

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:

Database Management System (CS403)

EMPLOYEE

Strong Entity Type

Weak Entity Type

DEPENDENTS

Figure 1: Symbols used for entity types

We have discussed different types of entity types; in the next section we are going to

discuss another component or E-R data model, that is, the attribute.

Attribute

An attribute of an entity type is a defining 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. For example, all instances of the entity type STUDENT may have the attributes

name, father name, age; but the values against each of these attributes for each instance

may be different. Like, one instance may have the values (M. Hafeez, Noor Muhammad,

37) other may have others. Remember one thing, that the values of the attributes may be

same among different entity instances. The thing to remember at this stage is that

attributes are associated with an entity type and those attributes then become applicable

/valid for all the instances of that entity type and instances have values against these

attributes.

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. The

guidelines for naming an attribute are similar to those of entity types. However, one

difference is regarding writing the names of attributes. The notation that has been adopted

in this course 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. Second part of the attribute name describes the purpose of attribute and only

first letter is capitalized. For example empName means name attribute of entity type

EMPLOYEE, stAdrs means address attribute of the entity type STUDENT and alike.

Others follow other notations, there is no restriction as such, and you can follow anyone

that you feel convenient with. BUT be consistent.

Domain of an Attribute

Database Management System (CS403)

We have discussed in the previous section that 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 part of the definitions of an attribute and we must provide them. Domain is

the set of possible values that an attribute can have, that is, we specify a set of values

either in the form of a range or some discrete values, and then attribute can have value

out of those values. 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,

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 `Reema', or

`10/10/2004', why, because they are not legal salary values 1 . It should be numeric.

Further, even if we have declared it as numeric it will have numeric values, but about a

value like 10000000000. This is a numeric value, but is it a legal salary value within an

organization? You have to ask them. It means not only you will specify that the value of

salary will be numeric but also associate 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, Varchar, Char,

String, etc. So domain associates certain possible values with an attribute and certain

operations that can be performed on the values of the attribute. Another important thing

that needs to be mentioned here 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 15325.45 and in another instance the same attribute has a value `Reema'. No. All

attribute will have values from same domain, values may be different or same, whatever,

but the domain will be the same.

Sometimes when some coding has been adopted, then such strange values may be legal but here we are

discussing the general conditions

Database Management System (CS403)

Symbols for Attributes

Each represented as an oval, linked with an

ET symbol

Figure 2: Symbol used for attribute in E-R diagram

Types of Attributes

Attributes may be of different types. They may be:

Simple or Composite

Single valued or multi-valued

Stored or Derived

Simple or Composite Attributes:

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 stName, stFatherName, stDateOfBorth of an entity type STUDENT are

example of simple attributes. On the other hand if 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. In this case

stAdres will be a composite attribute.

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.

Stored or Derived Attributes:

Normally attributes are stored attributes, that is, their values are stored and accessed as

such from the database. However, sometimes attributes' values are not stored as such,

rather they are computed or derived based on some other value. This other value may be

stored in the database or obtained some other way. For example, we may store the name,

father name, address of employees, but age can be computed from date of birth. The

Database Management System (CS403)

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.

How a particular attribute is stored or defined, it is decided first by the environment and

then it has to be designer's decision; your decision. Because, the organization or system

will not object rather they will not even know the form in which you have defined an

attribute. You have to make sure that the system works properly, it fulfills the

requirement; after that you do it as per your convenience and in an efficient way.

Symbols for Attributes

Simple

Composite

Multi-valued

Derived

Figure 3: Symbol used for different types of attributes in E-R diagram

An example diagram representing all types of attributes is given below:

Database Management System (CS403)

Example

Experience

empId

empName

address

EMPLOYEE

dateHired

emp_Qual

street

houseNo

Figure 4: Example entity type with attributes of different types

This concludes this lecture.

Summary:

In this lecture we have discussed entity and attribute. We discussed that there are three

different notions for which the term entity is used and we looked into these three terms in

detail. They are entity type, entity instance and entity set. An entity type is name or label

assigned to items or objects existing in an environment and having same or similar

property. An entity instance is a particular item or instance that belongs to a particular

entity type and a collection of entity instances is called an entity set. We also discussed in

this lecture the attribute component of the E-R data model and its different types. The

third component the E-R data model, that is, the relationship will be discussed in the next

lecture.

Exercises:

Take a look into the system where you work or study or live, identify different

entity types in that environment. Associate different types of attributes with these

entity types.

Look at the same environment from different possible perspectives and realize the

difference that the change of perspective makes in the abstraction process that

results in establishing different entity types or/and their different properties.

Table of Contents: