Are Key-Foreign Key Joins Safe to Avoid when Learning High-Capacity Classifiers?

TL;DR

This paper investigates whether avoiding key-foreign key joins impacts the performance of complex classifiers like decision trees, SVMs, and ANNs, finding they are more robust to such avoidance than linear models, contrary to prior assumptions.

Contribution

It extends previous work on safe join avoidance from linear classifiers to high-capacity models, providing extensive empirical evidence of their robustness.

Findings

High-capacity classifiers are more robust to avoiding KFK joins.

Avoiding KFK joins does not significantly degrade accuracy for complex models.

Results challenge previous assumptions based on linear classifier analysis.

Abstract

Machine learning (ML) over relational data is a booming area of the database industry and academia. While several projects aim to build scalable and fast ML systems, little work has addressed the pains of sourcing data and features for ML tasks. Real-world relational databases typically have many tables (often, dozens) and data scientists often struggle to even obtain and join all possible tables that provide features for ML. In this context, Kumar et al. showed recently that key-foreign key dependencies (KFKDs) between tables often lets us avoid such joins without significantly affecting prediction accuracy--an idea they called avoiding joins safely. While initially controversial, this idea has since been used by multiple companies to reduce the burden of data sourcing for ML. But their work applied only to linear classifiers. In this work, we verify if their results hold for three popular complex classifiers: decision trees, SVMs, and ANNs. We conduct an extensive experimental study using both real-world datasets and simulations to analyze the effects of avoiding KFK joins on such models. Our results show that these high-capacity classifiers are surprisingly and counter-intuitively more robust to avoiding KFK joins compared to linear classifiers, refuting an intuition from the prior work's analysis. We explain this behavior intuitively and identify open questions at the intersection of data management and ML theoretical research. All of our code and datasets are available for download from http://cseweb.ucsd.edu/~arunkk/hamlet.

Tables

Table 1. Table 4 : Robustness study for discarding dimension tables on the real-world datasets with a Gini decision tree.

	$\text{Flights}:NoR1:0.8466NoR2:0.8490NoR3:0.8483$
	$NoR1,R2:0.8488NoR1,R3:0.8481NoR2,R3:0.8519$

Full text

1 Introduction

The data management community has long studied how to integrate ML with data systems (e.g., [16, 11, 46]), how to scale ML (e.g., [5, 28]), and how to use database ideas to improve ML tasks (e.g., [22, 23]). However, little work has tackled the pains of sourcing data for ML tasks in the first place, especially, how fundamental data properties affect end-to-end data workflows for ML tasks [4]. In particular, real-world relational databases often have many tables connected by database dependencies such as key-foreign key dependencies (KFKDs) [33]. Thus, given an ML task, data scientists almost always join multiple tables because they like to obtain more features for ML models [25]. But from conversations with data scientists at many enterprise and Web companies, we learned that even this simple process of procuring features by joining tables could be painful in practice because different tables could be “owned” by different teams with different access restrictions. This slows down the ML analytics lifecycle. Furthermore, recent reports of Google’s production ML systems show that features that yield marginal benefits incur high “technical debt” that decreases code mangeability and increases costs [38, 31].

In this context, Kumar et al. [26] showed that one can often omit entire tables by exploiting KFKDs in the database schema. That is, one can ignore a table without even looking at its contents (i.e., “avoid the join”), but crucially, do so without significantly affecting ML accuracy (i.e., “safely”). The basis for this dramatic capability is that a KFK join creates a functional dependency (FD) between a foreign key feature and the foreign features brought in by the join.111While KFKDs are not the same as FDs [39], assuming features have “closed” domains, they behave essentially as FDs in the output of the join [26].

Example (based on [26]). Consider a common classification task: predicting customer churn. The data scientist starts with the main table for training (simplified for exposition): Customers (CustomerID, Churn, Gender, Age, Employer). Churn is the target, while Gender, Age, and Employer are features. So far, this is a standard classification task. She then notices the table Employers (Employer, State, Revenue) in her database with extra features about customers’ employers. Customers.Employer is thus a foreign key feature connecting these tables. She joins the tables to bring in the foreign features (about employers) because she has a hunch that customers employed by rich companies in coastal states might be less likely to churn. She then tries different classifiers, e.g., logistic regression or decision trees.

The analysis in [26] revealed a dichotomy in how safe it is to avoid a join from an accuracy standpoint: in terms of the bias-variance trade-off, avoiding a join is unlikely to increase bias but it might significantly increase variance, since foreign key features often have larger domains than foreign features. In simple terms, avoiding joins might cause extra overfitting. But this extra overfitting subsides with more training examples. In [26], the tuple ratio quantifies this behavior; in our example, it is the ratio of the number of labeled customers to the number of employers. When the tuple ratio is above a certain VC dimension-based threshold, we can safely avoid the join. For simpler classifiers with linear VC dimensions (e.g., logistic regression and Naive Bayes), this threshold was about $20$. Since there were public real-world datasets that satisfied this threshold, this idea of avoiding joins safely could be empirically validated.

While initially controversial, the idea of avoiding joins safely has been adopted by many data scientists, including at Facebook, LogicBlox, and MakeMyTrip [1]. Based on the value of the easy-to-compute tuple ratio, which only needs the foreign table’s cardinality rather than the table itself, the data scientist can decide if they want to avoid the join or procure the extra table. However, the results in [26] had a major caveat–they applied only to linear classifiers. In fact, their VC dimension-based analysis suggested that the tuple ratio thresholds might be too high for high-capacity non-linear classifiers, potentially rendering this idea of avoiding joins safely inapplicable to such classifiers in practice.

In this paper, we perform a comprehensive empirical and simulation study and analysis to verify (or refute) the applicability of the idea of avoiding joins safely to three popular high-capacity classifiers: decision trees, SVMs, and ANNs.

The natural expectation is that these complex models, some with infinite VC dimensions, will likely face larger extra overfitting by avoiding joins compared to linear classifiers. Surprisingly, our results show that their behavior is the exact opposite! We start by rerunning the experiments on the real-world datasets with KFK joins from [26] for these models.222But for simplicity and ease of comparison of all the models, we binarize all classification tasks. Irrespective of whether we use linear classifiers or the higher-capacity classifiers, the same set of joins turn out to be safe to avoid. Furthermore, on the datasets that had joins that were not safe to avoid, the decrease in accuracy caused by avoiding said joins (unsafely) was lower for the higher-capacity classifiers compared to the linear classifiers. In other words, our work refutes an intuition from the VC dimension-based analysis of [26] and shows that these popular high-capacity classifiers are counter-intuitively comparably or more robust to avoiding joins than linear classifiers, not less.

To understand the above surprising behavior in depth, we conduct an in-depth Monte Carlo-style simulation study to “stress test” how safe it is to avoid the join. We use decision trees for the simulation study, since they were the most robust to avoiding joins. We generate data for a two-table KFK join and embed various “true” distributions for the target. This includes a known “worst-case” scenario for avoiding joins with linear classifiers (i.e., the holdout test errors blow up) [26]. We vary different properties of the data and the true distribution: numbers of features in each base table, numbers of training examples, foreign key domain size, noise in the data, and foreign key skew. In very few of these cases does avoiding the join cause the error to rise beyond $1\%$! Indeed, the only scenario where avoiding the join caused significantly higher overfitting was when the tuple ratio was less than $3$; this scenario arose in only $1$ of the $7$ real datasets. These results are in stark constrast to the results for linear classifiers.

Our counter-intuitive results raise new research questions at the intersection of data management and ML theory. In particular, there is a need to formalize the effects of KFKDs/FDs on the behavior of decision trees, SVMs, and ANNs. As a step in this direction, we analyze and intuitively explain the behavior of decision trees and SVMs.

Other open questions include the implications of more general database dependencies such as embedded multi-valued dependencies on the behavior of such models and the implications of all database dependencies for other ML tasks such as regression and clustering. We believe that solving these fundamental questions could lead new analytics systems functionalities that make it easier to use ML for data analytics.

Finally, we observed that foreign key features cause two new practical bottlenecks for data scientists, especially with decision trees. First, the sheer size of their domains makes it hard to interpret and visualize the trees. Second, some foreign key values may not have any training examples even if they are known to be in the domain. We identify and adapt standard heuristics from the literature to resolve these bottlenecks and verify their effectiveness empirically.

Overall, the contributions of this paper are as follows:

• •

To the best of our knowledge, this is the first paper to analyze the effects of avoiding KFK joins on three popular high-capacity classifiers: decision trees, SVMs, and ANNs. We present a comprehensive empirical study that refutes an intuition from prior work and shows that these classifiers are counter-intuitively more robust to avoiding joins than linear classifiers.

• •

We conduct an in-depth simulation study with a decision tree to assess the effects of various data properties on how safe it is to avoid a KFK join.

• •

We present an intuitive analysis to explain the behavior of decision trees and SVMs when joins are avoided. We identify open questions for research at the intersection of data management and ML theory.

• •

We identify two practical bottlenecks with foreign key features and verify the effectiveness of standard heuristics in resolving them.

Outline

Section 2 presents our notation, assumptions, and scope. Section 3 presents results on the real data, while Section 4 presents our simulation study. Section 5 presents our intuitive analysis of the results and identifies open research questions. Section 6 verifies the techniques to make foreign key features more practical. We discuss related prior work in Section 7 and conclude in Section 8.

2 Preliminaries

2.1 Notation

The setting we focus on is the following: the dataset has a set of tables in the star schema with KFK dependencies (KFKDs). Star schemas are ubiquitous in many applications, including retail, insurance, Web security, and recommendation systems [33, 26, 25]. The fact table, which has the target variable, is denoted S. It has the schema $\textbf{S}(\underline{SID},Y,\textbf{X}_{S},FK_{1},\dots,FK_{q})$. A dimension table is denoted $\textbf{R}_{i}$ ($i=1$ to $q$) and it has the schema $\textbf{R}_{i}(\underline{RID_{i}},\textbf{X}_{R_{i}})$. $Y$ is the target variable (class label), $\textbf{X}_{S}$ and $\textbf{X}_{R_{i}}$ are vectors (sequences) of features, $RID_{i}$ is the primary key of $\textbf{R}_{i}$, while $FK_{i}$ is a foreign key feature that refers to $\textbf{R}_{i}$. We call $\textbf{X}_{S}$ home features and $\textbf{X}_{R_{i}}$ foreign features. For ease of exposition, we also treat X as a set of features since the order among features is immaterial in our setting. Let T denote the output of the projected equi-join (key-foreign key, or KFK for short) query that constructs the full training dataset by concatenating the features from all base tables: $\textbf{T}\leftarrow\pi(\textbf{R}\bowtie_{RID=FK}\textbf{S})$. In general, its schema is $\textbf{T}(\underline{SID},Y,\textbf{X}_{S},FK_{1},\dots,FK_{q},\textbf{X}_{R_{1}},\dots,\textbf{X}_{R_{q}})$. In contrast to our setting, traditional ML formulations do not distinguish between home features, foreign keys, and foreign features. The number of tuples in S (resp. R) is denoted $n_{S}$ (resp. $n_{R}$); the number of features in $\textbf{X}_{S}$ (resp. $\textbf{X}_{R}$) is denoted $d_{S}$ (resp. $d_{R}$). Without loss of generality, we assume that the join is not selective, which means $n_{S}$ is also the number of tuples in T. $\mathcal{D}_{FK}$ denotes the domain of $FK$ and by definition, $|\mathcal{D}_{FK}|=n_{R}$. We call $\frac{n_{S}}{n_{R}}$ the tuple ratio. Note that our setting is different from the statistical relational learning (SRL) setting, which deals with joins that violate the IID assumption and duplicate labeled examples from S [13]. KFK joins do not cause such duplication and thus, regular IID models are typically used in this setting.

2.2 Assumptions and Scope

For the sake of tractability, in this paper, we adopt some assumptions from [26]. In particular, we assume the features are categorical. Numeric features can be discretized using standard techniques such as binning [29]. We also focus on binary classification but our ideas can be easily applied to multi-class targets as well. We assume that the foreign key features ($FK_{i}$) are not (primary) keys in the fact table, e.g., Employer does not uniquely identify a customer.333Primary keys in the fact table are not generalizable features, unlike foreign keys. Finally, we also do not study the “cold start” issue because it is orthogonal to the focus of this paper [36]. Thus, all features have known finite domains, possibly including a special “Others” placeholder to temporarily handle hitherto unseen values. In our example, this means that both Employer and Gender have known finite domains. In general, $FK_{i}$ can take values only from the given set of $\textbf{R}_{i}.RID_{i}$ values (new $FK_{i}$ values are mapped to “Others”). Since ML models are rebuilt periodically in practice, new information can then be added to expand feature domains. We emphasize that our goal is not to create new ML or feature selection algorithms, nor is to compare which algorithms yield the best accuracy or runtime. Our goal is to expose and analyze how KFKDs/FDs enable us to dramatically discard foreign features a priori when learning some popular high-capacity classifiers.

3 Empirical Study with Real Data

We now present our detailed empirical study using real-world datasets on 10 classifiers, including 7 high-capacity classifiers (CART decision tree with gini, information gain, and gain ratio; SVM with RBF and quadratic kernels; multi-layer perceptron ANN; the “braindead” 1-nearest neighbor), and 3 linear classifiers (Naive Bayes with backward selection, logistic regression with L1 regularization, and linear SVM). We also conducted experiments with a few other feature selection techniques for the linear classifiers: Naive Bayes with forward selection and filter methods, as well as logistic regression L2 regularization Since these additional linear classifiers did not provide any new insights, we omit them due to space constraints.

3.1 Datasets

We take the seven real datasets from [26]; these are originally from Kaggle, GroupLens, openflights.org, mtg.upf.edu/node/1671, and last.fm. Two datasets have binary targets (Flights and Expedia); the others have multi-class ordinal targets. For the sake of simplicity, we binarize all targets for this paper by grouping ordinal targets into lower and upper halves (this change does not affect our overall conclusions). The dataset statistics are provided in Table 1. We briefly describe the task for each dataset and explain what the foreign features are. More details about their schemas, including the list of all features are already in the public domain (listed in [26]). All of our datasets, scripts, and code are available for download on our project webpage444http://cseweb.ucsd.edu/~arunkk/hamlet to make reproducibility easier.

Walmart: predict if department-wise sales will be high using past sales (fact table) joined with stores and weather/economic indicators (two dimension tables).

Flights: predict if a route is codeshared by using other routes (fact table) joined with airlines, source, and destination airports (three dimension tables).

Yelp: predict if a business will be rated highly using past ratings (fact table) joined with users and businesses (two dimension tables).

MovieLens: predict if a movie will be rated highly using past ratings (fact table) joined with users and movies (two dimension tables).

Expedia: predict if a hotel will be ranked highly using past search listings (fact table) joined with hotels and search events (two dimension tables but one foreign key, viz., the search ID, has an “open” domain, i.e., past values will not be seen in the future, which makes it unusable as a feature).

LastFM: predict if a song will be played often using past play level information (fact table) joined with users and artists (two dimension tables).

Books: predict if a book will be rated highly using past ratings (fact table) joined with readers and books (two dimension tables).

3.2 Methodology

Each dataset is pre-split 50%:25%:25% for training, validation (during feature selection and hyper-parameter tuning), and holdout testing. We retain the splits as is. We compare two approaches: JoinAll, which joins all base tables to provide all features to the classifier (the current widespread practice), and NoJoin, which avoids all foreign features a priori (the approach we study). We compare these two approaches for all the 10 classifiers mentioned earlier. For additional insights, we also include a third approach for the decision trees: NoFK, which is essentially the same as JoinAll but with all foreign key features dropped a priori. We used the popular R packages “rpart” for the decision trees555Except for the gain ratio case for which we used the “CORElearn” package in R. and “e1071” for the SVMs. For the ANNs, we used the popular Python library Keras on top of TensorFlow. For Naive Bayes, we used the code from [26], while for logistic regression with L1 regularization, we used the popular R package “glmnet.” We use the validation set for hyper-parameter tuning using a standard grid search for each classifier with the grids described in detail below. Note that for Naive Bayes, there is no hyper-parameter tuning.

Decision Trees: There are two hyper-parameters to tune: minsplit and cp. minsplit is the number of observations that must exist in a node for a split to be attempted. Any split that does not improve the fit by a factor of cp is pruned off. The grid is set as follows: minsplit $\in\{1,10,100,10^{3}\}$ and cp $\in\{10^{-4},10^{-3},0.01,0.1,0\}$

RBF-SVM: There are two hyper-parameters to tune: C and $\gamma$. C controls the cost of misclassification. $\gamma>0$ controls the bandwidth in the Gaussian kernel (given two data points $x_{i}$ and $x_{j}$): $k(x_{i},x_{j})=\exp(-\gamma\cdot\lVert{x_{i}-x_{j}}\rVert^{2})$. The grid is set as follows: C $\in\{10^{-1},1,10,100,10^{3}\}$ and $\gamma\in\{10^{-4},10^{-3},0.01,0.1,1,10\}$.666On Movies and Expedia alone, we perform an extra fine tuning step with $\gamma\in\{2^{-7},2^{-6},2^{-5},2^{-4},2^{-3},2^{-2},2^{-1},1,2,2^{2},2^{3}\}$ to improve accuracy.

Quadratic-SVM: We tune the same hyper-parameters C and $\gamma$ for the polynomial kernel of degree 2: $k(x_{i},x_{j})=(-\gamma\ x_{i}^{T}\cdot x_{j})^{degree}$. We use the same grid as RBF-SVM.

Linear-SVM: We tune the C hyper-parameter for the linear kernel: $k(x_{i},x_{j})=x_{i}^{T}\cdot x_{j}$, C $\in\{10^{-1},1,10,100,10^{3}\}$.

ANN: The multi-layer perceptron architecture comprises of 2 hidden units with 256 and 64 neurons respectively. Rectified linear unit (ReLU) is used as the activation function. In order to allow penalties on layer parameters, we do $L_{2}$ regularization, with the regularization parameter tuned using the following grid axis: $\{10^{-4},10^{-3},10^{-2}\}$. We choose the popular Adam stochastic gradient optimization algorithm [20] with the learning rate tuned using the following grid axis: $\{10^{-3},10^{-2},10^{-1}\}$. The other hyper-parameters of the Adam algorithm used the default values.

Logistic Regression: The glmnet package performs automatic hyper-parameter tuning for the L1 regularizer, as well as the optimization algorithm. However, it has three parameters to specify a desired convergence threshold and a limit on the execution time: nlambda, which we set to 100, maxit, which we set to 10000, and thresh, which we set to 0.001.

Tables 2 and 3 present the holdout test accuracy results for all the models on all the datasets.

3.3 Results

Accuracy

Our first and most important observation is that for almost all the datasets (Yelp being the exception) and for all three split criteria, the accuracy of the decision tree is comparable (a gap of within 1%) between JoinAll and NoJoin.777Except for gain ratio on LastFM, where NoJoin is actually significantly more accurate than JoinAll! The trend is virtually the same for the RBF-SVM and ANN as well. We also observe that the trend is virtually the same for the linear models as well! Thus, regardless of whether our classifier is linear or higher capacity, the relative behavior of NoJoin vis-a-vis JoinAll is virtually the same. These results represent our key counter-intuitive finding: joins are no less safe to avoid with the high-capacity classifiers than with the linear classifiers. The absolute accuracy of the high-capacity classifiers is often significantly higher than the linear classifiers, which is as expected but is also orthogonal and irrelevant to this paper’s focus. Interestingly, on the Yelp dataset, in which both joins are known to be not safe to avoid with the linear classifiers [26], NoJoin correctly sees a large reduction in accuracy from JoinAll–about $0.03$. However, the drop in accuracy is smaller for the high-capacity classifiers, e.g., the RBF-SVM, Gini decision tree, and ANN all see a drop of only about $0.01$! This suggests that these high-capacity classifiers are sometimes counter-intuitively more robust than linear classifiers to avoiding joins.

As for NoFK, it often has much lower accuracy than both JoinAll and NoJoin on all three forms of decision trees. For example, on Flights, the drop is about $0.05$. This reaffirms the importance of foreign key features; as such, it is known that dropping foreign key features could cause the bias to shoot up with linear classifiers [26]. A similar scenario arises for the high-capacity classifiers too. Interestingly, in some cases (e.g., Gini on Flights and gain ratio on Books), NoJoin has marginally higher accuracy than JoinAll.

To understand the above results more deeply, we conduct a “robustness” experiment by discarding dimension tables one at a time instead of all together. Table 4 presents this experiment’s results for the Gini decision tree. Discarding each dimension table one at a time (and also two at a time in the case of Flights) did not differ much from NoJoin, except for Yelp. On Yelp, the accuracy drops only when $\textbf{R}_{2}$ (users table) is dropped. From Table 1, we find that the tuple ratio for $\textbf{R}_{2}$ in Yelp is extremely low: $2.5$. That is, there are not enough training examples per unique foreign key value for $\textbf{R}_{2}$ in Yelp.888Interestingly, the tuple ratio is similarly low ($2.6$) for $\textbf{R}_{2}$ in Books but the error of NoJoin is not much higher. So, the tuple ratio seems to be a conservative indicator: it can tell if an error is likely to rise but the error may not actually rise in some cases. Almost every other dimension table can safely be discarded. A similar situation arises for the ANN on Yelp and for the RBF-SVM on Yelp, LastFM, and Books.

Overall, out of $14$ dimension tables across the $7$ datasets that can potentially be discarded, we were able to safely discard $13$ for the decision tree and ANN, with the tuple ratio threshold being only about $3$x. For the RBF-SVM, we were able to discard $11$ dimension tables, with the tuple ratio threshold being about $6$x. These results are surprising given the more conservative behavior predicted even for the linear classifiers in [26]. For both Naive Bayes and logistic regression, only $7$ of the dimension tables were deemed “safe to avoid” with the tuple ratio threshold being about $20$x. But of course, even tables that were predicted not safe to avoid could have been avoided without lowering accuracy significantly. Overall, we see that the decision trees and ANN need six times fewer training examples and the RBF-SVM needs three times fewer training examples than linear classifiers to avoid extra overfitting when avoiding the joins. These results are counter-intuitive because conventional wisdom holds that such complex models need more (not fewer) training examples to avoid extra overfitting.

For an interesting comparison that we will use later on in Section 5, we also present the results for 1-NN (from package “RWeka” in R; it has no hyper-parameters). Surprisingly, as Table 2 shows, the accuracy of even this braindead classifiers is sometimes comparable to decision trees and RBF-SVMs! More importantly, on most of the datasets, 1-NN with NoJoin has a higher accuracy than with JoinAll. We discuss this behavior further in Section 5.

Runtimes

A key benefit of avoiding KFK joins safely is that ML runtimes (including feature selection) could be significantly lowered for the linear classifiers [26]. We now verify if this is the case for the high-capacity classifiers as well. We compare the runtimes of the end-to-end execution of the ML training (including the grid search) and testing for all models on all datasets. Due to space constraints, we only report Gini metric for the decision tree and the RBF kernel for the SVM; these were also the most robust to avoiding joins. All experiments (except for ANN) were run on CloudLab, which offers free access to physical compute nodes for research [35]. We use a custom OpenStack profile running Ubuntu 14.10 with 40 Intel Xeon cores and 160GB of RAM. The ANN experiments were run on a commodity laptop with Nvidia GeForce GTX 1050 GPU, 16GB RAM and running Windows 10. The version of R used is 3.2.2 and the version of TensorFlow used is 1.1.0. Figure 1 presents the results.

For the high-capacity classifiers, we saw an average speedup of about 2x for NoJoin over JoinAll. The highest speedup was on the Movies: 3.6x for the decision tree and 6.2x for the RBF-SVM. As for the ANN, LastFM reported the largest speedup of 2.5x. The speedup for the linear classifiers were more significant. For example, on Movies, we saw a speedup of 707x for Naive Bayes, while on LastFM, we saw a speedup of 20x for logistic regression. Thus, these results corroborate the orders of magnitude speedup reported in [26] for Naive Bayes with backward selection.

4 In-depth Simulation Study

We now dive deeper into the behavior of the decision tree classifier using a simulation study in which we vary the properties of the underlying “true” data distribution. We focus on a two-table KFK join for simplicity. We sample datasets of different dimensions. We use the decision tree for this study because it exhibited the maximum robustness to avoiding KFK joins on the real-world datasets. Our simulation study is designed to comprehensively “stress test” this robustness. Note that our simulation methodology is not tied to decision trees; it is generic enough to be applicable to classifier because we only use standard generic notions of error and net variance as defined in [26].

Setup and Data Synthesis

There is one dimension table R ($q=1$), and all of $\textbf{X}_{S}$, $\textbf{X}_{R}$, and $Y$ are boolean (domain size $2$). We control the “true” distribution $P(Y,\textbf{X})$ and sample labeled examples in an IID manner from it. We study two different scenarios for what features are used to (probabilistically) determine $Y$: OneXr and XSXR. These scenarios represent opposite extremes for how likely the (test) error is likely to shoot up when $\textbf{X}_{R}$ is discarded and $FK$ is used as a representative [26]. In OneXr, a lone feature $X_{r}\in\textbf{X}_{R}$ determines $Y$; the rest of $\textbf{X}_{R}$ and $\textbf{X}_{S}$ are random noise (but note that $FK$ will not be noise because it functionally determines $X_{r}$). In XSXR, all features in $\textbf{X}_{S}$ and $\textbf{X}_{R}$ determine $Y$. Intuitively, OneXr is the worst-case scenario for discarding $\textbf{X}_{R}$ because $X_{r}$ is typically far more succinct than $FK$, which we expect to translate to less possibility of overfitting with NoJoin. Note that if we use $FK$ directly in $P$, $\textbf{X}_{R}$ can be more easily discarded because $FK$ conveys more information anyway; so, we skip this scenario.

The following data parameters are varied one at a time: number of training examples ($n_{S}$), size of foreign key domain ($|\mathcal{D}_{FK}|$ $=n_{R}$), number of features in $\textbf{X}_{R}$ ($d_{R}$), and number of features in $\textbf{X}_{S}$ ($d_{S}$). We also sample $\frac{n_{S}}{4}$ examples each for the validation set (for hyper-parameter tuning) and the holdout test set (final indicator of error). We generate $100$ different training datasets and measure the average test error and average net variance (as defined in [9]) based on the different models obtained from these $100$ runs.

4.1 Scenario OneXr

The “true” distribution is set as follows: $P(Y=0|X_{r}=0)=P(Y=1|X_{r}=1)=p$, where $p$ is called the probability skew parameter that controls the Bayes error (noise). The exact procedure for sampling examples is as follows: (1) Construct tuples of R by sampling $\textbf{X}_{R}$ values randomly (each feature value is an independent coin toss). (2) Construct the tuples of S by sampling $\textbf{X}_{S}$ values randomly (independent coin tosses). (3) Assign $FK$ values to S tuples uniformly randomly from $\mathcal{D}_{FK}$. (4) Assign $Y$ values to S tuples by looking up into their respective $X_{r}$ value (implicit join on $FK=RID$) and sampling from the above conditional distribution.

We compare the same three approaches: JoinAll, which uses $\textbf{X}\equiv[\textbf{X}_{S},FK,\textbf{X}_{R}]$, NoJoin, which uses $\textbf{X}\equiv[\textbf{X}_{S},FK]$ (i.e., discard $\textbf{X}_{R}$), and NoFK, which uses $\textbf{X}\equiv[\textbf{X}_{S},\textbf{X}_{R}]$ (i.e., discard $FK$). We include NoFK for a lower bound on errors, since we know $FK$ does not determine determine $Y$ (although indirectly it does).999In general though, NoFK could have much higher errors if $FK$ is part of the true distribution; indeed, NoFK had much higher errors on many real datasets (Table 2). Figure 2 presents the results for the (holdout) test errors for varying each relevant data and distribution parameter, one at a time.

Interestingly, regardless of the parameter being varied, in almost all cases, NoJoin and JoinAll have virtually identical errors (close to the Bayes error)! From inspecting the actual decision trees learned in these two settings, we found that in almost all cases, $FK$ was used heavily for partitioning and seldom was a feature from $\textbf{X}_{R}$, including $X_{r}$, used. This suggests that $FK$ can indeed act as a good representative of $\textbf{X}_{R}$ even in this extreme sccenario. In contrast to these results, [26] reported that for linear models, the errors of NoJoin shot up compared to JoinAll (a gap of nearly $0.05$) as the tuple ratio starts falling below $20$. In stark contrast, as Figure 2(B) shows, even for a tuple ratio of just $3$, NoJoin and JoinAll have similar errors with the decision tree. This corroborates the results seen for the decision tree on the real datasets (Table 2). When $n_{S}$ becomes very low or when $|\mathcal{D}_{FK}|$ becomes very high, the absolute errors of JoinAll and NoJoin increase compared to NoFK. This suggests that when the tuple ratio is very low, NoFK is perhaps worth trying too. This is similar to the behavior seen on Yelp. Overall, NoJoin exhibits similar behavior as the current practice of JoinAll.

Finally, we also ran this scenario for the RBF-SVM (and 1-NN) and found the trends to be similar, except for the magnitude of the tuple ratio at which NoJoin deviates from JoinAll. Figure 3 presents the results for the experiment in which we increase $|\mathcal{D}_{FK}|=n_{R}$, while fixing everything else, similar to Figure 2(B) for the decision tree. We see that for the RBF-SVM, the error deviation starts when the tuple ratio ($n_{S}/n_{R}$) falls below roughly $6$x. This corroborates its behavior on the real datasets (Table 3). The 1-NN, as expected, is far less stable and the deviation starts even at a tuple ratio of $100$x, i.e., $n_{R}=10$). As Figure 4 confirms, the deviation in accuracy for the RBF-SVM arises due to the net variance, which helps quantify the extra overfitting. This is akin to the extra overfitting reported in [26] using the plots of the net variance. Intriguingly, the 1-NN sees its net variance exhibit non-monotonic behavior; this is likely an artifact of its unstable behavior, since fewer and fewer training examples will match on $FK$ as $n_{R}$ keeps rising.

Foreign Key Skew

The regular OneXr scenario samples $FK$ uniformly randomly from $\mathcal{D}_{FK}$ (step 3 in the procedure). We now ask if a skew in the distribution of $FK$ values could widen the gap between JoinAll and NoJoin. To study this scenario, we modify the data generation procedure slightly: in step 3, we sample $FK$ values with a Zipfian skew or a needle-and-thread skew. The Zipfian skew simply uses a Zipfian distribution for $P(FK)$ controlled by the Zipfian skew parameter. The needle-and-thread skew allocates a large probability mass (parameter $p$) to a single $FK$ value (the “needle”) and uniformly distributes the rest of the probability mass to all other $FK$ values (the “thread”). For the linear model case, [26] reported that as the skew parameters increased, the gap widened. Figure 5 presents the results for the decision tree.

Surprisingly, the gap between NoJoin and JoinAll does not widen significantly no matter how much skew introduced in either the Zipfian or the needle-and-thread case! This result further affirms the remarkable robustness of the decision tree when discarding foreign features. As expected, NoFK is better when $n_{S}$ is low, while overall, NoJoin is quite similar to JoinAll.

4.2 Scenario XSXR

Unlike the OneXr scenario, we now create a true distribution that maps $\textbf{X}\equiv[\textbf{X}_{S},\textbf{X}_{R}]$ to $Y$ without any Bayes error (noise). The exact procedure for sampling examples is as follows: (1) Construct a true probability table (TPT) with entries for all possible values of $[\textbf{X}_{S},\textbf{X}_{R}]$ and assign a random probability to each entry such that the total probability is $1$. (2) For each entry in the TPT, pick a $Y$ value randomly and append the TPT entry; this ensures $H(Y|\textbf{X})=0$. (3) Marginalize the TPT to obtain $P(\textbf{X}_{R})$ and from it, sample $n_{R}=\mathcal{D}_{FK}$ tuples for R along with an associated sequential $RID$ value. (4) In the original TPT, push the probability of each entry to [math] if its $\textbf{X}_{R}$ values did not get picked for R in step 3. (5) Renormalize the TPT so that the total probability is $1$ and sample $n_{S}$ examples ($Y$ values do not change) and construct S. (6) For each tuple in S, pick its $FK$ value uniformly randomly from the subset of $RID$ values that map to its $\textbf{X}_{R}$ value in R (an implicit join).

We compare three settings: JoinAll, NoJoin, and NoFK, with NoFK meant to be a lower bound on the errors possible (because it uses the knowledge that $FK$ is not directly a part of the true distribution). Once again, our hypothesis is that JoinAll and NoJoin will exhibit similar errors in most cases, while NoFK will perform better when the tuple ratio is low. Figure 6 presents the results.

Once again, we see that NoJoin and JoinAll exhibit similar errors in almost all cases, with the largest gap being $0.017$ in Figure 6(C)). Interestingly, even when the tuple ratio is close to $1$, the gap between NoJoin and JoinAll does not widen much. Figure 6(B)) shows that as $|\mathcal{D}_{FK}|$ increases, NoFK remains at low overall errors, unlike both JoinAll and NoJoin. But as we increase $d_{R}$ or $d_{S}$, the gap between JoinAll/NoJoin and NoFK narrows because even NoFK does not have enough training examples. Of course, all gaps virtually disappear as the number of training examples increases, as shown by Figure 6(A). Overall, NoJoin exhibits similar behavior as the current practice of JoinAll even in this scenario.

4.3 Scenario RepOneXr

We now present results for a new simulation scenario in which the true distribution is precisely captured using a lone feature $X_{r}\in\textbf{X}_{R}$. We sample examples similarly as per the procedure mentioned earlier for OneXr, except that the tuples of R will now be constructed by replicating the value of $X_{r}$ sampled for a tuple to create all the other features in $X_{R}$. That is, $X_{R}$ of an example is just the same value repeated $d_{R}$ times. Note that the FD $\textit{FK}\rightarrow X_{R}$ implies there are at least as many unique $FK$ values as $\textbf{X}_{R}$ values. Thus, by increasing the number of $FK$ values relative to $X_{R}$ values, we hope to increase the chance of the model getting “confused” with NoJoin. Our goal is to see if this widens the gap between JoinAll and NoJoin.

Figure 7 presents the results for the two experiments on decision trees where (A) has a high tuple ratio of 25x and (B) has a low tuple ratio of 5x. We see that once again, JoinAll and NoJoin exhibit similar errors in both the cases. We also run this simulation scenario for both the RBF-SVM and 1-NN as well; the results are shown in Figure 8) and Figure 9 respectively. We see that the trends are similar to the decision tree. For the RBF-SVM, the error of NoJoin deviates at a tuple ratio of about 5x. As for 1-NN, as expected, it is much less stable and the deviation happens even at a higher tuple ratio of 25x. At low tuple ratios, as expected, the absolute errors of JoinAll and NoJoin increase compared to NoFK for all three models.

5 Analysis and Open Questions

5.1 Explaining the Results

We now intuitively explain the surprising behavior of decision trees and RBF-SVM with NoJoin vis-a-vis JoinAll. We first ask: Does NoJoin compromise the “generalization error”? The generalization error is the difference of the test and train errors. Tables 2 and 3 already provided the test accuracy. Tables 5 and 6 now provide the train accuracy. Clearly, JoinAll vs NoJoin are almost indistinguishable for the decision tree! The only exception is Yelp, which we already noted. Note that the absolute generalization error is often high, which is expected for decision trees [17]. For example, the train accuracy is nearly $100\%$ on Flights, while the test accuracy on it is only $85\%$. But the absolute generalization error is orthogonal to our focus; we only note that NoJoin does not increase this difference significantly. In other words, discarding foreign features did not significantly affect the generalization error of the decision tree! The generalization errors of the RBF-SVM also exhibit a similar trend.

Returning to 1-NN, Table 2 showed that it has similar accuracy as RBF-SVM on some datasets. We now explain why that comparison is useful: the RBF-SVM essentially behaves similar to the 1-NN in some cases when $FK$ is used (both JoinAll and NoJoin)! But this does not necessarily hurt its test accuracy. Note that $FK$ is represented using the standard one-hot encoding for RBF-SVM and 1-NN. So, $FK$ can contribute to a maximum distance of $2$ in a (squared) Euclidean distance between two examples $x_{i}$ and $x_{j}$. But since $\textbf{X}_{R}$ is functionally dependent on $FK$, if $x_{i}.FK=x_{j}.FK$, then $x_{i}.\textbf{X}_{R}=x_{j}.\textbf{X}_{R}$. So, if $x_{i}.FK=x_{j}.FK$, the only contributor to the distance is $\textbf{X}_{S}$. But in many of the datasets, since $\textbf{X}_{S}$ is empty ($d_{S}=0$), $FK$ becomes the sole determiner of the distances for NoJoin. This is akin to sheer memorization of a feature’s large domain. Since we operate on features with finite domains, test examples will also have $FK$ from that domain. Thus, memorizing $FK$ does not hurt generalization. While this seems similar to how deep neural networks excel at sheer memorization but still offer good test accuracy [45], the models in our setting are not necessarily memorizing all features – only the foreign keys. A similar explanation holds for the decision tree. If $\textbf{X}_{S}$ is not empty, then it will likely play a major role in the distance computations and our setting becomes more similar to the traditional single-table learning setting (no FDs).

We now explain why NoJoin might deviate from JoinAll when the tuple ratio is very low for the RBF-SVM. Even if $x_{i}.FK\neq x_{j}.FK$, it is possible that $x_{i}.\textbf{X}_{R}=x_{j}.\textbf{X}_{R}$. Suppose the “true” distribution is captured by $\textbf{X}_{R}$, e.g., as in OneXr. If the tuple ratio is very low, there are many $FK$ values but the number of $\textbf{X}_{R}$ values might still be small. In this case, given $x_{i}$, RBF-SVM (and 1-NN) is more likely to pick an $x_{j}$ that minimizes the distances on $\textbf{X}_{R}$, thus potentially yielding lower errors. But since NoJoin does not have access to $\textbf{X}_{R}$, it can only use $\textbf{X}_{S}$ and $FK$. So, if $\textbf{X}_{S}$ is mostly noise, the possibility of the model getting “confused” increases. To see why, if there are very few other examples that share $x_{i}.FK$, then matching on $\textbf{X}_{S}$ might become more important. Thus, a non-match on $FK$ becomes more likely, which means a non-match on the implicit $\textbf{X}_{R}$ becomes more likely, which in turns makes higher errors more likely. But if there are more examples that share $x_{i}.FK$, then a match on $FK$ is more likely. Thus, as the tuple ratio increases, the gap between NoJoin and JoinAll disappears, as Figure 3 showed. Internally, the RBF-SVM seems more robust to such chance mismatches by learning a higher-level relationship between all features compared to the stark 1-NN. Thus, the RBF-SVM is more robust to discarding foreign features at lower tuples ratios than 1-NN.

Finally, focusing on the decision tree, its internal feature selection and partitioning seems to make it quite robust to noise from any other features. Suppose again the “true” distribution is similar to OneXr. Since $FK$ already encodes all information that $\textbf{X}_{R}$ provides [26], the tree almost always uses $FK$ in its partitioning, often multiple times. This is not necessarily “bad” for test accuracy because test examples share the $FK$ domain. But when the tuple ratio becomes extremely low, the chance of $\textbf{X}_{S}$ “confusing” the tree over the information $FK$ provides goes up, potentially leading to higher errors with NoJoin. JoinAll escapes such a confusion thanks to $\textbf{X}_{R}$. If $\textbf{X}_{S}$ is empty, then $FK$ will almost surely be used for partitioning. But with very few training examples per $FK$ value, the chance of sending it to a wrong partition goes up, leading to higher errors. It turns out that even with just $3$ or $4$ training examples per $FK$ value, such issues get mitigated. Thus, the decision tree seems even more robust to discarding foreign features.

5.2 Open Research Questions

While our intuitive explanations capture the fine-grained behavior of the decision tree and RBF-SVM with NoJoin vis-a-vis JoinAll, there are many open questions for more research. Is it possible to quantify the probability of wrong partitioning with a decision tree as a function of the data properties? Is it possible to quantify the probability of mismatched examples being picked by the RBF-SVM? Why does the theory of VC-dimensions predict the opposite of the observed behavior with these models? How do we quantify their generalizability if memorization is allowable and what forms of memorization are allowed? Answering these questions would provide deeper insights into the effects of KFKDs/FDs on the generalizability and accuracy of such classifiers. It could also yield more formal mechanisms to characterize when discarding foreign features is feasible beyond just looking at tuple ratios.

From a data management perspective, there are database dependencies more general than FDs: embedded multi-valued dependencies (EMVDs) and join dependencies (JDs) [39]. How does the presence of such database dependencies among features affect the behavior of ML models? There are also conditional FDs, which satisfy FD-like constraints among subsets of the dataset [39]. How do such properties of the data distribution affect ML behavior? Finally, the axioms of FDs imply that foreign features can be divided into arbitrary subsets before being avoided, which opens up a new trade-off space between fully avoiding a foreign table and fully using it. How do we quantify this trade-off and exploit it? Answering these questions could open up new connections between data management and ML theory and potentially lead to new functionalities for ML systems.

6 Making FK Features Practical

We now discuss two key practical issues caused by the large domains of foreign key features and verify how standard approaches can be adapted to resolve them. In contrast to prior work on handling regular large-domain features [7], foreign key features are distinct in that they have coarser-grained side information available in the form of foreign features. This suggests an alternative way to exploiting such features, if possible, rather than always joining them in.

6.1 Foreign Key Domain Compression

While foreign keys often act as good representatives of foreign features for accuracy, they pose a practical bottleneck for interpretability due to their domain sizes. For example, it is hard to visualize a decision tree that uses a foreign key feature with 1000s of values. In order to make foreign key features more practical, we consider a simple approach that is standard in the ML literature: lossy domain compression to a (much) smaller user-defined domain size. Essentially, given a foreign key feature $FK$ with domain $\mathcal{D}_{FK}$ recoded as $[m]$ (where $m=|\mathcal{D}_{FK}|$) and a user-specified positive integer “budget” $l\ll m$, we want a mapping $f:[m]\rightarrow[l]$.

A standard unsupervised method to construct $f$ is the Random hashing trick [41], i.e., randomly hash from $[m]$ to $[l]$. We also try a simple supervised method we call the Sort-based method to preserve more of the information contained in $FK$ about $Y$. Sort-based is a greedy approach: sort $\mathcal{D}_{FK}$ based on $H(Y|FK=z),~{}z\in\mathcal{D}_{FK}$, compute the differences among adjacent pairs of values, and pick the boundaries corresponding to the top $l-1$ differences (ties broken randomly). This gives us an $l$-partition of $\mathcal{D}_{FK}$. The intuition is that by grouping $FK$ values that have comparable conditional entropy, $H(Y|f(FK))$ is unlikely to be much higher than $H(Y|FK)$. Note that the lower $H(Y|FK)$ is, the more informative $FK$ is to predict $Y$. We leave more sophisticated approaches to future work.

We now empirically compare the above two heuristics using two of the real datasets for the Gini decision tree with NoJoin. Our methodology is as follows. We retain the 50:25:25 train-validate-test split from before. We use the training split to construct $f$ and then compress $FK$ for the whole dataset. We then use the validation set as before to tune the hyper-parameters and measure the holdout test error. For random hashing, we report the average across five runs. Figure 10 presents the results.

On Yelp, both Random and Sort-based have comparable accuracy although Sort-based is marginally higher, especially as the budget $l$ increases. But on Flights, we see a larger gap for some values of $l$ although the gap narrows as the $l$ increases. The test accuracy with the whole $\mathcal{D}_{FK}$ ($l=m$) for NoJoin on Flights was $0.8516$ (see Table 2). So, it is surprising the test accuracy is about $0.83$ with such high compression. Even more surprisingly, the test accuracy with the whole $\mathcal{D}_{FK}$ ($l=m$) for NoJoin on Yelp was $0.8204$ and for NoFK was $0.8644$. So, with domain compression, we see significantly higher accuracy for NoJoin, even higher than NoFK. Overall, these results suggest that $FK$ domain compression is a promising way to resolve the large-domain issue rather than simply dropping $FK$.

6.2 Foreign Key Smoothing

Another issue caused by large $|\mathcal{D}_{FK}|$ is that some $FK$ values might not arise in the train set but arise in the test set or during deployment. This is not a cold start issue – the $FK$ values are all still from the fully known $\mathcal{D}_{FK}$. This issue arises because there are not enough labeled examples to cover all of $\mathcal{D}_{FK}$ during training. Typically, this issue is handled using some form of smoothing, e.g., Laplacian smoothing for Naive Bayes by adding a pseudocount of $1$ to all frequency counts [29]. While similar smoothing techniques have been studied for probability estimation using decision trees [32], to the best of our knowledge, this issue has not been handled in general for classification using decision trees. In fact, popular decision tree implementations in R simply crash if a value of $FK$ not seen during training arises during testing! Note that SVMs (or any other classifier operating on numeric feature spaces) do not face this issue due to the one-hot encoding of $FK$.

We consider a simple approach to mitigate this issue: smooth by reassigning an $FK$ value not seen during training to an $FK$ value that was seen. There are various ways to reassign; for simplicity sake, we only study two lightweight unsupervised methods. We leave more sophisticated approaches to future work. We consider both random reassignment and alternative approach that uses the foreign features ($\textbf{X}_{R}$) to decide the reassignment. Note that the latter is only feasible in cases where the dimension tables are available and not discarded. Since R provides auxiliary descriptive information about $FK$, we can utilize it for smoothing even if not for learning directly over them. Our algorithm is simple: given a test example with $FK$ not seen during training, obtain an $FK$ seen during training whose corresponding $\textbf{X}_{R}$ feature vector has the minimum $l_{0}$ distance with the test example’s $\textbf{X}_{R}$ (ties broken randomly). The $l_{0}$ distance is simply the count of the number of pairwise mismatches of the respective features in the two $\textbf{X}_{R}$ feature vectors.

The intuition for $\textbf{X}_{R}$-based smoothing is that if $\textbf{X}_{R}$ is part of the “true” distribution, it may yield higher accuracy than random reassignment. But if $\textbf{X}_{R}$ is just noise, this becomes essentially random reassignment. To validate our claim, we use the OneXr simulation scenario. Recall that a feature $X_{r}\in\textbf{X}_{R}$ determines the target (with some Bayes noise as before). We introduce a parameter $\gamma$ that is the ratio of the number of $FK$ values not seen during training to $|\mathcal{D}_{FK}|$. If $\gamma=0$, no smoothing is needed; as $\gamma$ increases, more smoothing is needed. Figure 11 presents the results.

The plots confirm our intuition: the $\textbf{X}_{R}$-based smoothing yields much lower test errors for both NoJoin and JoinAll–in fact, errors comparable to NoFK and the Bayes error–for lower values of $\gamma$ ($<0.5$). But as $\gamma$ gets closer to $1$, the errors of $\textbf{X}_{R}$-based smoothing also increase but not as much as random hashing. Overall, these results suggest that even if foreign features are available, rather for using them directly for learning the model, we could use them as side information for smoothing $FK$ features. Overall, these results suggest that it is possible to get “the best of both worlds”: the runtime and usability gains of NoJoin (as against JoinAll, which unnecessarily also learns over the foreign features) along with exploiting the extra information provided by foreign features (if they are available) for smoothing foreign key features.

7 Related Work

Database Dependencies and ML

The scenario of learning over joins of multiple tables without materializing the output of the join was studied in [25, 37, 34, 24], but their goal was primarily to reduce runtimes of some ML techniques without affecting accuracy. It was also studied in [43] but their focus was on devising a new ML algorithm. In contrast, our work focuses on the more fundamental question of whether KFK joins can be avoided safely for existing popular ML algorithms. We first demonstrated the feasibility of avoiding joins safely in [26] for linear models. In this work, we revisit that idea for higher capacity models and find that they are counter-intuitively more robust than linear models to avoiding joins, not less as the VC dimension-based analysis in [26] suggested. We also empirically verify mechanisms to make foreign key features more practical. Embedded multi-valued dependencies (EMVDs) are database dependencies that are more general than functional dependencies [2]. The implication of EMVDs for probabilistic conditional independence in Bayesian networks was originally described by [30] and further explored by [42]. However, their use of EMVDs still requires computations over all features in the data instance. In contrast, avoiding joins safely omits entire sets of features for complex ML models without performing any computations on the foreign features. There is a large body of work on statistical relational learning (SRL) to handle joins that cause duplicates in the fact table [13]. But as mentioned before, our work focuses on the regular IID setting for which SRL might be an overkill.

Feature Selection

The data mining and ML communities have long worked on feature selection methods to improve ML accuracy [14, 15]. In contrast, our goal is not to design new feature selection methods nor is it compare existing methods. Rather, we want to understand if KFKDs/FDs in the schema can enable us to avoid entire sets of features a priori for some popular complex classifiers. This is a way of “short-circuiting” the feature selection process using database schema information to reduce the burden of data sourcing. The trade-off between feature redundancy and relevancy is well-studied [14, 44, 21]. The conventional wisdom is that even a feature that is redundant might be highly relevant and hence, unavoidable in the mix [14]. Our work establishes, perhaps surprisingly, that this is not the case for foreign features; even if a foreign feature is highly relevant, it can be safely discarded in most practical cases for decision trees, RBF-SVMs, and ANNs. There is prior work on exploiting FDs in feature selection. [40] infers approximate FDs using the dataset instance and exploits them during feature selection, FOCUS [3] is an approach to bias the input and reduce the number of features by performing some computations over those features, while [6] proposes a measure called consistency to aid in feature subset search. The idea of avoiding joins safely is orthogonal to these algorithms because they all still require computations over all features, while avoiding a join safely omits dependent features without even looking at them and obviously, without performing any computations on them! To the best of our knowledge, no feature selection method exhibits such a dramatic capability. Scores such as Gini and information gain are known to be biased towards large-domain features in decision tree learning [7] and different approaches have explored alternatives to solve that issue [17]. Our problem is orthogonal because we study on how KFKDs/FDs enable us to ignore foreign features a priori safely. Even with the gain ratio score that is known to mitigate the bias towards large-domain features, our main findings stand. Unsupervised dimensionality reduction methods such as random hashing or PCA are also popular [15, 29]. Our lossy compression techniques to reduce the domains of foreign key features for decision trees are inspired by such methods.

Data Integration

Integrating data and features from different sources for ML and data mining algorithms often requires applying and adapting techniques from the data integration literature [27, 8]. These include integrating features from different data types in recommendation systems [18], sensor fusion [19], dimensionality reduction during feature fusion [12], and techniques to control data quality during data fusion [10]. Avoiding joins safely can be seen as one schema-based mechanism to reduce the integration burden by predicting a priori if a source table is unlikely to improve ML accuracy. It is a major open challenge to devise similar mechanisms can be devised for other types of data sources, say, using other forms of schema constraints, ontology information, and sampling. There is also a growing interest in making data discovery and other forms of metadata management easier [discovery, ground]. Our work can be seen as a mechanism to verify the potential utility of some of the discovered data sources using their metadata. We hope our work spurs more research in this direction of exploiting ideas from data integration and data discovery to reduce the data sourcing burden for ML tasks.

8 Conclusions and Future Work

We think it is high time for the data management community to look beyond just building faster or scalable ML systems and help reduce the pains of data sourcing and feature engineering for ML. Understanding how fundamental properties of data sources, especially schema information, affect ML behavior is one promising step in this direction. While the idea of avoiding joins safely has been adopted in practice for linear classifiers, in this comprehensive experimental study, we show that it works even better for popular high-capacity classifiers, which goes against the intuition that high-capacity classifiers are typically more prone to overfitting. We hope that our results and analysis spur more discussions and new research on simplifying data sourcing for ML-based analytics.

As for future work, we plan to formally analyze the effects of KFKDs/FDs on high-capacity classifiers from a learning theoretic perspective. Other interesting avenues for future work include understanding the effects of more general database dependencies on classifiers, the effects of all database dependencies on regression and clustering models, and designing an automated “advisor” for data sourcing for ML tasks, especially when there are heterogeneous data types and sources.