Data: From Business Records To Model Inputs · Lesson 1

What Does A Data Record Represent?

A record is a representation of an entity, event, or observation. It is not the real-world thing itself. Its meaning depends on the fields, values, units, identifiers, timestamps, source, and conventions used to create it.

Study And Save Progress

Watch The Lesson

6 min 44 sec

Read the video transcript

A customer places an order for 2 items. In the real world, that is an event: a person chose goods, at a time, under an agreement. A business system does not store the event itself. It stores a representation of it. That representation might include an order identifier, customer identifier, amount, currency, and status.

Each field answers a different question. The order identifier helps distinguish 1 order from another. The customer identifier links the order to a customer record. The amount needs a currency. The status needs a meaning and, often, a time. A record is a collection of fields about an entity, event, or observation. A field is a named kind of information.

A value is what that field contains for 1 record. If an order record says the amount is 120 but leaves out the currency, we cannot tell which monetary unit it uses. Add a currency and the value becomes interpretable for the decisions that depend on it. The record is not the thing it describes. It is a representation made according to conventions:

what counts as 1 order, which identifier is assigned, how dates are recorded, what shipped means, and which values are required. A system can store a well-formed record that describes the wrong event or uses a convention a downstream team misunderstands. NASA's Jet Propulsion Laboratory reported on September 30, 1999 that a transfer between teams

using English and metric units contributed to the loss of Mars Climate Orbiter. Those were preliminary findings, with investigations continuing. The values reached another team, but their interpretation failed across the handoff. Checking that a field contains a number would not establish that both teams understand its unit. Our currency and sensor checks

address that same representation problem. An identifier also needs a defined source. Imagine a checkout system and a warehouse system that both issue an order called O101. If a downstream process treats those values as globally unique without preserving which system issued them, it could connect the wrong records. A source name or a defined

combined identifier keeps that convention visible. Next lesson we will see how tables and keys formalize relationships. Data can be structured, semi-structured, or unstructured. Structured data follows an explicit organization such as named fields and types. Semi-structured data has recognizable organization but may allow optional or changing fields,

as in a JSON object. Unstructured data, such as prose, audio, or an image, does not follow the same fixed row-and-column shape. It is still encoded and can contain meaningful structure. Unstructured does not mean random. Metadata is information about data: where it came from, when it was created, which version it belongs to, who owns it,

how it was processed, and what access rules apply. Metadata can change whether content is usable evidence. Suppose a company’s documented rule says a return follows the policy version in effect on the purchase date. The company has 1 version effective through May 31 and another beginning June 1. An order purchased on May 20 is assessed under the earlier version even if

the customer asks about it on June 4. The latest document is not automatically the applicable one. A real system must define and verify the rule that determines applicability. A schema describes expected organization and constraints. It can say that amount is numeric, currency is required, and order identifiers must be unique within a defined source.

These checks catch some errors, such as text arriving where a number is expected. They cannot prove that the amount matches the payment or that the identifier was assigned to the correct order. A well-formed amount can pass every format check and still disagree with the independent payment record. Format validity and business accuracy are different checks.

Now follow the same order. Suppose its amount is 120 and its currency is USD. A payment record also shows 120 USD and carries the same verified order identity. Those details support a consistent comparison. If the currency were missing, or if the 2 O101 identifiers came from different systems,

the apparent match would not yet establish that the records describe the same transaction. The convention and the evidence change what we can responsibly conclude. The order status says shipped, but there is no event timestamp. Can the assistant say when it shipped, or claim that delivery happened?

Pause and decide. It cannot establish either from that field alone. We need the event meaning, time, and source. A timestamp without an event definition can create false confidence. Try a separate case. An order was purchased on May 20. The company’s hypothetical rule says eligibility follows the policy in force on the purchase date.

1 policy version is effective through May 31; another begins June 1. The customer asks on June 4. Which version should the system check? Pause and decide. Under the stated rule, it checks the version effective on May 20. The request date does not silently replace the applicability rule.

Try a different record. A warehouse sensor and a delivery van sensor each report 18, but 1 value has no unit. Can you compare them? Pause and decide. Not yet. First identify the unit, the measurement time, and which device produced each reading.

The same-looking number can represent different measurements. When you inspect a record, ask 3 questions: what real-world thing or event does 1 record represent; what conventions give each field meaning; and what independent evidence tells us the values are accurate and current? Next we will connect records into tables, keys, and relationships.

Those connections only work when we preserve the grain of each table: what 1 row represents.

Main Point

Key Points

Name the real event or entity a record represents.
Preserve units, event times, identifier scope and version context.
Check structural validity and agreement with independent evidence separately.

1. Worked example: interpret the opening record

Imagine a customer places an order for two products. A record might contain an order identifier, customer identifier, amount, currency, and status. The fields have different jobs. An amount of 120 without a currency is ambiguous. “Shipped” without the event definition and time does not say when dispatch occurred or whether the customer received the package.

A field is a named kind of information; its value is the information stored for one record. A schema defines expected organization and constraints, such as a numeric amount, required currency, or unique order identifier within its defined source. Schema checks catch format and structural errors. They do not prove the value describes the correct transaction.

Identifiers depend on scope. Two systems may each issue an order called O101. If a downstream process assumes every O101 is globally unique, it could connect records from different orders. Preserve the source namespace or define a combined identifier before joining records. Lesson 2 develops keys and relationships.

2. Structure and context

Structured data follows a fixed organization, such as named fields and types. Semi-structured data has recognizable organization but may admit optional or changing fields. Unstructured data, such as prose, audio, or an image, lacks the same fixed row-and-column format. It still has encoding and internal structure; unstructured does not mean meaningless.

Metadata describes data: its source, creation time, version, owner, processing history, and access rules. Metadata can determine which information is applicable. In a hypothetical company, a written rule says return eligibility follows the policy version in effect on the purchase date. A May 20 purchase is evaluated using the version effective on May 20, even if the question arrives June 4. The example rule is explicit and local to the scenario; real systems must identify the actual applicable rule.

A timestamp also needs an event meaning. Order creation, dispatch, and a delivery scan are different events. If the timestamp is attached to dispatch, the record supports a dispatch-time claim. It does not prove the customer received the parcel.

3. Worked interpretation

Suppose the checkout system records O101 as 120 USD. A payment record also shows 120 USD, and both records have verified source identifiers for the same order. That is a meaningful comparison. If the currency is missing, or both source systems use O101 for different orders, equal-looking values do not establish a match. A well-formed amount can also disagree with an independent payment record; schema validity and business accuracy are different checks.

Ask three questions when you inspect a record:

What real-world entity, event, or observation does one record represent?
Which conventions make the fields interpretable?
What independent evidence supports accuracy and currentness?

4. Check your understanding

A van sensor and a warehouse sensor both report 18, but one value has no unit. Do not compare them yet. Identify the unit, measurement time, and source before interpreting the values. If authoritative metadata cannot supply a missing unit, keep the value unresolved rather than guessing.

5. A dated example

NASA's Jet Propulsion Laboratory reported on September 30, 1999 that a transfer between teams using English and metric units contributed to the loss of Mars Climate Orbiter. Those were preliminary findings, with investigations continuing. The values reached another team, but their interpretation failed across the handoff. Checking that a field contains a number would not establish that both teams understand its unit. Our currency and sensor checks address that same representation problem.

6. Bringing the lesson together

Return to the order: its identifier, 120 USD amount and shipment state become useful only with source scope, units and event meaning. You can now inspect a new record, explain what it supports and name the missing evidence that would change the answer.

Learning Checks

Use this hypothetical order and related records. The event represented by the checkout timestamp has not yet been defined.

Checkout system: order O101; amount 120; currency USD; status shipped; timestamp 14:05 (event type unspecified).
Warehouse system: order O101; amount 120; currency not recorded; timestamp 14:05 (event type unspecified).
Delivery system: scan event recorded at 15:10; customer handoff not recorded.
Policy rule: for this hypothetical company, return eligibility follows the policy version in effect on the purchase date.
Policy A: effective through May 31.
Policy B: effective beginning June 1.
Purchase date: May 20. Customer asks: June 4.

Attempt each answer before expanding the reasoning.

M13-L01-Q01

What does the checkout record establish? What does it not establish about the event at 14:05 or customer delivery?

Show reasoning

The checkout system stored a shipped status and a timestamp of 14:05, but the event type is unspecified. We cannot call it creation, dispatch or scan. The separate delivery scan at 15:10 does not prove customer handoff.

M13-L01-Q02

Two systems each issue an order called O101. What source information and relationship evidence are needed before treating them as the same order?

Show reasoning

Preserve the source namespace and verify a documented relationship or identifier rule.

M13-L01-Q03

Which policy version applies under the stated hypothetical purchase-date rule? Why does the question date not decide it?

Show reasoning

Policy A, effective on the May 20 purchase date, under the explicitly stated hypothetical rule.

M13-L01-Q04

Can the van sensor’s 18 degrees Celsius and warehouse sensor’s 18 with no unit be compared? What evidence is needed?

Show reasoning

Not yet. Obtain authoritative unit, time and source metadata, or keep the value unresolved.

Sources

PostgreSQL documentation, “Constraints,” sections 5.5.4–5.5.5, for one implementation’s primary-key and foreign-key behavior: https://www.postgresql.org/docs/current/ddl-constraints.html (retrieved 2026-10-29).

NASA Jet Propulsion Laboratory, “Mars Climate Orbiter Team Finds Likely Cause of Loss”, published 1999-09-30; event/context: 1999-09-23 loss; preliminary report 1999-09-30. https://www.jpl.nasa.gov/news/mars-climate-orbiter-team-finds-likely-cause-of-loss/ (retrieved 2026-10-29). Historical preliminary finding, not sole-cause final investigation or measured business outcome.

Learner Materials

Download Lesson 1 Learner Materials

Use the supplied fictional cases and templates for practice.

Practice

Write your answer, compare it with the model answer and decide what to revisit. These written checkpoints are self-assessed.

What does the checkout record establish? What does it not establish about the event at 14:05 or customer delivery?

Show The Model Answer

Compare your reasoning with the model answer. These written checks are self-assessed.

Two systems each issue an order called O101. What source information and relationship evidence are needed before treating them as the same order?

Show The Model Answer

Preserve the source namespace and verify a documented relationship or identifier rule.

Compare your reasoning with the model answer. These written checks are self-assessed.

Which policy version applies under the stated hypothetical purchase-date rule? Why does the question date not decide it?

Show The Model Answer

Policy A, effective on the May 20 purchase date, under the explicitly stated hypothetical rule.

Compare your reasoning with the model answer. These written checks are self-assessed.

Can the van sensor’s 18 degrees Celsius and warehouse sensor’s 18 with no unit be compared? What evidence is needed?

Show The Model Answer

Not yet. Obtain authoritative unit, time and source metadata, or keep the value unresolved.

Compare your reasoning with the model answer. These written checks are self-assessed.

Open Practice And Save Your Work