Normalising Customers and Employers with a people table At what normalisation stage is it recommend to split say Customers and Employees into a People table and then link to the unique attributes of Customers and Employees? I can't seem to find the Functional Dependency to justify the change. This makes sense in OOP where you use inheritance but I don’t understand why it is done in database schemas.

This is an example of what I mean, possibly with more unique attributes:



Customers: Cid, FName, LName, AddId, CustType    
Employees: Eid, FName, LName, AddId, EmpType


vs

People   : FName, LName, AddId    
Customers: PeopleId, CustType
Employers: PeopleId, EmpType


The current answers explain why it is recommended to move data to a People table; however, at what normalisation stage does it become a FD to justify creating the extra table?
The design of your tables is not, as you noted, an OOP inheritance.  The underlying model is simpler:  


Do not duplicate your data! 


The more data you have, the more important this is because:


Nobody will type the duplicate data exactly the same in all cases.  (Names, Addresses, etc.)
If you have entered similar data in two different tables, you will regularly need to do some Sherlocking to figure out who is whom.


Having said that, people identification (particularly customers) is difficult to get correct and consistent no matter how diligent you try to be.  Likely you will unwittingly enter some people a second or third time.  But a People table gives you one place to examine, which can be a bit of a help.

Creating a Persons table would be 2nd Normal Form.  

I do not really understand what issue you are struggling with when you ask: when it "becomes an FD to justify creating the extra table". You are basically making a choice between:


Choosing to just cope with variant and duplicated data.
Set up your data to avoid duplicated data as much as possible.  


I avoid duplicating data as much as possible, because it gives me fewer headaches over time.