Social Interaction in Databases - Community-Built Databases: Research and Development - page 170

7.5.2 Private View Querying

Note that it is not enough to allow the user to add data to the database in a
customizable way. The user should also be able to retrieve such information;
therefore, any query means (SQL, forms or otherwise) must be made aware that
this extra information exists and retrieve it if requested. In our view, the system
should automatically create a private view (and all needed tables) each time a user is
added to the system; methods like naming the tables with the username can be used
to keep track of who owns the data and set permissions accordingly. For instance, for
a user with username “JJones”, the system creates tables JJones-private ,
JJones-Refs, and JJones-Values and gives read and write permission to
this user only.
One of the advantages of storing the user-created content in the database using
regular tables is that they are immediately available for querying. Using SQL
(perhaps through an appropriate interface), the user can search for comments,
tags, or any other user-created content that was previously stored. But another
interesting possibility is that when data from the database is queried, the user can
now retrieve data in two ways: standard mode , in which only the data from
the database is used to create an answer, and enriched mode , in which data from
the database is processed, but any related user-created content is automatically
added to data in the answer. That is, the private data is attached by the system,
without the user having to specify in the query additional tables or joins. We can
think of this as delivering raw data versus annotated data . Note that a user can
manually generate an enriched result by adding clauses to an existing SQL query.
However, the system can be made to perform this task automatically.
Intuitively, the process seems simple: for command c , user u , P v ( u ) is the private

data of u . Then, the enriched model processes c as follows:

1. Compute c ( D )( c over D ) as usual. If c was a query q , this is q ( D ). If c was a write
statement w , then aff ( w ) is computed.
2. Do a left outerjoin between c ( D ) and P v ( u ) using the rowid attribute. Formally,

we have

q ð D Þ./ rowid ð Refs ./ refid Private ./ refval Values Þ;

where is used to denote a left outerjoin. Note that a left outerjoin is used

since some rows in the answer may have user-created content attached to them
and others may not, but we do not want to miss any row originally in c ( D ).

./

However, as we will see next, there is an important difference between handling
data and metadata, and we deal with each separately.
Given a query q or write statement w , we can define the metadata involved in
q (in symbols, Meta ( q )) or w (in symbols, Meta ( w )) precisely: