Making Database Systems Usable

Mar 27, 2008 Christiano Santiago 1

Making Database Systems Usable

University of MichiganH.V. Jagadish, Adriane Chapman, Aaron Elkiss, Magesh Jayapandian, Yunyao Li, Arnab Nandi, Cong Yu


Agenda

Users Expectations The Persistence of Pain The Painless Future Conclusion Q&A


Users ExpectationsDatabase interactions

Ability to query in a more sophisticated way, using complex query semantics

More precise and complete answers

Expectation of structure in the result set

Create and update databases


The Persistence Of Pain


Higher Level Presentation Data ModelPainful Relations



Simple concept versus Implementation

Flight info

X



SELECT s.departure_timeFROM schedule AS s,flight_info AS f, airports AS d, airports AS aWHERE s.id = f.schedule_id AND f.fid = d.id AND d.city_name = “Beijing” AND f.tid = a.id AND a.city_name = “Detroit”

What are the fligth departure times from Detroit to Beijing?



Problems Large number of table Poorly named entities Poorly named fields Joins are not intuitive Recursive self-joins SQL is too onerous Dependency on DBA (please don’t leave!)


Multiple Ways to Access DataPainful Options



Too much functionality and too many options

X



Barry Schwartz, The tyranny of choice.

Scientific American, April 2004, pp. 71-75



Perspectives Design systems for customized value Care about how well uses can get their job

done Forms-based interfaces have been the

primary means to interact with databases Provide simple querying tools for novice

users and powerful tools for experts (customization)


Precision and RecallUnexpected Pain



X


Search engines error acceptance Expectations are set correctly Usually top few results do contain something

relevant If no relevant results were found, search it

again The web is so huge that no one knows

exactly what is out there




Unable to query Systems may impede users from querying the way they want Scenario: world traveler with infinite flexibility and many

destinations to visit


X



Unable to query User’s versus form designer’s mental model of the data.

Users should be worried about how. They just need the what.

Challenge #1: it’s not easy to provide a straightforward and comprehensive way of specifying what a user wants when a query requires aggregation or multiple complex joins.

Challenge #2: performance, security access level, data or program errors may prevent users from running a query.


Unexpected results (Unexpected results) + (no explanation) = frustration


Example 1Example 1• The client record shows he has 2 cars

but• There is only 1 car related to this client in the

database.# of cars was a field in the Client table, with no referential

Integrity with CarOwner table


Unexpected results (Unexpected results) + (no explanation) = frustration


Example 2Example 2User is looking for cheap flights provided by her favorite airline:• Los Angeles for $75• Boston for $100• San Francisco for $400 (?)

$400 was less than half the average price for a ticket to San Francisco



Unexpected results Empty & non-empty results Users may need to know where a result

comes from Users may need to know why a result is

returned System’s usability can be significantly

affected when no explanation can be given


Errors In Query ConstructionUnseen Pain



Database Users versus Computer Scientists

X





Perspectives Query purpose: provide information that the

user doesn’t have How do I provide a clear and precise “from”

and “where” clause, if I don’t know the possibilities?

WYSIWYG



WYISWYG

Assisted Querying using Instant-Response InterfacesArnab Nandi & H. V. Jagadish - University of Michigan



WYISWYG Google Earth approach Can you image finding a location in a map

using coordinates instead of zoom and rotation?


Database CreationBirthing pain



Corporate Market versus Average User

X



Perspectives Users want to store their data into databases

but this is not an easy task Database schema Table structure Normalization Relationships Constraints



Perspectives An everyday database

No clear view of required database structure No comprehensive design at starting point Structure grows as time passes

Structure grows incrementally Need to support both structured and

unstructured information


The Painless Future


The Painless FutureGeographic Model

Joins between data sets using geographic or spatial location as the basis


The Painless FutureNetwork Model

Graph or network representation of data.


The Painless FutureMultidimensional Model

Data as points in multi-dimensional space


The Painless FutureTabular Model

People is used to seeing data represented in simple two-dimensional tables


The Painless FuturePresentation Data Models

Perspectives Data manipulation through presentation data model versus view

updates

Consistency among view options: geographic and textual views in synchrony

Data provenance: “why” and “where” related to result sets

Direct data manipulation Point-and-click, drag-and-drop, etc. New few number of algebra operators to support it

Schema-later (unstructured) and heterogeneous database design


Conclusion

Databases are extremely difficult for most people to interact with.

We must rethink the architecture of the database systems as a whole.

Presentation model as a distinct layer above usual logical data model.


Questions & Answers

Documents

Making Database Systems Usable