Research data management deals with tracking and archiving of data collected during scienti c projects, experiments or observations. The path from data collection to publication should thus be kept comprehensible, reconstructable and plausible. The continuous growth of data, frequent schema changes as well as the varied evaluation of the data makes the storage of every possible database state a very complicated and lengthy task. With the help of data provenance, however, we can determine which part of the primary research data must be stored long-term in order to ensure the reproducibility of the evaluations. It should also be possible to recalculate changes to data and schemata so that old data records do not have to be archived completely. In addition, the stored data must not con ict with existing privacy guidelines.
The presentation and publication of research results increasingly requires the publication of the corresponding research data, which ensures the ndability, accessibility, interoperability, and reusability in the sense of FAIR Data Principles1. In our research, we concentrate on the structured data, e.g. resulting from measurement series, experiments, or always-on sensors, stored in a relational database. The FAIR principle does not necessarily mean, that the entire database of a project has to be stored and published, but only that part of the database which is necessary for the traceability and/or reproducibility of the respective publication. The di culty now is to generate exactly this minimal part of the original research database, called sub-database. The need for the data reduction can be due to high costs in collecting or evaluating the data (expensive or elaborately produced), to privacy aspects when evaluating personal data, or to intellectual property preservation. In our case, the evaluation of the research database is restricted to a
I* J* Provenance
Querynew
Provenancenew relational query language, starting from conjunctive queries, and adding arithmetic or aggregation functions lateron.
Thus, our goal is not only to store the evaluation query
and the query result itself, but also the relevant source data.
However, if data and/or schema change frequently, the
original database must be "frozen" and saved after each
evaluation carried out on the dataset. To avoid this, we use
provenance management techniques [
After the new general data protection regulation (GDPR) becoming valid, it was apparent that the storage of research data, even without containing personal data, may fall under the aspect of privacy. Reasons for the additional privacy requirements are high costs, a lot of time as well as the great e ort required to collect the research data. This implies a natural con ict of interest between publishing original data (provenance) and protecting these data (privacy) for reasons of competition.
All in all, this results in three central research questions, which are summarized in Figure 1: (I.) How to calculate the minimal part of the original research database that has to be stored permanently to achieve replicable research? (red highlighted) (II.) How to unify the theories behind data provenance and schema evolution? (blue highlighted) (III.) How to combine Data Provenance and Privacy aspects in the case of query inversion? (locked tuple)
Let us take a more detailed look at the di erent research
questions. A detailed description of the problems (I.) and
(II.) can be found in [
Data Provenance
Query Unification of Provenance and Evolution (Figure 3). Previous provenance queries have usually been processed on a given xed database and an evaluation query. The combination of data provenance with schema and data evolution should enable the evaluation of provenance queries with changing schemata. Under evolution the new query evaluation (green dotted) can be directly calculated as a composition of the original query evaluation and the inverse evolution (black). It is therefore su cient to memorize one of the two minimal sub-databases I (red highlighted) or J (blue highlighted), the other sub-database can be calculated with the help of the inverse. Privacy in the case of Query Inversion (Figure 4). The determination of a sub-database (red highlighted) based on the query result (green highlighted) is not always possible or permitted. For example, aggregated data cannot be inverted without storing additional information. Personal data, on the other hand, may not be published without a certain anonymization (see locked tuple). It is therefore necessary to generate a partial or generalized database that satis es the provenance criteria on the one hand and does not contradict the privacy aspect on the other. This implies a natural con ict of interest between publishing original data (provenance) and protecting these data (privacy).
Data Provenance
Query
Dependencies. The best known conditions are key
dependencies, functional dependencies (FD) or join dependencies
(JD). These can be extended to much more general
dependencies called (source-to-target) tuple generating
dependencies ((s-t) tgd) and equality generating dependencies (egd).
While s-t tgds are used as a kind of inter-database
dependencies, tgds { an s-t tgd on only one database schema {
as well as egds can be seen as intra-database dependencies
representing integrity constraints within a database [
In our use case s-t tgds create new tuples and tgds/egds
clean the database by replacing null values until the CHASEd
database satis es all given dependencies [
CHASE-inverse. A CHASE-inverse is an inverse function
calculated via the CHASE algorithm. Weaker variants like
the relaxed CHASE-inverse [
Data Provenance. Given a database instance I and an
evaluation query Q, data provenance describes (1) where a
result tuple r does come from (where-provenance), (2) why
and (3) how r exists in the result Q(I). Why -provenance [
Why and where can be derived from the result of the how -provenance. For this we can de ne a reduction based on the information content: where why how. Therefore, we often only concentrate on how -provenance. When including privacy aspects, however, the why - and whereprovenance should not be neglected.
Provenance under Schema Evolution. The description
of schema development using schema modi cation
operators (SMO) such as CREATE table, ADD or DROP column
enables schema and corresponding data changes [
In order to unify the di erent theories, we represent
evaluation queries, provenance queries and evolution functions as
s-t tgds, so that the CHASE algorithm can be applied as a
technique. The CHASE is thus a formalization of the
evaluation as well as evolution of the research database. In a
second step, called BACKCHASE process, we use the CHASE
again to generate a provenance query based on the result of
the evaluation query. Our theories of inverse functions can
be developed from the already existing work of Fagin [
The result equivalent CHASE-inverse is therefore the
weakest CHASE-inverse. Overall, this results in the reduction
result equivalent
relaxed
tp-relaxed
exact;
which forms the su cient conditions for the existence of
a CHASE-inverse. The necessary conditions, on the other
hand, refer to the existence of homomorphisms, an equal
number of tuples as well as result equivalence [
An exact (=), (tp-)relaxed ( tp) or result equivalent ($)
CHASE-inverse can be speci ed for each basic operation
like , ./, or AVG. Adding provenance information such as
provenance polynomials [
Unification of Provenance and Evolution. Given a
database instance I and its evolution J , we can di erentiate
between 15 schema modi cations like CREATE table, ADD or
DROP column. Theses modi cations can be formalized
using the schema modi cation operators de ned in [
Among other things, we found that in some research
institutions the SMOs de ned by Zaniolo et al. are not
sufcient [
Privacy in the case of Query Inversion. For us, the term privacy goes beyond the term of (usually personal) data protection. Rather, we refer to the protection of research data in general. Reasons for protecting research data include economic (company protection), personal (personal data) or nancial aspects. The creation of such data is often timeconsuming and expensive. The identi cation of personal or internal company information should also be strictly prevented.
When reconstructing the minimal sub-database only those
tuples may be reconstructed which do not contradict privacy
aspects. Depending on the selected provenance, di erent
data protection problems have to be considered [
For solving problems generated by the di erent provenance queries, di erent approaches such as generalization and suppression, permutation of attribute values, di erential privacy, and intensional (instead of extensional) answers have been developed. The next step is now to examine them for their compatibility with where-, why - and how provenance.
Generalization of the CHASE. We are currently working
on adapting the CHASE variant presented in [
The CHASE object is either a query Q or a database
instance I. In both cases variables/null values can be replaced
by other variables/null values or constants. The variable
substitution depends on certain conditions shown in [
Both in the calculation of a minimal sub-database and in the uni cation of provenance and evolution, there are still open questions to be answered. First, a concrete BACKCHASE process must be de ned using provenance polynomials and witness bases. Secondly, we have to evaluate the remaining 11 SMOs for their CHASE-inverse functions without and with the use of data provenance. Further, we need to examine the di erent privacy approaches for their compatibility with where-, why -, and how -provenance.
In addition to these speci c questions, we also want to know whether our results are applicable for other use cases than research data management. And of course we hope to further develop the theory of generalized CHASE a little bit.
We presented the current status and plans to extend our work in the eld of provenance management considering evolution and privacy aspects. We de ned the tp-relaxed and result equivalent CHASE-inverse, examined the di erent evaluation and evolution operators for their inverse types without and with using data provenance and started to critically study the correlation between provenance and privacy.
Special thanks go to my PhD supervisor Andreas Heuer and my mentor Goetz Graefe as well as to my colleagues from the database chair of the University of Rostock for their support during my PhD studies so far. Thanks to the Leibniz Institute for Baltic Sea Research Warnemunde for providing their research data and thanks also to my students for the many interesting discussions about privacy, provenance, evolution and the CHASE algorithm. 8.