Re: Normalization and DBMS

From: x <x-false_at_yahoo.com>
Date: Thu, 13 May 2004 11:23:35 +0300
Message-ID: <40a32fc0@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:c7tm9u$3g2$1_at_news.netins.net...
> "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:

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

I think You need to think more about that SOMETIME.

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

The question is WHEN your applications become broken ?

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

Thank you for repeating this: "You have a vocabulary and definitions ;-)" I think this is not well known, repeated enough and explained enough. I think this is one of the human abilities least exploited in computer programming.
Instead of building a vocabulary, we use those ugly procedures calls and rigid control structures :-)
If I understood you correctly, you are promoting is a tehnique similar to FORTH language but with polymorphic words.

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

What is the effect of this LIST statement ? Can you use the result for further processing ?

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

That vocabulary updating seems like schema updating. In an SQL-DBMS a DML statement does not change the schema, only the data. In PICK a DML statement is also a DDL statement ? If not,won't a simple update of the data broke some application without warning ?

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

Won't a simple update of the data broke some application without warning ? Won't the set of meaning associated with a term grow with growth in "data types" ?

Are PICK "fields" dynamic typed ?
If not, then there is not that much difference from RM and I think we can use the tricks from PICK on RM.

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

Well, using 2VL feels like programming in assembler ... Hard work this logic stuff.

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

• 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 Thu May 13 2004 - 03:23:35 CDT