Re: Modeling Address using Relational Theory

"dawn" <dawnwolthuis_at_gmail.com> wrote in message news:1125525546.555367.27220_at_g14g2000cwa.googlegroups.com...

> > Major1, Major2, Major3 are just names. What's in a name? The
question is
> > whether or not they form a set of majors, at the rock bottom semantic
level.
> > Let's take Course1, Course2, Course3, because it's easier to see that
they
> > are a set, and not a list.
>
> In fact, even I would say this constitutes a set and not a list.
> Major1, Major2, and Major3, however typically indicates that the "first
> major" is Major1. In other words, the modeler embedded an ordering to
> this data in the names of the attributes (!) as is also the case with
> addressLine1, addressLine2, addressLine3.
>
> >
> > At the rock bottom level, a student enrolled in Psych101, Calculus101,
> > English101, and Programming101 is still enrolled in the same courses if
one
> > permutes the order.
>
> Absolutely agreed. However, the student with a Major1 of Biology and a
> Major2 of Theater is likely to walk at graduation with the Theater
> majors while if the order is reversed, they will walk with the Biology
> majors (this is, of course, dependent on the business rules of the
> institution, but the fact is that business rules might be set based on
> this ordering whose value is embedded in an attribute name).
>

Depending on the institution this might be part of the problem domain. But is it part of the system's responsibilities?

If the answer is no, we can ignore that aspect of reality, and treat the majors as a set. If the answer is yes, we have to store information about which major determines the graduation walking order (did you get that backwards in the above?)

> > Disguising this set as attributes (columns) with
> > different names is obfuscating the fact that they are a set.
>
> Do you agree now that I am talking about ordered lists, whether or not
> they are sets?

No.

> Yes and that is one of my points. I was completely unaware that it was
> considered proper relational modeling to place ordering data in
> attribute names, although I realize that the data from the attributes
> is rarely parsed out to get this ordering -- it is simply understood
> from the names so that queries are done properly.

Where in relational modeling does it discuss naming conventions?

If they are different attributes they belong in different columns, with different names. If they are the same attribute, they belong in the same column, creating extra rows where necessary, and decomposing relations where advisable.

Whether the names suggest a linkage between the attributes or not is more a matter of aethetics than of modeling principles.

>
> > And that's the real point behind normalization. It isn't some mumbo
jumbo
> > you have to go through in order to satisfy the Spanish inquisition about
the
> > orthodoxy of your faith. It's a way of preventing certain problems that
> > will come up at access time or at update time if you depart from the
normal
> > forms.
>
> Yes, so what is a good way to model the
> non-city/state-province/postcode/country address lines?

It depends on what you are going to use the data for.

> Do you understand what I'm looking for with a relational model for
> address that is considered both relational and at the right level of
> detail for the typical problem domain? --dawn

What I don't understand is why you are looking for such a thing. Received on Thu Sep 01 2005 - 14:46:12 CEST