sql ddl statements are used to create and manipulate the ...1 sql - ddl • sql ddl statements are...
TRANSCRIPT
1
SQL - DDL
• SQL DDL statements are used to create and manipulate the schema definitions
of base tables, view tables, domains, assertions (integrity constraints),
privileges and so on.
• The statements include:
CREATE TABLE
ALTER TABLE
DROP TABLE
CREATE VIEW
DROP VIEW
GRANT
REVOKE
• Relational DBMS products vary even more widely in the DDL features
supported than DML features.
2
BASE TABLES
• A base table is a named table which exists in its own right. We can think of a
base table as being supported by actual stored rows in database files.
• The CREATE TABLE statement is used to define a new base table:
CREATE TABLE SUPPLIER
(SNUM VARCHAR(5) NOT NULL,
SNAME VARCHAR(20) NOT NULL,
STATUS NUMERIC(5) DEFAULT 20 NOT NULL,
CITY VARCHAR(15) DEFAULT 'LONDON' NOT NULL,
CONSTRAINT PK_SUPPLIER PRIMARY KEY (SNUM),
CONSTRAINT UNQ_SNAME UNIQUE (SNAME),
CONSTRAINT CHECK_STATUS CHECK (STATUS > 0))
• The table has 4 columns - SNUM, SNAME, STATUS and CITY. Each column has
a data type defined for it, and constraints are being defined to further limit the
acceptable values which may be stored in the table.
3
• In the definition of the SUPPLIER table, a data type (either VARCHAR or
NUMERIC) has been defined for each column. Some examples of SQL data
types are:
CHAR(n) Fixed length string of exactly n characters.
VARCHAR(n) Variable length string of up to n characters.
NUMERIC(p,s) Decimal number with p digits (precision) and decimal
point s digits (scale) from the right. The number may be
signed.NUMERIC(p) An abbreviation for NUMERIC(p,0).
NUMERIC An abbreviation for NUMERIC(p) where p is
implementation defined.
• Other data types for strings and numbers exist, for example for bit strings and
floating point numbers, as well as other data types, for example for dates and
times.
• When defining a column, it is possible to specify a default value. The default value will be used if an INSERT statement does not specify an explicit value for
the column in a new row.
4
INTEGRITY CONSTRAINTS
• In addition to data types, SQL supports integrity constraints including NOT NULL
column constraints, CHECK constraints, and primary, alternate and foreign key
definitions.
NOT NULL
• Any column of a base table may be specified as NOT NULL, indicating that it is
not possible for a null value to be stored in any row for the column in question.
CHECK
• A check constraint is of the form: CHECK ( conditional-expression )
e.g.
CONSTRAINT CHECK_STATUS CHECK (STATUS > 0)
• A change to a row in a table (INSERT, UPDATE, DELETE) violates the constraint
and is prevented if the conditional expression evaluates to "false" by reference
to any row in the table: the constraint is not violated if the conditional expression
evaluates to "true" or "unknown".
5
Another example CHECK constraint follows. This constraint on the SUPPLY table
would ensure that the quantity of any supply instance by a London supplier did not
exceed 2000.
CONSTRAINT CHECK_LONDON_S_QUANTITY
CHECK (SUPPLY.QUANTITY <= 2000]
OR NOT EXISTS
(SELECT *
FROM SUPPLIER
WHERE SUPPLIER.CITY = 'LONDON'
AND SUPPLIER.SNUM = SUPPLY.SNUM))
6
• If a CHECK, PRIMARY KEY or UNIQUE constraint only involves a single column it
may be defined as part of the column definition. Hence, table SUPPLIER could
have been defined as:
CREATE TABLE SUPPLIER
(SNUM VARCHAR(5) NOT NULL PRIMARY KEY,
SNAME VARCHAR(20) NOT NULL UNIQUE,
STATUS NUMERIC(5) DEFAULT 20 NOT NULL
CHECK (STATUS > 0),
CITY VARCHAR(15) DEFAULT 'LONDON' NOT NULL)
• Oracle supports a restricted form of CHECK constraint in which the conditional
expression may only refer to columns in the table whose definition the
constraint appears in, and the conditional expression must be evaluable for
each row in the table individually.
7
CANDIDATE KEYS
• Candidate keys for a base table may be specified with either a PRIMARY KEY
or UNIQUE clause.
• A candidate key constraint is satisfied if and only if no two rows in the table
have the same non-null values in the candidate key columns.
• For a given base table at most one candidate key may be specified as a primary
key.
• A primary key may consist of a list of columns. Primary key column(s) are implicitly NOT NULL even if explicit NOT NULL constraints are omitted.
• Alternate keys for a table are specified with UNIQUE. Again, the key may be
formed by multiple columns.
• Unlike PRIMARY KEY columns, alternate key columns are not necessarily NOT
NULL.
8
FOREIGN KEYS
• SQL supports the idea of a foreign key, namely a column or columns in one
"referencing" table which must match the values of a key in a second (not
necessarily distinct) "referenced" table.
• SQL allows the referenced key to be an alternate key instead of a primary key
(unlike many definitions of the relational model). e.g.
CREATE TABLE SUPPLY
(SNUM VARCHAR(5) NOT NULL,
PNUM VARCHAR(6) NOT NULL,
JNUM VARCHAR(4) NOT NULL,
QUANTITY NUMERIC(9),
PRIMARY KEY (SNUM, PNUM, JNUM),
FOREIGN KEY (SNUM) REFERENCES SUPPLIER
ON DELETE CASCADE ON UPDATE CASCADE,
FOREIGN KEY (PNUM) REFERENCES PART
ON DELETE CASCADE ON UPDATE CASCADE,
FOREIGN KEY (JNUM) REFERENCES PROJECT
ON DELETE CASCADE ON UPDATE CASCADE)
9
• Three foreign keys have been defined. In this particular case the foreign keys
are part of the referencing table’s own primary key, but that is not necessary.
• Neither is it necessary for foreign keys to be NOT NULL (unless of course they
do form part of the table’s own primary key).
• Each foreign key specifies the existing "referenced“ table holding the key which
the foreign key values must match.
• If a table without specific columns is referenced, that table must have a matching PRIMARY KEY definition for the column(s).
• If a reference is made to particular columns in a table, as for example in
FOREIGN KEY (SNAME) REFERENCES SUPPLIER (SNAME)
the referenced table could have a matching alternate key UNIQUE definition
rather than a PRIMARY KEY definition.
10
• If an INSERT or UPDATE of a row in the referencing table would cause a
foreign key constraint to be violated, the INSERT or UPDATE is rejected.
• A DELETE or UPDATE on a referenced table may also cause a foreign key
constraint to be violated. The default action is that the DELETE or UPDATE will
be rejected.
• However, use of the optional ON DELETE or ON UPDATE clauses enable other
actions to be specified. In the example, deletes and updates on the referenced
table are “cascaded” to the referencing table to ensure the constraints are not
violated.
• The cascaded updates and deletes may themselves result in further cascaded
updates and deletes if the referencing table is itself referenced by foreign key
definitions.
• Oracle provides support for foreign keys as described except its support for ON
DELETE and ON UPDATE is limited to an optional ON DELETE CASCADE or ON
DELETE SET NULL clause.
11
DEFERRED CONSTRAINT CHECKING
• By default, integrity constraints are checked after each SQL statement is
executed, and if there is a constraint violation the statement fails.
• However, the example of two base tables each with a foreign key referencing
the other shows that this can cause problems.
• Deferred constraint checking enables each constraint to be in the default IMMEDIATE mode, or DEFERRED mode in which case constraint checking is
deferred until a later point in the transaction.
• When a constraint is defined it is possible to specify whether or not checking of
the constraint may be deferred, and the initial mode which will be used for
• checking in each new transaction. For example:
CONSTRAINT FK1 ... INITIALLY DEFERRED
CONSTRAINT FK2 ... INITIALLY IMMEDIATE DEFERRABLE
CONSTRAINT FK3 ... INITIALLY IMMEDIATE NOT DEFERRABLE
-- the last is the default
12
• In order to switch modes during a transaction, the SET CONSTRAINTS
statement is used, as in:
SET CONSTRAINTS FK2 DEFERRED
SET CONSTRAINTS FK1, FK2 IMMEDIATE
SET CONSTRAINTS ALL IMMEDIATE
-- ALL is shorthand for all deferrable constraints
• If a constraint is switched to IMMEDIATE mode during a transaction, it is
checked at that point. If there is a constraint violation then the SET
CONSTRAINTS statement fails and checking of the constraint will remain in
DEFERRED mode.
• If a transaction executes a COMMIT with any constraints still in DEFERRED
mode, then they are checked at that point and the transaction fails and rolls
back if there is any constraint violation.
• Oracle provides support for deferred constraint checking as described.
13
ALTER TABLE and DROP TABLE
• An existing base table may be altered in a number of ways through use of
ALTER TABLE:
• A new column may be added to a table.
• The default definition of an existing column may be modified.
• An existing column may be removed.
• An integrity constraint may be added or removed.
• An existing base table may be removed with DROP TABLE.
14
VIEWS
• Views are tables derived from one or more other tables (base tables or views) by the evaluation of a SELECT query expression. They can be thought of as
providing an "external level" definition of table structures corresponding to the
"conceptual level" definition of base tables.
• Views provide:
• logical data independence
• a security mechanism
• a simplified application view of the content of a database.
• A view’s defining query expression is usually stored (in the data
dictionary/catalog) and the view table rows are formed as a matter of query evaluation when required.
15
• View definitions are created with CREATE VIEW and removed with DROP VIEW.
e.g.
CREATE VIEW RED_PARTS (PNUM, PNAME, WEIGHT, CITY) AS
SELECT P#, PNAME, WEIGHT, CITY
FROM PART
WHERE COLOUR = 'RED'
• Having created a view, it may be the subject of data manipulation statements as
if it were a "real" base table:
SELECT *
FROM RED_PARTS
PNUM PNAME WEIGHT CITY
------ ----------- ------- ---------
P1 NUT 12 LONDON
P4 SCREW 14 LONDON
P6 COG 19 LONDON
16
• To execute a query on the view, the DBMS can usually merge the query with the
view definition to produce an equivalent modified query. So
SELECT *
FROM RED_PARTS
WHERE WEIGHT > 13
can be translated by the DBMS to a query on "real" base tables:
SELECT P#, PNAME, WEIGHT, CITY
FROM PART
WHERE COLOUR = 'RED'
AND WEIGHT > 13
• Alternatively a DBMS may separately temporarily "materialize" i.e. construct the view table and then query it.
17
• Updates on views may cause difficulty. Given an INSERT, DELETE or UPDATE
on a view, there may be no way or multiple ways the base tables can be
modified to reflect the updated view. e.g.
CREATE VIEW LOCAL_PART AS
SELECT PNAME, JNAME
FROM PART, PROJECT
WHERE PART.CITY = PROJECT.CITY
SELECT *
FROM LOCAL_PART
PNAME JNAME
-------------------- ----------
NUT RAID
NUT TAPE
BOLT SORTER
SCREW DISPLAY
SCREW RAID
SCREW TAPE
CAM SORTER
COG RAID
COG TAPE
18
• Bearing in mind only one "RAID" row exists in PROJECT whereas three "RAID"
rows exist in LOCAL_PART, what should the effect of the following update
statement be?
UPDATE LOCAL_PART
SET JNAME = 'WIRE'
WHERE JNAME = 'RAID'
AND PNAME = 'NUT'
• The definition of SQL specifies that a view table is updatable if and only if
certain conditions hold for the defining query expression. These conditions are
rather complex under later SQL standards - the rather simpler conditions under
SQL-92 include:• The top-level SELECT expression does not specify DISTINCT.
• The top-level SELECT list consists of column references rather than
aggregate functions or other general expressions.• The top-level FROM clause only refers to one table, which is itself a base
table or updatable view.• The top-level SELECT expression does not include a GROUP BY or HAVING
clause.• and others...
19
• One integrity constraint exists specifically for use with views - the CHECK
OPTION.
• Consider the following (updatable) view definition and sequence of DML
statements.
CREATE VIEW HEAVY_PART AS
SELECT P#, PNAME, COLOUR, WEIGHT, CITY
FROM PART
WHERE WEIGHT > 15
SELECT *
FROM HEAVY_PART
P# PNAME COLOUR WEIGHT CITY
------ --------- ------ ---------- --------
P2 BOLT GREEN 17 PARIS
P3 SCREW BLUE 17 ROME
P6 COG RED 19 LONDON
UPDATE HEAVY_PART
SET WEIGHT = 14
WHERE P# = 'P2'
20
SELECT *
FROM HEAVY_PART
P# PNAME COLOUR WEIGHT CITY
------ --------- ------ ---------- ---------
P3 SCREW BLUE 17 ROME
P6 COG RED 19 LONDON
• The effect of the update is that a row has disappeared from HEAVY_PART since
the updated row no longer figures in the result of the query defining the view.
• To prevent a row inserted or updated in a view from disappearing in this way, the view may be defined WITH CHECK OPTION as in:
CREATE VIEW HEAVY_PART AS
SELECT P#, PNAME, COLOUR, WEIGHT, CITY
FROM PART
WHERE WEIGHT > 15
WITH CHECK OPTION
• With the check option in force, a view insertion or update is rejected if the modified rows would not then satisfy the view definition.
21
PRIVILEGES
• The person who creates and so "owns" an object (base table, view...) has a
series of privileges enabling him or her to then use the object. Privileges include SELECT, DELETE, INSERT and UPDATE to manipulate a specific owned table
in the obvious ways.
• The owner of an object may then use the GRANT statement to grant specific
privileges on an object to other users.
e.g.
GRANT SELECT, INSERT ON TABLE PART TO TOM, ANNE
authorizes users TOM and ANNE to execute SELECT and INSERT
statements on the PART table.
• Privileges may be withdrawn using the REVOKE statement, as in:
REVOKE SELECT ON TABLE PART FROM TOM
22
• Normally a granted privilege on an object may not be itself granted by the
recipient to a further user. However, if the grantor wishes the recipient of a
privilege to be able to grant that privilege to others, it can be done with use of WITH GRANT OPTION.
e.g.GRANT UPDATE ON TABLE SUPPLY TO TOM
WITH GRANT OPTION
• Use of roles can often simplify administration of privileges. Rather than granting
each privilege separately to each user, a suitable role could be created e.g. a "developer" role - CREATE ROLE DEVELOPER - and the privileges granted to
the role:
GRANT SELECT, DELETE, INSERT, UPDATE ON TABLE SUPPLIER
TO DEVELOPER
• That role could then be granted to each user who is a developer so each has
the privileges associated with the role:
GRANT DEVELOPER TO TOM, ANNE, MARY, BILL