Data Models and Levels of Abstraction
Date: Thu, 17 Jan 2008 10:21:22 -0800 (PST)
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:
Let me start out with a couple quotes:
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-
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.
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.
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).
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