Re: Data Models and Levels of Abstraction

On Jan 17, 10:21 am, Rob <rmpsf..._at_gmail.com> wrote:
> Q2. Can RM be mapped to SQL? (The inverse mapping is not relevant
> here.) If not, why not?

There is a lot in SQL which is not there in the RM. Admittedly, those features were introduced in ad hock manner, which prompted SQL criticism by purists.

1. Bags. Yes, bag semantics is more complicated compared to sets but I fail to see the issue here. Does it affect one's ability to do joins, projections and unions? In my (rather extensive) practice I never experience any problem. The rest of the operations (such as minus) are so rare, that we don't even have to mention them, although I can't recall any problems/inconsistensies either.
2. Grouping and aggregation. This is SQL feature that really shines. For mathematically inclined when we group relation tuples we establish some equivalence relation first. For example, equivalent employees are the ones that belong to the same department. This equivalence relation partition set of tuples into equivalence classes so that we collapse the set of tuiples into the set of classes, and assign one or several aggregates (e.g. count() -- the number of elements) to each class.
3. There is a normal form for select-project-join queries (ref. the Alice book). Basically, any sequence of nested select, project, and join operations could be flattened into a single select-project-join query. This theoretical result has been excellently captured by the SQL "select...from...where" clause.
4. Functions are relations. SQL is fairly restrictive on how you join a function with the rest of the query, yet calling functions in SQL is one of the most powerful features adding to SQL success.

In a word, there is more in SQL that meets the eye. There doesn't seem anything that might challenge the SQL leading role in database industry for at least a decade. Received on Thu Jan 17 2008 - 20:20:00 CET