Re: database systems and organizational intelligence
Date: Thu, 27 May 2004 13:14:22 -0400
Message-ID: <2hmlvdFep7foU1_at_uni-berlin.de>
"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
news:c94tev$3vu$1_at_news.netins.net...
> "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.
=====>>>>> I mean that you are very curious, and could learn a lot from the book.
>
> > 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?
=====>>>>> It very well may. In appendices that used to be chapters, there is discussion of the network and hierarchical data models. There are new chapters on current trends, such as deductive databases. The book is almost 1000 pages.
[And does it explain why it can be more difficult to go
> through menopause than childbirth!!?]
=====>>>>> Yes, in chapter 50ish.
>
> > 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
=====>>>>> It's over almost everybody's head in many places, but there's enough there regardless.
>> > =====>>>>> Sort of. I didn't determine anything. It is demonstrated by
> > but from this text you are
> > > able to determine that functional dependencies have nothing to do with
> > > functions?
> >
> > 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.
=====>>>>> Exactly, unfortunately.
>> > >
> >
> > > > 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?)
=====>>>>> I think you may have confused some ideas since then... See next answer.
>
> > 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?
>
=====>>>>> Flawed. A function takes inputs, specifies operations (or causes operations to be performed), and produces an output. Has nothing to do with "relations" in a data theory world, unless the functions are operating on sets, and even then, the function is not a relation. It is a function.
> > 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?
=====>>>>> Look, I have made it as clear as it can possibly be. In
relational theory, a functional dependency is not a relation. A relation is
a set. A functional dependency specifies constraints between attributes of
the set.
STUDENT(Name, SSN, HomePhone, Address, Age, GPA)
There is a functional dependency SSN -> (uniquely determines) Name, for
Here's an example of a relation:
Do you see any functions there?
Here is a function:
num_Business_Days = (DELTA(start_date, end_date))
Looky. There is data USED in the function.
That's all there is to it. You can twist it around any which way you like,
but a functional dependency is not a relation. Period. Perhaps you should
open an argument clinic. And I don't mean arguments to a function.
>> >
> > 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.
=====>>>>> Terrific, but this discipline is Relational Database Theory, and while derived from mathematics, we have our own definitions. Best to use _those_.
>> > > > 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.
=====>>>>> You are twisting my words. Data can be used in code, but it is not code. Code does things, data just exists. Code soes things with data. IT REALLY IS THIS SIMPLE. Verb/noun again.
>
> > 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.
>
=====>>>>> This is where OO starts to come in to play, but we are talking about Relational Theory, not OO. This is a whole 'nother can of worms...
> > >
> > > >
> > > > 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.
=====>>>>> I give up. You are incorrigible.
>> > =====>>>>> There are many excellent BOOKS on the subject that contain
> >
> > > > 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.
> >
> > 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.
=====>>>>> No, I don't wish to restate it or retract it. I also don't wish to (nor is it possible to) re-type pages of relational algebra here, so READ THE DAMN BOOK (Elmasri) before you go spouting off.
>
> > 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
=====>>>>> No thanks. I've already spent too much time on this very simple one.
>
>
Received on Thu May 27 2004 - 19:14:22 CEST