The basic table structure is correct. The problem is that the Contacts table has several multi-valued fields such as children's names and contact's interests.
It may seem like overkill to make additional tables to take care of children and contact's interests and spouses interests and lookup tables for interests and marital status but, if collecting accurate data is important then you want to keep it organized in a way that you can easily use it. People create multi-valued fields for ancillary data because they don't understand the value of proper structure. They don't understand how difficult multi-valued fields and repeating groups are to work with until it is too late. They feel that they have too much invested to make such a major change and so the db is crippled from the get-go.
Even when I build little apps for myself such as address books and household inventory, I structure the tables properly. It is always easier for me to do it right the first time than to do it over again or work around a stupid structure problem.
There is no alternate index on contact information so technically you can enter the same contact multiple times. A multi-part unique index would prevent this. But be careful because you may run into legimitate duplicates of first name and last name and if you include company name as a third field in the index, it must always have a value.