Shaping a solution to relational problems
Stories Columns Opinions Resources
Sun extends Groovy, PHP support to NetBeans
Version 6.5 of the IDE will see complete support for those two languages along with comple...
|
Sun reorganizes its software production infrastructure
Facing economic hardships, lost revenue and loss of employees, Sun has split its software ...
|
Adobe steers Flash toward RIA implementation
At this year's Adobe MAX Conference, the focus was on Flash, this time making Flash more o...
|
BigLever builds a bridge to SCM with Gears
The Gears Universal Configuration Management Bridge allows CM systems to integrate with Ge...
|
SOA Watch: New economic realities
In the current economic downturn, agile programming and SOA are attractive options that bu...
|
Integration Watch: A new twist on threads
The key to raising the efficiency of multiprocessors is to shrink the overall workload by ...
|
Integration Watch: The Return of NetRexx?
Java scripting languages are seeing a surge in popularity, with NetRexx looking particular...
|
Windows & .NET Watch: Transaction crowd gets a boost
With multicore chips becoming the standard for processors, the need for a flexible, usable...
|
From the Editors: Election should shake up JCP
Rod Johnson has the right ideas for opening up the Java Community Process, and he may be a...
|
Letters to the Editor: Sun gives REST, SOAP choice
A reader takes issue with a headline on our story about Sun working with REST along with S...
|
Guest View: Be smart and lazy
The optimal solution for problems is the simplest one, so always aim to streamline your ap...
|
Zeichick's Take: From EXEC to EXEC 2 to REXX to NetRexx
Andrew Binstock's column last week, "The Return of NetRexx," brought back some fond memori...
|
Practical tips for saving money on code maintenance
If software design is expensive, well, code maintenance is even more so. When you look...
|
Transform your app-dev quality by involving the whole community in testing
As the saying goes, the more eyes you have on software, the shallower the bugs. That’...
|
Build your dev and test labs for less – a lot less – with virtualization
You don’t have the budget to equip developers and software test teams with all the har...
|
Software Common Hacks and Counterattacks: A Guide to Protecting Software Products against the Top 7 Piracy Threats
Software piracy continues to be a growing epidemic. This white paper examines prevalen...
|
By Larry O'Brien
July 15, 2008 —
The relational data model: Great idea or greatest idea? In the 1980s and 1990s, this was the only debate in corporate data centers. The relational calculus formalized by Edgar Codd in the late 1960s provided the underpinnings for commercial databases that, by the 1990s, had reduced alternative structural models to afterthoughts.
Even the rise of the object-oriented programming model, which famously has an “impedance mismatch” with the relational model, failed to create significant market share for alternative databases. Aside from the great clouds of “dark data” locked away inside documents, the large majority of corporate data is stored in relational databases that model the data as a series of tables and columns and rows.
Pragmatically, the distinguishing characteristic of a relational database is the joining of tables to model associations and their multiplicity. Take e-mail addresses, many of which might be associated with a single person. Although tables with columns like “email1,” “email2” and “email3” (or “phone1” or “creditcard1,” etc.) are all too common, any database modeler worthy of the name would see a “one-to-many” relationship and create a separate “email” table related to the “person” table by a foreign key. (Eventually, the separate tables might be combined or turned into a view as part of a performance-justified “denormalization,” but that is a topic for another day.)
Programmers love normalized data. Create, Retrieve, Update, Delete (CRUD) operations have to work only on one location. The furthest reaches of the data model can be navigated by stitching together enough SQL “join” clauses, and components such as data grids make presentation straightforward to develop. Programmers look at an entity-relationship diagram and see a map that can guide them anywhere.
Users hate normalized data. Getting an answer requires opening multiple windows, jotting down and searching for identifiers, and backtracking to ensure that the change they made in one table is indeed related to the need they have in another. A user looks at an entity-relationship diagram and, to the extent he can make sense of it all, sees a grid of I-beams high in the air with no safety net.
Keeping users away from the raw data—and the raw data structure—is generally a fine idea. Users should be describing their ongoing business needs, and we programmers should try to deliver valuable information and smooth the process of business. That means figuring out the particular queries and sequences that most rapidly address their needs. There will always be a place for the development of database applications.
There’s a third group, however, that is poorly served. Whether you call them data-support staff or data administrators (drawing a distinction between those who administer the data and those who administer the database), larger businesses and corporations need to manipulate their relational data in a way that is not quite ad hoc but that is less structured than an end-user application would be. These are the people who have to be able to edit essentially all the data—fix ZIP codes, remove typos in phone numbers, figure out that the display of the price had changed because the discount expiration date had been reached, and so on.
Moderately complex corporate relational databases might have between several dozen and a few hundred tables. While tools such as Visual Studio’s LINQ data modeler can digest such models with impressive ease, the simple volume of screens needed to search and edit these typical databases easily can become burdensome. Often, companies choose not to develop such internal applications, at least until they realize just how much time their senior developers and DBAs are in SQL Server Management Studio typing minor variations on the same SQL queries.
Every time I point Access at a SQL Server database, I expect it to have something that seems to me a no-brainer feature: If a column is a foreign key to another table, it ought to be a hyperlink. That’s 80% of database navigation right there. Sure, many-to-many is a little harder, many foreign keys are not explicit, and there are many problems for which an SQL query would be much better than point-and-click editing.
The solution I’m suggesting requires a definite less-is-more approach to tool design. I’m not asking for a fourth-generation language; 4GLs inevitably grow to include report generators and procedural constructs, as well as 800-page reference manuals. Nor am I asking for an application in which users can “make your own database without programming,” applications that, at best, use wizards to do what an entity-relationship modeler does by choosing a multiplicity. Not that I have anything against either of those types of application, it’s just that I think they inevitably move toward attempting to be complete solutions for either developers or end users.
What I’m suggesting is a class of tools for data administrators that is something short of the blank canvas you get with Visual Studio and SQL Server Management Studio, but something more than the “populate a grid from a database” data pump you get in Excel. I think there’s a market.
Larry O’Brien is a technology consultant, analyst and writer. Read his blog at www.knowing.net.
Related Search Term(s): Databases
Share this link: http://sdtimes.com/link/32483