The Practical Benefits of the Relational Model

Thanks to Paul G. Brown for the thread, "The Theoretical Foundations of the Relational Model." In the same spirit, I would like to present a (partial) list of practical benefits that the Relational Model enables. Keep in mind that I am NOT necessarily describing SQL as it does fall short of many of these points. Please feel free to point out any major ones I miss.

-ALL integrity constraints (AKA business rules) can be enforced
declaratively. Why is this good?:
-Less work - ...just tell the system what must be "true"
-System optimizable - if I say that only Green items can be put into the
'parts' table, than when I ask for all Red parts, the system can 'know' that it isn't even worth looking for Red parts.
-Transactional implications - with procedural code, the developer must
handle certain transactional implications like when two tables (or objects ;) reference each other.
-Less buggy - no procedural code means that bugs are isolated to the
well tested system, not the app developer's code.
-Easier to maintain - just modify the constraint definition.
-For more read "What not How" from C. J. Date.

-Transaction management is (can be) system provided. OO engineers are
re-inventing this wheel, but worse they are moving it into the domain of the application developer. Have you written a 'compensating resource manager' for your object hierarchy lately (so you can rollback/redo changes)? Or perhaps tried to implement transaction isolation across a distributed set of objects? Just the fact that the RM allows the system to COMPLETELY automate all facets of transaction management should say something!

-Paging/buffering is (can be) system provided. Due to the
implementation independent nature of the RM, main memory vs. long term storage is not part of the application development paradigm. The result is that memory management can be handled (and optimized) by the system, not the application developer. In the RM, the app developer merely deals with global and/or local variables. How those variables are loaded, stored is completely up to the system. In OO, the developer is responsible for 'persistence'; granted the OS will most likely manage the paging of main memory at a low level.

-Applications can be completely described independent of a particular
platform implementation. Applications that don't become obsolete just because platforms change... what more is there to say on this!

-Application logic can be centralized rather than scattered throughout
the application layers.

-Mathematical style data manipulation and analysis lets us both 'look
at' AND update our data from ANY perspective.

-Conceptual simplicity. There are only a few concepts to learn in the
RM, and they are relatively simple. This makes training, implementing, and maintaining application much easier. To date (pun intended), no one has presented a model that is simpler (and is complete).

-Concepts are well defined. There are not the gray areas found in OO...
like which class to put a 'binary' method into, or whether to use a method or a 'write-only' property. How about the fact that the V-table is tied to the type, not the operator (so no future 'virtual' operators can be defined by someone other than the type designer).

-It is not necessary to traverse logically un-related information. In
OO, for example, I may decide to put SaleItems 'under' (or as a list within) Sales. Then when I want to see how many we have sold of a particular part, I can't just join the Parts with the SaleItems, I have to get to the SaleItems 'through' the Sales. This argument applies to any data management solution that arbitrarily decides that all data is hierarchical.

-Specialization by Constraint and Generalization by Constraint. In
English this means that I can treat an ellipse as a circle if the ellipse 'really is' as circle.

-Performance tuning without messing up my application logic. The RM is
a CONCEPTUAL model and allows for an implementation to do really about anything so long as the prescribed logic is preserved. Data could be stored in any way (including redundantly or distributed) without changing the application logic.

-User interface derivability. It is possible (though never accomplished
until recently) to provide COMPLETE user interfaces that are derived from any perspective of the data. This is only possible due to things like updateable views (expressions) and declarative integrity rules. People (even relational folks) are very skeptical about this, but I have seen it work.

-"metadata" inference. In other words, it is possible, with a
Relational implementation to no only know information like referential integrity constraints (FKs), keys, and other meta-data about base tables, but also about any arbitrary expression. This allows us, for example, to ask for the "default" column values of an arbitrary expression, or to know what the implicit references are of any expression. This also happens to be one of enabling factors for user interface derivation.

-System provided optimization. A Relational system can optimize at many
levels. The internal (storage/query processing) level can optimize physical access paths based on heuristics. Semantic optimizations can be made by analyzing and transforming the algebra. Extended literals, Contradictions, and Tautologies can be detected and optimized by the system. Further, the system can optimize the external (or consumer/user interface) of the system by detecting constraints that can be evaluated on the client where they can be enforced without a network round-trip.

-Automatic navigational transformations. A system can automatically
re-formulate expressions (again due to the formal algebra) to navigate, "search within" and fetch subsets of data AS THE USER CONSUMES IT. In other words, the developer doesn't have to pre-determine the granularity of data to be retrieved by the client. The system can "pipeline" the information to the client as it is needed. The performance, memory, bandwidth, and productivity benefits of this item alone are staggering.

-Fewer maintenance points. With the application logic centralized,
there are few to zero 'copies' of the application schema to maintain.

-Data retrieval/manipulation is provided by the system. This may seem
like a no-brainer, but in the OO realm, if you want a Join, you write a Join. You don't get these set-based operations 'for free'.

-Well defined and formal "model" for type inheritance. This actually
isn't a Relational thing because type is an orthoginal (apples and oranges) concept to the RM. I still think it is worth making explicit because it should be clear that OO doesn't have an exclusive on the concept. Well defined inheritance is beneficial because the SYSTEM can help us enforce domain constraints and such. Not to mention providing the app developer with the ability to rely and deterministic and well defined behavior from the system.

Now I should state that I use an OO programming language daily. As C. J. Date has pointed out, OO brought one... perhaps two good concepts to the table (neither of which are original but never mind):
-User defined types (OOP encourages the practice)
-Type inheritance.

OO is is not a "model" and is certainly not a data management solution.

--

Nathan Allan

--

Posted via http://dbforums.com Received on Tue Aug 27 2002 - 22:57:02 CEST