You asked about combining the address tables. I think I would not, however, I wonder about the split of the address tables from their parent. If a client can have many addresses, or an EC many addresses, you have it right (one to many, client to addresses or EC to address). If you will only keep one address per client, and one address for ED, then the address fields could go into the client ad EC tables. Or, combine the addresses into one table and distinguish by a type field (EC vs CL). If one thinks of addresses as a separate entity for business reasons, then you would do the latter, but I don't see them that way for your business model. That does not mean I am correct, it's just a judgement call based on my limited understanding of the business model. Then there are phone numbers. Why allow a client to have two listed by an EC only one?
For example:
- when you see AddressID in tblCLaddress (you should have used type prefixes) you know it is the client address id. I wouldn't call it ClientAddressID - minor point.
- I'd use FName, LName. You will find that Access distinguishes their parent table as tblClient.Fname or tblEC.Fname
- consider Tele1, Tele2, Tele3 (lest you limit types to home and cell - what about Office? Or whatever else may come up? They say 'normalize until it hurts', which would mean putting phone numbers into a different table rather than have a bunch of holes in your data where there are no extra contact numbers. You'd join them by type EC/CL as already mentioned.
You are forgetting or have missed a very important point from prior posts in this thread. NO WAY should you have a field named "HouseNumber/Name". No special characters other than the underscore _. I recommend you shorten names as well. If you have to write code in the future, long names become a pain (as do underscores, which is why I rarely use them). This includes Google+.
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.