Re: Multiplicity, Change and MV

From: B Faux <>
Date: Fri, 14 Apr 2006 17:23:59 GMT
Message-ID: <PUQ%f.9966$>

Ok 'X', at the risk of being labelled a 'troll' I'll attempt to clarify briefly;

The OP wrote:
Change bothers me. Especially in database schema, and specifically when we want to accomodate change in the cardinalities of the relationships we are modelling. Below I've setup a contrived example of lecturer-course, which a school initially deems to be a highly constrained 1-1 relationship, with (ID) serving as a surrogate primary key for the sake of clarity.

Courses = { (name:French), (name:English), (name:German) } Lecturers = { (id:1, name:Tom, teaches:French), (id:2, name:Bob, teaches:English) }


id name teaches

1 Tom French

2 Bob English

Apologies for this basic (and contrived) example, but hopefully its sufficient to show that change will have knock on effects to the queries of extant applications which interact with the database.

This is what I'd like to focus on here - I am interested in exploring how one might reduce the dependency between query-form and db-structure. I find it jarring that a change in multiplicity has introduced a new relation - perhaps it should have existed in the first place even with the 1-m relationship? Either way, going against my instincts, below I'm considering MV approaches, of which I can determine two:

MV - Set/List value approach (Pick?):

Courses = { (name:French), (name:English), (name:German) } Lecturers = {
 (id:1, name:Tom, teaches: {French, German} ),  (id:2, name:Bob, teaches: English )


I believe that I see the term "(Pick?)" written above, do I not?

Further, it appears to move ever so slightly beyond theory and toward actual implementation. I made the mistake of taking the above at face value and attempted to show how a real-world implementation might be achieved in a maintainable and extensible fashion. The OP obviously has some misgivings with the limitations of RM implementation where unknown, but inevitable change is expected. It is almost impossible to accurately predict how a data base will need to be modified in the future to handle unforseen environmental exigencies.

If my terminology troubles you, then I recommend you take a deep breath and examine the title of this NG... it does not limit itself to "RM", but rather specifies "databases" which most certainly would include non-RM databases. And one more time, the OP not only mentioned "MV" in the subject, but added the term (Pick?) in the actual post.

Get over yourself...

BFaux- Received on Fri Apr 14 2006 - 19:23:59 CEST

Original text of this message