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

The key intuition here is that a reference in the Refs table is akin to a foreign
key . That is, rowid values in this table are used to refer to existing data in the
database on which they depend. This intuition immediately tells us two important
things:
l When data is added to the database, there are no maintenance issues for private
views. This is similar to the introduction of new values in a primary key column;
such actions cannot break an integrity constraint.
l When data is deleted or updated, there are several possible options as to what to
do with references to them. Which one is better may depend on the particular
user. The user may be offered a set of options of what to do in such cases. A
cascade-like action would delete all rows in the Refs table (and also in the
Private and Values table) that refer to rows that are deleted or updated
(the rational to delete references to updated values is that it was the value that
most likely prompted the user to add some content). Note that this policy creates
some overhead, since rows that are referenced in the private data need to
somehow be marked so that, in deletion or update, the system knows that it
needs to check the private data of some users. Since the change may come from
the system, in principle the private data of all users that have access to such rows
need to be checked. This could be implemented with a mechanism similar to the
one used to manage triggers. However, cost remains an issue.
There is, however, a more complex but interesting possibility. As pointed out
earlier, the definitions given above are static , that is, they use the state of the
database at a point in time. As database D evolves over time, ext ( D ) is bound to
change. We assume that changes in both data and metadata are beyond the control
of any user, that is, for any user u , D may change over time as a result of events that
u neither initiates nor controls. Deleting any references to the data would avoid
dangling references . But if users created content (tags, etc.) in the first place, it is
because there was something of interest to them in such data. Even if the data
changes or is deleted, the content may still be of interest, and remembering the
content may be a more interesting option.
An idea proposed long time ago is that of a no overwrite database, that is, a
system where all data has a timestamp attached and new values are simply added to
the database with a current timestamp, while old values are never deleted [ 7 ]. Such
a mechanism enables the support of sophisticated temporal database capabilities,
which is a complex subject of research in itself [ 8 ]. The basic idea, however, is quite
intuitive: a tuple update creates a new tuple version. Each tuple version has an
associated timestamp, and all versions, old and new, are maintained by the system
and made accessible. Applying this idea to our concept of private view, we can
transform such view into a time-sensitive repository (even if the database itself is
not!). When referred data is deleted or updated, the content related to it in the
private view is not deleted. However, an extra marker is added to the table to mark
when data is active, or it has been deleted or updated. Thus, when changed, data is
simply marked, but annotations are kept. Note that the mechanism proposed earlier
for enriched queries can still be used, with only a slight modification. A selection is