UNIT-I

Database Systems
Data Data is nothing but some raw facts and figures. The word raw indicates that the facts have not yet been processed to reveal their meaning. Information Information is the result of processing raw data to reveal its meaning. Information should be in a meaningful format, i.e., to reveal meaning, information requires context. .g. an average temperature reading of !"# degrees does not mean much unless you also $now its context li$e. o Is this degrees are in %ahrenheit or &elsius' o Is this a machine temperature, a body temperature, or an outside air temperature. Information can be used as the foundation for decision ma$ing. (aw data must be properly formatted for storage, processing and presentation. )ome $ey points about data and information* !. Data constitute the building bloc$s of information. +. Information is produced by processing data. ,. Information is used to reveal the meaning of the data. -. .ccurate, relevant and timely information is the $ey to good decision ma$ing. #. /ood decision ma$ing is the $ey to organi0ational survival in a global environment. Introducing the database and the DBMS Database: .n organised collection of logically related data with out having any redundancy in one place is called database. . 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. +. Meta data, or data about data, through which the end user data are integrated and managed. Meta data: The meta data provide a description of the data characteristics 1eg., data types, si0es2 and the set of relationships1constraints2 that lin$ the data found with in the database. )uch as the name of the each data element 1column name2, the type of values 1numeric, text or date2 stored on each data element, whether or not the data element can be left empty and so on. DBMS: MDBMS 1/58 1/58

UNIT-I . D34) is a collection of programs that manages the database structure and controls access to the data stored in the database. Historical roots : files and file systems 3asic file terminology* Data* data is nothing but some raw facts. Field* . character or group of characters that has a specific meaning. . filed is used to define and store data. . field is nothing but a column in the table. Record* . logically connected set of one or more fields that describes a person, place or thing. It is nothing but a row in a table. File* It is a collection of related records. It is nothing but a table. Manual system or Manual File processing system: . manager of almost any small organi0ation was able to $eep trac$ of necessary data by using a manual file system. )uch a file system was traditionally composed of a collection of file folders, each properly tagged and $ept in a filing cabinet. g!* . file folder in a doctor5s office might contain patient data, one file folder for each patient. .l of the data in that file folder would describe only that particular patient5s medical history. g+* . personal manager might organi0e personal data by category of employment li$e clerical, technical, scales and administrative. Therefore a file folder labeled technical would contain data whose duties where classified as technical. .s long as a data collection was relatively small and an organi0ations managers had few reporting requirements, the manual system served its role well as a data repository. 6owever, as organi0ations grew and as reporting requirements became more complex, $eeping trac$ of data in a manual file system became more difficult. In fact, finding and using data in growing collection of file folders turned into time consuming and a difficult tas$. g* 7ust consider few questions to which a retail business owner might want answers. !. 8hat products sold well during the past wee$, month, quarter or year' +. 8hat is the current daily, wee$ly, monthly, quarterly or yearly sales volume' ,. Did the various cost categories increase, decrease or remain stable during the past wee$, month, quarter or year' The list of questions such as these tends to be long and to increase in number as an organi0ation grows. 9nfortunately, generating reports from a manual file system can be slow and difficult tas$. &omputer %ile :rocessing )ystem* The conversion from a manual file system to a matching computer file system could be technically complex. &onsequently, a new $ind of MDBMS 2/58 2/58

UNIT-I professional, $nown as a data processing ;D:< specialist, had to be hired or grown from the current staff. The D: specialist creates the necessary computer file structures, often wrote the software that managed the data with in those structures and designed the application programs that produces reports based on the file data. Initially, the computer files with in the file system were similar to the manual files. . simple example of a customer data file for a small insurance company is shown in the figure below*

The customer file shown in the above figure contains some records. ach record is composed of = fields. The records are stored in a named file. 3ecause the file in the above figure contains customer data for the insurance company, its file name is &9)T>4 (. 9sing the &9)T>4 ( files contents, the D: specialist wrote programs that produced very useful reports for the Insurance company5s sales department such as !. 4onthly summaries that showed the types and amounts of insurance sold by each agent. It can be used to analy0e each agents productivity. +. 4onthly chec$s to determine which customers must be contacted for renewal. ,. (eports that analy0ed the ratios of insurance type sold by each agent. .s time went on, the insurance company needed additional programs to produce new reports. Then the sales department and the insurance company created a file name ).? ), which helped trac$ daily sales efforts. .dditional files were created as needed to produce even more useful reports. Then, the D: specialist was as$ed to create the ./ @T file as shown in the below figure. The data in the ./ @T file were used to write chec$s, $eep trac$ of taxes paid and summari0e insurance coverage etc.,

MDBMS

3/58 3/58

UNIT-I

MDBMS

4/58 4/58

UNIT-I .s the number of files increased, a small file system li$e the one shown in the figure below evolved.

ach file in the system used its own application program to store, retrieve and modify data. ach file was owned by a particular department. .s the insurance company5s file system grew, the demand for the D: specialists programming sales grew even faster, and the D: specialists was authori0ed to hire additional programmers. :roblems with file system Data management The following are some of the problems with file system data management* !. +. ,. -. #. A. B. C. MDBMS )tructural Dependency Data Dependency %ield Definitions and @aming &onventions. Data (edundancy Data Inconsistency Data .nomalies ?ac$ of Data )haring ?engthy Development Times. 5/58 5/58

UNIT-I Structural Dependency: . file system exhibits structural dependency which means that access to a file is dependent on its structure. g* .dding a customer date of birth field to the &9)T>4 ( file. /iven this change, none of the previous programs will wor$ with the new &9)T>4 ( file structure. Therefore, all of the file system programs must be modified to conform to the new file structure. Data Dependency: ven changes in the characteristics of data, such as changing a field from integer to decimal, requires changes in all the programs that access the file. Data dependence ma$es the file system extremely cumbersome from the point of view of a programmer and database manager. %ield Definitions and @aming &onventions* )electing proper field names is also important. 4a$e sure that the field names are reasonably and descriptive. g* )uppose a field name (en represents the customer insurance renewal date, but it is not reasonably descriptive. The same column can be defined as &usD(enDDate, which indicates customer5s insurance renewal date. It can be easily understandable by the users. 8ith proper naming conventions, the file structure becomes self documenting. Data Redundancy: The Data (edundancy occurs when the same data are stored unnecessarily at different places 1The repetition of same data more than one place2. g* In the above file structures, the .gent names and phone numbers occur in both the &9)T>4 ( and ./ @T files. 3ut you need only one correct copy of the .gent name and :hone @umbers. 6aving them occur in more than one place produces data redundancy. Data Inconsistency: Data inconsistency exists when different and conflicting versions of the same data appear in different places. g* )uppose if we change an .gent phone number or address in the ./ @T file, but, if you forget to ma$e corresponding changes in the &9)T>4 ( file, then the files contain different data for the same agent. It leads to data inconsistency problems. Data nomalies: The dictionary defines anomalies as an abnormality that is some problems or errors. Data anomalies are divided into three types* !. Insertion .nomaly +. Deletion .nomaly ,. 9pdate .nomaly !ac" of Data Sharing: In computer file processing system there is no integration of data. )o we cannot share data among number of users. MDBMS 6/58 6/58

UNIT-I

!engthy De#elopment $imes: .ll application programs must be developed from the beginning because there is no any reusability of data. Role and ad#antages of DBMS $he role of DBMS: !. The D34) serves as the interface between the user and the database. +. The database structure itself is stored as a collection of files and the only way to access the data in those files is through the D34). ,. The following figure shows how a D34) acts as an interface.

-. The D34) receives all application requests and translate them into the complex operations required to fulfill those requests. #. The D34) hides much of the databases internal complexity from the application programs and users. A. The application program might be written by a programmer using a programming language such as )E?, )E? )erver, F3.@ T, &GG or 7ava. B. 6aving a D34) between the end users and the data base, it offers some important advantages* a. The D34) enables the data in the database to be shared among multiple operations or users. b. The D34) integrates the many different users of data into a single data repository.

MDBMS

7/58 7/58

UNIT-I $he ad#antages of DBMS: . D34) or database approach offers the following advantages* !. :rogram Data Independence +. 4inimal Data (edundancy ,. Improved Data &onsistency -. Improved Data )haring #. Improved :roductivity of .pplication Development A. nforcement of )tandards B. Improved Data Euality C. Improved Data .ccessibility and responsiveness =. (educed :rogram 4aintenance !". Improved Decision 4a$ing %rogram Data Independence: The separation of data descriptions 1meta data2 from the application programs that use the data is called data Independence with the database approach, data descriptions are stored in a central location called the repository. This property of database systems allows an organi0ations data to change and evolve without changing the application programs that process the data. Minimal Data Redundancy: The design goal with the database approach is that previously separated data files are integrated into a single, logical structure. )o each primary fact is recorded only once in one place in the data base. The database approach does not eliminate redundancy entirely, but it allows the designer to carefully control the type and amount of redundancy. Impro#ed Data &onsistency: 3y eliminating or controlling data redundancy we greatly reduce the opportunities for inconsistency. Impro#ed Data Sharing: . database is designed as a shared corporate resource. .uthori0ed internal and external users are granted permission to use the database, and each user ;or group of users< is provided one or more user views1it is a logical description of some portion of the database that is required by a user to perform some tas$2 to facilitate this use. Increased %roducti#ity of pplication De#elopment: . maHor advantage of the database approach is that it greatly reduces the cost and time for developing new business applications. Enforcement of Standards: 8hen the database approach is implemented with full management support, the database administration function should be granted authority and responsibility for establishing and enforcing data standards. These standards ;constraints< and procedures for accessing, updating and protecting data. MDBMS 8/58 8/58

UNIT-I Impro#ed Data 'uality: The database approach provides a number of tools and procedures to improve data quality. !. Database Designers can specify Integrity &onstraints that are enforced by the D34). +. To clean up the operational data before they are placed in the Dataware house. Impro#ed Data ccessibility and Responsi#eness: 8ith a relational data base, end users without having any programming experience can often retrieve and display the data from a database. Reduced %rogram Maintenance: )tored data can be easily maintained that is stored data must be changed frequently for a variety of reasons li$e new data items are added, data formats are changed etc., can be easily maintained. Impro#ed Decision Ma"ing: 3etter managed data and improved data access ma$e it possible to generate better quality information on which better decisions are based. $ypes of Databases . D34) can support different types of databases. )ome of them are as follows* !. .ccording to number of users +. .ccording to database locations ,. .ccording to data usage -. .ccording to the structure of data #. I4? databases ccording to number of users: .ccording to the number of users the databases are divided into two types. They are i2 )ingle 9ser Databases and ii2 4ulti 9ser Databases. Single (ser Databases: !. It supports only one user at a given time. In other words, if user J.5 is using the database, users J35 and users J&5 must wait until user J.5 is done. +. . single user database that runs on a personal computer is also called as Des$top Database. Multi (ser Databases: It supports multiple users at the same time. It is again divided into two types. They are* i2 8or$ /roup Database and ii2 nterprise Database. )or" *roup Database: 8hen the multi user Database supports a small number of users 1usually fewer than #"2 or a specific Department with in an organi0ation is called as 8or$ /roup Database. Enterprise Database: 8hen the database is used by the entire organi0ation and supports many users 1more than #", usually in !""5s2 across many departments then that database is called as nterprise Database. MDBMS 9/58 9/58

UNIT-I ccording to Database !ocations: ?ocation might also be used to classify the databases. 3ased on the locations databases are divided into two types* i2 &entralised and ii2 Distributed. &entralised Database: . database that supports data located at a single site is called as a &entralised Database. Distributed Database: . database that supports data distributed across several different sites is called as Distributed Database. ccording to Data (sage: The most popular way of classifying databases today, however, is based on how they will be used and on the time sensitivity of the information gathered from them. g* Transactions such as product sales, payments and supply purchases reflect critical day to day operations. )uch transactions might be recorded accurately and immediately. .ccording to data usage databases are divided into two types* i2 >perational Database ii2 Data 8are 6ouse +perational Database: . database that is designed to support a company5s day to day operation is classified as an operational database. It is also called Transactional or :roductional database. Data )are House: It can store data derived from different sources in an organi0ation. ccording to the structure of the data: Databases can also be classified to reflect the degree to which the data are structured. These are divided into* i2 9nstructured Database ii2 )tructured Database iii2 )emi )tructured Database (nstructured Database: It contains the data in their original 1raw2 state, i.e., in the format in which they were collected. Structured Database: These are the result of ta$ing unstructured data and formatting such data to facilitate, storage, use and the generation of information 1processed raw data2. )emi )tructured Database* These are the data that have already been processed to some extent. ,M! Databases: 9nstructured and )emi )tructured data storage and management needs are being addressed through a new generation of data bases $nown as I4? data bases. .n I4? database supports the storage and management of )emi )tructured I4? data. ,M! -E.tensible Mar"up !anguage/ MDBMS 10/58 10/58

UNIT-I It is a special language used to represent and manipulate data elements in a textual format.

MDBMS

11/58 11/58

UNIT-I 0arious components of Data Base En#ironment: The term database system refers to an organi0ation of components that define and regulate the collection, storage, management and use of data with in a database environment. %rom a general management point of view, the database system is composed of maHor components as shown in the figure.

The database system environment has the following components* !. 6ardware +. )oftware ,. :eople -. :rocedures #. Data Hard1are: 6ardware refers to all of the systems physical devices. %or example computers 1micro computers, wor$ stations, servers and mainframe computers2, storage devices, printers, networ$ devices 16ubs, (outers, )witches, %iber >ptics2 and other devices. Soft1are: &ollection of programs or instructions or commands to perform a tas$ is called software. To ma$e the database system function fully, three types of software are needed. They are !. >) K >perating )ystem )oftware +. D34) software ,. .pplication :rograms and 9tility )oftware

MDBMS

12/58 12/58

UNIT-I +perating System Soft1are: It manages all hardware components and ma$es it possible for all other software to run on the computers. g* 4icrosoft 8indows, ?inux, 9nix etc., DBMS Soft1are: It manages the Database with in the database system. g* )E?, 4icrosoft )E? )erver, >racle &orporations, I345s D3+ etc., pplication %rograms and (tility Soft1are: These are used to access and manipulate data in the database. These are also used for generating reports, tabulations and other information. %eople: This component includes all users of the database system. >n the basis of primary Hob function five types of users can be identified in a database system. They are* !. )ystem .dministrators +. Database .dministrators ,. Database Designers -. )ystem .nalysts and :rogrammers #. nd 9sers. System dministrators: This person supervises the database systems general operations. Database dministrators: They are also $nown as D3.s. These persons manage the D34) and ensure that the database is functioning properly. Database Designers: The persons who design the database structure of the organi0ation. System nalysts and %rogrammers: These people design and implement the application programs. They design and create the data entry screens 1forms2, reports and procedures through which end users access and manipulate the data in a data base. End (sers: These are the people who use the application programs to run the organi0ations daily operations. %rocedures: These are the instructions and rules that govern the design and use of the database system. Data: The word data indicates the collection of facts stored in the database. Data are the raw material from which information is generated.

MDBMS

13/58 13/58

UNIT-I Functions of DBMS . D34) performs several functions which are used for the integrity and consistency of the data in the database. They are* !. Data Dictionary 4anagement +. Data )torage 4anagement ,. Data Transformation and :resentation -. )ecurity 4anagement #. 4ulti 9ser .ccess &ontrol A. 3ac$up and (ecovery 4anagement B. Data Integrity 4anagement C. Database .ccess ?anguages and .pplication :rogramming Interfaces =. Database &ommunication Interfaces Data Dictionary Management: The D34) stores definitions of the data elements and their relationships in a data dictionary. .ny changes made in a database structure are automatically recorded in the data dictionary. Data Storage Management: The D34) creates and manages the complex structure required for data storage. . modern D34) 14D34)2 provides storage not only for the data, but also for related data entry forms, report definition, data validation rules, procedural code, structures to handle video and picture formats and so on. Data $ransformation and %resentation: The D34) transforms entered data into required data structures. The D34) formats the physically retrieved data to ma$e it confirm to the users logical expectations. Security Management: The D34) creates a security system that enforces users security. )ecurity rules determine which users can access the database, which data items each user can access, and which data operations 1read, add, delete or modify2, the user can perform. This is especially important in multi user database systems. .ll database users may be authenticated to the D34) through a user name and password. Multi (ser ccess &ontrol: 4ultiple users can access the D34) at the same time without waiting. Bac"up and Reco#ery Management: The D34) provides bac$up and data recovery to ensure data safety and integrity. 3ac$up means maintaining a duplicate copy of the original database that is copying the database into some other systems or to some other external secondary storage devices. (ecovery management deals with the recovery of the database after a failure such as bad sector in the dis$, virus attac$s or a power failure. Data Integrity Management:

MDBMS

14/58 14/58

UNIT-I The D34) promotes and enforces integrity rules, thus minimi0es data redundancy and maximi0es data consistency. The data relationships stored in the data dictionary are used to enforce data integrity.

MDBMS

15/58 15/58

UNIT-I Database ccess !anguages and pplication %rogramming Interfaces: !. The D34) provides data access through a Euery ?anguage. +. . Euery ?anguage is a nonLprocedural that is the users specify what must be done without having to specify how it is to be done. ,. )E? is used to access the data in a database through the D34). -. The D34) also provides application programming interfaces to procedural languages such as &>3>?, &, &GG, 7ava, F3.@ T etc., Database &ommunication Interfaces: &urrent generation D34) can accept end user request via multiple, different networ$ environments. %or example, the D34) might provide access to the database via the internet through the use of web browsers. Disad#antages of Database pproach

.lthough the database system yields considerable advantages over previous data management approaches, database systems due carry significant disadvantages. )ome of them are* !. Increased &osts +. 4anagement &omplexity ,. 4aintaining &urrency -. Fendor Dependency #. %requent 9pgrade or (eplacement &ycles Increase &osts: Database systems require hardware and software and highly s$illed personnel. The cost of maintaining the hardware, software and personnel required to operate and manage a database system. )o, we have to pay amounts for each thing. Management &omple.ity: The changes introduced by the adoption of a database system must be properly managed to ensure that they help advance the companies obHectives. Maintaining &urrency: To maximi0e the efficiency of the database system, one must $eep the system current. Therefore one must perform frequent updates and apply the latest patches and security measures to all components because database technology advances rapidly. :ersonnel training costs tend to be significant. 0endor Dependency: /iven the heavy investment in technology and personnel training, companies might be reluctant to change the database vendors. .s a consequence, vendors are less li$ely to offer pricing point advantages to existing customers, and those customers might be limited in their choice of database system components. Fre2uent (pgrade or Replacement &ycles: D34) vendors upgrade their products by adding new functionality. )uch new features often come bundled in new upgrade versions of software. )ome of these versions require hardware upgrades. @ot only MDBMS 16/58 16/58

UNIT-I do the upgrade themselves, cost, money but it also costs money to train database users and administrators to properly use and mange the new features.

MDBMS

17/58 17/58

UNIT-I )hy database design is important3 !. Database design refers to the activities that focus on the design of the database structure that will be used to store and mange end user data. +. :roper database design requires the designer to identify the databases expected use. ,. Databases can be designed to be used in centrali0ed, distributed, single or multi user environments. ach approach requires different database designs. -. . well designed database facilitates data management and generates accurate and valuable information. #. . poorly designed database leads to bad decision ma$ing and bad decision ma$ing can lead to the failure of an organi0ation.

MDBMS

18/58 18/58

UNIT-I &hapter K +

Data Models
Data modeling and Data Models Database design focuses on how the database structure will be used to store and manage end user data. . Data 4odel is a relatively simple representation, usually graphical, of more complex real world data structures. In general terms, a model is an abstraction of a more complex real world obHect or event. 8ithin the database environment, a data model represents data structures and their characteristics, relations, constraints, transformations and other constructs with the purpose of supporting a specific problem domain. Data Models . model is a representation of reality, Jreal world5 obHects and events, and their associations. It is an abstraction that concentrates on the essential, inherent aspects of an organi0ation. Data 4odel can be defined as an integrated collection of concepts for describing and manipulating data, relationships between data, and constraints on the data in an organi0ation. $he importance of Data Models !. Data models can facilitate interaction among the designer, application programmers and the end users. +. . well development data model can even foster improved understanding of the organi0ation for which the database design is developed. ,. Data constitute the most basic information units employed by a system. .pplications are created to manage data and to help transform data into information. -. Data are viewed in different ways by different people, for example, contrast the ;data< view of a company manager with that of a company cler$. .lthough the manager and the cler$ both wor$ for the same company, the manager is more li$ely to have an enterpriseLwide view of company data than the cler$. #. .pplication programmers have yet another view of data, being more concerned with data location, formatting and specific reporting requirements. 3asically, application programmers translate company policies and procedures from a variety of sources into appropriate interfaces 1forms, tables2, reports and queries. A. 8hen a good database blue print is available then it is very easy to implement database approach. Data Model Basic Building Bloc"s The basic building bloc$s of all data models* !. ntities +. .ttributes ,. (elationships MDBMS 19/58 19/58

UNIT-I -. &onstraints 45 Entity: .n entity is anything 1a person, a place, a device or an event2 about which data are to be collected and stored. ntities may be physical obHects, such as customers or products, but entities may also be abstractions, such as flight routes or musical concerts. 65 ttribute: .n attribute is a characteristic of an entity. %or example, a )T9D @T entity would be described by attributes such as (no, )name, .ddress, etc. .ttributes are the equivalent of fields in file systems. 75 Relationship: . relationship describes an association among entities. %or example, a relationship exists between students and courses that can be described as follows* a student can Hoin in any one course and a course can have many students. Types of (elationships* !. >ne to >ne 1!..! M !*!2 relationships +. >ne to 4any 1!..NM!*42 relationships ,. 4any to 4any 1N..NM@*4M4*@2 relationships +ne to Many Relationships 84:M9 . painter paints many different paintings, but each one of them is painted by only one painter. Thus, the painter ;the one< is related to the paintings ;the many<. Therefore database designers label the relationship :.I@T ( paints :.I@TI@/ as 4:M. +ne to +ne Relationship 84:49 ach patient assigned a single, bed and each bed is assigned for only patient. Therefore, the relationship, :.TI @T assigned 3 D is label as 4:4. Many to Many Relationships 8M::9 .n employee may learn many Hob s$ills and each Hob s$ill may be learned by many students. Database designers label the relationship 4:?>O learns )PI?? as ::M or M::. ;5 &onstraints: . constraint is a rule or a restriction placed on the data. &onstraints are important because they help to ensure data integrity. &onstraints are normally expressed in the form of rules. %or example !. mployee name should be in capital letters +. mployee number should start with an alphabet. Business Rules . Business Rule is a brief, precise description of a policy, procedure or principle or a statement within a specific organi0ation. 3usiness (ules can apply to any organi0ation large or small business, a government unit or a research laboratory that stores and uses data to generate information. :roperly written business rules are used to define entities, attributes, relationships and constraints. %or example !. .n .gent can serve many customers, and each customer can be served by only one .gent. MDBMS 20/58 20/58

UNIT-I i.e., ./ @T serves &9)T>4 (. +. . customer may generate many invoices. .n invoice is generated by only one customer. ,. . training session cannot be scheduled for fewer than ten employees or for more than ," employees. Disco#ering Business Rules: The main sources of business rules are company managers, policy ma$ers, department managers and written documentation such as a company5s procedures, standards or operation manuals. . faster and more direct source of business rules is direct interviews with end users. .dvantages of discovering business rules* !. To help standardi0e the company5s view of data +. It is communication tool between users and designers ,. They allow the designer to understand the natural role and scope of the data -. They allow the designer to understand business processes. #. They allow the designer to develop appropriate relationship participation rules and constraints and to create an accurate data model. $ranslating Business Rules into Data Model &omponents: 3usiness rules set the stage for the proper identification of entities, attributes, relationships and constraints. .s a general rule, a noun in a business rule will translate into an entity in the data model, and a verb 1active or passive2 associating nouns will translate into a relationship among the entities. g* The business rule . customer may generate many invoices contains two nouns 1customer, invoices2 and a verb 1generate2 that associates the nouns. E#olution of Data Models The quest for better data management has led to several different models that attempt to resolve the file system5s critical shortcomings.
/eneration %irst Time !=A"sL!=B"s 4odel %ile )ystem xamples F4)MF).4 &omments 9sed mainly on I34 mainframe systems 4anaged records, not relationships arly database systems @avigational access &onceptual simplicity ntity (elationship modeling and support for relational data modeling )upport complex data xtended relational products )upport obHects and data warehousing >rgani0ation management unstructured data and of

)econd Third

!=B"s 4idL!=B"s to present

6ierarchical and @etwor$ Data 4odel (elational Data 4odel

I4) .D.3.) ID)LII D3+ >racle 4) )E?Lserver 4y)E? Fersant %irst>bHects.@e t >bHectivityMD3 D3+ 9D3 >racle !"g DbI4? Tamino D3+ 9D3

%ourth

4idL!=C"s to present

>bHect >riented xtended (elational I4?

@ext /eneration

:resent %uture

to

MDBMS

21/58 21/58

UNIT-I
>racle !"g 4) )E? )erver (elational and obHect models add support for I4? documents

Hierarchical Data Models: The 6ierarchical model was developed in !=A"s to manage large amounts of data for complex manufacturing proHects such as the .pollo (oc$et that landed on the moon in !=A=. !. It5s basic structure is represented by an upside down tree +. The 6ierarchical structure contains levels or segments ,. . segment is equivalent of a file systems record type

-. 8ithin the hierarchy, the top layer the root 1level "2 is perceived as the parent of the segment directly beneath it. #. In the above figure, the root segment is the parent of the level ! segment, which in turn are the parents of the level + segment etc., A. The segments below other segments are the children of the segment above B. In short, the hierarchical model shows a set of >ne to 4any relationship between a parent and its children segments C. ach parent can have many children, but each child has only one parent d#antages: !. It promotes data sharing +. :arent &hild relationship promotes conceptual simplicity ,. :arent &hild relationship promotes data integrity -. It is efficient with !*4 relationship Disad#antages: !. It is complex to implement +. &omplex application development and management ,. There are no 4any to 4any relationships MDBMS 22/58 22/58

UNIT-I :et1or" Data Models: The networ$ data model was created to represent the more complex data relationships more efficiently than the hierarchical model The networ$ model was created to improve performance and to impose a database standards database

To establish database standards, the &onference >n D.ta )Ostem5s ?anaguages 1&>D.)O?2 created the D3 Tas$ /roup1D3T/2 in the late !=A"s The D3T/ was charged to define standard specifications for an environment that would facilitate database creation and data manipulation. The final D3T/ report contained specifications for three crucial database components* o The )chema, which is the conceptual organi0ation of the entire database as viewed by the database administrator. o The )ubschema, which defines the portion of the database seen by the application programs that actually produce the desired information from the data contained within the database. o . data management language 1D4?2, that defines the environment in which data can be managed. To produce the desired standardi0ation for each of the three components, the D3T/ specified three distinct D4? components. o . schema data definition language 1DD?2, which enables the database administrator to define the schema components. o . subschema DD?, which allows the application programs to define the database components that will be used by the application. o . data manipulation language to wor$ with the data in the database. The networ$ data base is a collection of records in !*4 relationships. 6owever, the networ$ model allows a record to have more than one parent i.e., it allows to maintain 4any to 4any relationships. In networ$ database terminology, a relationship is called a set. ach set is composed of atleast two record types one owner record;parent< and a member record ;child<. . set presents a !*4 relationship between the owner and the member. .n example of such a relationship is shown in the figure.

MDBMS

23/58 23/58

UNIT-I

The above figure illustrates a networ$ data model for a typical sales organi0ation. In this model &9)T>4 (, ).? )( :, I@F>I& , I@FD?I@ , :.O4 @T and :(>D9&T represent record types. I@F>I& is owned by both ).? )( : and &9)T>4 (. )imilarly I@FD?I@ has two owners :(>D9&T and I@F>I& . The networ$ model can also include one owner relationship such as &9)T>4 ( ma$es :.O4 @T. d#antages: !. It handles more relationship types such as 4*@ and multi parent +. Data access is more flexible than the hierarchical model ,. Data owner and member relationship promotes data integrity -. It has database standards Disad#antages: !. )ystem complexity limits efficiency +. The lac$ of ad hoc query capability ,. ?imited data independence Relational Data Model: The (elational model was introduced by .%.&odd in !=B" The relational model foundation is a mathematical concept $nown as a relation . relation is compared to a table in mathematics which consists of rows and columns ach row in a relation 1table2 is called a Tuple 1record or instance or occurrence2 ach column represents an attribute 1field or feature of an entity2 (elation1Table2 is called as an entity1obHect2 The relational data model is implemented through a (D34) )ome of the relational database softwares are* >racle, D3+, )E?, )E? )erver, 4y)E?, 4)L.ccess etc., The relational data model is easier to understand and implement Tables are related to each other through the sharing of a common attribute. %or example, the &9)T>4 ( table in figure might contain a sales agent5s number that is also contained in the ./ @T table. MDBMS 24/58 24/58

UNIT-I

The common column1.gentD&ode2 between the &9)T>4 ( and ./ @T tables enables you to match the &9)T>4 ( to his sales agent even though the customer data is stored in one table and sales representative data stored in another table. The relationship type 1!*!, !*4, @*42 is often shown in a relational schema as show in the figure.

Relational Diagram: It is a representation of the relational database5s entities, attributes within those entities and the relationships between those entities. !. In the above example, it uses the !*4 relationship and this diagram is produced by using the 4)L.ccess )oftware. +. The reason for the relational data models improvement is its powerful and flexible query language. ,. %or most relational database software, the query language is )E?, which allows the user to specify what must be done without specifying how it must be done. -. The (D34) uses )E? to translate user queries in to instructions for retrieving the requested data.

MDBMS

25/58 25/58

UNIT-I d#antages: !. )tructural Independence i.e., changes in a table structure do not effect the data access or application programs +. Tabular view of data improves conceptual simplicity, easier database design, implementation, maintenance and use ,. .d hoc query capability is based on )E? Disad#antages: !. The (D34) requires substantial hardware and system software overhead +. 9ntrained people can misuse the data of a database which leads to some anomalies. E-R Data Model: :eter &hen first introduced the L( Data 4odel in !=BA. It was the graphical representation of entities and their relationships in a database structure. L( models are normally represented in an entity relationship diagram ;D(D<, which uses graphical representations to model database components. &omponents of E-R Model: The L( model is based on the following components* !. ntity +. .ttribute ,. (elationships Entity: .n entity is nothing but an obHect li$e a person, a place, a device or an event about which data are to be collected and store. !. ntity names should be specified in capital letters. +. ntity name should be a noun in singular form. ,. ntity is represented in the (D by a rectangular, also $nown as an ntity 3ox. -. The entity name is written in the centre of the (ectangle. g* &9)T>(4 (, )T9D @T, 4:?>O etc., 9sually, when applying the (D to the relational model, an entity is mapped to a relational table. ach row in the relational table is $nown as an entity instance or entity occurrence in the L( 4odel. ttribute: .ttributes describe the characteristics or features of an entity. %or example a )T9D @T entity would be described by attributes such as )tuD@o, )tuD@ame, )tuD.ddr, etc. Relationships: . relationship describes an association among entities. 4ost relationships describe associations between two entities. (elationships are divided into three types* !. >ne to 4any ;!*4< +. 4any to 4any ;4*4 or 4*@< ,. >ne to >ne ;!*!< The name of the relationship usually is an active or passive verb. %or example* !. . :.I@T ( paints may :.I@TI@/) +. .n 4:?>O learns many )PI??) MDBMS 26/58 26/58

UNIT-I ,. .n 4:?>O manages a )T>( The below figures shows the different types of relationships using two (L@otations* !. The original &hen @otation +. &row5s %oot @otation

&hen :otation: !. The chen notation is based on :eter &hen ?and mar$ +. In this notation, the connectivities are written next to each entity box ,. (elationships are represented by a diamond connected to the related entities through a relationship line -. The relationship name is written inside the diamond &ro1<s Foot :otation: !. The name &row5s %oot is derived from the J, pronged5 symbol used to represent the many side of the relationship +. The connectivities are represented by symbols. %or example, the ! is represented by a short line segment1Q2 and the 4any is represented by the J,Lpronged5 crow5s foot symbol1 2 ,. The relationship name is written above the relationship line. d#antages: !. Fisual model yields conceptual simplicity +. Fisual representation ma$es it an effective communication tool ,. It is integrated with relational model Disad#antages: !. There is limited constraint representation +. There is limited relationship representation ,. ?oss of information content occurs when attributes are removed from entities to avoid crowded display.

MDBMS

27/58 27/58

UNIT-I +b=ect +riented Data Model: In the >bHect >riented Data 4odel 1>>D42, both data and their relationships are combined in a single structure $nown as an obHect. The >>D4 is the basis for the >bHect >riented Data 3ase 4anagement )ystem 1>>D34)2. .n obHect includes information about relationships with their obHects. >bHect also contain all operations that can be performed on it, such as changing its data values, finding a specific data value, printing data values etc. >bHect includes data, various types of relationships and operational procedures. &omponents of ++DM: The >>D4 is based on the following five components* !. >bHect +. .ttributes ,. &lass -. &lass 6ierarchy #. Inheritance +b=ect: .n obHect is an abstraction of a real world entity. That is an obHect may be considered equivalent to an L( models entity. g* )T9D @T, 4:?>O etc. ttribute: .ttributes describe the properties of an obHect. g* . &9)T>4 ( obHect includes the attributes &ustDID, &ustD@ame, &ustD:hone etc. &lass: !. . class is a collection of similar obHects with shared structure 1attributes2 and behaviour1methods2 +. . class contains a set of procedures $nown as methods ,. . class5s method represent a real world action such as* a. %inding a selected :erson5s name b. &hanging a :erson5s name c. :rinting a :erson5s address &lass Hierarchy: &lasses are organi0ed in a class hierarchy. The class hierarchy resembles on upside down tree in which each class has only one parent. %or example the &9)T>4 ( class and the 4:?>O class share a parent : ()>@ class. Inheritance: Inheritance is the ability of an obHect with in the class hierarchy to inherit the attributes and methods of the classes above it. g* Two classes &9)T>4 ( and 4:?>O can be created as subclasses from the super class : ()>@. In this case, &9)T>4 ( and 4:?>O will inherit all attributes and methods from : ()>@. >>D45s are represented using 9nified 4odeling ?anguage 194?2 class diagrams. 94? class diagrams are used to represent data and their relationships with I the larger 94? >bHect >riented )ystems.

MDBMS

28/58 28/58

UNIT-I g* To illustrate the main concepts of the >>D4, let us use a simple invoicing problem. In this case, invoices are generated by &9)T>4 (s, each invoice references one or more lines, and each line represents on item purchased by a &9)T>4 (. The below figure illustrates the obHect representation for this simple invoicing problem, as well as the equivalent 94? diagram and L( model.

!. The obHect representation of the I@F>I& includes all related obHects with in the same obHect box. The connectivities 1! and 42 indicate the relationship of the related obHects to the I@F>I& . %or example, the ! next to the &9)T>4 ( obHect indicates that each I@F>I& is related to only one &9)T>4 (. The 4 next to the ?I@ obHect indicates that I@F>I& contains many ?I@ s. +. The 94? class diagram uses three separate obHect classes 1&9)T>4 (, I@F>I& and ?I@ 2 and two relationships to represent this simple invoicing problem. The relationship connectivities are represented by the !..! 1one and only one2, "..N10ero or many2. !..N 1one or many2 symbols. ,. The L( model also uses three separate entities and two relationships to represent this simple invoice problem. d#antages: !. Fisual representation +. Inheritance promotes data integrity Disad#antages: !. 6igh system overhead slows transactions +. It is a complex navigational system Data Models: summary In the evolution of data models, there are some common characteristics that data models must have in order to widely accepted* . data model must show some degree of conceptual simplicity without compromising the semantic completeness of the database. . data model must represent the real world as closely as possible. MDBMS 29/58 29/58

UNIT-I (epresentation of the real world transformations1behaviour2 must be in compliance with the consistency and integrity characteristics of any data model.

ach new data model capitali0es on the shortcomings of previous models. The networ$ model replaced the hierarchical model because the former made it much easier to represent complex 1many to many2 relationships. In turn, the relational model offers several advantages over the hierarchical and networ$ models through its simpler data representation, superior data independence, and easy to use query language.

MDBMS

30/58 30/58

UNIT-I d#antages and Disad#antages of #arious Database Models

Data 4odel 6ierarchical Data Independence Oes )tructural Independenc e @o .dvantages !. It promotes data sharing +. :arentM&hild relationship promotes conceptual simplicity ,. Database security is provided and enforced by D34) -. :arentM&hild relationship promotes data integrity #. It is efficient with !*4 relationships Disadvantages !. &omplex implementation requires $nowledge of physical data storage characteristics +. &omplex application development, management and use ,. &hanges in structure require changes in all application programs -. There are implementation limitations1no multiparent or 4*@ relationships2 #. @o data definition and manipulation language in the D34) A. There is a lac$ of standards !. )ystem complexity limits efficiencyL still a navigational system +. @avigational system yields complex implementation, application development, and management ,. )trucutural changes require changes in all application programs

@etwor$

Oes

@o

!. &onceptual simplicity is at least equal to that of the hierarchical model +. It handles more relationship types, such as 4*@ and multiparent ,. Data access is more flexible than in hierarchical and file system models -. Data ownerMmember relationship promotes data integrity #. It includes data definition and manipulation languages in D34) A. There is conformance to standards

MDBMS

31/58

31/58

UNIT-I
(elational Oes Oes !. )tructural independence is promoted by the use of independent tables. &hanges in a table5s structure do not affect data access or application programs. +. Tabular view substantially improves conceptual design, implementation, management, and use. ,. .d hoc query capability is based on )E?. -. :owerful (D34) isolates the end user from physical level details and improves implementation and management simplicity. !. Fisual modeling yields exceptional conceptual simplicity. +. Fisual representation ma$es it an effective communication tool. ,. It is integrated with dominant relational model. !. The (D34) requires substantial hardware and system software overhead. +. &onceptual simplicity gives relatively untrained people the tools to use a good system poorly and if unchec$ed, it may produce the same data anomalies found in file systems. ,. It may promote islands of information problems as individuals and departments can easily develop their own applications. !. There is limited constraint representation. +. There is limited relationship representation. ,. There is no data manipulation language. -. ?oss of information content occurs when attributes are removed from entities to avoid crowded displays. !. )low development of standards caused vendors to supply their own enhancements, thus eliminating a widely accepted standard. +. It is a complex navigational system. ,. There is a steep learning curve. -. 6igh system overhead slows transactions.

ntity (elationshi p

Oes

Oes

>bHect oriented

Oes

Oes

!. )emantic content is added. +. Fisual representation includes semantic content. ,. Inheritance promotes data integrity.

MDBMS

32/58

32/58

UNIT-I 3asic terminology used by the various data models (eal 8orld . group of vendors . single Fendor The contact name The vendor identifier xample Fendor %ile cabinet /lobal supplies Fen$ateswar a !!! %ile :rocessing %ile (ecord %ield Index 6ierarchical 4odel )egment type )egment occurrence )egment field )equence field @etwor$ 4odel (ecord type &urrent (ecord (ecord %ield (ecord $ey (elational 4odel Table (ow 1tuple2 Table attribute Pey ( 4odel ntity )et ntity occurrence ntity attribute ntity identifier >> 4odel &lass >bHect instance >bHect attribute >bHect identifier

MDBMS

33/58

33/58

UNIT-I Degrees of Data bstraction

%or the system to be usable, it must retrieve data efficiently. The need for efficiency has led designers to use complex data structures to represent data in the database. )ince many databaseLsystems users are not computer trained, developers hide the complexity from users through several levels of abstraction, to simplify users5 interactions with the system* %hysical !e#el : The lowest level of abstraction describes how the data are actually stored. The physical level describes complex lowL level data structures in detail. !ogical !e#el : The nextLhigher level of abstraction describes what data are stored in the database, and what relationships exist among those data. The logical level thus describes the entire database in terms of a small number of relatively simple structures. .lthough implementation of the simple structures at the logical level may involve complex physicalLlevel structures, the user of the logical level does not need to be aware of this complexity. Database administrators, who must decide what information to $eep in the database, use the logical level of abstraction.

The three levels of data abstraction 0ie1 !e#el : The highest level of abstraction describes only part of the entire database. ven though the logical level uses simpler structures, complexity remains because of the variety of information stored in a large database. 4any users of the database system do not need all this informationR instead, they need to access only a part of the database. The view level of abstraction exists to simplify their interaction with the system. The system may provide many views for the same database.

MDBMS 34/58

34/58

UNIT-I

Data Abstraction
1. The major purpo e o! a "a#a$a e % #em & #o pro'&"e u er (&#h a) abstract view o! #he % #em. The % #em h&"e *er#a&) "e#a&+ o! ho( "a#a & #ore" a)" *rea#e" a)" ma&)#a&)e"

,omp+e-&#% hou+" $e h&""e) !rom "a#a$a e u er . 2. There are e'era+ +e'e+ o! a$ #ra*#&o). 1. /h% &*a+ 0e'e+. 1o( #he "a#a are #ore". 2.3. &)"e-4 B-#ree4 ha h&)3. 0o(e # +e'e+ o! a$ #ra*#&o). ,omp+e- +o(-+e'e+ #ru*#ure "e *r&$e" &) "e#a&+. 2. ,o)*ep#ua+ 0e'e+. Ne-# h&3he # +e'e+ o! a$ #ra*#&o). De *r&$e what "a#a are #ore". De *r&$e #he re+a#&o) h&p amo)3 "a#a. Da#a$a e a"m&)& #ra#or +e'e+. 3. 5&e( 0e'e+. 1&3he # +e'e+. De *r&$e part o! #he "a#a$a e !or a par#&*u+ar 3roup o! u er . ,a) $e ma)% "&!!ere)# '&e( o! a "a#a$a e. 2.3. #e++er &) a $a)6 3e# a '&e( o! *u #omer a**ou)# 4 $u# )o# o! pa%ro++ "a#a. 7&3ure &++u #ra#e #he #hree +e'e+ .

MDBMS 35/58

35/58

UNIT-I . data model comprises of three components* S . structural part> consisting of a set of rules according to which databases can be constructed. S . manipulati#e part> defining the types of operation that are allowed on the data 1this includes the operations that are used for updating or retrieving data from the database and for changing the structure of the database2. S :ossibly a set of integrity rules, which ensures that the data is accurate. The purpose of a data model is to represent data and to ma$e the data understandable. There have been many data models proposed in the literature. They fall into three broad categories* S >bHect 3ased Data 4odels S :hysical Data 4odels S (ecord 3ased Data 4odels The obHect based and record based data models are used to describe data at the conceptual and external levels, the physical data model is used to describe data at the internal level. +b=ect Based Data Models >bHect based data models use concepts such as entities, attributes, and relationships. .n entity is a distinct obHect 1a person, place, concept, event2 in the organi0ation that is to be represented in the database. .n attribute is a property that describes some aspect of the obHect that we wish to record, and a relationship is an association between entities. )ome of the more common types of obHect based data model are* S ntityT(elationship S >bHect >riented The ntityL(elationship model has emerged as one of the main techniques for modeling database design and forms the basis for the database design methodology. The obHect oriented data model extends the definition of an entity to include, not only the attributes that describe the state of the obHect but also the actions that are associated with the obHect, that is, its behavior. %hysical Data Models :hysical data models describe how data is stored in the computer, representing information such as record structures, record ordering, and access paths. There are not as many physical data models as logical data models, the most common one being the 9nifying 4odel. Record Based !ogical Models (ecord based logical models are used in describing data at the logical and view levels. In contrast to obHect based data models, they are used to specify the overall logical structure of the database and to provide a higherLlevel description of the implementation. The three most widely accepted record based data models are* S 6ierarchical 4odel S @etwor$ 4odel MDBMS 36/58 36/58

UNIT-I S (elational 4odel

MDBMS 37/58

37/58

UNIT-I &hapterL,

$he Relational Database Model

The database structures required by both the hierarchical and networ$ database models often become complicated enough to diminish efficient database design. The relational data model changed all of that by allowing the designer to focus on the logical representation of the data and its relationships, rather than on the physical storage details. The relational model enables you to view data logically rather than physically. The practical significance of ta$ing the logical view is that it serves as a reminder of the simple file concept of data storage. .lthough the use of a table, quite unli$e that of a file, has the advantages of structural and data independence, a table does resemble a file from a conceptual point of view. ?ogical simplicity tends to yield simple and effective database design methodologies. $ables -relation/ and their characteristics The logical view of the database is facilitated by the creation of data relationships based on a logical construct $nown as a relation. . table is perceived as a two dimensional structure composed of rows and columns. . table is also called a relation. . table contains a group of related entity occurrences that is, an entity set. %or example a )T9D @T table contains a collection of entity occurrences, each representing a student. The terms entity set and table are often used interchangeably. &haracteristics of a Relational $able: !. . table is perceived as a twoLdimensional structure composed of rows and columns. +. ach table row 1tuple2 represents a single entity occurrence within the entity set. ,. ach table column represents an attribute and each column has a distinct name. -. ach row and column intersection represents a single data value. #. .ll values in a column must conform to the same data format. A. ach column has a specific range of values $nown as the attribute domain. B. The order of rows and columns is immaterial to the D34). C. ach table must have an attribute or a combination of attributes that uniquely identifies each row i.e., each table must have a primary $ey. ?eys In the relational model, $eys are important because they are used to ensure that each row in a table is uniquely identifiable and as well as they establish relationships among tables and ensure the integrity of the data. . $ey consists of one or more attributes that determine other attributes. %or example student num identifies all of the student attributes, such as name, dob, group studying etc.

MDBMS 38/58

38/58

UNIT-I

The $ey5s role is based on the concept of determination. In the context of a database table, the statement . determines 3 indicates that if you $now the value of attribute ., you can loo$ up 1determine2 the value of attribute 3. %or example, $nowing the )tuD@um in the )T9D @T table means that you are able to loo$ up 1determine2 that student5s name, average, phone number and so on. The short hand notation for . determines 3 is . 3. If . determines 3,&,D, then . 3,&,D. The principle of determination is very important because it is used in the definition of a central relational database concept $nown as functional dependence. $he attribute B is functionally dependent on the attribute if each #alue in column a determines one and only one #alue in column B5 The functional dependence definition can be generali0ed to cover the case in which the determining attribute values occur more than once in a table. %unctional dependence can then be defined in this way* ttribute determines attribute B -i5e5> B is functionally dependent on / if all of the ro1s in the table that agree in #alue for attribute also agree in #alue of attribute B5 %or example, student classification based on hours completed 6ours &lassification &ompleted U," %r ,"L#= )o A"LC= 7r VW=" )r Therefore, one can write * )tuDhours )tuDclass MDBMS 39/58 39/58

UNIT-I 3ut the specific number of hours is not dependent on the classification. The classification1)tuDclass2 does not determine one and only one value for completed hours 1)tuDhours2. .ny attribute that is part of a $ey is $nown as $ey attribute. The combination of last name, first name, initial and home phone is very li$ely to produce unique matches for the remaining attributes. %or example )tuDlname, )tuDfname, )tuDinit, )tuDphone )tuDhrs, )tuDclass 8ith the possible existence of a composite $ey, the notion of functional dependence can be further refined by specifying full functional dependence* If the attribute -B/ is functionally dependent on a composite "ey - / but not on any subset of that composite "ey> the attribute -B/ is fully functionally dependent on - /5 8ithin the broad $ey classification, several speciali0ed $eys can be defined. %or example, a super $ey is any $ey that uniquely identifies each row. In short, the super $ey functionally determines all of a row5s attributes. In the )T9D @T table, the super$ey could be any of the following* )tuD@um )tuD@um, )tuD?name )tuD@um, )tuD?name, )tuDInit . relational database can also be represented by a relational schema. . relational schema is a textual representation of the database tables where each table is listed by its name followed by the list of its attributes in parentheses. The primary $ey attribute1s2 is 1are2 underlined. )T9D @T1)tuD@um, )tuD?name, )tuDInit, )tuD/pa2 Relational Database ?eys Pey Type Definition )uper $ey .n attribute 1or combination of attributes2 that uniquely identifies each row in a table &andidate $ey . minimal 1irreducible2 super $ey. . super$ey that does not contain a subset of attributes that it self is a super$ey :rimary $ey . candidate $ey selected to uniquely identify all other attribute values in any given row. &annot contain null entries )econdary $ey .n attribute 1or combination of attributes2 used strictly for data retrieval purposes %oreign $ey .n attribute 1or combination of attributes2 in one table whose values must either match the primary $ey in another table or be null Integrity rules The relational data model includes several types of constraints, or business rules, whose purpose is to facilitate maintaining the accuracy and integrity or data in the database. The maHor types of integrity MDBMS 40/58 40/58

UNIT-I constraints are domain constraints, entity integrity, referential integrity and action assertions. Domain constraints: . domain is the set of all values that may be assigned to an attribute. . domain definition usually consists of the following components * domain name, meaning, datatype, si0e and allowable values or allowable range. x* @>T @9??, &hec$ Entity Integrity: the entity integrity rule is designed to assure that every relation has a primary $ey, and that the data values for that primary $ey are all valid. It states that @o primary $ey attribute1or component of a primary $ey attribute2 may be null. Referential Integrity constraint: a referential integrity constraint is a rule that maintains consistency among the rows of two relations. The rule states that if there is a foreign $ey in one relation, either each foreign $ey value must match a primary $ey value in another relation or the foreign value must be null. Relational SE$ operators: the data in relational tables are of limited value unless the data can be manipulated to generate useful information. (elational algebra defines the theoretical way of manipulating table contents using the eight relational operators* ) ? &T, :(>7 &T, 7>I@, I@T () &T, 9@I>@, DI%% ( @& , :(>D9&T and DIFID . 9@I>@ combines all rows from two tables, excluding duplicate rows. The tables must have the same attribute characteristics1the columns and domains must be identical2 to be used in the 9@I>@. I@T () &T yields only the rows that appear in both tables. DI%% ( @& yields all rows in one table that are not found in the other table i.e., it subtracts one table from the other. :(>D9&T yields all possible pairs of rows from two tablesL also $nown as the &artesian product. ) ? &T, also $nown as ( )T(I&T yields values for all rows found in a table that satisfy a given condition. ) ? &T yields a hori0ontal subset of a table. :(>7 &T yields all values for selected attributes. In other words, :(>7 &T yields a vertical subset of a table. 7>I@ allows information to be combined from two or more tables. It allows the use of independent tables lin$ed by common attributes. There are several types of Hoins. . natural =oin lin$s tables by selecting only the rows with common values in their common attributes. .n e2ui =oin lin$s tables on the basis of an equality condition that compares specified columns of each table. The outcome of the equiHoin does not eliminate duplicate columns, and the condition or criterion used to Hoin the tables must be explicitly defined. The equiHoin ta$es its name from the equality comparison operator1W2 used in the condition. If any other comparison operator is used, the Hoin is called a theta =oin5 In an outer =oin, the matched pairs would be retained and any unmatched values in the other table would be left null. MDBMS 41/58 41/58

UNIT-I 4ore specifically, if an outer Hoin is produced for tables two scenarios are possible* a left outer =oin and a right outer =oin. The outer Hoins are labeled left and right, which refers to the order in which the tables are listed in the )E? command. DIFID operation uses one single column table as the divisor and one + column table as the dividend. The tables must have a common column. The output of the DIFID operation is a single column with the values of column a from the dividend table rows where the value of the common column in both tables match. $he Data Dictionary and the System &atalog The data dictionary provides a detailed description of all tables found within the userMdesigner created database. Thus the data dictionary contains at least all of the attribute names and characteristics for each table in the system. The data dictionary contains metadata 1data about data2. The data dictionary is sometimes described as Jthe database designer5s database. The system catalog can be described as a detailed system dictionary that describes all obHects within the database, including data about table names, the table5s creator and creating date, the number of columns in each table, the data type corresponding to each column, index filenames, index creators, authori0ed users, and access privileges. 3ecause the system catalog contains all required data dictionary information, the terms system catalog and data dictionary are often used interchangeably. The system catalog is actually a system created database whose tables store the userMdesigner created database characteristics and contents. They can be queried Hust li$e any userMdesignerLcreated table. The system catalog automatically produces database documentation. .s new tables are added to the database, that documentation also allows the (D34s to chec$ for and eliminate homonyms and synonyms. In general terms, homonyms are similar sounding words with different meanings such as boar and bore. In database context, the word homonym indicates the use of the same attribute name to label different attributes. In a database context, a synonym is the opposite of a homonym and indicates the use of different names to describe the same attribute. Relationships 1ithin the Relational Database The relationships in relational database are divided into three types. They are !. >ne to 4any 1!*42 +. 4any to 4any 14*@2 ,. >ne to >ne 1!*!2 +ne to Many-4:M/ relationship The !*4 relationship is the relational database norm. To see how such a relationship is modeled and implemented, consider the :.I@T ( paints :.I@TI@/ example. MDBMS 42/58 42/58

UNIT-I

.s you examine the :.I@T ( and :.I@TI@/ table contents in the above figure, note the following features* ach painting is painted by one painter, but each painter could have painted many paintings. There is only one row in the :.I@T ( table for any given row in the :.I@TI@/ table, but there may be many rows in the :.I@TI@/ table for any given row in the :.I@T ( table. The !*4 relationship is found in any database environment. Many to Many-M::/ Relationship: . 4any to 4any relationship is not supported directly in the relational environment. 6owever, 4*@ relationships can be implemented by creating anew entity in !*4 relationships with the original entities. g* To explore the 4*@ relationship, consider a college environment in which each )T9D @T can ta$e many classes and each &?.)) can contain many )T9D @T). The L( model for 4*@ relationship between )T9D @T and &?.))

MDBMS 43/58

43/58

UNIT-I

The features of the above (4 are * ach &?.)) can have many )T9D @T) and each )T9D @T can ta$e many &?.)). There can be many rows in the &?.)) table for any given row in the )T9D @T table and there can be many rows in the )T9D @T table for any given row in the &?.)) table. These are shown in the below tables. +ne to +ne Relationship-4:4/ In this relationship, one entity can be related to only one other entity and vice versa. g* >ne department chair a professor. . professor can chair only one department and one department can have only one department chair. The entities :(>% ))>( and D :.(T4 @T thus exhibit a !*! relationship. The basic !*! relationship is modeled in figure and its implementation is shown.

The implemented D :.(T4 @T.

!*!

relationship

between

:(>% ))>(

and

MDBMS 44/58

44/58

UNIT-I

.s you examine the above tables. The professor identification is through the empDnum. The !*! professor chairs department relationship is implemented by having the empDnum foreign $ey in the department table. The professor table contains the dept code as the foreign $ey.

MDBMS 45/58

45/58

UNIT-I Inde.es )uppose you want to locate a particular boo$ in a library. Then you use the libraries catalog, which is indexed by title, topic and author. The index 1in either a manual or a computer system2 points you to the boo$s location, there by ma$ing retrieval of the boo$ is a simple matter. )uppose you to find a topic in a text boo$, then it is much simpler to go to the boo$s index, loo$ up the required pharase X ( 4odelY and read the page references that point you to the appropriate pages. Index .n index is an orderly arrangement used to logically access rows in a table. It is used to locate a needed item quic$ly. Indexes in the relational database environment wor$ li$e the indexes li$e the above examples. %rom a conceptual point of view, an index is composed of an index $ey and a set of pointers. )uppose you want to loo$ up all the paintings created by a given painter in the painting data base* Table @ame * :ainter

8ithout an index, you must read each row in the :.I@TI@/ table and see if the painterDnum matches the requested painter. 6owever, if you index the painter table and use the index $ey painterDnum, you merely need to loo$ up the appropriate painterDnum in the index and find the matching pointers. The index will resemble the representation shown in the below figure.

MDBMS 46/58

46/58

UNIT-I .s you examine the above figure and compare it to the paintings database table, the !st painterDnum index $ey value1!,+,,2 is found in record1!,+,-2 of the painting table. The +nd index $ey value1!,+,A2 is found in records1,,#2 of the painting table. Indexes play an important role in D34)s for the implementation of primary $eys when you define a tables primary $ey, the D34) automatically creates a unique index on the primary $ey columns you declared. 8hen you declare cusDcode to be the primary $ey of the customer table, the D34) automatically creates a unique index on that attribute. (ni2ue Inde.: It is an index in which the index $ey can have only one painter value1row2 associated with it. . table can have many indexes, but each index associated with only table. The index $ey can have multiple attributes1composite index2 %urposes of Inde.es: The following are the some of the advantages of indexes* .n index is used to locate a needed item quic$ly. .n index can be used to retrieve data more efficiently. Indexes can also be used by a D34) to retrieve data ordered by a specific attribute or attributes. &odd Rules In !=C#, Dr. .%. &odd published a list of !+ rules to define a relational database system the reason Dr.&odd published the list was his concern that many vendors were mar$eting product as relational even though those products did not meet minimum relational standards. Dr. &odd5s list, shown in table serves as a frame of reference for what a truly relational database should be bear in mind that even the dominant database vendors do not fully support all !+ rules. (ul (ule @ame Description e !. Information .ll information in a relational database must be logically represented as column values in rows within tables +. /uaranteed .ccess very value in a table is guaranteed to be accessible through a combination of table name, primary $ey value and column name ,. )ystematic @ulls must be represented and treated treatment of @9??s in a systematic way, independent of data type -. Dynamic >nL?ine The meta data must be stored and &atalog based on managed as ordinary data, i.e., in the relational model tables, with in the database. )uch data must be available to authori0ed users using the standard database relational language MDBMS 47/58 47/58

UNIT-I #. &omprehensive Data The relational database may support )ub language many languages. 6owever, it must support one well defined, declarative language with support for data definition, view definition, data manipulation 1interactive and by program2, integrity constraints, authori0ation and transaction management Fiew 9pdating .ny view that is theoretically updatable must be updatable through the system 6igh level Insert, The database must support set level 9pdate and Delete inserts, updates and deletes :hysical Data .pplication programs and adhoc Independence facilities are logically affected when physical access methods or storage structures are changed ?ogical data .pplication programs and adhoc independence facilities are logically unaffected when changes are made to the table structures that preserved the original table values1changing order or column or inserting columns2 Integrity .ll relational integrity constraints must Independence be definable in the relational language and stored in the system catalog, not at the application level Distribution The end users and application programs Independence are unaware and unaffected by the data location 1distributed vs local databases2 @on subversion If the system supports low level access to the data, there must not be a way to bypass the integrity rules of the database (ule Zero .ll preceding rules are based on the notion that in order for a database to be considered relational it must use its relational facilities exclusively to manage the database

A. B. C.

=.

!".

!!. !+.

MDBMS 48/58

48/58

UNIT-II Entity Relationship Modeling 8ERM9 The relational database model, that the (4 forms the basis of an (D. The (D represents the conceptual database as viewed by the end user. (D5s shows the databases main components such as entities, attributes and relationships. The (D5s can be represented as in the &hen notation or in the &row5s %oot @otation or 94? notations. The &hen notation favours conceptual modeling. The &row5s %oot notation favours a more implementationL oriented approach. The 94? notation can be used for both conceptual and implementation modeling. Entities ntity is nothing but li$e a person, place, a thing or an event about which data are to be collected and stored. .n entity actually refers to the entity set and does not to a single entity occurrence. In otherwords, the word entity in the (4 corresponds to a table not to a row in the relational environment. The (4 refers to a table row as an entity instance or entity occurrence In both the chen and crow5s foot notations, an entity is represented by a rectangle containing the entities name. The entity name should be a noun in singular form and is usually written in all capital letters in the center of the rectangle box. STUD2NT 2M/08922 ttributes .n attribute is a characteristic or feature of an entity. g* the student entity includes attributes such as* )tuD%name, )tuDInitial, )tuD?name, )tuDDob etc., In the original chen notation, attributes are represented by ovals and are connected to the entity rectangle with a line ach oval contains the name of the attribute that represents. In the crowsLfoot notation, the attributes are written in the attribute box below the entity rectangle. &hen notation diagram and crow5s foot notation diagram

MDBMS 49/58

49/58

UNIT-II

Re2uired and +ptional ttributes . re2uired attribute is an attribute that must have a value, in other words it can5t be left empty or null. The required attributes are shown in the bold faced attribute &) #he :*ro( !oo#; )o#a#&o). I) #he a$o'e e-amp+e4 S#u<7)ame a)" S#u<I)&#&a+ are re=u&re" a##r&$u#e a)" (e mu # pa 'a+ue &)#o #ho e a##r&$u#e . >) optional attribute & a) a##r&$u#e #ha# "oe )?# re=u&re a 'a+ue4 #here!ore &# *a) $e +e!# emp#% or &# *a) $e )u++. I) #he a$o'e e-amp+e4 S#u<+)ame4 S#u<"o$ *a) $e +e!# emp#% Domains >##r&$u#e ha'e a "oma&). > "oma&) & #he e# o! po &$+e 'a+ue !or a 3&'e) a##r&$u#e. The "oma&) !or #he 3e)"er a##r&$u#e *o) & # o! o)+% #(o po &$&+&#&e . M or 7. >##r&$u#e ma% hare a "oma&). Identifiers (Primary Keys) The 2@M u e identifiers, #ha# & 4 o)e or more a##r&$u#e #ha# u)&=ue+% &"e)#&!% ea*h e)#&#% &) #a)*e. I"e)#&!&er are u)"er+&)e" &) #he 2@D.

Composite Identifiers I"ea++%4 a) e)#&#% &"e)#&!&er & *ompo e" o! o)+% a &)3+e a##r&$u#e. 1o(e'er4 &# & po &$+e #o u e a *ompo &#e &"e)#&!&er4 #ha# & 4 a pr&mar% 6e% *ompo e" o! more #ha) o)e a##r&$u#e. Composite and Simple Attributes >) a##r&$u#e (h&*h *a) $e !ur#her u$ "&'&"e" #o %&e+" a""&#&o)a+ a##r&$u#e & 6)o() a composite attributes. 7or e-amp+e4 #he a##r&$u#e :a""re ; *a) $e u$ "&'&"e" &)#o #ree#4 *&#%4 #a#e a)" A&p *o"e. > Simple attribute & a) a##r&$u#e (h&*h *a))o# $e u$ "&'&"e" #o %&e+" a""&#&o)a+ a##r&$u#e & 6)o() a &mp+e a##r&$u#e. 23. a3e4 3e)"er4 mar&#a+ #a#u (ou+" $e *+a &!&e" a &mp+e a##r&$u#e . Single alued attributes >) a##r&$u#e #ha# *a) ha'e o)+% a &)3+e 'a+ue & 6)o() a single valued attributes. 23. a per o) *a) ha'e o)+% o)e o*&a+ e*ur&#% )um$erBSSNC a)" a ma)u!a*#ure" par# *a) ha'e o)+% o)e er&a+ )um$er. !ulti alued Attributes The a##r&$u#e (h&*h *a) ha'e ma)% 'a+ue are 6)o() a multi valued attributes. 23. > per o) ma% ha'e e'era+ *o++e3e "e3ree . > hou eho+" ma% ha'e e'era+ "&!!ere)# pho)e 4 ea*h (&#h &# o() )um$er In the &hen (4, the multi valued attributes are shown by a double line connecting the attribute to the entity. 3ut the crows foot notation doesnt identify multi valued attributes. 4ulti valued attributes can be represented as follows*

MDBMS 50/58

50/58

UNIT-II

In the above example, carDvid is the primary $ey and carDcolor is a multi valued attribute of the car entity. Implementing Multi 0alued ttributes .lthough the conceptual model can handle 4*@ relationships and multi valued attributes, you should not implement them in the RDBMS. In the (elational table, each columnMrow intersection represents a single data value. )o if multivalued attributes exists, the designer must decide on one of the two possible courses of action* !. 8ithin the original entity, create several new attributes, one for each of the original multi valued attribute5s components. %or example, the &.( entity5s attribute &.(D&>?>( can be split to create the new attributes &.(DT>:&>?>(, &.(D3>DO&>?>( and &.(DT(I4&>?>(. .lthough this solution seems to wor$, its adoption can lead to maHor structural problems in the table. Imagine how the solution in figure splitting a multi valued attribute into new attributes K would cause problems when it is applied to an employee entity containing employee degrees and certifications. If some employees have !" degrees and certifications while most have fewer of none, the number of degreeMcertification attributes would number !" and most of those attribute values would be null for the most.

+.

&reate a new entity composed of the original multi valued attribute5s components. The new entity 1&.(D&>?>(2 then related to the original 1&.(2 entity in a !*4 relationship.

Deri#ed MDBMS

ttributes 51/58 51/58

UNIT-II . deri#ed attribute is an attribute whose value is calculated 1derived2 from other attributes. The derived attribute need not be physically stored within the database, instead, it can be derived by using an algorithm. %or example, an employee5s age, 4:D./ , may be found by computing the integer value of the difference between the current date and the 4:DD>3.

Derived attributes are sometimes referred to as computed attributes. The decision to store derived attributes in database tables depends on the processing requirements and the constraints placed on a particular application. The advantages and disadvantages of storing1or not storing2 derived attributes in the database shown below in the table.

Relationships . relationship is an association between entities. The entities that participate in a relationship are also $nown as participants, and each relationship is identified by a name that describes the relationship. (elationships between entities always operate in both directions. That is, to define the relationship between the entities named &9)T>4 ( and I@F>I& , you would specify that* . &9)T>4 ( may generate many I@F>I& s. ach I@F>I& is generated by one &9)T>4 (. &onnecti#ity and &ardinality The term connecti#ity is used to describe the relationship classification. That is one to one, one to many and many to many relationships. &ardinality expresses the minimum and maximum number of entity occurrences associated with one occurrence of the related entity. In the (D, cardinality is indicated by placing the appropriate MDBMS 52/58 52/58

UNIT-II numbers beside the entities, using the format 1x,y2. The first value represents the minimum number of associated entities, while the second value represents the maximum number of associated entities. Pnowing the minimum and maximum number of entity occurrences is very useful at the application software level. %or example, a college might want to ensure that a class is not taught unless it has at least !" students enrolled.

.s you examine the &row5s %oot Diagram, the cardinality 1!,-2 written next to the &?.)) entity in the :(>% ))>( teaches &?.)) relationship indicates that the :(>% ))>( table5s primary $ey value occurs at least once and no more than four times as foreign $ey values in the &?.)) table. )imilarly, the cardinality1!,!2 written next to the :(>% ))>( entity indicates that each class is taught by one and only one professor. That is, each &?.)) entity occurrence is associated with one and only one entity occurrence in :(>% ))>(. E.istence Dependence .n entity is said to be existence dependent if it can exist in the database only when it is associated with another related entity occurrence. Relationship Strength The concept of relationship strength is based on how the primary $ey of a related entity is defined. To implement a relationship, the primary $ey of one entity appears as a foreign $ey in the related entity. There are times when the foreign $ey also is a primary $ey component in he related entity. )ea"-:on-identifying/ Relationships . wea$ relationship, also $nown as non-identifying relationship, exists if the :P of the related entity does not contain a :P component of the parent entity. 3y default, relationships are established by having the :P of the parent entity appear as an %P on the related entity. %or example, suppose that the &>9() and &?.)) entities are defined.

MDBMS 53/58

53/58

UNIT-II

In this case, a wea$ relationship exists between &>9() and &?.)) because the &?.))D&>D is the &?.)) entity5s :P, while the &()D&>D is only an FK. In this example, the &?.)) :P did not inherit the :P component from the &>9() entity. The &row5s %oot notation depicts the weak(non identifyin!" relationship with a solid line between the entities. Strong -Identifying/ Relationships . strong relationship, also $nown as an identifying relationship, exists when the :P of the related entity contains a :P component of the parent entity.

%or example, the definitions of the &>9() and &?.)) entities indicate that a strong relationship exists between &>9() and &?.)), because the &?.)) entity5s composite :P is composed of &()D&>D G&?.))D) &TI>@. The &row5s %oot notation depicts the stron!(identifyin!" relationship with a solid line between the entities. )ea" Entities . 1ea" entity is one that meets two conditions* !. The entity is existenceLdependentR i.e., it cannot exist without the entity with which it has a relationship. +. The entity has a primary $ey i.e., partially or totally derived from the parent entity in the relationship. %or example, a company insurance policy insures an employee and hisMher dependents. %or the purpose of describing an insurance policy, an 4:?>O might or might not have a D : @D @T, but the D : @D @T must be associated with an 4:?>O . 4oreover, the D : @D @T MDBMS 54/58 54/58

UNIT-II cannot exist without the 4:?>O R i.e., a person cannot get insurance coverage as a dependent unless he happens to be a dependent of an employee. D : @D @T is the wea$ entity in the relationship 4:?>O has D : @D @T.

Relationship %articipation :articipation in an entity relationship is either optional or mandatory. +ptional participation means that one entity occurrence doest not re#uire a corresponding entity occurrence in a particular relationship. In other words, an entity occurrence 1row2 in the one entity does not necessarily require the existence of a corresponding entity occurrence in another entity. In &row5s %oot notation, an optional relationship between entities is shown by drawing a small circle 1>2 on the side of the optional entity. The existence of an optional entity indicates that the minimum cardinality is " for the optional entity. Mandatory participation means that one entity occurrence requires a corresponding entity occurrence in a particular relationship. The existence of a mandatory relationship indicates that the minimum cardinality is ! for the mandatory entity. &onsider the relationship the :(>% ))>( teaches &?.)), It is quite possible for a :(>% ))>( not to teach a &?.)). Therefore, &?.)) is optional to :(>% ))>(. >n the other hand, a &?.)) might by taught by a :(>% ))>(. Therefore, :(>% ))>( is mandatory to &?.)).

The cardinality next to &?.)) to be 1",,2 in the figure, thus indicating that a professor may teach no classes at all or as many as three classes. MDBMS 55/58 55/58

UNIT-II

Table shows the various cardinalities that are supported by the &row5s %oot notation.

Relationship Degree . relationship degree indicates the number of entities or participants associated with a relationship. . unary relationship exists when an association is maintained within a single entity. . binary relationship exists when two entities are associated. . ternary relationship exists when three entities are associated.

(nary Relationships In the case of the unary relationship shown in figure, an employee within the 4:?>O entity is the manager for one or more employees MDBMS 56/58 56/58

UNIT-II with that entity. In this case, the existence of the manages relationship means that 4:?>O requires another 4:?>O to be manager i.e., 4:?>O has a relationship with itself. )uch a relationship is $nown as a recursi#e relationship. . binary relationship exists when two entities are associated in a relationship. 3inary relationships are most common. In fact, to simplify the conceptual design, whenever possible most higher order 1ternary and higher2 relationships are decomposed into appropriate equivalent binary relationships. $ernary and Higher Degree Relationships . ternary relationship implies an association among three different entities. %or example note the relationships in figure, which are represented by the following business rules* . D>&T>( writes one or more :( )&(I:TI>@s. . :.TI @T may receive one or more :( )&(I:TI>@s. . D(9/ may appear in one or more :( )&(I:TI>@s. ssociati#e -composite/ Entities In general, relationships do not contain attributes. The associative entity1composite or bridge entity2 is composed of the primary $eys of each of the entities to be connected. @ormally relationships do not contain attributes. 3ut some times $ypes of Entities ntities are divided into three types. They are )trong ntity 8ea$ ntity .ssociative ntity Strong Entity .n entity that exists independently of other entity types is $nown as strong entity. It is also $nown as e.istence independent. g* some regular entities li$e* )T9D @T, 4:?>O , &>9() , &9)T>4 (, :(>D9&T, I@F>I& etc., Instances of a strong entity type always have a unique characteristic called an identifier. )ea" Entity: .n entity type whose existence depends on some other entity type is $nown as wea$ entity type. It is also called as existence dependent. . wea$ entity type has no business meaning in the (D without the entity on which it depends. The entity type on which the wea$ entity type depends is called the Identifying owner. . wea$ entity type does not have its own identifier. g* the below diagram shows the example of a wea$ entity and its identifying relationship. 4:?>O is a strong entity type with identifier mpDno1we denote the Identifier attribute by underlining it2, D : @D @T is a wea$ entity which is indicated by double lined rectangle box. MDBMS 57/58 57/58

UNIT-II The relationship between a wea$ entity type and its owner is called an Identifying relationship. In the above example, has is the identifying relationship which can be indicated by the double lined diamond symbol. The attribute JdependentDname5 serves as a partial identifier. 8e use a double under line to indicate a partial identifier. 6ere, dependent name is also a composite attribute which can be bro$en into three attributes li$e * first name, 4iddle initial, last name. .ssociative ntity* .n entity type that associates the instances of one or more entity types and contains attributes that are peculiar to the relationship among those entity instances. The associative entity & (TI%I&.T is represents with the diamond relationship symbol enclosed with the entity box as shown in the above figure. Thus an associative acts both as an entity type by including some attributes and also has a relationship between two or more entity types.

MDBMS 58/58

58/58