The document discusses the importance of security and integrity in database management systems, emphasizing the need to protect databases from unauthorized access and maintain data consistency. It covers various security measures at different levels, including physical, human, operating system, and database system security, as well as the use of authorization and views to control access to data. Additionally, it outlines integrity constraints that ensure authorized changes do not lead to data inconsistency, with a focus on key and domain constraints for efficient testing.

1. Thank You!
L ogistics
E d i t t h i s t e x t h e r e
DBMS
Seminar
Security &
Integrity violations
Authorization
and views
Integrity
constraints
Presented By :
Prakash Kumar
MCA/25023/22

2. Security and
Integrity
Violations
The data stored in the database needs to be protected from
unauthorized access, malicious destruction or alteration, and
accidental introduction of inconsistency.
Misuse of the database can be categorized as being either
intentional (malicious) or accidental. Accidental loss of data
consistency may result from:
 Crashes during transaction processing
 Abnormalities due to concurrent access to the database
 Abnormalities due to the distribution of data over several
computers

3. It is easier to protect accidental loss of data consistency than
to protect against malicious access to the database. Among
the forms of malicious access are the following:
 Unauthorized reading of data (theft of information)
 Unauthorized modification of data
 Unauthorized destruction of data
Absolute protection of the database from malicious abuse is
not possible, but the cost of the perpetrator can be made
sufficiently high to deter most if not all attempts to access the
database without proper authority.
The term database security usually refers to security from
malicious access, while integrity refer to the avoidance of
accidental loss of consistency. In practice, the dividing line
between security and integrity is not always clear. We shall use
the term security to refer to both security and integrity in
cases where the distinction between these concepts is not
essential.

4. To protect the database, security measures must be taken at several
levels:
 Physical: The site or sites containing the computer systems must be
physically secured against armed or surreptitious entry by intruders.
 Human: Authorization of users must be done carefully to
chance of authorized user giving access to an intruder in exchange
for a bribe or other favors.
 Operating system: No matter how secure the database system is,
in operating system security may serve as a means of unauthorized
access to the database. Since almost all database systems allow
remote access through terminals or networks, software-level
security within the operation system is as important as physical
security.
 Database system: Some authorized database system users may be
authorized to access only a limited portion of the database. Other
users may be allowed to issue queries, but may be forbidden to
modify the data. It is the responsibility of the database system to
ensure that these restrictions are not violated.

5. Authorization and Views
The concept of views is a means of providing a user with a “personalized” model
of the database. A view can hide data that a user does not need to see. The
ability of views to hide data serves both to simplify usage of the system and to
enhance security. System usage is simplified since the user is allowed to restrict
attention to the data of interest. Security is provided if there is a mechanism to
restrict the user to his or her personal view or views.
Relational database systems typically provide security at two levels:
 Relation: A user may be permitted or denied direct access to a relation
 View: A user may be permitted or denied access to data appearing in a view.
Although a user may be denied direct access to a relation, the user may be able
to access part of that relation through a view. Thus, a combination of relational
level security and view level security can be used to limit a user’s access to
precisely the data that user needs.

6. A user may have several forms of authorization on part of the
database. Among these are the following:
 Read authorization, which allows reading, but not
modification of data
 Insert authorization, which allows insertion of new data, but
not the modification of existing data
 Update authorization, which allows modification, but not
deletion, of data
 Delete authorization, which allows deletion of data.

7. In addition to the above forms of authorization for access to data, a
user may be granted authorization to modify the database scheme:
 Index authorization, which allow creation and deletion of indices
 Resources authorization, which allow the creation new
relations
 Alteration authorization, which allow the addition or deletion of
attributes in a relation
 Drop authorization, which allows the deletion of relations
The drop and delete authorization differ in that delete authorization
allows deletion of tuples only. If a user deletes all tuples of a
relation, the relation still exists, but it is empty. If a relation is
dropped, it no longer exists.

8. Integrity constraints
Integrity constraints provide a means of ensuring that changes made
to the database by authorized users do not result in a loss of data
consistency.
In the network model and the E-R model, we saw integrity constraints
in the form of:
 Key declarations, the stipulation that certain attributes form a
candidate key for a given entity set constrains the set of legal
insertions.
 Form of a relationship, many-to–many, one–to–many, one–to–
one. A one-to– one or one–to-many relationship restricts the set of
legal relationships among entities of a collection of entity sets.
Another example of an integrity constraint is set retention in the
network model.

9. In general, an integrity constraint can be an arbitrary predicate pertaining to the
database. However, arbitrary predicates may be costly to test. Thus, we usually
limit ourselves to integrity constraints that can be tested with minimal overhead.
This is the purpose behind dependency – preserving decompositions of relation
schemes. Recall that in a dependency – preserving decomposition, it is
possible to test for satisfaction of the data dependencies without the need to
compute any joins. Domain – key normal is an ideal design from the point of
view of efficient testing of integrity constraints, since the only forms of constraint
that need be tested are key constraints and domain constraints.
If the key and domain constraints are satisfied, and the database scheme is in
DKNF, then all integrity constraints on the database are satisfied.
Key constraints are one of the most easily tested forms of consistency
constraint, especially if an index is maintained on that candidate key. During the
process of inserting a record into the database a lookup must be performed
using the index and any duplicate key values that may exist are found. Since
not all index search keys are candidate keys for the relation (Indices may be for
secondary keys), we need to declare an index to be either
 Unique: Only one record may exist for a key value
 Non-unique: Multiple records are allowed to have the same key value

10. Another form of constraint that is easy to test is domain
constraints. Testing domain constraints is analogous to runtime –
type checking in a programming language. A form of constraint
closely related to domain constraints involves the admissibility of
null values. We may forbid null values for certain attributes but
allow them for others.
Relatively few systems allow the expression of constraints that
are more complex than key declarations or domain constraints.
The original proposal for the SQL language included a general
purpose construct called the assert statement for the expression
of integrity constraints.

11. An assertion pertaining to a single relation takes the form:
For example, if we wish to define an integrity constraint that no
account balance is negative we write:
In its most general form, the assert statement takes the form:

12. Thank You