Section 4
A Supertype can have only one
subtype. True or False?
True
False
(*)
A subtype can have a
relationship not shared by the supertype. True or False?
True
(*)
False
A subtype is shown on an ERD as
an entity with a one to many relationship to the supertype. True or False?
True
False
(*)
All ER diagrams must have one
of each of the following: (Choose two)
At
least one supertype and subtype
Arcs
Relationships
between entities (*)
One or
more Entities (*)
Which of the following is true
about subtypes?
Subtypes
must not be mutually exclusive.
One
instance of a supertype may belong to two subtypes.
Subtypes
must be mutually exclusive. (*)
Subtypes
should not be exhaustive.
All instances of a subtype may be an instance of the
supertype but does not have to. True or False?
True
False
(*)
All instances of a subtype must
be an instance of the supertype. True or False?
True
(*)
False
All instances of the supertype
must be an instance of one of the subtypes. True or False?
True
(*)
False
A business rule such as
"All accounts must be paid in full within 10 days of billing" is best
enforced by:
Creating
a message to be printed on every bill that reminds the customer to pay within
ten days.
Creating
additional programming code to identify and report accounts past due. (*)
Making
the payment attribute mandatory.
Making
the relationship between CUSTOMER and PAYMENT fully mandatory and 1:1 on both
sides.
Can all constraints be modeled on
an ER diagram?
No, in
which case you should let the database administrator handle them
No, but
you just explain them to the users so they can enforce them
No, and
those that cannot be modeled should be listed on a separate document to be
handled programmatically (*)
Yes,
all constraints must be modeled and shown on the ER diagram
Why is it important to identify and document business rules?
It
allows you to create a complete data model and then check it for accuracy. (*)
It
allows you to improve the client's business.
It
ensures that the data model will automate all manual processes.
None of
the above
How should you handle constraints
that cannot be modeled on an ER diagram?
Explain
them to the users so they can enforce them
All
constraints must be modeled and shown on the ER diagram
List
them on a separate document to be handled programmatically (*)
Always
let the network architect handle them
A new system would have a mixture
of both Procedural and Structural Business Rules as part of the documentation
of that new system. True or False?
True
(*)
False
Business rules are important to
data modelers because:
A. They
capture all of the needs, processes, and required functionality of the
business. (*)
B. All
Business rules are easily implemented in the ERD diagram.
C. The
data modeler must focus on structural rules, because they are easily
represented diagrammatically and eliminate other rules that involve extra
procedures or programming.
D. Both
A and C are true.
Why is it important to identify
and document structural rules?
Ensures
we know what data to store and how that data works together. (*)
Ensures
nothing. There are no benefits to be gained from documenting your Structural
Business Rules. We need to concentrate on the Procedural Business Rules only.
Ensures
we know what processes are in place and how to program them.
All of
the Above.
No comments:
Post a Comment