Schema-Driven Relations

In POCO DataSet, relations are not a configuration feature. They are a derived fact. A relation is created when the system can prove that one table depends on another via key structure (foreign keys referencing primary or unique keys).

This design is intentional: it keeps POCO DataSet predictable, testable, and safe in disconnected workflows. Developers should not "author" relations in code. Instead, the system derives them from schema metadata and uses them to enforce integrity and produce deterministic ordering.

The core idea

Relations are part of the dataset's structure, not part of its workflow. They exist to answer questions like:

Which tables must be inserted first?
Which tables must be deleted last?
When multiple tables change together, what is the safe, deterministic save order?
Which "restrict" rules can be validated inside the dataset before saving?

Relations are not an object graph and are not a navigation feature. They are a structural guarantee that enables correct transitions.

Where relations come from

POCO DataSet does not invent relations. It reads them from authoritative schema sources:

EF Core bridge — relations are derived from the EF Core model metadata (primary keys, foreign keys, composite keys, and alternate keys such as HasPrincipalKey).
SQL Server Data Adapter — relations are derived from SQL Server schema (foreign keys, including composite foreign keys and FKs that reference unique keys).

Because the relation source is external and authoritative, POCO DataSet can be used as a neutral model that stays consistent across backends.

When relations are created

Relations are created only when POCO DataSet has enough information to do it safely. In practice, that means:

The dependent (child) table exists in the dataset.
The referenced (parent) table exists in the dataset.
The referenced key columns exist on the parent table.
The foreign key columns exist on the child table.
Composite keys are treated as ordered column lists.

When relations are removed

Relations are removed when the dataset no longer contains the tables required to maintain them safely. In practice, this currently means:

The dependent (child) table is removed from the dataset.
The referenced (parent) table is removed from the dataset.

Relations also require the corresponding parent and foreign key columns to remain valid. If schema changes remove those columns, the relation may become invalid and should be removed or recreated accordingly.

This implies an important rule for developers: If you load only a single table, relations may not exist — and POCO DataSet will not pretend they do.

What relations are used for

Deterministic ordering

When multiple tables contain changes (Added / Modified / Deleted rows), relations provide a stable ordering that prevents foreign key violations:

Insert order: parent tables first, then child tables
Delete order: child tables first, then parent tables
Update order: stable ordering based on dependencies

If a cycle exists in the schema (A depends on B and B depends on A), POCO DataSet does not guess. It falls back deterministically to a stable ordering rule rather than producing nondeterministic behavior.

Integrity validation (Restrict rules)

Relations are also used to validate integrity rules within a dataset before persistence. In SQL and EF bridge workflows, the intent is to support "restrict" semantics explicitly, without relying on cascade deletes.

In changeset workflows, POCO DataSet typically validates relation definitions and delete-restrict rules without performing "orphan checks" against the database, because a changeset may be sparse (PATCH payload).

Why relations are not copied into changesets

When a changeset is created from a dataset, relations are intentionally not copied into the changeset. This is by design.

A changeset represents state changes only — added, modified, or deleted rows — and is meant to behave like a PATCH payload. It is not a complete model snapshot and does not carry structural metadata.

Relations belong to the dataset structure, not to the changeset state.

Copying relations into a changeset would be misleading:

Relations might reference tables or columns that are not present in the delta.
They would suggest integrity guarantees that cannot be validated in isolation.
They would blur the boundary between structure and change.

Instead, the system itself determines the correct order for saving and deleting data, based on the database schema or the Entity Framework model.

This separation keeps changesets minimal, transport-safe, and backend-agnostic, while still allowing adapters to enforce correct ordering and integrity rules.

Developer responsibilities

Relations are automatic, but developers still have responsibility for loading and usage patterns.

What you should do

Load related tables into the same dataset when relation-aware behavior is needed.
Use the EF Core bridge or SQL adapter schema binding features to derive relations automatically.
Treat relations as structural facts that enable deterministic persistence.

What you should not do

Do not manually author relations as application configuration.
Do not treat relations as an object graph navigation model.
Do not rely on relations when only a subset of tables is loaded.
Do not assume cascade deletes; POCO DataSet is designed to work with restrict semantics.

A quick example

If your schema contains Department and Employee, and Employee has a foreign key referencing Department:

Load only Employee — no relation exists (parent table not present).
Load Department and Employee — relation exists and save ordering is deterministic.
Load incrementally — the relation appears once both tables exist in the dataset.

Table of Content POCO DataSet POCO DataSet Concepts

Business Process Programming in .Net
© 2004–2026 Laskarzhevsky Software Inc.
Unless otherwise noted, the content of this website is licensed under the Creative Commons Attribution 4.0 International License (CC BY 4.0).
Code examples are provided under the MIT License.
You are free to share and adapt the material provided that appropriate credit is given and any modifications are clearly indicated.
The information provided on this website is for educational purposes only.
The author and publisher make no warranties regarding the completeness or suitability of the information and are not responsible for any damages resulting from its use.