重新設計CRM中成員實體的建議

-2

我們有一個包含memebr實體的CRM作爲系統中最重要的實體。問題在於它有太多的屬性，導致它不規範。這裏是屬性：重新設計CRM中成員實體的建議

[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]

我正在考慮正常化這件事情。有什麼建議麼？

來源

2011-05-23 AliAliAli

應根據數據使用情況仔細執行標準化和非標準化等。查看屬性時引起注意的是當然是許多編號這些領域肯定是正常化的候選人，並且會爲您提供關於相關價值數量的更大靈活性。但建議必須具體針對特定領域。 – faester 2011-05-23 08:08:16