Re: Real world issue: How to "split" queries in presence of record replication and replication sensitive aggregate functions ?

pamelafluente_at_libero.it schrieb:
> That's the point. Content is unimportant. What matters are only formal
> the properties of involved objects.

If we want to get meaningful reports then content is a primary issue. While the formal model is simply a concise encoding of what we expressed in words. This is why to have a meaningful use case is so important.

> The input of the problem are:
>
> - Tables (in abstract sense, as a list of field) and a list of their
> field including datatype
> - Relationships
> - Structure (list of fields) of the report with properties of involved
> functions:
> - Function is aggregate: Yes/No
> - Function is sensitive to replication (eg. sum): Yes/no
>
> That's it. Simple to state.

I like your problem formulation. But in this form it hardly can be solved. And the main reason is that providing "a list of fields" as a report specification is in most cases ambiguous, i.e., it cannot be translated into one query unambiguously.

A solution to your problem could be as follows:

1. Choose one *primary* table with entities listed in the report.

Notice 1.1 No fields are chosen yet from this and other tables.

Notice 1.2 If this table does not exist then it has to be somehow defined, e.g., as a view or via query.

2. Define properties of the primary entities by indicating fields from other tables.

2.1 Properties may have 3 major types: from supertables via dimension (column) names, from subtables via inverse dimensions (columns taken in the opposite direction), zigzag properties which combine the previous two types.

Notice 2.2 Sometimes specifying a field is not enough and it is necessary to provide a hint for choosing an appropriate access path.

Notice 2.3 An aggregation function can be applied to properties returning a collection (see 2.1.2 and 2.1.3)

This approach can be more or less easily implemented but here I would like to warn you that the main problem is not here. It appears when you start imposing restrictions in your report (say, via WHERE and HAVING clause in SQL). You may easily get cyclic dependencies which need to be somehow resolved. But it is already another story...

>> -P
>

--
http://conceptoriented.com