vldm10 wrote:
I doubt if I would get the drift of the rest of your message no matter
how hard I tried, so I snipped it, but would like to ask if you would
please give a link to Reiner's post about 'union is always a join'. I
remember sending a series of messages with that subject. It was a
provocation that is slightly reminiscent of the rest of your post, which
has to do with 'update history' as far as I can tell. Whereas my motive
was to discount history, ie., if a relation's extension can be
materialized, then I was hoping that people might see the way clear for
an implementation to choose an arbitrary history, but one that would be
consistent for all extensions in some sense. This seemed an easy way to
get around the so-called view update problem, but I gave up on it as the
only person, as I recall, who gave the slightest hint that he got the
idea was Bob B and he didn't care to elaborate (which I don't mean as a
complaint, just an observation).

On Jul 8, 5:30*am, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
You can try at:
http://groups.google.com/group/comp....d52f2527d24cb#

vldm10 wrote:
Thanks, not sure if I had ever noticed those messages before but if I
had I probably would have discounted them as soon as they suggested that
dependencies are somehow intrinsic to the question when at most they are
only a way to enumerate or differentiate cases (a misleading way if you
ask me even though I know Date uses them, maybe that's why he concludes
certain updates are 'unsafe'. Apart from that the various 'principles'
that he invokes make me uncomfortable because they suggest that some
approaches are more 'proper' than others, somehow more 'inherent', when
in fact and in the first place there is no inherent insert or delete in
the bare RM. How an implementation language defines the assertion and
retraction of facts is closer to a matter of policy than of principle,
so I sometimes wish Date would say 'policy of ...', instead of
'principle of ...'. People who want to avoid mysticism need to
recognize the place of logic in an rdbms, where it starts and where it
ends. When they suggest a language that can retract certain facts but
not assert those same facts, or vice-versa, I think their language
definitions need some more work, to put it mildly!).

On Jul 10, 4:34*am, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
If you mean FDs and intrinsic properties then note that FDs are on
language level and intrinsic properties are not. Note in my paper
(see 3.3.3) that I connect intrinsic properties with universal
attributes, m-attributes, entity’s attributes, concepts and extensions
of concepts.

Note that C. Date in his book “An introduction to database systems”
starts his section about DB design with FDs and in fact, it is about
FDs and NFs. But one thing confuse me in this section. He didn’t write
what are steps in DB design. It will be good if you can write for this
user group what are the first two (or three) steps in the DB design
using RM.

Yes, logic is great science, precise and strict. But let me give you
two examples, which are on basic level in logic – it is about
attributes and truth:

1. One will tell you that lemon is lemon even if its (attribute) color
is green.
2. In some db application about historical persons, you will put (for
example) that B. Mussolini had blue eyes. But he had gone from this
world before you was born.

Vladimir Odrljin

Snipped nonsense


separate concepts that are to remain unbound in definition purposes.
Since the intermix between the two concepts is the *premice* of the
logic used in the beginning of your response to paul, I can only
*logically* assume that I was right to snip most of it.

On Jul 14, 5:37*pm, Cimode <cim... (AT) hotmail (DOT) com> wrote:
My first example infact is from Hillary Putnam. I suggest you to try
as first step some introducing text about his work, and then in next
period, try more complex.
My second example is from one of the most important school in logic.

Snipped
significant and/or meaningful, in any sense other than metaphysical,
is totally unworthy of inquisitiveness.

Quite the contrary in fact. As far as computing is concerned, the
further one gets away from such nonsense the better.

vldm10 wrote:
Well, there aren't any mainstream languages that I've heard of that
express FD's, for example I don't believe there is a way in SQL to
specify a key in a SELECT stat;ement. Sorry to break my rule of posting
when I've had more than one glass of plonk, but the above supposition
would likely be easy to answer if I had ten. For some perverse reason,
I have a fascination with such rhetoric because no matter how well it is
replied to, nobody who reads any reply, not just mine, will understand
anything more than they did before! My question would be why do you
post this stuff here? There must be plenty of non-technical, social
groups where the audience can make sense of any mumbo-jumbo you throw at
them. I remember making many trips to one large US state where rote
ruled and if some methodology or other mentioned, say, intrinsic
properties, everybody involved was thereupon expected, for all time,
world without end, to take care to distinguish those from the
non-intrinsic properties. At one time, the cost of typewriters and the
time needed to learn them made this form of illiteracy not so common.


I doubt if it would be 'good' for people who have spent more than the
ten years or so that I spent excising phony requirements or who have
studied db theory more carefully than I have (I suspect that most of
those don't post nearly as often as I do) but assuming the applications
step have already been done (for example, why do you think you have an
app here? or what do you think your app is?), there are obvious first
steps that various people might re-arrange in ways they prefer: 1) find
out what answers are needed from the db, 2) find out what facts are
available to infer them from, 3) reconcile the results from 1) and 2)
and 4) organize the facts. Step 4) is susceptible to various
techniques, normalization among them. I think Date should have not
called that chapter 'database design', rather 'database implementation
tools/techniques' or similar.

I don't know why you might suspect I had anything to say about truth.
It does remind me that most participants here are just looking for a
way to appear to fit in commercially in an immediate way and have no
real interest in basic theory. In any field I know something of, that's
usually the last thing I care about and here it's generally a waste of
time for db practioners to talk about truth. Theory and practice trump
truth in every field, including the religious pursuits and other sops to
natural human confusion. Maybe it has something to do with the term
'truth-functional' and the so-frequent supposed connection from that to
the word 'reality' by semi-literates who couldn't tell a field from a
context. The very first question that a dbms must deal with is how (in
the case of an rdbms) and to what extent logic is to be applied. There
are a few reasons to use FOL in the first place, one is to re-phrase
declarative statements for machine efficiency. How a supposedly popular
language chooses to allow us to express ourselves to a machine has
nothing to do with logic. From my experience it is a certainty that
very few users will ever apply FOL to predict or prove results and they
will certainly not ever graviitate to a language that requires them to
express logic overtly. (I remember the only logic exam I ever had to
write, at least 100 Arts students out of about 200, walked out after ten
minutes. I was very impressed at how they could finish a three-hour
exam so quickly! Later I knew CS professors who had never taken a logic
course, let alone taught one.)


Religious theorists try to tie up logic with truth all the time and
claim various forms of both for their own. To the man or woman in the
street they will proclaim various self-serving 'logics' to do with
propriety of some kind, usually the proper management of the most basic
human motives and inescapable behaviours. The Vatican never has the
guts to admit it is in basic competition with Hollywood in the sexual
area, usually disguising its motives by the introduction of an
essentially logical term, 'morality' and never mentioning the aspects of
sexuality that don't contribute to their purpose, which has to do with
expansion and control, never truth. Now, we talk here about a subject
whose purpose is obviously economic, ie., commercial. It was big
business centralization and accountants who got this field off the
ground. What has truth ever got to do with db?


My amateur language is perhaps partly responsible, but as I suggested
above, it's not all my fault and I would have hoped if you took the
trouble to respond to my polemics that you would have said something
about what I think is a basic scandal, the propagation of systems that
go in one direction but not another. I think the db industry is very
much playing the same game as the tailors of the Emperor's New Clothes,
putting out systems that let people paint themselves into corners, you
can insert but you can't delete, or the other way around. This is a
tyranny of the technocrats if there ever was one. I read somewhere
that McGoveran is writing a book which is at least in part about this.
I hope to see it someday (in this rote world). Apart from that, I
think you are posting this stuff to the wrong group..

On Jul 15, 7:30*am, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:


DB theory didn't solve the problems posted in ½this stuff½;
With ½Historical data½ and ½temporal data½ current Relational
theory is completely unsuccessiful.
The first time we have software implementation of a paper which is
from ½temporal data½ and it is implemented in Microsoft DB software,
maybe one day it can become a part of OS, as it is ½dot net½.


This is not DB design. However maybe you can try these four steps to
locate, organize, systematize, arrange and coordinate the facts.


Did you consider the possibility to lay off the coffe.

Vladimir Odrljin

I wrote:

Brian replies:

No, Brian. These deletes, inserts, and updates are about statements
of fact about the world, which can change to reflect new or changed
observations, even when we haven't identified any objects that these
statements are about to the extent you appear to deem necessary. I can
observe Mary's goldfish and its medical condition, and truthfully record
that in my database, two days in a row, *regardless of* whether I can
tell whether we're dealing with the same goldfish in both cases.

We may choose not to care and it won't be a problem.

But for goldfish, at least we know they are identifiable in principle.
This is not so easy for other types of objects; say, species of fish,
countries of the world, or clouds.

If you mean: once you commit to being able to identify objects
across changes, you're right. But it becomes a rather tautological
statement.

I feel you keep confusing things and statements about things.
A relational database records statements, usually about things.

--
Reinier