database normalization

EDIT: Would it be a good idea to just keep it all under 1 big table and have a flag that differentiates the different forms?

I have to build a site with 5 forms, maybe more. so far the fields for the forms are the following:

What would be the best approach to normalize this design?

I was thinking about splitti开发者_如何转开发ng "Personal Details" into 3 different tables:

and then reference them from the others with an ID...

Would that make sense? It looks like I'll end up with lots of relationships...

Normalized data essentially means that the same data is not stored multiple times in multiple places. For example, instead of storing the customer contact info with an order, the customer ID is stored with the order and the customer's contact information is 'related' to the order. When the customer's phone number is updated, there is only one place the phone number needs to be updated (the customer table) and all the orders will have the correct information without being updated. Each piece of data exists in one, and only one, place. This is normalized data.

So, to answer your question: no, you will not make your database structure more normalized by breaking up a large table as you described.

The reason to break up a single table into multiple tables is usually to create a one to many relationship. For example, one person might have multiple e-mail addresses. Or multiple physical addresses. Another common reason for breaking up tables is to make systems modular, so that tables can be created that join to existing tables without modifying the existing tables.

Breaking one big table into multiple little tables, with a one to one relationship between them, doesn't make the data any more normalized, it just makes your queries more of a pain to write.* And you don't want to structure your database design around interfaces (forms) unless there is a good reason. There usually isn't.

*Although there are sometimes good reasons to break up big tables and create one to one relationships, normalization isn't one of them.