Re: Database design

Alexandr Savinov <spam_at_conceptoriented.com> wrote:

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

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

But that's what I wondered. For all intents, a component or concept can itself become a leaf or black box. An atom or unit. An item. And any item can be a component, and has some limited meaning and utility by itself, by its very definition. The tone middle-C is still middle-C. In the same example, I can see, however, that one might wish to distinguish such elementary building blocks as a controller scalar from a full run of such. Still, I don't know. I suppose as a practical matter, one would only reference a component but have to refer to items in a different fashion.

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

Well, sure. If a hierarchy is placed in a flat table (that word again), by adjacency or the more brute force full/materialized path, then the reference is to the 'physical' record, however arranged in a logical hierarchy. The two are exclusive, except perhaps not semantically. But that's not something the machine would understand. It is the very sort of independence I think Codd sought, but violates his most basic rules of relations. Received on Wed Feb 22 2006 - 20:18:09 CET