CompTIA Data+ DA0-002 · Free study guide

Objective 5.1 — Explain data management concepts

Data management makes an analytical result understandable after the original analyst has moved on. It connects technical movement with business meaning: where a field came from, what changed it, which version was used, who owns the definition, and when the data was last refreshed.

Integration and authoritative sources of truth

Data integration combines data across systems so it can support a shared process or question. Integration may copy data into a warehouse, transform it through a pipeline, query systems through a federated layer, or synchronize selected attributes. Successful connectivity is not enough. Keys, grain, timing, units, and definitions must also align.

An authoritative source of truth is the approved source for a particular fact or metric. The billing system might be authoritative for current subscription status, while the closed finance ledger is authoritative for reported revenue. One system does not need to be authoritative for every question.

A system of record is the controlled operational home for a record. A certified analytical table may become the trusted reporting source after reconciling several systems. Governance states which source wins when values conflict.

Calling a dashboard the source of truth does not make it one. Authority comes from ownership, controlled definitions, quality evidence, and an approved process.

Data flow diagrams

A data flow diagram shows how data moves among external sources, processes, stores, and destinations. It can include trust boundaries and major transformations. A useful diagram answers questions such as:

• Where does customer data enter the process?
• Which transformation creates the reporting table?
• Where is an intermediate copy stored?
• Which external party receives an export?
• Where does sensitive data cross a controlled boundary?

A data flow diagram is not a network topology and does not need every server address. Its purpose is to make movement and processing understandable at the relevant level.

Data lineage

Data lineage traces a data element backward to its origin and forward through transformations and consumers. Table-level lineage might show that a dashboard uses a monthly revenue model built from invoice and refund tables. Column-level lineage can show that net_revenue equals recognized invoice value minus approved refunds after currency conversion.

Lineage supports impact analysis, troubleshooting, audit, and trust. If a source column changes type, lineage identifies the models and reports that may break. If a KPI is challenged, lineage reveals the exact source and calculation path.

Lineage and a flow diagram overlap, but they answer different questions. The diagram emphasizes movement and architecture; lineage emphasizes provenance and dependency.

Data dictionaries, hierarchies, and explainability reports

A data dictionary records the meaning and handling of data elements. Strong entries include business definition, technical name, type, allowed values, unit, grain, source, owner, sensitivity, null meaning, calculation, and effective version. A list of column names alone is not a useful dictionary.

A hierarchy defines levels that roll up and drill down consistently. Geography may follow store to city to region to country. Products may follow item to category to department. A hierarchy prevents one report from treating a region as a peer of a country and another from counting an item in two incompatible parent groups.

A data explainability report documents how an output was produced and how it should be interpreted. Depending on the system, it can describe sources, selected fields, transformations, model or rule logic, assumptions, validation, limitations, and known risks. For an AI-assisted score, it should make the data provenance, intended use, major drivers, and review controls visible. Explainability is not a claim that every complex model can be reduced to one simple cause.

Snapshots, versions, and refresh intervals

A snapshot preserves data at a point in time. It supports reproducible reporting, audit, comparison, and recovery from a later bad change. A regulatory submission should reference a frozen snapshot rather than a live table that continues to accept late records.

Data versioning distinguishes states of a data set or definition over time. Versions may be full snapshots, incremental changes, immutable table commits, or dated releases. Version the schema and metric logic as well as the rows; the same data processed under two formulas can produce two legitimate but incomparable results.

A refresh interval states how frequently data is updated. Real-time, hourly, daily, and monthly refreshes serve different decisions. Faster refresh is not automatically better. It increases infrastructure cost and can publish unvalidated changes sooner. The displayed “last refreshed” time, source event time, and processing completion time may differ, so freshness metadata should be explicit.

Late-arriving records need a rule. A team may restate prior periods, preserve the original closed snapshot and issue a new version, or apply adjustments in the next period. Silent changes destroy reproducibility.

Metadata ownership and change control

Metadata is information about data. Business metadata describes definitions and owners. Technical metadata describes schemas, types, relationships, and transformations. Operational metadata records refreshes, row counts, failures, and performance. Security metadata records classification, access, and handling requirements.

Metadata needs an accountable owner and a maintenance process. Stale metadata can be more dangerous than missing metadata because users trust it without realizing it is wrong.

Change control evaluates and records a proposed change before it reaches consumers. A sound process captures the reason, owner, affected assets, compatibility risk, approvals, test evidence, effective date, communication, and rollback plan. Breaking changes may require a parallel version so consumers can migrate safely.

Change control should not prevent improvement. It makes improvement visible, tested, and recoverable.

Scenario: reconciling monthly revenue

Sales operations calculates revenue from order totals, while finance uses recognized invoice value minus refunds. Both publish a tile called “Revenue,” and the values differ. A currency field is also changing from three-letter codes to numeric identifiers.

Governance first names the finance ledger as authoritative for closed financial reporting and documents where the sales measure remains appropriate. The dictionary gives each metric a distinct name, formula, grain, unit, owner, and effective date. Lineage traces invoice, refund, and currency sources into the certified model. A data flow diagram shows the operational and finance paths and the dashboard destination. The currency schema change goes through impact analysis and a versioned transition. Monthly snapshots preserve the exact closed result, while refresh metadata tells users when the current operational view last changed. An explainability report records the reconciliation and limits of comparison.

Exam traps

• Declaring one universal source of truth when authority differs by fact and use.
• Treating technical connectivity as complete integration.
• Confusing a data flow diagram with detailed network topology.
• Confusing lineage with a dictionary: lineage traces; a dictionary defines.
• Calling a column-name list a complete data dictionary.
• Assuming a snapshot and a live real-time view serve the same purpose.
• Believing a faster refresh always produces better decisions.
• Versioning rows while silently changing the metric formula.
• Treating metadata as self-maintaining documentation.
• Using change control as a reason to avoid ownership or testing.

Readiness checklist

• I can distinguish systems of record, certified analytical sources, and authoritative metrics.
• I can identify when integration requires reconciliation of keys, grain, time, and definitions.
• I can explain the different purposes of data flow diagrams and lineage.
• I can name the fields a useful data dictionary entry should contain.
• I can describe a hierarchy and an explainability report.
• I can choose snapshots and versions when reproducibility matters.
• I can match refresh intervals to decision needs and explain late-arriving-data rules.
• I can distinguish business, technical, operational, and security metadata.
• I can outline ownership and change control for a breaking data change.