We have a CRM which contains a memebr entity as the most important entity in the system. The thing is that it has too many attribute in it which makes it unnormalized. here are the attributes:
[MEMBER ID]
,[FIRST NAME]
,[LAST NAME],[TITLE],[ADDRESS 1],[ADDRESS 2]
,[ADDRESS 3],[POST CODE],[TELEPHONE HOME]
,[TELEPHONE WORK],[GENDER],[DURATION OF MEMBERSHIP],[START DATE]
,[AMOUNT PAID],[BALANCE],[STATUS],[DOB]
,[MONTH FEE],[ORIGINAL START DATE],[PAYMENT TYPE]
,[HEAR],[Interest],[NUMBER MONTH FEES]
,[FIRST MF DUE DATE],[LAST VISIT],[CARD NUMBER]
,[BANK NAME],[SORT CODE],[ACCOUNT NUMBER]
,[DEFINE1],[DEFINE2],[DEFINE3],[DEFINE4]
,[DEFINE5],[DEFINE6],[DEFINE7],[DEFINE8],[DEPENDENT]
,[ROLL NO],[ALLOWED VISITS],[TOTAL VISITS],[CREDIT LIMIT]
,[JOINING FEE],[NON VAT MONTH FEE],[PAYMENT METHOD]
,[CentreId],[Letter Title],[Email Address]
,[Vehicle Registration],[Standing Order Reference],[Notes]
,[Outstanding Balance],[MobileNo],[FaxNo],[Nonparent Password]
,[Emergency Name1],[Emergency Relation1],[Emergency HomeTel1],[Emergency WorkTel1],[Emergency MobileNo1]
,[Emergency Name2],[Emergency Relation2],[Emergency HomeTel2]
,[Emergency WorkTel2],[Emergency MobileNo2],[Doctors Name],[Doctors Tel],[Medical Info]
,[Password],[MethodOfContact],[Address 4],[Address 5]
,[Address 6],[ExtRef1],[ExtRef2],[ExtRef3],[ExtRef4],[OnMailingList],[HasChildren]
,[ParentMemberId],[MedicalIllness],[MedicalQuestion],[COMMENTS]
,[MembershipFeePaid],[JoiningFeePaid],[IsDeleted]
,[Pending],[Induction],[UserName]
,[CompanyName],[RowVer],[MembershipProductId]
,[Id],[EmailVerified],[ConcessionTypeId]
,[MemberTypeId],[Age],[Renewal_Date]
i was thinking about normalizing this thing. Any suggestions?
To start, if the field is numbered it is often a candidate for normalisation. Consider moving the address details out for starts. The phone numbers can be elsewhere and stored with types to save the need of having so many fields that are likely not used. Address details can follow a similar pattern if the types are given a sequence (so you can derive the order the fields should be printed for example).
Bank details are another candidate.
Consider it this way. The member should contain details that are directly relevant to the member only. Not the member’s bank, address, etc. It should contain details of their first name, last name, direct attributes of the member.
Consider reviewing some of these links for an idea:
http://databases.about.com/od/specificproducts/a/normalization.htm
http://support.microsoft.com/?id=209534
http://ipconflict.co.uk/2009/12/29/basic-guide-to-database-normalisation-first-normal-form/