Re: The Practical Benefits of the Relational Model

pbrazier_at_cosmos-uk.co.uk (Paul) wrote in message news:<51d64140.0209240257.41ab8599_at_posting.google.com>...

> > And I am saying that there IS a solution to these things and it CAN be
> > done it real time. In fact all of the goals you are aiming for are
> > accomplished elegantly in Dataphor. For example, we have (and have
> > had) Windows and Web UIs that are dynamically derived from the
> > database. They require no data access stored procedures and are
> > driven from the data model. Check it out... I think you will like it!
>
> There must be procedural code somewhere that translates down to
> machine code to actually produce the UI - is that done externally to
> the DBMS (e.g. with something like PHP or ASP using the database to
> get parameters) or internally (at the physical implimentation level or
> the DBMS itself)?
>
> If it was internal it would be like an layer enabling relations to
> access the windows API - so for example you put the coordinates into a
> relation and up pops a window automatically. You delete the row and
> the window disappears. Is this how it works?

UIs are external to the relational query processor. We are still a ways off from wrapping UIs relationally (they are currently part of the implementation level, not the logical one).

Dataphor has UI clients that are thin in the sense that they are not specific to a certain application. Both clients consume XML-based "user interface description documents" from a web server via HTTP (like a web browser consumes HTML). Unlike HTML, the UI document format is not hard-coded. We have a general "serializer/deserializer" that constructs class instances (I am purposely avoiding the vague "O" word) from the document, bringing into existence a hierarchy of UI "nodes." These nodes reflect the logical layout of the UI document and collaborate to construct the actual user interface. For the Windows client, the nodes create and maintain Windows controls. The Web client (which is also a server) renders HTML. Each node can be re-interpreted and new node types can be developed by simply creating and registering new classes (the (de)serializer does the work of reading and writing their state). In other words, the clients are like easily extensible browsers.

Rather than send data with the UI description, we defined nodes that are intrinsically data aware themselves. The clients connect to the RDBMS to perform data operations. This way, the UI descriptions do not have to be re-presented as the user navigates and manipulates the data. The result is the "feel" of a fat client without the "fat."

Dataphor can also "descend" one UI from another. This form of UI inheritance allows UIs to be customized at different levels while maintaining common structure. The inheritance is facilitated on the UI server, and is transparent to the clients.

So at this point, I have discussed the infrastructure to design and customize data-aware multi-client user interfaces at a high level of abstraction. So who builds these UI descriptions? The developer can build them, using either XML or our UI design environment. We also have a "UI derivation engine" that dynamically derives user interface descriptions from the data dictionary based on an arbitrary expression against the database. The dynamic user interfaces are influenced by user specified metadata which adorns the data dictionary, allowing the developer to steer the derivation process. The developer can also modify the derivation process, or make arbitrary changes to the resulting user interfaces. They can even save the customized user interfaces as "descendants" of dynamic ones. This facilitates user interfaces that are both dynamic, and customized.

The UI derivation engine is an interesting piece of work because it uses our query processor's ability to infer information through arbitrary expressions. For example, if table A has a reference (FK) to table T, and we ask for a UI on "A join B", our engine "knows" that the resulting view implicitly references table T. This information is then used by the derivation engine to provide appropriate elements within the user interfaces to navigate the data structures.

--
Nathan Allan