Thanks for your advice. There are a lot of points here, so to be clear. Naming to avoid ambiguity/irrelevant conventions is a must so I'll definitley do this, but have some questions about structure.

@jeff Moden "I would plan on any given contact having more than one phone number, more than one email address, and working for more than one company, as well as the items previously mentioned." The contacts have 1 job, if the job changes the record is replaced, so I am not sure about this level of normalisation...

@alan. B "Economic Class can be it's own table with a Foriegn Key (e.g. EconomicClass_ID) in your ContactInformation table. Also think about object where there may be a one-to-many relationship such as Email or Phone_Nbr. I sometimes like to give those things their own table.

If Sector is a subcategory of Economic class you could snowflake that out as Category > Sector > SectorID in you ContactInformation Table. If, in your OLTP environment, you need to get the Economic Class, Sector and info from the ContactInformation table you could do this in a view and index it."

If economic class is seperate table, is it logical to put Category, Sector, Sector ID in ContactINformation i.e. with the names?

Are there some clear delineations that are an absolute must, as I am struggling a bit with how these would work. My mind can't get past that if info is linked to a person then that has to be in their table with their name...I do want to implement the changes I jus tneed to get my head around it. Thanks for your help 😉