Data Models and Levels of Abstraction
Date: Thu, 17 Jan 2008 10:21:22 -0800 (PST)
Message-ID: <59ba33c5-e551-4965-82e6-0ae415b6a588_at_t1g2000pra.googlegroups.com>
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?id=806891&coll=ACM&dl=ACM&CFID=50368499&CFTOKEN=61989412
Let me start out with a couple quotes:
<quote>
1 WHAT IS A DATA MODEL?
It is a combination of three components:
- a collection of data structure types (the building blocks of any database that conforms to the model);
- 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;
- 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-
-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 Received on Thu Jan 17 2008 - 19:21:22 CET