Newbie starting a database app need direction/suggestions

Question

I've been mucking about with C# and SQL databases for some time now and I've decided its time to try a serious project. I want to create an application for managing on the job training at work. I have played around the last week with SQLCE and making
little experimental databases to learn more about relational databases. I have a rudimentary understanding oF RDBMS(wouldn't go so far as to say basic), I know how to do simple queries, subqueries, basic joins, and I've even played with triggers a bit (in
MSSSEE).
I could probably make a go of this project and make something work but I figured since its a pretty basic (to an expert anyway) I'd probably be better off going to the community for direction and advice (not to get people to code for me). I've partially planned
out how to set up the database and I'd like to describe what I've come up with so more knowledgable folks can tell me if its a good or bad path to follow and perhaps point me in a better direction for the bad parts. I'd rather understand what I'm doing and
learn the proper ways than simply say "can someone write this for me?".
Anyway, I thought a lot about what this app needs to do and did a few experimental projects where I realized even more things that it needs to do. I think I have the requirements just about covered.
Some training happens only once, some (by law or policy) have to be repeated periodically, some need a subset redone due to movement of an employee from one job or facility to another where some, but not all, of the previous training needs to be redone (machinery
operator moving to a different plant with the same function but different systems would have to relearn the system specifics). Some subjects apply to all employees and others to very few.
The most basic function is to let supervisors assign training tasks to employees and track their progress but the application also needs to alert a supervisor of upcoming due dates for assigned training and upcoming re-do dates for the periodic training. In
some cases, like with mandatory periodic training, it could (should?) initiate assignment rather than wait for a supervisor to remember to assign the training manually.
The application could be set up to have every bit of training for a job class organized under that job class but I think it would be more flexible to organize around a specific skill or area of duty.
For example, an ice rink worker needs to know how to operate the refrigeration plant, operate the ice-resurfacer (generically called the Zamboni), perform emergency duties (fire, earthquake, chemical leak, etc), and several other areas of knowledge. One area/skill
would be to operate refrigeration plant, another would be Emergeny response. Each of these would be a training "topic". Many topics would be applicable to mutiple job classes which is why they are under a seperate table from books.
Each topic would be broken down into focused steps - small bite sized chunks that the employee would learn then be tested on that knowledge. As each step is completed the examiner (supervisor or "expert" in that field) marks the step as completed
and records that in the application (might be a weekly or monthly hand-in of books to record progress).
Each job would have several topics they have to know so the topics are organized in what I've ingeniously decided to call a "book" (talk about imaginative!). We have areas where a person in a job class actually has a different knowledge requirement
than the same job class in another area. There are commonalities of course but I don't think it would be good to have every person in a job class expected to complete training in something they aren't doing and in many cases will never be required to do in
their entire career.
So a book would something like Arena Operation, Boiler Operation, WHMIS, or Emergency Response. A job class would be assigned several "books" to cover all the areas of knowledge they require.
Now to kick off thinking about actual database design.
The training definitions would be in three tables: Books, Topics, and Objectives. A book has multiple topics and a topic has multiple objectives.
The book table would have an int primary key, a title field, a longer description field (explaining the aim of the book in some way), a time to complete field (add to assignment date to get a due date), a repeatability field (The values here would indicate
a one shot, can repeat, or must repeat), and a repeat frequency field (how long before it has to be repeated - might be a date or a datediff, haven't figured that out yet).
The topics table would have an ID primary key, a title, and another longer description field for information specific to that topic.
The objectives table would had an ID primary key, a Topic foreign key, a short description, a long description, a "given" field outlining what the trainee needs and a "denied" field outlining what the trainee can't have (no drawings allowed
when your describing a system).
Later on I want the program to be able to print shirt pocket sized booklets for trainees that contains short descriptions and larger OJT manuals that have all the details that trainees can refer to.
The next table needed would be the employees table. I think the obvious ID field, first and last name fields - possibly an initials field (in case of identical first and last names), and possibly a "deleted" field for employees that leave (don't want
to actually delete them in case they come back at some later date). If not a deleted field then a "former" employee table that an employee is copied to when they leave.
Several relations tables would be created when a book is assigned to an employee. I haven't quite figured out exactly what to use which is why I chose now to post this. Some direction from here could save a lot of headache later. The relations tables would
contain only "current" books - ones that are still in progress.
I was thinking of EmployeeBook, BookTopic, and TopicObjective.
EmployeeBook would have EmployeeID and BookID, a date field for the assigned date and another date field for the due date. I had thought of just due date or just assigned date and a time allowed but I think it might be simpler to have both dates specified.
I'd also thought of making a unique key on EmployeeID and BookID but quickly realized some books may have to be assigned many times (WHMIS etc).
BookTopics would have a primary key of BookID and TopicID - cant think of any more fields here.
TopicObjective would have TopicID and ObjectiveID as well as a status field (three values - not complete, complete, not applicable) and an examiner ID field (for who signed off on the objective).
Once a book is completed I was thinking of deleting it from the relational tables and creating an entry in an archive table - no relations, everything would be the full text so if the training data is changed it won't change the completed training records.
The indexes would be whole names and any reporting would have to be grouped by book name, topic name, etc.
So thats the general idea. I'd dearly love any suggestions or advice people have. What sounds reasonable to me might be recognized as a fool's errand by someone with actual competence in database programming. I'll work on specifics once I know I'm not running
full tilt without a flashlight down a blind alley in the dark.
Thanks for getting through the entire post 8)

Answer 1

Hi Ghidera,
From my point of view, there is no need to design the BookTopic table. You can create a EmployeeID filed in the TopicObjective table, then
create a foreign key on the column EmployeeID
and reference the column EmployeeID in the EmployeeBook
table. Also you need to create foreign key relation from EmployeeBook table to Employees table and Books table.
Besides, you should create a foreign key on a column in Topics table and reference the column ID in the Books table.
Thanks,
Lydia Zhang
Lydia Zhang
TechNet Community Support