I'd like to end the thread I started 1/1/08 ("Something new for the
New Year (2008)") and begin a new post that is not about RM or any
other specific data model, but rather, the real and perceived
differences between them. As a starting point, I recommend Codd's 1980
3-page paper: "DATA MODELS in DATABASE MANAGEMENT". If you are an ACM
member, you can get your own copy here:

http://portal.acm.org/citation.cfm?i...TOKEN=61989412

Let me start out with a couple quotes:

<quote>
1 WHAT IS A DATA MODEL?

It is a combination of three components:

1) a collection of data structure types (the building blocks of any
database that conforms to the model);
2) a collection of operators or inferencing rules, which can be
applied to any valid instances of the data types listed in (1), to
retrieve or derive data from any parts of those structures in any
combinations desired;
3) a collection of general integrity rules, which implicitly or
explicitly define the set of consistent database states or changes of
state or both -- these rules may sometimes be expressed as insert-
update-delete rules.
</quote>

<quote>
Numerous authors appear to think of a data model as nothing more than
a collection of data structure types. ... In comparing data models
people often ignore the operators and integrity rules altogether. When
this occurs, the resulting comparisons run the risk of being
meaningless.
</quote>

<quote>
A data model may be used in any of the following:
1) as a tool for specifying the kinds of data and data organization
that are permissable in a specific database;
2) as a basis for developing a general design methodology for
databases;
3) as a basis for coping with evolution of databases so as to have
minimal logical impact on existing applications programs and terminal
activities;
4) as a basis for the development of families of very high level
languages for query and data manipulation;
5) as a focus for DBMS architecture;
6) as a vehicle for research into the behavioral properties of
alternative organizations of data.
</quote>

<quote>
Many people fail to separate in their minds different levels of
abstraction. A specific example of this is the failure to realize that
tuples are at a higher level of abstraction than records (one is not
allowed to use the contiguity of components of tuples, whereas one can
use the contiguity of fields ina record).
</quote>

So, to kick things off, here's my first two questions:
Q1. Are Codd's 1980 pronouncements still valid today?
Q2. Can RM be mapped to SQL? (The inverse mapping is not relevant
here.) If not, why not?

Rob

On Jan 17, 10:21*am, Rob <rmpsf... (AT) gmail (DOT) com> wrote:
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.

On Jan 17, 10:21*am, Rob <rmpsf... (AT) gmail (DOT) com> wrote:
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.

On Jan 17, 10:21*am, Rob <rmpsf... (AT) gmail (DOT) com> wrote:
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.

On Jan 17, 10:21*am, Rob <rmpsf... (AT) gmail (DOT) com> wrote:
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.

On Jan 17, 10:21*am, Rob <rmpsf... (AT) gmail (DOT) com> wrote:
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.

On Jan 17, 10:21*am, Rob <rmpsf... (AT) gmail (DOT) com> wrote:
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.

On Jan 17, 10:21*am, Rob <rmpsf... (AT) gmail (DOT) com> wrote:
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.

On Jan 17, 10:21*am, Rob <rmpsf... (AT) gmail (DOT) com> wrote:
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.