DATABASE ARCHITECTURE
The design of a Database Management System (DBMS) is contingent upon its architecture, which can vary between centralized, decentralized, or hierarchical structures. This architecture can be categorized as either single-tier or multi-tier.
In a single-tier architecture, the DBMS serves as the sole entity where users directly interact with it. Any modifications are made directly to the DBMS itself, without providing additional tools for end-users. Database designers and programmers typically favor single-tier architecture due to its simplicity.
In a two-tier architecture, the DBMS requires an intermediary application for access. Programmers opt for two-tier architecture when accessing the DBMS via an application. In this setup, the application tier operates independently of the database in terms of functionality, design, and programming.
Three-tier Architecture
A three-tier architecture divides its tiers based on user complexity and their interaction with the database data. It stands as the most commonly employed architecture for designing a DBMS.
Database (Data) Tier: This tier houses the database itself along with its query processing languages. Here, data relations are defined, along with their constraints.
Application (Middle) Tier: In this tier, the application server and programs accessing the database are located. For users, this tier offers an abstracted perspective of the database. Users remain unaware of the database's existence beyond the application. Similarly, the database tier remains oblivious to users beyond the application tier. Thus, the application layer serves as a mediator between end-users and the database.
User (Presentation) Tier: End-users interact with this tier without any knowledge of the database's existence beyond it. The application can provide multiple views of the database at this layer. These views are generated by applications residing in the application tier.
0 Comments