But another issue plagues database applications, which is the user interfaces they tend towards. Relational databases drive a certain type of user interface that is inherently difficult to understand.
To understand why relational databases lead to interface complexity, a little context is necessary. All relational databases are really graphs as discussed in the prior article, where records point to or are connected to other records. The difference is that in relational databases a specific *field* in a given record points to another record, whereas in a graph database, the record *as a whole*, points to another record. This difference is critical because while a relational database is a form of graph database, it is much harder to visually demonstrate a link between a field and a record as opposed to a record pointing to a record.
On the surface, it may not be clear why this is the case. For example, consider an invoice that has a payment associated with it. The invoice record has the check number as a field of the invoice. This check number is a pointer to the check object.
Indeed this interface is easy to understand, but only because we intuitively understand that an invoice might point to a check, and in any case we all know what a check is. But this kind of dependency is cheating. In circumstances where the user doesn't already have the data model in her head such linkages are not at all clear. For example, if the linking field, instead of a check number was an authorization id, it would not be immediately clear whether or not there was some authorization object that the authorization id was pointing to, and if so, what it meant.
What is typically missing in such user interfaces is actually seeing relationships between database objects in a more physical way. For example, it is much clearer to show that there is a relationship between an invoice and a check by representing them both on the screen, laying them out in such a way as to reflect the underlying relationship. For example, the check and invoice could be organized in a folder. Or they could be organized in outline form so that the check is indented and shown under the invoice. But whatever the visual metaphor is, the key is that the graph model allows for a more physical representation that is understandable by any user even when she has absolutely no pre-existing knowledge about the structure of the data.
The fundamental problem we are really pointing to here is that relational database applications tend towards designs that require too much spatial visualization. As I discussed in a previous article on user interface psychology, this is problematic.
For example, without being able to demonstrate relationships in a more physical way, the authorization id discussed above requires some text explaining what it is, or perhaps some button, which takes you to the authorization record. But actually pressing such a button would have the effect of changing your context, which may actually increase complexity, particularly if the authorization record is connected to other objects in the database who's relationships must then also must be explained.
To reduce the spatial visualization issue, standard relational UIs have to work hard to make it clear what the data represents. Or in many cases, designers simply abandon making the data model understandable as a design goal, and instead the interface is built around just following instructions with some kind of step by step wizard interface. This is fine for a data input operator, but for people who really need to understand what is going on, if this is their only interface into the system, it is a nightmare.
The economic impact of this relational database interface complexity is substantial. Each time a new relational database application is designed, a significant amount of money is spent designing interfaces to make opaque data relationships clearer. And yet, even with all of that design work, huge amounts of money are spent each year training people to use these applications. Companies like Siebel made billions of dollars helping people create these complex monstrosities, and then training people how to use them.
I posit here that moving away from the relational model can save businesses billions of dollars in lost productivity and development costs as applications inherently become more intuitively understandable. But there is huge vestigial momentum behind relational databases, and the resulting derived products are often painful to use. Indeed perhaps instead of calling the prior article The Death of the Relational Database, I should have just said, if we are not careful, the relational database will be the death of us.
0 comments:
Post a Comment