Data Provenance for Historical Queries in Relational
Database
Asma Rani Navneet Goyal
Lecturer Professor
Birla Institute of Technology & Science Birla Institute of Technology & Science
Pilani, India Pilani, India
+919468646534 +919929095379
asma.rani@pilani.bits- goel@pilani.bits-pilani.ac.in
pilani.ac.in
ABSTRACT
Capturing, modeling, and querying data provenance in databases
has gained considerable importance in the last decade. All kinds
of applications developed on top of databases, now a days collect
provenance for various purposes like trustworthiness of data,
update management, quality measurement etc. For these purposes,
there is a need to efficiently capture, store, and query provenance
information for current as well as historical queries executed on
the database. Most of the existing provenance models like DB-
Notes, MONDRIAN, Perm, Orchestra, TRIO, and GProM are
suitable for capturing and querying provenance in relational
databases. All these models can capture provenance only for
currently executing queries, except for TRIO and GProM, which
can capture and query provenance for historical queries also. But,
the time and space complexity of these two models is very high.
In this paper, we propose a framework, Data Provenance for
Historical Queries (DPHQ), which is capable of efficiently
capturing and querying provenance for queries, including that of
historical queries. The proposed model also supports provenance
for updates. In our model, we have used Zero Information Loss
Database [2] to execute historical queries at any point of time,
using the concept of nested relations. A graph database is used for
storing and subsequent querying of provenance information.
CCS Concepts
Information Systems Data Provenance; 500
Information Systems Query Languages; 300
Keywords
Data Provenance; DPHQ; ZILD; Query Inversion; Provenance
Querying; Graph Database; Neo4j; TPC-H.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. Copyrights
for components of this work owned by others than ACM must be honored.
Abstracting with credit is permitted. To copy otherwise, or republish, to
post on servers or to redistribute to lists, requires prior specific
permission and/or a fee. Request permissions from
Permissions@acm.org.
Compute 2015, October 29-31, 2015, Ghaziabad, India
2015 ACM. ISBN 978-1-4503-3650-5/15/10$15.00
DOI: http://dx.doi.org/10.1145/2835043.2835047
Shashi K. Gadia
Associate Professor
Iowa State University
United States
(515) 294-2253
gadia@iastate.edu
1. INTRODUCTION
As the data in the world is growing at an unprecedented rate, data
provenance has become an important topic of research. Data
provenance is used to determine the veracity [11] and the quality
[5] of data. Provenance of a piece of a data includes information
such as the origin of the data, date and process of creation, date
of last modification etc. [19].Capturing, storing and querying the
provenance data is of paramount importance as it supports to
trustworthiness [10], reliability, reputability, accountability,
privacy and quality [5] of data. In the context of scientific
experiments, data provenance can be used in reproducing the
experiments [18] and to determine the quality of work. It
empowers the auditing and helps in View Maintenance [7],
Update Propagation [13] without executing the query again. In
addition, it also provides scope for data analysis with less efforts
in terms of time and volume of data to be searched [11]. In a
business domain, it makes easier for the business to trust the data
which is transferred between trusted partners [21] and helps in
decision making or analyzing data. One of the most common
examples of provenance information is data citation [3], where a
reference to a previous publication is mentioned.
Granularity of provenance information can be defined at
following two levels, viz., coarse grained and fine grained. The
first level tells us about which sequence of activities or operators
are executed to generate a dataset and the second level gives
information about which source tuples contribute to a piece of
data in result set, respectively [21]. In Databases, data provenance
is captured at fine-grained level as it is more significant and
explanatory. Fine grained provenance can further be classified
into three categories, viz., Where-Provenance [4], Why-
Provenance [4] and How-Provenance.[14]. Where-Provenance
indentify sources from where a value is copied to the result set. It
only tells us about the cells from where the value is coming, but
not about the source tuples which are sufficient enough to
generate the result tuple by executing the query again on
provenance information. Why-Provenance captures, why a result
tuple has been derived [4]. It gives us the source tuples those
contributed to produce the result tuple and are sufficient enough
to produce the result tuple by executing the same query again, on
provenance information. But, it does not provide any information
about the derivation process of a result tuple i.e., how these tuples
in provenance information have contributed towards the result.
How-Provenance captures the complete derivation history of a
result tuple in a form of provenance polynomial [14] [17]. How-
Provenance is a superset of Where and Why Provenance. An
example showing why and how provenance is given in Figure 1.
 Part Partsupp
Tid Pid Pname Tid Pid Sid
P1 1 Mouse
PS1 1 1
P2 2 HDD PS2 2 1
P3 3 Kindle PS3 1 2
Query: select Pname from Part p join Partsupp ps on
p.Pid=ps.Pid where ps.Sid=2.
Query Result: Mouse
Why-Provenance=<P1,PS3>, How-Provenance= <P1*PS3>
Figure 1. Example : Why and How Provenance
In this work, we present a provenance framework, Data
Provenance for Historical Queries (DPHQ), which captures the
detailed provenance information for every result tuple of queries,
including that for historical queries. To capture provenance
information for historical queries, we need to efficiently maintain
the complete history of all the updates in a database. For this
purpose, we have used a Zero Information Loss Database (ZILD)
[2], which has been implemented on top of a relational database.
ZILD is space efficient as with any update it only stores updated
value in nested table without storing the values of other attributes
in new row, unlike relational databases which use Type II
changes (new record approach).
A result tuple for a query can be generated in multiple ways.
DPHQ generates provenance polynomial that includes all the
derivations to generate a given result tuple. DPHQ architecture
and the details of implementation of ZILD is given in Section 3.
DPHQ query support is presented in Section 3.1. The provenance
information is captured using Query Inversion approach [12], and
is stored in a provenance table. Details of capturing and storing of
provenance is presented in Section 3.1. Although, storing
provenance data in relational databases is very simple, but
querying or tracking it is computationally expensive due to a large
number of joins. Therefore, to efficiently query the provenance
information, our framework also provides a support to store
provenance information in a graph database in the form of key-
value pairs [22]. Details of how provenance is stored in graph
database and querying provenance is given in Section 3.2. Salient
features of DPHQ are:
Captures provenance information for every result tuple of
queries, including that for historical queries using zero
information loss database.
Manages updates efficiently using nested tables.
2. RELATED WORK
In the literature, there are two broad approaches for data
provenance, viz., annotation-based approach[21][19][6] and
query inversion based approach[21][19][12].
In Annotation-based approach, zero or more annotations are
appended with every cell value in source tuples which propagate
from source to result data while querying. Laura Chiticariu et. al.
[6] proposed a DB-Notes System based on where-provenance.
System applies zero or more annotations on each cell which
propagates from source to result data while querying. They
developed a Provenance Query Language, pSQL (an extension of
SQL) to support storing and propagating annotation (transparent
to user). Floris Geerts et. al [8] presents an annotation-oriented
data model, MONDRIAN, for provenance capturing and
querying. They applied annotations on set of cell values in the
form of blocks instead of applying on each cell. Proposed model
uses different colors for different values (annotations) on blocks.
Color Query Language was proposed based on Color Algebra for
querying data as well as provenance. Both DB-Notes and
MONDRIAN use Annotation approach to capture provenance.
But it is very complex to assign annotations on each cell or block
and assigning the annotations causes storage overhead also.
In query inversion approach, provenance information is captured
using query rewriting. By using this approach, transformations
can be inverted to determine the source tuples that have
contributed towards the result set. Boris Glavic et al.[9][12]
proposed a model for provenance in relational database, Perm
(Provenance Extension of the Relational model), based on why-
provenance and presented PI-CS (Perm Influence Contribution
Semantics) to generate the provenance which works on both sets
and bags. Perm is built on PostgreSQL for capturing provenance
by rewriting the original query which annotates the result dataset
with provenance information. Perm uses an SQL language
extension called SQL-PLE to enable a user to issue provenance
queries.
Todd J. Green et. al. [13][15] proposed an Orchestra Data Model
based on the need for Collaborative Data Sharing of data between
different users to help update exchange efficiently. Orchestra also
enforces the trust level by capturing the provenance information at
every step of transformation by any user. As the updates
performed by any user are being translated, they are filtered based
on the trust conditions that use the provenance of the data in the
updates. They implemented a query language ProQL [16] for
provenance graph based on provenance semiring [14] to trace the
derivation of each transformed update. But Orchestra Data Model
is applicable to small dataset only. As the volume of data
increases, communication overhead will also increases due to
more number of updates may happen.
DB-Notes, MONDRIAN, ORCHESTRA, and PERM are suitable
to capture provenance information for currently executing query
only. Also, these models support the provenance querying while
capturing . But, in current scenario, to analyze the data which has
been generated in the past, there is a need to capture the
provenance information for historical queries also. Querying
support for the stored provenance information is also needed for
various applications like quality measurement, reputability, error
analysis etc.
Jennifer Widom [23] proposed the Trio model for database system
basically for data accuracy and data lineage. She defined the view
data lineage as the maximal set of tuples from source tables that
produced a data item in a materialized warehouse view. TRIO
uses Inverse Query [21] instead for Annotation Propagation for
provenance generation. The inverse queries are recorded at the
granularity of a tuple and stored in a special Lineage table.
Lineage table is: Lineage (tupleID, derivation-type, time, how-
derived, lineage-data). Jennifer Widom et.al. proposed TriQL
query language [20] for provenance querying in TRIO based on
SQL. TriQL query is converted into SQL query and then post-
processing is done for Accuracy, confidence and lineage queries.
TRIO model is suitable for capturing the lineage for past queries
(Historical Lineage) from the expired portion of database i.e. the
data which is not valid now. But its lineage table which includes
complete lineage information for every tuple, creates lots of
storage overhead. Bahareh Sadat Arab et. al. [1] presents GProM
(Generic Database Provenance Middleware) which captures Start
provenance using query rewriting. GProM is able to capture
provenance for concurrent database transactions also. Using the
Audit log it traces the transaction provenance and provenance for Find all the tables (TABLES [M]) of
classical database to design ZILD.
past queries. Capturing the provenance of past queries using audit
log will need complex query rewriting. Audit log may not capture
all the information all the time. GProM does not store provenance I=0
information explicitly for querying it later.
Marcin Wylot et. al. [24][25] presents TripleProv: which co- N
Stop Is I<M?
locates Lineage, L (Annotation) in RDF Triplets with different
options like SLPO and SPOL. TripleProv is suitable for web data Y
but not suitable for relational data as propagating the annotations For TABLES [I], find all the
from source to result set increases overhead as in [6][8]. columns COLUMNS [N].

In this paper, we are presenting an approach to generate ZILD on

top of any relational database which manages all the updates J=0
efficiently and is suitable to capture provenance of currently Add validfrom,
executing query as well as historical queries. Provenance N validto, tupleid
polynomial [17] which includes complete derivation is generated Is J<N? Columns to
Table creation.
using query inversion approach [12] and stored in Neo4j graph Y
database for querying provenance information efficiently [22].
Analyze the column[J]
Create Table.
I++
3. PROPOSED PROVENANCE
FRAMEWORK Add Column to N Is Column [J]
Table Creation.
Figure 2. shows the complete data flow in the proposed DPHQ J++
Updatable?
(Data Provenance for Historical Queries) framework. The user
Y
issues queries on the relational database which are then
automatically rewritten and executed on a Zero Information Loss Create type TYPE1 which has Column[J],
Database (ZILD). Queries are executed and provenance is validfrom, Validto members.
captured in the provenance table and also in a graph database. We
have implemented ZILD on top of a relational database using Create type TYPE2 which is table of TYPE1
object-relational database concepts like user defined data types
and nested tables. A complete flowchart for creating ZILD schema
Create Column of TYPE2
from a given relational schema is given in figure 3. In this paper,
we have used the following TPC-H schema [27]:
PART(partkey,name,mfgr,brand,type,size,container,retailprice,comment) Figure 3. ZILD Schema Design
SUPPLIER(suppkey,name,address,nationkey,phone,acctbal,comment) NATION(nationkey,name,regionkey,comment)

PARTSUPP(partkey,suppkey,availqty,aupplycost,comment) REGION(regionkey,name,comment)
CUSTOMER(custkey, name, address, nationkey, phone, acctbal,
mktsegment,comment)
Provenance Graph
Query Result ORDERS(orderkey,custkey,orderstatus,totalprice,orderdate,orderpriority,
clerk, shippriority, comment,)
Graph Database
LINEITEM(orderkey,partkey,suppkey,linenumber,quantity,extendedprice
,discount, tax, returnflag, linestatus, shipdate, commitdate, receiptdate,
shipinstruct,shipmode,comment)
ZILD Nested tables have been created for all the updatable attributes in
the schema to capture all the updates on attributes. For example,
in Region table, name of region and comment are updatable. To
Query and Provenance Capturing Module (QPCM)
store all the updates related to name, we have created a nested
table for name within region table as shown below:
create or replace type R_Name as object (
eR_Name varchar2(60),
Query Relational Database Provenance
Table Table valid_from timestamp,
valid_to timestamp);
create or replace type Reg_Name as table of R_Name;
In ZILD, the following table corresponding to Region has been
User Query created:
create table Zero_Region(R_RegionKey number(38) primary key,
Figure 2. DPHQ Framework r_Name Reg_Name, r_Comment Reg_Comment, r_valid_from
timestamp, r_valid_to timestamp, R_tID varchar2(10)) NESTED
 q72: select r_name from zero_nation n join
zero_region r on r.r_regionkey=n.n_regionkey

Query Rewriting Module User1

Query Result
Rewritten Query TupleID R_Name PROVENANCE
Select rr.er_name, replace(wm_concat(rtrim( q72t0 AMERICA R2*N3+R2*N2+R2*N25+
nvl2(r.r_tid , r.r_tid ||*,)||nvl2(n.n_tid, R2*N18+R2*N4
n.n_tid ||*,),*)),,,+) provenance from q72t1 ASIA R3*N9+R3*N22+R3*N19
zero_nation n, zero_region r, table(r.r_name) +R3*N13+R3*N10
rr where r.r_regionkey=n.n_regionkey and q72t2 EUROPE R4*N7+R4*N24+R4*N23
n_valid_to is null and r_valid_to is null and +R4*N20+R4*N8
rr.valid_to is null group by rr.er_name
q72t3 MIDDLEEAST R5*N5+R5*N21+R5*N14
+R5*N12+R5*N11
q72t4 africa R1*N6+R1*N1+R1*N17
ZILD
+R1*N16+R1*N15

Provenance Table
RESULTID PROVENANCE
Query Table q72t0 R2*N3+R2*N2+R2*N25
QID QUERYNAME USER TIME +R2*N18+R2*N4
q70 update zero_region set r_name= asma 22-apr-2015 q72t1 R3*N9+R3*N22+R3*N19
BHARAT where r_name=INDIA 03:33:50 pm +R3*N13+R3*N10
q71 select p_name from zero_part, User1 24-apr-2015 q72t2 R4*N7+R4*N24+R4*N23
zero_ps where p_partkey= 09:01:42 am +R4*N20+R4*N8
ps_partkey and ps_suppkey=5 q72t3 R5*N5+R5*N21+R5*N14
q72 select r_name from zero_nation n User1 15-may- +R5*N12+R5*N11
join zero_region r on r.r_regionkey= 2015 q72t4 R1*N6+R1*N1+R1*N17
n.n_regionkey 12:04:31 pm +R1*N16+R1*N15

Figure 4. DPHQ: Querying and Provenance Generation for Example 2

TABLE r_Name store as rReg_Name_tab, NESTED TABLE

r_Comment store as rReg_Comment_tab;
To store the data which is not valid now, we have added two
attributes, viz., valid_from and valid_to in each tuple in a relation,
where valid_to attribute will have the constant NULL for
currently valid tuples.
Querying and Provenance Capturing Module (QPCM) is
developed on top of ZILD. In the proposed provenance
framework, complexity introduced by ZILD is completely
abstracted from the user. Queries posed by the users are parsed
against the schema of ZILD and rewritten by QPCM, which
passes it to ZILD for execution. A complete worked out example
is given in section 3.1. All the queries executed on the system are
stored in a table in the relational database with the schema:
QUERYTABLE (QueryID, Query, USER, Time). It also provides
some provenance information like which users are accessing the
database and when, and what kind of queries they are executing.
The captured provenance information is stored in a table with the
schema: PROVENANCETABLE (ResultID, PROVENANCE) in
the relational database where ResultID is concatenation of
QueryID and TupleID. To provide support for efficient
provenance querying, provenance information is also stored in a
graph database in the form of key-value pairs.
3.1 Provenance Generation in DPHQ
In this section, we give details of provenance generation in
DPHQ with some suitably chosen examples. Unlike any
conventional relational database, DPHQ allows a user to query
data that has expired or has been modified, by using the qualifiers,
valid_from and valid_to. DPHQ also allows users to generate
results of queries that were executed in the past. ZILD gives the
same result as was obtained by a query when it was executed in
the past. To get historical data or currently valid data, we have
extended our SQL query by adding two constructs, viz., instance
and valid_on_now or valid_on 'date' as explained in Examples 1
and 2.
We now present a few examples of queries and their
corresponding provenance that gets generated thereof.
Example 1: (Q1) Display the partname supplied by supplier
'Supplier#000000001 on 15/04/2015.
User query: select instance p_name from part p, partsupp ps,
supplier s where p.p_partkey=ps.ps_partkey and s.s_suppkey=
ps.ps_suppkey and s.s_name=' Supplier#00000001' valid_on
15-Apr-2015.
This query will be passed to QPCM which will automatically
rewrite the query into a query that can be executed on ZILD.
Rewritten query is given below:
Rewritten Query: Select instance pn.ep_name, replace(
wm_concat(rtrim( nvl2(p.p_tid , p.p_tid ||*,)|| nvl2(ps.ps_tid,
n.n_tid ||*,) nvl2(s.s_tid, s.s_tid ||*,),*)),, ,+)
provenance from zero_part p, table(p.p_name) pn, zero_partsupp
ps, zero_supplier s, table(s.s_name) sn where
p.p_partkey=ps.ps_partkey and s.s_suppkey=ps.ps_suppkey and
sn.es_name='Supplier#00000001' and p_valid_from<= 15-Apr-
2015<=p_valid_to and ps_valid_from<=15-Apr-2015 <=
ps_valid_to and s_valid_from<= 15-Apr-2015<=s_valid_to
and pn.valid_from<= 15-Apr-2015<=pn.valid_to and
sn.valid_from <= 15-Apr-2015<=sn.valid_to group by
p.p_name;
Above query will display all part names which are supplied by
Supplier#000000001 on 15-April-2015. The corresponding
provenance in the form of provenance polynomial is also
generated.
Example 2: (q72) Display the region name where nation key=1.
User Query: select instance r_name from region r join nation n on
n.n_regionkey=r.r_regionkey where n.n_nationkey=1
valid_on_now.
Rewritten Query: select instance rr.er_name, replace(
wm_concat(rtrim( nvl2(r.r_tid , r.r_tid ||*,)||nvl2(n.n_tid,
n.n_tid ||*,),*)),,,+) provenance from zero_nation n,
zero_region r, table(r.r_name) rr where
r.r_regionkey=n.n_regionkey and n.n_nationkey=1 and
n_valid_to is null and r_valid_to is null and rr.valid_to is null
group by rr.er_name
Above query will display region name corresponding to nation
with nationkey=1.
Complete worked out Example 2 and corresponding provenance
polynomial is shown in Figure 4.
Provenance information will include provenance polynomial as
well as query execution time. Query execution time gives validity
time of source tuples. We store this in the query table. Captured
provenance shown in figure 4 is stored in graph database, where
edges are directed from source to result tuple. Result tuple
attributes in provenance graph have addition property which
include query execution time to store complete provenance
information as stated earlier. The snapshot of provenance graph
in Neo4j for Example 2 is shown in Figure 5. It shows the
different derivations of tuple q72t3 in result set like N5*R5+
N11*R5+ N14*R5+ N21*R5+N12*R5. In this polynomial, *
signifies Multiplication (join operator) and + signifies (OR
operator).
3.2 Querying Provenance Data
To store the provenance information, common data structure
generally used is Directed Acyclic Graph (DAG). Although,
storing provenance information in relational database is very
simple but querying or tracking is computationally inefficient [22]
due to a large number of joins as shown in Figure 4. Therefore, to
efficiently query the provenance information, our framework
provides a support to store provenance information in graph
database in the form of key-value pairs. For this purpose, we have
used Neo4j graph database.
Thus, DPHQ provides following two interfaces for provenance
querying; querying via relational database using SQL and
querying via graph database. User can also perform forward and
backward query in provenance graph as explained in Example 3
and 4.
Source Tuples
Join Operator
N21
*
N14 +
*
+ Output Tuples
N5
q72t3
* +
R5
+
*
N12 +
*
N11
Figure 5. Subset of Provenance Graph for Query in Figure 4.
Example 3: Find all tuples which are derived from tuple with
TupleID R5 (Assuming an error in input tuple with TupleID
R5).
Query: match (tupleid: tuple {name:'R5'})-[*]->(b) RETURN
tupleid,b .
Above Query will result a subtree rooted with node R5 and gives
all the result tuples it contributed towards.
Example 4: Find all tuple which contribute to derive Output
Tuple with TupleID q72t3 (To know about quality or
trustworthiness of this Result)
Query: match (tupleid: tuple {name:'q72t3'}) <-[*]-(b) RETURN
tupleid,b.
Above query will perform backward tracking in provenance graph
and gives all the tuple which contributed to it.
4. CONCLUSION AND FUTURE WORK
We have presented a framework to capture Data Provenance for
Historical Queries (DPHQ). In DPHQ, a zero information loss
database is implemented on top of relational database which
allows us to capture the provenance information for currently
executing query as well as past queries. For this, our framework
creates the nested table for only those attributes in the relations
which are updatable, and manages all the updates with less
storage requirements. DPHQ captures provenance information
using query inversion approach. Captured provenance information
is also stored in the form of DAG in graph database for efficiently
querying. Provenance graph is updated every time new
provenance is captured. Currently, DPHQ supports simple queries
including join and union operator; in future, we will extend it
further to capture provenance for complex queries and also for
nested queries. Presently, DPHQ captures the provenance
information for relational database. It will be further extended to
capture provenance information for Big Data.
5. REFERENCES
[1] Arab, B., Gawlick,D., Radhakrishnan, V., Guo, H., and
Glavic,B. 2014. A Generic Provenance Middleware for
Queries, Updates, and Transactions. In TaPP 14: 6th
USENIX Workshop on the Theory and Practice of
Provenance.
[2] Bhargava, G., and Gadia.S. K. 1993. Relational Database
Systems with Zero Information Loss. In IEEE Transactions
on Knowledge and Data Engineering, vol. 5, Issue. 1, pages
76-87.
DOI=http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnum
ber=204093
[3] Buneman, P., Khanna, S., and Tan.,W.C. 2000. Data
provenance some basic issues. In proceeding of Foundations
of Software Technology and Theoretical Computer Science,
pages 87-93.
DOI=http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1
.1.101.7132
[4] Buneman, P., Khanna, S., and Tan.,W.C. 2001. Why and
Where: A Characterization of Data Provenance. In ICDT,
LECT NOTES COMPUT SC, pages 316-330.
DOI=http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1
.1.6.1848
[5] Buneman,P., and Davidson,S.B. 2010. Data provenance
the foundation of data quality. A Technical Report,
September. DOI= http://icnjp.net/reading/data-provenance-
the-foundation-of-data-quality-wOhg.html
[6] Chiticariu, L., Tan.,W.C., and Vijayvargiya.,G. 2005.
DBNotes: A Post-It System for Relational Databases based
on Provenance. In SIGMOD, pages 942-944.
[7] Cui, Y., Widom, J.,and Wiener., J. L. 2000. Tracing the
Lineage of View Data in a Warehousing Environment. In
TODS, Volume 25 Issue 2, pages 179-227.
[8] Geerts, F., and Kementsietsidis, A. 2006. MONDRIAN:
Annotating and querying databases through colors and
blocks, In ICDE, pages 82-91.
[9] Glavic, B., and Alonso., G. 2009. Perm: Processing
provenance and data on the same data model through query
rewriting. In ICDE, pages 174-185.
DOI=http://ieeexplore.ieee.org/xpls/icp.jsp?arnumber=48124
01
[10] Glavic,B., and Miller,R.J. 2011. Reexamining Some Holy
Grails of Data Provenance. In TaPP 11: 3rd USENIX
Workshop on the Theory and Practice of Provenance, pages
1-6.
[11] Glavic,B. 2012. Big Data Provenance: Challenges and
Implications for Benchmarking. In Springer LNCS 8163,
pages 72-80.
DOI=http://cs.iit.edu/~dbgroup/php/bibtexbrowser.php?key=
G13&bib=..%2Ffiles%2Fdbgroup.bib
[12] Glavic,B., Alonso,G., and Miller,R.J. 2013. Using SQL for
Efficient Generation and Querying of Provenance
Information. In Springer LNCS 8000, pages 291-320.
DOI=http://cs.iit.edu/~dbgroup/pdfpubls/GM13.pdf
[13] Green, T. J., Karvounarakis, G., Ives, Z. G., and Tannen, V.
2007. Update Exchange with Mappings and Provenance. In
VLDB, pages 675-686.
[14] Green, T. J., Karvounarakis, G., and Tannen, V. 2007.
Provenance Semirings. In PODS, pages 31-40.
DOI=http://dl.acm.org/citation.cfm?id=1265535
[15] Green, T. J., Karvounarakis, G., Ives, Z. G., and Tannen, V.
2010. Provenance in Orchestra. In IEEE Data Eng. Bull.,
33(3), pages 9-16.
DOI=http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1
.1.174.5428
[16] Karvounarakis, G., Tannen, V., and Ives, Z.G. 2010.
Querying Data Provenance. In SIGMOD, pages 951-962.
[17] Karvounarakis,G., and Green,T.J. 2012. Semiring-Annotated
Data: Queries and Provenance. In SIGMOD, Volume 41,
Issue 3, pages 05-14.
[18] Korolev, V., and Joshi,A. 2014. PROB: A tool for Tracking
Provenance and Reproducibility of Big Data Experiments. In
Proceeding of Workshop on Reproducible Research
Methodologies (REPRODUCE'14).
[19] Rani,A., and Thalia,S. 2014. Knowledge driven decision
support system for provenance models in relational database.
In Proc. ICDSE, pages 68-75.
DOI=http://ieeexplore.ieee.org/xpls/icp.jsp?arnumber=69746
14
[20] Sarma, A. D., Theobald, M. and Widom,J.2008. Exploiting
Lineage for Confidence Computation in Uncertain and
Probabilistic databases. In ICDE, vol 29, pages 1023-1032.
DOI=http://ieeexplore.ieee.org/xpls/icp.jsp?arnumber=44975
11
[21] Simmhan ,Y. L., Plale ,B., and Gannon, D. 2005. Survey of
data Provenance in e-science. In SIGMOD, vol 34, pages 31-
36.
[22] Vicknair,C. 2010. A comparison of a graph database and a
relational database: a data provenance perspective. In
Proceedings of the 48th Annual Southeast Regional
Conference, ACM SE10, Article no: 42. DOI=
http://dl.acm.org/citation.cfm?id=1900067
[23] Widom,J. 2005. Trio: A System for Integrated Management
of Data, Accuracy, and Lineage. In CIDR, pages 262-276.
DOI=http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.
1.153.9613
[24] Wylot, M., Cudre-Mauroux, P., and Groth P. 2014.
TripleProv: Efficient Processing of Lineage Queries in a
Native RDF Store. In Proceeding of the 23rd international
conference on World Wide Web, WWW'14, pages 455-466.
[25] Wylot, M., Cudre-Mauroux, P., and Groth, P.2015.
Executing Provenance-Enabled Queries over Web Data. In
Proceeding of the 24th international conference on World
Wide Web, WWW'15.
[26] Neo4j Graph Database http://neo4j.com/developer/get-
started/
[27] The TPC-H Benchmark.
http://www.tpc.org/tpch/spec/tpch2.7.0.pdf , page 12.