Module -III
Module -III
Module -III
Chapter-I
Functional Dependencies & Normalization for Relational
Databases
Functional Dependence:
- The attribute B is functionally dependent on A if A determines B. “A determines B”
indicates that knowing the value of attribute A means that we can look up (determine)
the value of attribute B. In this case, attribute A is the called the determinant.
- For example, knowing the PROD_CODE in the PRODUCT table in Figure 1 means
we can look up the product’s description, product price and so on. The notation we use
for “A determines B” is:
A→B if A determines B
A → B, C, D if A determines B, C & D
Using the above example, we have
PROD_CODE → PROD_DESCRIPT
- As a rule, note that the primary key determines every other attribute in the table.
Eg:
Guideline 1. Design a relation schema so that it is easy to explain its meaning. Do not combine
attributes from multiple entity types and relationship types into a single relation. Intuitively, if a
relation schema corresponds to one entity type or one relationship type, it is straightforward to
explain its meaning. Otherwise, if the relation corresponds to a mixture of multiple entities and
relationships, semantic ambiguities will result and the relation cannot be easily explained.
2. Reducing the Redundant Value in Tuples
Mixing attributes of multiple entities may cause problems Information is stored
redundantly wasting storage Problems with update anomalies
Insertion anomalies
Deletion anomalies
Modification anomalies
Eg:
Another problem is updata anamolies ie if we insert new dept that has no students.
If we delet the last student of a dept,then whole information about that department will be
deleted
If we change the value of one of the attributes of aparticaular table the we must update the
tuples of all the students belonging to thet depy else Database will become inconsistent.
Guideline 2. Design the base relation schemas so that no insertion, deletion, or odification
anomalies are present in the relations. If any anomalies are present, note them clearly and make
sure that the programs that update the database will
Attributes that are NULL frequently could be placed in separate relations (with the
primary key)
Guideline 3. As far as possible, avoid placing attributes in a base relation whose values may
frequently be NULL. If NULLs are unavoidable, make sure that they apply in exceptional cases
only and do not apply to a majority of tuples in the relation. operate correctly.
Guideline 4. Design relation schemas so that they can be joined with equality conditions on
attributes that are appropriately related (primary key, foreign key) pairs in a way that guarantees
that no spurious tuples are generated. Avoid relations that contain matching attributes that are
not (foreign key, primary key) combinations because joining on such attributes may produce
spurious tuples.
- Normalization
- Normalization is a technique used to design table structures in which data redundancies
are minimized/eliminated.
- Normalization works through a series of stages called normal forms. The first three stages
are described as first normal form (1NF), second normal form (2NF), and third normal
form (3NF).
- From a structural point of view, 2NF is better than 1NF, and 3NF is better than 2NF.
- For most business database design purposes, 3NF is as high as we need to go in the
normalization process.
- You should not assume that the highest level of normalization is always the most
desirable. Generally, the higher the normal form, the more joins are required to produce a
specified output and the more slowly the database responds to end user demands.
Therefore, you will occasionally be expected to denormalize some table structures to
avoid performance degradation.
- Denormalization is the reverse process of normalization and it produces a lower normal
form; that is, 3NF can be denormalized to 2NF and 2NF can be denormalized to 1NF.
- The table in Figure 2 contains information about projects and employees working on
these projects. This table does not conform to the Relational Database Model we learned
in Chapter 5 for the following reasons:
- Figure 4 below displays the conversion of the table in Figure 2 to 1NF by satisfying the above
three conditions.
- Note that the table in Figure 4 satisfies the three conditions. The first condition is satisfied
because the table has a composite primary key consisting of the key attributes PROJ_NUM
and EMP_NUM. The second condition is satisfied because the table no longer contains
repeating groups. The third condition is satisfied because any attribute is dependent on the
primary key. For example, EMP_NAME is dependent on the primary key PROJ_NUM,
EMP_NUM because if we know PROJ_NUM and EMP_NUM (15 and 103 for example), we
can determine EMP_NAME (J. Arbough).
- Dependencies between attributes for the table in Figure 4 can be identified with the help of
the dependency diagram as shown in Figure 5 below:
3. The arrows below the dependency diagram indicate less desirable dependencies:
- A table is said to be in second normal form (2NF) if it satisfies the following conditions:
1. It is in 1NF.
2. It includes no partial dependencies; that is, no attribute is dependent on a portion of the
primary key.
- Let us convert the table in Figure 4 from 1NF to 2NF. To do that, follow these steps:
1. Write each key attribute (recall from Chapter 2 that a key attribute is an attribute
that is part of the key) on a separate line, then write the primary key on the last
line:
PROJ_NUM
EMP_NUM
PROJ_NUM EMP_NUM
The attributes on each line will become keys in a new table. In other words, the
original table is now split into three tables. We’ll call these tables PROJECT,
EMPLOYEE and ASSIGN respectively.
2. The attribute(s) on each line will form the primary key for the new tables. The
rest of the attributes for each table can be determined from the dependency
diagram:
PROJECT(PROJ_NUM, PROJ_NAME) because in the dependency diagram in
Figure 5, PROJ_NUM → PROJ_NAME
EMPLOYEE(EMP_NUM, EMP_NAME, JOB_CLASS, CHG_HOUR) because
in the dependency diagram in Figure 5, EMP_NUM → EMP_NAME,
JOB_CLASS, CHG_HOUR
ASSIGN(PROJ_NUM, EMP_NUM, HOURS) because in the dependency
diagram in Figure 5, PROJ_NUM, EMP_NUM → HOURS
- Note that the new tables are in 2NF because each table is in 1NF and none of the tables
contain partial dependencies. The dependency diagram for the new tables is shown in Figure
6:
- Note that the conversion to 2NF did not eliminate the transitive dependency (the conversion
to 3NF will eliminate it). This dependency causes data redundancy if multiple employees
have the same JOB_CLASS and it will therefore create the data anomalies we learned in
Chapter 1.
- Because a partial dependency applies only to tables with composite primary keys, a table
whose primary key consists of only a single attribute must automatically be in 2NF if it is in
1NF.
- To eliminate the transitive dependency, the table must be converted to 3NF. A table is said to
be in 3NF if it satisfies the following two conditions:
1. It it is in 2NF.
2. It contains no transitive dependencies.
- Note that in Figure 6, the EMPLOYEE table is the one that contains transitive dependency:
- To eliminate the transitive dependency, simply move the attributes causing data redundancy
(namely JOB_CLASS and CHG_HOUR) into a new table called JOB. Then in the
EMPLOYEE table, define a foreign key that will be used to link it to the JOB table. In this
case, the foreign key will be JOB_CLASS. The result of the conversion to 3NF will be the
following tables:
- Note that the conversion to 3NF has eliminated the original EMPLOYEE table’s transitive
dependency; the tables are now said to be in third normal form (3NF).
A B C D
A, B → C, D
C→B
- Note that the table structure in Figure 7 has no partial dependencies nor does it contain
transitive dependencies (Note that C → B indicates that a nonkey attribute determines a
key attribute and this dependency is neither partial nor transitive).
- Therefore, the table structure in Figure 7 is in 3NF but not in BCNF because of the
dependency C → B.
- To convert the table structure in Figure 7 to BCNF, follow the following procedure:
A C D
C B
- The table structure above is in 3NF but not BCNF because CLASS_CODE is a
determinant but not a superkey key. Why? To convert this table structure, we apply the
above procedure by creating two tables. The first table will contain STU_ID,
CLASS_CODE and ENROLL_GRADE (with STU_ID and CLASS_CODE as the primary
key). The second table will contain the attributes CLASS_CODE and STAFF_ID with
CLASS_CODE as the primary key. The result of the conversion to BCNF is shown in
Figure 10 below.
CLASS_CODE STAFF_ID
Examples
Multivalued Dependencies
For example, consider the relation EMP shown in Figure below:
■ A tuple in this EMP relation represents the fact that an employee whose name is
Ename works on the project whose name is Pname and has a dependent whose
name is Dname
■ An employee may work on several projects and may have several dependents
■ To keep the relation state consistent, and to avoid any spurious relationship
between the two independent attributes, we must have a separate tuple to
represent every combination of an employee's dependent and an employee's
project
■ In the relation state shown in the EMP, the employee Smith works on two
projects 'X' and 'Y' and has two dependents 'John' and 'Anna' and therefore there
are 4 tuples to represent these facts together
■ The relation EMP is an all-key relation (with key made up of all attributes) and
■ proposed and based on this dependency, the fourth normal form was defined
■ Informally, whenever two independent 1:N relationships are mixed in the same
relation, R(A, B, C), an MVD may arise.
The process of normalizing a relation involving the nontrivial MVDs that is not in
4NF consists of decomposing it so that each MVD is represented by a separate
relation where it becomes a trivial MVD
First we decompose relation R to R1 and R2 , where if we join R1* R2 , we get a spurious tuple
(any new record is arised) as in fig shown so If we can decompose table further to eliminate
redundancy and anomaly, and when we re-join the decomposed tables by means of candidate
keys, we should not be losing the original data or In simple words, joining two or more
decomposed table should not lose records nor create new.
Example 2:
SQL is a comprehensive database language: It has statements for data definitions, queries, and
updates. Hence, it is both a DDL and a DML. It also has rules for embedding SQL statements
into a general-purpose programming language such as Java,COBOL,or C/C++.
SQL uses the terms table, row, and column for the formal relational model terms
relation,tuple,andattribute,respectively.We will use the corresponding terms interchangeably.
The main SQL command for data definition is the CREATE statement, which can be used to
create schemas, tables (relations), and domains (as well as other constructs such as views,
assertions, and triggers).
The concept of an SQL schema was incorporated starting with SQL2 in order to group together
tables and other constructs that belong to the same database application. An SQL schema is
identified by a schema name, and includes an authorization identifier to indicate the user or
account who owns the schema,as well as descriptors for each element in the schema.Schema
elements include tables,constraints,views,domains,and other constructs (such as authorization
grants) that describe the schema.
A schema is created via the CREATE SCHEMA statement,which can include all the schema
elements’ definitions. Alternatively, the schema can be assigned a name and authorization
identifier, and the elements can be defined later. For example, the following statement creates a
schema called COMPANY,owned by the user with authorization identifier ‘Jsmith’.Note that
each statement in SQL ends with a semicolon.
The CREATE TABLE command is used to specify a new relation by giving it a name and
specifying its attributes and initial constraints.The attributes are specified first, and each attribute
is given a name, a data type to specify its domain of values, and any attribute constraints, such as
NOT NULL. The key, entity integrity, and referential integrity constraints can be specified
within the CREATE TABLE statement after the attributes are declared, or they can be added
later using the ALTER TABLE command. we can explicitly attach the schema name to the
relation name, separated by a period.
rather than
we can explicitly (rather than implicitly) make the EMPLOYEEtable part of the COMPANY
schema.
The relations declared through CREATE TABLE statements are called base tables (or base
relations); this means that the relation and its tuples are actually created and stored as a file by
the DBMS.Base relations are distinguished from virtual relations, created through the CREATE
VIEWstatement which may or may not correspond to an actual physical file.
Example:
CREATE TABLE EMPLOYEE ( Fname VARCHAR(15) NOT NULL, Minit CHAR, Lname
VARCHAR(15) NOT NULL, Ssn CHAR(9) NOT NULL, Bdate DATE, Address
VARCHAR(30), Sex CHAR, Salary DECIMAL(10,2), Super_ssn CHAR(9), Dno INT NOT
NULL, PRIMARY KEY (Ssn), FOREIGN KEY (Super_ssn) REFERENCES
EMPLOYEE(Ssn), FOREIGN KEY (Dno) REFERENCES DEPARTMENT(Dnumber)) ;
The basic data types available for attributes include numeric, character string, bit
string,Boolean,date,and time.
■Numeric data types include integer numbers of various sizes (INTEGER or INT, and
SMALLINT) and floating-point (real) numbers of various precision (FLOAT or REAL, and
DOUBLE PRECISION). Formatted numbers can be declared by using DECIMAL(i,j)—or
DEC(i,j) or NUMERIC(i,j)—where i, the precision, is the total number of decimal digits and j,
the scale, is the number of digits after the decimal point.
■Bit-string data types are either of fixed length n—BIT(n)—or varying length—BIT
VARYING(n), where n is the maximum number of bits. The default for n, the length of a
character string or bit string, is 1. Literal bit strings are placed between single quotes but
preceded by a B to distinguishthem from character strings;
for example,B‘10101’
■A Boolean data type has the traditional values of TRUE or FALSE. In SQL, because of the
presence of NULL values, a three-valued logic is used, so a third possible value for a Boolean
data type is UNKNOWN.
The TIME data type has at least eight positions,with the components HOUR,MINUTE,and
SECOND in the form HH:MM:SS.
■ A timestamp data type (TIMESTAMP) includes the DATE and TIME fields, plus a minimum
of six positions for decimal fractions of seconds and an optional WITH TIME ZONE
qualifier.Literal values are represented by singlequoted strings preceded by the keyword
TIMESTAMP, with a blank space between data and time;
■Another data type related to DATE, TIME, and TIMESTAMP is the INTERVAL data type.
This specifies an interval—a relative value that can be used to increment or decrement an
absolute value of a date, time, or timestamp. Intervals are qualified to be either YEAR/MONTH
intervals or DAY/TIME intervals.
It is possible to specify the data type of each attribute directly,as in Figure 4.1;alternatively, a
domain can be declared, and the domain name used with the attribute specification. This makes it
easier to change the data type for a domain that is used by numerous attributes in a schema,and
improves schema readability.For example, we can create a domain SSN_TYPE by the following
statement:
We can use SSN_TYPE in place of CHAR(9) in the above create table for the attributes Ssn and
Super_ssn of EMPLOYEE, Mgr_ssn of DEPARTMENT, Essn of WORKS_ON, and Essn of
DEPENDENT.
Because SQL allows NULLs as attribute values,a constraint NOT NULLmay be specified if
NULLis not permitted for a particular attribute.This is always implicitly specified for the
attributes that are part of the primary key of each relation,but it can be specified for any other
attributes whose values are required not to be NULL.
It is also possible to define a default value for an attribute by appending the clause
DEFAULT<value> to an attribute definition.
Another type of constraint can restrict attribute or domain values using the CHECK clause
following an attribute or domain definition.
For example, suppose that department numbers are restricted to integer numbers between 1 and
20; then, we can change the attribute declaration of Dnumber in the DEPARTMENT table to the
following: Dnumber INT NOT NULL CHECK (Dnumber> 0 AND Dnumber< 21);
Ex:
CREATE TABLE EMPLOYEE ( Dno INT NOT NULL DEFAULT 1, CONSTRAINT EMPPK
PRIMARY KEY (Ssn), CONSTRAINT EMPDEPTFK FOREIGN KEY(Dno) REFERENCES
DEPARTMENT(Dnumber) ON DELETE SET DEFAULT ON UPDATE CASCADE);
CREATE DOMAIN D_NUM AS INTEGER CHECK (D_NUM > 0 AND D_NUM <21 );
We can then use the created domain D_NUM as the attribute type for all attributes that refer to
department numbers In create table , such as Dnumber of DEPARTMENT, Dnum of
PROJECT,Dno of EMPLOYEE,and so on.
The UNIQUE clause specifies alternate (secondary) keys, as illustrated in the DEPARTMENT
and PROJECT table declarations.
Referential integrity is specified via the FOREIGN KEY clause. A referential integrity constraint
can be violated when tuples are inserted or deleted, or when a foreign key or primary key
attribute value is modified. The default action that SQL takes for an integrity violation is to reject
the update operation that will cause a violation, which is known as the RESTRICT option.
However, the schema designer can specify an alternative action to be taken by attaching a
referential triggered action clause to any foreign key constraint. The options include SET NULL,
CASCADE, and SET DEFAULT. An option must be qualified with either ON DELETE or ON
UPDATE. We illustrate this with the examples shown in create table Here, the database
designer chooses ON DELETE SET NULL and ON UPDATE CASCADE for the foreign key
Super_ssn of EMPLOYEE. This means that if the tuple for a supervising employee is deleted,
the value of Super_ssnis automatically set to NULLfor all employee tuples that were referencing
the deleted employee tuple.On the other hand,if the Ssnvalue for a supervising employee is
updated (say,because it was entered incorrectly),the new value is cascaded to Super_ssn for all
employee tuples referencing the updated employee tuple.8
A constraint may be given a constraint name,following the keyword CONSTRAINT. The names
of all constraints within a particular schema must be unique. A constraint name is used to
identify a particular constraint in case the constraint must be dropped later and replaced with
another constraint. Giving names to constraints is optional.
SQL allows a table (relation) to have two or more tuples that are identical in all their attribute
values.Hence,in general, an SQL table is not a set of tuples, because a set does not allow two
identical members; rather,it is a multiset (sometimes called a bag) of tuples.
The basic form of the SELECT statement, sometimes called a mapping or a select-from-where
block, isformed of the three clauses SELECT, FROM, and WHERE and has the following form:
Query 1.
Ex:Retrieve the birth date and address of the employee(s) whose name is ‘John B.Smith’.
Query 1.a.
Retrieve the name and address of all employees who work for the ‘Research’department.
In the WHERE clause of query, the condition Dname = ‘Research’is a selection condition that
chooses the particular tuple of interest in the DEPARTMENT table,becauseDname is an attribute
of DEPARTMENT. The condition Dnumber = Dno is called a join condition, because it
combines two tuples: one from DEPARTMENT and one from EMPLOYEE, whenever the value
of Dnumber in DEPARTMENT is equal to the value of Dno in EMPLOYEE.
A query that involves only selection and join conditions plus projection attributes is known as a
select-project-join query. The next example is a select-project-join query with two join
conditions.
Query 2.
For every project located in ‘Stafford’, list the project number, the controlling department
number, and the department manager’s last name, address,and birth date.
The join condition Dnum = Dnumber relates a project tuple to its controlling department
tuple,whereas the join condition Mgr_ssn=Ssnrelates the controlling department tuple to the
employee tuple who manages that department.
In SQL,the same name can be used for two (or more) attributes as long as the attributes are in
different relations.If this is the case,and a multitable query refers to two or more attributes with
the same name, we must qualify the attribute name with the relation name to prevent ambiguity.
This is done by prefixing the relation name to the attribute name and separating the two by
a period.
We can also create an alias for each table name to avoid repeated typing of long table names.
For each employee, retrieve the employee’s first and last name and the first and last name of
his or her immediate supervisor.
It is also possible to rename the relation attributes within the query in SQL by giving them
aliases. For example,if we write EMPLOYEE AS E(Fn, Mi, Ln, Ssn, Bd, Addr, Sex, Sal, Sssn,
Dno) in the FROMclause,Fn becomes an alias for Fname,Mi for Minit,Ln for Lname,and so on.
In Query,we can think of E and S as two different copies of the EMPLOYEErelation;the first, E,
represents employees in the role of supervisees or subordinates; the second, S, represents
employees in the role of supervisors.
A missing WHERE clause indicates no condition on tuple selection; hence, all tuples of the
relation specified in the FROM clause qualify and are selected for the query result.If more than
one relation is specified in the FROM clause and there is no WHERE clause, then the CROSS
PRODUCT—all possible tuple combinations—of these relations is selected.
Select all EMPLOYEE Ssns (Q9) and all combinations of EMPLOYEE Ssn and
DEPARTMENT Dname (Q10) in the database.
It is extremely important to specify every selection and join condition in the WHERE clause; if
any such condition is overlooked, incorrect and very large relations may result.
SQL usually treats a table not as a set but rather as a multiset; duplicate tuples can appear more
than once in a table,and in the result of a query. SQL does not automatically eliminate duplicate
tuples in the results of queries.
If we do want to eliminate duplicate tuples from the result of an SQL query, we use the keyword
DISTINCT in the SELECT clause, meaning that only distinct tuples should remain in the result.
Query 11. Retrieve the salary of every employee (Q11) and all distinct salary values
(Q11A).
In general, a query with SELECT DISTINCT eliminates duplicates, whereas a query with
SELECT ALL does not.
SQL has directly incorporated some of the set operations from mathematical set theory,which are
also part of relational algebra (see Chapter 6).There are set union (UNION), set difference
(EXCEPT) and set intersection (INTERSECT) operations. The relations resulting from these
set operations are sets of tuples; that is, duplicate tuples are eliminated from the result. These set
operations apply only to union-compatible relations, so we must make sure that the two relations
on which we apply the operation have the same attributes and that the attributes appear in the
same order in both relations.The next example illustrates the use of UNION.
Query 4. Make a list of all project numbers for projects that involve an employee whose last
name is ‘Smith’, either as a worker or as a manager of the department that controls the project.
UNION
In this section we discuss several more features of SQL.The first feature allows comparison
conditions on only parts of a character string, using the LIKE comparison operator.This can be
used for string pattern matching. Partial strings are specified using two reserved characters: %
replaces an arbitrary number of zero or more characters,and the underscore (_) replaces a single
character.Forexample,consider the following query.
Query 12A.Find all employees who were born during the 1950s.
Another feature allows the use of arithmetic in queries. The standard arithmetic operators for
addition (+), subtraction (–), multiplication (*), and division (/) can be applied to numeric values
or attributes with numeric domains.
Query 13.Show the resulting salaries if every employee working on the ‘ProductX’project is
given a 10 percent raise.
Query 14.Retrieve all employees in department 5 whose salary is between $30,000 and
$40,000.
SELECT * FROM EMPLOYEE WHERE (Salary BETWEEN 30000 AND 40000) AND
Dno = 5;
The condition (Salary BETWEEN30000AND40000) in Q14is equivalent to the condition
SQL allows the user to order the tuples in the result of a query by the values of one or more of
the attributes that appear in the query result, by using the ORDER BY clause.
The default order is in ascending order of values.We can specify the keyword DESC if we want
to see the result in a descending order of values.The keyword ASCcan be used to specify
ascending order explicitly.
A simple retrieval query in SQL can consist of up to four clauses, but only the first two—
SELECT and FROM—are mandatory. The clauses are specified in the following order,with the
clauses between square brackets [ ... ] being optional:
The SELECTclause lists the attributes to be retrieved,and the FROMclause specifies all relations
(tables) needed in the simple query. The WHERE clause identifies the conditions for selecting
the tuples from these relations, including join conditions if needed.ORDERBYspecifiesan order
for displaying the results of a query.
In its simplest form,INSERTis used to add a single tuple to a relation.We must specify the
relation name and a list of values for the tuple.The values should be listed in the same order in
which the corresponding attributes were specified in the CREATE TABLE command.
A second form of the INSERT statement allows the user to specify explicit attribute names that
correspond to the values provided in the INSERTcommand.This is useful if a relation has many
attributes but only a few of those attributes are assigned values in the new tuple.
Attributes not specified in the above query are set to their DEFAULT or to NULL, and the
values are listed in the same order as the attributes are listed in the INSERTcommand itself.
A variation of the INSERT command inserts multiple tuples into a relation in conjunction with
creating the relation and loading it with the result of a query.
The DELETE command removes tuples from a relation.It includes a WHERE clause, similar to
that used in an SQL query, to select the tuples to be deleted. Tuples are explicitly deleted from
only one table at a time. However, the deletion may propagate to tuples in other relations if
referential triggered actions are specified in the referential integrity constraints of the DDL.
The above DELETE commands if applied independently to the database in Figure 3.6,will
delete zero,one,four,and all tuples,respectively,from the EMPLOYEErelation:
The UPDATE command is used to modify attribute values of one or more selected tuples. As in
the DELETE command, a WHERE clause in the UPDATE command selects the tuples to be
modified from a single relation. However, updating a primary key value may propagate to the
foreign key values of tuples in other relations if such a referential triggered action is specified in
the referential integrity constraints of the DDL. An additional SET clause in the UPDATE
command specifies the attributes to be modified and their new values.
For example, to change the location and controlling department number of project number
10 to ‘Bellaire’and 5,respectively,we use the below query
Several tuples can be modified with a single UPDATE command. An example is to give all
employees in the ‘Research’department a 10 percent raise in salary.
SQL has various techniques for specifying complex retrieval queries, including nested queries,
aggregate functions, grouping, joined tables,outerjoins,and recursive queries; SQL
views,triggers,and assertions; and commands for schema modification.
■ SQL has various techniques for writing programs in various programming languages that
include SQL statements to access one or more databases. These include embedded (and
dynamic) SQL, SQL/CLI (Call Level Interface) and its predecessor ODBC (Open Data Base
Connectivity), and SQL/PSM (Persistent Stored Modules).
■ Each commercial RDBMS will have,in addition to the SQL commands,a set of commands for
specifying physical database design parameters, file structures for relations, and access paths
such as indexes.
SQL has transaction control commands. These are used to specify units of database processing
for concurrency control and recovery purposes.
. ■ SQL has language constructs for specifying the granting and revoking of privileges to
users.Privileges typically correspond to the right to use certain SQL commands to access certain
relations. Each relation is assigned an owner, and either the owner or the DBA staff can grant to
selected users the privilege to use an SQL statement—such as SELECT, INSERT, DELETE, or
UPDATE—to access the relation.
In addition, the DBA staff can grant the privileges to create schemas, tables, or views to certain
users. These SQL commands—called GRANT and REVOKE—
■ SQL has language constructs for creating triggers. These are generally referred to as active
database techniques, since they specify actions that are automatically triggered by events such as
database updates.
■ SQL has incorporated many features from object-oriented models to have more powerful
capabilities,leading to enhanced relational systems known as object-relational.
■ SQL and relational databases can interact with new technologies such as XML