Entities and Attributes

Introduction

Entities and attributes are two of the first concepts you must understand when learning database design, SQL table design, and the relational model. Before a developer writes CREATE TABLE statements, before a tester validates database records, and before an architect creates an ER diagram, the team must answer two simple questions: what things does the system need to store, and what information must be stored about each thing? The answers to those questions lead directly to entities and attributes.

An entity represents a real-world object, person, place, event, transaction, or business concept about which the system needs to store information. A customer, employee, product, order, payment, department, course, account, subscription, shipment, and invoice can all be entities depending on the application. An attribute represents a property or characteristic that describes an entity. For an employee, attributes may include employee_id, first_name, last_name, email, salary, hire_date, and department_id.

Entity
  |
Employee
  |
Attributes:
employee_id
first_name
last_name
email
salary
hire_date

When implemented in a relational database, an entity commonly becomes a table and an attribute commonly becomes a column. Each row in the table represents one entity instance, and each cell stores an attribute value for that instance. This mapping is simple, but it is the foundation for strong database design.

What Is an Entity?

An entity is something meaningful to the business or application about which data needs to be stored. It is not just any noun in a requirement sentence. It is a business object or concept that has enough identity, properties, relationships, or lifecycle to be tracked by the system. In an e-commerce system, Customer, Product, Order, Payment, and Shipment are good candidate entities because each one represents a real business concept with multiple properties and meaningful behavior.

An entity can be physical, conceptual, or event-based. Physical entities include objects that exist in the real world, such as Employee, Laptop, Vehicle, Product, Book, Device, Warehouse, or Store. Conceptual entities include ideas or business structures such as Account, Subscription, Department, Role, Contract, Course, or Project. Event entities represent things that happen, such as Login, Payment, Order, Appointment, Shipment, Refund, Transfer, or Purchase.

E-Commerce System
  |
  +-- Customer
  +-- Product
  +-- Order
  +-- Payment
  +-- Shipment

The important point is that an entity represents something the business cares about. If the business asks reports about it, applies rules to it, tracks its status, stores history for it, or relates it to other things, it is probably an entity.

Entity to Table Mapping

In relational database implementation, an entity commonly becomes a table. The entity Customer becomes a customers table. The entity Product becomes a products table. The entity Order becomes an orders table. The table stores multiple instances of the entity, and each row represents one specific instance.

CREATE TABLE customers (
    customer_id INT PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    email VARCHAR(150) UNIQUE
);

In the example above, Customer is the entity, customers is the table, customer_id, name, and email are attributes implemented as columns, and each inserted row represents one customer. The database table is the practical SQL structure used to store the modeled entity.

Entity and table are closely related, but they are not exactly identical. Entity is a data-modeling concept. Table is a relational database implementation structure. Usually one entity maps to one table, but some designs may represent one conceptual entity using multiple tables, and some technical tables may exist for logging, auditing, caching, mapping, or framework purposes rather than direct business modeling.

Entity Type, Entity Instance, and Entity Set

An entity type describes a category of things. CUSTOMER is an entity type. EMPLOYEE is an entity type. PRODUCT is an entity type. It defines what kind of thing the system stores. An entity instance is one specific occurrence of that type. Customer 101 named John Smith is an entity instance. Product 501 named Laptop is an entity instance.

An entity set is a collection of entities of the same type. All customer records together form the customer entity set. In SQL, the corresponding table contains that collection of rows. The table structure represents the entity type, and the rows represent entity instances.

This distinction becomes important when explaining database design in interviews. If someone asks whether Customer is a table or a row, the precise answer is that Customer as a type maps to a table, while one specific customer maps to a row.

How to Identify Entities

The most practical way to identify entities is to start with business requirements. Read the requirement and identify important nouns, but do not blindly convert every noun into a table. For example, the requirement "customers place orders containing products and make payments for their orders" contains several useful candidate entities: Customer, Order, Product, and Payment.

Business Requirement
       |
Identify Important Nouns
       |
Candidate Entities
       |
Validate Business Meaning
       |
Final Entities

Not every noun is an entity. In the sentence "a customer has a name and email address," Customer is usually an entity, while name and email are usually attributes. The difference is business identity. A customer has independent meaning, may have many properties, can be uniquely identified, and can be related to orders, payments, addresses, tickets, and accounts. A name normally describes the customer; it does not usually need its own independent lifecycle.

Useful questions help confirm whether something should be an entity. Does the business need to store information about it? Does it have multiple properties? Can multiple instances exist? Does it need to be uniquely identified? Does it have relationships with other business objects? Does it have an independent lifecycle? Do we need to track history for it? If several answers are yes, the concept may deserve its own entity.

What Is an Attribute?

An attribute is a property or characteristic that describes an entity. If Customer is the entity, customer_id, first_name, last_name, email, phone, date_of_birth, created_at, and status may be attributes. If Product is the entity, product_id, sku, product_name, description, price, stock_quantity, and category_id may be attributes.

Attributes provide information about individual entity instances. One customer has one customer_id value, one email value, one status value, and perhaps one created_at value. The attribute name describes the type of information; the attribute value is the actual stored data for a specific instance.

Entity:   Employee
Attribute: department
Value:     IT

Entity:   Product
Attribute: price
Value:     499.99

When implemented in SQL, an attribute commonly becomes a column. For example, the email attribute can become email VARCHAR(150) inside the customers table. The attribute definition should include a suitable data type, size, nullability, default value, uniqueness rule, and other constraints when required.

Entity, Attribute, and Value

Beginners often confuse entity, attribute, and value. The entity is the thing. The attribute is the property. The value is the actual data. Customer is a thing. City is a property. Chicago is a value. Product is a thing. Price is a property. 499.99 is a value.

In table form, the table name commonly represents the entity type, column names represent attributes, and cell contents represent values. A row represents one entity instance with values for its attributes.

In this example, Customer is the entity type, customers would be the table, customer_id, name, and city are attributes, and 101, John, and Chicago are values in one entity instance. This mental separation prevents many modeling mistakes.

Types of Attributes

Attributes can be classified in several useful ways. A simple attribute is treated as an indivisible value in the data model. Salary, product_id, quantity, price, and hire_date are usually simple attributes for many applications. A composite attribute can be logically divided into smaller attributes. Name may be divided into first_name, middle_name, and last_name. Address may be divided into street, city, state, postal_code, and country.

Whether an attribute should be split depends on how the business uses the data. If the system needs to search by state, calculate shipping by postal code, or group customers by country, storing the address as one long text field is weak design. If the value is a free-form product description, splitting it into many columns may not add value.

Composite Attribute: Address
  |
  +-- street
  +-- city
  +-- state
  +-- postal_code
  +-- country

A single-valued attribute has one value for each entity instance. An employee may have one original hire_date in an employment record. A product may have one product_id. A multi-valued attribute can have multiple values for one entity instance. A customer may have mobile, home, and work phone numbers. A product may have multiple images. A student may have multiple emergency contacts.

Multi-valued attributes often signal the need for another table. Instead of phone1, phone2, phone3, and phone4 columns, create a customer_phones table. That design allows any number of phone records, avoids many NULLs, supports phone type metadata, and makes searching easier.

Stored and Derived Attributes

A stored attribute is physically stored in the database. date_of_birth, quantity, unit_price, first_name, created_at, and salary are examples. The database retains the actual value. A derived attribute can be calculated from other attributes. Age can be calculated from date_of_birth. Line total can be calculated from quantity and unit_price.

SELECT
    quantity,
    unit_price,
    quantity * unit_price AS line_total
FROM order_items;

Derived attributes are not always wrong to store. Sometimes systems store derived values for performance, historical accuracy, audit needs, or reporting convenience. For example, an order line may store unit_price at the time of purchase because product prices can change later. The important design question is whether the value should be recalculated each time or preserved as a historical fact.

Key, Optional, and Mandatory Attributes

A key attribute participates in uniquely identifying an entity. employee_id identifies an employee. customer_id identifies a customer. product_id identifies a product. A primary key attribute is the selected main identifier in a table. A composite key uses multiple attributes together to identify a row, such as student_id and course_id in an enrollment table.

CREATE TABLE enrollment (
    student_id INT NOT NULL,
    course_id INT NOT NULL,
    enrollment_date DATE NOT NULL,
    final_grade VARCHAR(5),
    PRIMARY KEY (student_id, course_id)
);

An optional attribute may have no value for some entity instances. middle_name is a common example. Some customers may not have a secondary phone number. Some orders may not have a coupon_code. SQL commonly represents optional values with NULL, although NULL should be used carefully and with clear meaning.

A mandatory attribute must have a value. customer_id, product_name, order_date, and email may be mandatory depending on business requirements. SQL uses NOT NULL to enforce mandatory data. Mandatory attributes are important because they protect required business information from being missed.

CREATE TABLE customers (
    customer_id INT PRIMARY KEY,
    email VARCHAR(150) NOT NULL,
    created_at TIMESTAMP NOT NULL
);

Attribute Domains, Data Types, and Constraints

Every attribute should have an appropriate domain. The domain describes the set of valid values for the attribute. For quantity, the domain may be positive integers. For order_status, the domain may be NEW, PAID, SHIPPED, DELIVERED, CANCELLED, and REFUNDED. For salary, the domain may be non-negative decimal values within an expected range.

In SQL, domains are implemented through data types and constraints. Data types define the kind of value: INT, VARCHAR, DATE, TIMESTAMP, DECIMAL, BOOLEAN, or other database-specific types. Constraints add rules such as NOT NULL, UNIQUE, PRIMARY KEY, FOREIGN KEY, CHECK, and DEFAULT.

CREATE TABLE products (
    product_id INT PRIMARY KEY,
    product_name VARCHAR(150) NOT NULL,
    sku VARCHAR(50) UNIQUE,
    price DECIMAL(10,2) CHECK (price >= 0),
    stock_quantity INT DEFAULT 0 CHECK (stock_quantity >= 0)
);

Good attribute design is not only about choosing a name. It includes choosing the correct data type, length, precision, scale, nullability, uniqueness, and validation rules. A price stored as VARCHAR is a design problem because the database cannot naturally compare, sum, or validate it as a number. A date stored as text creates sorting and formatting problems. Attribute choices affect correctness, performance, maintainability, and reporting.

Strong Entities and Weak Entities

A strong entity can be uniquely identified using its own attributes and does not depend on another entity for its identity. Customer is usually a strong entity because customer_id identifies the customer independently. Product is usually a strong entity because product_id or sku can identify a product independently. Department may be a strong entity if department_id identifies it.

A weak entity cannot be fully identified by its own attributes alone in the classical ER-model sense. Its identity depends on another entity, called the owner entity. Order Item is a common example. A line_number of 1 is not globally unique across all orders, but order_id 5001 plus line_number 1 can uniquely identify the first item in order 5001.

ORDER
  1
  |
  N
ORDER_ITEM

ORDER_ITEM key:
order_id + line_number

In SQL, weak entities are often implemented with composite primary keys that include the owner entity's key. They also use foreign keys to enforce the dependency. This structure clearly shows that the weak entity belongs to the owner.

CREATE TABLE order_items (
    order_id INT NOT NULL,
    line_number INT NOT NULL,
    product_id INT NOT NULL,
    quantity INT NOT NULL,
    PRIMARY KEY (order_id, line_number),
    FOREIGN KEY (order_id)
        REFERENCES orders(order_id)
);

Associative Entities

An associative entity represents a many-to-many relationship and may contain attributes of its own. Student and Course are a common example. A student can enroll in many courses, and a course can contain many students. The relationship between them is not just a line in a diagram because it may have its own information such as enrollment_date, status, final_grade, and completion_date.

STUDENT
   |
   N
ENROLLMENT
   N
   |
COURSE

Enrollment is an associative entity. It represents the relationship between Student and Course while storing facts that belong to that relationship. final_grade should not be stored only on Student because a student can have different grades for different courses. It should not be stored only on Course because different students receive different grades. It belongs to Enrollment.

CREATE TABLE enrollment (
    student_id INT NOT NULL,
    course_id INT NOT NULL,
    enrollment_date DATE NOT NULL,
    status VARCHAR(20) NOT NULL,
    final_grade VARCHAR(5),
    PRIMARY KEY (student_id, course_id)
);

Recognizing associative entities is one of the skills that separates basic table creation from real database modeling.

Entity vs Attribute Decisions

One of the most important design questions is whether a concept should be modeled as an entity or an attribute. Address is a good example. In a simple application, customer address may be stored as street, city, state, and postal_code attributes inside the customer table. In a more complex application, a customer may have multiple addresses, addresses may be verified, shipping and billing addresses may be tracked separately, and address history may matter. In that case, Address may deserve its own entity.

A concept should be considered as a separate entity when it has multiple attributes of its own, can occur multiple times, has its own lifecycle, has relationships with other entities, needs historical tracking, or needs independent identification. Phone number can be a simple attribute in a small system, but a separate PHONE table in a system that tracks phone type, country code, verification status, primary flag, and verified_at timestamp.

Department is another useful example. For a very small report, department_name on Employee may be acceptable. For a real organization, Department usually becomes an entity because it can have department_id, department_name, manager_id, location, budget, and relationships with employees, projects, and cost centers.

Poor for large systems:
EMPLOYEE(employee_id, name, department_name)

Better:
DEPARTMENT(department_id, department_name, manager_id, location)
EMPLOYEE(employee_id, name, department_id)

Attribute Placement Matters

Attributes should describe the correct entity. order_date belongs to Order, not Customer. customer_email belongs primarily to Customer, not Order. product_price may belong to Product as a current price, while unit_price may belong to Order Item as the price captured at purchase time. Good placement reduces duplication and avoids synchronization problems.

Poor placement often creates repeated data. If orders store customer_name, customer_email, and customer_phone on every row, the same customer data repeats across many orders. If the customer email changes, many order rows may need updates. If one row is missed, the database contains conflicting customer information.

Poor:
ORDERS(order_id, customer_name, customer_email, customer_phone)

Better:
CUSTOMERS(customer_id, name, email, phone)
ORDERS(order_id, customer_id, order_date)

Sometimes historical snapshots are intentionally stored. For example, an invoice may store billing_name and billing_address exactly as they were at the time of invoice generation. That is not always a mistake. The key is to understand whether repeated data is uncontrolled duplication or intentional history.

Common Attribute Design Problems

Repeated columns are a common sign of weak modeling. Columns such as phone1, phone2, phone3, product1, product2, product3, image1, image2, and image3 usually indicate a multi-valued concept. This design sets an arbitrary maximum, creates many NULLs, makes searching harder, and complicates validation. A separate dependent table is usually cleaner.

Packing attributes together is another problem. A column such as customer_info containing "101|John|Chicago|john@test.com" prevents proper filtering, sorting, indexing, validation, and joining. Separate meaningful facts into separate attributes.

Avoid storing multiple entity types in one table. A PEOPLE_AND_PRODUCTS table with id, name, email, price, and stock mixes unrelated concepts. Customer rows will have irrelevant product attributes, and product rows will have irrelevant customer attributes. Separate Customer and Product into their own entities.

Excessive NULL attributes may signal a design issue. A Payment table with credit_card_number, bank_account, paypal_email, and crypto_wallet may have many NULLs because only one payment method applies per row. Depending on requirements, payment-method-specific tables or structured subtypes may be better.

Names, Units, and Time Attributes

Attribute names should have clear business meaning. Generic names such as date, value, type, flag, and status are often ambiguous. Better names include order_date, payment_amount, customer_type, is_active, order_status, payment_status, and shipment_status. A good name reduces guesswork for developers, testers, analysts, and future maintainers.

Numeric attributes should define their units. weight = 25 is ambiguous because it could mean kilograms, pounds, or grams. The model should establish the unit through naming, documentation, or a related unit attribute. Examples include weight_kg, length_cm, duration_seconds, and amount_usd, where the fixed unit is part of the business rule.

Time-related attributes should be precise. Instead of a vague date column, use created_at, updated_at, order_date, shipped_at, delivered_at, cancelled_at, login_time, or effective_from. Each name communicates a different business event. Precise naming becomes especially important in audits, reports, debugging, and automation validation.

Current Values and Historical Entities

Some attributes represent current values. Employee salary on the EMPLOYEE table may represent the current salary. Order status on the ORDER table may represent the current status. Customer address on CUSTOMER may represent the current primary address. This is acceptable when only the latest value matters.

If history matters, the attribute may need to become a separate entity or dependent table. Salary history is a common example. Instead of storing only current salary, the system may need salary, effective_from, effective_to, changed_by, and reason. Those facts belong in a SALARY_HISTORY relation.

EMPLOYEE
  1
  |
  N
SALARY_HISTORY

SALARY_HISTORY:
employee_id
salary
effective_from
effective_to
changed_by

Status history works the same way. If the business only needs current order_status, one attribute may be enough. If the business needs every status change, including when it changed and who changed it, create ORDER_STATUS_HISTORY. The requirement for history often transforms an attribute into an entity-like record.

Entities and Relationships

Entities rarely exist completely independently. Customers place orders. Orders contain order items. Order items refer to products. Departments employ employees. Students enroll in courses. Accounts receive transactions. These associations are relationships, and in relational databases they are implemented through keys and sometimes junction tables.

CUSTOMER
   |
   1:N
   |
ORDER
   |
   1:N
   |
ORDER_ITEM
   |
   N:1
   |
PRODUCT

Attributes can participate in relationships. orders.customer_id is an attribute of the orders table, but it is also a foreign key that connects an order to a customer. enrollment.student_id and enrollment.course_id are attributes, but together they identify an enrollment and connect it to Student and Course.

This is why entity and attribute design cannot be separated from relationship design. The entities define what the business stores. The attributes define what is known about each entity. The relationships explain how those entities interact.

ER Diagram Representation

In traditional ER diagrams, entities are commonly shown as rectangles and attributes are shown around or inside the entity depending on the notation. In modern practical ERD tools, a table-like box is common. The top of the box shows the entity or table name, and the body lists attributes, including primary keys and foreign keys.

+----------------------+
| CUSTOMER             |
+----------------------+
| PK customer_id       |
|    first_name        |
|    last_name         |
|    email             |
|    phone             |
+----------------------+

When multiple entities are connected, the diagram shows relationships and cardinality. For example, Customer to Order is usually one-to-many. The ERD helps teams review whether entities, attributes, keys, and relationships match the business rules before implementation becomes expensive.

+-------------------+       1:N       +-------------------+
| CUSTOMER          |-----------------| ORDER             |
+-------------------+                 +-------------------+
| PK customer_id    |                 | PK order_id       |
|    name           |                 | FK customer_id    |
|    email          |                 |    order_date     |
+-------------------+                 +-------------------+

E-Commerce Entity Analysis

Consider the requirement: customers purchase products by placing orders, orders contain one or more products, and payments are recorded for orders. A strong entity analysis identifies Customer, Product, Order, Order Item, and Payment. Each has its own purpose and attributes.

Customer attributes may include customer_id, first_name, last_name, email, phone, and created_at. Product attributes may include product_id, sku, product_name, description, price, and stock_quantity. Order attributes may include order_id, customer_id, order_date, status, and total_amount. Order Item attributes may include order_id, product_id, quantity, and unit_price. Payment attributes may include payment_id, order_id, amount, payment_date, payment_method, and status.

CUSTOMER(customer_id, first_name, last_name, email)
ORDER(order_id, customer_id, order_date, status)
ORDER_ITEM(order_id, product_id, quantity, unit_price)
PRODUCT(product_id, sku, product_name, price)
PAYMENT(payment_id, order_id, amount, payment_method, status)

This model separates facts cleanly. Customers are not duplicated on every order. Products are not duplicated inside every order row. Order Item captures the relationship between Order and Product. Payment has its own identity because payment can have status, amount, method, transaction reference, and lifecycle.

Converting Entities Into SQL

After identifying entities and attributes, the next step is converting the model into SQL tables and columns. This step adds implementation details such as data types, primary keys, foreign keys, nullability, and constraints.

CREATE TABLE customers (
    customer_id INT PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    email VARCHAR(150) UNIQUE
);

CREATE TABLE products (
    product_id INT PRIMARY KEY,
    product_name VARCHAR(150) NOT NULL,
    price DECIMAL(10,2) NOT NULL
);

CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_id INT NOT NULL,
    order_date DATE NOT NULL,
    FOREIGN KEY (customer_id)
        REFERENCES customers(customer_id)
);

CREATE TABLE order_items (
    order_id INT NOT NULL,
    product_id INT NOT NULL,
    quantity INT NOT NULL,
    PRIMARY KEY (order_id, product_id),
    FOREIGN KEY (order_id)
        REFERENCES orders(order_id),
    FOREIGN KEY (product_id)
        REFERENCES products(product_id)
);

The conceptual entities and attributes have now become physical tables and columns. This conversion is where design quality becomes visible. Poor entity analysis leads to confusing tables. Poor attribute analysis leads to weak columns. Strong modeling leads to SQL that is easier to query, test, maintain, and extend.

Common Entity Modeling Mistakes

One common mistake is creating an entity with no reliable identity. A CUSTOMER table with only name and city creates problems when two customers have the same name in the same city. Names are usually poor identifiers because they can be duplicated, corrected, changed, abbreviated, or spelled differently. Use a proper key based on business requirements.

Another mistake is wrong attribute ownership. A CUSTOMER table with last_order_date, last_order_amount, and last_product_name may look convenient, but those facts belong primarily to Order and Order Item. Storing them on Customer can create duplication and synchronization problems unless they are intentionally maintained as summary values.

Modeling directly from a screen is also risky. If a UI displays customer name, order number, product name, and payment status, do not automatically create one SCREEN_DATA table. Instead identify the real business entities: Customer, Order, Product, and Payment. The screen is a view of business data, not necessarily the structure of the database.

The opposite mistake is creating an entity for every attribute. You usually do not need separate FIRST_NAME, LAST_NAME, SALARY, or CITY tables for ordinary values. Too many entities can make the model unnecessarily complex. Good design balances clarity, normalization, performance, and business need.

Requirement-to-Entity Workflow

Suppose the requirement says: students enroll in courses, each course is taught by an instructor, and the system stores the student's name, email, enrollment date, and final grade. A careful model identifies Student, Course, Instructor, and Enrollment as entities. Student has student_id, name, and email. Course has course_id and course_name. Instructor has instructor_id and name. Enrollment has student_id, course_id, enrollment_date, and final_grade.

Enrollment is important because final_grade does not belong only to Student and does not belong only to Course. A student can have different grades in different courses, and a course can have different grades for different students. The grade describes the relationship between a student and a course, so the relationship becomes an associative entity.

STUDENT(student_id, name, email)
COURSE(course_id, course_name, instructor_id)
INSTRUCTOR(instructor_id, name)
ENROLLMENT(student_id, course_id, enrollment_date, final_grade)

This example shows how requirement analysis becomes database design. Good modeling asks where each fact truly belongs and what uniquely identifies each thing.

Review Questions for Entities and Attributes

For every possible entity, ask whether it has independent business meaning, multiple instances, its own identifier, several attributes, relationships with other entities, its own lifecycle, or a need for history. These questions prevent both under-modeling and over-modeling.

For every attribute, ask what property it describes, whether it belongs to the correct entity, whether it is required or optional, whether it can have multiple values, whether it changes over time, whether it is derived, whether it needs a domain constraint, and whether it should actually become a separate entity.

Real-World Business
        |
Identify Things
        |
ENTITIES
        |
Identify Their Properties
        |
ATTRIBUTES
        |
Identify Unique Values
        |
KEYS
        |
Identify Associations
        |
RELATIONSHIPS
        |
Apply Rules
        |
CONSTRAINTS
        |
Convert to SQL
        |
TABLES + COLUMNS

This review process catches many problems before code is written. It helps avoid repeated columns, missing identifiers, vague names, wrong ownership, uncontrolled NULLs, and tables that mix unrelated concepts.

Quick Comparison

Interview-Ready Explanation

A short interview answer is: an entity is a real-world thing or business concept about which data is stored, and an attribute is a property that describes that entity. In a relational database, an entity usually maps to a table, an entity instance maps to a row, an attribute maps to a column, and an attribute value maps to a cell value.

A stronger answer is: entities are identified from business requirements by looking for meaningful objects, events, transactions, or concepts that have identity, properties, relationships, or lifecycles. Attributes describe those entities and should have clear names, proper domains, correct data types, appropriate constraints, and correct ownership. Multi-valued or historically tracked attributes may become separate entities, and many-to-many relationships may become associative entities.

You can add a practical example: in an e-commerce system, Customer, Product, Order, Order Item, and Payment are entities. Customer has attributes such as customer_id, name, and email. Order has order_id, customer_id, order_date, and status. Order Item connects Order and Product and stores quantity and unit_price. This shows how entities and attributes become SQL tables and columns.

Key Takeaway

Entities represent the things the database needs to know about, while attributes describe those things. Customer is an entity. customer_id, name, email, and phone are attributes. One actual customer row is an entity instance. John, john@example.com, and 555-1111 are attribute values.

Data Modeling          Relational Database
-----------------------------------------
Entity             -> Table
Entity Instance    -> Row
Attribute          -> Column
Attribute Value    -> Cell Value
Identifier         -> Key
Association        -> Relationship

A strong database design begins by correctly answering two questions. What things does the business need to store? Those are candidate entities. What information must we know about each thing? Those are candidate attributes. Once entities and attributes are modeled correctly, relationships, primary keys, foreign keys, constraints, normalization, and table design become much easier to build correctly.