Data & Data Science
A technically valid dataset is more than a collection of parseable values. The examination distinguishes the conceptual model from its physical implementation, tests constraints and relationships and considers how schema changes or migrations affect the integrity of actual data.
Short answer
The logical data model describes concepts and relationships; the physical schema implements them through tables, fields, types, constraints, documents or graph shapes. Comparing the two can reveal where intended rules are absent, relaxed or implemented differently in the running system.
Schema validation can establish conformity with defined structural rules, but structural conformity is not proof that values are factually correct. The report therefore separates format and integrity findings from substantive data accuracy and traces schema changes to their processing consequences.
1. Distinguish logical data model and physical schema
Conceptual intent and implementation are different evidence layers
The logical model describes entities, attributes and relationships expected by the domain or application design. The physical schema describes how those concepts are implemented in a relational database, JSON documents, files, event formats or graph structures.
An examination compares documented intent with the actual deployed schema. A conceptual “required” attribute may be nullable in the database; a one-to-one relationship may be implemented without a uniqueness constraint; a documented enumeration may accept arbitrary strings in production.
Differences are not automatically defects. They are recorded as technical properties and assessed against the concrete requirement or processing purpose relevant to the examination.
2. Examine types, required fields and value domains
Type and constraint rules should be explicit
Data types influence parsing, comparisons, sorting and downstream calculations. Text fields containing numbers, localised date strings or floating-point representations can create different behaviour from formally typed values.
Required fields, nullability, length limits, ranges, enumerations and pattern constraints are compared with actual data. Violations are counted and linked to the relevant dataset version so that the result is reproducible.
A field passing a type check is not necessarily semantically valid. A date can be syntactically well formed but refer to the wrong event; a positive integer can still be an incorrect customer identifier.
3. Examine keys and relationships for referential integrity
Relationships require more than matching column names
Primary keys, unique constraints, foreign keys and application-level identifiers define how records are related. The examination checks duplicate keys, orphan references, many-to-many bridge structures and cases where relationships are enforced only in application code.
Where database constraints are disabled or absent, reproducible queries can measure relationship violations directly. In document or graph systems, equivalent rules may be expressed through JSON Schema, SHACL shapes or application validation.
A technically consistent relationship does not prove that the linked records represent the correct real-world entities. Referential integrity and factual accuracy remain separate findings.
4. Perform schema and format validation reproducibly
Validation rules should be versioned with the data state
For JSON documents, JSON Schema Draft 2020-12 can express structural and validation rules. For RDF graphs, SHACL can express shapes and constraints. Similar principles apply to database DDL, Avro, XML Schema or custom validators.
The examination records the exact schema or validation rule version, the validator or tool version where relevant and the input dataset. A generic statement that “the data was validated” is insufficient if the rule set cannot be identified.
Validation results are preserved with counts and examples of violations. This makes later re-testing possible and avoids reducing a detailed result to a binary pass/fail label.
5. Consider migrations and schema drift
The same field name can have different meaning over time
Schema migrations can add, remove, rename or reinterpret fields and relationships. Historical data may therefore require the schema version active at the time it was written rather than the current production schema.
Drift can also occur without formal migrations, for example when upstream JSON payloads gain optional fields, CSV column meanings change or an API starts returning different enumerations. The examination compares versions and identifies when processing assumptions changed.
Migration scripts, DDL history, repository commits, schema registries and deployment records can support the chronology. Missing versions limit claims about historical validity.
6. Connect integrity findings to processing effects
Structural findings matter through their technical consequences
A broken foreign-key relationship may cause missing joins; a type change may alter sorting; a nullable field can propagate missing values into analytics; an unexpected enumeration can trigger fallback behaviour. The report links relevant integrity findings to observed or technically supported processing effects.
Not every schema deviation is material. The assessment therefore distinguishes violations that are tolerated without downstream effect from those that change records, calculations or system behaviour.
The final conclusion states what was validated, against which schema, for which data state and with what observed consequences. It does not equate structural validity with overall data quality or substantive correctness.
Is the technical conclusion sufficiently supported?
- Is the logical model distinguished from the deployed physical schema?
- Are the exact schema and dataset versions identified?
- Are data types, required fields, ranges and enumerations tested reproducibly?
- Are key uniqueness and relationship violations measured?
- Are application-level constraints considered where the database does not enforce them?
- Are migrations and schema drift tied to historical data states?
- Are validation tools and rule versions documented?
- Are integrity findings connected to actual processing consequences without being confused with factual accuracy?
Constructed example
A system specification states that every order references exactly one existing customer. The production database contains no foreign-key constraint, and a reproducible query finds several orders whose customer identifiers do not exist in the customer table. The application suppresses those orders in a reporting join.
The report therefore records a referential-integrity violation and its observed reporting effect. It does not conclude that all remaining relationships represent the correct real-world customers merely because their identifiers resolve.
The example is entirely constructed and does not describe a real engagement.
Sources and technical basis
- Technical specification JSON Schema Draft 2020-12, used for structural and validation rules for JSON documents. Open source.
- W3C Recommendation SHACL Recommendation 2017, used as a reference for validating RDF graphs against defined shapes. Open source.
- Author methodology Sources and methodology of the knowledge base; structural validation is separated from substantive correctness and downstream impact.
Further reading
- Data as a Subject of Examination
- Technical Assessment of Data Quality
- Data Provenance, Lineage and Transformations
- Data Preparation, Missing Values and Outliers
Critical review and methodological limitation
Schema validation is strongest when the rule set, validator and data state are all versioned. A current schema cannot automatically validate the historical meaning of records created under an earlier contract.
Structural integrity is also narrower than correctness. A record may satisfy every declared constraint and still contain a wrong real-world value. The conclusion should state which type of integrity was actually tested.
- Model versus schema: compare intended relationships with the deployed implementation.
- Versioning: validate historical data against the relevant rule set rather than only the current schema.
- Impact: connect material violations to downstream behaviour where evidence supports the link.
Translation and methodological scope
This English article is based on the reviewed German V1 source article. The translation preserves the technical meaning, methodological distinctions, source status and stated limitations. It does not strengthen technical findings into legal conclusions and does not treat technical references as proof of compliance or suitability for a specific system.
Author's technical literature and publications
The following works provide additional technical and methodological context. They do not replace required primary sources, standards, manufacturer documentation or other independent specialist sources. Unpublished manuscripts, drafts and teaching materials are deliberately not presented here as public sources.
Data Science & AI Assessments
Technical examination of data quality, model validity, reproducibility, bias, robustness and documented AI-system behaviour.
Explore this assessment service