Database Reference
In-Depth Information
values in the new row (assuming that all required fields are present). Unless the isolation level
of the transaction is a dirty read, only committed updates and deletions are visible to the cursor.
A dynamic cursor is a fully featured cursor. All inserts, updates, deletions, and changes in
row order are visible to a dynamic cursor. As with keyset cursors, unless the isolation level of
the transaction is a dirty read, only committed changes are visible.
The amount of overhead and processing required to support a cursor is different for each
type of cursor. In general, the cost goes up as we move down the cursor types shown in Figure
9-13. To improve DBMS performance, the application developer should create cursors that
are just powerful enough to do the job. It is also very important to understand how a particu-
lar DBMS implements cursors and whether cursors are located on the server or on the client.
In some cases, it might be better to place a dynamic cursor on the client than to have a static
cursor on the server. No general rule can be stated because performance depends on the
implementation used by the DBMS product and the application requirements.
A word of caution: If you do not specify the isolation level of a transaction or do not
specify the type of cursors you open, the DBMS will use a default level and default types. These
defaults may be perfect for your application, but they also may be terrible. Thus, even though
these issues can be ignored, their consequences cannot be avoided. You must learn the capa-
bilities of your DBMS product.
Database Security
The goal of database security is to ensure that only authorized users can perform authorized
activities at authorized times. This goal is difficult to achieve, and to make any progress at all,
the database development team must determine the processing rights and responsibilities of
all users during the project's requirements specification phase. These security requirements
can then be enforced using the security features of the DBMS and additions to those features
written into the application programs.
Processing Rights and Responsibilities
Consider, for example, the needs of View Ridge Gallery. The View Ridge database has three
types of users: sales personnel, management personnel, and system administrators. View
Ridge designed processing rights for each as follows: Sales personnel are allowed to enter new
customer and transaction data, to change customer data, and to query any of the data. They
are not allowed to enter new artist or work data. They are never allowed to delete data.
Management personnel are allowed all of the permissions of sales personnel, plus they are
allowed to enter new artist and work data and to modify transaction data. Even though man-
agement personnel have the authority to delete data, they are not given that permission in this
application. This restriction is made to prevent the possibility of accidental data loss.
The system administrator can grant processing rights to other users; and he or she can
change the structure of the database elements such as tables, indexes, stored procedures, and
the like. The system administrator is not given rights to process the data. Figure 9-14 summa-
rizes these processing rights.
Figure 9-14
Processing rights at View
ridge Gallery
CUSTOMER
TRANSACTION WORK
ARTIST
Sales
personnel
Insert, change,
query
Insert, query
Query
Query
Management
personnel
Insert, change,
query
Insert, change,
query
Insert, change,
query
Insert, change,
query
System
administrator
Grant rights,
modify structure
Grant rights,
modify structure
Grant rights,
modify structure
Grant rights,
modify structure
 
 
 
Search WWH ::




Custom Search