Question 1

Entity–Relationship (E–R) modeling: which of the following is NOT a basic element present in all versions of the E–R model?

Accepted Answer

Introduction / Context: The Entity–Relationship (E–R) model captures the conceptual structure of data. It focuses on what data means, not on implementation details. Knowing its core elements is foundational for translating requirements into a robust schema. Given Data / Assumptions: E–R diagrams consistently include entities, attributes, and relationships. Primary keys are a relational implementation device used when mapping to tables. The question asks which item is not a universal E–R element across variants of the model. Concept / Approach: Entities represent things of interest, attributes describe those things, and relationships show associations. Primary keys are part of relational schema design (logical/physical), though many notations show identifiers; the concept of a “primary key” specifically is relational rather than intrinsic to all E–R notations. Step-by-Step Solution: List basic E–R elements: entities, attributes, relationships are present in all versions.Recognize that “primary key” is a relational table construct for uniqueness enforcement.Therefore, select “Primary keys” as not a core E–R element. Verification / Alternative check: Review Chen E–R and extended EER variations: identifiers may be shown, but the relational term “primary key” arises during mapping to relations. Why Other Options Are Wrong: Entities: fundamental conceptual objects. Attributes: properties of entities and relationships. Relationships: associations between entities. Common Pitfalls: Equating identifiers shown in E–R with relational primary keys; the former are conceptual identifiers and may map to different key choices during implementation. Final Answer: Primary keys

Question 2

In data modeling, which type of entity represents a logical template or generalization whose real-world occurrences are represented by a second, associated entity?

Accepted Answer

Introduction / Context: Designs sometimes distinguish between a blueprint and its concrete occurrences. This pattern clarifies how templates (archetypes) relate to their realized instances in databases. Given Data / Assumptions: An entity serves as a logical generalization or template. Another entity records actual occurrences tied back to the template. We need the name of the template entity. Concept / Approach: The archetype/instance pattern models two related entities: an Archetype (template) that defines default or canonical characteristics, and an Instance that represents a real occurrence. This differs from supertype/subtype, which models specialization within a single generalization hierarchy. Step-by-Step Solution: Identify that the description speaks of a template with occurrences.Map “template” to “archetype” and “occurrence” to “instance.”Select “Archetype entity” as the correct term. Verification / Alternative check: Examples: ProductTemplate (archetype) and ProductItem (instance); ContractType (archetype) and Contract (instance). Why Other Options Are Wrong: Supertype and subtype describe inheritance hierarchies within one concept, not template-to-occurrence pairing. Instance entity describes the occurrence itself, not the template. Common Pitfalls: Confusing supertype/subtype with archetype/instance. The first is about specialization; the second is about template versus occurrence. Final Answer: Archetype entity

Question 3

Cardinality question: a single entity instance of one type is related to many entity instances of another type. What cardinality is this?

Accepted Answer

Introduction / Context: Understanding relationship cardinalities is essential for correct schema design, foreign key placement, and query formulation. Given Data / Assumptions: Exactly one instance on the first side relates to several instances on the second side. There is no implication of multiple instances back to the first side. Concept / Approach: A “one-to-many” relationship connects one parent to many children. Typical mappings place the foreign key on the many side (child table) pointing to the one side (parent table). Step-by-Step Solution: Interpret the phrase “single entity instance … related to many.”Match the description to the standard cardinality term: one-to-many.Select the option that states “One-to-Many Relationship.” Verification / Alternative check: Common examples: one Customer has many Orders; one Department has many Employees. Why Other Options Are Wrong: One-to-one: at most one on each side. Many-to-many: many on both sides. Composite relationship: not a standard cardinality term here. Common Pitfalls: Misplacing foreign keys by putting them on the one side. In relational design, the many side holds the foreign key to the one side. Final Answer: One-to-Many Relationship

Question 4

In a one-to-many relationship, what is the standard name for the entity on the “one” side?

Accepted Answer

Introduction / Context: Naming conventions like parent and child help communicate directionality and key placement in one-to-many relationships. Given Data / Assumptions: The relationship has one instance on one side and many on the other. The side with one instance conceptually owns or governs the many side entries. Concept / Approach: The entity on the “one” side is commonly called the parent; the entity on the “many” side is the child. In tables, the child holds the foreign key referencing the parent’s key. Step-by-Step Solution: Recognize standard terminology used in relational and ORM contexts.Map “one” side to “parent.”Select “parent.” Verification / Alternative check: Customer (parent) to Order (child); Department (parent) to Employee (child). Why Other Options Are Wrong: Child denotes the many side. Instance and subtype are unrelated to this directional naming. Common Pitfalls: Assuming the parent must physically contain the child rows; in relational systems, containment is logical via keys, not physical nesting. Final Answer: parent

Question 5

In an E–R model, what is the term for properties that describe the characteristics of entities?

Accepted Answer

Introduction / Context: E–R modeling assigns properties to entities to capture business facts. Knowing the correct term for these descriptive properties is necessary for clear communication and accurate designs. Given Data / Assumptions: Entities are things of interest (for example, Customer, Product). We need the term for descriptive properties of those entities (for example, CustomerName, BirthDate). Concept / Approach: Attributes are the named properties that hold values for each entity instance. Some attributes, singly or in combination, may be used as identifiers (keys), but the general term for properties is attributes. Step-by-Step Solution: Match “properties that describe entities” to “attributes.”Differentiate from identifiers (special attributes used to uniquely distinguish entities).Select “attributes.” Verification / Alternative check: Any E–R diagram shows entities with lists of attributes inside or near the entity box. Why Other Options Are Wrong: Entities are the things themselves, not their properties. Identifiers are specific attributes chosen for uniqueness. Relationships describe associations, not properties. Common Pitfalls: Using attributes and identifiers interchangeably. All identifiers are attributes, but not all attributes are identifiers. Final Answer: attributes

Question 6

Cardinality question: in which relationship type can many instances of one entity be related to many instances of another entity?

Accepted Answer

Introduction / Context: Many-to-many (M:N) relationships are common in domains such as course enrollments or product orders. Recognizing them is key because their relational implementation requires an associative (junction) table. Given Data / Assumptions: Each entity on the first side can be associated with many on the second side. Each entity on the second side can also be associated with many on the first side. Concept / Approach: An M:N relationship connects multiple instances on both sides. In relational databases, you implement it by introducing a third table whose foreign keys point to each parent; together they can form the primary key or a unique constraint. Step-by-Step Solution: Identify that “many on both sides” matches the definition of many-to-many.Recall implementation: create an associative table to avoid repeating groups and anomalies.Choose “Many-to-Many Relationship.” Verification / Alternative check: Examples: Students and Courses; Tags and Articles; Doctors and Patients (in some contexts). Why Other Options Are Wrong: One-to-one and one-to-many do not allow many associations on both sides. Composite relationship is not the standard cardinality label here. Common Pitfalls: Attempting to represent M:N with foreign keys in just two tables; this design leads to duplication or nulls. Use a junction table instead. Final Answer: Many-to-Many Relationship

Question 7

In E–R terminology, entities of a given type are grouped into what?

Accepted Answer

Introduction / Context: E–R modeling distinguishes between individual occurrences and the set that contains all occurrences of a type. Using the correct term helps during analysis and documentation. Given Data / Assumptions: We are asked for the collective grouping of same-type entities. We are operating at the conceptual modeling level. Concept / Approach: An entity class (also called an entity set) is the collection of all entity instances of a given type. It is not the database (the whole system), not an attribute (a property), and not the diagram itself (ERD). Step-by-Step Solution: Identify terms: instance vs. class (set).Match the collection of entities of the same type to “entity class.”Select “entity class.” Verification / Alternative check: Textbooks often use “entity set” interchangeably with “entity class,” both referring to the grouping of instances. Why Other Options Are Wrong: Database is the entire data store. Attribute is a property, not a grouping. ERD is a diagram artifact, not a collection of instances. Common Pitfalls: Confusing entity class with table implementation; while often mapped one-to-one, the conceptual term is independent of physical storage. Final Answer: entity class

Question 8

Which entity type represents an actual occurrence of an associated generalized entity in an archetype/instance pattern?

Accepted Answer

Introduction / Context: Some designs explicitly model templates and their real occurrences. Distinguishing the instance from the template clarifies how data is populated and referenced. Given Data / Assumptions: The question explicitly mentions an associated generalized entity (the template). We must name the entity that represents the actual occurrence. Concept / Approach: In the archetype/instance pattern, the archetype holds the generalized definition, while the instance represents the specific, real-world occurrence based on that definition. Step-by-Step Solution: Identify “occurrence of a generalized entity” as the instance.Map to terminology: archetype = template, instance = occurrence.Select “Instance entity.” Verification / Alternative check: Examples: ContractType (archetype) vs. Contract (instance); ItemModel (archetype) vs. ItemSerial (instance). Why Other Options Are Wrong: Supertype/subtype refer to inheritance specialization, not template-to-occurrence. Archetype is the template, not the occurrence. Common Pitfalls: Interchanging subtype with instance. A subtype is still a template-level specialization, whereas an instance is a concrete occurrence. Final Answer: Instance entity

Question 9

Recursive relationship: a relationship that associates an entity with ________ is known as recursive.

Accepted Answer

Introduction / Context: Not all relationships connect different entity types. Sometimes an entity relates to other entities of the same type (for example, an employee managing other employees). This is called a recursive (or unary) relationship. Given Data / Assumptions: Single entity type participates on both sides of the relationship. Typical examples include managerial hierarchies or part–subpart structures. Concept / Approach: A recursive relationship is a relationship in which an entity is related to itself. The relation is modeled by linking one occurrence of the entity to another occurrence of the same entity type, usually with roles (for example, manager vs. subordinate). Step-by-Step Solution: Recognize that the same entity type appears twice in the relationship.Identify that this is the definition of a recursive (unary) relationship.Choose “itself.” Verification / Alternative check: Consider a self-referencing foreign key in a table (for example, employee.manager_id references employee.id). This implements a recursive relationship in relational schema. Why Other Options Are Wrong: Subtype, archetype, and instance are different modeling concepts not required by the definition of recursion. Common Pitfalls: Omitting role names in recursive relationships; always label roles to avoid ambiguity in diagrams and schema. Final Answer: itself

Question 10

In entity–relationship (ER) modeling, which type of entity sits above two or more related, more specialized entity types, where those specialized types have attributes that apply to some but not all instances of the broader entity?

Accepted Answer

Introduction / Context: In logical data modeling, designers often face situations where one real-world concept has common attributes plus additional attributes that only apply to certain variations. The ER solution is to use supertype–subtype structures, with a shared supertype and one or more specialized subtypes. Given Data / Assumptions: A broad entity has attributes common to all instances. Two or more associated specialized entities each carry attributes relevant only to a subset of instances. We want the term for the broader, generalized entity. Concept / Approach: A supertype captures common attributes and relationships; subtypes capture specialized attributes and possibly specialized relationships. A discriminator on the supertype can indicate which subtype an instance belongs to. This supports clarity, avoids NULLs for inapplicable attributes, and enables inheritance-like behavior in the schema. Step-by-Step Solution: Recognize the pattern: a generalized entity with multiple specialized variants.Name for the generalized entity in ER modeling → supertype.Name for specialized entities → subtypes with subtype-only attributes. Verification / Alternative check: Supertype–subtype hierarchies are standard in ERD notation (e.g., Chen or Crow’s Foot) for modeling generalization/specialization. Why Other Options Are Wrong: Subtype entity: Refers to the specialized, not the generalized, entity. Archetype entity: Not a standard ER term for this structure. Instance entity: Refers to an occurrence, not a type. Associative entity: Used to resolve many-to-many relationships, not specialization. Common Pitfalls: Putting subtype-only attributes on the supertype leads to sparse columns and integrity issues. Always push specialized attributes into subtypes. Final Answer: Supertype entity

Question 11

In ER modeling, which type of entity cannot exist unless another entity exists, yet does not need to include the other entity's identifier as part of its own identifier?

Accepted Answer

Introduction / Context: Some child entities require a parent for existence (mandatory relationship) but still have their own identifying key. Understanding the difference between ID-dependent and ID-independent situations determines how you choose primary keys and relationship types in the schema. Given Data / Assumptions: The child cannot exist unless the parent exists (existence-dependent). The child's identifier does not include the parent's identifier. We seek the term that describes this situation. Concept / Approach: An ID-dependent entity uses a primary key that includes its parent's key (identifying relationship). By contrast, an ID-independent entity has its own primary key while still being existence-dependent on the parent (non-identifying relationship with mandatory participation). The prompt explicitly says the child does not require the parent's identifier in its own key, so the child is ID-independent. Step-by-Step Solution: Check dependence: child requires parent → existence-dependent.Check identifier composition: parent's ID is not part of child's ID → not ID-dependent.Therefore, the correct term is ID-independent entity with a mandatory relationship. Verification / Alternative check: In Crow’s Foot modeling, this is modeled as a non-identifying relationship (dashed line) with required participation on the child side. Why Other Options Are Wrong: Weak entity: Typically implies identifying relationship using the parent’s key (ID-dependent). Strong entity: Has existence independent of any parent. ID-dependent entity: Contradicts the prompt because it must include the parent’s identifier. Associative entity: Resolves many-to-many relationships; not necessarily tied to this key behavior. Common Pitfalls: Assuming all existence-dependent entities must be ID-dependent. Existence dependence and identification are related but distinct design choices. Final Answer: ID- independent entity

Question 12

In entity–relationship modeling, what do we call an attribute that uniquely names or identifies instances of an entity?

Accepted Answer

Introduction / Context: Every entity type should have at least one attribute (or set of attributes) that uniquely distinguishes its instances. This unique naming/identifying concept underpins keys in relational tables derived from the ER model. Given Data / Assumptions: An entity has many instances (rows in a derived table). One attribute or combination must uniquely identify each instance. The ER term is being asked. Concept / Approach: The ER term for the unique naming attribute(s) is identifier. When mapped to the relational model, an identifier typically becomes a candidate key; the chosen one becomes the primary key. Identifiers can be natural (business meaning) or surrogate (system-generated). Step-by-Step Solution: Match the role (uniqueness) to the ER term → identifier.Map to relational schema → candidate key / primary key.Ensure uniqueness constraint is enforced in DDL. Verification / Alternative check: Standard ERD notations label identifying attributes with key symbols or unique markers. Why Other Options Are Wrong: Entity: The set/type being modeled, not the naming attribute. Attribute: General column; not necessarily unique. Relationship: Connects entities; does not name them. Foreign key: An attribute that references another entity's identifier; not the entity's own identifier. Common Pitfalls: Confusing identifiers with descriptions. A description may not be unique; an identifier must be. Final Answer: identifier.

Question 13

In an ERD, what term indicates the maximum number of entity instances that can participate in a given relationship?

Accepted Answer

Introduction / Context: Cardinality specifies how many instances of one entity may relate to instances of another entity. Understanding minimum and maximum cardinalities is essential to enforce business rules in database design. Given Data / Assumptions: The question asks about the upper bound in a relationship. ERD notation (Crow’s Foot, UML class diagrams) captures both minima and maxima. We want the explicit term for the upper bound. Concept / Approach: Maximum cardinality expresses the largest number of related instances allowed (e.g., 1, many, or a specific number like 5). Minimum cardinality expresses the least number required (0 or 1 in most designs). These together define participation constraints. Step-by-Step Solution: Identify relationship bounds: minimum (lower) and maximum (upper).The question asks for the upper bound → maximum cardinality.Examples: 1..1 (one-to-one), 0..* (optional many), 1..* (mandatory many). Verification / Alternative check: Modeling references consistently use “maximum cardinality” for the upper bound. Why Other Options Are Wrong: Minimum cardinality: Lower bound, not upper. ERD: The diagram itself, not the bound. GEC / Participation degree: Not standard terms for maximum bound in classical ER modeling. Common Pitfalls: Confusing optionality (minimum) with multiplicity (maximum) when translating to database constraints. Final Answer: Maximum cardinality

Question 14

In a supertype–subtype hierarchy, which type of entity has its association to the supertype governed by a discriminator attribute defined on the supertype?

Accepted Answer

Introduction / Context: Generalization/specialization modeling uses a discriminator on the supertype to decide which specialized path an instance follows. This is a cornerstone of clean modeling for heterogeneous categories. Given Data / Assumptions: A discriminator attribute exists on the supertype (e.g., CustomerType = 'Retail'/'Wholesale'). Instances are routed to the correct specialized entity based on the discriminator value. We seek the name of the specialized entity affected by the discriminator. Concept / Approach: The subtype is the specialized entity that inherits common attributes from the supertype and adds subtype-specific attributes. The discriminator value determines which subtype applies for a given supertype instance. Step-by-Step Solution: Identify the discriminator's role → select a specialized path.Specialized entities in such a hierarchy → subtypes.Therefore, the affected entity type is the subtype entity. Verification / Alternative check: ERD notations often annotate the supertype with a discriminator attribute and connect to subtypes via exclusive or overlapping constraints. Why Other Options Are Wrong: Supertype entity: Hosts the discriminator, not governed by it. Archetype / Instance / Associative entity: Not the standard terms for specialization levels in ER modeling. Common Pitfalls: Putting the discriminator on each subtype—by definition it belongs on the supertype to choose among subtypes. Final Answer: Subtype entity

Question 15

In ER modeling, entities are connected to each other using which construct?

Accepted Answer

Introduction / Context: Beyond defining entities and their attributes, a data model must express how entities are associated. This is where relationships enter the picture, defining cardinalities and participation rules. Given Data / Assumptions: We have multiple entities needing meaningful associations. We must express business rules like one-to-many or many-to-many. We are choosing the correct connector construct. Concept / Approach: A relationship captures how instances of one entity are associated with instances of another (or the same) entity. Relationships also carry cardinality and optionality information and may have attributes of their own in certain notations (especially for associative entities). Step-by-Step Solution: Identify need to connect entities.Apply ER construct → relationship (binary, ternary, or higher).Later, relationships map to foreign keys (and sometimes associative tables) in the relational schema. Verification / Alternative check: All major ERD notations use relationship symbols (lines, Crow’s Foot, etc.) to connect entities. Why Other Options Are Wrong: Entities / Attributes / Identifiers / Domains: These define data elements and types, not the connections between entities. Common Pitfalls: For many-to-many relationships, forgetting to implement an associative entity (junction table) leads to poor relational design. Final Answer: Relationships

Question 16

In ERD notation, what term specifies the minimum number of entity instances that must participate in a relationship?

Accepted Answer

Introduction / Context: Cardinality constraints include both an upper bound and a lower bound. The lower bound indicates whether participation is optional (0) or mandatory (1 or more). Correctly capturing this avoids orphaned or incomplete data. Given Data / Assumptions: We want the minimum number of related instances required. ER models reflect this as optionality or mandatory participation. Common notations: 0..1, 1..1, 0.., 1... Concept / Approach: Minimum cardinality is the lower bound of a relationship. A value of 0 means optional involvement; 1 means mandatory. This propagates to referential constraints and application validations in implementation. Step-by-Step Solution: Identify lower versus upper bound → minimum cardinality is lower bound.Map to optional/mandatory rules for business logic and database constraints.Ensure DDL and application enforce the intended minimum cardinalities. Verification / Alternative check: ER references consistently define lower bound as minimum cardinality. Why Other Options Are Wrong: Maximum cardinality: Upper bound, not lower. ERD / GEC / Participation degree: Not the specific term for the minimum bound in standard ER vocabulary. Common Pitfalls: Failing to align optionality in ERD with NOT NULL and foreign key constraints at implementation time. Final Answer: Minimum cardinality

Question 17

In data modeling, what do we call something in the user's environment that can be identified and that users want to track?

Accepted Answer

Introduction / Context: Before designing tables, we must decide what to model. ER modeling begins by identifying the key things—people, places, events, or concepts—that the business cares about and wants to store data for. Given Data / Assumptions: The focus is on a real-world thing of interest to users. It must be identifiable (instances distinguishable from each other). We need the correct modeling term for such a thing. Concept / Approach: An entity represents a class of things of interest. Each occurrence is an entity instance (tuple/row in the relational mapping). Entities have attributes (columns) and relationships to other entities. Defining entities correctly provides the foundation for a maintainable schema. Step-by-Step Solution: Identify the business concept → a thing users wish to track.Model it as an entity with attributes and keys.Relate entities via relationships to capture business rules. Verification / Alternative check: Any ER methodology starts by listing candidate entities from requirements, use cases, or user interviews. Why Other Options Are Wrong: Attribute: A property of an entity, not the thing itself. Identifier: A key for entities, not the entity. Relationship: Connects entities, not a thing in the domain. Domain: A set of allowable values for an attribute. Common Pitfalls: Over-specifying attributes before the entity set is clear; start with entities and relationships first. Final Answer: Entity

Question 18

In a one-to-many (1:N) relationship, what do we call the entity on the many side?

Accepted Answer

Introduction / Context: One-to-many relationships are ubiquitous: one customer has many orders, one department has many employees. Understanding the parent–child terminology clarifies referential integrity and foreign key placement. Given Data / Assumptions: The relationship is 1:N (one parent to many children). We need the role name for the N-side entity. Conventional ER terminology is assumed. Concept / Approach: In 1:N, the single-instance side is the parent, and the multiple-instances side is the child. In the relational schema, the child table typically contains the foreign key referencing the parent's primary key. Step-by-Step Solution: Identify the one side → parent.Identify the many side → child.Place foreign key on child referencing parent's key to enforce the relationship. Verification / Alternative check: Most modeling notations and RDBMS textbooks use this nomenclature for clarity when mapping relationships to tables. Why Other Options Are Wrong: Parent: Refers to the one side. Instance: A specific occurrence, not a role. Subtype: Part of supertype–subtype, unrelated to 1:N roles. Associative: Typically resolves M:N relationships. Common Pitfalls: Putting the foreign key on the parent instead of the child leads to incorrect optionality and duplication issues. Final Answer: child

Question 19

Which relationship type connects exactly one instance of an entity to exactly one instance of another entity?

Accepted Answer

Introduction / Context: Different cardinalities capture different business rules. One-to-one (1:1) relationships are less common than 1:N but appear for security partitions, optional extensions, or performance-related vertical splits. Given Data / Assumptions: Each instance on side A maps to at most one instance on side B. Each instance on side B maps to at most one instance on side A. We need the standard term for this cardinality. Concept / Approach: A One-to-One relationship specifies a maximum cardinality of 1 on both sides. Implementation often places a foreign key with a UNIQUE constraint (or both tables share the same primary key in an identifying 1:1). Step-by-Step Solution: Check upper bounds: both sides are 1 → 1:1.Decide optionality (minimum cardinality) based on business rules (0..1 vs 1..1).Implement via shared PK or unique foreign key to enforce 1:1. Verification / Alternative check: SQL DDL can enforce 1:1 using UNIQUE on the foreign key column or by sharing the same primary key between paired tables. Why Other Options Are Wrong: One-to-Many: One maps to many, not 1:1. Many-to-Many: Many on both sides; requires an associative table. Composite Relationship: Not a standard cardinality term. Recursive Relationship: Relates an entity to itself; can be 1:N or M:N, not necessarily 1:1. Common Pitfalls: Using 1:1 where a subtype would be clearer; if side B always exists when A exists and adds attributes, consider a subtype pattern. Final Answer: One-to-One Relationship

Question 20

In data modeling, which term refers to an entity whose identifier includes (and depends on) the identifier of another parent entity, such that the child's primary key contains the parent's key?

Accepted Answer

Introduction / Context: An essential idea in logical data modeling is how one entity's identity can depend on another. When the child's key literally embeds the parent's key, we call that an ID-dependent pattern. This question asks you to name that concept. Given Data / Assumptions: The child entity cannot be uniquely identified without the parent's identifier. The child's primary key includes the parent's key (for example, OrderLine has key (OrderID, LineNo)). We are reasoning at the logical design level, independent of a specific DBMS. Concept / Approach: An ID-dependent entity is one whose primary key contains the primary (or candidate) key of its parent entity. This is stronger than merely having a foreign key; here, the foreign key is part of the child's primary key, binding the child's identity to the parent. Step-by-Step Solution: Identify the key phrase: “identifier of one entity includes the identifier of another.”Match this to the formal term: ID-dependent entity.Confirm with a classic example: Order (OrderID) and OrderLine (OrderID, LineNo). Verification / Alternative check: Try removing the parent's key from the child's key. If the child would no longer be unique, the entity is ID-dependent. Why Other Options Are Wrong: Weak entity: often used broadly, but the precise term for “identifier includes parent's identifier” is ID-dependent entity. Strong entity: its identity is independent. ID-independent entity: explicitly the opposite of what is described. Common Pitfalls: Confusing “has a foreign key” with “is ID-dependent.” Many children have foreign keys; ID-dependence requires the parent's key to be part of the child's primary key. Final Answer: ID-dependent entity

Data Modeling with ER Model Questions