The first step in the logical design stage of the (DBLC) database life cycle is to create a conceptual model.
This involves converting business objects (and their characteristics) identified during requirements analysis into the language of
entities and attributes for use in an ER diagram.

Entities

An entity is a business object and can be either tangible (such as a person or an item) or intangible (such as an event or a reservation).
Every entity in a database must have a different name. It is common practice (but not required) to name entities in the singular.
Entities become tables in a database. Special types of entities, discussed in a later module, are sometimes created to represent the relationship between other entities.

Entities and attributes used in relational database design

When thinking about what constitutes an entity, it is important not to confuse an aggregate concept, such as an inventory or a medical history, with a single entity.
These aggregates actually represent groups of entities and not single, discrete entities.

Attributes

Just as business objects have characteristics that describe them, entities are described by their attributes.
When we represent an entity in a database, what we actually store are that entitys attributes.
In a nutshell, attributes store data values that either

describe or

identify entities.

data value: Data entered at the intersection of a row (record) and column (field); the data describes or identifies the subject of the record.

Attributes become fields in a table.

Attributes that describe a person (for instance, customer, employee, student, etc.) would include such things as name, address, and telephone number.
Attributes that identify a person would include such things as social security number or any combination of letters and numbers that uniquely identify a person.

Attributes that describe entities are called non-key attributes.

Attributes that identify entities (entity identifiers) are called key attributes.