Database Reference
In-Depth Information
This structure allows the user to enter structured information in the database using
a schema that may not be part of the database (view) schema, that is, with a user-
defined schema. The motivation to allow this kind of input is that whenever
structure is available, it should be used, as it makes storage and querying support
more effective. At the same time, we want to allow the user to enter the informa-
tion in a format of his/her choice to make sure that no data is discarded because it
does not adhere to the predetermined database schema.
A private view is distinguished from a traditional view by two main characteristics:
l Because it is created to collect user-created data in whatever format the user
chooses, its schema is different from traditional schemas. We use a generic table
format inspired by the work in [ 5 ].
l Since private views are completely under the control of the user, the user can
insert, delete, or change all the data in the view. Thus, unlike traditional views,
all kinds of updates are allowed. This avoids the problems that are associated
with traditional views [ 4 ].
Even though the previous point would suggest that a private view should be
considered as an independent table, the data on it is dependent on the database in the
sense that we collect only parasitic user-created content (see Sect. 7.3 ). Hence, the
data on the view does not really have an independent existence and should change
whenever the mentioned data or metadata changes. This is discussed in Sect. 7.5.4 .
Applied to our examples in the previous section, we can see how a private view
would help deal with them. In the first example, the user attaches a comment to two
of the attributes in the schema of the table Locations , using a annotate
command. In the second, a query q is run, and some tuples are found to have
incorrect values. The system computes the lineage of such tuples and attaches to
them (through their rowids) a comment that values are incorrect (another annota-
tion, but this time to data). Finally, the user uses a link to associate with table
Location the URL of a Web site with relevant information.
7.5.1 Private View Organization and Storage
We propose a completely normalized storage for our private views. This achieves
not only efficiencies of space, but also helps define operations over the view, as will
be seen in the next subsection.
We assume that the user issues a query q or a write statement w and then selects a
part of q ( D )or aff ( w ), called the referent , to which user-created content refers. Note
again that q or w is usually generated through an interface of some kind, and the
selection process may involve clicking or other icon manipulation. We simply
assume that the database is made aware of the referent by receiving a set of row
identifiers. We also assume that each row in any table of the database is assigned a
Search WWH ::




Custom Search