Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Superkey concept. A unique key comprises a single column or a set of columns. No two distinct rows in a table can have the same value (or combination of values) in those columns if NULL values are not used. Depending on its design, a table may have arbitrarily many unique keys but at most one primary key. Unique keys do not enforce the NOT NULL constraint in practice. Because NULL is not an actual value (it represents the lack of a value), when two rows are compared, and both rows have NULL in a column, the column values are not considered to be equal. Thus, in order for a unique key to uniquely identify each row in a table, NULL values must not be used. According to the SQL[1] standard and Relational Model theory, a unique key (unique constraint) should accept NULL in several rows/tuples however not all RDBMS implement this feature correctly[2][3]. A unique key should uniquely identify all possible rows that exist in a table and not only the currently existing rows. Examples of unique keys are Social Security numbers (associated with a specific person[4]) or ISBNs (associated with a specific book). Telephone books and dictionaries cannot use names, words, or Dewey Decimal system numbers as candidate keys because they do not uniquely identify telephone numbers or words. A table can have at most one primary key, but more than one unique key. A primary key is a combination of columns which uniquely specify a row. It is a special case of unique keys. One difference is that primary keys have an implicit NOT NULL constraint while unique keys do not. Thus, the values in unique key columns may or may not be NULL, and in fact such a column may contain at most one NULL fields.[5] Another difference is that primary keys must be defined using another syntax. The relational model, as expressed through relational calculus and relational algebra, does not distinguish between primary keys and other kinds of keys. Primary keys were added to the SQL standard mainly as a convenience to the application programmer. Unique keys as well as primary keys can be referenced by foreign keys.
Contents
[hide]
1 Defining primary keys 2 Defining unique keys 3 Surrogate keys 4 Alternate key 5 Notes 6 External links 7 See also
The primary key can also be specified directly during table creation. In the SQL Standard, primary keys may consist of one or multiple columns. Each column participating in the primary key is implicitly defined as NOT NULL. Note that some DBMS require explicitly marking primary-key columns as NOT NULL.
CREATE TABLE TABLE_NAME ( id_col INT, col2 CHARACTER VARYING(20), ... CONSTRAINT tab_pk PRIMARY KEY(id_col), ... )
If the primary key consists only of a single column, the column can be marked as such using the following syntax:
CREATE TABLE TABLE_NAME ( id_col INT PRIMARY KEY, col2 CHARACTER VARYING(20), ... )
Likewise, unique keys can be defined as part of the CREATE TABLE SQL statement.
CREATE TABLE TABLE_NAME ( id_col INT, col2 CHARACTER VARYING(20), key_col SMALLINT, ... CONSTRAINT key_unique UNIQUE(key_col), ... ) CREATE TABLE TABLE_NAME (
id_col INT PRIMARY KEY, col2 CHARACTER VARYING(20), ... key_col SMALLINT UNIQUE, ... )
A primary key uniquely defines a relationship within a database. In order for an attribute to be a good primary key it must not repeat. While natural attributes are sometimes good primary keys, surrogate keys are often used instead. A surrogate key is an artificial attribute assigned to an object which uniquely identifies it (for instance, in a table of information about students at a school they might all be assigned a student ID in order to differentiate them). The surrogate key has no intrinsic (inherent) meaning, but rather is useful through its ability to uniquely identify a tuple. Another common occurrence, especially in regards to N:M cardinality is the composite key. A composite key is a key made up of two or more attributes within a table that (together) uniquely identify a record. (For example, in a database relating students, teachers, and classes. Classes could be uniquely identified by a composite key of their room number and time slot, since no other class could have exactly the same combination of attributes. In fact, use of a composite key such as this can be a form of data verification, albeit a weak one.)
[edit] Foreign key Main article: Foreign key
A foreign key is a reference to a key in another relation, meaning that the referencing table has, as one of its attributes, the values of a key in the referenced table. Foreign keys need not have unique values in the referencing relation. Foreign keys effectively use the values of attributes in the referenced relation to restrict the domain of one or more attributes in the referencing relation. A foreign key could be described formally as: "For all tuples in the referencing relation projected over the referencing attributes, there must exist a tuple in the referenced relation projected over those same attributes such that the values in each of the referencing attributes match the corresponding values in the referenced attributes."
fields. A surrogate key can be used as the primary key. In other situations there may be more than one candidate key for a relation, and no candidate key is obviously preferred. A surrogate key may be used as the primary key to avoid giving one candidate key artificial primacy over the others. Since primary keys exist primarily as a convenience to the programmer, surrogate primary keys are often usedin many cases exclusivelyin database application design. Due to the popularity of surrogate primary keys, many developers and in some cases even theoreticians have come to regard surrogate primary keys as an inalienable part of the relational data model. This is largely due to a migration of principles from the Object-Oriented Programming model to the relational model, creating the hybrid object-relational model. In the ORM, these additional restrictions are placed on primary keys:
Primary keys should be immutable, that is, not changed until the record is destroyed. Primary keys should be anonymous integer or numeric identifiers.
However, neither of these restrictions is part of the relational model or any SQL standard. Due diligence should be applied when deciding on the immutability of primary key values during database and application design. Some database systems even imply that values in primary key columns cannot be changed using the UPDATE SQL statement[citation needed].
[edit] Notes
Relation universe A relation universe U over a header H is a non-empty set of relations with header H. Relation schema A relation schema (H,C) consists of a header H and a predicate C(R) that is defined for all relations R with header H. A relation satisfies a relation schema (H,C) if it has header H and satisfies C.
One of the simplest and most important types of relation constraints is the key constraint. It tells us that in every instance of a certain relational schema the tuples can be identified by their values for certain attributes.
Superkey A superkey is written as a finite set of attribute names. A superkey K holds in a relation (H,B) if:
A superkey holds in a relation universe U if it holds in all relations in U. Theorem: A superkey K holds in a relation universe U over H if and only if holds in U. Candidate key A superkey K holds as a candidate key for a relation universe U if it holds as a superkey for U and there is no proper subset of K that also holds as a superkey for U. Functional dependency A functional dependency (FD for short) is written as names. A functional dependency
and
A functional dependency is trivial under a header H if it holds in all relation universes over H. Theorem: An FD Closure Armstrong's axioms: The closure of a set of FDs S under a header H, written as S + , is the smallest superset of S such that: is trivial under a header H if and only if .
Theorem: Armstrong's axioms are sound and complete; given a header H and a set S of FDs that only contain subsets of H, universes over H in which all FDs in S hold. Completion if and only if holds in all relation
The completion of a finite set of attributes X under a finite set of FDs S, written as X + , is the smallest superset of X such that:
The completion of an attribute set can be used to compute if a certain dependency is in the closure of a set of FDs. Theorem: Given a set S of FDs, Irreducible cover An irreducible cover of a set S of FDs is a set T of FDs such that:
if and only if