DATABASE MANAGEMENT SYSTEM

SUBJECT CODE : 571089

INTRODUCTION
Data constitute the building blocks of information Information is produced by processing data. Information is used to reveal the meaning of data Accurate, relevant and timely information is the key to good decision making. Good decision making is the key to organizational survival in a global environment.

DATA MANAGEMENT
Data management is a discipline that focuses on the proper generation, storage, and retrieval of data. Data management is the core activity for any business, government agency, service organization, or charity.

DATABASE
A database is a shared, integrated computer structure that stores a collection of End user data, that is, raw facts of interest to the end user. Metadata, or data about data, through which the end user data are integrated and managed. The Metadata provides a description of the data characteristics and set of relationship that link the data found within the database.

METADATA
For example, a webpage may include metadata specifying what language it's written in, what tools were used to create it, and where to go for more on the subject, allowing browsers to automatically improve the experience of users.

DATABASE
A database resembles a very well organized electronic filing cabinet.

Data Base Management System

A database management system(DBMS) is a collection of programs that manages the database structure and controls access to the data stored in the database. DBMS serves as the intermediary between the user and the database. DBMS receives all application requests and translates them into the complex operations required to fulfill those requests.

Data Base Management System(Cont.)

DBMS hides much of the databases internal complexity from the application programs and the users. The application programs might be written by a programmer using a programming language such as Visual Basic, CICS(Customer information control system), Visual C++ or it might be created through a DBMS utility program(Power Builder).

Data Base Management System(Cont.)

Examples for DBMS

DB2 SYSBASE MS ACCESS SQL SERVER ORACLE

Characteristics of DBMS
Represents complex relationship between data Controls data redundancy. Enforces user defined rules. Ensures data sharing. It has automatic and intelligent backup and recovery procedures. Data independence. It has central dictionary to store information.

Characteristics of DBMS(Cont.)
Pertaining to data and its manipulation. It has different interfaces via which user can manipulate the data. Enforces data access authorization. Maintenance of Integrity. Support for transaction control and recovery. Data abstraction. Control over Security.

Importance of DBMS
It helps make data management more efficient and effective. Its query language allows quick answers to ad hoc queries. It provides end users better access to more and better-managed data. It promotes an integrated view of the organizations operations big picture. It reduces the probability of inconsistent data

Advantages of DBMS
Improved data sharing Better data integration Minimized data inconsistency Improved data access Improved decision making Increased end user productivity

Database Environment

Evolution of DBMS

Evolution of DBMS(Cont.)
FLAT File. Flat files are data files that contain records with no structured relationships. Additional knowledge is required to interpret these files such as the file format properties. A list of names, addresses, and phone numbers written on a sheet of paper is a flat file database A text editor program may be used to implement flat file databases.

Evolution of DBMS(Cont.)
Hierarchical DBMS A DBMS is said to be hierarchical if the relationships among data in the database are established in such a way that one data item is present as the subordinate of another one. Here subordinate means that items have 'parentchild' relationships among them. The data structure "tree" is followed by the DBMS to structure the database. Most of the older DBMS such as Dbase, FoxPro are hierarchical which are rarely used nowadays.

Evolution of DBMS(Cont.)

Evolution of DBMS(Cont.)
Network DBMS A DBMS is said to be a Network DBMS if the relationships among data in the database are of type many-to-many. The relationships among many-to-many appears in the form of a network. structure of a network database is extremely complicated because of these many-to-many relationships in which one record can be used as a key of the entire database.

Evolution of DBMS(Cont.)

Evolution of DBMS(Cont.)
Relational DBMS. The term "relational database" was invented by E. F. Codd at IBM in 1970. A DBMS is said to be a Relational DBMS or RDBMS if the database relationships are treated in the form of a table. A number of RDBMSs are available, some popular examples are Oracle, Sybase, Ingress, Informix, Microsoft SQL Server, and Microsoft Access.

Evolution of DBMS(Cont.)

Evolution of DBMS(Cont.)
Object-oriented database management system An object database (also object-oriented database management system) is a database management system in which information is represented in the form of objects as used in object-oriented programming. When database capabilities are combined with object-oriented programming language capabilities, the result is an object-oriented database management system (OODBMS). OODBMS allow object-oriented programmers to develop the product, store them as objects, and replicate or modify existing objects to make new objects within the OODBMS. The database is integrated with the programming language, the programmer can maintain consistency within one environment, in that both the OODBMS and the programming language will use the same model of representation. Some object-oriented databases are designed to work well with objectoriented programming languages such as Delphi, Ruby, Python, Perl, Java, C#, Visual Basic .NET and C++.

Evolution of DBMS(Cont.)

Evolution of DBMS(Cont.)
Programmers and designers began to treat the data in their databases as objects. That is to say that 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.

Evolution of DBMS(Cont.)
Object-relational database management system (ORDBMS) An object-relational database (ORD), or objectrelational database management system, is a database management system (DBMS) similar to a relational database, but with an object-oriented database model. The basic goal for the Object-relational database is to bridge the gap between relational databases and the object-oriented modelling techniques used in programming languages.

Evolution of DBMS(Cont.)
Dataware House DBMS A data warehouse is a subject-oriented integrated time varying non-volatile collection of data in support of the management's decision-making process. A data warehouse is a centralized repository that stores data from multiple information sources and transforms them into a common, multidimensional data model for efficient querying and analysis. IBM DB2 Warehouse 9.5 - Microsoft SQL Server 2008 - Oracle Database 11g - Teradata Enterprise Data Warehouse 12.0 - Sybase IQ

Evolution of DBMS(Cont.)

Evolution of DBMS(Cont.)
Web-enabled DBMS A Web-enabled database server can be used to form a virtual community, where participants in remote locations can exchange ideas in electronic formats. Users can upload information, submit a query, update a record, take a test, or produce a report through a Web interface running off a database server Web enabled Oracle Express Server 6.0, Launched in 1996.

Evolution of DBMS(Cont.)
Duplicate Data

Evolution of DBMS(Cont.)
Order Filing System Central database Contains employee, order, inventory, pricing, and customer data

Invoicing System

DBMS

Payroll System

Evolution of DBMS(Cont.)
1st Generation: Early Database Applications
1960s:The Hierarchical and Network Models were introduced 1970s: They became dominated. A bulk of the worldwide database processing still occurs using these models, particularly, the hierarchical model.

2nd Generation: Relational Model based Systems

Originally introduced in 1970, a paper by E. F. Codd IBM Research and several universities. 1980s: Relational DBMS Products emerged.

Evolution of DBMS(Cont.)
3rd Generation: Object-oriented Applications 1990s: Object-Oriented Database Management Systems (OODBMSs) for complex data processing in CAD and other applications. Object-relational DBMSs (ORDBMSs) Extended relational systems add further capabilities (e.g. for multimedia data, XML, and other data types)

Overview of CODDs 12 rules

Codd's twelve rules are a set of thirteen rules (numbered zero to twelve) proposed by Edgar F. Codd, a pioneer of the relational model for databases. 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)

Overview of CODDs 12 rules(Cont.)

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.

Overview of CODDs 12 rules(Cont.)

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.

Overview of CODDs 12 rules(Cont.)

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.

Overview of CODDs 12 rules(Cont.)

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.

Overview of CODDs 12 rules(Cont.)

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.

Overview of CODDs 12 rules(Cont.)

Rule 5: The comprehensive data sublanguage rule The system must support at least one relational language that Has a linear syntax Can be used both interactively and within application programs. 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).

Overview of CODDs 12 rules(Cont.)

Rule 6: The view updating rule

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

Overview of CODDs 12 rules(Cont.)

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.

Overview of CODDs 12 rules(Cont.)

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.

Overview of CODDs 12 rules(Cont.)

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.

Overview of CODDs 12 rules(Cont.)

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.

Overview of CODDs 12 rules(Cont.)

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 This means a Application program that accesses the DBMS on a single computer should also work, without modification, even if the data is moved from one computer to another in a network environment.

Overview of CODDs 12 rules(Cont.)

Rule 12: The nonsubversion rule If the system provides a low-level (record-at-atime) interface, then that interface cannot be used to subvert the system, for example, bypassing a relational security or integrity constraint. All the database access must be controlled through the DBMS so that the integrity of the database cannot be compromised without the knowledge of the user.

Database Architecture
Three-Level Database Architecture External Level Conceptual Level Internal Level

Database Architecture(Cont.)
User 1
External Data View 1

User 2
View 2

User n
View 3 Mapping and independence btw external and internal levels. The way the DBMS and OS perceive the data.

The way users perceive the data

Conceptual Level Conceptual Schema Internal Schema

Internal Level

Physical Data Organization

Database

Database Architecture(Cont.)
EXTERNAL LEVEL (highest level) The users view of the database. Consists of a number of different external views of the DB Describes part of the DB for particular group of users. Provides a powerful and flexible security mechanism by hiding parts of the DB from certain users. The user is not aware of the existence of any attributes that are missing from the view. It permits users to access data in a way that is customized to their needs, so that the same data can be seen by different users in different ways, at the same time

Database Architecture(Cont.)
CONCEPTUAL LEVEL The logical structure of the entire database as seen by DBA. What data is stored in the database The relationships among the data Complete view of the data requirements of the organization, independent of any storage consideration. Represents: - ntities, attributes, relations - constraints e on data - semantic information on data - security, integrity information. Supports each external view: any data available to a user must be contained in, or derivable from the conceptual level.

Database Architecture(Cont.)
INTERNAL LEVEL Physical representation of the DB on the computer How the data is stored in the database Physical implementation of the DB to achieve optimal run time performance and storage space utilization. Storage space allocation for data and indexes Record description for storage - Record placement - Data compression, encryption.