https://www.careerbless.com/db/rdbms/c1/datamodels.

php

https://www.tutorialcup.com/dbms/file-processing-system.htm

DBMS
Traditional Approach for Data Storage and the Need of DBMS

Traditional Data Storage Model

1. In traditional approach, information is stored in flat files which are

maintained by the file system under the operating system’s control.

2. Application programs go through the file system in order to access these flat
files

How data is stored in flat files

• Data is stored in flat files as records.

• Records consist of various fields which are delimited by a space, comma,

pipe, any special character etc.

• End of records and end of files will be marked using any predetermined
character set or special characters in order to identify them.

Example:  Storing employee data in flat files

Problems with traditional approach for storing data

Disadvantages of file processing

File processing system is good when there is only limited number of files and data in are very less. As the data
and files in the system grow, handling them becomes difficult.

1. Data Mapping and Access: - Although all the related informations are
grouped and stored in different files, there is no mapping between any
two files. i.e.; any two dependent files are not linked. Even though
Student files and Student_Report files are related, they are two different
files and they are not linked by any means. Hence if we need to display
student details along with his report, we cannot directly pick from those
two files. We have to write a lengthy program to search Student file first,
get all details, then go Student_Report file and search for his report.

When there is very huge amount of data, it is always a time consuming

task to search for particular information from the file system. It is always
an inefficient method to search for the data.

2. Data Redundancy: - There are no methods to validate the insertion of

duplicate data in file system. Any user can enter any data. File system
does not validate for the kind of data being entered nor does it validate
for previous existence of the same data in the same file. Duplicate data
in the system is not appreciated as it is a waste of space, and always
lead to confusion and mishandling of data. When there are duplicate
data in the file, and if we need to update or delete the record, we might
end up in updating/deleting one of the record, leaving the other record in
the file. Again the file system does not validate this process. Hence the
purpose of storing the data is lost.
 Though the file name says Student file, there is a chance of entering
staff information or his report information in the file. File system allows
any information to be entered into any file. It does not isolate the data
being entered from the group it belongs to.

3. Data Dependence: - In the files, data are stored in specific format, say
tab, comma or semicolon. If the format of any of the file is changed, then
the program for processing this file needs to be changed. But there
would be many programs dependent on this file. We need to know in
advance all the programs which are using this file and change in the
entire place. Missing to change in any one place will fail whole
application.  Similarly, changes in storage structure, or accessing the
data, affect all the places where this file is being used. We have to
change it entire programs. That is smallest change in the file affect all
the programs and need changes in all them.
4. Data inconsistency: - Imagine Student and Student_Report files have
student’s address in it, and there was a change request for one particular
student’s address. The program searched only Student file for the
address and it updated it correctly. There is another program which
prints the student’s report and mails it to the address mentioned in the
Student_Report file. What happens to the report of a student whose
address is being changed? There is a mismatch in the actual address
and his report is sent to his old address. This mismatch in different
copies of same data is called data inconsistency. This has occurred
here, because there is no proper listing of files which has same copies of
data.
5. Data Isolation: - Imagine we have to generate a single report of student,
who is studying in particular class, his study report, his library book
details, and hostel information. All these informations are stored in
different files. How do we get all these details in one report? We have to
write a program. But before writing the program, the programmer should
find out which all files have the information needed, what is the format of
each file, how to search data in each file etc. Once all these analysis is
done, he writes a program. If there is 2-3 files involved, programming
would be bit simple. Imagine if there is lot many files involved in it? It
would be require lot of effort from the programmer. Since all the datas
are isolated from each other in different files, programming becomes
difficult.
6. Security: - Each file can be password protected. But what if have to give
access to only few records in the file? For example, user has to be given
access to view only their bank account information in the file. This is very
difficult in the file system.
 7. Integrity: - If we need to check for certain insertion criteria while entering
the data into file it is not possible directly. We can do it writing programs.
Say, if we have to restrict the students above age 18, then it is by means
of program alone. There is no direct checking facility in the file system.
Hence these kinds of integrity checks are not easy in file system.
8. Atomicity: - If there is any failure to insert, update or delete in the file
system, there is no mechanism to switch back to the previous state.
Imagine marks for one particular subject needs to be entered into the
Report file and then total needs to be calculated. But after entering the
new marks, file is closed without saving. That means, whole of the
required transaction is not performed. Only the totaling of marks has
been done, but addition of marks not being done. The total mark
calculated is wrong in this case. Atomicity refers to completion of whole
transaction or not completing it at all. Partial completion of any
transaction leads to incorrect data in the system. File system does not
guarantee the atomicity. It may be possible with complex programs, but
introduce for each of transaction costs money.
9. Concurrent Access: - Accessing the same data from the same file is
called concurrent access. In the file system, concurrent access leads to
incorrect data. For example, a student wants to borrow a book from the
library. He searches for the book in the library file and sees that only one
copy is available. At the same time another student also, wants to
borrow same book and checks that one copy available. First student opt
for borrow and gets the book. But it is still not updated to zero copy in the
file and the second student also opt for borrow! But there are no books
available. This is the problem of concurrent access in the file system.

To overcome all drawbacks of file processing system, a new system called

database system is developed.

All the files in the file processing system are known as tables in the database.

The contents of files form records of the table.

In database, each of column values are known as attribute and each row of
information is known as record.

There no difference in the data being stored. But it is different from the file
system by the way data is stored and accessed in the database.
In the database, each set of information is stored in the form of rows and
columns.

We define a unique key column for each record known as primary key.

Using primary key, we can access the data much faster than file system. We can
also define a mapping between any two related tables. This helps in reducing
unnecessary data storage and faster retrieval of data.

Advantages of DBMS

DBMS is developed to cover the drawbacks of the traditional file system.

1. Data Mapping and Access: - DBMS defines the way to map any
two related tables by means of primary key –foreign key
relationship. Primary key is the column in the table which
responsible for uniquely identifying each record in the table.
Foreign key is the column in the table which is a primary key in
other table and with which the entries in the current table are
related to other table.

For example, in the new database system, we can Student and

Student_Report table as follows.

STUDENT_ID is the unique using which we can identify each

student and hence it forms a primary key in STUDENT table.
Similarly, REPORT_ID is the primary key in the
STUDENT_REPORT table. STUDENT_ID in the
STUDENT_REPORT table is the foreign key. It links STUDENT
and STUDENT_REPORT tables.
 Because of such mapping, it becomes each for the programmer to
search for related tables, join them, and fire the query as per the
requirement. This reduces the time consumed while searching and
mapping these tables. Even when there is large amount of data, the
time consumed to retrieve, insert, update or delete is very less.
Hence there is no data isolation in the system.

Note: Mapping of tables is usually done when they are created.

2. Data Redundancy: - By the introduction of primary key in the table,

data redundancy problem is reduced to great extent. As we saw,
primary key is the unique column for each record, when there is a
re-entry of same record, it does not allow saving such records.

DBMS has strong designing techniques like normalization which

makes sure the same copy of data is not stored in same table or in
multiple tables. It makes sure all the informations are stored only
once in the database tables.

We can see the difference in the way data is being stored in the file
and database system. Primary key, foreign keys are defined;
unnecessary columns are removed from the STUDENT_REPORT
table in the database system. These are missing in the file
processing system.

3. Data Independence and Consistency: - DBMS defines a

standard to represent the data in the form of rows and columns. It
also stores the information about the tables, columns, keys, storage
space, used space, available space etc separately from the logical
data. Hence they totally independent of the way they are stored and
the data being stored. Any changes to the physical storage (like
 disks, tapes etc) or structure, does not harm the data being stored.
Since DBMS defines each columns and rows at the beginning itself
and controls the way data being entered, there is no affect on the
programs or any other tables or data. Hence the consistency of the
data also maintained.

If there is a change in the address of any student, we just have to

update it in the Student table. There is no other place his
information is being stored. Hence it maintains the consistent data
in the database.

Suppose there is a new column addition to STUDENT table, say

DOB. This will change the metadata to reflect additional column in
the table structure. It will hardly affect the application unless until
there is a new requirement to have transaction with DOB. Hence
data independence is also assured in the database.

4. Security: - DBMS allows different levels of access to different

users based on their roles. In the school database, individual
students will have access to their data alone, while their teachers
will have access to all the students whom they are teaching and for
the subjects that they are teaching. Class teacher will be able to
see the reports of all the students in that class, but not other
classes.

Similarly, in a banking system, individual account holder will have

Read-Only access to their account. While accountant can update,
individual account details for each of their transaction.

All these levels of security and access are not allowed in file
system.

5. Integrity: - DBMS allows having restrictions on individual columns.

It would be defined while designing the table itself. If we want to
enter salary of an employee within the range 10000 to 40000, we
can impose this while designing the table by using CHECK
constraint. When salary is entered, it will automatically check for the
range specified.
 CREATE TABLE EMPLOYEE ……….. CONSTRAINT chk_salary
CHECK (salary>10000 AND salary <40000)

6. Atomicity: - DBMS makes sure either the transaction is fully

complete or it is rolled back to the previous committed state. It does
not allow the system to be in a partially committed state. In our
example above, DBMS commits marks change transaction before
calculating the total. If there is any crash or shutdown of the
system, before committing the marks, then updated marks will be
rolled back to the original marks. Hence it makes sure atomicity of
the transaction is achieved.
7. Concurrent Access: - DBMS provide access to multiple users to
access the database at the same time. It has its own mechanism to
have concurrency accesses and hence avoid any incorrect data in
the system.

Disadvantages of DBMS

1. It is bit complex. Since it supports multiple functionality to give the

user the best, the underlying software has become complex. The
designers and developers should have thorough knowledge about
the software to get the most out of it.
2. Because of its complexity and functionality, it uses large amount of
memory. It also needs large memory to run efficiently.
3. DBMS system works on the centralized system, i.e.; all the users
from all over the world access this database. Hence any failure of
the DBMS, will impact all the users.
4. DBMS is generalized software, i.e.; it is written work on the entire
systems rather specific one. Hence some of the application will run
slow.

Introduction to Database Technology and DBMS

What is Database?
 Database is a computer based record keeping system which is used to
record ,maintain and retrieve data.It is an organized collection of interrelated
(persistent) data.

What is Database Management System (DBMS)?

A Database Management System (DBMS) is a collection of interrelated files

and set of programs which allows users to access and modify files. It provides
a convenient and efficient way to store, retrieve and modify information.
Application programs request DBMS to retrieve, modify/insert/delete data for
them and thus it acts as a layer of abstraction between the application
programs and the file system.

 DBMS acts as a layer of abstraction on top of the File system.

 For interacting with the DBMS we use a Query language called
Structured Query Language (SQL)
General Block Diagram

Difference Between File based Data Storage System and DBMS

Types of Databases

1. Centralized Database

In Centralized database system, all data is stored at a single site. It offers a

great control in accessing and updating data. However failure chances are high
because the system depends on the availability of resources at the central site

Example: Think about a banking application which uses centralized database.

In this case the data is stored in a common place. Applications running in
various banks may communicate to the common database over network to
access or insert/update/delete information.
2. Distributed Database

In Distributed Database system, the database is stored on several computers.

Computers in a distributed system may communicate with one another
through internet/intranet/telephone lines etc. Most of the distributed systems
will be geographically separated and managed. Distributed databases can also
separately be administered

Example: Think about a banking application which uses distributed database.

Bank's head office may be in India where as branch offices may be in United
States and United Kingdom. In this case the bank database can be distributed
across the branch offices and head office whereas the individual offices are
connected through a network.
 Services provided by a DBMS

1. Data management
2. Data definition
3. Transaction support
4. Concurrency control
5. Recovery
6. Security and integrity
7. Facilities to import and export data
8. user management
9. backup
10. performance analysis
11. logging
12. audit
13. physical storage control
View of Data : Database Abstraction
Database is full of datas and records.
What we see in rows and columns is quite different when it reaches the
memory. When they are stored in the memory like disks or tapes, they are
stored in the form of bits. But any users will not understand these bits. He
needs to see the actual data to understand.
But all the details about the data stored in the memory are not necessary
for the users. He needs only little information that he is interested or wants
to work with.
Masking the unwanted data from the users happens at different levels in
the database. This masking of data is called data abstraction. There are 4
levels of data abstraction.

 External level - This is the highest level in data abstraction. At this

level users see the data in the form of rows and columns. This level
illustrates the users how the data is stored in terms of tables and
relations.
 Users view full or partial data based on the business
requirement. The users will have different views here, based on
their levels of access rights.
 For example, student will not have access to see Lecturers
salary details, one employee will not have access to see other
employees details, unless he is a manager.
 At this level, one can access the data from database and
perform some calculations based on the data. For example
calculate the tax from the salary of employee, calculate CGPA
of a Student, Calculate age of a person from his Date of Birth
etc. These users can be real users or any programs.

Any changes/ computations done at this level will not affect other
levels of data. That means, if we retrieve the few columns of the
STUDENT table, it will not change the whole table, or if we calculate
the CGPA of a Student, it will not change/update the table. This level
of data is based on the below levels, but it will not alter the data at
below levels.
 Logical/ Conceptual level – 
 This is the next level of abstraction. It describes the actual data
stored in the database in the form of tables and relates them by
means of mapping.
 This level will not have any information on what a user views at
external level. This level will have all the data in the database.

Any changes done in this level will not affect the external or physical
levels of data. That is any changes to the table structure or the
relation will not modify the data that the user is viewing at the external
view or the storage at the physical level. For example, suppose we
have added a new column ‘skills’ which will not modify the external
view data on which the user was viewing Ages of the students.
Similarly, it will have space allocated for ‘Skills’ in the physical
memory, but it will not modify the space or address of Date of Birth
(using which Age will be derived) in the memory. Hence external and
physical independence is achieved.

 Internal level - This is one of the intermediary levels. In most of the

cases this level is not mentioned and usually it is said that we have
3 levels of data abstraction. This level depends on the DBMS
software. This level is how the database is seen from DBMS. We
can even combine logical level and this level.
 Physical level - This is the lowest level in data abstraction. This
level describes how the data is actually stored in the physical
memory like magnetic tapes, hard disks etc. In this level the file
organization methods like hashing, sequential, B+ tree comes into
picture. At this level, developer would know the requirement, size
and accessing frequency of the records clearly. So designing this
level will not be much complex for him.
Three layer Architecture

Detailed System Architecture

 The external view is how the use views it.
 The Conceptual view is how the DBA views it.
 The Internal view is how the data is actually stored.
An example of the three levels
Architecture of Database
Database architecture can be 2-tier or 3 tier architecture based on how users are connected to the database to
get their request done.

2-tier Architecture
In 2-tier architecture, application program directly interacts with the database. There will not be any user
interface or the user involved with database interaction. Imagine a front end application of School, where we
need to display the reports of all the students who are opted for different subjects. In this case, the application
will directly interact with the database and retreive all required data. Here no inputs from the user are required.
This involves 2-tier architecture of the database.

Let us consider another example of two tier architecture. Consider a railway ticket reservation system. How
does this work? Imagine a person is reserving the ticket from Delhi to Goa on particular day. At the same time
another person in some other place of Delhi is also reserving the ticket to Goa on the same day for the same
train. Now there is a requirement for two tickets, but for different persons. What will reservation system do? It
takes the request from both of them, and queues the requests entered by each of them. Here the request
entered to application layer and request is sent to database layer. Once the request is processed in database,
the result is sent back to application layer for the user.

Advan
tages of 2-tier Architecture
 Easy to understand as it directly communicates with the database.
 Requested data can be retrieved very quickly, when there is less number of users.
 Easy to modify – any changes required, directly requests can be sent to database
 Easy to maintain – When there are multiple requests, it will be handled in a queue and there will not be
any chaos.

Disadvantages of 2-tier architecture:

 It would be time consuming, when there is huge number of users. All the requests will be queued and
handed one after another. Hence it will not respond to multiple users at the same time.
 This architecture would little cost effective.

3-tier Architecture
3-tier architecture is the most widely used database architecture. It can be viewed as below.

 Presentation layer / User layer is the layer where user uses the database. He does not have any
knowledge about underlying database. He simply interacts with the database as though he has all
data in front of him. You can imagine this layer as a registration form where you will be inputting
your details.  Did you ever guessed, after pressing ‘submit’ button where the data goes? No right?
You just know that your details are saved. This is the presentation layer where all the details from
the user are taken, sent to the next layer for processing.
 Application layer is the underlying program which is responsible for saving the details that you have
entered, and retrieving your details to show up in the page. This layer has all the business logics
like validation, calculations and manipulations of data, and then sends the requests to database to
get the actual data. If this layer sees that the request is invalid, it sends back the message to
presentation layer.  It will not hit the database layer at all.
 Data layer or Database layer is the layer where actual database resides. In this layer, all the tables,
their mappings and the actual data present. When you save you details from the front end, it will be
inserted into the respective tables in the database layer, by using the programs in the application
layer. When you want to view your details in the web browser, a request is sent to database layer
by application layer. The database layer fires queries and gets the data. These data are then
transferred to the browser (presentation layer) by the programs in the application layer.

Advantages of 3-tier architecture:

 Easy to maintain and modify. Any changes requested will not affect any other data in the database.
Application layer will do all the validations.
 Improved security. Since there is no direct access to the database, data security is increased. There is
no fear of mishandling the data. Application layer filters out all the malicious actions.
 Good performance. Since this architecture cache the data once retrieved, there is no need to hit the
database for each request. This reduces the time consumed for multiple requests and hence
enables the system to respond at the same time.

Disadvantages 3-tier Architecture

Disadvantages of 3-tier architecture are that it is little more complex and little more effort is required in terms of
hitting the database.

Advantages of a DBMS
1. Data independence
2. Reduced data redundancy
3. Increased security
4. Better flexibility
5. Effective data sharing
6. Enforces integrity constraints
7. Enables backup and recovery

Relational data model

In relational data model, data exists in two dimensional tables known as

relations. A relation (table) consists of unique attributes (columns) and tuples
(rows).

Sometimes the value to be inserted into a particular cell will be unknown, or it

will not have any value. This is represented by a null. Please note that null is
not the same as zero, blank or an empty string

A database whose logical organization is based on relational data model is

a Relational Database

A DBMS that manages the relational database is known as RDBMS

Conceptual Database Design - Entity Relationship(ER) Modeling

What is ER Modeling?

A graphical technique for understanding and organizing the data independent

of the actual database implementation

We need to be familiar with the following terms to go further.

Entity

Any thing that has an independent existence and about which we collect data.
It is also known as entity type.

In ER modeling, notation for entity is given below.

Entity instance

Entity instance is a particular member of the entity type.

Example for entity instance : A particular employee

Regular Entity

An entity which has its own key attribute is a regular entity.

Example for regular entity : Employee.

Weak entity

An entity which depends on other entity for its existence and doesn't have any
key attribute of its own is a weak entity.

Example for a weak entity : In a parent/child relationship, a parent is

considered as a strong entity and the child is a weak entity.

In ER modeling, notation for weak entity is given below.

Attributes

Properties/characteristics which describe entities are called attributes.

In ER modeling, notation for attribute is given below.

Domain of Attributes

The set of possible values that an attribute can take is called the domain of the
attribute. For example, the attribute day may take any value from the set
{Monday, Tuesday ... Friday}. Hence this set can be termed as the domain of
the attribute day.

Key attribute

The attribute (or combination of attributes) which is unique for every entity
instance is called key attribute.

E.g the employee_id of an employee, pan_card_number of a person etc.If the

key attribute consists of two or more attributes in combination, it is called a
composite key.

In ER modeling, notation for key attribute is given below.

Simple attribute

If an attribute cannot be divided into simpler components, it is a simple

attribute.

Example for simple attribute :employee_id of an employee.

Composite attribute

If an attribute can be split into components, it is called a composite attribute.

Example for composite attribute : Name of the employee which can be split
into First_name, Middle_name, and Last_name.

Single valued Attributes

If an attribute can take only a single value for each entity instance, it is a single
valued attribute.

example for single valued attribute : age of a student. It can take only one
value for a particular student.

Multi-valued Attributes

If an attribute can take more than one value for each entity instance, it is a
multi-valued attribute. Multi-valued

example for multi valued attribute : telephone number of an employee, a

particular employee may have multiple telephone numbers.

In ER modeling, notation for multi-valued attribute is given below.

Stored Attribute

An attribute which need to be stored permanently is a stored attribute

Example for stored attribute : name of a student

Derived Attribute

An attribute which can be calculated or derived based on other attributes is a

derived attribute.

Example for derived attribute : age of employee which can be calculated from
date of birth and current date.

In ER modeling, notation for derived attribute is given below.

Relationships

Associations between entities are called relationships

Example : An employee works for an organization. Here "works for" is a

relation between the entities employee and organization.

In ER modeling, notation for relationship is given below.

However in ER Modeling, To connect a weak Entity with others, you should

use a weak relationship notation as given below

Degree of a Relationship
Degree of a relationship is the number of entity types involved. The n-ary
relationship is the general form for degree n. Special cases are unary, binary,
and ternary ,where the degree is 1, 2, and 3, respectively.

Example for unary relationship : An employee ia a manager of another

employee

Example for binary relationship : An employee works-for department.

Example for ternary relationship : customer purchase item from a shop keeper

Cardinality of a Relationship

Relationship cardinalities specify how many of each entity type is allowed.

Relationships can have four possible connectivities as given below.

1. One to one (1:1) relationship

2. One to many (1:N) relationship

3. Many to one (M:1) relationship

4. Many to many (M:N) relationship

The minimum and maximum values of this connectivity is called the

cardinality of the relationship

Example for Cardinality – One-to-One (1:1)

Employee is assigned with a parking space.

One employee is assigned with only one parking space and one parking space
is assigned to only one employee. Hence it is a 1:1 relationship and cardinality
is One-To-One (1:1)

In ER modeling, this can be mentioned using notations as given below

Example for Cardinality – One-to-Many (1:N)

Organization has employees

One organization can have many employees , but one employee works in only
one organization. Hence it is a 1:N relationship and cardinality is One-To-
Many (1:N)

In ER modeling, this can be mentioned using notations as given below

Example for Cardinality – Many-to-One (M :1)

It is the reverse of the One to Many relationship. employee works in
organization

One employee works in only one organization But one organization can have
many employees. Hence it is a M:1 relationship and cardinality is Many-to-
One (M :1)

In ER modeling, this can be mentioned using notations as given below.

Cardinality – Many-to-Many (M:N)

Students enrolls for courses

One student can enroll for many courses and one course can be enrolled by
many students. Hence it is a M:N relationship and cardinality is Many-to-
Many (M:N)

In ER modeling, this can be mentioned using notations as given below

Relationship Participation

1. Total

In total participation, every entity instance will be connected through the

relationship to another instance of the other participating entity types

2. Partial

Example for relationship participation

Consider the relationship - Employee is head of the department.

Here all employees will not be the head of the department. Only one employee
will be the head of the department. In other words, only few instances of
employee entity participate in the  above relationship. So employee entity's
participation is partial in the said relationship.

However each department will be headed by some employee. So department 

entity's participation is total in the said relationship.

Advantages and Disadvantages of ER Modeling ( Merits and Demerits of ER

Modeling )

Advantages

1. ER Modeling is simple and easily understandable. It is represented in

business users language and it can be understood by non-technical specialist.

2. Intuitive and helps in Physical Database creation.

3. Can be generalized and specialized based on needs.

4. Can help in database design.

5. Gives a higher level description of the system.

Disadvantages

1. Physical design derived from E-R Model may have some amount of
ambiguities or inconsistency.

2. Sometime diagrams may lead to misinterpretations

Entity Relationship (ER) Modeling - Learn with a Complete Example

Prerequisite :Basic knowledge about ER Modeling. It is recommened to read

the previous topic if you have not done so before proceeding further.

Here we are going to design an Entity Relationship (ER) model for a college
database . Say we have the following statements.

1. A college contains many departments

2. Each department can offer any number of courses
3. Many instructors can work in a department
4. An instructor can work only in one department
5. For each department there is a Head
6. An instructor can be head of only one department
7. Each instructor can take any number of courses
8. A course can be taken by only one instructor
9. A student can enroll for any number of courses
10. Each course can have any number of students
Good to go. Let's start our design.(Remember our previous topic and the
notations we have used for entities, attributes, relations etc )

Step 1 : Identify the Entities

What are the entities here?

From the statements given, the entities are

1. Department
2. Course
3. Instructor
4. Student
Stem 2 : Identify the relationships

1. One department offers many courses. But one particular course can be
offered by only one department. hence the cardinality between department
and course is One to Many (1:N)
2. One department has multiple instructors . But instructor belongs to only
one department. Hence the cardinality between department and instructor
is One to Many (1:N)
3. One department has only one head and one head can be the head of only
one department. Hence the cardinality is one to one. (1:1)
4. One course can be enrolled by many students and one student can enroll
for many courses. Hence the cardinality between course and student is
Many to Many (M:N)
5. One course is taught by only one instructor. But one instructor teaches
many courses. Hence the cardinality between course and instructor is Many
to One (N :1)
Step 3: Identify the key attributes

 "Departmen_Name" can identify a department uniquely. Hence

Department_Name is the key attribute for the Entity "Department".
 Course_ID is the key attribute for "Course" Entity.
 Student_ID is the key attribute for "Student" Entity.
 Instructor_ID is the key attribute for "Instructor" Entity.
Step 4: Identify other relevant attributes

 For the department entity, other attributes are location

 For course entity, other attributes are course_name,duration
 For instructor entity, other attributes are first_name, last_name, phone
 For student entity, first_name, last_name, phone
Step 5: Draw complete ER diagram
By connecting all these details, we can now draw ER diagram as given below.