(Database) Application Programs
Application A computer program that interacts with the database by issuing an
program appropriate request (typically an SQL statement) to the DBMS.
Users interact with the database through a number of application programs that are used
to create and maintain the database and to generate information. These programs can be
conventional batch applications or, more typically nowadays, they will be online applications.
The application programs may be written in some programming language or in some
higher-level fourth-generation language.
The database approach is illustrated in Figure 1.7, based on the file approach of Figure
1.5. It shows the Sales and Contracts Departments using their application programs to
access the database through the DBMS. Each set of departmental application programs
handles data entry, data maintenance, and the generation of reports. However, compared
with the file-based approach, the physical structure and storage of the data are now managed
by the DBMS.
Views
With this functionality, the DBMS is an extremely powerful and useful tool. However, as
the end-users are not too interested in how complex or easy a task is for the system, it
could be argued that the DBMS has made things more complex because they now see
more data than they actually need or want. For example, the details that the Contracts
Department wants to see for a rental property, as shown in Figure 1.5, have changed in the
database approach, shown in Figure 1.7. Now the database also holds the property type,
the number of rooms, and the owner details. In recognition of this problem, a DBMS provides
another facility known as a view mechanism, which allows each user to have his or
her own view of the database (a view is in essence some subset of the database). For example,
we could set up a view that allows the Contracts Department to see only the data
that they want to see for rental properties.
As well as reducing complexity by letting users see the data in the way they want to see
it, views have several other benefits:
n Views provide a level of security. Views can be set up to exclude data that some users
should not see. For example, we could create a view that allows a branch manager and
the Payroll Department to see all staff data, including salary details, and we could
create a second view that other staff would use that excludes salary details.
n Views provide a mechanism to customize the appearance of the database. For example,
the Contracts Department may wish to call the monthly rent field (rent) by the more
obvious name, Monthly Rent.
n A view can present a consistent, unchanging picture of the structure of the database,
even if the underlying database is changed (for example, fields added or removed, relationships
changed, files split, restructured, or renamed). If fields are added or removed
from a file, and these fields are not required by the view, the view is not affected by this
change. Thus, a view helps provide the program–data independence we mentioned in
the previous section.
The above discussion is general and the actual level of functionality offered by a
DBMS differs from product to product. For example, a DBMS for a personal computer
may not support concurrent shared access, and it may provide only limited security,
integrity, and recovery control. However, modern, large multi-user DBMS products offer
all the above functions and much more. Modern systems are extremely complex pieces
of software consisting of millions of lines of code, with documentation comprising many
volumes. This is a result of having to provide software that handles requirements of a
more general nature. Furthermore, the use of DBMSs nowadays requires a system that
provides almost total reliability and 24/7 availability (24 hours a day, 7 days a week), even
in the presence of hardware or software failure. The DBMS is continually evolving and
expanding to cope with new user requirements. For example, some applications now
require the storage of graphic images, video, sound, and so on. To reach this market, the
DBMS must change. It is likely that new functionality will always be required, so that the
functionality of the DBMS will never become static. We discuss the basic functions provided
by a DBMS in later chapters.
Application A computer program that interacts with the database by issuing an
program appropriate request (typically an SQL statement) to the DBMS.
Users interact with the database through a number of application programs that are used
to create and maintain the database and to generate information. These programs can be
conventional batch applications or, more typically nowadays, they will be online applications.
The application programs may be written in some programming language or in some
higher-level fourth-generation language.
The database approach is illustrated in Figure 1.7, based on the file approach of Figure
1.5. It shows the Sales and Contracts Departments using their application programs to
access the database through the DBMS. Each set of departmental application programs
handles data entry, data maintenance, and the generation of reports. However, compared
with the file-based approach, the physical structure and storage of the data are now managed
by the DBMS.
Views
With this functionality, the DBMS is an extremely powerful and useful tool. However, as
the end-users are not too interested in how complex or easy a task is for the system, it
could be argued that the DBMS has made things more complex because they now see
more data than they actually need or want. For example, the details that the Contracts
Department wants to see for a rental property, as shown in Figure 1.5, have changed in the
database approach, shown in Figure 1.7. Now the database also holds the property type,
the number of rooms, and the owner details. In recognition of this problem, a DBMS provides
another facility known as a view mechanism, which allows each user to have his or
her own view of the database (a view is in essence some subset of the database). For example,
we could set up a view that allows the Contracts Department to see only the data
that they want to see for rental properties.
As well as reducing complexity by letting users see the data in the way they want to see
it, views have several other benefits:
n Views provide a level of security. Views can be set up to exclude data that some users
should not see. For example, we could create a view that allows a branch manager and
the Payroll Department to see all staff data, including salary details, and we could
create a second view that other staff would use that excludes salary details.
n Views provide a mechanism to customize the appearance of the database. For example,
the Contracts Department may wish to call the monthly rent field (rent) by the more
obvious name, Monthly Rent.
n A view can present a consistent, unchanging picture of the structure of the database,
even if the underlying database is changed (for example, fields added or removed, relationships
changed, files split, restructured, or renamed). If fields are added or removed
from a file, and these fields are not required by the view, the view is not affected by this
change. Thus, a view helps provide the program–data independence we mentioned in
the previous section.
The above discussion is general and the actual level of functionality offered by a
DBMS differs from product to product. For example, a DBMS for a personal computer
may not support concurrent shared access, and it may provide only limited security,
integrity, and recovery control. However, modern, large multi-user DBMS products offer
all the above functions and much more. Modern systems are extremely complex pieces
of software consisting of millions of lines of code, with documentation comprising many
volumes. This is a result of having to provide software that handles requirements of a
more general nature. Furthermore, the use of DBMSs nowadays requires a system that
provides almost total reliability and 24/7 availability (24 hours a day, 7 days a week), even
in the presence of hardware or software failure. The DBMS is continually evolving and
expanding to cope with new user requirements. For example, some applications now
require the storage of graphic images, video, sound, and so on. To reach this market, the
DBMS must change. It is likely that new functionality will always be required, so that the
functionality of the DBMS will never become static. We discuss the basic functions provided
by a DBMS in later chapters.
No comments: