 Download Download Presentation Relational Model

# Relational Model

Download Presentation ## Relational Model

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
##### Presentation Transcript

1. Relational Model

2. Outline • Relational Model • History • Concepts • Constraints

3. Relational Model History • Introduced by Ted Codd in 1970 • Ted Codd was an IBM Research Fellow • Laid the foundation for database theory • Many database concepts & products based on this model

4. Why is the relational model so popular? • supported by a mathematical model • relations (tables) are a good tool to use when communicating information to users and developers • efficient implementations exist for the storing of relational information in the form of Relational DBMSs (RDBMSs)

5. What is a Relation? • A Relation is a 2-dimensional table of values (rows and columns) • each row, or tuple, is a collection of related facts • the degree of the relation is the number of attributes in the relation • each column represents an attribute • each row is an instance of the relation

6. What is a Relation (cont’d)? • So, a relation is a big table of facts. • Each column contains the same attribute data with the same data type • Each row describes a real-world instance of the relation • A Relational database contains one or more relations (or tables).

7. Schema vs. Instance • the name of the relation and the set of attributes is called the schema (or the intension) • the current values in the relation represent an instance (or extension) of the data

8. More formally…… • A domainD is a set of atomic values • local phone number – The set of 7-digit numbers • names – The set of names of persons • date of birth – Possible dates of birth for people • A relation schemaR(A1, A2, …, An) is a: • relation name (R) • list of attributes (A1, A2, …, An) • each attribute Ai is the name of a role played by some domain D in the relational schema R

9. More formally (cont’d) • a relationr(R) is a subset of dom(A1) X dom(A2) X … X dom(An) • each element in a relation, called a tuple, is a collection of n values

10. Student (name, address, phone number) Attribute Tuple

11. Characteristics of Relations • tuples have no particular order • ordering of attributes not important • all values belonging to a particular attribute are from the same domain • attributes are atomic • attributes may have a null value

12. Types of Constraints • Domain constraints • Key constraints • Integrity constraints • Entity Integrity Constraint • Referential Integrity Constraint • Semantic Integrity Constraint

13. Domain Constraints • The value of each attribute, A, must be an atomic value from the domain of A • So, if an attribute is from the domain of a phone number, then the attribute must be a phone number.

14. Key constraints • value of a key uniquely identifies a tuple in a relation • a superkeyK is subset of attributes of R such that: • no 2 tuples have same values for K • Every relation has at least one superkey; what is it?

15. Keys (cont’d) • A key is a minimal superkey; a superkey from which we cannot remove any attributes and still be able to uniquely identify tuples in a relation • common keys – ID number, Social Insurance Number, etc.

16. Keys (cont’d) • A relational schema may have more than one key • each key called a candidate key • one designated as the primary key

17. Integrity Constraints • Integrity constraints are specified on a schema and hold for every instance of the schema • Entity integrity constraint • no primary key value can be null • Referential integrity constraint • if R1 refers to R2 then t1 r1(R1) must refer to an existing t2 r2(R2)

18. Foreign Keys • a foreign keyin R is a set of attributes FK in R such that FK is a primary key of some other relation R’ • a foreign key is used to specify a referential integrity constraint • Example?

19. Key examples Department (code, name, phone) Faculty (name, number, office, dept_code) FK dept_code  department (code) Course (name, number, dept_code) FK dept_code  department (code)

20. Referential Integrity • A constraint involving two relations (the previous constraints involve a single relation). • Used to specify a relationship among tuples in two relations: the referencing relation and the referenced relation. • Tuples in the referencing relation R1 have attributes FK (called foreign key attributes) that reference the primary key attributes PK of the referenced relation R2. A tuple t1 in R1 is said to reference a tuple t2 in R2 if t1[FK] = t2[PK]. • A referential integrity constraint can be displayed in a relational database schema as a directed arc from R1.FK to R2.

21. Referential Integrity Constraint Statement of the constraint The value in the foreign key column (or columns) FK of the the referencing relation R1 can be either: (1) a value of an existing primary key value of the corresponding primary key PK in the referenced relation R2,, or.. (2) a null. In case (2), the FK in R1 should not be a part of its own primary key.

22. Semantic Integrity Constraints • Constraints on data values such as: • The salary of an employee must not exceed that of his supervisor. • The total of available seats must be > 0 in order for a reservation to be made. • A person’s date of birth must be before the current date.

23. Update Operations on Relations • INSERT a tuple. • DELETE a tuple. • MODIFY a tuple. • Integrity constraints should not be violated by the update operations. • Several update operations may have to be grouped together. • Updates may propagate to cause other updates automatically. This may be necessary to maintain integrity constraints.

24. Update Operations on Relations • In case of integrity violation, several actions can be taken: • Cancel the operation that causes the violation (REJECT option) • Perform the operation but inform the user of the violation • Trigger additional updates so the violation is corrected (CASCADE option, SET NULL option) • Execute a user-specified error-correction routine

25. Example – Referential Integrity Faculty Department Course Enrolled Student

26. Insert • Provide a list of attribute values to be inserted (ie. A new tuple) • Example insert values (554433, “Bob”, 25143.56, “ENGL”) into faculty

27. Insert (cont’d) Inserts may violate constraints. Key Constraint: insert values (554433, “Bob”, 25143.56, “ENGL”) into employee (Will fail if the employee number “554433” is already in the table) Entity Integrity Constraint: insert values (NULL, “Bob”, 25143.56, “ENGL”) into employee (primary key cannot be NULL)

28. Insert (con’t) Referential Integrity Constraint: insert values (554433, “Bob”, 25143.56, “ENGL”) into employee (Will fail if the “ENGL” is not a code for a department)

29. Delete Faculty delete the faculty tuples with name=“Fred” • Why is this not a good idea?

30. Delete (con’t) • The only constraint which can be violated is the referential integrity constraint (i.e. A tuple in another relation references the tuple that is slated for deletion). delete from Faculty where name = “Fred” (referenced by tuples in Course) • Also, what if there are two people named “Fred”?

31. Modify • Change the value for one or more attributes in a relation Example: modify SALARY of Faculty where ID# = 1234 to 30000 • Modifying a primary key is like deleting a tuple and adding a new one. (Same violations may apply).