Re: cdt glossary 0.1.0 [Relation]
Date: Sun, 26 Feb 2006 00:53:16 GMT
Message-ID: <0_6Mf.130526$Q11.10137_at_tornado.ohiordc.rr.com>
dawn wrote:
> Mark Johnson wrote:
>
>>[Relation] >>1. A relation is a subset of the set of ordered >>tuples (A1, A2, ... Am) formed by the Cartesian >>cross-product of sets S1 x ... x Sm where each >>An is an element of Sn. >> >>I might say, instead, because I think they logically go closely >>together, and again just as a suggestion, nothing more:
>
>
> Mark -- I, too, am unable to understand your intended meaning from what
> you write, in general. Can you spell out what you mean by the above
> sentence?
>
>
>>Relation - mathematically by a language of sets, a relation is an >>(ordered) array/tuple of elements drawn one each from a set of >>domains, in order, with duplicate domains allowed. This set of >>n-tuples, said to have degree, n, or to be 'n-ary', where the number >>of n-tuples is said to be its, cardinality. The relation is uniquely >>named with regard to other relations. It can both be imagined and >>represented as a 2-D grid, or table.
The "relational model" is, indeed, analogous to the concept of a mathematical relation: a subset of a matrix. The method of matrix construction may include the Cartesian product, but doesn't matter. The Cartesian product is often used because it is defined over many more combinations of operands - potentially infinite, I would guess - than "ordinary" matrix arithmetic.
Unlike matricies (which a mathematic relation is) of mathematics, the order of components in the relational model's non-scalar types - be they tuples in relations or attributes in tuples - is meaningless.
Additionally, the components of tuples and relations are required to be sets: no duplicates allowed. (Taken together, these seem obvious: if a tuple held more than one attribute of the same name, there would be no way to distinguish them if one couldn't refer to "the first" or "the fifth.")
The attributes of tuples are required to be uniquely named. "Back in the day," there might have been some wrangling over distinguishable combinations of attribute "name and type," but such a scheme would have resulted in cumbrous rules: designers would be allowed to change an attribute type only when some other attribute name didn't get in the way. Nonsense.
>
> This definition does not seem better than the one that I think you are
> suggesting be replaced. There are multiple definitions of Relation in
> the glossary. In order for me to understand your point, could you say
> what you think is missing from, or less than clear in, the current
> definitions?
>
>
>>Tuple - also termed an, element, of a relation, it is an unordered set >>of n-attributes,
>
>
> this might seem like nitpicking, but one part of your style that is
> difficult to read is your use of commas between an article and a noun.
> Removing some commas might help. For example, the above fragment could
> be punctuated as "Also termed an element of a relation, it is an
> unordered set of n-attributes,"
>
> Once I was able to read it that way, I could better identify whether I
> agreed or disagreed with it. In this case, I disagree. 1. A tuple is
> not a set. 2. I don't know what an n-attribute is. 3. Tuples are not
> unordered. The combination of poor grammar and punctuation along with
> imprecise terminology makes it very difficult for me to read, and I am
> a native speaker of English. There a many readers where English is a
> second language and I'm sure this makes it very difficult for them to
> understand you too.
>
>
>>each attribute drawn from a particular dimension or >>domain, as irreducible 'atomic' scalars or strings (though multiples, >>if a multi-valued domain, were once considered),
>
>
> We do not need to introduce into a definition of a tuple any discussion
> about what domains might be valid in database products.
>
>
>>and identified by >>unique name in order to a) express any relationship among any set of >>attributes and b) to allow the tuple to have no particular order. As >>an unordered tuple does not properly correspond with a set relation, >>the relation might be termed, instead, a relationship, which might >>more properly correspond with a table. The tuple can be imagined as a >>vector/array. The tuple can be imagined and represented as a rows in >>the table, its attributes as columns.
>
>
> Is there something amiss with the current glossary definition of tuple?
> The above definition would do nothing to help clarify the term for me.
>
>
> I think you have points you are trying to make and also seem to have
> familiarity with the topics, but in all of the postings of yours that I
> have read, I am unable to determine what your points are. I see that
> you have not taken kindly to suggestions to improve your writing style
> so that we can better undersand you, but I agree with those who have
> made such suggestions. I'll try to read your next few postings, but if
> I am still unable to understand, I'll have to pass in the future. I
> make a ton of typos in my writing here and have a problem writing too
> much when I don't edit myself, so I understand you might be moving
> fast.
>
> My specific suggestions, in case you find them helpful, are to
> a) improve your use of commas, primarily by removing many
> b) verify that each sentence is a sentence
> c) use the terms already in the glossary according to the definitions
> given there (at least as an exercise to help improve readability for
> now),
> d) Use other terms as precisely as feasible, particularly if you are
> trying to provide a definition or description for a term
> e) proofread and edit at least your next few posts (I need to do this
> more often too).
>
> I think many of your readers will try to meet you half-way if you can
> help us better understand what you are trying to tell us. Best wishes.
> --dawn
>
Received on Sun Feb 26 2006 - 01:53:16 CET