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 users view should reflect the users 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 users 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 users view
of data must coincide exactly with the database schema.
Requiring the users
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 users 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
Capabilities Which Provide Solutions
to get answers to simple, ad how requests
Query language and report writer if the data is already in the organizational
· Database definition and creation function if the data is
not already in the system
High level data language and data management functions which can
be used in building application systems
· Full definition of database semantics
responsiveness to change
Independence of data in programs from the database
· Database revision function and database conversation routines
Full definition of database semantics and validation criteria
· Data integrity control functions to protect existence,
maintain quality, and regulate access to data
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