Re: database systems and organizational intelligence

"Alan" <alan_at_erols.com> wrote in message news:2hm938Ferg5oU1_at_uni-berlin.de...
> 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.

You had me with the first part of the sentence and lost me with the last part. I might be more well-read than you have guessed. Of course that is a reflection on me as well.

> It answers all of your
> questions, and then some.

I'm skeptical of that. Does it answer my main question of why implementations that are based on relational theory and book-learning related to databases do not seem to translate into better bang for the buck software solutions for companies than those that are not, even those that pre-date them? [And does it explain why it can be more difficult to go through menopause than childbirth!!?]

> You will read more about this topic than you ever
> thought existed, or dare say, even care about. They get _real_ deep.

might be over my head then

> 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.)

Yes, just as "relation" and "relational" can -- thus the glossary for our discussions.

>
> >
> > > 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?
uh, mathematics texts (from grad school, so they are dated -- have the defs changed in the past few decades?)

> That is one of
> the most uniformed remarks I've ever heard,

are you trying to bait me or do you really think my definition of a mathematical function to be significantly flawed? Could you give me yours?

> 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.
I don't say they are the same, but that they are interrelated and hard to tell apart -- two sides of the same coin. We can certainly define them as being different, but a function in mathematics, is, by definition, a relation in mathematics. Codd started with mathematical relations and functions are one type of relation. It is quite simple mathematics -- do you want me to google for some sources for you?

> 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...

Until you understand what I see as the definitions of mathematical relations and functions, you will not understand what I mean, I'm sure. So that would be the place to start. I'm not solo on this - there is an entire discipline -- mathematics -- from which I am extracting these definitions.

>
> >
> > > 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.

I'm with you there.

> Object
> code is data to the compiler.

Still tracking.

> Remember, I said that code can be data (the
> Oracle example).

OK, code can be data - can data also be code? I like the "with respect to" approach -- one man's data is another man's code and vice versa.

> 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.

I'm not trying to make it profound -- just understandable and usable. Partitioning the design of software into code and data often leads to very poor designs. The two are too intermingled, particularly related to Types, Constraints, and other Rules for the data.

> >
> > >
> > > 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.

I think a few others in this thread have indicated that it is not quite as clear as you seem to think it is. I'm not trying to be difficult, but there is not a chasm or even an identifiable crack between data and code as some suggest.

>
> > > 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,

If I chose a quote of the week as Pascal does, then I might pick that one -- "definitions supported by proofs" -- do you want to restate or retract that? I would love to see an example of a proof for any definition.

> not opinion. Yes, it would be handy to have
> an on-line glossary, but not one based on opinion.

we were going for some consensus and your opinions can play into that. If you have any proofs for your definitions, those would be even better. smiles. --dawn Received on Thu May 27 2004 - 16:20:00 CEST