Alexey Parshin wrote:
Please, consider this structure as a proposition and not as a statement.
I surely got it this way, don't worry!
I believe we do not need Aprentice. I think it used to be just another name for student.2006/4/30, Anatoly Volynets <firstname.lastname@example.org <mailto:email@example.com>>:Now, I want some clarifications: Person to Course relation: Type: many to many ------ means many people can relate to the same course, while a person can relate to many courses Fields: type (student/apprentice/author) ----- so these are fields of the intermediate table?1) Yes 2) No, these are the possible values for the field "type" (assumed the referrence to some table of three or more rows)BTW, I am not sure, I remember what exactly an apprentice is here? A co-author or teacher with some limited rights or a student with some expanded duties (makes sense if we talk about a group of students)? Anysuggestions?IMHO, an apprentice is a trusted student, with some extra rights/duties.
Topic to Required Topics relation: Type: one to many ----------- means a topic can be optional or mandatory? We have related issue in specs: prerequisites for a topic, but it seems to be much complicated. There can be many topics/courses/texts/problems/tests/games/other objects pre-required for the given topic, or course, or problem, or game, or.... Thus we need to provide one-to-many prerequisite-relation for an object in a course to objects from Repository (I start to think)?Means - a topic may require an optional list of other topics. And yes, this is one of the required relations, probably the most important. It means - the person can't start topic if he/she didn't complete the required topics.
We do not have it in specs and I think now, we need some more generic relation - see my previous note (some kind of object-objects one-to-many). I'll put it in specs. Let me make up my mind :)
Keyword to Topic relation Type: one to many Fields: keyword One keyword an be used in many topics, courses and so forth, while many keywords can be used in a course, topic, explanation, etc. So it is many-to-many and involves many objects, not only topics.Yes, however if we do it this way - we have more complicated structure with not so much of the gain. It may be done both ways, with some pros and cons.
Well, many keywords for an object - is plain reality. Having many objects for a keyword makes it possible keyword-based search. Am I right?
Explanation to Topic relation Type: one to many ---- if one-to-many, then Topic to Explanation: there supposed to be many explanations for a topic Explanation to Person relation - I'm not sure we need this at all Type: one to many Explanation Fields: name, reference to source, ---- Why we need this? If an author refers students to a text from Repository instead of writing his own text (next field)? I think this situation does not differ from usage of other objects. textDon't you want to know - where (from outside) this text came from? The Bible, a book, etc.. It's optional.
As I said - in this case an object "explanation" is originated from another object "text" and as such have to bear the "origin stamp". OTOH, normally, explanation is a regular text, written by its author for this course. If there are just regular references like in a regular book, we have to think how to put them there. Probably, plain web-links to outside-uu sources?
-- Alexey Parshin,http://www.sptk.net
-- Anatoly Volynets, Co-Founder total-knowledge.com culturedialogue.org
Authoright © Total Knowledge: 2001-2008