Refer 2^nd Question & Answer OR CLICK HERE

Figure 7.1 illustrates, in a simplified form, the typical DBMS components. The figure is divided into two parts. The top part of the figure refers to the various users of the database environment and their interfaces. The lower part shows the internal modules of the DBMS responsible for storage of data and processing of transactions.

The database and the DBMS catalog are usually stored on disk. Access to the disk is controlled primarily by the

operating system (OS)

, which schedules disk read/write.

Many DBMSs have their own

buffer management

module to schedule disk read/write, because management of buffer storage has a considerable effect on performance. Reducing disk read/write improves performance considerably.

A higher-level

stored data manager

module of the DBMS controls access to DBMS information that is stored on disk, whether it is part of the database or the catalog.

Let us consider the top part of Figure 7.1 first. It shows interfaces for the DBA staff, casual users who work with interactive interfaces to formulate queries, application programmers who create programs using some host programming languages, and parametric users who do data entry work by supplying parameters to predefined transactions. The DBA staff works on defining the database and tuning it by making changes to its definition using the DDL and other privileged commands.

The DDL compiler processes schema definitions, specified in the DDL, and stores descriptions of the schemas (meta-data) in the DBMS catalog.

The catalog includes information such as the names and sizes of files, names and data types of data items, storage details of each file, mapping information among schemas, and constraints.

Casual users and persons with occasional need for information from the database interact using the

interactive query

interface in Figure 7.1. We have not explicitly shown any menu-based or form-based or mobile interactions that are typically used to generate the interactive query automatically or to access canned transactions.

These queries are parsed and validated for correctness of the query syntax, the names of files and data elements, and so on by a

query compiler

that compiles them into an internal form.

This internal query is subjected to query optimization. Among other things, the

query optimizer

is concerned with the rearrangement and possible reordering of operations, elimination of redundancies, and use of efficient search algorithms during execution.

Application programmers write programs in host languages such as Java, C, or C++ that are submitted to a precompiler. The

precompiler

extracts DML commands from an application program written in a host programming language. These commands are sent to the DML compiler for compilation into object code for database access.

In the lower part of Figure 7.1, the

runtime database processor

executes (1) the privileged commands, (2) the executable query plans, and (3) the canned transactions with runtime parameters.

It works with the

system catalog

and may update it with statistics. It also works with the

stored data manager

, which in turn uses basic operating system services for carrying out low-level input/output (read/write) operations between the disk and main memory.

The runtime database processor handles other aspects of data transfer, such as management of buffers in the main memory. Some DBMSs have their own buffer management module whereas others depend on the OS for buffer management.

We have shown

concurrency control and backup and recovery

systems separately as a module in this figure. They are integrated into the working of the runtime database processor for purposes of transaction management.

It is common to have the

client program

that accesses the DBMS running on a separate computer or device from the computer on which the database resides. The former is called the

client computer

running DBMS client software and the latter is called the

database server

. In many cases, the client accesses a middle computer, called the

application server

, which in turn accesses the database server.

Fig 7.1: Component modules of a DBMS and their interactions.

Entities and Their Attributes

. The basic concept that the ER model represents is an entity, which is a thing or object in the real world with an independent existence. An entity may be an object with a physical existence (for example, a particular person, car, house, or employee) or it may be an object with a conceptual existence (for instance, a company, a job, or a university course).

Each entity has

attributes

-the particular properties that describe it. For example, an EMPLOYEE entity may be described by the employee's name, age, address, salary, and job. A particular entity will have a value for each of its attributes. The attribute values that describe each entity become a major part of the data stored in the database.

Figure 8.1 illustrates the ER diagram for COMPANY DATABASE.

Figure 8.2 shows two entities and the values of their attributes. The EMPLOYEE entity e1 has four attributes: Name, Address, Age, and Home_phone; their values are 'John Smith,' '2311 Kirby, Houston, Texas 77001', '55', and '713-749-2630', respectively. The COMPANY entity c1 has three attributes: Name, Headquarters, and President; their values are 'Sunco Oil', 'Houston', and 'John Smith', respectively.

Several types of attributes occur in the ER model: simple versus composite, singlevalued versus multivalued, and stored versus derived. First we define these attribute types and illustrate their use via examples. Then we discuss the concept of a NULL value for an attribute.

Fig 8.1: An ER schema diagram for the COMPANY database

Fig 8.2: Two entities, EMPLOYEE e1, and COMPANY c1, and their attributes.

1.1

Database Administrators

In any organization where many people use the same resources, there is a need for a chief administrator to oversee and manage these resources. In a database environment, the primary resource is the database itself, and the secondary resource is the DBMS and related software.

Administering these resources is the responsibility of the database administrator (DBA). The DBA is responsible for authorizing access to the database, coordinating and monitoring its use, and acquiring software and hardware resources as needed.

The DBA is accountable for problems such as security breaches and poor system response time. In large organizations, the DBA is assisted by a staff that carries out these functions.

1.2

Database Designers

Database designers are responsible for identifying the data to be stored in the database and for choosing appropriate structures to represent and store this data. These tasks are mostly undertaken before the database is actually implemented and populated with data.

It is the responsibility of database designers to communicate with all prospective database users in order to understand their requirements and to create a design that meets these requirements.

In many cases, the designers are on the staff of the DBA and may be assigned other staff responsibilities after the database design is completed. Database designers typically interact with each potential group of users and develop views of the database that meet the data and processing requirements of these groups.

Each view is then analysed and integrated with the views of other user groups. The final database design must be capable of supporting the requirements of all user groups.