Home/ Questions/Q 8785087
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-13T21:15:50+00:00

I am researching database design and theory and have finally made a thoughtful attempt

  • 0

I am researching database design and theory and have finally made a thoughtful attempt at creating a schema that would be based upon SQL. I would like, if someone has time, to review my layout and make sure that it is logical. Tips and criticism aimed at bettering my knowledge is of course welcome! 🙂

Here is my general goal:
Create a database that will allow for a business with multiple stores to be able to track employee training progress by simply marking date trained and date verified. Basically, this would be the hierarchy:

Business 1 
--Store Location (a)
----Employee
----Employee
----Employee
--Store Location (b)
----employee
----employee
----employee

Business 2
--Store Location (a)
----employee
----employee
--Store Location (b)
----employee
----etc...

This schema should allow for unlimited businesses, stores, and employees.

As far as the training goes, there should be this type of hierarchy:

Business 1
--Employee Class           (Manager, Employee, Salesman, Associate, etc)
----Training Category      (Sales, Stocking, Manufacturing, etc)
------Training Activity    (How to sell X product, How to stock Y aisle, etc)
------Training Activity
------Training Activity
----Training Category
------Training Activity
------Training Activity
--Employee Class
----Training Category
----Training Category

Business 2
--Employee Class           
----Training Category     
------Training Activity    
------Training Activity
------Training Activity
----Training Category
------Training Activity
------Training Activity
--Employee Class
----Training Category
----Training Category

The following things should be variable based on business needs and created upon creation of business’s account:

*Number of Stores
*Number of Employees 
*Employee Classes

*Training Categories
*Training Activities

So the grand questions are:
1) How close did I get?
2) How can it be done better?

Thanks in advance!

Here is the link to the picture of the Diagram:
http://i1227.photobucket.com/albums/ee422/CorySCline/diagram.jpg

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    It looks pretty good just from a glance. Arguably, many to many relationships should always be broken up. For example, with your company and employee table, you have a company id that links to an employee id. Consider the fact an employee could be hired by 2 different companies with all attributes the same. You would have no unique identifiers. The way to counteract this is to creating a matching table where you will have 2 attributes, company_id and employee_id (maybe an autoincrement identifier just in case).

    Similarly, consider an employee that moves between stores… You couldn’t find out an employee’s track record. Also, you do it with employee class and employee.

    • 0