Transforming forms to table design is not really difficult if you will follow a set of structured steps without doing immediate shortcuts. For me to illustrate that process, let us have this sample form shown left.
It would help if you underline the data items with red (header and footer) or blue (body). Before we design the tables, each form is unique and there is a particular data that identifies a form (this is typically the form #). This identifier help us identify one form from another. In our example, we can obviously identify the Purchase Order # as our form identifier.
Any business form will have the following parts - Header data, body, footer. Identifying these parts of the form will allow you to create a skeleton table design which you will adjust later. As a rule to follow, header and footer data are all in one table called the parent table, and the data in the body is in another table called the child table.
Investigating our sample form, what are the data in the form that forms the header, footer and the body? You can seek the assistance of the company to help you identify these parts if you are not accustomed to it yet.
It would help if you underline the data items with red (header and footer) or blue (body). Before we design the tables, each form is unique and there is a particular data that identifies a form (this is typically the form #). This identifier help us identify one form from another. In our example, we can obviously identify the Purchase Order # as our form identifier.The image on the left shows the same form marked with the footer and header data (in red) and the body data (in blue).
What's next?
After identifying header and footer data, and body data, we can directly do a draft table design from this following the basic rule we have stated above (parent and child table). See the image below.
What's next?
After identifying header and footer data, and body data, we can directly do a draft table design from this following the basic rule we have stated above (parent and child table). See the image below.
If you have noticed, the primary key of the parent table (PURCHASE ORDER) is the identifier we decided for the form early on. The primary key of the child table (PURCHASE ORDER DETAILS) is the combined identifier of the form and the identifier for each of the records in the body (which in our sample is obviously the item#).
At this point, you have a draft table design. You are ready to go for design refinements through normalization and other splitting the table methods. To refer to the possible situations that will signal us that splitting tables are necessary, check this blog post.
