Re: Multiplicity, Change and MV

> > > The most resilient designs are those which accurately represent data, not relationships. In that vein, I've found Halpern's ORM approach to be helpful..
.
> > Would someone demonstrate this resiliency starting with the OP's simple example ...
.
> But the question about the values in a domain ("you are now told by the customer that attrib1 can have any number of values") seems to be type related;

I don't think attrib1 having 1 value initially and then having 0 to many values later is type related. But then I would need to know what exactly you meant by type.

> I'm not sure that "the proper method of allowing an attribute to have multiple values is to have a separate table" is true.

If you have an alternate method that reduces the need for schema changes in response to situation unanticipated at design time, could you explain it further.

> DBMS support for arbitrary types is miserable - and SQL products that toss NULLs into the mix don't help in the least. I suspect that what you think are shortcomings in the relational model are, in fact, defects in various SQLDBMS products that the vendor claims are relational.

I don't suspect, I know for sure that the relational model at its core is responsible for certain inflexibilites and NULLs and not due to SQL and product implementors. Since I have already posted much on this before, I will say no further.

> Regarding the OP's question: he seems to be asking, "Why must I change my design when one of the constraints which resulted in a 5NF design is removed?" ... but careful and complete analysis of the real world entities would not have resulted in a design that relies upon the presumption that Tom will never teach French because he teaches English.

Hmm, I interpretted the OP's question to mean, what initial schema will allow me to avoid schema changes later. For obvious reasons, people have difficulty confronting: how to design for the unknown. This is what I call an AI-ish type of problem for which RM isn't practical. Received on Thu Apr 13 2006 - 05:07:26 CEST