User Interface Patterns For Database Apps

A database can be seen as a kind of a graph, often tree-like, sometimes forest-like (in the mathematical sense); so doing a query is like finding a path in a graph - this leads quite naturally to a graph-based user interface for databases, where manipulating the graph (clicking on nodes, as an example) in an ordered pattern, generates queries - the user is not focussed on a particular query language, like SQL, but manipulating a graphical representation of information.

-- MishtuBanerjee

Do you have any examples for such a GUI?

Like any GUI - design emerges, iteratively.

Go to: http://www.harmeny.com/create_explore.html for an early version of the GUI - the tree metaphor is implicit here, but not obvious yet. There is a "Select a Data Source" area - that essentially represents nodes in a tree.

Then go to: http://www.harmeny.com/twiki/pub/Main/LifeLineNet/LifeLineAI2002Tutorial.pdf and the tree metaphor emerges more clearly in the "Database Map" window (pg 4), where the interface has become a tree-like graph.

I am a little skeptical that trees are the best classification system. While they are easy for many users to grasp, they are limited in their expressiveness, especially when dealing with multiple orthogonal traits. (LimitsOfHierarchies) Some of those examples look similar in structure to some of the DataDictionary "Query by example" examples, I would note. However, those are meant for developers and not end-users.

Following the theme that TheDataIsTheUserInterface, this model originated in an analysis pattern. I had adapted Martin Fowler's AnalysisPattern ObservationsAndMeasurements? to apply to natural resource databases, and over time, it gradually struck me that one of the key features of the pattern was its hierarchical nature. As I applied it to a wider variety of resource data, over time the DomainDetails? were stripped away, leaving the MathematicalAbstraction?.

It was interesting how long it took for the PatternBehindThePattern? to become apparent. Like a set of dominoes - you start going - "oh, so a database can be a graph; and well, I guess that means a query is like a path through a graph - but hold on, a query is also like a hypothesis, its proof being the result set, so by manipulating the graph, you are also doing logic." A few more hops skips and jumps, and one is reading CharlesPeirce? and the development of ExistentialGraphs?, and dreaming about logic as these dynamic forests of relations constantly changing ... and it soon becomes clear that the user interface you spent 5 years on is just the first iteration of an idea that is still just nascent.

-- MishtuBanerjee

What exactly is a "database application", and why should the UI be any different for an application that uses a database versus one that does not? Excluding RAD, the UI requirements should be dictated by the requirements, and not the underlying usage of a database.

Well, maybe we should be talking about UserInterfacePatternsForDomainModelBasedApps?, every application has a DomainModel, and the UserInterface shouldn't go against that domain model, it should flow with it... if the DomainModel is described using ObjectOriented techniques then UserInterfaceWidgets? should be used in a way that matches the multiplicity relationships between the entities in the DomainModel (See WidgetsRepresentRelationshipsInTheModel)