Free DAMA CDMP Fundamentals Practice Questions: Data Modelling and Design

Topic snapshot

Sample questions

These are original IT Mastery practice questions aligned to this topic area. They are not official exam questions, copied live-exam content, or exam dumps. Use them for self-assessment, scope review, and deciding what to drill next.

Question 1

Topic: Data Modelling and Design

During stakeholder validation of a logical data model for claims processing, a claims manager reviews the Claim, Policy, and Payment entities and says: “The model shows each claim linked to one payment, but a single claim can have several partial payments over time, and some claims have no payment yet.” What type of model feedback is the manager providing?

Options:

• A. Relationship error

• B. Scope issue

• C. Implementation constraint

• D. Definition gap

Best answer: A

Explanation: Stakeholder validation helps confirm that a data model reflects business rules, not just technical structures. The manager is not asking for a new subject area or clarifying the meaning of an entity. The concern is that the relationship between Claim and Payment is modeled incorrectly: one claim may have zero, one, or many payments, and payments may occur over time. That points to cardinality and optionality, which are core relationship characteristics in logical data modelling.

A definition gap would involve unclear business meaning. A scope issue would involve something missing or out of bounds. An implementation constraint would involve platform, storage, or system limitations rather than the business relationship itself.

• Definition gap would fit unclear terms, such as whether “payment” means approved, issued, or settled.
• Scope issue would fit a missing business area, such as excluding recoveries or third-party reimbursements.
• Implementation constraint would fit a technical limitation, such as a system allowing only one stored payment record.

Question 2

Topic: Data Modelling and Design

An insurance company is replacing a claims reporting data mart. Business leaders disagree on what counts as a “closed claim,” application teams only have source-system table layouts, and analytics teams need consistent KPI definitions before building dashboards. Data governance is new, but claims data stewards are available. Which action is the best professional decision?

Options:

• A. Build dashboard prototypes to expose definition gaps

• B. Let application teams derive definitions from source tables

• C. Facilitate a validated conceptual and logical model review

• D. Select a modeling tool and enforce one notation

Best answer: C

Explanation: Data models are communication tools as much as design artifacts. In this situation, the main risk is semantic disagreement: “closed claim” means different things to different stakeholders. A conceptual model can align business entities and relationships in business language, while a logical model can add attributes, definitions, and rules that data professionals, application teams, and analytics teams can validate. Involving data stewards supports governance without making the effort overly technical. Physical table layouts and dashboards are useful later, but they should be grounded in agreed business meaning first.

• Source-table definitions fail because physical structures often reflect system design, not agreed business meaning.
• Dashboard prototypes may reveal conflicts, but they do not establish governed definitions before analytics work begins.
• Tool enforcement addresses documentation consistency, not stakeholder validation of claims concepts and KPI definitions.

Question 3

Topic: Data Modelling and Design

A data governance council is reviewing a new customer onboarding initiative. Business stakeholders disagree on the meaning of “customer,” “applicant,” and “account holder.” They need to validate shared business concepts and relationships before solution design begins. Most reviewers are nontechnical, and the team wants to avoid discussion of tables, keys, and platform choices. Which model artifact is the best professional choice?

Options:

• A. Conceptual data model with business definitions

• B. Physical data model with indexes and datatypes

• C. Database deployment diagram

• D. Source-to-target mapping specification

Best answer: A

Explanation: Model communication should match the stakeholder decision being made. Here, the need is early business validation of shared concepts and relationships, not implementation detail. A conceptual data model, supported by clear business definitions, is designed for that purpose. It helps business stakeholders confirm entity meaning, major relationships, and scope using language they understand. Logical and physical design artifacts become useful later, after the business view is agreed. The key is to choose the least technical model view that still answers the stakeholders’ question.

• Physical detail too early fails because indexes, datatypes, and storage choices distract from validating business meaning.
• Integration mapping fails because source-to-target rules support data movement, not agreement on core business concepts.
• Deployment focus fails because infrastructure views do not communicate entity definitions or business relationships.

Question 4

Topic: Data Modelling and Design

A bank maintains a central model repository, but project teams often upload logical data models after development is complete. Several models define Customer differently, lineage links to source systems are missing, and analysts cannot assess which reports would be affected by a proposed definition change. The bank wants better reuse and impact analysis without slowing active projects unnecessarily. What is the best professional decision?

Options:

• A. Create a new reporting data mart for customer analysis

• B. Ask each project team to keep its own model inventory

• C. Establish model repository governance with required ownership, status, definitions, lineage links, and change review

• D. Add more physical database details to every model

Best answer: C

Explanation: A model repository supports reuse and impact analysis only when its contents are governed, not merely stored. The facts point to weak control over model ownership, approved definitions, lifecycle status, lineage, and change review. Requiring these elements in the repository gives teams a shared source for finding reusable models, understanding where data comes from, and assessing downstream effects when a definition changes. The governance approach can be scaled to avoid unnecessary delay, for example by requiring minimum metadata and review at defined model lifecycle checkpoints. More technical detail or another data mart may help other problems, but it does not fix uncontrolled definitions and missing lineage in the repository.

• Local inventories would fragment knowledge further and reduce enterprise reuse and impact analysis.
• Physical details may support implementation, but they do not establish approved definitions, ownership, or lineage control.
• New analytical storage might serve a reporting need, but it bypasses the repository governance weakness causing the issue.

Question 5

Topic: Data Modelling and Design

A regional insurer is consolidating customer, policy, and claims data models from three business units. The business goal is to reuse common subject-area definitions for a new enterprise reporting platform, but the current models use different entity names and are stored in separate project folders. Governance is still maturing, and data stewards need a practical way to review proposed model changes before projects build new interfaces. Which action is the best professional decision?

Options:

• A. Create report-specific physical tables first and document definitions after delivery

• B. Let each project team maintain its own model and map differences during integration

• C. Adopt modelling standards, naming conventions, review checkpoints, and a shared model repository

• D. Assign database administrators to rename tables according to local system constraints

Best answer: C

Explanation: Model governance and design standards help an enterprise manage models as reusable data assets rather than isolated project artifacts. Common naming conventions and modelling standards make entities, attributes, and relationships easier to compare across business units. Review practices give stewards and architects a controlled point to resolve definition conflicts before implementation. A shared model repository supports reuse, impact analysis, version control, and visibility across projects. In this situation, the insurer needs enterprise consistency for reporting and a practical governance mechanism for proposed changes, so the combined standards-and-repository approach best fits the stated needs. Mapping differences later may be necessary in some integrations, but it does not create the enterprise consistency or reuse the organization is trying to achieve.

• Project-only models leave naming and definition conflicts unresolved until integration, increasing rework and semantic inconsistency.
• Report-first tables may deliver quickly, but documenting later weakens governance and reduces reuse of shared definitions.
• Local table renaming focuses on physical implementation constraints rather than enterprise modelling consistency and steward review.

Question 6

Topic: Data Modelling and Design

A data governance council is resolving inconsistent use of Customer, Account, and Contract across several business units. Stakeholders need a shared representation of the main entities, their important attributes, business identifiers, and relationship cardinalities, but they are not ready to specify database tables, indexes, or storage details. Which artifact best fits this need?

Options:

• A. System data lineage diagram

• B. Conceptual subject-area model

• C. Logical data model

• D. Physical database schema

Best answer: C

Explanation: A logical data model is the best fit when the organization needs precise shared meaning for data structures before implementation. It expands beyond a conceptual view by defining entities, key attributes, identifiers, and relationship cardinalities, while remaining independent of a specific DBMS or storage design. In this scenario, the council needs enough detail to resolve business meaning and consistency across units, but not physical design choices such as indexes, partitions, or column data types. The key distinction is that conceptual models support high-level scope, logical models define business structure, and physical models translate that structure into implementable database objects.

• Conceptual scope is too high-level because it usually identifies major subject areas and relationships, not detailed attributes and identifiers.
• Physical schema design goes too far because tables, indexes, and storage details are explicitly not needed yet.
• Lineage focus addresses data movement and transformation, not the primary representation of entities, attributes, identifiers, and cardinalities.

Question 7

Topic: Data Modelling and Design

A customer service, billing, and analytics group are creating a shared data model for Customer. They disagree about whether an email address uniquely identifies a customer because some customers share an email and some change it over time. The model must support common business definitions before physical database design, reduce duplicate customer records, and be understandable to business stewards. What is the best professional decision?

Options:

• A. Create separate Customer entities for billing, service, and analytics

• B. Model Customer as an entity with a stable business identifier and email as an attribute

• C. Defer identity decisions until physical database keys are assigned

• D. Use email address as the primary identifier for Customer

Best answer: B

Explanation: Conceptual and logical data modelling should clarify business meaning before physical implementation. In this situation, Customer is a shared business entity, while email is a descriptive attribute that can change and may not be unique. A stable business identifier, such as a customer number or governed customer ID, supports consistent relationships across billing, service, and analytics while allowing email history or contact preferences to be handled separately. Business stewards can then agree on definitions, uniqueness rules, and relationships before database-specific keys are designed.

The key distinction is identity versus description: identifiers establish what makes an entity instance distinct; attributes describe it.

• Email as identity fails because email is neither stable nor reliably unique under the stated facts.
• Separate entities by function preserves departmental silos instead of creating shared understanding of the same business concept.
• Physical keys first confuses implementation mechanics with business identity and delays stewardship agreement.

Question 8

Topic: Data Modelling and Design

A sales dashboard reports revenue by product from an order-line fact table. It also shows customer satisfaction score by product, but satisfaction is collected once per customer per month. The current model joins the monthly satisfaction records to order lines by customer and month, causing the same score to be repeated across every product the customer bought. Which modelling correction best addresses the problem?

Options:

• A. Average the repeated satisfaction values after the join

• B. Add product as a mandatory key to the satisfaction fact

• C. Separate the facts by grain and report satisfaction only at compatible dimensions

• D. Store satisfaction score as an attribute of the product dimension

Best answer: C

Explanation: Dimensional models must declare and respect the grain of each fact table. Revenue from order lines is at a product/order-line level, while customer satisfaction is at a customer-month level. Joining these facts directly creates a fan-out effect: the same satisfaction value is repeated for each purchased product, making product-level satisfaction appear more precise than the source supports. The better correction is to keep the measures in separate fact tables at their true grains and combine them only through conformed dimensions where the grains are compatible, such as customer, month, or a valid aggregate. Product-level satisfaction would require a defensible collection or allocation method, not just a join.

• Forced product key invents detail that was not captured in the satisfaction process.
• Product attribute misclassifies a measured customer-month event as descriptive product metadata.
• Post-join averaging may hide duplication but does not fix the incorrect grain relationship.

Question 9

Topic: Data Modelling and Design

A retail analytics team is redesigning a sales performance dashboard. Sales transactions are captured by product, store, and day, but revenue targets are approved only by region and month. Executives need an auditable variance metric, and there is no approved rule for allocating regional monthly targets to stores or days. What is the best professional correction to the analytical model?

Options:

• A. Use separate fact tables and compare at the target grain.

• B. Remove product, store, and day detail from sales.

• C. Store monthly targets on each daily sales transaction row.

• D. Allocate targets evenly across stores and days.

Best answer: A

Explanation: Dimensional and analytical models need a clearly declared grain for each fact table. Daily store-product sales and monthly regional targets are facts at different levels of detail, so combining them in one fact structure can repeat targets and distort variance calculations. Since no approved allocation rule exists, the model should not invent one. A sound correction is to keep sales and targets in separate fact tables at their natural grains, use conformed dimensions where appropriate, and calculate variance only after sales are summarized to region and month. This preserves drill-down for sales while keeping target comparisons controlled and auditable.

• Repeating targets causes double counting when users slice by transaction, product, store, or day.
• Even allocation invents a business rule that has not been approved and would reduce auditability.
• Dropping detail protects the target comparison but unnecessarily removes valid sales analysis capability.

Question 10

Topic: Data Modelling and Design

A lending library is designing a logical data model. A registered member may have no loans yet. Every loan must be for exactly one physical copy and must be associated with exactly one member. A physical copy may exist before it has ever been loaned. LoanNumber is unique for each loan. Which interpretation is most accurate?

Options:

• A. Physical Copy is an attribute of Loan because every Loan names one Copy.

• B. A Member has zero-to-many Loans; each Loan has one Member.

• C. A Member has one-to-many Loans; each Member must have a Loan.

• D. LoanNumber identifies Member because each Loan has one Member.

Best answer: B

Explanation: Cardinality describes how many instances can participate in a relationship, and optionality describes whether participation is required. Here, a member may have no loans, so the Member-to-Loan relationship is optional on the Member side and can be zero-to-many. Each loan must be associated with exactly one member, so the Loan-to-Member side is mandatory and one. LoanNumber is an identifier for Loan, not for Member. Physical Copy should be modeled as an entity related to Loan because copies can exist independently before any loan occurs. The key takeaway is to separate relationship participation rules from identifiers and entity-vs-attribute decisions.

• Mandatory member loans fails because the scenario explicitly allows a registered member to have no loans.
• Misplaced identifier fails because a unique loan number identifies Loan, not the Member associated with it.
• Copy as attribute fails because a physical copy has independent existence before being loaned, making it an entity candidate.

Continue in the web app

Use IT Mastery for interactive DAMA CDMP Data Management Fundamentals practice with mixed sets, timed mocks, topic drills, explanations, and progress tracking.

Try DAMA CDMP Data Management Fundamentals on Web

Related focused pages

• Free DAMA CDMP Data Management Fundamentals Full-Length Practice Exam
• Data Management Process
• Big Data
• Data Architecture
• Document and Content Management
• Data Ethics
• Data Governance
• Data Integration and Interoperability
• Master and Reference Data Management
• Data Quality
• Data Security
• Data Storage and Operations
• Data Warehousing and Business Intelligence
• Metadata Management