An ‘Entity’ is something that actually exists in the real world – like an Organisation, Person or a Project or job that they work on.

Often databases have tables or files for things like Customers, Suppliers, Staff and so on. This is actually a bad database structure as it means that if someone is both a Customer and a member of Staff, for example, then you have to duplicate their data in two places. This means that you, rather than the system, have to remember this person is in the database twice, so that if you need to change their data you have remember to do so in both places.

What has happened is that the designer of those systems has confused data about the Person who happens to be a customer with the data that describes the relationship. The GEM approach separates the information about the Person, their Name, Age, and Sex and so on, from the data that describes the relationship – their Account No, Type of Customer and so on.

Separating the data like this also makes it possible to have multiple relationships with someone as well as track all the relationships between everyone and everything in the system.

You may have noticed when describing a Person we did not mention their Address or Phone No. This is because in the real-world an Address is something separate from a Person, and several People can share the same Address and Phone number.

The GEM approach is paranoid about duplicating data. So this means Address are modelled separately too. Hence the system can keep track of who shares the same Address. This means that if you change the Phone No for a particular Address, it immediately applies to everyone who shares the same Address. It also makes it possible for anyone to have an unlimited number of Addresses.

Remembering all the inter-relationships like this between everyone and everything in the system, means that you no-longer need to remember who shares the same data – as the system remembers it for you.  (Very important if you didn't input the original data anyway.)