optionsScalper

Please tell me Relational Algebra is not dead

It seems that a lot of "database guys", i.e. software developers, architects, DBAs, etc., lack an understanding of Relational Algebra (RA) and Relational Calculus (ok, at least two kinds of RC). If you fancy yourself an architect, have experienced database performance issues, have used the word "normalization" but don't have an idea what RA and RC are, take a moment here.

Let's start with the fundamentals. If you think that you know what a function and a relation are, double check by looking here. After reading this page, you should have a clear understanding of Set, Relation, Range (or codomain), Domain, Function, Surjection, Injection and Bijection.

Let's continue. RA and RC need some formalization. I won't even attempt to provide definitions because someone else has done a great job: Relational Algebra, Domain Relational Calculus and Tuple Relational Calculus. I use Tuple RC for any work that I formalize.

E.F. Codd introduced RA and RC in 1972. Codd is generally considered the father of relational database theory and relational databases. Simply put, an implementation of a relational database receives SQL statements (RC), transforms the statements into query plans (RA) and executes the plans through the query processor. There's a lot more going on in the database than this simplified version attests to, but it is important to note that statements are made in the RC and transformed into RA. If you want more information, purchase "An Introduction to Database Systems" by C.J. Date.

It's also important to note that SQL is a less than complete form of the RC. Cunningham's wiki is a definitive source for a great deal of information, but this page distracts from the problem. I'm not sure that this is the proper way to think about SQL as well. I'm not interested in taking a swipe at Fowler or Cunningham because I learn a great deal from their work. The problem is that SQL does not implement RC entirely and completely.

I could stop here, but I think I should include coverage of normalization.

There are six common rules that define precisely a relation in relational database practice:

1. Each attribute stored in the relation is single valued. At a row-column intersection in a database table, one and only value is held.
2. The order of attributes (columns) is not significant.
3. The order of tuples (rows) is not significant.
4. All values for a given attribute (column) must be of the same type (domain).
5. All attribute (column) names must be unique.
6. All rows are separate and distinct, i.e. no two tuples in a relation are identical.

In Yoda-ese: "This do and have relations you will. Do it not and forever you will be haunted by the chaotic-data side". If your data in your database satisfies these six rules, not allowing for any subjective interpretation, your data is said to be a relation. For those who subscribe to the practice of normalization, these rules must be satisfied for your database to be classified as First Normal Form (abbreviated as 1NF or NF1). Please note that NF1 historically referred to database systems that followed the above rules except for #1.

Another (and more comprehensive) view of normalization can be found here.  In fact, the wiki editors have asked that this page be "dumbed down".  DON'T DO IT.  It covers the essentials.

So stop looking at your data as though it was magically allowing the database to store it. The RA and RC used to construct the database and manipulate the data are formal disciplines. These principles should be used in your applications as well. Take the time to learn these. I promise that they will make you a better person. And your mom will love you all the more . . .

posted on Saturday, May 14, 2005 8:01 PM by optionsScalper