Chapter4_The Relational Data Model and the Relation Database Constraints
Chapter4_The Relational Data Model and the Relation Database Constraints
Chapter 3
§ Relational model
§ First commercial implementations available in
early 1980s
§ It has been implemented in a large number of
commercial system
§ Hierarchical and network models
§ Preceded the relational model
§ Domain D
§ Set of atomic values
§ Atomic
§ Each value indivisible
§ Specifying a domain
§ Data type specified for each domain
§ Relation schema R
§ Denoted by R(A1, A2, ...,An)
§ Made up of a relation name R and a list of
attributes, A1, A2, ..., An
§ Attribute Ai
§ Name of a role played by some domain D in
the relation schema R
§ Degree (or arity) of a relation
§ Number of attributes n of its relation schema
Domains, Attributes, Tuples, and
Relations (cont’d.)
§ Cardinality
§ Total number of values in domain
§ Current relation state
§ Relation state at a given time
§ Reflects only the valid tuples that represent a
particular state of the real world
§ Attribute names
§ Indicate different roles, or interpretations, for
the domain
Characteristics of Relations
§ NULL values
§ Represent the values of attributes that may be
unknown or may not apply to a tuple
§ Meanings for NULL values
• Value unknown
• Value exists but is not available
• Attribute does not apply to this tuple (also known
as value undefined)
Characteristics of Relations
§ Constraints
§ Restrictions on the actual values in a database
state
§ Derived from the rules in the mini-world that the
database represents
§ Typically include:
§ Numeric data types for integers and real
numbers
§ Characters
§ Booleans
§ Fixed-length strings
§ Variable-length strings
§ Date, time, timestamp
§ Money
§ Other special data types
§ Candidate key
§ Relation schema may have more than one
candidate key
§ Invalid state
§ Does not obey all the integrity constraints
§ Valid state
§ Satisfies all the constraints in the defined set of
integrity constraints IC
Operation:
Insert <‘Cecilia’, ‘F’, ‘Kolonsky’, NULL, ‘1960-04-05’, ‘6357
Windy Lane, Katy, TX’, F, 28000, NULL, 4> into EMPLOYEE.
Result: This insertion violates the entity integrity constraint
(NULL for the primary key Ssn), so it is rejected.
Operation:
Insert <‘Alicia’, ‘J’, ‘Zelaya’, ‘999887777’, ‘1960-04-05’, ‘6357
Windy Lane, Katy, TX’, F, 28000, ‘987654321’, 4> into
EMPLOYEE.
Result: This insertion violates the key constraint because
another tuple with the same Ssn value already exists in the
EMPLOYEE relation, and so it is rejected.
36
The insertion operation… An example:
Operation:
Insert <‘Cecilia’, ‘F’, ‘Kolonsky’, ‘677678989’, ‘1960-04-05’,
‘6357 Windswept, Katy, TX’, F, 28000, ‘987654321’, 7> into
EMPLOYEE.
Result: This insertion violates the referential integrity constraint
specified on Dno in EMPLOYEE because no corresponding
referenced tuple exists in DEPARTMENT with Dnumber = 7.
Operation:
Insert <‘Cecilia’, ‘F’, ‘Kolonsky’, ‘677678989’, ‘1960-04-05’,
‘6357 Windy Lane, Katy, TX’, F, 28000, NULL, 4> into
EMPLOYEE.
Result: This insertion satisfies all constraints, so it is
acceptable.
37
The delete operation
Operation:
Delete the WORKS_ON tuple with Essn = ‘999887777’ and Pno = 10.
Result: This deletion is acceptable and deletes exactly one tuple.
Operation:
Delete the EMPLOYEE tuple with Ssn = ‘999887777’.
Result: This deletion is not acceptable, because there are tuples in
WORKS_ON that refer to this tuple. Hence, if the tuple in EMPLOYEE
is deleted, referential integrity violations will result.
Operation:
Delete the EMPLOYEE tuple with Ssn = ‘333445555’.
Result: This deletion will result in even worse referential integrity
violations, because the tuple involved is referenced by tuples from
the EMPLOYEE, DEPARTMENT,WORKS_ON, and DEPENDENT relations.