Architecture of a DBMS

There are 2 levels of architecture in a DBMS, the logical level, and the physical level. The logical level deals with how the user interacts and perceives the DBMS, and does not concert itself with the actual (physical) processing and storing of data, processing the queries, and managing users, permissions etc..

The logical architecture
The logical architecture provides a level of abstraction between the end user and the physical storage of the data. This allows the end user to manipulate the data without being concerned with how and where the data is stored. The logical architecture is mostly based on the ANSI/SPARC generalized DBMS architecture. This standardized model divides the DBMS in 3, the internal, the conceptual, and the external level. The internal level (or physical) is how the files are stored on the secondary storage. The conceptual level brings the whole of the database into a single entity, showing the entirety of the data in the database. This level also provides data definition (metadata). The last level, the external level is the level with which the end user interacts, which allows the user to see the data relevant to them.

The physical DBMS architecture

The physical DBMS architecture is the software components used to enter and process the data. Unlike the logical architecture, which uses the ansi/sparc architecture, the physical architecture does not have a standardized architecture. There are, however, a number of functions that are standard, and that appear in all DBMS. The physical DBMS architecture is usually separated into two, the front end, with which the user actually interacts, and the back end, which actually manages the database itself. The front end, is, in a separate application that gives the user an interface and that interacts with the back end throught it’s API (application programming interface).
Since the front end is completely separated from the back end, and interacts with it through it’s API, it is possible to change the front end without changing the underlying DBMS. Because of this the front end can come from the DBMS vendor, or a third party, and separate systems can be used to do various specialized tasks, such as backups, restores, etc…
The back end can be seen as more of the heart of the dbms. We can further subdibide this in 3 main parts. First, the API, which as mentioned above allows the front end to interact with the back end. Then, there is the Qeury language processor, which receives and interprets the queries sent by the user, so that the third part, the DBMS engine can respond to it. The DBMS engine can be seen as the core of the DBMS. It is the part which is responsible for all the data management in for the DBMS.

Some DBMS systems include, some commercial application such as Microsoft SQL Server, or Oracle, but also include free alternatives, such as MySQL, SQLite, or ProstgreSQL

Sources/further reading
http://www.dbmaker.com.tw/reference/manuals/tutorial/tutorial_03.html
http://yaddarabullah.blogspot.com/2008/07/rdbms-architecture-of-database.html