Chapter No 2

Introduction To Database
By: Hadeesullah Sahak
Department of Computer Science
Entity-Relationship Data Model

 The ER model defines the conceptual view of a database. It works

around real-world entities and the associations among them. At view

level, the ER model is considered a good option for designing

databases. It is a semantic data model that is used for the graphical

representation of the conceptual database design.

Entity-Relationship Data Model

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

Constructs in E-R Data Model
 The E-R data model supports following major constructs:

 Entity

 Attribute

 Relationship
Entity
 An entity can be a real-world object, either animate or inanimate,

that can be easily identifiable. For example, in a school database,

students, teachers, classes, and courses offered can be considered as

entities. All these entities have some attributes or properties that

give them their identity.

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.
Entity Type – Continue
 It is collection of entity having common attribute. As in Student table each

row is an entity and have common attributes.

 So STUDENT is an entity type which contains entities having attributes id,

name and Age.

 Also each entity type in a database is described by a name and a list of

attribute. So we may say a table is an entity type

Entity Instance
 An entity instance is a single occurrence of an entity. Or A particular

object belonging to a particular entity type is called Entity Instance.

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.

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.

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.
 Singular noun recommended, but still plurals can also be used
 Organization specific names, like customer, client, 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.
Naming Entity Types
Symbol 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:
Attributes
 Entities are represented by means of their properties, called attributes.

All attributes have values.

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

Attributes – Continue
 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.

Domain of an Attribute
 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
Attributes – Symbols
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

 Simple attributes are atomic values, which cannot be divided further.

For example, a student's phone number is an atomic value of 10 digits.

Or stDateOfBorth of an entity type STUDENT are example of simple

attributes.
Simple or Composite Attributes
 Composite attributes are made of more than one simple attribute. For

example, a student's complete name may have first_name and

last_name.

 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, 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.
Stored or Derived Attributes
Example
Relationships
 The association among entities is called a relationship. For example,

an employee works_at a department, a student enrolls in a course.

Here, Works_at and Enrolls are called relationships.

Relationships - Continue
 A relationship is any association, linkage, or connection between the

entities of interest to the business; it is a two-directional, significant

association between two entities. Each relationship has a name, an

optionality (optional or mandatory), and a degree (how many).

 An example of a relationship would be:
 Employees are assigned to projects
 Projects have subtasks
 Departments manage one or more projects
Naming Relationships
 If there is no proper name of the association in the system then

participants’ names of abbreviations are used. STUDENT and CLASS

have ENROLL relationship. However, it can also be named as STD_CLS.

Degree of Relationships
 Unary Relationship
 An ENTITY TYPE linked with itself, also called recursive relationship.
Example Roommate, where STUDENT is linked with STUDENT
Degree of Relationships
 Binary relationship
 A Binary relationship is the one that links two entities sets e.g.
STUDENT-CLASS. Relationships can be formally described in an
ordered pair form.
Degree of Relationships
 Ternary Relationship
 A Ternary relationship is the one that involves three entities e.g.
 STUDENT-CLASS-FACULTY.
Relationship Cardinalities
 Cardinality defines the number of entities in one entity set, which

can be associated with the number of entities of other set via

relationship set.
Relationship Cardinalities
 One-to-one − One entity from entity set A can be associated with at

most one entity of entity set B and vice versa.

Relationship Cardinalities
 Many-to-one − More than one entities from entity set A can be

associated with at most one entity of entity set B, however an entity

from entity set B can be associated with more than one entity from
entity set A.
Relationship Cardinalities
 Many-to-many − One entity from A can be associated with more than

one entity from B and vice versa.

Database Keys
 Keys are very important part of Relational database. They are used to

establish and identify relation between tables. They also ensure that

each record within a table can be uniquely identified by combination

of one or more fields within a table.

Database Keys – Continue
 A key is an attribute or a set of attributes in a relation that identifies

a tuple in a relation. The keys are defined in a table to access or

sequence the stored data quickly and smoothly. They are also used to

create relationships between different table.

Database Keys – Super Key
 Super Key: a super key is an attribute or combination of attributes in

a relation that identifies a tuple uniquely within the relation. A super

key is the most general type of key.

 For example, in a relation STUDENT consists of different attribute like

RegistrationNo, Name, FatherName, Class And Address. It means that

RegNO is the super key for the realtion and any combination of
attributes with the super key is also a super key.
Database Keys – Super Key
 Any attribute of set of attributes combined with the super key RegNo

will also become a super key. A combination of two attributes

{RegNO, Name} is also a super key. And similarly {RegNo, Class} or any

other combination.
Database Keys – Candidate Key
 A candidate key is a super key that constrains no extra attribute. It

consists of minimum possible attributes. A super key like

{RegNo,Name} constrains an extra filed Name.

 it can be sued to identify a tuple uniquely in the relation, but it does

not consist of minimum possible attribute as only {RegNo} can be used

to identify a tuple in relation. It means that {RegNo, Name} is a super
key but it is not a candidate key because it contains an extra
attribute. And {RegNo} is also a super key and Candidate Key.
Database Keys – Candidate Key
Database Keys – Primary Key
 A primary key is a candidate key that is selected by the database

designer to identify tuples uniquely in a relation. A relation may

contains many candidate keys.

 When the designer selects one of them to identify a tuple in the

relation, it becomes a primary key. It means that if the is only one

candidate key, it will be automatically selected as primary key.
Database Keys – Primary Key
 Some most important points about a primary key are.
 1. A relation can have only one primary key.

 2. Each value in primary key attribute must be unique.

 3. Primary key can not contain null values.
Database Keys – Alternate Key
 The candidate key that are not selected as primary key are known as

alternate keys. Suppose STUDENT relation contains different attributes

such as {RegNo, RollNo, Name and Class}.

 The attributes {RegNo} can be used to identify each student in the

table. If {RegNo} is select as primary key then {RollNo} Attribute is

known as alternate key.

Database Keys – Alternate Key
Database Keys – Composite Key

 A primary key that consists of two or more attributes is known as

composite key.
Database Keys – Foreign Key
 A foreign key is an attribute or set of attributes in a relation

who's values match a primary key in another relation.

 The relation in which foreign key is created is know as

Dependent table or child table. The relation to which the

foreign key refers is known as parent table. The key
connects to another relation when a relationship is establish
between tow relation.
Database Keys – Foreign Key
General Example