*Keys of Relations*

On May 20, 2013, In The Relational Data Model by Admin

Views (1732)

We say a set of one or more attributes {A_{1}, A_{2},. . . ,A_{n}} is a key for a relation R if:

1. Those attributes functionally determine all other attributes of the relation. That is, because relations are sets, it is impossible for two different tuples of R to agree on all of A_{1}, A_{2}, ... ,A_{n}.

2. No proper subset of {A

_{1}, A

_{2},,...., A

_{n}} functionally determines all other attributes of R; i.e., a key must be minimal.

When a key consists of a single attribute A, we often say that A (rather than {A}) is a key.

**Example :**Attributes { title, year, starName} form a key for the relation Movies of figure 2 of "Functional Dependencies". First, we must show that they functionally determine all the other attributes. That is, suppose two tuples agree on these three attributes: title, year, and starName. Because they agree on title and year, they must agree on the other attributes - length, filmType, and studioName - as we discussed in "Functional Dependencies" example. Therefore two different tuples cannot agree on all of title, year, and starName; they would in fact be the same tuple.

Now, we must argue that no proper subset of {title, year, starName} functionally decides all other attributes. To see why, begin by observing that title and year do not decide starName, because many movies have more than one star. Thus, {title, year} is not a key.

{year, starName} is not a key because we could have a star in two movies In the same year; therefore

year starName → title

is not a FD. Also, we claim that {title, starName} is not a key, because two movies with the same title, made in different years, rarely have a star in common.

Often a relation has more than one key. If so, it is common to designate one of the keys as the primary key. In commercial database systems, the choice of primary key can influence some implementation issues such as how the relation is stored on disk. A useful convention we shall follow is:

● Underline the attributes of the primary key when displaying its relation schema.

### Tags

- attributes
- tuples
- key
- Scrolling Cursors
- Protecting Against Concurrent Updates
- Modifications by Cursor
- Cursors
- Instead-Of Triggers
- Triggers in SQL
- Schema-Level Constraints and Triggers
- Tuple-Based CHECK Constraints
- Constraints on Attributes and Tuples
- Declaring Foreign-Key Constraints
- Keys Declared With UNIQUE
- Constraints and Triggers
- Modifying Views
- View Definitions
- Introduction to Selection of Indexes
- Default Values / Indexes
- Simple Table Declarations
- Defining a Relation Schema in SQL
- Deletion / Updates
- Database Modifications
- Grouping / HAVING Clauses
- Full-Relation Operations
- Natural Joins / Outerjoins
- Subqueries in FROM Clauses
- Conditions Involving Tuples
- Subqueries
- Union, Intersection, and Difference of Queries
- Interpreting Multirelation Queries
- Tuple Variables
- Disambiguating Attributes
- Queries Involving More Than One Relation
- Null Values and Comparisons Involving NULL
- Selection in SQL
- Projection in SQL
- The Database Language SQL
- Additional Constraint Examples
- Extending the Projection Operator
- Grouping
- Extended Operators of Relational Algebra
- Selection on Bags / Product of Bags / Joins of Bags
- Union, Intersection, and Difference of Bags
- Relational Operations on Bags
- A Linear Notation for Algebraic Expressions
- Dependent and Independent Operations
- Renaming
- Combining Operations to Form Queries
- Selection / Cartesian Product
- Set Operations on Relations
- An Algebra of Relational Operations
- Relational Algebra
- Attribute Lists
- Information Integration Via Semistructured Data
- Semistructured Data Representation
- Object-Oriented Versus Object-Relational
- Nested Relations
- The Object-Relational Model
- What If There Is No Key
- Representing ODL Relationships
- Representing Other Type Constructors
- Representing Set-Valued Attributes
- Nonatomic Attributes in Classes
- Declaring Keys in ODL
- Subclasses in ODL / Multiple Inheritance in ODL
- Types in ODL
- Methods in ODL
- Multiplicity of Relationships
- Relationships in ODL / Inverse Relationships
- Attributes in ODL
- Introduction to ODL
- The Type System
- Decomposition into Fourth Normal Form
- Fourth Normal Form
- Reasoning About Multivalued Dependencies
- Definition of Multivalued Dependencies
- Multivalued Dependencies
- Third Normal Form
- Boyce-Codd Normal Form
- Decomposing Relations
- Projecting Functional Dependencies
- Closing Sets of Functional Dependencies
- The Transitive Rule
- Why the Closure Algorithm Works
- Computing the Closure of Attributes
- Trivial Functional Dependencies
- The Splitting/Combining Rule
- Rules About Functional Dependencies
- Superkeys
- Using Null Values to Combine Relations - Comparison of Approaches
- An Object-Oriented Approach
- Converting Subclass Structures to Relations
- Handling Weak Entity Sets
- Combining Relations
- From E/R Relationships to Relations
- From Entity Sets to Relations
- From E/R Diagrams to Relational Designs
- Relation Instances
- Equivalent Representations of a Relation
- Tuples / Domains
- Attributes / Schemas
- The Relational Data Model
- Summary of The Entity-Relationship Data Model
- Weak Entity Set Notation
- Requirements for Weak Entity Sets
- Weak Entity Sets
- Representing Keys in the E/R Model
- Keys in the E/R Model
- The Modeling of Constraints
- Picking the Right Kind of Element
- Design Principles
- Subclasses in the E/R Model
- Converting Multiway Relationships to Binary
- Attributes on Relationships
- Multiway Relationships
- Elements of the E/R Model
- Database System Implementation
- Database Design
- Multimedia Data
- Relational Database Systems