Looks reasonable
Couple of things I would question:
In the instructor table what is in skills and time-avail?
What is the relationship between Instructor and Product, if it is 1 Product can have many Instructors and an Instructor can only have 1 Product then it is okay. If it is a one to one then I would say why not put it all in one table. If it is a many to many then you need a link table with Instructor#, Product# (nothing else) and take Product# out of Instructor table.
In the Product table what is in package-details?
In the Customer table I would think about splitting Name into Firstname and Surname fields, I would split Address into different fields i.e. house_number, street, town, post_code etc.
makes querying easier and more efficient, for example if I want to know all customers that stay in 'High Street' and have the surname 'Smith'
the way you have it just now the query would be
select * from customer where
name like '%Smith%' and address like '%High Street%'
using the % at the start of a where clause value would mean a full table scan on all records, not an issue on small tables but try it with 1 million records. With the fields split you would have
select * from customer where
surname = 'Smith' and street = 'High Street'
much more efficient, or if people entering data put things like High St., High Street, High St into the street field even a search like
where street like 'High St%' is still efficient.
Don't use dashes (-) in your field names use underscores _ , easier to port to other databases (Oracle for example).
Keep your case consistent, I use all UPPERCASE for field name and table names.
Hope this helps
Mike
