Re: Database design

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.

>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.

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. Received on Tue Feb 21 2006 - 23:46:49 CET