Join dependency

In database theory, a join dependency is a constraint on the set of legal relations over a database scheme. A table is subject to a join dependency if can always be recreated by joining multiple tables each having a subset of the attributes of . If one of the tables in the join has all the attributes of the table , the join dependency is called trivial.

The join dependency plays an important role in the fifth normal form (5NF), also known as project-join normal form, because it can be proven that if a scheme is decomposed in tables to , the decomposition will be a lossless-join decomposition if the legal relations on are restricted to a join dependency on called .

Another way to describe a join dependency is to say that the relations in the join dependency are independent of each other.

Unlike in the case of functional dependencies, there is no sound and complete axiomatization for join dependencies,[1] though axiomatization exist for more expressive dependency languages such as full typed dependencies.[2]: Chapter 8  However, implication of join dependencies is decidable.[2]: Theorem 8.4.12 

Formal definition

Let be a relation schema and let be a decomposition of .

The relation satisfies the join dependency

if

A join dependency is trivial if one of the is itself.[3]

2-ary join dependencies are called multivalued dependency as a historical artifact of the fact that they were studied before the general case. More specifically if U is a set of attributes and R a relation over it, then R satisfies if and only if R satisfies

Example

Given a pizza-chain that models purchases in table Order = {order-number, customer-name, pizza-name, courier}. The following relations can be derived:

  • customer-name depends on order-number
  • pizza-name depends on order-number
  • courier depends on order-number

Since the relationships are independent there is a join dependency as follows: *((order-number, customer-name), (order-number, pizza-name), (order-number, courier)).

If each customer has his own courier however, there can be a join-dependency like this: *((order-number, customer-name), (order-number, pizza-name), (order-number, courier), (customer-name, courier)), but *((order-number, customer-name, courier), (order-number, pizza-name)) would be valid as well. This makes it obvious that just having a join dependency is not enough to normalize a database scheme.

See also

References

  1. ^ Petrov, S. V. (1989). "Finite axiomatization of languages for representation of system properties". Information Sciences. 47: 339–372. doi:10.1016/0020-0255(89)90006-6.
  2. ^ a b Abiteboul; Hull; Vianu (1995). Foundations of databases. Addison-Wesley. ISBN 9780201537710.
  3. ^ Silberschatz, Korth. Database System Concepts (1st ed.).

Content Disclaimer

Informasi ini disarikan dari Wikipedia dan disajikan kembali untuk tujuan edukasi. Konten tersedia di bawah lisensi CC BY-SA 3.0. Kami tidak bertanggung jawab atas ketidakakuratan data yang bersumber dari kontribusi publik tersebut.

  1. The information displayed on this website is sourced in part or in whole from Wikipedia and has been adapted for the purpose of restating it. We strive to provide accurate and relevant information, however:
  2. There is no guarantee of absolute accuracy. Wikipedia is an open, collaborative project that can be edited by anyone, so information is subject to change.
  3. It is not intended to constitute professional advice. The content displayed is for informational and educational purposes only. For important decisions (e.g., medical, legal, or financial), please consult a professional.
  4. Content copyright. Wikipedia is licensed under the Creative Commons Attribution-ShareAlike License (CC BY-SA). This means that content may be reused with appropriate attribution and shared under a similar license.
  5. Responsible use. Any risk arising from the use of information from this website is entirely the responsibility of the user.