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 .
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 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|