Re: Normalization and DBMS
Date: Wed, 12 May 2004 19:08:44 +0300
Message-ID: <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> > > > > such constructs are much more likely in a relational
> > > 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:
> > > >
> > > > > 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
Well, a set of e-mail addreses is not the same as an e-mail address. :-)
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.
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 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=