Anatomy of a Database Application — Front-End and Back-End

2. Anatomy of a Database Application — Front-End and Back-End

What a database application is. A database application is a piece of software that lets users store, retrieve, update and manage data that is kept in a database. A shop's billing program, a school's admission and marks system, a library's issue-and-return system and an online store are all database applications. What they share is a simple but powerful structure: they are built in two connected parts — a front-end and a back-end.

The front-end. The front-end is the part of the application that the user sees and interacts with — the screens, windows, forms, buttons, text boxes and menus. It is also called the presentation layer or the user interface (UI). Its job is to take input from the user (for example, a customer's name and the item to be billed) and to present output back to the user (for example, the printed bill or a list of records). The front-end does not itself store the data permanently; when it needs to save or fetch data, it passes the request to the back-end.

The back-end. The back-end is the part that stores and manages the data — the database and the database management system (DBMS) that controls it. It is also called the data layer. The user never works with the back-end directly; it works silently behind the front-end, accepting requests (usually written in SQL), performing them on the stored tables, and sending results back. Its job is to keep the data safe, accurate, consistent and available.

Why separate the two? Splitting an application into a front-end and a back-end brings real advantages:

1. Division of work — designers can improve the look and ease of the interface without touching the data, and the data can be re-organised without changing every screen.
2. Shared data, many interfaces — the same back-end database can serve several front-ends (for example, a counter-billing screen and a manager's report screen) using one common store of data.
3. Security — sensitive data is kept in the back-end and reached only through controlled requests, not exposed on the user's screen.
4. Easier maintenance — a fault in the interface is fixed in the front-end; a fault in the data or its rules is fixed in the back-end.

How the two work together — the request cycle. When a user does something on the front-end (say, clicks Save after typing a new customer's details), the following happens:

1. The front-end collects and checks the input.
2. It forms an instruction (usually an SQL statement such as an INSERT).
3. It sends that instruction to the back-end over a connection.
4. The back-end carries out the instruction on the stored tables.
5. The back-end returns a result (success, or the data asked for).
6. The front-end shows the result to the user. …