Re: Database design

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'?

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. 

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

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