Components of the DBMS Environment

 

Components of the DBMS Environment


We can identify five major components in the DBMS environment: hardware, software, data, procedures, and people .


                        Figure -  DBMS Environment



Hardware

The DBMS and the applications require hardware to run. The hardware can range from a single personal computer, to a single mainframe, to a network of computers. 

The particular hardware depends on the organization’s requirements and the DBMS used. Some DBMSs run only on particular hardware or operating systems, while others run on a wide variety of hardware and operating systems. 

A DBMS requires a minimum amount of main memory and disk space to run, but this minimum configuration may not necessarily give acceptable performance.

    
                    Figure - Hardware Component of DBMS


Software

The software component comprises the DBMS software itself and the application programs, together with the operating system, including network software if the DBMS is being used over a network. Typically, application programs are written in a third-generation programming language (3GL), such as ‘C’, C++, Java, Visual Basic, COBOL, Fortran, Ada, or Pascal, or using a fourth-generation language (4GL), such as SQL, embedded in a third generation language. 

The target DBMS may have its own fourth-generation tools that allow rapid development of applications through the provision of non-procedural query languages, reports generators, forms generators, graphics generators, and application generators. The use of fourth-generation tools can improve productivity significantly and produce programs that are easier to maintain.


Data

Perhaps the most important component of the DBMS environment, certainly from the end-users’ point of view, is the data. From figure 1 - we observe that the data acts as a bridge between the machine components and the human components. The database contains both the operational data and the metadata, the ‘data about data’. The structure of the database is called the schema.


Procedures


Procedures refer to the instructions and rules that govern the design and use of the database. The users of the system and the staff that manage the database require documented procedures on how to use or run the system. 

These may consist of instructions on 

  • how to log on to the DBMS
  • use a particular DBMS facility or application program
  • start and stop the DBMS
  • make backup copies of the database
  • handle hardware or software failures. 

This may include procedures on how to identify the failed component, how to fix the failed component (for example, telephone the appropriate hardware engineer) and, following the repair of the fault, how to recover the database , change the structure of a table, reorganize the database across multiple disks, improve performance, or archive data to secondary storage.


People

The final component is the people involved with the system.

i explain all peoples with their roles regarding DBMS in the next blog if you want to see then click on it .

Comments

Post a Comment

Popular posts from this blog

Limitations of the File-Based Approach

  Limitations of the File-Based Approach This brief description of traditional file-based systems should be sufficient to discuss the limitations of this approach .  1 . Separation and isolation of data When data is isolated in separate files, it is more difficult to access data that should be available. With file systems, such processing is difficult. The application developer must synchronize the processing of two files to ensure the correct data is extracted. This difficulty is compounded if we require data from more than two files. 2 . Duplication of data Owing to the decentralized approach taken by each department, the file-based approach encouraged, if not necessitated, the uncontrolled duplication of data . Uncontrolled duplication of data is undesirable for several reasons, including: Duplication is wasteful. It costs time and money to enter the data more than once.  It takes up additional storage space, again with associated costs. Often, the duplication of data...
Read more

The Three-Level ANSI-SPARC Architecture

Image
  The Three-Level ANSI-SPARC Architecture For our purposes, the fundamental point of these and later reports is the identification of three levels of abstraction, that is, three distinct levels at which data items can be described. The levels form a three-level architecture comprising an external, a conceptual, and an internal level . The way users perceive the data is called the external level.  The way the DBMS and the operating system perceive the data is the internal level, where the data is actually stored using the data structures and file organizations . The conceptual level provides both the mapping and the desired independence between the external and internal levels.  The objective of the three-level architecture is to separate each user’s view of the database from the way the database is physically represented. There are several reasons why this separation is desirable: Each user should be able to access the same data, but have a different customized view...
Read more

Relational Data Model:-Brief History, Terminology in Relational Data Structure, Relations, Properties of Relations, Keys, Domains, Integrity Constraints over Relations

Image
  Relational Data Model:-Brief History, Terminology in Relational Data Structure, Relations, Properties of Relations, Keys, Domains, Integrity Constraints over Relations What is Relational Model? Relational Model  represents the database as a collection of relations. A relation is nothing but a table of values. Every row in the table represents a collection of related data values. These rows in the table denote a real-world entity or relationship. The table name and column names are helpful to interpret the meaning of values in each row. The data are represented as a set of relations. In the relational model, data are stored as tables. However, the physical storage of the data is independent of the way the data are logically organized. The History of the Relational Model The relational model for database introduced by a gentleman named E.F. Codd. Codd developed the model in a 1970 research paper. His concepts were put into practice in the late 70's in an IBM product called...
Read more