Martin has 16 years experience in Human Resources Information Systems and has a PhD in Information Technology Management. He is an adjunct professor of computer science and computer programming.
This lesson describes the concept of an entity in a database. Entity attributes are also discussed along with the relationships between entities, including a simple example of an entity relationship diagram.
An entity is an object that exists. It doesn't have to do anything; it just has to exist. In database administration, an entity can be a single thing, person, place, or object. Data can be stored about such entities. A design tool that allows database administrators to view the relationships between several entities is called the entity relationship diagram (ERD).
In database administration, only those things about which data will be captured or stored is considered an entity. If you aren't going to capture data about something, there's no point in creating an entity in a database.
If you're creating a database of your employees, examples of entities you may have include employees and health plan enrollment.
An attribute defines the information about the entity that needs to be stored. If the entity is an employee, attributes could include name, employee ID, health plan enrollment, and work location. An entity will have zero or more attributes, and each of those attributes apply only to that entity. For example, the employee ID of 123456 belongs to that employee entity alone.
Attributes also have further refinements, such as domain and key. The domain of an entity describes the possible values of attributes. In the entity, each attribute will have only one value, which could be blank or it could be a number, text, a date, or a time. Here are examples of entity types and domains:
Name: Jane Doe
Employee ID: 123456
Health Plan Enrollment: Premium Plan
Work Location: RO, ME, Floor 2
Here's an example figure of an entity.
The key is the unique identifier that identifies the entity. A key is also a domain because it will have values. These values are unique to each record, and so it's a special type of domain. A key isn't always required, but it should be! In our example, a unique key value ensures that the Employee entity cannot have duplicate Social Security Numbers or Employee IDs.
Entity or Attribute?
The previous example of an employee leaves little doubt in the difference between an entity and an attribute. Jane is the entity and has an employee ID of 123456, which is the attribute. But what if we add in 'email address'? Is 'work location' an attribute of Jane, or is 'work location address' its own entity? We could define an entity of 'work location' and add the attribute of 'name' to it. There really isn't a wrong answer, but it's something to consider when designing a database. Some rules of thumb to ponder when in doubt include asking:
Over 79,000 lessons in all major subjects
Get access risk-free for 30 days,
just create an account.
Is the item directly related to the purpose of the database? In the previous example, we only care about the employees and not the work location. Since the focus is on the employee, the work location fits better as an attribute of the employee entity.
Are there components within the item itself? We've placed the health plan in the entity as an attribute. However, employees can be in more than one benefit, and even health plan enrollments can change over time. We could store the plan name, effective date, coverage options, and so forth, into another entity and relate them together.
Could the item have more than one instance? There can't be more than one employee with the same ID; but a single employee could have more than one e-mail address. If the company policy allows this, then we have to split off e-mail into its own entity.
Is the item often blank or unknown? Let's return to the example of a benefit. Not all employees take flexible spending accounts. In a large organization, the employee entities would have thousands of blanks for the 'benefit plan' attribute. Again, it makes much more sense to split off benefit plans to their own entities.
The entities by themselves serve little purpose if they cannot be tied with other entities and attributes within the database. In database structure, two or more entities are tied together in a defined relationship. An example of a relationship, using the previous example of an employee, would be the relationship of the employee to the health plan. One health plan may have thousands of enrolled employees.
For example, say an employee enrolls in a dependent care flexible spending account. The entities are 'employee' and 'benefit plan' and the relationship is 'enrolls in.' In the figure, we've removed the benefit enrollment as an attribute and created a separate entity and thus a simple relationship diagram displays how all pieces might fit together.
This lesson has defined an entity in terms of database structure and design. An entity is an object about which data is to be captured. The attributes of an entity further define the information being stored. For database effectiveness, some attributes become entities. Entities are also joined together in relationships. An important domain type is the key. It should be a required value that's unique to every record in the entity, such as a Social Security Number or Employee ID.
Did you know… We have over 200 college
courses that prepare you to earn
credit by exam that is accepted by over 1,500 colleges and universities. You can test out of the
first two years of college and save thousands off your degree. Anyone can earn
credit-by-exam regardless of age or education level.