Re: Modeling Address using Relational Theory
Date: 1 Sep 2005 07:38:48 -0700
Message-ID: <1125585528.381322.193380_at_g43g2000cwa.googlegroups.com>
dawn wrote:
> David Cressey wrote:
> >
> > It's "principal insurance policy" versus "supplemental insurance policy".
> > These are frequently stored side by side in a single table. In almost all
> > cases, the semantic difference between the two columns determines which
> > column on wishes to use in a query's conditions.
>
> Good example. In this one the ordering is not with numbers in the
> attribute names, but with ordering information in those names.
Sure. But if he'd used the names "policy1" and "policy2" with the exact same semantics, would it have been any different?
> Unfortunately (my opinion), this also seems to make a difference in the
> conceptual data model. Those who have been trained only in the
> relational model push that thought process on SMEs, even in cases where
> the end-users might initially think in terms such as "then we have
> insurance policies, up to two of them, and we submit to the first and
> then only submit it to the second only after the first denies payment"
>
> Even if we do an implementation in an RDBMS, it seems that the
> conceptual data model could be well-served with list structures.
This doesn't strike me as a good place to use lists.
> Because AddressLines only has a cardinality of 2, it is not a big deal
> to make it two separate lines, but the only reason I see to do so is
> that the target environment has no list types.
What would be the motivation to use lists? It would be if there were list operations that we were going to perform on the data. If there were, then a list would make sense; if not, then it would be the list advocate that was guilty of having his or her preferred data structure intruding into the logical model.
(Although here I guess our differing experiences may color our perspective, because I haven't seen list operators used on address lines and I think I remember you said you had?)
I still agree, though, that SQL suffers for its severely limited ability to handle ordered data.
Marshall Received on Thu Sep 01 2005 - 16:38:48 CEST