SQL and Table
Constraints
CMSC 461
Michael Wilson
A few more basic commands
All
we’ve gone over so far, there’s two
more commands I’d like to elaborate on
Delete statement
To
get rid of existing rows in a table, use a
delete statement
DELETE FROM <table>
WHERE <where-clause>
Delete statement
DELETE
FROM AddressBook
Where phoneType = ‘Cell’;
Alter table
Say
you’ve discovered an issue in the
schema you’ve provided to your
database
How do you correct that?
Altering the table
There are several variants on this
Alter table
Basic
syntax:
ALTER TABLE <table>
<action>
<action> can be:
RENAME
<column> to <new_column>
RENAME to <new_table_name>
ADD <column> <data_type>
DROP <column> <data_type>
ALTER <column> TYPE <data_type>
Alter table
Alter
table can do much more than this
These are kind of the more frequently
applicable actions
Going to leave the example part of this as
an exercise for you
It’s
infrequently used and there are a lot of
nuances to it that make it difficult to show a
concrete example for
Table constraints
When
designing your tables, you should
often think about exactly how the data
should fall together
Putting together a database schema
should not be a quick step
SQL
and DBMSes have built in methods for
enforcing interrelated tables
Keys!
Remember
our talk of keys from before?
Extremely important when designing tables
In
general, most tables will have primary
keys
If you’re designing a table that doesn’t
have one, you should question whether or
not the table is designed properly
Primary key constraints
Your
table creation scripts should always
contain a primary key constraint
This requires a slight modification to our
create table statement
Let’s look at our AddressBook table
Primary key constraints
CREATE
TABLE AddressBook
(address varchar(256),
daysSinceContact integer,
contactPhoneNumber varchar(64),
numberType varchar(16),
contactName varchar(256));
Primary key constraints
Let’s
add an identifier to this that will be
our primary key
Primary key constraints
CREATE
TABLE AddressBook
(id integer PRIMARY KEY,
address varchar(256),
daysSinceContact integer,
contactPhoneNumber varchar(64),
numberType varchar(16),
contactName varchar(256));
Primary key constraints
id
address
lastContacted
contactPhoneNum
ber
numberType
contactName
1
111 Great
Street
1 day
ago
555
5555
Cell
Phil
2
123 Not So
Great
Street
Last
month
555
6666
Landline Henry
3
8 Get Out
of Here
Way
Last
week
555
7777
Work
Bob
4
7 RUN!
Drive
2 years
ago
555
8888
Cell
Octavio
Primary key constraints
Primary
If you try to insert an entry with a duplicate
primary key, it will give you an error
This is good – it enforces your DB schema for
you
Also,
keys must be unique
primary keys must be present
Cannot be NULL, which we’ll get into later
Primary key note
The
“id” method is pretty frequently used
in DB design
Easy way to have a key that you can
reference by a single number
Compound keys
Compound
keys are keys that consist of
multiple columns
Sometimes it requires several attributes to
identify an item
Compound keys
dogName
dogDOB
favoriteToy
Fido
2/20/2004
Chew toy
Benjamin
6/01/2007
Ball
Cujo
5/07/2008
Squeaky toy
Compound keys
CREATE
TABLE FavoriteDogToys
(dogName varchar(128),
dogDOB date,
favoriteToy varchar(256),
PRIMARY KEY (dogName, dogDOB));
Foreign keys
When
you have interrelated tables, often
times you’ll have a table that depends on
the primary key of another table
Very akin to the weak entities we saw in ER
Diagramming
Let’s take our previous AddressBook
example and imagine a new table, Calls
Foreign keys
addressBookId
callTime
callLength
1
2/4/13
0:20:00
1
5/2/12
1:23:00
4
12/12/13
0:05:00
3
07/7/12
0:02:00
4
07/8/12
0:59:00
Foreign keys
CREATE TABLE Calls (
addressBookId REFERENCES AddressBook,
callTime timestamp,
callLength interval
);
What is the primary key in this table?
Foreign keys
CREATE TABLE Calls (
addressBookId REFERENCES AddressBook,
callTime timestamp,
callLength interval,
PRIMARY KEY(addressBookId, callTime)
);
Foreign keys
We
are unable to create any entries in
the Calls table without there being a
corresponding addressBookId in the
AddressBook table
PostgreSQL will give us an error if we
attempt to do so
What to do about foreign keys
and deletes?
Say
we’ve got a situation where
somebody wants to delete a row that
we’re referencing
What behavior do we want to exhibit?
We can use ON DELETE to specify
ON DELETE
ON DELETE takes an action modifier
NO ACTION (by default)
RESTRICT
If a referenced row is deleted, this row is removed as well
SET NULL
Prevents the deletion of a referenced row
CASCADE
If somebody attempts to delete something that we’re
referencing, we do nothing and throw an error
If a referenced row is deleted, the value in this row is set
to NULL
SET DEFAULT
If a referenced row is deleted, the value in this row is set
to the DEFAULT value for that row
ON DELETE RESTRICT
CREATE TABLE Calls (
addressBookId REFERENCES AddressBook ON
DELETE RESTRICT,
callTime timestamp,
callLength interval
);
If we attempt to delete an entry from
AddressBook, what happens?
ON DELETE CASCADE
CREATE
TABLE Calls (
addressBookId REFERENCES
AddressBook ON DELETE CASCADE,
callTime timestamp,
callLength interval
);
If we attempt to delete an entry from
AddressBook, what happens?
Why?
Why
not just handle all this stuff in code?
Foreign keys, etc. don’t necessarily add
functionality
We could handle ON DELETES in code
Referential integrity
Referential
integrity is essentially ensuring
that relationships between tables remain
consistent
By declaring things as foreign keys, explicitly
stating ON DELETEs, you ensure that it’s
impossible to enter an inconsistent state
Impossible to have a foreign key reference
that no longer exists
Your
data is more predictable and
reliable
0
