|
|
|||||||||
|
|||||||||
|
|||||||||
| |
|||
| |||||||||
![]() |
|
|
«
Previous Thread
|
Next Thread
»
|
Thread Tools | Search this Thread | Display Modes |
|
|
|
Stay one step ahead of the competition. Evaluate and give feedback
on some of the hottest web development tools on the market today.
Make your opinion heard! Click
Here
|
|
#1
|
|||
|
|||
|
Normalization Question
Hi guys! I'm creating a testing application. One of my goals is to store the employee info, questions, number of test taken, etc for each test an employee takes. The tests are all the same except that the questions will be selected from a pool.
Questions are grouped into Categories. Each Category has one or more goals. Some questions may have a diagram. Below are 10 tables. I think they are pretty normalized. I just want to know if you think this is a good design or not. I've attached a picture of an ER-Diagram i created in MS Access also. I also have a few questions about some derived fields i would like to ask later. Thanks! |
|
#2
|
|||
|
|||
|
I was trying to make this as legible as possible. Table names are in bold. Attributes are in green. comments are along the side. I minimized them reduce clutter.
Employee EmpID* FName LName Position Employee’s Title or Position Center Employee’s Main Location Table Description: Stores vital information about Employees Center CenterID* CenterName Name of each company Center Table Description: Stores all of Franklin’s centers Test TestID* Identifies all employee testing information EmpID Table Description: Used to identify all employee tests using a unique identifier (TestID) that can be used to identify all questions presented to employee. Objective ObjectiveID* Unique Identifier for all objectives ObjectiveName ObjectivePurpose Desc. of the purpose of each testing objective Table Description: Provides each testing objective with a unique identifier and name. It also stores a description of the purpose of the testing objective. Goal GoalID* Unique identifier for each objective’s goal ObjectiveID GoalDescription Desc. of what each employee should learn after completing an objective. Table Description: Stores all of the goals for each objective. Question QID* ObjectiveID Used to identify which question belongs to which objective. Question Description of question Table Description: Provides a pool of questions for each objective. Answer AnswerID* QID Answer Possible answer to a particular question Correct Boolean value describing whether Answer is a correct choice. Table Description: Stores all the possible answers to a particular question. Diagram DiagramID* QID FileName Name of diagram file; used to find file on disk. DiagramDescription Description of file Table Description: Stores information diagrams used on the test. Completed_Objective COID* TestID Foreign Key from Test table; used to identify which set of objectives belong to each TestID. ObjectiveID Foreign Key from Objective table; used to identify tested or completed objective. StartTime Stores the date and time testing of objective began. FinishTime Stores the date and time testing of objective was completed. Table Description: Used to store all objectives completed by user. Ties completed objective to a specific TestID, allowing for retesting. Completed_Question CQID* Primary Key; Uniquely identifies completed questions for each TestID COID Identifies an objective and TestID to a completed or answered question. Correct Boolean explaining whether the question was answered correctly or not. Table Description: Stores all the test questions for a particular TestID by Objective while providing information indicating whether the question was correctly answered or not. |
|
#3
|
||||
|
||||
|
I would think you'd want to add a more generic test table that provides the name and any other info about a given test (assuming you might wind up with more than one form of the test with its own set of objectives, etc.). I'd then tie the available (not just the completed) objectives and goals to each test, and I'd consider putting the objectives and goals into one table unless you plan to have multiple goals per objective. Of course, that's all armchair quarterback sort of advice without my having the benefit of a top-level view of what you're trying to accomplish, so take it for what it's worth. At a glance, your structure looks ok, though I found myself tripping over it and having to scroll up and down to squint at the keys and make sure all the relationships were in place. Which is part of having a normalized database, I guess.
__________________
Please don't PM me asking for solutions outside the scope of a thread. Keeping all responses in a thread stands to help others who come along later, which is after all what this forum's all about. |
![]() |
| Viewing: Dev Articles Community Forums > Databases > Database Development > Normalization Question |
| Thread Tools | Search this Thread |
| Display Modes | Rate This Thread |
|
|
|
|