As others have mentioned, there should be an ENO column in the COMMISSION table and a foreign key to the Employee table through it.
Also, if you want to restrict the values of EMPCATEGORY to a set of known employee categories, then you might consider having a table that lists those out and a foreign key constraint from EMPCATEGORY to that table. An additional benefit is that you have a single clean list of all employee categories. By the way, what is an employee category? Is it something like Sales vs Marketing, etc? Or is it more analogous to job title? "Category" is a little too generic for my tastes.
You might consider changing the relationship between the TV_SALES table and the TV table. As things are modeled now, you record only a single kind of TV in a single sale. If you wanted to record the sale of two different kinds of TVs, you would end up with two sales records and two commissions, even if it's logically just a single sale. You could change the model by introducing a table in between the TV_SALES and TV that contains the line items. The TV_SALES table would represent the entire sale. The intermediate table (TV_SALES_LINEITEM) would represent each line item on the sale and it would reference the unit purchased and the quantity.
Do you need to support partial payments of commissions? Would you record any additional information about the payment other than the date it was paid? For instance, you might record a check number of something. If so, you could split out that information into a different table. The COMMISSION table would record what commission should have been generated from the sale. A PAYMENT table could record how that commission was paid, and it could also be used if you had to pay your employees for other things. The COMMISSION table would contain a nullable PAYMENT_ID that refers to a record in the PAYMENT table.
Facebook
Twitter