Re: Normalization and DBMS

From: x <x-false_at_yahoo.com>
Date: Wed, 12 May 2004 19:08:44 +0300
Message-ID: <40a24b43$1@post.usenet.com>

Post for FREE via your newsreader at post.usenet.com ****

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c7tbpg$rtc$1_at_news.netins.net...

> "x" <x-false_at_yahoo.com> wrote in message news:40a1f159_at_post.usenet.com...

> > **** Post for FREE via your newsreader at post.usenet.com ****
> >
> >
> > "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> > news:c7rti3$m51$1_at_news.netins.net...
> > > "Leandro Guimarães Faria Corsetti Dutra" <leandro_at_dutra.fastmail.fm>

> wrote


> > > in message news:pan.2004.05.12.00.24.02.523801_at_dutra.fastmail.fm...

> > > > Em Tue, 11 May 2004 17:07:47 -0500, Dawn M. Wolthuis escreveu:

> > > >

> > > > > such constructs are much more likely in a relational
> > > > > database simply because there is no ability to have a "real"

> repeating


> > > > > group for the grades (a little subtable within the table).

> > > >

> > > > Consider that subtables add lots of complexity with no added power.

> > >
> > > I agree they add complexity of a sort and I agree there is no
additional
> > > "power" but it seems to have a direct correlation to the flexibility
of

> a

> > > system to withstand years of requirements changes. For example, if

> people

> > > used to have an e-mail address and now they have several, SOMETIME
> > > absolutely NOTHING has to change in the entire application other than
to
> > > change the metadata for the field to describe it as permitting

> multiples.

> >
> > You are right. SOMETIME.
> > Let's see for some operations if they are affected:
> > 1) query the e-mail address: will return a set of addreses instead of
one.
> > Rule: When you ask for a value, always expect a set of values.

>
> Or, another way to say this is: expect the full value.
> Asking for a student's major and getting only one of two would be rather
> misleading, right?

Well, a set of e-mail addreses is not the same as an e-mail address. :-)

> > 2) insert a new e-mail address: will add the address to the set. This is
a
> > kind of update in RM.
> > 3) delete an e-mail address: will substract the address from the set.
This
> > is a kind of update in RM.
> > 4) update the e-mail address: will forget all the addreses ? or it is
> > equivalent to 3) then 2) ?.

>
> Whatever the user is trying to do -- remove the list or an entry in the list
> or add an entry

Well, a set of e-mail addreses is not the same as an e-mail address. :-)

> > 5) equality test on e-mail address: will return a set of common e-mail
> > addreses instead of true or false.

> Equality still results in a boolean. You can test for equality of the full
> value (all elements, in order) or test to see if a single entry in the list

> is also in another list. (and other combinations -- whatever a human being
> might want to test for).  Whatever you want to test for, if the operators
> are not there, then create them.

Well, a set of e-mail addreses is not the same as an e-mail address. :-)

How do you know in advance "whatever you want to test for" if you planned for single values ?
How do you know in advance "whatever you want to test for" if you planned for arbitrary nested sets ?
Or do you allow only values of type SetOf(T) where T is atomic ?

Let's take an example:
Suppose you have a table that assign an e-mail address to a person ea(p person, a address).
a) Suppose you'll need to find out the e-mail address for each person from a set P.
b) Suppose you'll need to find out the person that use an e-mail address for each e-mail address from a set E.
Suppose you write 2 "procedures" for solving a) and b) Suppose someone update the table in such a way that the records associate:

1) a person with  a set of e-mail addreses
2) an e-mail address with a set of persons
3) a set of persons with a set of e-mail addresses
4) any combination of the above

In what cases you'll need to change the 2 "procedures" ?

> > I'm concerned with the case 5) in this list.
> > The questions are:
> > - How often this case will occur ?
> > - What logic we use to deal with this case ?
>
> Other than using a 2VL rather than 3VL (i.e. NULL is treated as a null set),
> equal functions as you would expect. Intersection would be separate from > equals.

Well, how about nVL as in "any Boolean Algebra" :-)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Usenet.com - The #1 Usenet Newsgroup Service on The Planet! *** http://www.usenet.com Unlimited Download - 19 Seperate Servers - 90,000 groups - Uncensored -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Received on Wed May 12 2004 - 11:08:44 CDT