Section 3.1-3.6

Question 1 (3.1.4)
Which noun is an entity?

• information

• name

• professor

Correct answer: professor
Explanation: An entity represents a real-world object or concept with independent existence. “Professor” is a real-world object, while “information” and “name” are not entities.

Question 2 (3.1.4)
Which verb is a relationship?

• taken

• track

• have

Correct answer: taken
Explanation: A relationship describes how entities interact. “Taken” describes the relationship between Student and Course (a student takes a course).

Question 3 (3.1.4)
Which noun is an attribute?

• record

• Assistant Professor

• title

• course

Correct answer: title
Explanation: An attribute describes a property of an entity. “Title” is an attribute of Professor. “Assistant Professor” is a value of that attribute, not the attribute itself.

Question 1 (3.1.5)
“Students” is a good entity name.

• True

• False

Correct answer: False
Explanation: Entity names should be singular nouns. “Student” would be correct, not “Students”.

Question 2 (3.1.5)
“License” is a good attribute name.

• True

• False

Correct answer: False
Explanation: Attribute names must have a type suffix. The correct attribute name is "LicenseNumber", "LicenseCode", or similar. Optionally, the name can have an entity prefix, as in "EmployeeLicenseNumber".

Question 3 (3.1.5)
“Employee-Manages-Employee” is a good relationship name.

• True

• False

Correct answer: True
Explanation: Sometimes relationships relate an entity to itself. Since "Manages" is the active form of "manage", "Employee-Manages-Employee" is a good relationship name.

Question 4 (3.1.5)
“People” is a good entity name.

• True

• False

Correct answer: False
Explanation: Although "People" is grammatically either singular or plural, "People" suggests many individuals. Since entity names should be singular, "Person" is a better entity name.

Question 5 (3.1.5)
“PassengerMileagePlanCode” is a good attribute name.

• True

• False

Correct answer: True
Explanation: "Passenger" is the name of the attribute's entity. "Code" is an attribute type, usually defined as a mix of letters and numbers. "MileagePlan" is a two-word qualifier. Thus, "PassengerMileagePlanCode" has the form EntityQualifierType and is a good attribute name.

Question 6 (3.1.5)
“Department-IsManagedBy-Employee” is a good relationship name.

• True

• False

Correct answer: False
Explanation: "IsManagedBy" is the passive form of the verb "manage". Although relationship names are sometimes passive verbs, active verbs are more concise. "Employee-Manages-Department" uses an active verb and is a better relationship name.

Question 1 (3.1.7)
Must entity, relationship, and attribute synonyms follow naming conventions?

• Yes

• Only attribute synonyms must follow naming conventions

• No

Correct answer: No
Explanation: Synonyms exist to map commonly used terms to official names. They should reflect common usage, not formal naming conventions.

Question 2 (3.1.7)
What is wrong with the following entity description?

“The difference between a course and a class is that a course refers to the catalog description, while a class is an individual offering of a course in a specific term.”

• Description does not begin with entity name

• Description does not include counterexamples

• Description does not use complete sentences

Correct answer: Description does not begin with entity name
Explanation: Entity descriptions should begin with the name of the entity being described, such as “Course” or “Class,” not a generic noun like “difference.”

Question 3 (3.1.7)
What is wrong with the following relationship description?

“Student-Takes-Course describes all course instances taken by a student instance.”

• Description should begin with an entity name

• Description does not use complete sentences

• Description does not include examples and counterexamples

Correct answer: Description does not include examples and counterexamples
Explanation: Relationship descriptions must clarify meaning using examples and counterexamples to avoid ambiguity, such as whether failed or withdrawn courses are included.

Question 1 (3.1.8)
Discovery is a step in which phase?

• Conceptual design

• Logical design

• Database design

Correct answer: Conceptual design
Explanation: Discovery occurs during conceptual design, where requirements are gathered and entities, relationships, and attributes are identified before any schema is built.

Question 2 (3.1.8)
Identification of entities, relationships, and attributes precedes documentation.

• Always

• Usually

• Never

Correct answer: Usually
Explanation:
Usually, database designers identify entities, relationships, and attributes before documentation. However, the steps are iterative. Additional identification often takes place after names, synonyms, and descriptions are documented.

In most cases, entities, relationships, and attributes are identified before documentation is finalized, but some documentation may happen in parallel or be refined later.

Question 3 (3.1.8)
Standard attribute types are determined after the ER diagram is drawn.

• Always

• Usually

• Never

Correct answer: Usually
Explanation: Usually, database designers draw high-level ER diagrams before determining attribute types. However, steps are iterative, and different database designers might follow a different order of steps.

Attribute data types are typically decided after the ER diagram is completed, during logical design, though some may be considered earlier.

Question 1 (3.2.2)
A project is a(n) ______.

Correct answer: entity

ZyBooks Explanation:
An entity is a thing, such as a person, place, or activity. Since a project is a thing, project is an entity.

Second Explanation:
In ER modeling, anything that exists independently and can be talked about on its own is an entity. A project clearly exists as its own object in the system, so it must be modeled as an entity.

Question 2 (3.2.2)
The duration of a project is a(n) ______.

Correct answer: attribute

ZyBooks Explanation:
An attribute is a property of an entity. Since "duration of a project" describes project, duration is an attribute.

Second Explanation:
Duration does not exist on its own. It only makes sense in the context of a project, which is exactly what attributes are for: describing properties of entities.

Question 3 (3.2.2)
“Task belongs to project” is a(n) ______.

Correct answer: relationship

ZyBooks Explanation:
A relationship is a statement about two things. Since "task belongs to project" is a statement about tasks and projects, the statement is a relationship.

Second Explanation:
Relationships describe how two entities are connected. This statement explains how tasks and projects are linked, so it cannot be an entity or attribute.

Question 4 (3.2.2)
The starting date of a task is a(n) ______.

Correct answer: attribute

ZyBooks Explanation:
An attribute is a property of an entity. Since "starting date of a task" describes task, "starting date" is an attribute.

Second Explanation:
A starting date only makes sense when attached to a task. Because it describes a property of the task, it is modeled as an attribute.

Question 1 (3.2.4)
Referring to the animation above, how is the “schedules” relationship read?

• Flight-Schedules-Airline

• Airline-Schedules-Flight

• Flight-IsScheduledBy-Airline

Correct answer: Airline-Schedules-Flight

ZyBooks Explanation:
Relationships are read in the direction of the verb. "Schedules" starts at "airline" on the ER diagram, so "airline" is read first.

Second Explanation:
In ER diagrams, you always read relationships starting from where the verb originates. Since the verb “schedules” flows from Airline to Flight, the correct reading must begin with Airline, not Flight.

Question 2 (3.2.4)
An entity-relationship model is completely described by:

• An ER diagram

• A glossary

• Both an ER diagram and a glossary

Correct answer: Both an ER diagram and a glossary

ZyBooks Explanation:
The ER diagram provides an intuitive overview of the model, and the glossary provides full detail. Both ER diagram and glossary, together, describe an entity-relationship model.

Second Explanation:
The ER diagram shows structure visually, but it cannot capture all definitions, meanings, or edge cases. The glossary fills in those details, so you need both for a complete and unambiguous model.

Question 3 (3.2.4)
What is included in a glossary?

• Descriptions only

• Names and synonyms only

• Names, synonyms, and descriptions only

• Names, synonyms, descriptions, and ER diagrams

Correct answer: Names, synonyms, and descriptions only

ZyBooks Explanation:
A glossary includes names, synonyms, and descriptions of all entities, relationships, and attributes.

Second Explanation:
The glossary is purely textual. It documents terminology and meaning, not diagrams. ER diagrams are separate artifacts that work alongside the glossary, not inside it.

Question 1 (3.2.6)
Conceptual design considers implementation issues related to a specific database system.

• True

• False

Correct answer: False

ZyBooks Explanation:
Conceptual design documents database requirements, without regard to implementation details for any database system.

Second Explanation:
Conceptual design focuses only on what the database must represent, not how it will be implemented. Details like MySQL, data types, indexes, or performance tuning are intentionally ignored at this stage.

Question 2 (3.2.6)
An entity-relationship model is developed for all database design projects.

• True

• False

Correct answer: False

ZyBooks Explanation:
An entity-relationship model is developed in the conceptual design phase. Conceptual design is sometimes omitted for simple databases with just a few users and tables.

Second Explanation:
While ER models are best practice, very small or simple databases may skip formal conceptual design and go straight to tables. Larger or more complex systems almost always require an ER model.

Question 3 (3.2.6)
Entities, relationships, and attributes always map directly to tables, foreign keys, and columns, respectively.

• True

• False

Correct answer: False

ZyBooks Explanation:
In the logical design phase, entities, relationships, and attributes usually become tables, foreign keys, and columns. Sometimes, however, an entity splits into several tables, several entities merge into one table, and relationships and attributes become tables.

Second Explanation:
The mapping from ER models to tables is not one-to-one in all cases. Normalization, many-to-many relationships, and multivalued attributes can cause entities or relationships to become separate tables or be merged differently.

Question 1 (3.3.2)
Determine the maxima for the relationship Student-Takes-Course.

• one-one

• one-many

• many-one

• many-many

Correct answer: many-many

ZyBooks Explanation:
Each student can take many courses, and each course has many students, so Student-Takes-Course is many-many.

Second Explanation:
A single student can enroll in multiple courses, and each course can have many students enrolled. Since both sides can have many, the maximum cardinality is many-to-many.

Question 2 (3.3.2)
Determine the maxima for the relationship City-IsCapitalOf-State.

• one-one

• one-many

• many-one

• many-many

Correct answer: one-one

ZyBooks Explanation:
A city is capital of at most one state, and each state has one capital city. City-IsCapitalOf-State is one-one.

Second Explanation:
A city cannot be the capital of multiple states, and each state designates exactly one capital. This limits both sides to one, making the relationship one-to-one.

Question 3 (3.3.2)
Determine the maxima for the relationship Airport-Has-Runway.

• one-one

• one-many

• many-one

• many-many

Correct answer: one-many

ZyBooks Explanation:
A runway is located in only one airport. So Airport is singular. An airport can have many runways. So Runway is plural.

Second Explanation:
Each runway belongs to exactly one airport, but airports usually have multiple runways. That means one airport maps to many runways, giving a one-to-many relationship.

Question 4 (3.3.2)
Determine the maxima for the relationship Person-Owns-Vehicle.

• one-one

• one-many

• many-one

• many-many

Correct answer: many-many

ZyBooks Explanation:
A person can own many vehicles and, in most states, a vehicle can have many registered owners. Person-Owns-Vehicle is many-many.

Second Explanation:
People can own multiple cars, and cars can be jointly owned by multiple people. Because both sides can have many, the maximum cardinality is many-to-many.

Question 1 (3.3.4)
Determine the minima for the relationship Person-Marries-Person.

• zero-zero

• zero-one

• one-zero

• one-one

Correct answer: zero-zero

ZyBooks Explanation:
Since a person can be unmarried, Person-Marries-Person is zero-zero.

Second Explanation:
Neither side is required to participate in the relationship. A person may be married or not married, so the minimum participation for both people is zero.

Question 2 (3.3.4)
Determine the minima for the relationship Person-Has-Passport.

• zero-zero

• zero-one

• one-zero

• one-one

Correct answer: one-zero

ZyBooks Explanation:
Every passport must belong to a person, so Person is required. A person may have no passport, so Passport is optional. Since Person-Has-Passport is required-optional, the minima are one-zero.

Second Explanation:
A passport cannot exist without a person, so the minimum on the Person side is one. However, a person does not need to have a passport, so the Passport side minimum is zero.

Question 3 (3.3.4)
Determine the minima for the relationship Flight-ArrivesAt-Airport.

• zero-zero

• zero-one

• one-zero

• one-one

Correct answer: one-one

ZyBooks Explanation:
All flights must arrive at an airport. Assuming the database does not track new or inactive airports, all airports have arriving flights. Flight-ArrivesAt-Airport is one-one.

Second Explanation:
Every flight must arrive somewhere, and the problem assumes every airport in the database has at least one arriving flight. Since neither side can exist without the relationship, both minimums are one.

Question 1 (3.3.6)
Entity Airport, attribute AirportCode

• singular-required

• singular-optional

• plural-required

Correct answer: singular-required

ZyBooks Explanation:
Several different code systems describe airports, however the three-letter IATA code is commonly used. Assuming the database uses only the IATA system, each airport has at most one code, so AirportCode is singular. Every airport has a code, so AirportCode is required.

Second Explanation:
Each airport can only have one IATA code, and an airport would not exist in the database without one. That makes the attribute both singular (max one value) and required (must exist).

Question 2 (3.3.6)
Entity Person, attribute SpouseName

• singular-required

• plural-required

• singular-optional

Correct answer: singular-optional

ZyBooks Explanation:
In most countries, each person has at most one legal spouse, so SpouseName is singular. A person may be unmarried, so SpouseName is optional.

Second Explanation:
A person can only have one spouse name stored, but not everyone is married. Because the attribute may be missing, it is optional, not required.

Question 3 (3.3.6)
Entity Employee, attribute LanguageCode

• singular-required

• plural-optional

• plural-required

Correct answer: plural-required

ZyBooks Explanation:
An employee may speak several languages, so LanguageCode is plural. Each employee speaks at least one language, so LanguageCode is required.

Second Explanation:
Employees can speak multiple languages, which makes the attribute plural. Since everyone speaks at least one language, the attribute must exist, making it required.

Question 1 (3.3.9)
“Cardinality” refers to relationships only.

• True

• False

Correct answer: False

ZyBooks Explanation:
Cardinality is a general term for minima and maxima of both relationships and attributes.

Second Explanation:
Cardinality is not limited to relationships. Attributes also have minimum and maximum values, such as whether an attribute is required or optional, or singular or plural.

Question 2 (3.3.9)
ER diagrams indicate maxima and minima for relationships only.

• True

• False

Correct answer: False

ZyBooks Explanation:
Minima and maxima for both attributes and relationships appear in ER diagrams. Relationship maxima and minima are indicated with crow’s foot notation. Attribute maxima and minima are indicated with the letters R, P, and U.

Second Explanation:
ER diagrams show cardinality for both relationships and attributes. Relationships use crow’s foot symbols, while attributes use labels to show whether they are required, optional, or unique.

Question 3 (3.3.9)
Maxima and minima usually depend on business rules.

• True

• False

Correct answer: True

ZyBooks Explanation:
Although some maxima and minima are universal, most depend on business rules and are determined during interviews and document review.

Second Explanation:
Business rules define how the real-world system works. Because different organizations operate differently, cardinality constraints often change based on policies, laws, or operational decisions.

Question 4 (3.3.9)
In the conceptual design phase, cardinality is always determined after discovery is complete.

• True

• False

Correct answer: False

ZyBooks Explanation:
In principle, discovery precedes determination of cardinality. However, conceptual design is an iterative process. In practice, cardinality is determined in parallel with discovery, and additional discovery takes place after cardinality is determined.

Second Explanation:
Conceptual design is not linear. Designers often go back and forth between discovery and defining cardinality as new information emerges.

Question 1 (3.4.2)
Each project has at most one code. The ProjectCode attribute is _____.

• unique

• singular

• plural

• required

• optional

Correct answer: singular

ZyBooks Explanation:
'Singular' means each entity instance has at most one attribute value. This is the case for ProjectCode, so ProjectCode is singular.

Second Explanation:
“Singular” focuses only on how many values an attribute can have per entity. Since a project can have only one ProjectCode at most, it is singular, regardless of whether the code exists or is unique.

Question 2 (3.4.2)
Each project code describes at most one project. The ProjectCode attribute is _____.

• unique

• singular

• plural

• required

• optional

Correct answer: unique

ZyBooks Explanation:
'Unique' means each attribute value describes at most one entity instance. This is the case for ProjectCode, so ProjectCode is unique.

Second Explanation:
“Unique” looks at the attribute from the opposite direction. If no two projects can share the same ProjectCode, then each value uniquely identifies at most one project.

Question 3 (3.4.2)
A project may have no code. The ProjectCode attribute is _____.

• unique

• singular

• plural

• required

• optional

Correct answer: optional

ZyBooks Explanation:
'Optional' means an entity instance may have no attribute value. This is the case for ProjectCode, so ProjectCode is optional.

Second Explanation:
If a project can exist without a ProjectCode, then the attribute is not required. That makes it optional, even if it is singular and unique when present.

Question 4 (3.4.2)
ProjectCode is an identifying attribute of the Project entity.

• True

• False

Correct answer: False

ZyBooks Explanation:
An identifying attribute is unique, singular, and required. ProjectCode is optional, not required, and therefore not an identifying attribute of Project.

Second Explanation:
Identifying attributes must always exist. Even though ProjectCode is unique and singular, the fact that it is optional disqualifies it from being an identifying attribute.

Question 1 (3.4.6)
How often is an identifying entity also a weak entity?
• Never
• Sometimes
• Always

Correct answer: Sometimes

ZyBooks Explanation:
An identifying entity may be either weak or strong. Ex: In the animation above, the strong entity Project identifies Task. The weak entity Task identifies SubTask.

Second Explanation:
An identifying entity is just something that helps uniquely identify another entity. That identifier does not have to be weak itself. A strong entity can identify a weak one, and a weak entity can also identify another weak entity. So it depends on the situation, not a fixed rule.

Question 2 (3.4.6)
How many relationships can identify one weak entity?
• Zero or one
• Exactly one
• One or many

Correct answer: One or many

ZyBooks Explanation:
A weak entity must have at least one identifying relationship. Some weak entities are identified by several identifying entities. Ex: Booking is identified by both Flight and Passenger.

Second Explanation:
A weak entity cannot exist without being identified, but that identification can come from more than one relationship. Some weak entities need multiple parents to be uniquely identified, which is common in real-world systems like bookings or line items.

Question 3 (3.4.6)
How many weak entities can one entity identify?
• Zero or one
• One or many
• Zero, one, or many

Correct answer: Zero, one, or many

ZyBooks Explanation:
An entity can identify any number of entities, including none.

Second Explanation:
There is no upper or lower bound on how many weak entities a single entity can identify. An entity might identify none, exactly one, or many weak entities depending entirely on business rules.

Question 1 (3.4.7)
Distinguishing strong and weak entities is a logical design activity.
• True
• False

Correct answer: False

ZyBooks Explanation:
The distinction between strong and weak entities does not depend on a specific database system. Activities that document database requirements without regard to a specific database system are part of the conceptual design phase.

Second Explanation:
Strong vs. weak entities are identified while figuring out what the data means, not how it will be implemented. That makes this a conceptual design concern, not a logical design one.

Question 2 (3.4.7)
Determining cardinality always precedes distinguishing strong and weak entities.
• True
• False

Correct answer: False

ZyBooks Explanation:
Conceptual design activities are not always done in sequence. Conceptual design is iterative and, occasionally, steps are done out of order.

Second Explanation:
In real database design, you often go back and forth. You might think about cardinality first, or notice a weak entity first. There is no strict required order.

Question 3 (3.4.7)
Database designers may look for identifying relationships first, before noting weak entities.
• True
• False

Correct answer: True

ZyBooks Explanation:
Some database designers prefer to focus on identifying relationships rather than weak entities.

Second Explanation:
Designers sometimes spot relationships that uniquely identify data before explicitly labeling something as a weak entity. The weak entity becomes obvious after the identifying relationship is found.

Question 1 (3.5.2)
What is passenger?
• Supertype entity
• Subtype entity
• Weak entity

Correct answer: Supertype entity

ZyBooks Explanation:
All mileage plan members are passengers, so Passenger is a supertype entity.

Second Explanation:
Passenger is the general category that includes all types of travelers. Gold, silver, and bronze members are all specific kinds of passengers, so Passenger must be the supertype.

Question 2 (3.5.2)
What is gold plan member?
• Supertype entity
• Subtype entity
• Attribute

Correct answer: Subtype entity

ZyBooks Explanation:
The set of gold plan members is a subset of passengers, so GoldPlanMember is a subtype of Passenger.

Second Explanation:
Gold plan members are a special group within passengers, not a separate main entity. That makes GoldPlanMember a subtype.

Question 3 (3.5.2)
What is mileage plan number?
• Subtype entity
• Attribute of Passenger
• Attribute of GoldPlanMember

Correct answer: Attribute of Passenger

ZyBooks Explanation:
MileagePlanNumber is data, so MileagePlanNumber is an attribute. MileagePlanNumber applies to all gold, silver, and bronze members, and is an attribute of the supertype Passenger.

Second Explanation:
Because all mileage members have a plan number regardless of tier, the attribute belongs to Passenger, not a specific subtype.

Question 4 (3.5.2)
What is the name of the family member designated by gold status passengers?
• Subtype entity
• Attribute of Passenger
• Attribute of GoldPlanMember

Correct answer: Attribute of GoldPlanMember

ZyBooks Explanation:
"Designated family member" applies to gold plan members only.

Second Explanation:
Only gold members get this benefit, so the attribute belongs specifically to the GoldPlanMember subtype.

Question 1 (3.5.5)
Which entity does GradePointAverage belong to?
• Person
• Student
• Faculty
• Administrator

Correct answer: Student

ZyBooks Explanation:
GradePointAverage describes students only, not faculty or administrators, and belongs to the Student subtype entity.

Second Explanation:
GPA is only relevant for students, so it should not be stored on the Person supertype.

Question 2 (3.5.5)
Which entity does TelephoneNumber belong to?
• Person
• Student
• Faculty
• Administrator

Correct answer: Person

ZyBooks Explanation:
TelephoneNumber describes all people and should be assigned to the supertype Person.

Second Explanation:
Since everyone has a phone number, it belongs in the supertype so it’s not duplicated across subtypes.

Question 3 (3.5.5)
Which entity does EmploymentStatus belong to?
• Person
• Student
• Faculty
• Administrator

Correct answer: Administrator

ZyBooks Explanation:
Employment status describes administrators only and belongs to the Administrator subtype.

Second Explanation:
Only administrators are hourly or salaried, so the attribute should live in that subtype.

Question 1 (3.5.7)
An entity instance can be in two subtypes of the same partition.
• True
• False

Correct answer: False

ZyBooks Explanation:
Subtypes of a partition are mutually exclusive. Ex: A card cannot be both Visa and Mastercard, or Visa and Discover, at the same time.

Second Explanation:
Partitions split entities into non-overlapping groups. You must belong to exactly one subtype in that partition.

Question 2 (3.5.7)
An entity instance can be in two subtypes of different partitions.
• True
• False

Correct answer: True

ZyBooks Explanation:
Subtypes of different partitions can overlap. Ex: A card can be both a credit card and Visa simultaneously.

Second Explanation:
Different partitions classify entities in different ways, so overlap is allowed.

Question 3 (3.5.7)
Each partition attribute value corresponds to one subtype.
• True
• False

Correct answer: True

ZyBooks Explanation:
Values of a partition attribute indicate which partition subtype contains each entity instance. Ex: CreditType value "Debit" indicates the card is a DebitCard.

Second Explanation:
The partition attribute acts like a label that tells you exactly which subtype applies.

Question 4 (3.5.7)
One partition attribute can correspond to several partitions.
• True
• False

Correct answer: False

ZyBooks Explanation:
Each partition corresponds to one partition attribute. Ex: CreditCard cannot also correspond to SponsorCode.

Second Explanation:
Each partition has its own defining attribute. You don’t reuse one attribute across multiple partitions.

Question 1 (3.5.9)
Subtype entities must have an identifying attribute.
• True
• False

Correct answer: False

ZyBooks Explanation:
All subtype entities have an identifying IsA relationship to the supertype entity. An identifying relationship takes the place of an identifying attribute. So subtype entities do not need an identifying attribute. Ex: The VehicleIdentificationNumber attribute, which identifies Vehicle, does not appear in ElectricVehicle.

Second Explanation:
Subtypes inherit identification from the supertype, so they don’t need their own primary key.

Question 2 (3.5.9)
The identifying attribute of a supertype entity also identifies the subtype entities.
• True
• False

Correct answer: True

ZyBooks Explanation:
Subtypes "inherit" the identifying attribute of the supertype. Ex: If VehicleIdentificationNumber identifies vehicles, then VehicleIdentificationNumber also identifies electric vehicles and gas vehicles.

Second Explanation:
The subtype shares the same identity as the supertype instance.

Question 3 (3.5.9)
All subtype entities are weak entities.
• True
• False

Correct answer: True

ZyBooks Explanation:
Any entity that has an identifying relationship instead of an identifying attribute is weak. Subtypes have an identifying IsA relationship to the supertype, and therefore are also weak entities.

Second Explanation:
Because subtypes rely on the supertype for identification, they meet the definition of weak entities.

Question 4 (3.5.9)
All weak entities are subtype entities.
• True
• False

Correct answer: False

ZyBooks Explanation:
Both weak and subtype entities have an identifying relationship to another entity. However, a subtype entity is a subset of a supertype entity, but a weak entity is not necessarily a subset of a strong entity. So a weak entity is not necessarily a subtype entity.

Second Explanation:
Weak entities depend on another entity for identification, but they are not always part of an IsA hierarchy.

Question 1 (3.6.4)
In some models, weak entities are called _____ entities.

Correct answer: dependent

ZyBooks Explanation:
"Independent" and "dependent" are alternative terms for "strong" and "weak".

Second Explanation:
Some ER modeling approaches use different terminology. A weak entity depends on another entity for identification, so it can also be called a dependent entity.

Question 2 (3.6.4)
A group of related entities is often called a/an _____.

Correct answer: subject area

ZyBooks Explanation:
A subject area is a group of related entities. Large, complex ER models are often decomposed into subject areas.

Second Explanation:
When an ER diagram becomes large, it is broken into smaller sections to make it easier to understand. Each section is called a subject area.

Question 3 (3.6.4)
_____ is a modeling standard intended for software development.

Correct answer: UML or Unified Modeling Language

ZyBooks Explanation:
Unified Modeling Language, or UML, is commonly used for depicting software requirements. Since software data structures are similar to database structures, UML can be used for ER models and diagrams.

Second Explanation:
UML is mainly used in software design, but because software and databases both model structured data, UML diagrams can also represent ER models.