Re: Many-2-many relationships: Can I be told ...
- From: scubadiver <scubadiver@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 10 Nov 2006 02:38:02 -0800
I know it is a many-to-many relationship. In principle I can see that a
junction box IS required. I'm not disagreeing with you but I still haven't
been given a convincing *practical* (and I emphasise the word "practical")
argument as to why it is required.
Asking the question differently, If I also create a 1:n relationship between
course and employee what practical advantage does that have for form design
and data entry?
If that question can be answered for me, I would be happy!
"tina" wrote:
yes, i followed that thread. the issue is not how clear your descriptions.
are, hon. you seem to think that if you explain your entities enough,
someone will tell you that they are not a many-to-many relationship and you
don't need a junction table. but the fact is that employees and courses IS a
many-to-many relationship, and you DO need a third, junction table to model
that relationship.
hth
"scubadiver" <scubadiver@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:3506A329-27D4-43D6-97B9-7F75727FF12A@xxxxxxxxxxxxxxxx
It isn't as though we have set annual time tables like a professionalsay
training organisation would have. The training where I work is done on an
ad-hoc basis and whenever its required so I will include a date field to
when the employee did that course.the
I had a discussion with BruceM which turned rather heated but it was my
fault for not being clearer than I should have been.
"Allen Browne" wrote:
The other important piece of the puzzle is that each course can be run
multiple times. Therefore employees enrol in an instance of a unit (e.g.
Course2006 instance of "Basic Firefighting"), not just a unit
Therefore you need:
Unit table: one record for each subject that an employee can do:
UnitID primary key
Course table: One record for every time a Unit is offered
CourseID primary key
UnitID foreign key to Unit.UnitID
StartDate when this instance of this unit begins.
Enrol table: One record for every student in a course.
EnrolID Primary key
CourseID Which couse the person enrolled in. (Defines Unit too.)
EmployeeID Who enrolled in this course.
Outcome Whether the employee met all criteria
Employee table: One record for each person
EmployeeID primary key
The Enrol table above resolves the many-to-many relationship between
Thatand Employee into a pair of one-to-many.
--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
"scubadiver" <scubadiver@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:3CA2E8B5-1EFD-456F-A353-F4F521401BCB@xxxxxxxxxxxxxxxx
...what I am missing?
If I have training courses and employees, I know that each employee
attends
many training courses and each course is attended by many employees.
willI
can understand.
If I set up a "1:n" relationship between "employee" and "course" I
theknow
by DEFAULT who attended what course. Since I am assuming that this is
purpose of having a "1:n" relationship between "course" and "employee"
doesn't this make the 2nd relationship completely redundant?
I could be entirely wrong ... *sigh!*
- References:
- Re: Many-2-many relationships: Can I be told ...
- From: Allen Browne
- Re: Many-2-many relationships: Can I be told ...
- From: scubadiver
- Re: Many-2-many relationships: Can I be told ...
- From: tina
- Re: Many-2-many relationships: Can I be told ...
- Prev by Date: Re: Which field to use
- Next by Date: Re: Which field to use
- Previous by thread: Re: Many-2-many relationships: Can I be told ...
- Next by thread: Re: Many-2-many relationships: Can I be told ...
- Index(es):
Relevant Pages
|
Loading