Entity and its types:
In a relational database, a weak entity is an entity that cannot be uniquely identified by its
attributes alone; therefore, it must use a foreign key in conjunction with its attributes to create
a primary key. The foreign key is typically a primary key of an entity it is related to. A weak entity
does not have any items in its primary key other than its inherited primary key.
Example: A weak entity is one that can only exist when owned by another one. For example: a
ROOM can only exist in a BUILDING. On the other hand, a TIRE might be considered as a
strong entity because it also can exist without being attached to a CAR.
Just to play with it, question is strong entity type and answer is weak. Question is always there,
but an answer requires a question to exist.
A Strong Entity is one that exists on its own, independent of other entities. The Strong Entity
is usually referred to as the Owner or Parent entity.
For example, at a university or college we have student entities and we would define a student
entity type. Universities and Colleges assign unique student numbers, one per student.
Student has a key attribute and would be considered a strong entity type.
A recursive entity is one in which a relation can exist between occurrences of the same entity
set. This occurs in a unary relationship.
Example: sir sy pochna aa.
If a Many to Many relationship exist we must create a bridge entity to convert it into 1 to Many.
Bridge entity composed of the primary keys of each of the entities to be connected. The bridge
entity is known as a composite entity. A composite entity is represented by a diamond shape
with in a rectangle in an ER Diagram.
The attributes of an entity that cannot be divided into smaller components, are called simple
attributes. They art also referred to as atomic attributes. For example, the color, age and roll
number of a student are examples of simple attributes.
The attribute of an entity that can be divided into smaller components is called composite
attribute. Each component also represents simple attribute with independent meanings. For
example, student's name can be divided into: first-name, middle-name and last-name.
Single Valued and Multi Valued attribute
A single valued attribute can have only a single value. For example a person can have only one
'date of birth', 'age' etc. That is a single valued attributes can have only single value. But it can
be simple or composite attribute.That is 'date of birth' is a composite attribute , 'age' is a simple
attribute. But both are single valued attributes.
Multivalued attributes can have multiple values. For instance a person may have multiple phone
numbers,multiple degrees etc.Multivalued attributes are shown by a double line connecting to
the entity in the ER diagram.
Example1: A customer can have multiple phone numbers, email
Example2: A person may have several college degrees
Stored and Derived Attributes
The value for the derived attribute is derived from the stored attribute. For example 'Date of
birth' of a person is a stored attribute. The value for the attribute 'AGE' can be derived by
subtracting the 'Date of Birth'(DOB) from the current date. Stored attribute supplies a value to
the related attribute.
Stored Attribute: An
Example: Date of Birth
Derived Attribute: An attribute that’s value is derived from a stored
Example : age, and it’s value is derived from the stored attribute Date of Birth.
A complex attribute that is both composite and multi valued.
Definition and Explanation of Relationship in Database and Types of Relationships in
Definition and Explanation:
A relationship is an association between the instances of one or more entity types. For
example, a student may be related to a class by being enrolled in that class. Another example is
the link between mother and children. One mother may have many children, but each child has
only one mother.
A relationship between entities is given a relevant name. For example, there is a relationship
between MANAGER and DEPARTMENT. A manager manages the department; on the other
hand a department is managed by a manager. This leads to a relationship called "Manages"
between MANAGER and DEPARTMENT.
Similarly, there is a relationship between AUTHOR and the BOOK. An author writes a book; on
the other hand a Book is written by an Author. This leads to a relationship called "Writes"
between AUTHOR and BOOK.
In E-R diagram, a relationship is indicated by a diamond shape labeled with relationship name.
The diamond symbol is placed between the entities symbols connecting with lines. The
relationships between MANAGER-DEPARTMENT and AUTHOR-BOOK are shown in figure
The entities can be associated /connected to one another in different ways. For example,
different possible and relevant relationships between BOOK STORE and BOOK(s) are as
A BOOK STORE returns BOOK(s).
Degree of Relationships:
The entities that are participating in a given relationship are known as participants. The number
of participants in a given relationship is called degree of relationship. Thus, the relationship
"writes" is of degree two because only two entities are participating in this relationship, i.e.
AUTHOR and BOOK.
Types of Relationships:
In E-R model, the most common relationship (with respect to degree of relationships) are:
(1) Binary relationship
(2) Unary relationship
(3) Ternary relationship
(1) Binary Relationship:
A relationship type of degree two is called binary relationship. A binary relationship is a
relationship between the instances of two entity types. It is the most common type of
relationship countered in data modeling.
The binary relationship is further divided into:
a. One-to-one relationship
b. One-to-many relationship
c. Many-to-many relationship
a. One-to-One (1:1) Relationship:
In one-to-one relationship, two entity types are associated in such ft way that for each
instance in First entity type, there is only one matching instance in Second entity type. On the
other hand, for each instance in Second entity type, there is only one matching instance in First
The following examples show one-to-one relationships:
1. Consider the relationship between COUNTRY and CAPITAL entities.
The above relationship shows that a country has only one capital. On the other hand, a capital
belongs to only one country. The sample data is given below.
2. The relationship between PRINCIPAL and COLLEGE entities is given below.
The above relationship shows that a principal runs one college. On the other hand, a college is
run by only one principal.
(b) One-to-Many (1:N) Relationship:
In one-to-many relationship, two entity types are associated in such a way that for each
instance in First entity type, there can be many matching instances in Second entity type. On
the other hand, for each instance in Second entity type, there is only one matching instance in
First entity type. For example, a mother may have many children, but a child can have one-toone mother. In the E-R diagram, Crow's paw
is used to indicate many instances.
The following examples show one-to-many relationships:
1. The relationship between STUDENT and TELEPHONE entities is given below.
The above relationship shows that a student may have many telephone numbers. On the other
hand, a telephone number belongs to only one student.
2. The relationship between DEPARTMENT and TEACHER entities is given below.
The above relationship shows that a department of a college may have many teachers. On the
other hand, a particular teacher belongs to only one department.
c. Many-to-Many (M:N) Relationship:
In many-to-many relationship, two entity types are associated in such a way that for each
instance in First entity type, there can be many matching instances in Second entity type. On
the other hand, for each instance in Second entity type, there can also be many matching
instances in First entity type.
The following examples show many-to-many relationships:
1. The relationship between UNCLE and NEPHEW entities is shown below.
The above relationship shows that an uncle may have many nephews, while a nephew may
have many uncles.
2. The relationship between PATIENT and DOCTOR entities is given below.
The above relationship shows that a patient may be checked by many doctors. On the other
hand, a doctor may check many patients.
3. The relationship between EMPLOYEE and COURSE entities is shown below to track which
training courses each of the employee of an organization has completed. The name of the
relationship is "completes".
The above relationship shows that each employee may have completed more than one course.
On the other hand, each course may be completed by more than one employee. In this way, it
can easily be determined which courses of a particular employee has been completed.
Similarly, it can also be easily determined which employees have completed a particular course.
Associating Attributes with Relationship:
In many-to-many relationship, attributes may also be associated with the relationship. Suppose
date is recorded when an employee of an organization completes any course. The sample data
is given below.
Course Name Date Completed
In the above sample data, the "Date Completed" attribute is not a property of EMPLOYEE and
COURSE entities, since a particular course may be completed on different dates. Therefore,
"Date Completed" is a property of relationship between EMPLOYEE and COURSE. It means
that, there is a "Date Completed" for each instance of an employee and a course. This attribute
is associated with the relationship as shown below.
(2) Unary Relationship:
The relationship between the instances of only one entity type (or participant) is known as
unary relationship. It is also referred to as recursive relationship. This relationship has degree
Like binary relationship, unary relationship is also further divided into:
a. One-to-One relationship
b. One-to-Many relationship
c. Many-to-Many relationship
a. One-to-One Unary Relationship:
The one-to-one unary relationship is represented in the similar way as one-to-one binary
relationship. Some examples are given below to explain the concept of one-to-one unary
1. The recursive one-to-one relationship between the instances of DOCTOR entity type is given
The above relationship shows that a doctor is treated by another doctor. On the other hand, a
doctor treats another doctor.
2. The recursive relationship between the instances of PERSON entity type is given below.
The above relationship shows that a person is married to a person. On the other hand, a person
is married by another person.
b. One-to-Many Unary Relationship:
The one-to-many unary relationship is shown in figure below. This relationship is named as
'Manages' that associates employees of an organization with another employee who is their
c. Many-to-Many Unary Relationship:
The many-to-many unary relationship "Treated-By" is given below. It represents the situation
in which doctors give treatments to other doctors (doctors as patients).
The above relationship shows that a doctor is treated by many other doctors. On the other hand,
a doctor treats many other doctors.
(3) Ternary Relationship:
A ternary relationship is a simultaneous relationship among instances of three entity types.
This type of relationship has degree three. An example of ternary relationship is given below.
The name of relationship is "Supplies". The Supplier supplies Parts to Project.
The above ternary relationship "Supplies" can be read as "A Supplier can supply many Parts to
a particular Project".
Another example of ternary relationship "Teaches" is given below, in which three entities
STUDENT, CLASS and TEACHER are associated with each other.
The above ternary relationship "Teaches" can be read as "Many teachers may teach many
classes with many students".
Cardinalities of Relationship:
In a relational database model, the number of records in a table (or relation) is called
cardinality. However, relationship types usually have certain constraints that limit the number of
instances of one entity type that can be associated with each instance of another related entity
Therefore, cardinality of a relationship is defined as; the number of instances of one entity type
that can be associated with each instance of another related entity type.
Suppose there are two entity types A and B that are connected by a relationship R. If there are
no cardinality constraints on R, then any number of instances of A can be associated with any
number of instances of B. Usually there are cardinality constraints such as:
If there is one-to-one relationship between A and B, then each instance in A will be
associated with exactly one instance in B. Conversely each instance in B will be
associated with exactly one instance in A.
If there is one-to-many relationship between A and B, then each instance in A will be
associated with many instances in B. On the other hand, each instance in B will be
associated with exactly one instance in A.
If there is many-to-many relationship between A and B, then each instance in A will be
associated with many instances in B. On the other hand, each instance in B will also be
associated with many instances in A.
The cardinality of one is denoted by a small vertical line ( | ) on the relationship line, next to the
first entity type or before the second entity type. Similarly, the cardinality of many is denoted by
For example, a department may have many teachers. On the other hand, a teacher belongs to
one department. The relationship between DEPARTMENT and TEACHER is shown below.
Minimum and Maximum Cardinalities:
The minimum number of instances of one entity type that may be associated with each instance
of another related entity type is called minimum cardinality. Similarly, the maximum number of
instances of one entity type that may be associated with each instance of another related entity
type is called maximum cardinalities.
Modality of Relationship:
The modality defines the nature of relationship as either it is optional or mandatory. If the
minimum instance in one entity is zero for an instance of another related entity, then the
relationship is called optional. The optional relationship is denoted by small circle 'O' on the
Similarly, if the minimum instance in one entity is one for an instance of another related entity,
then the relationship is referred to as mandatory. It is denoted by a small vertical line ' | ' on the
relationship line. If minimum and maximum cardinalities are both one, it is known as Mandatory
For example, a relationship between STUDENT and TELEPHONE entities given below, which
shows 'one optional' and 'one mandatory' cardinality.
Figure: One Optional, One Mandatory Cardinality
In the above figure, the following combined symbols are used to represent the cardinality and
After STUDENT entity, the First vertical line represents the cardinality and
second vertical line represents the modality of relationship.
Before TELEPHONE entity, the small circle 'O' represents the zero modality,
while represents the cardinality.
In the relationship STUDENT Has TELEPHONE, each instance of STUDENT entity may be
zero or many associated instances in TELEPHONE entity. On the other hand, each instance of
TELEPHONE belongs to exactly one instance in STUDENT entity.
Figures (a) and (b) are given below that show the relationship between TEACHER and CLASS
entities and recursive relationship of PERSON entity.
Definition - Explanation of Attribute and Types of Attributes - Simple Attribute - Composite
Attribute - Basicsofcomputer.com
A brief description of the above relationships is given below.
1. In the relationship "TEACHER Teaches CLASS", each teacher may teach one or many
classes. On the other hand, each class is taught by only one teacher, i.e. each instance of Class
belongs to exactly one Teacher.
2. In the relationship "PERSON Is Married To PERSON", there is an optional zero or one
cardinality in both directions, since a person may or may not be married.
The notations for relationship cardinalities are shown below.
The Database Terms of Reference (Keys)
Keys are, as their name suggests, a key part of a relational database and a vital part of the
structure of a table. They ensure each record within a table can be uniquely identified by one or
a combination of fields within the table. They help enforce integrity and help identify the
relationship between tables. There are three main types of keys, candidate keys, primary
keys and foreign keys. There is also an alternative key or secondary key that can be used, as
the name suggests, as a secondary or alternative key to the primary key.
A Super key is any combination of fields within a table that uniquely identifies each record within
A candidate is a subset of a super key. A candidate key is a single field or the least combination
of fields that uniquely identifies each record in the table. The least combination of fields
distinguishes a candidate key from a super key. Every table must have at least one candidate
key but at the same time can have several.
As an example we might have a student_id that uniquely identifies the students in a student
table. This would be a candidate key. But in the same table we might have the student’s first
name and last name that also, when combined, uniquely identify the student in a student table.
These would both be candidate keys.
In order to be eligible for a candidate key it must pass certain criteria.
It must contain unique values
It must not contain null values
It contains the minimum number of fields to ensure uniqueness
It must uniquely identify each record in the table
Once your candidate keys have been identified you can now select one to be your primary key
A primary key is a candidate key that is most appropriate to be the main reference key for the
table. As its name suggests, it is the primary key of reference for the table and is used
throughout the database to help establish relationships with other tables. As with any candidate
key the primary key must contain unique values, must never be null and uniquely identify each
record in the table.
As an example, a student id might be a primary key in a student table, a department code in a
table of all departments in an organisation. This module has the code DH3D 35 that is no doubt
used in a database somewhere to identify RDBMS as a unit in a table of modules. In the table
below we have selected the candidate key student_id to be our most appropriate primary key
Primary keys are mandatory for every table each record must have a value for its primary key.
When choosing a primary key from the pool of candidate keys always choose a single simple
key over a composite key.
A foreign key is generally a primary key from one table that appears as a field in another where
the first table has a relationship to the second. In other words, if we had a table A with a primary
key X that linked to a table B where X was a field in B, then X would be a foreign key in B.
An example might be a student table that contains the course_id the student is attending.
Another table lists the courses on offer with course_id being the primary key. The 2 tables are
linked through course_id and as such course_id would be a foreign key in the student table.
Secondary Key or Alternative Key
A table may have one or more choices for the primary key. Collectively these are known as
candidate keys as discuss earlier. One is selected as the primary key. Those not selected are
known as secondary keys or alternative keys.
For example in the table showing candidate keys above we identified two candidate keys,
studentId and firstName + lastName. The studentId would be the most appropriate for a primary
key leaving the other candidate key as secondary or alternative key. It should be noted for the
other key to be candidate keys, we are assuming you will never have a person with the same
first and last name combination. As this is unlikely we might consider fistName+lastName to be
a suspect candidate key as it would be restrictive of the data you might enter. It would seem a
shame to not allow John Smith onto a course just because there was already another John
Any of the keys described before (ie primary, secondary or foreign) may comprise one or more
fields, for example if firstName and lastName was our key this would be a key of two fields
where as studentId is only one. A simple key consists of a single field to uniquely identify a
record. In addition the field in itself cannot be broken down into other fields, for example,
studentId, which uniquely identifies a particular student, is a single field and therefore is a
simple key. No two students would have the same student number.
A compound key consists of more than one field to uniquely identify a record. A compound key
is distinguished from a composite key because each field, which makes up the primary key, is
also a simple key in its own right. An example might be a table that represents the modules a
student is attending. This table has a studentId and a moduleCode as its primary key. Each of
the fields that make up the primary key are simple keys because each represents a unique
reference when identifying a student in one instance and a module in the other.
A composite key consists of more than one field to uniquely identify a record. This differs from a
compound key in that one or more of the attributes, which make up the key, are not simple keys
in their own right. Taking the example from compound key, imagine we identified a student by
their firstName + lastName. In our table representing students on modules our primary key
would now be firstName + lastName + moduleCode. Because firstName + lastName represent
a unique reference to a student, they are not each simple keys, they have to be combined in
order to uniquely identify the student. Therefore the key for this table is a composite key.