DBMS Architecture For A Shared, Evolvable Database And How It Satisfies The Users And The Organization
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 |