UNIT 1: BASIC CONCEPTS OF DATABASE MANAGEMENT SYSTEMS

1. Overview of a Database Management System

A Database Management System (DBMS) is a set of software programs that controls the organisation, storage, management, and retrieval of data in a database. The DBMS accepts requests for data from an application program and instructs the operating system to transfer the appropriate data. The queries and responses must be submitted and received according to a format that conforms to one or more applicable protocols. When a DBMS is used, information systems can be changed much more easily as the organisation‘s information requirements change. New categories of data can be added to the database without disruption to the existing system.

1.1. What is a Database Management System?

 A Database Management System can simply be defined as a set of software programs that controls the organisation, storage, management, and retrieval of data in a database.

 Typical examples of Database Management Systems include Oracle

Database, Microsoft SQL Server, and PostgreSQL. Nowadays, a small number of DBMSs are used by the great majority of database applications to manage practically all the world‘s databases.

1.2. Categories of Database Management Systems (DBMS)

 Database management systems are categorised according to their data structures and types. Well known types are relational, hierarchical, and object-oriented.

1. Database Management System (RDBMS)

 The Relational database management system organises data in tabular files. Most modern Database Management Systems (Oracle, Sybase, and Microsoft SQL Server) are relational databases. These databases support a standard language - SQL (Structured Query Language).

2. Hierarchical Database Management System (RDBMS)

 This category of database management system stores data in a tree-like structure.

3. Object-Oriented Database Management System (RDBMS)

The Object-Oriented database management system stores objects as opposed to tuples or records in a RDBMS.

DBMSs are categorized according to their data structures or types.

1.3. Features of Database Management Systems (DBMS)

Features commonly offered by database management systems include:

Query ability

Querying is the process of requesting attribute information from various perspectives and combinations of factors. Example: How many 2-door cars in Texas are green?‖ A database query language and report writer allow users to interactively interrogate the database, analyze its data and update it according to the users privileges on data.

 Backup and replication

 Copies of attributes need to be made regularly in case primary disks or other equipment fails. A periodic copy of attributes may also be created for a distant organisation that cannot readily

access the original. DBMS usually provide utilities to facilitate the process of extracting and disseminating attribute sets. When data is replicated between database servers, so that the information remains consistent throughout the database system and users cannot tell or even know which server in the DBMS they are using, the system is said to exhibit replication transparency.

 Rule enforcement

Often one wants to apply rules to attributes so that the attributes are clean and reliable. For example, we may have a rule that says each car can have only one engine associated with it (identified by Engine Number). If somebody tries to associate a second engine with a given car, we want the DBMS to deny such a request and display an error message. However, with changes in the model specification such as, in this example, hybrid gas- electric cars, rules may need to change. Ideally such rules should be able to be added and removed as needed without significant data layout redesign.

 Security

Often it is desirable to limit who can see or change which attributes or groups of attributes. This may be managed directly by individual, or by the assignment of individuals and privileges to groups, or (in the most elaborate models) through the assignment of individuals and groups to roles which are then granted entitlements.

 Computation

There are common computations requested on attributes such as counting, summing, averaging, sorting, grouping, cross- referencing, etc. Rather than have each computer application implement these from scratch, they can rely on the DBMS to supply such calculations.

 Change and access logging

Often one wants to know who accessed what attributes, what was changed, and when it was changed. Logging services allow this by keeping a record of access occurrences and changes.

 Automated optimisation

If there are frequently occurring usage patterns or requests, some DBMS can adjust themselves to improve the speed of those interactions. In some cases the DBMS will merely provide tools to monitor performance, allowing a human expert to make the necessary adjustments after reviewing the statistics collected.

1.4. Database Servers

Database servers are computers that hold the actual databases and run only the database management system and related software. They are usually multiprocessor computers, with generous memory and RAID disk arrays used for stable storage. Hardware database accelerators, connected to one or more servers via a high-speed channel, are also used in large volume transaction processing environments.

2. Evolution of Database Management Systems

Databases have been in use since the earliest days of electronic computing, but the vast majority of these were custom programs written to access custom databases. Unlike modern systems which can be applied to a wide range of databases and needs, these systems were tightly linked to the database in order to gain speed at the price of flexibility.

 The major DBMS that evolved are as follows:

•              Navigational DBMS

•              Relational DBMS

•              Multidimensional DBMS

•              Object DBMS

2.1. Navigational DBMS

Objects are the basic run-time entities in an object-oriented system. A number of general-purpose database systems emerged due to growth in the speed and capability of computers; by the mid-1960s there were a number of such systems in commercial use. Interest in a standard began to grow, and Charles Bachman, founded the ―Database Task Group‖ within CODASYL, the group responsible for the creation and standardization of COBOL. In 1971 they delivered their standard, which generally became known as the ―Codasyl approach‖, and soon there were a number of commercial products based on it available.

The Codasyl approach was based on the ―manual‖ navigation of a linked data set which was formed into a large network. To find any particular record the programmer had to step through these pointers one at a time until the required record was returned. Simple queries like ―find all the people in India‖ required the program to walk the entire data set and collect the matching results. There was, essentially, no concept of ―find‖ or ―search‖. This might sound like a serious limitation today, but in an era when the data was most often stored on magnetic tape such operations were too expensive to contemplate anyway.

IBM also had their own DBMS system in 1968, known as IMS. IMS was a development of software written for the Apollo program on the System/360. IMS was generally similar in concept to Codasyl, but used a strict hierarchy for its model of data navigation instead of Codasyl‘s network model. Both concepts later became known as navigational databases due to the way data was accessed, and Bachman‘s 1973 Turing Award presentation was The Programmer as Navigator. IMS is classified as a hierarchical database. IMS and IDMS, both CODASYL databases, as well as CINCOMs TOTAL database are classified as network databases.

2.2. Relational DBMS

Not satisfied with the navigational model of the Codasyl approach, notably the lack of a ―search‖ facility which was becoming increasingly useful, Edgar Codd, wrote a number of papers that outlined a new approach to database construction in 1970. He described a new system for storing and working with large databases. Instead of records being stored in some sort of linked list of free-form records as in Codasyl, Codd's idea was to use a ―table‖ of fixed-length records. A linked-list system would be very inefficient when storing ―sparse‖ databases where some of the data for any one record could be left empty. The relational model solved this by splitting the data into a series of normalised tables, with optional elements being moved out of the main table to where they would take up room only if needed.

Fig. 1.1:        The Relational Model

 In the relational model, related records are linked together with a ―key‖. For instance, a common use of a database system is to track information about users, their name, login information, various addresses and phone numbers. In the navigational approach all of these data would be placed in a single record, and unused items would simply not be placed in the database. In the relational approach, the data would be normalised into a user table, an address table and a phone number table (for instance). Records would be created in these optional tables only if the address or phone numbers were actually provided.

Linking the information back together is the key to this system. In the relational model, some bit of information was used as a ―key‖, uniquely defining a particular record. When information was being collected about a user, information stored in the optional (or related) tables would be found by searching for this key. For instance, if the login name of a user is unique, addresses and phone numbers for that user would be recorded with the login name as its key. This ―re-linking‖ of related data back into a single collection is something that traditional computer languages are not designed for.

Just as the navigational approach would require programs to loop in order to collect records, the relational approach would require loops to collect information about any one record. Codd‘s solution to the necessary looping was a set-oriented language, a suggestion that would later spawn the ubiquitous SQL. Using a branch of mathematics known as tuple calculus, he demonstrated that such a system could support all the operations of normal databases (inserting, updating etc.) as well as providing a simple system for finding and returning sets of data in a single operation.

IBM itself did one test implementation of the relational model, PRTV, and a production one, Business System 12, both now discontinued. All other DBMS implementations usually called relational are actually SQL DBMSs. In 1968, the University of Michigan began development of the Micro DBMS relational database management system. It was used to manage very large data sets by the US Department of Labor, the Environmental Protection Agency and researchers from University of Alberta, the University of Michigan and Wayne State University. It ran on mainframe computers using Michigan Terminal System. The system remained in production until 1996.

2.3. SQL DBMS

IBM started working on a prototype system loosely based on Codd‘s concepts as System R in the early 1970s. The first version was ready in 1974/5, and work then started on multi-table systems in which the data could be split so that all of the data for a record (much of which is often optional) did not have to be stored in a single large ―chunk‖. Subsequent multi-user versions were tested by customers in 1978 and 1979, by which time a standardized query language, SQL, had been added. Codd's ideas were establishing themselves as both workable and superior to Codasyl, pushing IBM to develop a true production version of System R, known as SQL/DS, and, later, Database 2 (DB2).

Many of the people involved with INGRES became convinced of the future commercial success of such systems, and formed their own companies to commercialise the work but with an SQL interface. Sybase, Informix, Nonstop SQL and eventually Ingres itself were all being sold as offshoots to the original INGRES product in the 1980s. Even Microsoft SQL Server is actually a re-built version of Sybase, and thus, INGRES.

Stonebraker went on to apply the lessons from INGRES to develop a new database, Postgres, which is now known as PostgreSQL. PostgreSQL is often used for global mission critical applications (the .org and .info domain name registries use it as their primary data store, as do many large companies and financial institutions).

In Sweden, Codd‘s paper was also read and Mimer SQL was developed from the mid-70s at Uppsala University. In 1984, this project was consolidated into an independent enterprise. In the early 1980s, Mimer introduced transaction handling for high robustness in applications, an idea that was subsequently implemented on most other DBMS.

2.4. Object-Oriented Databases

Objects contain data, and code to manipulate that data. The entire set of The 1980s, saw a growth in how data in various databases were handled. Programmers and designers began to treat the data in their databases as objects. That is as if a person's data were in a database, that person‘s attributes, such as their address, phone number, and age, were now considered to belong to that person instead of being extraneous data. This allows for relationships between data to be relation to objects and their attributes and not to individual fields.

Another big game changer for databases in the 1980s was the focus on increasing reliability and access speeds. In 1989, two professors from the University of Michigan at Madison published an article at an ACM associated conference outlining their methods on increasing database performance. The idea was to replicate specific important and often queried information, and store it in a smaller temporary database that linked these key features back to the main database. This meant that a query could search the smaller database much quicker, rather than search the entire dataset. This eventually leads to the practice of indexing, which is used by almost every operating system from Windows to the system that operates Apple iPod devices.

3. Components of Database Management System (DBMS)

 A Database Management System (DBMS) includes four main parts: modeling language, data structure, database query language, and transaction mechanisms. We will look at these components in the subsequent units.

 Modeling Language

 The first component of a database management system is the implementation of a modeling language that serves to define the language of each database hosted via the DBMS. There are several approaches currently in use, with hierarchical, network, relational, and object examples. Essentially, the modeling language ensures the ability of the databases to communicate with the DBMS and thus operate on the system.

Data Structures

Data structures are administered by the database management system. Examples of data that are organised by this function are individual profiles or records, files, fields and their definitions, and objects such as visual media. Data structures enable DBMS to interact with the data without causing damage to the integrity of the data itself.

 Data Query Language

A third component of DBMS software is the data query language. This element is involved in maintaining the security of the database, by monitoring the use of login data, the assignment of access rights and privileges, and the definition of the criteria that must be employed to add data to the system. The data query language works with the data structures to make sure it is harder to input irrelevant data into any of the databases in use on the system.

 Transaction Mechanism

A database transaction mechanism ideally guarantees ACID properties in order to ensure data integrity despite concurrent user accesses (concurrency control), and faults (fault tolerance). It also maintains the integrity of the data in the database. The DBMS can maintain the integrity of the database by not allowing more than one user to update the same record at the same time. The DBMS can help prevent duplicate records via unique index constraints; for example, no two customers with the same customer numbers (key fields) can be entered into the database.