Results 1 to 2 of 2
  1. #1
    Join Date
    Aug 2003
    Posts
    1

    Tables with only a Primary Key?

    I have the following tables (simplified example):

    Staff (id, FK_school)

    Teachers (id, FK_staff, FK_homeroomList)

    TeacherAssistants (id, FK_staff, FK_homeroomList, trainingLevel)

    Homerooms (id, description, FK_school)

    HomeroomLists (id)

    HomeroomListItems (id, FK_list, FK_homeroom)

    You can probably determine the relationships from the table descriptions. My question is, is it normal to have a table that has only a Primary Key? (ie. the HomeroomLists table). There is no information/fields specific to this list, it is just used to link various 'people' (Teachers, TA's, etc.) to multiple homerooms.

    I cannot use a FK to link from a homeroomListItem to a 'person' since the FK would then be pointing to different tables. (different types of people)

    The 'people' are not related in any way that concerns homerooms. For example, a Janitor may have a list of homerooms, but that list would be used for an entirely different reason (ie. cleaning not teaching, no connection).

    Any tips would be greatly appreciated,
    Mike

  2. #2
    Join Date
    Sep 2002
    Location
    UK
    Posts
    5,171

    Re: Tables with only a Primary Key?

    Originally posted by lijil
    I have the following tables (simplified example):

    Staff (id, FK_school)

    Teachers (id, FK_staff, FK_homeroomList)

    TeacherAssistants (id, FK_staff, FK_homeroomList, trainingLevel)

    Homerooms (id, description, FK_school)

    HomeroomLists (id)

    HomeroomListItems (id, FK_list, FK_homeroom)

    You can probably determine the relationships from the table descriptions. My question is, is it normal to have a table that has only a Primary Key? (ie. the HomeroomLists table). There is no information/fields specific to this list, it is just used to link various 'people' (Teachers, TA's, etc.) to multiple homerooms.

    I cannot use a FK to link from a homeroomListItem to a 'person' since the FK would then be pointing to different tables. (different types of people)

    The 'people' are not related in any way that concerns homerooms. For example, a Janitor may have a list of homerooms, but that list would be used for an entirely different reason (ie. cleaning not teaching, no connection).

    Any tips would be greatly appreciated,
    Mike
    There's nothing wrong with a PK-only table in principle, though I have known analysts who disagree for some reason. In this example, you could add an attribute HomeroomLists.description and then it wouldn't be PK-only - but there is no need to do so.

    There is also no reason why every table has to have a column called ID as the primary key: for example, a prefectly good primary key for HomeroomListItems would be (FK_list, FK_homeroom) - and in fact, that should be defined as at least a Unique constraint, otherwise you could set up the same relationship twice with different IDs.

    If Teachers, TAs etc. are "subtypes" of Staff, then they don't need a separate ID either: e.g. the primary key of Teachers can be FK_Staff (which will of course still also be a foreign key to Staff).

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •