You are on page 1of 8

Chp4

CHP 4
A view is updatable when?

The from clause has only one database relation


The select clause contains only attribute names of the relation and does not
have
any expressions, aggregates, or distinct specification.

Any attribute not listed in the select clause can be set to null; that is, it does
not
have a not null constraint and is not part of a primary key.
The query does not have a group by or having clause.

view relation
View relations can be defined as relations containing the result of queries.
Views
are useful for hiding unneeded information and for gathering together
information
from more than one relation into a single view.

integrity constraint
Integrity constraints ensure that changes made to the database by authorized
users
do not result in a loss of data consistency.

referential integrity constraint


Referential-integrity constraints ensure 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.

domain constraint
Domain constraints specify the set of possible values that may be associated
with
an attribute. Such constraints may also prohibit the use of null values for

Chp4 1
particular
attributes.

Transaction

Transactions are sequences of queries and updates that together carry out a
task.
Transactions can be committed, or rolled back; when a transaction is rolled
back,
the effects of all updates performed by the transaction are undone.

Assertion

In SQL, an assertion is a statement that specifies a condition that must be


true at all times. Assertions are used to enforce business rules and ensure
data integrity in the database.
The SQL statement you provided is an example of creating an assertion. The
name of the assertion is "credits-earned", and the "CHECK" constraint
ensures that the assertion condition is met.

The assertion condition is specified as "NOT EXISTS" clause that uses a


subquery to check whether there exists any student who has a different "tot
cred" value from the sum of credits earned in all courses that the student has
taken and received a non-null and non-"F" grade. In other words, the
assertion ensures that the "tot cred" value for each student is consistent with
the sum of credits earned for all completed courses.
If the assertion condition is not met, an error will be thrown, and the operation
that violates the assertion will be rolled back. Therefore, assertions help to
maintain the integrity of the database by preventing the insertion, deletion, or
modification of data that does not satisfy the specified conditions.

Assertion example

create assertion credits-earned constraint check


(not exists (select ID
from student
where tot cred <> (select coalesce(sum(credits), 0)
from takes natural join course
where student.ID= takes.ID
and grade is not null and grade<> ’F’ )))

Indices

Chp4 2
Indices are important for efficient processing of queries, as well as for
efficient
enforcement of integrity constraints. Although not part of the SQL standard,
SQL
commands for creation of indices are supported by most database systems.

Roles
Roles enable us to assign a set of privileges to a user according to the role
that the
user plays in the organization.

using check example:

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')));

Dropping constraint

salary numeric(8,2), constraint minsalary check (salary > 29000),


alter table instructor drop constraint minsalary;

creating index

create index <index-name> on <relation-name> (<attribute-list>);

creating domain

create domain DDollars as numeric(12,2) not null;

auto increment
we use auto increment in place of generated always as identity, while in SQL
Server we can use just identity.

catalogue, schema, relation

reference privilege

Chp4 3
SQL includes a references privilege that permits a user to declare foreign
keys when creating relations.
grant references (dept name) on department to Mariano;

with grant option

grant select on department to Amit with grant option;


In your example, the command "GRANT SELECT ON department TO Amit
WITH GRANT OPTION" would give Amit the SELECT privilege on the
"department" table and also allow Amit to grant the SELECT privilege to
other users.
So, Amit would be able to execute the following command: "GRANT SELECT
ON department TO another_user" and grant the SELECT privilege to
"another_user".

authorization graph
The passing of a specific authorization from one user to another can be
represented by an authorization graph.
The nodes of this graph are the users.
A user who creates a new relation is given all privileges on that relation
automatically.
Authorizations on data include:
Authorization to read data. Authorization to insert new data.
Authorization to update data. Authorization to delete data.
Each of these types of authorizations is called a privilege.

data types, user defined types


date '2018-04-25'
time '09:30:00'
timestamp '2018-04-25 10:29:01.45'
create type Dollars as numeric(12,2) final;
cast (department.budget to numeric(12,2))

final
That's correct. If you create a user-defined data type in SQL and mark it
as "FINAL", you cannot extend or modify that data type to create new
subtypes. This means that you cannot convert the "Dollars" type to a
different data type later, or create new data types based on the "Dollars"
type.

Chp4 4
If you need to modify the data type later, you will need to create a new
data type based on the original "Dollars" type, but with the modifications
you require. This new data type would not be considered a subtype of the
"Dollars" type, but rather a separate data type that shares some of the
same characteristics.
It's worth noting that marking a data type as "FINAL" can help to ensure
data integrity and consistency in a database system, but it can also limit
flexibility and make it more difficult to modify the data type later. It's
important to consider the trade-offs carefully when designing a database
schema and deciding how to define user-defined data types.

extract function
In SQL, the EXTRACT function is used to extract a specific part (such as
year, month, day, hour, minute, or second) of a date or timestamp value.
Here's an example of how to use the EXTRACT function in a SQL query:

Suppose we have a table "orders" with a column "order_date" of type


"timestamp". We can use the EXTRACT function to retrieve the year of the
order_date for each order:

SELECT EXTRACT(YEAR FROM order_date) AS order_year


FROM orders;

cast function to convert data type


SELECT CAST(salary AS INT) AS salary_int
FROM employees;

sys-context→private data

SELECT SYS_CONTEXT('USERENV', 'SESSION_USER') AS current_user


FROM dual;

row level authorization


Row-level authorization is a database security feature that allows database
administrators to control access to individual rows of data in a table based on
the user's permissions. With row-level authorization, different users can be
granted different levels of access to the same table based on the contents of
the row.
This type of authorization is often used to ensure that users can only access
the data that they are authorized to see. For example, a bank might use row-

Chp4 5
level authorization to ensure that each bank teller can only access the
account information for the customers they are assigned to serve.
Row-level authorization can be implemented in different ways, depending on
the database system being used. Some databases provide built-in row-level
security features, while others may require the use of custom scripts or third-
party tools to implement this type of security. Regardless of the
implementation, row-level authorization is an important tool for ensuring the
security and integrity of sensitive data stored in a database.

decode example
select ID, decode (salary, null, 'N/A', salary) as salary
from instructor

lob

clob, blob

grant eg
grant <privilege list> on <relation name or view name> to <user/role list>;
grant select on department to Amit, Satoshi;
grant update (budget) on department to Amit, Satoshi;

revoke eg

revoke select on department from Amit, Satoshi;


revoke update (budget) on department from Amit, Satoshi;
execute privilege can be granted on a function or procedure, enabling a user
to execute the function or procedure.

cascading revocation

As we just saw, revocation of a privilege from a user/role may cause other


users/roles also to lose that privilege. This behavior is called cascading
revocation.

to revoke with option


revoke grant option for select on department from Amit;

restrict after revoke

revoke select on department from Amit, Satoshi restrict;

In SQL, the "RESTRICT" keyword is used in conjunction with the "REVOKE"


command to restrict the revocation of a privilege. When a privilege is revoked

Chp4 6
with the "RESTRICT" option, the revocation will only be allowed if the
privilege is not currently in use by any of the specified users or roles.

In the example given, the "REVOKE" command is used to revoke the


"SELECT" privilege on the "department" table from the users "Amit" and
"Satoshi". The "RESTRICT" keyword is used to indicate that the revocation
should only be allowed if the "SELECT" privilege is not currently being used
by either of these users.

If the "SELECT" privilege is currently in use by either "Amit" or "Satoshi", the


revocation will fail and an error message will be generated. This can help to
ensure that privileges are only revoked when they are no longer needed, and
prevent accidental or unintended revocation of privileges that could lead to
data integrity or security issues.

cascade after revoke

revoke select on department from Amit, Satoshi cascade;


In SQL, the "CASCADE" keyword is used in conjunction with the "REVOKE"
command to revoke a privilege and also revoke any dependent privileges
that were granted based on the original privilege. When a privilege is revoked
with the "CASCADE" option, any privileges that were granted based on the
original privilege will also be automatically revoked.

In the example given, the "REVOKE" command is used to revoke the


"SELECT" privilege on the "department" table from the users "Amit" and
"Satoshi". The "CASCADE" keyword is used to indicate that any dependent
privileges granted based on the "SELECT" privilege should also be
automatically revoked.

For example, if "Amit" and "Satoshi" were both granted the "SELECT"
privilege on the "department" table, and then other users were granted the
"SELECT" privilege on views or subqueries based on the "department" table,
those dependent privileges would also be automatically revoked if the original
"SELECT" privilege is revoked with the "CASCADE" option.

Using the "CASCADE" option can help to ensure that dependent privileges
are not left dangling or unused when the original privilege is revoked, and
can help to maintain data integrity and security in a database system.
However, it's important to use this option carefully and ensure that all
dependent privileges are correctly identified and accounted for before
revoking the original privilege.

Chp4 7
like ‘ab#%cd%` escape # ;v

exist, not exist for checking empty relations

outter query→ correlation

inner→correlated

transaction
commit work

rollback work

atomic→indivisible

dependencies→type of constraints

Chp4 8

You might also like