Independent and Dependent, or as they can be found in some publications: strong and weak entities. We will also adopt the strong / weak notation because we find it more suggestive. In order to define the two categories, we appeal to the intuition that every entity should have a set of attributes that uniquely identifies that entity. The minimal such set is called the primary key. So, a strong entity is an entity that does not rely on any other entity for identification. A weak entity relies on the existence of another entity, in which case its primary key or part of it is called a foreign key ( intuitively because it is a primary key of the entity it depends on ).
According to the English Dictionary , an entity is "Something that exists as a particular and discrete unit ", and adapted from  , a definition that can be the starting point in the discussion is that an entity is something that has a distinct, separate existence, though it need not be a material existence. In the context of databases, entities became the main discrete data objects that make the subject of collecting and keeping data. There have been developed techniques and methodologies of identifying entities for a certain problem or world which we do not cover here, we mention just that in the general case entities are usually recognizable concrete or abstract concepts.
Examples of entities are: person, places, things, or events which have relevance to the database. For the medical world we develop the Epocrates software, easy recognizable entities are : drug, disease, diagnosis, symptom and many others. The more difficult to recognize imply the experience of the database designer and its knowledge on the subject as they resulted from the analysis and requirements gathering phases.
There are many classifications that can be done on entities, based on the criteria used. One of the most important is the classification that divides entities into two main categories :
An entity occurrence ( also called an instance ) is an individual occurrence of an entity. In the mapping process, any occurrence of the entity has an analogous row in the relational table.
A relationship represents an association between two or more entities. An example of a relationship in the medical world would be:
any drug is produced by one manufacturer.
a disease presents zero, one or more symptoms.
a drug causes more reactions, and a reaction can be caused by one or more drugs.
An attribute is the abstraction used to describe one property of the entity set ( the totality of the one entity instances makes up the entity set ). A value is an attribute's particular instance. The entire collection of possible values an attribute can have is called the domain of an attribute.
The classification of attributes is done according to their role : whether they identify an instance of an entity or not. If they do, they are called identifiers, and if describe a non-unique characteristic they are called descriptors. Identifiers are generally named keys.
Having introduced all the key elements of the ER model ( entities, attributes and relationships ), the introduction on special entity types and the discussion about relationships classification ( which have been intentionally omitted ) is required.
SPECIAL ENTITY TYPES
The Associative entity is used to solve the problem of two entities with a many-to-many relationship; what this entity really does is to associate two or more entities in order to reconcile a many-to-many relationship like the third example above : "a drug can cause more reactions, and a reaction can be caused by one or more drugs".
A proper solution to this situation would be an associative entity DrugsReactions that keeps track of the relationship between the two strong entities drugs and reactions.
Subtypes entities are used in generalization hierarchies in order to represent a subset of instances of their parent entity; the subset has the property that it has relationships or attributes that apply only to the subset. The parent entity is called the super type.
An example of subtype entity in a hospital model could be the employee - doctor, with the meaning that doctor represents an employee with more access rights, info available, etc with respect to a common employee.