What are database entities?
We create databases to store information about things that exist in the real world. If it can be uniquely identified as being separate from other things and recorded in a database, it can be a database entity.?.
Database entities can be persons, places, events, objects, or concepts, such as a university course, job, or online order. A database can record and describe each of these, so they’re all potential database entities.
Make your own ER diagram in Gleek.
The most important element in the database entity is that it can be uniquely identified. Read on to find out how entities and attributes combine to make this possible.
What kinds of database entities are there?
Database entities can further be divided into tangible and intangible entities. If the entity physically exists in the real world, then it is tangible. A person is tangible, as is a city. If it exists logically in the real world, then it is intangible. A job is not a physical thing that you can touch, so it is intangible. The same goes for your car – tangible – and your car insurance – intangible. One may be tangible, and the other intangible, but they both exist for you and they can both be recorded in a database as database entities.
Tangible entity
Intangible entity
Entities are stored in tables in databases. Each table will contain an entity set or a list of all those entities which are considered similar. For instance, in a university database, the students might be in one table, the staff in another. If your database contains entities that share attributes, you can group them into an entity set and store them in a single table.
One of the criteria for determining whether something is an entity is that it can be differentiated from other entities, so the table will only contain unique entities. These are recorded in rows. One row per entity.
Related topic: What is an associative entity in an ERD?
If you want to be able to work with your database, you need to be able to distinguish each entity from all other entities. They need to have information describing how they exist in the real world. The way to differentiate entities in the table from each other is through attributes.
What is the difference between entities and attributes?
Each entity has its own row, but all entities in a particular table will share the same possible attributes. These attributes are the columns of the table. The attributes describe the entity. A table of employees might contain attributes such as name, address, phone number, and job title.
To preserve uniqueness, each entity should also have a key attribute. In our employee table, employee ID number might be the key attribute. No two employees should have the same employee ID number, even if otherwise they’re unusual enough to share every other attribute!
The primary key is not the only type of key. You should also watch out for terms like primary, super, secondary, surrogate, composite, foreign, candidate, and alternate keys. Each of these does a different job. For now, it might be useful to know that candidate keys are unique attributes in the table and that the primary key is selected from one of these candidate keys to be the identifier for the entity set. For example, an employee ID number might be one candidate key, social security number might be another. The database designer could choose either, but in most cases, it would be safer to go with employee ID number, despite the uniqueness of social security numbers.
Find out more about the Primary key in our recent Primary keys vs. foreign keys: The key differences article.
Each attribute also has some restrictions on the values that it can contain. These attribute domains are the rules that make sure that the entity is being described correctly. For our employee database, the domain constraints might make sure that employee ID will be of a certain length and only include certain characters, or that an email address must contain a single @ sign and no spaces. Carefully-designed domains make sure that the database entities end up with valid information and prevent headaches in the future.
The presence of a key attribute tells you something more about the type of entity. If an entity has a key attribute, then it is a strong entity type, if it does not have a key attribute, then it is a weak entity type and can only be identified in reference to a strong entity type. You can also describe a strong entity as an independent entity and a weak entity as a dependent entity.
Learn more about Weak entities and how to represent them in ERD.
Address could be an attribute in the employee example above. But it could also be an entity composed of attributes of its own, such as city, state, country, and so on. That address will remain a weak entity that depends on the employee entity for its existence.
So you have strong and weak, or independent and dependent entity types. Another type of database entity is a characteristic entity. This provides additional information on another entity. Characteristic entities, also known as attributive entities, might contain attributes that do not need to be contained in the parent entity, but which could be usefully stored in connection with it. An example might be the parts used in a car. By storing the parts in a characteristic entity, you can independently make changes to the parts without affecting the car model entity.
There are several different types of attributes. If you want to dig deeper into attributes, read our article on composite and other attributes in the entity-relationship model.
So a database entity needs its attributes for it to be differentiated from other entities. That enables your database to describe how entities interact with each other.
How do database entities interact?
It’s useful to create an entity-relationship diagram (ERD) to work out how everything works. An ERD will allow you to map out all the entities to be contained in your database, list their attributes, determine the relationships between entities, and make sure that you understand exactly what it is that you’re going to build.
Make your own ER diagram in Gleek.
If you want to design a database, you really need to learn how entities, attributes, and relationships all come together in an ERD, so check out our article: What is the entity-relationship diagram in database design?
Related posts
ER diagram example: online shopping system (Crow’s Foot notation)
Improving your database skills with many-to-many relationship examples
Primary keys vs. unique keys: Fundamental differences
Exploring One-to-Many Relationship Examples in Databases
ER diagram for an E-commerce website with Gleek's AI chat
Derived Attributes in ER diagrams: A comprehensive exploration
All about ER model cardinality with examples
The Basics of One-to-One Relationships in ERD
Relational schema vs. ER diagrams: A detailed comparison
Guide to entity-relationship diagram notations & symbols
What is the entity-relationship diagram in database design?
Composite and other attributes in the entity-relationship model