Database Languages

 


Database Languages


A data sublanguage consists of two parts: a Data Definition Language (DDL) and a Data Manipulation Language (DML). The DDL is used to specify the database schema and the DML is used to both read and update the database. 

These languages are called data sublanguages because they do not include constructs for all computing needs such as conditional or iterative statements, which are provided by the high-level programming languages. 

Many DBMSs have a facility for embedding the sublanguage in a high-level programming language such as COBOL, Fortran, Pascal, Ada, ‘C’, C++, Java, or Visual Basic. In this case, the high-level language is sometimes referred to as the host language. 

To compile the embedded file, the commands in the data sublanguage are first removed from the host-language program and replaced by function calls. The pre-processed file is then compiled, placed in an object module, linked with a DBMS-specific library containing the replaced functions, and executed when required. 

Most data sublanguages also provide non-embedded, or interactive, commands that can be input directly from a terminal.

The Data Definition Language (DDL)


A language that allows the DBA or user to describe and name the entities, attributes, and relationships required for the application, together with any associated integrity and security constraints.


The database schema is specified by a set of definitions expressed by means of a special language called a Data Definition Language. The DDL is used to define a schema or to modify an existing one. It cannot be used to manipulate data. The result of the compilation of the DDL statements is a set of tables stored in special files collectively called the system catalog. 

The system catalog integrates the metadata, that is data that describes objects in the database and makes it easier for those objects to be accessed or manipulated. The metadata contains definitions of records, data items, and other objects that are of interest to users or are required by the DBMS. 

The DBMS normally consults the system catalog before the actual data is accessed in the database. The terms data dictionary and data directory are also used to describe the system catalog, although the term ‘data dictionary’ usually refers to a more general software system than a catalog for a DBMS.

At a theoretical level, we could identify different DDLs for each schema in the threelevel architecture, namely a DDL for the external schemas, a DDL for the conceptual schema, and a DDL for the internal schema. 

However, in practice, there is one comprehensive DDL that allows specification of at least the external and conceptual schemas.



The Data Manipulation Language (DML)


A language that provides a set of operations to support the basic data manipulation operations on the data held in the database.

Data manipulation operations usually include the following

  • Insertion of new data into the database
  • Modification of data stored in the database
  • Retrieval of data contained in the database
  • Deletion of data from the database. 

Therefore, one of the main functions of the DBMS is to support a data manipulation language in which the user can construct statements that will cause such data manipulation to occur. Data manipulation applies to the external, conceptual, and internal levels. 

However, at the internal level we must define rather complex low-level procedures that allow efficient data access. In contrast, at higher levels, emphasis is placed on ease of use and effort is directed at providing efficient user interaction with the system.

The part of a DML that involves data retrieval is called a query language. A query language can be defined as a high-level special-purpose language used to satisfy diverse requests for the retrieval of data held in the database. 

The term ‘query’ is therefore reserved to denote a retrieval statement expressed in a query language. The terms ‘query language’ and ‘DML’ are commonly used interchangeably, although this is technically incorrect. DMLs are distinguished by their underlying retrieval constructs. We can distinguish between two types of DML: procedural and non-procedural. 

The prime difference between these two data manipulation languages is that procedural languages specify how the output of a DML statement is to be obtained, while non-procedural DMLs describe only what output is to be obtained. Typically, procedural languages treat records individually, whereas non-procedural languages operate on sets of records.


Procedural DMLs


A language that allows the user to tell the system what data is needed and exactly how to retrieve the data. 

With a procedural DML, the user, or more normally the programmer, specifies what data is needed and how to obtain it. This means that the user must express all the data access operations that are to be used by calling appropriate procedures to obtain the information required. Typically, such a procedural DML retrieves a record, processes it and, based on the results obtained by this processing, retrieves another record that would be processed similarly, and so on. This process of retrievals continues until the data requested from the retrieval has been gathered. Typically, procedural DMLs are embedded in a high-level programming language that contains constructs to facilitate iteration and handle navigational logic.

Non-procedural DMLs


A language that allows the user to state what data is needed rather than how it is to be retrieved.


Non-procedural DMLs allow the required data to be specified in a single retrieval or update statement. With non-procedural DMLs, the user specifies what data is required without specifying how it is to be obtained. The DBMS translates a DML statement into one or more procedures that manipulate the required sets of records. This frees the user from having to know how data structures are internally implemented and what algorithms are required to retrieve and possibly transform the data, thus providing users with a considerable degree of data independence. Non-procedural languages are also called declarative languages. 


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

Roles of DA , DBA , Database Designer , Application Developers and Users

  Roles of Data Administrator(DA) , Database Administrator (DBA) , Database Designer , Application Developers and Users Here i will explain all peoples who are involved in DBMS in two parts  Actors on the scene Workers behind the scene . Actors on the scene Roles of Data Administrator The Data Administrator (DA) is responsible for the management of the data resource including database planning, development and maintenance of standards, policies and procedures, and conceptual/logical database design.  The DA consults with and advises senior managers, ensuring that the direction of database development will ultimately support corporate objectives. "Person in the organization who controls the data of the database refers data administrator." DA determines what data to be stored in database based on requirement of the organization. DA works on such as requirements gathering, analysis, and design phases. DA does not to be a technical person, any kind of knowledge about database...
Read more