Re: The OverRelational Manifesto. VOCIFEROUS IGNORANCE vs. NUMB DOGMA.(the sequel)

From: Alexandr Savinov <spam_at_conceptoriented.com>
Date: Mon, 29 May 2006 17:28:57 +0200
Message-ID: <447b133c$1@news.fhg.de>

U-gene schrieb:

>> Do you mean by "object's component" a field?

> It can be field. Commonly I mean something what contains (or returns)
> value. So it can be fields, attribute, method - anything what define in
> specification of object type to have value what describe these object.
>
> There are two king of types in RxO system - object types and valued
> types.
> "...In the general case, the specification of an object type includes
> 1. the type name;
> 2. a list of parent types (unless otherwise is defined explicitly,
> the
> parent type is the Object type implicitly);
> 3. a collection of specifications of components, which include (a)
> the
> component name; (b) the value type of the component, and (c),
> optionally, the set of parameters each one described as a pair
> <parameter name, value type of the parameter>;
> 4. a set of data integrity constraints, i.e., keys...."
> ...where "...The value types are the following:
> 1. scalar type including the basic ones (numerical, symbolic,
> Boolean,
> etc.) and reference types.
> 2. constructed tuple type. A value of this type (hereinafter, a
> tuple)
> is a set of pairs "an attribute name, a value of the attribute of the
> scalar type." Accordingly, the tuple type is defined as a set of
> pairs "attribute name, scalar type of the attribute."
> 3. constructed set type. A value of this type (hereinafter, a set)
> is a
> set of scalar or tuple values. Accordingly, a set-type variable is
> defined as (variable_name AS SET OF name_of_scalar_or_tuple_type)..."
>
> When these types are specified and implemented, then we can create both
> the objects and global variables of valued types. As you can see SET
> types is constructed types which are defined as set of tuples, where
> each typle is set of scalars. You can consruct this type as you wish -
> directly in object type specification or somewhere else.
>

>> If so then nothing prevents me from having an explicit declaration of
>> all relations and then using set-valued attributes via "SET OF" keyword,
>> for example:
>>
>> MyType {
>>   INT myIdentifer;
>>   DOUBLE balance;
>> } CONSTARIN myIdentifer Key
>>
>> and then we write
>>
>> SHIPMENT {
>>    ...
>>    Items SET OF MyType;
>>    ...

>
> Is "MyType" a relation definition? In this case you shouldn't use "SET
> OF" when you describe "Item"? because result of such definition is set
> of relations(I cannot imagine what is it:) ) - not single relation. But
> if "MyType" is just tuple definition you cannot define keys into
> definition expression, because there is no yet set of tuples here. So
> you can write
>
> MyType {
> myIdentifer INT;
> balance DOUBLE;
> }
>
>
> ObjectType2 {
> ...
> SetValuedField SET OF MyType CONSTARIN myIdentifer Key;
> ...
> }
>
> Or you can write something like
>
> CREATE RelationType MyType {
> myIdentifer INT;
> balance DOUBLE;
> } CONSTARIN myIdentifer Key
>
>
> ObjectType2 {
> ...
> SetValuedField MyType;
> ...
> }

But in this example field SetValuedField is one-valued. In order to define it as a set-valued component we need to define it as follows:

ObjectType2 {

    ...
    SetValuedField AS SET OF MyType;
    ...
}

On the other hand, you noticed above that it is wrong. I am feeling that I am lost... If

SetValuedField MyType;

should be a set-valued property then how can we define a single-valued property?

Let us consider a simple task. An order is characterized by a set of (ordered) product items AND by one product item (say, it is the main item or an item to be delivered first):

ORDER {
   orderId INT;
   ...
   items AS SET OF ITEM; // Ordered products    mainItem ITEM; // The main product
   ...
}

ITEM {
   itemId INT;
   ...
   price DOUBLE;
   ...
}

Could you show how this could be described using your approach (object types vs. valued types etc.)? In particular, how can I define two properties taking values from one domain: - a single-valued property, and
- a multiple-valued property

If this example is not very appropriate then probably you can modify it in order to clarify the following issue:

why do we need to distinguish between object types and valued types?

I mean that we used to define types of *entities* as a number of *properties* which can be either *one-valued* or *set-valued*. In your approach we introduce more basic notions and I am not able to construct an example which would demonstrate their importance and advantages.

> In any cases you can use "MyType" repeatedly. Why not?
>
> RxO system works with something, what is more complex than single
> relation. The only thing exists in RDM what is more complex than single
> relations - is is set of relations. But each of these relations is
> usual relation as it is defined in RDM and each relation can be defined
> in any way if the result of this definition is true relation.
>

-- 
http://conceptoriented.com

Received on Mon May 29 2006 - 10:28:57 CDT