Re: database systems and organizational intelligence

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

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c94eft$sfl$1_at_news.netins.net...
> "Alan" <not.me_at_uhuh.rcn.com> wrote in message
> news:gvdtc.22728$4%3.3430_at_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>
>
>
Received on Thu May 27 2004 - 15:34:33 CEST