Re: On what OLAP can and what OLAP can't - A little problem

pamelafluente_at_libero.it schrieb:
> Hi Alexandr ,
>
> That's fine and correct. But I need the general logic (that's is what I
> meant for "algorithm") to deal with *any* arrangement of tables and
> relationship. Again my perspective is a programmer's one. One or more
> istances of a problem are good for discussions and counterexamples, but
> I need the general logic to deal with any set of "tables" (can be views
> or whatever actually) and relationships.

I seems that you need a kind of a full-featured data model because your criteria are very general. In particular, you need a "general logic" dealing with "any set of tables".

> The information I assume to be known is:
>
> - table structure for each table
> - relationships
> - functions applied to each field and their properties(row function/
> aggregate function / replication sensitive or not)
>
> Then the "algorithms" (a systematic method to perform this task) must
> be able to make automatically the partioning and union of subqueries,
> according to some logic, which is the object of my question.

I am afraid that it is too general formulation. Are you sure that numerous existing approaches to data modeling cannot do what you need?

> PS

>> LINE_A   CLIENT    LINE_B
>>       \  /      \   /
>>      TRANS_A    TRANS_B

Yes, your interpretation is correct. Table A references table B if A has a column where it stores an identifier to a row from B.

> 2. Not familiar with the term "dimension" in the way you use it (my
> fault). How do you count to 6?

Dimension is the same as degree of freedom. It is the number of paths from bottom to top if you order your tables accordingly. This order then is important for all the operations with data and its semantics. In my diagram if table A references table B then it is drawn below:

B
|
A

it is always many-to-one relationship, i.e., many a in A reference one b   in B. This ordering can be then used for operations you mentioned: aggregation (higher levels are general while lower levels are specific), relationships (a common subtable is a relationship for its supertables) and so on...

--
http://conceptoriented.com