AI Glossary / Data governance and quality / Intermediate

Entity integrity

Definition

Entity integrity is the database principle that each row must have a dependable identity, commonly enforced through a primary key whose values are unique and non-null. A primary key can consist of one column or a combination of columns. For a composite primary key, no component may be null, and the complete combination must be unique. This identifies rows; it does not guarantee that every other stored fact is correct.

What it means

A database needs a reliable way to distinguish one represented occurrence from another. Names and descriptions often repeat, so they may not provide that identity. Entity integrity makes the chosen row identifier explicit and prevents certain ambiguous or missing identifiers. It differs from referential integrity, which concerns relationships between rows through foreign keys. Both are useful, but neither automatically resolves real-world duplicate people, mislabeled records, or an incorrectly chosen business key.

How it works

Determine what one row represents, identify suitable candidate keys, and select a primary key. Define the corresponding enforced constraints in the database. The system then checks relevant inserts and updates for missing key components and duplicate complete key values. For a composite key, test combinations rather than demanding that each component be individually unique. Keep business-level uniqueness rules separate when a generated surrogate key is used. Review actual enforcement because some analytical systems support declarations that are informational rather than enforced.

Three practical examples

• Orders: an order identifier distinguishes individual orders even when customer, date, and amount happen to match.
• Enrollments: a student-and-course combination identifies an enrollment under a rule that allows only one enrollment per pair.
• AI evaluation: an example-version identifier distinguishes dataset records so labels and predictions can be connected to the intended version rather than a similarly named item.

Think of it this way

Think of numbered claim tickets at a collection desk. Every claim needs a usable ticket number, and two active claims must not accidentally share the same number under the desk's scheme. The analogy is limited because database keys may combine several fields, apply within a defined table or scope, and identify records without proving that those records represent distinct real-world people.

Worked example

In an original toy Enrollment table, the primary key is (StudentID, CourseID). Rows (S1, C1), (S1, C2), and (S2, C1) are valid: StudentID and CourseID each repeat, but every pair is different. A second (S1, C1) violates the key's uniqueness. A row (S3, null) also violates the primary-key requirement because one component is missing. Whether C2 refers to an existing course is a separate referential-integrity question. If repeated enrollment across academic years is valid, the original key may be too narrow; the row definition and key need to account for that additional distinction rather than rejecting legitimate business events.

Illustrative case study

Fictional example: Elm Evaluation gives each imported example a new generated ID. The primary key remains unique, but the same source item is imported twice under two different IDs. The team adds a separately defined source-item-and-version uniqueness rule where the project requires it. This invented case shows that a technically valid surrogate key does not, by itself, prevent every business duplicate or establish correct dataset membership.

Common misconceptions and mistakes

Do not assume every column in a composite primary key must be unique individually. Do not use a default empty string as a substitute for understanding a missing identity. Do not confuse a primary key with a foreign key, and do not claim that all foreign keys must always be non-null. A row's unique identifier also does not make its measurements accurate. Finally, databases may permit tables without a declared primary key; the existence of a table does not prove that this integrity principle has been enforced.

Business use

Reliable row identity supports updates, reconciliation, audit trails, and stable relationships between records. In AI workflows, it helps connect predictions, labels, and review decisions without relying on display order. Agree on the meaning and scope of identifiers before integration, including whether versions and repeated events need distinct rows. Combine key constraints with appropriate business uniqueness checks and referential rules. When consolidating data from several sources, preserve source identity so that identical local IDs do not accidentally become one global entity.

People also ask

Can a primary key contain several columns?

Yes. The combination must be unique, and every component must be non-null.

Does a unique generated ID eliminate duplicate customers?

No. Two records for the same customer can receive different generated IDs.

Is entity integrity the same as referential integrity?

No. The first concerns row identity; the second concerns valid relationships between referenced and referencing records.

Check your understanding

A key consists of ProjectID and ItemID. Two rows share ProjectID but have different ItemIDs. Is that necessarily a violation?

Answer: No. The complete key combinations differ. A violation occurs if the same combination repeats or a primary-key component is null.

Related terms

• Primary key
• Candidate key
• Composite key
• Surrogate key
• Referential integrity
• unique constraint
• entity resolution

Learn next

define the grain of a small table in one sentence, such as one row per item per version. Propose a key and test repeated events, missing identifiers, and imports from multiple sources. Then identify which additional business rules are necessary beyond uniqueness and non-null key values.

More in Data governance and quality

• Discretionary access control - Discretionary access control, or DAC, is an approach in which an object's owner or another authorized controller has some discretion to decide who can...
• Doxing - Doxing, also spelled doxxing, is the deliberate online exposure of someone's identity or personal information without their consent, typically to enable...
• Electronic seal - An electronic seal is electronic data associated with other electronic information to support verification of its origin and integrity.
• Extrusion detection - Extrusion detection is a security-monitoring perspective that looks for harmful activity originating inside a system or network, especially through outgoing...
• Firewall (computing) - A firewall is a device, program, or service that controls network traffic according to a defined security policy.
• Guard (information security) - In information security, a guard is a trusted system or mechanism that mediates information transfer between systems operating under different security...

Sources

Sources: IBM, Entity integrity, https://www.ibm.com/docs/en/informix-servers/12.10.0?topic=integrity-entity ; IBM, Constraining column data, https://www.ibm.com/docs/en/ias?topic=concepts-constraining-column-data-constraints-defaults-null-settings ; PostgreSQL 18, Constraints, https://www.postgresql.org/docs/18/ddl-constraints.html ; IBM Db2, Informational constraints, https://www.ibm.com/docs/en/db2/12.1.x?topic=constraints-informational . Relevant official excerpts were consulted for entity identity, primary-key requirements, and the distinction between declared and enforced constraints. Examples and case are original. Product-specific behavior should be checked for the deployment in use.

Previous: Entity grid Next: Entity linking