Integrity Security

You might also like

Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 37

Integrity and Security in

Database
Module 4
Integrity and Security in Database
 Domain Constraints
 Referential integrity
 Assertions
 Trigger
 Security
 Authorization in SQL
Transactions
 Transaction is a Unit of work
 It consists of sequence of query and/or update statements.
 Atomic transaction

◦ either fully executed or rolled back as if it never occurred


 Isolation from concurrent transactions
 Ended by commit work or rollback work
Transactions
One of the following SQL statements must end the transaction:
 Commit work commits the current transaction; that is , it

makes the updates performed by transaction become permanent


in the database. After the transaction is committed , a new
transaction is automatically started.
 Rollback work causes the current transaction to be rolled back;

that is, it undoes all the updates performed by the SQL


statements in the transaction. Thus the database state is restored
to what it was before the first statement of the transaction was
executed.
 But default on most databases: each SQL statement commits

automatically
Integrity Constraints
Integrity constraints guard against accidental damage to
the database, by ensuring that authorized changes
to the database do not result in a loss of data consistency.

 Domain Constraints
 Referential Integrity
 Assertions
 Triggers
 Functional Dependencies
Domain Constraints
 They define valid values for attributes.
 They are the most elementary form of integrity

constraint.
 They test values inserted in the database, and test

queries to ensure that the comparisons make sense.


Domain Constraints on a Single Relation
 Null
 notnull
 primary key
 Unique
 Default
 check (P), where P is a predicate
Constraints
 Null: unknown value is acceptable in columns
email_id varchar(10) null;

 not null : prohibits the insertion of null values


◦ Declare name and budget to be not null
◦ name varchar(20) not null
budget numeric(12,2) not null

 Unique
unique ( A1, A2, …, Am)
The unique specification states that the attributes A1, A2, … Am form a
candidate key.
Candidate keys are permitted to be null (in contrast to primary keys).
Constraints
 Primary key
o Combination of unique and not null. i.e. each row
should have known distinct value.
emp_id number(10) primary key;

 Default
o It specifies the default value for a column using default
clause.
o The default value for column is inserted for a row, when

a user does not enter a value for that column


country varchar(10) default = ‘India’
Constraints
 check (P) where P is a predicate
 Ensures that attribute value satisfies specific conditions.

Example: Ensure that semester is one of fall, winter, spring or


summer:
create table section (
course_id varchar (8),
sec_id varchar (8),
semester varchar (6),
year numeric (4,0),
building varchar (15),
room_number varchar (7),
time slot id varchar (4),
primary key (course_id, sec_id, semester, year),
check (semester in (’Fall’, ’Winter’, ’Spring’, ’Summer’))
);
Constraints
l
Eg: Check (assets>=0) in create table command
for relation branch will ensure that value of assets
is non-negative.

l
Check clause can also be applied to domain
declarations.
l
Eg: A domain can be restricted to contain only a
specified set of value by using the in clause.
l
Create domain AccountType char(10)
l
constraint account-type-test
l
check (value in ('Checking','saving'));
Referential Integrity
 Ensures that a value that appears in one relation for a
given set of attributes also appears for a certain set of
attributes in another relation.

 Let A be a set of attributes. Let R and S be two


relations that contain attributes A and where A is the
primary key of S. A is said to be a foreign key of R if
for any values of A appearing in R these values also
appear in S.
Referential Integrity
 Ensures that a value that appears in one relation for a given set
of attributes also appears for a certain set of attribute in another
relation.
◦ If an account exists in the database with branch name “SBI”,
then the branch “SBI” must actually exist in the database.
Foreign key

account ( account-no, branch-name, balance )


A-123 SBI 5000

branch (branch-name, branch-city, asset )


Primary keys of SBI Borivali 500,000
respective relations

A set of attributes X in R is a foreign key if it is not a


primary key of R but it is a primary key of some relation S.
Referential Integrity in SQL -example
create table customer
(customer-name char(20) not null,
customer-street char(30),
customer-city char(30),
primary key (customer-name))

create table branch


(branch-name char(15) not null,
branch-city char(30),
assets integer,
primary key (branch-name))
Referential integrity in SQL- example
create table account
(branch-name char(15),
account-number char(10) not null,
balance integer,
primary key(account-number),
foreign key (branch-name) references branch)

create table depositor


(customer-name char(20) not null,
account-number char(10) not null,
primary key (customer-name, account-number),
foreign key (account-number) references account,
foreign key (customer-name) references customer)
Cascading Actions in SQL
create table account
…..
foreign key (branch-name) references branch
on delete cascade
on update cascade,
…)
 Due to the on delete cascade clauses, if a delete of a tuple in
branch results in referential-integrity constraint violation,
the delete “cascades” to the account relation, deleting the
tuple that refers to the branch that was deleted.
 Cascading updates are similar.
Cascading Actions in Referential Integrity
create table course (
course_id char(5) primary key,
title varchar(20),
dept_name varchar(20) references department
)
 create table course (
 …
 dept_name varchar(20),
 foreign key (dept_name) references department
 on delete cascade
 on update cascade,
 ...
)

Triggers
 A trigger is a statement that is executed automatically by the
system as a side effect of a modification to the database.
 To design a trigger mechanism, we must:

◦ An event that causes the trigger to be checked and the


conditions under which the trigger is to be executed.
◦ Specify the actions to be taken when the trigger executes.
Trigger Components
 Three components
Event: When this event happens, the trigger is activated
Condition (optional): If the condition is true, the trigger
executes, otherwise skipped
Action: The actions performed by the trigger

 Semantics
When the Event occurs and Condition is true, execute the
Action

Lets see how to define these


components
Trigger: Events
 Threeevent types
Insert
Update
Delete

 Twotriggering times
Before the event
After the event

 Twogranularities
Execute for each row
Execute for each statement
1) Trigger: Event
Trigger name
Create Trigger <name>
Before|After Insert|Update|Delete ON <tablename> That is the event

….

 Example
Create Trigger ABC Create Trigger XYZ
Before Insert On Students After Update On Students
…. ….

This trigger is activated This trigger is activated


when an insert statement is when an update statement
issued, but before the new is issued and after the
record is inserted update is executed
Granularity of Event

A single SQL statement may update, delete, or insert many


records at the same time
 E.g., Update student set gpa = gpa x 0.8;

 Doesthe trigger execute for each updated or deleted


record, or once for the entire statement ?
 We define such granularity

Create Trigger <name> This is the event


Before| After Insert| Update|
Delete

For Each Row | For Each Statement


….
This is the granularity
2) Trigger: Condition
 This component is optional
Create Trigger <name>
Before| After Insert| Update| Delete On <tableName>
For Each Row | For Each Statement

When <condition>

That is the condition

If the employee salary > 150,000 then some actions will be


taken
Create Trigger EmpSal
After Insert or Update On Employee
For Each Row
When (new.salary >150,000)

3) Trigger: Action
 Action depends on what you want to do, e.g.:
Check certain values
Fill in some values
Inserts/deletes/updates other records
Check that some constraints are satisfied
Commit (approve the transaction) or roll back (cancel the
transaction)

 In
the action, you may want to reference:
The new values of inserted or updated records (:new)
The old values of deleted or updated records (:old)
Trigger: Referencing Values
 In the action, you may want to reference:
The new values of inserted or updated records (:new)
The old values of deleted or updated records (:old)

Create Trigger EmpSal


After Insert or Update On Inside “When”, the “new”
Employee and “old” should not have
For Each Row “:”
Trigger When (new.salary >150,000)
body Begin
if (:new.salary < 100,000) …
End; Inside the trigger body, they
should have “:”
Row vs Statement Level Trigger
 Row level: activated once per modified tuple
 Statement level: activate once per SQL statement
 Statement level triggers will be more efficient if we do
not need to make row-specific decisions
Another Trigger Example
CREATE TRIGGER youngSailorUpdate
AFTER INSERT ON SAILORS
REFERENCING NEW TABLE AS NewSailors
FOR EACH STATEMENT
INSERT
INTO YoungSailors(sid, name, age, rating)
SELECT sid, name, age, rating
FROM NewSailors N
WHERE N.age <= 18
When Not To Use Triggers
 Triggers were used earlier for tasks such as
◦ maintaining summary data (e.g., total salary of each
department)
◦ Replicating databases by recording changes to special
relations (called change or delta relations) and having a
separate process that applies the changes over to a replica
 There are better ways of doing these now:

◦ Databases today provide built in materialized view facilities


to maintain summary data
◦ Databases provide built-in support for replication
When Not To Use Triggers
 Risk of unintended execution of triggers, for example, when
◦ loading data from a backup copy
◦ replicating updates at a remote site
◦ Trigger execution can be disabled before such actions.
 Other risks with triggers:

◦ Triggers should be written with great care, since a trigger


error detected at run time causes the failure of the action
statements that set off the trigger
◦ Also the action of one trigger can set off another trigger.
Assertions vs. Triggers
 Assertions do not modify the data, they only check certain
conditions

 Triggersare more powerful because the can check conditions


and also modify the data

 Assertions are not linked to specific tables in the database and


not linked to specific events

 Triggers are linked to specific tables and specific events


Assertions vs. Triggers (Cont’d)
 All assertions can be implemented as triggers (one or more)

 Not all triggers can be implemented as assertions

 Oracle does not have assertions


Authorization
 Authorization is the process of giving someone permission to
do or have something.
 It is the function of specifying access rights to resources related

to database systems.

 Different types of authorization


l Read authorization: Allows reading but no modification.
l Insert authorization: Allows insertion of new data but not
modification of existing data.
l Update authorization: Allows modification but not deletion
l Delete authorization: Allows deletion of data.
Authorization
 Each of these types of authorizations is called a privilege.

 Different types of privileges:


l Select privilege: Allows reading of data.
 In addition, SQL also supports create,delete or modify relations

privileges.
 The privilege all privileges can be used as a short form to

allow all the allowable privileges.


 The user who creates a new relation is given all privileges on

that relation automatically.


Authorization
 SQL DDL includes commands to grant and revoke privileges.
 Grant statement is used to confer authorization.
 grant<privilege list> on <relation/view name> to<user/role

list>
 Eg: grant select on account to John,Mary
 Eg: grant select on account to teller

 Revoke command is used to cancel authorization.


 Revoke <privilege list> on <relation/view name> to

<user/role list>
 Eg: revoke select on account to John,Mary
Security in Database
 Security is protection from malicious attempts to steal or
modify data.
 Security should be provided at following levels:

a) Database System Level: Use authentication and


authorization mechanisms to allow specific users access
only to required data.
b)Operating System Level: There are many common threats
to OS like Viruses, Trojan Horse, etc. Good operating
system level security is required
Security in Database
 c) Network Level: Use encryption to prevent
l
Eavesdropping
l
Masquerading
 d) Physical level: Computers must also be protected from

floods, fire, etc.


 e) Human Level: Users must be screened to ensure that an

authorized users do not give access to intruders.

You might also like