Without knowing the specific of what you are trying to accomplish i would be concerned. In a traditional job tracking system objects jobs and people/staff make perfect sense. Objects forms, register and stamps are not easy to interpret as they have special meaning that only you understand and don't seem to fit into an object model for a job tracking system. If forms have anything to do with interface items, like layouts for a form data entry, then you should stop developing and construct an object relational diagram to understand the things you want to track and how they relate to each other. Once you have done that the names for tables and the data they contain will be obvious and you can structure things around that model.
all the forms have a layout for each of them and is used by user to fill in. its kind of a form filling purpose done on an ipad. the data in each form dont really have any meanings to the system. but once the form is created the user will then assign other users to view or sign the form , and the form.
the forms need to be stored based on the job number the form belongs to. and will be accessible based on the job number
could you please give me some directions on how i should proceed.
As i said you have to understand the data that you are trying to collect and how it is logically organized in order to best fit into an RDBMS.
Forms may have a place in the final schema but that is putting the cart before the horse at this point.
Filling out a form is a business process that you need to fully understand before trying to fit it into the schema
Here is an example schema of a timesheet application that could be used as a starting point to build such a system in FM.