DBMS3

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 91

Database Management

System
COURSE CODE- BCA1203
COURSE CREDIT: 2
2 HOURS A WEEK
Lesson : 1
Evaluation Pattern

Exam/Assignment Final marks to be scaled


Internal Exam 15
Daily Assignments N.A
External Exam 35
Total (50)

2
Query Languages
• A query language is a language in which a user requests information from
the database. .
• Relational query languages use relational algebra to break the user requests
and instruct the DBMS to execute the requests
• Categorized into-
– Procedural - the user instructs the system to perform a sequence of operations on
the database to compute the desired result.
– Non-procedural- the user describes the desired information without giving a
specific procedure for obtaining that information.
• “Pure” languages:
– Relational Algebra- procedural
– Tuple Relational Calculus- non-procedural
– Domain Relational Calculus- non-procedural
• Pure languages form underlying basis of query languages that people use
Query Languages
Procedural Language: In procedural languages, the program code is written as a
sequence of instructions.
User has to specify “what to do” and also “how to do” (step by step procedure).
These instructions are executed in the sequential order.
These instructions are written to solve specific problems.
Examples of Procedural languages: FORTRAN, COBOL, ALGOL, BASIC, C and Pascal.

Non-Procedural Language: In the non-procedural languages, the user has to specify


only “what to do” and not “how to do”.
It is also known as an applicative or functional language.
It involves the development of the functions from other functions to construct more
complex functions.
Examples of Non-Procedural languages: SQL, PROLOG, LISP.
Relational Model in DBMS
Relational Algebra
• It is Procedural query language
• Six basic operators
– select
– project
– union
– set difference
– Cartesian product
– rename

• The operators take two or more relations as inputs and give a


new relation as a result.
Select Operation
• The select operation selects tuples that satisfy a given predicate.
• This operation pulls the horizontal subset (subset of rows) of the
relation that satisfies the conditions.
• Greek Letter Sigma (σ) is used to denote selection.
• The predicate appear as a subscript to σ.
• It can allow comparison using =, !=, >, ≥, <, ≤ in predicate.
• It can also combine several predicate into larger predicate using :
∧ (AND), ∨ (OR), ¬ (NOT)
• Example:
σ Place = “Vadodara”
Example
Roll Name Department Fees Team

1 Bikash CSE 22000 A

2 Josh CSE 34000 A

3 Kevin ECE 36000 C

4 Ben ECE 56000 D

Select all the student of Team A :


σ Team = 'A' (Student)

Output:
Roll Name Department Fees Team

1 Bikash CSE 22000 A

2 Josh CSE 34000 A


Project Operation
• This is a unary operator and is similar to select operation above.
• It creates the subset of relation based on the conditions
specified. Here, it selects only selected columns/attributes from
the relation- vertical subset of relation.
• The project operation is a unary operation that returns its
argument relation with certain attribute left out.
• Projection is denoted by the Greek letter Pi (∏).
• List those attributes that appear in the result as a subscript to ∏.
Example
Class Dept Position

5 CSE Assistant Professor

5 CSE Assistant Professor

6 EE Assistant Professor

6 EE Assistant Professor

Project Class and Dept from Faculty –


πClass, Dept(Faculty)
Output:
Class Dept

5 CSE

6 EE
Union Operation
• Notation: r ∪ s
• Defined as:
• r ∪ s = {t | t ∈ r or t ∈ s}
• For r ∪ s to be valid.
• 1. r, s must have the same arity (same number of attributes)
• 2. The attribute domains must be compatible (e.g., 2nd column
of r deals with the same type of values as does the 2nd
column of s)
Example
1.SELECT column_name FROM table1
UNION
SELECT column_name FROM table2;
Set Difference Operation

• Notation: r – s
• This is a binary operator.
• This operator creates a new relation with tuples that are in one
relation but not in other relation.
• It is denoted by ‘-‘symbol.
• Defined as:
• r – s = {t | t ∈ r and t ∉ s}
• Set differences must be taken between compatible relations.
– r and s must have the same arity
– attribute domains of r and s must be compatible
Consider a relation Student(FIRST, LAST) and Faculty(FIRSTN, LASTN) given
below :
First Last
FirstN LastN
Aisha Arora
Raj Kumar

Bikash Dutta
Honey Chand

Makku Singh
Makku Singh

Raju Chopra

Student MINUS Faculty :


Student - Faculty

First Last

Aisha Arora

Bikash Dutta

Raju Chopra
Cartesian-Product Operation
• Notation: r x s
• Allows to combine attributes from two relations.
• Defined as:
• r x s = {t q | t ∈ r and q ∈ s}
• Assume that attributes of r(R) and s(S) are disjoint. (That is,
R ∩ S = ∅).
• If attributes of r(R) and s(S) are not disjoint, then renaming
must be used.
Example
Consider two relations STUDENT(SNO, FNAME, LNAME) and DETAIL(ROLLNO,
AGE) below:
On applying CROSS PRODUCT on STUDENT and DETAIL:
STUDENT ✕ DETAILS
SNO FNAME LNAME ROLLNO AGE

1 Vishal Singh 5 18
2 Niya Patel 9 21

SNO FNAME LNAME ROLLNO AGE

1 Vishal Singh 5 18
1 Vishal Singh 9 21
2 Niya Patel 5 18
2 Niya Patel 9 21
Rename Operation
• Allows us to give the name, and therefore to refer to, the results of relational-
algebra expressions.
• Allows us to refer to a relation by more than one name.
• Example:
• ρ x (E)
• returns the result of expression E under the name X
• It is denoted by Greek letter rho(ρ).
• This is a unary operator used to rename the tables and columns of a relation.
• When we perform self join operation, we have to differentiate two same
tables. In such case rename operator on tables comes into picture
Example
Query to rename the relation Student as Male Student and
the attributes of Student – RollNo, SName as (Sno, Name).

Sno Name

2600 Ronny

2655 Raja
Set-Intersection
• This operation is a binary operation. It results in a relation with tuples that are
in both the relations. It is denoted by ‘∩’
• R∩S
• Where R and S are the relations. It picks all the tuples that are present in both R
and S, and results it in a new relation.
• DESIGN_EMPLOYEE – (DESIGN_EMPLOYEE – TESTING_EMPLOYEE)
• It first filters only those employees who are only design employees-(104,
Kathy)
Exam p le

Find all the customers whose account is in the bank and have taken out
a loan. Borrowe
Depositor
r
ID Name ID Name
1 Raj 2 Vinayak
2 Vinayak 3 Raj
3 Priya 5 Priya

∏Name(Depositor) ∩ ∏Name(Borrower)
Raj
Vinayak
Example Queries
• Find all loans of over $1200
 σamount > 1200 (loan)

• Find the loan number for each loan of an amount greater than $1200
 ∏loan-number (σamount > 1200 (loan))

• Find the names of all customers who have a loan, an account, or both, from
the bank
 ∏customer-name (borrower) ∪ ∏customer-name (depositor)

• Find the names of all customers who have a loan not an account at bank.
 ∏customer-name (borrower) ∩ ∏customer-name (depositor)
Modification of the Database
• The content of the database may be modified using the
following operations:
– Deletion
– Insertion
– Updating
• All these operations are expressed using the assignment
operator.
Deletion

• A delete request is expressed similarly to a query, except


instead of displaying tuples to the user, the selected tuples
are removed from the database.
• Can delete only whole tuples; cannot delete values on only
particular attributes
• A deletion is expressed in relational algebra by:
• r←r–E
• where r is a relation and E is a relational algebra query.
Deletion Examples

• Delete all account records in the Perryridge branch.


 account ← account – σ branch-name = “Perryridge” (account)
• Delete all loan records with amount in the range of 0 to 50
 loan ← loan – σ amount ≥ 0 and amount ≤ 50 (loan)
Insertion

• To insert data into a relation, we either:


– specify a tuple to be inserted
– write a query whose result is a set of tuples to be inserted
• in relational algebra, an insertion is expressed by:
• r← r ∪ E
• where r is a relation and E is a relational algebra expression.
• The insertion of a single tuple is expressed by letting E be a
constant relation containing one tuple.
Insertion Example

• Insert information in the database specifying that Smith has


$1200 in account A-973 at the Perryridge branch.
• account ← account ∪ {(“Perryridge”, A-973, 1200)}
• depositor ← depositor ∪ {(“Smith”, A-973)}
Updating

• A mechanism to change a value in a tuple without changing all


values in the tuple
• Use the generalized projection operator to do this task
• r ← ∏ F1, F2, …, FI, (r)
• Each Fi is either
– the ith attribute of r, if the ith attribute is not updated, or,
– if the attribute is to be updated Fi is an expression, involving only
constants and the attributes of r, which gives the new value for the
attribute
Updating

• Make interest payments by increasing all balances by 5


percent.
• account ← ∏ AN, BN, BAL * 1.05 (account)
• where AN, BN and BAL stand for account-number, branch-
name and balance, respectively.
View
• A view is a virtual or logical table that allow to view or
manipulate parts of the table.
• Unlike ordinary base tables in a relational database, a view
does not form part of the physical schema: as a result set, it
is a virtual table computed or collated dynamically from
data in the database when access to that view is requested.
• In database theory, a view is the result set of a stored query
on the data, which the database users can query just as
they would in a persistent database collection object.
Creating a View
• CREATE OR REPLACE VIEW <view_name> AS SELECT <any
valid select query>;
• Treated Like a table but not a table
• Derived from more than one table known as base table
• View does not have storage space to store data
• E.g. CREATE VIEW [Brazil Customers] AS
SELECT CustomerName, ContactName
FROM Customers
WHERE Country = 'Brazil';
Advantages of View
• Simplifies the access to certain data.
• Allows hiding of certain piece of data from unauthorized users.
Thus it restrict to access to the data such that a user can see or
modify exactly what they need.
• Views can join and simplify multiple tables into a single virtual
table.
• Views can hide the complexity of data.
• Views take very little space to store; the database contains only
the definition of a view, not a copy of all the data that it
presents.
Indexes
• An index, as you would expect, is a data structure that the
database uses to find records within a table more quickly.
• An index is an ordered list of content of the column or a group
of columns of table.
• Indexes are built on one or more columns of a table; each index
maintains a list of values within that field that are sorted in
ascending or descending order.
• Index is a pointer to data in a table.
• Rather than sorting records on the field or fields during query
execution, the system can simply access the rows in order of
the index.
Creating Index
• CREATE INDEX <indexname> ON <tablename>
(<column>, <column>...);
• Characteristics:
• An index is similar to table. It contains at least two
columns.
• A column having sorted data on which an index is
created.
• A column representing RowID for each row in a table
Characteristics of Index
• Way to improve overall performance by knowing
exactly where the data is on disk and avoiding costly
table scans.
• Makes searching and sorting of records in the table
fast.
• After index has been created oracle automatically
maintain that index.
• An associated indexes must be updated whenever
the table data is altered.
Database Trigger
• A database trigger is procedural code that is
automatically executed in response to certain events on
a particular table or view in a database.
• The trigger is mostly used for maintaining the integrity
of the information on the database.
• They are automatically executed before or after
invocation of operations like insert, update or delete.
• E.g.
create trigger stud_marks before INSERT
on Student for each row set
Student.total = Student.subj1 + Student.subj2 +
Student.subj3,
Student.per = Student.total * 60 / 100;
Stored Procedure
• A stored procedure is a subroutine available to
applications that access a relational database system.
• Stored procedures are similar to
user-defined functions (UDFs). The major difference
is that UDFs can be used like any other expression
within SQL statements, whereas stored procedures
must be invoked using the CALL statement.
• Typical use for stored procedures include
data validation (integrated into the database) or
Stored Procedure
• Furthermore, stored procedures can consolidate and
centralize logic that was originally implemented in
applications.
• Extensive or complex processing that requires execution of
several SQL statements is moved into stored procedures,
and all applications call the procedures.
• One can use nested stored procedures by executing one
stored procedure from within another.
Stored Procedure
• Syntax :
• CREATE PROCEDURE procedure_name
AS
sql_statement
GO;
• EXEC procedure_name;
• E.g. :
• CREATE PROCEDURE SelectAllCustomers
AS
SELECT * FROM Customers
GO;
• EXEC SelectAllCustomers;
Database Joins
• Join operation allows us to derive output from
multiple tables
• Join operation performs Cartesian product of rows of
two given relations
• Types of Joins
– Inner Join (Natural join)
– Outer Join
• Left Outer Join
• Right Outer Join

Inner Join

• The natural-join operation forms a Cartesian product of its two


arguments, performs a selection forcing equality on those attributes that
appear in both relation schemas, and finally removes duplicate
attributes.
• loan inner join borrower on loan.loan-number = borrower .loan-number
Left Outer Join
• The Left JOIN keyword returns all records from the Left table (table1), and the matching records from the
right table (table2). The result is 0 records from the right side, if there is no match
• Syntax
– SELECT column_name
FROM table1
LEFT JOIN table2
ON table1.column_name = table2.column_name;
• E.g.
– SELECT Customers.CustomerName, Orders.OrderID
FROM Customers
LEFT JOIN Orders ON Customers.CustomerID = Orders.CustomerID
ORDER BY Customers.CustomerName;
– Note: The LEFT JOIN keyword returns all records from the left table (Customers),
even if there are no matches in the right table (Orders).
Right Outer Join
• The RIGHT JOIN keyword returns all records from the right table (table2), and the
matching records from the left table (table1). The result is 0 records from the left side, if
there is no match
• Syntax :
– SELECT column_name(s)
FROM table1
RIGHT JOIN table2
ON table1.column_name = table2.column_name;
• E.g. :
– SELECT Orders.OrderID, Employees.LastName, Employees.FirstName
FROM Orders
RIGHT JOIN Employees ON Orders.EmployeeID = Employees.EmployeeID
Full Outer Join
• The FULL OUTER JOIN keyword returns all records when there is a match in left (table1) or right
(table2) table records.
• Tip: FULL OUTER JOIN and FULL JOIN are the same.
• Syntax :
• SELECT column_name(s)
FROM table1
FULL OUTER JOIN table2
ON table1.column_name = table2.column_name
WHERE condition;
• E.g. :
– SELECT Customers.CustomerName, Orders.OrderID
FROM Customers
FULL OUTER JOIN Orders ON Customers.CustomerID=Orders.CustomerID
ORDER BY Customers.CustomerName;
– Note: The FULL OUTER JOIN keyword returns all matching records from both tables whether the other
table matches or not. So, if there are rows in "Customers" that do not have matches in "Orders", or if
there are rows in "Orders" that do not have matches in "Customers", those rows will be listed as well.
Relational Calculus
• Relational calculus is a non procedural query language.
• It uses mathematical predicate calculus instead of
algebra.
• It provides the description about the query to get the
result where as relational algebra gives the method to
get the result. It informs the system what to do with
the relation, but does not inform how to perform it.
Tuple Relational Calculus
• A tuple relational calculus is a non procedural query language which specifies to
select the tuples in a relation.
• It can select the tuples with range of values or tuples for certain attribute
values etc. The resulting relation can have one or more tuples. It is denoted as
below:
• {t | P (t)} or {t | condition (t)} -- this is also known as expression of relational
calculus
• It describes the desired information without giving a specific procedure for
obtaining that information.
• Where
– T is the resulting tuples
– P(T) is the condition used to fetch T.It describes the desired information without giving a
specific procedure for obtaining that information.
Tuple Relational Calculus
• For example:
• Below query selects the tuples from the AUTHOR relation. It
returns a tuple with 'name' from Author who has written an
article on 'database'.
• { T.name | Author(T) AND T.article = 'database' }
Tuple Relational Calculus
• For example:
• Find branch-name, loan-number and amount for loans of over
$1200.

{t| t ∈ loan ^ t[amount] >1200}
• It selects all tuples t from relation loan such that the resulting
loan tuples will have amount greater than $1200.
The Relational Model
• Gather user/business requirements.
• Develop the conceptual ER Model (shown as an ER Diagram)
based on the user/business requirements.
• Convert the ER Model to a set of relations in the (logical)
relational model
• Normalize the relations to remove any anomalies.
• Implement the database by creating a table for each normalized
relation in a relational database management system.
What is Normalization?
• Database Normalization is proposed by Dr. EDGAR F. CODD.
• Normalization is a process that “improves” a database design
by generating relations that are of higher normal forms.
• Normalization is also the process of simplifying the design of
a database so that it achieves the optimum structure. It
reduces and eliminate redundant data.
• The main goal of Database Normalization is to restructure the
logical data model of a database to:
• Eliminate redundancy
• Organize data efficiently
Data Anomalies
• Data anomalies are inconsistencies in the data stored in a
database as a result of an operation such as update, insertion,
and/or deletion.
• Such inconsistencies may arise when have a particular record
stored in multiple locations and not all of the copies are
updated.
• We can prevent such anomalies by implementing 7 different
level of normalization called Normal Forms (NF)
Functional Dependencies
• A Functional Dependency describes a relationship between
attributes within a single relation.
• An attribute is functionally dependent on another if we can use
the value of one attribute to determine the value of another.
• Example: Employee_Name is functionally dependent on
Social_Security_Number because Social_Security_Number can
be used to uniquely determine the value of Employee_Name.
• We use the arrow symbol → to indicate a functional
dependency.
• X → Y is read X functionally determines Y
Modification Anomalies
• Once our ER model has been converted into relations, we may
find that some relations are not properly specified. There can be
a number of problems:
• Deletion Anomaly: Deleting one fact or data point from a
relation results in other information being lost.
• Insertion Anomaly: Inserting a new fact or tuple into a relation
requires we have information from two or more entities – this
situation might not be feasible.
• Update Anomaly: Updating one fact in a relation requires us to
update multiple tuples.
Normalization Process
• Relations can fall into one or more categories (or classes) called Normal Forms
• Normal Form: A class of relations free from a certain set of modification anomalies.
• Normal forms are given names such as:
1. First normal form (1NF)
2. Second normal form (2NF)
3. Third normal form (3NF)
4. Boyce Codd normal form (BCNF)
5. Fourth normal form (4NF)
6. Fifth normal form (5NF)
7. Domain Key normal form (DK/NF)
• These forms are cumulative. A relation in Third normal form is also in 2NF and 1NF.
1 Normal form -1NF
st

• A relation is in first normal form if it meets the definition of a


relation:
1. Each attribute (column) value must be a single value only.
2. Each attribute (column) name must be unique.
3. No two tuples (rows) in a relation can be identical.
4. If you have a key defined for the relation, then you can meet the
unique row requirement.
• A relation is in 1NF if all values stored in the relation are single-
valued and atomic.
1 Normal form -1NF
st

• If you have a key defined for the relation, then you can meet
the unique row requirement.
• Example relation in 1NF (note that key attributes are
underlined):
• STOCKS (Company, Symbol, Headquarters, Date, Close_Price)
Second Normal Form (2NF)

• A relation is in second normal form (2NF) if all of its non-key


attributes (Non Prime)are dependent on all of the key.
• Another way to say this: A relation is in second normal form if it
is free from partial key dependencies.
• A relation is in 2NF if it is in 1NF, and every non-key attribute is
fully dependent on each candidate key. (That is, we don’t have
any partial functional dependency.)
• Relations that have a single attribute for a key are automatically
in 2NF.
Second Normal Form (2NF)
• This violates the rule for 2NF in that a part of our key
determines a non key attribute.
• Another name for this is a Partial key dependency. Symbol is
only a “part” of the key and it determines a non-key
attribute.
• Also, consider the insertion and deletion anomalies.
Second Normal Form (2NF)

• This violates the rule for 2NF in that a part of our key key determines a non key attribute.
• Another name for this is a Partial key dependency. Symbol is only a “part” of the key and
it determines a non-key attribute.
• Also, consider the insertion and deletion anomalies.
Second Normal Form (2NF)
• One Solution: Split this up into two new relations:
• COMPANY (Company, Symbol, Headquarters)
• STOCK_PRICES (Symbol, Date, Close_Price)
• At this point we have two new relations in our relational
model. The original “STOCKS” relation we started with is
removed form the model.
• Sample data and functional dependencies for the two new
relations:
• COMPANY Relation:
Third Normal Form (3NF)
• A relation is in 3NF if the relation is in 2NF and all
determinants of non-key attributes are candidate keys
• That is, for any functional dependency: X → Y, where Y is a
non-key attribute (or a set of non-key attributes), X is a
candidate key.
• A relation in 3NF will not have any transitive dependencies of
non-key attribute on a candidate key through another non-key
attribute.(If one non-key -> non-key attribute)
Second Normal Form (2NF)
• STOCK_PRICES relation:
• FD1: Symbol, Date → Close Price
•Symbol •Date ClosePrice

•MSFT •09/07/2013 •23.96

•MSFT •09/08/2013 •23.93

•MSFT •09/09/2013 •24.01

•ORCL •09/07/2013 •24.27

•ORCL •09/08/2013 •24.14

•ORCL •09/09/2013 •24.33

So, Definition of 1NF (each one has well defined unique keys) and 2NF (no
partial key dependencies).
Third Normal Form (3NF)
• The functional dependencies we can see are:
• FD1: Symbol → Company
• FD2: Company → Headquarters
• so therefore:
• Transitive dependency: Symbol → Headquarters
• This is a transitive dependency.
Third Normal Form (3NF)
• What happens if we remove Oracle?
• We loose information about 2 different facts.
• The solution again is to split this relation up into two new
relations:
• STOCK_SYMBOLS(Company, Symbol)
• COMPANY_HEADQUARTERS(Company, Headquarters)
Third Normal Form (3NF) example :-
• Here, EMP_STATE & EMP_CITY dependent on EMP_ZIP and EMP_ZIP
dependent on EMP_ID. The non-prime attributes (EMP_STATE, EMP_CITY)
transitively dependent on super key(EMP_ID). It violates the rule of third
normal form.
That's why we need to move the EMP_CITY and EMP_STATE to the new
<EMPLOYEE_ZIP> table, with EMP_ZIP as a Primary key.
Integrity
• Integrity of database means correctness of data stored in the
database.
• Constraints are set of defined rules which are used to maintain
integrity of database.
• 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
• Domain constraints are the most elementary form of integrity constraint.
• Domain constraints can be defined as the definition of a valid set of values for an
attribute.
• They test values inserted in the database, and test queries to ensure that the
comparisons make sense.
• Implementation: Data types and derived data types
• Domain Constraint = data type + Constraints (NOT NULL / UNIQUE / PRIMARY KEY /
FOREIGN KEY / CHECK / DEFAULT)
Referential Integrity
• Based on foreign key concept
• Referential integrity is a property of data which, when satisfied,
requires every value of one attribute (column) of a relation
(table) to exist as a value of another attribute in a different (or
the same) relation (table).
• Foreign key is an attribute or a set of attributes whose values
correspond to primary key of another table.
• Master table within relation is one which contains primary key
• Detail table in a relation is one which contains foreign key.
Referential Integrity

• In the Referential integrity constraints, if a foreign key in Table 1


refers to the Primary Key of Table 2, then every value of the
Foreign Key in Table 1 must be null or be available in Table 2
Referential Integrity in E-R Model
• Consider relationship set R between entity sets E1 and E2. The relational schema
for R includes the primary keys K1 of E1 and K2 of E2.
Then K1 and K2 form foreign keys on the relational schemas for E1 and E2
respectively.

• Weak entity sets are also a source of referential integrity constraints.


– For the relation schema for a weak entity set must include the primary key attributes of the entity
set on which it depends
Assertions
• An assertion is a predicate expressing a condition that we wish the
database always to satisfy.
• Domain constraints, functional dependency and referential integrity
are special forms of assertion.
• An assertion in SQL takes the form
• create assertion <assertion-name> check <predicate>
• When an assertion is made, the system tests it for validity, and tests
it again on every update that may violate the assertion
– This testing may introduce a significant amount of overhead;hence assertions should be used with great
care.
Assertions Example
• Do not allow braches of Vadodara:

create assertion branch-constraint check
(not exists (select * from branch
where branch_name = ‘Vadodara’))
• Ensuring every loan customer keeps a minimum of $1000 in an
account.
Security
• Database security refers to protection from malicious access.
• A security policy defines who should be allowed to see and/or
modify specific data in the system.
• Database system level
– Authentication and authorization mechanisms to allow specific users access only to required
data.

• Operating system level


– Operating system super-users can do anything they want to the database! Good operating
system level security is required.
Security
• Network level: must use encryption to prevent
– Eavesdropping (unauthorized reading of messages)
– Masquerading (A masquerade attack is an attack that uses a fake identity, such as a network identity, to gain
unauthorized access to personal computer information through legitimate access identification.)


Physical level
– Physical access to computers allows destruction of data by intruders; traditional lock-and-key security is needed.
– Computers must also be protected from floods, fire, etc.


Human level
– Users must be screened to ensure that an authorized users do not give access to intruders.
– Users should be trained on password selection and secrecy.
Authorization
• Forms of authorization on parts of the database:
• Read authorization - allows reading, but not modification of
data.
• Insert authorization - allows insertion of new data, but not
modification of existing data.
• Update authorization - allows modification, but not deletion of
data.
• Delete authorization - allows deletion of data.
Authorization
• Forms of authorization to modify the database schema:

Index authorization - allows creation and deletion of indices.
• Resources authorization - allows creation of new relations.
• Alteration authorization - allows addition or deletion of
attributes in a relation.
• Drop authorization - allows deletion of relations.
Authorization and Views
• Users can be given authorization on views, without being
given any authorization on the relations used in the view
definition.
• Ability of views to hide data serves both to simplify usage of
the system and to enhance security by allowing users access
only to data they need for their job.
• A combination or relational-level security and view-level
security can be used to limit a user’s access to precisely the
data that user needs.
GRANTING PRIVILEGES
The grant statement is used to confer authorization
grant <privilege list>
on <relation name or view name> to <user list>
<user list> is:
 a user-id public, which allows all valid users the privilege granted
 A role

Granting a privilege on a view does not imply granting any


privileges on the underlying relations.
The grantor of the privilege must already hold the privilege on the
specified item (or be the database administrator).
PRIVILEGES IN SQL
select: allows read access to relation, or the ability to query using
the view
 Example: grant users U1, U2, and U3 select authorization on the branch relation:

grant select on branch to U1, U2, U3


insert: the ability to insert tuples
update: the ability to update using the SQL update statement
delete: the ability to delete tuples.
references: ability to declare foreign keys when creating relations.
all privileges: used as a short form for all the allowable privileges
PRIVILEGES TO GRANT
PRIVILEGE
with grant option: allows a user who is granted a privilege to
pass the privilege on to other users.
 Example:

grant select on branch to U1 with grant option


gives U1 the select privileges on branch and allows U1 to grant this
privilege to others
REVOKING
AUTHORIZATION IN SQL
The revoke statement is used to revoke authorization.
revoke<privilege list>
on <relation name or view name> from <user list> [restrict|cascade]
Example:
revoke select on branch from U1, U2, U3 cascade
Revocation of a privilege from a user may cause other users also to lose that
privilege; referred to as cascading of the revoke.
We can prevent cascading by specifying restrict:
revoke select on branch from U1, U2, U3 restrict
With restrict, the revoke command fails if cascading revokes are required.
ROLES
Roles permit common privileges for a class of users can be specified just
once by creating a corresponding “role”.
Privileges can be granted to or revoked from roles, just like user.
Roles can be assigned to users, and even to other roles.
SQL:
create role teller
create role manager

grant select on branch to teller


grant update (balance) on account to teller
grant all privileges on account to manager
ENCRYPTION
Data may be encrypted when database authorization provisions do
not offer sufficient protection.
Properties of good encryption technique:
 Relatively simple for authorized users to encrypt and decrypt data.
 Encryption scheme depends not on the secrecy of the algorithm but on the
secrecy of a parameter of the algorithm called the encryption key.
 Extremely difficult for an intruder to determine the encryption key.
ENCRYPTION
Data Encryption Standard (DES) substitutes characters and rearranges their
order on the basis of an encryption key which is provided to authorized users
via a secure mechanism. Scheme is no more secure than the key
transmission mechanism since the key has to be shared.
Advanced Encryption Standard (AES) is a new standard replacing DES, and is
based on the Rijndael algorithm, but is also dependent on shared secret keys
Public-key encryption is based on each user having two keys:
 public key – publicly published key used to encrypt data, but cannot be used to decrypt data
 private key -- key known only to individual user, and used to decrypt data.
Need not be transmitted to the site doing encryption.

Encryption scheme is such that it is impossible or extremely hard to decrypt


data given only the public key.
AUTHENTICATION
Password based authentication is widely used, but is susceptible to
sniffing on a network
Challenge-response systems avoid transmission of passwords
 DB sends a (randomly generated) challenge string to user
 User encrypts string and returns result.
 DB verifies identity by decrypting result
 Can use public-key encryption system by DB sending a message encrypted using user’s
public key, and user decrypting and sending the message back

Digital signatures are used to verify authenticity of data


 E.g. use private key (in reverse) to encrypt data, and anyone can verify authenticity by
using public key (in reverse) to decrypt data. Only holder of private key could have
created the encrypted data.
 Digital signatures also help ensure nonrepudiation: sender cannot later claim to have
not created the data.
THANK YOU!

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy