Three Level Architecture

By Parteek Bhatia

FacultyDepartment of Comp Sc & Engg

Thapar UniversityPatiala

parteek.bhatia@gmail.com

An early proposal for a standard terminology and general architecture for database systems was produced in 1971 by the DBTG (Data Base Task Group) appointed by the Conference on Data Systems and Languages (CODASYL, 1971). The DBTG recognized the need for a two level approach with a system view called the schema and user views called subschema. The American National Standards Institute (ANSI) recognized the need for a three level approach with a system catalog.

 

Three Level Architecture

There are following three levels or layers of DBMS architecture:

 

 

      External Level

 

      Conceptual Level

 

      Internal Level

 

Objective of the Three Level Architecture

 

      Each user should be able to access the same data, but have a different customized view of the data.

      User’s interaction with the database should be independent of storage considerations.

 

      The Database Administrator (DBA) should be able to change the database storage structures without affecting the user’s views.

 

      The internal structure of the database should be unaffected by changes to the physical aspects of storage, such as the changeover to a new storage device.

 

      The DBA should be able to change the conceptual structure of the database without affecting all users.

External Level or View level

 

It is the users’ view of the database. This level describes that part of the database that is relevant to each user. External level is the one, which is closest to the end users. This level deals with the way in which individual users view data. Individual users are given different views according to the user’s requirement.

External level is also known as the view level. In addition different views may have different representations of the same data. For example, one user may view dates in the form (day, month, year), while another may view dates as (year, month, day).

Conceptual Level or Logical level

 It is the community view of the database. This level describes what data is stored in the database and the relationships among the data. The middle level in the three level architecture is the conceptual level.

This level contains the logical structure of the entire database as seen by the DBA. It is a complete view of the data requirements of the organization that is independent of any storage considerations. The conceptual level represents:

       All entities, their attributes, and their relationships;

      The constraints on the data;

      Security and integrity information.

 .

This level must not contain any storage dependent details. For instance, the description of an entity should contain only data types of attributes (for example, integer, real, character) and their length (such as the maximum number of digits or characters), but not any storage considerations, such as the number of bytes occupied. Conceptual level is also known as the logical level

Internal Level or Storage level

 It is the physical representation of the database on the computer. This level describes how the data is stored in the database. The internal level is the one that concerns the way the data are physically stored on the hardware.

The internal level covers the physical implementation of the database to achieve optimal runtime performance and storage space utilization. It covers the data structures and file organizations used to store data on storage devices. It interfaces with the operating system access methods to place the data on the storage devices, build the indexes, retrieve the data, and so on.

 

The internal level is concerned with such things as:

       Storage space allocation for data and indexes;

       Record descriptions for storage (with stored sizes for data items);

       Record placement;

       Data compression and data encryption techniques.

  

There will be only one conceptual view, consisting of the abstract representation of the database in its entirely. Similarly there will be only one internal or physical view, representing the total database, as it is physically stored.

 

Schema

 The overall description of the database is called the Database Schema. There are three different types of schema in the database corresponding to each data view of database. In other words, the data views at each of three levels are described by schema.

  A schema is defined as an outline or a plan that describes the records and relationships existing at the particular level. The External view is described by means of a schema called external schema that correspond to different views of the data. Similarly the Conceptual view is defined by conceptual schema, which describes all the entities, attributes, and relationship together with integrity constraints. Internal View is defined by internal schema, which is a complete description of the internal model, containing definition of stored records, the methods of representation, the data fields, and the indexes used.

 

There is only one conceptual schema and one internal schema per database. The schema also describes the way in which data elements at one level can be mapped to the corresponding data elements in the next level.

 Thus, we can say that schema establishes correspondence between the records and relationships in the two levels. In a relational database, the schema defines the tables, the fields in each table, and the relationships between fields and tables. Schema are generally stored in a data dictionary.

 The schema is specified during the database design process and is not expected to change frequently. However the actual data in the database may change frequently;  The data in the database at any particular point in time is called a database instance. Therefore, many database instances can correspond to the same database schema. The schema is sometimes called the intension of the database, while an instance is called an extension (or state) of the database.

To understand the difference between the three levels, consider again the database schema that describes College Database system. If User1 is a Library clerk, the external view would contain only the student and book information. If User2 is a account office clerk then he/she may be interested in students detail and fee detail.

Mapping between Views

External/Conceptual Mapping: Each external schema is related to the conceptual schema by the external/conceptual mapping. A mapping between the external and conceptual views gives the correspondence among the records and the relationships of the external and conceptual views. There is a mapping from a particular logical record in the external view to one (or more) conceptual record(s) in the conceptual view.

Names of the fields and records, for instance, may be different. A number of conceptual fields can be combined into a single external field, for example, Last_Name and First_Name at the conceptual level but Name at the external level. A given external record could be derived from a number of conceptual records.

 

Conceptual/Internal Mapping: Conceptual schema is related to the internal schema by the conceptual/internal mapping. This enables the DBMS to find the actual record or combination of records in physical storage that constitute a logical record in conceptual schema. Mapping between the conceptual and the internal levels specifies the method of deriving the conceptual record from the physical database.

 

Data Independence-Achievement of Layered Architecture of DBMS

 There are two kinds of data independence:

       Logical data independence

      Physical data independence

 Logical data independence

 Logical data independence indicates that the conceptual schema can be changed without affecting the existing external schemas. The change would be absorbed by the mapping between the external and conceptual levels.  

Physical data independence

 Physical data independence indicates that the physical storage structures or devices could be changed without affecting conceptual schema. The change would be absorbed by the mapping between the conceptual and internal levels. Physical data independence is achieved by the presence of the internal level of the database and the mapping or transformation from the conceptual level of the database to the internal level.

If there is a need to change the file organization or the type of physical device used as a result of growth in the database or new technology, a change is required in the conceptual/internal mapping between the conceptual and internal levels.

The physical data independence criterion requires that the conceptual level does not specify storage structures or the access methods (indexing, hashing etc.) used to retrieve the data from the physical storage medium.

The Logical data independence is difficult to achieve than physical data independence as it requires the flexibility in the design of database and programmer has to foresee the future requirements or modifications in the design.

The Procedure for Database Access

 A user’s request for data is received by the data manager, which determines the physical record required. The decision as to which physical record is needed may require some preliminary consultation of the database and/or the data dictionary prior to the access of the actual data itself.

 

The data manager sends the request for a specific physical record to the file manager. The file manager decides which physical block of secondary storage devices contains the required record and sends the request for the appropriate block to the disk manager. A block is a unit of physical input/output operations between primary and secondary storage. The disk manager retrieves the block and sends it to the file manager, which sends the required record to the data manager.

Functions of Data Base Administrator

• Makes decisions concerning the content of the database: It is the DBA’s job to decide exactly what information is to be held in the database—in other words, to identify the entities of interest to the enterprise and to identify the information to be recorded about those entities.

• Plans storage structures and access strategies: The DBA must also decide how the data is to be represented in the database, and must specify the representation by writing the storage structure definition (using the internal data definition language). In addition, the associated mapping between the storage structure definition and the conceptual schema must also be specified.

• Provides support to users: It is the responsibility of the DBA to provide support to the users, to ensure that the data they require is available, and to write the necessary external schemas (using the appropriate external data definition language). In addition, the mapping between any given external schema and the conceptual schema must also be specified.

Functions of Data Base Administrator

• Defines security and integrity checks: DBA is responsible for providing the authorization and authentication checks such that no malicious users can access database and it must remain protected. DBA must also ensure the integrity of the database.

• Interprets backup and recovery strategies: In the event of damage to any portion of the database-caused by human error, say, or a failure in the hardware or supporting operating system—it is essential to be able to repair the data concerned with a minimum of delay and with as little effect as possible on the rest of the system. The DBA must define and implement an appropriate recovery strategy to recover the database from all types of failures.

• Monitoring performance and responding to changes in requirements: The DBA is responsible for so organizing the system as to get the performance that is “best for the enterprise,” and for making the appropriate adjustments as requirements change.

Metadata or Data Dictionary

• A metadata (also called the data dictionary) is the data about the data. It is the self-describing nature of the database that provides program-data independence. It is also called as the System Catalog. It holds the following information about each data element in the databases, it normally includes:

• Name• Type• Range of values• Source• Access authorization• Indicates which application programs use the data so that when a

change in a data structure is contemplated, a list of the affected programs can be generated.

Active and Passive Data Dictionaries

• Data dictionary may be either active or passive. An active data dictionary (also called integrated data dictionary) is managed automatically by the database management software. Since active data dictionaries are maintained by the system itself, they are always consistent with the current structure and definition of the database. Most of the relational database management systems contain active data dictionaries that can be derived from their system catalog.

• The passive data dictionary (also called non-integrated data dictionary) is the one used only for documentation purposes. Passive dictionary is simply a self-contained application. It is managed by the users of the system and is modified whenever the structure of the database is changed. Since this modification must be performed manually by the user, it is possible that the data dictionary will not be current with the current structure of the database.

Components of a DBMS

• Query processor: The query processor transforms user queries into a series of low-level instructions. It is used to interpret the online user’s query and convert it into an efficient series of operations in a form capable of being sent to the run time data manager for execution. The query processor uses the data dictionary to find the structure of the relevant portion of the database and uses this information in modifying the query and preparing and optimal plan to access the database.

• Run time database manager: Run time database manager is the central software component of the DBMS, which interfaces with user-submitted application programs and queries. It handles database access at run time. It converts operations in user’s queries coming directly via the query processor or indirectly via an application program from the user’s logical view to a physical file system. It accepts queries and examines the external and conceptual schemas to determine what conceptual records are required to satisfy the users request.

• Run time database manager: It enforces constraints to maintain the consistency and integrity of the data, as well as its security. It also performs backing and recovery operations. Run time database manager is sometimes referred to as the database control system and has the following components:

– Authorization control: The authorization control module checks the authorization of users in terms of various privileges to users..

– Command processor: The command processor processes the queries passed by authorization control module.

– Integrity checker: It checks the integrity constraints so that only valid data can be entered into the database.

– Query optimizer: The query optimizers determine an optimal strategy for the query execution.

– Transaction manager: The transaction manager ensures that the transaction properties should be maintained by the system.

– Scheduler: It provides an environment in which multiple users can work on same piece of data at the same time in other words it supports concurrency.

• Data manager: The data manager is responsible for the actual handling of data in the database. It provides recovery to the system which that system should be able to recover the data after some failure. It includes Recovery manager and Buffer manager. The buffer manager is responsible for the transfer of data between the main memory and secondary storage (such as disk or tape). It is also referred as the cache manger.

References

Simplified Approach To DBMSBy

Parteek BhatiaKalyani Publishers