OiRc-0005 A question of scale

Why did I ever do database visualization in 3D with VRML?

I had been working with a large, complex database, never mind where or should for whom, and I wanted to see it.

It defined or was defined by 750 objects. That's seven hundred and fifty object, and countless instances but I don't have to care about them.

Now how do you show 750 objects? Being an architecture student, which if you've been following along you already know and you can guess where I'm going with this, I am familiar with 3D.

The rationale for using VR and three dimensions is the following:

• On a static linear presentation, we can present, illegibly, a dozen objects in a row. (12)
• Extending this in two dimensions, we can present, illegibly, one hundred and forty-four object on a plane. (144)
• Extending this to three dimensions and using a VR browser, we can present one thousand, seven hundred and twenty-eight objects in a cube. (1,728).

Now, that's a lot more than the 750 objects I was faced with when trying to visualize the dataverse. Keep in mind that the 750 objects are local to a database and the Relationships revealed through an examination of the database for foreign keys are also local.

They don't have to be, which gets me back to the theme explored in OiRc-0001 Zip, nada, nothing, Sweet Fanny Adam. Ownership of specific memes is possible using the internet wisely.

I've already thought of this and out it in a wiki web page. Since I can't garantee that the page will survive all the turmoil in my house I'm including and comment on it:

A scheme for database presentation/interaction in VRML:

Disposition

a) Array the persistency mechanisms on the surface of a series of imaginary nested spheres. (0)

b) Topologically sort the persistency mechanisms (and therefore the objects mapped onto them) by the relationships in which they participate (1)(2) to provide the necessary information to position the persistency mechanisms and object classes in 3D.

c) Sometimes the mapping between tables (T) and objects (O) (T:O) will not be 1:1.

c1) The tables should be thought of as sections running from the surface to the center of a sphere. The objects should be distributed in the section as per their hierarchy. If database views are being used to 'simplify' access, objects representing the views can span several sections.

Tables and files, API'd legacy systems and other persistent external storage mechanisms should be rendered as colored 'tiles' on the surface of the nested imaginary sphere on which they are arrayed in sections. Differentiation between the types of persistency mechanisms can be accomplished by mapping a texture in addition to a color and providing a legend of any texture mapping used.

Objects are colored 'spheres' on or inside the 'tile' to which they are mapped. Relationships are thin 'rods' that run between tables and objects. They should probably be run in channels between the sections.

Color and opacity/transparency:

Color is best thought of as saturated CYMK (Cyan, Yellow, Magenta and Black) on a white or pale primary RGB (Red, Green or Blue,) colored background. The assignment of colors is arbitrary except that the mapping is the same as that used in creating real-world four color maps. The recently proved four color map theorem states that it will always be possible to construct a map where each object and each relationship will be dintinguished from adjacent objects and relationships with only the use of CMYK as color keys.

Opacity is an alpha channel quantity which should reflect the degree of interest in objects. Classifying objects as belonging to various systems and sub systems, it becomes possible to set the opacity to a low value for objects and relationships that are not relevant and high value for objects that are relevant. Nesting objects/tables should be partially saturated so that the reveal the nested objects/tables/relationships.

Given the computational burden imposed by the architectural presentation scheme, it should be generated only when the underlying data model changes.

The interaction and 3D manipulation, rotation and navitation can be provided by a VRML browser or an HTML browser VRML plug-in.

"Touching" a table, an object or a relationship should bring up any associated HTML description in a separate window or in a separate frame in a frame set.

Some interactive mechanism should be provided to allow the user to select a s(ubS)ystem and have the relevant objects, tables & relationships highlighted and irrelevant detail faded out. Execution of a macro adjusting the alpha channel is probably the simplest way to achieve this.

That leads us to the following data structures:

ALL objects have the following fields

ObjectUniqueID (128bits);

Mnemonic (128 bytes); (if none the UniqueID is used)

Description (String);

Class; (String, element of schema)

Version; (Integer)

Release; (Integer)

createUserDateTimeStamp;

activateUserDateTimeStamp;

alterUserDateTimeStamps; (OrderedCollection of UserDateTimeStamps)

inactivateUserDateTimeStamp;

dataDictionary (Dictionary of {Association of field=>value});

relationshipDictionary (Dictionary of relationship=>(OrderedCollection of ConnectionUniqueID)).

Connections consist of the following fields

ConnectionUniqueID (128bits);

Mnemonic (128 bytes); (if none the UniqueID is used)

Description (String);

Class; (String element of schema)

Version; (1)

Release; (0)

createUserDateTimeStamp;

connectUserDateTimeStamp;

alterUserDateTimeStamps; (OrderedCollection of UserDateTimeStamps)

disconnectUserDateTimeStamp;

dataDictionary (Dictionary of {Association of field=>value});

relationshipDictionary (Dictionary of relationship=>(OrderedCollection of ObjectUniqueID)).

This schema is the subject of another article.

RDObject

Associated_HTML_description;

it will be assigned

position (XYZ);

color (CYMK-alpha).

Participating in

RDObject<->RDMapping;

RDObject<->RDRelationship;

RDS(ub)ystem<->RDObject.

RDTable

Associated_HTML_description;

it will be assigned

position (XYZ);

color (CYMK-alpha).

Participating in

RDTable<->RDMapping;

RDTable<->RDRelationship;

RDS(ub)ystem<->RDTable.

RDMapping

Associated_HTML_description;

RDTable{,RDTable}:RDObject{,RDObject} {;RDTable{,RDTable}:RDObject{,RDObject}}.

Participating in

RDObject<->RDMapping

RDTable<->RDMapping.

RDRelationship

Associated_HTML_description;

RDObject|RDTable{,RDObject|RDTable}; 0|1|n:0|1|(N|M); RDObject|RDTable{[,RDObject|RDTable};

it will be assigned

startPosition (XYZ){,articulationPosition (XYZ)} {;startPosition (XYZ){,articulationPosition (XYZ)}}:

joinPosition (XYZ);

articulationPosition (XYZ){,articulationPosition (XYZ)};

joinPosition (XYZ);

{articulationPosition (XYZ),}endPosition (XYZ) {;{articulationPosition (XYZ),} endPosition (XYZ)}.

Participating in

RDObject<->RDRelationship;

RDTable<->RDRelationship;

RDS(ub)ystem<->RDRelationship.

RDS(ub)ystem

Associated_HTML_description;

RDObject{,RDObject};

RDRelationship{,RDRelationship};

RDTable{,RDTable};

RDS(ub)ystem{,RDS(ub)ystem}

Participating in

RDS(ub)ystem<->RDObject;

RDS(ub)ystem<->RDTable;

RDS(ub)ystem<->RDRelationship;

RDS(ub)ystem<->RDS(ub)ystems.

0) The rationale for using VR and three dimensions is the following:

• On a static linear presentation, we can present, illegibly, a dozen objects in a row. (12)
• Extending this in two dimensions, we can present, illegibly, one hundred and forty-four object on a plane. (144)
• Extending this to three dimensions and using a VR browser, we can present one thousand, seven hundred and twenty-eight objects in a cube. (1,728).

1) The relationships themselves are a special class of problem since there may be several functional/state-based relationships between two tables which will not necessarily be revealed since one table (T) will only have one foreign key (FK) to another table (T') which would satisfy the relational calculus but not the actual object model. It is therefore necessary to delve deeper into the object model than simply relying on the data model. It is a starting point but not

2) Tables which have no dependencies on other tables (which don't have foreign keys) are arrayed on the outermost sphere. The nesting depth of a table (T) depends on nesting of relationships to other tables (T'..T). It will be positioned one level deeper than the deepest in T'..T;.

The schema was well enough defined that I could find all foreign keys and link them to their specific tables