Skip to content

Foreign key

A foreign key is a set of attributes in a table that refers to the primary key of another table, linking these two tables.

Core Idea

Foreign key is treated here as the recurring relational databases identity summarized by this source-grounded definition: A foreign key is a set of attributes in a table that refers to the primary key of another table, linking these two tables.

A foreign key is a set of attributes in a table that refers to the primary key of another table, linking these two tables. In the context of relational databases, a foreign key is subject to an inclusion dependency constraint that the tuples consisting of the foreign key attributes in one relation, R, must also exist in some other (not necessarily distinct) relation, S; furthermore that those attributes must also be a candidate key in S. In other words, a foreign key is a set of attributes that a candidate key.

For example, a table called TEAM may have an attribute, MEMBER_NAME, which is a foreign key referencing a candidate key, PERSON_NAME, in the PERSON table. Since MEMBER_NAME is a foreign key, any value existing as the name of a member in TEAM must also exist as a person's name in the PERSON table; in other words, every member of a TEAM is also a PERSON. In database relational modeling and implementation, a candidate key is a set of zero or more attributes, the values of which are guaranteed to be unique for each tuple (row) in a relation.

For Foreign key, the abstraction is narrower than the article's general subject matter: a positive case must preserve A foreign key is a set of attributes in a table that refers to the primary key of another table, linking these two tables. Retaining only the name, a familiar example, or a downstream effect is insufficient. The specialist roles and tests remain anchored in relational databases, which is why this identity is domain-specific rather than prime.

Structural Signature

Sig role-phrases:

  • Defining carrier — Suppose the business requires that each order must refer to a single customer.
  • Constitutive relation — Many real world databases work around this problem by 'inactivating' rather than physically deleting master table foreign keys, or by complex update programs that modify all references to a foreign key when a change is needed.
  • Operating condition — One important part of database design is making sure that relationships between real-world entities are reflected in the database by references, using foreign keys to refer from one table to another.
  • Recognition evidence — In database management systems, this is often accomplished by linking a first and second reference to the same table.
  • Admissible variation — Using NO ACTION, the triggers or the semantics of the statement itself may yield an end state in which no foreign key relationships are violated by the time the constraint is finally checked, thus allowing the statement to complete successfully.
  • Characteristic consequence — Another important limitation appears with transaction isolation: your changes to a row may not be able to fully cascade because the row is referenced by data your transaction cannot "see", and therefore cannot cascade onto.
  • Failure boundary — Each foreign key is enforced independently by the database system.

What It Is Not

  • Not the whole field of relational databases. The node requires the specific identity stated by A foreign key is a set of attributes in a table that refers to the primary key of another table, linking these two tables.
  • Not an over-broad reading. However, this can no longer be assumed if the ORDER table is not kept up to date when rows of the CUSTOMER table are deleted or the ID column altered, and working with these tables may become more difficult.
  • Not an over-broad reading. However, the referential action RESTRICT modifies the "behavior" of the master table, not the child table, although the word RESTRICT appears in the child table and not in the master table!
  • Not an over-broad reading. Many real world databases work around this problem by 'inactivating' rather than physically deleting master table foreign keys, or by complex update programs that modify all references to a foreign key when a change is needed.
  • Not automatically One-to-many (data model). Retrieval proximity does not establish equivalence; the two identities must be compared by carrier, operation, and failure boundary.

Scope of Application

Foreign key applies literally inside relational databases wherever the source-defined carrier and relation can be established. Its documented habitats include:

  • RESTRICT. The referential action CASCADE modifies the "behavior" of the (child) table itself where the word CASCADE is used.
  • Summary. Since the purpose of the foreign key is to identify a particular row of referenced table, it is generally required that the foreign key is equal to the candidate key in some row of the primary table, or else have no value (the NULL value. ).
  • Summary. The table containing the foreign key is called the child table, and the table containing the candidate key is called the referenced or parent table.
  • Summary. In database relational modeling and implementation, a candidate key is a set of zero or more attributes, the values of which are guaranteed to be unique for each tuple (row) in a relation.
  • Summary. The value or combination of values of candidate key attributes for any tuple cannot be duplicated for any other tuple in that relation.
  • Summary. This rule is called a referential integrity constraint between the two tables.

Outside relational databases, the name should be retained only when these same operational conditions survive; otherwise the comparison belongs to the broader parent Pattern or should be marked as analogy.

Clarity

A clear use of Foreign key names the carrier, the operative relation, and the conditions under which the source treats the identity as present. The minimal definition is A foreign key is a set of attributes in a table that refers to the primary key of another table, linking these two tables. The strongest recognition evidence in the frozen account is: In database management systems, this is often accomplished by linking a first and second reference to the same table. A report should distinguish that evidence from a proxy, consequence, or common implementation. It should also state the qualification However, this can no longer be assumed if the ORDER table is not kept up to date when rows of the CUSTOMER table are deleted or the ID column altered, and working with these tables may become more difficult. so that a reader can reproduce the classification rather than infer it from topical resemblance.

Manages Complexity

Foreign key compresses multiple relational databases details into a stable diagnostic relation. The source shows both the central mechanism—many real world databases work around this problem by 'inactivating' rather than physically deleting master table foreign keys, or by complex update programs that modify all references to a foreign key when a change is needed.—and the practical consequence—another important limitation appears with transaction isolation: your changes to a row may not be able to fully cascade because the row is referenced by data your transaction cannot "see", and therefore cannot cascade onto. This compression makes cases comparable while leaving parameters, conventions, exceptions, and evidential quality explicit. It is lossy by design: local history and implementation details may be omitted only when they do not alter the defining relation.

Abstract Reasoning

  1. Type the carrier. Identify the relational databases entities to which the claim applies.
  2. State the relation. Use the source-grounded identity: A foreign key is a set of attributes in a table that refers to the primary key of another table, linking these two tables.
  3. Check operation and conditions. One important part of database design is making sure that relationships between real-world entities are reflected in the database by references, using foreign keys to refer from one table to another.
  4. Demand recognition evidence. In database management systems, this is often accomplished by linking a first and second reference to the same table.
  5. Test variation. Change an implementation or setting while preserving using NO ACTION, the triggers or the semantics of the statement itself may yield an end state in which no foreign key relationships are violated by the time the constraint is finally checked, thus allowing the statement to complete successfully.
  6. Run the collapse test. Remove the defining operation; if the label still seems equally apt, only a topic or correlate was retained.
  7. Reduce cautiously. When the specialist conditions cannot be carried, route the residual comparison to Pattern.

Knowledge Transfer

Within the home domain. Knowledge about Foreign key transfers literally when a new case preserves the same carrier type, relation, and recognition test. The referential action CASCADE modifies the "behavior" of the (child) table itself where the word CASCADE is used. Since the purpose of the foreign key is to identify a particular row of referenced table, it is generally required that the foreign key is equal to the candidate key in some row of the primary table, or else have no value (the NULL value. ).

Beyond the home domain. No canonical parent is asserted for Foreign key. An outside case receives the specialist name only when the same typed roles and rejection conditions can be filled literally; otherwise the comparison remains an analogy pending later graph densification.

Examples

Canonical

For example, consider a database with two tables: a CUSTOMER table that includes all customer data and an ORDER table that includes all customer orders. This case is canonical because it supplies a concrete carrier and lets the defining relation be checked rather than merely named.

Mapped back: carrier → the entities in the documented case; operation → A foreign key is a set of attributes in a table that refers to the primary key of another table, linking these two tables; recognition evidence → In database management systems, this is often accomplished by linking a first and second reference to the same table

Applied / In Practice

To reflect this in the database, a foreign key column is added to the ORDER table (e.g., CUSTOMERID), which references the primary key of CUSTOMER (e.g. The applied case shows how the identity is used under a second setting or qualification while keeping the same operative relation.

Mapped back: changed setting → Summary; invariant → A foreign key is a set of attributes in a table that refers to the primary key of another table, linking these two tables; boundary → the case exits the class when however, this can no longer be assumed if the ORDER table is not kept up to date when rows of the CUSTOMER table are deleted or the ID column altered, and working with these tables may become more difficult

Structural Tensions

T1 — Stable identity versus admissible variation. However, this can no longer be assumed if the ORDER table is not kept up to date when rows of the CUSTOMER table are deleted or the ID column altered, and working with these tables may become more difficult. The tension matters because emphasizing only one side either dissolves the identity or overstates what the evidence and domain conventions warrant.

Diagnostic: Which changes preserve the defining relation, and which replace it?

T2 — Recognition versus proxy. However, the referential action RESTRICT modifies the "behavior" of the master table, not the child table, although the word RESTRICT appears in the child table and not in the master table! The tension matters because emphasizing only one side either dissolves the identity or overstates what the evidence and domain conventions warrant.

Diagnostic: Does the cited evidence establish the identity or only a correlated sign?

T3 — Definition versus implementation. Many real world databases work around this problem by 'inactivating' rather than physically deleting master table foreign keys, or by complex update programs that modify all references to a foreign key when a change is needed. The tension matters because emphasizing only one side either dissolves the identity or overstates what the evidence and domain conventions warrant.

Diagnostic: Is the observed implementation constitutive, optional, or merely common?

T4 — Scope versus overextension. A table may have multiple foreign keys, and each foreign key can have a different parent table. The tension matters because emphasizing only one side either dissolves the identity or overstates what the evidence and domain conventions warrant.

Diagnostic: Can every claimed application fill the same typed roles without metaphor?

T5 — Transfer versus domain accent. Suppose the business requires that each order must refer to a single customer. The tension matters because emphasizing only one side either dissolves the identity or overstates what the evidence and domain conventions warrant.

Diagnostic: Does the receiving case instantiate Foreign key literally, co-instantiate Pattern, or only resemble it?

T6 — Autonomy versus reduction. Many real world databases work around this problem by 'inactivating' rather than physically deleting master table foreign keys, or by complex update programs that modify all references to a foreign key when a change is needed. The tension matters because emphasizing only one side either dissolves the identity or overstates what the evidence and domain conventions warrant.

Diagnostic: What does Foreign key distinguish that the broader parent Pattern leaves together?

Structural–Framed Character

Foreign key is mixed or framed-leaning. Its structural side is the repeatable organization summarized by A foreign key is a set of attributes in a table that refers to the primary key of another table, linking these two tables. Its framed side is the relational databases vocabulary that fixes the carrier, evidence, exceptions, and admissible transformations.

Evaluative weight: the identity can be stated descriptively even when applications carry practical stakes. Human-practice dependence: the source-grounded carrier determines whether the relation exists independently or is constituted by a practice. Institutional origin: disciplinary conventions stabilize the name and test. Vocabulary portability: One important part of database design is making sure that relationships between real-world entities are reflected in the database by references, using foreign keys to refer from one table to another. Import versus recognition: literal transfer requires the same mechanism; shape alone is analogy.

Its portable skeleton is Pattern. Its character: a recurring specialist identity whose thin organization can be abstracted, while its operational meaning remains domain-bound.

Structural Core vs. Domain Accent

What is skeletal. A foreign key is a set of attributes in a table that refers to the primary key of another table, linking these two tables. The stable skeleton is the typed relation expressed in that definition and the entry's recognition and collapse tests. The source identifies these operative conditions: Suppose the business requires that each order must refer to a single customer. Many real world databases work around this problem by 'inactivating' rather than physically deleting master table foreign keys, or by complex update programs that modify all references to a foreign key when a change is needed. It further constrains recognition and variation through: One important part of database design is making sure that relationships between real-world entities are reflected in the database by references, using foreign keys to refer from one table to another. In database management systems, this is often accomplished by linking a first and second reference to the same table.

What is domain-bound. relational databases supplies the operative entities, technical vocabulary, warrants, and exceptions that make Foreign key literal. Its documented scope includes the condition that The referential action CASCADE modifies the "behavior" of the (child) table itself where the word CASCADE is used. Another bounded application condition is that Since the purpose of the foreign key is to identify a particular row of referenced table, it is generally required that the foreign key is equal to the candidate key in some row of the primary table, or else have no value (the NULL value. ). These are not decorative examples; they determine which carrier and evidence can fill the abstraction's roles.

Why no parent is asserted. Removing those specialist details does not currently yield one live catalog node that is a necessary genus for every instance. The entry is therefore approved as unparented rather than attached by topical resemblance. Its collapse evidence remains specific—Using NO ACTION, the triggers or the semantics of the statement itself may yield an end state in which no foreign key relationships are violated by the time the constraint is finally checked, thus allowing the statement to complete successfully.—and future graph densification may discover a defensible relation only if it preserves that boundary.

  • Approved unparented node. No current live node supplies a defensible necessary genus or structural prerequisite for Foreign key. The reviewed identity is: A foreign key is a set of attributes in a table that refers to the primary key of another table, linking these two tables. The accelerated suggestion was declined because topical or lexical similarity does not establish hierarchy; the node is admitted without a parent pending later graph densification.
  • Related reasoning operations. Evidence, representation, comparison, classification, transformation, or evaluation may participate in particular cases, but participation does not make any one of them a necessary parent of every instance.

Neighborhood in Abstraction Space

Foreign key sits in a crowded region of the domain-specific corpus (38th percentile for distinctiveness): several abstractions share nearly its structure, so a description that fits it tends to fit its neighbors too.

Family — Unclustered & Miscellaneous (2551 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-08

Not to Be Confused With

  • Pattern. The parent omits the specialist differentia. Tell: Can the case establish A foreign key is a set of attributes in a table that refers to the primary key of another table, linking these two tables?
  • One-to-many (data model). A relationship cardinality in which one parent entity may relate to multiple child entities while each child participates with at most one parent in that relationship, commonly enforced by a child-side foreign key. Tell: Which entry's carrier, operation, and failure condition are satisfied?
  • Relational database. A database that represents data as relations of tuples and attributes governed by keys, constraints, and relational operations. Tell: Which entry's carrier, operation, and failure condition are satisfied?
  • Row (database). A tuple in a relational table containing one value for each attribute under the table's heading and representing one occurrence of the table's relation. Tell: Which entry's carrier, operation, and failure condition are satisfied?
  • A measurement, proxy, or consequence. Those may provide evidence without being the identity. Tell: Would Foreign key remain present if the detector or downstream effect changed?
  • A metaphorical analogue. A similar shape outside relational databases lacks the specialist mechanism. Tell: Do the native roles transfer literally, or only the parent Pattern?

References

  • Frozen Wikipedia discovery revision: https://en.wikipedia.org/wiki/Foreign_key (revision 1270418735).
  • Preserved source candidate: https://archive.org/details/fundamentalsdata00elma
  • Preserved source candidate: https://archive.org/details/fundamentalsdata00elma/page/n101
  • Preserved source candidate: http://www.visualcase.com/kbase/database_basics_-_foreign_keys.htm
  • Preserved source candidate: https://archive.org/details/oraclesqljumpsta00powe
  • Preserved source candidate: https://archive.org/details/oraclesqljumpsta00powe/page/n41
  • Preserved source candidate: https://archive.org/details/databasesystemsc0000_2ndedgarc
  • Preserved source candidate: https://archive.org/details/databasesystemsc0000_2ndedgarc/page/93
  • Preserved source candidate: https://mariadb.com/kb/en/library/foreign-keys/

The frozen Wikipedia revision is discovery provenance. The retained source set was reviewed for identity, formal or operational relation, and scope. The encyclopedia's structural synthesis is bounded to those claims; a thin authority surface is recorded as a nonblocking source-strengthening repair rather than concealed.