When writing a program or interacting with a database, DBMS users must have some perception of the data structure and content. This is true of both programming and non programming users. They must have names to refer to data objects, some knowledge of how data item values are represented, and some sort of mental picture of the structural relationships among those data objects.

______________________________________________________________________________


______________________________________________________________________________

Ideally, the user’s view should reflect the user‘s environment-the entities and their attributes in the organizational and operational environment and only those of interest to the user. In many DBMSs, the database schema predetermines the user’s view. User must know the exact and entire definition of the database. Moreover, they must use the precise data names in the schema and know exactly how to interpret the physical stored representation of the data. The user’s view of data must coincide exactly with the database schema.

Requiring the user’s view to coincide with the database schema produces real problems under two conditions, multiple users and a changing database. With a common schema view, multiple users must be of one mind, they must all have exactly the same view of the database. How ever, different users have different jobs, may use different jargon, and do not need to know about all the data in a database. As the database changes, so must the user view. As the database grows and gets more complex, so must the user views. The database administrator must notify all users to incorporate any change in to their view of the database.

Alternatively users could ask if the database schema has changed since their last interaction with the database. If so, they could study the revised schema to change their view of the database. prior to executing a program, the system to change their view of the database schema changed since the program was last complied or the request was catalogued . These are all possible but not so practical ways of handling multiple users of a changing database.

To achieve a shareable , evolvable database, it would be desirable to decouple each user’s view of the database from the database schema. This would enable different users and different application systems to have different views of the same database. It would also help to insulate the user views from changes in the database schema.

Satisfying the motivators: The five factors motivating the database approach are summarized as follows, along with the capabilities for solution found in a DBMS .

Motivating Problem	DBMS Capabilities Which Provide Solutions
Inability to get answers to simple, ad how requests	· Query language and report writer if the data is already in the organizational database. · Database definition and creation function if the data is not already in the system
High Development Costs	· High level data language and data management functions which can be used in building application systems · Full definition of database semantics
Low responsiveness to change	· Independence of data in programs from the database · Database revision function and database conversation routines
Low data integrity	· Full definition of database semantics and validation criteria · Data integrity control functions to protect existence, maintain quality, and regulate access to data
Inadequate database model of the real world	· Comprehensive data definition for a broad class of data structures including the representation of rich structures, data relationships, and all relevant data characteristics

______________________________________________________________________________


______________________________________________________________________________