Re: Does Codd's view of a relational database differ from that ofDate&Darwin? [M.Gittens]
Date: Tue, 07 Jun 2005 19:10:21 +0200
Message-ID: <42a5d50f$1_at_news.fhg.de>
erk schrieb:
> Alexandr Savinov wrote:
>
>>Another point is that variable is something that stores a reference.
>
>
> A variable stores a value. The value it stores can change over time.
> References and pointers are implementation "niceties" that are often
> overexposed; they are, in essence, variable-variables. Contrast with
> relational theory, in which relations are the only variables.
>
>
>>This reference may point to >>- one object (record), >>- a collection of records which is dynamically defined (for example, a >>result of some query), >>- a table/domain which is statically defined in the schema >>- anything else that can be represented by reference
>
>
> References without limitations, while useful in some meta-theory, are
> invitations to unrestrained graph theory. Not what most practicioners
> need, as relational and OO and other languages all reign this in in
> different ways.
A constraint for variables is type, which specifies from where we are allowed to take objects (type is also a reference but it references a scope or container or table).
I prefer to distinguish only two types of references and variables: - variables for referencing individual items/objects/records, - variables for referencing collections (of items/objects/records),
>>So you are right that domain is not a variable but reference to a domain >>can be stored in as many variables as we like just like we can store in >>variable references to records or result sets.
>
>
> Your previous example showed a changing domain, n'est-ce pas?
>
>
>>If we define null as absence then as a >>minor advantage we avoid problems with aggregation because absent things >>are simply not visible, i.e., null values are skipped.
>
>
> So we can't count the number of "objects" that "contain" a "null
> value"?
Objects exhibit themselves by having 1. a reference (should be constant), and 2. properties (may change). So when we say that an object is absent because of having null (having no property) we mean that it is absent only along one concrete dimension. If we count references (by means of COUNT(*)) then it will return all objects in the domain (reference are not null by definition - if it is null then the object is deleted or marked as non-existing). But we get objects existing in some dimension and then count them by their values in this dimension. In this case objects with null values for this property should not be counted (if we striclty follow the semantics of absence).
>>No, and this precisely what I wanted to emphasize. Because you cannot >>count what does not exist.
>
>
> So an object can "contain" a null, but we can't be aware of that fact
> because the null cannot be counted? Is this some baroque application of
> Heisenberg's Uncertainty Theorem to data management? :-)
No, I would be glad to reach such a level :-)
The problem as I noticed is what concretely we are going to count. Any object has its semantics distributed globally over the whole database. This means that an object taken by itself is meaningless - it has only a reference. So we can count objects by references and find all of them. Further we can count objects as they exhibit themselves along available dimensions, i.e., depending on their properties (see above). Then we can count the same objects as they exhibit themselves in other parts of this model (the notorious concept-oriented approach by the way).
>>The problem is to understand that different >>things may exist in different dimensions.
>
>
> Projection is the usual reference here, but projections aren't
> completely unrestrained as you would have them.
Yes, projection is the same as aggregation (do not understand me absolutely), i.e., aggregation is the process or a procedure which shows how information/objects look like from some side/dimnension.
Deprojection is an opposite process (called also cylindrical extension) but has a little use in data modeling.
-- alex http://conceptoriented.comReceived on Tue Jun 07 2005 - 19:10:21 CEST