1. Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 3 The Relational Data Model and Relational Database Constraints

2. Copyright © 2011 Ramez Elmasri and Shamkant Navathe The Relational Data Model  The relational model was formally introduced by Dr. E. F. Codd in 1970 and has evolved since then, through a series of revisions.  The model provides a simple, yet rigorously defined, concept of how users perceive data.  First commercial implementations available in early 1980s  Has been implemented in a large number of commercial system

3. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Relational Model Concepts  Represents data as a collection of relations  Data in the form of two-dimensional tables.  Table of values  Row Represents a collection of related data values Fact that typically corresponds to a real-world entity or relationship a row is called a tuple  A column header is called an attribute, and the table is called a relation. Column name Interpret the meaning of the values in each row attribute

4. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Relational Model Concepts (cont’d.)

5. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Domains, Attributes, Tuples, and Relations  Domain D  Set of atomic values  Atomic  Each value indivisible  Specifying a domain  Data type specified for each domain

6. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Domains, Attributes, Tuples, and Relations (cont’d.)  Relation schema R  Denoted by R(A 1, A 2,...,A n )  Made up of a relation name R and a list of attributes, A 1, A 2,..., A n  Attribute A i  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

7. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Domains, Attributes, Tuples, and Relations (cont’d.)  Relation (or relation state)  Set of n-tuples r = {t 1, t 2,..., t m }  Each n-tuple t Ordered list of n values t = Each value v i, 1 ≤ i ≤ n, is an element of dom(A i ) or is a special NULL value  Relation (or relation state) r(R)  Mathematical relation of degree n on the domains dom(A 1 ), dom(A 2 ),..., dom(A n )  Subset of the Cartesian product of the domains that define R: r(R) ⊆ (dom(A 1 ) × dom(A 2 ) ×... × dom(A n ))

8. Copyright © 2011 Ramez Elmasri and Shamkant Navathe 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

9. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Characteristics of Relations  Ordering of tuples in a relation  Relation defined as a set of tuples  Elements have no order among them  Ordering of values within a tuple  Order of attributes and values is not that important  As long as correspondence between attributes and values maintained

10. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Characteristics of Relations (cont’d.)

11. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Characteristics of Relations (cont’d.)  Alternative definition of a relation  Tuple considered as a set of (, ) pairs  Each pair gives the value of the mapping from an attribute A i to a value v i from dom(A i )  Use the first definition of relation  Attributes and the values within tuples are ordered  Simpler notation

12. Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

13. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Characteristics of Relations (cont’d.)  Values in tuples  Each value in a tuple is atomic  Flat relational model Composite and multivalued attributes not allowed First normal form assumption  Multivalued attributes Must be represented by separate relations  Composite attributes Represented only by simple component attributes in basic relational model

14. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Characteristics of Relations (cont’d.)  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)

15. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Characteristics of Relations (cont’d.)  Interpretation (meaning) of a relation  Assertion Each tuple in the relation is a fact or a particular instance of the assertion  Predicate An alternative interpretation of a relation schema is as a predicate; in this case, the values in each tuple are interpreted as values that satisfy the predicate.

16. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Summary: Properties of Relational Tables  Values are atomic: This property implies that columns in a relational table are not repeating group or arrays.  Column values have the same type: This means that all values in a column come from the same domain.  Each row is unique: This property ensures that no two rows in a relational table are identical; there is at least one column, or set of columns, the values of which uniquely identify each row in the table.  The ordering of the columns in a relational table has no significance. Columns can be retrieved in any order and in various sequences.  The ordering of the rows in the relational table has no meaning.  Each column has a unique name: In general, a column name need not be unique within an entire database but only within the table to which it belongs.

17. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Relational Model Notation  Relation schema R of degree n  Denoted by R(A 1, A 2,..., A n )  Uppercase letters Q, R, S  Denote relation names  Lowercase letters q, r, s  Denote relation states  Letters t, u, v  Denote tuples

18. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Relational Model Notation  Name of a relation schema: STUDENT  Indicates the current set of tuples in that relation  Notation: STUDENT(Name, Ssn,...)  Refers only to relation schema  Attribute A can be qualified with the relation name R to which it belongs  Using the dot notation R.A

19. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Relational Model Notation  n-tuple t in a relation r(R)  Denoted by t =  v i is the value corresponding to attribute A i  Component values of tuples:  t[A i ] and t.A i refer to the value v i in t for attribute A i  t[A u, A w,..., A z ] and t.(A u, A w,..., A z ) refer to the subtuple of values from t corresponding to the attributes specified in the list

20. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Relational Model Constraints  Constraints  Restrictions on the actual values in a database state  Derived from the rules in the miniworld that the database represents  Inherent model-based constraints or implicit constraints  Constraints that are inherent in the data model  Schema-based constraints or explicit constraints  Can be directly expressed in schemas of the data model  Application-based or semantic constraints or business rules  Cannot be directly expressed in schemas  Expressed and enforced by application program  Data dependencies  functional dependencies and multivalued dependencies.

21. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Domain Constraints  Domain constraints specify that within each tuple, the value of each attribute A must be an atomic value from the domain dom(A).  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

22. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Key Constraints  No two tuples can have the same combination of values for all their attributes.  Superkey: a set of attributes  No two distinct tuples in any state r of R can have the same value for SK  A superkey SK specifies a uniqueness constraint  Key  Superkey of R  Removing any attribute A from K leaves a set of attributes K that is not a superkey of R any more It is a minimal superkey

23. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Key Constraints  Candidate key  Relation schema may have more than one key  Primary key of the relation  Designated among candidate keys  Underline attribute  To qualify as a primary key for an entity, an attribute must have the following properties: it must have a non-null value for each instance of the entity the value must be unique for each instance of an entity the values must not change or become null during the life of each entity instance  Other candidate keys are designated as unique keys

24. Copyright © 2011 Ramez Elmasri and Shamkant Navathe More on Primary Key  Composite Keys: A primary key containing more than one attribute is known as a composite key.  Artificial Keys: Artificial keys are permitted when  no attribute has all the primary key properties, or  the primary key is large and complex.  Primary Key Migration: A dependent entity depends on the existence of another entity for its identification. Therefore it inherits the entire primary key from the parent entity. Every entity within a generalization hierarchy inherits the primary key of the root generic entity.

25. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Rules for Primary Key  Every entity must have a primary key to identify entity instances. That is, the primary key attribute cannot be optional (i.e., have null values).  The primary key cannot have repeating values. This is called the No Repeat Rule.  Entities with compound primary keys cannot be split into multiple entities with simpler primary keys. This is called the Smallest Key Rule.  Two entities may not have identical primary keys with the exception of entities within generalization hierarchies.  The entire primary key must migrate from parent entities to child entities and from supertype, generic entities, to subtype, category entities.

26. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Key Constraints

27. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Constraints on NULL Values  Another constraint on attributes specifies whether NULL values are or are not permitted.  If an attribute must have a valid, non- NULL value, then the attribute is constrained to be NOT NULL.

28. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Relational Databases and Relational Database Schemas  Relational database schema S  Set of relation schemas S = {R 1, R 2,..., R m }  Set of integrity constraints IC  Relational database state  Set of relation states DB = {r 1, r 2,..., r m }  Each r i is a state of R i and such that the r i relation states satisfy integrity constraints specified in IC  Invalid state  Does not obey all the integrity constraints  Valid state  Satisfies all the constraints in the defined set of integrity constraints IC

29. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Integrity, Referential Integrity, and Foreign Keys  Entity integrity constraint  No primary key value can be NULL  Referential integrity constraint  Specified between two relations  Maintains consistency among tuples in two relations  The referential integrity constraint states that a tuple in one relation that refers to another relation must refer to an existing tuple in that relation.

30. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Integrity, Referential Integrity, and Foreign Keys (cont’d.)  A set of attributes in relation schema R1 is a foreign key of R1 that references relation R2 if it satisfies the following rules:  The attributes in FK have the same domain(s) as the primary key attributes PK of R2; the attributes FK are said to reference or refer to the relation R2.  Value of FK in a tuple t 1 of the current state r 1 (R 1 ) either occurs as a value of PK for some tuple t 2 in the current state r 2 (R 2 ) or is NULL  R1 is called the referencing relation and R2 is the referenced relation.

31. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Integrity, Referential Integrity, and Foreign Keys (cont’d.)  Foreign key attributes are not considered to be owned by the entities to which they migrate, because they are reflections of attributes in the parent entities.  If the primary key of a child entity contains all the attributes in a foreign key, the child entity is said to be “identifier dependent” on the parent entity, and the relationship is called an “identifying relationship.” If any attributes in a foreign key do not belong to the child's primary key, the child is not identifier dependent on the parent, and the relationship is called “non- identifying.”  Diagrammatically display referential integrity constraints  Directed arc from each foreign key to the relation it references  All integrity constraints should be specified on relational database schema

32. Copyright © 2011 Ramez Elmasri and Shamkant Navathe

33. Non-key Attributes  Non-key attributes can be in only one entity. Unlike key attributes, non-key attributes never migrate from parent to child entities.  Assign the attributes to the associated entities begins by the modeler and validate the assignment by normalization.  Rules:  In general, entities with the same primary key should be combined into one entity.  Place non-key attributes in the parent entity for parent-child relationships as long as it makes sense.  If a parent entity has no non-key attributes, combine the parent and child entities.

34. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Multi-valued Attributes  If an attribute is dependent upon the primary key but is multi-valued,  We first create a new child entity and migrate the multi-valued attributes into the child entity.  If the multi-valued attribute is unique within the new entity, it becomes the primary key. If not, migrate the primary key from the original entity.  Example:  Project(proj_ID, Proj_Name, Task_ID)  Task(Task_ID, Task_Name) Proj_IDProj_NameTask_IDTask_Name 0001MeTube001Analysis 0001MeTube002Design 0001MeTube003Implementation 0002DB001Analysis 0002DB003Implementation Project

35. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Other Types of Constraints  Semantic integrity constraints  May have to be specified and enforced on a relational database  Use triggers and assertions  More common to check for these types of constraints within the application programs

36. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Other Types of Constraints (cont’d.)  Functional dependency constraint  Establishes a functional relationship among two sets of attributes X and Y  Value of X determines a unique value of Y  State constraints  Define the constraints that a valid state of the database must satisfy  Transition constraints  Define to deal with state changes in the database

37. Copyright © 2011 Ramez Elmasri and Shamkant Navathe Update Operations, Transactions, and Dealing with Constraint Violations  Operations of the relational model can be categorized into retrievals and updates  Basic operations that change the states of relations in the database:  Insert  Delete  Update (or Modify)

38. Copyright © 2011 Ramez Elmasri and Shamkant Navathe The Insert Operation  Provides a list of attribute values for a new tuple t that is to be inserted into a relation R  Can violate any of the four types of constraints  If an insertion violates one or more constraints  Default option is to reject the insertion

39. Copyright © 2011 Ramez Elmasri and Shamkant Navathe The Delete Operation  Can violate only referential integrity  If tuple being deleted is referenced by foreign keys from other tuples  Restrict Reject the deletion  Cascade Propagate the deletion by deleting tuples that reference the tuple that is being deleted  Set null or set default Modify the referencing attribute values that cause the violation

40. Copyright © 2011 Ramez Elmasri and Shamkant Navathe The Update Operation  Necessary to specify a condition on attributes of relation  Select the tuple (or tuples) to be modified  If attribute not part of a primary key nor of a foreign key, Usually causes no problems  Updating a primary/foreign key  Similar issues as with Insert/Delete

41. Copyright © 2011 Ramez Elmasri and Shamkant Navathe The Transaction Concept  Transaction: an executing program that includes some database operations  Must leave the database in a valid or consistent state  Online transaction processing (OLTP) systems  Execute transactions at rates that reach several hundred per second