data manipulation operations on views 1. 2 outline retrieval operations in theory in practice (sql92...
TRANSCRIPT
Data manipulation operations on views
1
Data manipulation operations on views
Data manipulation operations on views
2
Outline
retrieval operations in theory in practice (SQL92 and PostgreSQL)
update operations in theory - basics in practice
• SQL92• PostgreSQL
in theory - more advanced issues
Data manipulation operations on views
3
Example
suppose Student ( S_id, Name, Address, Programme, Tutor, …) Tutor ( T_id, Name, Address, …) Course ( C_id, Name, Length, …) C_Reg ( S_id, C_id, ... )
suppose all tutors need access to all course-lists, but are not allowed to see other information; this can be achieved via a view.
Data manipulation operations on views
4
View “Course-lists”
CREATE VIEW Course-lists (Student, Tutor, Course) AS
SELECT (Student.Name, Tutor.Name, Course.Name)
FROM Student, Tutor, Course, C_Reg
WHERE Tutor = T_id AND Course.C_id = C_Reg.C_id
AND Student.S_id = C_Reg.S_id ;
Data manipulation operations on views
5
Retrieving from “Course-lists”
-- all students that take “Database Systems”
SELECT Student FROM Course-lists
WHERE Course = ‘Database Systems’ ;
--Marian’s tutees and the courses they take
SELECT Student, Course FROM Course-lists
WHERE Tutor = ‘Marian’ ;
--etc.
Data manipulation operations on views
6
Retrieval operations
suppose• DB - is the set of base relations in a a database
• a view V can be considered as a function V = X(DB)
a retrieval operation R on the view is defined in terms of the materialisation of V as
• R(V) = R(X(DB)) /* X(DB) is a materialisation of V */
in practice is more efficient to use substitution• R(V) = (RX)(DB)
• in principle works perfectly (100%) well, but in practice, sometimes fails; e.g. “Restrictions on views [in SQL]” (Connolly, 1999, p. 446)
Data manipulation operations on views
7
Principle
a view should look like and behave exactly like a base relation
• satisfied, in theory, in case of retrieval operations• in practice, even in case of retrieval operations, it is
sometimes violated; e.g. in SQL92 (Connolly, 1999, p.446):– columns based on aggregate functions cannot be used in a
WHERE clause or as an argument of an aggregate function
– a grouped view cannot be joined with a base table
Data manipulation operations on views
8
Updating “Course-lists”
--insert the fact that “Bob Marley”, who’s personal tutor is
--“Marian Ursu”, has registered for “Database Systems”
INSERT INTO Course-lists
VALUES (“Bob Marley”, “Marian Ursu”, “Database Systems”);
will this work? why? “Course-lists” is a virtual relation; the base tables have to
be updated instead; how should this be done?
Data manipulation operations on views
9
Updating a view
suppose V is a view of the database DB, written as V = X(DB); then UPDATE(V) means UPDATE(X(DB)) however, X(DB) does not exist in reality therefore it is not updateable therefore, UPDATE1 must be found, such that UPDATE(X(DB)) = X(UPDATE1(DB))
view updating is governed by sets of rules for determining UPDATE1 given X and UPDATE
such sets of rules must satisfy some general (updating) principles
Data manipulation operations on views
10
Main updating principle
a given tuple can appear in a given relation only if that tuple satisfies the relation predicate for that relation; this is true both for base relations and views
Data manipulation operations on views
11
Predicate - the meaning of a relation
suppose the relation • Student(Id, Name, Address, Course, Tutor)
• its meaning is: the student with the identifier Id having the name Name lives at the Address address, takes the Course course and has the Tutor tutor
• this is formally expressed by the predicate of the relation
predicate = truth valued function, true for all the tuples that should be in the relation and false for the rest
• student(5334,’Scott Sherman’,’USA’,’CIS’,’Rob Hierons’) - true
• student(-21,’Mick Jagger’,’Richmond’,’Rock’,’Duda’) - false
Data manipulation operations on views
12
DBMSs and relation predicates
the DBMS does not (cannot) know, a priori, exactly, the predicate for a given relation
however, it knows the set of all integrity constraints / rules
therefore the meaning of a relation = the logical AND of all
integrity constraints / rules that apply to that relation
Data manipulation operations on views
13
Meaning of a relation - example
CREATE TABLE Suppliers
(S_id Id_number NOT NULL,
S_name Name,
S_status Status,
S_city City,
PRIMARY KEY (S_id),
UNIQUE (S_name),
CHECK (Status > 0 AND Status < 101) );
Data manipulation operations on views
14
Main updating principle
the predicate for a relation constitutes the criterion for update acceptability; remember: a given tuple can appear in a given relation only if
that tuple satisfies the relation predicate for that relation; this is true both for base relations and views
this is the main principle; other principles may exist as well
Data manipulation operations on views
15
Updating principles
view update is a semantic (not syntactic) issue; i.e. should not depend upon the form in which the view is stated; create view V as select S_name, City from Suppliers where Status > 25 or City = ‘Paris’ create view V as (select S_name, City from Suppliers where Status > 25 ) union (select S_name, City from Suppliers where City = ‘Paris’) both or neither should be updateable; however, in SQL the first is
updateable but the second not;
Data manipulation operations on views
16
Updating principles
the view updating mechanism must work correctly when the view is a base relation
the updating rules must preserve symmetry where applicable
updates on views must be implemented by the same kind of updates on the underlying relations (e.g. DELETE by means of DELETES)
the rules cannot assume that the database is well designed
etc. (Date, 1995, p.473)
Data manipulation operations on views
17
Updating rules
comply with the general principles given for simple relational expressions
(A <relational operator> B) for complex expressions - recursive application
convention• the SQL syntax is going to be used for defining the views
in the following examples; however, note that THE RULES ARE GENERIC; THEY ARE NOT SQL RULES
Data manipulation operations on views
18
Rules for updating set operators views
updating views defined by expressions as• A UNION B• A INTERSECT B• A MINUS B• where A and B are relational expressions
in detail: INSERT into a UNION
Data manipulation operations on views
19
Updating UNION views - INSERT
the new tuple must satisfy at least PA or PB; the new tuple must not already exist in either A or B; if it satisfies PA, it is inserted into A (providing it wasn’t already inserted as a result of inserting it into B); if it satisfies PB, it is inserted into B (providing it wasn’t already inserted as a result of inserting it into A);
• no temporal order exist between the two attempted insertions
Data manipulation operations on views
20
Example #1
Suppliers1(S_id, S_name, Status, City) constraint: City IN (‘London’, ‘Paris’, ‘Madrid’, ‘Rome’, ‘Berlin’)
Suppliers2(S_id, S_name, Status, City) constraint: City IN (‘London’, ‘New York, ‘Washington’, ‘Boston’)
CREATE VIEW Test1 AS Suppliers1 UNION Suppliers2
Data manipulation operations on views
21
Example #1
INSERT INTO Test1 VALUES (S6, Smith, 50, London); satisfies City IN ... therefore it is
inserted into the first relation Suppliers1if it was not already there
satisfies City IN ... therefore it is inserted into the second relation Suppliers2 if it was not already there
INSERT INTO Test1 VALUES (S7, Jones, 40, Paris); satisfies City IN ... therefore it is
inserted into the first relation Suppliers1 if it was not already there
does not satisfy City IN ... therefore it is not inserted into the second relationSuppliers2
Data manipulation operations on views
22
Example #2
Suppliers(Id, Name, Address, …, Status, …) CREATE VIEW Test2 AS (SELECT * FROM Suppliers WHERE Status > 25) UNION (SELECT * FROM Suppliers WHERE City = ‘Paris’)
S_id S_name Status City
S2 Jones 10 Paris
S3 Blake 30 Paris
S5 Adams 30 Athens
Data manipulation operations on views
23
Example #2
INSERT INTO Test2 VALUES (S6, Smith, 50, London); satisfies Status > 25 therefore it is
inserted into the first relation (Suppliers WHERE Status > 25) if it isn’t already there
does not satisfy City = ‘Paris’ therefore it is not inserted into the second relation(Suppliers WHERE City = ‘Paris’)
as a final result, the tuple is inserted once in Suppliers
INSERT INTO Test2 VALUES (S7, Jones, 40, Paris); satisfies Status > 25 therefore it is
inserted into the first relation (Suppliers WHERE Status > 25)if it isn’t already there
satisfies City = ‘Paris’ therefore it is inserted into the second relation(Suppliers WHERE City = ‘Paris’) if it isn’t already there
however, only one insertion is performed on Suppliers, since both expressions refer to the same base relation (Suppliers)
Data manipulation operations on views
24
Example #3
a similar view definition, but this time over two base relations: DEFINE VIEW Test 3 AS Sstat UNION Scity
S_id S_name Status CityS3 Blake 30 ParisS5 Adams 30 Athens
S_id S_name Status CityS2 Jones 10 ParisS3 Blake 30 Paris
Sstat
Scity
Constraint: Status > 25
Constraint: City = Paris
Data manipulation operations on views
25
Example #3
INSERT INTO Test3 VALUES (S6, Smith, 50, London) will be inserted into Sstat (satisfies
the predicate) will not be inserted into Scity (does
not satisfy the predicate) intuitively “correct” behaviour
INSERT INTO Test3 VALUES (S7, Jones, 40, Paris) will be inserted into Sstat (satisfies the
predicate) will also be inserted into Scity (satisfies
the predicate) intuitively “incorrect” - a certain kind of
information has to be kept in only one place (relation)
this is an example of a surprising result; the cause is the bad design of the database (the two predicates are not mutually exclusive)
Data manipulation operations on views
26
Updating views - in practice
in practice, the rules for updating views are simpler
• to simplify the DBMS
defined in an ad-hoc manner• i.e. they do not necessarily comply with the generic
principles previously stated
Data manipulation operations on views
27
SQL2 rules for updating views
the FROM clause of the SELECT statement of the defining query contains exactly one table reference (the view is defined on exactly one table), i.e. the view definition does not contain JOIN, UNION, INTERSECT or EXCEPT
every element in the SELECT statement of the defining query is a column name (rather than a calculated field, aggregate function, …)
the SELECT clause defining the view does not contain the word DISTINCT
the defining query does not include a GROUP BY clause etc … (refer to Date, 1995, p. 490 or Connolly, 1999, p.449)
Data manipulation operations on views
28
PostgreSQL rules for updating views
views in Postgres are not updateable (yet)
Data manipulation operations on views
29
Conclusions
view - named virtual relation, behaving similarly with a base relation
logical data independence (restructuring) security and macro-capability retrieval operations - substitution - in principle works fine in
any case; in practice is does not always work fine update principles - i theory update rules specific to relational algebra operators - in theory update rules specific to certain implementations - in practice
Data manipulation operations on views
30
Extra reading
Data manipulation operations on views
31
Updating UNION views - UPDATE
the updated version must satisfy PA or PB; if the tuple appears in A it is deleted from A without performing any triggered action and without checking the relation predicate; similarly for B; if the updated version of the tuple satisfies PA then it is inserted into A (provided it wasn’t already inserted, as a result of inserting it into B); similarly for B.
Data manipulation operations on views
32
Activities
deduce (study) rules for updating UNION views - DELETE INTESECT views DIFFERENCE views
Data manipulation operations on views
33
Updating pure relational operators views
updating views defined by• a RESTRICTION• a PROJECTION• a JOIN
in detail: • INSERT into a PROJECTION• INSERT into a many-to-many JOIN
Data manipulation operations on views
34
INSERT into a PROJECTION
X is the set of attributes of the projection Y is the remaining set of attributes let the tuple to be inserted be (x); let the default value for Y be
(y); if a default value does not exist the insertion cannot be performed; if the tuple (x, y) satisfies PA (where A is the original relation) then it is inserted into A corollary: if the projection (view) does not include all candidate
keys, the underlying relation will not permit insert via the view
Data manipulation operations on views
35
Example
DEFINE VIEW Test AS SELECT S_id, S_name, City FROM Suppliers -- the default value for Status is 50
S_id S_name CityS1 Smith LondonS2 Jones ParisS3 Blake ParisS4 Cark LondonS5 Adams Athens
INSERT INTO TestVALUES (S6, Marian, Cluj); succeeds
INSERT INTO TestVALUES (S1, Marian, Cluj); fails; why?
Data manipulation operations on views
36
INSERT into A JOIN B
the new tuple j = (a, b) must satisfy PJ (i.e. PA (a) AND PB (b)); if the A portion of j (i.e. a) does not appear in A, it is inserted into A; if the B portion of j (i.e. b) does not appear in B, it is inserted into B.
Data manipulation operations on views
37
Example
DEFINE VIEW Test AS <Rel1 JOIN Rel2 OVER City>
S_id S_name CityS1 Smith LondonS2 Jones ParisS3 Blake ParisS4 Clark London
P_id P_name CityP1 Nut LondonP2 Screw LondonP3 Bolt ParisP4 Cam London
Data manipulation operations on views
38
The view
S_id S_name City P_id P_nameS1 Smith London P1 NutS1 Smith London P2 ScrewS1 Smith London P4 CamS2 Jones Paris P3 BoltS2 Blake Paris P3 BoltS4 Clark London P1 NutS4 Clark London P2 ScrewS4 Clark London P4 Cam
INSERT INTO Test VALUES (S6, Green, London, P5, Cog);
Data manipulation operations on views
39
Question
how many tuples will be added to the view?