Add Denial Constraint structures that are necessary to implement DC verification #417

This class represents an operator used in predicates for Denial Constrains (DC) representation. Predicates used there are less, greater, eq, neq, geq and leq. This C++ implementation is 100% bad, there is whole bunch of objects being created, but conceptually all of them are the same. Object "Operator '+'" and another object "Operator '+'" represents the same thing. ---------------------------------------------------------------------------- This is just a copy of a java code from https://github.com/RangerShaw/FastADC. I will refactor and think about better implementation later. I'll be just copying java code to get working algorithm ASAP, and after that I'll start thinking about good implementation.

This commit adds test_dc_structures.cpp file, which will be used to test different data structures which are required for DC representation (there are a lot).

This class represents a column operand within a predicate for FastADC. FastADC processes Denial Constraints (DCs) that involve comparisons between pairs of rows within a dataset. A typical DC example, derived from a Functional Dependency (FD) such as A -> B, is expressed as: ∀𝑡, 𝑠 ∈ 𝑟, ¬(𝑡.𝐴 = 𝑠.𝐴 ∧ 𝑡.𝐵 ≠ 𝑠.𝐵). This denotes that for any pair of rows in the relation, it should not be the case that while the values in column "A" are equal, the values in column "B" are unequal. A predicate in this context (e.g., 𝑡.𝐴 = 𝑠.𝐴) comprises three elements to be fully represented: the column operand from the first tuple ("t.A"), the comparison operator ("="), and the column operand from the second tuple ("s.A"). The `ColumnOperand` class encapsulates the column operand part of a predicate, such as "t.A" or "s.A".

First step in FastADC algorithm is to build so-called "Predicate Space". This is a long process during which many places in the code wants to get a Predicate. But each predicate is stored in a global storage -- map. In Java code this class (and other similar "provider" classes) are singletons. BaseProvider class is the class, from which a *Provider class should be derived. It ensures that only a PredicateBuilder class can initialize and free these singletons. I'm sure there exists a better approach, where we will store Provider classes in some fields to bind their lifetime more explicitly, but this is how it's done in Java, and I don't have much time to devise perfect architecture.

This class acts as a centralized storage to manage and provide access to Predicate objects. A Predicate is defined as "t1.A_i op t2.A_j", where t1 and t2 represent different rows, and A_i and A_j are columns (which may be the same or different) The FastADC algorithm first will build a so-called "Predicate Space", which is a set of all predicates that are allowed on R (set of rows, basically a table). In order to create and store predicates, this commit implements a singleton class with a hashmap storage.

FastADC processes Denial Constraints (DCs) that involve comparisons between pairs of rows within a dataset. A typical DC example, derived from a Functional Dependency such as A -> B, is expressed as: `forall t, s in r, not (t.A = s.A and t.B != s.B)` This denotes that for any pair of rows in the relation, it should not be the case that while the values in column "A" are equal, the values in column "B" are unequal. A predicate in this context (e.g., t.A == s.A) comprises three elements to be fully represented: the column operand from the first tuple ("t.A"), the comparison operator ("="), and the column operand from the second tuple ("s.A").

This simple test creates two predicates on a 2x2 table and evaluates them. We're checking for mo::GetPredicate function ability to correctly create a predicate

In the original FastADC pull request this class manages creation of predicates, so it initializes PredicateProvider. But in this pr this class is not required for DC verification. Hence adding a temorary class just to make the tests work

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add Denial Constraint structures that are necessary to implement DC verification #417

Add Denial Constraint structures that are necessary to implement DC verification #417

Commits on Jun 8, 2024

Add Denial Constraint structures that are necessary to implement DC verification #417

Are you sure you want to change the base?

Add Denial Constraint structures that are necessary to implement DC verification #417

Commits on Jun 8, 2024