Re: Modeling Address using Relational Theory

Gene Wirchenko wrote:
> On 30 Aug 2005 12:01:24 -0700, "dawn" <dawnwolthuis_at_gmail.com> wrote:
>
> >Marshall Spight wrote:
> >> Gene Wirchenko wrote:
> >> > On 29 Aug 2005 20:49:44 -0700, "dawn" <dawnwolthuis_at_gmail.com> wrote:
> >> > >
> >> > >I understand the Line1, Line2, Line3 implementation, but any model with
> >> > >those attributes screams "this model is not relational", right? I am
> >> >
> >> > No. It is not 1NF if the attributes can have other than one
> >> > value, but the names are irrelevant except that they be unique within
> >> > the relation.
> >>
> >> Agreed. Line1 and Line2 are not two interchangable instances of
> >> the same kind of thing; they are specific distinct fields. It
> >> is not a repeating group.
> >
> >I realize it is not a repeating group, but I thought that having
> >Major1, Major2, Major3 or AddressLine1, AddressLine2, AddressLine3
> >violated relational modeling principles. Are you saying that this is
> >just fine? If I understand correctly, it is fine because line1 is the
>
> No, it is not fine that you thought incorrectly about the RM.

Can you point me to any resources that explain this?
>
> Yes, it is fine to have such entities.
>
> >first line, where line2 is the second line, so they are different
> >attributes? So, if you want to have a person's name and up to 4 of
>
> They are.
>
> >their former names, does it violate relational principles to have these
> >as attributres Name, FormerName1, FormerName2, FormerName3,
> >FormerName4? The most recent former name is decidedly a different type
> >than the one before that. If relational theory supports lists made in
>
> How?
>
> >this fashion, I find that really fascinating, don't you?
>
> They are not lists. They are separate entities.

And if you want to place an address line between what is current line one and line two, then in the application code, you move addressLine2 to addressLine3 and put the new line in addressLine2, right? You are modeling an ordered collection of addressLines that requires operators of insert, "ripple" delete (I'm sure there is a real name for it, but I've been doing some digital video editing and I like that term), etc.

If it looks like a list and it sounds like a list, it obviously still doesn't need to be implemented as a list -- it can be implemented as individual attributes and you can hand code those inserts & deletes. But that doesn't mean that it is not, logically, a list of values you are modeling.

I must have read some inaccurate information on relational model in the past as I really thought that this attr1, attr2, attr3, approach to data modeling was incorrect. Perhaps I'm thinking about how it was considered a poor practice prior to relational theory and didn't realize that it is now considered a good approach, if I am understanding you now. Please verify that as I'm still confused. Is there anyone else who has read or learned that it is not good to model a list of values in this way, even if it is sometimes a good idea to implement this way? --dawn Received on Tue Aug 30 2005 - 23:11:03 CEST