The reason for having a database is to store data values about entities, and then to retrieve the data values about those entities as needed. In order to accomplish this, there must be some way to distinguish one entity from another.
Entity identifiers perform this function.
Entity identifiers are attributes, specifically, key attributes that uniquely identify each entity.
An entity identifier is not an optional attribute; every entity must have a key attribute to uniquely identify it. Entity identifiers (key attributes) become primary keys in a table.
A composite entity is also known as a bridge entity. This bridge is used to handle the many-to-many relationships that the traditional entity could not handle.
This entity lies between the two entities that are of interest and this composite entity shares the primary keys from both the connecting tables. This composite entity is also known as a gerund because it has the characteristics of an entity and a relationship.
You will learn about a composite entity later in the course. The composite entity exists only to link two other entities together. A composite entity has no entity identifier of its own. Instead, it receives the entity identifiers from each of the two entities it serves to link, and combines them to form a composite entity identifier (usually called a composite key attribute).
The next lesson lists two rules for creating entity identifiers.
Entity Identifier Attribute
An entity is something about which we store data. For example, a customer is an entity, as is a merchandise item stocked by Distributed Networks.
Entities are not necessarily tangible. For example, a concert is an entity.
Entities have data that describe them (their attributes).
For example, a customer entity is usually described by a
zip code, and
A concert entity might be described using the following attributes: 1) title, 2) date, 3) location, and 4) name of the performer.
When we represent entities in a database, we actually store only the attributes. Each group of attributes that describes a single real-world occurrence of an entity acts to represent an instance of an entity.
For example, in Figure 5-3, you can see three instances of a customer entity stored in a database. If we have 1000 customers in our database, there will be 1000 collections of customer attributes.