Re: Multiplicity, Change and MV
Date: Fri, 14 Apr 2006 17:23:59 GMT
Message-ID: <PUQ%f.9966$%m4.3662_at_newssvr33.news.prodigy.com>
Ok 'X', at the risk of being labelled a 'troll' I'll attempt to clarify briefly;
The OP wrote:
<quote>
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) }
i.e.:
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 )
}
</quote>
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.
BFaux- Received on Fri Apr 14 2006 - 19:23:59 CEST