No More Posts Available.

No more pages to load.

    • Source: Referential integrity

      • Referential integrity is a property of data stating that all its references are valid. In the context of relational databases, it requires that if a value of one attribute (column) of a relation (table) references a value of another attribute (either in the same or a different relation), then the referenced value must exist.
      For referential integrity to hold in a relational database, any column in a base table that is declared a foreign key can only contain either null values or values from a parent table's primary key or a candidate key. In other words, when a foreign key value is used it must reference a valid, existing primary key in the parent table. For instance, deleting a record that contains a value referred to by a foreign key in another table would break referential integrity. Some relational database management systems (RDBMS) can enforce referential integrity, normally either by deleting the foreign key rows as well to maintain integrity, or by returning an error and not performing the delete. Which method is used may be determined by a referential integrity constraint defined in a data dictionary.
      The adjective 'referential' describes the action that a foreign key performs, 'referring' to a linked column in another table. In simple terms, 'referential integrity' guarantees that the target 'referred' to will be found. A lack of referential integrity in a database can lead relational databases to return incomplete data, usually with no indication of an error.


      Formalization


      An inclusion dependency over two (possibly identical) predicates



      R


      {\displaystyle R}

      and



      S


      {\displaystyle S}

      from a schema is written



      R
      [

      A

      1


      ,
      .
      .
      .
      ,

      A

      n


      ]
      ⊆
      S
      [

      B

      1


      ,
      .
      .
      .
      ,

      B

      n


      ]


      {\displaystyle R[A_{1},...,A_{n}]\subseteq S[B_{1},...,B_{n}]}

      , where the




      A

      i




      {\displaystyle A_{i}}

      ,




      B

      i




      {\displaystyle B_{i}}

      are distinct attributes (column names) of



      R


      {\displaystyle R}

      and



      S


      {\displaystyle S}

      . It implies that the tuples of values appearing in columns




      A

      1


      ,
      .
      .
      .
      ,

      A

      n




      {\displaystyle A_{1},...,A_{n}}

      for facts of



      R


      {\displaystyle R}

      must also appear as a tuple of values in columns




      B

      1


      ,
      .
      .
      .
      ,

      B

      n




      {\displaystyle B_{1},...,B_{n}}

      for some fact of



      S


      {\displaystyle S}

      .
      Such constraint is a particular form of tuple-generating dependency (TGD) where in both the sides of the rule there is only one relational atom. In first-order logic it is expressible as



      ∀



      x
      →



      ,



      y
      →



      .
      (
      R
      (



      x
      →



      ,



      y
      →



      )
      →
      ∃



      z
      →



      .
      S
      (



      x
      →



      ,



      z
      →



      )
      )


      {\displaystyle \forall {\vec {x}},{\vec {y}}.(R({\vec {x}},{\vec {y}})\rightarrow \exists {\vec {z}}.S({\vec {x}},{\vec {z}}))}

      , where






      x
      →





      {\displaystyle {\vec {x}}}

      is the vector (whose size is



      n


      {\displaystyle n}

      ) of variables shared by



      R


      {\displaystyle R}

      and



      S


      {\displaystyle S}

      , and no variable appears multiple times neither in the TGD's body nor in its head.
      Logical implication between inclusion dependencies can be axiomatized by inference rules: 193 
      and can be decided by a PSPACE algorithm. The problem can be shown to be PSPACE-complete by reduction from the acceptance problem for a linear bounded automaton.: 196  However, logical implication between dependencies that can be inclusion dependencies or functional dependencies is undecidable by reduction from the word problem for monoids.: 199 


      Declarative referential integrity


      Declarative referential integrity (DRI) is one of the techniques in the SQL database programming language to ensure data integrity.


      = Meaning in SQL

      =

      A table (called the referencing table) can refer to a column (or a group of columns) in another table (the referenced table) by using a foreign key. The referenced column(s) in the referenced table must be under a unique constraint, such as a primary key. Also, self-references are possible (not fully implemented in MS SQL Server though). On inserting a new row into the referencing table, the relational database management system (RDBMS) checks if the entered key value exists in the referenced table. If not, no insert is possible. It is also possible to specify DRI actions on UPDATE and DELETE, such as CASCADE (forwards a change/delete in the referenced table to the referencing tables), NO ACTION (if the specific row is referenced, changing the key is not allowed) or SET NULL / SET DEFAULT (a changed/deleted key in the referenced table results in setting the referencing values to NULL or to the DEFAULT value if one is specified).


      = Product-specific meaning

      =
      In Microsoft SQL Server the term DRI also applies to the assigning of permissions to users on a database object. Giving DRI permission to a database user allows them to add foreign key constraints on a table.


      See also


      Null pointer dereferencing
      Dangling pointer
      Data integrity
      Domain/key normal form
      Entity integrity
      Functional dependency
      Propagation constraint
      Surrogate key
      Slowly changing dimension


      References




      External links


      DRI versus Triggers (archived)

    Kata Kunci Pencarian: