Database Reference
In-Depth Information
Increasing the Performance of Provenance Queries with redundant Prove Set storage.
A Prove Set (PS) formally consists of n elements, where each element is a triple:
PS
=
{
(
name, type, size
)
n
}
. Each element consists of a name, a type (e.g., char or int), and
the size of this element (in bytes). We use this structure, because it is highly related
to the relational data model and can be easily extracted into (provenance) data tables.
These tables
redundantly
contain all Prove Sets of the same type and thus, these Prove
Sets are accessible with common SQL. Consequently, we can increase the performance
of provenance queries, because the Prove Set does not have to be extracted in every
query again, which is extremely costly in range queries. Note, that we can check the
redundant information in the tables with help of the watermarked image at any time.
4.5
Implementation of the Hybrid Approach with Postgres 8.4
We implemented a first version of the reliable provenance approach that is based on
Postgres 8.4. Although this version is yet in a premature state, we will explain the main
characteristics of this approach by means of the running example.
Rights extension.
Basically, we have to create a possibility that checks the presence
of the watermark in an image and inserts this image, created by a sensor, initially in the
database. However, since there is no write access to the image data table for the sensor,
the respective user rights have to be extended
temporarily
while executing the UDF.
Permanent insert privileges are not applicable, because this could lead to circumvention
of the watermark checking.
Generally, two variants exist for defining the security level of an UDF in Post-
gres
3
. First, we can define the privileges of the user invoking an UDF (SECURITY
INVOKER). Second, we can define (and change) the privileges of the current user to
those of the user who defined an UDF (SECURITY DEFINER). However, redefining
SECURITY DEFINER to extend the users privileges temporarily fits best to our needs
(see Figure 8 line 22). As a result, the user associated with the sensor, can insert data
into the sensor image table.
Internal Access and external Provenance Library.
The UDF we use for image data
insertion consists of two parts so that we can separate the
access
and
provenance
func-
tionality. The first part contains only functions that are part of our
access library
and
that are responsible for data insertion only. By contrast, the second part of the UDF con-
tains several functions that realise meta data extraction and insertion. These functions
belong to the
provenance library
and are called from access functions.
For instance, the function
insert_sensor_image
in Figure 8 is part of the access li-
brary. This function is called by a client program and executes the insertion of a new
fingerprint image into FiVe DB. At the same time, it performs the privilege extension
(Figure 8 line 22). Furthermore, this access function calls several functions from the
provenance library
, listed below:
•
validate_watermark()
- This function determines whether the data provided as argu-
ment contains a valid watermark.
3
http://www.postgresql.org/docs/8.4/static/sql-createfunction.html
