Relation (database)
concept in relational database theory
In database theory, a relation, as originally defined by E. F. Codd, is a set of tuples (d1,d2,...,dn), where each element dj is a member of Dj, a data domain. Codd's original definition notwithstanding, and contrary to the usual definition in mathematics, there is no ordering to the elements of the tuples of a relation. Instead, each element is termed an attribute value. An attribute is a name paired with a domain (nowadays more commonly referred to as a type or data type). An attribute value is an attribute name paired with an element of that attribute's domain, and a tuple is a set of attribute values in which no two distinct elements have the same name. Thus, in some accounts, a tuple is described as a function, mapping names to values.
A set of attributes in which no two distinct elements have the same name is called a heading. It follows from the above definitions that to every tuple there corresponds a unique heading, being the set of names from the tuple, paired with the domains from which the tuple elements' domains are taken. A set of tuples that all correspond to the same heading is called a body. A relation is thus a heading paired with a body, the heading of the relation being also the heading of each tuple in its body.
The public source identifies “Relation (database)” as concept in relational database theory. This brief keeps that definition visible, then builds a research path around Relation, database and concept.
Why this record matters
A short description can identify a subject without explaining its stakes. For “Relation (database)”, the useful work is to connect “concept in relational database theory” to the records capable of establishing context and consequence.
Named sources, stable identifiers and responsible institutions provide the strongest route from overview to verifiable evidence. The source revision retrieved here is dated Sep 11, 2026. The linked authority identifier is Q277521. None of the 0 selected statements returned an explicit reference.
Overview language is designed for orientation and should not be treated as a substitute for the evidence cited beneath it. The lead is largely declarative, so disagreement and counter-evidence require a deliberate search beyond the opening account. Authority statements aid reconciliation but still require their own references, qualifiers and ranks to be checked.
How to read it
Use the entry as an orientation point, then follow its citations and revision history. Names, dates and institutional relationships should be checked against the original record.
- Subject orientation
- Search vocabulary
- Locating named sources
The closest primary source, responsible institution and strongest cited specialist reference.
Three-step research path
- Establish the record: confirm the title “Relation (database)”, its source revision and the description used here.
- Expand the search: follow Relation (database) primary sources, Relation (database) archive and Relation research across catalogues and specialist indexes.
- Test the account: compare the strongest cited source with the responsible institution’s current record and note any disagreement.
Questions for further research
- Which source most directly establishes the central claim about “Relation (database)”?
- What terminology or title could unlock a more precise catalogue search?
- Which institution is responsible for the underlying evidence?
Search terms from this dossier
This entry incorporates text from “Relation (database)” on English Wikipedia. Contributors are listed in the page history. Text is available under the Creative Commons Attribution-ShareAlike 4.0 License. Selected authority identifiers and statements are retrieved from Wikidata under CC0; their references and qualifiers remain part of the verification path.