Re: Normalization and DBMS

"x" <x-false_at_yahoo.com> wrote in message news:40a24b43$1_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: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. :-)

You are right -- if you want just one and the system gives you a set, then turn around and ask for one. Otherwise you would have to know in advance whether the answer allowed multiples. For multivalued fields where people are likely to want either the full list or the top value, there is typically vocabularly added to the dictionary for the file so that the stored field might be described as EMAIL-ADDRESSES and there might be another definition for PRIMARY-EMAIL or some such. In either case, it is important for the user to have a vocabulary and definitions.

> > > 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. :-)

You seem to have a point to make ;-)
and the point is taken

> > > 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. :-)

Yes, and somehow in English I know how to ask a question and get the answer I'm looking for -- you have a vocabulary and definitions ;-)

> How do you know in advance "whatever you want to test for" if you planned
> for single values ?

You have a vocabularly and definitions ;-)

> How do you know in advance "whatever you want to test for" if you planned
> for arbitrary nested sets ?

You have a vocabulary and definitions ;-)

> Or do you allow only values of type SetOf(T) where T is atomic ?

Nope.

> 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.

E.G.
LIST PEOPLE EmailAddress

> 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.
E.G.
LIST EMAIL Person

> Suppose you write 2 "procedures" for solving a) and b)
OK, like those above.

> Suppose someone update the table in such a way that the records associate:
> 1) a person with a set of e-mail addreses
Now there are two likely possibilities:
a) when the person updated the table [sic] they redefined the vocabulary item EmailAddress to be a derived data field pointing to the top address (index of 1) and they created a new field at the same location in the file (just to raise blood pressure in some folks) called EmailAddresses and described that one as multivalued,while the other remained single-valued. In this case, the previous query remains unchanged b) they might keep the same vocabularly name and change it to be multivalued and recognize at the time no need for a single value so the previous query would then show both values for that field that has a changed def

> 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

Unless I'm missing something, I think I cover it with the answer to 1)

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

If the definition of any term changes in meaning and you don't want to adopt the new meaning, then you need to change your query.

> > > 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" :-)
peachy, but I haven't had a need to use anything beyond 2VL in a database as yet and it has only been problematic when using 3VL, so I'll stick to 2, thanks. Cheers! --dawn Received on Wed May 12 2004 - 19:18:33 CEST