Yep, you've got it! Corresponding rows in both tables contain the same
primary key value, and in the dependant table the primary key is also a
foriegn key. The example you've given is correct.
"Eric Gibson" <aithien_at_SCREWSPAMearthlink.net> wrote in message
news:dHtta.56637$4P1.5228485_at_newsread2.prod.itd.earthlink.net...
>
[snip]
>
> Okay, okay, I've read up and I think I've got it! The only thing I don't
> quite understand is this shared key thing... Is the actual key *value*
the
> same in both tables for a given IsA relationship?
>
> Say I have a table entry in CourseActivities:
>
> CourseActivities(CourseActivityID=1, ActivityOccurence=1,
ActivityChapter=1,
> ActivityCompleteTime=30, ActivityType=1, CourseID=1)
>
> It's the first object to occur (ActivityOccurence) in the Course
(CourseID),
> labeled under chapter one (ActivityChapter), and the person must view it
for
> 30 minutes(ActivityCompleteTime), and it's labeled as a lecture by type
> (ActivityType).
>
> Then I have an entry in my Lecture object table:
>
> Lectures(CourseActivityID=1, LectureName='Basics of Med Term')
>
> In this example CourseActivityID in the Lectures table acts as a foriegn
key
> and primary key simultaneously, right? You're right my entire model
snapped
> together perfectly and it actually fixed quite a few other small
> descrepencies after I made these changes.
>
> Eric
>
>
Received on Mon May 05 2003 - 11:36:46 CDT
