Top Viva Questions for a DBMS / Management System Project (with Answers)

Give a two or three sentence summary: what the system does, who uses it, and its main features. For example: “It is a management system where an admin can manage records and perform the core operations of the business, with a secure login and a dashboard. It is built with a database to store all the data and a web or desktop interface to work with it.”

Give a practical reason: it solves a real problem (replacing manual or paper-based work), it covers important concepts you wanted to demonstrate (database design, CRUD, authentication), and it is a realistic system that mirrors how actual organizations work.

Name your stack and give a reason for each part. For example: “I used PHP for the server-side logic because it is widely used and well suited to web applications, MySQL for the database because it is reliable and free, and HTML/CSS/JavaScript for the interface.” For a desktop project, mention your language, UI framework, and database similarly.

List your core features clearly, for example record management (add, view, edit, delete), a login system, search, and reports or a dashboard. Being able to list them shows you understand the scope of what you built.

Most projects have at least an admin who manages everything. Some also have a regular user with limited access. Explain what each role can do, this shows you thought about access and permissions.

Examiners love this question, and honesty impresses. Mention a real limitation (no online payment, single admin, no mobile app) and a sensible improvement (add reporting, add user roles, add email notifications). It shows mature thinking.

Describe your tables and how they relate. For example: “I have a table for each main entity, and the tables are linked by foreign keys. For instance, an orders table references the customer who placed the order.” Being able to walk through your own schema is the single most important viva skill.

A primary key is a column that uniquely identifies each row in a table, so no two rows have the same value and it is never empty. In most projects it is an auto-incrementing id column on each table.

A foreign key is a column in one table that refers to the primary key of another table, creating a link between them. For example, a customer_id column in an orders table that points to the id in the customers table. Foreign keys are how relationships between tables are represented.

Normalization is organizing tables to reduce duplicate data and keep data consistent, by splitting information into related tables instead of repeating it. For example, storing customers in one table and their orders in another, linked by an id, rather than repeating customer details on every order. Most student projects are normalized to a basic, sensible level, which is enough to explain.

Both ensure values do not repeat. The difference: a table has only one primary key and it can never be empty (null), while a table can have several unique keys and a unique column can sometimes be empty. The primary key is the main identifier of the row.

A relationship is a link between tables. The common types are one-to-many (one customer has many orders) and many-to-many (students and courses, resolved with a linking table). Point to a real example in your own schema, for instance “one user can have many records, so it is a one-to-many relationship.”

A database stores data in a structured, searchable way, handles relationships between data, prevents duplication, and lets many operations run reliably. Files would make searching, updating, and relating data far harder. This shows you understand why a DBMS exists.

SQL (Structured Query Language) is the language used to work with data in a relational database, creating tables, and inserting, reading, updating, and deleting data.

The core four for working with data are INSERT (add a row), SELECT (read rows), UPDATE (change rows), and DELETE (remove rows). These four are exactly the create, read, update, and delete operations of your project.

A JOIN combines rows from two or more tables based on a related column, so you can pull connected data together, for example showing an order with the customer’s name by joining the orders and customers tables. If your project shows data from more than one table on a single screen, you used a join.

WHERE filters individual rows before grouping. HAVING filters groups after a GROUP BY, for example “only show products with total sales above 100.” In simple projects you mostly use WHERE.

DELETE removes specific rows (and can be undone within a transaction). TRUNCATE removes all rows from a table quickly but keeps the table. DROP removes the entire table, structure and all. They go from least to most destructive.

By using a primary key or a unique constraint on the column that should not repeat, the database then refuses duplicate values. You can also check in code before inserting.

Explain the flow: the user enters a username and password, the system checks them against the stored user record, and if they match it creates a session that keeps the user logged in across pages. Mention that passwords should be stored hashed, not as plain text, if your project does this, say so, it impresses.

A session is how the server remembers a user across multiple pages after they log in. Without it, the system would forget who you are on every page. Sessions are what keep a logged-in user logged in and protect pages that require login.

Mention the protections you used: a login to restrict access, hashed passwords, and using parameterized queries or prepared statements to prevent SQL injection. Even naming these shows security awareness, which examiners value highly.

SQL injection is an attack where a user types malicious input that changes your SQL query to do something unintended, like bypassing a login. You prevent it by using prepared statements (parameterized queries) so user input is treated strictly as data, never as part of the SQL command. This is one of the most valuable things to be able to explain.

Walk through it: the user fills a form and submits it, the data is sent to the server, the server runs an INSERT query to save it in the database, and the page then shows the updated list. Knowing this end-to-end flow for one feature proves you understand how your project works.

If your project has search, explain that it takes the user’s keyword and runs a SELECT query with a WHERE clause (often using LIKE for partial matches) to find matching rows, then displays them. If you do not have search, this is a great improvement to mention.

The honest and confident answer is to show understanding. Even if you started from a template or sample, focus on what you understand and what you changed or added. The whole point of preparing with questions like these is that you can genuinely explain your project, which is what “building it yourself” really means in a viva.

The frontend is what the user sees and interacts with (the pages, forms, and buttons, made with HTML, CSS, and JavaScript in a web project). The backend is the server-side logic and database that process and store data (PHP and MySQL, for example). Explain which parts of your project are which.

Yes, because the data lives in a database that handles multiple connections, and each logged-in user has their own session. This is one reason a database is used instead of files.

Sensible answers: add indexes to speed up searches, paginate long lists instead of loading everything at once, and archive old data. You do not need deep detail, just show you have thought about it.

The data is stored in the database, not in the application, so it stays safe even when the app or browser is closed. The application only reads from and writes to the database; it does not hold the data itself.