Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: Multiplicity, Change and MV

Re: Multiplicity, Change and MV

From: Neo <>
Date: 12 Apr 2006 15:04:20 -0700
Message-ID: <>

> > 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.
> What is an "RM script"?

Apologies for the sloppy terminology. I was referring to the "SQL script" necessary to create the db schema, create referential integrity constraints, insert data, select data, etc. I should be able to submit the script to a RMDB such as SQL Server or Access to verify it works. The script would have statements such as "CREATE TABLE T_Thing (ID long, Name text(50), Attrib1 text(50));" etc.

> > 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.
> Why "create an empty database and transfer the data"?

First, it was just an option, which admittedly isn't necessary in this small/trivial situation.

Let me describe a situation where the above was more applicable. Consider a situation where there are numerous test systems on the production floor for different kinds of products and electronic subassemblies. The only major similar components of these different kinds of test systems is that they all had a PC, the same test executive (written in Visual Basic and C) and a RMDB with the same schema (or least the schema was the same when first installed). The remaining test system characteristics were different and were accounted for by data in the database. Thus the test sequence, test limits, operator instructions, tester's hardware (AI, AO, DI, DO, Serial I/O, power supplies, pneumatics, etc) were all different. As each new test system was developed in the lab, the test executive was enhanced to provide new features, which necessitated a new schema. In order to reduce the knowledge required by test engineers to maintian the test systems, older test systems were periodically updated to the lastest test executive. In this case, the customer deemed it was more important to import prior data into a new/empty db with the lastest schema to reduce the possibility of incompatibility with new test excutive than to risk production down time (very expensive) with a supposedly updated db (each of which might have had a different schema depending on when it was first installed or last updated). Received on Wed Apr 12 2006 - 17:04:20 CDT

Original text of this message