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

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;

	DueID INTEGER;
	Name STRING;
	Divisions SET OF
	{
		Address STRING
	} CONSTRAIN Name KEY;

...SHIPMENT

{

	No Integer;
	Recipient CLIENT;
	Items SET OF
	{
		Art ARTICLE
		Quantity INTEGER
	} CONSTRAIN Art KEY;

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.

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)". Received on Tue May 23 2006 - 08:40:16 CEST