Few confusing things about first normal form

On Oct 24, 3:27 am, David BL wrote:
> On Oct 23, 9:11 pm, paul c wrote:
>
>
>
> > David BL wrote:
>
> > ...
>
> > > Is the value of an attribute that is an RVA a scalar?
>
> > I believe it is ie., in a "containing" tuple it's a (single) relation
> > value and (in the D&D approach) there is no way to operate on its
> > individual tuples.  Their algebra only operates on the value of the
> > relation.
>
> > (They have an operator called UNGROUP that forms a different relation
> > that has no RVA's.  Definition in thethirdmanifesto.com, see appendix A.
> > They don't the equality operator to treat the second relation as equal
> > to the first even though some of the possible values for the containing
> > /GROUPed relation might have exactly the same information as the
> > UNGROUPed one.  However, I don't believe they forbid an operator apart
> > from equality that decides some kind of equivalence.)
>
> > Hope somebody will correct me if I've mangled what D&D say.
>
> Isn't every type a scalar type?  Why not drop the word "scalar" as
> meaningless?   In fact it would seem a good idea to avoid the
> confusion with the rather specific meaning of "scalar" used in linear
> algebra (where it is associated with the field over which matrices and
> vectors are defined).

There is clash between the compsci use of the term, and the
mathematical use. AFAIK Codd meant the former, a scalar meaning a
variable that can only hold one value meeting the variable's type. One
logical address - one item. This contrasts with an array, for example,
which can contain more than one value, but does not require any form
of decomposition to iterate through those values (i.e. it is not an
object). One logical address - several items (lined up contiguosly)

While this once made sense in the low-level programming world, the
uptake of OO (and specifically templates and containers) has severely
confused these distinctions - an "Array" in pure OO languages /does/
require decomposition (through accessor methods), it is just that this
is often hidden via overloading of an indexing syntax to mimic non-
scalars (i.e. square brackets). A <vector> for example is one item, at
one logical address, that just happens to contain lots of others.

Hence, to a modern high level programmer, who probably wouldn't have
any notion of contiguous memory addressing, all variables are scalars
and for it to be otherwise would seem bizarre.

On Oct 23, 1:43 pm, Gene Wirchenko wrote:
> wrote:
>
> [snip]
>
> >Anyways, I realize SQL doesn’t allow multi-valued attributes, but I
> >figured at least in theory they would be allowed, since I can’t bring
> >myself to believe that the author of my book was so off. Uh
>
> No, they are not allowed under the RM, and there are good reasons
> for this. (You can break up multi-valued attributes into another
> relation.)

The solution that makes rdbms purists happy is to declare the entire
repeating group be instead a string or blob and let the application
deal with the repeating-groupedness of the actual data.

> >thank you all for helping me

Your welcome!