Entities and Attributes

When building a database, the very first challenge is deciding what the database should store information about. This is where the concept of an entity comes in. An entity is a distinct, identifiable object or concept in the real world that a business or system needs to track. Before a single table is created or a single column is named, a data modeler must think carefully about the things that matter in the problem domain and the descriptive facts — called attributes — that need to be recorded about each of those things. Getting this foundation right determines the quality of every design decision that follows.

An entity represents something that exists independently and can be distinguished from every other thing of the same kind. "Independently" is the key word: an entity has meaning on its own, not merely as a description of something else. In a university information system, a Student exists independently — each student has their own identity, their own records, and their own history in the system. Similarly, a Course exists independently: courses are offered, assigned instructors, and enrolled in by students. Both are good candidates for entities. By contrast, a student's date of birth is not independent — it only makes sense as a fact about a particular student, so it is an attribute, not an entity.

The practical test for entity-hood is whether the thing needs to be tracked on its own terms. If a hospital needs to store multiple facts about each physician — their name, specialty, license number, schedule — then Physician is an entity. If the hospital only needed to note a single physician's name on a patient record and nothing else, it might be just an attribute of the Patient entity. Context always shapes these decisions.

During implementation in a relational database, each entity becomes a table. The attributes of the entity become the columns of that table, and each uniquely identifiable instance of the entity becomes a row. Understanding this mapping helps students see why careful entity and attribute identification at the modeling stage prevents messy, redundant, or incomplete database structures later.

A useful first step when identifying entities is to read a problem description carefully and highlight every noun. Nouns are candidates for either entities or attributes. A noun that stands alone and requires its own collection of facts is almost certainly an entity. A noun that merely describes or quantifies another noun is likely an attribute. For example, in the sentence "The library lends books to members and tracks the loan date for each borrowing," the nouns are library, books, members, and loan date. Books and members are strong entity candidates; loan date is a candidate attribute (describing a borrowing event).

Entity Types vs. Entity Instances is a distinction that mirrors the concept of a class and its objects in programming. An entity type is the category or blueprint — it defines what kind of information will be captured for all members of that category. An entity instance is one specific, real occurrence of that type.

Consider the entity type Student. The type tells us that every student has a StudentID, a first name, a last name, an email address, and a date of enrollment. These are the defined attributes for the type. An entity instance might be the individual student Maria Gonzalez, whose StudentID is 10042, whose email is m.gonzalez@university.edu, and who enrolled on 2022-09-01. A second instance is James Park, StudentID 10043, and so on. A large university might have tens of thousands of Student instances, all conforming to the same entity type definition.

This distinction matters because data models describe types, while actual databases are populated with instances. The ER (Entity-Relationship) diagram a designer draws represents types; the rows eventually loaded into a table represent instances. Every instance must be uniquely identifiable — if two rows in the Student table were completely indistinguishable, the database would not know which student it was reading or updating. This is why each entity type must have a key attribute: a field whose value uniquely identifies each instance.

Attributes are the individual pieces of data that describe an entity. Each attribute captures one specific fact relevant to its entity. The choice of attributes should be driven by the real-world requirements of the problem: what does the organization actually need to know about each entity? Attributes should be chosen to capture all necessary facts without introducing redundancy. For example, storing both a student's date of birth and their age would be redundant — age can always be calculated from date of birth and the current date, so storing both creates a maintenance problem (age goes stale; date of birth does not).

Attributes are typically named with clear, descriptive labels: LastName, EnrollmentDate, AccountBalance. Good naming conventions make the model self-documenting and reduce misunderstandings among team members. The following table illustrates several entities and some of their common attributes in different problem domains:

Data modeling recognizes several types of attributes, each with different implications for how data is stored and queried. Understanding these types helps a designer make precise, efficient modeling decisions.

A simple (atomic) attribute cannot be meaningfully subdivided. StudentID, Email, Price, and LicenseNumber are all atomic: they are treated as single, indivisible values. Most attributes in a well-normalized database end up being simple attributes because decomposing data into its smallest meaningful parts makes querying and sorting far easier.

A composite attribute is made up of multiple component sub-parts that together form a logical whole. A classic example is Address, which can be broken down into Street, City, State, ZipCode, and Country. Another example is FullName, which might be composed of FirstName, MiddleName, and LastName. Whether to store a composite attribute as a single text field or decomposed into its parts depends on how the data will be used. If users will frequently search by city alone, or sort by last name alone, decomposing the composite attribute into its components makes those operations far more efficient. In a relational database, composite attributes are almost always decomposed into separate columns.

A derived attribute is one whose value can be computed from another attribute or set of attributes already stored in the database. Age is the prototypical example: if DateOfBirth is stored, age can always be calculated as the difference between today's date and the date of birth. Similarly, TotalOrderValue might be derived by summing the price of all items in an order. Derived attributes are usually not physically stored in the database (to avoid the stale-data problem), but they may appear in ER diagrams — represented with a dashed oval in the traditional notation — to communicate that the value is logically meaningful even if not directly persisted. In practice, derived values are often computed in SQL queries or application logic at retrieval time.

A multi-valued attribute can hold more than one value for a single entity instance. A person's phone numbers is a classic example — one contact might have a mobile number, a home number, and a work number. Similarly, an employee might hold multiple professional certifications. In an ER diagram, multi-valued attributes are shown with a double oval. In a relational database, multi-valued attributes are not stored directly as multiple values in one column (which would violate first normal form). Instead, they are handled by creating a separate related table. For example, a PhoneNumber table with a foreign key back to the Contact table can store as many phone numbers as needed for each contact.

The following table summarizes all four attribute types with their characteristics and database implications:

Key attributes deserve special attention because they are what make entity instances uniquely identifiable. Every entity type must have at least one key attribute. Without a key, there is no reliable way to distinguish one instance from another, update the correct record, or enforce referential integrity across related entities. In traditional ER diagram notation, a key attribute is shown with its name underlined.

A good key attribute has three essential properties: it must be unique (no two instances share the same key value), it must be non-null (every instance must have a value — a missing key is meaningless), and it should be stable (the value should not change over time, because key values are used to cross-reference records throughout the database). Consider using a person's name as a key: names are not unique (many people share the same name) and they can change (through marriage, for example), so a name is a poor key. A student ID number, assigned by the institution and never reused, is a far better key.

Sometimes the real world provides a natural, meaningful unique identifier — a government-issued ID number, an ISBN for a book, or an airline flight number. These are called natural keys. When no natural key exists, designers introduce a surrogate key: an artificial identifier, typically an auto-incremented integer or a generated UUID, that has no real-world meaning but is guaranteed to be unique. Surrogate keys are extremely common in relational databases because they are immune to changes in the real world and are efficient to index.

To illustrate, consider the Product entity in an e-commerce system. The product's name could change (a rebranding), its price certainly changes, and even a barcode can be reassigned in some industries. A surrogate ProductID generated by the database at insertion time is stable, unique, and never meaningful in itself — making it the ideal primary key. The product's UPC barcode might be stored as a separate, regular attribute.

The process of identifying entities and attributes from real-world scenarios is as much an analytical skill as a technical one. It involves reading and listening carefully, asking the right questions, and iteratively refining a model. Here is a worked example to illustrate the process.

Suppose a small car rental company describes its needs as follows: "We rent cars to customers. Each car has a make, model, year, license plate number, and daily rental rate. Each customer has a name, driver's license number, email address, and phone number. When a customer rents a car, we record the start date, the expected return date, and the actual return date."

Step one: highlight the nouns. The nouns are cars, customers, make, model, year, license plate number, daily rental rate, name, driver's license number, email address, phone number, start date, expected return date, and actual return date.

Step two: separate entities from attributes. Cars stand alone — the company tracks many cars, each with its own history. Customers stand alone — each customer may rent multiple times and has their own profile. The rental event itself (with its dates) is something the company tracks independently — this becomes a third entity, which we might call Rental. Everything else — make, model, year, license plate, daily rate, name, driver's license number, email, phone, start date, expected return date, actual return date — describes one of the three entities and therefore becomes an attribute.

Step three: assign attributes to entities and identify keys. The result might look like this:

Step four: refine and verify. Are there any missing attributes? The business description mentions a "daily rental rate" — is this truly an attribute of the Car, or does the rate vary per rental (perhaps with seasonal pricing or promotions)? This is exactly the kind of question that must be raised with stakeholders. If the rate can vary per rental, it becomes an attribute of Rental, not Car. Is PhoneNumber truly a single value, or do some customers have multiple phone numbers? If so, it may need to become a multi-valued attribute handled by a separate table. These refinements are made through iterative review.

Step five: confirm nothing is overlooked. Would the company ever need to track which employee processed a rental, or which branch office the car was rented from? If yes, Employee and Branch might need to become additional entities. The model evolves as the requirements become clearer. Iterative review — going back to stakeholders, revisiting the problem description, and cross-checking the model against business rules — is essential to building a model that faithfully represents reality.

In summary, the foundation of any well-designed database is a thoughtful identification of entities and their attributes. Entities are the independently meaningful things the system must track; attributes are the descriptive facts recorded about each entity. Every entity needs a reliable key to distinguish its instances. Attributes come in several varieties — simple, composite, derived, and multi-valued — each carrying different implications for how data is physically stored and queried. The process of discovering entities and attributes is iterative, noun-driven, and deeply collaborative with the people who understand the problem domain. Getting these foundations right makes every subsequent step in database design — relationships, normalization, and physical implementation — far more straightforward.