Path: newssvr20.news.prodigy.com!newsmst01a.news.prodigy.com!prodigy.com!atl-c02.usenetserver.com!news.usenetserver.com!border1.nntp.dca.giganews.com!nntp.giganews.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: "Alan" <alan@erols.com>
Newsgroups: comp.databases.theory
Subject: Re: database systems and organizational intelligence
Date: Thu, 27 May 2004 09:34:33 -0400
Lines: 131
Message-ID: <2hm938Ferg5oU1@uni-berlin.de>
References: <Diwrc.1887$L.919@news-server.bigpond.net.au> <72f08f6c.0405231341.49d8d675@posting.google.com> <1xcsc.6800$L.1262@news-server.bigpond.net.au> <e4330f45.0405240416.44eaaa24@posting.google.com> <40b1f055@post.usenet.com> <c90rd7$uvj$1@news.netins.net> <40b48b19.9483676@news.wanadoo.es> <jrmdnYPhReTWEindRVn-uA@comcast.com> <c92552$lnf$1@news.netins.net> <vM-dnfgxwLmtOCndRVn-uQ@comcast.com> <c92dtl$oan$1@news.netins.net> <2hk09hFdml8oU1@uni-berlin.de> <c92r6d$23i$1@news.netins.net> <2hkd28Fe0ou7U1@uni-berlin.de> <c933tu$63u$1@news.netins.net> <gvdtc.22728$4%3.3430@nwrdny01.gnilink.net> <c94eft$sfl$1@news.netins.net>
X-Trace: news.uni-berlin.de I4qseUFHiBMsZD/FXv5LCgwbQKLDfX28vdgh507mMjH6G0VMkf
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1409
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Xref: newssvr20.news.prodigy.com comp.databases.theory:27209

Answers in line, marked with =====>>>>>


"Dawn M. Wolthuis" <dwolt@tincat-group.com> wrote in message
news:c94eft$sfl$1@news.netins.net...
> "Alan" <not.me@uhuh.rcn.com> wrote in message
> news:gvdtc.22728$4%3.3430@nwrdny01.gnilink.net...
> > Top-posting - please don't shoot me.
> >
> > The definitions, examples, and explanations I've given of functional
> > dependency are either quoted directly or paraphrased slightly from
> > "Fundamentals of Database Systems"  3rd Ed. by Elmasri & Navathe. This
> text
> > is used in Masters programs at major universities.
>
> I haven't read this book (do you recommend it?),

=====>>>>> Yes, I recommend it, especially for you. It answers all of your
questions, and then some. You will read more about this topic than you ever
thought existed, or dare say, even care about. They get _real_ deep.

but from this text you are
> able to determine that functional dependencies have nothing to do with
> functions?

=====>>>>> Sort of. I didn't determine anything. It is demonstrated by
proofs in the book. This is what it is- you just don't want to believe it.
BTW, words (like  "function" and "functional") can have more than one
meaning, even in a single realm like IS. (Yes it would be better for
everyone if "they" didn't do that, but that's the way it is.)


>
> > GPA as you have described is an example of "derived" data. It is based
on
> > data already stored. Of course code and functions (which are just
> > pre-written chunks of code)
>
> Functions can be specified with code.  A function is, by definition, a
> relation.

=====>>>>> Where did you ever get such a ridiculous notion? That is one of
the most uniformed remarks I've ever heard, except for American Idol's Simon
Cowell stating there are no mountains in Georgia. See next answer for more
details.

  I wouldn't call any relation, including a function a chunk of
> code,

=====>>>>> Have you ever written a function? I have. It is a chunk of code.
A relation is a specific set, and is therefore data. PLEASE STOP INSISTING
THAT THEY ARE THE SAME THING! THEY ARE NOT, NO MATTER HOW MANY TIMES OR WAYS
YOU TRY TO CLAIM THAT THEY ARE.

but there is the specification (formula) for the function, which is
> encoded in some way.

=====>>>>> I have no idea what you are talking about. There is a business
specification that a programmer codes into a program or a function within a
program. Maybe that's what you mean...


>
> > are needed to extract data, but that does not
> > mean that code and data are the same thing. You are essentially saying
> that
> > driving a car and directions to a destination are the same thing.
> Directions
> > are data (information, actually), driving is code (specific actions
taken
> to
> > affect a certain result). They are two different things.
>
> In that case, source code is data and object code that is "running" is
code,
> right?  What about data that is fed as input to code to alter the course
> (e.g. parameters)?  Is it data as coded (source code) and then code when
> applied during execution or does it remain data throughout?  If source
code
> is executed by an interpreter instead of a compiler, then does it switch
> from being instructions (data) to code when the interpreter is taking it
in
> as parameters?

=====>>>>> It is relative. Source code is data to the interpreter. Object
code is data to the compiler.  Remember, I said that code can be data (the
Oracle example).


I don't think you have hit the nail on the head with this
> distinction of directions vs. driving, but I could be wrong (it's happened
> before).

=====>>>>> The driving analogy was just an attempt at trying to explain the
idea in another paradigm. Code is code and data is data. They get
intermingled in a program. It is really that simple. Stop trying to make it
profound. It isn't.


>
> >
> > Or, try this (wish I had thought of this sooner)... data:noun/code:verb,
> or
> > more accurately, data:subject/code:predicate.
>
> That's a broad stroke, and acceptable as such, so perhaps I'm suggesting
> that we can verbize the nouns and nounize the verbs and it is not all that
> clear where to draw the line between code and data.
>

=====>>>>> It is very clear, you just refuse to admit it.


> > The cdt glossary was written by whom? They have what credentials?
>
> It is in process and folks from this list are contributing, so the
> credentials are varied.

=====>>>>>  There are many excellent BOOKS on the subject that contain
definitions supported by proofs, not opinion. Yes, it would be handy to have
an on-line glossary, but not one based on opinion.



> --dawn
>
> <snip>
>
>


