Chapter 02

GAV & LAV: Mapping Global and Local Schemas

The two ways to relate a global schema to its sources — define the global schema as views over the sources (GAV, answered by unfolding) or the sources as views over the global schema (LAV, answered by rewriting) — plus soundness and the GAV view operators every integration exercise leans on.

Reading: ~40 min Interactive: 1 widgets Source: Polimi TIS 2025/26 — Structured Data Integration 1 (deck 02)

01 · Setup

Global schema, source schemata, the mapping

Formally, a data integration system is a triple $(G, S, M)$ : a global (mediated) schema $G$ , a set of sources $S$ , and a set of mappings $M$ relating them. A user query is posed against $G$ ; the mapping’s job is to say which real data in the sources correspond to the virtual data of the global schema.

This is a virtual-integration problem by definition: with materialized integration the user queries a physical database, so there is nothing to reformulate. The moment the data stays at the sources, you must decide the direction of the mapping — and there are exactly two basic choices (plus their combination):

GAV — Global As View

Each element $g$ of the global schema is defined as a query over the sources: $g \leftarrow q_S$ . The mapping tells you how to compute each global concept.

LAV — Local As View

Each source relation $s$ is defined as a query over the global schema: $s \leftarrow q_G$ . The mapping tells you what each source contains in global terms.

GLAV — both

A set of assertions, some views over the global schema and some over the sources — the general case combining the two.

key

The one sentence that unlocks the topic

In GAV the global schema is the view (built from sources); in LAV the sources are the views (built from the global schema). Everything else — how you answer a query, how easy it is to add a source — follows from that direction.

Here is that sentence as a picture, with the two consequences graders ask for written underneath each arrow:

02 · Exam-hot

GAV: global as view & unfolding

GAV vs LAV — a Part I favourite, and half of every integration exercise

“Describe GAV and LAV, their differences, and when each is appropriate” is asked as standalone theory in 2 of 16 sessions (2017-09-08, 2018-09-07). More importantly, writing the GAV mapping and rewriting a query is a graded sub-part of all 7 integration Part II exercises in the bank — so this is not optional theory, it is the machinery of the exercise. Graders want the direction of each mapping, the query-processing consequence (unfolding vs rewriting), and the maintenance trade-off.

In GAV, a mapping is a set of assertions — one per global element $g$ — of the form $g \leftarrow q_S$ , a query $q_S$ over the sources. Because each global relation is a query over the sources, answering a global query is mechanical: replace every global predicate by its defining query. This is view unfolding, and it is why GAV query processing is easy.

tip

Worked GAV — two product catalogs

Two sources describe products with slightly different schemas. The global relation GLOB-PROD is defined as their UNION (one branch joins Product to Version, the other pads the missing version fields with null):

CREATE VIEW GLOB-PROD AS
  SELECT Code AS PCode, VersionCode AS VCode, Version.Name AS Name, Size, Color,
         Version.Description AS Description, CatID, Price, Stock
  FROM   SOURCE1.Product, SOURCE1.Version
  WHERE  Code = ProductCode
UNION
  SELECT Code AS PCode, null AS VCode, Name, Size, Color, Description,
         Type AS CatID, Price, Q_ty AS Stock
  FROM   SOURCE2.Product

Now unfold a query on the global schema. A selection over GLOB-PROD is pushed through the union into each branch:

GAV query processing Unfolding a global query into source queries

1 · The global query

SELECT PCode, VCode, Price, Stock FROM GLOB-PROD WHERE Size = 'V' AND Color = 'Red'

2 · Replace GLOB-PROD by its definition

GLOB-PROD is a UNION of two source queries — substitute the view body in place of the name.

3 · Push the selection through the union

The filter Size = 'V' AND Color = 'Red' applies to each branch independently.

4 · Two source queries

Branch 1 hits SOURCE1.Product ⋈ SOURCE1.Version; branch 2 hits SOURCE2.Product; UNION the results. No reasoning required — pure substitution.

Change the query and the substitution follows it. Two things only show up this way: each branch renames columns differently (Stock is Q_ty in SOURCE2), and filtering on a column a branch pads with null kills that branch outright:

Hands-on

GAV unfolding — a global query becomes source queries

GLOB-PROD is defined as a UNION over two product catalogs. Because each global relation is a query over the sources, answering is pure substitution. Pick a query and step through it.

The worked example: a projection plus a two-predicate filter. Both branches contribute.

4 · Two source queries

-- SOURCE1
SELECT Code AS PCode, VersionCode AS VCode, Price, Stock
FROM   SOURCE1.Product, SOURCE1.Version
WHERE  Code = ProductCode AND Size = 'V' AND Color = 'Red'

UNION

-- SOURCE2
SELECT Code AS PCode, null AS VCode, Price, Q_ty AS Stock
FROM   SOURCE2.Product
WHERE  Size = 'V' AND Color = 'Red'

Each branch now speaks its own source dialect. Send them off, union the answers, done.

Branch	Global attribute	Source column
SOURCE1	PCode	Code
SOURCE1	VCode	VersionCode
SOURCE2	PCode	Code
SOURCE2	Stock	Q_ty

Branches

Contributing

Renames

Try thisLoad A dead branch. The query filters on VCode, but SOURCE2 has no versions and pads that column with null — so one of the two source queries can never return a row. Recognising that a branch is unservable, and dropping it, is the kind of judgement the Part II rewards.

TakeawayGAV query processing is unfolding: replace the global relation by its defining query, push the selection through the union, translate each branch into its source's own column names. No reasoning is required — which is precisely why GAV is easy to query and painful to extend, and why LAV trades one for the other.

GAV's weakness: adding a source

GAV is OK for stable sources but hard to extend. Introduce a new source and the global views must be reconsidered — in the easy UNION case you just add another SELECT … UNION, but in general the view definitions are far more complex and every one mentioning the changed concept must be rewritten. This brittleness under source change is exactly what LAV fixes.

2017-09-08-q12017Q01GAV vs LAV mappingsmedium5 pts

Describe the GAV (global as view) and LAV (local as view) approaches used to define the mapping between the global logical schema and the single source schemata in the data integration context. Discuss the main differences between the two approaches and describe under which conditions GAV is more appropriate than LAV, and vice versa.

03 · Exam-hot

LAV: local as view & answering with views

In LAV the global schema is designed independently — often from a domain description such as an ontology or an enterprise model — and each source relation $s$ is described as a view $s \leftarrow q_G$ over that global schema. The mapping now points the “wrong” way for query answering: it tells you how to build sources from the global schema, but a query arrives on the global schema. There is no unfolding; you must reason to produce a plan — a rewriting of the query as a set of source queries plus a recipe for combining their answers. This is answering queries using views, and it is why LAV query processing is hard.

Worked example The Bertossi movie example, end to end

Global schema $G$ : Movie(Title, Year, Director, Genre), AmerDir(Director), Review(Title, Rev).

The two sources are defined as views over $G$ (conjunctive queries, written Datalog-style):

S1 holds R1 — comedies filmed after 1960 by American directors, with their year:

$R1(\text{Title}, \text{Year}, \text{Director}) \leftarrow \text{Movie}(\text{Title}, \text{Year}, \text{Director}, \text{Genre}),\ \text{AmerDir}(\text{Director}),\ \text{Genre}=\text{comedy},\ \text{Year} \ge 1960$
S2 holds R2 — movies after 1990 with reviews, no directors:

$R2(\text{Title}, \text{Rev}) \leftarrow \text{Movie}(\text{Title}, \text{Year}, \text{Director}, \text{Genre}),\ \text{Review}(\text{Title}, \text{Rev}),\ \text{Year} \ge 1990$

Query on $G$ — all comedies with their reviews filmed since 1950:

$\text{Ans}(\text{Title}, \text{Rev}) \leftarrow \text{Movie}(\text{Title}, \text{Year}, \text{Director}, \text{comedy}),\ \text{Review}(\text{Title}, \text{Rev}),\ \text{Year} \ge 1950$

There is no direct table for this. The system must rewrite the query in terms of the available views: R1 supplies comedies, R2 supplies reviews, so — extract Title values from R1, extract all tuples from R2, and join them on Title at the global level.

The catch (source incompleteness). Because R1 only has comedies after 1960 by American directors and R2 only reviews after 1990, the answer you actually get is “comedies by American directors after 1990 with their reviews” — a subset of what the query asks for. The sources cover only part of what $G$ can express.

A LAV view maps source → global, so any source attribute that has no counterpart in the global schema (a Warnings or Notes column the global schema never declares) is simply left out of the view — and that is fine: no query on the global schema can ever ask for it. LAV only has to describe each source in the vocabulary $G$ actually offers.

key

Why LAV favours extensibility

Because a source is described only in terms of the stable global schema, adding or changing a source means writing (or editing) just that source’s view — nothing else moves. GAV pays for cheap queries with expensive maintenance; LAV pays for cheap maintenance with expensive query answering. Choose GAV when the sources are few and stable; choose LAV when they are many and volatile and the global schema is the fixed point.

04 · Subtlety

Sound, complete & exact mappings

A source almost never holds everything the global schema could express about its concept — it holds a slice. Formalising that slice is the soundness question. A mapping (equivalently, the way a source populates its corresponding definition) is:

Sound

It provides a subset of the data that corresponds to the definition — correct but possibly incomplete. This is the open-world reading, and the usual assumption for real sources.

Complete

It provides a superset — all the relevant data, possibly with extra.

Exact

It provides all and only the corresponding data — both sound and complete. The closed-world reading.

All three are the same question asked three ways — which way does the subset arrow point:

'Complete' is the confusing word — read it carefully

In the LAV case a mapping can be exact or only complete, precisely because sources are incomplete. The mapping is “complete” in the sense that the global schema covers the source contents; yet each source is “incomplete” because it does not cover all the data the independently designed global schema could contain. The Bertossi answer above is the concrete symptom: you get the certain answers, not every answer $G$ could in principle name.

The most common real-world assumption is therefore that sources are sound (incomplete) — you can trust what they return but not assume they return everything. (Symmetrically, when a GAV view is constrained by integrity constraints on the global schema, its mapping can be only sound or exact, never merely complete.)

The GAV view operators

Writing the GAV mapping in an exercise means combining sources with a small, fixed toolkit. Know these by name — the exam expects the right operator for the right situation:

Union

Combine two sources that already share the same schema.

Outer-union

Union of sources with different schemas — missing columns become null (so single-source attributes survive).

Join / Outer-join

Correlate records across sources on a shared key; the outer variant keeps unmatched tuples (padding with null / leaving “uncertain” values to resolve).

Generalization

Fold two related entities into a common super-concept.

key

KeyGen — the missing piece for real mappings

The product example skipped key reconciliation “because it is irrelevant there”. In a real exercise the sources reuse the same codes, so a UNION would collide. You generate a fresh, source-tagged global key — KeyGen(localId, source) — in each branch of the mapping. This is the trick you will apply in every Part II integration exercise; it lives here in the mapping, and we use it throughout the integration chapters.

Load-bearing ideas

A data integration system is $(G, S, M)$ , and the mapping problem is a virtual-integration problem — materialized integration just queries a physical DB.
GAV: global-as-view, $g \leftarrow q_S$ . Query answering by unfolding (easy); adding a source is hard (revise the views).
LAV: source-as-view, $s \leftarrow q_G$ . Query answering by rewriting/reasoning (hard); adding a source is easy (edit one view). Favoured when the global schema is stable.
Soundness: sound = subset (open-world, the usual case), complete = superset, exact = both (closed-world). Sources are normally assumed sound/incomplete.
GAV toolkit: union, outer-union, join, outer-join, generalization — plus KeyGen for source-tagged global keys.
Exam radar: be able to (1) state GAV vs LAV with their query-processing and maintenance trade-offs and pick one under given conditions; (2) write a GAV UNION view with KeyGen and unfold a query through it; (3) define sound/complete/exact.