Re: Discovering new relationships

From: mountain man <hobbit_at_southern_seaweed.com.op>
Date: Sat, 03 Mar 2007 01:55:53 GMT
Message-ID: <JA4Gh.6198$8U4.101_at_news-server.bigpond.net.au>


"Walt" <wamitty_at_verizon.net> wrote in message news:Oo%Fh.2$Tf.1_at_trndny03...

> It seems to me that, sometimes, relationships in data are discovered by
> other people than the ones who initially tabulated the data. This is
> tangentially related to the discussion on constraints and functional
> dependencies.
>
> Let me start with a couple of examples.

...[trim]...

> I think the two examples where I used SQL notation would be clearer if
> they
> were in mathematical notation, but I'm too timid to try. Can anybody
> help?

There exists another more administrative level example of the need to sporadically manage "new relationships": "change management".

Evolution of databases generally implies an expanding schema over time; well and truly over and above the specifications of the first implementation. When the schema is added to, or altered, there is a need to be consistent in the management of the initial loading and integrity testing (or constraint testing of [new] data).

For example, someone want to load in a new group of clients and their addresses which do not yet exist in the database. We discover that this new data has an integrity problem with NULL postcodes, however we know that data entry operators and standing by to correct such errors.

For the initial load into a new table, the POSTCODE will need to allow nulls. The exception report is made available to the operators (ie: records where PC=NULL) and they correct the externally sourced non integrous data, at which time the constrainst, POSTCODE is not NULL can be applied.

Data relationships during change management of many forms will often be best managed by a stage-wise approach, sequential steps of changing relationships (especially related to increasing integrity) towards the long term data relationships to be established.

Database systems theory can instruct you only to a certain level about change management. Practice on the other hand, with live and volatile and changing data, will also instruct you in the more practical matters of evolving relationships in changing schemas. Received on Sat Mar 03 2007 - 02:55:53 CET

Original text of this message