Processing Rights and Responsibilities
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 management 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.
Chapter 9 Managing Multiuser Databases
CUSTOMER
TRANSACTION WORK
ARTIST
Sales
Insert, change, Insert, query
Insert, change, Insert, change, Insert, change, Insert, change,
Figure 9-13
Grant rights, Grant rights, administrator modify structure modify structure modify structure modify structure Processing Rights at View Ridge Gallery
System
Grant rights,
Grant rights,
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-13 summarizes these processing rights.
You may be wondering what good it does to say that the system adminis- trator cannot process the data when that person has the ability to grant
processing rights. He or she can just grant the right to change data to him- or herself. Although this is true, the granting of those rights will leave an audit trail in the database log. Clearly, this limitation is not foolproof, but it is better than just allowing the system administrator (or DBA) full access to all rights in the database.
The permissions in this table are not given to particular people, but rather are given to groups of people. Sometimes these groups are termed roles, because they describe people acting in a particular capacity. The term user groups is also used. Assigning permission to roles (or user groups) is typical, but not required. It would be possible to say, for example, that the user identified as “Benjamin Franklin” has certain processing rights. Note, too, that when roles are used, it is necessary to have a way to allocate users to roles. When “Mary Smith” signs on to the computer, there must be some way to determine which role or roles she has. We will discuss this further in the next section.
In this discussion, we have used the phrase processing rights and responsibilities. As this phrase implies, responsibilities go with processing rights. If, for example, the manager modifies transaction data, the manager has the responsibility to ensure that these modifica- tions do not adversely impact the gallery’s operation, accounting, and so forth.
Processing responsibilities cannot be enforced by the DBMS or by the database applica- tions. Instead, they are encoded in manual procedures and explained to users during systems training. These are topics for a systems development text, and we will not consider them further here—except to reiterate that responsibilities go with rights. Such responsibilities must be documented and enforced.
According to Figure 9-1, the DBA has the task of managing processing rights and responsibilities. As this implies, these rights and responsibilities will change over time. As the database is used and as changes are made to the applications and to the structure of the DBMS, the need for new or different rights and responsibilities will arise. The DBA is a focal point for the discussion of such changes and for their implementation.
Once processing rights have been defined, they can be implemented at many levels: operating system, network, Web server, DBMS, and application. In the next two sections, we will consider DBMS and application implementation. The other levels are beyond the scope of this text.