Database Reference
In-Depth Information
, which may be an
insertion, deletion, or update statement. We denote by aff ( w ) the set of rows affected
(changed) by the statement w . For an insertion, this is the set of inserted rows; for a
deletion, this is the set of deleted rows; and for an update, this is the set of modified
rows. Note that for a user u to issue a write statement, the user needs to have certain
permissions granted by the DBA. Given a command c from user u , we use c ( D )to
refer to q ( D )if c is a query q ,or aff ( w )if q is a write statement w .
Given a database D , we talk of the set of users U of D . This is the set of all agents
that are allowed to access D . When agent u
Besides queries, we will also consider
write statements
U accesses D , it is to send a query or a
write statement. We assume that the system can attribute any query or write
statement to a particular user, unambiguously.
Note that we do not define what an agent is. This is due to the fact that many
databases are accessed by applications, and an application may access D on behalf
of several users. Likewise, a database may be used to register sensor inputs in a
totally automatic fashion. We assume, in what follows, that the set of agents has
been defined as needed by the analysis so that it may be restricted to human users or
include other entities. What we assume is that the interactions of agents with the
database can be identified as such, that is, when user u
U accesses the database,
such access is considered a transaction, and all queries and write accesses through-
out the transaction can be attributed to u . In the examples that follow, we will
assume that u is a person; however, we point out that even “programmed” agents
like a sensor may want to access the database in ways that have not been foreseen by
the database creators/designers, and hence, such agents would also benefit from the
framework proposed here.
Given database D , user
sch ( D ) the part of the database
which is accessible (visible) to u . It is understood that any user access of the
database (query or write access) is over D (
u
U , we denote by D
u
) only. Thus, if user
u
issues command
c
, c ( D )
D (
u
), that is, if c is a query q or write statement w ,
rel
( q )
D (
u
) and
aff (
).
Finally, we note that in many cases the access of u to D will be
w
)
D (
u
by an
interface of some kind: typically a GUI, a Web form, or even a process that picks up
user input (clicks, etc.). Such interfaces are usually designed based on the database
schema and on the functionality of the application of which they are a part. We will
assume that any added functionality proposed also creates changes in the interface
so that u can effectively communicate extra information to D . How interfaces
should be enlarged to handle this extra information is an issue beyond the scope
of this chapter.
mediated
7.3 User-Created Content
From now on, we call all data that is entered by a user
.This
covers a wide variety of information. Roughly speaking, user-created content can
be divided into two types:
user-created content
Search WWH ::




Custom Search