Re: Constraints and Functional Dependencies: Notation

<<Just to show I'm not trying to let you do all the work, I'll take a compound guess.>>
Don't worry, I would not call this work, just an encouragement to your attempt at better formalism.

<<I may be completely off, but please remember: I am asking you. >> No problem.
Guess3 is correct only. Throught your post, you have created an opportunity to use a much more efficient communication based on the preciseness of math symbology. I was trying to point out some additional elements making the formalism closer to what math requires to gives one the right to exploit a definition in further demonstrating perspective:

1. It is preferable to express all domain of values for any element present in the definition.

For instance speaking of R(a) or S(b) one *must* define what a, b, R and S. In set theory, such definition can be done in two possible ways : *naively* using symbols ∀, ∃, ∃!, ∈ ...(+ others such as include etc...) such as or *explicitely* using formal operation definition such as *| a = R(a) /\ S(b) = somevalue*. I personally favor the latter. Bourbaki's naive operators have been strongly criticized for some vagueness they induce in further demonstration.

It was the purpose of completing the definition stated.

2) Second, math rigor dictates that a definition must be first expressed and systematically demonstrated (or negated). In other words, a definition should be considered a hypothesis and demonstrated thanks to set theory axiomatic (extensionnality etc...) and set theory operations. Only when demonstrated, it becomes acceptable. On that matter, I observed that computing approach of RM leads often to favor formulation over demonstration of definitions.

3) As for the definition itself (meaning not the formalism), I formulated a variation on the definition proposed 10 years ago. I reached quickly a dead end into trying to exploit that definition for further demonstrations. Reason: attribute based definitions are too
*computing oriented* because Codd's attribute's based structuralism
was chosen for computing implementation. Such structuralism reveals quickly its limits for abstract thinking and formal demonstration in mathematical perspective. For instance, if one considers relation
*R* and attribute *a* and considers the formal expression R(a), what
kind of *explicit* demonstrations can be made out of it (how can definitions not just stated but demonstrated). Having explored such way , I realized that such bias would encourage demonstration based on naive set operators but undermined explicit operation demonstration. That is why, I have came to the conclusion that demonstration should be done not using attribute based structuralism but domain based structuralism...

In such direction, R is a relation and a is relation variable representing an NTuple set as opposed to current's structuralism.

In other words,when using R(a) - a being an attribute, one often ends up with tons of undemonstrated definitions based on naive operators. Oppositely, defining R(x) - x being a relation variable that may
*filled* by NTuples set values helps getting easier to demonstrate
(mostly by equations, inequations resolutions) new definitions. This is in no sense a conclusion but an observation after several hundred attempts going the way you described.

I would be glad to share few interesting discoveries made (after tons of dead ends reached) but I do not want to be insulted by some hostile people who have a tendancy to confuse RM and RM structuralism and favor conservative attitudes (not to be mistaken for healthy skepticism) to exploration of new concepts that maybe useful for future computing implementations or resolving matters that are off limits.

Sincerely hoes this makes sense. I write in English but I still think in French. Received on Fri Mar 02 2007 - 11:57:15 CET