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

U-gene schrieb:
> The beginning can be found on
> http://groups.google.com/group/comp.databases.theory/browse_frm/thread/32e771cb8a3e70af
>
> Here...
> http://groups.google.com/group/comp.databases.theory/tree/browse_frm/thread/32e771cb8a3e70af/24b09e5385c76ceb?rnum=11&_done=%2Fgroup%2Fcomp.databases.theory%2Fbrowse_frm%2Fthread%2F32e771cb8a3e70af%3F#doc_7841166a7f60a90d
> ... I describe briefly the type system existing in RxO system.
> According to this type RxO-system looks like OO-system. All data exists
> in the set of objects, which have complex structure and can be linked
> with referenses into complex hierarhic structure. The only existing
> type requirement is "each object's component has type that allows
> relational assignment ", becouse it gets easy possibility to meet main
> requirement of "The OverRelational Manifesto".
>
> For example
>
> ...ARTICLE
> {
> No INTEGER;
> Definition String;
> }CONSTARIN No Kys
>
> ...CLIENT
> {
> DueID INTEGER;
> Name STRING;
> Divisions SET OF
> {
> Address STRING
> } CONSTRAIN Name KEY;
> } CONSTRAIN DueID KEY
>
> ...SHIPMENT
> {
> No Integer;
> Recipient CLIENT;
> Items SET OF
> {
> Art ARTICLE
> Quantity INTEGER
> } CONSTRAIN Art KEY;
> } CONSTRAIN No KEY

As far as I understand one of the main distinguishing features is that here is the keyword "SET OF" to define multi-valued attributes? If so then is not it more natural to define a type explicitly, for example:

SHIPMENT {
   ...
   Items SET OF MyType;
   ...
}
MyType { ... }

instead of

Items SET OF { ... }; // From your example

In other words, your notation seems to be equivalent to anonymous types. It might be useful in rare situations but normally we would like to have our types explicitly defined.

> According to this definition, each SHIPMENT object is copmplex (0NF)
> objects, which includes refences on ARTICLE and SUPPLIER objects. In
> fact complex hierarchic structure is defined here.

Did you study this structure and do you use it in your approach? (For me it is the most interesting issue.)

> But I promise that RxO system is simultaneously relational system too
> and all data existing in this system reprezented as set of relation.
> These relations are defined implicity but users has access to these
> relations and can manipulate with them. It means that relvars exist in
> system and users must know their names and names of their attributes.
> So RxO system keeps a rule what allows users to know that names right
> after complex hierarhic structure was defined.
>
> This rule is very simple: the definition of complex reference
> structure, in which path expression "C.*.*.s" is correct, can be
> interpreted as definition of a relation variable named as "C.*" , in
> which the scalar attribute named as "*.s" exists (among others)..."
> Here
> - "C" is name which defines existense of set of complex objects in
> system. It can be name of object type (or, in a procedure code, name of
> reference)
> - "s" is name of scalar field. This name can be defined in complex
> structure definition as name of scalar component or as scalar attribute
> of tuple or set object component.
> - "*" is any, possible empty sequense of reference or non-scalar names
> defined in complex structure definition.
> Also all such relvars (R-vars below) contain back-reference attribut
> "Object()" that defines on OID domain (so OID is just scalar value -
> nothing more here).
>
> According to complex structure described above this rule sounds that
> (for example) R-vars named "SHIPMENT.Items", which contains arrtibutes
> "Object()", "Art", "Art.No", "Art.Definition", "Quantity", exists
> (among others relvars, which can exist in this system according to
> described rule).
>
> This rule is kept by RxO system and this rule allows users to use
> names, which looks like path expressions defined with complex hierarhic
> structures, in operations, based on relational. For example next query
> can be executed...
>
> SHIPMENT
> (WHERE Items.Art.No = "...")
> [Recipient.Name,Recipient.Division.Address]
>
> ...because path expressions "SHIPMENT.Items.Art.No",
> "SHIPMENT.Recipient.Name" and " SSHIPMENT.Recipient.Division.Address"
> are possible(according with structure definition above) and "SHIPMENT"
> is common first part of all these expressions.
>
> It is possible to understand that R-vars are kind of predefined
> possible views. For users it looks like all these views already exist.
> Of course these views doesn't exist in a system all the time - but
> they can exist.
>
> All these views are built by the system dynamically over the internal
> data representation (which is relatonal too) when expressions what are
> similar to the query above are executed. In this internal
> representation all data exist in optimal normalizer forms. Or rather
> this form is defetmined by object type description too, so it is user's
> posibilities to make internal representation optimal. For example data
> about SHIPMENT objects exists internally as two normalised relations,
> where the first one contains attributed described as scalar component
> "No" and "Recipient"(shipment header) and the second one contains data
> described as SET component "Item" (shipment item).
>
> So according to examples kindly given by Mikito Harakiri this proposed
> feature can sound in one sentence as "Complexity of hierarchical
> structures can be expressed with (names of relation "point" names of
> its attributes in RDM)".
>

-- 
http://conceptoriented.com