Learn DBMS, Part III

DATABASE SYSTEM ARCHITECT


Following are the three types of database architectures:

1. Client-Server Database Systems

A client is defined as a requester of services and a server is defined as the provider of services.
Today centralized systems act as server systems that satisfy requests generated by client systems.
Functionally database systems can be broadly divided into two parts:


• Front end: front end of a database system consists of tools such as SQL user interface, forms interfaces, reports generation tools, and analysis tools.
• Back end: The back end of a database system manages query evaluation and optimization, access structures, concurrency control and recovery management.



2. Parallel Systems

In parallel processing, many operations are performed simultaneously and the computational steps are performed sequentially. It can process thousands of transactions per second.


There are four types of Architectural Models for Parallel Processing:



• Shared Memory (tightly coupled) architecture: Multiple processors share secondary (disk) storage and also share primary memory.
• Shared Disk (loosely coupled) architecture: Multiple processors share secondary (disk) storage but each has their own primary memory.
• Shared Nothing: The processors share neither a common memory nor common disk.
• Hierarchical: this model is the combination of preceding three architectures.


3. Distributed Systems


Distributed database is a collection of multiple logically interrelated databases distributed over a computer network and a distributed database management system is a software system that manages a distributed database while making the distribution transparent to the user. Transparency means hiding the details of where the data is physically stored within the system.
Reasons for building a distributed database are sharing of data, autonomy, and availability.

Functions of distributed databases:


• Keeping track of data.
• Query Processing by a communication network.
• Security Management.
• Distributed Transaction Management
• Database Recovery.

CODD’S RULE


E.F. Codd, the famous mathematician has introduce 12 rules for the relational model for databases commonly known as Codd's rules. The rules mainly define what is required for a DBMS for it to be considered relational , i.e., an RDBMS. There is also one more rule i.e Rule00 which specifies the relational model should use the relational way to manage the database. The rules and their description is as follows:-

Rule 000: A RDBMS system should be capable of using its relational facilities (exclusively) to manage the database.

Rule 1: The information rule : All information in the database is to be represented in one and only one way. This is achieved by values in column positions within rows of tables.

Rule 2 : The guaranteed access rule : All data must be accessible with no ambiguity.This is achieved in the RDBMS by using the primary key concept.

Rule 3: Systematic treatment of null values : The DBMS must allow each field to remain null. The null can be stored in any field of any datatype.

Rule 4: Active online catalog based on the relational model : The authorized users can access the database structure by using common language i.e SQL.

Rule 5: The comprehensive data sublanguage rule : The system must support at least one relational language that has simple syntax and transaction management facilities. It can be used in the application as well as in the RDBMS systems.

Rule 6: The view updating rule : All views must be updatable by the system.

Rule 7: High-level insert, update, and delete : The system is able to insert, update and delete operations fully. It can also perform the operations on multiple rows simultenously.

Rule 8: Physical data independence : Changes to the physical storage structure must not require a change to an application based on the structure.

Rule 9: Logical data independence : Changes to the logical level (tables, columns, rows, and so on) must not require a change to an application based on the structure.

Rule 10: Integrity independence : All the Integrity constraints like primary key, uniques key etc must be specified separately from application programs and stored in the catalog.

Rule 11: Distribution independence : The distribution of portions of the database to various locations should be invisible to users of the database.

Rule 12: The nonsubversion rule : If the system provides a low-level (record-at-a-time) interface, then that interface cannot be used to subvert the system, for example, bypassing a relational security or integrity constraint.

Note:- Any database management system which fulfills 6 or more than 6 rules can be considered as the RDBMS.