DBMS

Education
Data Base Management System
	Requirements
	Basics
	Need of DBMS
	Advantages
	Constraints
	Relationship
	Monitoring Database
	Security

Basics

The three level architecture

The three level architecture is an architecture for a DBMS to provide a framework for describing database concepts and structures. Not all DBMS fit neatly into this architecture, but most do. The model has been proposed by ANSI/SPARC and has three levels. Mappings exist between the three levels and it is the responsibility of the DBA to ensure these mappings are correct.

External level (individual users view)
Conceptual level (community user view)
Internal level (storage)

Backend database machine

The backend database machine approach refers to a conventional machine running DBMS functions. The host application program issues the database request, the interface code intercepts and gets the database machine to do the work and then send back the result. The main overhead is the cost of the offloading process. To be cost-effective, the amount of work offloaded should be an order of magnitude greater than the work involved in doing the offload.

A DBMS on a backend machine is the only application running on that machine, so it is permanently resident in main memory. Many of the operating system functions on this machine are dispensed with. General purpose algorithms in a conventional operating system are not suited to special purpose DBMS applications, like file handling. A backend machine should run a DBMS with its own file manager and mini-operating system.

Database utilities and tools

The DBA will need many utilities to implement proper control over the database. The following are some examples.

Load routines - to create the initial database.
Dump/restore routines - for backup and recovery purposes.
Reorganization routines - to rearrange the data for various performance reasons.
Statistical routines - to compute performance statistics etc.
Analysis routines - to analysis the statistics.

These tools allow the DBA to monitor the performance of the DBMS.

Properties of DBMS data

DBMS are available on any machine, from small micros to large mainframes, and can be single or multi-user - obviously, there will be special problems in multi-user environments in order to make other users invisible, but these problems are internal to DBMS.
Data may be shared over many databases, giving a distributed DBMS, though quite often it is centralized and stored in just one database on one machine. In general, the data in the database, at least in a large system, will be both integrated and shared.

Relational domains

The smallest unit of data is the data value, and such values are considered to be atomic. A domain is defined as a set of values of the same type e.g. the domain of student numbers is the set of all possible student number values e.g. 88000000 to 88999999. Hence, a domain can be alternatively defined as a pool of values from which one or more attributes in a relational table take their values. If two attributes draw their values from the same domain then comparisons of these attributes can be made, perhaps over different tables.
Domains are specified as part of the data definition. Most systems however, don't support domains as defined in the relational model.
Domains may be simple or composite - where a composite domain is defined as the product of some collection of simple domains e.g. DATE is a product of month, day, year where month etc. is the simple domain 1 - 12 etc. Supporting domains is a complex process.

Stored file structure

A given stored file may be physically implemented in a number of ways e.g. may be entirely contained within a single storage volume or spread across several volumes. However, how it is stored should not affect applications in any way, other than in performance thus providing data independence. Thus the stored file structure should be an operating system concern and should be transparent to the users of a DBMS.

| Disclaimer | Privacy Policy | Terms of Use |