Introduction to DBMS / RDBMS

Difference Between DBMS and RDBMS

The software application that enables the users to store the data is known as a database. In database architecture, there are different implementations and theories in order to store physical data. The database which stores data in the tables that have relationships with other tables in the database is called RDBMS or Relational Database Management System. However, in DBMS or Database Management System, there are no relationships among tables.

DBMS

DBMS is defined as the software program that is used to manage all the databases that are stored on the network or system hard disk. There are different types of database management systems and some of them are configured for specific purposes.

DBMS is available in different forms as a tool that is used to manage databases. Some popular DBMS solutions include DB2, Oracle, FileMaker and Microsoft Access. Using these products, privileges or rights can be created that can be specific to particular users. It means that the administrators of the database can grant specific rights to some users or assign different levels of administration.

Every DBMS has some fundamental elements. First is the implementation of the modeling language which defines the language used for each database. Second, DBMS also administers the data structures. Data query language is the third element of a DBMS. Data structures work with data query language in order to make sure that irrelevant data cannot be entered into the database used in the system.

RDBMS

The database system in which the relationships among different tables are maintained is called Relational Database Management System. Both RDBMS and DBMS are used to store information in physical database.

RDBMS solution is required when large amounts of data are to be stored as well as maintained. A relational data model consists of indexes, keys, foreign keys, tables and their relationships with other tables. Relational DBMS enforces the rules even though foreign keys are support by both RDBMS and DBMS.

In 1970s, Edgar Frank Codd introduced the theory of relational database. Thirteen rules were defined by Codd for this relational theory or model. Relationships among different types of data Is the main requirement of the relational model.

RDMS can be termed as the next generation of database management system. DBMS is used as a base model in order to store data in a relational database system. However, complex business applications use RDBMS rather than DBMS.

DBMS vs. RDBMS • Relationship among tables is maintained in a RDBMS whereas this not the case DBMS as it is used to manage the database. • DBMS accepts the ‘flat file’ data that means there is no relation among different data whereas RDBMS does not accepts this type of design. • DBMS is used for simpler business applications whereas RDBMS is used for more complex applications. • Although the foreign key concept is supported by both DBMS and RDBMS but its only RDBMS that enforces the rules. • RDBMS solution is required by large sets of data whereas small sets of data can be managed by DBMS.

Edgar F. Codd

Edgar Frank "Ted" Codd (August 23, 1923 – April 18, 2003) was an English computer scientist who, while working for IBM, invented the relational model for database management, the theoretical basis for relational databases (see also database management system). He made other valuable contributions to computer science, but the relational model, a very influential general theory of data management, remains his most mentioned achievement.

Edgar Frank "Ted" Codd
Born	August 23, 1923 Isle of Portland, England
Died	April 18, 2003 (aged 79) Williams Island, Florida
Fields	Computer Science
Institutions	IBM
Alma mater	University of Michigan
Known for	relational model OLAP
Notable awards	Turing Award

Codd's 12 rules

Codd's twelve rules are a set of thirteen rules (numbered zero to twelve), designed to define what is required from a database management system in order for it to be considered relational, i.e., a relational database management system (RDBMS). They are sometimes jokingly referred to as "Codd's Twelve Commandments".

Codd produced these rules as part of a personal campaign to prevent his vision of the relational database being diluted, as database vendors scrambled in the early 1980s to repackage existing products with a relational veneer. Rule 12 was particularly designed to counter such a positioning.

Even if such repackaged non-relational products eventually gave way to SQL DBMSs, no popular "relational" DBMSs are actually relational, be it by Codd’s twelve rules or by the more formal definitions in his papers, in his books or in succeeding works in the academia or by its coworkers and successors, Christopher J. Date, Hugh Darwen, David McGoveran and Fabian Pascal. Only less known DBMSs, most of them academic, strive to comply. The only commercial example, as of December 2010, is Dataphor.

Some rules are controversial, specially rule three, due to the debate on three-valued logic.

The rules

Rule (0): The system must qualify as relational, as a database, and as a management system.

For a system to qualify as a relational database management system (RDBMS), that system must use its relational facilities (exclusively) to manage the database.

Rule 1: The information rule:

All information in the database is to be represented in only one way, namely by values in column positions within rows of tables.

Rule 2: The guaranteed access rule:

All data must be accessible. This rule is essentially a restatement of the fundamental requirement for primary keys. It says that every individual scalar value in the database must be logically addressable by specifying the name of the containing table, the name of the containing column and the primary key value of the containing row.

Rule 3: Systematic treatment of null values:

The DBMS must allow each field to remain null (or empty). Specifically, it must support a representation of "missing information and inapplicable information" that is systematic, distinct from all regular values (for example, "distinct from zero or any other number", in the case of numeric values), and independent of data

type. It is also implied that such representations must be manipulated by the DBMS in a systematic way.

Rule 4: Active online catalog based on the relational model:

The system must support an online, inline, relational catalog that is accessible to authorized users by means of their regular query language. That is, users must be able to access the database's structure (catalog) using the same query language that they use to access the database's data.

Rule 5: The comprehensive data sublanguage rule:

The system must support at least one relational language that

1. Has a linear syntax
2. Can be used both interactively and within application programs,
3. Supports data definition operations (including view definitions), data manipulation operations (update as well as retrieval), security and integrity constraints, and transaction management operations (begin, commit, and rollback).

Rule 6: The view updating rule:

All views that are theoretically updatable must be updatable by the system.

Rule 7: High-level insert, update, and delete:

The system must support set-at-a-time insert, update, and delete operators. This means that data can be retrieved from a relational database in sets constructed of data from multiple rows and/or multiple tables. This rule states that insert, update, and delete operations should be supported for any retrievable set rather than just for a single row in a single table.

Rule 8: Physical data independence:

Changes to the physical level (how the data is stored, whether in arrays or linked lists etc.) must not require a change to an application based on the structure.

Rule 9: Logical data independence:

Changes to the logical level (tables, columns, rows, and so on) must not require a change to an application based on the structure. Logical data independence is more difficult to achieve than physical data independence.

Rule 10: Integrity independence:

Integrity constraints must be specified separately from application programs and stored in the catalog. It must be possible to change such constraints as and when appropriate without unnecessarily affecting existing applications.

Rule 11: Distribution independence:

The distribution of portions of the database to various locations should be invisible to users of the database. Existing applications should continue to operate successfully :

1. when a distributed version of the DBMS is first introduced; and
2. when existing distributed data are redistributed around the system.

Rule 12: The nonsubversion rule:

If the system provides a low-level (record-at-a-time) interface, then that interface cannot be used to subvert the system, for example, bypassing a relational security or integrity constraint.

====================================================================
Back to Home & RDBMS
====================================================================