Re: Database design

From: Alexandr Savinov <spam_at_conceptoriented.com>
Date: Wed, 22 Feb 2006 15:24:19 +0100
Message-ID: <43fc7413@news.fhg.de>

Mark Johnson schrieb:
> Alexandr Savinov <spam_at_conceptoriented.com> wrote:
>

>> Mark Johnson schrieb:
>>> Alexandr Savinov <spam_at_conceptoriented.com> wrote:

>>> http://conceptoriented.com

>>> As I understand it, aren't your 'class operators' much like level/join
>>> operator of XSLT? Alice.Bob.Walker implies some routine/mechanism to
>>> tie Alice to Bob, and then Bob to Walker, but which will not tie Alice
>>> to Walker directly? It would essentially be an alias for Connect By?

>> I do not know if it relates (directly) to XSLT and where did you see 
>> 'class operators'?

>
> It's almost a staple of what you see, anymore. Your dot operator seems
> to suggest the similar operator in XSL-T, which is a slash. Alice dot
> Bob dot Walker. Establishing that chain is essentially the great
> issue, at hand, and one that presumeably would seem contentious to
> some.

One point is that dot separates dimension names - not entities.

Another important point is that there are two operations: - projection, and
- de-projection
Since all our elements are ordered we can use these two operations to navigate over this structure. Projection is a move upward (to more general element) while de-projection is a move downward (to a more specific element).

>> The idea is that a model should be aware of the data 
>> item connections; it should manage links - not items. The price for that 
>> is a concrete structure the model must obey. More specifically, we bring 
>> a order into a set of data elements. And this order is the most 
>> important thing because it determines everything including data 
>> semantics. An element is positioned among other elements and this 
>> position determines what does it mean.

>
> I agree. More importantly, in a hierarchy, the item, and all its
> sundry sub-items may trivially be relocated. One need not rework
> 'relations' and external link columns, every time someone feels it
> better that the subtree go here, and not there.
>

>> If we change it then the data 
>> element changes its meaning accordingly. So it is not important what is 
>> inside - it is important how this element is positioned among other 
>> elements. Each element has a number of superelements and a number of 
>> subelements (normally these are concepts and data items). If you further 
>> describe it formally then you get the concept-oriented data model.

>
> The item must have some intrinsic semantic meaning. The scalar applies
> to one chart not another. But something else may be relocated
> precisely because it means something on its own, unrelated to another,
> not exclusively part of another I should say. It cascades and builds,
> like classes. Each component combines with new components in proper
> order to itself become atomic to a larger combination, and so on.

Primitive items are supposed to have some intrinsic meaning. All other items do not have it and their meaning is defined only by surrounding items. For example,

> But one always has to handle the start state, the upmost level, as
> somehow something different. So I would stick with this difference
> between atoms and components, even if by level one becomes the other,
> and we really are discussing the same thing.

> That is, you have two principal paths. You have the component, and its
> internal connection and order, its link and sort, each step of the
> way. And you have its placement in the larger component, as a subtree
> if you will.
>
> But it seems to me that the concepts and data items you mention cannot
> account for concepts becoming data items to other concepts, unless I
> misunderstand your definitions.

In the general case it is not only possible but it is assumed so. Any elements participates in two structures: - a purely hierarchical, called physical or identity structure (it is a kind of physical inclusion or physical containment which determines such issues as life-cycle, identification and access), and - a multidimensional and hierarchical, called logical or entity structure (it depends how elements are characterized by other elements)

For the two-level model the physical structure has one root, a number of concepts in it, each having a number of items. But we may have multiple levels and then a concept can be viewed an item for its parent concept (the leaf elements then are called items). Thus the difference between concepts and items is not so fundamental. An item is a concept without internal items (a leaf in the physical structure).

So actually there is two sorts of orders: physical and logical. For example, a row physically lives in its table while logically it belongs to rows identified by its attributes.

-- 
http://conceptoriented.com

Received on Wed Feb 22 2006 - 08:24:19 CST