Skip to content

Success and Failure Scenarios

Andrea Falconi edited this page Apr 13, 2020 · 2 revisions

The model makes it plain that the query method comes with (implicit) preconditions PC and NAC—the latter only applicable to the case where the client requested a numeric aggregate, one of sum, avg, min, or max. If such preconditions fail, the client gets back either an empty list or an incomplete result list. Otherwise, preconditions hold and the client gets back a list containing the rows each table contributed to the query—in particular, this could be the empty list again if the query returned an empty result list on each table. We're going to flesh out how the possible combinations of PC and NAC determine success and failure scenarios.

Preview

As a warm up, let's start with the case where the query only involves a single table T. We return an empty list in any of these cases:

  • PC(T) = false, i.e. T doesn't have some of the requested attributes.
  • The client requested a numeric aggregate (sum, avg, min, max) but some of the requested attributes aren't numeric, i.e. PC(T) = true but NAC(T) = false.
  • PC(T) = true (or NAC(T) = true for the numeric aggregate case) but the query predicate selects no rows, i.e. there actually are no matching records.

The first two are failure scenarios whereas the last one is a success scenario. The only other possible success scenario is when PC(T) = true (or NAC(T) = true) and the query selects some rows in which case the client gets back a non-empty result list.

What happens if the query touches more than one table? The situation is conceptually similar to the single-table case but there's a combinatorial explosion of scenarios. How many? 3^a⋅t where a is the number of requested attributes and t is the number of tables. To see why, we'll need a little combinatorics with which we can handle both the single- and multi-table case.

Combinatorial model

Any requested attribute x can be in one of three states with respect to a table T

  • 0: T has no column named x.
  • 1: T has a column named x but it isn't numeric.
  • 2: T has a numeric column named x.

We can build a chart TA to represent all possible states of the requested attributes Attr = { x, y, ...} with respect to T

 x   y  ...
--- --- ---
 0   0  ...
 0   1  ...
 0   2  ...
 1   0  ...
... ... ...
 2   2  ...

Obviously

TA = {0, 1, 2} × {0, 1, 2} × ... = {0, 1, 2}^a

where a = |Attr|, the number of requested attributes. Now if T1, T2, ..., are the tables touched by the query, we'll have to look at

V = TA1 × TA2 × ...

to determine all possible scenarios, of which there are 3^a⋅t where t is the number of tables. In other words, we identify each possible scenario with a "scenario" vector v ∈ V. With that in mind, if the client requests no numeric aggregate operation, the success scenarios and failure scenarios are, respectively, the sets S1 and F1

S1 = { v ∈ V | ∀ i . 0 < v[i] }
F1 = V - S1 = { v ∈ V | ∃ i . v[i] = 0 }

If the client requested a numeric aggregate operation, success and failure sets are

S2 = { v ∈ V | ∀ i . v[i] = 3 }
F2 = V - S2 = { v ∈ V | ∃ i . v[i] < 3 }

Notice that if there's only one table involved, the query method returns an empty list in failure scenarios whereas if multiple tables get queried, on failure the query method returns either an empty list (preconditions failed on all tables) or a list with results from some of the tables (preconditions failed only on some tables, other tables contributed results).

Examples

Here are a few concrete examples of failure scenarios.

  • Client requests numeric aggregate from one table that doesn't satisfy the NAC constraint. E.g. client requests attributes x and y from T but T doesn't have a y column. Outcome: empty list.
  • Same as above, but now T has both x and y columns with x numeric and y non-numeric. Outcome: empty list.
  • Client requests attributes from multiple tables, none of which satisfy the PC constraint. E.g. x, y and z from tables T1 and T2. T1 has both x and y but no z whereas T2 has x and z but no y. Outcome: empty list.
  • Client requests aggregate from multiple tables, none of which satisfy the NAC constraint. E.g. attributes x and y, T1 has both but y isn't numeric whereas T2 has a numeric y but no x. Outcome: empty list.
  • Client requests attributes from multiple tables some of which fail PC. E.g. attribute x from T1 and T2; T1 has it, T2 does not. Outcome: results from tables satisfying PC.

The examples also highlight that in general, the set of failed attributes for one table may be different than another. Moreover, in the case of aggregates, some attributes may have failed PC whereas others NAC. For the sake of completeness, here's an example of success scenario:

  • Client requests existing attributes but there are no matching records. E.g. attribute x is defined both for tables T1 and T2 but none of them contributes rows to the query. Outcome: empty list.

Up

Prev | Next