Re: Multiplicity, Change and MV

B Faux wrote:

> 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.
>
> Get over yourself...
>
> BFaux-

As you so correctly point out, this is a theory newsgroup and not a product newsgroup. As such, product specific vocabulary has no real business here.

If you want to use vocabulary people familiar with the existing theory will understand, either use their vocabulary or define the vocabulary you use for them.

I see nothing wrong with a request that you define your stupid fucking terms. Idiot. Received on Sun Apr 16 2006 - 19:03:05 CEST