Types of DBMS Users

Who uses a database?

A database is not used by just one kind of person. Think of a school database: the principal checks reports, the office clerk enters fees, a teacher feeds marks, a programmer built the result software, and someone takes daily backups. Each of them is a DBMS user, but each uses the database in a very different way.

1. Database Administrator (DBA)

The DBA is in overall charge of the database. In the school example, the DBA is the person who keeps the whole system running safely.

• Creates user accounts and decides who can see or change what.
• Grants and revokes permissions with commands such as GRANT and REVOKE.
• Takes backups and recovers data after a crash or a mistake.
• Monitors performance — adds indexes, fixes slow queries.
• Keeps the database secure and up to date.

-- A DBA giving a clerk read-only access to the fees table
GRANT SELECT ON school.fees TO 'clerk'@'localhost';

2. Database designers

Database designers decide what data will be stored and how it is organised — before any data is entered. They talk to the users, then design the tables, keys and relationships (often using an ER diagram) and apply normalization.

Example: deciding that the school needs students, classes and fees tables, with roll_no as the primary key.

3. System analysts

System analysts study what the end users actually need and write clear requirements — for example, "the clerk must print a fee receipt in one click". Designers and programmers then build the system from these requirements.

4. Application programmers

Application programmers (developers) write the programs, forms and reports that other people use. They connect to the database from languages like PHP, Java or Python and run SQL from their code.

// A PHP programmer reading a student's result
$stmt = $pdo->prepare("SELECT name, total FROM results WHERE roll_no = ?");
$stmt->execute([$roll]);

The programmer never needs to type queries by hand for every request — the finished application does that for the end user.

5. End users and their types

End users use the database to do their daily work. There are four kinds:

• Naive (parametric) users — use only ready-made screens and buttons. They never write queries. Example: the school clerk entering fees, a bank cashier, a railway ticket clerk.
• Casual users — use the database occasionally and may need different information each time. Example: the principal who sometimes asks for a special report.
• Sophisticated users — know SQL well and write their own queries. Example: a data analyst, an engineer or a researcher.
• Standalone users — keep a small personal database using a ready-made package. Example: a teacher keeping marks in a personal app or a small LibreOffice Base file.

Workers behind the scene

Some people never use your database directly, but make the DBMS itself possible:

• DBMS designers and implementers — build the DBMS software itself (for example, the MySQL team).
• Tool developers — make tools such as backup, design or reporting software.
• Operators and maintenance staff — run and maintain the hardware and software.

Try it: one MySQL account per kind of user

In a real school system the DBA does not give everyone the root password. Each kind of user gets its own account with only the permissions it needs (the principle of least privilege). Run these commands as the DBA (root):

CREATE USER 'dev_app'@'localhost' IDENTIFIED BY 'Dev#2026pass';
CREATE USER 'clerk'@'localhost'   IDENTIFIED BY 'Clerk#2026pass';
CREATE USER 'analyst'@'localhost' IDENTIFIED BY 'Ana#2026pass';

GRANT SELECT, INSERT, UPDATE, DELETE ON school.* TO 'dev_app'@'localhost';  -- application programmer's app
GRANT SELECT, INSERT ON school.fees TO 'clerk'@'localhost';                -- naive user (fee screen)
GRANT SELECT ON school.* TO 'analyst'@'localhost';                         -- sophisticated user: read-only

SHOW GRANTS FOR 'clerk'@'localhost';

Now log in as clerk and try something the clerk is not allowed to do:

-- logged in as clerk
DELETE FROM school.fees WHERE roll_no = 2;
SELECT * FROM school.students;

The clerk can add and view fees but cannot delete them or see student records. If the clerk leaves the job, the DBA runs DROP USER 'clerk'@'localhost'; – no other account is affected.

Tested on MariaDB 10.11 (MySQL-compatible). MySQL 8 gives the same permissions and errors; its SHOW GRANTS output does not print the password hash. Read more: GRANT and REVOKE.

Quick comparison table

Common mistakes

• Calling the application programmer an "end user" — the programmer builds the app; the end user uses it.
• Mixing up naive and casual users — naive users repeat the same task daily through fixed screens; casual users ask for different information occasionally.
• Thinking only big companies have a DBA — in a small school, one person often does the DBA, designer and programmer jobs together.

Summary

DBMS users are the DBA, database designers, system analysts, application programmers and end users (naive, casual, sophisticated and standalone). Next, read the advantages and limitations of DBMS or see how a DBA uses GRANT and REVOKE.