# Data Protection and Multi-Database Data-Driven Models
## 3 Methodology
Then, we select the most similar one \(r^{\prime}(r_{1})\) to \(r_{1}\). Formally, this corresponds to \(r^{\prime}(r_{1})=\arg\min_{r_{2}\in DB_{2}^{\prime}}d(r_{1},r_{2})\). Distance-based record linkage needs a distance function \(d\)We have used the Euclidean distance, which uses and compares the common attributes in both databases \(DB_{1}^{\prime}\) and \(DB_{2}^{\prime}\). So, \(d(r_{1},r_{2})\) uses only the common attributes of records \(r_{1}\) and \(r_{2}\) (i.e., \(nC\) attributes). It is important to note that for the database integration process, we know how \(DB_{1}^{\prime}\) and \(DB_{2}^{\prime}\) have been generated, and we know which attributes in one database correspond to which attributes in the other database. Therefore, in our case, the database integration process does not need to take into account attribute alignment nor schema matching. More complex situations can be envisioned in the context of data privacy, in line with the above mentioned references and with [4] (Appendix A). We have considered two different types of evaluations for the database integration process. One relates to the result of the integration process itself. Note that both databases, \(DB_{1}^{\prime}\) and \(DB_{2}^{\prime}\), are generated from a single database \(DB\) through its partition and the subsequent process of masking the two parts. Because of this, we can evaluate to what extent the database \(DB^{\prime}=\textit{integrate}(DB_{1}^{\prime},DB_{2}^{\prime})\) is correctly integrated by means of considering whether the record linkage aligns the records \(r_{1}\) and \(r_{2}\) correctly. To do so, we count how many times \(r^{\prime}(r_{1})\) is the correct link in \(DB_{2}^{\prime}\) for \(r_{1}\). As we will discuss in Section 4, the number of correct links drops very quickly with respect to the data protection level. In other words, most of the links we compute using distance-based record linkage are incorrect. The other evaluation is related to the models built from the databases. Even if the databases are not correctly integrated, we can consider whether the model we build is good enough (or similar enough in terms of performance) compared with the model we build using the original data; that is, a comparison between \(m(DB)\) for a record \(x\) (i.e., \(m(DB)(x)\)) and \(y(x)\). As we solely use numerical data, we use for this evaluation the prediction of the models for the records in the testing database (i.e., \(DB_{t}\)). We compute the sum of squared errors of both \(m(DB)\) and \(m(DB^{\prime})\) and compare them. Formally, our evaluation of both models uses the following expression, which is about zero when the error is similar for both types of models. Note that we keep the sign in the difference (no squared numerator, no absolute value in the numerator). Therefore, if the model built from the masked data performs worse than the model built from the original data, the evaluation is positive. This is what we would expect, and what we see in the experiments. Nevertheless, if the performance of the model built from the masked data is better than the model built from the original database, then the evaluation would be negative. We have observed this situation only a few times in our experiments, which is consistent with other results in the literature. For example, it has been observed when masking single databases (see, e.g., the work by [PERSON] and [PERSON] [20] and by [PERSON] and [PERSON] [21]). Because of this, we consider that it is better to define the expression by keeping the sign. That is,  
\[ev(DB_{t},DB^{\prime})=\frac{\sum_{x\in DB_{t}}(m(DB)(x)-y(x))^{2}-\left(m(DB^{ \prime})(x)-y(x)\right)^{2}}{\left|DB_{t}\right|} \tag{1}\]  
If we consider the process as a whole, we also need to describe the masking methods and the algorithms used to compute the machine learning model. We have used several masking methods and several machine learning algorithms, which are described below.