Re: Normalization and DBMS

"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?

> 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

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

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

--dawn Received on Wed May 12 2004 - 16:18:58 CEST