Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Foreign key
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== 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.<ref>{{cite book|last=Sheldon|first=Robert|title=Beginning MySQL|year=2005|publisher=John Wiley & Sons|isbn=0-7645-7950-9|pages=119β122}}</ref> 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. The value or combination of values of candidate key attributes for any tuple cannot be duplicated for any other tuple in that relation. 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 (SQL)|NULL]] value.<ref name=elmasri />). This rule is called a [[referential integrity|referential integrity constraint]] between the two tables.<ref>{{Cite web | url = http://www.visualcase.com/kbase/database_basics_-_foreign_keys.htm | title = Database Basics β Foreign Keys | access-date = 2010-03-13 }}</ref> Because violations of these constraints can be the source of many database problems, most [[database management systems]] provide mechanisms to ensure that every non-null foreign key corresponds to a row of the referenced table.<ref>{{cite book|last=MySQL AB|title=MySQL Administrator's Guide and Language Reference|year=2006|publisher=Sams Publishing|isbn=0-672-32870-4|page=40}}</ref><ref>{{cite book|last=Powell|first=Gavin|title=Oracle SQL: Jumpstart with Examples|url=https://archive.org/details/oraclesqljumpsta00powe|url-access=limited|year=2004|publisher=Elsevier|asin= B008IU3AHY|page=[https://archive.org/details/oraclesqljumpsta00powe/page/n41 11]}}</ref><ref>{{cite book|last=Mullins|first=Craig|title=DB2 developer's guide|year=2012|publisher=IBM Press|asin=B007Y6K9TK}}</ref> 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. Suppose the business requires that each order must refer to a single customer. 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. ID). Because the primary key of a table must be unique, and because CUSTOMERID only contains values from that primary key field, we may assume that, when it has a value, CUSTOMERID will identify the particular customer which placed the order. 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. 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. Foreign keys play an essential role in [[database design]]. 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.<ref>{{cite book|last=Sheldon|first=Robert|title=Beginning MySQL|year=2005|publisher=John Wiley & Sons|isbn=0-7645-7950-9|page=156}}</ref> Another important part of database design is [[database normalization]], in which tables are broken apart and foreign keys make it possible for them to be reconstructed.<ref>{{cite book|last=Garcia-Molina|first=Hector|title=Database Systems: The Complete Book|url=https://archive.org/details/databasesystemsc0000_2ndedgarc|url-access=registration|year=2009|publisher=Prentice Hall|isbn=978-0-13-187325-4|pages=[https://archive.org/details/databasesystemsc0000_2ndedgarc/page/93 93]β95}}</ref> Multiple rows in the referencing (or child) table may refer to the same row in the referenced (or parent) table. In this case, the relationship between the two tables is called a [[Cardinality (data modeling)|one to many relationship]] between the referencing table and the referenced table. In addition, the child and parent table may, in fact, be the same table, i.e. the foreign key refers back to the same table. Such a foreign key is known in [[SQL:2003]] as a self-referencing or recursive foreign key. In database management systems, this is often accomplished by linking a first and second reference to the same table. A table may have multiple foreign keys, and each foreign key can have a different parent table. Each foreign key is enforced independently by the [[database system]]. Therefore, cascading relationships between tables can be established using foreign keys. A foreign key is defined as an attribute or set of attributes in a relation whose values match a primary key in another relation. The syntax to add such a constraint to an existing table is defined in [[SQL:2003]] as shown below. Omitting the column list in the <code>REFERENCES</code> clause implies that the foreign key shall reference the primary key of the referenced table. Likewise, foreign keys can be defined as part of the <code>CREATE TABLE</code> SQL statement. <syntaxhighlight lang="sql"> CREATE TABLE child_table ( col1 INTEGER PRIMARY KEY, col2 CHARACTER VARYING(20), col3 INTEGER, col4 INTEGER, FOREIGN KEY(col3, col4) REFERENCES parent_table(col1, col2) ON DELETE CASCADE ) </syntaxhighlight> If the foreign key is a single column only, the column can be marked as such using the following syntax: <syntaxhighlight lang="sql"> CREATE TABLE child_table ( col1 INTEGER PRIMARY KEY, col2 CHARACTER VARYING(20), col3 INTEGER, col4 INTEGER REFERENCES parent_table(col1) ON DELETE CASCADE ) </syntaxhighlight> Foreign keys can be defined with a [[stored procedure]] statement. <syntaxhighlight lang="sql"> sp_foreignkey child_table, parent_table, col3, col4 </syntaxhighlight> * '''child_table''': the name of the table or view that contains the foreign key to be defined. * '''parent_table''': the name of the table or view that has the primary key to which the foreign key applies. The primary key must already be defined. * '''col3''' and '''col4''': the name of the columns that make up the foreign key. The foreign key must have at least one column and at most eight columns.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)