Database Reference
In-Depth Information
Having defined the user-created content we intend to represent, we outline a list
of operations to capture such content. In the following,
c
is a command issued by
the user (either a query or a write statement).
l
annotate
(
t
,
c
) associates a tag or comment
t
with an attribute (column), tuple
(row), cell, or whole relation which is the result of running
c
on
D
. Note that this
includes schema items (relation or attribute names), which are obtained by
running
c
on Catalog tables.
l
Enrich
(
t
,
c
) associate structured information (a tuple
t
) with some existing data:
attribute (column), tuple (row), cell, or whole relation which is the result of
running
c
in
D
. Again, this includes metadata.
l
Link
(
l
,
c
) associates with some data or metadata (the result of running
c
)an
external reference
l
(URL, filename in a local file system, or combination of
network address and filename).
U
be a database user. We
assume that
u
has access to the Catalog (system) tables, at least to the data in them
that refers to the schema of
D
.The
private view
of user
u
(in symbols,
Pv
(
u
)) is
defined as a relation with schema
(Reference, Type, Value)
, where
l
Reference
is a set of rowids in the database, given by the command
c
from
the user, that identify the referent
l
Type
is one of
annotate, enrich, link
l
Value
depends on the type, and it represents the user-created content
We discuss
Reference
and
Value
in more detail. When a command
c
is
over Catalog tables, the reference is called a
metadata reference
; otherwise it is a
data reference
. When the command refers to a single attribute in a single row, it is
called a
cell reference.
3
For metadata references, which we expect to be the most
used, we simply get the rowids from the Catalog tables. For data references, though,
we need to distinguish between
aff
Formally, this is summarized as follows. Let
u
∈
for a write statement
w
and the result
q
(
D
)of
running a query
q
. The rows in
aff
(
w
) exist in the database, and hence have rowids,
which we can collect. A relational query, on the other hand, may create tuples that
do not exist in the database through the use of joins and groupings. When the user
wants to attach content to some tuples
R
ð
w
Þ
,
r
n
} of the answer to some query
q
, those tuples exists only in a transient form and have no rowids (unless, of course,
q
is issued in the context of a
CREATE TABLE
or
CREATE MATERIALIZED
VIEW
command). Hence, we instead attach the content to those tuples in the
database that were used to create
q
(
D
). For a query
q
, answer
q
(
D
), the
lineage
of
¼
{
r
1
,
...
3
Note that it may be impossible to decide when a query returns as answer a single row. In practice,
we expect that a (human) user would pick a particular row (and/or a particular attribute within a
row) by clicking on it in a GUI, and then attaching some information to the selected value. Thus,
the implementation of this functionality may depend on the user interface, an issue that is not
within the scope of this chapter. We assume, though, that such functionality exists, and hence we
provide operations for it.
Search WWH ::
Custom Search