Entity is a logical concept of relational database model. And table is used to express it, but there is a slight difference. Table expresses not only entities, but also relations.

For example, assume that you want to make a database of projects and employees of a company. Entity is a unit of information that has meanings by itself. In this case, there will be two entities - "Project" and "Employee". Each entity has its own attributes.

In relational DB model, there is another idea, 'relation'. If employees participate in several projects, then we can say that there is a relation with a name 'works_on'.

Sometimes, relation can have its own attribute. In this case, 'works_on' relation can have attribute 'start_date' and so on. And if this relation is M:N relation(Like this case: In project 1, there are 5 employees. Employee A works on two projects.), then you have to make an extra table to express this relation. (If you don't make an extra table when the relation is M:N, then you have to insert too many duplicated rows into both 'Project' and 'Employee' table.)

CREATE TABLE works_on(
  employee,
  project_id,
  start_date
)

That's quite a general question!

Basically, all types that the database system itself offers, like NUMERIC, VARCHAR etc., or that the programming language of choice offers (int, string etc.) would be considered "atomic" data(base) types.

Anything that you - based on your program's or business' requirements - build from that, business objects and so forth, are entities.

Tables, constraints and so forth are database-internal objects needed to store and retrieve data, but those are general not considered "entities". The data stored in your tables, when retrieved and converted into an object, that then is an entity.

Marc