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.
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.
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.
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 entitys attributes.
In a nutshell, attributes store data values that either
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.
The next lesson explains the purpose of entity identifiers.