Re: Multiplicity, Change and MV

From: Neo <neo55592_at_hotmail.com>
Date: 12 Apr 2006 08:26:20 -0700
Message-ID: <1144855580.320397.259340_at_g10g2000cwb.googlegroups.com>


> > In RM, the proper method of allowing an attribute to have multiple
> > values is to have a separate table.

> No. You just change the key definition :-)

I didn't understand.

Assume at initial design time, you are told by the customer to model a thing (ie thing1) which has an attribute (attrib1) which has one value (val1). Please post the actual RM script for this situation and populate db with thing1. Also include the query to find thing1's attrib1 value.

Next assume you are now told by the customer that attrib1 can have any number of values (ie NULL, val1, val2, val3 ...). Please post the RM script, which when executed against the already populated db (populated with thing1), allows thing1 to have val1, val2 and val3. Or post the RM script which creates an empty db with new schema and transfers data in old db to new. Verify if the original query still works, if not, include the new query to find thing1's attrib1 values.

You may be wondering why anyone would go through these kind of steps on a trivial example? They wouldn't. These are the type of steps that frequently occur with larger, real-world applications/solutions.

> > If the separate table is not included in the initial schema,
> > adding it later usually requires schema changes, data migration
> > and script/query/code updates.

> Separate from what?
> What initial schema?

I should be able to answer these questions once you post scripts for the above.

> The RM has no code. Only data. :-)

My apologies for the confusion. In the current small/trivial example, there is essentially no code. The code I am referring to is that which typically accompanies the database to implement larger, real-world solutions. An example of this might be a billing system that allows a utility company to bill their customers, maintain useage history, customer interactions, etc. In such a case, there will be considerable code written against the database, possibly in the form of Visual Basic and stored procedures, some of which are likely to fail and require updates as a result of schema changes. X have you worked on projects such as these? Received on Wed Apr 12 2006 - 17:26:20 CEST

Original text of this message