Difficulty: Intermediate | Prerequisites: Basic understanding of databases and data modelling concepts.
This topic sits at the very start of conceptual database design. Before you can build a relational schema or write SQL, you need to identify what things exist in your problem domain (entity types) and what properties describe them (attributes). The homework uses a "Pizza Delivery" case study to practise this analysis. If you are unsure what a database schema is or why we model data before building tables, review your introductory database notes first.
Entity types are the "things" in your problem domain that you need to store data about (customers, orders, products). Each entity type has attributes that describe it, and those attributes have characteristics like being composite, multi-valued, or derived. Identifying entity types and their attributes correctly is the first step in building an EER diagram, and getting it wrong cascades into every later stage of database design.
Entity type
A category of real-world objects or concepts that share the same set of attributes and about which data is collected. In simple terms, it is a "thing" your database needs to track, such as CUSTOMER, ORDER, or EMPLOYEE.
Weak entity type
An entity type that cannot be uniquely identified by its own attributes alone and depends on a related "owner" (strong) entity type for its identification. Think of it as something that only makes sense in the context of another thing, like a DEPENDENT that belongs to an EMPLOYEE.
Attribute
A property or characteristic that describes an entity type. In simple terms, it is one piece of information you record about a thing, such as a customer's name or an order's date.
Composite attribute
An attribute that can be broken down into smaller, meaningful sub-parts. Think of it as a group label: "Address" is composite because it splits into Street, City, Postcode, and so on.
Complex attribute
An attribute that is both composite and multi-valued at the same time. In simple terms, it is a group of sub-parts that can also have multiple instances, like a person having several addresses each made up of Street, City, and Postcode.
Multi-valued attribute
An attribute that can hold more than one value for a single entity instance. Think of it as a list: a person's PhoneNumbers attribute might store two or three different numbers.
Derived attribute
An attribute whose value is calculated or derived from other stored attributes rather than stored directly. In simple terms, it is a value you can work out, such as Age derived from DateOfBirth.
Required attribute
An attribute that must have a value for every entity instance; it cannot be left null. Think of it as a mandatory field on a form.
Key attribute
An attribute (or set of attributes) whose value uniquely identifies each instance of an entity type. In simple terms, it is the field that tells you exactly which record you are looking at, such as StudentID or OrderNumber.
Simple key
A key consisting of a single attribute. Think of it as one field that does the job on its own, like a Social Security Number.
Composite key
A key consisting of two or more attributes taken together. In simple terms, no single attribute is unique on its own, but the combination is, like (CourseCode, Semester, Year).
Domain (of an attribute)
The set of permitted values an attribute can take. Think of it as the rules for what can go in that field, such as "integers between 1 and 100" or "any valid email address."
Constraint
A rule or restriction on the values or structure of data in the model. In simple terms, constraints are the guardrails that stop invalid data from entering the database.
Read the problem description and look for nouns that represent distinct, independent "things" the system needs to track.
Strong entity types can be uniquely identified by their own attributes. They exist independently.
Example: CUSTOMER, PIZZA, STORE, ORDER.
Weak entity types cannot be uniquely identified by their own attributes. They depend on an owner entity.
A weak entity has a partial key, which only distinguishes instances within the scope of the owner.
Example: an ORDER_ITEM might depend on ORDER. The item number (1, 2, 3) only makes sense within a specific order.
When listing entity types, give each a short description that explains what category of real-world object it represents. This keeps your model grounded in the problem domain rather than becoming abstract.
For each entity type, you need to list every attribute and classify it. The homework asks you to flag only these characteristics:
Composite: can be split into sub-parts (e.g., Name into FirstName, MiddleName, LastName).
Complex: composite AND multi-valued at the same time (e.g., multiple Addresses, each with Street, City, Postcode).
Multi-valued: can hold more than one value per entity instance (e.g., PhoneNumbers).
Derived: calculated from other attributes, not stored directly (e.g., Age from DateOfBirth, TotalPrice from Quantity and UnitPrice).
Required: must have a value; cannot be null.
If an attribute does not have any of these special characteristics, it is a simple, single-valued, stored, optional attribute. You do not need to state that explicitly, but you should know the default.
Every strong entity type must have at least one key attribute (or composite key) that uniquely identifies each instance.
A simple key is a single attribute (e.g., CustomerID).
A composite key is two or more attributes taken together (e.g., (StoreID, EmployeeNumber)).
Weak entity types have a partial key: an attribute that distinguishes instances only within the scope of their owner entity.
The homework also asks for domain and constraint information where available:
Domain: what values the attribute can take. For example, PizzaSize might have a domain of {Small, Medium, Large}.
Constraints: any rules, such as a price being a positive decimal, a quantity being a positive integer, or a date being in YYYY-MM-DD format.
Specifying these early helps when you later translate the conceptual model into a logical schema with data types and CHECK constraints.
Students often confuse multi-valued attributes with composite attributes. A composite attribute has sub-parts (Name splits into First and Last). A multi-valued attribute has multiple values of the same type (several phone numbers). They are independent characteristics, and an attribute can be both (that is a complex attribute).
Students sometimes treat verbs or actions as entity types. "Delivering" is not an entity type; DELIVERY might be, if the system stores data about each delivery as a separate thing. Look for nouns with their own attributes.
A derived attribute is not the same as a computed column you plan to add later for performance. In the conceptual model, "derived" means the value is logically determined by other attributes in the model and would not need independent storage.
Students sometimes forget that a weak entity type still has a partial key. It is not that the weak entity has no distinguishing attribute at all. It is that the partial key only works in combination with the owner's key.
Listing entity types and attributes is typically the first step in any EER modelling question. If you get this wrong, your entire diagram will be off.
Expect to be asked to classify attributes by their characteristics (composite, multi-valued, derived, required). Know the definitions cold.
Identifying key attributes correctly is critical. Exams often ask you to distinguish simple keys from composite keys, and to explain why a particular attribute qualifies as a key.
Weak entity types are a favourite exam topic. Be ready to identify them, name the owner entity, and state the partial key.
True or False: A composite attribute is one that can hold multiple values for a single entity instance.
False. That describes a multi-valued attribute. A composite attribute is one that can be split into sub-parts.
True or False: A weak entity type has no key attribute at all.
False. It has a partial key, which uniquely identifies instances only within the context of its owner entity.
Fill in the blank: An attribute whose value is calculated from other attributes rather than stored directly is called a ______ attribute.
Derived.
True or False: Every strong entity type must have at least one key attribute.
True.
Fill in the blank: An attribute that is both composite and multi-valued is called a ______ attribute.
Complex.
Q: Given a case study, how do you decide whether something is an entity type or just an attribute of another entity type?
A: If the "thing" has its own set of attributes that need to be stored and is independently meaningful, it is likely an entity type. If it is just a single descriptive property of something else, it is an attribute. For example, "pizza size" is an attribute of PIZZA, but "customer" is its own entity type because it has Name, Address, Phone, and so on.
Q: What is the difference between a weak entity type and a strong entity type?
A: A strong entity type has a key attribute that uniquely identifies each instance on its own. A weak entity type cannot be uniquely identified by its own attributes alone; it relies on a relationship with an owner (strong) entity type, and its full key is the combination of its partial key plus the owner's key.
Q: Explain the difference between a composite attribute and a multi-valued attribute, and give an example of each.
A: A composite attribute is one that can be divided into smaller sub-parts (e.g., Address into Street, City, Postcode). A multi-valued attribute is one that can have more than one value for a single entity (e.g., a person may have multiple PhoneNumbers). They are independent concepts.
Q: A student says "Age is a stored attribute because we keep it in the database." What is wrong with this statement?
A: Age is typically modelled as a derived attribute because its value can be calculated from DateOfBirth and the current date. Even if the system stores it for performance reasons, the conceptual model classifies it as derived because it is logically determined by another attribute.
Q: In the homework table for question (2), what should you put in the "Other Specification" column?
A: Domain information (the set of allowed values, such as {Small, Medium, Large} for PizzaSize) and constraints (such as "positive integer" for Quantity, or "valid email format" for Email). This column captures rules about the attribute beyond its basic classification.
Entity type, weak entity, strong entity, attribute, composite attribute, complex attribute, multi-valued attribute, derived attribute, stored attribute, required attribute, optional attribute, key attribute, primary key, partial key, simple key, composite key, domain, constraint, EER model, enhanced entity-relationship, conceptual data model, ACS575, database systems, Purdue, entity-relationship diagram, ER diagram, data requirement analysis, pizza delivery case study.