XML Querying and Views

Helena GalhardasDEI IST

(slides baseados na disciplina CIS 550 – Database & Information Systems, Univ. Pennsylvania, Zachary Ives)

Agenda

Recalling XML Querying Views

3

XQuery’s Basic Form Has an analogous form to SQL’s

SELECT..FROM..WHERE..GROUP BY..ORDER BY The model: bind nodes (or node sets) to variables;

operate over each legal combination of bindings; produce a set of nodes

“FLWOR” statement [note case sensitivity!]:for {iterators that bind variables}

let {collections}

where {conditions}

order by {order-conditions} (older version was “SORTBY”)

return {output constructor}

4

“Iterations” in XQueryA series of (possibly nested) FOR statements assigning the results

of XPaths to variables

for $root in document(“http://my.org/my.xml”)for $sub in $root/rootElement,

$sub2 in $sub/subElement, …

Something like a template that pattern-matches, produces a “binding tuple”

For each of these, we evaluate the WHERE and possibly output the RETURN template

document() or doc() function specifies an input file as a URI Old version was “document”; now “doc” but it depends on your

XQuery implementation

5

Example XML DataRoot

?xml dblp

mastersthesis article

mdate key

author title year school editor title yearjournal volume eeee

mdatekey

2002…

ms/Brown92

Kurt P….

PRPL…

1992

Univ….

2002…

tr/dec/…

Paul R.

The…

Digital…

SRC…

1997

db/labs/dec

http://www.

attributeroot

p-i element

text

6

Two XQuery Examples<root-tag> {

for $p in document(“dblp.xml”)/dblp/proceedings, $yr in $p/yrwhere $yr = “1999”return <proc> {$p} </proc>

} </root-tag>

for $i in document(“dblp.xml”)/dblp/inproceedings[author/text() = “John Smith”]

return <smith-paper><title>{ $i/title/text() }</title><key>{ $i/@key }</key>{ $i/crossref }

</smith-paper>

7

Another ExampleRoot

?xml universities

name

Univ….

attributeroot

p-i element

text

university

country

USA

mastersthesis

key

author title year

ms/Brown92

Kurt P….

PRPL…

1999

…

…

school

Univ….

8

What If Order Doesn’t Matter?By default:

SQL is unordered XQuery is ordered everywhere! But unordered queries are much faster to answer

XQuery has a way of telling the query engine to avoid preserving order: unordered {

for $x in (mypath) …}

9

Querying & Defining Metadata – Can’t Do This in SQLCan get a node’s name by querying node-name():

for $x in document(“dblp.xml”)/dblp/*

return node-name($x)

Can construct elements and attributes using computed names:

for $x in document(“dblp.xml”)/dblp/*,

$year in $x/year,

$title in $x/title/text(),

element node-name($x) {

attribute {“year-” + $year} { $title }

}

10

XQuery Wrap-up XQuery is very SQL-like, but in some ways

cleaner and more orthogonal It is based on paths and binding tuples, with

collections and trees as its first-class objects

See www.w3.org/TR/xquery/ for more details on the language

11

A Problem We frequently want to reference data in a way that

differs from the way it’s stored XML data HTML, text, etc. Relational data XML data Relational data Different relational representation XML data Different XML representation

Generally, these can all be thought of as different views over the data A view is a named query Let’s start with a special presentation language for XML

HTML

12

XSL(T): XML “Other Stuff” XSL (XML Stylesheet Language) is actually divided

into two parts: XSL:FO: formatting for XML XSLT: a special transformation language

We’ll leave XSL:FO for you to read off www.w3.org, if you’re interested

XSLT is actually able to convert from XML HTML, which is how many people do their formatting today Products like Apache Cocoon generally translate XML

HTML on the server side Your browser will do XML HTML on the client side

13

Other Forms of ViewsXSLT is a language primarily designed from going

from XML non-XML

Obviously, we can do XML XML in XQuery

… Or relations relations

… What about relations XML and XML relations?

Let’s start with XML XML, relations relations

14

Views in SQL and XQuery A view is a named query We use the name of the view to invoke the query

(treating it as if it were the relation it returns)

SQL:CREATE VIEW V(A,B,C) AS

SELECT A,B,C FROM R WHERE R.A = “123”

XQuery:declare function V() as element(content)* {

for $r in doc(“R”)/root/tree, $a in $r/a, $b in $r/b, $c in $r/cwhere $a = “123”return <content>{$a, $b, $c}</content>

}

SELECT * FROM V, RWHERE V.B = 5 AND V.C = R.C

for $v in V()/content, $r in doc(“r”)/root/treewhere $v/b = $r/breturn $v

Using the views:

15

What’s Useful about ViewsProviding security/access control

We can assign users permissions on different views Can select or project so we only reveal what we want!

Can be used as relations in other queries Allows the user to query things that make more sense

Describe transformations from one schema (the base relations) to another (the output of the view) The basis of converting from XML to relations or vice versa This will be incredibly useful in data integration, discussed

soon…

Allow us to define recursive queries

16

Materialized vs. Virtual Views

A virtual view is a named query that is actually re-computed every time – it is merged with the referencing query

CREATE VIEW V(A,B,C) AS

SELECT A,B,C FROM R WHERE R.A = “123”

A materialized view is one that is computed once and its results are stored as a table Think of this as a cached answer These are incredibly useful! Techniques exist for using materialized views to answer other queries Materialized views are the basis of relating tables in different

schemas

SELECT * FROM V, RWHERE V.B = 5 AND V.C = R.C

17

Views Should Stay Fresh Views (sometimes called intensional relations)

behave, from the perspective of a query language, exactly like base relations (extensional relations)

But there’s an association that should be maintained: If tuples change in the base relation, they should

change in the view (whether it’s materialized or not) If tuples change in the view, that should reflect in

the base relation(s)

18

View Maintenance and the View Update Problem There exist algorithms to incrementally recompute a

materialized view when the base relations change We can try to propagate view changes to the base

relations However, there are lots of views that aren’t easily updatable:

We can ensure views are updatable by enforcing certain constraints (e.g., no aggregation),but this limits the kinds of views we can have

A B

1 2

2 2

B C

2 4

2 3

R S A B C

1 2 4

1 2 3

2 2 4

2 2 3

R⋈S delete?

19

Views as a Bridge between Data Models

A claim made several times:“XML can’t represent anything that can’t be

expressed in in the relational model”

If this is true, then we must be able to represent XML in relationsStore a relational view of XML

(or create an XML view of relations)

An Important Set of QuestionsViews are incredibly powerful formalisms for describing

how data relates: fn: rel … rel rel

(Or XML XML XML, or rel rel XML, ...)

Can I define a view recursively? Why might this be useful in the XML construction case?

When should the recursion stop?

Suppose we have two views, v1 and v2

How do I know whether they represent the same data? If v1 is materialized, can we use it to compute v2?

This is fundamental to query optimization and data integration, as we’ll see later

Reasoning about Queries and ViewsSQL or XQuery are a bit too complex to reason

about directly Some aspects of it make reasoning about SQL

queries undecidable

We need an elegant way of describing views (let’s assume a relational model for now) Should be declarative Should be less complex than SQL Doesn’t need to support all of SQL – aggregation,

for instance, may be more than we need

Referências Raghu Ramakrishnan et al, “Database

Management Systems” Avi Silberchatz et al, “Database System

Concepts” XML Recommendation.