Intersection Table

[shaunk]

I have a simple Issues_Log database. There is Issue_ID, Issue_Description, Issue_Start_Date, Issue_End_Date, Entering_Person, Status, Priority.
Currently, I have a main Issues Table that contains the Issue specific data ie. Dates and Description, and that
links to the Status Table, Priority Table and Entering Person Table thru uique ID's.

Q1) Should I create a seperate Issue table with only the Issue specific data, as well as a new Issue_Intersection table that links to all the other tables through Issue_ID, Entering_Person_ID, Status_ID, Priority_Id. If this is expected under relational rules, what am I gaining from this ?
Q2) A dummer question. Are the Entering_Person, Status and Priority tables in a one to many relationship with Issues, given that, for example, one Entering Person can be in many Issues ? OR are they in a one to one, given that each Issue can have one and one only Entering Persons.

 

[Terpsfan]

This is how I would break up the tables. I would have one main issue table for recording issues. Within that table you would have several related lookup tables.

tblIssues (IssueID, IssueDescriptionID, Issue_Start_Date, Issue_End_Date, Entering_Person_ID, Status_ID, Priority_ID)

tblIssueDescription (IssueDescriptionID, IssueDescription)

tblEnteringPerson (Entering_Person_ID, Lname, Fname, MI,Dept)

tblStatus (Status_ID, Status)

tblPriority (Priority_ID, Priority)

What do you gain by doing this? You normalize the data, which in turn takes up less disk space and also makes it easier to generate reports. Of course, it means you have to create more joins in your queries.

 

[shaunk]

Thanks for your response Omega36.

Couldn't the setup be viewed as normalised if you leave Issue Description in tblIssues. The description is as specific to an individual Issue as Start and End Dates ?