1. Modifying the Database
We have 3 kinds of modifications: insertion, deletion, update.
Insertion: general form --
INSERT INTO R(A1,…., An) VALUES (v1,…., vn)
Insert a new purchase to the database:
INSERT INTO Purchase(buyer, seller, product, store)
VALUES (‘Joe’, ‘Fred’, ‘wakeup-clock-espresso-machine’,
‘The Sharper Image’)
If we don’t provide all the attributes of R, they will be filled with NULL.
We can drop the attribute names if we’re providing all of them in order.

2. More Interesting Insertions
INSERT INTO PRODUCT(name)
SELECT DISTINCT product
FROM Purchase
WHERE product NOT IN
(SELECT name
FROM Product)
The query replaces the VALUES keyword.
Note the order of querying and inserting.

3. Deletions DELETE FROM PURCHASE WHERE seller = ‘Joe’ AND
product = ‘Brooklyn Bridge’
Factoid about SQL: there is no way to delete only a single
occurrence of a tuple that appears twice
in a relation.

4. Updates UPDATE PRODUCT SET price = price/2 WHERE Product.name IN
(SELECT product
FROM Purchase
WHERE Date =‘Oct, 25, 1999’);

5. Data Definition in SQL So far, SQL operations on the data.
Data definition: defining the schema.
Create tables
Delete tables
Modify table schema
But first:
Define data types.
Finally: define indexes.

6. Data Types in SQL Character strings (fixed of varying length)
Bit strings (fixed or varying length)
Integer (SHORTINT)
Floating point
Dates and times
Domains will be used in table declarations.
To reuse domains:
CREATE DOMAIN address AS VARCHAR(55)
You wish you had richer types, no? (hang on…)

7. Creating Tables CREATE TABLE Person( name VARCHAR(30),
social-security-number INTEGER,
age SHORTINT,
city VARCHAR(30),
gender BIT(1),
Birthdate DATE );

8. Deleting or Modifying a Table
Deleting: DROP Person;
Altering: (adding or removing an attribute).
ALTER TABLE Person
ADD phone CHAR(16);
ALTER TABLE Person
DROP age;
What happens when you make changes to the schema?

9. Default Values The default of defaults: NULL
Specifying default values:
CREATE TABLE Person(
name VARCHAR(30),
social-security-number INTEGER,
age SHORTINT DEFAULT 100,
city VARCHAR(30) DEFAULT ‘Seattle’,
gender CHAR(1) DEFAULT ‘?’,
Birthdate DATE

10. Indexes REALLY important to speed up query processing time.
Suppose we have a relation
Person (name, SSN, age, city)
An index on SSN enables us to fetch a tuple
for a given SSN very efficiently (not have to scan the whole relation).
The problem of deciding which indexes to put on the relations is
very hard! (it’s called: physical database design).

11. Creating Indexes CREATE INDEX ssnIndex ON Person(SSN)
Indexes can be created on more than one attribute:
CREATE INDEX doubleindex ON
Person (age, city)
Why not create indexes on all the attributes?

12. Defining Views (!!)
Views are relations, except that they are not physically stored.
They are used to:
simplify complex queries, and
define distinct conceptual interfaces for different classes
of users.
Example view: purchases of telephony products.
CREATE VIEW telephony-purchases AS
SELECT product, buyer, seller, store
FROM Purchase, Product
WHERE Purchase.product = Product.pname
AND Product.category = ‘telephony’
The view is materialized when its results are stored in the DBMS.

13. A Different View CREATE VIEW Seattle-view AS
SELECT buyer, seller, product, store
FROM Person, Purchase
WHERE Person.city = ‘Seattle’ AND
Person.per-name = Purchase.buyer
We can later use the views:
SELECT name, store
FROM Seattle-view, Product
WHERE Seattle-view.product = Product.name AND
Product.category = ‘shoes’
What’s really happening when we query a view?? It’s unfolded.

14. Updating Views
How can I insert a tuple into a table that doesn’t exist?
CREATE VIEW bon-purchase AS
SELECT store, seller, product (note: buyer is not selected)
FROM Purchase
WHERE store = ‘The Bon Marche’
If we make the following insertion:
INSERT INTO bon-purchase
VALUES (‘the Bon Marche’, ‘Joe’, ‘Denby Mug’)
We can simply add a tuple
(‘the Bon Marche’, ‘Joe’, NULL, ‘Denby Mug’)
to relation Purchase.

15. Non-Updatable Views CREATE VIEW Seattle-view AS
SELECT seller, product, store
FROM Person, Purchase
WHERE Person.city = ‘Seattle’ AND
Person.name = Purchase.buyer
How can we add the following tuple to the view?
(‘Joe’, ‘Shoe Model 12345’, ‘Nine West’)
In principle, two tuples should be added to the database:
Person: (foo, NullPhoneNumber, ‘Seattle’)
Purchase: (foo, ‘Joe’, ‘Nine West’, ‘Shoe Model 12345’)
But it’s very hard to manage the foo’s later, so this update is not legal.

16. Reusing a Materialized View
Suppose I have only the result of SeattleView:
SELECT buyer, seller, product, store
FROM Person, Purchase
WHERE Person.city = ‘Seattle’ AND
Person.per-name = Purchase.buyer
and I want to answer the query
SELECT buyer, seller
Person.per-name = Purchase.buyer AND
Purchase.product=‘gizmo’.
Then, I can rewrite the query using the view.

17. Query Rewriting Using Views
Rewritten query:
SELECT buyer, seller
FROM SeattleView
WHERE product= ‘gizmo’
Original query:
FROM Person, Purchase
WHERE Person.city = ‘Seattle’ AND
Person.per-name = Purchase.buyer AND
Purchase.product=‘gizmo’.

18. Another Example I still have only the result of SeattleView:
SELECT buyer, seller, product, store
FROM Person, Purchase
WHERE Person.city = ‘Seattle’ AND
Person.per-name = Purchase.buyer
but I want to answer the query
SELECT buyer, seller
Person.per-name = Purchase.buyer AND
Person.Phone LIKE ‘ %’.

19. The General Problem
Given a set of views V1,…,Vn, and a query Q, can we answer Q using only the answers to V1,…,Vn?
Why do we care?
We can answer queries more efficiently.
We can query data sources on the WWW in a principled manner.
Many, many papers on this problem.
The best performing algorithm: The MiniCon Algorithm, (Pottinger & Levy, 1999).

20. Querying the WWW Assume a virtual schema of the WWW, e.g.,
Course(number, university, title, prof, quarter)
Every data source on the web contains the answer to a view over the virtual schema:
UW database: SELECT number, title, prof
FROM Course
WHERE univ=‘UW’ AND quarter=‘4/99’
Stanford database: SELECT number, title, prof, quarter
WHERE univ=‘Stanford’
User query: find all professors who teach “database systems”

21. Datalog Another language for expressing queries: cleaner
closer to a “logic” notation, prolog
more convenient for analysis
can express queries that are not expressible in
relational algebra or SQL (recursion).

22. Predicates and Atoms - relations are represented by predicates
- tuples are represented by atoms.
Purchase( “joe”, “bob”, “Nike Town”, “Nike Air”, 2/2/98)
- arithmetic comparison atoms:
X < 100, X+Y+5 > Z/2
- negated atoms:
NOT Product(“Brooklyn Bridge”, $100, “Microsoft”)

23. Datalog Rules and Queries
A datalog rule has the following form:
head :- atom1, atom2, …., atom,…
ExpensiveProduct(X) :- Product(X,Y,P), P > $100
BritishProduct(X) :-
Product(X,Y,P), Company(P, “UK”, SP)
P(X,Y) :- Between(X,Y,Z), NOT Direct(X,Z)
A single rule can express exactly select-from-where queries.

24. The Meaning of Datalog Rules
ExpensiveProduct(X) :- Product(X,Y,P) & P > $100
Consider every assignment from the variables in the body
to the constants in the database.
If each of the atoms in the body is made true by the
assignment,
then
add the tuple for the head into the relation of the head.

25. Rule Safety
Every variable that appears anywhere in the query must appear
also in a relational, non-negated atom in the query.
Q(X,Y,Z) :- R1(X,Y) & X < Z not safe
Q(X,Y,Z) :- R1(X,Y) & NOT R2(X,Y,Z) not safe

26. Composing Datalog Rules
Extensional predicates: represent relations appearing in the database.
Intentional predicates: defined by rules. These can be thought of as
being views.
Datalog rules may be composed in order to express more complex
queries.
With composition:
it becomes easier to express certain queries (define views)
we can define queries including unions,
we can define recursive queries.

27. From Relational Algebra to Datalog
We can translate any relational algebra operation to datalog:
- projection
- selection
- union
- intersection
- join