AI Glossary / Governance, ethics and safety / Beginner
Data record
Definition
A data record is a collection of related data items handled as one unit. It might describe an event, transaction, object or observation, such as one delivery with its identifier, date, destination and status.
What it means
A spreadsheet row is a familiar example, but records are not limited to tables. A structured message or a document in a database can also represent a record. The important point is the agreed unit and the relationship among its items.
Record boundaries determine what counts as one observation. One customer can have many orders, and one order can have many line items. Mixing these levels can distort analysis or accidentally duplicate information. A dataset should therefore explain what each record represents, not merely list its column names.
How it works
A schema or data contract describes the items expected in a record, their types and any relationships or constraints. An identifier may distinguish the record, while other fields connect it to related records. Not every record has a globally unique identifier, so that assumption needs checking.
Systems create, transmit, store and update records according to defined rules. Some records are immutable event observations; others represent a current state that changes. Keeping those meanings distinct matters for time-based analysis and model training.
When records are combined, engineers check key relationships, missing values, duplicates and units of observation. The physical encoding is separate from the logical meaning: a CSV row and a JSON object can carry similar information while differing in structure and representation.
Three practical examples
- Delivery prediction: One record describes a shipment, with fields available before the predicted arrival time. Later outcome fields are kept separate from prediction inputs.
- Sensor monitoring: One record captures a reading from a particular sensor at a particular timestamp, including units and status information.
- Document processing: A record stores an extracted document identifier, candidate fields and review status. Multiple pages may belong to the same logical document record.
Think of it this way
Think of a form with several related boxes that together describe one event. The form is the record, while each filled box is a data item. The analogy is limited because digital records can contain nested structures, links and repeated items rather than a fixed set of paper fields.
Worked example
Suppose a shop has three orders. Order A contains two line items, order B contains one and order C contains three. An order-level table has three records; a line-item table has six.
If each order-level total is copied onto every joined line-item record and then summed, the total can be counted several times. For example, A's total of 50 appears twice and contributes 100 to the incorrect sum.
The correct calculation depends on the question: sum line-item amounts for item analysis, or count each order total once for order revenue. The example illustrates why understanding record granularity matters before joining data or training a model.
Illustrative case study
Fictional case: Event Grove combines registration records with session-attendance records to predict event demand. Its first join produces several rows for attendees who joined multiple sessions.
The analyst initially interprets the larger row count as more people. After defining the record unit at each stage, the team separates attendee counts from attendance-event counts and revises the features. It documents the relationship between the tables. This invented case demonstrates a common granularity error rather than a real project's results.
Common misconceptions and mistakes
A record is not always equivalent to a person, customer or independent training example. Several records may describe the same entity, and nearby sensor records may be strongly dependent.
A unique row number also does not prove that the underlying event is unique. Duplicate real-world events can receive different identifiers. Do not assume one line of text always equals one record: quoted fields and structured formats can complicate physical line boundaries. Finally, a well-formed record can still contain incorrect facts or lack information required for the intended use.
Business use
Clear record definitions help teams exchange data, prevent join errors and interpret model results. They are especially important when reports count events, customers and items differently.
Document the unit of observation, identifier semantics, update behavior and time reference. When splitting data for model evaluation, consider whether related records should remain together to avoid leakage. A model tested on near-duplicates of its training records may appear stronger than it is on genuinely new entities or events.
People also ask
Is every spreadsheet row a record?
Often, but headers, notes and multirow layouts can violate that assumption. The dataset's structure determines the logical record.
Can a record contain another structure?
Yes. Some formats support nested objects or lists within a record.
Does a record identifier guarantee no duplicates?
No. It may uniquely identify stored entries while duplicated real-world events remain present.
Check your understanding
One customer has five transaction records. Does a table containing those five rows necessarily represent five customers?
Answer: No. The record unit is a transaction; customer counts require the appropriate customer identity and counting rule.
Related terms
- Data item
- Schema
- Primary key
- Event
- Data leakage
- entity
- granularity
- duplicate record
Learn next
Choose two related tables and write a sentence defining one record in each. Identify keys, repeated entities and update rules. Predict how many rows a join should produce before running it. Then check whether the resulting record unit matches the intended analysis or machine-learning task.
More in Governance, ethics and safety
- Data quality model - A data quality model organizes the characteristics used to define and evaluate data quality.
- Data quality plan - A data quality plan specifies how an organization or project will achieve its data quality objectives.
- Data quality planning - Data quality planning is the activity of setting data quality objectives and deciding which processes and resources are needed to achieve them.
- Data security - Data security is the protection of data against unauthorized access, disclosure, alteration, destruction, and loss of availability.
- Debiasing - Debiasing is the process of identifying and reducing a specified unwanted bias in data, representations, models, or their use.
- Decision support system - A decision support system, or DSS, is a computer-based system that helps people make decisions by organizing relevant information, analyzing alternatives...
Sources
ITU-T Y Supplement 97, term 3.1.37, consulted in the official PDF: https://www.itu.int/rec/T-REC-Y.Sup97-202511-I/en. The term is attributed there to ISO/IEC 25024. RFC 4180, Section 2, consulted for CSV record syntax and quoted line breaks: https://www.rfc-editor.org/rfc/rfc4180. RFC 8259 provides the JSON encoding reference: https://www.rfc-editor.org/rfc/rfc8259. Encoding rules do not determine the application’s logical record granularity.
Previous: Data quality planning Next: Data recovery