In database design workflow, is the following sequencing a sound practice? First identify entities, then determine their attributes, and finally establish the relationships among those entities.

Difficulty: Easy

Correct Answer: Valid statement

Explanation:


Introduction / Context:
Database design typically progresses from high-level understanding to detailed structure. A common approach is to: identify entities, list attributes, and then capture relationships. The question asks whether this sequence is sound as a general guideline in conceptual and logical modeling.


Given Data / Assumptions:

  • We are discussing early-stage (conceptual/logical) modeling, not vendor-specific physical tuning.
  • Entities represent real-world things or concepts users need to track.
  • Attributes describe properties of those entities.
  • Relationships connect entities and define cardinality and optionality.


Concept / Approach:
Starting with entities reduces noise and keeps focus on business nouns. Attributes attached to entities give concrete structure. Once entities and their attributes are clear, relationships can be defined with appropriate cardinalities (1:1, 1:N, M:N), sometimes introducing associative entities for M:N. This sequence is widely taught and used, even though iterative refinement is expected.


Step-by-Step Solution:
Elicit business requirements to list candidate entities.For each entity, enumerate attributes and candidate identifiers.Define relationships (including participation and cardinalities) and resolve M:N via associative entities if needed.Iterate with normalization to remove anomalies.


Verification / Alternative check:
Cross-check with standard methodologies (e.g., ER modeling texts): entities → attributes → relationships is a common, effective starting order, with iterative feedback loops for normalization and constraint validation.


Why Other Options Are Wrong:
“Invalid” contradicts common practice. “Only for physical design” is incorrect; this is conceptual/logical. “Ambiguous — DBMS” confuses logical modeling with physical implementation. “Only after normalization” reverses the process; normalization follows initial structure.


Common Pitfalls:
Locking the sequence rigidly; in practice, you iterate. Also, jumping to relationships first can lead to weak entity definitions.


Final Answer:
Valid statement

Discussion & Comments

No comments yet. Be the first to comment!
Join Discussion