Thanks for the explanations, Stan! Things are beginning to clear up.
See below...
* Stan Mitchell [Tue, 9 Jul 2002 at 15:03 -0700]
> Yes, you're right, it is a three-way association with 0-1 instances of
> activity.
> From a database perspective, repository-source is an associative table -
> no primary key only foreign keys. So it would be useful for performing
> queries on various combinations of the foreign keys.
>
> I think the three ids (activity, repository, source) serve to identify a
> specific search. In Activity/Search, activity-id is a primary key.
> Each record defines one of three possible kinds of searches:
> 1- source without a known repository (search for a repository?)
> 2- repository without a particular source in mind (search for sources?)
> 3- a source known to exist in a specific repository (normal search)
Ahh, I see why we need the three keys in the search table.
>
> On the other hand, repository-source is indexed by the three ids.
> If a repository has several copies of a source, then a given search
> in one of those copies, would require a separate repository-source
> record to store the call number, etc. If you were interested in which
> copies (call-numbers) of the source you had looked at in a repository,
> a query of just those repository-source records which match
> repository-id and source-id would give that info.
But then you have to store call-numbers possibly many times. For
example, a professional researcher would doubtless perform many searches
in any particular US Census. For that Census the repository, source, call
number and description would all be the same for every repository-source
record. The only unique information in each record would be the
activity-id. Yet if we take out the activity-id from repository-source
we get rid of that redundancy. AFAICS there is no loss of querying power
when we do so - search has all three keys, so if you want to know which
searches you did on a particular call-number, you only have to query the
search table with the repository-id and source-id. Or am I still
missing something?
> BTW, I'm a software engineer in the San Francisco bay area.
> Genealogy is a side interest of mine. I have studied the gdm
> spec and have an idea to represent it using UML. My background
> is more in C++, OOP, and systems programming. XML is still
> new to me.
I've often thought a UML representation of the GDM would be useful. Let
me know if you come up with one!
<hans/>
--
"Everybody is talking about the weather but nobody does anything about it."
-- Mark Twain
_______________________________________________
gdmxml mailing list
[EMAIL PROTECTED]
http://fugal.net/cgi-bin/mailman/listinfo/gdmxml
